Introduction

In the first three chapters of Volume 2 we have been focused internally. In Chapter 13, we turn our focus to outside your organization. Threat intelligence, like situational awareness, is the discipline of becoming conscious of the environment in which you are operating with the intent of decreasing the potential impact of harms that are presented to you or your community. You’ll need to use a combination of data about the relevant threat actors and the vulnerabilities of your high-value assets along with your judgment about the combinations that pose the greatest risk to your organization.

Bill starts the discussion where we have traditionally associated protection from risk, with the law enforcement community. Every organization operates in the context of local, state and federal jurisdictions, some grounded in the physical world and many increasingly incorporating the digital realm. From there, Bill expands the scope to include the entire human network that all three authors have repeatedly highlighted.

Matt asks us to look inward again to establish the context in which threat intelligence is most effective. He guides us on an exploration of six keys to threat intelligence that teach us how to use that context to make better decisions about which threats are most real to us and build a program around that knowledge.

Gary gives a thorough analysis of the sources for threat intelligence and leaves us with an understanding of how these sources are structured, characterized, and effectively utilized. He concludes with an extensive review of Open Source Threat Intelligence and how you should incorporate that into your threat intelligence program.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  What is threat intelligence, and what types of external threat intelligence sources should the CISO use to augment their cybersecurity suite?

♦  What are the business scenarios for incorporating threat intelligence services into an enterprise cybersecurity program?

♦  Which Open Source Threat Intelligence (OSINT) resources should a CISO consider for enhancing their threat vulnerability management program?

Situational Awareness – Bonney

What Is Threat Intelligence?

Before answering the questions that we have posed for threat intelligence, I’d like to define what threat intelligence is, or what it means to me. Some threat intelligence products and services might include phrases like “organized, analyzed and refined information” and reference “potential and current attacks” somehow targeted, generally or specifically, “at your organization or industry.” That’s certainly one aspect of a good threat intelligence program. That kind of information is consumed at a knowledge level, in other words, informing the people on your team about the current threats that they should focus on, how to recognize them, how to prepare for them, and how to defend against them.

Threat intelligence information can also refer to specific vulnerabilities and the techniques that might be used to exploit those weaknesses in a way that your people and your defensive systems can immediately use to prevent or mitigate specific threats. Threat intelligence can also refer to specifics about the adversaries (who is posing a threat) and the victims (who is the target). Good threat intelligence should be actionable; you need to know what the adversaries want to do, to what, and you need to know if that applies to your organization.

We have to assume that you know what assets you have that are susceptible to any threat. Much of what I’ve listed above is available through commercial and cooperative services. Depending on the scope and capabilities of your organization, you might consume one or more commercially available sources of threat intelligence.

There is a tendency to believe that once something like threat intelligence is packaged commercially, that “buying” your threat intelligence is the most comprehensive and practical approach. Let the experts collect the data from their millions of sensors and their honeypots, and let their analysts review that intelligence and monitor the dark web for you and tell you where you should focus your attention. It’s true that very few companies have the means to run a comprehensive threat intelligence program on their own, and even those that do still consume commercial feeds to support their efforts. But there is another aspect to threat intelligence that does involve work that you do on behalf of your organization. You now have an excellent opportunity to work with your human network, especially your external network of peers, subject matter experts, law enforcement, vendors, and partners.

With this context for threat intelligence, I want to ask an additional set of tactical questions:

1. What is our current working relationship with law enforcement?
2. What are our sources of international cyber threat intelligence?
3. What organizations are we sharing our cyber threat knowledge with, and what are we learning from them?
4. What is our working (information sharing) relationship with the most high-profile firms who have had breaches? Do we have information coming to us from them? What have we learned?
5. Do we track social mediasites and blogs referencing us for clues about our vulnerabilities?
6. When we hear of a breach in another organization, what do we do? When does that process start, and what is the routine reporting in the organization? What are the criteria that determine who to notify and when to notify the board of directors?
7. As we look at the data for intrusions, penetrations, or attempts to gain unauthorized access, what has been the primary category of threat actorswho seem to have made these efforts? How has that information influenced our defensive efforts?

Threat Intelligence Is More Than a Service

Let’s look at what these questions are getting at and how we, as CISOs, might go about responding. Starting with number 1, our relationship with law enforcement. We’ve all heard that law enforcement wants to have a relationship with us. They would like organizations to tell them when suspicious events occur and identify potential bad actors for them. Then, they will share information with industry about threats they become aware of through various means. Each party would be able to use this information without additional jeopardy.

Just a few years ago, this statement met with a fair amount of skepticism. However, through organizations such as InfraGard, which is an FBI public-private partnership program, and concerted efforts by law enforcement and various supportive industry groups, cooperation and trust has been building. While it still varies by region and community, there has been significant progress.

