Challenges in enforcing company security policy at scale
As one of the largest and most diverse technology companies in the world, Microsoft faces a unique challenge in securing its network. With over 160,000 employees, thousands of devices, and hundreds of applications, the company needs to ensure that its network security policy is consistent, compliant, and effective across the entire organization. This also means that network security policy is applied across all services and can modify rules to meet special needs across the entire organization.
However, enforcing network security policy at scale isn’t an easy task. Traditional models of network security administration rely on manual processes, complex configurations, and rigid hierarchies that can introduce human errors, inconsistencies, and bottlenecks. Moreover, these models are not designed to cope with the dynamic and heterogeneous nature of modern networks, where devices, users, and applications can change frequently and unpredictably.
What are the traditional models?
Network security groups (NSGs) are a core component of Microsoft Azure network security, allowing users to define and apply granular rules for inbound and outbound traffic. However, managing NSGs across multiple applications and teams can be challenging, especially when there is a need to enforce some common security policies across the organization. There are three traditional models for managing NSGs:
- Centralized model—A central governance team manages all the NSGs and their security rules. This ensures consistent and effective security enforcement, but also adds operational overhead and reduces agility.
- Decentralized model—Individual application teams manage their own NSGs and security rules. This gives them flexibility and autonomy, but also introduces security risks, as the central governance team cannot enforce any critical security rules or audit the compliance of the NSGs.
- Hybrid model—Individual application teams manage their own NSGs, but with some guidance and oversight from the central governance team. The central team can use Microsoft Azure Policy to create standard rules for the NSGs and monitor the changes made by the application teams. This combines some of the benefits of the centralized and decentralized models, but also has some drawbacks. For example, there is still no hard enforcement of the security policies, and the notifications can be overwhelming and hard to manage.
A new approach to network security with Azure Virtual Network Manager
In the past, Microsoft used a hybrid model of network security, where some NSGs were centrally managed by the governance team, and some were locally managed by the application teams. This model had some drawbacks, such as inconsistency, complexity, and lack of enforceability. To overcome these challenges, Microsoft is moving to a new model based on Azure Virtual Network Manager, which allows the governance team to create and apply admin rules across multiple NSGs, while still enabling the application teams to manage their own NSG rules.
To allow the management of security rules easier, Azure Virtual Network Manager introduced the concept of network group, which is a collection of network resources that can be defined using logical conditions. With Azure Policy, you can define membership rules conditionally for your network groups. Azure Virtual Network Manager integrates with Azure Policy to automatically apply the security admin rules to virtual networks that appear in these network groups. In the example below, users can let Azure add to the network group those virtual networks with the key value pair of environment=production, and the security admin rules will automatically apply to these virtual networks.
This way, we can ensure that security policies are consistently enforced across your network groups and resources, without manual intervention.
Using Azure Virtual Network Manager coupled with Azure Policy, Microsoft defines security policies for different units as below and manages them cohesively to make sure both Microsoft and our customers are secured by default.
One of the main use cases of Azure Virtual Network Manager is to create network baselines (policies) for blocking high-risk ports and implementing zero-trust principles. These baselines are important for customers’ security because:
- High risk ports are a list of network applications and the normal Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ports that they use, which are considered to present a very high security risk to Microsoft and its customers. These ports are often associated with malware, ransomware, or unauthorized access, and should be blocked by default on all NSGs.
- Zero-trust baseline is a policy that assumes that all network traffic poses some level of risk, and therefore only allows the minimum required traffic for each service. This is the concept of network security by least privilege. In the past, when new services were released on the physical network, a security review was performed to determine what ports and protocols were absolutely required to be exposed and to what addresses. The routers that the physical computers were behind were then configured to only allow the traffic that was approved by the security review. With the development of Azure Virtual Network Manager, this process can be automated and applied to the entire organization.
By using Azure Virtual Network Manager, the governance team can create and update these network baselines at the network manager level, and apply them to multiple NSGs at once, ensuring that some critical security policies are enforced across the organization. At the same time, the application teams can still manage their own NSG rules, if they do not conflict with the admin rules, allowing them to adapt to their specific needs and scenarios, without waiting for the approval or intervention of the central team. This way, Azure Virtual Network Manager provides security for Microsoft and its customers.
The post Using Microsoft Azure Virtual Network Manager to enhance network security appeared first on Microsoft Azure Blog.
