Azure Security Center

Most companies have someone whose job is to learn best practices and ensure the company complies with them. When it comes to Azure, learning those best practices can be a tough job because of the large number of services available. Because Azure is always changing and evolving, this job is made even tougher.

Fortunately, Azure Security Center can help you keep up with best practices, but it also can help with providing the steps you need to take to keep your resources configured in a way that makes them more secure. Security Center can even help you with keeping your on-premises resources secure.

Security Center offers two tiers of service:

Free tier The free tier provides general assessment and recommendations for securing your Azure resources and covers only Azure virtual machines and Azure App Service.

Standard tier The Standard tier adds coverage of your Azure SQL Databases, MySQL databases, PostgreSQL, Azure Storage, IoT devices, AKS, Azure Container Registry, and Azure Key Vault. The Standard tier also offers additional features such as advanced threat detection, analysis from Microsoft Threat Intelligence, and the ability to manage the regulatory compliance of your Azure resources. The Standard tier is billed by the hour, and full details on pricing can be found at https://azure.microsoft.com/en-us/pricing/details/security-center.

To get started with Security Center, click Security Center in the menu on the Azure portal homepage. This will take you to the Overview blade where you can see an overview of all your resources being protected by Security Center, as shown in Figure 4-1.

There are three primary areas of coverage in Security Center.

• Policy & Compliance Provides a Secure Score and an Overall Score, which shows the security of your resources. This area also covers your compliance with regulatory standards.

• Resource Security Hygiene Provides a high-level overview of the health of your resources from a security perspective. Security issues are categorized as High Severity, Medium Severity, or Low Severity.

• Threat Protection Shows you any active or past attacks or threats on your resources.

Information for the Policy & Compliance and Resource Security Hygiene areas is provided by the service being protected. This information is often related to best practices. The information in the Threat Protection area, on the other hand, is specifically targeted at analyzing both the network traffic and the behavior of users of your resources. If anything looks suspicious, it’s reported by Security Center.

Microsoft Threat Intelligence is used to identify security threats. Threat Intelligence uses Microsoft’s historical data and machine learning to identify possible threats. These threats could be a hacker attempting to gain access to a resource, or they could be related to suspicious activity performed by a user. For example, if a user elevates his privileges on a VM and runs an unknown process, these activities would likely be flagged as an incident that should be investigated.

By clicking an item in the Overview blade, you can drill down into more details. In Figure 4-2, we’ve clicked Compute & Apps in the Overview blade. This view allows you to see all the recommendations. You can also see how much your Secure Score will improve if you address each recommendation.

Clicking one of the recommendations will provide additional information. In most cases, you’ll see a link to instructions on how you can address the recommendation, but Security Center can automatically take care of some recommendations. Recommendations that can be fixed automatically will display a Quick Fix badge, as shown in Figure 4-2.

Open network ports on your VMs are one of the greatest security threats to your cloud resources. Accessing your VMs using the remote desktop for Windows VMs or SSH for Linux VMs is a necessary part of managing those resources, but hackers commonly use the network ports used for remote management to break into VMs. Security Center provides a feature called just-in-time (JIT) access that helps to protect your VMs from attacks on management ports.

When JIT access is enabled, users must request access to a VM in order to remote into it. Until someone is given JIT access, management ports on the VM are closed so they can’t be accessed. Once JIT access is given to a user, the ports are open for a specific period of time as requested by the user. Once that time period has elapsed, the management ports are closed again.

To enable JIT access on a VM, click Just In Time VM Access in Security Center, as shown in Figure 4-3. Click the Recommended tab to see VMs that are currently not configured for JIT access. Select one or more VMs and click Enable JIT to turn on the feature.

When enabling JIT access, you can choose which ports you want to protect, as shown in Figure 4-4. The recommended ports for management are listed, but you can add your own ports. For example, if you’ve changed your VM configuration so that management happens on a non-typical port, you can add that port for JIT access.

In addition to specifying the port, you can also control which protocols are allowed over the port and which IP addresses are allowed. If the allowed IPs are set to Per Request, the user who requests access will have the option of specifying an IP address or a CIDR block. Otherwise, you can specify a CIDR block yourself in order to allow access only from a specific IP address range.