If your organization has a relationship with local law enforcement through its physical security organization, partnering with that group and leveraging that connection is a great place to start. Usually, this involves at least local law enforcement, such as city police departments, county sheriff’s departments, and state troopers across the United States. If your organization does not currently maintain any federal relationships, you should consider connecting with the FBI (through regional associations such as InfraGard) and the Department of Homeland Security (DHS).

The DHS was created in the aftermath of the events of September 11, 2001, to manage and coordinate the activities between several existing agencies. The combined organization addresses land and marine borders and immigration, with the U.S. Customs and Border Protection (CBP), the U.S. Immigration and Customs Enforcement (ICE), and the U.S. Coast Guard (USCG). It also addresses accidents and several types of threats, with the Federal Emergency Management Agency (FEMA), the Transportation Security Administration (TSA), the U.S. Secret Service (USSS), and the Office of Intelligence and Analysis (OIA).

In addition to the FBI’s InfraGard program, there are many cooperatives and public-private partnerships. Among them are the ISACs (Information Sharing and Analysis Centers), which exist for all of the elements of the U.S. critical infrastructure. The graphic below (courtesy of the National Fusion Center Association – NFCA) depicts the 16 components of the U.S. critical infrastructure. The U. S. DHS declared a 17th component, the U. S. Electoral System, a part of the nation’s critical infrastructure in January 2017.

Figure 13.1 The 16 Original Industries in the U.S. Critical Infrastructure

In addition to the NFCA, the ISACs, and your local law enforcement, there are the 76 regional “Law Enforcement Coordination Centers” (LECC). Reach out and connect with these groups and then leverage these groups to find local industry associations if you are new to the region or just don’t know who to ask.

Regarding question 2, not every organization will need sources of international threat intelligence, but if your team has a global footprint, there are significant considerations. First, some cyber-criminal gangs are very regional, and intelligence is limited outside their region. Second, if you do not have a substantial presence in international markets, your international field offices might be especially vulnerable to local cyber-criminal activity if you aren’t able to keep the cyber education level high among your global workforce. To address this, ensure that any vendors you use for threat intelligence have sufficient coverage in the markets where you are present.

Introduction

In the next four chapters, we’re going to do a deep dive into the entire process of preparing for, responding to, recovering from, and learning from cyber incidents. A passage Bill writes in Chapter 17 is worth previewing here: While it’s helpful to break the entire incident response discipline into a series of discrete phases so that each can be described individually to assist with training and the command and control of response activities, it is rarely clear-cut when one process ends, and the next begins. There is often significant overlap, and as new information emerges, it is usually necessary to revisit a phase previously thought completed. For instance, while in recovery, monitoring activity may detect the presence of indicators of compromise identified for the current cyber incident and that may send you all the way back to the containment phase.

At times, the material we present over the 12 essays that make up these next four chapters, that overlap will become apparent not just within the activities of responding to the specific event, but over the entire set of disciplines we cover.

In Chapter 14 we look at the close relationship between business continuity planning and your strategy for becoming a cyber-resilient organization. Each of the three authors ties these two critical business processes together and emphasizes the importance of understanding what is fundamental to the business.

Bill discusses backup and recovery planning. He challenges the reader to factor into their backup planning the traditional elements of business continuity planning while considering vital new dimensions. These new dimensions include accommodating new service delivery models such as cloud computing and new attack methods such as ransomware in our models.

Matt emphasizes the importance of executive and board-level engagement. From understanding the organization’s core priorities and tying those to the appetite for risk to making sure the board understands how the BCP / DR strategy seeks to manage and mitigate that risk, Matt shows how ultimately it is about business strategy. A key way that the CISO drives this engagement is by making sure that the security program and security architecture should be reflective of organizational priorities as captured in BCP tools such as the BIA. Ensuring that the organization is a going concern is the ultimate responsibility of the board.

Gary reminds us of the impact that cyber incidents can have, including outcomes like disruptions to business continuity and reputation damage. Significant events can translate to disappointed customers, lost jobs, and hard monetary costs that can leave an organization reeling. He then helps the reader construct a plan by building on many of the lessons from previous chapters and showing how the pieces fit together.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  What is a Business Continuity Plan (BCP) and what are the steps to create one?

♦  What critical components should a Disaster Recovery Plan (DRP) include to be effective?

♦  What value does the CISO’s security program receive from the organization’s Business Continuity Plan and its associated Disaster Recovery Plan?

Cybersecurity’s Debt to the Business Continuity Community – Stamper

Let’s face it – cybersecurity is exciting. Our profession is in the crosshairs of the media, with reports related to high-profile attacks frequently covered on the nightly news. We even have popular TV shows. For new entrants to our profession, this focus on cybersecurity may seem to be the norm. For those of us who have been in the industry more years than we’d like to admit, we recognize that the current focus on cybersecurity is a relatively new phenomenon. It may come as a shock to some that there was a time when cybersecurity (and before that, information security) was the forgotten stepchild of IT, overlooked from a resource and budget perspective. Security was the department – let’s be honest about this, the individual – that would get the table scraps from the IT budget once leadership addressed all other “priorities.”

