Cybersecurity Practice #8: Security Operations Center and Incident Response (medium/small)

Most cybersecurity programs begin by implementing controls designed to prevent cyberattacks against an organization’s IT infrastructure and data. This is a good place to start and there is a lot of value in basic cyber hygiene, implementing the cybersecurity practices that are discussed in this volume.

However, in the modern age of cyber threats, not all attacks can be prevented with these basic controls. It is equally important to invest in and develop capabilities to detect successful attacks and respond quickly to mitigate the effects of these attacks.

A good example is the threat of phishing attacks. Even if organizations followed every practice discussed in Cybersecurity Practice #1: E-mail Protection, they would still be susceptible to phishing attacks. It is therefore important to detect, in near real time, phishing attacks that successfully infiltrate your environment and to neutralize their effects before widespread theft of credentials or malware installation occurs. This is a classic example of what it means to shore up your detection capabilities (detecting the phishing attack that gets past your basic controls) and response capabilities (neutralizing the effects before serious damage to the organization occurs).

Maintaining detection and response capabilities requires establishing an IR program and an SOC to manage the IR, along with security engineering that enhances an organization’s ability to detect and respond to cyberattacks.

Sub-Practices for Medium-Sized Organizations

An SOC is an organizational structure that leverages cybersecurity frameworks, people, tools, and processes to provide dedicated cybersecurity operations. SOCs are the areas within an organization that dedicate 100 percent of their time to cybersecurity prevention, detection, or response capabilities, providing the execution arm of cybersecurity IR.

An SOC is generally segmented into four main functions, depending on the organization’s level of maturity. These functions are as follows:

• Engineering: The process of building new cybersecurity capabilities into the existing toolsets in an environment. Examples include building new alerts within a security incident and event management (SIEM) system, establishing new log sources for log management systems, establishing new analytics patterns for detection, or simply implementing new cybersecurity systems to add capabilities into the environment.
• Operations: The process of managing and maintaining the cybersecurity tools within the SOC. This is sometimes referred to as keeping the lights on. Keeping the lights on generally means monitoring critical cybersecurity systems to ensure that they operate at agreed-upon performance levels.
• Threat intelligence: A specific function that focuses entirely on how to discover cybersecurity threats that may be relevant to the organization, along with the means and methods these threats may use to infiltrate the organization. This function focuses on the threat actors themselves, the tools they leverage, and the digital signatures they leave in the process of conducting their activities. Once these digital footprints, sometimes called indicators of compromise (IOCs) are established, engineering teams can use integrate IOC patterns into cybersecurity systems and establish IR plays to execute when the IOCs are activated.
• Incident response: the process of conducting a structured and consistent response to any IR plays that have been created. The goal of this function is to
  • validate an IR process that has been triggered;
  • contain any successful cybersecurity attacks to the organization;
  • eliminate the threat from the environment;
  • recover systems or data that might have been affected by the attack; and
  • ensure that any attack vectors that were exploited are well understood and fed back to the security engineering teams for future prevention or enhanced detection capabilities, further minimizing the impacts of those vectors.
    

It is critical to create a continuous feedback loop between your IR and engineering teams so the organization continues to learn and grow based on the actual success of threats and threat actors.

As SOCs are developed, a core concept is to ensure that IR teams and handlers apply consistent methods to execute response practices. SOCs and IR teams should establish playbooks, also known as runbooks, that describe existing detection mechanisms and the procedures to be followed if the mechanisms are triggered. For each detection, the triggered process may be referred to as a play, like plays that football teams maintain in their playbooks.

Examples of plays that might be found in an IR playbook are provided in Table 10. The table provides high-level play details, including what the play seeks to accomplish and the types of source data that must be collected to successfully detect it. The list below will not discuss specific technical log event data required. Information on how to configure this information can be found in multiple publications.^32,33

Table 10. Example Incident Response Plays for IR Playbooks

In each of these cases, the source data provided will include events or log information that is critical to detect the play being constructed. Specialized security systems can ingest these logs and apply pattern matching, rule matching, and analytics capabilities to specific events in the logs to call out potential incidents of interest. These specialized systems are referred to as SIEM systems.

