Department of Justice: Steps Toward Mitigating Risk

Eric Green of the Infowar Broadcasting Network talks to Dennis Heretick, chief information security officer with the Department of Justice, about information warfare, risk mitigation and infrastructure protection.

Green: In such a multifaceted agency, how do you quantify, how do you categorize what you have to deal with as you approach the issue of security? What are the first steps you’ve been taking over there?

Heretick: The key to that is starting with our mission needs, looking at our mission objectives and the risks to those mission objectives. Then identifying the security controls that mitigate those risks or directly support a mission objective. Preventing terrorism is our number-one goal, one that we share with many federal agencies, and of course a big part of that is data sharing and preventing that information from getting into the hands of people it shouldn’t. Much of that information has to be protected by law; other [information has to be protected] just in support of your mission. So the ability to look at risk control requirements that would allow you to encrypt data, that could give you techniques for preventing it from being copied, gives you a great trust relationship with whoever you share that sensitive information. So you use both the mission need and the risk, and then prioritize requirements based on those two parameters.

And so I think the benefit is also the challenge, in that when you’re within your agency, you can kind of say, this is our guideline and this is what we’re going to be doing and you can only hope that the people who report up through you do it. Now we’re going to start crossing agencies and we’ve been talking about information sharing, and so if everyone is using a different risk-based structure and everyone is using different systems, forget about whether the systems can talk to each other; the security risks might not equate to the same levels. How do you deal with that?

That’s something that we’ve always had trouble dealing with because we have to share information across agencies. Mr. Meyerrose, the CIO for the director of national intelligence, has formed a group including key players DoD, NSA and NIST, and they are really integrating the intelligence community requirements into the 800-53 set of requirements from NIST. That set of requirements, when you continue to add other types of requirements such as financial system requirements from FISCAM, then you get what might be referred to as meta controls. And then depending on the scope of your system, you can add those controls that apply to you. Depending on risk and mission need—mission need for confidentiality, availability and integrity is the one we use most frequently across different organizations, both private and public—that gives you a way to categorize the level of protection that you need for a system.

Green: On a daily basis, are you more worried about these systems that are not in your control, or are you, frankly, more worried about this counter-terrorism side of things and someone getting into your system directly? You’re dealing with two different things here.

Heretick: My main worry is preventing the primary threats to the Department of Justice systems. Now, we want a way to deal with other agencies because, first of all, the solutions that they have often can be applied to Justice systems. We’re not unique in the solution sets in private industry or government. But what we’ve found, through forensics on attacks that have been successful, is that most of [incidents] are allowed through basic [attacks] that we already know about. It’s not necessarily the zero-day attacks that just pop up and really hurt us. It’s basic things we already know to protect ourselves against. So that prioritization that I talked about is critical, and prioritizing the controls and implementing those things are basic weaknesses. The criminals and others who attack our systems are not doing that, for the most part using high-tech methods. They’re using the basics. So what would keep me up at night is not to have done due diligence in doing the basic protections.

Green: One of the things that you were able to create, of course, was CSAM [the Cyber Security Assessment and Management system]. It’s a FISMA control appliance, but the bottom line is it’s about security and it’s about analyzing what’s happening with your systems. Knowing what systems you have, and controlling those systems. It would be interesting to hear a little bit more about where that came from and where is it now.

Heretick: We found that we were spending an inordinate amount of money doing security planning rather than implementing the priority controls. So our objective was to automate as much as possible in the planning mode. It’s not that we don’t want to do planning, but we would like to do it in a way that lets us focus on implementing priority controls: the identification of the requirements, prioritizing them based on the risk, and then being able to have compliance guidance that provides specifics on how to implement that control. What technologies would be used or what documents, if it’s a document that’s required. And then provide templates for those documents and the test case. Prewrite the test case so we don’t have to spend our time rewriting all that documentation. Then separate our enterprise solutions from those requirements for things that have to be done at the individual system level, so that we can have projects to implement really exciting solutions in vulnerability management, secure configurations, access controls, incident response.

