Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

CIS CSC: Logging and Monitoring (CSC 6,12,15) ARC

by Josef Weiss
June 20, 2016

Monitoring system logs is critical in reducing the potential of data compromise as logs contain alerts, events, and historical data. This ARC provides details and information on logging and monitoring efforts, and can aid in improving vulnerability management within the organization. The data presented aligns with CIS CSC Controls 6, 12, and 15.

As defined by the Center for Internet Security (CIS), the Critical Security Controls are a relatively small number of prioritized, well-vetted, and supported security actions that organizations can take to assess and improve their current security state. Developed based on specific knowledge of the threat environment and currently available technologies, the Controls are informed by actual attacks and effective defenses and reflect the combined knowledge of many experts. This dashboard aligns with CIS Critical Security Control 6 (CSC 6) Maintenance, Monitoring, and Analysis of Audit Logs; Control 12 (CSC 12) Boundary Defense; and Control 15 (CSC 15) Wireless Access Control.

In addition, deficient logging and monitoring practices can allow attackers to hide their location, and could potentially leave organizations blind to attack details. Logs are often the only method that can determine if a system has been compromised. The Center for Internet Security has stated, “Because of poor or nonexistent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.” Organizations may also have regulatory and compliance requirements, such as Payment Card Industry (PCI), Sarbanes-Oxley (SOX), and others, that contain specific data logging and monitoring requirements. Each policy statement allows the viewer to drill down into the data to review additional details. Organizations can use this ARC to measure the effectiveness of the logging and monitoring methods used on their networks.

More details on each of the policy statements included in the ARC are given below. Clicking on a policy statement will bring up the analysis screen to display more details related to that policy statement. The ARC policy statement parameters are guides that can be customized as necessary to meet organizational requirements.

This ARC is available in the SecurityCenter Feed, a comprehensive collection of dashboards, reports, Assurance Report Cards, and assets. The ARC can be easily located in the SecurityCenter Feed under the category Executive. The ARC requirements are:

  • SecurityCenter 5.3.1
  • Nessus 6.5.4
  • PVS 5.0.0
  • LCE 4.8.0
  • Compliance data

Tenable SecurityCenter Continuous View (CV) is the market-defining continuous network monitoring solution. SecurityCenter CV includes active vulnerability detection with Tenable Nessus and passive vulnerability detection with the Tenable Passive Vulnerability Scanner (PVS), as well as log correlation with the Tenable Log Correlation Engine (LCE). Using SecurityCenter CV, an organization will obtain the most comprehensive and integrated view of its network.

ARC Policy Statements:

  • Percentage of hosts with NTP clients installed (Passive Detection): This policy statement displays the percentage of the total systems where NTP clients have been passively detected. CSC 6 suggests that all servers and networking equipment synchronize to a network time source. This policy statement reports on NTP client connections across the entire environment. By default, detection is across all hosts. To limit the results to a specific set of hosts, such as servers, an asset should be utilized in the base filter, which groups servers and networking devices together.
  • More than 95% of systems have LCE Clients installed: This policy statement displays the percentage of total systems that have an LCE client installed. Systems that have been identified by a Nessus scanner are evaluated against credentialed scan results, which identify if a data aggregation client is installed on the host. CSC 6 suggests that comprehensive logging be enabled and hosts centralize their logs. While all hosts should have logging enabled, organizational standards will dictate the actual number of hosts that require logging enabled. Adjust the policy statement as required to meet organizational requirements.
  • All LCE Clients are operational (no dead LCE Clients): This policy statement displays a non-compliant status if any LCE Clients are found to be dead. Hosts that have LCE Clients installed on them periodically reach out to the LCE Server with a configurable heartbeat. When LCE no longer detects the heartbeat, the client is reported to be “dead”. CSC 6 suggests that comprehensive logging be enabled and hosts centralize their logs. Dead clients are indications that logs are no longer being forwarded.
  • Log Correlation Engines are running: This policy statement displays a non-compliant status if SecurityCenter has not received LCE events within the last 24 hours. CSC 6 suggests that comprehensive logging be enabled and hosts centralize their logs. Loss of event data could indicate a potential failure, configuration change, or license expiration has occurred and should be checked immediately.
  • Firewalls are transmitting log data to LCE: This policy statement displays a non-compliant status if LCE has not received events of the type firewall within the last 24 hours. CSC 6 suggests that comprehensive logging be enabled and hosts centralize their logs. Loss of event data could indicate a potential failure or configuration change has occurred and should be checked immediately.
  • No Large Firewall anomalies are present in the last 72 hours: This policy statement displays a non-compliant status if LCE has detected firewall anomalies within the last 72 hours. The LCE looks for events to continue for periods of time longer than 20 minutes. The intent is to find activity that is potentially hostile and sustained. CSC 12 suggests that organizations pay special attention to control and flow of traffic through boundary defenses systems. Event activity could mean that your systems are being scanned more aggressively than they have been in the past.
  • No attack anomalies or events are present in the environment in the last 72 hours: This policy statement displays a non-compliant status if LCE has detected attack anomalies within the last 72 hours. The LCE looks for events to continue for periods of time longer than 20 minutes. The intent is to find activity that is potentially hostile and sustained. CSC 12 suggests that organizations pay special attention to control and flow of traffic through boundary defense systems. The focus of this correlation is to see when your systems connect outward to a known hostile IP address. When this occurs, it is very likely that one of your systems is infected or being controlled by a botnet.
  • No Large Access Denied anomalies are present in the environment in the last 72 hours: This policy statement displays a non-compliant status if LCE has detected access-denied anomalies within the last 72 hours. The LCE looks for events to continue for periods of time longer than 20 minutes. The intent is to find activity that is potentially hostile and sustained. CSC 12 suggests that organizations pay special attention to control and flow of traffic through boundary defenses systems. Logs that indicate some form of denied access, but not necessarily a failure to present credentials or attempt to authenticate, are normalized to the “access-denied” event type.
  • Wireless events are being transmitted to LCE: This policy statement displays a non-compliant status if LCE has not received events of the type wireless within the last 24 hours. CSC 15 suggests that organizations pay special attention to wireless access points and devices. Wireless-based events detected by the LCE from wireless access points, wireless controllers, new wireless hosts, and wireless routers are tracked. Loss of event data could indicate a potential failure or configuration change and should be checked immediately.