One of the most basic and most important functions in a cybersecurity organization is the IR process. This process provides the organization with standardized procedures to respond to cyberattacks. The attack may be as simple as an attempted phishing attack against users or a highly sophisticated extortion attack that shuts down digital operations. In both cases, from minimal to significant impact, the organized manner of an IR is critical to managing these threats.

The following procedure is a summary of NIST’s Computer Security Incident Handling Guide.³⁴ Generally, a structured IR process is segmented into the following steps:

• Preparation: Before you respond to a cybersecurity incident, it is important to have policies, processes, and procedures in place, including the following components:
• IR policy: a policy that defines the categorization and severity of incidents, the stakeholders involved in IR, the roles and responsibilities of each person, the entry criteria when a security incident occurs, and the person who oversees IR plays. Stakeholders may range from the standard blocking and tackling personnel in IT operations to legal, marketing, and public affairs personnel for high-impact incidents. A template IR policy is provided in Appendix G in the Main document.
• Cybersecurity incident response team (CIRT): a pre-formed and “on the ready” group that knows how to navigate issues when critical- or high-severity security incidents arise. This team develops and manages your organizational response. Most commonly, CIRTs are formed in the HPH sector when potential data breaches occur and the organization must manage the potential breach in compliance with HITECH. It is important to identify the incident commander, the most senior official who will oversee managing cybersecurity incidents. The incident commander is usually the CISO or equivalent. Note that the incident commander should not dive into the technical weeds of the incident, but should keep the various teams organized and focus on their objectives. Table 11 describes the teams may be involved in resolving a critical security incident and potential breach.

Table 11. Roles and Responsibilities for an Organizational CIRT

• Playbook, or runbook: a document that contains standard operating procedures to respond to different types of cyberattacks. Procedures to respond to a phishing attack are different from those required to respond to a system intrusion or a ransomware attack. Each of these three types of attack is a distinct play in an organization’s cybersecurity playbook. For each play, it is important to describe the steps that will be followed to mitigate the attack so that your response is not “made up on the fly.” Though each attack has its own unique characteristics and nuances, your procedures should follow the steps provided in your playbook for that type of attack. A template playbook is provided in Appendix G in the Main document.
  • Tools and technologies: After you establish your policies, CIRTS, and playbook, the next level of improvement is to configure your tools and technologies to streamline the execution of your plays. Streamlining connects your IR processes to your security engineering processes to create a continual feedback loop, which is essential to becoming a resilient organization.

• Identification: The first response to any cyberattack is to understand the scope and extent of the attack. The identification phase of an attack response involves categorizing and classifying components of the attack based on your policies and procedures. Critical and sophisticated attacks warrant a well-organized and effective response.

For example, a general phishing attack that targets a small user set and that is easily identified as malicious may be assigned a lower level of concern than a targeted phishing attack against a select user base leveraging the nomenclature of your organization. These highly specialized attacks are known to be very successful and can easily compromise a user’s credentials or introduce remote-access malware into your environment.

The identification exercise in a phishing process may be as simple as the following example:

• Receive notification from your user base or through your own detection systems of a phishing attack or campaign.
• Profile and understand the extent and scope of the phishing attack. Determine its level of sophistication and intent.
• Conduct a basic investigation to determine whether links were clicked or malware was delivered.

A containment exercise for a phishing attack may be as simple as the following:

• Shun/prevent any remote access C2 traffic that might be established as part of the attack.
• Change credentials proactively for users who clicked to open a credential-theft phishing campaign.

In either case, the process to restore technical capability in the organization is as important as the process to remove the threats and malicious activities in your systems. As you restore functionality, shut down the vectors that made the attack successful. This may be done by patching an exploited vulnerability or rebuilding an entire system to leverage hardening processes such as those identified in Cybersecurity Practice #2: Endpoint Protection Systems.

• Lessons Learned/After-Action Report: Arguably, the most important stage of your IR process is a full debrief with your IR teams after the attack is mitigated and systems are returned to full functionality. This debrief should profile the successful attack vectors and identify short-term adjustments to introduce enhanced prevention, detection, or response capabilities, as well as long-term strategic elements that require more detailed planning.

