Attachments A - D.pdf

Attachment A - Page 1 of 4

ATTACHMENT A

SECTION 508 COMPLIANCE – INFORMATION AND COMMUNICATION

TECHNOLOGY (ICT) ACCESSIBILITY REQUIREMENTS STATEMENT

Accessibility Requirements Tool

ICT Accessibility Requirements Statement per Section 508 of the Rehabilitation Act

Incident Management Software System and Support Services

E205.1 General Electronic content shall comply with E205.

E205.2 Public Facing Electronic content that is public facing shall conform to the accessibility requirements specified in E205.4.

E205.3 Agency Official Communication Electronic content that is not public facing shall conform to the accessibility requirements specified in E205.4 when such content constitutes official business and is communicated by an agency through one or more of the following:

A. An emergency notification.

B. An initial or final decision adjudicating an administrative claim or proceeding.

C. An internal or external program or policy announcement.

D. A notice of benefits, program eligibility, employment opportunity, or personnel action.

E. A formal acknowledgement of receipt.

F. A survey questionnaire.

G. A template or form.

H. Educational or training materials; or I. Intranet content designed as a Web page.

E205.4 Accessibility Standard (WCAG 2.0) - Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (Incorporated by reference, see 702.10.1).

E205.4.1 Word Substitution when Applying WCAG to Non-Web Documents. For non- Web documents, wherever the term "Web page" or "page" appears in WCAG 2.0 Level A and AA Success Criteria and Conformance Requirements, the term "document" shall be substituted for the terms "Web page" and "page". In addition, in Success Criterion in 1.4.2, the phrase "in a document" shall be substituted for the phrase "on a Web page".

E206 Hardware

• E206.1 General. Where components of ICT are hardware and transmit information or have a user interface, such components shall conform to the requirements in Chapter 4.

E207 Software

• E207.1 General Where components of ICT are software and transmit information or have a user interface, such components shall conform to E207 and the requirements in Chapter 5

• Exception from E207.1 General: Software that is assistive technology and that supports the accessibility services of the platform shall not be required to conform to the requirements in Chapter 5.

Attachment A - Page 2 of 4

• E207.2 WCAG Conformance User interface components, as well as the content of platforms and applications, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

Exceptions from E207.2 WCAG Conformance:

● Software that is assistive technology and that supports the accessibility services of the platform shall not be required to conform to E207.2.

● Non-web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation;

and 3.2.4 Consistent Identification.

● Non-Web software shall not be required to conform to Conformance Requirement 3 Complete Processes in WCAG 2.0.

E207.3 Complete Process for Non-Web Software Where non-Web software requires multiple steps to accomplish an activity, all software related to the activity to be accomplished shall conform to WCAG 2.0 as specified in E207.2.

E301 General E301.1 Scope. The requirements of Chapter 3 shall apply to ICT where required by 508 Chapter 2 (Scoping Requirements), 255 Chapter 2 (Scoping Requirements), and where otherwise referenced in any other chapter of the Revised 508 Standards or Revised 255 Guidelines.

E302 Functional Performance Criteria

● 302.1 Without Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that does not require user vision.

● 302.2 With Limited Vision. Where a visual mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited vision.

● 302.3 Without Perception of Color. Where a visual mode of operation is provided, ICT shall provide at least one visual mode of operation that does not require user perception of color.

● 302.4 Without Hearing. Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that does not require user hearing.

● 302.5 With Limited Hearing. Where an audible mode of operation is provided, ICT shall provide at least one mode of operation that enables users to make use of limited hearing.

● 302.6 Without Speech. Where speech is used for input, control, or operation, ICT shall provide at least one mode of operation that does not require user speech.

● 302.7 With Limited Manipulation. Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that does not require fine motor control or simultaneous manual operations.

● 302.8 With Limited Reach and Strength. Where a manual mode of operation is provided, ICT shall provide at least one mode of operation that is operable with limited reach and limited strength.

● 302.9 With Limited Language, Cognitive, and Learning Abilities. ICT shall provide features making its use by individuals with limited cognitive, language, and learning abilities simpler and easier.

Attachment A - Page 3 of 4

502 Interoperability with Assistive Technology

● 502.4 Platform Accessibility Features. Platforms and platform software shall conform to the requirements in ANSI/HFES 200.2, Human Factors Engineering of Software User Interfaces — Part 2: Accessibility (2008) (incorporated by reference, see 702.4.1) listed below:

