Think like a Responder

Take each step of this chapter from the perspective of someone working in your company’s security operations center. It doesn’t matter if your organization does not have a physically separate SOC or an officially designated set of people who are the SOC team complete with its leaders and responders. It does not matter if your “normal” IT department or team handles all of the network operations, IT security tasks, and help-desk-like anomaly investigation, response, and escalation processes. Think as if you run the SOC. Own that SOC as a mental set of resources, frameworks, and responsibilities. Take off your planner and architect’s hats and start thinking in the near real time. “Job one” of the SOC is to alert management and leadership to situations and conditions that may require urgent or immediate decisions that can keep the business operating—or ensure its survival—in the face of information security risk events.

If your organization already does have an security operations center (SOC) or has otherwise formally designated SOC-like roles and responsibilities, that’s good news! Grab a copy of their procedures, their training, and their resourcing plans, and use them as a starting point and checklist as you put this chapter to work for you.

Many organizations will formally define the team of responders who are called into action when an information systems security incident or other information systems emergency occurs. Known by names such as computer emergency response team (CERT), computer incident response team (CIRT), or computer security incident response team (CSIRT), these teams are called into action by the SOC’s alerts to management that an urgent situation is in progress. (I’ll use CSIRT throughout this chapter to refer to any such team of incident responders.) The SOC does not own either of these teams (usually), and unless the incident is small in scope and can quickly be handled by the SOC team, most incidents are turned over to the CERT or CSIRT for ongoing response activities. So again, in the spirit of putting this chapter to work for you, it’s time to think and act as if you own the CERT or CSIRT too. During an actual incident, you might be called upon to perform many tasks that start as SOC responsibilities but transition to the on-scene management, direction, and control of the CSIRT.

Physical, Logical, and Administrative Surfaces

Keep in mind that your organization and its information systems present a combined set of physical, logical, and administrative attack or hazard surfaces, places where hostile action, accident, or natural causes can attempt to inflict disruption, damage, or loss upon the organization and its objectives. By the same token, these three surfaces present you, their defender, with powerful opportunities to observe, gather data, make decisions, and respond. Events that might be security incidents in the making can and do happen at all three of these surfaces, and the more complex and pernicious attacks combine physical, logical, and administrative actions throughout their kill chain.

Think of the physical, logical, and administrative surfaces as comparable to the data plane, control plane, and management plane of your networks: each layer or plane presents opportunities to attacker and defender alike. And since you already know your own systems architectures and understand all of these views of them, you should be several steps ahead of your potential adversaries.

Incident Response: Measures of Merit

“If you can’t measure it, you can’t manage it.” This bit of commonsense management wisdom should focus our thinking on what might be the most important question this chapter can help you answer: how do you know you’re getting better at incident response?

In many information security professional circles, discussion about this question focuses on what may be the three most vitally important metrics.

• Mean time to detect (MTTD)
• Mean time to respond (MTTR)
• Mean time to eradicate (MTTE)

