New capabilities in Azure Firewall

Azure Firewall has a new “Threat intelligence based filtering”

Microsoft has a rich signal of both internal threat intelligence data, as well as third party sourced data. Our vast team of data scientists and cybersecurity experts are constantly mining this data to create a high confidence list of known malicious IP addresses and domains. Azure firewall can now be configured to alert and deny traffic to and from known malicious IP addresses and domains in near real-time. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed. The Microsoft Intelligent Security Graph powers Microsoft Threat Intelligence and provides security in multiple Microsoft products and services, including Azure Security Center and Azure Sentinel.

Threat intelligence-based filtering is default-enabled in alert mode for all Azure Firewall deployments, providing logging of all matching indicators. Customers can adjust behavior to alert and deny.

Managing your firewall

Logging analysis of threat data and actionable insights are all crucial and central themes to planning, building, and operating applications and infrastructure.

Azure Firewall provides full integration with Azure Monitor. Logs can be sent to Log Analytics, Storage, and Event Hubs.  Azure Log Analytics allows for the creation of rich dashboards and visualization. Along with custom data queries this powerful integration provides a common place for all your logging needs, with vast options to customize the way you consume your data. Customers can send data from Azure Monitor to SIEM systems such as Splunk, ArcSight and similar third party offerings.

Advertisements

Multi Resource Metric Alerts

Ignoring the slightly boring title this is actually quite an exiting new and welcomed feature.

Up until now unless you were using complex queries and Azure log analytics you would have to setup alerts (Metrics, locks…) On a per resource base.

This was both a long and tedious job and not very useful in dynamic environments where new resources are constantly being deployed.

The new Multi Resource alerts allow you to now configure a single metric rule that monitors:

  • A list of virtual machines in one Azure region
  • All virtual machines in one or more resource groups in one Azure region
  • All virtual machines in a subscription in one Azure region

All this allowing you to manage fewer rules and automatically monitor newly deployed resources.

The Benefits of this our outstanding.

  • Get alerting coverage faster: With a small number of rules, you can monitor all the virtual machines in your subscription. Multi-resource rules set at subscription or resource group level can automatically monitor new virtual machines deployed to the same resource group/subscription (in the same Azure region). Once you have such a rule created, you can deploy hundreds of virtual machines all monitored from day one without any additional effort.
  • Much smaller number of rules to manage: You no longer need to have a metric alert for every resource that you want to monitor.
  • You still get resource level notifications: You still get granular notifications per impacted resource, so you always have the information you need to diagnose issues.
  • Even simpler at scale experience: Using Dynamic Thresholds along with multi-resource metric alerts, you can monitor each virtual machine without the need to manually identify and set thresholds that fit all the selected resources. Dynamic condition type applies tailored thresholds based on advanced machine learning (ML) capabilities that learn metrics’ historical behavior, as well as identifies patterns and anomalies.

You can read the official blog here

Azure, AWS & GCP Global Networking Performance Compared

Just came across this very interesting article comparing the three big clouds on global network performance.

https://www.networkworld.com/article/3319776/cloud-computing/the-network-matters-for-public-cloud-performance.html 

Some of the main points being

  • AWS relies mostly on public internet
  • GCP lack connectivity between Europe & India
  • Within Asia, AWS network performance was 56 percent less stable than Azure
  • When connecting Europe to Singapore, Azure was 1.5 times faster than AWS and GCP

These are some pretty strong points for Azure, when dealing with global customers who require a multi-region cloud based approach. But read the full article, it makes for an interesting read. 


DDoS Attack Analytics and rapid response

Another new announcement during Microsoft Ignite (2018) was additional features being added to the DDoS standard tier (the paid tier).

Azure offers two levels of DDoS protection.

  1. DDoS Basic protection built in at no cost.
  2. DDoS standard protection, a paid tier with AI and fine tuning to your environment. 

The newly added features to DDoS Standard are DDoS Attack Analytics & DDoS rapid response.

  • DDos Attack Analytics
    provides attack insights that can be used for compliance, security audits and post attack analysis to optimize defense strategies and security operations
  • DDoS rapid response
    enables customers to engage DDoS experts during an active attack for specialized support.

As part of the Attack Analytics customers will have Attack Mitigation reports. Once enabled the logs can be analyzed using Log Analytics or integrated with a SIEM such as Splunk & Stream Analytics. When under attack data will generated every 5 minutes and when the attack is over a post-mitigation report will be generated for the entire duration of the DDoS attack. 

