RFP_attachment_D_of_OIT_IAD_IV_and_V_process_.pdf

For Official Use Only

RFP Attachment D:

Independent Verification and Validation Process

1.0 Introduction

1.1 Purpose

This Independent Verification and Validation (IV&V) Process was developed to validate that each Offeror’s Information Technology (IT) and operating systems meet a minimum level of security in order to appropriately handle and protect Government test data, which contains sensitive information such as personally identifiable information (Sensitive PII) that will be used during the conduct of the DHS Science and Technology (S&T) Testing. An Offeror’s IT and operating systems shall include an Offeror’s subcontractors’ IT and operating systems that will process the Government test data during the DHS S&T Testing.

The Transportation Security Administration (TSA) will ensure that each Offeror meets the security requirements and adheres to policy as outlined in the Department of Homeland Security (DHS) Sensitive Systems Policy Directive 4300A.

At the completion of the DHS S&T Testing, TSA will verify and validate that all the assets containing or used to process TSA information have been sanitized in accordance with TSA MD 1400.3, TSA Information Assurance Handbook and Technical Standards.

1.2 Assumptions

The following assumptions apply to this IV&V:

• The TSA IV&V Team will conduct the review of the technical controls on-site at the Offeror’s facility.

• The assessment will require a maximum of one day of on-site activities.

• The Offeror shall provide a point of contact for the assessment to assist with scheduling of meetings and interviews.

• The Offeror’s staff shall be available for meetings, interviews, and technical testing activities during the site visit.

• The Offeror shall provide its Team Composition Table 2 as required in Section 3.0 of RFP

Attachment D.

• As its Volume III of the proposal, the Offeror shall provide security documentation of any of its

IT and operating systems (including an Offeror’s subcontractors’ IT and operating systems) that will process Government test data, which contains sensitive personally identifiable information (Sensitive PII) during the RFP process, that includes the following:

o A list of hardware and software for the Offeror’s IT and operating systems and the configuration files for firewalls and routers that would handle any Government test data.

o A list of all Offeror’s subcontractors to be used/engaged by the Offeror that will handle any

Government test data during the RFP process.

o Incident Response Plan of the Offeror’s and Offeror’s subcontractors’ IT and operating systems that would handle any Government test data.

o System Security Plan of the Offeror’s and Offeror’s subcontractors’ IT and operating systems that would handle any Government test data.

o Contingency Plan of the Offeror’s and Offeror’s subcontractors’ IT and operating systems that would handle any Government test data.

o Standard Operating Procedures of the Offeror’s and Offeror’s subcontractors’ IT and operating systems that would handle any Government test data.

o The Offerr shall complete the Access Methods table 7 as required in Section 5.3.4 of the RFP Attachment D.

1.3 Constraints

The following constraints apply to this IV&V:

• The Offeror’s technical staff shall provide vulnerability scans to the TSA IV&V Team for review at least 5 business days prior to the start of the IV&V on-site assessment.

• No scanning will be conducted by the TSA IV&V team.

2.0 Assessment Tools

Testing of the Offeror’s system(s) using the tailored TSA IV&V process will be conducted on an agreed upon date at the Offeror’s location, which will occur within 5 business days of receipt of notice of the IV&V process. The Offeror shall employ commercial-grade vulnerability scanning tools comparable to Nessus, WebInspect, AppDective, and Nipper. Scanning shall be conducted on all devices within the isolated boundary environment designated for utilizing, storing, or transmitting DHS/TSA evaluation data.

Table 1 lists the assessment tools and procedures that will be used during the IV&V Execution Process.

The Plans and Procedures documents will be included in Volume III of the proposal.

Table 1: Assessment Tools and Procedures

Tool Description Operator Documentation Reviews System Security Plan, Incident

Response Plan, Standard Operating Procedures, Contingency Plan, etc.

TSA IV&V Team

Interviews Interviews with the Information System Owner, Security Officer, Technical POCs and other personnel as necessary

TSA IV&V Team

System Examinations Work with System Administrators, Web Application Administrators and Database Administrators to verify that system configurations/ hardening not able to be discovered through vulnerability assessment tools are correctly implemented

TSA IV&V Team

Operating System (OS) OS vulnerability scanner Offeror’s Staff and TSA

Vulnerability scanning tool is to be determined by the Offeror

(such as Nessus using up to date plugins)

IV&V Team

Web vulnerability scanning tool is to be selected by Offeror

Web application/console vulnerability testing (such as WebInspect)

Offeror’s Staff and TSA IV&V Team

Database vulnerability scanning tool is to be selected by Offeror

Database vulnerability testing (such as AppDetective)

Offeror’s Staff and TSA IV&V Team

Network vulnerability scanning tool is to be selected by Offeror

Network fabric devices (firewalls, routers, switches, load balancers, etc) (such as Nipper)

Offeror’s Staff and TSA IV&V Team

3.0 Team Composition

Table 2 identifies the Offeror’s Personnel and shall be included in Volume III of the proposal.

Table 2: Offeror’s Personnel

