The administration has been pushing agencies to include more cybersecurity language in contracts, specifically in citing control standards like those advanced by the National Institute of Standards and Technology. Some officials don’t think those standards are enough and are encouraging agencies to get specific with vendors when writing cybersecurity requirements.
“In software assurance or as a computer scientist you say it’s all about the code,” Kris Britton, director of NSA’s Center for Assured Software, said during a panel discussion hosted by the Consortium for IT Software Quality (CISQ) on Oct. 13. “Ultimately it is. But it all begins — at least in government — back at the acquisition process.”
As more products and services are being managed by third-parties, much of the cybersecurity responsibility is falling on the vendors, Britton said, particularly for delivering resilient code. In order for those vendors to be successful, they have to understand exactly what is expected of them, he said.
Britton also noted the difficulty in holding contractors accountable if cybersecurity duties aren’t explicitly laid out in the service level agreements (SLAs).
John Keane, software assurance lead for the Department of Defense Healthcare Management System Modernization (DHMSM) program, took it a step further, outlining in the solicitation the specific software assurance tools the agency planned to use to test potential vendors for its massive electronic health records system.
“We put in some very strong contracting language through three draft RFPs about what we expected [the contractors] to go through for software assurance,” he explained. “When the final RFP went out, the lawyers and the contracting officers said, ‘Oh, you can’t call out tools by name because that restricts full and open competition.’ Little known to them, the vendors went though and said, ‘This is such a smart idea, we don’t care if we win the procurement or not, we’re just implementing this.’”
Keane said the companies looked at it from a business perspective and made the determination that it would be cost effective to develop their solutions with these tools in mind, rather than going in blind.
“To buy a security tool or to do security scanning is an irrelevant, incremental cost to the way they’re doing business,” he said.
More than that, it gave both the vendors and the government confidence that the code being provided would be acceptable to everyone involved.
Keane suggested contracting officers be explicit about what testing software they plan to use, offering open source examples like FindBugs for testing Java applications.
“You say, ‘Here’s the tool and this is how we’re going to go through and rate you,’” he said. “No category 1 [defects] or you don’t get an ATO.”