Both the incremental and post-attack Mitigation Reports include the following fields:

  • Attack vectors
  • Traffic statistics
  • Reason for dropped packets
  • Protocols involved
  • Top 10 source countries or regions
  • Top 10 source ASNs

The second feature of Attack Analytics is Attack Mitigation Flow Logs. The flow logs allow you to review dropped traffic and forwarded traffic in near real-time during a DDoS attack. Again this data can be ingested into SIEM systems.

Flow logs will have the following fields:

  • Source IP
  • Destination IP
  • Source Port
  • Destination port
  • Protocol type
  • Action taken during mitigation

New High Performance Storage in Azure

Well it’s that time of the year again – That’s right Microsoft Ignite!

And the Azure announcements are coming out fast and thick.

One of them being the new Storage options. The fist thing to note is that current existing Standard HDD, Standard SSD and Premium SSD are being upgraded to 32TB capacity, the previous limit being 4TB.

As is the norm the larger SSD disks are also faster, in this case the 32TB disk providing 20,000 IOPS and 750 MB/s of throughput. However for the first time standard HDD disks are also receiving faster speeds with all previous sizes having 500 IOPS and 60 MB/s throughput the new 32TB HDD offers up to 2000 IOPS and up to 500 MB/s throughput.

Another announcement is a new disk type labeled Ultra SSD. This new disk type offers Sub-Millisecond Latency for your most intensive workloads, disk sizes will be up to 64TB with a single 64TB disk providing 160,000 IOPS & 20,000 MB/s throughput. You can of course chain disks together for faster speeds via the OS (software RAID, storage spaces…).

The last new offering is Azure Premium Files, an upgrade to the existing Azure files now based on premium SSD disks.

Also regarding Azure files is the new announcements that Azure file share can now support identity based access using Azure AD domain services, allowing you to have Windows servers joined to Azure AD and user Azure files with full access control and identity management. You can read the full announcement over here.

Azure introduces new Virtual WAN & Firewall – Part II

In my previous post I wrote about the new Azure Virtual WAN, in this post I’m going to talk about the new Azure Firewall. Also in the time between these posts both services have become GA.

So what is the New Azure Virtual Firewall and how does it differ from the existing NSG?

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability.

What this means is that unlike 3rd party marketplace firewalls, there is no requirement to manage infrastructure at any level including scaling an HA. The Firewall is a full service and will scale behind the scenes as required.

Unlike the existing NSG the firewall is a layer 3 device, meaning that it has a public IP and this IP can be used from both inbound and outbound NAT allowing external services to recognize your network based on IP (Previously this could be accomplished using a public load balancer). 

The second thing achievable with the Firewall is FQDN tagging, allowing you to state FQDN’s (and not just IP’s) in your firewall rules.

All Firewall rules can of course be logged and viewed using either (or both) Azure monitor or Azure Log Analytics.

To wrap up, you can now configure an Azure Firewall to protect multiple Vnets (using Peering) and centrally manage all inbound/outbound access of all your Vnets including Nat rules.

Azure introduces new Virtual WAN & Firewall – Part I

Microsoft just announced at Ignite two new amazing network/security related features.

  • Azure Virtual Wan
  • Azure Firewall

In this post I’ll focus on the new Virtual WAN.
First off it’s important to note that this service is currently in preview. You actually have to sign up for this preview and during preview there is no SLA offered for the service.

So enough of that, what can we actually achieve with Azure Virtual WAN?
Basically Virtual Wan is a networking service that allows you to connect you branch office together via Azure.
Aswell as branch office you can of course also add Azure Vnets into the mix.

The idea being that instead of creating dedicated links between all your offices, or delegating you head/HQ office as a hub you utilize Azure as your hub for networking and routing between all of your offices.

Now why would you do this? Well to begin with Azure has over 130 PoPs (points of presence) around the globe meaning that you’ll be connecting to the PoP that is closet to you. Once connected all your traffic will flow over the Azure Global Network and terminate at the SD-WAN hub.  This will allow you to take advantage of Azure’s global network to interconnect all your branch offices and of course you Azure Vnets.

To create connectivity you basically just create a Site To site VPN from your branch office to the closest PoP. Two active tunnels will always be created for redundancy. Once connected automated spoke setup is configured seamlessly for you. Allowing full connectivity between your branch offices while utilizing the Azure global network for lower routing hops resulting in lower latency and faster transfer speeds.

 

You can find the official documentation over here