CSS-FD SIR J-2 Security Controls_DRAFT_v2.3_2024-11-15 clean.xlsx

Title Page Federal Aviation Administration (FAA) Common Support Services - Flight Data (CSS-FD) Solicitation #

Attachment J-2: Security Controls

Federal Aviation Administration 800 Independence Avenue, SW Washington, DC 20591

J-2 Security Requirements

Access Control policies must contain purpose, scope, roles, responsibilities, management commitment, and involve related organizational entities to ensure compliance with higher-level requirements.

Procedures must be reviewed and updated annually, or as deemed necessary.

Note 1: The deactivation of accounts (and not removal) is to support the concept of not reusing user account identifiers. Also see IA-04.d.

(1) When accounts are no longer required,

(2) When users are terminated or transferred, and

(1) Have expired;

(2) Are no longer associated with a user or individual;

(3) Are in violation of organizational policy; or

(4) Have been inactive for 90 days.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from implementation of the requirement. However, ICS tailoring and compensating controls must be documented in the SSP.

System Owners must identify and document the security mechanism implemented to monitor user account activity in the SSP under AC-02EN12.ab.

(1) Decrypting the information;

(2) Blocking the flow of the encrypted information; and/or

(3) Terminating communications sessions attempting to pass encrypted information.

Systems must not implement network layer or transport layer encapsulation/encryption for internal inter-facility data or voice traffic, as this circumvents enterprise security controls. If systems require network layer or transport layer encapsulation/encryption services for internal inter-facility data or voice traffic, they must be obtained via enterprise services (e.g., FENS/FTI services and infrastructure) and submitted to the Authorizing Official (AO) for review and approval.

Note 1: This is being required for all systems, including LOW, to be consistent with existing FAA policy.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from this requirement. ICS tailoring and compensating controls must be documented in the SSP.

Note: ICS tailoring does not exempt this requirement for any non-local or remote access.

Definitions:

(1) Local logical access is direct access on a machine or access from one machine to another on the system controlled facility LAN.

(2) Non-local access is across the FAA controlled WAN or other network within the facility not under the control of the system.

(1) Notify System Administrator, or

(2) Lock the account for 15 minutes or until released by an administrator when the maximum number of unsuccessful attempts is exceeded. The control applies regardless of whether the login occurs via a local or network connection.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from (2) - Locking accounts. ICS assets, when technically feasible, must notify System Administrators (1) of 5 failed login attempts within 15 minutes. ICS tailoring and compensating controls must be documented in the SSP.

The banner must be displayed on all systems including but not limited to; all network devices (routers, switches, virtual private network (VPN), etc.), servers, workstations, laptops, tablets, and smartphones.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from this requirement. ICS tailoring and compensating controls must be documented in the SSP.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from this requirement. ICS tailoring and compensating controls must be documented in the SSP.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from this requirement. ICS tailoring and compensating controls must be documented in the SSP.

Note 1: This is being required for all systems, including LOW, to be compliant with DOT/FAA policy.

ICS Tailoring: Local logical access accounts for ICS assets are exempt from this requirement. ICS tailoring and compensating controls must be documented in the SSP.

MC-OE and ME-OE systems must utilize NESG services for external IP based communications in accordance with ATO Order JO 1370.114, per SC-07.a.2.

ATO A-OE systems must use FENS/FTI Remote Access Control (FRAC) for all remote connections.

(1) The authorized privileged functions (e.g., configuring access privileges, setting events to be audited, setting intrusion detection parameters) that can be accessed remotely, and

(2) The rationale for providing remote access to the privileged functions.

List any and all mobile devices in the Hardware/Firmware and Software Tables in the System Characterization Document.

Document in the SSP, under AC-19.b, the following information for each mobile device that is authorized to connect to system assets:

(1) Type of mobile device,

(2) Purpose and use of device,

(3) Authorized information types to be loaded onto the mobile device,

(4) Authorized sources for obtaining information that is loaded onto the mobile device,

(5) Authorized information types to be transferred from the mobile device to system assets,

