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
I'm planning to do a series of posts about penetration testing over the next couple of weeks so I thought I should start in the obvious place of defining what it actually is.
You'd think this would be relatively straightforward, but the term "penetration testing" is mis-used all over the place. Some people use it to refer to vulnerability assessment, some people use it to refer to Web Application Security Assessment, and a lot of business people use it to refer generically to any and all security assessment activity.
So what actually is it? Well for me, a penetration test is a scenario based assessment where the tester will actually try to exploit security vulnerabilities in a system or systems (depending on the scope) and then leverage those exploited vulnerabilities to gain further access to systems within the scope of the assessment which may be accessible after exploiting the initial vulnerability.
So that's what it is, why is it important to use the term correctly?
Well, different security assessment types have different characteristics and provide the owner of the system with different levels of assurance, so it's important to make sure everyone's talking about the same thing.
For example, vulnerability assessment is typically primarily tool based (eg, Nessus), focuses on networking/Operating System/maybe database level problems and doesn't usually exploit the vulnerabilities found. Pretty low risk to the systems under test (usually) but won't provide definite confirmation of problems and typically doesn't look at web applications, so it won't cover all the attack surface of a typical web application exposed over the Internet.
So if someone calls a vulnerability assessment a penetration test (and this is pretty common, in my experience) there's a good chance that someone's going to be disappointed in the results...
From the definition I used there's a couple of areas that can be very important to define correctly when conducting a test, so next time, I'm planning to go over some of the common problems and misconceptions in scoping penetration tests.
http://riskmanagementinsight.com/riskanalysis/?p=532
Very interesting post over at Riskanalysis.is on penetration testing and what it may turn in to.
There's some good reasons to do penetration testing in there and I'd agree that targeted testing to prove or disprove theories about the security environment is a smart way to use penetration testing. My feeling though is that, at the moment, only more mature security organisations will be in a good place to use it in that way.
For most companies there are other reasons why penetration testing is going to remain on the menu in its current form
So whilst I'd definitely like to see smarter use of penetration tests, I don't think that testing as it's used currently is going to go out of fashion any time soon.
Here's a question to ask your security policy people, to see whether their recommendations are actually risk based or just "best guesses"...
"Have you updated the minimum password length/complexity requirements due to recent advances in password cracking speeds?"
I was reading a couple of posts on the Red Database Security blog (here and here, and it occurred to me that despite the increases that have been made in password cracking speeds over the last couple of years, I've not seen a lot of movement in minimum password length/strength requirements to go along with it...
Obviously password policies should be tailored to mitigate the threats to the systems they protect and the primary risk that long passwords mitigate is an offline attack where the attacker has access to the encrypted password. (the more common online brute-force is better mitigated by account lockout and security monitoring in most cases)
So if crackers are getting faster, passwords should obviously get longer...