When a user requests access, the number of hours that access is given can be set up to the maximum number of hours you specify in the port configuration. The maximum request time can be configured from 1 to 24 hours, but it defaults to 3 hours.

Once a VM is configured for JIT access, users request access from Security Center. After clicking Just in Time VM Access, select the VM and click Request Access, as shown in Figure 4-5.

As shown in Figure 4-6, users requesting access must specify which ports to open, the IP addresses that are allowed (assuming they weren’t specified when JIT access was enabled for the VM), and how long access is needed (up to the maximum time configured). Once Open Ports is clicked, the requested ports will remain open for the specified period.

Key Vault

Most applications use sensitive or secret information. For example, an application that uses a database needs to know how to connect to that database, and that connection information is stored in a connection string. The connection string might contain a username and password that protects the database and storing that username and password in a clear text file would be an obvious security risk.

Azure Key Vault provides a secure way to store secrets, keys, and certificates. Once an item is stored in Key Vault, you can apply security policies that define which users and applications can access it. Key Vault is encrypted using encryption keys, but Microsoft has no visibility into the encryption keys or the encrypted data.

Key Vaults are created in the Azure portal, as shown in Figure 4-7.

There are two pricing tiers available in Key Vault: Standard and Premium. The only difference between the two is that keys are stored in hardware security modules (HSMs) in the Premium tier. An HSM is a separate piece of hardware that is designed for securely storing encrypted content, and it’s also specialized for processing cryptographic data.

You can import a key, secret, or certificate into Key Vault, but Key Vault can also generate security keys and certificates for you. For example, you might want to generate a security key that your company can use to sign certificates. If you want to generate a 4,096-bit security key for this purpose and store it in Key Vault, click Keys and then click Generate/Import, as shown in Figure 4-8.

In Figure 4-9, a 4,096-bit RSA key is being generated and stored in Key Vault.

As shown in Figure 4-10, once the key has been stored, you can view the entry to get the key identifier, which is a URL that can be used by authorized users or applications to retrieve the key. However, you cannot view the key because it’s encrypted and not available except through the key identifier.

Another common use scenario for Key Vault is to store encryption keys for Azure VMs. One of the security recommendations offered by Security Center is to encrypt VM disks. A VM disk is stored as a VHD file, and when it’s encrypted, the host operating system that runs the VM must be able to access the security key in order to decrypt the VHD and run the VM. Key Vault offers capabilities that are specifically targeted for this kind of scenario.

In order to use Key Vault for disk encryption keys, the access policies must be configured to allow the vault for disk encryption. If this wasn’t done when the vault was created, you can change it by clicking Access Policies, and checking the Azure Disk Encryption For Volume Encryption option, as shown in Figure 4-11.

Azure Disk Encryption is enabled on your VMs using Azure PowerShell, the Azure command-line interface (CLI), or an ARM template.

Azure Sentinel

When it comes to securing data and resources, many businesses use tried and proven frameworks that are designed to focus on what’s most important, such as SOAR (Security Orchestration, Automation, and Response) or SIEM (Security Information and Event Management). Many companies, in fact, use SOAR and SIEM in combination.

Implementing SOAR and SIEM can be challenging. Many companies hire security experts to implement them in their businesses. Microsoft wanted to make SOAR and SIEM easy to implement, even for people who aren’t security experts. The result of their work is Azure Sentinel.

To start using Azure Sentinel, you first create a Sentinel workspace. Once you do that, you’ll see the Azure Sentinel Workspaces screen shown in Figure 4-12. Click the Connect Workspace button to create an instance of Azure Log Analytics and add it to your Sentinel workspace. If you already have an instance of Log Analytics, you can choose it to add it to Azure Sentinel.

After you add Log Analytics to Azure Sentinel, you connect data sources to Sentinel using connectors by clicking the Connect button, as shown in Figure 4-13.

Microsoft provides connectors for Azure and other Microsoft products, but there are also connectors for third parties. In Figure 4-14, you can see a connector for Amazon Web Services.

