Protecting the Crown Jewels

Why do so many organizations maintain essentially open, “flat” networks, leaving thousands of users and devices with network-layer reach to their “crown jewels”? Especially in light of what we know with data breaches, theft, and loss? One possibility may be that some organizations simply grew too quickly, and the tools in the tool chest to implement network segmentation were onerous. Other tools or point products were deployed, making it easy to say “we have Identity and Access Management Systems” for that.

But this argument falls flat in the face of a massively-increased attack surface. How did organizations become so vulnerable? Easy – the combination of enterprise mobility trends, the exponential proliferation of devices, and the dramatic increase in workloads made possible by virtualized data centers. Combine that with advanced threats – the notion that with just one social engineering attack, an adversary can quickly move across systems until he finds valuable information – and organizations quickly start to realize that network segmentation and restricting network reach are more than just “nice-to-have,” but rather, an imperative.

Limiting who and what have network-layer reach to sensitive resources to those that truly have a need to know makes a lot of sense. The trouble has been that traditional methods of implementing network segmentation and network access control are generally cumbersome and entirely dependent on how the network is architected. Need to change or maintain the policy? You may be in for major network changes and massive resource hours – whether to redesign VLANs and IP-based ACLs, or simply to rewrite thousands upon thousands of firewall rules (in many of locations). Ouch.

Fortunately, there’s a readily available technology to apply secure access policy independent of network topology. If you can (1) classify the users and devices that access resources, (2) classify the resources themselves, and (3) specify the access permissions between these classifications, then Cisco TrustSec can enforce that policy within the network – it’s that simple.

Take a look at the example above. Here, we show a simple policy that specifies how different classes of users can access various resources in the data center. Changing this policy by changing a permission or adding a new class of users or resources is really straightforward and easy-to-understand. There’s no need to redesign VLANs, carve up the IP address space and (re) subnet the network, and/or re-write IP-based ACLs or firewall rules.

To learn how TrustSec can help protect your organization’s crown jewels by limiting the reach of who and what has access to sensitive resources, check out www.cisco.com/go/trustsec.

Follow @CiscoSecurity on Twitter for more security news and announcements, and, if you’re in Milan, Italy, during the last week of January, come visit us at Cisco Live! Milan! We’d love to see you!

Share