Attachment 8 - FDA Application Development Constraints and Assumptions.pdf

FDA Application Development Constraints and Assumptions

1.0 Network and Data Centers

FDA Systems and Applications are accessed and managed remotely over a Transmission Control Protocol/Internet Protocol (TCP/IP) and Active Directory based network that provides connectivity to the White Oak Data Center (WODC), the Ashburn Data Center (ADC), National Center for Toxicological Research (NCTR) Data Center, and the CSP Cloud environments.

(Amazon Web Services, GovCloud, Cloud Integrated Services Applications, Cloud Log Aggregation Warehouse, Microsoft Azure))

The ODT Data Center and Infrastructure Support contractors are responsible for installing, managing, and monitoring the physical and logical infrastructure of the environments (network, storage, servers, backups, etc.). The FDA also utilizes and, in some cases, provides direct connectivity to multiple Cloud Service Providers (CSPs), (e.g., Amazon, GovCloud, and Azure).

The FDA maintains several data centers and requires homogeneous standards for IT procurement and IT infrastructure. These systems are often sharing databases or hardware and therefore could have a direct impact on other systems if they are not developed properly in concert at an enterprise level. Furthermore, historical procurements pass through different teams including the customer or user community, requiring frequent communication, interactions and modifications/updates. FDA’s move to an enterprise procurement model will decrease redundancies, reduce cost, and allow the FDA to leverage its purchasing power.

1.1 Redundancy

FDA Systems are installed and configured in a redundant shared server infrastructure where physical and virtual servers support multiple FDA Centers. FDA Systems are accessed via redundant load balancers, firewalls, and networking.

1.2 Communication

The FDA requires that communication between all internal and external systems, servers, and data centers is managed by ODT on an exception-by-exception basis in accordance with the FDA’s Security Policy.

1.3 Databases

FDA Systems are primarily supported by databases residing in an Oracle Real Application Cluster (RAC) environment installed on Oracle Exadata.

There are other instances of databases such as SQL Server and virtual servers, database servers, applications servers, cloud service providers, GovCloud, Cloud Integrated Services Applications, CaaS Node servers, Identity Access Servers that are primarily leveraged in support of specific tools or software.

1.4 Virtual Private Network

Any off-site work performed for FDA will be conducted using the FDA Virtual Private Network (VPN). All work in support of FDA must be performed using Government Furnished Equipment (GFE) unless explicitly approved by the COR or designee in advance.

1.5 Environments

FDA applications and databases are deployed, operated, and maintained in a number of distinct environments: Development, Testing, Pre-Production, and Production. These environments are hosted in the FDA’s data centers which are located in Silver Spring, MD;DC Metro Area; Jefferson, AR; College Park, MD; Ashburn, VA; or in the cloud from a Federal Risk and Authorization Management Plan (FedRAMP) approved Cloud Service Provider (CSP) or Contractor-Owned Contractor-Operated data centers (COCO). These environments are typically implemented using shared infrastructure technologies such as Cloud and virtual servers. Engineering tasks are performed in a proof of concept “Sandbox”, development, test, pre-production, or production environment in either of the data centers or an FDA approved CSP. All code in development and in production shall reside in the FDA hosting environments.

AWS Cloud to Cloud will provide secure, efficient, and compliant direct connections between systems and applications hosted in the FDA’s Amazon Web Services (AWS) GovCloud environment and resources on the public internet. AWS Cloud to Cloud is comprised of a firewalls and dedicated mechanisms that support integration with the Cloud Integrated Services Application (CISA) Cloud Log Aggregation Warehouse (CLAW).

This solution complies with requirements defined by the Department of Homeland Security (DHS) Trusted Internet Connection (TIC) initiative and aligns with the FDA CMAP and FDA Zero Trust Cybersecurity Network Defense Plan.

The data centers are operated and maintained separately from this BPA contract. However, system and application owners, including the BPA Contractors, must collaborate with the FDA employees and the Contractor staff responsible for the data centers. Please see Attachment 2 – Application Development and Process Standards, Attachment 5 – FDA List of Technologies, Attachment 6 - FDA Cloud Technologies for more information on FDA’s technical environment including the data center environments.

FDA’s systems are developed across four logically and physically separated environments to meet the FDA’s Enterprise security and configuration management requirements. The environments and their purpose are as follows:

1.5.1 Production

Production release of system code and configurations in the Ashburn Data Center (ADC) or in the cloud and is typically a higher performance environment where only production applications are hosted.

Table 1 - FDA Data Center Locations (not including Cloud)

Data Center Address

FDA OIMT ADC

(Also known as “Contractor Hosted Data Center” or CHDC)

DC Metro Area

FDA OIMT WODC DC Metro Area

FDA Wiley Scientific Data Center DC Metro Area

FDA OIMT National Center for Toxicological Research (NCTR) Data Center

Jefferson, AR

Additional field laboratory and office locations are throughout the US and a few international sites.

1.5.2 Pre-Production

FDA The Pre-Production environment is hosted at the Ashburn Data Center (ADC) or in the cloud and is configured as closely as possible to match the Production Environment including firewalls and other configurations unique to Production Environment. The Pre- Production environment is meant to facilitate the following objectives:

