Search:  

 Blog     e-Newsletter       Resource Library      Directories      Webinars     Apps     EBooks
   AFCEA logo
 

Security Comes Standard

August 2010
By Maryann Lawlor, SIGNAL Magazine
E-mail About the Author

 

In 2008, according to its own records, the National Institute of Standards and Technology published 17 new information systems security vulnerabilities per day in the National Vulnerability Database.

Identifying vulnerabilities may be as simple as agreeing to speak the same language.

Instead of a NASCAR winner-take-all competition, the race to secure information systems is more of a traffic jam where getting ahead depends on the lane you’re in. Operators consistently crawl along by putting patches in place and upgrading antivirus software, yet that annoying lane-changing system attacker keeps bobbing and weaving its way to the front of the gridlock daring you to catch up. But information superhighway menaces are being quashed by a collaborative effort among government organizations to ensure that the United States is in the correct lane when it comes to staying ahead of information security troublemakers.

One solution is to automate some of the tasks that information security entails. The Security Content Automation Protocol (SCAP) and the SCAP-validated tools automate security, assets and configuration management functions, as well as revamp how government agencies manage and defend their critical information technology infrastructure and data. The tool suite comprises open, interoperable standards that support automated vulnerability management, measurement and policy compliance evaluation.

The U.S. Defense Department, National Security Agency (NSA) and the National Institute of Standards and Technology (NIST) were the primary drivers behind creating SCAP. Brought down to their bare bones, the standards establish common enumerations for software flaws, security-related configuration issues and product names. This seemingly simple piece of common sense helps agencies that are working together to understand each other’s languages when describing details of the same information security problems.

These standards also determine which software flaws, configuration issues, patches or products reside on a system, resulting in a vulnerability score. Because of automation, they can reliably communicate the impact of security issues accurately and consistently, while providing transparency regarding how the vulnerability score was derived. This is particularly helpful to information security specialists as they attempt to determine the best ways to reduce the number of innate vulnerabilities and boost the potency of security solutions. Finally, SCAP enables integration and management of critical computer network defense and information technology configuration information.

According to Anthony Sager, SCAP’s roots took hold more than a decade ago at MITRE. At the time, one particular software flaw could have as many as a dozen different names, depending on where the information systems analyst looked and how each organization tagged it, explains Sager, chief of the vulnerability analysis and operations group, Information Assurance Directorate, NSA. Headquartered both in Bedford, Massachusetts, and McLean, Virginia, MITRE began developing the common vulnerabilities and exposures (CVEs) list because the organization believed that no matter what tool an analyst used to assess systems’ vulnerabilities, these flaws should have a publicly standard name.

Concurrently, the U.S. government was attempting to solve a similar problem, Sager relates. For example, blue teams using three different commercial scanners would find three different names for the same vulnerability. Sager explains that it was at this point that the government began working with MITRE to determine how to know which of the results was correct. The effort became a community activity, Sager says, with collaboration and consensus overseen by a government advisory board; eventually, the government began funding MITRE’s work.

“There was no magical moment when the SCAP began. Around 2005, the NSA produced a security guide to help people configure their systems to best protect them. But the agency was trying to move away from producing textbooks for system managers to read and toward finding a way that machines could talk to machines in a common, readable form. In parallel, NIST was working on solving the same problem, so the two organizations combined into essentially one governmentwide program,” Sager relates. While NIST was busy building the program, the NSA was determining how to provide solid security guidance and get this information out to government agencies as well as to businesses.

Obtaining information management tools that naturally interacted was a massive challenge for both government agencies and the commercial sector, he adds. Either buyers had to purchase one expensive product line, which locked them into using one vendor, or buy products from different companies and pay an integrator to ensure that the solutions could work together.

Once aware of the availability of these security standards and the potential to grow profits, industry’s interests grew. When solutions were built to SCAP specifications, customers could be assured that the individual products they purchased would be able to talk to each other on a data level. The idea that manufacturers could build a product to certain standards and then have a NIST-approved laboratory validate it made good business sense because it made the product more valuable to the customer.

“SCAP removes the question of how tools talk to each other and how people talk to tools and raises the bar to having the ability to mix tools for information management at the standards level. The focus is on information management instead of tool management.

“I used to be in charge of a program that would take a bunch of different sources and integrate the information into one big database. We ended up spending an astronomical amount of money to convert data and move it from one place to another place, from this database structure to that database structure. And even when you’d get everyone in the business to agree on what the database structure should be—which was almost impossible—we still had the big problems. So we had the first order of integration, which would involve either people integrating information or writing expensive software to move it around. SCAP extracts that process, because whenever a tool goes into my environment, it follows certain standards,” Sager explains.

Although industry was interested in a way that would entice government agencies to purchase their products, the NSA and NIST still had to find a way to convince large companies that did not want to change because they had cornered the market. They were not enthusiastic about designing to standards that would allow other companies to interact with their products, he allows.

