Cyber threat detection and prevention in the supply chain is a growing issue for federal acquisition. The National Institute of Standards and Technology is formulating best practices and, soon, guidance for agencies to acquire secure IT products and services. Improving acquisition could be a first step in encouraging more transparent supply chains and more secure technology.

FierceGovernmentIT recently spoke with Marianne Swanson, the senior advisor for information technology security management in the Computer Security Division at NIST, about the organization's work in this area.

FierceGovernmentIT: Your team recently released NIST IR-7622 (.pdf), a draft interagency report on supply chain risk management for federal IT. Can you tell me about that document and explain how it's different from a special publication or more formal NIST guidance?

Marianne Swanson: A NIST IR is similar to a whitepaper. A NIST IR could be a report or it could be conference proceedings, it outlines good strategies to consider that are not mandatory.

It was really important that we put this document out as a NIST IR, because we wanted to use it to test the waters to see if the approach makes sense to people.

When we turn it into a special publication, a year from now, that's different. The [Office of Management and Budget] has mandated that all federal agencies must implement guidance in NIST special publications. So, the NIST SP becomes much more compliance oriented.  

It's required that special publications are implemented by federal agencies, not private industry. So even though this is a supply chain document, it is for the federal agencies to use and determine the best way to work requirements into procurements. It's not mandating that private industry do anything.

FGIT: So, a NIST IR is typically used as a preliminary document to build an SP?

Swanson: No, it does not necessarily work toward a special publication. For example, sometimes there will be work done in a specific area and it will be shared publically as a report. So a NIST IR can be a NIST interagency report, where several agencies have worked together and they just want to share the work product or research--you can issue it like a whitepaper. Or it can be a NIST internal report, meaning that only NIST staff worked on it.

FGIT: Let's talk about the problem of supply chain risk management. What issues are federal IT managers facing? What risks might be mitigated by NIST guidance in this area?

Swanson: You could do a Google (NASDAQ: GOOG) search and find a variety of incidents that have occurred when a supply chain has been tampered with, somewhere along the line. When that happens, organizations have less assurance that the product includes the correct components, which are functioning correctly, and when they need to function.

For example, there are call home features, typically used for remote maintenance, but can also be used  by a product to access your network and send out sensitive information.

If you do a Google search on cyber supply chain incidents, you may find that there are silicone chips that people have discarded. When we discard computers, many times we send them to a special spot in a landfill. From there, they could get shipped off to a company, who ships them off to another company--maybe offshore--who then takes the motherboards, pulls off the silicone chips and ends up filing off the serial numbers. They clean them in a back alley, not a clean room, and re-stamp them as high-grade silicone chips that can be used maybe by the military.

These are not real high-grade chips, but they get repackaged and people buy them thinking they're the real thing. They could put them into helicopters, and when the helicopters need to do some specific maneuver requiring a high-impact or high-functioning silicone chip, it doesn't have the capability because it really wasn't the right chip--it was in someone's desktop somewhere--and the helicopter can malfunction and crash.

This information is out there and these things happen.

FGIT: So, supply-chain problems can be anything from counterfeit hardware parts to embedded code...

Swanson: Yes, malware can be inserted into products as well. So, maybe it is a high-functioning chip, but it's been programmed so that when it goes into this special mode--when you need the high-functionality--it purposely malfunctions.

In fact, when we were in the symposium the other day, it was said, "just use your imagination." You just don't know; a supply chain disruption could be anything.

The key, what we need to start doing--and what I have said and what the document said--is checking this for those critical components, those critical systems. You need to be thinking about and starting to implement assurances when you're procuring the products. And the vendors that you're purchasing from should also have transparency into their vendors' supply chains, and they can start to provide assurances, as well. The supply chain then becomes secure.

We're not saying, in the document, that this needs to happen with every purchase that you make, but with the critical components, those critical pieces in your cyber infrastructure.

FGIT: The draft IR went out to comment. What's next?

Swanson: We're working on incorporating the comments that we received and we'll be putting out a final version around the beginning of the year. Then, that final document will be available for agencies to use and implement.

It's called "piloting," so, really what we're trying to do is have agencies take the language, take some of the requirements that are in the guide, put them into procurement language and report back to us on how well it's working for them.

We also want them to work with the [General Services Administration], and have GSA report back and let us know how it's working. Because GSA is conducting some large, government-wide SmartBUYs using some of this language, and we need to hear from them about whether or not it's achieving a level of assurance.

[Department of Homeland Security] is also doing various pilots and we need to hear from them on whether or not the language is working, how vendors are responding and if they're getting enough transparency from the vendors to help make a selection.

FGIT: When the IR went out to comment, who provided feedback? I'm curious how a NIST strategy will fit into some sort of international standard. Were any international bodies sought for comment?

Swanson: Actually, there aren't any international standards out there yet for cybersecurity supply chain. There are standards for maritime and shipping supply chain, and there are a few acquisition-type international standards, but nothing directly related to cyber supply chain.   

So, we're working with [the International Organization for Standardization] on a cybersecurity supply chain standard. So, our best practices and this guide are going to be used--and already it has been used--as the base for submitting an ad hoc proposal to ISO on what we think the standard could look like.

We're definitely dovetailing this with the whole standards arena.

FGIT: What about the comments you received from industry?

Swanson: Well, when we were creating the document, we were working closely with the IT Sector Coordinating Council and the Communications Sector Coordinating Council, which are groups set up by DHS.

There was a key group within each of the two sectors that commented and helped really frame how the document should be put together, so that we would have requirements that a federal agency could write if they were hiring an integrator, for example. Or if I was buying [commercial, off-the-shelf products] just from a vendor what I would require from a vendor and what I could require-because, you know, from a COTs perspective it's very different. You really don't have that much you can specify.

But with an integrator who's actually bringing pieces together and building it for the agency, you have a lot more control. And so we wrote the guidance that way, primarily because they said, "this makes much more sense." So they have roles, vendor roles and integrator roles, and then the federal role and that was something that they really helped frame the IR for us.

FGIT: Is the need for greater, or easier, customization of COTs products something that GSA may be able to leverage as well?

Swanson: Yes, definitely. So the requirements that are in there for a supplier, a COTs supplier, would definitely apply to GSA. In fact, I think GSA has been using some of the requirements language from the NIST IR.

FGIT: In the past, the Common Criteria project has been used to test products and make sure they do exactly what they say they can do. Do you envision a next generation of this project that could assess that products only do what they say they do and nothing more?

Swanson: [The National Security Agency] has been pursuing the idea of a common criteria evaluation protection profile from a supply-chain perspective.

FGIT: OMB's recent "cloud-first" procurement announcement and NIST's work on a cloud computing standards roadmap have me thinking about how supply chain risk management fits into cloud computing. Is your team working with the cloud computing team at all?

Swanson: Not yet. But that doesn't mean that we won't be. I definitely think the issues that any federal agency faces when procuring equipment apply to the cloud providers as well. And so it presents the same issues of the quality of the product and the assurance that the product is what it's supposed to be. Definitely that's something that we will have to pursue, but we haven't gotten involved too much, yet.

Related Articles:
Hathaway: Global standards, vendor accountability key to securing the supply chain
Commerce Department cybersecurity not adequate, say auditors 
Commission: China Telecom routed .gov and .mil traffic to Chinese servers 
DOT auditors fault CIO cybersecurity hole prioritization policy 
DHS official: Variants of Stuxnet could attack industrial systems 
Guest Commentary: Certification and the cybersecurity human capital crisis