CISO DRG Vol 2: Chapter 16 – Recovery and Resuming Operations

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.

Bill Bonney

CISO DRG Vol 2: Chapter 17 – The Aftermath: Forensics and the Value of Post-Mortem Reviews

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.

Matt Stamper

CISO DRG Vol 2: Chapter 18 – Building Your Strategic Plan

Introduction

While drafting and editing the material for this book, we thought we could offer additional value by providing an essay on each topic by all three authors, independently edited, to preserve their unique perspective and voice.

It is a technique that was intended to provide multiple viewpoints that would both explore the topics more thoroughly and provide options for readers to use these different viewpoints to help them solve different problems depending on their needs at the time.

We appreciate your tolerance with our construct, and hope we’ve achieved what we intended. In this final chapter, we’ve decided to stitch together our combined perspective and present an integrated essay on building your strategic plan.

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

♦  What components should the CISO use in developing their cybersecurity strategic plan?

♦  How should the CISO align their strategic plan to the organization’s business objectives?

♦  What steps can the CISO use to leverage the cybersecurity strategic plan for future growth?

Strategic Plan – Bonney, Hayslip & Stamper

How Did I Get into This?

There are many ways you may have come into this responsibility. In larger companies, you may have been the subject of a recruiting process or an internal vetting process. You may be replacing someone or inheriting an issue with board visibility. In this case, you’re probably going to have something in place. In the best case you can carry forward most of the existing plan, but you may be faced with a complete overhaul.

If you’re coming into the position at a smaller company, you could still be subject to an internal vetting process, perhaps as the former “network” or “compliance” person. In this case, you’re likely to have at most a bare skeleton of a plan. It might not be much more than a budget or an organization chart, possibly just a list of services the other IT managers are looking forward to getting off their plates.

We are drawing attention to the latter condition because as we mentioned in the preface to Volume 1, cybercrime will continue to move “down the food chain” as more relative economic value is managed via interconnected computer networks. As a result, many smaller to medium-sized organizations have requirements to have specific security practices and capabilities in place given regulatory obligations or increased diligence necessitated by the organization’s customers and other stakeholders. CISOs hired or promoted by these companies will be scrambling to build security programs from scratch.

We’ll cover the building blocks of a sound strategic plan, aligning the plan to the organization’s business objectives, and using the strategic plan as a roadmap for the future of your cybersecurity function. While we walk through developing the plan, we’ll continue to offer both a complete treatment grounded in best practice and reveal our thought process to maintain the instructional approach to ensure this is helpful to CISOs just stepping into the role.

Structure of Your Strategic Plan

The cybersecurity strategic plan needs to be concise and easy to understand and reflect realistic expectations for funding that are in line with what the organization can afford. The plan document is not the place to surface a 300% increase in funding. That is a discussion that should already have taken place between you and the management team and, as appropriate, the board. The document should be organized in a methodical manner that makes it easy for the stakeholders to read and its objectives should be aligned with current business functions and processes. We recommend the following structure:

1.  MissionStatement – This is the declaration of the organization’s core purpose that normally doesn’t change over time.

Example: Develop and execute a proactive, company-wide security program based on Organization’s strategic business objectives.

2.  Vision Statement – An aspirational description of what the organization would like to achieve or accomplish in the mid-term or long-term future.

Example: Incorporate a continuous security mindset into all aspects of our business functions.

3.  Introduction – This is a statement describing the business and the environment in which the security program currently operates. The executive leadership team typically will use this section to communicate broad information about the cybersecurity program and its critical role in the strategic plan for the business and key stakeholders.

4.  Governance – This portion of the document will explain how the strategic plan will be implemented, who will audit the process, and what committees or personnel will be part of the overall process of assessing its effectiveness and recommending changes to it over time. This is a long-term plan, and there should be a documented process of how this plan will be managed and audited and who will be responsible for it over time.

5.  Strategic Objectives – The strategic objectives define how the cybersecurity organization should invest its time and resources to manage the security risks discovered in the assessment and SWOT data previously described. In laying out the objectives, the CISO is assuming there will be sufficient resources for people, processes, and technology. The objectives typically are arrayed over a one- to a three-year timeline. Understand that timelines can be shortened with additional resources. Each objective will have several initiatives, derived from the analyzed security gap data, which need to be completed to achieve the objective.

Objective Examples:

♦  Improved Security of System and Network Services

♦  Proactive Risk Management

♦  Business Process Enablement

♦  Security Incident Management

Your objectives will typically mirror the gaps found in your assessment and the improvements or investments you want to make in currently effective processes that you want to continue to mature.

6.  Key Initiatives – An initiative will state what objectives it satisfies when completed, it will have a description of the security/risk issues it will alleviate, and it should state the benefits it brings to the business when completed.

The following is an example of an initiative:

Initiative 1 – Security Policy, Standards, and Guidelines Framework

Enables Objectives – Improved security of system and network services, proactive risk management and crisis and security incident management.

Description – Develop, approve, and launch a suite of information security policies, standards, and guidelines based on the ISO/IEC27001 code of best practices for information security. These policies will formally establish the organization’s Cybersecurity Program and set forth employee responsibility for information protection. The policy, standards, and guideline framework will also take into consideration the multitude of Federal, State, and Industry regulations that govern the use of personal, financial, customer, and vendor data managed by the business.

Key Benefits

♦  Clear security baselines for all departments

♦  Policy-based foundation to measure results

♦  Consistent application of security controls across the enterprise

Developing Your Plan

We’ve mentioned throughout these two volumes that how you approach any task is going to depend on the needs of the organization. Part of your value to the organization is that you bring your experience and your human network to help the organization assess and adjust to reality, and plan for the future. As with other divisions within your organization, your strategic plan should address your current state cybersecurity practices, near-term objectives to be addressed in the next 12 months, midterm objectives to be addressed in the next 18-24 months, and long-term objectives to be addressed over the next three years.

We’ve also mentioned that cybersecurity is not something you can do in a vacuum. It is very much a contact sport. Resist the temptation to hide away and work on your plan in isolation. Engage with your business partners and involve all of your stakeholders in the process of identifying the priorities for your strategic plan. The role of the CISO is to help the organization reduce the inherent risks of its business model and mitigate the residual risks that cannot be avoided. You exist to serve the business, not the other way around. Determine what the management teams need and what the board needs from your cybersecurity program and develop a strategic plan to deliver that.

Recognize, however, that these stakeholders may not be familiar with the more “formal” language of enterprise risk management (ERM) or other risk-management practices we’ve expounded on in the CISO Desk Reference Guide. The founder’s family or close-knit executive teams often dominate many smaller to medium-sized organizations. They are confronting globalization, new competitors, enhanced regulatory oversight, and several other factors that strain their capabilities to understand what the risk environment is for the organization. Tailor your discovery to your audience. Your job is to help these stakeholders navigate this environment in a manner that is financially prudent for the organization, while also reflecting the security “debt” that you may have inherited.

In each of the previous chapters, we’ve given you a series of assignments that, taken together, should provide the bulk of your discovery. The next step is to determine how to apply this information and come up with a plan that emphasizes your strengths, shores up your weaknesses, and buys you the time you need to implement the program the organization needs. One tool you might consider using is a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis. In figure 1 we show a typical set of definitions for a SWOT analysis that you can use to assess capabilities.

Bill Bonney

Gary Hayslip

Matt Stamper