How to develop a security test strategy, part two

This is the second in a series of posts describing how to put together a security testing stategy and the associated test plans. Part one is here and part three is here.

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

In the next post I’ll dive into the security test plans a little more. Part one is here and part three is here.