LB
  • Home
  • Reference Link Library
  • Cyber Security Fundamentals
  • Cryptography
  • Security Architecture
  • Operational Policy
  • Risk Management
  • Management & Cyber Security
  • Secure Software Design & Development
  • Network Visualization & Vulnerability Detection
  • Cyber Threat Intelligence
  • Incident Response and Computer Network Forensics
  • Gallery
  • Contact

Secure Software Design & Development

Photo: Castel Sant'Angelo and the Bridge of Angels at midnight, Rome, Italy, July 2016.
Introduction:
Micro-service Reference Architecture Diagram:
System Design Diagram:
Sua Sponte Cyber Security Solutions Test Plan: 1. Overview
2. Testing Summary:
3. Test Focus Areas:
4. Unit Test Objectives:
5. Functional Test Objectives:
6. Regression Test Objective:
7. Verification & Validation Test Objectives:
8. Mitigation Objectives:
9. Testing:
10. Test Strategy:
11. Test Environment Plan:
Introduction:
All software developers have a responsibility to ensure that their products are secure.  The process to ensure secure software begins at the very beginning of the design and development processes.  It does not end throughout the process, nor does it end after the product goes live.  The investment a company must make in ensuring the security of its software is not to be overlooked.  These costs were once seen as too burdensome for the software development companies to invest in.  The customers were responsible for seeking out additional security software to secure the operational software.  More companies are opting to invest more money up front for software that has been designed and developed to be more secure.  This way the customer does not need to invest as heavily on the back-end to secure a less expensive and less secure software.
Ethically it is important for the software developer to be honest and upfront about the security mechanisms built into their software systems.  Potential customers will understand the initial upfront higher costs to purchase the software if the developer is able to justify the costs as saving money in the long run due to a more secure software program.  All software designers and developers have a responsibility to ensure that they are not exposing their users and customers to vulnerabilities.
Micro-service Reference Architecture Diagram:
Picture
(Dambal, 2010); (Microsoft, 2018)

Public Nodes:  The Public Nodes are able to be reached via the public-facing load balancers.  The API gateway is found on these nodes. (Microsoft, 2018)
 
Backend Nodes:  The Backend Nodes run the services that the clients reach via the API gateway.  The Backend Nodes do not get Internet traffic directly.  Each Backend Node will each have their own hardware profile, and could have more than one pool of VMs. (Microsoft, 2018)
 
VM Cluster Management:  The VM Cluster Management runs the master nodes. (Microsoft, 2018)
 
Networking:  The Public Nodes, Backend Nodes, and the VM Cluster Management are in separate subnets within the same VM. (Microsoft, 2018)
 
Load Balancers:  The external facing load balancer sits in front of the Public Nodes.  The Load Balancer role is to distribute internet requests to the Public Nodes.  Another load balancer is in front of the VM Cluster Management to allow secure shell (SSH) traffic to the VM Cluster Management. (Microsoft, 2018)
System Design Diagram:
Picture
(Dambal, 2010); (Microsoft, 2018)
Sua Sponte Cyber Security Solutions Test Plan: 1. Overview
1.1. Purpose
            The purpose of this document is to define the scope, focus areas, and objectives of the Sua Sponte Cyber Security Test Plan.  The Sua Sponte Cyber Security Test Plan shall include unit tests, functional tests, regression tests, verification, validation, and mitigation plans.  For unit tests each set of functions that implement the functional requirements, a unit test shall ensure the function is properly implemented.  For functional tests shall provide description of what functional testing shall be performed for the software application.  For regression tests, it shall be explained how to ensure changes by a developer to a portion of the code will not introduce errors elsewhere.  Descriptions of the processes for verification and validation of the software application shall be provided.  An explanation for mitigation strategies addressing vulnerabilities or software errors not identified using the testing mechanisms shall be implemented as part of the Sua Sponte Cyber Security Test Plan.
1.1. Scope

This document details the testing that will be performed by the project team for the Sua Sponte Cyber Security Test Plant. It defines the overall testing requirements and provides an integrated view of the project test activities. Its purpose is to identify what shall be tested, how the testing shall be performed, and identify what resources shall be required.

