In cyber-security circles, this question often pops into discussions around Penetration Testing, ethical hacking or ‘Offensive Security’.
Penetration testing is a great validation mechanism that provides assurance that security controls are:
a) actually as effective as you think they are; and
b) at least as effective as when they were originally implemented.
A ‘clean’ Penetration Test report demonstrates that the money and resources invested in security are delivering value to the company and are also invaluable during compliance and regulatory audits.
All security controls degrade in effectiveness over time, as new techniques, tools and flaws are identified. A greater elapsed time between Penetration Tests means reduced assurance over the protection and resiliency of an organisation’s cyber assets.
For this reason, a number of industry-based security standards recommend or require Penetration tests at least every 6 months. One example is the Payment Card Industry Data Security Standard (PCI DSS) Version 3.2 that, from January 29, 2018, mandates a six-monthly validation cycle for controls segregating the Cardholder Data Environment (CDE) from the rest of the organisation’s cyber assets.
Other regulatory pressures also exist, such as the Australian Data Breach legislation that comes into effect in early 2018. Having evidence that an effective security and governance program is in place is often touted as deflecting some or most regulatory penalties should a cyber-security breach occur.
In practice, PCI DSS requirements mean performing testing from multiple locations on the internal network to ensure that no network connectivity exists from the non-CDE systems and infrastructure to the CDE. Depending on the environment and network topography, a variety of tools and techniques can validate segregation effectiveness – a topic too complex for this blog post.
The tools used to perform this validation do need to be fit for purpose and used by experienced / skilled personnel who are not validating their own work. These latter two points are important – since any QSA reviewing these outcomes must sign off that the testing occurred and was performed by suitably skilled individuals with appropriate organisational independence.
For example, the network engineer or IT Manager can’t be seen to validate their own work. For this reason, Loop often recommends that smaller clients with limited resources use external resources for penetration testing, those who have the skills and tools needed to satisfy auditor concerns over independence.
Unfortunately, increasing the number of penetration testing cycles may increase the cost of compliance. Every organisation needs to consider this in light of the costs of non-compliance, the potential perceptions of negligence in the event of a cyber security incident and the increased assurance that arises from improved governance over cyber-security controls.