RFI-2024-001_BWC.pdf
PDF 279 KB Posted
- Attached to
- Body Worn Cameras
- Solicitation number
- RFI-2024-001
- Issued by
-
Department of Justice Bureau of Prisons
About this file
This document is a Request for Information (RFI) issued by the Federal Bureau of Prisons (FBOP) for a Body Worn Camera (BWC) Pilot Program. The FBOP is seeking contractor assistance to implement a pilot program consisting of approximately 260 body-worn cameras for four positions/posts at a designated facility. In addition to the BWCs, the FBOP requires contractor service and support to ingest, manage, and share the captured BWC video/audio events.
The RFI outlines detailed technical requirements for the BWCs, including hardware specifications, storage capabilities, compliance with FedRAMP, and requirements for privacy and FOIA considerations. It also details the IT requirements for the overall solution, including operating systems, databases, security, cloud services, and assessment and authorization processes. The RFI does not request proposals, but seeks vendor information to help refine the FBOP's specifications for a future solicitation. Vendors are instructed to provide cost estimates for a typical installation based on the requirements provided.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| BWC RFI Vendor Response Form 2 Final.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
FBOP, ITDD
Body Worn Camera RFI for FBOP
8-1-2024
TABLE OF CONTENTS
1.0 Background
2.0 Purpose & Scope
3.0 Requirements
3.1 Hardware
3.2 Storage
3.4 FedRAMP Compliance
3.5 Privacy Act and FOIA Requirements
3.6 System Standards Compliance ................................................ Error! Bookmark not defined.
4.0 Vendor Profile ................................................................................... Error! Bookmark not defined.
4.1 Market Data .............................................................................. Error! Bookmark not defined.
4.2 Product Information .................................................................. Error! Bookmark not defined.
4.3 Licensing .................................................................................. Error! Bookmark not defined.
5.0 Assumed Milestone/Phases for initiative
6.0 IT Requirements
6.1 APPLICABILITY
6.2 OPERATING SYSTEMS, DATABASES, AND APPLICATIONS
6.3 SECURITY ASSESSMENT AND AUTHORIZATION COMPLIANCE
6.4 PRIVACY AND RECORDS MANAGEMENT
6.5 SYSTEM INTERCONNECTIONS
7.0 Cost Breakdown
8.0 Disclaimer
1.0 Background
The FBOP is responsible for the custody and care of approximately 156,000 Federal offenders. Approximately 91 percent of these inmates are confined in Bureau-operated facilities, while the balance is confined in community-based facilities. More information about the agency can be found on the Federal Bureau of Prisons’ public site, www.bop.gov.
2.0 Purpose & Scope
The Federal Bureau of Prisons (FBOP or Bureau) is seeking to initiate a Body Worn Camera (BWC) Pilot Program at a designated facility which houses Adults in Custody. The technology will be leveraged to provide accountability and transparency for staff actions, provide support in the investigation of inmate allegations, and increase training and procedural adherence to agency policy. The FBOP is seeking contractor assistance to implement a pilot program consisting of approximately 260 body-worn cameras for four positions/posts at the designated facility during the pilot. In addition to the BWCs, the FBOP will also need contractor service and support to ingest, manage, and share the captured BWC video/audio events.
3.0 Requirements
3.1 Hardware
BWCs will be used as audio and video recording devices equipped to users as part of their uniform to document what they see and hear in the performance of their duties when interacting with federal inmates.
3.1.1 The BWC should meet the following design specifications:
a. The camera hardware should be Black in color.
b. The audio and video capture and imaging should be from the user’s point of view.
c. The solution should provide multiple mounting options to accommodate varying uniforms. Example mountpoints include, but are not limited to lapel, shoulder, helmet, button shirt, zipper jacket, duty belt, etc.
d. The BWC should be rain, wind, dust, and fluid resistant with an Ingress Protection (IP) rating of at least IP67.
e. The BWC should be able to operate in temperatures ranging from -4 F to 120 F.
f. The BWC lens should be scratch resistant, and the device should be capable of operating after a 6-foot drop.
g. The BWC solution should provide ease of operation to power activate/deactivate and be able to record activate/deactivate as needed with a single switch/button.
h. The solution should include the ability to charge the BWC in a docking station.
i. The solution should provide the capability to alert all BWCs within a visual or audible range when a single BWC begins recording and provide the option to turn on those co-located BWCs.
j. The solution should provide the capability to allow designated personnel to activate all BWCs in the event of an emergency.
3.1.2 Required BWC Minimum Operation Specifications:
a. Provides a minimum 120-degree field of view.
b. Records full color video at a resolution of at least 720p using H.264 codec.
c. Records at a minimum of 30 frames per second (FPS).
d. Audio recording capability of 44.1kHz.
e. Includes low light capabilities and auto white balance and auto exposure.
f. Includes minimum internal/integrated memory of at least 16GB.
g. Provides minimum of 30 seconds pre-event recording configurable up to 2 minutes.
h. User should have the capability to view, categorize and/or annotate the recorded video on-scene.
i. Battery life should provide an initial standby capability of 12 hours without recharging or the need for additional batteries.
j. Provides minimum of five (5) hours of continuous record time after the BWC has been fully charged.
k. Capability to recharge device to full capacity in less than 8 hours.
l. Capability to provide technology utilization metrics such as camera activation rates and usage in accordance with defined specifications to facilitate implementation assessment.
m. Cameras include a five (5) year manufacturer warranty.
3.2 Storage
The solution should provide the FBOP with the capability to store, manage, share, redact, protect and dispose of digital evidence, most typically in the form of video, photo and audio records. The FBOP requires that this capability be provided as a cloud-based solution, consistent with federal cloud strategies. The FBOP prefers that said cloud-based solution be in the form of a Software-as-a-Solution (SaaS). SaaS is a software distribution model in which the application is hosted, by a vendor or service provider, and made available to customers over a network, typically the internet. If the vendor offers a SaaS solution, the FBOP will expect to purchase licenses and support to utilize the software. Any cloud-based solution that is proposed (whether as an infrastructure, platform, or SaaS solution) must receive or have FedRAMP Authorization with an Authority to Operate (ATO) capability for impact level Moderate or High systems.
The solution should be capable of storing content (recordings and applicable metadata) in the cloud for at least 30 days or longer to satisfy FBOP records retention requirements. The information provided should represent best practices for data management and storage on the vendor’s system, for the purpose of effectively managing available storage and mitigating additional charges for storage to the extent possible.
3.3 FedRAMP Compliance
The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. The proposed solution must obtain or be at least FedRAMP Moderate compliant as a cloud service provider (CSP). A FedRAMP and FBOP-compliant Authority to Operate (ATO) are required by FBOP prior to the solution going into production.
3.4 Privacy Act and FOIA Requirements
Provide an integrated module (or functionality) for specified personnel to manipulate media files for editing or redaction purposes, with the ability to:
1. Delete portions or periods of audio or video content.
2. Blur portions or periods of video content with tagging indicating FOIA exemption.
3. Crop audio or video.
4. Scramble or redact portions of audio content.
5. Automatically track and redact faces and other objects in video so as to eliminate need to perform manual frame-by-frame redaction.
6. Export files in raw H.264 format (e.g., to Adobe Photoshop and Premier).
3.4.1 Legal and FOIA release of records:
Alterations should be captured within the system’s action or audit records and be able to be provided to the requesting entity.
3.4.2 Additional Requirements
1. Can quickly be deployed to multiple institutions throughout the United States, including Hawaii and Puerto Rico.
2. Original and altered files from the solution should have evidentiary value in federal court. A solution that has historically proven the ability to adequately secure video files for inclusion as reliable evidence in court will be given strong preference.
3.4.3 Policy Notes
Vendor personnel accessing any recordings may not delete, alter, release, or redact, in part or in whole, any recording without legal (Court/U.S. Attorney’s Office) or administrative authority (valid Freedom of Information Act (FOIA) request through the FOIA office) to do so.
3.4.4 Legal Release
All recordings may be altered, redacted and released with the guidance and constraints of an applicable federal judicial court entity. (NOTE: steps must be taken to ensure the integrity of the original recording.)
Alterations should be captured within the system’s action or audit records and be able to be provided to the requesting Court entity.
4.0 Assumed Milestone/Phases for initiative
Phase 1: Program Management Requirements definition
Phase 2: Procurement & Distribution
Phase 3: Training
Phase 4: Commence Pilot/ Closeout
5.0 IT Requirements
5.1 APPLICABILITY
All information systems deployed within the FBOP, or on behalf of FBOP to include contractor built and operated on-prem, private cloud systems, or government cloud, will be developed to include support for the standards detailed in this section to the greatest extent possible regardless of whether the system is connected to the FBOP's administrative network (BOPNet). All systems will be evaluated prior to acquisition and/or deployment to determine that each system supports the technical standards contained in this section.
Approval to connect to BOPNet will not be granted to any system that cannot support these standards unless a waiver has been granted by the CIO.
Additionally, all systems will acquire an Authority to Operate (ATO) prior to use, and an Authority to Test (ATT) prior to system testing. Testing will not leverage live data (must use data created for the sole purpose of verifying functional capability and contain neither FBOP nor FBOP user information). A pilot, if needed, will also be performed without the use of live data. All the system environments, including development, test, quality assurance, integration, production, and any other environment related to the system, and reside within the authorization boundary.
5.2 OPERATING SYSTEMS, DATABASES, AND APPLICATIONS
5.2.1 OPERATING SYSTEMS AND DATABASES
All systems should be developed to use FBOP standard workstations, laptops, and servers with versions of operating systems and databases that are supported by the OS/database manufacturer/developer and will continue to be supported by the manufacturer/developer for at least three years after the FBOP system goes live. Any system that will rely on an operating system and/or database that is no longer supported or will be approaching its end-of-life or the end of extended support date before the contract expires, is prohibited from being installed unless a waiver is granted by the CIO.
All devices should have Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) Category I and Category II settings applied, if applicable.
Workstations and laptops with Windows operating systems should have DISA STIG settings applied for the versions of Windows currently in standard use in the FBOP. Servers, workstations, laptops, and other devices running non-Windows operating systems must be approved for use by the FBOP CIO prior to acquisition and must be the latest supported versions by the vendor. If a DISA STIG exists for any non-Windows operating system, the operating system must be configured in accordance with that DISA STIG.
5.2.2 APPLICATIONS
All systems on the FBOP network should be capable of using a FBOP standard image for workstations. Systems should be developed to minimize the installation of new applications directly onto workstations. Systems that require a client application be installed on workstations are strongly discouraged.
Web-based applications will be installed on standard FBOP servers running FBOP-approved server operating systems and meet the following requirements:
Support TLS (non-deprecated version);
Be browser-agnostic;
Not require browser plug-ins, helper objects, specific ActiveX controls, or Java dependencies on the client.
All applications should be able to operate with the latest version of any supporting applications or services required to run that application (i.e., Java, Apache, IIS, etc.).
5.2.3 AUDITING/LOGGING
All operating systems and/or applications should be capable of auditing events and maintaining logs with sufficient information to be able to account for the actions of individual users and record system events and processes.
5.2.4 IDENTIFICATION, AUTHENTICATION, AND AUTHORIZATION
To comply with Homeland Security Presidential Directive 12 (HSPD-12), all information systems will use a centralized directory for identification, authentication, and authorization to control, provision, and de-provision access to those systems. To connect to the FBOP network, all information systems should be capable of supporting Lightweight Directory Access Protocol (LDAP v3 or successor).
Systems that cannot support either a FBOP directory service or DOJ federated service and require the management of a separate credential store for identification, authentication, and authorization are prohibited.
Each system user will be uniquely identified. Access to information is controlled using a “Least Privilege” role- or assignment-based methodology that provides the user with only the information and access required to perform his/her duties and nothing more. Systems should be capable of tiered-role privileges that distinguish between users and administrators and their authorized functions.
The federal government has implemented a Zero Trust security model to enforce least privilege per-request access decisions in information systems and services. Therefore, authentication to the system will be facilitated via the use of multi-factor authentication and access to the data controlled via role-based access.
5.2.5 ENCRYPTION
6.2.5.1DATA AT REST
All information systems that store data should have the capability to encrypt the drives on which the data is stored using FIPS 140-2 compliant encryption. If the system cannot support encryption of system drives, it must be approved for use by the FBOP CIO prior to acquisition and use.
5.2.5.2 DATA IN MOTION
All information systems that transmit data over the FBOP network will use protocols that encrypt data as it traverses the network. Information systems must support the most current version of secure protocols and encryption standards and must be capable of being configured to prevent the use of non-secure protocols.
5.2.5.3 PUBLIC FACING WEBSITES
Any information system that hosts a publicly accessible website and web services must only provide service through a secure connection (HTTPS) and must use HTTP Strict Transport Security (HSTS) to ensure this connection.
5.2.6 NETWORK STANDARDS AND PROTOCOLS
6.2.6.1 NETWORK STANDARDS AND APPROVED PROTOCOLS
Information systems must meet the following network standards to be deployed on the FBOP network:
Supports IPv4/v6 Dual Stack and provides full and equal functionality when utilizing IPv6 as when using IPv4;
Does not require or enable wireless of any type (Wi-Fi, Bluetooth, 3G/4G, etc.) unless an exception is granted by the FBOP CIO and is implemented per FBOP and DOJ guidelines;
All physical devices that make up the system must have a single network connection, only one IPv4 address, one Globally Unique IPv6 address, and not be capable of routing;
If internet accessible, can transmit traffic thru a proxy server to access the internet;
Does not require direct inbound connections from the public internet;
Does not allow out-of-band access (no modems, etc.);
Does not require media converters;
Does not directly connect to other IP networks;
Does not use IPv4 Multicast;
Cabling is IEEE Gigabit standard compliant;
Power over Ethernet (POE) devices are IEEE 802.3af compliant;
Cannot act (or is disabled from acting) as a DHCP server.
5.2.6.2 NON-SECURE PROTOCOLS
In accordance with current NIST standards, non-secure protocols will be disabled and not planned for use. The information system should have the capability of disabling any non-secure protocols including, but not limited to, the protocols listed below:
Telnet
FTP
SNMP v1/2
HTTP
5.2.7 CLOUD SERVICES
Any system that will connect to or be hosted in a non-FBOP cloud service will use cloud service providers (CSP) that have been independently evaluated by an authorized FedRAMP
3PAO (Third Party Assessment Organization) and are FedRAMP-certified. The CSP must provide the most current System Security Plan (SSP), Control Implementation Summary (CIS), Customer Responsibility Matrix (CRM), Security Assessment Report (SAR), and list of any open Plans of Actions and Milestones (POAMs) to the FBOP Chief Information Security Officer (CISO) for consideration. The CSP is required to receive an ATO from the FBOP Authorizing Official (AO) prior to use.
5.2.7.1 CLOUD APPLICATIONS – REQUIREMENTS FOR COTS AND CUSTOM DEVELOPED
Contractors should develop or provide administration and user guides for applications, whether the application is custom developed for the FBOP or is a Commercial Off the Shelf (COTS) product.
All applications will adhere to Section 508 accessibility standards.
5.2.7.2 CLOUD APPLICATIONS – CUSTOM DEVELOPED
The FBOP owns any and all source code generated for applications custom developed for the FBOP. The source code for any application custom developed for the FBOP will be delivered to the FBOP before the contract expires.
Use of an Agile development strategy (or similar strategy) to enable rapid development with routine opportunities for stakeholders to review progress and provide feedback during the development process is preferred.
Applications should adhere to usability principles, plain language, and industry best practices.
Applications should interface with the FBOP's IdP using SAML2.0 or OAuth 2.0 to appropriately authenticate users and protect sensitive resources.
Application data will be made available via webservices that are built using REST APIs, with endpoints appropriately protected.
Applications intended for deployment in the FBOP’s cloud environment should either be hosted in AWS GovCloud West or AWS GovCloud East, depending on the FISMA classification of the information contained in the system.
Identify exact cloud services and resources (i.e., Lambda, RDS types, EC2 instance types, etc.) that will be required to build the system and use the AWS cost estimation tool to provide a breakdown of the anticipated system cost.
Contractors should make necessary changes to the application, configuration, or cloud infrastructure/services script (i.e., IaC) if required by the FBOP cloud team.
Contractors should create CloudFormation scripts that will be used to build the Virtual Private Clouds (VPC) and infrastructure needed, and make necessary changes as identified by the FBOP cloud team.
Any exceptions to the above statements will be reviewed and approved by FBOP IT Leadership, and under no circumstances will any deviation from these statements that adversely affects the security of the FBOP IT environment or data be permitted.
5.2.7.3 MOBILE APPLICATIONS
Mobile applications should be designed using HTML5 or operate natively on a version of the Android operating system currently being supported by industry with security patches.
5.3 SECURITY ASSESSMENT AND AUTHORIZATION COMPLIANCE
The FBOP will conduct an Assessment & Authorization (A&A) of the system before the Chief Information Officer’s office issues an Authority to Operate (ATO) on the system.
Government project officers are responsible for ensuring their contractor-hosted or cloud-hosted applications are authorized to operate (ATO) in accordance with the Federal Information Security Modernization Act of 2014 (FISMA). This activity includes all planning, testing, and continuous monitoring activities associated with the system’s lifecycle. Most importantly, this means that the vendor is responsible for securing the resources to conduct required security testing, which for moderate or higher impact systems means using an independent third-party assessor qualified to conduct FISMA/FedRAMP audits.
The FBOP will not develop required FISMA/FedRAMP security documentation (except for assisting with the FIPS-199, e-Authentication, and Privacy Impact Assessment), or conduct any of the security testing for applications that are operated exclusively at contractor locations or hosted in the cloud. The extent of FBOP’s support for exclusively contractor-and cloud-hosted systems is advisory only.
A&A is the methodology by which an organization establishes and then demonstrates a sound, risk-based security posture for a specific system. The A&A process establishes the extent to which a particular design and implementation meet a set of specified security requirements defined by the organization, government guidelines, and federal mandates into a formal authorization package. This authorization package is reviewed by the Authorizing Official (AO) and a formal declaration of an information system accreditation is either granted as an Authorization to Operate (ATO) or ATO with conditions or outright denial of authorization to operate. For more information about A&A requirements for federal IT systems, please see NIST SP 800-37 Rev 2 (https://csrc.nist.gov/pubs/sp/800/37/r2/final).
When this assessment is conducted, the vendor may be required to answer questions, to participate in the A&A process and potentially implement any information security changes necessary to facilitate receiving an ATO for this system. The system is required to meet or exceed specific and relevant security requirements identified and detailed in the Security and Privacy Requirements documentation.
Where a follow-up action against a person or the FBOP after an incident involves legal action (either civil or criminal), the system should ensure that evidence can be collected, retained, and presented to conform to the rules for evidence in accordance with Federal rules of civil or criminal procedures.
The system and any/all electronic and information technology procured through this effort will be compliant with 29 U.S.C § 794d - Electronic and information technology (Section 508 compliance Amendment to the Rehabilitation Act of 1973) and the applicable accessibility standards at 36 CFR 1194. 36 CFR 1194 implements Section 508 of the Rehabilitation Act of 1973, as amended, and is viewable at https://www.section508.gov/.
Standards applicable to this requirement include Functional Performance criteria 1194.31 and Information, Documentation, and Support 1194.41.
Because of the above requirements, the contractor would be required to include Information Systems Security Officer (ISSO) resources as part of a future proposal to assist in the development of documentation for the ATO process. Such personnel should be experienced and familiar with writing control implementation statements so that security controls can be appropriately and promptly assessed. The length of the ATO process is dependent on the outcome of the quantity and quality of resources proposed for the solution.
5.4 PRIVACY AND RECORDS MANAGEMENT
All systems will be evaluated prior to ATT or ATO for privacy and records management requirements. An Initial Privacy Assessment (IPA) will be completed and if FBOP Privacy and Records Management Branch, and DOJ Office of Privacy and Civil Liberties (OPCL) determines that the system collects, processes, stores or disseminates personally identifiable information (PII), a Privacy Impact Assessment (PIA) will be done to evaluate the impact on the confidentiality, integrity, and availability of the system data. If required, the FBOP Office of General Counsel (OGC) will prepare a System of Records Notice (SORN) to be published in the federal register prior to system’s deployment. All systems will complete a Records and Information Management Certification (RIMCert) evaluation regardless of Personally Identifiable Information (PII) status.
Contractor should be aware, for planning purposes, that the current FBOP ATO process can take 6 to 18 months to complete. The length of this time is dependent on the outcome of the IPA for the system.
5.5 SYSTEM INTERCONNECTIONS
DOJ requires that Components identify all system interconnections, both external and internal to DOJ. A system interconnection is defined as the direct connection of two or more IT systems for the purpose of sharing data and other information resources. All interconnections from one information system to another system outside of the respective accreditation boundaries must have an approved Interconnection Security Agreement (ISA), and optionally a Memorandum of Understanding/Agreements (MOU/A). Both parties will mutually agree on terms and conditions and define expiration requirements or timelines. The agreements define how security will be maintained for the interconnection during its operation. Information systems are only permitted to interconnect with systems that have undergone a system authorization and have a current Authorization to Operate (ATO). If the Authorizing Official (AO) is the same for both interconnecting systems, an ISA or MOU/A is not required.
All contractors are required to comply with DOJ/FBOP background clearance requirements before being permitted to do any work under a FBOP contract. Contractors working remotely for the FBOP will be issued contractor user accounts and PIV cards. Contractors will be required to use government furnished equipment (computers) to access the FBOP network. To prevent loss of FBOP data, all email communications between contractor personnel and FBOP personnel must be conducted using the FBOP’s email system.
6.0 Request for Information Response
For each proposed product, provide cost estimates based upon a typical installation. To allow for seamless comparison of the responses, assume that the product is going to be used at the specified site. Also, any additional details regarding cost or pricing that may be helpful in our analysis should be included as well.
One-time fees
One time implementation fees:
Training fees:
Equipment fes:
Consulting fees:
Software fees
Please use the attached template (BWC RFI Vendor Response Form) to submit your responses as a separate document within the RFI response.
7.0 Disclaimer
The Bureau may continue conducting market research by scheduling an onsite, follow-up demonstration at the Bureau’s headquarters located in Washington D.C. of proposed solutions by select vendors to provide more detailed information and display functionality and/or methodology. If web/virtual conferencing is used for a remote demonstration, the following solutions would be supported: Cisco WebEx, and Microsoft Teams to be organized by FBOP employees only. Include specification sheets and product literature in the responsive materials. Interested parties shall not be reimbursed for any costs related to the development and submission of information in response to this RFI.
Be advised that providing responses to the RFI will not automatically include the vendor in acquisition planning. Information provided by responsive vendors will be used to further refine the Bureau’s specifications for any eventual solicitation for such tools and services.
This RFI is issued solely for information and planning purposes and does not constitute a Request for Quote (RFQ) or a promise to issue an RFQ in the future. This RFI does not commit the Government to contract for any supply or service whatsoever.
Further, the Bureau is not, at this time, seeking proposals and will not accept unsolicited proposals. A response to this notice is not an offer and cannot be accepted by the government to form a binding contract. Respondents are advised that the U.S. Government will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested vendor's expense. Responses to this RFI will not be returned. All information received will be for internal use within the Bureau and will not be published. However, not responding to this RFI does not preclude participation in any future RFQ, if any is issued.
In addition, this RFI is intended solely for the use to improve communications between potential contractors and the Bureau. If for some reason, the responses are requested by outside parties (i.e. FOIA request); the information is not protected as source selection information (FAR 2.101 and 3.104). If you intend for the information to be exempt from disclosure under FOIA Exemption 4, indicate this in your response and on each page you want to be exempt. Furthermore, indicate that your response is proprietary information that may not be used, reproduced, or disclosed to any other parties for any purpose without the expressed written permission of (Provide individual name and title).
Product maintenance/repair fee
| 1.0 Background |
| 2.0 Purpose & Scope |
| 3.0 Requirements |
| 3.1 Hardware |
| 3.1.1 The BWC should meet the following design specifications: |
| 3.1.2 Required BWC Minimum Operation Specifications: |
| 3.2 Storage |
| 3.3 FedRAMP Compliance |
| 3.4 Privacy Act and FOIA Requirements |
| 3.4.1 Legal and FOIA release of records: |
| 3.4.2 Additional Requirements |
| 3.4.3 Policy Notes |
| 3.4.4 Legal Release |
| 4.0 Assumed Milestone/Phases for initiative |
| 5.0 IT Requirements |
| 5.1 APPLICABILITY |
| 5.2 OPERATING SYSTEMS, DATABASES, AND APPLICATIONS |
| 5.2.1 OPERATING SYSTEMS AND DATABASES |
| 5.2.2 APPLICATIONS |
| 5.2.3 AUDITING/LOGGING |
| 5.2.4 IDENTIFICATION, AUTHENTICATION, AND AUTHORIZATION |
| 5.2.5 ENCRYPTION |
| 6.2.5.1DATA AT REST |
| 5.2.5.2 DATA IN MOTION |
| 5.2.5.3 PUBLIC FACING WEBSITES |
| 5.2.6 NETWORK STANDARDS AND PROTOCOLS |
| 6.2.6.1 NETWORK STANDARDS AND APPROVED PROTOCOLS |
| 5.2.6.2 NON-SECURE PROTOCOLS |
| 5.2.7 CLOUD SERVICES |
| 5.2.7.1 CLOUD APPLICATIONS – REQUIREMENTS FOR COTS AND CUSTOM DEVELOPED |
| 5.2.7.2 CLOUD APPLICATIONS – CUSTOM DEVELOPED |
| 5.2.7.3 MOBILE APPLICATIONS |
| 5.3 SECURITY ASSESSMENT AND AUTHORIZATION COMPLIANCE |
| 5.4 PRIVACY AND RECORDS MANAGEMENT |
| 5.5 SYSTEM INTERCONNECTIONS |
| 6.0 Request for Information Response |
| 7.0 Disclaimer |
File details come from the government source that posted it. Updated .