I bring up this historical perspective to acknowledge our profession’s debt of gratitude to our colleagues in the business continuity and disaster recovery (BC/DR) community. Historically, our two disciplines shared similar common neglect. Like security, everyone knows and recognizes that business continuity and disaster recovery are important elements to an organization’s overall resilience.

Despite this recognition of the importance of BC/DR, most organizations only pay lip service to this critical discipline with incomplete and untested BC/DR plans. Furthermore, our colleagues in BC/DR frequently have their budgets and projects undermined by higher priority efforts within the organization. The result is that organizations are less resilient and subject to significant interruptions to their operations. Kind of sounds like the risk factors associated with inadequate and poorly-resourced security programs.

While the current focus on cybersecurity is beneficial, we should not overlook the contributions from our colleagues in BC/DR, especially in the context of resiliency. Our respective professions both focus on resiliency. Resiliency is at the heart of cybersecurity. No organization is immune from being attacked. In fact, our organizations are subject to ongoing and in many cases highly persistent attacks. Our jobs are to ensure that our organizations remain resilient when confronted with risks, be they cyber or natural disasters.

We can learn and have learned much from our colleagues in BC/DR. First and foremost, let’s not overlook one of the great tools that our BC/DR friends leverage to evaluate their continuity programs – the business impact analysis (BIA). BIAs are powerful tools that should be leveraged to improve our security programs. They convey detail related to organizational priorities, expressed in terms such as maximum allowable downtime (MAD), recovery-point objective (RPO), and recovery-time objective (RTO). Further, well-crafted BIAs highlight key dependencies on applications, staff, infrastructure, and vendors.

Collectively, the detail resulting from the review of a BIA provides essential context related to the organization’s risk landscape. We don’t have cybersecurity for cybersecurity’s sake. Cybersecurity must be focused on the business and not just cool and innovative technology. Ultimately, a business consists of distinct processes and protecting these processes from cyber risk is our raison d’être.

The BC/DR community has also done an excellent job of looking at mitigating strategies to improve organizational resilience. Strategies related to fault tolerance of components, fail-over, and high-availability architectures including active/active and active/passive configurations have their roots in approaches designed to improve RPO and RTO. In the aggregate, our BC/DR colleagues have produced a body of work that can inform how we look at our cyber programs with the ultimate goal of improving the operational resiliency of organizations.

Let’s take a look at how cybersecurity can improve resiliency. I’d like to recommend we spend a bit of time on the following:

♦  Defining, documenting, and mitigating risk

♦  Tying risk to the organization’s core priorities and organizational objectives

♦  Keeping executive management and the board of directors appropriately informed

 These three practices will help us to position our cybersecurity program in a manner that improves the resilience of the organization.

Defining, Documenting, and Mitigating Risk

CISOs would be well served to bring risk management front and center in their security programs. We cannot protect every system equally. Not all business processes, applications, and infrastructure are created equal. Similarly, not all employees have the same value to the organization. This inequality may seem obvious, but our security programs frequently don’t reflect this reality. Too many security programs attempt to apply ubiquitous security to all systems, infrastructure, and employees.

The consequences of a blanket, cover-all approach to security are challenging. Unless the organization benefits from an ever-expanding budget and nearly unlimited resources, the reality of a protect-everything-equally security program is watered down security. Critical systems are under-resourced and under-secured while we effectively overprotect non-critical systems. The root cause of this disconnect is fundamentally a lack of alignment with organizational priorities. A discussion that is risk-focused is the most effective means to avoid this dynamic.

Key to a successful risk discussion is for the CISO to capture and understand the organization’s overall risk appetite concerning the impacts on the confidentiality, integrity, availability, privacy, and even the safety of material business processes. These impacts, however, need to be more formally aligned with enterprise risk management and specific risk considerations for the organization related to financial, reputational, operational, and other higher-level risk considerations.

When done correctly, a risk-focused discussion translates detailed technical risk into business terms which senior executives and the board can more readily consume and act upon. Executive management and the board are concerned about the impacts of an adversary on the organization, its reputation, and its finances, even if they are not well-versed on the tactics, techniques, and procedures (TTPs).

CISOs should continually ask themselves: “What is it that I don’t know that I should know about this business process or initiative that could impact the confidentiality, integrity, availability, privacy, and safety of the process?” This open-ended question keeps the focus on considerations that could materially impact the organization. Returning to our colleagues in BC/DR, the BIA can facilitate this line of questioning. What dependencies and risk factors – notably from a cyber perspective – could negatively influence those processes that are most critical to the organization? Knowing these factors will help align your security program and architecture to those processes that the organization values most – as noted in the MAD and RPO/RTO.

Another, more direct but less structured approach to understand risk appetite across the organization is to simply ask colleagues in various departments and lines of business to clarify their areas’ priorities and key functions (e.g., business processes). This insight will facilitate the alignment of your security program to the organization’s core focus, effectively, what the organization values most. For the good of their security programs, CISOs must excel at understanding this business context.