A. Section 9.3.3 Enable sequential entry of multiple (chorded) keystrokes.

B. Section 9.3.4 Provide adjustment of delay before key acceptance.

C. Section 9.3.5 Provide adjustment of same-key double-strike acceptance;

D. Section 10.6.7 Allow users to choose visual alternative for audio output.

E. Section 10.6.8 Synchronize audio equivalents for visual events.

F. Section 10.6.9 Provide speech output services; and G. Section 10.7.1 Display any captions provided.

503 Applications

● 503.1 General Applications shall conform to 503.

● 503.2 User Preferences Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor.

● Exception from E503.2 User Preferences: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2.

● 503.3 Alternative User Interfaces. Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services.

● 503.4 User Controls for Captions and Audio Description Where ICT displays video with synchronized audio, ICT shall provide user controls for closed captions and audio descriptions conforming to 503.4.

● 503.4.1 Caption Controls Where user controls are provided for volume adjustment, ICT shall provide user controls for the selection of captions at the same menu level as the user controls for volume or program selection.

● 503.4.2 Audio Description Controls. Where user controls are provided for program selection, ICT shall provide user controls for the selection of audio descriptions at the same menu level as the user controls for volume or program selection.

602 Support Documentation

● 602.1 General. Documentation that supports the use of ICT shall conform to 602.

● 602.2 Accessibility and Compatibility Features. Documentation shall list and explain how to use the accessibility and compatibility features required by Chapters 4 and 5.

Documentation shall include accessibility features that are built-in and accessibility features that provide compatibility with assistive technology.

● 602.3 Electronic Support Documentation. Documentation in electronic format, including Web-based self-service support, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

● 602.4 Alternate Formats for Non-Electronic Support Documentation. Where support documentation is only provided in non-electronic formats, alternate formats usable by individuals with disabilities shall be provided upon request.

Attachment A - Page 4 of 4

603 Support Services

● 603.1 General. ICT support services including, but not limited to, help desks, call centers, training services, and automated self-service technical support, shall conform to 603.

● 603.2 Information on Accessibility and Compatibility Features. ICT support services shall include information on the accessibility and compatibility features required by 602.2.

● 603.3 Accommodation of Communication Needs. Support services shall be provided directly to the user or through a referral to a point of contact. Such ICT support services shall accommodate the communication needs of individuals with disabilities.

Instructions to Offerors

1 Provide an Accessibility Conformance Report (ACR) for each commercially available Information and Communication Technology (ICT) item offered through this contract.

Create the ACR using the Voluntary Product Accessibility Template Version 2.1 or later, located at https://www.itic.org/policy/accessibility/vpat. Complete each ACR in accordance with the instructions provided in the VPAT template. Each ACR must address the applicable Section 508 requirements referenced in the Work Statement. Each ACR shall state exactly how the ICT meets the applicable standards in the remarks/explanations column, or through additional narrative. All "Not Applicable" (N/A) responses must be explained in the remarks/explanations column or through additional narrative. Address each standard individually and with specificity, and clarify whether conformance is achieved throughout the entire ICT Item (for example - user functionality, administrator functionality, and reporting), or only in limited areas of the ICT Item. Provide a description of the evaluation methods used to support Section 508 conformance claims. The agency reserves the right, prior to making an award decision, to perform testing on some or all of the Offeror’s proposed ICT items to validate Section 508 conformance claims made in the

ACR.

2 Describe your approach to incorporating universal design principles to ensure ICT products or services are designed to support disabled users.

3 Describe plans for features that do not fully conform to the Section 508 Standards.

4 Describe "typical" user scenarios and tasks, including individuals with disabilities, to ensure fair and accurate accessibility testing of the ICT product or service being offered.

Acceptance Criteria

1 Prior to acceptance, the government reserves the right to perform testing on required ICT items to validate the offeror’s Section 508 conformance claims. If the government determines that Section 508 conformance claims provided by the offeror represent an inaccurate level of conformance than what is actually delivered to the agency, the government shall, at its option, require the offeror to remediate the delivered item to align with the required Section 508 conformance claims prior to acceptance.

https://www.itic.org/policy/accessibility/vpat

ATTACHMENT B

PAST PERFORMANCE QUESTIONNAIRE

National Transportation Safety Board

Contractor’s Name: ___________________________________________

Solicitation: 9531BM25Q0014

Person/Point of Contact: ___________________________ Telephone: _______________________

