Archive for May, 2011

How to develop a security test strategy, part three

This is the third 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 two is here.

This is what I want to see covered in security test plans. Whenever I ask the supplier to specify or carry out the security tests I ensure I get to review and approve the test plans and the test outputs as part of the formal project deliverable process. I also try to make sure that the inputs to the test plan are made available to the actual security testers completing the test so they get a better feel for what the context of their test results is. (more…)

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? (more…)

How to develop a security test strategy, part one

This is the first of a series of posts describing how to put together a security testing strategy and the associated test plans. Part two is here and part three is here.

What is a security test strategy

A security test strategy is a key document deliverable to get into the master plan for delivery. It sets the expectations for everyone involved and gives the project managers and programme managers the material they need to build and run their own plans. (more…)

What I need from pen test reports.

I get a lot of pen test reports to read. They vary from beautifully crafted prose extolling the skilled exploitation of the system by security testing artistes to functional dumps of tool output into a word format by jobbing vulnerability scanners.

Usually I read that report once, I use the summary to know what detail I need to understand and use the the risk or vulnerability tables to pinpoint the urgent issues to fix. Those vulnerability tables are then transfered to spreadsheets where extra columns tracking the management of the issues identified are added and populated.
(more…)

Twitter RSS