Penetration Testing Tutorial

1. Introduction A penetration test is an authorized simulation of a real-world cyberattack which is used to identify security weaknesses by way of technical flaws, misconfigurations, and/or business logic flaws. A penetration tester will attempt to exploit weaknesses to gain access, modify functionality, and/or corrupt the business logic of the target system without creating additional risk to the agency or organization. The penetration tester will attempt to perform activities of a malicious actor; however, such activities are to be conducted ethically and with the permission of the organization and/or system or network owner of said entity(ies) to be penetrated. A penetration test exercise supports the overall risk management process by identifying security risks and demonstrating exploitability of findings that may not be readily apparent when performing a security review. A penetration test can be performed with or without knowledge of the system and involves the execution of a scenario and use cases focusing on violating technical, administrative, and management controls to gain access to the system or data. Penetration tests can be used to verify and prove scan results that are false positives or false negatives. Penetration tests, as opposed to vulnerability scans, should not have false positive findings, since they only report on found vulnerabilities. Penetration tests, while capable of verifying or proving a specific false negative finding, are not exhaustive and therefore cannot prove there are no vulnerabilities to a system. The test processes described in this document are used for measuring, evaluating, and testing the security posture of a system, but test findings should not be used to the exclusion of other security processes (e.g., architecture analysis, configuration checks). 1.1 PURPOSE This procedural step-by-step tutorial provides guidance for performing penetration test exercises against contracted applications, infrastructures, and systems. This guide provides IT security professionals involved in penetration testing exercises on various IT resources as a independent, repeatable framework for conducting penetration testing activities. 1.2 SCOPE The requirements outlined within this tutorial apply to any internal or external organizations involved in penetration testing of internal and external systems and data. 1.3 POLICY This guide contains the following statements regarding penetration testing. POLICY FOR IDENTIFY FUNCTION Risk Assessment. All Internet accessible information systems, and all FIPS 199 High impact information systems are required to compete an independent penetration test (or 'pentest') and provide a Penetration Test Report documenting the results of the exercise(s) as part of the A&A package. In addition, these same systems must complete penetration tests annually. "Independent" testing means the testers are free from any perceived or actual conflicts of interest regarding the development, operation, or management of the information system(s) targeted by the penetration test. Independent vulnerability testing including penetration testing and system or port scanning conducted by a third-party, such as other external organizations, must be specifically authorized by the AO and supervised by the ISSM, or ISSO in absence of ISSM and vice versa. References FEDERAL LAWS, STANDARDS, REGULATIONS, AND PUBLICATIONS Federal Information Processing Standards (FIPS) Publication 199 , "Standards for Security Categorization of Federal Information and Information Systems." National Institute of Standards and Technology (NIST) Special Publication (SP) 800-115 , "Technical Guide to Information Security Testing and Assessment." NIST Special Publication (SP) 800-145 , "The NIST Definition of Cloud Computing." NIST National Vulnerability Database (NVD), Common Vulnerability Scoring System (CVSS) GSA DIRECTIVES, POLICIES, AND GUIDANCE The GSA policies listed below are available on the GSA.gov Directives Library page. GSA Order CIO 2100.1 , "GSA Information Technology (IT) Security Policy." CIO-IT Security-01-02: Incident Response OTHER APPLICABLE SOURCES Common Vulnerability Scoring System (CVSS-SIG), CVSS v3.1: Specification Document Open Web Application Security Project (OWASP), OWASP Serverless Top 10 OWASP, OWASP Top Ten OWASP, OWASP Web Security Testing Guide v4.2 (WSTGv4.2) Penetration Testing Execution Standard (PTES) Technical Guidelines, PTES-TG SANS, CWE/SANS Top 25 Most Dangerous Software Errors
2. Penetration Testing Overview A penetration test is an authorized simulation of a real-world cyberattack which is used to identify security weaknesses by way of technical flaws, vulnerabilities, and/or business logic flaws with or without knowing the inner workings of the system or network. NIST SP 800-115 describes two primary types of testing: external and internal testing. External security testing offers the ability to view the environment's security posture as it appears outside the security perimeter, usually as seen from the Internet, with the goal of revealing vulnerabilities that could be exploited for malicious purposes. In internal security testing, assessors with within the security perimeter, assuming the identity of a trusted insider or an attacker who has penetrated the perimeter defenses. This testing can reveal exploitable vulnerabilities and demonstrates the potential risk to the organization or agency. Internal security testing also focuses on system-level security and configurations including application and service configurations, authentication, access controls, and system hardening. 2.1 TYPES OF PENETRATION TESTS In general, there are 14 types of penetration tests. Network Penetration Testing: Network penetration testing is used to evaluate the susceptibility of systems to network attacks by identifying and exploiting weaknesses found in networks, hosts, and devices, to help assess the levels of risk posed by specific vulnerabilities in accordance with PTES and PTES-TG. Web Application Penetration Testing: Web application security testing involves an active analysis and exploitation of the web application for any weaknesses, technical flaws, or vulnerabilities in accordance with the OWASP WSTGv4.2. Software or Application Penetration Testing (includes Mobile Application and Application Programming Interface (API) testing): Software application testing evaluates the security of internal software applications using white box testing, during the developmental phase to find and remediate system flaws in the application prior to deployment. Software testing generally utilizes reverse engineering and its techniques. Social Engineering Testing: Social engineering testing evaluates the human aspect of the organization or agency using email phishing or other social or non-technical means to test the organizational security awareness training program. Wireless Network Penetration Testing: Wireless network penetration testing evaluates the susceptibility of the agency's wireless network components, including, but not limited to access points, Internet of Things (IoTs) devices, and hosts. It helps to assess the level of risk posed by specific vulnerabilities in accordance with PTES and PTES-TG. Physical Penetration Testing: The primary objective for a physical penetration test is to measure the strength of existing physical security controls and uncover their weaknesses before bad actors can discover and exploit them.

