Symantec: Common Criteria is bad for you
Connecting state and local government leaders
Security vendor puts pressure on framework board to get a seat at the table.
Common Criteria is not meeting Defense Department security needs, but it could be more relevant if software vendors had input into the standard's development process, charges the Symantec executive overseeing that company's Common Criteria efforts.
'I would say our [DOD] customers are not satisfied with Common Criteria,' said Wesley Higaki, Symantec's director of product certifications, in an interview with GCN. 'People on the ground are finding that Common Criteria doesn't help them make their products more secure. It doesn't help them pass accreditation. It's just a procurement hurdle at this point.'
Common Criteria is an internationally standardized framework for matching end-user security requirements with vendor product specifications. For the U.S., the National Security Telecommunications and Information Systems Security Policy No. 11 mandates that agencies use Common Criteria-evaluated equipment and software for networks carrying sensitive information.
In recent years, critics have decried Common Criteria as being too cumbersome. Vendors have to pay hundreds of thousands of dollars to get their products evaluated, and the evaluations ' which are conducted by third-party testing firms ' can take up to a year.
As a result, agencies may have to install older, already-obsolete versions of software in order to comply with NSTISSP. With security products in particular, this is a dangerous practice, as updates are frequently added to these products in order to address recent vulnerabilities, Higaki said. He has seen cases of government customers installing a Common Criteria-approved product only to upgrade a few minutes later in order to enjoy the full benefits of the newer version.
What Symantec and other vendors want, Higaki said, is a 'seat at the table when it comes to developing Common Criteria.' Higaki said he has approached David Martin, who heads Common Criteria development, about this idea, but to no avail. 'I've made this plea a number of times and just have not gotten a response,' he said.
The current version of Common Criteria fails on a number of levels, Higaki said. His chief concern is that it does not address areas in which actual vulnerabilities could occur. The testing labs may look at factors such as what source control system the vendor used to manage the software development, and how does the CD with the software get delivered to the customer. 'What they don't ask, is in the development process, does [the vendor] comb the code for security vulnerabilities?' he said. Scans would identify spots that could be used for attacks, such as buffer overflows.
Another problem is that the Common Criteria evaluation activities must be started late in the development cycle for a new product, which, given Common Criteria's long review time, means that product may not be finished being certified until it has been on the market for a while. In the fast-moving world of commercial software, a product may have only a shelf life of a year or so, so by the time it gets Common Criteria certification, it may be retired.
As an example, Higaki pointed to one of the first Common Criteria documents the vendor must produce, the Security Target. The Security Target is a statement of claims of what the software does, including a description of how the product will work.
'There are parts of the Security Target that require us to know what the software will look like at the end,' he said. But companies rarely have this information at the beginning of the development cycle. 'The reality of commercial off-the-shelf products is that you start with a certain set of requirements, but what you end up with is not necessarily where you intended to go,' he said.
As a result, by the time most companies can assemble adequate information for a Security Target, they are already halfway through the development cycle.
Higaki suggested making the Security Target a lot more general in scope, or 'taking [it] up a level of abstraction,' he said. He admitted making this document more general would be perceived by some as degrading the quality of Common Criteria, but he said the evaluation process needs to be more of a trade-off between assurance and the realities of the software development process.
Customers may want to ask if they want a complete certificate for an outdated product, 'one that has less assurance but is for the product that they are buying,' he said.