Continuous Monitoring

Objective

The Objective of Continuous Monitoring, according to NIST SP 800-137[1], is to maintain an up-to-date view of information security risks across an organization. This is a complex, multifaceted undertaking. Many organizations are required to maintain Continuous Monitoring as part of Compliance, including PCI-DSS[2].

"There are some significant problems that can arise if organizations move down the continuous monitoring road with a narrow focus on security controls at the information system level without first doing some basic investment in strengthening the underlying information technology (IT) infrastructure." - What Continuous Monitoring Really Means, Ron Ross[3]

For the purposes of this publication, an Outsourced Continuous Monitoring function is not discussed, though much of the material presented here is re-usable for that purpose.

Description

As security events are generated throughout the organization, a monitoring service may be desired or required to identify which security events must be investigated. Those events may become security incidents.

Process

The following Processes are included in Continuous Monitoring:

1. Log Management Compliance - The organization must be able to identify how many assets are reporting, how many should be reporting, if the log source is providing the correct information and if any device stops reporting.

2. Use Case Development & Life-cycle - This process identifies candidate use cases for implementation, evaluates existing use cases for alerts and decommissions those using defined criteria.

3. Enrichment & Correlation - Data must be enriched, correlated with other sources and prioritized based on asset criticality. This may be a process or a function, however it must still occur.

4. Escalation - When investigating incidents, analysts may need to escalate.

5. Investigation - Expect that new staff will require some orientation time and guidelines on investigations.

6. Automation & Orchestration - On-board, create, tune and evaluation automation and orchestration.

Tooling

Tooling is more than just technology and technology is a subset of Tooling. The list below is the minimum set of tools required to be successful based on experience.

1. SIEM

2. Network Maps

3. CIDR Blocks

4. Asset Inventory

5. Use Case Repository

6. Access to Controls for Investigation

7. Ticketing system

Ticketing

Ticketing is an essential function of Continuous Monitoring. Ticketing allows shift hand-off, provides historical reference for investigations and provides accountability for the enterprise. The criteria for who, what, where, when and why ticketing occurs should be clear across the team.

Access Control

Access control to the ticketing system should be based on need to know. It is not advisable to enter Security Event and Incident investigations into the enterprise ticketing system unless strict security controls can be verified and maintained.

Integration

Integration with other tools throughout the enterprise will make the ticket creation and enrichment process smooth. Foresight from an architectural perspective will save bandwidth down the road.

Best practices

• Often, Security Operations analysts will need to attach log files to investigation tickets. This will require forecasting in capacity management[4].
• Where possible, design or use ticketing systems capable of full text search and field search. As the SOC matures, analysts begin to search this body of knowledge for any prior investigations. Those include analyst notes.
• Start with a simple workflow[[5]] to open a ticket, investigate, make notes, close the ticket. Review tickets regularly, if not daily, in a team environment providing peer commentary.
• Expect that, with implementation of any ticketing system, development time will be required. The investment usually pays off.

Reporting

From a management level, there are several metrics which are industry standard and some that we suggest based on success. Some available industry standards come from CIS[6].

Industry Standards

While these are industry standards, some practitioners have criticism of these based on experience.

• Mean Time to Detect (MTTD)

• Mean Time to Resolve (MTTR)

• Number of Incidents

• Mean Time Between Security Incidents

• Mean Time to Incident Recovery

Our Recommended Metrics

In practice, there are several issues with these standard metrics. Those issues stem from Level of Effort, the availability of information and the purpose one is trying to achieve. For example, Mean Time to Incident Recovery becomes meaningless in a large scale incident. A metric gets increased by orders of magnitude based on the severity. Here is what we recommend:

• Mean Time to Contain (MTTC): From when you identified the incident, how long did it take the organization to get to containment. Recommend measuring this in hours.

• Signal to Noise Ratio: When an alert is presented to the analyst, what is the % chance that that alert is an actual incident.

• Incidents by Severity: Over time, how many incidents are occurring and what is the severity.

These metrics should be collected and reported in a time series so that management can maintain visibility on trends and identify issues and anomalies early.

Staffing

Staffing a Security Operations Center is one of the most essential pieces of success. This is because Security Operations work is highly technical, the staff are expected to be the authority in the interpretation and the risks to the organization are high.

In an article published on Indelible.global[7], staffing challenges associated with premature allocation of resources is discussed along with potential solutions.

In establishing a new Security Operations Center, staff must be:

• trained on their work
• orientated to the environment
• educated on current threats
• become knowledgeable on the business needs and risks
• understand or establish processes.

This is a complex set of requirements for a new team, and so the recommendation is to set reasonable expectations for ramp up.

Budgeting

This section will discuss budgeting.

Communications

Continuous Monitoring has immediate communication flows outputs to the CSIRT (Computer Security Incident Response Team), Content Engineering and Security Architecture.

Continuous Monitoring takes inputs from Threat Hunting, the Business, Risk Management and Threat Intelligence.

Documentation

• Use Case Development, Methodology
• Process Flows
• Procedures (e.g. SIEM Use Case Tuning)

Consider a Wiki for rapid changes during rapid development.

Lessons Learned | Pain Points

Staffing - Alert Fatigue which can be a contributor to Burnout

Process Staffing - "Premature allocation of resources toward continuous monitoring of security controls at Tier 3 may preclude organizations from investing the resources needed to build stronger, more penetration resistant information systems" What Continuous Monitoring Really Means, Ron Ross[8]

False Negatives - Here will discuss false negatives

Additional Reading

https://www.sans.org/reading-room/whitepapers/auditing/successful-siem-log-management-strategies-audit-compliance-33528 [9]