(6) Authorized applications to run on the mobile device, and

All FAA systems with a connection to an external system must:

1) Identify the external connection in the Authorization documentation and assessment,

2) Have an active MOA,

3) Include the MOA in the Authorization package, and

4) Connect to the FAA network through one of the approved connection gateways.

(1) The FAA must provide System Owners with the proper process and procedures for establishing trust relationships with external systems. A partnering organization of an external system must meet one of the following criteria:

(a) Owns a system component that exists outside of the connecting system’s security authorization boundary.

(b) Operates a component of the system that is outside of its security authorization boundary.

(c) Maintains a component that is outside of the system’s security authorization boundary.

System Owners must document public facing web servers in the System Characterization Document.

Awareness and Training policies must contain purpose, scope, roles, responsibilities, management commitment, and involve related organizational entities to ensure compliance with higher-level requirements.

(1) User obligations and responsibilities for protecting FAA systems and SUI, to include SSI, PII, SPII, SFD, NAS STI, and ATO CAVI.

(2) FAA’s policies on the protection of FAA systems and information.

(3) Potential cybersecurity threats against FAA systems, information, facilities, and personnel.

(4) How to respond when incidents occur.

(5) Privacy concepts and terminology that enables individuals to identify and mitigate risks to the security and protection of PII.

(6) Penalties for violating Agency policy, departmental policy, and/or Federal law.

The FAA must increase Security and Privacy awareness of system users using the following techniques: displaying posters, displaying logon screen messages, generating email advisories or notices from organizational officials, and conducting awareness events.

The FAA must update literacy training and awareness content annually or when there are significant changes in the security environment. Lessons learned from internal or external security or privacy incidents must be incorporated into literacy training and awareness techniques.

Note: This incorporates the requirements of AT-02EN02.

(1) Define and communicate the process for identifying Cybersecurity Personnel requiring role-based training.

(2) Describe how identified Cybersecurity Personnel satisfy and submit their role-based training completion information (e.g., completion certificate, semester transcripts, authoritative acknowledgement that training was completed, etc.).

(3) Ensure that Cybersecurity specialized role-based training is commensurate with the individual's Cybersecurity and Privacy responsibilities.

ASH must track and record the completion of Security Awareness Virtual Initiative (SAVI) training for employees and contractors.

ASH must retain Security Awareness Virtual Initiative (SAVI) training completion records for three years for employees and contractors.

Audit and Accountability policies must contain purpose, scope, roles, responsibilities, management commitment, and involve related organizational entities to ensure compliance with higher-level requirements.

(1) Resource degradation alerts (e.g., 100% utilization, disk space full, volume full),

(2) Login and logout, successful and unsuccessful,

(3) Account creation/modification and permissions or configuration changes,

(4) Administrator level activities,

(5) Startup/Shutdown of System/Services/processes,

(6) Access to privileged functions (e.g., setting auditable event and intrusion detection devices) including maintenance,

(7) Results from malicious code protection (as capable),

(8) Access control list denials (as capable), and

(9) IDS signature based attacks (as capable).

OPIP network connected assets must send generated audit logs to the NAS Cyber Management System (NCMS) enterprise service.

System Owners of assets that are not connected to any shared LAN/WAN environment must document the specific assets for which the requirement cannot be satisfied.

Note: This incorporates the auditing requirements from AC-02.g, AC-06EN09, AU-02.c, AU-12.c, and MA-04EN01.a.

System Owners of MC-OE and ME-OE assets that are not connected to any shared LAN/WAN environment may be given relief from this requirement, but must document the specific assets for which the requirement cannot be satisfied.

System Owners of MC-OE and ME-OE assets that are not connected to any shared LAN/WAN environment must document rationale for deviating from these requirements in the SSP.

OPIP network connected Systems must send generated audit logs to the NCMS enterprise service for storage. The NCMS must allocate sufficient storage capacity to store 14 days of security-relevant audit records in online storage.

Systems must configure the system auditing capacity to reduce the likelihood of audit record storage capacity being exceeded (e.g., provide 25% capacity above estimated need).