The MTTD story is not an encouraging one; in 2017, research by the Ponemon Institute for IBM Security showed it had fallen from 201 days to 191 days, but since then, many sources report it is now pushing upward of 220 days to detect an intrusion. (Ponemon’s report can be found at https://www.ibm.com/downloads/cas/ZYKLN2E3.) MTTR was last reported in 2017 as 66 days; that’s nearly 10 months to detect and contain an intrusion. Industry average mean time to eradicate estimates are hard to come by; even if MTTE is in the 30- to 60-day range, you still have a serious problem on the front end of this timeline.

Note the metric that isn’t in this conversation: mean time to repair or remediate. The issue here is that depending upon the impacts of an incident, organizations might take days, months, or even years to “recover enough” to consider themselves more or less back to normal. It’s also worth considering the number of organizations that get put out of business by a serious information security incident (and what number do you put in to represent the time to repair when you go out of business?). Perhaps, too, it’s worth noting that the repairs and remediation are not usually the responsibility of the information security specialists; it’s the rest of the management and leadership team that have to make the hard choices about what to repair, and on what kind of timeline, and then get the money, people, and other resources lined up to achieve that desired remediation target.

Your job is to find ways to make the MTTD and MTTR for your organization drive toward immediate. In a 2015 summit report for SANS Institute, Christopher Petersen notes that most organizations already have, on their own networks and systems, all of the threat intelligence data that they need to provide much more timely indications and warnings of an intrusion or incident in the making. That I&W problem—finding the right indications and translating them into useful, actionable warnings—is probably where smart investments can produce high-leverage returns by reducing those metrics and by giving you more focused, actionable alarms about threats becoming incidents. (Petersen’s report can be found at https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493840823.pdf.)

The Lifecycle of a Security Incident

Traditionally, the incident response lifecycle consists of six major phases of activity: preparation, detection, containment, eradication, recovery, and post-incident analysis and improvement. Chapter 3 put this cycle in the context of the planning decisions that senior management must make, which start with translating risk appetite into measurements such as maximum allowable outage time limits. Figure 4.2 builds on Chapter 3’s use of quantitative risk assessment time frames to put these major phases of incident response activity in context.

It’s important to realize that, as Figure 4.2 shows, there are no hard and fast boundary points between these large phases of activity. Similarly, within each major phase of activities there’s an ebb and flow of effort, as you shift focus and effort from subtask to subtask or from issue to issue. It is during detection, for example, that you go from sifting through signals to declaring an information security incident alarm, by way of recognizing an event or series of events and subjecting them to further analysis. Notice, too, that the cyclical, backward-chaining, or iterative nature of incident response isn’t shown in gory detail on this flow. (Imagine, if you will, multiple APTs at various stages in their kill chains, as they separately attempt to reconnoiter, penetrate, take command, and exploit your systems against you. You need to detect each skirmish-level attack attempt and deal with it, capturing what that experience has taught you into your ongoing efforts to detect and respond to other activities.) Finally, too, it’s important to realize that sometimes there is a lot of just plain waiting involved, whether waiting on resources to be available, training to be completed, or (shudder!) for an incident to occur.

What’s also not explicitly shown in Figure 4.2 is the never-ending cycles of learning that the SOC team and the organization as a whole must engage with throughout. Initial assumptions are made during initial preparation and during each incident response. Those assumptions get tested (often to the breaking point) by reality; the organization either learns from watching those assumptions fail or continues to be vulnerable to repeated attacks that exploit those flawed assumptions.

Let’s get into the details using a checklist borrowed from NIST SP 800-61 rev 2 as the road map.

Preparation

Getting prepared to respond to incidents starts with planning; then, of course, you must gain management’s commitment to provide the people, funding, tools, connectivity, and management support necessary to achieve the goals of that plan. One useful approach is to start with an incident handling checklist as your “shopping list” of milestones in that plan. NIST’s Incident Handling Checklist, shown in Figure 4.3, is a useful place to start. It is designed to be used in real time, incident by incident, reminding your watch-standers and first responders of key steps to perform, data to gather, or decisions to make, phase by phase, as they respond to an unauthorized penetration or other attack. You can use this same checklist as your template to plan and prepare with, by adding columns that prompt you (as preparation planner) to:

• Estimate how long it will take to accomplish each task.
• Identify needed resources, such as digital forensics workbenches, security information and event monitoring and analysis tools, workspaces, or people.
• Identify key decision points, which provide management with critical insights into your readiness preparation.
• Record the accomplishment of each preparation task, along with any action items or open discrepancies.

At each step in the checklist, ask these six questions: who and what do you need; where do you need it; by when; why; how are you going to get it in place, on time; and how will you measure or demonstrate that you’ve successfully completed this step in the checklist?

One key question to ask, step-by-step in the checklist, is whether an administrative control such as a policy, procedure, or guideline needs to be issued in support of that step. Written administrative documents are either directive, instructional, or advisory in nature; all are important, but the policy documents provide the best opportunity for personnel accountability. Policies set the constraints and expectations on employee behavior and direct affected employees to comply with them; they also provide the legal framework for disciplinary action, changes in job duties, or loss of a job altogether for employees who cannot or will not comply.

NIST breaks its checklist down into three broad categories; these may be useful as guideposts when you consider the current incident response capabilities and state of the practice within your organization. This checklist-focused planning process is also useful to use when auditing or assessing your current incident detection and response capabilities and practices—simply add to it, row by row, as you discover significant gaps in your end-to-end ability to prepare for, detect, contain, eradicate, recover from, and learn from incidents of all types.

The same checklist that you use to develop your preparation plan can and should be used to plan and conduct your response team initial training, as well as ongoing refresher or proficiency training. Clearly, if there’s a task on your checklist that you’ve not trained someone to do (or that you cannot identify who’s responsible for getting that task done), you’ve found a gap.

Detection, Analysis, and Escalation

First and foremost, remember why you’re on the SOC: to enable your organization’s senior leadership and management to make informed decisions about emergency or urgent actions to take to protect the organization from loss or impact. The SOC doesn’t unilaterally decide to activate a backup alternate operations location or halt business operations; what it must do instead is escalate the event and the need for an urgent decision to previously designated responsible managers and leaders—or to the next rung in the reporting chain in their absence. Your SOC roles and responsibilities will provide you with clear guidance on what issues to escalate and to whom; your procedures should also clearly define what you must do in real time and how to escalate the fact of taking those actions to your responsible managers and leaders.

Next, remember that you’re not only leading the technical charge to protect your organization’s information systems and get them back into action, but you’re also a vital part of protecting its legal capabilities to respond and recover. Those legal responses will in all probability depend upon evidence that points to who is responsible and in what capacity; your actions during containment, eradication, and recovery can significantly enhance your organization’s legal abilities to respond or all but erase them.

Watching for Kill Chains in Action

Let’s take a closer look at the kill chain concept shown in Figure 4.4, which was introduced in Chapter 3, and look more closely at the kinds of outputs your SOC team members need if they are to detect, characterize, and respond to a security incident or an intrusion promptly.

Any kind of surveillance, monitoring, or control system can produce a number of different types of signals, which are the observable results of an event having taken place. Table 4.1 illustrates some of these types of signals and the types of events they might be associated with.

Signal Type	Meaning	Examples of Causes	Degree of Confidence	Urgency
Precursor	Suggests that a security-related event might occur in the near future	Local area social/political unrest; government threat condition warnings	Low	Low
Indicator	Change of state in a designated systems element	Server successful reboot; User privilege elevation; file deletion	Moderate (can be forensically verified)	Depends upon security alert needs
Alarm	Systems element conditions out of limits, or critical events have occurred	Server halt; ISP connection fails to respond; switchover to backup power	Medium to High (usually can be cross-checked with other signals in near real time)	High: Corrective Actions may be needed immediately
Telltale	An important or hazardous event has occurred or is in progress	Server started shutdown or reboot; system updates being pushed	Medium to High (usually can be cross-checked with other signals in near real time)	High: If unexpected, may be an IOC
Indicator of Compromise	Security posture of systems or elements has occurred	Suspected malware detected; Missing or corrupt security/server logs causing server to stop; Unauthorized attempts at privilege elevation	Low to High (dependent upon monitoring technology and strategy)	High: Incident Response Procedures should be invoked

Of the five types of signals in Table 4.1, only two—precursors and indicators of compromise—are presumed to be related to some kind of information security event of interest.

Indicators, telltales, and alarms by design are calling attention to an event that someone ought to pay attention to, but it will take further investigation and analysis to determine whether the signal is crying out for a repair team, a security response, or a simple acknowledgment of its occurrence. Telltales are a case in point: such signals are generally associated with significant changes in the status, state, or health of the system or of major subsystems and elements, and they are often related to complex sequences of events. They also are generally accepted as high-confidence, unambiguous evidence that the event they are related to has happened. A scheduled push of access control data, security policy settings, or a software update might generate a telltale signal to the SOC so that the on-shift crew is aware that this event has started. Progress indicators may be sent to the SOC team as this task progresses, and a final telltale would indicate successful completion. They can then verify that this is a planned, authorized event, and if it is not, they can take appropriate action to correct it. Similarly, indicators and alarms can be calling attention to equipment or systems malfunctions regardless of their root cause.

By contrast, indicators of compromise (IOCs), which should definitely be high on your priority list of security concerns, are typically generated by specific systems-security-monitoring technologies, such as an anti-malware or an intrusion detection and prevention system. Some of these indicators may be clear, unambiguous, and irrefutable. Immediate incident response action should be taken for these types of indicators. Other IOCs may be of lower confidence, requiring additional investigation or analysis before the SOC can declare that a compromise event may in fact be taking place and invoke the incident response procedures to characterize, contain, and respond to it. Precursors may come from threat information sharing communities or even from the news media, and they generally do not convey sufficient information or confidence to act upon. Where do these signals come from? Think about the monitoring and assessment capabilities that you have set up and the data sources that drive them. Chapter 3 provided you with shopping lists of systems, servers, platforms, applications, and devices that can provide you with rich sources of status, state, health, and alarm indications data. With Figure 4.4 in mind, ask yourself: which of our systems elements might be trying to tell me that something’s gone wrong with it? Start this by focusing on the types of events that steps in an attacker’s kill chain might be trying to accomplish, such as:

• Input buffer overflows that indicate attempts to inject SQL or other script commands into a web page or database server.
• Antivirus software detects that a device, such as an endpoint or removable media, has a suspected infection on it.
• Systems administrators, or automated search tools, notice filenames containing unusual or unprintable characters in them.
• Access control systems notice a device attempting to connect, which does not have required software or malware definition updates applied to it.
• A host, server, or endpoint device does an unplanned restart.
• A new or unmanaged host or endpoint attempts to join the network.
• A host or an endpoint device notices a change to a configuration-controlled element in its baseline configuration.
• An application platform logs multiple failed login attempts, seemingly from an unfamiliar system or IP address.
• Email systems and administrators notice an increase in the number of bounced, refused, or quarantined emails with suspicious content or ones with unknown addressees.
• Unusual deviations in network traffic flows or systems loading are observed.

If events of those types do not correlate with administrative information—if they are not planned and approved configuration changes (that might result in restarts of systems) or are not the legitimate actions of known, authorized subjects—then you have an event of interest on your hands.

Now, step back from that set of events, and ask what indicators (or alarms) should be observable and reported to your SOC to help you recognize that a possible security incident is happening. Figure 4.4 illustrated some possible indicator events; think these through for your systems to help you determine your needs for event-specific alarms.

In some cases, your desired tell-tale sign is only going to surface from analysis, and potentially deep analysis at that. A data exfiltration attack, for instance, might be using a series of bogus or compromised accounts to initially clone copies of its desired data assets and then fragment, encrypt, and package them for transmission outside of your systems. Each of these steps could be done record by record (if the attacker is that patient); traffic pattern anomaly recognition might not find it for you in such cases. Only a thorough review, account by account, of everything it has been doing lately might find this for you.

It’s often assumed that the incident response process cannot begin until an incident is detected; the types of risk events examined at the start of this chapter highlight a potentially devastating counter-example, however, with incidents that you become aware of only when someone outside of your organization tells you about them. Even then, investigating what has happened is still quite similar to detecting that something is happening: you have to wade through a tremendous number of event-level signals to find the real indicators worth worrying about.

Let’s consider some of the near-real-time aspects of constant vigilance.

Containment

Containment and eradication are the next major task areas that the CSIRT needs to take on and accomplish. As you can imagine, the nature of the specific incident or attack in question all but defines the containment and eradication tactics, techniques, and procedures you’ll need to bring to bear to keep the mess from spreading and to clean up the mess itself.

These two steps are also the ones that could have the greatest impact on the success of any subsequent forensic investigation. Take advantage of the time you have right now, while you’re not in the middle of an incident response action, to make sure that your organization has the forensic aspect of containment and eradication thoughtfully considered in its plans. Those plans should address questions such as:

• How does forensic triage relate to incident severity level (or security incident triage) with respect to this incident?
• How does the SOC team determine whether a system component (a server, endpoint, network device, or other) can be isolated without corrupting information in it that may be evidence the investigation needs?
• Are there forensic triage procedures in place to determine which systems components must be restored to operational condition as quickly as possible and therefore need to have forensic information collected from them during the incident response? (The rest, presumably, can stay contained or idle until further forensic triage efforts can determine which ones need to be imaged and which ones can be released back to operational use.)
• Are the SOC team or incident responders trained and equipped to conduct forensic triage efforts as part of containment and eradication?

More formally, containment is the process of identifying the affected or infected systems elements, whether hardware, software, communications systems, or data, and isolating them from the rest of your systems to prevent the disruption-causing agent from affecting the rest of your systems or other systems external to your own. Pay careful attention to the need not only to isolate the causal agent, be that malware or an unauthorized user ID with superuser privileges, but also to keep the damage from spreading to other systems. As an example, consider a denial-of-service (DoS) attack that’s started on your systems at one local branch office and its subnets and is using malware payloads to spread itself throughout your systems. You may be able to filter any outbound traffic from that system to keep the malware itself from spreading, but until you’ve thoroughly cleansed all hosts within that local set of subnets, each of them could be suborned into DoS attacks on other hosts inside your system or out on the Internet.

Some typical containment tactics might include the following:

• Logically or physically disconnecting systems from the network or network segments from the rest of the infrastructure
• Disconnecting key servers (logically or physically), such as Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), or access control systems
• Disconnecting your internal networks from your ISP at all points of presence
• Disabling Wi-Fi or other wireless and remote login and access
• Disabling outgoing and incoming connections to known services, applications, platforms, sites, or services
• Disabling outgoing and incoming connections to all external services, services, applications, platforms, sites, or services
• Disconnecting from any extranets or VPNs
• Disconnecting some or all external partners and user domains from any federated access to your systems
• Disabling internal users, processes, or applications, either in functional or logical groups or by physical or network locations

Take another close look at your data sources for monitoring and alarm information. Quite often, attack vectors are trying to cover their tracks by modifying, erasing, or otherwise making log files and indicator data unavailable to the SOC. As the alarms begin to sound, keeping your event data sources clean and pristine needs to be high on the SOC’s internal priority watch-and-protect lists.

A familiar term should come to mind as you read this list: quarantine. In general, that’s what containment is all about. Suspect elements of your system are quarantined off from the rest of the system, which certainly can prevent damage from spreading. It also can isolate a suspected causal agent, allowing you a somewhat safer environment in which to examine it, perhaps even identify it, and track down all of its pieces and parts. As a result, containment and eradication often blur into each other as interrelated tasks rather than remain as distinctly different phases of activity.

This gives us another term worthy of a definition: a causal agent is a software process, a data object, a hardware element, a human-performed procedure, or any combination of those that perform the actions on the targeted systems that constitute the incident, attack, or disruption. Malware payloads, their control and parameter files, and their carriers are examples of causal agents. Bogus user IDs, hardware sniffer devices, or systems on your network that have already been suborned by an attacker are examples of causal agents. As you might suspect, the more sophisticated APT kill chains may use multiple methods to get into your systems and in doing so leave multiple bits of stuff behind to help them achieve their objectives each time they come on in.

