Leadership

There are many everyday circumstances that are beyond the control of information security leaders and members of incident response teams: limited budgets, executives who refuse to understand the reality of cyber threats, and many other factors too numerous to mention here. Good leaders see situations for what they are and what can be done to mitigate them, refusing to think about the what ifs. Maverick McNealy, professional golfer and son of Sun Microsystems cofounder Scott McNealy, credits his father with telling him, “If you can do something about it, do it. If not, don’t worry about it.”¹

These realities are frustrating to incident response leaders. But they cannot affect the leader’s response. Figure 12-1 is a reminder of Meyer’s formula.

Meyer believes that leaders cannot control events or outcomes, but the one piece of the equation under their control is response. For leaders of incident response, keeping in mind how one responds to situations affects outcomes and is controllable. Poor responses to challenging situations cause outcomes to worsen. The right response lessens the impact of challenging situations.

Balancing the Incident Response Program Against Other Priorities

The incident response leader often carries other titles. He or she may be a director or manager of the information security program or perform another similar role. The number of entities with dedicated incident response teams is few, compared to the total population, which makes prioritization of incident activities necessary.

Network Segmentation and Incident Response

Network segmentation conjures thoughts of complexity, workload, and maintenance. It is not an easy undertaking, but it is one worth considering. If lateral movement is complicated, and opportunities for escalating privilege are fewer, attackers may decide that the effort or risk of detection is too great to continue. Flat networks, in which control of one end point presents an opportunity to compromise any other end point of an attacker’s choosing, can make the attacker’s task too easy. Some point to the use of vLANs as a solution to network segmentation, but only if access is somehow restricted. If every server has permission to communicate with another, this approach does not solve the problem. Two criteria are required for successful segmentation (illustrated in Figure 12-2):

• Except in exceptional circumstances, servers should not talk to other servers, and end-user devices should not talk to other end-user devices.

• vLANs and other network segments with important information assets should not allow access to any application, database, operating system, or other information system component, unless it is required as part of one’s job function.

This figure shows a rudimentary structure for a manufacturing entity. This entity’s ability to thrive depends on new product development derived by the research and development team. The concept here is to break down the end users by function: examples exist for Accounting and Finance, Marketing, and New Product Development departments.

Figure 12-3 shows a breakdown of the infrastructure within the data center for the New Product Development team. There is a production server, used when products are manufactured; a demo server for the team to use when showing executives and other stakeholders progress on new product development; and three development servers, one for each new product under development.

Preplanning and Strategy Development

When designing the incident response strategy for this environment, the focus is to complicate the process for breaching intellectual property used in new product development. By forcing communication to occur only between laptops and servers, it makes pivoting through the environment much tougher. Any end users victimized by a phishing e-mail in Accounting or Marketing force the attacker to pivot between servers and laptops until a member of the development team is breached. Depending on the data targeted, controlling a laptop for someone working on New Product only has access to New Product Development Server 1. The same goes for New Product 2 and New Product 3. Production data is only accessible to the Production team. There is more work to be done by the intruder, and more opportunity to detect the intrusion.

The other value to preplanning and design of the network is understanding where ideal data collection points exist. In this environment, placing detection and traffic capture capabilities in line with communications related to all new products under development, being demonstrated, and produced is more valuable than any other internal data captures. If anything goes wrong, necessary data points to build a time line and investigate is available.

Identification

Data needs a place to go and a way for analysis to occur. Security events spawn many indicators. These indicators may make obvious that an attack is occurring, and others only hint at one. The increased use of SIEM solutions was designed to identify all the subtle hints of an attack and alert cybersecurity teams. These represent just some of the capabilities organizations must implement to identify potential security incidents.

Containment

Containment requires an organization to collect indicators of compromise. Indicators are attributes and artifacts left behind during events. Threat actors have specific attributes, based on tools, techniques, and procedures used. Specific types of malware or ransomware make changes to systems the incident response team use to search the remaining information systems and assets. When matches to the indicators hit, the incident response team can quarantine those systems, taking them offline for further analysis.

The process of gathering an initial set of indicators and searching for signs of each in the remaining systems are documented in playbooks used by the response team. Playbooks are specific to event types: malware/ransomware, denial of service, lost assets, data theft, and unauthorized use or misuse of company assets. This is not a complete list but identifies very common scenarios seen by incident response teams.

During the containment phase, forensic evidence used to determine the root cause and the time line illustrating how the event unfolded is also gathered. Images of the affected systems are obtained for complete analysis of all system characteristics during containment.

During this time, incident response teams deal with contact from members of the business and company leadership who are seeking answers. This is to be expected. The organization could be impacted, depending on the severity of the events in question, and these individuals have a need to know what is occurring. The key is to give facts and not speculate. Speculation causes more harm than good.

Eradication , Recovery, and Lessons Learned

Eradication is the process of removing the malicious artifacts from the environment. It also includes mitigating vulnerabilities exploited and other weaknesses, such as those exploited by the adversary. Recovery processes place systems back into production, in a stronger state, it is hoped Updates to network hardware, additional patches, and configuration changes designed to strengthen the systems from future attacks are key. Finally, ensuring that the team sits down and goes over the event is important. This requirement is often missed. Entities do not find the time to go over the incident response process and document what is effective and what needs improvement. Common examples include updating the incident response plan or playbooks, to add or modify steps, and discussing behaviors and actions of the team, to reinforce expectations. The goal at the end of the eradication phase is to document the incident and events in an executive report outlining actions taken, outcomes, and lessons learned, with metrics tracking activities directed at desired outcomes. Ultimately, management, or the body representing management at the cybersecurity table, must review the documentation and authorize necessary changes.