E-Mail: __________________________

Title and Organization: _________________________________________________________________

Instructions: Contractors are requested to forward this questionnaire to references listed under responses to the Past Performance portion of the RFQ. References should submit completed questionnaires via email to Mr. P. Matt Hazlinsky at matt.hazlinsky@ntsb.gov. Any questions regarding this questionnaire may be directed to P. Matt Hazlinsky at the email address above.

1. Type of Service. What type of services did the contractor perform for your agency?

2. Quality of Performance. Did the contractor perform in a manner that conformed to contract requirements and demonstrated standards of good workmanship? Please explain.

3. Timeliness of Performance. Did the contractor adhere to the contract schedule?

4. Customer Satisfaction. Did the contractor demonstrate reasonable and cooperative behavior and commitment to customer satisfaction? Did the contractor display a business-like concern for the interest of the customer? Was the customer ultimately satisfied?

5. Based on the contractor’s overall performance, would you award them another contract?

[ ] YES [ ] NO Please explain.

mailto:matt.hazlinsky@ntsb.gov

Department of Homeland Security

Cybersecurity and Infrastructure Security Agency (CISA)

Secure Software Development Attestation Form Instructions

Read all instructions before completing this form

Privacy Act Statement

[NOTE: This Privacy Act Statement is unique to DHS. All agencies using this common form will need to provide an agency-unique Privacy Act Statement when they request to use this form.

Each agency using this common form should provide Privacy Act Statements that conform to its applicable agency procedures and requirements.]

Authority: 44 U.S.C. § 3554, Executive Order (E.O.) 14028, “Improving the Nation’s

Cybersecurity,” and OMB Memorandum M-22-18, “Enhancing the Security of the Software

Supply Chain through Secure Software Development Practices,” as amended by OMB

Memorandum M-23-16, “Update to Memorandum M-22-18, Enhancing the Security of the

Software Supply Chain through Secure Software Development Practices,” authorize the collection of this information.

Purpose: The purpose of this form is to provide the Federal Government assurances that software used by agencies is securely developed.

Background: This information may be disclosed as generally permitted under Executive Order

14028, Improving the Nation’s Cybersecurity (E.O. 14028) and Memorandum M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development

Practices” (M-22-18), as amended. This form collects contact information from vendor employees who make the attestation. For DHS, information may be disclosed as necessary and authorized by the routine uses published in DHS/ALL-002 Department of Homeland Security

(DHS) Mailing and Other List System, November 25, 2008, 73 FR 71659.

Failure to provide any of the information requested may result in the agency no longer utilizing the software at issue. Willfully providing false or misleading information may constitute a violation of 18 U.S.C. § 1001, a criminal statute.

ATTACHMENT C

What is the Purpose of Filling out this Form?

The Federal Information Security Modernization Act of 2014 (FISMA) requires each Federal agency to provide security protections for both “information collected or maintained by or on behalf of an agency” and for “information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency.” FISMA and other provisions of Federal law authorize the Director of the Office of Management and Budget

(OMB) to promulgate information security standards for information security systems, including to ensure compliance with standards promulgated by the National Institute of Standards and

Technology (NIST).

Executive Order 14028, “Improving the Nation’s Cybersecurity” (E.O. 14028), emphasizes the importance of securing software used by the Federal Government to perform its critical functions. To further this objective, E.O. 14028 required NIST to issue guidance “identifying practices that enhance the security of the software supply chain.”1 The NIST Secure Software

Development Framework (SSDF) (SP 800-218),2 and the NIST Software Supply Chain Security

Guidance3 (these two documents, taken together, are hereinafter referred to as “NIST Guidance”) include a set of practices that create the foundation for developing secure software.

E.O. 14028 further requires that the Director of OMB take appropriate steps to ensure that

Federal agencies comply with NIST Guidance. To that end, OMB issued Memorandum M-22-

18, “Enhancing the Security of the Software Supply Chain through Secure Software

Development Practices” (M-22-18), on September 14, 2022. That memorandum was updated on

June 9, 2023, through OMB Memorandum M-23-16, “Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development

Practices” (M-23-16). M-22-18, as amended by M-23-16, provides that a Federal agency may use software subject to M-22-18’s requirements only if the producer of that software has first attested to compliance with Federal Government-specified secure software development practices drawn from the SSDF.