Check your SOC’s processes and procedures as to when and how you should escalate or notify management regarding containment activities. Don’t lose sight of the need to keep the organization informed and patient.

Before you conclude your containment efforts and begin eradication (or other recovery actions), make sure you’ve made protected copies of affected systems, as required, for evidence; ensure that you properly log all evidence to establish and protect its chain of custody.

Eradication

It’s sometimes difficult to separate containment from eradication, since in many cases, the tools and processes you use to contain a causal agent (such as a malware infection or an unauthorized user ID) provide a one-step contain-and-eradicate. One vital distinction is to remember the need for evidence to support any follow-on forensics investigation: containment, by itself, should not alter information that might be needed as evidence, whereas eradication certainly will! Eradication is the process of identifying and then removing every instance of the causal agent and its associated files, executables, and so forth, from all elements of your system. For example, a malware infection would require you to thoroughly scrub every CPU’s memory, as well as all file storage systems (local and in the clouds), to ensure you had found and removed all copies of the malware and any associated files, data, or code fragments. You’d also have to do this for all backup media for all of those systems to ensure you’d looked everywhere, removed the malware and its components, and clobbered or zeroized the space they were occupying in whatever storage media you found them on. Depending on the nature of the causal agent, the incident, and the storage technologies involved, you may need to do a full low-level reformat of the media and completely initialize its directory structures to ensure that eradication has been successfully completed.

Eradication is where two priorities potentially collide: getting back into business naturally conflicts with being able to know and prove who or what was responsible for the disruption in the first place. Eradicating malware from infected systems does, at one level, destroy evidence of the malware’s presence there. Anti-malware systems usually provide extensive logging capabilities, which may be sufficient to meet evidentiary needs. This is something that should of course have been examined and decided upon during risk management, mitigation, and incident response planning and preparation activities, but there may be incidents where this decision has to be made in real time. If that’s the case, get senior leadership or management’s concurrence first, if at all possible! The incident response team must make note of these circumstances and management’s authorization to proceed in the formal incident response team log files.

Eradication should result in a formal declaration that the system, a segment or subsystem, or a particular host, server, or communications device has been inspected and verified to be free from any remnants of the causal agent. This declaration is the signal that recovery of that element or subsystem can begin.

It’s beyond the scope of this book to get into the many different techniques your incident response team may need to use as part of containment and eradication—quite frankly, there are just far too many potential causal agents out there in the wild, and more are being created daily. It’s important to have a working sense of how detection and identification provided you the starting point for your containment, and then your eradication, of the threat. Your best bet may be to think even more like an attacker would and continue to get training, education, and experience in ethical penetration techniques, including reverse engineering of malware, as part of staying current and effective as an SSCP.

Recovery

Recovery is the process by which the organization’s IT infrastructure, applications, data, and workflows are reestablished and declared operational. In an ideal world, recovery starts when the eradication phase is complete and when the hardware, networks, and other systems elements are declared safe to restore to their required “normal” state. The ideal recovery process brings all elements of the system back to the moment in time just before the incident started to inflict damage or disruption to your systems. When recovery is complete, end users should be able to log back in and start working again, just as if they’d last logged off at the end of a normal set of work-related tasks.

It’s important to stress that every step of a recovery process must be validated as correctly performed and complete. This may need nothing more than using some simple tools to check status, state, and health information, or using preselected test suites of software and procedures to determine whether the system or element in question is behaving as it should be. It’s also worth noting that the more complex a system is, the more it may need to have a specific order in which subsystems, elements, and servers are reinitialized as part of an overall recovery and restart process.

With that in mind, let’s look at this step-by-step, in general terms:

• Eradication Complete Ideally, this is a formal declaration by the CSIRT that the systems elements in question have been verified to be free of any instances of the causal agent (malware, illicit user IDs, corrupted or falsified data, etc.).
• Restore from “Bare Metal” to Working OS Servers, hosts, endpoints, and many network devices should be reset to a known good set of initial software, firmware, and control parameters. In many cases, the IT department has made standard image sets that it uses to do a full initial load of new hardware of the same type. This should include setting up systems or device administrator identities, passwords, or other access control parameters. At the end of this task, the device meets your organization’s security and operational policy requirements and can now have applications, data, and end users restored to it.

• Ensure All OS Updates and Patches Are Installed Correctly It’s critical to ensure that the reloaded operating systems have all the required operational, functional, and security updates and patches correctly applied to them as a part of systems recovery efforts. Some organizations build and maintain a master or golden image of each operating system for each type of device and ensure that this golden image is routinely updated in accordance with configuration management and control decisions. Reloading systems from these golden images thus brings with it all current approved updates and patches. Otherwise, you will have to restore from the last known good distribution kit or systems image and then apply all patches and updates.

  A special set of system restoration assessment tests should be developed (prior to being in the midst of an incident response) and used to verify that each reloaded system does in fact have its operating system correctly and completely restored.

• Restore Applications as Well as Links to Applications, Platforms, and Servers on Your Network Many endpoint devices in your systems will need locally installed applications, such as email clients, productivity tools, or even multifactor access control tools, as part of normal operations. These will need to be reinstalled from pristine distribution kits if they were not in the standard image used to reload the OS. This set of steps also includes reloading the connections to servers, services, and application platforms on your organization’s networks (including extranets). This step should also verify that all updates and patches to applications have been installed correctly.
• Restore Access to Resources via Federated Access Controls and Resources Beyond Your Security Perimeter on the Internet This step may require coordination with these external resource operators, particularly if your containment activities had to temporarily disable such access.

At this point, the systems and infrastructure are ready for normal operations. Aren’t they?

Lessons Learned; Implementation of New Countermeasures

Figure 4.2, you recall, suggests but does not explicitly show the web of cross-connections that are the opportunities for you and your teammates to learn from the painful lessons of the experiences you gain, moment by moment, in dealing with an information systems security incident. As the SOC team and the CSIRT focused on the details of further characterizing the incident, containing it, eradicating as necessary, and recovering all systems back to normal, those teams learned important lessons. Perhaps some procedures were found to be incomplete; tools and processes were found to be inadequate or had significant room for improvement to make them more effective and reliable to use. Logging, record-keeping, and the gathering of evidence might have shown that your chain of custody processes need improvement, if you’re going to help the organization make its bullet-proof case really bullet-proof, based on that evidence and its associated records. People-to-people communication skills, processes, or protocols might not have worked very well.

No lesson is too small to make note of, capture, and then consider as part of your continuing process of improvement. Nor should you push this lessons-learning too far off into the future. Yes, the textbook portrayals of the incident response lifecycle can suggest that it’s after the incident is over that you begin the process of debriefing the responders, capturing the ideas and problems, prioritizing which to deal with first, and getting those fixes or improvements into production. This does not need to be a “Monday-morning quarterbacking” exercise of trying to second-guess what happened in Sunday’s game. Instead, reality and experience suggest several reasons why immediately starting to implement the lessons your current response experiences are teaching you is sound practice.

• Incidents may have long dwell times: APTs using a sophisticated kill chain strategy may take months to go from their first attempts to infiltrate your systems to finally departing your systems (if they leave at all); you’ll need to respond to such an attack over weeks or months as well.
• Attacks by different threat actors may overlap in time and space: As you respond to one element of one APT’s kill chain, you may discover that other unwanted guests are attempting to capture your systems’ resources and capabilities to use for their own ends.
• Let different teams work in parallel across the incident response lifecycle: In all but the smallest of organizations, the on-shift watch-standing SOC teams and incident response team members are not the only ones who can (or should) be working on developing, implementing, and testing new or improved information risk mitigation and security controls. Usually, too, there are subtly different skill sets needed to analyze and assess requirements, select and implement new controls, and operationalize them via administrative, procedural, and training efforts, versus those needed for on-scene incident response.
• Some fixes, improvements, or changes can and should be quick and easy, so do them: You have no real reason to wait; if you’ve got the people time or other assets you need to make some of these fixes right now, while the need for them and the pertinent details are fresh in your mind, do it before the next incident arrives.

Go back to that NIST checklist in Figure 4.3; the lessons learned process, be it done after the incident response or during it, can use this same kind of checklist approach. Preparation planning identified assets that you believed would increase your chance of successfully surviving an incident and recovering from it. The reality of an incident has tested the assumptions you made regarding each of those readiness items. In light of that, re-evaluate each item; write down the list of changes, improvements, repairs, or the justification to outright replace that asset, based on what you’ve just learned in the “live-fire” testing event (the incident) you’ve just been through. Then get management and leadership to start resolving each action item on that list you’ve just created.

Third-Party Considerations

Today, with public/private hybrid environments and those that lean heavily on outsourced or third-party services, it is imperative to include them in your incident management program’s policies, plans, and procedures. Security teams should be reviewing their third parties as part of their overall risk management strategy; it is also important to make sure they align with your incident management program. This detailed coordination should start before selecting and contracting with any such third-party services provider or strategic partner, by identifying the total set of services, information exchanges, coordination, and collaboration activities required by that relationship. Your organization, after all, is totally responsible for every step, every nuance, and every detail of every process that is part of how you do business; delegating some of those responsibilities and actions to third parties does not relieve your team of their due diligence and due care burdens. Once your team has identified everything that needs a particular third-party type of support relationship, your organization can then negotiate with that third party from a more informed and confident position. After the contracts are signed, it can be extremely difficult (and expensive) to renegotiate aspects of that relationship or to attempt to add forgotten or overlooked items. You certainly do not want to be trying to negotiate for exchanges of log files or other forensic data while you’re in the middle of responding to an information security incident.