• UAT and Performance Testing of applications. Typically, system owners and system administrators will designate UAT user accounts that are maintained in this environment. Security scans and code verification which are meant to ascertain and certify compliance with security standards and requirements are conducted here.

• Testing of Extranet applications.

• Testing and verification.

• Troubleshooting for actions for an application which is dependent on the Production environment and Production data.

• A stable “Training Environment” for end users.

1.5.3 Development

The Development Environment provides the Development Team with a stable working development environment with required privileges and is used to perform the unit testing of code. The servers for this environment are available virtually in a Contractor supported data center at the FDA’s White Oak campus, also known as the White Oak Data Center (WODC) or in the Cloud. Development and deployments may take place in the FDA’s data centers (WODC and Ashburn Data Cener (ADC)) or in the Cloud.

applications and databases are deployed, operated, and maintained in a number of distinct environment

1.5.4 Test

Testing and integration of system code and configurations in the White Oak Data Center. The Test Environment is configured to match as closely as possible the Pre- Production environment. This stable environment is available virtually from a hosted data center at the FDA’s White Oak campus or in Cloud. The Test environment is meant to facilitate the following objectives:

• System and integration testing required as part of the approval process for code release.

• Testing for applications that require frequent refresh of data or the code baseline.

• Testing and development of scripts for purposes such as:

o Load testing o Integration testing o User Acceptance Testing (UAT) o Authoring and verifying the accuracy of the Version Description Document

(VDD). VDD’s are documents and scripts which provide detailed instructions to deploy and implement systems in Pre-Production and Production environments where the development team typically has very limited and controlled access.

*Note that FDA’s Modernized architecture is moving away from an architecture that strictly adheres to this security model as we move towards a more streamlined and cloud native architecture*

1.6 Public Cloud Infrastructure

The FDA currently is utilizing various public Cloud Service Providers (CSP) as part of the Enterprise Cloud Strategy. There will be a mixture of development, test, preproduction, and production applications that will be hosted within the public CSPs. Please see Attachment 6 – FDA Cloud Technologies for a list of Cloud Services utilized at FDA.

The Contractor shall support IT applications deployed to the cloud in AWS, Azure, and all other FedRamp approved IaaS (Infrastructure as a Service) providers, Software as a Service (SaaS), and Platform as a Service (PaaS). The FDA currently is utilizing various providers of software as a service (SaaS) and platform as a service (PaaS) for developing software applications. The Contractor shall provide Task Order support and development as part of the Enterprise Cloud Strategy for applications built/developed/migrated to these platforms. This support includes Salesforce platforms, Appian platforms, and any future cloud platform approved by the FDA.

1.7 Modernized Architecture

FDA is moving away from its existing monolithic systems/applications and leveraging Application Programming Interfaces (APIs), microservices, containers and other Cloud Native technologies with more modern approaches to IT architecture and development, such as Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and agile development within a DevSecOps framework and culture.

1.8 Modernized Common Technical Foundation

FDA has implemented a software build pipeline and containerization platform as a Common Technical Foundation (CTF) to support all future software builds and related tools. The CTF provides an agile, flexible, highly reusable, and fit for purpose architecture. The pipeline includes several opensource and licensed software packages for automation, code quality and security, code storage, automated testing, data as code, etc.

1.9 Modernized Containerization Environment

