The Gap Between Policy and Implementation
Mark Twain once wrote, “Everybody complains about the weather, but nobody ever does anything about it.” Security policy is a lot like that. Creating a security policy is at the top of the list for anyone looking to really secure their network. But the devil is in the details.
Among the things a security policy needs to cover are:
- All users
- All physical and virtual devices
- All access methods
- All resource classifications and locations
- All compliance requirements
- All of the OSI layers, from the physical layer up the stack to the application layer
- AND the policy needs to be applied uniformly across the entire distributed enterprise
That last one is where most of this begins to really break down. Failure to apply security policies uniformly across the entire infrastructure imposes the “weakest link” risk on an organization. Traditionally, the weak link was likely a branch office or someone in IT who created a back door to simplify access while off-site. But with the advent of borderless networks, including a highly mobile workforce, cloud and web-based resources, and increased virtualization, that weak link in security enforcement could exist almost anywhere.
Adding to the problem is that ownership of implementation has been fragmented across the organization. Different teams are required to interpret policy and then figure out how to implement it. The team responsible for the network operations applies rules at layers 2 and 3 across a variety of devices. This may often include writing ACLs by hand on switches, or trying to ensure that network rules remain consistent at remote locations where IT staff may be limited. This gets really ugly during things like add/move/change events.
The challenge for the security operations team can often be even far more daunting. They are often dealing with a heterogeneous mix of purpose-built security devices that do not talk to each other or the network. Policy must be implemented on a per-device basis using different interfaces. And applications operations teams have to apply these rules using a completely different set of tools in order to secure internal purpose-built applications, web sites, and web-based applications.
The list goes on and on. And at every step of the process there are significant opportunities for policies to be misapplied, for errors to be introduced, and for serious gaps to develop between these various policy iterations. And it is those gaps that represent a very real danger to the security of organizations. Interestingly, of all of the security solutions available on the market, no one has thought to address, in a comprehensive manner, the issue around security policy.
Sure, there is the odd AAA server vendor, and a few one-off policy solutions, but nothing that really unifies and simplifies the larger security policy problem, which seems strange given that the security community all agrees that security policy is fundamental. But the gap between policies and the implementation and enforcement of those policies is like a herd of angry elephants in the room that no one wants to talk about, probably because no one can do anything about it, short of shutting everything down. So instead, we tend to focus on how some security device or other solves a specific problem at a discrete point in the network and pretend that this will make the policy problem go away. It won’t. Here’s a question: If you have a boat with seven holes in the bottom, and you manage to plug five of them, what happens to the boat?
The reason that no one has addressed this problem is that no security vendor in the market is able to see across the entire distributed network, or up and down the stack, to identify inconsistencies in policy enforcement. And even if they could find the big picture, they don’t have the ability to address any of the problems they might find.
That’s where Cisco comes in.
Because Cisco has such a large network footprint, we are uniquely positioned to address this problem. Think about it for a second. Any device you are concerned about, any user you lie in bed worrying about, and any piece of data you need to control or protect, crosses the network at some point. Why not use the network to see what happens and coordinate policy implementation?
Cisco’s new Identity Services Engine (ISE), part of Cisco TrustSec, is a powerful appliance that for the first time actually leverages the power and intelligence of the network to address the issue of policy. ISE allows organizations to create centralized policies for any user or device through a single, unified interface using a set of highly customizable business objects. It can then push those policies out to the furthest reaches of your distributed network, where they can be enforced by the network itself, at the point in the network closest to the user or device.
The range of tools that ISE provides is wildly impressive. It includes:
- Centralized Policy Creation
- Distributed Enforcement
- AAA Services
- Links to Active Directory services
- Endpoint Posture Assessments
- Guest Access Services
- Device Profiling
So, for example, if someone from engineering (let’s call her Pam) brings her iPad to work, the network (an 802.1X-enabled switch) recognizes a new user and device and queries ISE as to what it should do. ISE identifies the device and the user, grabs a bunch of other contextual information (Is the device healthy? Is this a wired, wireless, or VPN access? Is the user inside or outside the network? Is she currently logged in somewhere else?), and then links Pam and her iPad to an access policy. (ISE comes pre-loaded with hundreds of customizable policies, including some for iPads.)
That access policy is pushed back to the switch where Pam is trying to log in. Pam is granted policy-based access, and a tiny metafile, called a security tag, is attached to the individual data packets coming from Pam’s iPad. These tags identify Pam’s (and her iPad’s) access policy, and are read by other switches on the network to enforce that policy, regardless of what Pam tries to do.
So when Pam decides that she wants to access files from the engineering server, her security tag is read and that is permitted. She checks her email. OK. She then decides to see what’s happening over on the payroll server. Whoops. Pam’s security policy specifically disallows anyone from engineering from accessing payroll. The switch infrastructure reads Pam’s security tag and blocks her. Pam’s improper behavior is logged and an alert is sent to the IT administrator.
The options are staggering, because not only does ISE provide access policy for Cisco TrustSec, but in future releases it will provide a wide range of other policy services as well, including working with MediaNet to manage video traffic, or managing Cisco’s SmartGrid services. In fact, anything that can have a policy attached to it can be managed from ISE, from the transport layer to the application layer.
This is breakthrough, sea-changing technology. It may take a bit for security folks to wrap their heads around it, but this ability to create, provision, and enforce policy, and then see and respond to policy-based events, across the entire distributed, borderless network, could change everything. It’s the last major milestone towards a comprehensive security strategy. And as networks are in the process of being utterly transformed by mobile workers, clouds, social networks, and virtualized devices, it has come just in the nick of time.