It’s important to recognize the demonstrated ability of APTs to use multiple targets of opportunity to ultimately strike at the target that supports their main objective. Along the way, these attacks—as in the Target data breach in 2013—involve using service providers that have existing business relationships with the APT’s ultimate target. Third-party considerations for information security incidents reach far beyond your cloud services providers or strategic partners that are part of your SSO-enabled federated systems. Every organization you do business with, including your customers, is a potential player in your next information security incident response. This should be carefully considered during the planning phases, as you develop both your incident response plans and procedures and identify where your third parties can and should be stronger parts of your overall shared security posture.

Coordination and collaboration continue throughout the entire lifecycle of the relationship with any third-party services provider, whether they provide cloud services, website hosting, off-site data storage and archiving, data recovery, systems maintenance, logistics support, or data and systems disposal and destruction. This covers phases such as the following:

• Pre-incident
  • Prediction: All service provider relationships should define the real-time and near-real-time telemetry data that needs to be exchanged for both parties to be able to meaningfully detect possible information security incidents in the making. Based on each partner’s needs, this might also include behavioral information to support advanced threat detection systems or other trending and performance data. Both parties have a vested interest in improving each other’s capabilities in keeping their joint threat surface safe, secure, and useful after all.
  • Detection: Does the third party warn of any incidents or take actions to minimize the probability and/or impact of a security incident? This answer can depend greatly with third parties, and it is important to understand how the third party prevents breaches and how they document and provide their customers with security reviews and audits.
• During the incident
  • Notification: Your incident response procedures must include timely notification to potentially affected third parties, especially those providing services that may be involved in the incident. Your team should also have clearly identified points of contacts to receive incident notifications from third parties (including ones that have no third party standing with you, such as someone surfing your website who detects something suspicious).
  • Assessment: Some incidents may be strictly internal, not involving any third-party services or information; for those that do involve one or more third-party relationships, a collaborative assessment process can bring each party’s knowledge of their own systems and data to the incident at hand.
  • Response: Once an incident is believed to involve third-party systems and services, coordination before action is crucial to keeping both organizations and their systems on the safest of paths to recovery. Just as you risk disrupting your own business by too aggressively attempting to contain and eradicate a threat actor’s causal agents or in disabling accounts they may be using, so too your business can be derailed if one of your third parties overreacts to an incident. You don’t want to help the attacker by cascading the damages to your systems into those of your third parties, and vice versa.
• Post-incident
  • Recovery and reporting: Recovery timelines must be in sync with both internal and external parties as a delay from one could result in damages or fees. A hosting company that fails to recover a database or application could have severe financial impacts to the organization. It is therefore important to develop relationships with the people who receive notifications and how customers are notified. Reporting of vulnerabilities from third parties in a timely matter must take place and be incorporated with internal vulnerability management programs.
  • After action: The security team should work with third parties to evaluate how an incident may have happened and what steps can be taken to further prevent a reoccurrence. The security practitioner should regularly evaluate, address, and verify remediation of weaknesses and deficiencies with the third-party providers.
• During a forensic investigation
  • At some point in an incident response process, your organization’s management and leadership may decide to institute a forensic investigation, either formally or informally. Such investigations may require that third parties be notified that an investigation is underway and that they are requested to protect all information involved with the event; or they may be served with digital discovery motions. In almost all cases, the forensic investigations teams (yours and that of your third parties) and the respective managers and legal counsel will have to take charge of coordinating this with any third parties that are a party to the incident.

The involvement of third parties, both upstream and downstream, is vitally important in incident response, as they may affect explicit and crucial aspects in the sequence of response actions.

Legal and Ethical Principles

The complexities of the law at home, much less abroad, dictate that you call in the lawyers early and often throughout your incident response lifecycle. Regardless, there are a few key legal and ethical ideas you should have a solid understanding of as you conduct all of your tasks as an information security specialist.

Chapter 2, “Security Operations and Administration,” established the broadly accepted legal and ethical principles behind CIANA, the core information security requirements of confidentiality, integrity, availability, nonrepudiation, authentication, privacy, and safety. Each of these directly links to the common business ethical requirements of due care and due diligence (which many nations have embodied in their criminal and civil laws). Chapter 2 also linked these ideas to the (ISC)² Code of Ethics and to your professional obligations to supporting that code. Taken together, those concepts (CIANA, privacy, safety, due care, and due diligence) should be a sufficient set of foundational elements for you to build your incident response processes upon.

Most legal systems do impose constraints and duties upon everyone involved in an incident scene, whether as participants, bystanders, responders, or owners or managers of the property or location in question. Societies value being able to establish that something happened and further to show who had responsibility for what happened; they need to be able to demonstrate that laws were broken (or complied with) and be able to unemotionally assess what injuries, deaths, damage to property, or other losses resulted from an incident. In almost all societies, evidence is required to establish those conclusions; therefore, it’s in everyone’s interest that evidence at the scene be preserved and protected as best as possible. But societies do recognize that first responders may, in emergency situations, have higher priorities to attend to than the preservation of evidence. Firefighters responding to a structure fire in your data center will not, of course, be worrying about saving the digital contents of your servers or the media, documents, and files kept in your records center; their priority is ensuring the safety of life by controlling the fire, containing it, and ideally extinguishing (eradicating) it.

For the rest of us, the nonemergency and non-life-saving first responders and incident investigators, we share in the legal obligation to ensure that the incident scene be preserved as best as possible so that it can tell its own story; the evidence in that scene needs to be protected from loss, damage, or corruption (be that deliberate or accidental) so that any investigation of that incident will come to an unimpeachable and irrefutable conclusion. By controlling, preserving, and protecting the scene, we limit or prevent loss, damage, or corruption of evidence; this is due care in action. Establishing and maintaining a chain of custody for evidence related to that scene is the accountability proof that we need, as responders and investigators, to show that we fulfilled our due diligence responsibilities.

Chapter 2 also examined various legal and ethical concepts regarding the rights that individuals and organizations have against unwarranted search of their belongings (including their information and record-keeping systems) and their rights to privacy of their persons, places, and actions. These legal and ethical rights form a set of constraints on how you and an incident response team can search an incident scene, question people who are or may have been involved in the incident, and attempt to search the property under the control of such persons. They can constrain how you establish internal, perimeter, and external surveillance systems; they can also limit or dictate what you can or must do with surveillance data, such as video or audio recordings these systems collect. Different legal systems have different processes that control how you can give access to such surveillance information to others, such as to national or local government agencies, law enforcement, insurance adjusters, and investigators, or even to others in your management and leadership chain. Thus, it’s vital that you get your organization’s legal team involved as you develop these aspects of your incident response procedures; gain their approval before you put your teammates in jeopardy by tasking them to carry out those procedures.

Logistics Support to Investigations

Digital forensics is a game of large numbers: the total number of objects to examine can easily exceed one million or more when you consider every file, file header, date and time stamp, location information, and the data in the file itself. It’s imperative that the investigators use efficient forensics tool sets, often integrated as a forensic workstation, as their investigative infrastructure. When you combine this with the need to preserve and protect such evidence with a strong chain of custody procedures, you can quickly imagine that an investigative team is going to have some specific needs from your organization for facilities and administrative support.

• Separate workspaces, which the investigative team can secure or lock when they are not present. These should be considered as restricted access spaces, and other organizational employees (even senior managers or leaders) must be prevented from attempting to access them without express permission from the investigators. (This supports chain of custody integrity.) Larger or more technically savvy organizations (which as lucrative targets may attract multiple attack attempts per year) may see the need to establish separate clean room facilities to support forensic investigations.
• Access to your systems, information storage and documentation libraries, administrative procedures, policies, and guidelines.
• Access to your networks and systems.
• Access to your people.

Depending upon your organization’s physical locations, you may also need to provide routine access (such as special visitor badges), reserved parking, or otherwise expedite the ways in which the team can bring in their own forensic analysis, evidence collection, and related equipment and supplies.

It’s also wise to designate someone in the organization as the principle point of contact for investigators to come to when special support needs or issues arise. This point of contact can then broker the issues within the organization and get the right resources marshalled to resolve them; or, if need be, get the right managers and leaders to meet with the investigators to seek a common understanding and a way forward.

Evidence Handling

“Evidence collection and handling” can have a broad range of meaning, much of which is beyond the normal duties of an SSCP. Organizations need evidence to support criminal prosecution of attackers and malicious insiders. Evidence informs the choices organizations make during incident response, during recovery, and in remediation, repair, or upgrades of systems and processes after an incident. Evidence also establishes whether the organization fulfilled its due care and due diligence responsibilities in the event of an information security incident or a data breach. Evidence also aids in lawsuits brought in civil court.

There is a tendency for information systems professionals to hear “evidence” and think only about digital evidence; this is hard to understand, since as an information security professional you also have to make the right choices about physical and administrative risk mitigation and security controls, as well as logical (that is, software-implemented digital) controls. You’ll need to use a combination of physical, logical, and administrative evidence to prove to your managers that your physical access control systems, for example, are working correctly. Thus, it’s important and relevant to think about all forms of evidence when you consider the collection, protection, and use of evidence pertaining to an incident scene.

As the on-scene SSCP, you might have to assist in gathering and protecting evidence related to a security incident. This evidence could be in many forms:

• Physical IT-related evidence, such as computers, USB or other media, paper documentation, cables, or other hardware devices.
• Physical evidence about the scene itself, such as damaged doors on secured cabinets.
• Images or descriptions of physical evidence, such as a video or photograph of a portion of the incident scene, or video recordings showing the movement of people, vehicles, or other objects in and around the scene.
• Documentary evidence, which can be any log, recording, notes, or papers that describe or attest to something at the scene. A book found at the scene is a physical piece of evidence; your personal notes made during the incident response are your description or documentation of what you believe transpired.
• Digital evidence, such as files, directory structures, memory dumps, disk images, packet trace histories, log files, or extracts from databases.
• Testimony given by any person regarding the incident, either in direct (in person) form, as a recording, or as a transcript.

Everybody who has any role in responding to an incident will become involved with items of evidence such as these. Typical information security incidents may have actions taking place in many different physical and virtual locations, which of course complicates the whole process of identifying who is a “first responder,” which incident response teams have responsibility over which portions of this dispersed scene-of-scenes, and what it means to have one person take control of “the” scene. For starters, let’s consider a simpler scene, confined to one building, such as a data center at your company’s main operating location.

It’s useful to think about evidence collection, protection, and analysis from the organizational perspective of the end game: what does the evidence need to do for the organization, when it take its case to court or uses the findings of an investigation to take a controversial internal action? Generally speaking, the total set of evidence you put together as the findings of your investigation needs to be the following:

• Be accurate: The evidence and documentation must not vary, deviate, or conflict with other evidence or contain any errors. Inaccurate evidence can be disputed or dismissed.
• Be authentic: Evidence should not deviate from the truth and relevant facts. In addition to harming your side’s opportunity for a favorable court decision, inauthentic evidence may be construed as deceiving the court, which is itself a crime.
• Be complete: Both sides of a court case will be allowed to review and dispute all evidence provided by the other side; you will be required to share any and all data related to the case, regardless of whether that data supports your side. Even evidence that does not demonstrate your intended outcomes must be shared with the opposing side to give the court an opportunity to make a fair, informed, and objective decision. Furthermore, as with deception, failure to disclose all evidence in a legal matter may have financial and even criminal consequences.
• Be convincing: Regardless of the type of court, the purpose of the case is to determine which side’s narrative is more believable, as supported by testimony and evidence. You will try to convince the court your story is more believable, while disputing your opponent’s side; the adversary will be doing the same. The evidence you present should support your story, and your story should be reasonably demonstrated by the evidence.
• Be admissible: There are many kinds of evidence that are admissible in court and only a few that aren’t; some are admissible only after a ruling by the court and discussion/review by opposing counsel (such as expert testimony). Be sure to understand the rules of evidence that are applicable in your jurisdiction to know which evidence will be admissible.

In all matters of evidence, it is absolutely imperative to consult with legal counsel to ensure your efforts are suitable for the court.

Evidence Collection

