What Does "One Hour" Mean for Incident Response?

Yesterday, 8 January 2014, was the 11th birthday of TaoSecurity Blog. Please check out my happy 10th birthday post if you want to know why I don't blog much! In brief: Twitter.
I just read a story which I thought required more than 140 characters of attention: OMB revising data breach reporting requirements by Jason Miller. It says in part:
GAO found OMB's requirement to submit information about data breaches to the DHS U.S. Computer Emergency Readiness Team (US-CERT) within an hour after discovering the breach is of little value...
"Officials at agencies and US-CERT generally agreed that the current requirement that PII-related incidents be reported within one hour may be difficult to meet and may not provide US-CERT with the best information," auditors wrote.
"Specifically, officials at the Army, FDIC, FRB, FRTIB, and SEC indicated that it was difficult to prepare a meaningful report on a PII incident to US-CERT within the one-hour time frame required by OMB. The officials stated that meaningful information on an incident is often not available in that time frame, and reporting an incident to US-CERT without all relevant details would likely be of limited value. While VA officials stated that most of their incidents are reported in less than an hour, they do not believe the time frame is consistent with other US-CERT reporting guidelines and that the majority of the incidents would more appropriately be reported on a weekly basis."
US-CERT told GAO that the one-hour time frame doesn't give a clear picture of the reported incident and the information isn't used to help remediate incidents or provide technical support to agencies.
"Further, US-CERT's Chief of Performance Metrics confirmed that the vast majority of PII-related data breaches are not cybersecurity-related," the report stated. "Specifically, the official estimated that seven of every eight reported breaches do not involve attacks on or threats to government systems or networks...
Additionally, OMB staff said that they were unaware of the rationale for the one-hour time frame, other than a general concern that agencies report PII incidents promptly.




I'm not quite sure if OMB required reporting all incidents within an hour, or just "PII-related incidents." The latter seems true, but the article mentions reporting other incidents within an hour.
If you've heard me speak or read my fourth book, The Practice of Network Security Monitoring, you will recall me mentioning "one hour." The one hour in my context is time from detection to containment. There is no explicit time reporting requirement. There is a difference between notification to implement containment and writing a thorough investigative report.
Furthermore, my one hour recommendation is a requirement for high severity intrusions, not every incident. (The meanings of all these words matter, hence the bold and underline formatting.) Not all incidents are intrusions. Please see my 2009 post on intrusion ratings for examples of different severities.
The reason to strive for one hour from detection to containment is to implement the strategy of limiting the intruder's time of maneuver. If you can stop an intruder from accomplishing his ultimate objective, the fact that he penetrated your resistance systems is less important. What's important is that the intruder didn't complete his mission.
The fact that "OMB staff said... they were unaware of the rationale for the one-hour time frame" shows that requirement was divorced from an articulated, thoughtful, grounded defensive strategy. There is nothing magic about one hour, although I believe it represents an aggressive yet realistic containment requirement for organizations willing to invest in thorough and comprehensive detection, response, and containment processes and technology staffed by motivated CIRT members.
Ideally you implement one hour from intrusion to recovery, but let's save that even more aggressive goal for a time when you can implement one hour from detection to containment!
If you want to read more, chapter 9 of my book explains these ideas. Use code NSM101 to save 30% off when ordering from No Starch.









Comments

Matt said…
One hour from detection to containment should be a realistic goal for any mature information security program. For those in their infancy, it will likely be much more difficult. With a mature information security program, the incident should be detected earlier, with more meaningful contextual data allowing organizations to effectively contain them.

In an immature program, the ability to accurately understand what is happening is more difficult and will probably take longer to determine. It is also more likely that the intruder has become more deeply embedded and may have already accomplished his objective prior to detection.
fraze said…
The one hour from detection to containment wasn't a realistic goal at the time this blog was published. This is especially true for targeted attacks based on stolen credentials.

What a difference a year makes. There are now solutions that detect attackers by using machine learning engines, custom alogs and user credential behavior analytics to see the divergence of employee vs. hacker behaviors. One or two of these solutions also build out the entire attack chain analysis timeline complete with all credential behaviors, systems touched (compromised) and attribution of security infrastructure alerts to credentials.

Detection (>200 days) and analysis (6-10 days) generation/creation are compressed into a single automated process so that upon detection, containment can begin (or even in some cases be automated to begin).

The "Golden Hour" is possible.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics