Star Trek always had some cool concepts. One of the things that always caught my fancy was the totally cool concept of cloaking. If you can’t see the ship or feel its presence close by, it is significantly harder to mount an attack on it. Years later, that same idea resurfaces as a strong paradigm for securing mission critical resources on the network. One of the critical things that any IT administrator worries about is how to secure servers that host confidential information, mission critical applications as well as services. In a world where domain users, along with guests, contractors, and vendors, all start accessing the corporate network via a myriad set of devices including desktops, handhelds, and mobile devices. The internal corporate network has become a free for all. As long as you can just get on to the network, you can go all kinds of places. “Where no user has gone before,” I might add in keeping with the Star Trek theme. And what that leads to is all kinds of opportunities to access information and mount attacks against the critical resources on your network. The analogy one could make is that you if can see the starship, you can mount an attack on it. Eventually with a sustained attack, the shields will go down.
So just how do we “cloak” the resource? I believe that feature can be implemented within the network fabric itself. If the role of a user prevents the user from having access to a certain server, the network should enforce that by preventing any traffic between the user and the protected resources from getting through. In effect, this “cloaks” the protected resources from the user since the user will not even know that the resource exists. Pings, traceroutes and other scanning tools will all fail to detect the resource as the network enforces the policy by dropping all such packets. This also, in effect, forms a “shield” around the protected resource since any network-based attacks mounted against the resource will get thwarted in the network itself. The key here is that this is all identity driven. If a resource is “cloaked” from one user, it can just as easily be made available to another user that should have access to it. Essentially, "identity-based cloaking" – now there’s one for the Romulans. Another key aspect of this is that the enforcement should be done close to the user itself. I.e., the threat should be thwarted close to the source. The deeper in the network that this control resides, the larger the portion of the network that gets exposed. To put it another way, why allow the thief to get to the locked bedroom door if you can lock the front door itself?
I also believe that putting this kind of control within the network requires a new breed of network switches. Ones that are stateful, fully flow-based, identity-aware, and have the capability to detect and prevent intrusion attempts. All at speeds that can scale to LAN environments and at price points that enable effective deployment of such a comprehensive solution across the network. I think it is just a matter of time before this becomes the accepted paradigm.
Shehzad Merchant
Comments