[We want to have] program managers assigned to those areas who then can implement controls for systems that are within the enclave that’s being protected. Then the system owner can focus on those things they can do. So you inherit the controls from the larger systems, and CSAM is used, not only to document the requirements first, but then to do the program management plan to basically identify the enterprise solutions and the individual system solutions, and then the plans of actions and milestones, goals and performance metrics, and performance tracking. And of course, it generates 95 percent of the system’s security plan because that’s what’s in CSAM, descriptions for test cases, requirements, priorities, the scope of the system, the security category, and that inheritance.

Then you can spend your time implementing the system and building the testing into the implementation process, which is the third piece of that. That way, you’re starting off implementing the controls that are the highest priority for your system. You already know what the test results should be because you’ve got the test case as an implementer, and you work the tester to make sure you have that same understanding, and then you can generate all the management reports, so you’re not spending a lot of time on data calls and generating reports. CSAM has got all that information entered once [so it can be] reported many times.

Green: Back to the risk point, the benefit of having other agencies using CSAM goes back to my comment earlier which was its like/unlike. You know that they are monitoring their systems. You know the risk—the risk you’re undertaking is quantifiable and you can make a decision based on fact, like to your systems, whether you want to take it or not.

Heretick: That’s exactly right. So that your test cases and compliance guidance, you constantly improve those, but by having other federal agencies as partners, you can look at the improvements that they’ve made in specific areas and incorporate them so that all of our capabilities rise and we can communicate with one another on exactly where we are in implementing those expected results in each of the control requirements. That gives you a common understanding of what security you have versus what we have. When we share [sensitive] data, we know the level of risk that you’ve protected against. If it’s not at an adequate level, then we can’t share the data. Or at least if we do share it, we know we’re sharing it and we know the risk of sharing it because of the lack of protections in some areas and we can put more emphasis on that.

Green: How many other agencies are looking into this data-sharing area, and who are the people you’re talking to—is it your counterparts? CIOs? More technical people? Who are the people who are buying into this?

Heretick: We have 13 federal agencies that are part of this effort. Many of them are intelligence community members, and the intelligence community, in this case, helps us to protect non-intelligence community systems. The intelligence community incident response center, for instance, is giving us information on key areas to protect, telling us which software patches are critical. That is critical information, and building that capability into CSAM gives us a way as a whole community to be doing the right thing. We work with CIOs from most of the federal agencies; certainly my counterpart, the CISO, in every case; and then because of the defense and breadth that we cover with the NIST 800 controls, the intelligence community, DCID 63 requirements, FISCAM requirements—even HIPAA and SOX are of interest to us—because we want to pick up a wide range of requirements and make sure that we’ve not left pieces out that are of interest to a community. You don’t have to apply all of them, but by working with different levels in the other federal agencies, you pick up those specifics and can get down to the specific compliance guidance and cost guidance for implementing these controls.

Green: So for many years now, everyone’s been looking to the private sector for stuff like this, so should the private sector be looking back to you guys for something like this now?

Heretick: I would love to partner with the private sector on this, and there are a number of initiatives that are ongoing. Robert Rodriguez, for instance, is sponsoring efforts with Stanford University and the community there. Another is the IT Security Exchange, which takes the same controls we’re talking about and is a wiki, if you will, for solution sets, for those controls, and so you’ve got a requirement. Instead of waiting for vendors to come to you and tell them what they can solve, you start with the requirement, go to the solution sets, and contact the vendors that provide support in those areas.

Eric S. Green is COO and security practice leader of Larstan Publishing and co-chair, with Winn Schwartau, of InfowarCon 2007 (www.infowarcon.com). In addition to co-hosting the Infowar Broadcast Network and hosting the SecureIT Podcast show, Green has been deeply involved in the security industry since 1998 with his groundbreaking CISO work for Fortune magazine. As Larstan’s group publisher, he has been responsible for more than 11 titles ranging from the topics of security to those of podcasting, service-oriented architecture, public relations and personal finance.