Additionally, FDA has implemented a Containerization environment that is the intended platform for all FDA software (Custom, Government-off-the-Shelf (GOTS), or Commercial-of-the-Shelf (COTS).

1.10 Modernized Common User Interface

FDA has also implemented a common user interface based on approved design standards that will be the single point of entry that provides access to most FDA business capabilities and tools.

1.11 Modernized Identity and Access Management

An Identity and Access Management (IAM) software package has also been integrated with various FDA and HHS Enterprise systems. The IAM provides for the curation of identity as well as RBAC for all new code, services, APIs, etc.

1.12 Auto Deployment

The Contractor shall use auto-deployment tools and processes (a software upgrade release system already in production at FDA) to deploy all releases, after the first initial implementation, including: maintenance, enhancement and emergency releases, for Pre-Production and Production environments, where available. The Contractor shall provide Self Service Automated Application Deployments in Test environment. The Application Deployment Artifacts shall be tested in the Test environment and then provided to FDA IT Server administrators for both WODC & ADC that will auto install these upgrades/releases in Pre-Prod/Prod.

1.13 Change to Disable Macros in Microsoft Office Documents from

Outside Sources

The FDA does not accept documents which contain the use of macros. Document submissions required throughout the award period(s) shall not have macro enabled functionality and any document delivered having that functionality will be deemed delinquent, if not corrected prior to the due date.

1.14 FDA Approved Technologies List

The FDA Product Catalog List contains a list of approved and not approved technologies including applications (software and tools), infrastructure and peripherals (hardware), and scientific software and devices. The list is on an FDA website and allows users to enter criteria, e.g., software name, to determine if it is on the list, along with any restrictions, e.g., contained to a specific FDA Center/Organization. Access to this is GFI will be provided after award. The Contractor is not limited to the Product Catalog; however, if the Contractor proposes a technology that is not in the Product Catalog, they must work with the COR or COR designee to get the technology in the Catalog before proceeding with implementation.

Access to the FDA Product Catalog will be provided after award of the individual Order.

2.0 Software Development Lifecycle

The contractor shall adhere to the HHS EPLC management process, which is currently used by the FDA. This process-driven IT lifecycle management approach emphasizes enterprise integration based on development of sound business and technical requirements.

2.1 Enterprise Performance Lifecycle (EPLC)

A process-driven Information Technology (IT) life cycle management approach emphasizing enterprise integration based on the development of sound business and technical requirements. This lifecycle guidance applies to software development and includes agile and waterfall methodologies. The HHS EPLC has been tailored by the FDA and will be referred to as the FDA EPLC for this document. For each project, from the FDA EPLC, the Project Process Agreement (PPA) is customized to generate the activities and deliverables required in this procurement. This process-driven IT lifecycle management approach emphasizes enterprise integration based on development of sound business and technical requirements. The framework will evolve over time in response to changes in technology and business needs and, therefore, the Contractor is expected to adapt accordingly to comply with the most current framework methodology in performance of work under this BPA. The Contractor shall consult with the COR and OIM to clarify the EPLC artifacts required for an individual project or system. The required artifacts depend on the release type and are tailored through the PPA.

Furthermore, the Contractor shall work with the COR and OIM Enterprise Architecture (EA) leads to ensure that updated artifacts are maintained in the EA repositories.

2.1.1 Stage Gate Review (SGR) Support

SGRs are FDA’s release review and approval process, which focuses on the review and approval of the EPLC documents created or modified per the Project Process Agreement (PPA) for the release. The Contractor shall provide the Government with the technical support to create or modify documents per the PPA. The Contractor shall be available to attend the SGR upon notification of the COR.

2.1.2 FDA TBM Center of Excellence (COE)

The FDA has adopted the Technology Business Management (TBM) model aligned to FDA’s digital transformation strategy. TBM is a value-management framework for IT Financial Management designed to drive transparency into IT costs, consumption, and performance. The TBM discipline is designed to bridge the gaps between IT, Finance, and Mission / Business stakeholders and allow for a shared understanding of the Enterprise IT Portfolio. At the FDA, the TBM Taxonomy is expanded to account for the unique mission, priorities, and activities that the FDA performs and is divided into four

(4) layers: 1) Business Capabilities, 2) Solutions/Services, 3) IT Towers, and 4) Cost Pools.

TBM information is provided in Attachment 1, FDA TBM Layers Diagram.

2.1.3 FDA IT Governance

FDA’s Strategic IT Plan guides FDA’s efforts on providing a framework aimed at improving the overall selection and management of IT systems and applications to enable FDA to manage IT risks, invest in the right priorities, ensure compliance, and measure performance. All IT applications must go through enterprise architecture governance reviews by the FDA Technology Council (Tech Council), change control boards, and IT working groups to ensure alignment with the FDA Strategic IT Plan.

2.1.4 Change Control Boards

FDA’s Change Control Boards (CCBs) consist of the following: Change Control, Configuration & Release Management CCB; Desktop CCB; and Firewall CCB; and Active Directory (AD) CCB. The CCB is the governing body that facilitates approval of changes to the FDA Infrastructure within the Ashburn Data Center (ADC), Scientific Data Center(SDC), White Oak Data Center (WODC), NCTR data center, Cloud Service Providers, and all other FDA locations hosting infrastructure services. The CCB manages the process of formally changing the FDA IT infrastructure and Configuration Management database through requests to the Change Control Board. Configuration Management, Change Management, and Release Management comprise the activities focused on establishing and maintaining the integrity of applications, systems, and services throughout the product and operational life cycle. Formal change management is required under the Office of Management and Budget (OMB) Circular A-130 and Federal Information Security Management Act (FISMA) to ensure the organization:

1. authorizes and documents changes to information systems

2. retains and reviews records of configuration managed changes to the systems

3. audits activities associated with configuration managed changes to the system

The CCB is also the administrator of the automated Configuration Management Tools:

Atlassian JIRA, Confluence, Bamboo, Fisheye, Crucible and Subversion. The Change Management Procedures will be furnished upon award.

The Desktop CCB provides a forum for FDA business, management, and technical staff to propose and reject/accept changes to the FDA desktop base image, center specific top-offs, and software deployments. The Firewall CCB, composed of members of FDA IT Security, provides necessary protection for any network connected to the internet against overt, network-based intrusion by creating rules to be put into place on the firewall to allow services to connect in all environments of WODC, ADC,, NCTR, SDC, COCO data centers, cloud providers, and other FDA Border firewalls. The Active Directory CCB provides a forum for changes to Microsoft Active Directory (AD) as the service solution for authentication and authorization in addition to group policy updates.

