Albert Einstein once observed, “Not everything that can be counted counts, and not everything that counts can be counted.” This admonition is particularly true when it comes to incident analysis and response.
From all of the data that can be counted, the first step is to get to the heart of what actually counts. The good news is that best-of-breed technologies are doing an increasingly good job of logging, collating, assessing and categorizing just about every computer process you can imagine, as well as many you can’t. They prevent attacks in progress and issue alerts based on pre-defined thresholds.
The bad news is that computers still can’t do everything. A gap in analysis often exists in those areas that Einstein would say count, but cannot be counted. Consider, for example, the roles that business context and business judgment play in incident response. Mature analysis programs simultaneously support tactical IT efforts (kick out the hackers while keeping the systems running), operational requirements (comply with law, including industry-specific regulations), and strategic management concerns (retain customer loyalty, establish risk appetite, and maximize the bottom line). Unfortunately, many companies limit their analysis to the tactical, potentially leaving a lot of important questions unanswered.
Overcoming the cyber analysis gap requires a focus on impact. That’s step two. Technical analysis may determine the duration of an outage or disruption to IT services, but it takes business analysis to understand how that downtime could affect clients and client relations. Technical analysis may determine the quantity and nature of customer or employee data affected, but sound legal analysis reveals a company’s resulting obligations and potential liabilities. Technical analysis may count the number of users or computers involved in a breach, but only the business units fully understand how that can impact performance targets and how best to pivot. Technical analysis may determine that key security controls were compromised, but it takes the leadership to question whether the security program was adequately resourced, staffed and executed.
The NIST Framework is a helpful tool for considering best practices for incident analysis, the goal of which is “to ensure adequate response and support recovery activities.” The underlying essentials include ensuring that notifications from detection systems are investigated, that the impact of an incident is understood, that forensics are performed when necessary, and that incidents are categorized consistent with response plans. This process should be iterative, incorporating lessons learned along the way, such as by refining alert levels and honing response plans.
To close with another Einstein saying, “The only source of knowledge is experience.” Faced with a breach, companies would do well to assemble a multidisciplinary incident response team to address their most pressing tactical, operational, and strategic objectives. After all, it often takes a company’s collective experience to know what counts, and whether or not it can be counted.