Physical penetration testing, or physical intrusion testing, reveals real-world opportunities for malicious insiders or bad actors to compromise physical barriers (e.g., locks, sensors, cameras, mantraps) and obtain unauthorized physical access to sensitive areas leading up to data breaches and system/network compromise. Incident Response (IR) Penetration Testing: IR penetration testing is performed at the request of the Incident Response Federal Lead or Information Security (IS) Division Directors with approval from the organization's CISO in response to an identified incident on an external facing Web Application. Incident response penetration tests utilize SANS Top 25 Most Dangerous Software Errors and can be authenticated or unauthenticated. The test can include specific exploits observed during the incident. Additionally, internal testing may be conducted to determine the extent of the incident. Phishing: An organization whose aim it is to reduce overall risk and attack surface must regularly perform phishing testing across the agency. Tools like Cofense PhishMe, and other tools can be used to accomplish these tasks. Phishing emails are sent to randomly selected organizational employees. By request from the associated Federal Information Security Modernization Act (FISMA) systems, the Information System Security Manager (ISSM)/Information System Security Officer (ISSO), or CISO, a phishing attack can be designed and carried out on organizational end users and admin role users. At the end of the test, a report will evaluate the attack, identifying the number of users who were successfully lured and phished. Network Stress Testing: Stress testing evaluates when a computer, application, device, or the entire network can withstand high loads and remain operational. A stress test can simulate an adverse condition that takes a system down or at least decreases its performance. These types of tests are recommended for any component on the organizational network but not recommended for any Amazon Web Services (AWS) component without prior AWS approval. Cloud Penetration Testing: Cloud penetration testing takes place in the cloud environment. During this process the penetration tester will review cloud security configurations as well as systems, web apps, and other components associated with the cloud environment. Serverless Penetration Testing: Applications running on serverless providers, such as AWS Lambda and Google Cloud Functions use serverless penetration testing. This type of testing focuses on vulnerabilities from a serverless environmental perspective, such as Hypertext Transfer Protocol (HTTP) APIs, messages, cloud storage, and IoT devices, including protocols used for these components. Testing is performed based on the OWASP Serverless Top 25, taking into consideration the attack surface and overall system complexity. Red Team Exercise: Per the NIST SP 800-53, Revision 5, a Red Team Exercise is an exercise, reflecting real-world conditions that is conducted as a simulated adversarial attempt to compromise organizational missions or business processes and to provide a comprehensive assessment of the security capabilities of an organization and its systems. Purple Team Exercises: Purple team exercises consists of a security methodology, whereby red (attack) and blue (defend) teams test cyber capabilities to enhance security knowledge and inform security improvements through continuous feedback and knowledge transfer. Open-Source Intelligence (OSINT) Assessment: OSINT is a highly diverse form of unclassified intelligence data collected from overt and covert sources to be assessed and used to make proactive decisions about imminent risks facing the organization at a tactical and strategical level.