All IT systems developed or maintained under this BPA shall follow the FDA change management and Enterprise Performance Lifecycle (EPLC) policies developed for changes to the IT infrastructure using the FDA’s ITIL (IT Infrastructure Library) Service Lifecycle processes. ITIL recommends best practices for IT service management (ITSM) to support the standardization of various processes and stages in the IT lifecycle. A change request must be submitted for approval to the appropriate CCB when a change to the FDA infrastructure is needed. The Contractor shall follow the IT processes for change management through the submission of change requests into FDA’s ServiceNow and supporting the change in the weekly CCB meetings. The ODT ITIL Process Portal link will be furnished upon award.

2.2 Technical Standards and Guidelines

All solutions developed on this contract shall comply with current standards and guidelines, which include, but are not limited to, the following activities:

• Comply with and supply a resource to assist with the FDA Security Authorization process, which closely resembles NIST

SP 800-37.

• Establish a continuous monitoring capability in accordance with NIST SP 800-137.

• Maintain an accurate inventory of all devices used in the performance of the contract.

• Complete the FDA recommended templates of security artifacts for development or maintenance of any IT system.

• Review all identified and applicable weaknesses within the Plan of Action and Milestones and provide a resolution within the required timeline.

• Employees with access to data will be required to undergo a Level 5 Public Trust security clearance.

• Sign non-disclosure agreement FDA Form 3398: Contractor's Commitment to Protect Non-Public Information (NPI) Agreement.

• Comply with NIST SP 800-53.

• Comply with all FISMA, NIST, and OMB requirements.

• Comply with FDA 3250 series of SMG policies, as well as HHS security policies.

• Comply with the FDA approved technologies list and use FDA issued laptop/workstations.

2.2.1 Technical Standards and Guidelines

All The Contractor, shall, where applicable, conform to the FDA standard technologies, processes, and tools. Additional information is included in the Attachment 2 – Application Development and Process Standards. The Contractor shall submit new technologies or different versions of an already approved technology into the ServiceNow process which will be reviewed by the FDA Center IT Investment Review Boards. This process is also used to request the provisioning of new servers in the data centers, containers, and cloud storage. The Government reserves the right to upgrade and/or change these tools and technologies as necessary to meet FDA’s mission. All tools and technologies go through rigorous approval process before introducing to the FDA environment.

2.2.2 Security Authorization Process

All solutions developed on this contract shall comply with current standards and guidelines, which include, but Security Authorization is the approach FDA follows to fulfill Federal Information Security Management Act (FISMA), Office of Management and Budget (OMB) and Department of Health and Human Services (HHS) requirements to ensure that information resources have adequate security to protect the confidentiality, integrity and availability of information collected, processed, transmitted, stored, or disseminated by the Agency. For further information, see SP 800- 37 Rev. 1: Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach located at http://csrc.nist.gov/publications/nistpubs/800- 37-rev1/sp800-37-rev1-final.pdf.

a. NIST Special Publication (SP) 800-53:

This publication was developed by the Joint Task Force Transformation Initiative Interagency Working Group with representatives from the Civil, Defense, and Intelligence communities in an ongoing effort to produce a unified information security framework for the Federal Government— including a consistent process for selecting and specifying safeguards and countermeasures (i.e., security controls) for federal information systems. See SP 800-53 Rev. 4: Security and Privacy Controls for Federal Information Systems and Organizations located at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf for more information.

http://csrc.nist.gov/publications/nistpubs/800-%2037-rev1/sp800-37-rev1-final.pdf http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

b. Federal Information Security Management Act (FISMA):

The E-Government Act (Public Law 107-347) passed by the 107th Congress and signed into law by the President in December 2002 recognized the importance of information security to the economic and national security interests of the United States. FISMA, which is Title III of the E- Government Act, requires each federal agency to develop, document, and implement an agency- wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, Contractor, or other source (see http://csrc.nist.gov/groups/SMA/fisma/index.html).

c. FDA 3250 Series of Staff Manual Guide (SMG) Policies:

FDA Staff Manual Guides (SMGs) are the Agency directives that document organizations and functions; delegations of authority; and administrative and program policies, responsibilities and procedures. The Staff Manual Guides 3250 series (Information Technology Security) is applicable to this BPA.

d. FDA Security Program, Contractor Oversight Guide – Section 2:

Information systems subject to Departmental and Federal requirements are predominantly maintained by Department personnel within HHS facilities; however, there exist a substantial number of Contractor-run systems. This section clarifies security requirements for these Contractor-based systems as well as defines the related roles of Contractors and Departmental personnel.

This BPA shall also provide an efficient means of obtaining technical support services to align with the following constraints:

FDA Technology Modernization Action Plan (TMAP) and Data Modernization Action Plan (DMAP) – See BPA SOW Attachment 6: TMAP & DMAP).

Federal Information Technology Acquisition Reform Act (FITARA) and the HHS FITARA Implementation Plan (inclusive of OPDIV responsibilities). FITARA provides information and addresses priorities that includes Datacenter closures, energy among other efficiencies and related reporting support.

Clinger-Cohen Act of 1996, 40 U.S.C. 11101(6);

The Federal Information Security Management Act of 2002 (FISMA);