But Sager credits John Gilligan, then chief information officer for the U.S. Air Force, with breaking the logjam in regard to industry. Gilligan’s philosophy was that agencies can buy inexpensive solutions on the front end, but they would have to pay more to fix the problems later. He believed in streamlining the process and worked with Microsoft Corporation, then cooperated with the NSA baseline. Although there were some holdouts, the goal was to have software ready in terms of security and configured to the way the user needed it when it came out the of box, Sager explains. This work eventually led to the Federal Desktop Core Configuration, and it aligns with the purpose of SCAP, he relates.

Whether industry was on board or not, it now is apparent that SCAP is making its way into the mainstream. Sager relates that SCAP requirements now are part of many requests for proposals (RFPs), and the NSA has been working with other vendors to promote SCAP use to their customers. It is important to understand, he adds, that the NSA provides the content, but NIST creates the standards. In terms of the military, the Defense Information Systems Agency has the authority to put the SCAP requirement into military RFPs, and the NSA is tied closely to how the Defense Department sets its requirements, he notes.

Although the government initially had received some pushback from industry, many companies now understand that if they are going to be part of the cyber ecological system, products and tools need to be able to speak to each other using a common language. “Although it is not a delineated requirement, it has become apparent that if you want to sell products in the DOD environment, then your product has to speak this language, or I can’t afford to have you in our group,” Sager explains.

Stephen Quinn, senior computer scientist, Information Technology Laboratory, Computer Security Division, NIST, explains that SCAP supports security by automating many of the necessary actions that otherwise are conducted by humans. He uses an analogy to describe what the automation protocols do: SCAP is the table around which a number of chairs from different rooms are placed. Certain rules must be followed to make the chairs function properly. Through using a common language, SCAP ensures that the people sitting at the chairs can talk to each other because they speak the same language and use the same enumerations, Quinn relates.

The second hurdle that must be overcome if SCAP is to be widely used is to explain how following these protocols benefits the company pitching specific products or the agencies purchasing them. Once again Quinn uses an analogy. In this case, he likens it to buying a Ford vehicle that can be refueled only at Ford gas stations. Instead, buyers are more likely to purchase a car that can be refueled at any gas station. In terms of security,  SCAP means freedom of product choice and freedom of data sharing among the products, he notes.

In the past, government agencies had to macromanage problem vulnerabilities by determining which operating systems could be affected and then establishing a patch for each one. “In the government, we only want the interface to have one way to address patching for security. On the micro and macro levels, we [government agencies] also had the problem of how to look at software maintenance. After a company sells software to any government agency, it is the government that needs to be able to keep it patched and configured securely,” Quinn explains.

The first SCAP specification was established 10 years ago; the seventh specification is only four years old, he relates. Like the invention of the Small Computer System Interface, or SCSI, which became the standard to connect and transfer data between computers and peripheral devices in the 1980s, SCAP is a platform for innovation, Quinn proposes. The protocols provide innovators with specifications to follow that ensure that their products will benefit the larger marketplace.

SCAP not only involves the CVEs but also the common configuration enumerations (CCEs). Products can be tested against standards to ensure that they have the same configuration language. The goal is to automate the work on compliance frameworks and map the area between the lower- and higher-level settings.

To ensure that products meet SCAP specifications, inventors can visit the NIST website and download the guidelines, which include the technical information on requirements and specifications. NIST accredits specific laboratories that are part of the National Voluntary Laboratory Accreditation Program to test companies’ products to determine if they meet SCAP specifications. Downloading the technical guidelines is free; companies and the specific laboratories determine the price of accreditation for specific products. In the long run, it is likely that this increased level of automation will save both industry and the government dollars, and it makes security sense, he adds.

In addition to ensuring that a device can share and compare information using the same language, Quinn points out that SCAP provides a side benefit, one that he believes is very important. “If all are following the same rules and all are certified, it helps with compliance to security requirements. My view is, ‘How do we improve security, whether people like it or not?’” he says. By buying products that comply with the automation protocols, government agencies are improving security, whether they know it or not, he notes.

Quinn admits that SCAP is only 20 percent of the story because it does not deal with network, human or geographical events. However, other protocols are being developed to address these items, including the Event Management Automation Protocol, or EMAP, and the Event Remediation Automation Protocol, or ERAP. NIST is working with companies as it develops these protocols with the goal of acquiring protocol compliance buy-in upfront, he explains.

Today, approximately 30 companies are following the SCAP standards, which allow their users a common way to scan for vulnerabilities. A list of vendors that offer SCAP-validated products is available on the SCAP website.

WEB RESOURCES
Security Content Automation Protocol: http://scap.nist.gov
MITRE: www.mitre.org
Federal Desktop Core Configuration: http://nvd.nist.gov/fdcc/index.cfm