Earlier this year, we hosted a azure security best practices webinar that highlighted best practices and native Azure security capabilities to help you protect your workloads running in the cloud.
Several companies, including Microsoft, are shifting from a perimeter focused cyber security model to prevent data breaches to an Assume Breach mentality. There is still a lot of value in maintaining a security perimeter, but you also need to increase your network security monitoring to identify indicators of compromise, and segment your environment to minimize reach and access of a bad actor who is trying to move laterally in your environment. In other words, you may set up a perimeter in your cloud environment similar to what you are using in your own datacenter, but there are other things you can do within your cloud environment to reduce your risk and protect your applications and data.
Microsoft lays out several options for setting up a security perimeter based on two factors. First, will your application or web service be available to the public, and second, will you be deploying a hybrid architecture that connects your cloud environment to your on-premises datacenter.
For publicly facing applications and services, you want to monitor all traffic going in and out of your environment to detect cyber attacks and identify data exfiltration. Many organizations start with a next generation firewall, web application firewall (WAF), application gateway, or similar inline device to monitor the traffic as it passes through it, and often times they start with the same tools they are using for their own datacenter. These may work well for workloads that are relatively static, but trying to scale this perimeter for autoscaling workloads can be challenging, so it is important to validate autoscaling works for both the application and the security solutions deployed inline. Another challenge with inline devices is they can be too restrictive for ‘suspicious’ activity that may not necessarily indicate reconnaissance or a cyber attack.
There are some situations where an inline device makes sense, and in the cloud you can evaluate this approach on a per application or per service basis instead of implementing it as part of a perimeter for all of your infrastructure running on Azure.
Once you finalize your perimeter strategy, you should look at the internal network segmentation. Network security groups should be used across your environment, whether the application or service is publicly exposed or not. They isolate VMs and reduce the reach of an attacker if they have compromised your environment. You should review the default settings to make sure the NSG does not allow traffic across the entire VNET. Also, NSGs for database tiers and application or logic tiers should not have access to the internet, only the web or presentation layer should. Finally, you should make sure these policies are reviewed and kept up to date. You may want to publish these policies as ARM templates–so your developers can implement these policies as part of their deployment process–and maintain these ARM templates in a source control repository.
Operations Management Suite can help you understand the topology, data flows, and performance of these logical networks. The recently released Azure Network Watcher can help you validate your NSG configurations before rolling them into production. One of the questions we’ve heard from customers is “how do you know these NSGs are working properly?” We recommend enabling diagnostic logs for NSGs which will track all of the events and the number of times a particular NSG rule was applied to either deny or allow traffic.
The options for implementing a connection between your datacenter and your cloud environment are straightforward. A direct connect connection using Azure ExpressRoute is more secure and offers faster throughput because it is not going over the public internet. These can also be used to migrate your data to cloud, as these connections are much faster and more reliable than the public internet.
The other option is to setup a VPN connection. There are more considerations around scale and performance, but this may be a good option of the data flows between the two environments are minimal.
Monitoring network traffic in cloud environments is challenging because there is no way to tap into the networking infrastructure and pull the traffic for analysis as you would with a SPAN port in your network. We had to find a different to capture this traffic, but before I share that, I wanted to clarify this meant more to understand how network monitoring can be done in the cloud versus promoting our solution. Our approach uses an agent to mirror the traffic coming in-and-out of the host VM and sends that information to our virtual appliance for analysis. We analyze the network and application traffic on the appliance to avoid creating additional overhead on the VM. If we find something suspicious, we will send those packets back to our environment for further analysis by our Security Operations team. We manage the appliances and tune them to ensure they are up to date with the latest threat signatures and attack patterns specific to the applications you are running in your environment. All of this network monitoring is done out-of-band, so our appliances are not standing between your application or service and the users accessing it. We can also deploy into your own datacenter and provide holistic security monitoring across your hybrid-cloud or even multi-cloud deployment.
You can find out more information about our intrusion detection system and web application protection on our website.