Name Position Phone E-mail

Risk Assessment Facilitator

Vulnerability Scan Monitor

Technical POC (servers, databases, infrastructure)

Software and Patch Management POC

System Development and Lifecycle Support

Physical Site and Environmental Systems POC

Information System Security Officer(s)

4.0 Schedule

Table 3 documents the major actions and activities associated with the Offeror’s IT Systems Risk Assessment.

Table 3: Security Risk Assessment Schedule

System Test Step Dates

Introductory Call

Receive and Review Key Documents and Scan Results

Assessment Activities (on-site)

5.0 Security Test Procedures

The testing of the information system's security features will range from a series of formal tests to vulnerability scans of the information system.

The verification of system controls will be accomplished by means of:

• Technical testing (software/hardware): The system controls shall be tested on-site at the Offeror’s location by the Offeror’s personnel and analyzed by the TSA IV&V Team

• Technical automated tools: The controls shall be tested by the Offeror’s personnel and analyzed by the TSA IV&V Team according to agreed-upon procedures, using agreed upon technical scanning tools

• Documentation and procedural reviews: All applicable documentation for the system will be reviewed as part of this IV&V

• Interviews with Offerors team personnel from Table 2f will be conducted by the TSA IV&V Team.

5.1 Process Overview

The general process used for conducting the IV&V will be:

• Execution of defined test procedures using:

o Vulnerability Scans o Interviews using a Security Test Procedures matrix o Hardware/software system and application examination/observation o Documentation reviews.

• System security controls and security requirements to be satisfied by this system will be verified by the Test Cases as described in Section 5.2.1 of this document.

• The Security Test Procedures and security scan results will be used to document and verify that system security features are implemented in accordance with the Offeror’s documented policies and procedures and are operating effectively.

5.2 Test Procedures

1. Coordinate vulnerability scans with Offeror’s personnel using tools identified in Table 1, Assessment Tools and Procedures.

2. Collect preliminary and site data; such as operating systems, software list with versions, hardware asset inventory, operating system configuration files etc., of the IT and operating systems that would handle any Government test data in the RFP process.

5.2.1 Test Cases

Test Case Requirement Expected Result

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the access control policy and associated access controls. (Access Control)

An access control policy exists and has been formally documented for review that addresses responsibilities and compliance.

Only those users expressly authorized access are granted access privileges to Government test data. (Access Control)

Only specific and cleared users are identified as individuals allowed access to evaluation data and are granted access.

Users requiring Administrative privileges on the information system containing the Government test data are identified and have a formal request on record for review.

Administrative access rights are granted to only a limited number of cleared and known individuals who are allowed privileged access rights.

Account lockout duration is implemented.

(Access Control)

The system automatically locks the account until released by an administrator when the maximum number of unsuccessful login attempts is exceeded. Session is terminated after 20 minutes of inactivity.

Access is restricted to users with a need to know the information in the performance of their official duties. (Access Control)

Only users assigned to these tasks that have appropriate clearances or permissions are allowed access to evaluation data. Least Privilege is enforced.

The system enforces a limit on unsuccessful login attempts. (Access Control)

Failed login attempts restrictions are implemented. The system enforces a limit of three (3) consecutive invalid access attempts by a user.

Accounts are disabled after a specified length of inactivity. (Identification and Authentication)

The system disables user identifiers after forty-five (45) days of inactivity.

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the identification and authentication control policy and associated identification and authentication controls. (Identification and Authentication)

An identification and authentication control policy exists and has been formally documented for review that addresses responsibilities and compliance.

Multifactor authentication is used for local access to privileged accounts.

(Identification and Authentication)

All privileged users (those users with privileged access rights) must use multifactor authentication to gain access to the system. Two or more authentication factors are enforced. Privileged users have separate accounts from their general user accounts in order to perform privileged access.

User access is controlled and limited based on positive user identification and authentication mechanism that support the minimum requirement of access control, least privilege, and system integrity.

(Identification and Authentication)

Least Privilege access is employed.

Default user ids and passwords have been removed or changed. (Access Control)

Factory default user ids and passwords, including Guest accounts, received at installation time have been changed.

Anonymous login accounts are disabled.

(Access Controls)

Anonymous login accounts received at installation time have been disabled.

Password management has been implemented to include requiring strong passwords, password change periods, and removal of expired passwords, minimum password length, password composition, and number of allowed rejections during verification. (Identification and Authentication)

Password complexity is implemented per the TSA IA Handbook.

Passwords are submitted via SSL to prevent sending user credentials in a clear text format. (System and Communications Protection)

System processes password via SSL preventing sending user credentials in clear text format. At a minimum, TLS1.1 is employed.

TLS 1.2 is preferred

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the audit and accountability policy and associated audit and accountability controls. (Audit and Accountability)

An audit and accountability control policy exists and has been formally documented for review that addresses responsibilities and compliance.

Audit logs are generated and reviewed daily.

(Audit and Accountability)

Review of audit logs has been implemented.

