Computer Penetration Testing

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

At its simplest, 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, as opposed to a solely theoretical or paper-based audit.

The results of the assessment will then be documented in a report, which should be presented at a debriefing session, where questions can be answered and corrective strategies can be freely discussed.

From a business perspective, penetration testing helps safeguard your organization 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 result in your organization losing business, receiving heavy fines, gathering bad PR or ultimately failing. At a personal level it can also mean the loss of your job, prosecution and sometimes 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 so that they can be managed proactively; budget can be allocated and corrective measures implemented.

All parts of the way that your organization 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, hardware, switches, appliances, networking equipment etc.)
• Bespoke development (dynamic web sites, in-house applications etc.)
• Telephony (war-dialing, remote access etc.)
• Wireless (WI-FI, Bluetooth, IR, GSM, RFID etc.)

Ideally, your organization 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 related to these threats. If you haven’t conducted a risk assessment, then it is 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 process may be dictated by the standards that your organization is required to comply with. For example, a credit-card handling standard may require that all the components that store or process card-holder data are assessed.

While a great deal of technical effort is applied during the testing and analysis, the real value of a penetration test is in the report and debriefing that you receive at the end. If 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.

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 may be focused purely on a 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 that 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 that they deployed the systems insecurely, or quietly ignore some issues).

Detailed below are some questions that you might want to ask your potential security partner:

• Is security assessment their core business?
• How long have they been providing security assessment services?
• Do they offer a range of services that can be tailored to your specific needs?
• Are they vendor independent (do they have NDAs with vendors that prevent them passing information to you)?
• Do they perform their own research, or are they dependent on out-of-date information that is placed in the public domain by others?
• What are their consultant’s credentials?
• How experienced are the proposed testing team (how long have they been testing, and what is their background and age)?
• Are they recognized contributors within the security industry (white papers, advisories, public speakers etc)?
• Are the CVs available for the team that will be working on your project?
• How would the supplier approach the project?
• What is their policy on confidentiality?
• Do they outsource or use contractors?
• Is there a legal agreement that will protect you from negligence on behalf of the supplier?