NIST SP 800-137

Around 2005, Cisco coined the term “self-defending networks” and used it to market products like Cisco PIX and Catalyst IDS blades. By 2007, the marketing brain trust at Cisco had moved on in another direction, adopting another grand theme for network security.

While “self-defending networks” marketing campaigns may be a thing of the past, the concept continues to be extremely intriguing. Imagine a tightly integrated network with a direct connection to the latest threat intelligence in the cloud. The network would immediately know about new types of exploits, propagation techniques, compromised IP addresses, Command & Control server locations, etc. It could then use this intelligence to detect suspicious/malicious activities or tighten controls to prevent future attacks. The network could even extend its intelligence purview to all connected nodes in order to spot vulnerabilities or rogue systems, and then automatically take remediation actions to reduce risk.

Yeah, I know we’ve all heard this shtick in one marketing presentation or another. Great theory but no one vendor is close to this vision.It may come as a surprise, but the U.S. government recognizes the potential of self-defending networks and is taking some leadership action to make this happen. This effort began in 2011 with the publication of a National Protection and Programs Directorate (NPPD) paper titled, “Enabling Distributed Security in Cyberspace.” The concepts of this paper were picked up by DHS and became part of its blueprint for a secure cyber ecosystem. Finally, DHS and NIST put out an RFI to network security vendors to gauge where this vision is today and then guide the industry on how to make progress.Despite federal leadership, self-defending networks remain theoretical, but the NDDP paper and subsequent initiatives do a good job of defining some steps needed to make this model a reality. These action items include:

* Embracing standards. The secure cyber ecosystem concept is built on top of the Secure Content Automation Protocol (SCAP) leveraging a number of standards like Common Vulnerabilities and Exposures (CVE, Common Configuration Enumeration (CCE), and Common Platform Enumeration (CPE). These provide a foundation on the vulnerability and configuration side but self-defending networks need standard data formats and transport protocols for threats like the Mitre Trusted Automated eXchange of Indicator Information (TAXII) and Structured Threat Information eXpression (STIX). It’s likely that some of the Trusted Computing Group (TCG) standards for chain-of-trust, platform authentication, and data exchange will also come into play.

* Continuous monitoring. Self-defending networks can only be effective if they understand what the network looks like in real-time. What assets are connected? What is the state of those assets? Are they doing anything suspicious? Many enterprises struggle to collect, process, and analyze this data on a sporadic basis, let alone continuously. Achieving this kind of situational awareness will require data standards, security technology integration, and improved analytics.

* Acceptance of security automation. Security professionals are always reluctant to deploy filtering products like IPS “in-line,” opting for passive monitoring instead. Sure, no one wants to disrupt business applications with false-positive policy enforcement but humans simply can’t be expected to analyze billions of IP packets and take remediation actions in an acceptable timeframe. Self-defending networks need to be “expert systems” that make the right decisions far faster than even the most experienced security professional can.

I’m pleased that the Feds are taking this on for a few reasons:

1. This is exactly what the Federal government should be doing – using its budgets, brains, and collective power for research and development.

2. The Feds can use budget dollars as a potential carrot for vendors. Cisco, Check Point, Dell, HP, IBM, Juniper, McAfee, Palo Alto Networks, and Sourcefire are far more likely to participate if they foresee ROI in terms of hefty Federal contracts.DHS and other agencies can help push these initiatives to the commercial market.

3. I don’t know why enterprise organizations in financial services, health care, and manufacturing maintain a Laissez Faire attitude toward security technology standards but alas, that’s what’s happening today. Perhaps the Feds can spread the word, provide tax breaks, or something.

Cloud computing, global IP networks, virtualization, SOA, and mobile devices are complex systems that are too big, fast, and complex for today’s security technologies. It’s nice to see that the Federal government recognizes this and is willing to push for technology innovation and change. This effort has the potential to bear fruit if the Feds can build security community awareness and push vendors and the commercial market to join the effort.