HHS Enterprise Architecture and PL 112-144 (enterprise program management plan).

2.3 Data Standards

The FDA provides guidance for data compliance with FDA regulations and the submission of data to the FDA. Specific data standards requirements will be detailed in each Order released under this contract. The guidance on data standards references and resources can be found at:

http://csrc.nist.gov/groups/SMA/fisma/index.html https://www.fda.gov/industry/fda-resources-data-standards/study-data-standards-resources .

The following is a representative list of data standards that are being used or being considered for use at FDA:

• Structured Product Labeling (SPL).

• Individual Case Safety Report (ICSR).

• Regulated Product Submission (RPS).

• Electronic Common Technical Document (eCTD).

• Study Data Standards.

• Stability Data Standard.

• Substance Registration System - Unique Ingredient Identifier

(UNII).

• Federal Medication Terminology hosted by NCI Enterprise Vocabulary

Services.

• FDA Terminology hosted by NCI Enterprise Vocabulary

Services.

• XForms.

• Validators.

• XML.

• HL7.

• Clinical Data Interchange Standards Consortium (CDISC) including:

Study Data Tabulation Model (SDTM) Analysis Data Model (ADaM) Standard for Exchange of Non-Clinical Data

(SEND)

• Identification of Medicinal Products (IDMP).

• FASTQ

*Note: More details about the data standards can be found by browsing to: http://www.fda.gov/ForIndustry/DataStandards/default.html*

2.4 Non-commercial Computer Software Compliance

The following is a representative list of data standards that are being used or being considered for use at FDA:

2.4.1 General Requirements

The Contractor shall ensure that computer software operated on behalf of the Government is fully functional and operates correctly on systems configured in accordance with government policy regarding configuration requirements. The Contractor shall test applicable products and versions with all relevant and current updates and patches updated prior to installing in the government environment. The https://www.fda.gov/industry/fda-resources-data-standards/study-data-standards-resources https://www.fda.gov/industry/fda-resources-data-standards/study-data-standards-resources http://www.fda.gov/ForIndustry/DataStandards/default.html*

Government will have unlimited rights in all software developed exclusively with Government funds. "Computer software" means:

• Computer programs that comprise a series of instructions, rules, routines, or statements, regardless of the media in which recorded that allow or cause a computer to perform a specific operation or series of operations; and

• Recorded information comprising source code listings, design details, algorithms, processes, flow charts, formulas, and related material that would enable the computer program to be produced, created, or compiled.

2.4.2 Security Requirements

The Contractor shall incorporate IT security requirements into all phases of program planning and execution, from budgeting to close-out and the implementation of those requirements shall align with the HHS Enterprise Performance Life Cycle (EPLC). The Contractor shall comply with security requirements, EPLC processes, and Enterprise Architecture, to ensure proper and confidential handling of data and information.

The Contractor shall refer to the HHS-OCIO Policy for Information Systems Security and Privacy, dated July 7, 2011. The Contractor shall become familiar with the HHS Departmental Information Security Policies, which may be found at http://www.hhs.gov/ocio/policy/. The HHS Cybersecurity Program develops policies, procedures, and guidance to serve as a foundation for the HHS information security program. These documents implement relevant Federal laws, regulations, standards, and guidelines that provide a basis for the information security program at the Department.

The Contractor must become familiar with HHS Cybersecurity Program guidelines as presented at http://www.hhs.gov/ocio/policy/index.html.

Contractors shall follow and adhere to National Institute of Standards and Technology (NIST) Special Publication (SP) 800-64 Security Considerations in the System Development Life Cycle http://dx.doi.org/10.6028/NIST.SP.800-64r2 at a minimum, for system development. This requirement may include providing system documentation at designated intervals within the EPLC that require artifact review.

2.4.3 General Security Requirements.

The Contractor (and/or any subcontractor) shall comply with information security and privacy requirements, Enterprise Performance Life Cycle (EPLC) processes, HHS Enterprise Architecture requirements to ensure information is appropriately protected from initiation to expiration of the contract.

2.4.4 System Documentation.

Contractors (and/or any subcontractors) must follow and adhere to NIST SP 800-64, Security Considerations in the System Development Life Cycle, at a minimum, for system http://www.hhs.gov/ocio/policy/ http://www.hhs.gov/ocio/policy/index.html http://dx.doi.org/10.6028/NIST.SP.800-64r2 development and provide system documentation at designated intervals (specifically, at the expiration of the contract) within the EPLC that require artifact review and approval.

2.4.5 Sanitization of Government Files and Information.

As part of contract closeout and at expiration of the contract, the Contractor (and/or any subcontractor) shall provide all required documentation in accordance with FDA OAGS SMGs to the CO and/or COR to certify that, at the government’s direction, all electronic and paper records are appropriately disposed of and all devices and media are sanitized in accordance with NIST SP 800-88, Guidelines for Media Sanitization and FDA IS2P Sanitization of Computer-Related Storage Media.

