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.
A security test strategy should include the inputs to the individual test plans and test plans that include:
- A specification of what types of tests should be performed,
- A specification of which what point in the delivery process should they be performed,
- What the expected output of each test plan is.
Why you need a security test strategy
I’ve been involved in a series of large-scale system procurements and a huge number of smaller implementation projects. One of the key areas to get right early in the procurement is the specification of the test requirements for delivery acceptance.
It’s rare that a supplier or an integrator will offer up a strategy or an approach for security testing. To be fair, in the UK public sector there is a default approach of just running an IT Security Health Check days before go live. The first problem with not having a security test strategy is you can’t be sure if you’ve tested everything appropriately to the level for the risk you’re running. The other big and fairly common issue is that even if you get a good test team who manage to voodoo up a good coverage test rather than some security tool jockeys you’ll then end up with a huge list of security defects right before go-live.
Suppliers, in my experience, will jump right into the other functional and non-functional test approaches as they know that the output from these activites will be tied to payment milestones. Security is still seen as a ‘blocker’ or a problem to be navigated around so they rarely volunteer to do this. Linking the successful outcomes of the security testing to payment milestones does tend to focus the suppliers attention.
The extent of your strategy obviously depends on the scale of the project you’re running, but much of this content is reusable in smaller more focused projects or in more agile security engineering programmes. My experience recently has been on large-scale, high-threat, security-critical programmes so the material in the following posts is a pretty substantial basis for a security test strategy. You might want to scale this back if you’re building an intranet content management system for example.
In the next post I’ll start describing the contents of the security testing strategy in more detail. Part two is here and part three is here.
If the project or programme is high profile enough (among the security community) you can get that reputational association to work to your benefit too as the client. Supplier-side security professionals will jump higher to get over the bar if they can do so visibly to their peers and the delivery is viewed as mission critical (and therefore has a high probability of being called A Success Story). Its a double-edged sword though – senior management and the supplier have a mutual interest in downplaying risks in a high risk delivery.
Depending on how cutover is done, the whole issue of security defects flaring up before go-live is an expectation management issue don’t you think?