Perimeter-less Security and Clouds on the Horizon

Archive for the ‘Architecture’ Category

Perimeter-less Security and Clouds on the Horizon

Posted by

Cloud computing is similar to what the tech industry has been calling “on-demand” or “utility” computing, terms used to describe the ability to tap into computing power on the Web with the same ease as plugging into an electric outlet in your home. But cloud computing is also different from the older concepts in a number of ways. One is scale. Google, Yahoo!, Microsoft, and have vast data centers full of tens of thousands of server computers, offering computing power of a magnitude never before available. Cloud computing is also more flexible. Clouds can be used not only to perform specific computing tasks, but also to handle wide swaths of the technologies companies need to run their operations. Then there’s efficiency: The servers are hooked to each other so they operate like a single large machine, so computing tasks large and small can be performed more quickly and cheaply than ever before. A key aspect of the new cloud data centers is the concept of “multitenancy.” Computing tasks being done for different individuals or companies are all handled on the same set of computers. As a result, more of the available computing power is being used at any given time.”

Clouds are on the horizon. I know very few data centers that host everything internally. Most, including my own, deliver a mixture of desktop applications, client-server applications, and hosted (e.g., cloud) web apps. The shift has an immediate impact on security planning. Information security architectures began with terminal-server applications and focused on strong perimeters. With apps moving to the desktops, the perimeter became a little wider and a little more porous. But we could still control the information, by restricting what data was on the desktops and using technologies like end-point security. In fact, one might argue that many of our controls today are based around restricting information to the data center and keeping it off the desktops. The next major shift, which we are already starting to see, is moving the information from data centers to third-party hosting providers. This is only going to accelerate as young people, weaned on MySpace and Gmail,  join the workforce. Another accelerant which we may see in the next few years is another economic downturn. Both sociological and economical changes are moving the data from controlled perimeters to uncontrolled open spaces. The clouds on the horizon are coming nearer.

The open question is this: how do we build controls in an age of perimeter-less security?

Encrypting private circuits (VPN over Frame Relay and MPLS)

Posted by

This is a summary of a debate I recently had with a network engineer. The question is whether or not to run a VPN over a private circuit.

Let’s start with a quick definition of terms.

Private circuits are provided by the telcos to sites that companies own. So say you have a site in Detroit and Chicago. Way back when, the way to connect the two was to run a dedicated line. A dedicated line provides dedicated bandwidth and constant latency at a price. This was rather expensive. For redundancy, you purchased separate lines.

Frame Relay was the telcos solution. You can think of Frame Relay as a virtual dedicated line. The connection relays network frames (layer 2 or data link) over several physical networks to create a logical end-to-end line. The Detroit-Chicago traffic crosses any number of devices and circuits, but the link is presented to your layer 2 switches like a dedicated line. This cuts down the cost. The trade-off is varying bandwidth and latency because Frame Relay is a shared resource. Like dedicated lines, you needed to purchase separate circuits for redundancy.

MPLS (Multi-Protocol Label Switching) aims to provide performance of dedicated circuits at the cost of frame relay. MPLS adds traffic management and in-network redundancy. Detroit-Chicago over MPLS is still a shared resource, but now the link can more effectively shape the traffic and utilize the networks of circuits. Redundancy is baked into the circuit.

In terms of cost, it goes redundant dedicated lines, redundant Frame Relay, and MPLS. All three are rather expensive. Meantime, the Internet reliability has increased and cost has decreased. Strictly from a costing perspective, you might build the Detroit-Chicago link with a VPN (Virtual Private Network) over the Internet. Like MPLS and Frame Relay, VPN is a logical end-to-end line that builds on top of a physical network.

Now to dive into the confusion.

Telcos sell dedicated lines as private circuits. Telcos sell Frame Relay and MPLS as virtual private circuits. The argument you will hear is that security is built-in because these are private circuits. There is also the operations efficiency of not having to deal with routing infrastructure and possibly even IP infrastructure. (Novell administrators love Frame Relay as they can run IPX/SPX over it.) A private circuit is private, right? Not exactly.

First, all the telco equipment between Detroit and Chicago have visibility into the IP traffic. A truism of network security is that a network is only as secure as the people who have access to the equipment. In this case, that could be any number of telco support technicians. They can read your packets.

Second, the privacy of the private circuit depends upon the correct configuration of the equipment. Your packets and some other organization’s packets are streaming down over the same routers. The only difference is the tags in the packets and the how the routers treat those tagged packets. When improperly configured, the circuit fails open. I have seen situations where new IP subnets suddenly appear on the LAN switch, and are traced back to a misconfigured frame relay. Whose packets were they? Did the owner of those packets know he was broadcasting onto our network? Probably not.

My recommendation.

Treat dedicated lines, Frame Relay, and MPLS circuits the same as you would untrusted Internet circuits. Encrypt all internal traffic that travels over these circuits.

Virtual private circuits are not the same as Virtual Private Networks. One is clear text and the other is encrypted. The first ensures availability and integrity. The second ensures confidentiality. For best results, run a VPN over a virtual private circuit.

What about bandwidth and latency? With decent gear, the bump in thru put should be no more than 10%. Look for routers or firewalls that advertise encryption and line speed.

What about packet shaping? Use the QoS preclassify features of your gear. This reads the DSCP/TOS from the unencrypted packets, and writes it to the encrypted packets. The MPLS gear can then handle the encrypted packets properly.

What about complexity and cost? The trade-off is security for operational complexity. You may need to purchase more gear. You will need to implement IP routing. These add to the overall cost of the solution. Given the increases in security of encryption over clear text, the trade-off is worth it.