(1) The centralized audit service provider (NCMS),

(2) The System Operations Center (SOC), or

(3) System Administrator.

(1) When there is a failure in the system event generation /audit capturing mechanism; the system administrator must perform a controlled restart of the system or a controlled restart of the auditing mechanism.

(a) If the system event generation/audit capture function is not available, the controlled restart should occur manually when the next maintenance window becomes available.

All system assets (MC-OE, ME-OE, A-OE and Service Provider's assets) must provide audit record warning notifications in accordance with defined thresholds. Systems must implement at least three levels of warning notifications (e.g., 50%, 75%, 90%).

MC-OE and ME-OE systems onboarded to NCMS, must generate and send a real-time alert to the NCO when the audit events are no longer being captured. System Owners must identify and document the maximum latency in reporting audit failure events.

MC-OE and ME-OE systems that are not NCMS onboarded must provide a notification within one hour to the NCO when audit records are no longer captured.

Administrative Operating Environment

System Owners of OPIP network connected assets must send generated audit logs to the NCMS enterprise service to support these reviews.

MC-OE and ME-OE Service Providers must review audit log/records at least weekly, review on an ad hoc basis when requested by the NCO, and review whenever there is an indication of inappropriate or unusual activity, unusual or suspicious activity/behavior; security incidents; policy violations; fraudulent activity; and operational problems.

System Owners of MC-OE and ME-OE assets that are not connected to any shared LAN/WAN environment must document rationale for deviating from these requirements in the SSP.

MC-OE and ME-OE Service Providers must generate audit logs and perform automated audit reviews, analyses, and reporting to support investigation and response to suspicious activities.

System Owners of MC-OE and ME-OE assets that are not connected to any shared LAN/WAN environment must document rationale for deviating from this requirement in the SSP.

System Owners of assets connected to the Mission Support network must employ Microsoft Endpoint Detection and Response (EDR) solution to integrate audit review, analysis, and reporting processes to investigate and respond to suspicious activities. Use of a centralized auditing service must be documented in the SSP under AU-06EN01.

A-OE systems must rely on the FAA SOC for monitoring in conjunction with System Owners and Administrative Operating Environment centralized auditing services.

MC-OE and ME-OE Service Providers must provide an audit reduction and report generation capability that supports the NCO's role of on-demand audit review. analysis, and reporting including after-the-fact investigations of security incidents.

System Owners of assets that are not connected to any shared LAN/WAN environment must document rationale for deviating from these requirements in the SSP.

MC-OE and ME-OE Service Providers must provide the capability to process audit records for events of interest in support of NCO security responsibilities.

Non-OPIP network connected assets must provide the capability to process audit records for events of interest upon request.

(1) Protect audit information and audit tools from unauthorized access, modification, and deletion by restricting access privileges to individuals who are responsible for performing auditing functions.

All MC-OE and ME-OE FIPS 199 HIGH impact OPIP connected systems must send audit records to NCMS, which retains backup system audit files.

System Owners must identify and document in the SSP under AU-09EN02, the specific storage asset used to retain copies of audit records to ensure a physically different system asset is used.

All A-OE FIPS 199 HIGH impact systems must send audit records to a centralized audit collection service. Document in the SSP under AU-09EN02 the centralized audit service provider.

Audit record backup frequency must be documented and occur at least once per 24 hour period.

All MC-OE and ME-OE FIPS 199 HIGH impact systems not connected to the OPIP infrastructure are exempt from sending audit records to the NCMS, but must satisfy all other requirements. Document the exemption in the SSP under AU-09EN02.

All FIPS 199 HIGH security categorized systems must encrypt stored audit records.

Hybrid Common: CSS-FD will rely on Cloud provider provided cryptographic mechanisms to ensure confidentiality of data-at-rest. CSS-FD will rely on the Cloud provider as a Common control to ensure that cryptographic mechanisms meet FIPS 140-2 requirements.

System Specific: CSS-FD will configure its…