NIST, DHS push security automation to the next stage

The future of network security is automation, using various tools to monitor systems and network traffic for signs of trouble, alert administrators and even respond to attacks on their own. Automation can handle jobs that otherwise would have to be done by IT staff members, who are then freed up for other tasks.

Agencies face challenges in getting to an automated environment, however, whether because of tight budgets, complex systems or automated tools that don’t necessarily work together. The federal government is supporting the effort by developing the standards that are necessary for interoperable tools and offering intrusion detection and prevention as a service to agencies.

SCAP

The government is working to create a standards-based security environment through the Security Content Automation Protocol (SCAP), a suite of interoperable specifications developed at the National Institute of Standards and Technology in collaboration with the public- and private-sector security community.

Although NIST’s agenda for security automation goes beyond vulnerability management, SCAP in its present form, Version 1.2, deals primarily with endpoint compliance for configuration requirements. The specifications, contained in Special Publication 800-126,  support automated configuration, vulnerability and patch checking, technical control compliance and security measurement.

“In the U.S. government it has been a challenge to implement configuration management,” said NIST’s Dave Waltermire, SCAP architect. “There is often a tension between allocating resources to manage systems and developing configuration management policies, procedures and baselines.”

The SCAP specifications provide the building blocks for vendors to create standards-based tools that can work and communicate with each other in automating these processes. They create a common format for developing and enforcing baselines and producing standardized results. This requires common methods of expressing information about hardware, software and vulnerabilities.

SCAP Version 1.2 includes 11 component specifications in five categories:

• Languages for expressing security policy, technical check mechanisms and assessment results, including Extensible Configuration Checklist Description Format, Open Vulnerability and Assessment Language and Open Checklist Interactive Language.
• Reporting formats to express collected information, including Asset Reporting Format and Asset Identification. Although Asset Identification is not explicitly a reporting format, SCAP uses it in identifying the assets.
• Enumerations, standard nomenclatures and an official dictionary of items expressed using that nomenclature, including Common Platform Enumeration, Common Configuration Enumeration and Common Vulnerabilities and Exposures.
• Measurement and scoring systems for evaluating severity of a security weakness, including Common Vulnerability Scoring System and Common Configuration Scoring System.
• Integrity of SCAP content and results, Trust Model for Security Automation Data.

Independent laboratories are accredited by NIST to validate security products that conform to SCAP requirements for government use. There currently are 43 products from 32 vendors validated under the program.

Einstein

While NIST is building a framework for interoperable vendor products that agencies can implement within their systems, the Homeland Security Department is developing an intrusion detection and prevention system to be offered as a managed service through agencies’ Internet service providers.

Einstein was initially deployed in 2004 to detect and block malicious activity across the .gov domain. The first version analyzed network flow information from participating agencies to provide a high-level view for observing potential malicious activity. Its second iteration, Einstein 2, launched in 2008, is a passive, automated system that incorporates intrusion detection based on custom signatures of known or suspected threats, and is able to alert US-CERT of malicious activity. It relies primarily on commercial tools for detection.

Einstein 2 now is deployed at 17 of 18 agencies that are using a Trusted Internet Connection provider, and at 52 other agencies using Managed Trusted IP Services (MTIPS) under the Networx contract. DHS officials say the department is on track to meet its milestone of providing Einstein 2 service to 70 percent of executive branch agencies by the end of fiscal 2013 as legacy networking contracts expire and agencies that are not yet served move to MTIPS. That 70 percent figure for agencies could include as much as 90 percent of .gov network traffic, officials said.

Einstein 2 already has shown its value for detecting and alerting, department officials said. As analytical capabilities grow its value is expected to increase, and alerting will be expanded from US-CERT to agency security operations centers as well. This is expected to happen in 2014.

In its next iteration, Einstein 3 will be a managed service through service providers to not only detect but also automatically block malicious traffic before it enters government networks. Under the direction of DHS, service providers will administer threat-based decisions on traffic entering and leaving participating agency networks. Agencies will enter into agreements with DHS to authorize use of intrusion prevention capabilities through service providers.

Einstein 3 includes three major activities. The first, operational today, is the ability to connect analysts with the data that will be used to block malicious traffic. The second activity is the segregation and aggregation of .gov traffic by ISPs for analysis. Four contracts for this function have been awarded; one is fully operational and two more are expected to become operational this summer. The fourth contract is being finalized and should be operational by the end of September.

The final activity is the trickiest one: automated blocking of malicious traffic. One contract for this was awarded to an ISP in March, but it is not yet operational. Other contracts with ISPs are in the works, and service delivery plans are being developed.

Initially there will be two countermeasures used by service providers against malicious traffic.

• Domain Name Server sinkholing will block malware in .gov networks from communicating with known or suspected malicious domains, redirecting the traffic to safe sinkhole servers. ISPs will have access only to information about the DNS request for this traffic and not to the contents.
• E-mail filtering will scan incoming mail addressed to .gov networks for malicious attachments, URLs and other malicious content. Infected e-mails could be quarantined or redirected for further inspection and analysis by DHS.

Even without enterprisewide systems such as Einstein and large-scale frameworks such as SCAP, individual tools have demonstrated the power of automation to improve both network security and management.

Nevada’s Department of Transportation for example, was able to spot misconfigured devices almost immediately when it began using Splunk Enterprise to gather and correlate log data and has been able to troubleshoot problems more efficiently. The DOT was able to reduce errors on its networks and is aiming to put Splunk to other uses.