Active OSINT collection may include active scanning for sensitive domain data on the darknet, as well as listening for darknet chatter of upcoming attacks which will assist the agency in long-term strategic decision making. Passive OSINT collection may include techniques such as using web crawlers (e.g., Google search indexing engine) to identify accidental data/vulnerability exposure on the Internet and organizational threat discussions on social media platforms. Business Logic Assessment (BLA): BLAs are manual assessments of application security weaknesses that cannot be tested effectively in an automated manner. BLAs consist of reviewing internal policies and procedures and applying those to an application's business logic to identify and limit risk to the agency. 2.2 PENETRATION TESTING APPROACHES As part of planning the penetration test exercise, the test team determines the level of access required for the exercise. The penetration tester acts like an attacker and attempts to find and exploit vulnerabilities within the defined scope and boundaries granted by the Rules of Engagement (RoE). In many cases, the penetration tester will be given a valid account on the system. The following terms are used to describe penetration testing approaches: black box, gray box, and white box. 2.2.1 BLACK BOX TESTING Black box testing assumes the penetration tester has no knowledge of the internal structure and implementation detail of the assessment object. Because an attacker will incorporate a low and slow attack strategy to avoid detection of the targeted attack, it can takes months and even years for the attacker to gain enough information about the system to infiltrate an effective cyberattack. Black box testing is very difficult to simulate, as most penetration tests typically only last a few weeks. This type of testing is done only with CISO approval. 2.2.2 WHITE BOX TESTING In white box testing, the penetration tester has full, unrestricted access to the target environment including the internal structure and source code. Testing can include running test cases to check whether the system(s) meet specification requirements. Using derived test cases, the tester exercises the test cases by providing input to the system and comparing the actual output to expected output. In this type of testing, the tester has to go beyond the user interfaces to test the correctness of the system. White box testing is one of the best approaches to find errors in the development stage of a system's life cycle. In this process, deriving test cases is an important part of the test exercise. The test case design strategy should include execution of all lines of the source code and/or all available functions at least once to complete 100% code coverage during testing. Access to supporting documentation, network, and all levels of access is required. This type of testing is done only with IS Directory or CISO approval. At a minimum, the following information will be provided to the penetration testing team: Network Diagram System Security and Privacy Plan (SSPP) Full Admin Level access to internal and external interface List of Administrator users to both Network and Web interface Vulnerability Scan Data (Web/Network/Software) Code Coverage Control Flow Testing Data Flow Testing Branch Testing Statement Testing Decision Coverage Modified condition/decision Coverage Prime Path Testing Path Testing 2.2.3 GRAY BOX TESTING Gray box testing is a hybrid approach between black box and white box testing. In gray box testing, the internal structure is partially known. This often involves having access to internal data structures and algorithms for purposes of designing the test cases but performing testing at the user or black box level. Gray box testing provides many of the benefits of white box testing such as reducing the time required for information gathering while maintaining the external threat perspective. At a minimum the following information will be provided to the Penetration Testing Team: Network Diagram SSPP Accounts (Web Interface/Network): One for each role List of Administrative users for both Network and Web interface Vulnerability Scan Data (Web/Network/Software) There are multiple factors to consider when deciding which penetration testing approach to use on a target system. The relationship between time and system exposure is important. While time is a restraint to ethical hackers, system exposure is a restraint to the non-ethical hackers. Utilizing the gray box testing approach allows ethical hackers to save time by working with developers and system administrators to understand the functionalities and operations of target systems while non-ethical hackers have to spend more time researching the system in an attempt to gain similar knowledge. 2.3 DEFINING THE SCOPE AND TEST BOUNDARY Properly defining the scope of the penetration test ensures the test exercise is focused on relevant components and safeguards against testing components outside of the system's authorization boundary unless authorized per the RoE. ISSMs/ISSOs and test personnel must strike a balance between performing a comprehensive set of tests and evaluating functionality and the features presenting the greatest risk. Any special cases or sensitivities should be carefully evaluated to prevent disruption of services prior to the start of the exercise. Accepted standard scopes are any interactions identified in the SSPP. Testing interconnections with third-party entities is considered out of scope until the third-party agrees to an assessment. 2.4 VULNERABILITY RISK RATING Risk ratings provide penetration testing teams with a metric to calculate the associated risk of an identified vulnerability. Risk ratings are defined by the NIST CVSSv3.x based score. The penetration tester uses these risk ratings to justify the assigned severities of vulnerabilities. A penetration tester will typically use the CVSSv3.x calculation: Attack Vector (AV): Attack Complexity (AC): Privileges Required (PR): User Interaction (UI) Scope (S): Confidentiality (C); Integrity (I): Availability (A) Note: Vulnerability severity can deviate from NIST CVSSv3.x when directed by SecOps management. For example, vulnerabilities associated with Binding Operational Directive (BOD) compliance have an elevated severity, while findings with risk mitigation implemented may have a decreased severity rating to account for risk mitigation. 2.5 EXPLOITING VULNERABILITIES The purpose of a penetration test is to identify risk to organization's by exploitation of potential vulnerabilities and/or other security weaknesses. Because security scan tools do not always validate the presence of a finding, scanning tools are often configured to make educated guesses about the presence of potential vulnerabilities and, in certain cases, validation required by a human to perform manual inspection and testing to confirm the finding. Actively exploiting a system is often much harder than simply identifying potential vulnerabilities. A penetration tester will utilize various open-source and commercial penetration testing tools. While the specific means and methods used to exploit vulnerabilities may vary, Section 3 defines the process which will be applied to ensure testing activities are reasonable and conducted within appropriate limits. 3. Penetration Tests Defined 3.1 ASSESSMENT AND AUTHORIZATION (A&A) PENETRATION TESTS 3.1.1 WEB APPLICATION PENETRATION TESTS The A&A Web Application Penetration Test is a gray box text (unless otherwise specified with the appropriate approvals), authenticated, and covers all OWASP WSTGv4.2 controls. All external facing FISMA systems involved in the full A&A process require a A&A Penetration Test. A request for an internal system Web Application Penetration Test requires approval from the ISSM, IS Directors, or CISO. Penetration testing of all environments (Test/Dev/Prod) will be allowed only with approval of the IS Federal Penetration Test Lead. 3.1.2 NETWORK PENETRATION TESTS The A&A Network Penetration Test is only performed on FIPS High systems or at the request of the CIO. The network side is tested using PTEST-TG and web applications are tested using OWASP WSTGv4.2 controls. Network penetration testing can be performed from an internal or external perspective depending on the needs of the network and the scope defined within the RoE. These penetration tests are authenticated and gray box unless otherwise specified with the appropriate approval of the IS Federal Penetration Test Lead. 3.1.3 API-SPECIFIC PENETRATION TESTS The API-Specific Penetration Test is performed against externally facing API endpoints. This type of testing focuses on API-specific security concerns and does not include Web Application Penetration Testing. API-Specific Penetration Tests will only be used to test API components and must be approved by the ISSM and the ISSO Support (IST) Division Director. 3.1.4 CONTAINER-SPECIFIC PENETRATION TESTS The Container-Specific Penetration Test is performed against Web Applications hosted in containerized environments. This penetration test type is based on the OWASP WSTGv4.2 tests and is tailored to focus on potential areas of exploitation specific to containerized environments, while also excluding a small number of tests that do not provide value in these types of environments. 3.2 Annual Penetration Tests 3.2.1 ONGOING AUTHORIZATION (OA) Systems in OA will receive an annual penetration test of their external URLs. Any exceptions to this rule will need the Security Operations (ISO) Division Director or CISO approval. 3.2.2 FISMA HIGH VALUE ASSETS (HVAs) All FISMA HVAs are required to have a full A&A penetration test performed annually. 3.2.3 FIPS 199 HIGH SYSTEMS All FIPS 199 High systems are required to have a full A&A penetration test performed annually. 3.2.4 FIPS 199 MODERATE AND LOW For FIPS 199 Moderate and Low systems not covered in Sections 3.2.1-3.2.3, the annual penetration test is performed on a sampling of external interfaces as approved by the CISO. These penetration tests are unauthenticated and at a minimum shall utilize OWASPs Top 10. The annual penetration test does not replace the full A&A penetration test requirement required for Moderate and Low systems undergoing A&A OA. 3.3 Delta Penetration Test Delta penetration tests focus on penetration testing minor changes to a web application. Delta Penetration Tests are authenticated, utilize OWASP WSTPv4.2, and are gray box. The scope is based on the changes made to the application. Delta penetration tests are conducted only with approval from the FISMA system ISSM/ISSO. Penetration testing of all environments (Test/Dev/Prod) will be allowed only with approval of the IS Federal Penetration Test Lead. 3.4 Incident Response (IR) Penetration Test IR penetration test is conducted with CISO approval and in response to a documented incident. Incident response penetration tests can be either unauthenticated or authenticated, and gray box, and utilize SANS Top 25 Web Application Vulnerabilities testing methodology. Note: All penetration tests must be performed against the production environment. If the system is a new system, it will need to be placed into a pre-production ("pre-prod") environments. Test and development environments are not externally accessible. Any requests for penetration testing outside of the production or pre-production environment must be submitted by the ISSM and approved by the CISO. This approval will then be documented and included in the penetration testing team's final package. Penetration testing of all environments (test/development/production) will be allowed only with the approval of the IS Federal Penetration Test Lead. 4. Penetration Testing Process Organizations that require an independent penetration test on the system or system components for all Internet facing and FIPS 199 High systems. Independent penetration test agents or teams are individuals or groups who conduct impartial penetration testing of organizational systems. Impartially implies that penetration test agents or teams are free from any perceived or actual conflicts of interest with regard to the development or operation, or management of the system(s) targeted by the penetration testing exercise. The following sections constitute a generic version of the penetration test process to be followed for network, software/application, and web application penetration testing. The test phases may be repeated as required through the process based on the scope of the exercise. 4.1 RESPONSIBILITIES A penetration test is a coordinated effort between the ISSM/ISSO, System Owner/Network Owner, and the Penetration Test Team. Then following lists the responsibilities of each party in conducting a penetration test. 4.1.1 ISSM/ISSO Initiates the penetration test request with the Penetration Test Lead. Provides the type of penetration test to be conducted. Identifies scope and provides SSPP. Signs the RoE. Note: Penetration tests outside of the accepted standard will be addressed with ISO Division's Federal and Contractual leadership. 4.1.2 PENETRATION TEST LEAD Drafts kickoff meeting slides and RoE. Schedules then kickoff meeting. Verifies the penetration test type. Validates the scope. Manages the penetration test schedule. Assigns a penetration tester(s). Signs the RoE. Circulates the RoE for signatures. 4.1.3 SYSTEM OWNER(S) Conducts system backups. Provides penetration tester access. Provides an acceptable penetration test window. Whitelists (or allowlists) the penetration test VPN. Signs the RoE. 4.1.4 PENETRATION TESTER/TEAM Signs the RoE. Conducts the penetration test. Provides risk ratings and recommendations. Validates remediations. Prepares penetration test final deliverable, the Executive Summary. 4.2 Planning Phase A kickoff meeting must be held to share contact information and establish key points of the project timeline. The kickoff meeting typically covers the following topics: Key personnel points of contact. Review of RoE document. Define responsibilities for coordination and conduct of the Penetration Test. A manual, non-intrusive review of relevant forms, queries, and previous vulnerability and/or penetration test reports. Testing window's start and finish times and dates. Final reporting process. Signed final RoE document via electronic signature, or digital signatures. The kickoff meeting should include the Penetration Test Lead, System Owner, Lead Penetration Tester, and ISSM/ISSO. Key stakeholder(s) should be fully aware of the test protocol and be able to intervene when necessary. Note: Onsite-Testing Special Considerations: Exact location, date, time, and escort musts be approved in advanced and documented in the RoE before the onsite visit. If a vendor device is required for the onsite penetration testing, the vendor POC must coordinate with the Pentest Lead to make sure the identified device is customized with the required Pentest software and licenses. Note: System Owners are responsible for backing up their systems prior to the start of testing. In addition, organizations may want to have their continuity of operations and disaster recovery plans in place and operational prior to testing so they are assured system failures due to testing can be quickly and efficiently overcome. Note: An RoE Kickoff Presentation template and additional penetration testing templates are available at the InSight Forms and Aids page . Google Docs versions of all penetration testing templates are available to internal team penetration testers on my Google Drive . Prior to signing the RoE, System Owner(s) are responsible for notifying all third parties who will be affected by the penetration testing exercise, including, but not limited to: Cloud Service Provider(s). Internet Service Provider(s). Other System Owners using the same platform. For external penetration testing, the Penetration Test Team is responsible for obtaining a signed RoE for penetration testing exercises on contracted organizational and client systems and data and providing it to their Internet Service Provider (ISP) (as necessary). Even though the client may approve the risk, it must always be clearly communicated with the applicable Internet Service Provider. Note: Any documentation provided to the Internet Service Provider (ISP) must first be cleared by the OCISO. 4.2.1 PENETRATION TEST SCOPE The penetration test scope defines what is being tested. For all penetration tests the scope must be defined and provided to the Penetration Test Team by the ISSM/ISSO. For A&A assessments, the scope should match the boundaries defined in the SSPP. If an SSPP is not available, the Penetration Test Team will work with the ISSM/ISSO and System Owner(s) to outline and validate the scope of the penetration test. The scope will be reviewed and identified in the RoE. 4.3 Defining the Rules of Engagement (RoE) Penetration testing is used to identify security weaknesses in areas such as technical flaws, misconfigurations, vulnerabilities, and/or business logic flaws. To minimize the potential for service disruption, damage, or loss of integrity, the OCISO IST Division provides an Assessment Penetration Test RoE template which is used to define the responsibilities and limitations of the test team and the System Owner(s) throughout the entire testing process. Prior to testing, the RoE template must be completed and signed by key personnel or ALCON ("all concerned") to ensure there is a common understanding of the limitations, constraints, liabilities, and considerations between the System Owner(s) and the Penetration Test Team throughout the penetration testing process. During this process, stakeholder(s) should establish specific reporting thresholds in a manner consistent with the risk and impact of any potential vulnerability. OCISO IST Division recommends that established thresholds allow the penetration tester to determine the impact of vulnerability exploitation, not just the existence or presence of vulnerabilities. Knowing the potential impact and severity of individual flaws will allow developers and engineers to focus efforts on patching and fixing vulnerabilities based on their severity levels. If the Penetration Test Team identifies a high-risk vulnerability, the finding will be reported to the ISSO, ISSM, and System Owner(s). As part of this notification, the System Owner(s) agree to not modify the system(s) until the end of the assessment or after approval from the Penetration Test Team. The Penetration Test Team will work with the System Owner(s) upon remediation(s) to validate and re-validate vulnerability findings have been cleared and resolved properly. Important principles of penetration testing exercises include, but are not limited to: The Penetration Test Team will not violate the scope or boundary of the Penetration Testing Exercise defined in the RoE. The Penetration Test Team will not maintain persistence beyond the testing window defined in the RoE. The Penetration Test Team will not introduce any new vulnerabilities to the target system(s) or its components. The Penetration Test Team will not modify or delete log/audit trails of a target system to clear their tracks. Prior to testing, ALCON involved should have a common understanding of the limitations, constraints, liabilities, and indemnification considerations between the System Owner(s) and the Penetration Test Team throughout the penetration test. The Penetration Test Team may attack the application which may disable account users or system services. In the case of any service interruptions, the System Owner(s) will be responsible for resetting accounts in a timely manner so as not to restrict or extend the testing window. 4.4 Penetration Testing Authorization Prior to commencement of penetration test activities OCISO must review the RoE and approve it. Upon approval of the RoE, permission will be granted to specific members of the Penetration Test Team to conduct penetration tests against an organization's assets defined in the applicable SSPP while conducting such test(s) in accordance with the rules defined in the project Rules of Engagement Document. 4.5 Test Phases The testing process will involve four primary phases: Information gathering (mapping/footprinting/reconnaissance) Discovery Exploitation (attack) Documentation and reporting

