Ensuring IT Products Meet DoD Standards

Measuring Success of Security Technical Implementation Guides
Ensuring IT Products Meet DoD Standards

The Defense Information Systems Agency is working with vendors to ensure their products meet the Defense Department's demanding security standards.

See Also: Live Webinar | Cybersecurity in Healthcare Supply Chains: A CISO Perspective

DISA's Security Technical Implementation Guides aid vendors in understanding the Department of Defense's security requirements for products DoD uses.

Noting how the onslaught of malware is having an adverse impact on organizations, Terry Sherald, who heads DISA's STIG efforts, says: "Helping the vendors to build more secure products is going to be beneficial to everyone in the long run. Building security into the product just makes everyone's life easier because they can still build functionality and still keep security in mind."

Over the past few months, DISA has been helping mobile device maker Samsung understand DoD's security standards, so the South Korean manufacturer can tighten security for Knox, its mobile security software for Android devices. If Knox meets DoD's exacting security standards, the department would authorize the use of devices that employee the mobile security system.

In in an interview with Information Security Media Group [transcript below], Sherald discusses:

  • Use of STIGs to help vendors understand DoD's security requirements;
  • Interagency cooperation within the federal government in developing security standards; and
  • How DISA will measure the success of its work with technology vendors to create secure technology.

Sherald serves as chief of the DISA Field Security Operation's Information Assurance Standards Branch. She has 28 years of government experience; the last 20 years have been focused in the information assurance security arena. Besides STIGs, Sherald manages the development and release of the Department of Defense Security Requirement Guides. She served as a member of the federal government's Joint Task Force Transformation Initiative Interagency Working Group, led by National Institute of Standards and Technology's Ron Ross, which developed NIST Special Publication 800-53A: Guide for Assessing the Security Controls in Federal Information Systems and Organizations, a key component of NIST's risk assessment guidance.

Challenges in Using Mobile Devices

ERIC CHABROW: To get started, why don't we talk about the security challenges the Defense Department faces in allowing the use of commercial mobile devices?

TERRY SHERALD: There are probably three that jump right out at me. The biggest is implementation of PKI [public-key infrastructure] on the device. Then there's the protection of DoD data on the devices, especially as people are thinking about trying to do BYOD [bring your own device]. We have to make sure that if there's information that will be stored on the device, it's done in a secure way; and implementation of strong, remote network access procedures.

Samsung Knox

CHABROW: DISA worked with Samsung to help secure its mobile devices. Samsung has a new enterprise mobile security solution known as Samsung Knox, which is intended to be deployed on its commercial devices. First off, did DISA reach out to Samsung or vice versa? How did that relationship come about?

SHERALD: Some of the earliest contacts came from some of Samsung's business partners. They have worked with some of our STIGs in the past, so they actually made the introduction between Samsung and my support staff.

CHABROW: With Samsung Knox, the intent is to provide some security to their devices. Were there shortfalls in that solution?

SHERALD: We worked with them early so when we found a few shortfalls, we were able to work with them as they were developing the product. They were able to make some changes to the product so that it would meet requirements. A lot of the earlier work was in being able to help them understand what the DoD requirements were and then how those would be utilized, what the capabilities were in their product and how their product met those requirements.

Security Requirements

CHABROW: What features must be in a mobile device to satisfy DISA's security standards?

SHERALD: There are 140 separate requirements in our mobile security requirement guide. The requirements include things like protection of data stored on the device; protection of data that's being transmitted or received; malware blocking; control of the applications installed on the device; as I said earlier, support for PKI and the capabilities of the device to be controlled by a mobile device management server. In order for the product to successfully be able to have a STIG applied, they do need to address all of the requirements in their security technical implementation guide, or STIG.

Defining STIGs

CHABROW: Exactly what are those?

SHERALD: STIGs are configuration guides. Historically, they have been created and developed by DISA's Field Security Operations, the branch that I run, and they're actually DoD policies and best security practices together combined to tell how to properly configure a product or an IA [information assurance]-enabled device to be used on the DoD network. The change here has been in that, typically, as I said, Field Security Operations developed the STIGs. And what we're doing now is trying to reach out to the vendor community and allow them the opportunity to write a STIG for their product, because they know and understand their product better than anyone else. Being able to write a configuration guide for their product just seemed like the right idea.

Vendor Process

CHABROW: How does that relationship between DISA and Samsung work? Do you have certain people on your team and their team meeting, or are you sending messages?

SHERALD: What we've done is we've actually set up a process. We have a vendor intent form. The vendor can go out and get the intent form and say, "I'd like to write a STIG for my product," and they have to describe what their product does and what type of product it is. We have security requirement guides that we have developed in the mobile area. We have a mobile application; a mobile operating system; we have a mobile application security requirement guide; we have a security guide that addresses the mobile device management servers; and then we have one for policy. If a commercial mobile device vendor wanted to create a STIG, they could go out, download this intent form and send it into us.

