DRAFT SIR CSS-FD Attachment J-2.pdf

ATO Rev5 Ctl No.

ATO Rev5 Language

AC-01.abc.2 System Owners must develop Access Control procedures in accordance with the ATO ISS Procedures Guidance, laws, executive orders and directives, and ensure that the procedures are implemented by the system personnel that are assigned functional responsibilities for Access Control. System Owners must designate a representative(s) to manage development, documentation, and dissemination of the procedures.

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

Note: This incorporates the requirements of IA-04.a.1 and IA-04.bc.

AC-02.a.1 System Owners must identify and document in the SSP under AC-02.a, all OPERATING SYSTEM (including network device IOSs) account types (e.g., user, privileged user, individual, shared, guest/anonymous, and temporary) for all system assets.

AC-02.a.2 System Owners must identify and document in the SSP under AC-02.a, all APPLICATION account types permitted and specifically prohibited (e.g., user, privileged user, individual, shared/group, application-to-application, web app-to-database, web app user-to-web application, guest/anonymous, and temporary) for all system assets.

AC-02.b System Owners must document in the SSP under AC-02.b, personnel responsible for system account management. Document how accounts are managed,(e.g., system wide, by site installation, and/or by asset).

AC-02.c System Owners must document in the SSP under AC-02.c, accounts and account types that are managed by group membership, including privileges associated with each group.

Shared accounts used by Applications must be identified and documented. Shared accounts used by Operating Systems (OS and IOS) must be identified and documented.

AC-02.d.1 System Owners and Managers must document in the SSP under AC-02.d, the access privileges associated with each account type (identified in AC-02.a.1 and AC-02.a.2).

AC-02.d.2 System Account Managers must maintain a list of users for each account type for the system (Operating System and Application) and be capable of generating authorized user lists upon demand.

AC-02.e System account management procedures, documented in AC-01.abc.2, must include the process and responsibilities for requesting and approving account creation.

Note: This incorporates the requirements of IA-04.a.1.

AC-02.f System account managers must manage accounts by creating, enabling, activating, modifying, and deactivating account privileges, identifiers, and authenticators in accordance with system procedures.

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.

Note 2: This incorporates the requirements of IA-04.bc.

AC-02.h System account management procedures, documented in AC-01.abc.2, must include the process and responsibilities for notifying account managers:

(1) When accounts are no longer required,

(2) When users are terminated or transferred, and

(3) When individual system usage or need-to-know changes.

AC-02.i System Owners must document in the SSP under AC-02.i, or reference the specific procedure sections, that describe the criteria for granting access to the system based upon a valid need-to-know/need-to-share, as determined by assigned official duties and all personnel security criteria, and the intended system usage.

AC-02.j System Account Managers must review system level user accounts (Operating System and Application) annually and privileged user accounts semi-annually, and must initiate required actions (e.g., deactivate, change access rights/privileges) based upon the review.

System account procedures, documented in AC-01.abc.2, must include process and responsibilities for reviewing system accounts.

AC-02.k System Owner documented procedures, defined in AC-01.abc.2, must include procedures for reissuing shared/group account credentials when individuals are removed from the group.

AC-02.l System Owners must document in the SSP under AC-02.I how account management processes are incorporated into personnel termination and transfer processes.

AC-02EN01.1 System Owners must document in the SSP under AC-02EN01 which account management functions are performed via automated mechanisms, which automation mechanisms are used (e.g., Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Terminal Access Controller Access-Control System (TACACS), etc.) and how these tools support the management of system accounts.

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.

AC-02EN01.2 System Owners must employ automated mechanisms (e.g., AD, TACACS, LDAP) to support the management (e.g., establishing, activating, modifying, deactivating, reviewing, and monitoring accounts; expiring unused accounts) of system accounts.

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.

AC-02EN02 Systems must automatically disable or remove temporary and emergency user accounts within 24 hours after the need for the account is no longer valid.

AC-02EN03 Systems must automatically disable user accounts (Operating System and Application) after 90 days that:

