The underlying issue appears to stem from a perceived lack of trust by IT/Security teams with fears they could be shown up if a damming report is produced at the end of the engagement. In reality penetration testers have the same shared goal – to provide assurance that you don’t fall victim to an attack.
Work with not against a Penetration Tester
First and foremost, the aim of any security testing is ensuring your attack surface is as secure as reasonably possible. Independent security testing provides a fresh perspective on your web applications and infrastructure environments by skilled professionals who discover vulnerabilities every day that can often be overlooked when implemented or updated. At The Security Bureau we always request a technical contact for every engagement so we can work collaboratively to find every vulnerability and ensure the report does not show the team in a bad light. This dynamic approach allows for fixes to be implemented quickly and efficiently.
Web environments are increasingly complex
Networks and web applications are highly complex environments which require months of work and resources to configure securely. While it seems that a Penetration Tester only has to find one flaw to compromise an asset, a security team has to patch and securely configure hundreds to thousands of different potential entry points. This is the very reason why security testing is imperative as with such an expansive environment it’s all to easy for vulnerabilities to be introduce unknowingly.
To get a true understanding of an application’s security risk, having a single penetration test on a yearly basis is possibly not the best approach. A Penetration Test should not be seen as a “Tick Box” exercise, it should be utilised as best as possible to ensure the application is hardened and reviewed whenever a code change is made.
Penetration testing in an agile world
The current model of penetration testing does not account for agile development and ongoing deployment processes. These modern development methodologies could introduce new bugs which will not be found until up to 12 months later when the next yearly penetration test takes place. Or even worse when an attacker picks it up.
If something critical is amiss, such as a missing Windows patch, often it is easier for the client to patch this system while we are performing the engagement so it can be reduced to an informational finding. This in itself demonstrates that by working closely with your testing partner you are empowered to make changes quickly reducing the risks and how this information is reported.
We are increasingly seeing penetration testing programmes adapting to agile with tests being requested based on major releases and product updates. This approach is more aligned and robust than traditional annual testing and when combined with on the fly fixes it provides further assurance on reducing your risk exposure.
Remember why you are testing
Stepping back from the testing itself, it’s worth reflecting on why you are testing in the first place. Cyber attacks are increasing in frequency and sophistication all the time with many making headline news in mainstream media.
In most instances Penetration Tests should not be viewed as an “us vs them” exercise, we are here to ensure that every known issue is discovered and every potential entry point is examined closely.
Context is vital when considering the findings from a penetration test, while an application may be vulnerable, if the web application firewall was turned off for the engagement and no attackers can interact with the system on a normal day to day basis then the likelihood of this happening is reduced which should be highlighted in the executive summary.
By having a regimented security testing programme in place and embracing working collaboratively with your security partner you will get the most benefits from the project and keep your CEO out of the front pages.