Information for

Request for

Send us an email

Valid XHTML 1.0 Transitional Valid CSS!

Home -> Experience -> Penetration Test
Outsourcing software development to China - Penetration Test

Penetration Test

What is a penetration test?
Much of the confusion surrounding penetration testing stems from the fact it is 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 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.

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 result in your organisation 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

What can be tested?
All parts of the way that 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 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 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 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.
What to do to ensure 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 may be focussed 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)?
  • Do they hold professional certifications, such as PCI, CISSP, CISA, and CHECK?
  • Are they recognised 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?
  • Do they have a standardised methodology that meets and exceeds the common ones, such as OSSTMM, CHECK and OWASP?
  • Can you get access to a sample report to assess the output (is it something you could give to your executives; do they communicate the business issues in a non-technical manner)?
  • What is their policy on confidentiality?
  • Do they outsource or use contractors?
  • Are references available from satisfied customers in the same industry sector?
  • Is there a legal agreement that will protect you from negligence on behalf of the supplier?
  • Does the supplier maintain sufficient insurance cover to protect your organisation?

Standards compliance
There are a number of good standards and guidelines in relation to information security in general, for penetration tests in particular, and for the storage of certain types of data. Any provider chosen should at least have a working knowledge of these standards and would ideally be exceeding their recommendations.

Notable organisations and standards include:

  • PCI
    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. As well as a requirement to comply with this standard, there is a requirement to independently prove verification.

  • ISACA
    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.

  • CHECK
    The CESG IT Health Check scheme was instigated to ensure that 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 on account of its rigorous certification process. Whilst good it only concentrates on 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 want a CHECK test you will need to surrender your penetration testing results to CESG.

  • OSSTMM
    The aim of The Open Source Security Testing Methodology Manual (OSSTMM) is to set forth a standard for Internet security testing. It is intended 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 be certain of the level of technical assessment independently of other organisation concerns, such as the corporate profile of the penetration-testing provider.

  • OWASP
    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 is 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.

The key areas of relevance are the forthcoming Guide to Testing Security of Web Applications and Web Services and the testing tools under the development projects. The Guide to Building Secure Web Applications not only covers design principals, but also is a useful document for setting out criteria by which to assess vendors and test systems.

Penetration Testing Technique
Once the Attack and Penetration Testing team is set up, the actual assessment of vulnerabilities begins. A typical assessment follows the basic steps shown in Figure 1.

Penetration Testing L/> C <b>Figure 1. Penetration Testing</b></p>
<p>
<ol>
<li><u>Choose the target to test.</u> Usually the Risk Assessment team identifies the targets based on their risk assessment. Applications that contain high-value data or hosts connected to the Internet are considered critical and tested first. Other line-of-business applications are tested on a rotating, sampled basis to provide a reasonably complete sense of the state of vulnerabilities on the network.</li>
<li><u>Request access from the BUIT group.</u> The Security Project Manager contacts the BUIT group, notifies them of the upcoming test, and requests design and deployment information about the target to be assessed, as well as access credentials.</li>
<li><u>Evaluate the target.</u> Using the documentation provided by the target owner, knowledge of the testers in the group, and research on the typical weaknesses of the target, the Attack and Penetration Testing team evaluates various parts of the target, including: authentication, authorization, encryption, technologies used, and configuration.</li>
<li><u>Make and communicate the plan.</u> Using the collected information, the team identifies likely vulnerabilities to target and develops a test plan outlining the types of tests to be conducted, the criteria for success, and other weaknesses to investigate. The team communicates this plan to the target owners, along with information about where their attacks will be coming from. In addition, the Corporate Security group and the Microsoft IT Global Network Operations team are notified to avoid triggering an incident response.</li>
<li><u>Conduct closed system testing.</u> Often testing begins earlier in the process, after the BUIT group has been notified, while waiting for design and deployment information. The initial vulnerability scans are conducted, and testing is performed with no access rights to the target to see if the deployment is configured in a secure way and matches the documents provided by the BUIT groups.<br/>
In this phase, testers attempt to break into the target, snoop out sensitive data, and conduct other checks to make sure the basic access is set to an appropriate level of security.</li>
<li><u>Conduct testing with a user account.</u> Once the Attack and Penetration Testing team has been granted user accounts on the host or application, open system testing begins. In this phase, the team tests a user account for each authorization level of the application, and attempts to gain access to data the user account is not authorized to access. The goal is to see if the stated security policies of the application can be violated.<br/>
The source code is also examined, if it is available, to find places where code was not written with the proper security practices. For example, a web application that does not validate data coming from a user form may be vulnerable to a SQL injection attack, where the user can destroy or spoof data stored in a database.</li>
<li><u>Record and resolve issues.</u> If a critical vulnerability is discovered at any point during the testing, the testers immediately notify the target owner and work with the team to provide the necessary expertise to resolve the issue. Otherwise the testers track discovered vulnerabilities in an issue-tracking database.</li>
<li><u>Report results back to the target owner.</u> Once the testing is complete, the testers report their results. Reports are written to address both tactical and strategic needs. Tactical resources are assigned to fix discovered issues. For common issues that are easy to resolve, the Attack and Penetration Testing team works with the target owner to resolve them immediately. Strategic resources drive wider change and adoption of wider security concepts and requirements. For vulnerabilities that are harder to fix, the Attack and Penetration Testing team provides the group with an assessment of the risk of exploitation, and any known information about the vulnerability.</li>
<li><u>Assess and document the project.</u> The Attack and Penetration Testing team continually re-evaluates its methodology and process, refining it with every new assessment project. All actions and results are documented for both regulatory reasons and to grow the overall knowledge of the team. At Microsoft, the Attack and Penetration team undergoes a quarterly review to assess feedback from internal clients and other team members on perfo
behaviour, and effectiveness.</li>
</ol>
</p>
<p>Based on the above requirements, our consultants will then identify important system vulnerabilities and mis-configuration. Such works include:</p>
<p>
<ul>
<li>Network scanning</li>
<li>Software patch level review</li>
<li>Firewall rulesets review</li>
<li>IDS (Intrusion Detection System) setting review</li>
<li>Anti-virus system review</li>
<li>Physical security review</li>
<li>Change management review</li>
<li>Internet application testing on:
<ul>
<li>Authentication</li>
<li>Encryption</li>
<li>Session management</li>
<li>Input manipulation</li>
<li>Output manipulation</li>
<li>Interpreter injection (e.g.. SQL injection)</li>
<li>Error Handling</li>
<li>Administration Interface</li>
<li>Denial of Service Attack</li>
<li>Information Leakage</li>
</ul>
</li>
</ul>
</p>
<p>Thank you for evaluating us to be your penetration testing outsourcing partner.
We look forward to a long-lasting and mutually beneficial association with your company.</p>
<p>Click<a href= here to access our contact form or send us an email at [email protected].

Home | Contact us | Site map | Terms of use | Privacy | FSA Regu tion | Money Laundering Policy| Resources | Newsletter subscription | FAQ
© 2004 - Abstract Technology Ltd. Online Payment Enabler & Offshore Outsourcing System Development