Once you add a connector, you’ll see prerequisites for the connector, as well as next steps you need to take. In Figure 4-15, we’ve added a connector for Azure Active Directory.

The list of prerequisites is an active list that shows the current status of all prerequisites. In Figure 4-15, all prerequisites have been met except for the Azure Active Directory license requirement that is showing an X icon.

Clicking Next Steps allows you to take the steps necessary to complete adding your connector. In Figure 4-16, Next Steps for configuring the Azure Active Directory connector are shown.

After you add your connector, you’ll save the configuration inside an Azure Monitor Workbook. Workbooks make it easy to aggregate data so that it’s easier to consume.

Azure Sentinel can also search for specific security threats. Many queries are provided that search for threats of all kinds. By clicking Hunting, you can select a query you want to run against your resources, as shown in Figure 4-17.

When Sentinel finds a problem, you can have it respond using a Playbook. A Playbook is a workflow that runs in response to an alert in Sentinel. To create a Playbook, click Playbooks and then click Add Playbook, as shown in Figure 4-18.

When you add a new Playbook, Sentinel will ask you to create a new Logic App. That’s because Playbooks use Logic Apps for their workflows. As of this writing, the user experience is a little disconnected. After the Logic App is created, you’ll need to click Blank Logic App, as shown in Figure 4-19.

Enter sentinel in the search box and click When A Response To An Azure Sentinel Alert Is Triggered, as shown in Figure 4-20. After that, you can continue to build your workflow and add the actions you want to perform when the alert is triggered.

Defense in depth

Just for a moment, transport yourself back to medieval times and think about what it was like living in a castle. These weren’t friendly times in many ways, and there was always a hostile force trying to gain entry into the fortress. To prevent invasion, moats were built around castles. The purpose of the moat was to prevent an opposing force from tunneling under the wall and gaining entry.

Even before an enemy reached the moat, archers along the high wall of the castle would pose a formidable risk to attackers approaching the castle. Assuming an opposing force made it past the archers and traversed the moat, they were met with a high wall and a sturdy gate. If they were able to make it past the gate, they were met with an army of men with swords and other nasty weapons.

Medieval folks had a pretty good idea when it came to security. They realized that a single opposing force wouldn’t be enough to keep them secure. They needed layered opposition so that anyone defeating one method of security would be met with several more down the line.

This is a perfect example of defense in depth, and it’s why defense in depth is often referred to as the “castle approach.” When it comes to network security, this multi-layered approach is also the best way to keep your network safe. Azure Firewall can help prevent a malicious user from making it into your network, Network Security Groups can help you control network traffic inside your network, and Azure DDoS Protection can help to identify and mitigate malicious traffic that might otherwise seem normal.

Network Security Groups (NSGs)

A Network Security Group (NSG) allows you to filter traffic on your network and apply rules on that traffic. An NSG contains several built-in rules provided by Azure that are designed to allow your resources in the virtual network to communicate with each other. You can then add your own rules to the NSG to control traffic into and out of the network, and also between resources in the network.

Figure 4-21 shows a multi-tier application.

Here’s the traffic flow of this application.

• Subnet 1 receives data from another virtual network running Azure Firewall.

• Subnet 1 communicates with Subnet 2 to process requests.

• Subnet 2 communicates with a database server in Subnet 3 in order to access data.

If you want to ensure a secure environment, Subnet 1 should not be able to directly communicate with resources in Subnet 3. Likewise, Subnet 3 should not be able to directly communicate with resources in Subnet 1. Finally, only Subnet 1 should be able to communicate with the other virtual network running Azure Firewall. You can use NSGs to implement rules that will enforce these policies.

NSGs can be associated with a subnet or to a network interface attached to a VM. Each network interface or subnet can only have one NSG associated with it, but you can create up to 1,000 rules in a single NSG, so you should be able to easily apply all the rule logic necessary for any task. If you associate an NSG to both a subnet and to one or more network interfaces inside that subnet, the rules for the NSG associated with the network interfaces are applied first, followed by the subnet’s NSG’s rules.