This self-attestation form identifies the minimum secure software development requirements a software producer must meet, and attest to meeting, before software subject to the requirements of M-22-18 and M-23-16 may be used by Federal agencies. This form is used by software producers to attest that the software they produce is developed in conformity with specified secure software development practices.

Software requires self-attestation if any of the conditions is met:

1. The software was developed after September 14, 2022;

2. The software was developed prior to September 14, 2022, but was modified by major version changes (e.g., using a semantic versioning schema of Major.Minor.Patch, the software version number goes from 2.5 to 3.0) after September 14, 2022; or

1 Executive Order on Improving the Nation’s Cybersecurity (E.O. 14028), Section 4(e).

2 Available at: https://csrc.nist.gov/Projects/ssdf 3 Available at: https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidanceunder-EO-14028-section-4e.pdf

ATTACHMENT C

https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ https://csrc.nist.gov/Projects/ssdf https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidanceunder-EO-14028-section-4e.pdf https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidanceunder-EO-14028-section-4e.pdf

3. The producer delivers continuous changes to the software code (as is the case for software-as-a-service products or other products using continuous delivery/continuous deployment).

Software products and components in the following categories are not in scope for M-22-18, as amended by M-23-16, and do not require a self-attestation:

1. Software developed by Federal agencies;

2. Open-source software that is freely and directly obtained by a Federal agency;

3. Third-party open source and proprietary components that are incorporated into the software end product used by the agency; or

4. Software that is freely obtained and publicly available.

Software producers who utilize third party components in their software are required to attest that they have taken specific steps, detailed in “Section III – Attestation and Signature” of the common form, to minimize the risks of relying on such components in their products.

Agency-specific instructions may be provided to the software producer outside of this common form. Conformance to agency-specific requirements may be included with this form as an addendum; agencies are responsible for fulfilling any Paperwork Reduction Act requirements applicable to agency-specific additions.

If a software producer is unable to submit via the online form, they may email a pdf version of the form to the respective agency:

Online Form Instructions:

Selecting the provided URL: https://softwaresecurity.cisa.gov

OR

Local PDF Instructions:

Saving the completed form as a PDF using the following naming convention:

Software Producer: Software Producers name which manufactured/compiled the software product

Product name: Complete name of software product

Version: Version number of software product

Attestation date: Date the software product was attested:

e.g. [Software Producer]_[Product]_[Version]_[Attestation Date]

→Acme_SecuritySuite_4.6.2.1_20230124

Individual agencies will provide their respective email addresses.

Filling Out the Form

Software Producer Information

Please provide a description of the software and information about the software producer. All fields in the attestation form are required to be appropriately completed by the software producer. Incomplete forms will not be accepted.

The form must be signed by the Chief Executive Officer (CEO) of the software producer or their designee, who must be an employee of the software producer and have the authority to bind the corporation. By signing, that individual attests that the software in question is developed in conformity with the secure software development practices delineated within this form. The software may be used by a federal agency, consistent with the requirements of M-22-18, as amended by M-23-16, once the agency has received an appropriately signed copy of the attestation form.

The software producer may choose to demonstrate conformance with the minimum requirements by submitting a third-party assessment documenting that conformance. A third-party assessment must be performed by a Third Party Assessor Organization (3PAO) that has either been

FedRAMP certified or approved in writing by an appropriate agency official. The 3PAO must use relevant NIST Guidance that includes all elements outlined in this form as part of the assessment baseline. To rely upon a third-party assessment, the software producer must check the appropriate box in Section III and attach the assessment to the form. The producer need not sign the form in this instance. The agency shall take appropriate steps to ensure that the assessment is not posted publicly, either by the vendor or by the agency itself.

Additional Information:

In the event that an agency cannot obtain a completed self-attestation from the software producer, an agency may still decide to use the producer’s software if the producer identifies the practices to which they cannot attest, documents practices they have in place to mitigate associated risks, and submits a plan of actions and milestones (POA&M) to the agency. When an attestation is not provided, per OMB guidance, agencies are responsible for requesting from

OMB an extension or waiver for the continued use.

This common self-attestation form fulfills the minimum requirements set forth by OMB in M-

22-18, as amended by M-23-16.

The attestation form, background, and instructions are subject to change and may be modified.

Secure Software Development Attestation Form Version 1.0

Section I

[ ] New Attestation [ ] Attestation Following Extension or Waiver [ ] Revised Attestation

Type of Attestation: [ ] Company-wide [ ] Individual Product [ ] Multiple Products or Specific

