Security and Risk Management Strategies Blog

The NAC Fog Begins to Clear

Bloggers: Phil Schacter and Dan Blum

Several years ago Cisco announced an initiative to deliver a framework for network admission control using the Cisco Trust Agent client software, 802.1x-enabled Ethernet switches and a Cisco policy server. On the surface Cisco’s NAC offered the promise of network enforcement of endpoint security policies to reduce the risk of vulnerable desktop and laptop systems introducing malware to the enterprise network.

But gradually the industry discovered Cisco’s NAC framework had too many moving parts and adoption lagged. Customers were also reluctant to replace existing routers and switches with Cisco NAC-capable ones.

At the same time as Cisco promoted its framework, Microsoft promoted its own Network Access Protection (NAP) initiative. NAP comprised APIs and endpoint functionality with Windows Vista, and various policy decision points that would run on the Longhorn server. However, the proprietary NAP protocols between the endpoint client and the policy server were firmly closed.

The problems with the Cisco and Microsoft frameworks left NAC in a fog. The Trusted Computing Group (TCG) did promote an open Trusted Network Computing (TNC) initiative, but had few takers on the market, save for Juniper. A number of other proprietary NAC products came available from vendors such as Symantec and McAfee. Hedging its bets and trying to accelerate customer investments in network security, even Cisco began selling a different NAC solution based on its Perfigo acquisition.

But the industry still lacked a standard. In late 2006, Microsoft and Cisco announced an agreement by which NAC and NAP could interoperate, but this solution would require customers to operate duplicate policy systems – Cisco’s Secure ACS and Microsoft’s Network Policy Server (NPS). Hardly an ideal interoperability scenario, and still more moving parts to maintain and operate.

Finally, this week at Interop the fog cleared. Microsoft and the Trusted Computing Group announced interoperability between NAP and Trusted Network Connect (TNC). While Microsoft, as one of the founding members of the TCG, had previously committed to “harmonize” NAP with the work on TNC, the nature of this week’s announcement went much further than anticipated. Microsoft contributed its protocol for communicating system health information to TNC, which dubbed it IF-TNCCS-SOH.

Unpronounceable or not, IF-TNCCS-SOH looks like a win for the industry. Let’s call it the Statement of Health (SOH) protocol for short. SOH makes it possible for a true plug-and-play market to develop with any agent able to communicate with any policy server. Microsoft effectively allows established vendors with NAC appliances to displace NPS as the policy server for NAP, and it is possible for protection software on Windows and non-Windows endpoints to speak SOH as well. But at the same time, the long lineup of vendors already writing to Microsoft’s APIs virtually assures the dominance of NAP as the client architecture for NAC on Windows systems. At Interop, Microsoft and Juniper will demonstrate an early implementation involving Juniper’s Unified Access Control (UAC) product, which is also a TNC server.

Microsoft’s NAP is already shipping in every copy of Windows Vista and will be included in a Service Pack for Windows XP. As soon as Juniper and other third party NAC appliance vendors are able to provide customers with upgrades to support the SOH protocol, customers can begin their NAP deployments without having to be dependent on Microsoft’s Longhorn ship timetable. There will certainly be solutions in the market before the end of 2007, with most vendors in the NAC market having products to support NAP endpoints by mid-2008.

This week’s announcements go a long way to providing a de facto standard for factoring system health information into access control decisions. Rather than every NAC vendor having to create their own agent software, it is expected that endpoint security vendors will produce the System Health Assessment (SHA) modules that NAP requires, and that these modules will work with any NAC appliance and its policy infrastructure. At some point it is likely that the TNC effort and early stage work underway by IETF’s Network Endpoint Assessment group will converge, resulting in a de jure standard. The establishment of such standards reduces customer risk in deploying products, and enables co-existence between products from established network infrastructure and security vendors, and new entrants with innovative offerings.

Cisco is not a member of TCG and has distanced itself from the work on TNC, preferring to work through the IETF while advancing its own initiatives and product offerings. However, the new TNC-Microsoft protocol provides Cisco with an opportunity to shed the residual client aspects of its largely unsuccessful framework. It is also a competitive opportunity for Cisco to succeed in providing the policy infrastructure for customer networks dominated by Windows endpoints. One fallout of the new protocol is that it largely makes the Cisco NAC interoperability solution with Microsoft NAP irrelevant. All Cisco has to do is implement support for SOH in their NAC (CleanAccess) appliance. The only problem that Cisco and other NAC vendors face in the market is what to do with their client agent software. Their choices are to re-instrument and provide a SHA to plug into NAP on Windows clients, and then accept messages generated by NAP in their backend appliances; or to withdraw from the agent market once sufficient endpoint security vendors deliver their native support for SHA and the NAP Windows architecture.

The bottom line here is that we’re closer to a true NAC standard than anytime in the past six years, and this is good news for anyone interested in investing in NAC as part of an anti-malware strategy. 

More Sex is Safer Sex…

Blogger: Pete Lindstrom

… or so says “Armchair Economist” and Economics professor Steven Landsburg in his latest book with the same title. As a security professional I can say unequivocally that I want to be as safe as possible!

In his book, Landsburg talks about the “communal stream” principle – the simple notion that everything we do affects everyone else in some way. In the sex example, the idea is to slow the spread of AIDS by increasing the incidence of sex among partners who are more likely to be uninfected. There are a number of other examples discussing leaf blowers, home security, and pollution that follow the same idea.

The communal stream principle is often expressed in another more common way: we don’t live in a vacuum. It is up to security professionals, then, to determine what the effects are of various actions within our sphere of influence and also for the Internet at large.