2. Testing Summary:
2.1. Scope of Testing
2.1.1. In scope 
            The project team shall take a multipronged approach in conducting testing.  The project team shall be responsible for the Unit Testing, Functional Testing, Regression Testing, the Verification and Validation, as well as the Mitigation of errors.  These tests shall test to ensure that the business requirements, data requirements, and the timing requirements are met.  The project team shall also be responsible to validate that the specifications capture the customer’s needs, and verifying that the software meets the specifications.  Finally, the project team shall mitigate all errors discovered during the testing phases.
 
2.1.2. Out of scope
             The project team shall not test the usability of the application.  Usability testing shall be conducted by the users of the application.  It is also not the responsibility of the project team to perform integration testing.  Integration testing shall be conducted by the vendor. 
3. Test Focus Areas:
3.1. Platform Testing
  • For Unit Testing several automated tools shall be used, to include:
    • Junit: It is a free to use testing tool used for Java programming language
    • NUnit: It is a widely used unit-testing framework use for all .net languages
    • PHPUnit: It is a unit testing tool for PHP programmer
  • The Functional Testing tools that shall be used include:
    • QTP: This is a user-friendly functional test tool by HP
    • JUnit: It is used mainly for Java applications
  • The Regression Testing Tools that shall be used include:
    • QTP: It is an automated software designed to automate functional and regression test cases.
    • RFT: The Rational Functional Tester is a Java tool used to automate the test cases of software applications.
  • The Verification and Validation Testing:
    • System Test
    • Beta Test
4. Unit Test Objectives:
Ref
Function
Test Objective
Evaluation Criteria
X-Ref
P
1.1 - 1.6
Business Requirements
To ensure that all of the business requirements are accomplished. The War-fighter should be able conduct all actions associated with Requests for Information, view financial records, input and update data, and generate reports on Army operations.
War-fighters are able to submit Requests for Info
War-fighters are able to cancel Requests for Info
War-fighters are able to access financial records
War-fighters are able to view old Requests for Info
War-fighters are able to input or update data
Are able to generate reports on army operations
2.1 – 2.9
High
1.7 - 1.9
Data Requirements
To ensure that the data requirements are accomplished.  The War-fighter shall be able to access and edit the War-fighters records, operational intelligence information, and financial information.
War-fighters records ( name, permanent address, DoD ID number, social security number, etc, but no health information) are able to be accessed and edited
Operational intelligence information (reports, maps, intelligence records, etc.) is able to be accessed edited
Financial Information (payroll, pending debts, etc.) is able to be accessed and edited
2.1 – 2.3; 2.10 – 2.12
High
1.10 - 1.12
Timing Requirements
To ensure that the timing requirements are accomplished.  The application shall have no more than 1 second response time, conduct automatic updates every 6 months, and data shall have the ability to be archived indefinitely.
Latency: No more than 1 second response time on any task of the interface
Frequency: Upgrade 6 months
Duration: Data shall be archived indefinitely
2.1 - 2.3; 2.13 – 2.15
High
5. Functional Test Objectives:
Ref
Function
Test Objective
Evaluation Criteria
X-Ref
P
2.1 – 2.3
Mainline
To test the main functions of an application:
  • Business functions
  • Data Functions
  • Timeline Functions
  • Identify the test input (test data)
  • Compute the expected outcomes with the selected test input values
  • Does the expected result match the actual result
1.1 – 1.12
High
2.4
Submit Requests for Info
War-fighter is able to submit Requests for Info
  • War-fighter able to send Request for Info to application
  • Request for Info is received by application
1.1 – 1.6
High
2.5
Cancel Requests for Info
War-fighter is able to cancel Requests for Info
  • War-fighter able to send cancellation on sending Request for Info to application
  • Cancellation of sent Request for Info received by the application
1.1 – 1.6
High
2.6
Access financial records
War-fighter is able to access financial records
  • War-fighter is able to view financial records through application
1.1 – 1.6
High
2.7
View old Requests for Info
War-fighter is able to view past Request for Info
  • War-fighter is able to view archived History of Request for Info
  • Application archives all Requests for Info
1.1 – 1.6
High
2.8
Input or update data
War-fighter is able to input and update data
  • War-fighter is able to input data into the application
  • War-fighter is able to update data in the application
1.1 – 1.6
High
2.9
Generate reports on army operations
War-fighter is able to view reports on army operations
  • The War-fighter is able to view all reports in which they have a need to know
  • Application correctly assess War-fighters need to know
