How to develop a security test strategy

What do you need to write a security test plan?

The folowing documents comprise the list of what I would expect as inputs to the creation of the individual security test plans. This is a good point to go and review your overall security delivery plan. Does it include these documents as deliverables? Does the supplier have any of these as standard off-the-shelf products?:
  • System security requirements
  • System threat model
  • System risk model
  • Secure coding standards
  • Technical threat modelling
  • Infrastructure secure configuration guides
  • Security defect metrics

What is in a security test plan?

The security test strategy should as a minimum specify the following points as the core content for each of the security test plans:
  • What are the inputs to the test plan?
  • When in the process does this test occur?
  • Who specifies the test plan contents?
  • Who performs the test?
  • How many instances of the test are expected?
  • What are the required outputs of the test?
  • What are the success or failure criteria of the test?

What types of security test plan do you need to consider?

The security test strategy needs to consider whether all or some of the following types of tests are appropriate to be completed to assure the delivery of a secure system:
  • Automated Static Code Analysis
  • Manual Source Code Analysis
  • Risk Based Penetration Tests
  • Internal and Independent Programme Penetration Tests

Automated static code analysis test plan

I would expect to complete automated static code analysis at unit Test or component test stages of the test cycle. I would also expect this to repeat for each release of custom developed components or bits of glue code during the development phase.
Automated static code analysis is used to cover compliance with the Secure coding standards and to identify common security flaws in the language used for the development. The supplier should specify the test plan and test scripts for any automated static code analysis using:
  • Secure coding standards,
  • Technical threat model.
The supplier should carry out Automated static code analysis. As the customer the only outputs I expect to see are the documented security defects (even if they are subsequently fixed) and a set of security defect metrics. The sorts of metrics I would want reported out of each release include:
  • security defects by component per thousand lines of code,
  • security defects by component by time to mitigate,
  • security defects by component by type of vulnerability.
There are likely to be large numbers of both false positives thrown up by the automated tools, where these have been identified as such by the supplier they should be removed from the defect numbers.

Manual source code analysis test plan

The manual source code analysis should be completed at the component test stage of the test cycle. I would only require this on an ad-hoc basis for high-risk custom developed components identified through the development phase of each release.
Manual source code analysis is used to more accurately cover compliance with the Secure coding standards and to identify common security flaws in the language used for the development and flaws in the application business logic that might lead to a security breach. Manual code analysis is expensive and time consuming so it should be used sparingly.
the Supplier should specify the test plan and test scripts for the manual source code analysis. The inputs to this test plan should include:
  • Secure coding standards,
  • Technical threat model,
  • System risk model.
The supplier should carry out Manual source code analysis on an ad-hoc basis as identified by the review of the defect counts from the automated static code analysis and the system risk model. The supplier should carry out manual source code analysis, as the customer the only outputs I expect to see are the documented security defects (even if they are subsequently fixed) and a set of security defect metrics. The sorts of metrics I would want reported out of each release include:
  • security defects by component per thousand lines of code,
  • security defects by component by time to mitigate,
  • security defects by component by type of vulnerability.

Risk-based penetration test plans

I would expect to specify risk based penetration tests during the integration test stage of the test cycle. I would only require this on an ad-hoc basis for high-risk subsystems identified during the build phase of each release.
Risk based penetration tests focus on functional security requirements as defined in the security requirements for the system and negative requirements which are implied security requirements derived from the possible negative outcomes identified in the system risk model.
The supplier should specify the risk based penetration tests plans but in close collaboration with an independent testing company and me as the client. The inputs to the test plan and test scripts for the risk based penetration tests should include:
  • Technical threat model,
  • Security defect metrics,
  • System security requirements,
  • System threat model,
  • System risk model.
The test should be performed by the independent testing company and the output should be the detailed documented security defects.

Programme penetration test plans

The programme penetration tests occur at the system test or end to end test stage for each release. I recommend this is completed twice, first internally by the supplier and second by an independent testing company.
The programme penetration test is the wrap up, it covers the functional security requirements defined in the system security requirements, the negative requirements implied from the negative outcomes in the system risk model and the non-functional security requirements where the performance and stress testing of security-specific components is completed.
The supplier should specify this test plan but as the client I must assure that scope before it is agreed with the security testing teams. The content of the programme penetration test plan and scripts is derived from:
  • Technical Threat Model
  • Security Defect Metrics
  • System Security Requirements
  • System Threat Model
  • Infrastructure secure configuration guides
This should be performed first by the supplier to sweep up any glaring configuration errorss and missing patches and subsequently by an independent security testing company and the output should be the detailed documented security defects.

Comments

Post a Comment

Popular posts from this blog

How to calculate maximum number of concurrent users using littile law formula

When load testing an application, the first set of tests should focus on measuring the maximum throughput. This is especially true of multi-user, interactive applications like web applications. The maximum throughput is best measured by running a few emulated users with zero think time. This means that each emulated user sends a request, receives a response and immediately loops back to send the next request. Although this is artificial, it is the best way to quickly determine the maximum performance of the server infrastructure. Littile Law: Once you have that throughput (say X), we can use  Little’s Law  to estimate the number of real simultaneous users that the application can support. In simple terms, Little’s Law states that : N = X  / λ where N is the number of concurrent users,  λ is the average arrival rate and X is the throughput. Note that the arrival rate is the inverse of the inter-arrival time i.e. the time between requests. To under...
Read more

Singleton Design Pattern using Page Factory

Image
n this tutorial, We will learn about the  Framework Design Pattern using singleton class  in Selenium. In the Previous tutorial we have seen, How can we run the Test using Page Factory. Now question is, Will we repeat the Browser invoke and Logger code again and again in each and every Test. No, To resolve this issue we will use the Singleton Pattern. We will design the Single  Test Base  class.  First, Let's see what is  Singleton Pattern .  With the Singleton design pattern you can: Ensure that only one instance of a class is created Provide a global point of access to the object In  TestBase  class, we will Design the Singleton Pattern, We will write the command code here and all Test Classes will inherit this  TestBase  class.  n previous Example, we have seen we were invoking  WebDriver   instance  in each @Test. Here, We will Implement the WebDriver initializat...
Read more