Holding the Line

Sunday, April 6, 2014 Posted by Corey Harrell
You end up having to talk to a range of people when building out an internal incident response process. It's a natural consequence because the way people did things in the past is changing and these changes will impact the way they do things going forward. The people you need to communicate with is dependent upon the organization and what the changes actually are. In my case, I ended up discussing incident response with a cross section from the information technology department including: helpdesk, server groups, security units, and management. At some point during the discussions the "why" incident response is needed has to be addressed in order to get buy-in to implement the changes. Thinking about the "why" and the various audiences who need to hear it makes it more clear how concise your explanation needs to be. The message has to be clear and convey the reality we find ourselves in with the threats we face without adding any additional FUD (fear, uncertainty, and doubt) in attempts to influence people's decisions.

Prevention Will Eventually Fail

Despite our best efforts and everything we try to do to secure organizations the end result will be the same. The preventative controls we put in place to protect organizations from the threats we face will fail. The gravity of the situation is illustrated in a three year old FireEye quote:

"today’s cyber criminals are nearly 100% effective at breaking through traditional security defenses in every organization and industry, from the security savvy to security laggards"

The defense in-depth strategies of applying layers of security controls to protect data is incapable of preventing compromises and data breaches. The continuous stream of news about breached organizations from retail stores to universities to public sector organizations is our constant reminder that prevention will not prevent threats from accomplishing what they are trying to do.

Incident Response - The Last Line of Defense

Anton Chuvakin framed the conundrum we find ourselves in with his paper Security Incident Response in the Age of APT (behind a pay wall):

"First, prevention and preventative security controls will fail. Prevention fails on a daily basis at many organizations; it will suffice to look at antivirus tools and contrast their 99%-plus deployment rates with widespread ongoing malware infection rates."

"Second, detection also fails on a frequent basis. A copy of Verizon Data Breach Investigations Report reveals plentiful evidence of that."

"What remains of the entire realm of information security. Only incident response."

"Thus, IR simply has to be there because this is where the security of an organization will fall after all else fails - and it will."

In essence, after every other security control fails an organization's last line of defense is incident response. A line that needs to: investigate, contain, remediate, detect further compromises across the enterprise, and reduce future compromises. This last line of defense is solely dependent on having the right people (incident responders) to carry it out. As incident responders, our job is to hold this line against the threats our organizations face on a daily basis despite everything else failing around us.

To be a catalyst for change this is the message we must convey:

Prevention will fail and when it does, the last line of defense to thwart the threats we are up against is the incident response process and its staff.
Labels: ,
  1. Anonymous

    The sooner "we" as in "IR peeps" realize that we are not a disparate function the better. We are not unchained from the business and we are surely not unchained from our IT Security or IT counterparts. We have to operate as something in between the security, IT ops, and business functions. We really operate (or should be) in those areas to understand the "who, what, what, where, when"...and can be a conduit between those groups.

    Once we figure out a major portion of our job is not necessarily "IR" work in the traditional sense, the better we can get at actually detecting and responding. Heck, even our feedback can help some of that resistance security too.

  2. I can't agree with "Anonymous"...this isn't something that "we" have to come to realize. I've always seen IR folks (and the function as a whole) as something akin to snipers deployed in VietNam...commanders were faced with guerrilla forces, and were comfortable relying on conventional forces to get the job done. As such, few wanted to learn what snipers could provide them, so many of the unlucky snipers were subject to burning sh*tters.

    The fact is that in many cases today, business "leaders" have an IR function "forced" on them by some outside entity, usually part of some business compliance function. They really don't have much of a focus on security in relation to their business, so they tend to view this function as a burden...they now have people doing something that does not add to their bottom line. In the manager's mind, there is no line they can point to in a report that demonstrates what funds this IR function brings in to the business.

    Management needs to understand that business function of security, in general, and IR specifically, just as they understand the business need for functions such as HR, payroll, order processing, fulfillment, etc. Once we get to that point, there will no longer be the need for IR staff to spend ridiculous amounts of effort trying to sell or justify themselves.

  3. @anon

    Most of the responders I know came to the field either from security or IT. As such, most have a good understanding how IR fits into IT and information security (including IT security); in general IT security folks could know more about the business side. I think the issue is more along the lines of what Harlan mentioned. Management needing to view security as a business driver and ensuring it not only has adequate resources but the authority to implement change.

    As it relates to IR, regardless of the organization, IR team structure, or team's purpose one common service is reactive in nature. If management truly viewed security as a driver then instead of trying to get buy-in to support the reactive service, management would view IR as a resource. A resource that can be leveraged to further the organization by harnessing the information generated by the IR team when it responds to security events, alerts, and incidents. This information can help management make more informed decisions since they will have a clearer view about the threats they face and the security posture of their organization.

Post a Comment