1.1 – 1.6
High
2.10
Access and edit records
War-fighter is able to access and edit records (name, permanent address, DoD ID number, social security number, etc, but no health information)
  • War-fighter is able to access personnel records within the application
  • War-fighter is able to edit personnel records within the application
  • Application is able to determine the war-fighters need to know
1.7 - 1.9
High
2.11
Access and edit Operational intelligence information
War-fighter is able to access and edit Operational intelligence information (reports, maps, intelligence records, etc.)
  • War-fighter is able to access Intelligence Info
  • War-fighter is able to edit Intelligence Info
  • Application is able to determine the war-fighters need to know
  • Application is able to determine the war-fighters security clearance
1.7 - 1.9
High
2.12
Access and edit Financial Information
War-fighter is able to access and edit financial records
  • War-fighter is able to access financial records within the application
  • War-fighter is able to edit financial records within the application
  • Application is able to determine the War-fighters need to know
1.7 - 1.9
High
2.13
Latency
No more than 1 second response time on any task of the interface
  • All actions and functions are processed with 1 second or less response time
1.10 - 1.12
High
2.14
Frequency
Upgrade every 6 months
  • Application checks for daily updates
  • Application checks for bi-yearly upgrades
1.10 - 1.12
High
2.15
Duration
Data shall be archived indefinitely
  • All data shall be archived indefinitely on the application
  • All data shall be archived indefinitely at an off-site storage location
1.10 - 1.12
High
6. Regression Test Objective:
Ref
Function
Test Objective
Evaluation Criteria
X-Ref
P
3.1 – 3.3
Mainline
To test the main functions of an application:
  • Business functions
  • Data Functions
  • Timeline Functions
  • Identify the test input (test data)
  • Compute the expected outcomes with the selected test input values
  • Does the expected result match the actual result
1.1 – 1.12; 2.1 – 2.3
High
3.4
Submit Requests for Info
War-fighter is able to submit Requests for Info
  • War-fighter able to send Request for Info to application
  • Request for Info is received by application
1.1 – 1.6; 2.4
High
3.5
Cancel Requests for Info
War-fighter is able to cancel Requests for Info
  • War-fighter able to send cancellation on sending Request for Info to application
  • Cancellation of sent Request for Info received by the application
1.1 – 1.6; 2.5
High
3.6
Access financial records
War-fighter is able to access financial records
  • War-fighter is able to view financial records through application
1.1 – 1.6; 2.6
High
3.7
View old Requests for Info
War-fighter is able to view past Request for Info
  • War-fighter is able to view archived History of Request for Info
  • Application archives all Requests for Info
1.1 – 1.6; 2.7
High
3.8
Input or update data
War-fighter is able to input and update data
  • War-fighter is able to input data into the application
  • War-fighter is able to update data in the application
1.1 – 1.6; 2.8
High
3.9
Generate reports on army operations
War-fighter is able to view reports on army operations
  • The War-fighter is able to view all reports in which they have a need to know
  • Application correctly assess War-fighters need to know
1.1 – 1.6; 2.9
High
3.10
Access and edit records
War-fighter is able to access and edit records (name, permanent address, DoD ID number, social security number, etc, but no health information)
  • War-fighter is able to access personnel records within the application
  • War-fighter is able to edit personnel records within the application
  • Application is able to determine the war-fighters need to know
1.7 - 1.9; 2.10
High
3.11
Access and edit Operational intelligence information
War-fighter is able to access and edit Operational intelligence information (reports, maps, intelligence records, etc.)
  • War-fighter is able to access Intelligence Info
  • War-fighter is able to edit Intelligence Info
  • Application is able to determine the war-fighters need to know
  • Application is able to determine the war-fighters security clearance
1.7 - 1.9; 2.11
High
3.12
Access and edit Financial Information
War-fighter is able to access and edit financial records
  • War-fighter is able to access financial records within the application
  • War-fighter is able to edit financial records within the application
  • Application is able to determine the War-fighters need to know
1.7 - 1.9; 2.12
High
3.13
Latency
No more than 1 second response time on any task of the interface
  • All actions and functions are processed with 1 second or less response time
1.10 - 1.12; 2.13
High
3.14
Frequency
Upgrade every 6 months
  • Application checks for daily updates
  • Application checks for bi-yearly upgrades
