Please note that these guidelines are not final and still in development

Security Development Lifecycle

Perform Application Penetration Testing perform-application-penetration-testing

Practice #09

Perform Application Penetration Testing

Penetration testing is a security analysis of a software system performed by skilled security professionals simulating the actions of a hacker. The objective of a penetration test is to uncover potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses, and as such the test typically finds the broadest variety of vulnerabilities. Penetration tests are often performed in conjunction with automated and manual code reviews to provide a greater level of analysis than would ordinarily be possible.

Penetration Testing is generally relegated to internally developed applications that meet a certain level of maturity. (Well established SDLC, Dev/Test/Prod, publicly facing)

A campus sponsored Internal penetration testing program should be conducted on a periodic basis as part of a comprehensive SSDLC (Secure Software Development Life Cycle). The tests should be prioritized based on the applications overall risk, availability requirements, as well as data classification.

Internally conducted Penetration Tests should be well scoped, and conducted in a manner that does not conflict with the ISO led Business Continuity Policy. The Penetration Testing process is as follows:

  1. Scoping It is important that the organization have a well documented process for requesting the test as well as established rules of engagement with the application owner.
  2. Product Overview After establishing the rules of engagement, it is important to understand the functional expectations of the tool at a high level. Specific architectural information is not necessary however, an overview of expected functionality of the application should be provided.
  3. Enumeration / Scanning During the Penetration Testing process tools can be used (in a non-production context) such as nessus, Burp suite, nmap, and other tools with varying degrees of impact on traffic. These tests are meant to enumerate the vulnerabilities and potential attack vectors of the application.

    This gives the assessor a roadmap for the rest of the assessment.

  4. Exploitation After enumeration, the assessor conducts an assessment of the potential vulnerabilities, and uses this opportunity to exploit them. Exploitations are generally conducted in a strategic order in order to maximize data exfiltration.

    Additionally, during this phase, the assessor might conduct a series of tests such as fuzz testing, password cracking, brute force, and other tests to address the integrity of critical software design controls such as input validation, password salting, TLS encryption, etc.

  5. Reporting Throughout the engagement, the assessor is generally documenting their progress, techniques, as well as data access attempts (both successful as well as unsuccessful). At the end of the engagement the assessor uses their notes to generate a report. This report is a discovery of their findings, techniques, successful exploits, and a general road-map to remediating the most critical vulnerabilities.

    The assessor should meet with all stakeholders including the application owner to review the report and address questions or concerns.

Penetration Testing Framework

The most commonly used testing framework is the Penetration Testing Framework. It is a great resource for assessors that are looking for tools and techniques.

Keep in mind, the Penetration Testing Framework is NOT relegated to just software. It addresses Penetration Testing techniques in general, which includes, but are not limited to, wifi, networks, physical data centers, operating systems, mobile devices, and a number of others. The scope of this overview is just Application Penetration Testing.