What's Happening at NIST: Curtis Barker, Computer Security Division chief

National Institute of Standards and Technology computer scientists are delving into ways to secure Web 2.0 and cloud computing technologies as well as devising an easier way for users to identify its controls. Computer scientists at the National Institute of Standards and Technology are actively working on a number of projects aimed at helping federal agencies secure their IT systems.

Helping direct those projects is Curtis Barker, chief of the Computer Security Division at NIST's Information Technology Laboratory. The division provides standards needed to protect federal government information systems against threats to the confidentiality, integrity and availability of information and services.

In an interview, Barker describes active projects underway in the division, including:

Identifying information security processes that can be automated;
Improving ways for federal information security managers to more easily identify controls NIST identifies as crucial to secure government IT; and
Identifying the security challenges of Web 2.0 and cloud computing so federal agencies can safely implement these technologies.

Barker has been at NIST for more than eight years, including the past three as division chief. At NIST, he previously headed its personal identity verification program. Before joining NIST, Barker spent 19 year in business holding a number of IT security and management jobs. Earlier in his career, he spent 11 years at the National Security Agency in a number of roles, including IT security analyst. Barker earned his bachelor degree from the University of Texas, Pan American, and master degree from Johns Hopkins University.

ERIC CHABROW: Hello, I'm Eric Chabrow of the Information Security Media Group. Curt Barker is the chief of the Computer Security Division at the National Institute for Standards in Technology. His group is responsible for many of the special publications and issues that government agencies and even private companies follow to assure their IT systems comply with information security regulations. Welcome, Curt. How are you doing today?

CURT BARKER: Pretty well. How about you?

CHABROW: I'm fine, thank you. What's at the top of NIS Computer Security Division's agenda these days?

BARKER: One is working on aligning our product assurance activities with industry business models and product development practices, so that we can foster a reasonably strong level of assurance in at least understanding the security properties and systems, but not get in the way of their development and marketing activities, any more than necessary. When the government says, "We're here to help you," people tend to duck for cover.

CHABROW: Why do you think this is a concern? Is government getting in the way?

BARKER: We have some fairly robust security and security conformance programs that are in place, as they relate to products in the cryptographic product area, there is a crypto-module validation program and a cryptographic algorithm validation program that are pretty well established, and the industry knows what to expect, and the process for validating cryptography for use by the U.S. government is in place. It's had time to really shake its way out of the rough spots.

When we start looking at computer systems, software products, and even other products that are covered by the common criteria, like firewalls and that kind of thing, we've kind of had a long history of having good criteria for industry to meet, but trying to work out how much involvement government should have in the conformance process has been difficult. Years ago, there was the Orange Book exercise the Trusted Computer System Evaluation Criteria and getting through that process was time-consuming and very expensive for companies. We didn't end up with a lot of high assurance systems. Then, under the common criteria, I think the situation improved significantly. What we would like to do is to further improve that, so that as new products are developed by vendors and come on the market, they can do so, having been through a process in which we can at least, from the federal point of view, make fairly confident statements regarding their cybersecurity properties. This requires a little different relationship between government and industry than we have tended to have in the past.

The other area that we have been working, in the conformance area, has been primarily impacting government agencies. But, it is the Federal Information Security Management Act, or FISMA, system certification and accreditation requirements and processes. The process has improved, I think, the level of security in the government, but it can be, I guess I'll say, very process-heavy. We are working within government and within industry to try to have more automation of the conformance process. The more that you can have machines checked, for example, security configurations of your operating systems, the less manual process, the less expense, and the less time-consuming the conformance process tends to be.

CHABROW: How far along are you in that?

BARKER: With respect to configuration of some of the more commonly employed systems, we actually have tools available that are being used for, again, this is conformance of configurations. A number of organizations have automated tools supporting other aspects of FISMA compliance. We need to do better, and we are working that fairly actively, as a priority this year.

CHABROW: Is there a way to quantify how much of this compliance is automated at this point, and how far do we have to go?

BARKER: It's difficult at this point, mostly because some of the processes can't be automated. The management processes that determine whether or not you are actually using the tools, and whether you are acting on the results that you get from having used the tools.