1.10 - 1.12; 2.14
High
3.15
Duration
Data shall be archived indefinitely
  • All data shall be archived indefinitely on the application
  • All data shall be archived indefinitely at an off-site storage location
1.10 - 1.12; 2.15
High
7. Verification & Validation Test Objectives:
Ref
Function
Test Objective
Evaluation Criteria
X-Ref
P
4.1-4.3
Mainline
Verify and Validate the main functions of an application:
  • Business functions
  • Data Functions
  • Timeline Functions
  • Identify the test input (test data)
  • Compute the expected outcomes with the selected test input values
  • Does the expected result match the actual result
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15
High
4.4- 4.6
System
Verify and Validate the main functions of an application:
  • Business functions
  • Data Functions
  • Timeline Functions
  • Identify the test input (test data)
  • Compute the expected outcomes with the selected test input values
  • Does the expected result match the actual result
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15
High
4.7 - 4.9
Beta Test
Verify and Validate the main functions of an application:
  • Business functions
  • Data Functions
  • Timeline Functions
  • Identify the test input (test data)
  • Compute the expected outcomes with the selected test input values
  • Does the expected result match the actual result
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15
Medium
8. Mitigation Objectives:
Ref
Function
Test Objective
Evaluation Criteria
X-Ref
P
5.1 - 5.3
Mainline
To mitigate all errors with the main functions of an application:
  • Business functions
  • Data Functions
  • Timeline Functions
  • Identify the risk
  • Reduce the impact of risk
  • Reduce the probability or likelihood of risk
  • Monitor the risk
1.1 – 1.12; 2.1 – 2.15; 3.1 – 3.15; 4.1 – 4.9
Medium
9. Testing:
1.1. Unit Testing
            Unit testing is verifying the correctness of an isolated section of a code.  It is done during the development, or coding, of an application.  The intent is to isolate each part of a program and verify that each part is correct. (Guru99, 2018)
            Using the automated approach, codes shall be isolated to test them more rigorously.  The user shall copy and paste the function into its own environment.  In isolating the code, unnecessary dependencies between the code being tested and other units are revealed.  These unnecessary dependencies shall then be eliminated. (Guru99, 2018)
            The following unit testing best practices shall be followed:
  • Unit Test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected.
  • Test only one code at a time.
  • Follow clear and consistent naming conventions for unit tests
  • In case of a change in code in any module, ensure there is a corresponding unit Test Case for the module, and the module passes the tests before changing the implementation
  • Bugs identified during unit testing must be fixed before proceeding to the next phase in SDLC
  • Adopt a "test as your code" approach.
(Guru99, 2018)
 
For Unit Testing several automated tools shall be used, to include:
 
  • Junit: It is a free to use testing tool used for the Java programming language.  Junit shall be used to test all the business, data, and timing requirements that use the Java programming language.
 
  • NUnit: It is a widely used unit-testing framework use for all .net languages.  NUnit shall be used to test all the business, data, and timing requirements that use .net languages.
 
  • PHPUnit: It is a unit testing tool for PHP programmer.  PHPUnit shall be used to test all the business, data, and timing requirements that do not use either Java r .net programming languages.
 
1.2. Functional Testing
            Functional testing verifies each function of the software application is operating in conformance with the requirement specification.  All functionality of the system is tested.  The results are then compared with the expected results.  Functionality testing shall be conducted using automation. (Guru99, 2018)
            The following steps for a functional test shall be conducted:
  1. Identify test data
  2. Compute the expected outcomes with the selected test input values
  3. Execute test cases
  4. Compare actual and expected test results
(Guru99, 2018)
           
The Functional Testing tools that shall be used include:
 
  • QTP: This is a user-friendly functional test tool by HP.  QTP shall be used as the functional test tool on all the functions associated with the business, data, and timing requirements.  This functional testing tool was chosen as it is very user-friendly.
 
  • JUnit: It is used mainly for Java applications.  The JUnit shall be used as the functional test tool for all Java language functions associated with the business, data, and timing requirements.
 