Introduction

Incident response is the most visible function for a typical CISO. For good or for ill, it is the primary way CISOs are judged. Beyond the immediate impact of demonstrating the organization’s resilience to customers, management and employees, how an organization deals with incident response says a lot about its culture. Does the organization recognize the challenges and opportunities of doing business in the twenty-first century? Does management invest in and support the security hygiene and preparation it takes to protect long-term value delivery while competing in a digital world?

Bill starts by focusing the reader on the training and preparation that must be done, specifically triage training for the security team and situational training for the whole organization. Quickly recognizing and responding to incidents can be the difference between a minor disruption and a major breach. Communicating effectively during an incident is also critical to maintaining the confidence of the organization’s many stakeholders, and preparation is key to success here as well.

Matt reminds us of the ongoing yet still emerging convergence of information technology (IT) and operational technology (OT). The ability of errors in code or network misconfigurations to contribute to the physical harm done to a person or group adds a new dynamic to data protection. In addition to increased technical complexity, this now forces a level of due care that is new to many industries. Just as interactions between the physical and digital world are exploding in scope, so too are people becoming more aware of the peril of being an open book to merchants and criminals and demanding greater say over and greater protection for the use of their online identities.

Gary shows how organizations can demonstrate value in their incident response program by first understanding that the business must be the focus. Once the organization realizes that incident response is about staying in business, not playing spy-catcher and whack-a-hacker, investing in incident response becomes investing in the organization, its customers, and its people. He then walks us through building the incident response program and measuring its success.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  What is the business value of an Incident Response Program (IRP)?

♦  What are the processes to create an IRP?

♦  What are some methods to measures the effectiveness of an organization’s IRP and why is it important to the CISO?

Incident Response – a CISO’s Best Friend – Hayslip

I want to set the stage for us. In the early morning hours, as the CISO for a global software company, you are awakened from a deep sleep by the chirping of an emergency number on your smartphone. As you proceed to talk in hushed whispers, you are informed by your managed security services provider (MSSP) that their SOC analysts are reporting an anomalous incident in your organization’s primary datacenter.

The MSSP used the incident response communications tree and contacted the company network team and security liaison staff, who are now reporting they see suspicious network traffic and upon investigation have found evidence of a malware outbreak in several production servers. As you wake up and shift into troubleshooting mode, you receive more troubling information. This issue doesn’t affect just a couple of servers but has manifested itself as ransomware on critical production databases. With this information, as the CISO, it’s time to transition into your role as the Incident Response Team Manager and begin the activation of the company’s Security Incident Response Plan.

Cybersecurity leaders today know their roles have matured and they must align their departments and security programs to the business and support its strategic goals to be successful. However, one area many organizations and CISOs still need assistance with is incident response. In 2016, SANS surveyed 591 security professionals about the state of incident response in their organizations (Bromiley 2016). There was some good news – 76% of those security professionals had dedicated internal IR teams, an increase from the SANS 2015 survey.

However, there is still much work to be done. Approximately 21% said that their time to detect malware in their networks, or “dwell time,” was two to seven days, while 40% indicated that they could detect an incident in less than one day. Some other bleak statistics: malware remains the underlying cause of most reported breaches, at 69%, with unauthorized access seen as a rising menace due to attackers taking advantage of weak, outdated remote access and authentication mechanisms. This report noted that 65% of the security professionals surveyed were still dealing with a shortage of skilled personnel, and only 58% of organizations admit to regularly reviewing and updating their IR processes.

The report demonstrates that incident response, as a program, is in a state of change in organizations today and when there is a security incident, many lack the ability to lead a coordinated response to the event. I am sure there are reasons why organizations do not have formal incident response policies or documented incident response methodologies. Some companies focus on purchasing technology in the belief that when an event occurs, the purchased hardware and software will save the day. Unfortunately, they are missing a critical point – incident response isn’t about technology, it is really about business.

It’s About the Business

At its core, incident response is about an organization’s strategy and business processes, it is tactical and will incorporate stakeholders from many departments within the company as well as external partners. Incident response is an action plan for dealing with incidents like internal and external intrusions, cybercrime, disclosure of sensitive information, or denial-of-service attacks. In typical organizations, the CISO is tasked with developing the Incident Response Plan and managing the Incident Response Team. This is why the questions we will discuss focus on the business value of your incident response, the processes to follow for an effective program, and how the CISO can measure the effectiveness of their IR program.

Cybercriminals are successfully targeting and compromising businesses of every size across all industry sectors. This ongoing digital onslaught demonstrates the need for organizations to be prepared to respond to the inevitable data breach. They should guide their response with a methodical plan designed to manage a cybersecurity incident with the goals of limiting impact to business operations, increasing the confidence of external stakeholders, and reducing recovery time and incident remediation costs. These goals mean that organizations need to require their CISOs to create an incident response program tailored to the company’s strategic operations.