2.4.6 802.1x Requirements Any system requiring wired or wireless connectivity to the FDA Enterprise network shall support the Institute of Electrical and Electronics Engineers (IEEE) 802.1X protocol and shall provide 802.1x authentication “supplicant” software. All systems shall support X.509 Public Key Infrastructure (PKI) and accept FDA issued device certificates as a method of authentication. If the system does not support the 802.1X protocol, a waiver will be required to document and justify the exemption with the Information System Security Officer (ISSO), and the FDA system owner shall provide a device MAC (Media Access Control) address identifying the end point network device and its associated role the device will perform when connected to the FDA network. (e.g. Printer, Scientific Instrument, Telephone) The following Extensible Authentication Protocols (EAP) Methods are supported under 802.1x for wired access, EAP-TLS, EAP-PEAP, and EAP- TTLS. All Government Systems connected via wireless shall use EAP-TLS as defined by National Institute of Standards and Technology (NIST) Special Publication 800-53 - AC- 18(1) - Wireless Access – (Authentication and Encryption).

2.4.7 Accessibility and Section 508 Terms and Conditions

Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d) requires Federal agencies to purchase electronic and information technologies (EIT) that meet specific accessibility standards. This law helps to ensure that federal employees with disabilities have access to, and use of, the information and data they need to do their jobs. Furthermore, this law ensures that members of the public with disabilities have the ability to access Government information and services.

There are three (3) regulations addressing the requirements detailed in Section 508. The Section 508 technical and functional standards are codified at 36 CFR Part 1194 and may be accessed through the Access Board’s Web site at http://www.access-board.gov. The second regulation issued to implement Section 508 is the Federal Acquisition Regulation (FAR). FAR Part 39.2 requires that agency acquisitions of Electronic and Information Technology (EIT) comply with the Access Board’s standards. The entire FAR is found at Chapter 1 of the Code of Federal Register (CFR) Title 48, located at http://www.acquisition.gov. The FAR rule implementing Section 508 can be found at http://www.access-board.gov/ http://www.acquisition.gov/ http://www.section508.gov. The third applicable regulation is the HHS Acquisition Regulation (HHSAR).

Regardless of format, all Web content or communications materials produced for publication on or delivery via HHS Web sites - including text, audio or video - must conform to applicable Section 508 standards to allow federal employees and members of the public with disabilities to access information that is comparable to information provided to persons without disabilities. All Contractors (including subcontractors) or consultants responsible for preparing or posting content intended for use on an HHS-funded or HHS-managed website must comply with applicable Section 508 accessibility standards, and where applicable, those set forth in the referenced policy or standards documents below. Remediation of any materials that do not comply with the applicable provisions of 36 CFR Part 1194 as set forth in the SOW shall be the responsibility of the Contractor or consultant retained to produce the Web-suitable content or communications material.

Unless an agency exception to this requirement exists, the Contractor must conform to applicable Section 508 standards and must apply best practices associated with Section 508 compliance during the application design, development, and testing phases. The Contractor shall utilize FDA-approved tools to verify the compliance with the Section 508 standards and ensure the delivery of the fully compliant products.

The Section 508 accessibility standards applicable to this SOW are identified below. The Contractor must provide any necessary updates to the submitted HHS Product Assessment Template(s) at the end of each contract or order exceeding the simplified acquisition threshold (see FAR 2.101) when the contract or order duration is one year or less. If it is determined by the Government that EIT supplies and services provided by the Contractor do not conform to the described accessibility standards in the contract, remediation of the supplies or services to the level of conformance specified in the contract will be the responsibility of the Contractor at its own expense. These standards address access to information and communication technology (ICT) under Section 508 of the Rehabilitation Act and Section 255 of the Communications Act

The Section 508 accessibility standards applicable to this contract are:

• Must meet WCAG 2.0 A and AA

• E101.2 Equivalent Facilitation

• E203 Access to Functionality

• E204 Functional Performance Criteria

• E205 Electronic Content

• E206 Hardware

• E207 Software

• E208 Support Documentation and Services

• Chapter 4 Hardware http://www.section508.gov/ https://www.levelaccess.com/wcag-a-and-wcag-aa-conformance/ https://www.access-board.gov/ict/#E101.2 https://www.access-board.gov/ict/#E203-functionality https://www.access-board.gov/ict/#E204-functional-performance-criteria https://www.access-board.gov/ict/#E205-content https://www.access-board.gov/ict/#E206-hardware https://www.access-board.gov/ict/#E207-software https://www.access-board.gov/ict/#E208-documentation-Services https://www.access-board.gov/ict/#chapter-4-hardware

• Chapter 5 Software

• Chapter 6 Support Documentation and Services

• 302 Functional Performance Criteria

• Electronic content must be accessible to HHS acceptance criteria.

• Accessibility checklists for various formats are available at the HHS site.

• Materials that are final items must be compliant with Section 508 at time of delivery, except upon approval of the Contracting Officer or COR