Your organization will most likely need to collect a variety of physical, administrative, and logical or digital evidence in the course of responding to an incident and supporting a forensic investigation into its cause. In almost all cases, the organization will be better protected if it uses trained, expert forensic investigators to conduct all aspects of evidence collection, preservation, and analysis. You should, however, become familiar with the processes such evidence collection may use and appreciate what your role might be in supporting such expert investigators. Standards such as ISO 27037, “Information technology – Security techniques – Guidelines for identification, collection, acquisition and preservation of digital evidence” (https://www.iso.org/standard/44381.html), can provide great insight into what you and your organization need to do to be prepared to call in the experts and support them to achieve your investigative needs.

During the preparation phase, the organization should identify candidate investigator teams and establish at least a preliminary working relationship with them. This can help the organization establish on-call or urgent support relationships with investigators and analysts with the proper training, expertise, and tools to perform digital forensics. These investigators can be internal employees, external contractors, or a combination of both. These decisions should take into consideration response time, data classification, and sensitivity.

The ideal forensic team should be made up of people with diverse skillsets, including knowledge of networking principles and protocols, a wide range of security products, and network-based threats and attack vectors. Skillsets should overlap between team members, and cross-training should be encouraged so that no one member is the only person with a particular skill.

Other teams within the organization should be available to support forensic activities. This should have top-down support through policy, and the forensic team should feel enabled to approach members of management, the legal team, human resources, auditors, IT, and physical security staff. Working together, the cross-functional forensic team should have a broad set of skills, capabilities, tools, techniques, and understanding of procedures.

Emergency Response Plans and Procedures

Figure 4.5 also suggests that each type of incident may need to call upon one or more type of response capability. Prudence, if not due care, suggests that organizations plan for many different types of incident response. In broad topical terms, these plans are shown in Figure 4.6. Your own organization may refer to these planning processes by different names and may even put all of this planning activity into one process; it may also split some of these task areas apart. Key to successful risk management planning (which this is all about) is that the plans are suited to the risk environment and context that your organization faces; your plans should be tailored to meet that environment, as they should also meet your risk tolerance, the culture of your organization, and its surrounding context. Each of these plans should be driven by the BIA; more to the point, due care requires that your organization be effective at this spectrum of business continuity planning. The bottom-line goal of this planning—and of all of these plans taken together—is that if your organization wants to stay in business, it has to survive if it is to thrive.

It’s safe to conclude that each of the types of plans shown in Figure 4.6 has a different set of champions within your organization, since each type of plan must draw upon knowledge and experience with different aspects of the organization’s operations, resource planning, budgeting, and decision-making. While a chief risk officer (CRO) may have overall responsibility for all of these planning processes, it’s that set of champions on each plan that will do the leadership and management work of transforming their plan into an operationally prepared capability to respond. Senior leadership, including the CRO, challenges and leads the overall effort to achieve business continuity readiness; mid-level management and knowledge workers throughout the organization both turn the plans into reality and are often the ones who execute those plans when an incident takes place.

Each of these layers of planning is (or should be) driven by the business impact analysis, which took the results of the risk assessment process to produce a prioritized approach to which risks, leading to which impacts to the organization, were the most important, urgent, or compelling to protect against. (Note that important, urgent, and compelling do address different decision criteria about responding to risks.) Let’s take a brief look in more detail at each of these planning processes and the plans they produce.

• Business continuity planning considers how to keep core business logic and processes operating safely and reliably in the face of disruptive incidents; it also looks at how to restore these core processes after they have been disrupted. The business continuity plans (BCPs) that are produced are at the “high tactical” level; they use the strategic plans of the organization as context to take the prioritized core business processes (as defined by the BIA), specifying the tasks needed to recover from such a disruption. This includes all phases of incident response. BCPs do not normally go into the step-by-step operational details necessary to achieve effective preparation, response, or recovery; they rely on other, subordinate plans and procedures to do so.
• Disaster recovery planning must concern itself with significant loss of life, injury to people, damage to organizational assets (or the property or assets of others), and significant disruption to normal business operations. As a result, disaster recovery plans (DRPs) look to ways to prevent a disruption from turning into panic or hysteria, while at the same time meeting the organization’s due care and due diligence responsibilities to keep both stakeholders and the community informed. DRPs, for example, often must consider that organizational cash flow will probably suffer significantly as business operations are suspended, or greatly reduced, perhaps for months.
• Contingency operations planning takes business continuity considerations a few steps further by examining and selecting how to provide alternate means of getting business operations up and running again. This can embrace a variety of approaches, depending on the nature of the business logic in question.
  • Alternate work locations for employees to use
  • Alternate communications systems, internal and external, to keep employees, stakeholders, customers, or partners in touch, informed, and engaged
  • Information backup, archive, and restore capabilities, whether for physical backup of information and key documents or digital backups
  • Alternate processing capabilities
  • Alternate storage, support, and logistics processes
  • Temporary staffing, financial, and other key considerations
• Critical asset protection planning looks at the protection required for strategic, high-value, or high-risk assets in order to prevent significant loss of value, utility, or availability of these assets to serve the organization’s needs. As you saw in Chapter 3, these can be people, intellectual property, databases, assembly lines, or almost anything that is hard to replace and almost impossible to carry on business without.
• Physical security and safety planning focuses on preventing unauthorized physical access to the organization’s premises, property, systems, and people; it focuses on fire, environmental, or other hazards that might cause injury or death, property damage, or otherwise reduce the value of the organization and its ability to function. It works to identify safety hazards and reduce accidents.

Finally, we as SSCPs come back to the information security incident response planning processes, as shown in the “Preparation” section of this chapter. That planning process rightly focuses your attention on detecting IT and information systems events (or anomalies) that might be security incidents in the making, characterizing them, notifying appropriate organizational managers and leaders, and working through containment, eradication, and recovery tasks as you respond to such incidents.

The conclusion is inescapable: planning is what keeps you prepared so that you can respond, but your planning has to be multifaceted and allow you to look at your organization, your operations, your information architectures, and your risks across the whole spectrum of business strategic, tactical, and operational concerns and details.

It’s important to make a distinction here between plans and planning. Plans are sets of tasks, objectives, resources, constraints, schedules, and success criteria, brought together in a coherent way to show you what you need to do and how you do it to achieve a set of goals. Planning is a process—an activity that people do to gather all of that information, understand it, and put it to use. Planning is iterative; you do it over and over again, and each time through, you learn more about the objectives, the tasks, and the constraints; you learn more about what “success” (or “failure”) really means in the context of the planning you’re doing. In the worst of all worlds, plans become documents that sit on shelves; they are taken down every year, dusted off, thumbed through, and put back on the shelf with minor updates perhaps. These plans are not living documents; they are useless. Plans that people use every day become living documents through use; they stay alive, current, and real, because the people served by those plans take each step of those plans and develop detailed procedures that they then use on the job to accomplish the intent of the plan.

In a real sense, the planning you’ll do to meet the CIANA needs of your organization or business does not and should not end until that organization or business does. Ongoing, continuous planning is in touch with what the knowledge workers and knowledge-seeking workers on your team are doing, every day, in every aspect of their jobs.

Interim or Alternate Processing Strategies

When disruption or disaster strikes, your organization is faced with a stark but simple choice: either activate some kind of alternate capability to conduct business processes with or have employees, customers, suppliers, and stakeholders stand around and wait until you have your original (primary) processing capabilities back in operation. Management and leadership frame this choice by setting the maximum allowable outage (MAO) time; the shorter that time period is, the greater the need for backup, alternate processing capabilities, and the greater the need for those alternate capabilities to be on “hot standby,” ready to swing into action instantly. It’s worth a moment to think about what interim and alternate generally mean in this context.

• Interim processing tends to be thought of as addressing a short-term need, perhaps for less than a day; it normally does not involve the relocation of other business assets, people, or communications links; customers and suppliers are not faced with a temporary change of address or a new location to go to in order to do business with your organization.
• Alternate processing tends to involve a longer-term need, such as when a fire or natural disaster makes your primary business location (or your data center) unusable for weeks or months. Customers, suppliers, employees, and critical business assets need to move to the new location and orient their interactions around it.

Translating that MAO into a processing strategy requires that you shift your thinking for a moment to the business processes that your organization uses across its full spectrum of operations. How do these fail when data, communications, processing capabilities, or other critical resources, are not available or have become corrupted or unreliable? Business continuity planning should identify these, ranked in order of their criticality to the survival and continued operation of the organization. This leads to some process-based definitions of systems failure that are most useful for planning for interim or alternate processing.

• Disaster (or complete disruption): Most or all of the critical business processes needed for minimum safe operation of the business cannot function.
• Interruption: One or more business processes are not able to function for a relatively short period of time.
• Partial disruption: Some critical business processes cannot function, but others can continue to operate, perhaps with degraded capability or for a limited period of time.
• Minor disruption: A few critical business processes cannot function, but the majority of routine functions can operate with no or minimal impact for some period of time.

Most retail sales businesses, for example, can continue to meet customer needs even though their back-office human resources, accounts payable, or strategic planning functions are disrupted. Similarly, a manufacturer can continue to operate their assembly line without those back-office business functions. Both types of business, however, will start to run into obstacles if they cannot pay their suppliers, process payments from customers, or meet payroll and tax payment obligations. Segmenting your overall business processing workloads in this way (guided of course by the logic in your BCP) should allow you to make cost-effective choices for interim or alternate processing capabilities.

The BCP should also identify which functions are tied to physical locations and which are not. This may also require separating the command, control, and management functions (the automation) from the physical systems themselves. Interim or alternate processing needs to provide some designated subset of the normal set of data acquisition, processing, storage, retrieval, computation, display, and communication services that the business processes depend upon.

Taken all together, this suggests that several strategies may be used by your organization, depending upon its business activities and overall needs for security, reliability, safety, and robustness.

• Edge computing pushes the data acquisition, processing, and command and control of devices as close to the point of action as possible. For example, self-driving vehicles cannot rely on a distant command and control function because of communications latency, potential link failures or interruptions, and the volume of data acquired by the vehicle sensors and used in real time to navigate, avoid hazards, or deal with emergency conditions. Patient care, manufacturing and process control, traffic control, and many integrated logistics functions are making use of edge computing. In these cases, the endpoint systems can operate for some time without the central management system being available; and the failure of one endpoint to function does not usually cascade into failures of other endpoints.
• Mirrored or parallel processing uses two nearly identical data processing systems, physically separated from each other; each transaction or operation is performed simultaneously on both systems, and both centers’ underlying databases are updated in parallel and should always be in sync with each other.
• Hot backup provides for physically separated, nearly identical data processing centers as well; the backup center, however, is not mirroring every transaction or operation in real time but is refreshed with periodic incremental database updates (taken as incremental backups on the primary system). The primary system keeps a log file of transactions or operations that occur between such updates; at most, these updates (or delta transactions, as they’re sometimes called) will have to be repeated on the hot backup system before it can be fully up-to-date with the state of the business.
• Cold backup provides for a minimal set of capabilities at an alternate processing location. This usually consists of having similar IT systems installed and reasonably prompt access to off-site data archival storage. It may take some time to bring operations personnel, current backups, and other critical resources to the cold backup site, start it up, and bring its databases up to date, before business operations can resume.
• Warm backup refers to alternate backup processing capability that is anywhere between cold and hot in terms of responsiveness.

Each of these strategies brings with it some hard choices, as you must trade costs, time, availability of talent, and loss of business opportunity to get different levels of availability. Each brings with it a set of choices about levels of graceful degradation that you’ll want to consider, as well as choices you’ll need to make regarding fail-safe behavior.

• Fail-safe design and operation ensures that systems failures or disruptions cannot cause part or all of the system to operate in ways that can cause injury or death, or damage information, property, or the system itself. Rapidly shutting down a chemical processing facility, for example, might cause pressure vessels or pipes to overheat (or get too cold), leading to a rupture, explosion, or fire; fail safe design ensures that a pre-planned emergency shutdown operation can be performed instead.
• Graceful degradation is a design and operational characteristic that allows a system to lose or shut down functions in ways that can limit the impact of a disruption. Typically, this provides users and operators with time to safely isolate activities and then use normal shutdown processes to halt those operations. Graceful degradation relies on fail safe design.

Cloud computing delivers any of these alternate or interim processing capabilities, by means of what your organization contracts with the cloud services provider to deliver. Most major cloud services providers, such as Microsoft, Amazon, or Google, can at the flip of a virtual switch provide your organization with fully mirrored backup capabilities running in data centers on different continents, or any degree of hot, warm, or cold backup. Moving business functions into the cloud does not change the overall set of strategic, tactical, and operational choices your organization must make—it only affects how much money the organization must invest up front (to buy or lease its own equipment, and hire its own people), what its recurring costs are, and how much of the technical details of managing the alternate processing capabilities it wants to outsource.

Restoration Planning

Recovery operations bring a minimum acceptable set of capabilities back into operation and thereby deliver a minimum acceptable set of business services to the organization, its customers, and other stakeholders. Management and leadership define this minimum set of acceptable services as part of the business continuity planning process; as with all plans, the reality of any given incident may require tailoring expectations and needs to what’s practical and achievable. Restoration, by contrast, brings back the full and complete set of capabilities and services that would be considered “business normal” for the organization. These are not just IT systems–related terms. Both recovery and restoration include actions to ensure that related data, connectivity, and human procedural capabilities are also brought back to being operationally available and useful.

A third possibility exists, which applies in situations where the impact of the incident (or disaster) is significant enough that returning to “normal” business operations at that location, with the same business processes, would be too difficult, time-consuming, or exorbitantly expensive. In this case, the organization needs to build toward a new business normal, which may involve new or significantly reengineered business processes, along with the systems and infrastructures to enable and support them. A simple example would be when fire destroys the office of a small business, including its on-premises SOHO LAN system, data storage, and paper records. Migrating this business to a cloud-based platform service model might make a great deal of technical and business sense; using an application platform may require some changes to existing business processes, which might in turn catalyze the owners’ thinking in ways that reveal new business opportunities. In more extreme cases, the disaster may make it emotionally, financially, or politically difficult if not impossible to go back to the same location and restart the business at all.

The decision to return to normal operating conditions has its own set of risks that must be recognized and managed. Resuming normal operations too early, particularly at the original or primary operating location, may put people and assets at risk if containment of the causal agent(s), damages at the site, and secondary disruptions related to the incident still present hazards or risks to contend with. Conversely, a delay in returning to normal operations might incur additional unnecessary expense and maybe even additional losses. Key personnel, for example, may emotionally (not logically) react to a disaster or severe disruption by needing to seek greater job security elsewhere. Payroll obligations must be met during an outage; employment law may not allow for temporary layoffs of employees in such circumstances, and this may constrain the organization to paying its employees, or terminating them, if they cannot be put to useful work. Customers may feel the need to take their business elsewhere; investors may lose confidence in the company and its management team; share prices may start to suffer. These, of course, are management’s issues to worry about; what they’ll need from you and the rest of the information security team is the reassurance during incident response and, afterward, that the information they are getting about the organization’s systems, and the information from those systems, is reliable enough to base those decisions on.

Recovery and restoration planning are important opportunities for security professionals to advise, guide, and, if need be, lead the planning team toward effective ways to protect the organization’s information, assets, people, and reputation. Security’s viewpoints and experience should be involved as BCP and DRP policies are formulated, as those policies are turned into procedures and guidelines and as implementation programs are developed and put into action. From an information systems security perspective, you’ll be the experts to advise on the step-by-step of the recovery and restoration processes so that the right security controls are put back in place, configured, and activated at the right point in the recovery and restoration of each part of the organization’s IT infrastructure and its systems, servers, and endpoints. A significant amount of sensitive and important data is in motion during recovery and restoration operations—moving from archival and backup storage facilities and media, being reformatted, being reloaded into its proper operational places, and then validated as ready for use. Each step of that process is an opportunity for mistakes (or malfeasance) to cause more harm.

Every step of the recovery and restoration processes—in fact, every step of business continuity and disaster recovery activities, from planning to post-op—is an opportunity to learn from experience. It’s also important to learn from the experiences of other organizations as they have gone through responding to and recovering from incidents, disruptions, and disasters. This cross-fertilization of experience and ideas can be something your company pursues with its strategic partners or members of its trade or industry association; as an SSCP, you have many opportunities within (ISC)² and beyond to do the same. Listen to the people involved with each step, seek their views and impressions, and resist the temptation to explain, solve, or seem to judge what they are saying. Take their candor at face value, go back to your workspaces, and translate those observations into the two favorite lists of the ethical hacker: findings and good findings. Findings are the observations of what didn’t work right; either the plan was not sufficient or the steps were not executed according to plan. Good findings are observations of what worked correctly and effectively. These are good news! Celebrate them with the team, and with management and leadership. No matter how small the incident was, recovering from it brought stress, worry, aggravation, and lost work with it as part of its impacts. Good findings can be a powerful and inexpensive way to help re-invigorate a tired and worn-out team.

Backup and Redundancy Implementation

Perhaps the most important element in providing for safe, secure, and reliable data backup is the process by which you manage, account for, and control the ways that backups are made, stored, validated, used, and retired. If that sounds like another lifecycle model or another configuration management and configuration control opportunity, you’re right! It’s trivially easy for the smallest of organizations to benefit from many different free or inexpensive cloud-based data backup services, such as OneDrive, Dropbox, or iDrive. Very inexpensive RAID disk systems provide multiterabyte mirroring, striping, and recovery capabilities that bring hardware redundancy to the SOHO LAN user. These same controller and software technologies, when combined with very large arrays of high performance, high-reliability disk drives, are the backbones of modern data center and cloud-hosted storage systems.

Data Recovery and Restoration

Your incident response team has all the hardware, operating systems, and network elements of your IT infrastructure back up and running; you’re now about to reload data, either directly from archive or backup media or by restarting applications platforms and database systems servers and letting those software systems manage their own data reload. Several possibilities face you at this point:

1. Your archive and backup data exist where your backup management records say that they should, and they can be successfully read and used to reload the systems with.
2. Although you can find and access the backup media, parts or all of it cannot be read or loaded without errors.
3. You have no data backups available to load from.
4. The storage technologies on the systems disrupted by the impact had to be completely sanitized and reformatted as part of containment, eradication, and restoration.

Case 1 is the ideal, of course; it does not come free, and it does require both initial investment and ongoing costs to continually make backups, validate them, and manage them. Case 2 does happen, and as a worst-case situation, you may need to use data recovery tools to scan the storage devices on your systems to see whether you can identify original files, recover them, rebuild directory structures, and then get back into business. Cases 3 and 4, despite the difference in their causes, present your management with a hard choice: either the end users create a new “fresh start” in the data plane and then begin new business operations from that point forward or they exhume paper or other business records from archive, re-create the past transaction history in the systems’ data files and databases, and then build a “fresh start” on top of that foundation.

Although these may seem somewhat extreme, experience shows us that most organizations face similar data recovery choices despite their best efforts at pre-planning and arranging for data backup or archive operations.

The skills, tools, and techniques you’ll need for recovering data from a crashed or partially corrupted disk drive or storage subsystem are almost the same that you’d need when conducting a forensic analysis of it. Data carving is the name given to the art and science of scanning areas of storage to find partial files, file headers, and other data, and attempting to reassemble those pieces into logically complete files. It’s a bit like reverse engineering what’s stored on the drive(s) and is logically similar to trying to reverse engineer, decompile, or disassemble executable program files. Sometimes all that is needed is to physically mount the offending disk drive on a system running a different operating system (e.g., mount a Windows NTFS drive on a Linux machine) as a way to work around errors induced into the directory structures by the source operating system’s misbehavior during the incident. Other tools, such as RecoverMyFiles, can quickly deal with terabyte-sized disks and locate almost all recoverable files; these tools provide powerful capabilities to manage this recovery process, including extensive logging and reporting functions.

When you finally get to the happy landing of the previously described case (1) and can load backup or archive data directly into your systems, you’re just about done. Ideally, the same management tools, application platforms, or database systems you used to create and manage the backups and archive copies are being used to manage and verify the reload.

Three special considerations during data reload (whether by restoring from backups or recovering from damaged media) should come to mind at this point.

• Preventing reinfection from malware: It’s a good chance that a backup copy might have a specimen of malware on it that was unknown to your anti-malware scanner when the copy was made; scan all restore media using the latest malware definition and signature files that you can get hold of to reduce this risk.
• Prevent reloading of corrupted data files: Files that are malware-free but contain contradictory, illogical, or erroneous data could cause critical business processes to produce errors, hazardous outputs, or crash. Consider ways to scan or validate that all critical applications data files are logically correct before reloading them.
• Intruder user IDs, device IDs, or other subject-related data: At some point in the recovery of your systems, you may have to reload data into the access control system, which conceivably could be vulnerable to having bogus user IDs, device IDs, or attribute data loaded into it as if it were trustworthy data. The access control technologies you use may determine whether this is a significant or near-zero risk and may provide ways to mitigate that risk.

The nature of your systems and your information architecture will in large part determine whether you must reload all data for all applications before you can validate that the incident response and recovery is complete or whether you can do this by location, by function, by application, or by sets of business processes. Incident response and business continuity planning should consider this and provide structured guidance, which the reality of each incident will then test. Patience is hard to hold on to at this point, unfortunately, as it can seem hard for business unit managers to separate “we’re almost there” from “we’re ready to go back to business.” Regardless, your incident response process should invoke some kind of integrity checking at this point: just because you have everything reloaded, restarted, and running, and all of the data is there, doesn’t necessarily mean it’s all working correctly. Subsets of routine operational test and evaluation (OT&E) test scenarios may offer well-understood and proven benchmarks to use at this point.

Training and Awareness

Once the business continuity and disaster recovery plans have been written, they must be communicated to the entire staff of the organization. Although some people who have specific responsibilities during a crisis will need more advanced training, everyone should be provided an awareness of the organization’s plans and how they should react in a crisis.

At high-risk locations, crisis awareness should be provided to all personnel at the time they enter the site. This will ensure that everyone on the site knows how to recognize an emergency situation and how they should respond. All personnel should be familiarized with safety and occupant evacuation plans at the time of hiring and then provided with annual reminders. These awareness sessions will advise staff on evacuation plans and procedures, specify meeting points, declare who is in charge during a crisis, and advise on how to report a crisis or suspicious activity.

Other personnel may require training in the use of tools or procedures such as chemical suits, system recovery procedures, crowd control, team management, evidence preservation, incident analysis, and damage estimation.

Since staff often change roles within the organization, it can be necessary to retrain staff and reorganize recovery teams on a periodic basis.

Personnel training for BCDR activities should be in concert with plan testing, which is discussed in the following section.

Testing and Drills

It may seem odd to have a strong focus on testing and assessment of your information security practices embedded here in a chapter on incident response; if so, think of this as boiling this chapter down to the question of what your readiness to respond actually is. Other chapters will look at security testing and assessment in the context of risk mitigation and controls (Chapter 3) and the protections put in place for your networks and communications (Chapter 6), systems applications, and data (Chapter 7, “Systems and Application Security”). Here, let’s use testing, exercises, drills, assessments, inspections, and audits as part of how confident you and your managers can be in your end-to-end incident response capabilities and the people who deliver them day in and day out.

Three different approaches can be used to build confidence in your organization’s incident response capabilities; each brings different issues to light while providing a different way to assess overall response readiness. In some organizational and systems cultures, these three words have distinct meanings; in others, they are used interchangeably. The distinctions are useful to keep in mind.

• Testing validates that a system can or does deliver the functional or performance requirements allocated to it. Tests can include the operational procedures and the people who would normally use these systems during routine business operations; tests can also be performed against controlled test scenarios and be conducted by test teams.
• Exercises provide controlled, safe ways for the people and procedural components of systems to use those systems in realistic scenarios that reflect portions of normal operations. Exercises are often the major component in training programs, as they can focus on building skills and proficiency through practice.
• Drills are similar to exercises and tend to use a smaller set of activities in their specified scenario than an exercise might. Drills can be used to provide a simulation of reality, often without notice to end users (or building occupants).

The use of testing, assessment, exercises, and drills in information security has expanded greatly in the last decade and has borrowed many additional concepts from the world of military security and intelligence activities.

• Penetration testing (more properly known as ethical penetration testing) is a broad category of activities intended to see your systems from the adversary’s point of view; the pen testers attempt to challenge the security effectiveness of your organization and its systems to help the organization uncover exploitable weaknesses.
• War games can be a form of testing, exercises, drills, or penetration testing; many war games start with a given scenario or problem set (such as “Can we detect a data breach before it’s too late?”) and build the scenario to drive toward that assessment. Other war games can focus instead on personnel proficiency, which is at its heart an assessment of what people have been trained to do and how effective that training was in building knowledge and skills.
• Red team/blue team exercises are a form of war gaming or ethical penetration testing. A broad set of rules of engagement (ROE), constraints, and conditions is established; the red team (the attackers) can then do anything they want within those constraints and ROE, to attempt to “capture the flag,” exfiltrate the crown jewels of your data, or otherwise achieve objectives set by the red team and the organization. The blue team (the defenders) is usually not told that such a test is taking place; these are no-notice activities, with the conscious intent of having an independent attacker realistically test the organization’s defenses.

One further set of color schemes to keep in mind about all of these kinds of events describes the level of knowledge or awareness that participants, especially the attackers, aggressors, or pen testers, have about the organization, its systems, its security measures, and its problems.

• Black-box testing, or zero-knowledge testing, denies the testers any inside knowledge of how the system works, its design, and its operational characteristics. Testers can only learn about the system under test by observing it, probing it, or interacting with it; they can also exploit open source intelligence (OSINT) by seeking publicly available knowledge about the target, such as published filings with government regulators, news coverage, employee social media postings, and the like. Black-box testing is adversarial testing in every sense of the word.
• White-box testing, or full-knowledge testing, shares everything that the systems builders, operators, and owners know about their system with the testers. This is cooperative testing and is most often seen in development and acceptance testing.
• Gray-box testing involves any level of sharing of information between the extremes of zero sharing and full sharing.

This brings us to one more color of testing: purple team testing is a red team/blue team test that is structured to encourage and rely upon active cooperation and communication between the aggressors and the defenders.

Tests, evaluations, exercises, and drills should all be planned events that are managed and conducted by an evaluation, test, or exercise director. Each of these activities has an objective it is trying to achieve; the test or exercise director has to be able to decide in real time if the continued conduct of the activity is on track to demonstrating or achieving that objective or if the issues discovered so far dictate that the activity be suspended or terminated. The test or exercise director must also be able to terminate the activity if other real-world business or environmental circumstances dictate the need to do so. (For example, a real severe weather warning may dictate that personnel not essential to a minimum and safe level of business operations be sent home or sent to take shelter, which would probably require terminating a test, exercise, or drill activity.) The test director is also the single face and point of contact to other organizational managers and leaders.

Tests should be part of your ongoing process to validate that your various incident response plans still provide the capabilities you require. They can measure, assess, or demonstrate that functions can be performed and that specific response or recovery actions can be accomplished within the time allotted to them. They can also provide powerful ways to develop and train staff, familiarize them with their roles in carrying out the various plans, and help them bring their role together with those of other team members. Incremental or spiral test strategies help grow team capabilities while they find flaws in the initial concepts, procedures, or processes; this also provides the opportunity for continuously improving your incident response processes.

It Is a Dangerous World Out There

If we were to redraw Figure 4.7, we might be able to see that the people element of an organization makes up a great deal of its outermost threat surface. Even the digital or physical connections our businesses make with others are, in one sense, surrounded by a layer of people-facing, people-powered processes that create them, operate them, maintain them, and sometimes abuse or misuse them. You can see this reflected in the dark humor of the security services of many nations: before the computer age, they’d joke that if your guards, secretaries, or janitors owned better cars, houses, or boats than you did, you might want to look into who else is paying them and why. By the 1980s, we’d added communications and cryptologic technical and administrative people to that list of “the usual suspects.” A decade later, our sysadmins and database administrators joined this pool of people to really watch more closely. And like all apocryphal stories, these still missed seeing the real evolution of the threat actor’s approaches to social engineering.

The goal of any social engineering process is to gain access to insider information—information that is normally not made public or disclosed to outsiders, for whatever reason. With such insider information, an outsider can potentially take actions that help them gain their own objectives at greatly reduced costs to themselves, while quite likely damaging the organization, its employees, its customers, its stakeholders, or its community. In Chapter 3 you saw how one classical and useful approach to keeping insider information inside involves creating an information security classification process; the more damaging that disclosure, corruption, or loss of this information can cause to the company, the greater the need to protect it. This is a good start, but it’s only a start. Social engineering attacks have proven quite effective at sweeping up many different pieces of unclassified information, even that which is publicly available, and analyzing it to deduce the possible existence of an exploitable vulnerability.

Social engineering works because people in general want to be well regarded by other people; we want to be helpful, courteous, and friendly, because we want other people to behave in those ways toward us. (We’re wired that way inside.) But we also are wired to protect our group, be that our home and family, our clan, or any other social grouping we belong to. So, at the same time that we’re open and trusting, we are hesitant, wary, and maybe a bit untrusting or skeptical. Social engineering attacks try to establish one bit of common ground with a target, one element on which further conversation and engagement can take place; over time, the target begins to trust the attacker. The honest sales professional, the doctor, and the government inspector use such techniques to get the people they’re working with to let down their guard and be more open and more sharing with information. Parents do this with their children and teachers with their students. It’s human to do so. So, naturally, we as humans are very susceptible to being manipulated by the smooth-talking stranger with hostile intent.

Consider how phishing attacks have evolved in just the last 10 or 15 years.

• Phishing attacks tended to use email spam to “shotgun blast” attractive lures into the inboxes of perhaps thousands of email users at a time; the emails either would carry malware payloads themselves or would tempt recipients to follow a URL, which would then expose their systems to hostile reconnaissance, malware, or other attacks. The other major use of phishing attacks is to identity theft or compromise; by offering to transfer an inheritance or a bank’s excess profit to the addressee, the attacker tempts the target to reveal personally identifiable information (PII), which the attacker can then sell or use as another step in an advanced persistent attack’s kill chain. The attacker can also use this PII to defraud the addressee, banks, merchants, or others by masquerading as the addressee to access bank accounts and credit information, for example.
• Spear phishing attacks focused on individual email recipients or very select, targeted groups of individuals, and in true social engineering style, they’d try to suggest that some degree of affinity, identification, or relationship already existed in order to wear down the target’s natural hesitation to trusting an otherwise unknown person or organization. Spear phishing attacks often were aimed at lower-level personnel in large organizations—people who by themselves can’t or don’t do great things or wield great authority and power inside the company but who may know or have access to some little bit of information or power the attacker can make use of. The most typical spear phishing attack would be an email sent to a worker in the finance department, claiming to be from the company’s chief executive. “I’m traveling in (someplace far away), and to make this deal happen, I need you to wire some large amount of money to this name, address, bank name, account, etc.,” such phishing attacks would say. Amazingly, an embarrassingly large number of small, medium, and large companies have fallen for these attacks and lost their money in the process.
• Whaling attacks, by contrast, aim at key individuals in an organization. The chief financial officer (CFO) of a company might get an email claiming to be from their chief executive officer (CEO), which says much the same thing: “If we’re going to make this special deal happen, I need you to send this payment now!” CFOs rarely write checks or make payments themselves—so they’d forward these whaling attack emails on to their financial payments clerks, who’d just do what the CFO told them to do. (One of my friends is the CEO of a small technology company, and he related the story of how such an attack was attempted against his company recently, and the low-level payments clerk in that kill chain was the only one who said, “Wait a minute, this email doesn’t look right…,” which got the CEO involved in the nick of time.)

• Catphishing involves the creation of an entirely fictitious persona; this “person” then strikes up what seems to be a legitimate personal or professional relationship with people within its operator’s target set. Catphishing originated within the online dating communities, but we’ve seen several notorious examples so far of its use in attack strategies that do not involve romance.

This list could go on and on; we’ve already had more than enough examples of advanced persistent threat operations that create phony companies or organizations, staffed with nonexistent people, as part of their reconnaissance and attack strategies.

Notice that by shifting from phishing to more sophisticated spear phishing, whaling, or even catphishing attacks, attackers have to do far more social engineering, in more subtle ways, to gather the intelligence data about their prospective target, its people, and its internal processes. Of course, the potential payoff to the attacker often justifies the greater up-front reconnaissance efforts.

This all should suggest that if we can provide for more trustworthy interpersonal interaction and communication, we could go a long way toward establishing and maintaining a greater security posture at these additional layers of our organization’s information architecture. Much of this will depend on your organization, its decision-making culture and managerial style, its risk tolerance, and its mission or strategic sense of purpose. Similar to how we look at incident detection and its requirements for timely and far-ranging monitoring and analysis (as discussed in this chapter’s “Support the Incident Lifecycle” section), we’re looking for ways to find precursors and indicators that some kind of reconnaissance probe or attack is in the works. For example, separation of duties can be used to identify “need to know” boundaries; queries by people not directly involved in those duties, whether insiders or not, should be considered as possible precursor signals. This can aid in key asset protection, security for critical business processes, or even the protection of information about the movement or availability of key personnel. Penetration testing or exercises that focus on social engineering attack vectors might also help discover previously unknown vulnerabilities or identify important ways that improved (or different) staff education and training can help “phishing-proof” your organization.

People Power and Business Continuity

There’s a lot of great advice out there in the marketplace and on the Internet as to why organizations need to teach their people how to help protect their own jobs by protecting critical information about the company. As an SSCP, you can help the organization select or create the right education, training, and evaluation processes and tools for this. A survival tip: use the separation of duties principle to identify groups or teams of people whose job responsibilities suggest the need for specific, focused information protection skills at the people-to-people level.

That’s an important thought; this is not about multifactor identification or physical control of the movement of people throughout the business’s office spaces or work areas. This is also not trying to convert your open, honest, trusting, and helpful team members into suspicious, surly, standoffish “moat dragons” either! All you need to do is get each of them to add one key concept to their mental map of the workplace: trust, but verify. Our network engineers need to build our systems in as much of a zero-trust architectural way as the business needs and can afford, but the most flexible, responsive, surprise-tolerant, and “abnormality-detecting” link in our security chain needs to stay trusting if it’s going to deliver the agility that resilient organizations require. They just need to have routine, simple, safe, reliable, and efficient ways to verify that what somebody seemingly is asking them to do, share, or divulge is a legitimate request from a trustworthy person or organization.

Without needing to dive too deeply into organizational psychology and culture, as SSCPs we ought to be able to help our organizations set such processes in place and keep them simple, current, and useful. This won’t stop every social engineering attack—but then again, no risk control will stop every threat that’s targeted against it either. And as organizations find greater value and power in actually sharing more information about themselves with far larger sets of outsiders—even publishing it—the collection of information “crown jewels” that need to be protected may, over time, get smaller. That smaller set of valuable nuggets of information may be both easier to protect from inadvertent disclosure, but may also become much more of an attractive target.