Product Version(s) (please provide complete list)

If this attestation is for an individual product or multiple products, provide the software name, version number, and release/publish date to which this attestation applies. Additional pages can be attached to this attestation if more lines are needed:

Product(s) Name Version Number4

(if applicable)

Release/Publish Date

(if applicable)

YYYY-MM-DD

For the above specified software, this form does not cover software or any components of that software that fall into the following categories:

1. Software developed by Federal agencies;

2. Open source software that is freely and directly obtained directly by a Federal agency;

3. Third-party open source and proprietary components that are incorporated into the software end product used by the agency; or

4. Software that is freely obtained and publicly available.

Note: In signing this attestation, software producers are attesting to adhering to the secure software development practices outlined in Section III for code developed by the producer.

Section II

1. Software Producer Information

Company Name:

Address:

City:

4 Attestations are binding for future versions of the named software product unless and until the software producer notifies the agencies to which it previously submitted the form that its development practices no longer conform to the required elements specified in the attestation.

State or Province:

Postal Code:

Country:

Company Website:

2. Primary Contact for this Document and Related Information (may be an individual, role, or group):

Name:

Title:

Address:

Phone Number:

Email Address (may be an alias/distribution list):

Section III

Attestation and Signature

On behalf of the above-specified company, I attest that, to the best of my knowledge, [software producer] presently makes consistent use of the following practices, derived from the secure software development framework (SSDF),5 in developing the software identified in Section I:

1) The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum:

a) Separating and protecting each environment involved in developing and building software;

b) Regularly logging, monitoring, and auditing trust relationships used for authorization and access:

i) to any software development and build environments; and

ii) among components within each environment;

c) Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk;

d) Taking consistent and reasonable steps to document, as well as minimize use or inclusion of software products that create undue risk within the environments used to develop and

5 The SSDF are standards and best practices established by the National Institute of Standards and Technology

(NIST) in NIST Special Publication (SP) 800-218.

build software;

e) Encrypting sensitive data, such as credentials, to the extent practicable and based on risk;

f) Implementing defensive cybersecurity practices, including continuous monitoring of operations and alerts and, as necessary, responding to suspected and confirmed cyber incidents;

2) The software producer makes a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities;

3) The software producer maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible;

4) The software producer employs automated tools or comparable processes that check for security vulnerabilities. In addition:

a) The software producer operates these processes on an ongoing basis and prior to product, version, or update releases;

b) The software producer has a policy or process to address discovered security vulnerabilities prior to product release; and

c) The software producer operates a vulnerability disclosure program and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion and according to any timelines specified in the vulnerability disclosure program or applicable policies.

I further attest that the software producer will notify any agency to which it has submitted this form if and when the producer ceases to make consistent use of the practices identified above in developing the software.

Signature of CEO or Designee with authority to bind the corporation

Date (YYYY-MM-DD): _____________________________

Name:

Title:

OR

A certified FedRAMP Third Party Assessor Organization (3PAO) or other 3PAO approved in writing by an appropriate agency official has evaluated our conformance to all elements in this form. The 3PAO used relevant NIST Guidance that includes all elements outlined in this form as the assessment baseline. The assessment is attached.

ATTACHMENT(S):

• [Artifact/Addendum Title]: [Artifact/Addendum Description]

Burden Statement

The public reporting burden to complete this information collection is estimated at 3 hours and

20 minutes per response, including time for reviewing instructions, searching data sources, gathering, and maintaining the data needed, and completing and reviewing the collection of information. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number and expiration date. Send comments regarding this burden estimate or any other aspect of this collection information, including suggestions for reducing this burden, to DHS/CISA

CSCRM@cisa.dhs.gov.

APPENDIX

REFERENCES

Minimum Attestation References:

The minimum requirements within the Secure Software Attestation Form address requirements put forth in E.O. 14028 subsection (4)(e). A mapping to specific SSDF practices and tasks is provided for reference purposes.

Attestation Requirements Related

E.O.

14028

Subsection

Related SSDF

Practices and

Tasks

1) The software is developed and built in secure environments. Those environments are secured by the following actions, at a minimum: 4e(i)

[See rows below]

a) Separating and protecting each environment involved in developing and building software; 4e(i)(A)

PO.5.1

b) Regularly logging, monitoring, and auditing trust relationships used for authorization and access:

i) to any software development and build environments; and