However, many organizations lose sight of their incident response program’s strategic value. Instead, incident response documentation describing how to act in the event of a breach is forgotten and soon out of date. The documentation quickly becomes ineffective for key decision makers; too generic, and unhelpful for making critical, informed decisions. I therefore chose the first question for our discussion to be about the business value of an incident response program. As CISO, there will be times when you will need to defend the resources needed for the incident response program, and you will need to be able to describe several business cases that demonstrate the value it brings to the company and its operations.

This leads us to our first question: “What is the business value of an Incident Response Program (IRP)?”

Cybersecurity incidents are on the rise and now frequently headline news around the world. Many of the recent attacks have brought severe damage to organizations of all types, including governments and international nonprofits. An organization with a mature incident response program would have a methodical course of action for responding to these attacks in a fast, effective, and comprehensive manner. However, many organizations do not see incident response as a mature process. Instead, they see it as a collection of disjointed practices and procedures, thus they prefer to contract it out to third parties.

How Incident Response Adds Value

To address this, I will discuss some of the issues companies see when looking at incident response and describe several cases that highlight how incident response can provide value to an organization. As we begin, some of the contention around investing in an internal incident response program is as follows:

♦  There are too many common definitions of what constitutes a cybersecurity incident. With this wide variety of interpretations resulting in organizations adopting different views on how to manage them. Many organizations consider it difficult to address this effectively and understand the level of incident response capability they require.

◊  Response – That is true for many companies when they first start the process of addressing incident response and allocating resources for their CISO to build an IRP. However, there are amazing references from both NIST SP 800-61r2 (NIST 2012) and ISO/IEC 27035 (ISO 2016) to begin this process, so it is not unattainable.

♦  There are different sources and types of cybersecurity incidents. Some appear to originate from minor criminal groups and produce annoying disruptions, others from major organized crime syndicates that result in business-ending events. Plus, there are so many types of cyber incidents, such as hacking, malware, or social engineering. All of this generates confusion, and organizations just want something that is manageable. Given all this, why not outsourceit to a partner who specializes in incident response?

◊  Response – There are always some incident response services that can be outsourcedto a third party. With that said, the business still has accountability for how it manages its assets during a breach and must be able to answer the questions of “reasonable care.” For example, did the organization implement reasonable security controls and follow industry best practices to reduce risk exposure as much as possible? If a company doesn’t have an incident response program, they are likely not meeting a “reasonable care” standard.

Even if a contracted third party does the primary work for the incident response program, the business still have an incident response plan. The plan will cover communication with its partners, what resources to activate for an incident, who has overall responsibility to manage the incident, and how and when to report its findings to executive leadership. In a sea of misinformation on how to deal with an incident, an incident response program provides the business clarity to reduce the incident’s impact and return business operations to normal.

♦  Many organizations do not understand their state of readiness; they lack insight into how they would respond to a cybersecurity incident. In fact, many organizations are typically not well prepared in terms of having any personnel assigned to an incident response team or providing training to grow sufficient technical skills for team members. Even if they have an incident response program, they lack clear policies that provide guidelines on how to identify a cybersecurity incident, investigate the incident, take appropriate remediation action based on the incident, and recover critical business systems.

Many organizations also don’t fully understand the location or use of their critical business data. They lack a complete picture of how their enterprise network topology is architected, and they don’t know all of their egress/ingress points to the Internet. Finally, many of them lack information on the incidents themselves. Having no incident response program or an immature one at best, they respond to an incident after it impacts the organization and rarely collect internal threat intelligence on when, where, and how the incident occurred.

◊  Response – An incident response plan, policies, and program provide a framework that enables quick decisions and provides a communication process to access critical third partieswhen needed. The IRP would have procedures to help team members know what they need to do, how to do it, and when to do it during a time-critical cybersecurity incident. The IRP process, led by the CISO, will also provide organizations with an understanding of the lifecycle of their data and how their networks are architected, and help in determining what event logs are considered appropriate for collecting and storage.

During the remediation process, the collection of event logs will enable team members to understand when, where, and how the incident occurred. Finally, the IRP helps the organization define their business priorities; it provides understanding about its interdependencies between processes, support systems, and partners, such as cloud providers or MSPs.

♦  Many organizations opt to purchase the services of properly qualifiedthird-party  Yes, this option can significantly help organizations. It can provide qualified personnel with the experience to handle cyber incidents more effectively and appropriately. However, the company must interface and work with these competent individuals because they need context into the organization’s networks, its data, applications, and business practices to be effective. Even having the full IRP process contracted out, organizations will still have to participate in a cybersecurity-related incident. There is no sitting on the sidelines.

◊  Response – Outsourcingto a managed security services provider (MSSP) to access more experienced, dedicated technical staff to respond to sophisticated cybersecurity incidents is prudent. If the organization lacks the resources to employ an internal IRP fully, then I would suggest a hybrid approach to augment those internal staff who will execute and manage the organization’s response to an incident. A hybrid approach is one in which the company has an incident response program, created and managed by the CISO, with members from across the organization and trusted external partners. The program specifies in detail the business’ response to particular types of incidents and documents when MSSP staff are required to assist in conducting technical investigations or performing post-incident analysis.

