With data breaches becoming increasingly common, and increasingly costly to the victim organisation, penetration testing has become an essential and routine part of business security. It attempts to expose any vulnerabilities in an IT system so that they may be rectified. Those not familiar with such measures may well wonder what exactly goes into the process, and how these frailties may be discovered. Here we’re going to take a brief look at the methodology behind penetration testing.
Breaching the Keep
Initially, a penetration test will look to breach the outer defences of a system by attempting to compromise any and all exposed points. This will include things like servers, web applications, network and mobile devices, wireless networks and much more. The method in which this is done is likely to vary slightly depending on who is doing the testing, but it will always be a sustained and aggressive attack. It’s usually the responsibility of a third party to carry out rather than the organisation’s own IT department, as this better represents what an external threat might do. Crucially, this is an attempt to be as close to a real-world attack as possible, not just theoretically evaluating system security.
Blending in With the Locals
Beyond the outer wall, the penetration test will begin to look internally. Once a genuine, malicious force has gained entry, it is likely that it will attempt to gain access to internal resources and data by progressing through a variety of levels of security clearance. As it increases its privileges, it would be able to access increasingly valuable data or resources. The penetration test attack will do the same once inside.
Of course, from an internal perspective this part of the test is very important not only in considering external threats, but internal ones too. A malicious attack could well come from within, in which case it may never have to breach the perimeter in the first place. Employees and contractors are sometimes the originators of aggressive attempts to access restricted data and applications. Often it’s merely their lack of IT security knowledge that causes an issue. This article
Finally, as part of this methodology, we must also consider the frequency of testing. The fact is that threats do not stand still. They constantly evolve in their complexity, which means that those carrying out the test must also update their processes accordingly. As a general rule, testing has to happen whenever significant changes are made to the system, including security patches, policy updates and changes of location.
