Cisco’s TrustSec architecture significantly advances the state-of-the-art in network-provided security. Security was much easier when the action was primarily at the enterprise headquarters. We had a “perimeter” model of security. If a user was inside the perimeter (local) then they were trusted. Access from outside the perimeter was not trusted. Life was very simple.
But over the last five years the perimeter has pretty much become useless as a means of judging or enforcing security. Most enterprise users are no longer within the headquarters network. Compliance, security and privacy issues require that we “distrust” internal users. Where the user is doesn’t particularly help, while at the same time securing applications and data is increasingly important. What should we do?
IRG has long believed that the right answer categorically is an evolution to “identity-based” networking where the identity of the user is the prime determinant, not just their network location, but how should this be implemented? Historically the prime means of defense were various forms of firewall rules typically keyed off of source and destination IP number (network location again) augmented by some understanding about the specific flow (the application related to the traffic). Firewall rules were at best complicated (at worst incomprehensible) especially considering that firewalls were typically located in the “middle” of the network where there was a lot work to be done because of the diversity of flows that transited the network at that part -- sorting out what all the traffic was and then looking for the rules that were specific to that traffic. The difficulty of the approach was compounded by the challenge of fully understanding how traffic flows in a network and assuring that there aren’t any unanticipated network sneak paths that bypass the security devices.
A set of vendors including Nevis, Consentry and Vernier attacked this problem by putting much more intelligence at the network ingress points (e.g., where users connected to the network), and then using the user’s identity to determine the specific rules governing what they could do on the network. The difficulty in this approach is that it requires use of a new class of access switches with a great deal of security functionality on each port.
Cisco TrustSec re-factors the problem very creatively. The architecture encompasses these ideas:
1. Make the enterprise network more trustable (increase the confidence about the data that has transited the network);
2. When traffic enters the network tag each packet with an identifier that signifies what is known about it and do so in a way that most directly reflects how that data can be trusted.
3. Filter the data on exit from the network (e.g., at the point the network connects to a server) by acting on the tags.
TrustSec represents a long and large investment for Cisco; we can’t describe the details adequately here and won’t try. But the 50,000 foot view is relatively simple. We make the network trustable by (a) authenticating network devices before we let them join the network -- the device equivalent of NAC for people. For example, we can check the device serial number, the revision level of the firmware, and assure that the signature of the firmware is authentic, and only authenticate the device if all those tests pass. Then (b) we encrypt the links between authenticated devices so that the data cannot be snooped and more importantly can’t be modified by some “man in the middle” attack. This encryption is done link-by-link using certificates receives as part of the authentication process.
With a trustable network in place we next annotate traffic as it enters the network with what we know about it from a security perspective. Because the network is trustable we can confidently act on that tagging when the data exits the network because we know it hasn’t been modified. To simplify the filtering at the egress point, TrustSec is designed so that the tags used for the data identify the trust category (Cisco uses the term role) so the filtering task is as simple as possible since there aren’t complex IP-number-based rules to evaluate later on. A server only has to understand what level of trusted data to pass.
Finally, in a TrustSec based implementation, we need a way of tagging the data on entry. Cisco has announced a new family of edge switches capable of doing this tagging at line rates (a much simpler task than the challenge Nevis and Consentry had of doing full traffic identification and firewalling at line rate). An evolved version of NAC is used to authenticate the user and identify the suitable trust class (role) to assign to that user’s traffic. Anticipating the fact that Cisco customers aren’t going to do a wholesale refresh of their edge switches to implement TrustSec, there is a form of implementation in which the tagging is done by a switch inward from the edge coordinated with edge implemented NAC via out-of-band control plane communication.
The net result of this is to greatly diminish the role of traditional firewalls for this kind of security while emphasizing NAC and data center switching all of which makes sense given Cisco’s market strength. So we give Cisco two thumbs up for TrustSec for significantly advancing the state of network-enforced security!
We usually don't pay a lot of attention to Cisco organization changes as long as John Chambers is still in place at the top, but the recent engineering changes caught our eye. It starts with the Chief Development Officer -- Charlie Giancarlo -- leaving to join a Private Equity firm. The plot gets somewhat more interesting if you add in the fact that Chambers just hired Padmasree Warrior as CTO (she had been Motorola's quite visible CTO prior). Cisco's CTO role had been open since last held by Charlie, and not very visible since Judy Estrin left in 2000. Warrior will report directly to Chambers as will the engineering functions. The other interesting change is that Chambers has built a software group led by Don Proctor and including the other major software development organizations. From our perspective software is at the core of Cisco's future given the system nature of most of Cisco's strategic initiatives. We look forward to seeing what Proctor decides to do.
