The speed with which an organization can identify, analyze, and respond to an incident determines the damage levied and resources required to resolve and recover from it. So getting executive leadership onboard with that understanding will increase the likelihood that funding and resources will be there when you need them. You can then operate with the confidence and autonomy necessary to bring about the best possible outcome. In the middle of a high-profile incident is probably the worst time for a security practitioner to be going toe to toe with executive leadership.

Depending on the size and type of an organization, it is likely that you will not be able to maintain a team dedicated to incident response. You would then need to identify people to call in, when there is an incident, in advance. Whether or note there is a dedicated team to handle incidents, the make up of the team is critical.

Clearly, people from the security team will be key players on the response team. It is also important to include people from the broader IT team to ensure that there is knowledge of the network, as well as the ability to contact the administrators of systems throughout the organization. Given the varied nature of incidents, you have to anticipate that there may be operational, legal, personnel, public relations, among other issues to consider during formal responses. For this reason, you need to consider proactively having the incident response team having permanent members from other departments. Those departments may include, but are not limited to:

Definition of a team should include definition of a mission statement or charter that describes its purpose and commitments to the business. The mission statement allows the members and stakeholders to understand the objectives of the team, as well as develop expectations and success metrics as to how those objectives are to be achieved. A mission statement might include commitments that resemble those in use by the computer emergency response team (CERT):

It is also important to include non-technical elements of a mission statement, as many incidents may not involve traditional hacking, and will very likely have impacts that go well beyond technology. For example, calls or phishing messages to attempt to have people transfer money are on the rise, and involve a compromise of process, not technology.

Many security teams enjoy a kind of cloak-and-dagger or cowboy culture within their organizations and levy their rapid response capabilities to avoid formalities such as charters and mission statements. However, this shooting from the hip may eventually cause you to shoot yourself in the foot, as your team may not wind up with the aforementioned necessary leadership support when they really need it. Without the clear and agreed-upon objectives and direction provided by a charter or mission statement, the incident response team may lack the authority and support necessary to function at all, let alone effectively.

For the purpose of this book and in keeping with the most foundational definitions, we define the three terms.

It is important to remember that events, incidents, and breaches are not limited to technical happenings, and an organization has to be able to readily identify and respond to them as well. These must be defined and considered as well. You will also need to define the types of security incidents for your organization. Examples of security incidents include

One of the important things to keep in mind about incident definition is that you are just as much excluding what is not an incident. This is not obvious for many programs and will proactively eliminate many concerns. This is especially important where there is still an environment a perception that success is measured by the lack of incidents.

We also have a terrible habit of further victimizing the victim. It does not take long for coverage of a very public breach to turn into a nasty blame game. We hear about how poorly the organization handled things and about the myriad people who were asleep at the wheel for it to have happened. It is not just mainstream media who delight at the prospect of sensationalizing the breach and droning on about the horrific state of security that demands answers. Fellow industry professionals cannot wait to commence with the lambasting and ranting about how woeful and loathsome their brethren at victim X were to have let something happen on their watch. It is horribly unproductive. We, the authors, admit that we highlight the failings of organizations to adequately protect themselves after incidents. In some cases, it is to highlight the importance of proper cyber hygiene. In other cases, it is to highlight grossly inaccurate statements put out by victims to deflect responsibility.

Considering this, it is not surprising that victims immediately brand any successful attack as being advanced. Unfortunately, the adversary community is far better at collaborating about work and how they can work together to improve their craft and achieve their desired and shared outcomes.

Just like controls do not define a security program, incidents do not either. As such, incidents should not be measured in terms of what controls failed. They should be defined based on the actions of the adversary and the ability to respond, rather than focusing entirely on what oversight allowed them to manifest in the first place. As is the case with the adversary community, information needs to be shared, both internally and externally, about what was successful in the accomplishment of an objective as well. This is especially true when the adversary was thwarted through nontraditional means or recovery was made possible after an initial failure.

The adage, “It's not what you did, it's what you did next,” is applicable when speaking about incidents versus controls. Fine; a security control failed and an intrusion was successful. But what did you do to detect that, and how did you respond? What did you learn about your environment that you did not know without battle testing, and how have you improved your posture as a result? How are you using that failure in measuring and quantifying that improvement? Little will be accomplished if an organization's attitude is that the only way for a security program to be successful is for its reactive elements to be never taxed or used.

Information security, such as risk, is patently tough to quantify and therefore to measure in any meaningful manner. It is like proving the negative. “Prove to me you did not read this book.” How do you prove you did not have an incident? So it seems we measure the observable positives; events the tools could detect as being blocked, or actual incidents causing obvious harm.

Information security is risk management. As such, if we assess risk correctly and apply the appropriate security controls accordingly, we can reduce the incidence and impact of security incidents. But what does calculating the number and severity of incidents really tell us? If the number and severity are reduced, is that an indicator of higher functioning security controls, a lower number of attacks, or an unknown number of attacks of significant sophistication? If the number and severity of incidents increase, is that an indicator of ineffective controls, an increased number of attacks, an unknown number of attacks of significant sophistication, or possibly just better detection capabilities added to your program?

As you evaluate your security program objectives, also evaluate your security program metrics and make every effort to ensure that they accurately represent the success of your program as a whole. An individual countermeasure might or might not stop what it intends to stop. Those metrics are easy to collect. Metrics that determine the number and scope of actual breaches are the ultimate measure of the success of your program. Ensure that honest metrics do not get confused with failures. Measure successes and failures against the “outcomes” you want to avoid, not just against the “events” you want to avoid. Lastly, communicate interpreted metrics, especially those regarding incident handling, and not numbers in a vacuum, to ensure that the success of your countermeasures does not control the success of your program.

A comprehensive response must have a firm foundation. This includes extensive planning that accounts for as many potential incidents as possible. It should have the appropriate level of support from management and all required employees already approved and required. Once this base is established, actual responses can be executed properly.