Azure Network Security Proof of Concept Part 1: Planning

 

Overview

Planning a network security Proof of Concept (POC) in your Azure environment is an effective way to understand the risk and potential exposure of a conceptual network design and how the services and tools available in Azure may be used for improvement. This is the first part of a series of steps to check in validating your conceptual design scenarios.

 

At the end of this article, you will be able to put a process map on your POC, know the type of resources required and have an idea of the implementation strategy to use. Keep it simple.

 

Azure network security involves mandatory and continuous improvement processes for workload protection. The effort to improve the network security posture of every client is a combination of both the Azure team and the customer-shared responsibility in the cloud. For more information, see the Azure network  security controls documentation.

Azure resources also have a 30-day trial access that may be used to validate security with a POC. This is useful to note when making budgetary commitments.

 

 

Scope

 

In this article, we discuss the steps you should consider when performing a security POC (Network, Container, Apps) to meet regulatory and compliance standards.

 

When testing any tool, it will be necessary to determine what capabilities are expected, to achieve a good result. To get started, here are some scenarios that could benefit from layers of network security.

 

        

             

 

 

 

The different standards that guide the resources used by your service offerings such as NIST SP 800-53 R4, SWIFT CSP CSCF-v2020 and CIS, and how they align with compliance, should also be considered as you go along in the exercise.

Take advantage of Azure Security Benchmark to establish guardrails for your security configurations.

 

 

 

Understand your network

 

As the network administrator/manager, having an adequate understanding of the layout of your network provides insight into the security requirements. The requirements for the different scenarios may be considered by keeping the focus on the objective of your test:

 

Architecture: Cloud native or hybrid solutions. More information on Cloud design patterns

Resources: Network and Application layer resources. Decide on the focus of your test.

Infrastructure: Storage, Computing etc. See more on Azure infrastructure

Accessibility: Multi-factor auth, JIT, Role Permissions, RDP/SSH, Azure Bastion etc.

Connectivity services: Virtual WAN, ExpressRoute, VPN Gateway, Virtual network NAT Gateway, Azure DNS etc. More information on Connectivity services

 

 

Permissions

Access to resources should be role-based when managing user identities.  Conditional access should be granted to resources based on device, identity, assurance, network location, and grant temporary access for other connections. In addition, use JIT and MFA and follow the principle of least privilege assignment.

Implementation strategy

 

It is pertinent to understand which direction your proof of concept should take, such as: how long is the scheduled plan? Is there a dev environment or cluster dedicated to this? What priorities are attached to the application or network infrastructure? A few important guidelines should include:

 

- Build a security containment strategy: Align network segmentation with overall strategy and centralize network management and security. Develop and update the security incident response plan as the network changes.

- Define success index: This is a practical way to measure the work to be done and set the right expectation from the outcome of the process. Are you testing for feasibility, access control or confirming mitigation? How would you define a successful POC?

- Write down the contributors or administrators for each workload/resource for follow-up and task designation. It is pertinent to know who is assigned to a network contributor role or to a custom role and who has the appropriate actions listed for the permissions.

- Establish a timeline for the requirements that may be discovered during the POC.

 

 

 

Proof of Concept scenarios  

 

Once the guidelines and framework from above have been established, the next step is to map out the scenario. There are different examples of scenarios that may be considered. If unsure, you can look through this article on Azure network security best practices to see areas that need improvement and then work on a POC to address the problem.

Other common examples that an administrator/manager may consider for a POC include:

 

Network segmentation

The logical partition of the network is achieved using subnets, subnets peering and virtual networks to define resource accessibility by roles, users, functions, resource types, user-defined routing, location etc. Examples include:

- Restrict access within a Virtual network by using Network Security Groups and Firewall

- Access on-prem resources, cloud and filter internet traffic by creating User-Defined Routes in Azure Firewall

 

Web Application security

Requests served by HTTP and HTTPs require different components for the appropriate response type. You may be looking to test for layer 7 attack validation and mitigation or doing a post deployment check.

The application may require user-managed or system-managed certificates, protocol support (IPv6 and HTTP/2 traffic), bot management. An administrator may be looking to validate security prone issues. Example of POCs for web application security include:

- Web-App vulnerability protection from SQL injection

- Geo-based access control and rate limiting

 

Ingress and Egress traffic management

This includes a series of tests around how traffic is managed from one node to the other within and outside the network. Examples of POCs might include remote connectivity, intra-VLAN routing, forced tunneling, geolocation management, content distribution etc. Examples of this POC include:

- DNAT access by RDP protocol to Windows client

- Bastion connectivity to a virtual network

- Path-Based Routing for resources in a backend pool.

- Secured Virtual Hub to connect virtual WAN resources.

 

DDOS attack simulation

Insights into how resources with public facing interfaces handle DDOS attacks and deny access to legitimate users is a common POC. Validation of your threshold values, how your Azure networking environment responds to volumetric or protocol attacks, and the report generation are common instances you may want to review. Examples of this POC include:

- Simulate DDoS attack through a Microsoft approved partner.

- Rate limiting access for a specific IP address.

 

 

 

Monitor the process

 

Monitoring the proof of concept behavior as you perform the process is essential for aggregating feedback.

Log Analytics is the primary tool in the Azure portal for writing log queries and interactively analyzing their results.

NSG flow Logs provide information about the flow of IP addresses in NSGs. It is vital and highly recommended for more understanding of your network traffic.

Also, confirm that diagnostic logging is enabled for your resource through the Azure portal. This could take a few minutes to show the results during a test.

Diagnostic logs provide insight into Azure operations that were performed within the data plane of an Azure resource. Follow this link for more on diagnostics logging.

 

Network Performance Monitor is a cloud-based hybrid network monitoring solution that could be used to monitor network performance between various points in your network infrastructure and connectivity to application endpoints. Follow this guideline to set up performance monitoring, Service Connectivity monitoring and Express-route monitoring.

For a complete guide on monitoring your network, follow this 5 minute start video guide.

 

 

Conclusion

 

There are many reasons why you may want to do a POC. This series is focused on creating a direction for a network security POC for layer3-4 and layer 7.  Once you are clear on what you are testing for (e.g. WAF performance, DDOS mitigation/response or custom rules), proceed to the implementation strategy.

In summary, align your network segmentation model with the enterprise segmentation model for your organization. Delegation models that are well aligned improve automation and make for quick fault isolation. A recommended approach for production enterprise is to allow resources to initiate and respond to cloud requests through cloud network security devices.

As a rule, always adopt a Zero Trust approach.

 

(In the next part of this series, we build an environment to do a POC, using some of the examples in the Proof of Concept scenarios mentioned in this blogpost. You will be able to follow the steps in the article to do some POC examples)