Attachment 3.docx

Social Security Administration (SSA)

Security Categorization: [Enter Categorization]

Rules of Engagement and Test Plan For [System Name (Acronym)]

[DRAFT/FINAL] Version 0.1

[Date Format Ex: March 15, 2012]

Performed by {Organization Name} {Street Address} {City, State, and Zip Code}

Revision History

Table of Contents

IMPORTANT NOTE

Document Font Guidance

All RED Font must be filled in with the appropriate description (i.e., [System Name] must be replaced with the appropriate System Name) before the final document is submitted.

All [Organization] placeholders are to refer to the company or organization performing the security assessment/penetration testing service.

All [Component] placeholders are to refer to the SSA Component that owns the Information System and/or is sponsoring the security assessment/penetration testing service.

All BLUE Font is provided as reference or instruction and must be removed prior to the document finalization.

All BLACK Font is to remain unchanged.

THIS NOTE WILL BE REMOVED BEFORE FINAL DELIVERY OF ROE

1. Introduction The purpose of this document is to establish and formalize the parameters for the cyber security services and testing activities which will be conducted by [Organization] for [Component]. The [Organization] Assessment Team efforts will consist of a Vulnerability Assessment and Penetration Test to be conducted [Date Range Activities to be Performed]. This may include, but is not limited to, conducting vulnerability scans and penetration testing on [Component] external and internal networks, open source intelligence gathering, social engineering, wireless access point detection and exploitation of vulnerabilities discovered. [Organization] and [Component] will abide by this agreement.

Purpose Security testing performed by [Organization] is conducted to test the adequacy and effectiveness of security control measures in place to protect the security and integrity of sensitive information technology (IT) systems and data. In execution of security testing, experts identify system level, network level, application level, and configuration level vulnerabilities that introduce risks into the environment.

The test results from this engagement will be used to identify vulnerabilities and evaluate the effectiveness of technical controls in the [System Name] infrastructure. This information will be provided to [Component] senior management and engineers to allow for the development of remediation plans to mitigate the identified deficiencies and increase overall system security. Moreover, the test will provide valuable information on the potential effects to the confidentiality, integrity, and availability of [Component] data and network resources within the [System Name].

The Rules of Engagement (ROE) establish the guidelines followed by the [Organization] personnel during the assessment. The ROE defines the specific plans, methodology, and testing activities for the [System Name] assessment. This allows the [Organization] to perform testing in a manner that minimizes impact on operations while maximizing the usefulness of the results. This test plan is submitted for review and approval by the SSA Chief Information Officer (CIO) prior to execution of testing.