I'm kind of thinking of an exercise that an industry organization has just gone through, and which they grew controls into 20 categories, about 15 of which were auditable and therefore, perhaps subject to automation, and the other five were not. I think, in terms of a target figure, if we can end up with three-quarters of our controls subject to basically automatic checking against some checklist, as a philosophical approach, we are still going to be stuck with a quarter that are management and operational in nature, and at that point, it's really more a matter of responsible security management than anything else.

CHABROW: Let me just be clear. One of the goals this year is to make it easier to find things in the standards?

BARKER: To improve the ability to search for controls that are applicable to the users, or system owners' specific purposes. The government documentation far more frequently has a table of contents than it does an index. Tables of contents are a little bit like the signs that you see in the grocery store, telling you which aisle to look down. They're organized with a specific set of goals and objectives in mind, and if someone is coming in with a little bit different frame of reference, it's not intuitively obvious where to look for what you need. So, one of the things that we are working is basically improving this ability to find controls, and that project is ongoing.

CHABROW: Would that be using search engines?

BARKER: They have looked at search engines as a possibility. I don't know exactly where he is in terms of the decision-making process for how he is implementing it.

CHABROW: But, the idea would be a process, some kind of technology solution versus when you made reference to an index, rather than just something in the back of the publication that has an index.

BARKER: It wouldn't be a static paper index, no, because that would be entirely too static. The needs change over time, the contents change over time, and we need to be more agile on that.

CHABROW: What other goals does this have for the computer security division?

BARKER: I guess I will group them in a number of categories, for the most part. Most of them are technical in nature.

Security technology areas, or particularly the cryptographic area, we are working on our secure hash competition, it's a transform that will take a large block of information, digest it down to a short stream of nominally a 160 to 256, or 512 characters which can then be used for visual signature purposes, so that you have some assurance in the source and content authenticity of your information. It's probably time that we come up with a new set of algorithms, don't leave the target in place for too long. People begin having success in the case of the hash algorithms, some related algorithms have been pretty much broken, and we think it's time to come up with a new set. So, we have an international competition underway for a new hash algorithm.

We are also looking at key management issues. Cryptographic functions are most easily defeated if someone is careless about how they handle this variable string, or key, that allows, for example, intricate information to be encrypted or a digital signature to be checked. Management of that on a scale of thousands, or even, maybe low millions, is something that I think we probably have a pretty good handle on. But, as we look into the future, I think we are going to be managing much larger numbers of cryptographic keys. We need to have a fair amount of research going, and to efficient and effective key management. So, that's kind of security technology area.

And, systems and network security, the exciting work that we are kind of beginning to look at has to do with security properties of technologies like Web 2.0, cloud computing and so on. While these are exciting technologies from the standpoint of management of information resources, we need to fully understand the security properties of those systems, so that if I send my information to a company which is going to handle processing and storage of that information, we need to be sure that the information is actually well-protected. I need to understand the mechanisms much better. So, we are looking into security properties of technologies like cloud computing, and they're hoping to be able to come up with recommendations regarding implementing them in a manner that protects the security and privacy of the users.

Security management and assistance area, this is where we are, have been mostly doing the FISMA work, trying to improve the usability of some of the documentation, and assessing the completeness of the control set. We are also working at extending our outreach activities, particularly where we are dealing with organizations who voluntarily adopt the FISMA-based standards. Many of those, because it is voluntary, will have a tendency to adopt a subset of the standards, either because it's easier, it's affordable, or for some other reason, and we need to be able to explain the interrelationship of those. I guess the analogy that I use sometimes is that when you start picking subsets of standards and saying that some security controls are more important than others, you're kind of giving the bad guy a roadmap to where to hit you, because, the adversaries, most commonly, try to attack us where we are not protected, rather than where we are protected.

CHABROW: Thanks, Curt.

BARKER: Okay, great.

CHABROW: That's Curt Barker, chief of NIST's Computer Security Division. I'm Eric Chabrow of the Information Security Media Group.

About the Author

Eric Chabrow

Eric Chabrow

Retired Executive Editor, GovInfoSecurity

Chabrow, who retired at the end of 2017, hosted and produced the semi-weekly podcast ISMG Security Report and oversaw ISMG's GovInfoSecurity and InfoRiskToday. He's a veteran multimedia journalist who has covered information technology, government and business.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.