And that brings us to the question: Does publishing more information about vulnerabilities make us safer? The impact of vulnerability discovery and disclosure takes on a whole new light when we consider the tradeoffs. Indeed, Landsburg’s subtitle is “The Unconventional Wisdom of Economics” because the results are often surprising to folks that have only superficially considered the consequences. And the Internet’s scalability only serves to accelerate the issue. It’s like giving somebody in Melbourne, Australia strep throat from a loft in New York City.

The communal stream effects are not always apparent with vulnerability discovery and disclosure. If we keep in mind that risk is a function of threats, vulnerabilities, and consequences, then we can also see that if any of these is zero there is no risk. Let’s assume consequences are non-zero and that the vulnerabilities become greater than zero either when they are coded or when an enterprise deploys a vulnerable system. At this point, the only element keeping risk at bay would be a threat value of zero.

Thus, the initial discovery of a new vulnerability does nothing to the vulnerable state of a system. Instead, it starts the risk engine by making threat non-zero. And since we have no infallible pre-cog system of determining motives (consider the similar notion of the insider threat), every new person that learns of the vulnerability increases the threat and corresponding risk. As much as we would like to know about new vulnerabilities, there is no escaping the impact of public disclosure – it is like throwing gasoline on the fire.

Although we know that discovery and disclosure of vulnerabilities increases the (communal stream) risk in the aggregate, it also creates a specific opportunity for protection – the patch. This is where things get interesting… and difficult. For every patch applied the aggregate risk is reduced by a factor the size of the threat – in this case, the number of actors that might exploit the vulnerability.

Since the goal of discovery/disclosure is to reduce risk but the immediate result is to increase it, the real question is, can you reduce your amount of risk to a point at or below where it was before the discovery and disclosure? Some would say “no” because threat was zero by definition. However, it does seem reasonable to assign some level of threat-risk prior to public disclosure simply because one can never be certain that somebody hasn’t already discovered the vulnerability. If an enterprise can patch 100% of systems, bringing the vulnerability state to zero, then it can reduce risk from the level prior to disclosure. In cases where 100% patching (or other protection) is not possible, the product of the remaining number of systems multiplied by the number of threat actors must be less than it was prior to disclosure.

There are two other factors that should weigh in on this equation. The first is the addition of risk associated with new software. For every patch that increases the complexity of software with new lines of code, it is reasonable to expect the vulnerability number to increase as well. So the expectation must be that the decrease in risk associated with plugging the known vulnerability is greater than the amount of new risk introduced by the patch.

Perhaps the most difficult factor to address is the risk foregone due to the increased awareness of secure coding issues. Advocates of discovery and disclosure often cite this as an important point, perhaps even the most important reason for the process. But the comparison they make is always to an absolute, unchanged state, as if there were no other way for developers to learn secure coding practices. Given that the overriding assumption in this entire process is that risk is high to begin with, there would be incidents to follow that would provide the same information at a slower rate. This essentially negates the long-term effect.

The issue of discovery and disclosure is an ongoing one full of debate and rhetoric. It is only when we get to a fuller understanding of risk that we can fully assess the value proposition. In the end, discovery and disclosure is like junk food to the industry – it tastes really good and satisfies short-term desires, but it really isn’t healthy.

The Politics of Architecture

Blogger: Dan Blum

Bob Blakley and I recently sequestered ourselves for an entire day to work on revisions of two Burton Group security framework documents which had aged into the archive:

• A Systematic, Comprehensive Approach to Information Security
• Risk Management Concepts and Frameworks

The systematic, comprehensive security framework comprises business risk management, security objectives, security posture, business processes, security technology, lifecycles and contexts. We use it to remind ourselves that security projects must always be holistic endeavors; it is the framework that guides us.

Afterwards, I visited a number of large organizations and talked with them about various subjects Burton Group covers, including security programs. It struck me, as it always does, that defining security architecture or strategy is always a lot easier than actually making it happen!

One of the people we visited was a security manager at a large financial institution. He says that his CISO organization has created a new security strategy and identity management architecture to cover various business units and outsource partners throughout their global environment. “This is a new initiative for us,” he said, “The first strategy is being approved, and others will be brought in to cover additional domains.”

The security manager went on to say that the challenge was not only to create architecture but to communicate and enforce it. He calls this “the politics of architecture” and notes it is particularly difficult in a global, outsourced environment where multiple technical architectures must be received and reviewed from sub-contractors. Internally to the organization, it will be critical to manage expectations, set up success metrics, and show some real progress by the end of the year. The security manager struck me as a very intelligent, buoyant and optimistic person – someone who thrives on chaos.

Continuing to make the rounds of companies that are interested in Burton Group, I later visited the Head of Information Security at another large global organization. He radiates an air of crisp competence and organization. He is living the life of the CISO as we describe in our report Security Governance for the Enterprise. The subsidiaries and business units share a corporate culture of independence and autonomy, but they track to a baseline set of controls chosen from ISO 270001, as does the IT services organization. Reports are rolled up into a dashboard for management consumption. Clearly, the company understands about accountability and metrics, things that we’ve emphasized in other documents. One weakness, he admitted, was that the reports are self-assessments and only lightly spot checked by internal audit.

Whether we are talking about the politics of architecture on the grand scale of the information security program for a Global 2000 company or on the smaller scale of an identity management project, the challenge is clear: how to traverse from theory to practice? Burton Group has a lot of good ideas already published, but we’ll be mindful of this issue as we plan more coverage and work to prepare for our Catalyst conference Successful Security: Getting Proactive track. Hope to see you there!