To prevent rules from interfering with each other, each rule you create in an NSG has a priority between 100 and 4,096. Rules with a lower priority take precedence over rules with a higher priority. Network traffic is applied against the rule with the lowest-priority number first. If the traffic matches that rule, the rule is applied, and processing of the rule stops. If the traffic doesn’t match the rule, it is evaluated against the next-lowest priority rule. This continues until the traffic has either matched a rule, or there are no additional rules.

To create an NSG, search for Network Security Group in the Azure Marketplace. When you create an NSG, give it a name, enter a name in the Name field or click Create New to create a resource group, and choose a location for the NSG from the Region drop-down menu, as shown in Figure 4-22.

After you create an NSG, you can then add inbound and outbound rules for the NSG. Once you open the NSG in the Azure portal, click Inbound Security Rules to add new inbound rules, and click Outbound Security Rules to add outbound rules.

In Figure 4-23, Inbound Security Rules has been clicked to add a new rule that allows traffic from the virtual network running Azure Firewall. After that, the NSG will be associated with Subnet-1. Note that you can associate the NSG with a subnet or network interface before adding rules.

Click Add to add a new NSG rule. Figure 4-24 shows a new rule being added that allows traffic into this subnet from the address space of another virtual network that’s running Azure Firewall.

The rule being configured in Figure 4-24 uses CIDR notation for the source IP addresses, but you can also enter a specific IP address or change the Source drop-down menu to Any if you want the rule to apply to all IP addresses. Click Add to create the rule.

Once you’ve created a rule, click Subnets to associate an NSG with a subnet, or click Network Interfaces to associate it with a network interface used by a VM. Lastly, click Associate, as shown in Figure 4-25.

Figure 4-26 shows the blade where an NSG is associated with a subnet.

Outbound security rules are created in the same way inbound rules are created. You aren’t required, however, to create a corresponding outbound rule for every inbound rule. NSGs maintain what’s called a flow record that stores the state of a connection, and the NSG will allow traffic that corresponds to that flow record without an explicit rule. If a security rule allows inbound traffic to port 80 from IP addresses in the range of 10.1.0.0/16, such as the rule configured in Figure 4-24, the NSG will also allow outbound traffic on port 80 to addresses in that same range using the flow record. The flow record is no longer in effect once traffic stops flowing for a few minutes.

There are some cases where you won’t know the specific IP address range. For example, if you want to configure an NSG rule on a virtual network that allows all traffic from the Internet, you wouldn’t specify an exact address range. To deal with that, NSGs allow you to use service tags when configuring rules.

A service tag is a special identifier created by Microsoft that applies to the Internet or to a specific service type within Azure. For example, if you have some web apps running in Azure App Service, and you want to allow them to communicate with your subnet, you can use the AppService service tag in your inbound rule to allow that. Azure services also have region-specific service tags so that you can allow or deny traffic only from specific regions.

To use a service tag, set the Source of your rule to Service Tag. You can then select a service tag from the Source drop-down menu. In Figure 4-27, the AppService.CentralUS service tag is being used to allow traffic from Azure App Service resources in the Central US region.

Azure Firewall

In computing parlance, a firewall is an appliance through which network traffic travels into and out of a particular network. The purpose of a firewall is to allow only desired traffic on the network and to reject any traffic that might be malicious or that comes from an unknown origin. A firewall imposes control on the network using rules that specify a source and destination IP address range and port combination.

In a typical firewall configuration, all traffic is denied by default. In order for the firewall to allow traffic to pass through it, a rule must match that traffic. For example, if you want to allow someone on the public Internet to access a web application you have running on a particular server, create a firewall rule that allows communication to ports 80 and 443 (the ports for HTTP and HTTPS traffic). You then configure the rule to send that traffic to your web server.

There are several firewalls available from third parties in the Azure Marketplace, but Microsoft also offers its own firewall called Azure Firewall. Azure Firewall is a PaaS offering in Azure, and it’s easily managed and offers a 99.95 percent uptime guarantee. Azure Firewall scales according to your networking needs, so you don’t have to worry about traffic spikes causing latency or downtime for your applications.