Scope of Testing The [System Name] contains [General Technical Description of System components] located at [# of locations to be tested] sites, the [General Description of physical locations]. There are approximately [Estimate of active hosts included in assessment] hosts at the sites that will be included in the assessments. Testing will be conducted from two facilities:

1. Internal assessment activities will be conducted at the [Component Location]. The site is maintained by [Component]. Testing will be performed against internal [System Name] systems, connected to the [System Name] infrastructure, and designated by the Point of Contact (POC).

2. External assessment activities will be conducted at the [[Component] assessment location] via non-[Component] provided Internet connection. Testing will be performed against [Component] identified externally accessible [System Name] systems, as designated by the POC.

Testing Environment All IT components within the [System Name] and identified by the [Component] as within the included ranges, as defined in Appendix B, are assumed to be in the scope of the engagement unless otherwise identified by the [Component] POC. At the time of this agreement, specific assessment environment information is unknown to the [Organization]. The [Component] POC should, if possible, provide documentation on the testing environment to [Organization] prior to the engagement.

If the assessment is to be performed against a test/development environment, the environment should mimic the production system to the fullest extent possible. Standard system and security applications and security policies should be implemented and configured as normally deployed in the production environment. This will allow the team to assess the hosts and network as they would expect to find them in a production environment. Any discrepancies between a normal production implementation and the test environment should be provided to [Organization] prior to arriving on site for testing.

Methodology The [Organization] will use an approved suite of tools to perform security testing. External testing will be conducted from the [[Component] assessment location]. Internal testing will be conducted by connecting approved customer furnished equipment (CFE) laptops to the [Component] network. Various security tools will collect data from [Component] systems and the data will be analyzed to determine system vulnerabilities and paths for the testing team to possibly exploit (if within the scope of the assessment). All assessment tools available to the team are well known and widely available. Configuration of individual software assessment tools will be provided upon request. For a list of tools used during the specific assessment services, refer to Appendix G.

The [Organization] will follow common vulnerability assessment and penetration methodologies to ensure consistent and repeatable evaluations. Methodologies used include the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-115, Open Source Security Testing Methodology Manual (OSSTMM) and Open Web Application Security Project (OWASP) testing guide. The use of common methodologies will allow the [Component] to conduct follow-on evaluations utilizing [Organization] testing techniques.

Assumptions and Limitations Test Plan

· The ROE must be signed and approved prior to penetration test planning finalization.

· Test plan must include both calendar time and man hours.

· Test plan must include hours of testing.

Schedule

· The penetration testing schedule will be developed to provide additional details and will include detailed penetrating testing activities.

· During execution, a [Daily/Weekly] teleconference will be conducted with [Component]. Stakeholders to provide a summary of the activities to occur for the time period.

· An agreed upon timeframe is required to allow the test team to complete the report prior to the 1st draft submission to [Component] stakeholders.

Test Process

· A preliminary penetration testing vetting process will be conducted with [Component] prior to execution to ensure that the necessary preparation has been made and ensure that [Component] is ready for execution.

· [Component] will provide the test team with a signed version of the RoE before any testing is conducted. The signed RoE authorizes the team to initiate testing, grants the team permission to assess in-scope systems, and limits testing team liability for possible system damage to instances where malicious and unauthorized activities can be proven.

· The team will ensure that activities conducted during the engagement do not leave the assessed systems in a more vulnerable state then prior to the engagement.

· The test team will provide notification through regular process updates to [Component] when: (1) changes occur to the test plan or source test venue; (2) high risk findings are identified; (3) performing high risk or high traffic tests; and (4) testing problems occur. Reports will clearly state successful and failed security measures, and loss controls discovered through testing. The issue resolution process will begin once the draft report is submitted and approved Disclaimers and Limitation of Liability Disclaimers [Organization] will endeavor to use professional and industry standard procedures to avoid or mitigate any adverse impact on all relevant systems or operations during testing however [Component] understands that due to the inherently invasive nature of the techniques and tools utilized during the testing, [Organization] cannot guarantee desired or expected outcomes of a testing procedure and expressly disclaims any liability for any disruption or degradation in systems, networks, or operations, or for any system reset, loss of data, configuration change, unintentional compromise of data, denial of service (“DOS”), or other adverse system impact which may result from or be caused by, in whole or in part, such testing. In recognition of these inherent risks the [Component] will be solely responsible for providing sufficient back-up and recovery capability for all systems to return them to an operational state. [Component] understands that testing or analysis may fail to identify all system vulnerabilities or propose exhaustive and operationally viable recommendations to mitigate all exposure to risk.

Limitation of Liability [Organization’s] liability, to [Component], if any, arising out of this contract shall be as set forth in the Contracts Disputes Act, the Federal Acquisition Regulations and other applicable law.

Document Structure Section 2 covers the logistics of the ROE. This section will include the personnel to include Trusted Agents and key stakeholders, the test schedule, test site and test equipment.

Section 3 covers the communication strategy of the ROE. Included in this section are general communication procedures and incident handling and response. The incident handling section must cover suspension and resumption of testing.

Section 4 details the target system(s) and/or network(s). This section will define allowable and non-allowable target Internet Protocol (IP) addresses.

Section 5 details the test execution. The section will define technical and nontechnical test components and how the test team should handle data, particularly [Component] passwords.

Section 6 covers the reporting requirements of the ROE. As part of the scope detailed in section 1.3.4, this section will detail the Penetration Testing Report and any other deliverables.

Section 7 is the signature page. This section must have the signatures off all key stakeholders as detailed in Sections 1.2.1 and 1.2.3.

2. Services The following services will be conducted by [Organization] for the [Component] on [System Name]. Specific metrics for the services performed will be discussed before execution of assessment activities to appropriately map the accurate level of effort.

[Remove all services not covered by this particular ROE and relevant sections from the tool listing in Appendix C] Network Vulnerability Assessment A vulnerability assessment performed by an independent expert is designed to assess the adequacy and effectiveness of system security control measures in respect to a wide range of potential vulnerabilities. The assessment team will attempt to identify missing system or application patches, system mis-configurations, and poorly hardened hosts. These tests are generally intended to be non-intrusive and will not interfere with network activity. However, as with any vulnerability assessment activity, there is a risk that some tests may interfere with the operation of servers, workstations and the network depending on system configurations. Backups and/or backup procedures should be available during assessment activities.

A review of network, system and application configurations may be conducted based on platform specific configuration guidelines collected from system personnel and results from vulnerability scans. This data will be incorporated into the analysis portion of the report which will specify the actions needed (if any) to correctly configure and secure the environment.

If requested, the team may conduct a host-based configuration review as a component of the assessment. This review will utilize vulnerability scanning tools to check operating system and database system configuration baselines of system components. These tests will check system configurations against Federal Desktop Core Configuration (FDCC)/ United States Government Configuration Baselines (USGCB), or other configuration best practice guidelines, as dictated by the organization. The scans will provide an in depth look at the host based configuration and security hardening of particular systems. Due to varying organizational requirements, variances from standard baselines may exist. This may cause configuration review tools to generate a large number of false positives. The organization will need to provide the team with the organization’s configuration baseline in order for the team to identify these false positives.

Internal Penetration Test An internal penetration test is designed to demonstrate to customers the risks associated with potential vulnerabilities by attempting to emulate attacks from a malicious user already inside the network boundary. The result will allow the customer to more accurately assess the business risks of detected vulnerabilities, and determine the effects and potential impact of a successful compromise.

During an internal penetration test, the team will attempt to exploit vulnerabilities identified during the internal vulnerability assessment and perform other tests as needed. The purpose of this activity is to attempt to gain access to data without authorization or provided authentication credentials. This type of penetration test will be conducted under the auspices of an “Informed Insider” with prior network access and will be conducted from within the network boundary. The test will employ various degrees of malice and complexity to identify exploitable components of the system; all exploitable avenues will be explored. Computer systems and network operations will not be intentionally interrupted during the test without prior coordination with the customer.

During the engagement, if monitoring and detection systems are in use, it will be helpful, although not necessary, for customer personnel to notify the assessment team when penetration actions are generating alerts. This information can then be used when generating the test results.

Database Vulnerability Assessment Database vulnerability assessments are designed to assess the adequacy and effectiveness of security controls implemented internally, within databases existing on a system. The database assessment will include automated database discovery, vulnerability identification, and database user rights review for all in-scope internal databases. The result will enable the customer to get an accurate inventory of databases on the system and potential vulnerabilities of specifically identified databases.

The assessment team will attempt to identify every accessible database and enumerate vendor and release level for each database. The major databases that will be identified and enumerated by the assessment team are Oracle, Microsoft SQL Server, IBM DB2, Sybase, MySQL and Lotus Notes/Domino.

Once a database inventory is developed, database software and configuration vulnerabilities will be identified utilizing automated database vulnerability scanners. The scans will identify as many database vulnerabilities as possible within the defined test period. User rights review will be performed in conjunction with vulnerability identification. It will consist of a review of database user rights for excess database privileges and the ability of users to gain inappropriate access to data or functionality. These tests are intended to be non-intrusive and should not interfere with general network activity. However, some activities may interfere with proper operation of database servers depending on system configurations.

External Penetration Test An external penetration test is designed to demonstrate for customers the risks associated with potential vulnerabilities in external facing hosts and services by attempting to emulate attacks from an attacker outside the network boundary. The result will allow the customer to more accurately assess the business risks of external-facing vulnerabilities, and determine the effects and potential impact of a successfully exploited vulnerability.

To better simulate a real-world attack, the assessment team will conduct the external penetration test from a non-organization network (e.g. direct Internet Service Provider (ISP) connection).

During an external penetration test, the team will attempt to exploit system and network level vulnerabilities identified during network reconnaissance and perform other tests, as necessary, to further verify vulnerabilities. The team will attempt to penetrate the external network and gain access to systems by exploiting the identified vulnerabilities. The tests will employ various degrees of malice and complexity to identify exploitable components of the system; all exploitable avenues will be explored, unless identified prior to testing by the customer. Computer systems and network operations will not be intentionally interrupted during the test without prior coordination with the customer.

During the engagement, if monitoring and detection systems are in use, it will be helpful, although not necessary, for customer personnel to notify the assessment team when penetration activities are triggering monitoring devices and generating alerts. This information can then be used when generating the test results.

Web Application Assessment A web application assessment will thoroughly assess the adequacy and effectiveness of security controls implemented within a web application throughout the Software Development Lifecycle (SDLC). Web application assessments will include both vulnerability assessment and penetration testing activities. The result of this assessment will allow the customer to better assess the risk of their web application and the effects of a successful compromise.

Evaluations and penetration tests of web applications will include automated web application vulnerability scanning, using common web application assessment and manual methods to identify and possibly exploit vulnerabilities. The assessment will determine if common web application vulnerabilities such as the OWASP Top 10 vulnerabilities are present. The test will employ various degrees of malice and complexity to identify exploitable components of the system; all exploitable avenues will be explored, unless identified prior to testing by the organization. To better simulate a real-world attack, the assessment team may conduct the web application assessment test from a non-organization network (e.g. direct ISP connection).

If web applications require authentication, the assessment team will first attempt to gain access without authentication, however if access is not gained within 24 hours of the start of assessment activities, the assessment will assess the systems under the auspices of an “Informed Insider” with prior access. The assessment team will require multiple “external user” login identification (ID) and passwords based on the privilege levels of user accounts. This allows the assessment team to approach the application with the same access as an external or public user.

During the engagement, if monitoring and detection systems are in use, it is helpful, although not necessary, if organization personnel notify the assessment team when penetration activities are triggering monitoring devices and generating alerts. This information can then be used when generating the test results Wireless Vulnerability Assessment A wireless vulnerability assessment will enable the customer to develop a thorough picture of the wireless activity and risk within their facilities. The assessment team will attempt to identify wireless networks within the facilities and potential rogue wireless activity. The team will leverage different levels of effort to determine risk based on the complexity of the request from the customer. The result of this assessment will allow the customer a better understanding of the level of risk associated with wireless activity within their environment.

The assessment team will conduct an internal and external walkthrough of the organization’s facilities attempting to locate unauthorized and/or poorly secured Wireless Local Area Network (WLAN) Access Points (AP). If requested by the customer, the assessment team will also attempt to locate unauthorized Bluetooth enabled devices. The assessment team will walk all accessible corridors of the facilities to detect and localize WLAN APs and Bluetooth enabled devices.

Social Engineering / Email Spear Phishing Social engineering, in the form of email spear phishing activities, is designed to enable the customer to assess customer personnel’s susceptibility to the most common form of cyber-attack in use today. The result will allow the customer to understand the actual risk of these types of attacks and better tailor personnel information security training.

Social engineering activities will consist of pre-determined scenarios vetted by both [Organization] and the [Component] senior management. Further, all scenarios will be approved by the [Component] CIO. To better simulate a real-world attack, the assessment team will conduct social engineering activities from a non-organization network (e.g. direct ISP connection).

If requested, social engineering activities may be conducted against email addresses harvested from open source intelligence gathering. However, to increase the efficiency and thoroughness of an assessment, [Organization] recommends that [Component] provide email addresses for a group of randomly selected target users. The provided sample will aid in ensuring the social engineering activities are limited to the scope of the assessment. Users will be sent specially targeted e-mails, which contain a custom file or a Uniform Resource Locator (URL). Statistics will be collected on the number of users that open the file or click on the URL. Selected users will not be made aware of the assessment activities.

Statistics generated during social engineering activities will be provided to the customer; however user identification will not be recorded. As users should be randomly selected, the organization is encouraged to use the results as a means of assessing the effectiveness of user training and not in identifying specific users.

3. Logistics Personnel The following personnel will be involved in this security assessment:

Table 1: [Organization] Assessment Team Personnel

Project Manager

Assessment Lead

Security Analyst

Security Engineer

Security Engineer

Points of Contact and Trusted Agent Prior to the commencement of assessment activities, the [Component] will appoint an authorized representative to act as a POC. This representative will be the agency’s primary POC for the [Organization] during the testing. The [Organization] will rely on the POC to answer any questions concerning systems and related IT devices, give final authorization to test any vulnerabilities discovered and provide any additional information for unanticipated factors that may arise and impact the assessment.

Table 2: [Component] POC(s)

Primary POC

Secondary POC

Other POC

The [Component] will also appoint an authorized representative in the security incident reporting chain to act as a Trusted Agent (TA). The POC and the TA may be the same person if so authorized by [Component] management. The TA will serve as the Assessment Team’s primary point of contact during impact coordination, incident handling and incident response. The TA will also serve as the [Organization]’s Computer Security Incident Response Capability (CSIRC) primary point of contact should assessment activity be detected by [Component].

Table 3: [Component] Trusted Agent(s)

Primary TA

Secondary TA

Other TA

In addition to personnel listed above, [Component] IT staff or security personnel are encouraged to observe the assessment.

For a full listing of [Component] POC and [Organization] members, refer to Appendix H.

Testing Period and Schedule All assessment activities will be conducted from [Dates To Be Performed] during time windows of [Assessment Time Windows] as specified by [Component]. Typically, tests are conducted during non-production hours to avoid any interference with production activities. The assessment team shall be notified immediately of any other concurrent activities that may be degraded by the testing procedures.

Table 4 lists key milestones, critical tests, and deadlines associated with testing activities. All testing time frames must include the hourly schedule. Testing will not occur outside of this hourly schedule window.

The schedule is subject to change. The Assessment lead is responsible for maintaining the test schedule. When schedule changes are made, the Assessment lead will disseminate the updated schedule to all parties listed in Table 4.

Table 4: Milestones and Testing Schedule

Network Access Coordination of network access for the [Organization] must be completed prior to test commencement. During the onsite portion of the assessment, [Organization] will require the following:

· At least four (4) points of access (Ethernet-based) from within the [System Name] internal network. Depending on system configuration, access may be necessary in one or more network segments to facilitate comprehensive internal vulnerability scans. [Component] provided points of access information, including physical location, network range, and IP address information, will be documented in Appendix I.

· Network access points provided will be located in an office type workspace with Alternating Current (AC) power.

· Assessment equipment will be assigned internal network IP addresses, preferably with static IP addresses. Using a static IP address will allow for reconciliation of any issues arising during vulnerability scans.

· If port lockdown is in place then it must be disabled temporarily or reconfigured to provide network access to assessment equipment.

Prior to allowing assessment team equipment to connect to a network access point, the [Component] is authorized to scan the assessment equipment for vulnerabilities using agreed upon virus detection and vulnerability scanning tools.

Assessment Team Equipment and Software Appendix F contains the list of approved test team equipment. The [Organization] shall not use equipment outside of this list without consultation and approval from the [Component] [POC].

Appendix G contains the list of approved test team software. The [Organization] shall not use software outside of this without consultation and approval from the [Component] [POC].

Target Network Determination Prior to initiating any assessment activities, [Component] and the [Organization] will identify targeted (host) systems with a defined range/list of network IP addresses. The [Organization] will work with [Component] to determine which network ranges are to be considered part of the valid and allowable range. Subnets or network segments connected to the [System Name] system but not included in the scope of the assessment, or that are owned by outside contractors, will not be considered within the allowable test range. Additionally, the [Component] POC should indicate any additional systems that are to be considered critical to mission function and are excluded from assessment activities.

[Component] will ensure that IP network addresses that are identified as in scope are hosted in [Component] facilities (e.g. not hosted by an external organization).

Appendix B.1 lists all IP network ranges identified by [Component] as in scope for network reconnaissance.

Appendix B.2 lists all IP network ranges identified by [Component] as in scope for web application assessment and penetration testing.

Appendix B.3 lists all IP network ranges identified by [Component] as in scope for Network/OS assessment.

Appendix B.4 lists all IP network ranges identified by [Component] as in scope for database assessment.

Appendix B.5 lists all IP network ranges identified by [Component] as excluded from all assessment activities.

Prior to any spear phishing activities, [Component] and the [Organization] will identify specific email addresses for the [Organization] to target. The [Component] will specifically monitor and quarantine the selected email accounts to ensure the social engineering activities do not escape the scope of the assessment.

4. Rules of Engagement The ROE is mandatory and will not be deviated from without first obtaining written concurrence from the [Organization] and authorized representatives from the [Component] senior leadership.

System Backups The [Component] is responsible for ensuring that system backups have been performed and that a restore process is validated prior to the start of the security assessment. This is a mandatory requirement for all mission critical systems in case of an inadvertent outage requiring system restoration. If system backups are not performed on mission critical systems, those systems must be identified by the [Component] prior to the assessment and excluded from assessment activities.

Applied Conditions for Testing The [Organization] will only conduct vulnerability scan and penetration test activities against systems that reside within the [System Name] specified system architectures. As agreed to prior to testing, information-gathering tests and automated vulnerability scanning may be conducted at will within the agreed upon testing time-frame and testing windows. All components within the [System Name] that are not are listed in Appendix B.6 are considered to be within the scope of the testing. If any system component is deemed off-limits for the test, the [Component] POC must provide notice to the [Organization] prior to testing activities begin.

Test Commencement No testing activities will be conducted without prior approval of the [Component] POC.

Impact Coordination The [Organization] will make every reasonable effort to limit the operational impact of testing and ensure that network availability and data integrity are in no way compromised. General vulnerability scanning is non-intrusive and should not affect normal network connectivity or host operations. Any vulnerability scanning or penetration testing techniques that may adversely impact network or host performance will not be conducted without prior permission of the [Component] POC.

Incident Handling and Reporting Occasionally assessment activities have the unintentional consequence of causing an incident on the network despite the various countermeasures that are in place. In case of an incident, it is the responsibility of the [Organization], in conjunction with the Trusted Agent(s), to contact the [Component] CSIRC, or similar organization.

If an incident occurs that is not a direct result of testing but which further testing may hinder remediation and/or investigation of the incident, it is the responsibility of the [Component] CSIRC, or similar organization, to notify the [Organization] through the TA.

Termination of Testing At any point during the testing, the [Component] POC, TA, or designated personnel can command a pause or termination of the test. Should the tests be terminated, the [Organization] will document the rationale given by the POC for the termination, including a description of the potential adverse consequences that might have occurred if the testing continued.

The [Organization] will give verbal notification to the [Component] POC should any unforeseen event occur that impacts the client environment. In addition, immediate notification will be made by the [Organization] Team Lead should any vulnerabilities be discovered that present imminent risk to the [System Name] system or the overall [Component] network.

The termination of testing memorandum is located in Appendix E. This memorandum will be completed and signed by both the [Organization] Team Lead and [Component] POC requesting termination of testing.

Rules for Detection by Monitoring Systems During the course of performing the assessment, the [Component] CSIRC, or similar organization, and the [System Name] network and\or systems management center shall be fully aware of assessment activities.

Communications Check Prior to the commencement of any testing, the assessment team will confirm that the target network and devices are accessible from the provided network access points. The team will also validate that all person-to-person communication methods identified in the assessment plan are accurate and working.

Security The [Organization] will perform testing using an assessment platform built to a standard configuration and maintained under a [Organization] approved change management control process. The assessment equipment contains exploit tools, code and technical references, which are not to be viewed, distributed or evaluated by external organizations. Under no circumstances will assessment platforms be relinquished from the control of the [Organization].

During testing, audit logs will be used to monitor the [Organization]’s activities. Team members will keep a journal of comments in text and screen-shots documenting the assessment activities and times during testing.

Data Handling The test team and [Component] are responsible for protecting all work papers, interim results, and summaries of results from disclosure consistent with the sensitivity and classification of the information.

Under no circumstances shall any [Component] data or files be modified or deleted. However, to demonstrate potential user access vulnerabilities, the test team may copy a file, open a file, or write a non-disruptive text file to the target host with no direct modification of data. This file, after being written to, will be immediately restored to the original condition by the test team and the [Component] trusted agent.

Raw test data and results will be considered Sensitive But Unclassified (SBU). After the engagement, all [Component] data will be securely deleted from assessment laptop, as defined by the [Component] media sanitization policy, and stored at the [[Component] assessment location]. All data and test results will remain private between [Organization] and [Component] unless authorized by both parties.

Personally Identifiable Information The [Organization] has no intention of viewing, storing or processing personally identifiable information (PII). If the assessment team members inadvertently view and store user files or any other data contained in the [Component]’s IT environment that are part of a government agency system of records on individuals, this information will be identified to the [Component] for handling consistent with Privacy Act (5 U.S.C §552a) and any other applicable regulations.

Password Tests The [Organization] WILL NOT perform active password manipulation or password attacks (i.e. online password guessing) in this assessment. Password files captured from [Component] devices, or provided by the organization, may be loaded onto offline workstations for decryption. This relieves the processing workload of the password decryption tool from the test team's primary workstation and also prevents decrypted, live-system passwords from being stored on a system connected to the target network or Internet. At no time will a captured password file or the decrypted passwords be revealed to persons not officially participating in the security test.

5. Assessment Support

1. Prior to the onsite portion of the assessment, the [Organization] requests (if possible) [Component] provide the following documentation to assist in the planning, security review, and to increase efficiency of onsite testing:

· General System Design Information

· To include summary of system components

· Specific hardware platforms used (brand) Operating System (OS) used within the system

· Servers

· Network devices

· Workstations

· Firewalls

· Software list containing all software used on the system and the current version of that software

· Specific configuration data for the environment being tested to include:

· Network diagrams

· IP Charts (can provide once onsite if considered sensitive information)

· List of all equipment that is within the bounds of the test

· Any limitations for the assessments

2. Once on site, the [Organization] requests (if possible) [Component] provide the following documentation for security review and to enable comprehensive testing of the [System Name] system. This documentation will include:

· Production configuration files for:

· Router

· Switches

· Firewalls

· Intrusion Detection System (IDS)

· Other security devices

· Account Passwords

· System administrative accounts

· Web Application user or administrative accounts

· Database administrative accounts

· Network equipment access accounts

3. The following events are anticipated to require expenditure of [Component] staff time:

· In Brief Attendance

· Testing Coordination

· Testing Observation (if desired)

· Review of Deliverables and Documentation of Comments/Questions

· Out Brief Attendance

6. Assessment Results After Action Review If [Component] desires, a daily out-brief will be provided by the [Organization] Team Lead to personnel specified by the [Component]. The briefing will cover daily assessment activities and high-level daily assessment findings.

Upon the completion of all assessment activities, the [Organization] Team Lead will provide personnel specified by the [Component] with an after-action out-brief. This briefing will cover the testing methodologies used, the results of those testing methodologies, and high-level recommended fix actions. The intent of this briefing is to highlight the results from testing as well as provide an overall organizational risk picture.

Raw Assessment Results The [Organization] will provide the [Component] POC with at least two (2) copies of the raw technical assessment data. This data will be provided on a recordable Compact Disc (CD) or Digital Video Disc (DVD) or transferred to the POC with a secure Universal Serial Bus (USB) drive. This will allow [Component] personnel to review the detailed scan results and to perform independent analysis of the scan results if desired.

In addition, [Organization] will securely store raw assessment data at the [Organization] facility located in [facility location]. [Organization] will not disclose any source information obtained from the [Component] or results attributable to this testing to any unauthorized third parties.

Final Report At the conclusion of all testing activities, a final report will be prepared for presentation to designated [Component] personnel. The report will include an overview of methods used, including descriptions of any tools or manual processes; any vulnerabilities that present easily exploitable targets for attackers with a highly successful penetration; an assessment of risk represented by the vulnerabilities; and recommendations for countermeasures that will mitigate the residual risk created by the vulnerabilities to an acceptable level.

A draft report will be provided to the [Component] no later than two (2) weeks after the conclusion of test activities. Following a review of the draft report, the [Component] shall provide comments, requested corrections or changes to the [Organization] within five business days of receipt of draft report. The [Organization] shall deliver to [Component] a final report within five business days of receipt of [Component] comments.

7. Dispute Resolution In the event that disagreement(s) arise between the [Component] and the [Organization] during testing, the following individuals will determine the final resolution:

Table 5: Dispute Resolution – Executive Level Leadership from [Organization]

Table 6: Dispute Resolution – [Component]

8. Rules of Engagement and Test Plan Approval

[Name] Date [Title] [Component]

[Team Leader] Date [Assessment Project Manager or designated Authoritative Personnel] [Organization]

Appendix A: Acronyms

Appendix B: Included and Excluded IPs/URLs

B.1 Included IPs Network Reconnaissance

B.2 Included IPs Web Application Assessment

B.3 Included IPs Network/OS Assessment

B.4 Included IPs Database Assessment

B.5 Excluded IPs

Appendix C: Approved Tools

Approved tools list may potentially include such products as Nmap (Zenmap), Nessus, AppDetective, and Hailstorm for the Windows operating system. The actual approved tools list will be negotiated between [Organization] and the [Component] during the drafting of the ROE.

Appendix D: Approved Assessment Team Equipment

Appendix E: Termination of Assessment Activities Memorandum

This memorandum will establish an understanding between SSA and [Organization] to ensure that all parties are in agreement on the conditions that may exist and result in the termination of this security testing effort.

The test team will notify the designated SSA POC and TA if a significant event should occur during testing which results in the Assessment Team or the SSA desiring a termination of the testing. The POC and TA should have the knowledge and understanding of the significant events that would lead the SSA to direct the test team to terminate the testing.

The reason for the termination must be documented below. The signatures indicate agreement by all parties on the reason for termination of the testing.

Reason for termination of testing:

Assessment Team Lead

Signature: Date

Name and Title:

SSA POC or TA

Signature: Date

Name and Title:

[date] SSA ADMINISTRATIVELY CONTROLLED DOCUMENT Page 1

[date] SSA ADMINISTRATIVELY CONTROLLED DOCUMENT Page 2 TEMPLATE VERSION (v0.1) Appendix F: POC Listing SSA Personnel

[Organization] Personnel

[Acronym] ROE and Test Plan Version 0.1

[date] SSA ADMINISTRATIVELY CONTROLLED DOCUMENT Page 35 TEMPLATE VERSION (v0.1)

Appendix G: Network Access Points

Network Segment (CIDR notation)

image1.png