Conflicting information security standards slow acquisitions

Agencies have similar baseline requirements but add custom specifications, making it difficult for vendors to build widely accepted products.

Conflicting information security requirements often hinder the ability of federal agencies to quickly acquire products and services from industry partners, government officials said during a panel discussion on Wednesday.

Though civilian and defense agencies adhere to similar baseline information security standards, many add their own stipulations for products installed on their networks, according to panelists at the AFCEA Solutions cybersecurity conference in Leesburg, Va. These extra requirements often conflict, requiring vendors to customize offerings. For federal agencies, this means procurements are delayed and the pool of qualified products shrinks.

"[Vendors] go through hoops, spends millions of dollars, and are only allowed to sell into that [individual] agency," said David Hollis, senior policy analyst at the Office of the Secretary of Defense. "Agencies have a service-centric approach and in some ways I understand that; networks are different. But there has to be some way to allow manufacturers to test [products] at one agency [and have] them accepted at other agencies."

Baseline standards are necessary because "we won't know as much about the technology as we'd like," said Richard Schaeffer, information assurance director at the National Security Agency.

Vendors can use the Security Content Automation Protocol, he noted, to assess and address vulnerabilities in their applications and to comply with a variety of federal security requirements. Led by the National Institute of Standards and Technology, SCAP tests computer networks and tools for compliance with a range of security requirements, including provisions in the 2002 Federal Information Security Management Act and the Federal Desktop Core Configuration, which requires that agencies standardize operating system and browser settings to prevent security breaches.

"SCAP started as a great idea by a few people, who got a few more people, who got a few more people, and now is one of the critical enablers to security management at the enterprise level," Schaeffer said. "It's not the holy grail, but it's a tool in the toolbox. If you're producing a product that is not SCAP-compliant or compatible, you need to ask why [you're] not there."

One shortcoming of SCAP, however, is it lacks flexibility to allow vendors and agencies to customize software applications to meet operational requirements. The priorities of those focused on information security often are different from those of officials concentrating on technology enablement and innovation, said Bill Hunteman, associate chief information officer for cybersecurity at the Energy Department.

"The policy for employing tools like SCAP that we need and want [to ensure network security] is radically different than what our scientists want in our research labs," he said. "They want the ability to change their systems on a daily basis. We need a set of tools that are SCAP-compliant, but also give us the flexibility. I don't see that emerging."

Hollis emphasized the need for a governmentwide policy on application security.

"I'm not entirely sure how to get there," he said. "We'll need help from industry to write a standard that meets all the requirements for the software application, but is not so specific that it removes certain competitors providing valuable product and services."