2020 Microsoft Hong Kong Top MSP Partner
8 April 2020SCCM Deployment And Optimization
8 April 2024Zero Trust Networking & Arguing With Physics
Original article: https://www.enowsoftware.com/solutions-engine/zero-trust-networking-arguing-with-physics
When you’re in your own data center and your security model is based on perimeter security and passwords, you’re not cloud-ready. Security models that only leverage firewalls and passwords, leave organizations exposed as soon as cloud services start to be consumed. However, many organizations don’t realize just how exposed they are…
A perimeter-based model assumes that the inside is safe and the outside is not, which is fair enough, however, it breaks down rapidly once you start consuming any kind of cloud service. Identity may include another factor of authentication, which means if you try to access services inside your network, you’ll build a trusted tunnel (VPN) and use another factor of authentication to prove that you are really who you say you are. This could be betokening, SMS, biometrics, etc.
You may argue that you break and inspect all internet SSL traffic, which means you know exactly what your users are doing as well as where they’re doing it, however, that doesn’t always make sense. Let us look at Exchange on-premises for example; When you run Exchange servers on-premises, you don’t put firewalls and proxy servers to restrict or break and inspect the traffic to your Exchange Servers from your Exchange Clients (Outlook, Outlook Mobile, Active Sync, EWS, etc) since the benefit of doing that at a protocol level is zero. It’s also not supported.
However, we like to force layers of inspection on Exchange online traffic, since it’s moving through an untrusted medium, specifically the public internet. The net benefit of forcing Exchange Online client traffic through a proxy server to inspect it, like our Exchange Server example on our own network, is also zero. Once you move your data into a trusted location – a Microsoft Data Center – which has better security than most of us can afford, what is the benefit of doing protocol-level inspection?
Proxy servers are often paired with IPS/IPD devices, as well as layers of firewalls, DLP, and so on. I’ve counted up to 9 discrete levels of security for some customers. That makes the world of sense when you’re protecting data on the inside of that perimeter and your endpoints are locked down. Adding cloud services of any sort to these scenarios makes that security porous and semi-undefined.
Shift to the Cloud Security Model
Cloud security is more about trusting nothing as opposed to leveraging perimeter security and passwords. That means I’m not asking you to trust Microsoft Office 365. I’m also asking you to stop trusting your users, their devices, and potentially even the contents of your data, unless all of them are able to validate who they say they are and prove they can be trusted, continually and in real-time, no matter which device they’re coming from. Cloud services also need to authenticate themselves to our users and their clients. This makes Man in The Middle attacks exceptionally difficult when clients expect to see online service’s certificates or online services expect to see client’s certificates.
Browsing vs cloud
The Network that is built to browse (internet web traffic) is not the same network that is capable of consuming cloud services. Consider the holy grail of networking – latency. Every one of those inspection devices we spoke about earlier adds latency and often that latency is cumulative. Each device and layer that we force our traffic through will force a delay of some sort onto the packet. Inspecting proxies add the most, often 150 ms or more. Consider that your mailbox may be stored in an Office 365 data center in your city. With good internet, local DNS, and decent ISP peering that would mean 4 to 15 ms mailbox access. Customers who have invested heavily in network security can experience up to 400 ms access times or more.
Pulling on a thread
Outlook as a client will create 5+ long-running or persistent TCP threads with lifetimes measures in many hours per user. Opening more folders and calendars belonging to others will quickly multiply that. Firewalls and proxy servers optimize thread pools and as a result, are scaled for browsing traffic with connections that expire in seconds. Consider that a few thousand Outlook users can overwhelm a proxy server built to accommodate tens of thousands of browsing users.
Not arguing with physics
If any decent percentage of your data moves to the cloud, network traffic and security follow. Accessing cloud services means connecting your users to those cloud services in the most performant manner possible. For Office 365 that mantra is Local internet breakout and local DNS. Due to the way that Office 365 is architected, that will automatically route your users to one of the hundreds of Microsoft network edge locations or Service front door locations. Head office and branch office locations benefit from local internet and therefore dramatically accelerate client traffic.
What about security
As far as security goes, we treat those users, and their devices as if they’re not trusted. Because they’re not. In the trust-nothing model, we leverage mechanisms like Azure Active Directory Conditional Access to force users to prove who they are as well as that their devices are managed, patched, or at least compliant with our policies. Once we combine Identity, device, and location as authentication mechanisms, then it really doesn’t matter where in the world our users are. With that paradigm shift in mind, after moving user data to the cloud, how much security can we really achieve with on-premises network security and complex passwords?