Secure networks with Zero Trust
Big data presents new opportunities to derive new insights and gain a competitive edge. We are moving away from an era where networks were clearly defined and usually specific to a certain location. The cloud, mobile devices, and other endpoints expand the boundaries and change the paradigm. Now there isn't necessarily a contained/defined network to secure. Instead, there is a vast portfolio of devices and networks, all linked by the cloud.
Instead of believing everything behind the corporate firewall is safe, an end-to-end Zero Trust strategy assumes breaches are inevitable. That means you must verify each request as if it originates from an uncontrolled network—identity management plays a crucial role in this.
In the Zero Trust model, there are three key objectives when it comes to securing your networks:
Be ready to handle attacks before they happen.
Minimize the extent of the damage and how fast it spreads.
Increase the difficulty of compromising your cloud footprint.
To make this happen, we follow three Zero Trust principles:
Verify explicitly. Always authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.
Use least-privileged access. Limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA), risk-based adaptive polices, and data protection to protect both data and productivity.
Assume breach. Minimize blast radius for breaches and prevent lateral movement by segmenting access by network, user, devices, and application awareness. Verify all sessions are encrypted end to end. Use analytics to get visibility, drive threat detection, and improve defenses.
Network Zero Trust deployment objectives
Before most organizations start their Zero Trust journey, they have network security that is characterized by the following:
-
Few network security perimeters and open, flat networks.
-
Minimal threat protection and static traffic filtering.
-
Unencrypted internal traffic.
|
When implementing an end-to-end Zero Trust framework for securing networks, we recommend you focus first on these initial deployment objectives: |
|
|
|
I. Network segmentation: Many ingress/egress cloud micro-perimeters with some micro-segmentation. II. Threat protection: Cloud native filtering and protection for known threats. |
|
After these are completed, focus on these additional deployment objectives: |
|
|
|
|
Networking Zero Trust deployment guide
This guide will walk you through the steps required to secure your networks following the principles of a Zero Trust security framework.
|
|
Initial deployment objectives |
I. Network segmentation: Many ingress/egress cloud micro-perimeters with some micro-segmentation
Organizations should not just have one single, big pipe in and out of their network. In a Zero Trust approach, networks are instead segmented into smaller islands where specific workloads are contained. Each segment has its own ingress and egress controls to minimize the "blast radius" of unauthorized access to data. By implementing software-defined perimeters with granular controls, you increase the difficulty for unauthorized actors to propagate throughout your network, and so reduce the lateral movement of threats.
There is no architecture design that fits the needs of all organizations. You have the option between a few common design patterns for segmenting your network according to the Zero Trust model.
In this deployment guide, we'll walk you through the steps to achieve one of those designs: Micro-segmentation.
With micro-segmentation, organizations can move beyond simple centralized network-based perimeters to comprehensive and distributed segmentation using software-defined micro-perimeters.
Applications are partitioned to different Azure Virtual Networks (VNets) and connected using a hub-spoke model
Follow these steps:
Create dedicated virtual networks for different applications and/or application components.
Create a central VNet to set up the security posture for inter-app connectivity and connect the app VNets in a hub-and-spoke architecture.
Deploy Azure Firewall in the hub VNet to inspect and govern traffic between the VNets.
II. Threat protection: Cloud native filtering and protection for known threats
Cloud applications that have opened up endpoints to external environments, such as the internet or your on-premises footprint, are at risk of attacks coming in from those environments. It is therefore imperative that you scan the traffic for malicious payloads or logic.
These types of threats fall into two broad categories:
Known attacks. Threats that have been discovered by your software provider or the larger community. In such cases, the attack signature is available and you need to ensure that each request is checked against those signatures. The key is to be able to quickly update your detection engine with any newly identified attacks.
Unknown attacks. These are threats that don't quite match against any known signature. These types of threats include zero-day vulnerabilities and unusual patterns in request traffic. The ability to detect such attacks depends on how well your defenses know what's normal and what is not. Your defenses should be constantly learning and updating such patterns as your business (and associated traffic) evolves.
Take these steps to protect against known threats:
For endpoints with HTTP/S traffic, protect using Azure Web Application Firewall (WAF) by:
Turning on the default ruleset or OWASP top 10 protection ruleset to protect against known web-layer attacks
Turning on the bot protection ruleset to prevent malicious bots from scraping information, conducting credential stuffing, etc.
Adding custom rules to protect against threats specific to your business.
You can use one of two options:
For all endpoints (HTTP or not), front with Azure Firewall for threat intelligence-based filtering at Layer 4:
Deploy and configure Azure Firewall using the Azure portal.
Enable threat intelligence-based filtering for your traffic.
III. Encryption: User-to-app internal traffic is encrypted
The third initial objective to focus on is adding encryption to ensure user-to-app internal traffic is encrypted.
Follow these steps:
Enforce HTTPS-only communication for your internet facing web applications by redirecting HTTP traffic to HTTPS using Azure Front Door.
Connect remote employees/partners to Microsoft Azure using the Azure VPN Gateway.
- Turn on encryption for any point-to-site traffic in Azure VPN Gateway service.
Access your Azure virtual machines securely using encrypted communication via Azure Bastion.
|
|
Additional deployment objectives |
IV. Network segmentation: Fully distributed ingress/egress cloud micro-perimeters and deeper micro-segmentation
Once you've accomplished your initial three objectives, the next step is to further segment your network.
Partition app components to different subnets
Follow these steps:
Within the VNet, add virtual network subnets so that discrete components of an application can have their own perimeters.
Apply network security group rules to allow traffic only from the subnets that have an app subcomponent identified as a legitimate communications counterpart.
Segment and enforce the external boundaries
Follow these steps, depending on the type of boundary:
Internet boundary
If internet connectivity is required for your application that needs to be routed via the hub VNet, update the network security group rules in hub VNet to allow internet connectivity.
Turn on Azure DDoS Protection Standard to protect the hub VNet from volumetric network layer attacks.
If your application uses HTTP/S protocols, turn on Azure Web Application Firewall to protect against Layer 7 threats.
On-premises boundary
If your app needs connectivity to your on-premise data center, use Azure ExpressRoute of Azure VPN for connectivity to your hub VNet.
Configure the Azure Firewall in the hub VNet to inspect and govern traffic.
PaaS services boundary
- When using Azure-provided PaaS services (e.g., Azure Storage, Azure Cosmos DB, or Azure Web App, use the PrivateLink connectivity option to ensure all data exchanges are over the private IP space and the traffic never leaves the Microsoft network.
V. Threat protection: Machine learning-based threat protection and filtering with context-based signals
For further threat protection, turn on Azure DDoS Protection Standard to constantly monitor your Azure-hosted application traffic, use ML-based frameworks to baseline and detect volumetric traffic floods, and apply automatic mitigations.
Follow these steps:
Configure and manage Azure DDoS Protection Standard.
Configure alerts for DDoS protection metrics.
VI. Encryption: All traffic is encrypted
Finally, complete your network protection by ensuring that all traffic is encrypted.
Follow these steps:
Encrypt application backend traffic between virtual networks.
Encrypt traffic between on-premises and cloud:
Configure a site-to-site VPN over ExpressRoute Microsoft peering.
Configure IPsec transport mode for ExpressRoute private peering.
VII. Discontinue legacy network security technology
Discontinue the use of signature-based Network Intrusion Detection/Network Intrusion Prevention (NIDS/NIPS) Systems and Network Data Leakage/Loss Prevention (DLP).
The major cloud service providers already filter for malformed packets and common network layer attacks, so there's no need for a NIDS/NIPS solution to detect those. In addition, traditional NIDS/NIPS solutions are typically driven by signature-based approaches (which are considered outdated) and are easily evaded by attackers and typically produce a high rate of false positives.
Network-based DLP is decreasingly effective at identifying both inadvertent and deliberate data loss. The reason for this is that most modern protocols and attackers use network-level encryption for inbound and outbound communications. The only viable workaround for this is "SSL-bridging" which provides an "authorized man-in-the-middle" that terminates and then reestablishes encrypted network connections. The SSL-bridging approach has fallen out of favor because of the level of trust required for the partner running the solution and the technologies that are being used.
Based on this rationale, we offer an all-up recommendation that you discontinue use of these legacy network security technologies. However, if your organizational experience is that these technologies have had a palpable impact on preventing and detecting real attacks, you can consider porting them to your cloud environment.
Products covered in this guide
Microsoft Azure
Network Security Groups and Application Security Groups
Azure Web Application Firewall
Conclusion
Securing networks is central to a successful Zero Trust strategy. For further information or help with implementation, please contact your Customer Success team or continue to read through the other chapters of this guide, which spans all Zero Trust pillars.
The Zero Trust deployment guide series
