A blizzard froze the network

A blizzard helped a fellow CISO understand a better way to do IT security. 

I was talking recently with one of my CISO peers about adapting to crises, and he relayed this story to me. Early in his CISO career, he deployed company-wide security for his entire enterprise. The plan was straightforward, or so he thought: Build a single, centralized security control architecture. All traffic—local, branch office, remote user—would get routed through the “castle-and-moat” design, examined and inspected, then sent where it needed to go. 

Centralized security control promised a unified way for his security teams to keep threats at bay. It made sense strategically, and financially: Replicating security at different locations would have multiplied the effort, the equipment, and the cost. 

Early success was a ray of sunshine 

His plan met with early success: his team’s security blocked a virulent malware attack and they all patted themselves on the back for a job well done. They had made the right decision! But his sunny, centralization journey was experiencing a calm before the storm.  

Their castle-and-moat security architecture routed all traffic from everywhere—including traffic bound for the internet—through their security stack. Security became a huge bottleneck. Users couldn’t access simple things like social media. Media applications like YouTube slowed to a crawl. Important productivity applications became unusable.

The user experience degraded below an acceptable threshold, and people found new ways to use apps and services—ways that bypassed their centralized security. The more protection they put in place, the more latency they introduced, and the more people started using other channels to get online: home networks, mobile connections, or public Wi-Fi. Employees avoided their security using unsecured links and unapproved proxies. Now their network was less secure, and their highly-prized (and highly-expensive) security system was failing under the weight of the side effects caused by its intended use.

As a response, he was forced to do what he had tried to avoid: His security teams created three new data centers and cloned “centralized” security in each. In theory, this allowed people to get better performance by providing localized access, splitting one big bottlenecked traffic load into three smaller distributed loads. It also tripled the cost, management, and complexity of their security footprint, but they could justify it with the hope of improved user experience. 

Even with these new breakouts, the users still avoided their security stacks. Employees were used to accessing applications and services however they liked and were understandably reluctant to go back to indirect security routing.

Locked in at home, locked out of the network

That point got hammered home during a real-world blizzard. During and after the blizzard, nobody could come into the office. Everybody was out of the “castle” and outside the perimeter protection of our security “moat.” They had VPN access available, but as people jumped on VPNs, traffic competed for limited bandwidth, and app performance slowed to a crawl. Everybody stuck working from home defaulted to the path of least resistance to get things done: home broadband, Wi-Fi, and mobile connections. 

His security teams lost all control of any corporate devices not using their network. They couldn’t see anything their employees were doing, or the status of device health until users reconnected to the corporate network. 

Once those devices rejoined the network, the security teams could see and stop malicious traffic. But the damage was already done: There was a huge increase in malicious traffic once devices reconnected. The blizzard buried my friend’s security teams in threats. 

There are several morals to this story:

• Users have a low tolerance for delay. Any security that is difficult, inconvenient, or prevents access WILL be ignored or bypassed.
• Centralized security is difficult (and expensive) to scale, and can be inflexible to accommodate new circumstances. This is especially true now that enterprises are consuming more and more space in clouds and using “X”-as-a-Service (XaaS) to bolster infrastructure and increase productivity.
• Security must be inline between the user and the application. Users default to whatever gets them access to what they need, immediately. Enterprise security must support this behavior.

A secure access service edge (SASE) solution is a better alternative to a centralized security model. Cloud-based SASE positions security inline, securing the connection between users and applications, no matter where they (the users or the applications) sit. SASE security services are distributed across the cloud, near to each user: Users can go directly to the internet to access applications, infrastructure, or data. This negates the need for backhauling all network traffic through a central security stack and removes bottlenecks to SaaS applications like Salesforce.com and Office 365.

With a SASE model, the blizzard would have been just a blip for my friend rather than a major disaster.

SASE keeps security skies blue

A SASE cloud security platform built to accommodate digital transformation and the modern enterprise is an excellent way to ensure application and network performance and scalability. It allows users to directly access applications and services in the cloud without routing traffic through centralized security stacks that become bottlenecks for user experience. With a globally-distributed platform, users are always only a short hop to their applications. Even during unexpected crises, businesses like my friend’s can keep moving forward with minimal disruption.