The system retains records of all audit results, corresponding action plans, and action plan report until it is determined they are no longer needed for operational purposes. (Audit and Accountability)

Records of audit files, results.

Corresponding action plans, and action plan report are kept until determined no longer needed for operational purposes.

The system ensures that the data contained in the system logs is maintained and controlled in a manner that prohibits tampering, loss or destruction. (Audit and Accountability)

Data contained in the system logs are maintained and controlled in a manner that prohibits tampering, loss, or destruction.

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the system and communications protection policy and associated system and communications protection controls. (System and Communications Protection Control)

A system and communications protection control policy exists and has been formally documented for review that addresses responsibilities and compliance.

The Offeror employs, at a minimum, FIPS-validated cryptography to protect evaluation data at rest and while in transit. (See FIPS Pub 140-2). (System and Communications Protection Control)

The vendor implements required cryptographic protections using cryptographic modules that comply with applicable DHS/TSA directives. AES-256 (FIPS 197) and FIPS 140-2 compliant crypto module.

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the configuration management policy and associated system and configuration management controls. (Configuration Management)

A configuration management control policy exists and has been formally documented for review that addresses responsibilities and compliance.

The Offeror has established and documented for review a change control process. (Configuration Management)

A methodology has been established and documented to provide effective implementation of security controls and control enhancements.

Unnecessary services and ports have been disabled. (Configuration Management)

Services and ports not in use have been disabled.

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the incident response policy. (Incident Response)

An incident response policy and procedures policy exists and has been formally documented for review that addresses responsibilities and compliance.

The Offeror has developed, implemented, and documented an incident response program that includes incident monitoring and reporting. (Incident Response)

Offeror personnel are required to report suspected security incidents to the vendor’s incident response team and report incident information to DHS/TSA.

The Offeror has established a firewall that separates the evaluation data from other boundaries. (System and Communications Protection Control)

Segregated storage of evaluation data is employed on a protected network that is designed to house only DHS/TSA evaluation data.

The Offeror’s system prevents public access into the organization’s internal networks containing evaluation data. (System and Communications Protection Control)

Routers, firewalls, and isolation zones are employed to block access to the evaluation data from external access attempts.

Malicious code protection has been installed and is updated. (System and Information Integrity)

Malicious code protection mechanisms are provided at information system entry and exit points and at workstations, servers, or mobile computing devices on the network to detect and eradicate malicious code.

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the contingency planning and procedures policy. (Contingency Planning

A contingency planning exists and has been formally documented for review that addresses contingency planning policies responsibilities and compliance.

The Offeror has developed, implemented, and formally documented procedures to facilitate the implementation of the security planning policy and procedures policy.

(Security Plan)

A security plan exists and has been formally documented for review that addresses security planning policy and procedures responsibilities and compliance.

The Offeror has not implemented and is not executing obsolete operating systems.

(System and Information Integrity)

The Offeror has upgraded to a supported version of the operating system or has replaced obsolete operating systems.

Packages and patches that fix security issues are deployed. (System and Information Integrity)

System releases that fix known security vulnerabilities are applied to the system on a regular scheduled basis.

Vulnerability scanning is performed on a regular, scheduled basis and open vulnerabilities are resolved. (Risk Assessment)

The Offeror employs vulnerability scanning tools and procedures to enumerate platforms, software flaws, and improper configurations and remediates legitimate vulnerabilities identified.

5.3 Component Identification

5.3.1 Hardware

Table 4 lists the in-scope hardware components for the Offeror’s system and shall be included in Volume III of the proposal.

Table 4: Hardware Components Hardware Location Test Method Number of

Tests specified in the Security Test Plan/Procedures

Automated Assessment tools

Tests specified in the Security

Tests specified in the Security

5.3.2 Software

Table 5 lists the in-scope software components for Offeror’s system and shall be included in Volume III of the proposal.

Table 5: Software Components Software/Application Location Test Method

Observation, Automated Scanning

Observation, Automated Scanning

5.3.3 Operating Systems

• Industry standards and best practices will be used to test the operating systems.

• Perform manual checks with the System Administrator.

• Discuss findings with System Administrator to ensure validity.

Table 6 describes the operating system(s) for the Offeror’s system and shall be included in Volume III of the proposal.

Table 6: Operating Systems Operating System Location Test Method

Tests specified in the Security Test Plan/Procedures

Automated Assessment tools Tests specified in the Security

Automated Assessment tool

5.3.4 Access Methods

Table 7 lists the access methods for the Offeror’s system and shall be included in Volume III of the proposal.

Table 7: Access Methods Access Method Test Method

Tests specified in the Security Test Plan/Procedures Automated Assessment tools

Tests specified in the Security Test Plan/Procedures

Tests specified in the Security Test Plan/Procedures

5.4 Automated Scans

• The Offeror’s technical staff shall conduct automated scans of the network, web portals, applications, and databases and provide the results to the TSA IV&V Team for evaluation.

• The Offeror’s System and Database Administrators will be interviewed to validate scan results.

5.4 Automated Scans