• Refine a play within the playbook that did not execute as efficiently as possible. Timeliness is one of the most critical aspects of any response; taking too long to ramp up your IR playbook increases your exposure to a successful attack.
• Refine and expand logging capabilities to detect threats more quickly. Implementing these capabilities into your SIEMs. Delve into the specific patterns of the attack as much as possible for lessons learned.
• Share attack details and information with participating ISACs and ISAOs. This helps other organizations to prevent validated and vetted threats. It provides greater credence to the intelligence and increases resiliency of the sector.
• Leverage advanced analytics-based phishing protection tools such as “click protection” or “attachment sandboxing/” These usually require investment and budget allocation by the organization.
• Refocus and prioritize resources to build out greater capabilities to identify and respond to phishing attacks. From a strategic perspective, it is important to refocus your resources in response to a threat that is ramping up against your organization.

A feedback loop from your IR processes back into engineering and operations is a key to becoming a resilient organization. This type of feedback loop enhances an organization’s cybersecurity capabilities over time and organically, while increasing flexibility and agility in IR response processes.

To read an example case of a mock attack, consider “A Practical Example of Incident Response to a Network Based Attack” from the S! NS Reading Room.³⁵

Further details associated with IR playbooks can be found in the SANS Reading Room article, “Incident Handler’s Handbook.”³⁶

Security engineering and operations activities tend to focus on preventing cyberattacks and building out systems that enable streamlined execution of IR functions. That said, not all attacks are equal. They range from simple “script kiddies” that attempt to gain entry to any target to advanced persistent threats backed by substantial resources and a strong desire to gain entry to your specific organization. The means to differentiate these types of attacks falls under the discipline of threat intelligence.

Sophisticated threat intelligence is realized through involvement with and participation in ISACs and ISAOs. ISACs and ISAOs tend to focus on a specific vertical (such as the Health Information Sharing and Analysis Center within the health care sector) or community (such as the Population Health ISAO³⁷). In all cases, the primary function of these associations is to establish and maintain channels for sharing cyber intelligence. The means to share this intelligence vary in sophistication; most mature ISACs leverage common standards and formats, such as Structure Threat Information eXpression (STIX) and Trusted Automated eXchange of Indicator Information (TAXII), as well as flash reports that profile current attacks. ISAC or ISAO participation offers substantial value to an organization. It connects your cybersecurity professionals with the greater cybersecurity community.

As with all disciplines, there are multiple levels of maturity within the threat intelligence discipline. The most basic sharing of threat intelligence involves consuming lists of “vetted bad IP addresses” or “feeds” from commodity sources. These sources have been well curated to identify where the loudest and most obvious attack space resides. Organizations can use multiple means to consume these feeds, but the most usual process is to subscribe to a daily download of IOCs.

Sub-Practices for Large Organizations

In addition to the basic SOC practices already discussed, an organization’s move to more advanced security management should include expanding its SOC to a 24x7x365 model. In this model, the SOC is staffed and monitored 24 hours per day, 7 days per week, 365 days per year.

There are multiple methods to achieve this model, all of which have benefits and constraints. Some of these methods are described below:

• Fully outsourced: In the fully outsourced model, all SOC and threat actions are outsourced to a third-party provider who has the required infrastructure, staff, and capabilities. Such providers normally install sensors on your networks and use them to collect necessary log information that enriches detection and response activities. SOC analysts actively look for threats and provide your internal IR personnel with specific actions to take when threats are identified.This model has the advantage of scale and capability. It is difficult to hire and retain qualified security analysts to provide this dedicated function. Additionally, organizations benefit from the shared intelligence discovered by the service provider’s other clients. The main disadvantage is that these analysts often do not fully complete response actions, requiring engagement from your internal teams. Additionally, investments made by your organization in cybersecurity tools might not be fully leveraged, because the service providers are likely to use their own tools.
• Fully insourced: In the fully insourced model, all SOC and threat actions are handled with internal staff and infrastructure. This model requires the buildout of a dedicated physical space with the IT infrastructure and tools necessary to support your IR personnel. It requires a combination of skills from security engineers, incident handlers, and threat hunters. This model has the advantage of situational awareness and an in-depth understanding of the organization’s business requirements and nuances. Internal staff are accustomed to the specific needs of the organization. Additionally, internal staff understand the context of an organization’s various systems in far more depth than an outside service provider could. The main disadvantages of this model relate to cost, workforce retention, and threat intelligence. Building out an internal SOC can costly if the organization lacks existing facilities to support it. Moving to a 24x7 operation requires hiring new employees and supervisors to ensure effective management and coverage during holidays and time off. Lastly, in this model, the organization does not necessarily get current information about threat actions occurring in other organizations.
• Hybrid: In the hybrid model, the SOC and incident handling functionalities attempt to take advantage of the strengths of the fully outsourced and the fully insourced models while minimizing the disadvantages. In this model, organizations contract with a service provider who provides 24x7x365 monitoring and response by remotely accessing the organization’s existing security technologies (e.g., SIEMs, IPS, firewalls). The service provider provides facilities and staff for monitoring and response actions, and the organization provides the tools and escalation processes. This model tends to offer flexibility and scaling of existing investments made in cybersecurity technologies, processes, and people. However, it requires specific and scripted procedural playbooks to be effective. The organization is required to drive these procedural playbooks and ensure that the service provider complies with them. Lastly, in this model, organizations lose some of the situational awareness normally provided by internal handlers. Precise roles and responsibilities must be established to achieve the desired outcome. 

Leveraging threat intelligence can be challenging. The organization must establish a threat model, ingest data according to the model, and automate data collection and response. This requires dedicated human and technology resources to be successful.

MITRE has developed a model to manage threats. “Adversarial Tactics, Techniques, and Common Knowledge (ATTACK™)” is a curated knowledge base and model for cyber adversary behavior. It addresses the phases of an adversary’s lifecycle and the platforms that are targeted. ATTACK is useful for understanding security risks from known adversary behavior, planning security improvements, and verifying that defenses work as expected.³⁸ It is recommended that organizations consider using this model in addition to STIX and TAXII automation methods to build out a robust threat intelligence program.

Beyond ISACs and ISAOs, there are individual intelligence gathering organizations or departments within organizations that have a vested interest in getting “deep intelligence” directly from the attacker community. This capability requires substantial investment and specialized talent (think intelligence officers), so this level of maturity is not achievable in most large organizations. However, with proper investigation, the fruits of intelligence organizations’ labor can assist the HPH sector immensely. 

Because many specialized tools exist to provide organizational cybersecurity, it can become complicated to leverage all these tools at once. Examples include SIEMs, user behavior analytics, deception technologies, e-mail protection platforms, and endpoint detection and response technologies. Though tools like SIEMs are designed to ingest information from multiple sources and provide context, this capability is dependent on the extensibility of log data, as well as the workflow and process capabilities of the SIEM technology. SIEMs are good at developing alerts and notifying security resources about emergent issues, but they are generally not as robust in the process of executing IR playbooks.

This is where IR orchestration tools come in handy. Once playbooks have been created and approved, IR orchestration tools ensure that playbook execution is consistent. Without IR orchestration, cybersecurity personnel must manage IR consistency. IR orchestration tools enable cybersecurity personnel to focus on the incident, rather than on the consistent execution and documentation of a response play.

In addition to monitoring workflow, IR orchestration tools can pull data from system security stacks and present it to the incident responder in a centralized dashboard. Examples of data that may be pulled into this dashboard include: SIEM, log data, Dynamic Host Configuration Protocol logs, asset inventories, antimalware consoles, vulnerability management data, threat intelligence information, identity management systems, and endpoint security technologies. Each of these data types provides a unique perspective on the threat that your organization is experiencing.

It is useful to baseline your network traffic and implement capabilities to alert upon anomalous changes to the baseline. This can be accomplished by leveraging netflow data and systems that can ingest netflow data. Each system that operates in the ecosystem will have a standard digital footprint for its network communications and will generally operate within those parameters. By conducting a baseline operation on each of the major and core systems, you can compare what is expected to what is occurring. This can be done manually, or you can invest in technologies that can automate the process.

User Behavior Analytics (UBA) is a technique that may be considered as the “SIEM for Users.” In most modern threats, the threat actors attempt to leverage access that already exists in the user space.

Although attackers can generate new accounts for access attempts, they understand most organizations monitor systems for new accounts, especially those with privileged access. The exploitation of existing accounts, however, might go unnoticed.