1.3. Regression Testing
            Software maintenance is an activity which includes enhancements, error corrections, optimization and deletion of existing features. These modifications may cause the system to work incorrectly. Therefore, Regression Testing becomes necessary. (Guru99, 2018)
            Regression testing is a type of software testing that confirms a recent program or code change has not adversely affected existing features.  Regression testing is full or partial selection of already executed test cases which get re-executed to ensure functionality works fine.  In other words, it checks that old code still works when the new code is implemented. (Guru99, 0218)
            Regression testing shall be conducted based on the prioritization of test cases.  The prioritization of test cases shall be done based upon the business impact, and the critical and frequently used functionalities.  This will greatly reduce the regression test suite. (Guru99, 2018)
            The following regression test cases shall conducted based upon the following priority:
  1. Test cases which have frequent defects
  2. Functionalities which are more visible to the users
  3. Test cases which verify core features of the product
  4. Test cases of Functionalities which has undergone more and recent changes
  5. All Integration Test Cases
  6. All Complex Test Cases
  7. Boundary value test cases
  8. Sample of Successful test cases
  9. Sample of Failure test cases
(Guru99, 2018)
To ensure that proper regression testing management is being conducted, the following rules must be followed by managers:
  • Code being regression tested should be under a configuration management tool
  • During the regression test phase, no changes shall be allowed to code.  Regression test code shall be kept immune to developer changes.
  • The database used for regression testing shall be isolated. No database changes shall be allowed
(Guru99, 2018)
 
The Regression Testing Tools that shall be used include:
 
  • QTP: It is an automated software designed to automate functional and regression test cases.  QTP shall be used as the regression testing tool for all functions associated with the business, data, and timing requirements.  The QTP testing tools may also be used during the functional testing phase as well as the regression phase.
 
  • RFT: The Rational Functional Tester is a Java tool used to automate the test cases of software applications.  RFT shall be used to test all Java Language functions associated with the business, data, and timing requirements during the regression testing phase.
 
1.4. Verification & Validation Testing
            Verification is concerned with whether the system is well-engineered, and error-free.  While Validation is concerned with checking that the system will meet the customer’s actual needs.  Verification will help determine whether the software is of high quality, but it will not ensure that the system is useful.  Validation is the process of checking whether the specification captures the customer’s needs, while verification is the process of checking that the software meets the specifications. (Serendipity, 2018)
            The Processes that shall be followed to verify and validate the software application is indicated by each of the bullet points below:
  • Verification of requirement against defined specifications
  • Verification of design against defined specifications
  • Verification of product code against defined standards
  • Verification of terms, conditions, payment, etc., against contracts
  • Code reviews – Systematic examination of the product's source code
  • Inspections – Peer review of work products and documentation
  • Walkthroughs – Inspecting source code by following logical paths through the algorithms or code as determined by input conditions and choices made along the way
  • Determining the types and levels of product integrity to be verified and validated
  • Developing performance metrics to allow tracking of project completion against defined milestones
  • Identifying an integrity schema to measure the project's conformity to requirements
  • Planning and scheduling of V&V activities considering the project management plan and schedule
  • Consulting with stakeholders to assess their involvement and buy-in regarding system functionality and the system's ability to meet their needs
  • Reviewing and providing recommendations to improve both the management and technical aspects of the project including evaluating project progresses, resources, budgets, schedules, and reporting
  • Reviewing and analysing project management and software development activities, performance, and operational policies, processes, documentation, and products for accuracy and completeness
  • Reviewing product architecture for feasibility, consistency, and adherence to related industry standards
  • Reviewing traceability of product functions to original requirements
  • Documenting V&V activities and assessment results in the form of task reports, activity summary reports, anomaly reports, test documents, and eventually a final V&V summary report
(UCOP, 2018)
 
The Verification and Validation Testing:
 
  • System Testing shall be conducted by the project team in order to verify and validate that all units and functions are working properly in the application.
 
  • Beta Testing shall be conducted by the vendor in order to verify and validate that all of the units and functions are working properly within the application.  The Beta Testing shall also be conducted to ensure that the vendor is satisfied that all the business, data, and timing requirements have been met by the application.
 
1.5. Mitigation
            Measuring risk in current software systems can be seen as these types: “(a) internal risks that are within the control of the project manager and (b) external risks that are beyond the control of project manager.  Risk management is carried out to:
  1. Identify the risk
  2. Reduce the impact of risk
  3. Reduce the probability or likelihood of risk
  4. Risk monitoring”
