Central Log Server Security Requirements Guide

U_Central_Log_Server_SRG_V1R1_Manual-xccdf.xml

Version/Release Published Filters Downloads Update
V1R1 2018-08-29      
Update existing CKLs to this version of the STIG
This Security Requirements Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: [email protected]
Vuln Rule Version CCI Severity Title Description
SV-95819r1_rule SRG-APP-000080-AU-000010 CCI-000166 MEDIUM The Central Log Server must be configured to protect the data sent from hosts and devices from being altered in a way that may prevent the attribution of an action to an individual (or process acting on behalf of an individual). Without non-repudiation, it is impossible to positively attribute an action to an individual (or process acting on behalf of an individual). The records stored by the Central Log Server must be protected against such alteration as removing the identifier. A hash is one way of performing this function. The server must not allow the removal of identifiers or date/time, or it must severely restrict the ability to do so. Additionally, the log administrator access and activity with the user account information.
SV-95821r1_rule SRG-APP-000086-AU-000020 CCI-000174 LOW The Central Log Server must be configured to aggregate log records from organization-defined devices and hosts within its scope of coverage. If the application is not configured to collate records based on the time when the events occurred, the ability to perform forensic analysis and investigations across multiple components is significantly degraded. Centralized log aggregation must also include logs from databases and servers (e.g., Windows) that do not natively send logs using the syslog protocol.
SV-95823r1_rule SRG-APP-000086-AU-000030 CCI-000174 LOW Time stamps recorded on the log records in the Central Log Server must be configured to synchronize to within one second of the host server or, if NTP is configured directly in the log server, the NTP time source must be the same as the host and devices within its scope of coverage. If the application is not configured to collate records based on the time when the events occurred, the ability to perform forensic analysis and investigations across multiple components is significantly degraded. If the SIEM or other Central Log Server is out of sync with the host and devices for which it stores event logs, this may impact the accuracy of the records stored. Log records are time correlated if the time stamps in the individual log records can be reliably related to the time stamps in other log records to achieve a time ordering of the records within an organization-defined level of tolerance. This requirement applies only to applications that compile system-wide log records for multiple systems or system components. Note: The actual configuration and security requirements for NTP is handled in the host OS or NDM STIGs that are also required as part of a Central Log Server review.
SV-95825r1_rule SRG-APP-000086-AU-000390 CCI-000174 MEDIUM Where multiple log servers are installed in the enclave, each log server must be configured to aggregate log records to a central aggregation server or other consolidated events repository. Log servers (e.g., syslog servers) are often used on network segments to consolidate from the devices and hosts on that network segment. However, this does not achieve compliance with the DoD requirement for a centralized enclave log server. To comply with this requirement, create a central log server that aggregates multiple log servers or use another method to ensure log analysis and management is centrally managed and available to enterprise forensics and analysis tools. This server is often called a log aggregator, SIEM, or events server.
SV-95827r1_rule SRG-APP-000088-AU-000040 CCI-001353 LOW The Central Log Server log records must be configured to use the syslog protocol or another industry standard format (e.g., Windows event protocol) that can be used by typical analysis tools. Without a standardized format for log records, the ability to perform forensic analysis may be more difficult. Standardization facilitates production of event information that can be more readily analyzed and correlated. Log information that is normalized to common standards promotes interoperability and exchange of such information between dissimilar devices and information systems. If logging mechanisms within applications that send records to the centralized audit system do not conform to standardized formats, the audit system may convert the records into a standardized format when compiling system-wide audit trails. Thus, although the application and other system components should send the information in a standardized format, ultimately the audit aggregation server is responsible for ensuring the records are compiled to meet this requirement.
SV-95829r1_rule SRG-APP-000089-AU-000400 CCI-000169 MEDIUM The Central Log Server must be configured to retain the DoD-defined attributes of the log records sent by the devices and hosts. Log records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating log records. DoD has defined a list of information or attributes that must be included in the log record, including date, time, source, destination, module, severity level (category of information), etc. Other log record content that may be necessary to satisfy the requirement of this policy includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.
SV-95831r1_rule SRG-APP-000090-AU-000070 CCI-000171 LOW The Central Log Server must be configured to allow only the Information System Security Manager (ISSM) (or individuals or roles appointed by the ISSM) to select which auditable events are to be retained. Without restricting which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating log records.
SV-95833r1_rule SRG-APP-000111-AU-000150 CCI-000154 LOW The Central Log Server must be configured to perform analysis of log records across multiple devices and hosts in the enclave that can be reviewed by authorized individuals. Successful incident response and auditing relies on timely, accurate system information and analysis to allow the organization to identify and respond to potential incidents in a proficient manner. If the application does not provide the ability to centrally review the application logs, forensic analysis is negatively impacted. Segregation of logging data to multiple disparate computer systems is counterproductive and makes log analysis and event notification difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems. Automated mechanisms for centralized reviews and analyses include, for example, Security Information and Event Management (SIEM) products.
SV-95835r1_rule SRG-APP-000115-AU-000160 CCI-000158 LOW The Central Log Server must be configured to perform on-demand filtering of the log records for events of interest based on organization-defined criteria. The ability to specify the event criteria that are of interest provides the persons reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded. Events of interest can be identified by the content of specific log record fields including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required; for example, locations selectable by general networking location (e.g., by network or subnetwork) or by specific information system component. This requires applications to be configured to customize log record reports based on organization-defined criteria. Summary reports provide oversight for security devices, helping to identify when a device is not detecting or blocking to the extent one would expect. A simple “top 10” list of what was detected and blocked, with a count by severity, can help prioritize security responses. Operational reports detailing the source hosts for any given malware can then direct remediation responses.
SV-95837r1_rule SRG-APP-000116-AU-000270 CCI-000159 LOW The Central Log Server must be configured to use internal system clocks to generate time stamps for log records. Without an internal clock used as the reference for the time stored on each event to provide a trusted common reference for the time, forensic analysis would be impeded. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. If the internal clock is not used, the system may not be able to provide time stamps for log messages. Additionally, externally generated time stamps may not be accurate. Applications can use the capability of an operating system or purpose-built module for this purpose.
SV-95839r1_rule SRG-APP-000125-AU-000300 CCI-001348 LOW The Central Log Server must be configured to back up the log records repository at least every seven days onto a different system or system component other than the system or component being audited. Protection of log data includes ensuring log data is not accidentally lost or deleted. Backing up log records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to ensure that in the event of a catastrophic system failure, the log records will be retained. This helps to ensure that a compromise of the information system being audited does not also result in a compromise of the log records. This requirement only applies to applications that have a native backup capability for log records. Operating system backup requirements cover applications that do not provide native backup functions.
SV-95841r1_rule SRG-APP-000125-AU-000310 CCI-001348 LOW The Central Log Server system backups must be stored on media capable of guaranteeing file integrity for a minimum of five years. If backups are not properly processed, protected, and stored on appropriate media, recovery from a system failure or implementation of a contingency plan would not include the data necessary to fully recover in the time required to ensure continued mission support.
SV-95843r1_rule SRG-APP-000181-AU-000200 CCI-001876 MEDIUM The Central Log Server must be configured to perform audit reduction that supports on-demand reporting requirements. The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
SV-95845r1_rule SRG-APP-000292-AU-000420 CCI-001684 LOW For devices and hosts within its scope of coverage, the Central Log Server must be configured to notify the System Administrator (SA) and Information System Security Officer (ISSO) when account modification events are received. When application accounts are modified, user accessibility is affected. Accounts are used for identifying individual users or for identifying the application processes themselves. Sending notification of account modification events to the SA and ISSO is one method for mitigating this risk. Such a function greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. Notification may be configured to be sent by the device, SNMP server, or the Central Log Server. The best practice is for these notifications to be sent by a robust events management server.
SV-95847r1_rule SRG-APP-000293-AU-000430 CCI-001685 LOW For devices and hosts within its scope of coverage, the Central Log Server must notify the System Administrator (SA) and Information System Security Officer (ISSO) when events indicating account disabling actions are received. When application accounts are disabled, user accessibility is affected. Accounts are used for identifying individual users or for identifying the application processes themselves. Sending notification of account disabling events to the SA and ISSO is one method for mitigating this risk. Such a function greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. Notification may be configured to be sent by the device, SNMP server, or Central Log Server. The best practice is for these notifications to be sent by a robust events management server.
SV-95849r1_rule SRG-APP-000294-AU-000440 CCI-001686 LOW For devices and hosts within its scope of coverage, the Central Log Server must notify the System Administrator (SA) and Information System Security Officer (ISSO) when events indicating account removal actions are received. When application accounts are removed, user accessibility is affected. Accounts are used for identifying users or for identifying the application processes themselves. Sending notification of account removal events to the SA and ISSO is one method for mitigating this risk. Such a function greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. Notification may be configured to be sent by the device, SNMP server, or Central Log Server. The best practice is for these notifications to be sent by a robust events management server.
SV-95851r1_rule SRG-APP-000353-AU-000050 CCI-001914 LOW The System Administrator (SA) and Information System Security Manager (ISSM) must configure the retention of the log records based on criticality level, event type, and/or retention period, at a minimum. If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to respond effectively and important forensic information may be lost. The organization must define and document log retention requirements for each device and host and then configure the Central Log Sever to comply with the required retention period. This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed; for example, in near real time, within minutes, or within hours.
SV-95853r1_rule SRG-APP-000353-AU-000060 CCI-001914 LOW The Central Log Server must be configured so changes made to the level and type of log records stored in the centralized repository must take effect immediately without the need to reboot or restart the application. If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to respond effectively and important forensic information may be lost. This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed; for example, in near real time, within minutes, or within hours.
SV-95855r1_rule SRG-APP-000354-AU-000080 CCI-001919 LOW The Central Log Server must be configured to allow selection, capture, and view of all events related to a user session, host, or device when required by authorized users. If the system is not configured to select a user session to capture and view or produce a report, investigations into suspicious or harmful events would be hampered by the volume of information captured. The volume of information captured may also adversely impact the operation for the network. This only includes auditable events. The Central Log Server (i.e., SIEM, syslog server) should be able to correlate across multiple devices and hosts within its span of control to provide an aggregated view of the single user's activity.
SV-95857r1_rule SRG-APP-000356-AU-000090 CCI-001844 LOW The Central Log Server must be configured for centralized management of the events repository for the purposes of configuration, analysis, and reporting. If the application is not configured to centrally manage the content captured in the log records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in log records must be managed from a central location (necessitating automation). Centralized management of log records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Application components requiring centralized audit log management must be configured to support centralized management.
SV-95859r1_rule SRG-APP-000358-AU-000100 CCI-001851 MEDIUM The Central Log Server must be configured to off-load log records onto a different system or media than the system being audited. Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. Although this may be part of the operating system function, for the enterprise events management system, this is most often a function managed through the application since it is a critical function and requires the use of a large amount of external storage.
SV-95861r1_rule SRG-APP-000359-AU-000120 CCI-001855 LOW The Central Log Server must be configured to send an immediate alert to the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) when allocated log record storage volume reaches 75 percent of the repository maximum log record storage capacity. If security personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion. Although this may be part of the operating system function, for the enterprise events management system, this is most often a function managed through the application since it is a critical function and requires the use of a large amount of external storage.
SV-95863r1_rule SRG-APP-000360-AU-000130 CCI-001858 LOW For the host and devices within its scope of coverage, the Central Log Server must be configured to send a real-time alert to the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) of all audit failure events, such as loss of communications with hosts and devices, or if log records are no longer being received. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit function and application operation may be adversely affected. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less). User-configurable controls on the Central Log Server help avoid generating excessive numbers of alert messages. Define realistic alerting limits and thresholds to avoid creating excessive numbers of alerts for noncritical events. This requirement must be mapped to the severity levels used by the system to denote a failure, active attack, attack involving multiple systems, and other critical notifications, at a minimum. However, note that the IDS/IDPS and other monitoring systems may already be configured for direct notification of many types of critical security alerts.
SV-95865r1_rule SRG-APP-000361-AU-000140 CCI-001861 LOW The Central Log Server must be configured to send an immediate alert to the System Administrator (SA) or Information System Security Officer (ISSO) if communication with the host and devices within its scope of coverage is lost. If the system were to continue processing after audit failure, actions could be taken on the system that could not be tracked and recorded for later forensic analysis. To perform this function, some type of heartbeat configuration with all of the devices and hosts must be configured. Because of the importance of ensuring mission/business continuity, organizations may determine that the nature of the audit failure is not so severe that it warrants a complete shutdown of the application supporting the core organizational missions/business operations. In those instances, partial application shutdowns or operating in a degraded mode may be viable alternatives. This requirement applies to each audit data storage repository (i.e., distinct information system component where log records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.
SV-95867r1_rule SRG-APP-000362-AU-000170 CCI-001886 LOW The Central Log Server must be configured to perform on-demand sorting of log records for events of interest based on the content of organization-defined audit fields within log records. The ability to sort the log records to better view events of interest provides the persons reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded. This requires applications to be configured to sort log record reports based on organization-defined criteria.
SV-95869r1_rule SRG-APP-000363-AU-000180 CCI-001887 LOW The Central Log Server must be configured to perform on-demand searches of log records for events of interest based on the content of organization-defined audit fields within log records. The ability to search the log records to better view events of interest provides the persons reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded. This requires applications to provide the capability to search log record reports based on organization-defined criteria.
SV-95871r1_rule SRG-APP-000364-AU-000190 CCI-001875 MEDIUM The Central Log Server must be configured to perform audit reduction that supports on-demand audit review and analysis. The ability to perform on-demand audit review and analysis, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Audit reduction is a technique used to reduce the volume of log records to facilitate a manual review. Audit reduction does not alter original log records. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
SV-95873r1_rule SRG-APP-000365-AU-000210 CCI-001877 LOW The Central Log Server must be configured to perform audit reduction that supports after-the-fact investigations of security incidents. If the audit reduction capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. Audit reduction capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to applications with audit reduction capabilities.
SV-95875r1_rule SRG-APP-000366-AU-000220 CCI-001878 LOW The Central Log Server must be configured to generate on-demand audit review and analysis reports. The report generation capability must support on-demand review and analysis to facilitate the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Report generation must be capable of generating on-demand (i.e., customizable, ad hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective. Audit reduction and report generation capabilities do not always reside on the same information system or within the same organizational entities conducting auditing activities. The audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in log records. The report generation capability provided by the information system can generate customizable reports. Time ordering of log records can be a significant issue if the granularity of the timestamp in the record is insufficient. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand audit review and analysis.
SV-95877r1_rule SRG-APP-000367-AU-000230 CCI-001879 LOW The Central Log Server must be configured to generate reports that support on-demand reporting requirements. The report generation capability must support on-demand reporting to facilitate the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents The report generation capability provided by the application must be capable of generating on-demand (i.e., customizable, ad hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand reporting requirements.
SV-95879r1_rule SRG-APP-000368-AU-000240 CCI-001880 LOW The Central Log Server must be configured to generate reports that support after-the-fact investigations of security incidents. If the report generation capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. The report generation capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand reporting requirements.
SV-95881r1_rule SRG-APP-000369-AU-000250 CCI-001881 LOW The Central Log Server must be configured to perform audit reduction that does not alter original content or time ordering of log records. If the audit reduction capability alters the content or time ordering of log records, the integrity of the log records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
SV-95883r1_rule SRG-APP-000370-AU-000260 CCI-001882 LOW The Central Log Server must be configured to generate reports that do not alter original content or time ordering of log records. If the audit report generation capability alters the original content or time ordering of log records, the integrity of the log records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this. The report generation capability provided by the application can generate customizable reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
SV-95885r1_rule SRG-APP-000374-AU-000290 CCI-001890 LOW Upon receipt of the log record from hosts and devices, the Central Log Server must be configured to record time stamps of the time of receipt that can be mapped to Coordinated Universal Time (UTC). If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the application include date and time. Time is commonly expressed in UTC, a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.
SV-95887r1_rule SRG-APP-000375-AU-000280 CCI-001889 LOW The Central Log Server must be configured to record time stamps for when log records are received by the log server that meet a granularity of one second for a minimum degree of precision. Without sufficient granularity of time stamps, it is not possible to adequately determine the chronological order of records. Time stamps generated by the application include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks. Note: The actual configuring and security requirements for NTP is handled in the host OS or NDM STIGs that are also required as part of a Central Log Server review.
SV-95889r1_rule SRG-APP-000381-AU-000320 CCI-001814 LOW The Central Log Server must be configured to audit the enforcement actions used to prevent access to modules or functions that can change the account access levels. Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks, and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.
SV-95891r1_rule SRG-APP-000515-AU-000110 CCI-001851 LOW The Central Log Server must be configured to off-load interconnected systems in real time and off-load standalone systems weekly, at a minimum. Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. Although this may be part of the operating system function, for the enterprise events management system, this is most often a function managed through the application since it is a critical function and requires the use of a large amount of external storage.
SV-95893r1_rule SRG-APP-000516-AU-000330 CCI-000366 MEDIUM The Central Log Server must be configured to retain the identity of the original source host or device where the event occurred as part of the log record. In this case the information producer is the device based on IP address or some other identifier of the device producing the information. The source of the record must be bound to the record using cryptographic means. Some events servers allow the administrator to retain only portions of the record sent by devices and hosts. This requirement applies to log aggregation servers with the role of fulfilling the DoD requirement for a central log repository. The syslog, SIEM, or other event servers must retain this information with each log record to support incident investigations.
SV-95895r1_rule SRG-APP-000516-AU-000340 CCI-000366 MEDIUM The Central Log Server that aggregates log records from hosts and devices must be configured to use TCP for transmission to guarantee delivery. If the default UDP protocol is used for communication between the hosts and devices to the Central Log Server, then log records that do not reach the log server are not detected as a data loss. The use of TCP to transport log records to the log servers guarantees delivery and gives the option to encrypt the traffic if the log server communication is not protected using a management network (preferred) or VPN based on mission requirements.
SV-95897r1_rule SRG-APP-000516-AU-000350 CCI-000366 MEDIUM The Central Log Server must be configured to notify the System Administrator (SA) and Information System Security Officer (ISSO), at a minimum, when an attack is detected on multiple devices and hosts within its scope of coverage. Notification may be configured to be sent by the device, SNMP server, or Central Log Server. The best practice is for these notifications to be sent by a robust events management server. This is a function provided by most enterprise-level SIEMs. If the Central Log Server does not provide this function, it must forward the log records to a log server that does.
SV-95899r1_rule SRG-APP-000516-AU-000360 CCI-000366 MEDIUM The Central Log Server must be configured to automatically create trouble tickets for organization-defined threats and events of interest as they are detected in real time (within seconds). In most Central Log Server products today, log review (threat detection), can be automated by creating correlation content matching the organizational-defined Events of Interest (e.g., account change actions, privilege command use, and other AU and AC family controls) to automatically notify or automatically create trouble tickets for threats as they are detected in real time. Auditors have repeatedly expressed a strong preference for automated ticketing. They are also more likely to follow up on the threat and action items needed to address the detected issues if the ticketing process is automated. This is a function provided by most enterprise-level SIEMs. If the Central Log Server does not provide this function, it must forward the log records to a log server that does.
SV-95901r1_rule SRG-APP-000516-AU-000370 CCI-000366 MEDIUM For devices and hosts within the scope of coverage, the Central Log Server must be configured to automatically aggregate events that indicate account actions. If the Central Log Server is configured to filter or remove account log records transmitted by devices and hosts within its scope of coverage, forensic analysis tools will be less effective at detecting and reporting on important attack vectors. A comprehensive account management process must include capturing log records for the creation of user accounts and notification of administrators and/or application owners. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. This requirement addresses the concern that the Central Log Server may be configured to filter out certain levels of information, which may result in the discarding of DoD-required accounting actions addressed in the AC-2 (4) controls such as creation, modification, deletion, and removal of privileged accounts.
SV-95903r1_rule SRG-APP-000516-AU-000380 CCI-000366 MEDIUM The Central Log Server must be configured with the organization-defined severity or criticality levels of each event that is being sent from individual devices or hosts. This supports prioritization functions, which is a major reason why centralized management is a requirement in DoD. This includes different features that help highlight the important events over less critical security events. This may be accomplished by correlating security events with vulnerability data or other asset information. Prioritization algorithms often use severity information provided by the original log source as well.
SV-95905r1_rule SRG-APP-000516-AU-000410 CCI-000366 MEDIUM Analysis, viewing, and indexing functions, services, and applications used as part of the Central Log Server must be configured to comply with DoD-trusted path and access requirements. Analysis, viewing, and indexing functions, services, and applications, such as analysis tools and other vendor-provided applications, must be secured. Software used to perform additional functions, which resides on the server, must also be secured or could provide a vector for unauthorized access to the events repository.
SV-95995r1_rule SRG-APP-000148-AU-002270 CCI-000764 HIGH The Central Log Server must be configured to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses.
SV-95997r1_rule SRG-APP-000171-AU-002540 CCI-000196 HIGH For accounts using password authentication, the Central Log Server must be configured to store only cryptographic representations of passwords. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include: - When the user does not use a CAC and is not a current DoD employee, member of the military, or DoD contractor. - When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. If the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of a FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security. Verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) In the above, "n" is a cryptographically-strong random [*3] number. "Hn" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares "Hn" with the stored "Hn". A salt is essentially a fixed-length cryptographically strong random value. Another method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key.
SV-95999r1_rule SRG-APP-000172-AU-002550 CCI-000197 HIGH For accounts using password authentication, the Central Log Server must use FIPS-validated SHA-1 or later protocol to protect the integrity of the password authentication process. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. The information system must specify the hash algorithm used for authenticating passwords. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This requirement applies to all accounts, including authentication server; Authorization, Authentication, and Accounting (AAA); and local accounts such as the root account and the account of last resort. This requirement only applies to components where this is specific to the function of the device (e.g., TLS VPN or ALG). This does not apply to authentication for the purpose of configuring the device itself (management).
SV-96001r1_rule SRG-APP-000175-AU-002630 CCI-000185 HIGH The Central Log Server, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used to for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.
SV-96003r1_rule SRG-APP-000176-AU-002640 CCI-000186 HIGH The Central Log Server, when using PKI-based authentication, must enforce authorized access to the corresponding private key. If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.
SV-96005r1_rule SRG-APP-000178-AU-002660 CCI-000206 HIGH The Central Log Server must obfuscate authentication information during the authentication process so that the authentication is not visible. To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.
SV-96009r1_rule SRG-APP-000179-AU-002670 CCI-000803 HIGH The Central Log Server must use FIPS-validated SHA-1 or higher hash function to protect the integrity of keyed-hash message authentication code (HMAC), Key Derivation Functions (KDFs), Random Bit Generation, hash-only applications, and digital signature verification (legacy use only). Without cryptographic integrity protections, information can be altered by unauthorized users without detection. To protect the integrity of the authenticator and authentication mechanism used for the cryptographic module used by the Central Log Server must be configured to use one of the following hash functions for hashing the password or other authenticator in accordance with SP 800-131Ar1: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. Applications also include HMAC, KDFs, Random Bit Generation, and hash-only applications (e.g., hashing passwords and using SHA-1 or higher to compute a checksum). For digital signature verification, SP800-131Ar1 allows SHA-1 for legacy use where needed.
SV-96011r1_rule SRG-APP-000033-AU-001610 CCI-000213 HIGH The Central Log Server must be configured to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.
SV-96015r1_rule SRG-APP-000439-AU-004310 CCI-002418 HIGH The Central Log Server must be configured to protect the confidentiality and integrity of transmitted information. Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This requirement applies only to those applications that are either distributed or can allow access to data non-locally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, SSL VPNs, or IPSEC. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.
SV-96017r1_rule SRG-APP-000514-AU-002890 CCI-002450 HIGH The Central Log Server must implement NIST FIPS-validated cryptography for the following: to provision digital signatures; to generate cryptographic hashes; and/or to protect unclassified information requiring confidentiality and cryptographic protection. FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.
SV-96021r1_rule SRG-APP-000149-AU-002280 CCI-000765 MEDIUM The Central Log Server must use multifactor authentication for network access to privileged user accounts. Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the Internet).
SV-96023r1_rule SRG-APP-000150-AU-002320 CCI-000766 MEDIUM The Central Log Server must use multifactor authentication for network access to non-privileged user accounts. To assure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, token); or (iii) Something you are (e.g., biometric). A non-privileged account is any information system account with authorizations of a non-privileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.
SV-96027r1_rule SRG-APP-000151-AU-002330 CCI-000767 MEDIUM The Central Log Server must use multifactor authentication for local access using privileged user accounts. To assure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.
SV-96029r1_rule SRG-APP-000154-AU-002360 CCI-001936 MEDIUM The Central Log Server must be configured to use multifactor authentication for network access to privileged accounts such that one of the factors is provided by a device separate from the system gaining access. Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards, such as the U.S. Government Personal Identity Verification card and the DoD common access card. A privileged account is any information system account with authorizations of a privileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection.
SV-96031r1_rule SRG-APP-000156-AU-002380 CCI-001941 MEDIUM The Central Log Server must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts. A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoD PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols, such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also complaint. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.
SV-96033r1_rule SRG-APP-000163-AU-002470 CCI-000795 MEDIUM The Central Log Server must disable accounts (individuals, groups, roles, and devices) after 35 days of inactivity. Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of inactivity and disable application identifiers after 35 days of inactivity. Management of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual. To avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements.
SV-96035r1_rule SRG-APP-000164-AU-002480 CCI-000205 MEDIUM The Central Log Server must be configured to enforce a minimum 15-character password length. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.
SV-96037r1_rule SRG-APP-000391-AU-002290 CCI-001953 MEDIUM The Central Log Server must be configured to accept the DoD CAC credential to support identity management and personal authentication. The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. If the application cannot meet this requirement, the risk may be mitigated through use of an authentication server.
SV-96041r1_rule SRG-APP-000392-AU-002300 CCI-001954 MEDIUM The Central Log Server must be configured to electronically verify the DoD CAC credential. The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.
SV-96045r1_rule SRG-APP-000397-AU-002590 CCI-002041 MEDIUM For locally created accounts in the application, the Central Log Server must be configured to allow the use of a temporary password for system logons with an immediate change to a permanent password. Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts that allow the users to log on, yet force them to change the password once they have successfully authenticated. The risk can be mitigated by allowing only the account of last resort to be configured locally. This requirement does not apply to that account.
SV-96049r1_rule SRG-APP-000165-AU-002580 CCI-000200 LOW The Central Log Server must be configured to prohibit password reuse for a minimum of five generations. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.
SV-96051r1_rule SRG-APP-000166-AU-002490 CCI-000192 LOW The Central Log Server must be configured to enforce password complexity by requiring that at least one upper-case character be used. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.
SV-96053r1_rule SRG-APP-000167-AU-002500 CCI-000193 LOW The Central Log Server must be configured to enforce password complexity by requiring that at least one lower-case character be used. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
SV-96059r1_rule SRG-APP-000168-AU-002510 CCI-000194 LOW The Central Log Server must be configured to enforce password complexity by requiring that at least one numeric character be used. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
SV-96063r1_rule SRG-APP-000169-AU-002520 CCI-001619 LOW The Central Log Server must be configured to enforce password complexity by requiring that at least one special character be used. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.
SV-96067r1_rule SRG-APP-000170-AU-002530 CCI-000195 LOW The Central Log Server must be configured to require the change of at least 8 of the total number of characters when passwords are changed. If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.
SV-96069r1_rule SRG-APP-000173-AU-002560 CCI-000198 LOW The Central Log Server must be configured to enforce 24 hours/1 day as the minimum password lifetime. Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.
SV-96073r1_rule SRG-APP-000174-AU-002570 CCI-000199 LOW The Central Log Server must be configured to enforce a 60-day maximum password lifetime restriction. Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts that are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.
SV-96077r1_rule SRG-APP-000177-AU-002650 CCI-000187 LOW The Central Log Server must map the authenticated identity to the individual user or group account for PKI-based authentication. Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.