Rejoignez-nous pour Zenith Live 2019 Inscription
Rejoignez-nous pour Zenith Live 2019 Inscription

Why compass-thinking bias can hinder your cloud migration

By: Manoj Apte

Why compass-thinking bias can hinder your cloud migration

(This article originally appeared last month in Forbes.)

Those of us in the IT community often have to explain complex concepts in tangible business terms. We rely heavily on simplifying metaphors: Legacy network connectivity is mapped as “hub and spoke.” Networks are secured with a “castle-and-moat” enclosure. But sometimes those metaphors can be too simple, limiting our own ability (and our CxO colleagues’ ability) to think beyond the status quo.

When we describe network interactions, we use the metaphor of compass points: Traffic on a corporate network managed via multiprotocol label-switching (MPLS) runs east/west; traffic hopping the moat (metaphor!) and going outside the corporate network castle runs north/south. It’s an old-timey way to think about network navigation: Traffic inside the company runs side to side, traffic headed outside moves up and down.

Over the years, we IT community members have invested heavily to protect both types of traffic. We built firewalls to enclose the entirety of the corporate network and isolate the east/west traffic from the north/south traffic. We stacked security hardware at the moat drawbridge to reduce the risk of compromise and ensure only good traffic moves north and south. But those approaches are intended to protect hub-and-spoke models which, let’s face it, are legacy networks designed for an outdated way of work.

Picture employees at an office using desktop machines to connect to locally managed resources — in 1987. In this old-world model, a financial analyst completes a spreadsheet and uploads it to the company FTP server, which, for security’s sake, is backed up nightly. Similarly, a software developer checks in code to the local development server repository, where her colleague can then download and review it.

Those work examples epitomize traditional east/west traffic management: secure and safe, where all movement is controlled within the firewall-protected confines of the corporate network.

But we don’t work that way anymore. The analyst uses Office 365 — at Starbucks. The software developer puts code on GitHub from an Uber. Remote data backup is on an Amazon Web Services S3 bucket. The users access corporate resources in the cloud. Is the traffic east/west? North/south?

The answer is, we need to think about this differently. Three mega-shifts — cloud, remote-access and mobile technologies — effectively explode the notion of east/west north/south traffic management.

Yet many enterprises still secure corporate networks the way they did 30 years ago, force-fitting an old idea of east/west north/south traffic management onto a new way of work. They differentiate two types of traffic, inside and outside the firewall. If someone is inside, that user must have been authenticated and so can be trusted with the east-west run of the castle. If someone is outside and seeking to enter, that user must traverse the long, linear maze of one-at-a-time security appliances at the drawbridge. New threats emerge, and IT leaders struggle to make the metaphorical moat harder to cross. And when (not if) bad actors move south over the drawbridge, they have free range to move east-west within the castle. This lateral threat has been the biggest reason for IT to resist the cloud. Leveraging cloud in this old model invariably results in a much larger attack surface.

Creating exceptions or fitting old technologies for new problems slows (and weakens) our progress. We must redefine the east/west and north/south metaphor. In a direct-connection environment, all traffic becomes north/south. Policies and tools enable users to access resources, whether those resources are internal or external, in the cloud or in the data center. Ultimately, traffic is traffic, and geographical direction matters less. What matters is control. Threat risk must be assessed continuously, and traffic must be secured as it moves inside and outside the metaphorical castle.

It’s time to reimagine network traffic and network security for access that is uniform across corporate data center and cloud. Here's how.

Instead of protecting the castle, protect the user.

Stop pretending that it’s possible to secure the entire corporate network when the bulk of traffic goes to/comes from the internet. Consider microsegmentation and software-defined perimeters to surround (isolate, really) each user’s direct connection to cloud and internet resources.

Don’t trust the network.

Treat all traffic — to/from the internet, between clients and servers — as north/south and inherently untrustworthy. Having an IP address of a certain network should not make access any more trustworthy when connecting to a server.

Instead of one-time gating and authentication, monitor dynamically.

Assess risk and gauge trustability continuously. Even after a session is established, judge its trustability continually and revoke trust if anything changes.

Don’t add a cloud to your MPLS network.

Office 365, Azure, Amazon Web Services and GCP are optimized for access from any network and any device. Forcing them into an MPLS-east/west topology breaks security models and makes for a worse user experience. Design your own data centers to look (and act) like the cloud. Let employees access those corporate resources directly with federated identity. From Starbucks. Like they're already doing with Office 365.

Rethinking the east/west north/south compass metaphor is a must for IT leaders looking to transform their enterprises into a new, cloud-enabled way of work: users connecting directly to any application on any device on any network, with no sacrifice to security, visibility or user experience. The path to working differently starts with thinking differently about those compass points.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Manoj Apte is chief strategy officer at Zscaler

 




Suggested Blogs