(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.

Note: This is being required for all systems, including LOW, to be compliant with the requirements of IA-04.e.

AC-02EN05 Users must log out when departing from the immediate area of the workstation, server, or networking device or assets.

Users of MC-OE and ME-OE operational ICS assets, as defined in IA-02.2, are exempt from this requirement.

AC-02EN11 System Owners must identify and document in the SSP under AC-02EN11, usage restrictions for different user types, and ensure that systems implement usage restrictions as defined. For example, restricting usage to certain days of the week or time of day, for specific durations of time.

AC-

02EN12.ab

Systems must provide monitoring of user account activity to include atypical usage in accordance with requirements of AU-02.a.1, and review of user activity in accordance with AU-06.a.1. Reporting of atypical user activity must be in accordance with IR-06.a.

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

Note: Monitoring at the system level is required in addition to centralized monitoring by the NAS Cyber Operations (NCO) group and/or FAA Security Operations Center (SOC), or other entity.

AC-02EN13 System Owner/Administrator must disable user accounts within two (2) hours of discovery of individuals who pose a high level of risk to the FAA, other government agency, or USA.

AC-03 Systems must enforce the access control technical policies and privileges for all operating system and application accounts, as defined in the SSP under AC-02, including enhancements, through the use of access control mechanisms.

Note: This incorporates the LOGICAL access restriction requirements of AC-05.c, CP- 09.d, and MA-02.b.

AC-03EN11 System Owners of systems that process, store, or transmit Sensitive Unclassified Information (SUI), including Sensitive Security Information (SSI), Personally Identifiable Information (PII), Sensitive Personally Identifiable Information (SPII), Sensitive Flight Data (SFD), NAS Sensitive Technical Information (STI), and ATO Cybersecurity Authorization and Vulnerability Information (CAVI), must document in the SSP, under AC- 03EN11, how the system restricts access to SUI.

AC-04.1 System Owners must define and document information flow and flow restrictions, within the system (i.e., sub-system to sub-system) and between interconnected systems, in the System Characterization Document (SCD) under the Internal and External Interfaces sections, and the IP Supplemental Form, as applicable, for all information flows.

AC-04.2 FAA contracted telecommunication service providers that utilize carrier shared services (e.g., Carrier Ethernet, LTE), must obtain formal Service Level Agreement (SLA) documentation from each carrier that defines the specific technology/method used to control FAA data flows to only the FAA specified data path. This information must be provided to support the FAA architecture review and approval process, which includes approval via the Communications, Information, and Network Programs (CINP) Architecture Review Board (ARB).

AC-04EN04 Systems must prevent encrypted information (included encoded data that is not recognized by filters) from bypassing flow control mechanisms (content checking, security policy filters, and data type identifiers) by one or more of the following methods:

(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.

AC-05.a System Owners and/or System Account Managers must ensure user account privileges (defined in the SSP under AC-02) are implemented to provide separation of duties.

AC-06 System Owners must employ the concept of least privilege (assign and enforce the most restrictive set of rights/privileges, including system information input restrictions) when establishing system user accounts (Operating System and Application as defined in the SSP under AC-02).

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

Note 2: This incorporates the requirements of AU-09EN04.

AC-06EN01 System Owners must document in the SSP under AC-06EN01, how the account privileges (defined in the SSP under AC-02) explicitly authorize access to security functions (e.g., configuring access privileges, setting events to be audited, setting intrusion detection parameters).

AC-06EN02 System Owners must document in the SSP under AC-06EN02, how the user accounts (defined in the SSP under AC-02) enforce using privileged and non-privileged accounts.

Privileged account usage must be reserved for System Administrative and Security Related Functions (e.g., configuring access privileges, setting events to be audited, setting intrusion detection parameters). Non-privileged accounts or roles must be used for non-security and non-System Administrative Functions.

AC-06EN03 System Owners of High baseline systems must implement additional restrictions for privileged access commands above and beyond network access controls provided by the FAA LAN/WAN infrastructures. Document in the SSP under AC-06EN03, the additional security mechanisms implemented to restrict privileged access, and document the rationale for privileged access.

For example, a power down/reset from the network, versus being physically present at the device, might be allowed only for compelling operational need for a High baseline system. Rationale must be provided in the SSP.

AC-06EN05 Systems must restrict account privileges to system administration, security administration, or other roles as defined in the SSP.

AC-06EN06 Systems must prohibit privileged access to the system by non-organizational users in accordance with documented privileged access defined in AC-06EN01 and AC-06EN02.

AC-06EN07 System Owners must review annually the privileges assigned to users to validate the need for such privileges and reassign or remove privileges as necessary.

AC-06EN10 Systems must prevent non-privileged users from executing privileged functions including disabling, circumventing, or altering implemented security safeguards/countermeasures, as defined in AC-02 and enforced via AC-03.

AC-07.a System assets must enforce a limit of 5 consecutive invalid attempts within a 15 minute period.

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.

(3) Remote access is external to the domain.

AC-07.b System assets must be configured to automatically:

(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.

Note: ICS tailoring does not exempt this requirement for any Non-local Access and Administration.

AC-08.a Prior to granting system access, Systems must display a warning banner in accordance with FAA Order 1370.121B, FAA Information Security and Privacy: Policy, as amended, as part of every system login, even when systems are accessible from other systems.

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.

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

AC-08.b System assets must display the notification message or banner on the screen until users take explicit actions to acknowledge the notification.

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.

AC-08.c Prior to granting system access, all public (externally facing) websites or other applications must display a Disclaimer Statement in accordance with FAA Order 1370.121B, as amended.

AC-10 System Owners must identify and document in the SSP under AC-10, the number of concurrent sessions for privileged accounts that are allowed, and provide rationale for allowed concurrent sessions of two or more. The system must enforce concurrent sessions as defined in the SSP.

AC-11.a Systems must prevent further access to the system by initiating a session lock (e.g., password protected screen saver), which conceals information, for local access sessions after 15 minutes of inactivity.

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.

Note 2: This incorporates the requirements of AC-11EN01.

AC-11.b Systems must retain the session lock until the user re-authenticates.

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: This is being required for all systems, including LOW, to be compliant with DOT/FAA policy.

AC-12 Systems must automatically terminate a user initiated logical session after 30 minutes of user inactivity.

AC-14.a System Owners must identify and document in the system SSP under AC-14.a, the specific user actions that can be performed on the system without identification or authentication, (e.g., access to public websites for viewing, monitoring system status, Air Traffic Control functions).

AC-14.b System Owners must document the rationale in the system SSP under AC-14.b for allowing specific user actions that can be performed on the system (Operating Systems and Applications) without identification or authentication (as defined in the SSP under AC-14.a). If allowed, rationale must document the need based on mission/business objectives.

AC-17.b System Owners must identify and document all remote access connections as a part of the system's authorization. All authorized remote access connections must be documented in the SSP under AC-17.b, and in the System Characterization Document.

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.

Any new remote access connection must be approved by the MC-OE, ME-OE and/or A- OE Configuration Control Board and requires AO approval.

Note: JO 1370.114 will be superseded by JO 1370.129, “Information Security Requirements for Federal Aviation Administration (FAA) Telecommunications Services in the Mission Critical and Mission Essential Operating Environments”, after it has been signed and published.

AC-17EN02 The system must implement cryptographic mechanisms, or obtain enterprise remote access encryption services (e.g., FRAC) to protect the confidentiality and integrity of data during Remote Data Exchange and Remote Access & Administration (RAA) sessions.

AC-17EN04 System Owners must document in the SSP under AC-17EN04 the following:

(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.

Remote access of privileged functions as defined in AC-17EN04 must only occur in a format that provides assessable evidence.

AC-18.a.2 Systems that use wireless technology must IMPLEMENT the requirements of the FAA Order 1370.121B, as amended, as it relates to wireless technology.

AC-18.a.3 System Owners must document the use of wireless technology and any deviations from the FAA wireless policy in the SSP under AC-18.a and SCD.

AC-18EN01 Systems that use wireless must use authentication (of users and devices) and encryption standards approved by the ATO (currently FIPS 140-2 level 3) in compliance with FAA Order 1370.121B, as amended, to protect wireless system access.

Note: This is being required for all systems, including LOW.

AC-18EN03 System Owners must disable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.

AC-18EN04 As applicable, System Owners must identify and document in the SSP under AC-18EN04, individual user roles authorized to configure wireless networking capabilities.

AC-18EN05 System Owners that utilize wireless technology within their Authorization boundary, are responsible for using minimal signal strength to reduce the probability that signals are usable outside of the organizationally controlled boundary.

AC-19.b System Owners must document the mobile computer/devices (including removable media) that are authorized to connect to system assets.

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

(7) Methods used to prevent unauthorized connections to other non-authorized entities.

AC-19EN05 Mobile computers and devices must employ full-device encryption to protect the confidentiality and integrity of sensitive information in accordance with the FAA Order 1370.121B, as amended, and the NAS Security Advisory for USB Drives dated February 13, 2013.

AC-20.a The ATO must establish terms and conditions for allowing access to an authorized system from an external system, including processing, storing, and/or transmitting information between the authorized system and the external system.

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.

Note: See CA-03.a.1 regarding assessment and authorization of external connections to the NAS.

AC-20EN01.a If a connection to an external system IS NOT made via an approved security gateway (in accordance with ATO Order JO 1370.114, as amended), System Owners must include the externally connected infrastructure in the Authorization boundary and document in the Authorization documentation (System Characterization Document, SSP, ISCP).

Note: JO 1370.114 will be superseded by JO 1370.129, “Information Security Requirements for Federal Aviation Administration (FAA) Telecommunications Services in the Mission Critical and Mission Essential Operating Environments”, after it has been signed and published.

AC-22.a System Owners must document in the SSP under AC-22.a, the designated user types (as defined in the SSP under AC-02.a.2) that are authorized to post information onto an organizational system that is publicly accessible.

AC-22.c System Owners must identify and document in the SSP under AC-22.c, proposed content of information accessible from public sites to ensure nonpublic information is not publicly accessible.

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

AC-22.d System Owners must review content on publicly facing websites annually to ensure nonpublic information is not accessible. The SSP must document the specific date content review was completed in AC-22.d.

AT-04.a.2 System Managers must track and record the completion of system specific security and privacy training for employees and contractors, in accordance with the ATO ISS Training Implementation Guidance document.

AT-04.b.2 MC-OE and ME-OE Systems and Services must ensure training completion records are maintained for employees and contractors that support MC-OE and ME-OE, and A-OE vendor provided services for at least three years.

AU-01.abc.2 System Owners must develop Audit and Accountability procedures in accordance with the ATO ISS Procedures Guidance, laws, executive orders and directives, and ensure that the procedures are implemented by the system personnel that are assigned functional responsibilities for Audit and Accountability. System Owners must designate a representative(s) to manage development, documentation, and dissemination of the procedures.

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

AU-02.a.1 Systems must generate audit logs for both Operating System and Application level events for local, non-local, and remote sessions on all devices capable of generating event logs. The following minimum events must be captured and recorded:

(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 d h f f h h h b f d AU-02.a.2 Systems must document in the SSP, under AU-02.a, the auditable events that are logged by each system asset at the Operating System, IOS, Application, and Database levels.

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.

AU-02.d System Owners must document, in the SSP under AU-02.d, the rationale for why the list of auditable events documented in the SSP under AU-02.a is adequate to support after-the-fact investigations of security events if the list does not address the minimum requirements of AU-02.a.

AU-02.e System Owners must review and update in the SSP the event types selected for logging annually or as deemed necessary.

AU-03.1 System assets must generate audit records that contain the type of event, date, time, system source (asset name and IP address) where the event occurred, user/subject identification, outcome of the event (success/failure), and session ID if applicable.

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.

Note: This contains the requirements of AU-12.c.

AU-03.2 System audit records must not contain sensitive information, such as passwords, actual system data, or privacy information.

AU-03.3 System Owners must document in the SSP under AU-03, the audit record content fields and must organize by asset type.

AU-03EN03 System Owners must ensure that systems limit Personally Identifiable Information (PII) contained in audit records to the auditable events defined in AU-02. Use of PII must be explicitly documented in the SSP under AU-03EN03.

AU-04.1 All system assets (MC-OE, ME-OE, A-OE, and Service Provider's assets) capable of generating audit logs, must allocate sufficient storage capacity to store 14 days of security-relevant audit records in online storage.

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).

AU-04.2 System Owners must document in the SSP under AU-04, the system storage capacity (size), to reduce the likelihood of audit record storage capacity being exceeded (e.g., provide 25% capacity above estimated need).

System Owners of MC-OE and ME-OE assets that send audit logs to the NCMS must document in the SSP under AU-4 that the control is inherited from the NCMS for the specific assets.

AU-05.a Systems must be configured to alert at least one of the following in the event of an audit processing failure (e.g. software/hardware errors, failure in audit capturing mechanisms, audit storing capacity being reached or exceeded):

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

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

(3) System Administrator.

System must define their reporting timeframe in the SSP under AU-05.a.

AU-05.b.1 Personnel receiving alerts must take the following actions based on receiving an audit processing failure alert:

(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.

(2) Follow system-level procedures for audit storage capacity being reached or exceeded.

AU-05.b.2 System auditing procedures, documented in AU-01.abc.2, must include process and responsibilities to be taken when an audit processing failure occurs.

AU-05EN01 System Owners must identify and document in the SSP under AU-05EN01, specific thresholds of notifications for approaching audit record storage capacity for the system.

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%).

OPIP connected systems must provide notifications as part of event reporting to the

NCMS.

AU-05EN02 Mission Critical and Mission Essential Operating Environments 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 A-OE systems must generate and send a real-time alert to the FAA SOC when the audit events are no longer being captured. System Owners must identify and document the maximum latency in reporting audit failure events.

AU-06.a.1 System Owners must review audit logs/records at least weekly, when requested by the NCO, and 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 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.

Note: This incorporates the requirements of MA-4EN01.b.

AU-06.a.2 System auditing procedures, documented in AU-01.abc.2, must include the process and responsibilities for auditing, monitoring and analysis reporting.

AU-06.c System Owners must adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.

AU-06EN01 System Owners of OPIP network connected assets must send generated audit logs to the NCMS enterprise service to support automated audit review, analysis, and reporting processes and investigation and response to suspicious activities.

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 automated mechanisms 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.

AU-07.a.1 System Owners of OPIP network connected assets must send generated audit logs to the NCMS enterprise service to support audit reduction and report generation capabilities.

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.

System Owners of assets connected to the Mission Support network must provide, or obtain an external service that provides, an audit reduction and report generation capability to support on-demand audit review, analysis, and reporting requirements and after-the-fact investigations of security incidents.

AU-07.a.2 System auditing procedures, documented in AU-01.abc.2, must include the process and responsibilities of audit reduction and report generation.

System Owners of assets that do not generate audit logs (as defined in AU-02.a.1) must document rationale for deviating from this requirement in the SSP.

AU-07.b Systems that generate audit records and systems that provide enterprise audit services must not alter the original content or time ordering of audit records.

AU-07EN01 For OPIP network connected assets, the NCMS enterprise audit service must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria.

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.

AU-08.a Systems must provide accurate time stamps (including date, time, and UTC offset) in audit records.

AU-08.b Systems must time stamp audit records to within one second of Coordinated Universal Time, have a fixed local time offset from Coordinated Universal Time, or include the local time offset as part of the time stamp.

AU-09 Systems must:

(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.

(2) Alert System Manager upon detection of unauthorized access, modification, or deletion of audit information.

AU-09EN02 MC-OE, ME-OE and A-OE Systems categorized as FIPS 199 HIGH impact, must provide a syslog server that collects event records from all other system assets.

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.

AU-09EN03 Systems must use cryptographic mechanisms to protect the integrity of audit record information and auditing tools.

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

AU-10 Owners of FIPS 199 HIGH Security Categorization systems connected to the Mission Support network must identify and document in the SSP under AU-10, critical actions that users must not be able to deny performing. Examples may include creating information, sending or receiving messages, or approving information. Systems must implement non-repudiation of actions as defined in the SSP.

The requirement is tailored out for MC-OE and ME-OE system assets connected to the FENS/FTI OPIP infrastructure. MC-OE, ME-OE, and A-OE systems with assets on the Mission Support infrastructure must meet the above requirement.

AU-11 OPIP network connected assets must send generated audit logs to the NCMS enterprise service for retention, and retain a local copy of audit logs. Systems and the NCMS must retain audit records for a minimum of one year and for a minimum of three years, if associated with known security incidents.

MC-OE and ME-OE Service Providers must retain audit records for a minimum of one year and for a minimum of three years, if associated with known security incidents.

System Owners of assets that are not connected to the OPIP network must retain any security audit records that are generated by the system for a minimum of one year and a minimum of three years, if associated with known security incidents.

AU-12.a System Owners must identify in the SSP under AU-12.a, the components that generate the audit records, and where the logs are stored.

AU-12.c Systems must generate audit records based on the event types defined in AU-02.a.1.

Audit record contents must meet the requirements defined in AU-03.1.

AU-12EN01 FENS/FTI provides a common time source for OPIP that can be leveraged by ASH to correlate physical access records as part of an investigation, upon request.

Systems connected to the OPIP network must use the FENS/FTI NTP common time source to enable time correlation of logical access and physical access audit records.

A-OE systems must use an enterprise common time source for time correlation of logical access and physical access audit records.

System Owners must define an acceptable deviation from the FENS/FTI NTP time source between logical access and physical access audit records in the SSP under AU-12EN01.

AU-12EN03 System Owners must identify and document in the SSP under AU-12EN03, individuals or system roles that have the capability to change auditing levels based on selectable criteria.

When requested by the NCO or system-level SOC, Support Personnel must implement the auditing change and provide confirmation of the change to the requestor.

CA-02.d The ATO must ensure that Systems' security posture is assessed on an on-going basis, at least annually, in accordance with the ATO ISCM Plan, to determine if requirements are implemented correctly, operating as intended, and satisfy requirements.

CA-02EN02 System Owners must ensure that security requirements compliance and vulnerability testing are performed annually as defined in the ATO ISCM Plan and authorization master schedule. Assessment testing must include penetration testing in accordance with the DOT Compendium.

Note: System Owners or SSOs of FIPS 199 Low and Moderate impact level systems may request penetration testing or may be required to comply with penetration testing.

CA-03.a.1 System Owners must develop an Interconnection Security Agreement (ISA) between the FAA and recipient for each external connection as defined in ATO Order JO 1370.114, Implementation of FAA Telecommunications Services and Information Security Requirements in the Mission Critical and Mission Essential Operating Environments, and FAA Order 1370.121B, FAA Information Security and Privacy: Policy, as amended.

System Owners must follow the requirements of FAA Order 1200.22E, as amended, and submit all external data sharing requests to the NAS Data Release Board (NDRB) for review and approval prior to release. Persistent data sharing requests require NDRB approval and associated Memoranda of Agreement (MOA) and/or Information Exchange Agreement (IEA) between organizations and systems.

Vendors and external organizations (external to FAA) with an agreement (e.g., IEA/ISA/MOA) must protect received data that contains Controlled Unclassified Information (CUI) from further dissemination to third parties and only allow access to authorized users that have a need to know and a duty to protect. Failure to adhere to data protection requirements will result in revocation of the agreement and termination of subsequent data sharing.

Per FAA Order 1600.75, the recipient of CUI must have a valid need to know and duty to protect as prescribed in law, regulation, government wide policy or contractual agreement to protect the information from unauthorized access and disclosure.

Note 1: This incorporates the requirements of AC-20EN01.b.

Note 2: JO 1370.114 will be superseded by JO 1370.129, “Information Security Requirements for Federal Aviation Administration (FAA) Telecommunications Services in h i i i i l d i i i l i i ” f i h b CA-03.a.2 System Owners must list all ISAs in the SSP under CA-03.a.

CA-03.a.3 The AO must authorize each external system connection via approval of the ISA.

CA-03.c System Owners must annually review and update, as appropriate, all system ISAs.

CA-03EN06 System Owners must verify that individuals or systems transferring data between interconnecting systems have the requisite authorizations (i.e., write permissions or privileges) prior to accepting such data.

CA-05.b System Owners must update existing POAMs based on remediation activities, security assessment results, impact analyses, and continuous monitoring activities. POAMs with more immediacy or higher criticality must be checked more frequently.

CA-08 System Owners must ensure that the ATO performs penetration testing annually, on system threat entry points assets that pose a potential threat in accordance with the ATO ISCM Plan. The ATO must use an independent testing entity.

CA-09.b The System Owner must document each internal connection in accordance with the SCD template.

CA-09.c System Owners must define and enforce termination of internal connections when certain conditions (time, event, etc.) have been met. Conditions are defined based on system requirements.

CA-09.d System Owners must annually review the continued need for each internal interconnection.

CM-01.abc.2 System Owners must develop Configuration Management procedures in accordance with the ATO ISS Procedures Guidance, laws, executive orders and directives, and ensure that the procedures are implemented by the system personnel that are assigned functional responsibilities for Configuration Management. System Owners must designate a representative(s) to manage development, documentation, and dissemination of the procedures.

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

CM-02.a System Owners must develop, document, and maintain under configuration control, a current baseline configuration of the system, that includes all unique system configurations. The System Characterization Document (SCD) submitted with the Authorization and updated as part of the ATO Information Security Continuous Monitoring (ISCM) Assessment must reflect the current system baseline configuration and identify system assets that are designated as ICS and assets used for testing (Lab or Test environment).

The SCD must be in accordance with the current SCD Template, as amended.

Note: This incorporates the requirements of CM-07EN09.

CM-02.b System Owners must review and update the baseline configuration in the SCD at least annually or when system baseline changes such as with addition or removal of system components or when system components are upgraded.

Note: This incorporates the requirements of CM-07EN09.

CM-02EN02 MC-OE and ME-OE systems must implement mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of systems.

Mechanisms for maintaining baseline configurations of systems may be manual or automated. Identify and document in the SSP, under CM-02EN02, where baseline configurations of systems are saved/stored, and how they are maintained.

For the A-OE, the FAA must implement automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of systems.

Identify and document in the SSP, under CM-02EN02, where baseline configurations of systems are saved/stored, and how they are maintained.

CM-02EN03 System Owners must ensure as part of the Configuration Management process, at least one previous version of software and configuration data is retained to support rollback.

Identify and document in the SSP, under CM-02EN03, how the system supports rollback of software and/or configuration data.

CM-

02EN07.a

System Owners must contact the Office of Security and Hazardous Materials (ASH) prior to traveling to any non-U.S. location with ATO assets to determine if modified configuration is required based on risk.

CM-

02EN07.b

System Owners must contact ASH when any ATO asset is returned from a location that is deemed to be of significant risk for containment instructions.

CM-03.a System Owners must define in the System Security Plan (SSP) under CM-03.a the types of changes that are under configuration control. Document in the SSP if the system changes are approved via NAS Change Proposal (NCP), System Support Modification (SSM). Indicate how the system controls changes to system hardware, software, site adaptation and system configuration.

Note 1: This incorporates the requirements of CM-06.d.

Note 2: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, Configuration Management Policy, as amended.

CM-03.b Systems Owners must generate a record for each configuration-controlled change adjudicated by the change control entity (CCB). Identify in the SSP, under CM-03.c where the configuration change decisions are maintained.

Note 1: This incorporates the requirements of CM-06.d.

Note 2: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as amended.

CM-03.c Systems Owners must generate a record of each approved configuration-controlled change to systems under their purview.

Note 1: This incorporates the requirements of CM-06.d.

Note 2: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as amended.

CM-03.d System configuration management procedures, documented in CM-01.abc.2, must include how implementation of approved changes is tracked and recorded.

Configuration Management processes must be implemented in accordance with documented procedures.

Note 1: This incorporates the requirements of CM-06.d.

Note 2: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as amended.

CM-03.e System Owners must document in the SSP under CM-03.e, the retention period for all approved configuration-controlled changes to the system in accordance with the system's Records Disposition schedule.

Note 1: This incorporates the requirements of CM-06.d.

Note 2: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as amended.

CM-03.g The system change control entities (CCBs) authorized to approve configuration-controlled changes to systems under their purview must coordinate and provide oversight for configuration change control activities. The authorizing board must meet monthly or as defined by the board charter.

Note 1: This incorporates the requirements of CM-06.d.

Note 2: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as amended.

CM-03EN01 The system change control entity must implement automated mechanisms to assist with the following:

(1) Documenting proposed changes to the system,

(2) Notifying the appropriate defined approval authorities of proposed changes to the system and requesting change approval,

(3) Highlighting proposed changes to the system that have not been approved or disapproved by a defined time period,

(4) Prohibiting changes to any system until the designated approvals are received,

(5) Documenting all changes to systems, and

(6) Notifying appropriate personnel when approved changes to the system are completed.

CM-03EN02 System Owners must test all configuration controlled changes and document testing results before implementing the changes on the operational system. Document in the SSP, under CM-03EN02, the change release and promotion process and the system environments, to include key site testing.

Note: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as amended.

CM-03EN04 The System Owner must ensure security and privacy representatives are members of the Change Control Entity or CCB to ensure that all configuration-controlled changes are reviewed for impacts to security and privacy. For classified or systems that process CUI, all configuration changes must be reviewed by subject matter experts for CUI data.

CM-03EN06 System Owners of all FIPS 199 HIGH impact systems must ensure that cryptographic mechanisms are used to provide safeguards for key management, storage, and access.

The safeguards and cryptographic mechanisms must be under configuration management.

CM-04 The System Owner must ensure that the assigned System Security Officer (SSO) analyzes changes to the system to determine potential impacts to Security and Privacy prior to change implementation.

If the system accesses, processes, stores or transfers Sensitive Flight Data (SFD), the SSO must ensure that the system change does not adversely impact the confidentiality, integrity, or availability of SFD, and is handled in accordance with FAA Order 1200.22E, External Requests for National Airspace System (NAS) Data, as amended, and the NAS Data Release Board (NDRB).

Note: This is being required for all systems, including LOW, to comply with FAA Order 1800.66, as…