SANS vs NIST Incident Response Steps
What is the superior process?
In the years spent in SOC’s, the common format of an incident response process is pretty formalized, which all things considered is rare in our field. I’ve looked at an article from AT&T Cybersecurity dated January 2020 that talked about the difference between the frameworks from SANS and NIST regarding Incident Response steps part of those processes and talked about how they differed. While I won’t argue the contents of the article, as it’s well written by Elisha Girken, I do want to add my two cents to the matter while I have my pedestal to shout from the rooftops:
“SANS is better.”
But Mark, that’s in contrast to what the Twitter Poll in the article, showing 39% vs 30% use NIST. I know reader, I’m cutting against the grain here, but hear me out.
Why Granularity Matters
Really the only difference between NIST and SANS is the expansion of Containment, Eradication, and Recovery. In NIST, these are all one step (step 3). In SANS, these are Steps 3, 4, and 5. So why do I prefer SANS over NIST? Granularity is the word I’m looking at.
Where my story begins is way back in the earlier parts of my career, I studied for my CompTIA Network+ and was watching the videos from Total Seminars (shoutout for being my go-to for CompTIA Certs!) I still remember Mike Meyers discussing the differences between the OSI Model and the TCP/IP Model, and making the comment somewhere along the lines that he foresaw that the TCP/IP model would overtake the use of OSI, and it would eventually fade out, as networking technologies that come in and out of fashion do. A few years later I am in my SANS SEC503 Course and to my surprise the course essentially tosses out TCP/IP for the OSI Model. Why? Because the granularity the model provided was vital to understanding how packets worked. The TCP/IP model condensed layers 1 and 2 into Network Interface, and layers 5-7 into Application, but to construct and deconstruct packets, you needed that level of granularity to understand how packets are packaged and sent from the application on one host to another application on another host.
This concept instilled with me that the more specific we are in our processes, the more effective we are at conveying information as we, humans, are similar in how we construct messages and pass them to other humans who then have to deconstruct them (we do this almost always as a subconscious thing).
Communicating Ineffectively is an Inhibitor to Remediation
When we talk about effective human communication, we often don’t take into account that communications is a two way street. There’s a quote that I love that asks a very specific question to readers in a Psychology Today article by Caren Osten, and it’s:
“Are You Really Listening, or Just Waiting to Talk?”
The article goes on to discuss the concept of listening and understanding the messages that are being conveyed to us. According to her research, Caren emphasis that only ten percent of us listen effectively. So what can we do to improve that? Well, the best approach is to be an active listener, and understanding the difference between hearing and listening itself. But what does this mean on the flip side? Well it also means we should be effective in our engagement of specific words and messages we use to discuss with our active listeners. We otherwise waste our time not conveying the importance of the message we are sending when we fail to construct accurate, effective, and efficient messaging.
Okay Mark, so how does this all get looped back around to SOC’s and cybersecurity? This did take a turn you didn’t expect, didn’t it? However, you’ve been engaged with my messages, which is part of why I wanted to dive down this rabbit hole in the first place. Which speaking of rabbit hole, a reference to Alice in Wonderland, let’s talk about the purpose of storytelling…
Incident Response is About Telling Stories
If you haven’t heard of this section’s title as a phrase yet in your career in the SOC, then someone has likely failed you (in my humble opinion). A Good story is often broken down into pieces of a good beginning, middle, and end. The fun part of our job, very often the best stories, which consequently are always the worst impact-wise, start at the end. We’ve identified a breach has already happened. Our job then is to describe the who, what, when, where, how, and why in a backwards format; we work our way from the breached system to the initial exploit. The critical component of this is what I harkened to in the previous section: the devil is in the details.
Cyber attacks are always extremely technical, and for good reason. Attacks have to bypass layers of defense and planning to achieve a single victory that gets them in. While we tend to generalize these methods into a kill-chain, like the popular Lockheed Martin version, it doesn’t do the justice, and its often the industry standard now to instead use the MITRE ATT&CK Framework, an extremely complex and robust layout of tactics, techniques, and procedures that help us identify root causes and threat actors.
This is Why SANS Is Better
Correlating everything we’ve discussed, this brings my argument back to center stage: For us to be effective in communicating a strategy, while shorter methods can be more efficient, they aren’t always effective. Combining important and unique steps of our incident response plan does allow us to reduce overhead on tracking metrics like Mean-Time-To-Remediate (MTTRem), but at the cost of allowing us to control the flow of our incident response more effectively. I wouldn’t ever try to recover a system before eradication or containment of a threat, so why should it be in the same step?
This, to me, is why SANS is superior and should be the baseline for SOC’s to build their Incident Response Plans off of (and also why I use it as a template for IRP’s we develop on our blog!)
[/rant]
Enjoy reading our content? Consider Sharing this post and Supporting Us!