3.0 Federal Information Technology and Information Management Laws The Contractor must be familiar and comply with applicable Federal information technology an information management laws, regulations, policies, and standards at the Government-wide, HHS, and FDA levels. At the Government-wide level, these include Office of Management and Budget (OMB), National Institute of Standards and Technology (NIST), and General Accounting Office (GAO). These can be primarily found at or through the Federal CIO Council website at: http://www.cio.gov/. Other references are provided in the text below. Current standards and guidelines that must be considered in the performance of this BPA include, but are not limited to, the following.

Applicable standards will also be specified at the Order level.

3.1 The Federal Managers' Financial Integrity Act (FMFIA)

Requires agencies to establish internal control and financial systems that provide reasonable assurance of achieving the three objectives of internal control, which are:

A. Effectiveness and efficiency of operations;

B. Compliance with regulations and applicable laws; and

C. Reliability of financial reporting.

FMFIA requires the agency head to provide an annual Statement of Assurance on whether the agency has met these requirements. The Office of Management and Budget (OMB) Circular A-123, Management’s Responsibility for Internal Control, implements the FMFIA and defines management’s responsibility for internal control in Federal agencies. FMFIA requires agencies to establish internal control over their programs, financial reporting, and financial management systems.

3.2 OMB Circular A-11

Preparation, Submission and Execution of the Budget (current version) is a United States Government circular that addresses budget preparation for Federal agencies and is the primary document that instructs agencies how to prepare and submit budget requests for OMB review and approval.

https://www.access-board.gov/ict/#chapter-5-software https://www.access-board.gov/ict/#chapter-6-support-documentation-and-services https://www.access-board.gov/ict/#302-functional-performance-criteria http://www.cio.gov/

3.3 Federal Continuity Directive 1 (FCD 1)

A directive that applies to all Federal organizations to follow when planning their continuity program. FCD 1 implements requirements and establishes the framework, requirements, and processes that support the development of executive departments and agencies’ continuity programs and by specifying and defining elements of a continuity plan.

3.4 Federal Continuity Directive 2 (FCD 2)

A directive to implement the requirements of FCD-1, Annex B (Essential Functions), and provides direction and guidance to Federal Executive Branch Departments and Agencies (D/As) to assist in validation of Mission Essential Functions (MEFs) and Primary Mission Essential Functions (PMEFs). The update and validation of essential functions includes conducting a comprehensive Business Process Analysis to understand those processes necessary to the performance of organizational functions and requirements.

3.5 Presidential Policy Directive / PPD-8: National Preparedness A directive is aimed at strengthening the security and resilience of the United States through systematic preparation for the threats that pose the greatest risk to the security of the Nation, including acts of terrorism, cyber-attacks, pandemics, and catastrophic natural disasters.

3.6 FDA Enterprise Architecture

A structure that follows the FDA Enterprise Architecture (EA) standards and ensures integration and interoperability. All solutions and services shall meet (EA) policies, standards, and procedures as it relates to this overarching Statement of Work and all associated Orders. All new and refreshed applications must utilize the common FDA technology components that are standardized. All EA-related artifacts shall be maintained in the appropriate FDA repositories, including the OIM Technology Dependencies Inventory (TDI).

3.7 FDA Approved Technologies List

The FDA Product Catalog contains a list of approved and not approved technologies including applications (software), infrastructure and peripherals (hardware), and scientific software and devices.

3.8 FDA Security Authorization Process

Security Authorization is the approach FDA follows to fulfill Federal Information Security Management Act (FISMA), Office of Management and Budget (OMB) and Department of Health and Human Services (HHS) requirements to ensure that information resources have adequate security to protect the Confidentiality, Integrity and Availability of information collected, processed, transmitted, stored, or disseminated by the agency.

For further information see: SP 800-37 Rev. 1: Guide for Applying the Risk Management https://csrc.nist.gov/publications/detail/sp/800-37/rev-1/final

Framework to Federal Information Systems: A Security Life Cycle Approach

3.9 National Institute of Standards and Technology (NIST) SP800-53.

This publication was developed by the Joint Task Force Transformation Initiative Interagency Working Group with representatives from the Civil, Defense, and Intelligence Communities in an ongoing effort to produce a unified information security framework for the Federal Government— including a consistent process for selecting and specifying safeguards and countermeasures (i.e., security controls) for federal information systems. SP 800-53 Rev 4: Recommended Security Controls for Federal Information Systems and Organizations is located at https://csrc.nist.gov/publications/detail/sp/800-53/rev- 4/final.

3.10 Federal Information Security Management Act (FISMA)

Title III of FISMA requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, Contractor, or other source: Federal Information Security Management Act (FISMA).

3.11 The E-Government Act [Public Law 107-347]

Passed by the 107th Congress and signed into law by the President in December 2002 recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act of 2002 (FISMA), included duties and responsibilities for the Computer Security Division in Section 303 of the National Institute of Standards and Technology document: NIST: Computer Security Division - Computer Security Resource Center.

3.12 FDA 3250 series of Staff Manual Guide (SMG)

The FDA Staff Manual Guides (SMGs) are the Agency directives that document organizations and functions; delegations of authority; and administrative and program policies, responsibilities and procedures. FDA 3250 Series of Staff Manual Guide (SMG) can be accessed at:

http://www.fda.gov/aboutfda/reportsmanualsforms/staffmanualguides/default.htm

3.1 FDA Security Program

Defining Contractor Systems and Related Security Requirements - Information Systems is subject to Departmental and Federal requirements are predominantly maintained by Department personnel within HHS facilities; however, there exist a substantial number of Contractor-run systems. This section clarifies security requirements for these Contractor-based systems as well as defines the related roles of Contractors and Departmental personnel.

3.2 Office of Management and Budget (OMB)

https://csrc.nist.gov/publications/detail/sp/800-37/rev-1/final https://csrc.nist.gov/publications/detail/sp/800-37/rev-1/final https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final http://csrc.nist.gov/groups/SMA/fisma/index.html http://csrc.nist.gov/groups/SMA/fisma/index.html http://csrc.nist.gov/index.html http://csrc.nist.gov/index.html http://www.fda.gov/aboutfda/reportsmanualsforms/staffmanualguides/default.htm

The core mission of OMB is to serve the President of the United States in implementing his vision across the Executive Branch. OMB is the largest component of the Executive Office of the President. It reports directly to the President and helps a wide range of executive departments and agencies across the Federal Government to implement the commitments and priorities of the President. As the implementation and enforcement arm of Presidential policy Government-wide, OMB carries out its mission through five critical processes that are essential to the President’s ability to plan and implement his priorities across the Executive Branch.

3.3 FDA’s Project Management (PM)

FDA’s Project Management (PM) processes include a variety of project management methodologies which may be employed in the orders released under this contract including, but not limited to, the Project Management Body of Knowledge (PMBOK).

The Contractor shall update FDA Project Management repositories as required for the applications supported under individual Orders.

3.4 Quality Data standards

Ensures the exchange of information across FDA and with other Federal agencies, offices, and civilian users. The Contractor shall comply with all FDA Data Standards for consistency, standardization, and the FDA Office of Information Management (OIM) Data and Information Standards and Technology (DIST) group’s guidelines. Use HL7 Structured Product Labeling (SPL) standards for Product data. Use Regulated Product Submission Release (RPS) standard. Use existing standard terminologies/vocabularies such as Dun & Bradstreet (e.g., DUNS); ISO (e.g., 3166-1 Alpha-3 Country Code, ISO IDMP); FDA (e.g., UNII, NDC); commercial databases such as MedDRA, Herbs of Commerce (HoC), Personal Care Products Council (PCPC) Cosmetic Ingredient Dictionary; internal CFSAN vocabularies and CAERS verbatim terms; Substance Registration System (SRS). As appropriate, use the common data exchange format (e.g., XML) in exchanging data among IT component(s). Additionally, as regulations and standards are implemented to facilitate higher volume of data and better data quality (e.g., from electronic submissions or queries), FDA will exploit the feasibility of automating and consuming (i.e. acquire, validate, transform, transport, etc.) much of the data directly from input sources, thereby increasing the efficiency and quality of the overall master data environment.

3.5 Data Rights

Established in FAR Clause 52.227-14 (Alternates II, IV, and V), incorporated in this BPA, and governs the parties’ rights in data created in the performance of this BPA. FAR Clause 52.227-14 is applicable, unless an alternate is defined within the individual order.

3.6 Information Technology Investment Management (ITIM)

http://www.fda.gov/ForIndustry/DataStandards/default.htm

FDA has instituted the ITIM process to track technologies across the agency. The introduction of a new technology or a different version of an already approved technology requires the submission and approval of an ITIM request. The Contractor may be responsible for supporting the ITIM process including writing and submitting ITIM requests and tracking them from inception through completion. FDA Center IT Investment Review Boards may need to be included in a coordinated review process.

3.7 Release Management Procedures

As tasked in individual BPA Orders, the Contractor shall provide release management activities. Representative release management tasks include collaborating with ODT database administrators to support the development and deployment of system releases to the appropriate Data Center environments. All software releases will follow the FDA established release management procedures. The following are high-level FDA steps for the software release process for all version upgrades:

A. Determine if ITIM (IT Standards and the IT Investment Management) approval is required.

B. Register planned deployment dates on MARS (Master Application Release Schedule), participate in RMAC (Release Management and Coordination).

C. Create VDD (Version Description Document) for deploying to release.

D. Request CHDC Resources for Pre-Production and Production, Request ICCB (Infrastructure Change Control Board) approval for deployments.

E. Represent RFC(s) (Request for Change) at ICCB meeting.

F. Deliver final “Release Package" to FDA OIM Configuration Management Team, G. Validate successful deployment to target environment.

H. Evaluate all Change Request and Defect candidates for each release to ensure quality and performance standards.

3.8 Configuration Management Procedures

All The Configuration Management (CM) process establishes an orderly and effective procedure for tracking the submission, coordination, review, evaluation, categorization, and approval of all changes to the project’s baselines. All changes shall be tracked and managed using the approved CM Tool. Currently, FDA is using the JIRA CM tool.

3.9 Enterprise Application BPA Scope

The scope of the EAD BPA does not include the Data Center Contract or the Help Desk contract work which are covered until other FDA contracts.