Typical business continuity/disaster recovery plans inadequately cover the impact cybersecurity incidents can have on organizations. These incidents can affect the ability to operate strategic business units and can lead to loss of reputation in a competitive industry and financial losses due to fleeing customers or third-party lawsuits. These are just some of the effects that a business can experience due to a cybersecurity incident if they have no IRP and are not prepared to defend themselves.

However, if an organization funds an incident response program they now have a platform to focus on upcoming security issues, facilitate the centralized reporting of incidents, and coordinate a response to those incidents. In fact, an IRP managed by the CISO can provide a platform to educate staff on security awareness, promote good cyber hygiene, and provide contacts to legal and criminal investigative units both internal and external to the business. I believe that all of these positive outcomes make the case that a mature IRP process provides value to any organization. Incident response is not about technology; it is about business and how the company responds using people, processes, technology, and data to defend that business.

Building Your Incident Response Program

As organizations begin to build their incident response capability, they will want to identify the best strategy for putting an incident response program in place. They will not only want to know what has worked well for others within their industry, but also want some guidance on the process itself and requirements they should follow to establish an effective incident response capability. With that, let us move on to our next discussion: “What are the processes to create an IRP?”

The primary objective of incident response should be to guide the incident response team members in a methodical process to respond to and remediate an incident. Focus this process on managing the cyber event in a methodical manner to reduce its impact on the company, reduce the recovery time for full operations, and minimize the costs to triage the incident. There are numerous questions that the CISO and the company will need to answer as they start the process of establishing an Incident Response Program (IRP).

Introduction

There is a fine line between incident response and recovery and resuming operations. To some extent, that line is only academically useful. The authors have covered many of the discrete activities in resuming operations in Chapter 14. Nonetheless, there is some discipline that is helpful in the immediate aftermath, both to make sure the incident is really resolved, and to learn and improve for a better response to the next incident.

Bill highlights two discrete activities that can be thought of as specific to resuming operations. First, it is important to realize that outside of the family of ransomware attacks, a major objective of a modern attack is persistence. Verifying that the recovered asset is truly back to acceptable baseline takes planning and diligence. Second, as is the case while the incident is underway, communication during the recovery phase is also critical. All stakeholders, including customers, suppliers, law enforcement, and employees, need to know what is expected of them.

Matt takes the reader through a hypothetical situation that a healthcare provider, in this case a hospital, might face. He recognizes that for many people reading this book, you might not have been through an incident before and may not have inherited a mature program. He uses that hypothetical to challenge the reader to be capturing lessons while in the moment with an eye toward building the muscle memory that the organization will need to improve operational resilience.

Gary provides a series of planning guides to help the reader prepare for the inevitable and then walks the reader through the activities. The reader should find it helpful to see how the planning is put to use and benefit from the reminders about critical information to capture in the moment. As Gary has pointed out throughout his essays, the CISO can never stop learning. That learning discipline is what allows the CISO to continue to push their organization to improve.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  What steps should an organization take to prepare for a data breach?

♦  During a data breach, what operations should the CISO be aware of and possibly manage as a member of the organization’s business continuity effort and leader of the incident response team?

♦  What steps should be followed to resume normal operations and resume data breach management efforts?

Getting Back to Business – Bonney

Now that the incident has been detected, contained, and eradicated, it’s time to recover and resume operations. It’s important to distinguish between recovering the business process and recovering the asset. Certainly, many business processes will be entirely dependent on the availability and integrity of a specific set of critical assets. But keeping the focus on the business process as your key recovery objective will allow you and your organization to make crisper decisions about when to use backups, alternative sites, or other options defined in your recovery plans.

As with other disciplines that we’ve discussed, some of the ground we’re going to cover in this chapter has traditionally been within the CIO’s purview. But as we’ve stated before, in today’s digital business world the most likely cause of downtime requiring recovery operations are cyber-related events, and that’s going to place the CISO front and center. It’s important that the CISO can take responsibility as needed and is working with the same recovery objectives as the CIO.

Planning and Preparation 

Here again, the planning you have done in preparation for recovery is critical. We have already established that incident response does not begin with the incident. It begins in the preparation phase when you are taking inventory of your business processes and systems and creating RTOs, RPOs, and the sequence of eventual recovery activities. Each business process should have a runbook, validated by the business process owner, that details how to recover the business process, including decision criteria for asset recovery versus switching to backup or alternative assets.

It is critically important that the business process owner is intimately involved in the creation of the recovery runbook and the execution of the recovery runbook. The business process owner will need to balance internal stakeholder and external customer expectations regarding service delivery and contractual obligations for uptime and service availability. They will do this by using the RPO and RTO referenced in Chapter 14 as guideposts for prioritizing recovery activities and deciding between restoring primary assets versus switching to backups.