ii) among components within each environment; 4e(i)(B)

c) Enforcing multi-factor authentication and conditional access across the environments relevant to developing and building software in a manner that minimizes security risk; 4e(i)(C)

PO.5.1, PO.5.2

d) Taking consistent and reasonable steps to document, as well as minimize use or inclusion of software products that create undue risk within the environments used to develop and build software; 4e(i)(D)

e) Encrypting sensitive data, such as credentials, to the extent practicable and based on risk; 4e(i)(E)

PO.5.2

f) Implementing defensive cybersecurity practices, including continuous monitoring of operations and alerts and, as necessary, 4e(i)(F)

PO.3.2, PO.3.3,

PO.5.1, PO.5.2

responding to suspected and confirmed cyber incidents;

2) The software producer makes a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities; 4e(iii)

PO 1.1, PO.3.1,

PO.3.2, PO.5.1,

PO.5.2, PS.1.1,

PS.2.1, PS.3.1,

PW.4.1, PW.4.4,

PW 7.1, PW 8.1,

RV 1.1

3) The software producer maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible;

4e(vi)

PO.1.3, PO.3.2,

PO.5.1, PO.5.2,

PS.3.1, PS.3.2,

PW.4.1, PW.4.4,

RV.1.1, RV.1.2

4) The software producer employed automated tools or comparable processes that check for security vulnerabilities. In addition:

a) The software producer operates these processes on an ongoing basis and prior to product, version, or update releases;

b) The software producer has a policy or process to address discovered security vulnerabilities prior to product release; and

c) The software producer operates a vulnerability disclosure program and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion and according to any timelines specified in the vulnerability disclosure program or applicable policies. 4e(iv)

PO.4.1, PO.4.2,

PS.1.1, PW.2.1,

PW.4.4, PW.5.1,

PW.6.1, PW.6.2,

PW.7.1, PW.7.2,

PW.8.2, PW.9.1,

PW.9.2, RV.1.1,

RV.1.2, RV.1.3,

RV.2.1, RV.2.2,

RV.3.3

ATTACHMENT D

NDA for RFQ 9531BM25Q0014, Page 1 of 3

National Transportation Safety Board (NTSB) Acquisition Division Non-Disclosure Agreement

NON-DISCLOSURE AGREEMENT

I, ______________________________ intending to be legally bound, hereby consent to the terms and conditions in this Agreement in consideration of my being granted conditional access to certain information that is owned by, produced by, or in the possession of the United States Government. I understand and acknowledge that I have been approved for access for the purpose of providing Incident Management Software and services to perform the installation of the software.

I understand that I may gain access to information that has not been released to the public, and that such information is Confidential, Proprietary and/or Personally Identifiable Information (PII).

For purposes of this Agreement, "Confidential Information" includes, but is not limited to, NTSB investigative information, whether as physical evidence or in documentary form; NTSB testing protocols;

descriptions of NTSB existing, pending, or proposed work; enforcement or investigative evidence; NTSB opinions, analyses, and conclusions whether in draft or final forms; compilations of data performed for the NTSB by contractors and third parties; correspondence that includes preliminary discussions or deliberations; and any other information, records, or data marked “Confidential” and supplied by the NTSB.

For purposes of this Agreement, “Proprietary Information” is third party information provided to the NTSB, which the third party considers to be trade secrets or protected commercial or financial information.

Proprietary Information may include, but is not limited to, processes, know-how, and other protected technologies developed by that third party and exempt from release under the Freedom of Information Act, 5 United States Code (U.S.C.) § 552(b)(4).

For purposes of this Agreement, PII is defined as follows: “any information about an individual maintained by an agency, including, but not limited to (1) education, financial transactions, medical history, and criminal or employment history and (2) information which can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother’s maiden name, and biometric records, etc., including any other personal information which is linked or linkable to an individual.” Office of Management and Budget Memorandum, M-06-19 (July 12, 2006). I understand that PII is information that can be used to uniquely identify, contact, or locate a single person or can be used with other sources to uniquely identify a single individual, and may include, but is not limited to, pilot certificate numbers, mariner identification numbers, or commercial driver’s license numbers.

Be advised that all reports and/or written, electronic, and photographic items and data developed or acquired in the performance of work for or with the NTSB are, for the purpose of this agreement, the property of the United States and are, under 18 U.S.C. § 641, things of value. Be advised that 18 U.S.C. § 641 provides, in pertinent part, as follows:

Whoever...steals, purloins, or knowingly converts to his use or the use of another, or without authority, sells, conveys or disposes of any record...or thing of value of the United States or of any department or agency thereof...Shall be fined not more than $10,000 or imprisoned not more than one year, or both.

NDA for RFQ 9531BM25Q0014, Page 2 of 3

I understand that I am bound to maintain the confidentiality of any Confidential/Proprietary/PII information provided to me. I will honor and comply with any and all dissemination restrictions cited or verbally relayed to me by the NTSB or any other proper authority. In the event that I have access to, observe, or hear Personally Identifiable Information (PII) of any individual, I shall not disclose such information and will treat it as confidential information, in accordance with standards promulgated by the Office of Management and Budget. All Confidential/Proprietary/PII information shall not be disclosed to any third party and shall be protected with reasonable care. I acknowledge and understand that should I inadvertently receive materials for which the NTSB has not granted me access, I will promptly return the materials and not make copies of them in whole or in part.

I shall not alter or remove markings which indicate that information is Confidential/Proprietary/PII. I agree that if I use information from a Confidential/Proprietary document or other medium, I will carry forward any markings or other required restrictions to derivative products and protect them in the same manner as the original. I shall not use any Confidential/Proprietary information received from the NTSB except for purposes as may be stated in this Agreement.

This Agreement and the furnishing of Confidential/Proprietary/PII information as provided herein shall not be construed as establishing, either expressly or by implication, any grant of rights or licenses to me. By signing this form, I hereby agree to:

(1) Receive and hold all Confidential/Proprietary information in strict confidence;

(2) Safeguard such information from unauthorized use and from disclosure or release to unauthorized third parties, and report promptly to the appropriate official any loss, theft, misuse, misplacement, inadvertent access, unauthorized disclosure, or any other security violations I have knowledge of, whether or not I am personally involve; and

(3) Return all Confidential/Proprietary information to the NTSB:

(a) Upon demand by an authorized individual; and/or

(b) Upon conclusion of my duties, association, or support of the NTSB; and/or

(c) Upon determination that my official duties do not require further access to such information.

This Agreement is made and intended for the benefit of the United States and may be enforced by the United States Government or the NTSB contractor for whom I work. By granting me conditional access to information in this context, the United States Government may seek any remedy available to it to enforce this Agreement, including, but not limited to, application for a court order prohibiting disclosure of information in breach of this Agreement. I understand that if I violate the terms and conditions of this Agreement, such violation may result in the cancellation of my conditional access to information covered by this Agreement; termination of my participation; and I could be subject to administrative, disciplinary, civil or criminal action, as appropriate under the laws, regulations, directive or treaties applicable to the category of information involved. The United States Government and the NTSB contractor for whom I work have not waived any statutory or common law evidentiary privileges or protections that they may assert in any administrative or court proceeding to protect any Confidential/Proprietary/PII information to which I have been given conditional access under the terms of this Agreement.

Each provision of this Agreement is severable. If a court should find any provision of this Agreement to be unenforceable, all other provisions shall remain in full force and effect.

Signing this Agreement does not bar disclosure to Congress or to an authorized official of an Executive Agency or the Department of Justice that is essential to reporting a substantial violation of law.

NDA for RFQ 9531BM25Q0014, Page 3 of 3

The NTSB enters into this agreement with the below signed party as permitted under 49 U.S.C. § 1113(b)(1)(B).

The obligations contained in this Agreement are in consideration of being granted access to NTSB controlled confidential information, protected third party information, and PII that is in the possession of the NTSB. I acknowledge that all obligations imposed by this Non-Disclosure Agreement concerning the use and disclosure of NTSB Confidential Information apply for the duration of my participation and for a period of two years thereafter. There are no time limits on the obligations to keep confidential PII and third party Proprietary Information.

I represent and warrant that I have the authority to enter into this Agreement.

AGREED:

Signature:_________________________________

Print Name:________________________________

Contractor CompanyAddress:__________________________________Telephone:__________________

Date:____________________________

For the NTSB:

Signature:_________________________________

Print Name: Peter M. Hazlinsky

Address: 490 L’Enfant Plaza, SW Washington, D.C. 20594 Telephone: 202.314.6205

Date: ______________________________

This form is not subject to the requirements of P.L. 104-13, “Paperwork Reduction Act of 1995,” 44 U.S.C., Chapter 35.