NIST Readies Incident Coordination GuideGuidance Goal: How to Extend Trust Beyond the Enterprise
Creating circles of trust - networks of IT security professionals who trust one another - is a key element in forthcoming National Institute of Standards and Technology guidance on incident response.
NIST issued a request for information to gain feedback on the prospective guidance to be known as Special Publication 800-150: Computer Security Incident Coordination. The manager in charge of the forthcoming publication plans to cull the RFP responses for ideas to build that circle of trust.
"Having that circle of trust is very beneficial, but the process of forming such a circle of trust is informal today," Lee Badger, NIST manager of computer security and mechanisms group, says in an interview with Information Security Media Group [see transcript below].
Participants in circles of trust are more likely to share sensitive information on threat indicators, vulnerabilities and anomalous behaviors, he says.
IT security professionals generally create circles of trust among people with whom they regularly work, organized around the skills and reputations of members within their own enterprise. "Those folks trust one another because they know one another and they've helped each other in the past."
Finding other trustworthy experts beyond the organization can aid in preventing and mitigating computer incidents. "We're hoping that we'll get some feedback in this RFI that will help us get a little leverage on that problem of how to establish and maintain those kinds of sharing relationships," Badger says.
In the interview, Badger:
- Explains how the new report will complement SP 800-61: Computer Security Incident Handling Guide, which provides guidance on establishing computer security incident teams;
- Discusses the challenges organizations face in sharing cyberthreat information, in part, because of a lack of trust;
- Outlines other types of guidance that NIST expects to include in the new publication.
Before joining NIST in 2008, Badger served as a Defense Advanced Research Projects Agency program manager focusing on self-regenerating systems, intrusion tolerance, self-defending applications and software security analysis.
Incident Response Coordination Guidance
ERIC CHABROW: First off, please take a few moments to explain the difference between the existing Computer Security Incident Handling Guide and the forthcoming Computer Security Incident Coordination publication.
LEE BADGER: The original document, 800-61, is really providing guidance about how to set up and organize an incident response team. That has basically four pieces: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. This is a very important document. One of the topics that the document covers though, a little more abstractly than others, has to do with the coordination between computer security incident response teams. While 800-61 does cover that, it's not the focus of 800-61. However, the coordination between these kinds of responding teams is really crucial to preserving security and recovering from incidents, because what one team learns another team can benefit from. That's the focus of our following document.
CHABROW: I want to get to that in a moment. But first off, with the new guidance, who will be the audience for it?
BADGER: The audience for the new guidance will basically be systems administrators, system owners - basically everyone in the information technology management chain - information owners, responders and security officers.
CHABROW: Computer security incidents could involve more than one organization. What challenges exist in coordinating incident response among several organizations?
BADGER: There are at least several. One is that while it's important to share information to help another incident response team, sometimes the information that you would like to share carries sensitivity. It might contain personally identifiable information or it might contain proprietary information; or it might reveal techniques that are in use by an attacker; or it might just reveal that you're having an attack and so that carries some reputational risk. There's a balance that has to be struck between sharing when it's appropriate and not exposing itself or others to risk through undue disclosure.
CHABROW: When you talk about coordination, are you talking about incident handling teams, or is there coordination among other parties as well?
BADGER: It's primarily between the teams. We're writing this guidance for the benefit of the teams. However, a computer security incident response team will interact with a number of other parties in the process of doing what it does. It will have to interact with customers, ISPs, law enforcement and management in various organizations.
CHABROW: Let me just back up a bit. From your vantage point, do you think most organizations have these response teams in place, or is it often an ad hoc approach?
BADGER: I can't say what most organizations do. However, I can tell you that different industrial sectors do have computer security incident response teams and associated information sharing centers that express policies for a particular sector of the economy.
CHABROW: The so-called ISACs?
BADGER: Yes, CERTS are also operated by other nations. Lots of large companies have response teams, and agencies in the government have response teams. If you look at some of the large companies, they might have more than one response team. There's a question of inter-team coordination both within a large organization and between organizations.
Incident Response Guidance
CHABROW: Within your RFI, there are 38 questions, and that shows that NIST has already been thinking about this new report and is not working in a vacuum. Can you provide a few examples of the type of guidance that would likely be found in this report?
BADGER: I would prefer not to get specific about it until we've had a chance to collect and analyze the response to the RFI. We certainly, though, want to develop guidance that would, for instance, characterize the kinds of information beneficial for exchange between incident response teams, maybe provide some way of structuring and understanding so that it can be done more quickly and more reliably when an incident actually may be unfolding.
Another kind of guidance that we're interested in is guidance on how to form and maintain circles of trust. Today, response teams seem to be organized substantially around the skills and reputations of significant members. Those folks trust one another because they know one another and they've helped each other in the past. [It's] having a network of folks that you feel comfortable with that they won't disclose inappropriately the information, and that they have technical skills that can help while an incident is in progress. Having that circle of trust is very beneficial. But the process of forming such a circle of trust is informal today. We're hoping that we'll get some feedback in this RFI that will help us get a little leverage on that problem of how to establish and maintain those kinds of sharing relationships.
CHABROW: When you talk about coordinating incident response, one organization could be under attack, for example, and the same problem they're facing may not be faced by another organization, but the other organization could be called upon to help mitigate this?
BADGER: That's one scenario and, in fact, in some circles of trust that does happen, though oftentimes they don't really say, "Hey, I'm under attack." It would be more like, "I've seen these kinds of indicators, information or behavior in the network. Does anybody have related information, or has seen a piece of malware?" It's often not necessary for a participant to indicate that they've been damaged, but just the ability to talk about indicators of attack would usually be enough.
Collaborative Incident Response
CHABROW: One of the objectives of this guidance is to expand the expertise available to an organization to understand cyberthreats. The RFI raises questions about risk of collaborative incident response and technologies that have been found ineffective. They sort of have a negative connotation than what you're seeking. What does NIST hope to learn from those examples?
BADGER: We're hoping in this RFI to collect the insights of actual practitioners about technologies, techniques or even procedures or methodologies that have been beneficial in the past, and that seem to be scalable to the very large networks that we see coming in the future. On the other side, we're explicitly asking practitioners to give us insight about the kinds of guidance that could be harmful by, say, requiring processes that are onerous or that are slow [or] too encumbered.
CHABROW: When you learn about these things that could be a hindrance, would this be mentioned in the guidance or is this just something that you learn and won't put into the guidance?
BADGER: That's an interesting question. I think generally we would be silent rather than listing things that we're explicitly not saying. However, if there's a chance of ambiguity, of misunderstanding, then we might go ahead and articulate some guidance that we think is not a good idea, just to clarify that we're not suggesting a particular piece of guidance.
CHABROW: Soon you'll have these responses to the RFI. What happens next?
BADGER: We'll review, analyze and correlate. Of course, all of these responses are public and we post it publicly. After that, we will start working on a draft of our document. We'll probably have a number of meetings with folks who have responded to the RFI if they want to, and try to do some deeper dives depending on the answers that we've received. It's likely that at some point there will be a workshop and then there will be a public draft of SP 800-150.
CHABROW: Any timetable on any of this?
BADGER: We certainly have a timetable in mind; however, it seems to be sliding.
CHABROW: There's lots of work out there to do.
Differences Among Organizations
CHABROW: Anything else you would like to add?
BADGER: One of the elements we haven't talked about yet that's going to be important to our work is understanding the differences between organizations and their capabilities. Some organizations are very mature and have made a big investment in incident response and coordination; other organizations are less mature or they're smaller and they have fewer resources to devote to this kind of function. Part of the challenge of this work is trying to provide guidance that's actionable and helpful both to the large and sophisticated organizations and to the organizations that just haven't had as much time or as many resources to pour into it.