A typical setup for Azure Firewall consists of the following:

• A centralized hub network that contains the Azure Firewall and a VM that operates as a jumpbox. The firewall exposes a public IP address, but the jumpbox VM does not.

• One or more additional networks (called spoke networks) that don’t expose a public IP address. These networks contain your various Azure resources.

The jumpbox is a VM that you can remote into in order to manage other VMs in your networks. All other VMs are configured to only allow remote access from the jumpbox VM’s IP address. If you want to access a VM in a spoke network, you first remote into the jumpbox VM, and then you remote into the spoke network VM from the jumpbox. This set up is referred to as a hub-and-spoke configuration, and it provides additional security for your network resources.

Figure 4-28 is an illustration of a typical hub-and-spoke configuration that also includes Azure Firewall. Traffic that comes from the Internet over port 443 (HTTPS traffic) is directed by the firewall to a web server running in Spoke VNet 1. Traffic that comes in over the remote desktop port is directed to the jumpbox VM, and users can then use Remote Desktop Protocol (RDP) from the jumpbox VM to a VM in Spoke VNet 2.

Before you can configure a firewall to handle network traffic, you’ll need to create an instance of Azure Firewall. You can choose to include Azure Firewall when you create your virtual network in Azure, or you can create a firewall and add it to an existing virtual network. Figure 4-29 shows Azure Firewall being created during the creation of a new virtual network.

When you create a firewall during the creation of a virtual network, Azure creates a subnet in the virtual network called AzureFirewallSubnet, and it uses the address space you specify for that subnet. A public IP address is also created for the firewall so that it can be accessed from the Internet.

While the PaaS nature of Azure Firewall does remove much of the complexity, using a firewall isn’t as simple as enabling it in your virtual network. You will also need to tell Azure to send traffic to the firewall, and then you’ll need to configure rules in the firewall so that it knows what to do with that traffic.

To send traffic to your firewall, you need to create a route table. A route table is an Azure resource that is associated with a subnet, and it contains rules (called routes) that define how network traffic in the subnet is handled.

A route table is created using the Route Table item in the Azure Marketplace. Once you create a new route table, you must associate it with one or more subnets. To do that, click Subnets and then click Associate, as shown in Figure 4-30.

After you click Associate, select the Virtual Network and the Subnet, as shown in Figure 4-31.

In our particular setup, we want to associate both the JumpboxSubnet and the ServerSubnet with the route table. This will ensure that the firewall will handle all network traffic to the jumpbox VM and all traffic from the ServerSubnet.

Once we’ve associated the route table with the subnets, we create a user-defined route so that traffic is directed through Azure Firewall. To do that, click Routes and then click Add, as shown in Figure 4-32.

Figure 4-33 shows the configuration of a new user-defined route named ToFirewall. This route is configured for 0.0.0.0/0, which is the notation for all traffic. It’s then sending that traffic to a virtual appliance (Azure Firewall, in this case) located at IP address 10.1.1.4, which is the internal IP address of this firewall. Once this route is configured, it will immediately apply to all devices on the subnets associated with the route table.

Remember, Azure Firewall blocks all traffic by default, so at this point, there’s no way to reach the jumpbox VM that’s in the JumpboxSubnet. In order to access that VM, you must configure a firewall rule in Azure Firewall that will forward the appropriate traffic to the jumpbox VM.

To add a firewall rule, open Azure Firewall in the Azure portal and click Rules, select the type of rule, and click the Add button to add a new rule collection, as shown in Figure 4-34.

There are three types of rule collections available in Azure Firewall.

• NAT Rule Collection Network address translation (NAT) rules are used to forward traffic from the firewall to another device on the network.

• Network Rule Collection These are rules that allow traffic on specific IP address ranges and ports that you specify.

• Application Rules Collection Application rules are used to allow applications, such as Windows Update, to communicate across your network. Also, they can be used to allow particular domain names such as azure.com and microsoft.com.

Azure Firewall combines all the rules of a specific type and priority into a rule collection. The priority is a number between 100 and 65,000. Lower numbers represent a higher rule priority and are processed first. In other words, if you want to ensure that a rule is always applied before all other rules, include that rule in a rule collection with a priority of 100.

