Ethical Hacking: Penetration Testing

Penetration testing is part of the risk management of an organisation. It’s part of the processes for protecting the organisation’s high-value assets, as well as compliance with data protection legislation.

The need and scope of a penetration test is derived from the perceived and actual value of the business and its assets, as well as the estimated associated risks. For this, you’ll need to put your ‘business hat’ on – it’s your job as an ethical hacker to demonstrate the need for penetration testing and the value it has to companies.

Cyber security risk analysis

There are a number of different methods for estimating and analysing the cyber risks associated with the organisation’s assets. The more detailed and formal ones are used in environments requiring a high degree of security, such as critical infrastructure or financial institutions. Here we’ll discuss a relatively straightforward method which can be used during meetings to try to quantify the risk in front of management.

First, we need to introduce a few terms:

Asset is an entity in the organisation with an estimated value. This is what we will be looking to protect. An asset can be anything, such as the intellectual property, databases, servers critical for business operations, as well as the employee (who we will need to protect against social engineering attacks).

Risk is the potential of compromising the security controls of an asset, leading to its damage or loss. This is what we will be looking to estimate and eventually control and minimise.

Threat is an event that has the potential to materialise the risk and compromise the security of an asset. There are a number of threats we might need to consider, ranging from accidental events, such as equipment malfunction and employee mistakes, to deliberate cyber attacks and insider threats.

Vulnerability is a weakness or lack of safeguard that can be exploited by a threat. The main goal of a penetration test will be to identify the current vulnerabilities, evaluate them and recommend remediation measures.

Residual risk is the risk that remains after the implementation of security controls. Regardless of how much we harden the security of an organisation, there will always be some risk remaining. The organisation should be aware of this so that they monitor the affected assets closer.

The simple risk analysis process begins with identifying the critical assets of the organisation, focusing on assets critical for the operation of the business, and assets which could be of value for potential attackers.

Next we need to identify the potential realistic threats associated with each asset, their estimated frequency of occurring and also the impact on the asset if that threat materialises. With all that, we can calculate the annualised loss expectancy (ALE) using single loss expectancy (SLE), exposure factor (EF) and annualised rate of occurrence (ARO). The ALE will give some indication of the potential costs for the organisation if the assets are not adequately secured.

£ALE = £SLE x EF% x ARO

The business case for penetration testing is often justified through risk analysis. Return on investment (ROI) here is seen as mitigating the risk, complying with legal obligations and correcting design flaws and vulnerabilities. Some organisations (such as government, military or financial institutions) are required to execute periodic penetration tests on their critical systems or whenever a new system is being deployed.

Choosing your penetration testing team

Let’s briefly discuss the commissioning of a penetration test from a company perspective. When an organisation begins planning a penetration testing project, there are a number of factors they need to consider.

First, they need to determine the security areas to be addressed. For example, if a new piece of software has been developed, the company will need to decide whether they want a full source code audit and a white-box pentest, or black-box testing on the full deployment stack.

Alternatively, the organisation might need to evaluate the security posture of their environment – in this case, they’ll need to decide which parts of their infrastructure should be included in the scope (software, hardware, networking etc) as well as whether to test the employees’ security awareness.

Based on this draft plan, we’ll be able to draw some requirements for the expertise and experience of the pentesting teams and build a shortlist of consultancies able to do the assignment.

The organisation also needs to determine what kind of threats it will face – thinking about things like the type, sophistication and determination levels of any attackers. This will guide the penetration testers into the type of attacks they need to simulate.

In general, we should avoid pentesting live production systems and aim to emulate the full deployment stack as close as possible in a visualised environment. In some cases, however, that is not feasible and we have to target the actual systems, so we need to ensure that the pentesting team has the required expertise and experience allowing them to test production systems. Following that, they will be able to identify the technology areas to be covered as well as the expertise areas required.

You should also be able to obtain good references from the pentesters’ past and present clients. Sometimes, the consultants might not be able to give you detailed references for all recent projects they have done, particularly if these were for government, law enforcement or intelligence services.

However, the fact that they have worked on such classified assignments is a good indication that they know what they are doing and have already been vetted. It is never a good idea to employ a former malicious hacker unless you know what you are doing and really need their expertise.

The final project plan will be drawn together with the consultants. It will include the scope of the test, engagement terms, communication channels, set of deliverables, and form the basis for the formal contract. The contract with the consultants should also include liability for damage (accidents or negligence): they should have insurance covering that.

Ideally, the contract should also specify who the members of the pentesting team are, ensuring that the team as a whole will cover the required expertise, and the team members are experienced, competent and hold relevant degrees and/or certifications. This will also provide some assurance that the work will be done by the experienced professionals promised, rather than only by inexperienced ones.

Finally, the contract should include guarantees that all assets (information and items) accessed in the test will be kept confidential and disposed of at the end of the test. Sometimes the consultants might want to retain part of the data which was collected during the project – for example, if they have discovered that the organisation has been compromised and have collected some evidence (eg malware samples, network traffic, etc). In such cases, we need to make sure that the retained data does not include any sensitive information and is sufficiently anonymised.