What is Penetration Testing?

Penetration testing is an frequently baffled term. Just what is a penetration test?

Why conduct penetration testing?

What can be tested?

What should be tested?

What do you get for the money?

How to proceed to ensure the project is a success

What is a penetration test?

Much of the confusion surrounding penetration testing stems from the fact it’s a relatively recent and rapidly evolving field. Additionally, many organisations will have their own internal terminology (one man’s penetration test is another’s vulnerability review or technical risk assessment).

If nothing else, a penetration-test (actually, we prefer the term security assessment) is the process of actively evaluating your information security measures. Note the emphasis on ‘active’ assessment; the information systems will be tested to find any security issues, instead of a solely theoretical or paper-based audit.

The results from the assessment will then end up being documented inside a report, which should be presented at a debriefing session, where questions can be answered and corrective strategies can be freely discussed.

Why conduct a penetration test?

From a business perspective, penetration testing helps safeguard your organisation against failure, through:

Preventing financial loss through fraud (hackers, extortionists and disgruntled employees) or through lost revenue due to unreliable business systems and processes.

Proving due diligence and compliance to your industry regulators, customers and shareholders. Non-compliance can lead to your organisation losing business, receiving heavy fines, gathering bad PR or ultimately failing. At a personal level it can also mean loosing your job, prosecution or even imprisonment.

Protecting your brand by avoiding loss of consumer confidence and business reputation.

From an operational perspective, penetration testing helps shape information security strategy through:

Identifying vulnerabilities and quantifying their impact and likelihood in order to be managed proactively; budget can be allocated and corrective measures implemented.

What can be tested?

All parts of the way in which your organisation captures, stores and processes information can be assessed; the systems that the information is stored in, the transmission channels that transport it, and the processes and personnel that manage it. Examples of areas that are commonly tested are:

Off-the-shelf products (operating systems, applications, databases, networking equipment etc.)

Bespoke development (dynamic web sites, in-house applications etc.)

Telephony (war-dialling, remote access etc.)

Wireless (WIFI, Bluetooth, IR, GSM, RFID etc.)

Personnel (screening process, social engineering etc.)

Physical (access controls, dumpster diving etc.)

What should be tested?

Ideally, your organisation should have already conducted a risk assessment, so will be aware of the main threats (such as communications failure, e-commerce failure, loss of confidential information etc.), and can now use a security assessment to identify any vulnerabilities that are based on these threats. If you haven’t conducted a risk assessment, then it’s quite common to start with the areas of greatest exposure, such as the public facing systems; web sites, email gateways, remote access platforms etc.

Sometimes the ‘what’ of the procedure might be formed by the standards that your organisation is required to comply with. For example, a credit-card handling standard (like PCI) may require that all the components that store or process card-holder data are assessed.

What do you get for the money?

While a great deal of technical effort is applied during the testing and analysis, the real value of a penetration test is incorporated in the report and debriefing that you receive at the end. When they are not clear and easy to understand, then the whole exercise is of little worth.

Ideally the report and debriefing should be broken into sections that are specifically targeted at their intended audience. Executives need the business risks and possible solutions clearly described in layman’s terms, managers need a broad overview of the situation without getting lost in detail, and technical personnel need a list of vulnerabilities to address, with recommended solutions.

What to do to guarantee the project is a success

Defining the scope

The scope should be clearly defined, not only in the context of the components to be (or not to be) assessed and the constraints under which testing should be conducted, but also the business and technical objectives. For example penetration testing might be focussed solely on the single application on a single server, or may be more far reaching; including all hosts attached to a particular network.

Choosing a security partner

Another critical step to ensure your project is a success is in choosing which supplier to use.

As an absolute fundamental when choosing a security partner, first eliminate the supplier who provided the systems that will be tested. To use them will create a conflict of interest (will they really tell you just how they deployed the systems insecurely, or quietly ignore some issues).

Notable organisations and standards include:


The Payment Card Industry (PCI) Data Security Requirements were established in December 2004, and apply to all Members, merchants, and service providers that store, process or transmit cardholder data. In addition to a requirement to comply with this standard, there’s a requirement to independently prove verification.


ISACA was established in 1967 and has become a pace-setting global organization for information governance, control, security and audit professionals. Its IS Auditing and IS Control standards are followed by practitioners worldwide and its research pinpoints professional issues challenging its constituents. CISA, the Certified Information Systems Auditor is ISACA’s cornerstone certification. Since 1978, the CISA exam has measured excellence in the area of IS auditing, control and security and has grown to be globally recognized and adopted worldwide as a symbol of achievement.


The CESG IT Health Check scheme was instigated to ensure sensitive government networks and those constituting the GSI (Government Secure Intranet) and CNI (Critical National Infrastructure) were secured and tested to a consistent high level. The methodology aims to identify known vulnerabilities in IT systems and networks which may compromise the confidentiality, integrity or availability of information held on that IT system. In the absence of other standards, CHECK has become the de-facto standard for penetration testing in the uk. This is mainly out of its rigorous certification process. Whilst great it only specializes in national infrastructure testing and not application. However, open source methodologies such as the following are providing viable and comprehensive alternatives, without UK Government association. It must also be noted that CHECK consultants are only required when the assessment is for HMG or related parties, and meets the requirements above. If you prefer a CHECK test you will need to surrender your penetration testing results to CESG.


The purpose of The Open Source Security Testing Methodology Manual (OSSTMM) is to set forth a standard for Internet security testing. It is supposed to form a comprehensive baseline for testing that, if followed, ensures a thorough and comprehensive penetration test has been undertaken. This should enable a client to ensure of the level of technical assessment independently of other organisation concerns, like the corporate profile of the penetration-testing provider.


The Open Web Application Security Project (OWASP) is an Open Source community project developing software tools and knowledge based documentation that helps people secure web applications and web services. It’s an open source reference point for system architects, developers, vendors, consumers and security professionals involved in designing, developing, deploying and testing the security of web applications and Web Services.


Related Articles

One Response

  1. Roger Kine September 26, 2010

Leave a Reply

Your email address will not be published. Required fields are marked *