UBA systems provide analytics context from a user perspective. Like conducting a baseline activity over network access, UBAs baseline user activity and actions throughout the organization’s digital ecosystem. The tool ingests the most relevant user activity logs from these systems as well as existing authentication and authorization systems. Deviations are discovered after the user has been profiled, enabling IR actions to be executed according to the proper playbooks.

One note of importance: UBA protects against external as well as internal threat actors.

Deception technologies expand on the honeypot and honeynet techniques of old, scaling them for larger enterprises. These techniques place “fake systems” or “fake breadcrumbs” throughout the digital ecosystem and wait for them to be “tripped.” They work on the principle that communications should not occur in a system that serves no purpose in the organization. If such communication occurs, it should be brought to the attention of the IR teams for further investigation.

Deception technologies discover attackers who have placed a foothold in your organization’s network and are attempting to pivot to find targets of interest. These targets may be simple (e.g., file storage systems, e-mail systems) or they may be complicated (e.g., EMR or imaging systems). In all cases, the 

goal of the attacker is to leverage access already obtained to pilfer data, conduct an extortion attack (i.e., ransomware), or other maleficence. The organization’s approach is to generate hundreds or thousands of these fake systems, so that it is difficult for the hacker to differentiate them from real assets. In the process the organization’s information security office will be triggered to respond accordingly.

Your IR teams can profile threat actors by watching their behavior on fake systems. For example, technologies exist to create a complete fake file system that interacts and responds like a real file storage system, even generating files that appear to be legitimate. By watching the threat actor enumerate the file system, your IR teams can develop certainty of the malicious intent and identify the threat actor’s foothold in the organization’s network.

Threats Mitigated

1. Phishing attacks
2. Ransomware attacks
3. Loss or theft of equipment
4. Insider, accidental or intentional data loss
5. Attacks against connected medical devices that may affect patient safety

Suggested Metrics

• Time to detect and respond in aggregate, trended by week. The goal is that an IR response should kick off within x hours after detection of an incident, and the incident should be mitigated within y hours after response. Lag time between occurrence and detection of a security incident should be fewer than z days.
• Number of true positive incidents executed by incident category on a weekly basis. Though there is no specific goal for this metric, it is important to monitor trends in incidents that occur in your organization. This will inform the larger security strategy over time based on actual threats in your organization.
• Number of backup failures by week. The goal is to minimize the number of backup jobs that fail and to provide continual assurance that backup jobs are executing as intended.
• Number of notable (or critical- and high-rated) security incidents per week, providing a profiled enumeration of each incident. Each response to a notable security incident should be executed consistently and thoroughly. Each incident should have an after-action report. The goal is to demonstrate that after-action reports and incident reports are written for each notable security incident. This will help with the development and implementation of continual improvement processes.

32. David Swift, Successful SIEM and Log Management Strategies for Audit and Compliance, The SANS Institute, 2010, https://www.sans.org/reading-room/whitepapers/auditing/successful-siem-log- management-strategies-audit-compliance-33528.

33. Peter Czanik and BalaBit, “The 6 Categories of Critical Log Information,” S!NS Technology Security Laboratory, last modified 2013, accessed February 4, 2018, https://www.sans.edu/cyber- research/security-laboratory/article/sixtoplogcategories.

34. Paul Cichonski et al., Computer Security Incident Handling Guide: Recommendations of the National Institute of Standards and Technology (NIST Special Publication 800-61r2, August 2012, Gaithersburg, MD), https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf.

35. Gordon Fraser, A Practical Example of Incident Response to a Network Based Attack, The SANS Institute, 2017, https://www.sans.org/reading-room/whitepapers/incident/practical-incident-response- network-based-attack-37920.

36. Patrick Kral, The Incident Handlers Handbook, The SANS Institute, 2011, https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901

37. “Population Health Information Sharing & !nalysis Organization, “ International IS!O Network, accessed March 10, 2018, http://www.isaonetwork.org/population-health/.

38. “Adversarial Tactics, Techniques & Common Knowledge, MITRE Partnership Network, accessed March 7, 2018, https://attack.mitre.org/wiki/Main_Page.