Every second counts when you are under attack. Azure Security Center (ASC) uses advanced analytics and global threat intelligence to detect malicious threats, and the new capabilities empower you to respond quickly. This blog post showcases how an analyst can leverage the Investigation and Log Search capabilities in Azure Security Center to determine whether an alert represents a security breach, and to understand the scope of that breach.
To learn more about the ASC Investigation feature in detail see the article Investigate Incidents and Alerts in Azure Security Center (Preview). Let’s drill into an alert and see what more we can learn using these new features.
Security Center Standard tier users can view a dashboard similar to one pictured below. You can select the Standard tier or the free 90 day trial from the Pricing Tier blade in the Security Center policy. On the below screen click on the Security Alerts graph for a list of alerts. This view will include alerts triggered by Security Center detections as well as integrated alerts from other security solutions. When possible, Security Center combines alerts that are part of chain of an attacker activity into incidents. The three interconnected dots icon highlighted in
Azure Security Center monitors operating system (OS) configurations using a set of 150+ recommended rules for hardening the OS, including rules related to firewalls, auditing, password policies, and more. If a machine is found to have a vulnerable configuration, a security recommendation is generated. Today, we are pleased to preview a new feature that allows you to customize these rules and add additional rules to exactly match your desired Windows configurations.
The new custom security configurations are defined as part of the security policy, and allow you to:
Enable and disable a specific rule. Change the desired setting for an existing rule (e.g. passwords should expire in 60 days instead of 30). Add a new rule based on the supported rule types including registry, audit policy, and security policy.
Note: OS Security Config customization is available for Security Center users in the Standard tier on subscription level only.
To get started, open Security Center, select Security policy, choose a subscription, and “Edit security configurations (preview)” as shown below.
In the “Edit Security Configurations rules” blade, you can download the configuration file (JSON format), edit the rules, upload the modified file, and save to apply your changes. The customized rule
Web applications are increasingly becoming targets of attacks such as cross-site scripting, SQL injection, and application DDoS. While OWASP provides guidance on writing applications that can make them more resistant to such attacks, it requires rigorous maintenance and patching at multiple layers of application topology. Microsoft Web Application Firewall (WAF) and Azure Security Center (ASC) can help secure web applications against such vulnerabilities.
Microsoft WAF is a feature of Azure Application Gateway (layer 7 load balancer) that protects web applications against common web exploits using OWASP core rule sets. Azure Security Center scans Azure resources for vulnerabilities and recommends mitigation steps for those issues. One such vulnerability is the presence of web applications that are not protected by WAF. Currently, Azure Security Center recommends a WAF deployment for public facing IPs that have an associated network security group with open inbound web ports (80 and 443). Azure Security Center offers provisioning of application gateway WAF to an existing Azure resource as well as adding a new resource to an existing web application firewall. By integrating with WAF, Azure Security Center can analyze its logs and surface important security alerts.
In some cases, the security admin may not have resource permissions
How do you go about answering those perplexing questions such as what secure hardware to use? How do I gauge the level of security? How much security do I really need and hence how much premium should I place on secure hardware? We’ve published a new whitepaper to shed light on this subject matter.
In our relentless commitment to securing IoT deployments worldwide, we continue to raise awareness to the true nature of security—that it is a journey and never an endpoint. Challenges emerge, vulnerabilities evolve, and solutions age thereby triggering the need for renewal if you are to maintain a desired level of security.
Securing your deployment as desired comprises planning, architecture, and execution main phases. For IoT, these are further broken down into sub-phases to include design assessment, risk assessment, model assessment, development, and deployment as shown in Figure 1. The decision process at each phase is equally important, the process must take all other phases into consideration for optimal efficacy. This is especially true when choosing the right secure hardware, also known as secure silicon or Hardware Secure Module(HSM), to secure an IoT deployment.
Figure 1: The IoT Security Lifecycle
An industry-wide, hardware-based security vulnerability was disclosed today. Keeping customers secure is always our top priority and we are taking active steps to ensure that no Azure customer is exposed to these vulnerabilities. At the time of this blog post, Microsoft has not received any information to indicate that these vulnerabilities have been used to attack Azure customers.
The majority of Azure infrastructure has already been updated to address this vulnerability. Some aspects of Azure are still being updated and require a reboot of customer VMs for the security update to take effect. Many of you have received notification in recent weeks of a planned maintenance on Azure and have already rebooted your VMs to apply the fix, and no further action by you is required.
With the public disclosure of the security vulnerability today, we are accelerating the planned maintenance timing and will begin automatically rebooting the remaining impacted VMs starting at 3:30pm PST on January 3, 2018. The self-service maintenance window that was available for some customers has now ended, in order to begin this accelerated update.
During this update, we will maintain our SLA commitments of Availability Sets, VM Scale Sets, and Cloud Services. This reduces impact
At Microsoft Ignite, we announced new adaptive applications controls that protect your applications from malware by using whitelisting rules. Today, we are excited to share that these capabilities are available for public preview in Azure Security Center.
Application controls, such as whitelisting, can help limit exposure to malicious and vulnerable applications. Instead of trying to keep pace with rapidly evolving malware and new exploits, application control simply blocks all but known good applications. For purpose-built servers that typically run a fixed set of application, whitelisting can add significant protection. Application control solutions have existed for some time now, but organizations usually find it too complex and hard to manage, especially when unique rules are required per server or group of servers, and in large scale.
Adaptive Application Controls leverages machine learning to analyze the behavior of your Azure virtual machines, create a baseline of applications, group the virtual machines, and recommend and automatically apply the appropriate whitelisting rules. You can view, modify, and receive alerts for these rules in Azure Security Center.
Adaptive application controls are currently available for Windows virtual machines running in Azure (all versions, classic or Azure Resource Manager). To get started, open Security Center and select
This blog post is authored by Dotan Patrich, Senior Software Engineer, Azure Security Center and by Yossi Weizman, Security Software Engineer Intern, Azure Security Center.
Earlier this year, Rob Mead wrote a great article on the techniques used at scale by Azure Security Center to detect threats. In this post, we’ll go into the details on one such example, enabling Azure Security Center to detect usage of backdoor user account creation.
Backdoor user accounts are those accounts that are created by an adversary as part of the attack, to be used later in order to gain access to other resources in the network, open new entry points into the network as well as achieve persistency. MITRE lists the create account tactic as part of the credentials access intent of stage and lists several toolkits that uses this technique.
While it might seem at first glance that detecting such malicious account creation actions is easy, it is not often the case as creation of new accounts are mostly part of a legitimate administrative operation. Therefore, security products usually won’t alert on it as most organizations will have hard time coping with the volume of alerts to be triaged. This makes the
Today we are pleased to announce the release of a new Azure Financial Services Regulated Workloads Blueprint.
The Azure Security and Compliance Blueprint Program provides automated solutions and guidance for rapid deployment of Azure services that meet specific regulatory requirements from weeks to a few hours. The new Financial Services Regulated Workloads Blueprint gives you an automated solution that will help guide you in storing and managing sensitive financial information such as payment data in Azure. The Financial Services Blueprint is designed to help customers meet compliance requirements outlined in the American Institute of Certified Public Accountants (AICPA) SOC 1 and SOC 2 standards, the Payment Card Industry Data Security Standard (PCI DSS) version 3.2, as well as the Federal Financial Institutions Examination Council (FFIEC), and Gramm-Leach-Bliley Act (GLBA).
Using the Financial Services Blueprint, you can deploy and securely configure an Azure SQL Database, a web application protected by security services such as Azure App Service Environment (ASE), the Web Application Firewall (WAF), and Azure Security Center (ASC). Automated templates and reference architectures are provided to help you implement the technical controls required to achieve a trusted and more secure end to end compliant deployment.
The Financial Services
I am pleased to announce the renewal of the Singapore Multi-Tier Could Security (MTCS) Certification Level 3. As part of its commitment to customer satisfaction, Azure has adopted the MTCS standard to meet different cloud user needs for data sensitivity and business criticality. Azure has maintained its MTCS certification for the fourth consecutive year. This year, the scope has increased by 30% catching up with the latest ISO 27001 scope covering the latest data storage and analytics services including Data Lake Store, Data Lake Analytics, SQL Server Stretch Database, Azure Cosmos DB, Azure Container Service, etc.
Developed by the Infocomm Media Development Authority (IMDA) of Singapore, the MTCS Standard 584:2015 is the world’s first cloud security standard that covers three different tiers of security requirements spanning different service types including PaaS, IaaS and SaaS. The standard comprises a total of 535 controls closely mapped to ISO 27001 Information Security Management System (ISMS) standard, covering basic security in Level 1, more stringent governance and tenancy controls in Level 2, and reliability and resiliency for high-impact information systems in Level 3.
The MTCS standard seeks to drive cloud adoption across industries by giving clarity around the security service levels of Cloud Service