Got a reminder I've not blogged in a while, so here's the next part of what I was going to talk about..
So, following on from my first post in this series I thought I'd go on to talk about penetration test scoping.
Getting the scope right is one of the most important parts of a successful pen. test. If you get the wrong scope it won't matter how brilliantly the test is executed or how great the report looks, because you won't have fulfilled the customers requirements.
Unfortunately in a lot of cases the customer doesn't actually know what they want, they may have heard that they need "one of those security test things", they may have auditors telling them they have to have one, or if you're lucky they may have an idea of what they're looking to achieve.
The best pen. tests have specific goals in mind, which allow specific tests to be scoped. Most commonly a good scope will focus on the question "what's changed", along with a view of the level of security desirable for an application.
So a high risk new application on a new platform is likely to warrant a fairly heavy review (web application, possibly code review, likely config. security review of the operating system and other new components like firewalls or routers), whereas some new pages added to an existing application where it's purely static content, might not warrant a review at all (or a very quick sense check).
Ultimately there's going to be a trade-off between time spent and the level of assurance over security that's needed. A full code-review/manual build review/architecture review of a new application is likely to provide the best level of assurance, but at a pretty high cost. A "black box" vulnerability scan and web application test, will likely be quick and therefore cheaper, but will provide a lower level of assurance.
next time (hopefully sooner) I'll talk about some of the challenges in executing tests and touch on some of the gotchas that can cause problems
