This chapter is from the book
This chapter is from the book
This chapter is from the book
Threat Assessment
Since evolving from SIM and SEM, SIEM has for years played a vital role in identifying threats and detecting security incidents. Now organizations are looking for ways to combine threat intelligence with SIEM as the intelligence gained can provide enriched data with greater context through correlation with external information. One trend that has emerged in recent years is that organizations now tend to assume that they have already been breached. Rather than be reactive, security teams look for ways to be proactive rather than simply respond to incidents. Targeted threat hunting assessments have gained popularity as a result, and the programs and tools continue to evolve.
Security Information and Event Management (SIEM)
A security information and event management (SIEM) system provides the technological means to accomplish a number of goals related to security monitoring, including the following:
▸ Identifying internal and external threats
▸ Monitoring activity and resource usage
▸ Conducting compliance reporting for internal and external audits
▸ Supporting incident response
SIEM tools collect and correlate and subsequently provide alerts and information dashboards based upon that data. SIEM output can be used proactively to detect emerging threats and improve overall security by defining events of interest (EOI) and resulting actions. SIEM systems are the main element in compliance regulations such as SOX, GLBA, PCI, FISMA, and HIPAA. SIEM systems provide a plethora of fine-grained details to support incident response programs. The purpose of SIEM is to store and turn a large amount of data into knowledge that can be acted upon. SIEM systems are generally part of the overall security operations center (SOC) and have three basic functions:
▸ Centrally managing security events
▸ Correlating and normalizing events for context and alerting
▸ Reporting on data gathered from various applications
Consider, for example, that just one intrusion detection sensor or log data source can generate more than 100,000 events each day. SIEM systems rely on log collectors, which are responsible for aggregating and ingesting the log data from the various sources such as security devices, network devices, servers, and applications. Log aggregation is the process by which SIEM systems combine similar events to reduce event volume. SIEM systems aggregate data from many network sources and consolidate the data so that crucial events are not missed. By default, events are usually aggregated based on the source IP address, destination IP address, and event ID. The purposes of aggregation are to reduce the event data load and improve efficiency. Conversely, if aggregation is incorrectly configured, important information could be lost. Confidence in this aggregated data is enhanced through techniques such as correlation, automated data filtering, and deduplication within the SIEM system.
Event aggregation alone is not enough to provide useful information in an expeditious manner. A common best practice is to use a correlation engine to automate threat detection and log analysis. The main goal of correlation is to build EOIs that can be flagged by other criteria or that allow for the creation of incident identification. To create EOIs, the correlation engine uses data aggregated by using the following techniques:
▸ Pattern matching
▸ Anomaly detection
▸ Boolean logic
▸ A combination of Boolean logic and context-relevant data
Finding the correct balance in correlation rules is often difficult. Correlation rules that try to catch all possible attacks generate too many alerts and can produce too many false-positive alerts.
A SIEM facilitates and automates alert triage to notify analysts about immediate issues. Alerts can be sent via email but are most often sent to a dashboard. To help with the large volume of alerts and notifications that SIEM systems generate, these systems typically provide data visualization tools. From a business perspective, reporting and alerting provide verification of continuous monitoring, auditing, and compliance. Event deduplication improves confidence in aggregated data, data throughput, and storage capacity. Event deduplication is also important because it provides the capability to audit and collect forensic data. The centralized log management and storage in SIEM systems provide validation for regulatory compliance storage or retention requirements. Regarding forensic data and regulatory compliance, WORM (write once read many) drives keep log data protected so that evidence cannot be altered. WORM drives permanently protect administrative data. This security measure should be implemented when an administrator with access to logs is under investigation or when an organization is discussing regulatory compliance.
Some SIEM systems are good at ingesting and querying flow data both in real time and retrospectively. However, significant issues are associated with time, including time synchronization, time stamping, and report time lag. For example, if a report takes 45 minutes to run, the analyst is already that far behind real time, and then time is also needed to read and analyze the results.
When designing a SIEM system, the volume of data generated for a single incident must be considered. SIEM systems must aggregate, correlate, and report output from devices such as firewalls, intrusion detection/prevention systems (IDSs/IPSs), access controls, and myriad network devices. How much data to log from critical systems is an important consideration when deciding to use a SIEM system.
SIEM systems have high acquisition and maintenance costs. If the daily events number in the millions per day and events are gathered from network devices, endpoints, servers, identity and access control systems, and application servers, a SIEM might be cost-effective. For smaller daily event occurrences, free or more cost-effective tools should be considered.
SIEM systems continue to evolve to capture more and more use cases and to be combined with other solution sets. SIEM systems, for example, continue to help secure organizations against threats. Consider user behavior analysis, for example. A SIEM system can establish a baseline for user activity and identify anomalous behavior that deviates from that baseline. This often involves advanced techniques such as machine learning, and the SIEM system needs to be capable of comparing data across time horizons and across groups, such as the department the user works in. More recently, this data has been combined to perform sentiment analysis: Data can be tracked and analyzed to look for patterns that rely on human sentiment. In this way, systems are able to recognize threats before they become threats. This type of analysis should leverage external data sources, including those from the public domain. As discussed in the next section, SIEM systems are now being combined with other functions to perform security assessments.
Threat Hunting
Threat hunting is a proactive approach to finding an attacker before alerts are triggered. It is not reactive or detective. A reactive approach requires data such as the data a SIEM system provides; a detective approach relies on the use of various algorithms and rules. Threat hunting has the following key attributes:
▸ Hypothesis: Threat hunting starts with a hunch, often based on clues. Drivers may include analytics such as user behavior analytics, situational awareness (for example, based on internal risk assessment, trends, or high-value targets), and intelligence based on intelligence bulletins, intelligence feeds, or vulnerability scans.
▸ People: While many sources—such as those discussed in Chapter 5, “Threat Actors, Vectors, and Intelligence Sources,” and earlier in this chapter—are used, threat hunting is centered around the security analyst, who has deep expertise and knowledge of the organization’s environment.
▸ Assumptive: Threat hunting does not take a breach-preventive approach but rather assumes that the organization has already been breached.
▸ Iterative: Much like a penetration tester, a threat hunter must pivot frequently in order to continue lateral movement while seeking further evidence.
Throughout the process, a threat hunter is looking to disrupt the attacker during any phase of what’s known as the cyber kill chain, which is a framework developed to track the steps or phases that an attacker goes through as part of an intrusion. (We examine the cyber kill chain more closely in Chapter 27, “Incident Response.”) The threat hunting process combined with knowledge of the cyber kill chain allows a security analyst to quickly outmaneuver an attacker. The goal of the security team is to completely disrupt the attacker or quickly impede the attacker’s ability to move across the attack chain.
A threat hunter relies on a number of intelligence sources, such as a SIEM system and external sources. Recall that in Chapter 5, we discussed various open and closed sources of threat intelligence and research. All the gathered data may be intelligently pulled together using commercially available software and services. This bringing together of internal and external threat feeds is known as intelligence fusion, and it enables an organization to establish a more accurate threat profile. Internal and external sources are defined as follows:
▸ Internal threat data: Internal threat data consists of alert and event data from the SIEM system and any other raw log sources. It includes previous knowledge about prior attacks, including vulnerabilities exploited, previous indicators of compromise, details about the attacker, and packet captures. Baseline data on network traffic also makes it possible to understand what’s expected and aid in identifying anomalies.
▸ External threat data: External threat data consists of structured threat information such as STIX, as well as unstructured data from security advisories, bulletins, and other OSINT tools. External threat feeds from security organizations providing such data as a service can also be used as data sources. Attacks across organizations are often similar in their techniques. Chances are good that your organization isn’t the first to see an attacker and his or her methods, and external threat data can give you a warning about what is happening elsewhere.
Fusion analysis can aid in processing data and yielding more meaningful insights to provide a comprehensive look at the threats to an organization. This analysis can even compare internal telemetry data with external data to provide prioritized insight. A threat hunter with good threat data can more quickly identify indicators of compromise and indicators of attacks. Some intelligence platforms integrate with and can also provide capabilities to automate and orchestrate the actions required by security.
Security Orchestration, Automation, and Response (SOAR)
Security orchestration, automation, and response (SOAR) tools can aggregate intelligence from internal and external sources to provide fusion analysis and other insights. SOAR combines data and also provides for case management and automated workflow. Gartner, a leading technology research company, came up with the idea of SOAR. According to Gartner, SOAR primarily does three things:
▸ Threat and vulnerability management
▸ Security incident response
▸ Security operations automation
You can see that, as a combined platform, a SOAR solution combines security orchestration and automation (SOA) with threat intelligence platforms (TIP) and incident response platforms (IRP). SOAR works with and augments SIEM. Gartner expects that in the future these capabilities will merge.