1. Information Gathering After performing the necessary notifications, the Penetration Test Team begins information gathering activities to collect data that can be used as inputs for discovering vulnerabilities. The testing phases may be repeated multiple times throughout the exercise (as required) based on the Rules of Engagement and structure of the tests assigned to the exercise.

The information gathered during the mapping/footprinting/reconnaissance phase is reviewed to mark potential exploitable vulnerabilities. Information gathering is critical to understanding the attack surface and establishing the system's public footprint which includes: Discovering open-source disclosures. Enumerating public interfaces. Identifying system architecture and components. Diagramming application flow and design. Surveying the hosting environment. Discovering control channels. 2. Discovery Vulnerability discovery is the process of testing and probing system entry points for flaws that can be used to generate an error condition, raise an invalid response, monitor traffic or data, or control a key system process. Examples of these vulnerabilities include: Business process/logic or design flaws. Registration forgeries. Account/password reset attacks. Self-registration and account spoofing. Administrative/control channel monitoring and capture. Development errors. Input validation. parameter processing. Authentication bypass. Script injection. Privilege escalation. Configuration flaws. Default accounts. Accessible administrative interfaces. Versioning/error messages. Unpatched services. Provide/peer relationship forgery. Open service abuse. Internal/shared configurations. 3. Exploitation During the exploitation phase, the penetration tester determines whether vulnerabilities can be exploited to gain unauthorized access to systems and/or data. The nature of this phase is largely dependent on the findings form the vulnerability discovery phase and must be conducted in accordance with the established Rules of Engagement (RoE). During the information discovery and exploitation phases of the penetration test, testers will document penetration test findings to provide a record and accounting of the specific actions taken during the test for use in the final report. Note: System Owner(s) should be allowed viewer access to penetration test findings during the penetration test exercise but will not be authorized to remediate any of the findings until after the test window ends as defined in the RoE. 4. Documentation In the documentation phase, the lead penetration tester uses the penetration test findings captured during the test to populate the "Summary of Findings" and "Detailed Findings" sections of the Penetration Test Report Template . The report will also include a summary describing the tests conducted, the findings, a severity rating based on the risk to the organizations and its interests, and related recommendations for mitigation or a technically realistic and feasible solution.