Another key aspect of your preparation activities is making sure your executive team knows that you are constantly working on incidents. They need to understand that you are continually evaluating log files, investigating outages, and tweaking your monitoring tools. Your executive team should know how incident response works and that it is part of normal activity. You’ll want to present it as a routine activity and a continual process that addresses high-level investigations and specific incidents and outages. Reporting on some amount of the activity on a regular basis will help familiarize them with the work that will be required while recovering from high-profile events.

Having the executive team receive these periodic reports, act on them, and participate in communications and recovery activities will prepare them for the more challenging high-profile events, when you will need their support and when it’ll be vital for them to pitch in by working their human network.

The reason this is important is that when we are stressed we rely on habits; quick, easy-to-remember responses are best for stressful circumstances when we are under pressure. The reasons that airlines trust pilots with ever more complex aircraft flying more passengers over greater distances as they gain experience and the military drills continuously are to form habits that will take over in times of stress. For your executive team to react in a positive and supportive manner and not distract the team with knee-jerk reactions, they need to be part of the routine incident management process.

Recover and Resume 

The recovery steps include restoring the assets, validating the assets, determining when to place the assets back in service, monitoring the assets, and communicating the status, both at the business process and incident level. Restoring the assets will be the responsibility of the business teams and the IT team, but the CISO and the Information Security team also play critical roles. As you bring assets back online, InfoSec needs to assist with validation and monitoring.

However, before any of these activities can take place, it is essential that your organization’s process for determining the regulatory or contractual impact of the outage or disruption is executed to catalog and, if necessary, that you sequester all assets needed for forensics activities and follow-up analysis. This review can be required to assist with regulatory action (for instance, a record request for a high-profile breach or outage) or to help the organization with its defense against any litigation instigated by authorities, customers, or partners. It is more than a matter of convenience. In many cases, the regulatory obligations under which you operate or the contracts that specify the services you provide to key customers spell out the need to preserve records and evidence and the failure to do so can potentially subject the firm to additional legal jeopardy.

Here again, it is critical to work with your legal team to appropriately handle records and systems, make detailed notes of what, if any, compromise has taken place against sensitive records or systems, and ensure you can complete any subsequent analysis. At a minimum, copy all logs and all records involved in the incident, and preserve the state of any systems (do a snapshot of virtual machines, for instance) involved. Care must be taken to handle sensitive records according to the appropriate data handling policy, even (and especially) when systems are technically offline.

For example, a simple downtime event can turn into a breach notification event if recovery personnel inadvertently review restricted PHI records while reviewing for record integrity. Certain designated personnel are likely empowered to execute specific pre-approved record integrity validation routines. Make sure this is how the records are validated, so you don’t run afoul of data handling regulations. Remember that when offline, the application safeguards you or the vendor designed into the system may not be functioning. Without these controls, you may inadvertently expose records to inappropriate personnel. Make sure to account for this with your incident response and recovery runbook to avoid adding to your list of problems.

Introduction

Although we are covering them in one chapter, forensics activities and post-mortem activities for cyber incidents are entirely different. We’re going to repeat a passage from the introduction to Chapter 14: while it’s helpful to break the entire incident response discipline into a series of discrete phases so that each can be described individually to assist with training and the command and control of response activities, it is rarely clear-cut when one process ends, and the next begins. There is often significant overlap, and as new information emerges, it is usually necessary to revisit a phase previously thought completed. For instance, while in recovery, monitoring activity may detect the presence of indicators of compromise identified for the current cyber incident and that may send you all the way back to the containment phase.

Bill draws the distinction between forensics for law enforcement versus what an organization might do for internal investigative value. Depending on your industry and the specific details of a breach, preserving evidence may be essential. Regardless of your organization’s desire to use the courts, regulatory and contractual obligations may force you to preserve evidence and establish the chain of custody. Bill goes on to discuss how to incorporate post-mortem reviews into your process for continual improvement.

Matt helps the reader prepare for forensic activities, including working with your legal team, law enforcement, suppliers and anyone else who will need to know in advance what actions they can and cannot take and what assets, physical and digital, need to be sequestered. He then reviews the lifecycle of forensic analysis so that the organization can be prepared to conduct such an analysis by pulling together the right combination of internal and external resources.

Gary begins his discussion with a review of forensics methods that apply to all layers of the stack, including the network, system, software, mobile, and IOT. He then guides the reader through the decision-making process and the requirements for both building a forensics capability in-house, including a build-out of the lab, and staffing a forensics team. The caution to the reader is that this can be expensive, and the needs change continually, so be prepared for an ongoing investment.

Some of the questions the authors used to frame their thoughts for this chapter include:

♦  What is digital forensics and what value does it bring to the business?

♦  What resources are required to develop a digital forensics lab and should the CISO build one?

♦  What roles and resources are needed to field a digital forensics team?

Planning for Forensic Investigations – Stamper