When network traffic enters the firewall, NAT rules are applied first. If the traffic matches a NAT rule, Azure Firewall applies an implicit network rule so the traffic can be routed appropriately, and all further rule processing stops.

If there isn’t a NAT rule that matches the traffic, network rules are applied. If a network rule matches the traffic, all further rule processing is stopped. If there isn’t a network rule that applies to the traffic, the application rules are applied. If none of the application rules match the traffic, the traffic is rejected by the firewall.

To allow access to remote into the jumpbox VM, you might configure a NAT rule that forwards any traffic on port 55000 to port 3389 (the port for remote desktop) on the internal IP of the jumpbox VM, as shown in Figure 4-35. Because port 55000 is a general port that wouldn’t normally be used for remote desktop, someone with malicious intent would likely never discover that it’s being used for that purpose.

In addition to rules that you configure, the threat intelligence feature in Azure Firewall can protect you from known-malicious IP addresses and domain names. Microsoft constantly updates its list of known-bad actors, and the data collected is provided in the Microsoft Threat Intelligence feed.

When you enable threat intelligence, you can choose to have Azure alert you if traffic from a known-malicious IP address or domain name attempts to enter your network. Also, you can choose to have the traffic denied by the firewall automatically, as shown in Figure 4-36.

Azure DDoS Protection

Cloud applications that are accessible from the Internet over a public IP address are susceptible to distributed denial of service (DDoS) attacks. DDoS attacks can overwhelm an application’s resources and can often make the application completely unavailable until the attack is mitigated. DDoS attacks can also be used to exploit security flaws in an application and attack systems to which an application connects.

Azure uses DDoS Protection to help protect against DDoS attacks. DDoS Protection is a feature of Azure Virtual Networks. There are two tiers of DDoS Protection: Basic and Standard.

• Basic Basic protects you from volume-based DDoS attacks by distributing large amounts of volume across Azure’s entire network infrastructure. Basic DDoS Protection applies to both IPv4 and IPv6 public IP addresses. With the Basic tier, you have no logging or reporting of any DDoS mitigation, and there’s no way to configure alerts so that you’re notified if a problem is detected. However, the Basic tier is free and provides basic protection.

• Standard The DDoS Standard tier offers protection from volume-based DDoS attacks, and when it’s used in combination with Azure Application Gateway, it also provides protection from attacks designed to target the security of your applications. It offers logging and alerting of DDoS events and mitigations, and if you need help during a DDoS attack, Microsoft provides access to experts who can help you. The DDoS Standard tier applies only to IPv6 public IP addresses. The Standard tier is targeted at enterprise customers and is billed at $2,994 per month, plus a small fee per gigabyte for data that is processed. The fixed monthly price covers up to 100 resources. If you need to cover additional resources, you pay an additional $30 per resource, per month.

To enable the DDoS Standard tier, click DDoS Protection in your virtual network in the Azure portal and select Standard, as shown in Figure 4-37.

To enable Standard tier, you’ll need a DDoS Protection plan. If you don’t currently have one, click Create A DDoS Protection Plan to create one in the Azure portal. You can then apply that DDoS Protection plan to your virtual network and to other virtual networks that you have access to in Azure. Virtual networks that use the DDoS Protection plan aren’t required to be in the same subscription, so in most cases, an organization will only need a single DDoS Protection plan to protect all its virtual networks.

DDoS Protection Standard tier monitors your network traffic 24/7, and it uses machine learning to profile your traffic over time and adjust itself to accommodate your network’s traffic profile. During a DDoS event, Standard tier allows you to stream logs to an SIEM system. SIEM systems are designed to allow for the aggregation of data from a large number of sources for the purpose of analysis and to comply with data retention policies and standards.

Once you’ve configured any alerts and monitoring for DDoS Protection, you can simulate a DDoS event using a BreakingPoint Cloud account available at: https://www.ixiacom.com/products/breakingpoint-cloud. This allows you to ensure that your DDoS Protection is protecting you from DDoS attacks.