What we do is we assign a security matter expert to work with them, and that person is there to go through the requirements with the vendor and allow them opportunities to discuss them to try to get an understanding of what the requirement is. Then they're there to help the vendor as they're going through the process of writing this STIG to make sure that they're gathering all the requirements, all the things that we need to have addressed in the STIG, and following the format that typically the STIG looks like so when the STIG comes out it does still look like a typical STIG. We do work very closely with the vendor. We have to define the requirements; the DoD defines the requirements. The vendor is writing to those requirements and then we're helping the vendor through the process so that we have a STIG at the end that can be used for a product that can be used on a DoD network.

Off-the-Shelf Devices

CHABROW: These mobile devices that Samsung is going to provide that meet your standards, are these being configured specifically for the Defense Department or are you looking for them to have a product that's off-the-shelf that you or maybe employees can buy?

SHERALD: The goal is that we can have a product that we could use off-the-shelf. By working with the vendors and being able to help them understand the DoD requirements, we're hoping that they'll be able to take those and then build them into their product to make the product overall more secure.

CHABROW: Is this what's happening with Samsung?

SHERALD: Yes, I believe it is.

CHABROW: So it's the operating system that could go into various different products, the idea that if the Samsung device has it, then that would be meeting your requirements?

SHERALD: Right, if the Samsung device can use a Knox operating system. The STIG would address the Knox operating system and how it would be implemented on a specific device.

Importance of STIGs

CHABROW: Are you in contact with other vendors?

SHERALD: We actually have quite a few vendors that have come forward and said that they would like to write a STIG. We have two mobile-device-management vendors and a couple of mobile-commercial-device vendors that have come to us. But we're also taking this process that we've developed and reaching out, and we're actually working with several other basic operating system vendors. We're working with a database vendor. We have three Domain Name Servers STIGs that we're working on with a vendor and we have an application server. We have an IDS/IPS [intrusion detection system/intrusion prevent system] product that we're going to do a STIG with. The exciting thing to me is that this is a process that was started to meet a need in the mobility world, but we're able to take this process and also use it for other vendors to help get their products with a STIG.

CHABROW: Why is this important?

SHERALD: STIGs are used for a lot of different things. They're used to configure your system. They're also used within the DoD to do certification and accreditation. If you're an organization and you want to be able to use a product, one of the first things they're going to want to know is if there's a STIG. If there's a STIG, it makes it much easier for you to be able to bring this product in and connect it to a DoD network, because they know that the testing and the validation of the product has already been done and there's a set of configurations that can be used to validate that the product meets the requirements.

Government Collaboration

CHABROW: The DoD is a major purchaser of secure IT supplies, and the standards that you developed could influence the commercial product and could become maybe a de facto standard. There are other agencies in the federal government, such as the Department of Homeland Security, that may have similar concerns. Is there any kind of consultation on a government-wide basis?

SHERALD: Yes. We work closely with DHS, we work closely with NIST [National Institute of Standards and Technology] and we work closely with NSA [National Security Agency]. Everything that we do is typically vetted through the community so that we're not getting out of sync with everyone else. What we're doing is we're trying to keep in step with what the rest of the organizations are doing. I do think there's a lot of partnership in the community in the government.

CHABROW: How long does the process like Knox take from your perspective, developing the STIG for that?

SHERALD: Actually developing the STIG itself, we aren't putting a timeline on the vendors. We're making ourselves available to them, to work with them to try to develop the STIG, but we aren't putting a timeline on them. We're basically more or less putting a timeline on ourselves that once we have the STIG we can get it tested and processed within a timely matter. With the first four vendors that went through the process, it took us about 90 days from the time that we got the document until it was released.

Measuring Success

CHABROW: How will you judge whether what you're doing there in developing these STIGs works?

SHERALD: I look at whether it's working if we have any of the vendors joining in. That means we're getting the word out and they're aware that they now have the capability to write their own STIG. I also look to make sure that people are going through this process and they're being successful in getting their STIG developed. I think time alone will tell how the market goes. But I have very high expectations that this is going to be a successful process. Helping the vendors to build more secure products is going to be beneficial to everyone in the long run, especially today with all of the malware attacks and everything that's going on. Building security into the product just makes everyone's life easier because they can still build functionality and still keep security in mind. We've been doing STIGs since the 90's. It's nice that we're finally now to a point where we can start bringing vendors in.

One of the successes of this program has been the security requirement guides that we developed. Laying out the actual requirements for technology areas is something that I think the vendors have been looking for, and that's one of the things that I've heard from all of the vendors that we've talked with through this process so far - how much they appreciate having this list of requirements so that they know what the DoD wants in a product when they bring it to them. That has been something that has been very successful and I think that's something that I'd like to get out. It's a very good process we're building. We're trying to help identify for organizations that want to adopt these products the products that have been through this testing [and] validation and that [have met] DoD requirements, giving them the ability to better assess the risk to their environment as they bring these products in.

That's another thing that the requirement guides are doing. They're helping us to be able to level-set the community and say, in this technology area, here's the set of requirements - the ability for you to be able to see which products actually meet the requirements and how well they meet them.

About the Author

Jeffrey Roman

Jeffrey Roman

News Writer, ISMG

Roman is the former News Writer for Information Security Media Group. Having worked for multiple publications at The College of New Jersey, including the College's newspaper "The Signal" and alumni magazine, Roman has experience in journalism, copy editing and communications.

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.