Unless your organization and your security team are quite large, it’s unlikely that you will have dedicated expertise and resources available to facilitate forensic investigations of security-related matters, notably breaches. Nevertheless, there will be scenarios where having access to forensic capabilities will be necessary. Similar to the incident and breach responses, planning for forensic analysis in advance should be an essential priority associated with the CISO’s security program, even for smaller organizations. Let’s take a look at some of the core planning required to prepare you for when a forensic analysis is needed.

Why do we need forensic capabilities as part of our overall security program? There are two principal reasons. First, forensics supports legal claims and actions. Essentially, we use forensic analysis to determine if a crime has been committed and, ideally, determine attribution and present evidence that is legally admissible to support our claim in a court of law. This analysis can be required when there are disputes related to intellectual property, rogue employees, or corporate espionage. Another reason we might need forensic analysis is simply the matter of determining what took place and how – documenting “packet truth.” Forensics provides a great set of capabilities to evaluate the “history” of our environment (what took place at each stage or phase of the kill chain) and how actors who were not authorized made changes to that environment.

While there is overlap between these two capabilities, there are certain conditions precedent that need to be defined. If a forensic analysis is going to be used to support legal proceedings, effectively legally-defensible analyses, the activities must be legally authorized. Few things are worse than having evidence of a crime that would corroborate your case only to have the evidenced determined to be not legally admissible because the forensic analysis was not appropriately authorized, or the chain of custody did not offer the right assurance. To ensure proper chain of custody practices, you need to plan how you will handle forensic evidence (more on this below).

Preparing for a Forensic Analysis

When preparing for forensic analysis, make sure that you speak with your legal counsel and outline some of the scenarios where forensic analysis would be valuable. As discussed in Chapter 15, we should anticipate certain types of incidents. Revisit the list of potential incidents that you have planned for and determine what kind of forensic analysis to use in these scenarios. Recognize that just like threats and risks, evidence can come from many potential sources.

Evidence can be left behind by perpetrators outside of your organization (such as APTs, criminal elements, corporate espionage, state-sponsored actors, in-laws, among other unsavory actors). It can originate from inside the organization (for example, disgruntled and rogue employees). And it can come from your supplier and vendor ecosystem (this could include third-party service providers, “vetted” independent contractors, and the manufacturers and suppliers of systems, software, and hardware used in your environment). Anticipate needing to collect evidence outside of your “four walls,” and plan how you will get it. Further, with the advent of connecting more operational technology (IoT, ICS, and SCADA) to our networks, it’s important not to overlook these systems as potential sources of evidence.

Once you’ve evaluated these potential sources, coordinate a discussion with legal counsel to understand the repercussions of gathering evidence from these sources. Work out a process that is consistent with your organization’s priorities (e.g., attribution and prosecution when cases arise or – potentially in conflict with those two items – the restoration of services). For scenarios that involve the collection of evidence used to determine if there was a rogue insider involved, engage both human resources and legal counsel in this process.

While in the United States there are limited expectations of privacy in the workplace, we cannot say the same for organizations that operate outside of the U.S. As a case in point, privacy in the workplace in a European context is expected by employees and legally enforced. Knowing what can and cannot be collected in support of an investigation in advance is critical. Where legal privacy protections preclude the collection of the evidence systematically, you’ll need to look at alternative approaches such as user analytics that anonymize activity that can be unmasked subsequently with appropriate legal justification (e.g., a search warrant).

Equally important, the collection of evidence needs to be legally authorized. This authorization requires that practices are consistent with applicable laws and regulations. In the United States, Federal Rules of Evidence govern this process. Changes as recent as December 2017 to section 902, subsection 14 (902(14)) reflect the evolving nature of digital forensics and are focused on streamlining the admissibility of electronic evidence by standardizing certain practices and expectations.

Specifically, the hashing value to determine the integrity of forensic evidence (essentially a presumption of authenticity). Documented and strong chain-of-custody practices should be front and center in your forensics program. Bottom line, CISOs should proactively work with their legal counsel to pre-validate evidence collection procedures in a manner consistent with the organization’s objectives, priorities, and legal requirements.

As noted above, it’s important that your forensics program is also used to determine the fact pattern of incidents where the end game is not attribution and legal proceedings but rather improvements to the security practices and architecture of the firm. Under these circumstances, forensic analysis is used to make internal improvements to the security program and reduce the risk of a similar issue taking place in the future.

Beyond collaborating proactively with legal counsel and HR, a good investment in your forensic preparation would be to meet with your local FBI office or your local sheriff’s or police department’s cybercrimes units to validate their requirements when they are working a case. Learn what they would need from your organization. Many law enforcement cybercrime teams are real experts in forensic analysis and have learned to investigate many technically-distinct scenarios – frequently with open source tools, given their budget challenges.

While they are certainly not attorneys, you may also gain some insights from them around what you can and cannot obtain without authorization. In meeting with your local or regional law enforcement cyber teams, you may also learn more about the tricks of the trade and develop some valuable relationships with the agents and teams that may be called upon when you have a case.  It’s better to establish these relationships sooner rather than later, so be proactive.