Any security issues found during the exercise(s) will be presented to the ISSM/ISSO and System Owner(s) with an assessment of the impact, a proposal for mitigation, or a technically realistic and feasible solution. 4.6 Additional Considerations Tester(s) may leverage tools and techniques employed by real attackers, including open-source, custom-developed, and commercial software tools. All penetration test exercises should focus on identifying exploitable vulnerabilities in a manner that does not affect end users, if possible. The Penetration Test Team should make every attempt to provide specific windows of time (e.g., maintenance windows) to avoid disruption of system usage. Taking advantage of vulnerabilities during penetration testing can cause system instability, which can result in the corruption or loss of data as well as unintentional Denial of Service (DoS). If a DoS testing exercise is required the OCISO IST Division will coordinate with the appropriate organizational officials for approval. 5. Incident Response Procedures (IRPs) If a reportable threat or incident is found consistent with the CIO-IT Security-01-02, the Penetration Test Team shall stop testing immediately and report the incident to the ISSO, ISSM, and System Owner(s). Testing will resume after the incident is resolved with the approval of the ISSO, ISSM, and System Owner(s). 6. Points of Contact All penetration test exercises must be coordinated through the organization's CISO or OCISO. Penetration tests of internal organizational systems (inside the corporate firewall), must also be coordinated with the Penetration Test Team and Incident Response (IR) teams. Appendix A. Penetration Testing Minimum Requirements Matrix

Table A-1. Penetration Testing Minimum Requirements Matrix NOTE: Google Docs versions of the penetration testing template are available for internal team penetration tests on this Google Drive. What is a "Get Out of Jail Free Card (GOJFC)?" Appendix C. A&A Penetration Test Detailed Minimum Requirements What is a Plan of Action and Milestones (POA&M)?