(Test Institute, 2018)
            It is important to keep one up to date on the internal risks.  This is the type of risk that can be within the control of the project manager.  In managing the risk it becomes important follow certain processes and standards.  These standards should be followed by the project manager as well as by each member of a team.  A few of these standards include:
  • Always be forward-thinking about risk management.
  • Use checklists, and compare with similar previous projects.
  • Prioritize risks, ranking each according to the severity of exposure.
  • Develop a top-10 to top-20 risk list for your project.
  • Vigorously watch for surfacing risks by meeting with key stakeholders – especially with the marketing team and the customer.
  • As practicable, split larger risks into smaller, easily recognizable and readily-manageable risks.
  • Strongly encourage stakeholders to think proactively and communicate about risks throughout the entire project.
(CAST, 2018)
            The strong aspect of measuring risk is the current software systems is the processes associated with risk management.  “A project manager has to deal with risks arising from three possible cases:  (1) Known knowns, (2) Known unknowns, (3) Unknown Unknowns.” (Test Institute, 2018)  Once the project manager is able to address each of the three possible cases they must then quantify the risks.  “This includes:  (1) Giving a precise description of risk event that can occur in the project, (2) Defining risk probability that would explain what are the chances for that risk to occur, (3) Defining how much loss particular risks can cause, and (4) Defining the liability potential of risk.” (Test Institute, 2018)  The project manager must then ensure that the following processes are followed: “(1) Software Risk Identification, (2) Software Risk Analysis, (3) Software Risk Planning, and (4) Software Risk Monitoring.” (Test Institute, 2018)
            The main weakness in the risk management of software is that the best practices are very general.  This is done because of the fast pace of technology advancement as well as the ever evolving threats.  As a result, any specific solution that is given is nothing more than a temporary solution.  Once a patch is implemented the attackers will find a new way in which conduct their attacks.  This requires the cyber security professionals to be proficient in the latest technologies as well as have a creative mind to come up with new effective solutions in an ever changing environment.
10. Test Strategy:
10.1. Test level responsibility
Primary (P); Secondary (S); Tertiary (T)
Test Level
External Party
Project Team
Business
Unit Testing
S
P
T
Functional Testing
S
P
T
Regression Testing
S
P
T
Verification & Validation Testing
S
P
T
Mitigation
T
P
S
10.2. Test Execution Schedule
Test Type
Objectives
Priority
Schedule
Unit Testing
The objectives are to verify that the application:
  • Meets the defined requirements;
  • Performs and functions accurately;
  • Correctly handles error conditions;
  • Interfaces function correctly;
  • Data load is successful.
Unit testing will occur during programming and in a controlled manner, ensuring the units meet the requirements.
High
10/22/2018
To
10/29/2018
Functional Testing
The objectives are to verify that the application:
  • Meets the defined requirements;
  • Performs and functions accurately;
  • Correctly handles error conditions;
  • Interfaces function correctly;
  • Data load is successful.
Functional testing will occur in an iterative and controlled manner, ensuring the solution matches the defined requirements.
High
10/30/2018
To
11/05/2018
Regression Testing
The objectives are to verify that the recent program or code changes have not adversely affected the application.
High
11/06/2018
To
11/12/2018
Verification & Validation Testing
The objectives are to verify that the application meets the specifications and to validate if the application meets the customer’s needs.
Medium
11/13/2018
To
11/20/2018
Mitigation
The objectives are to identify and correct any errors that may have occurred as a result of the previous testing phases.
  • System Testing shall be conducted by the production team.
Beta Testing shall be conducted by the vendor.
Medium
11/21/2018
To
11/28/2018
11. Test Environment Plan:
11.1. Environment Roles and Responsibilities
Role
Staff Member
Responsibilities
Release Manager
Jake Smith
Responsible for overall establishment, coordination and support of the test environment
Test Manager
Mary Rossi
Responsible for advising release manager of environment requirements for planning, establishment and ongoing
Project Manager
Leo Blasius
Escalation point for environment issues.
Proudly powered by Weebly
  • Home
  • Reference Link Library
  • Cyber Security Fundamentals
  • Cryptography
  • Security Architecture
  • Operational Policy
  • Risk Management
  • Management & Cyber Security
  • Secure Software Design & Development
  • Network Visualization & Vulnerability Detection
  • Cyber Threat Intelligence
  • Incident Response and Computer Network Forensics
  • Gallery
  • Contact