What initially started like a minor Microsoft Teams outage has also taken down multiple Microsoft 365 services with Teams integration, including Exchange Online, Windows 365, and Office Online.
“We’ve received reports of users being unable to access Microsoft Teams or leverage any features,” the company revealed on its official Microsoft 365 Status Twitter account more than 8 hours ago.
Two hours later, Redmond said the issue causing the connection problems was a recent deployment that featured a broken connection to an internal storage service.
However, Teams was not the only product impacted by the outage since users also began reporting failures to connect to various Microsoft 365 services.
Microsoft confirmed the issues saying that the subsequent Microsoft 365 outage only affected services that came with Teams integration.
“We’ve identified downstream impact to multiple Microsoft 365 services with Teams integration, such as Microsoft Word, Office Online and SharePoint Online,” Microsoft explained.
As the company further detailed on its Microsoft 365 Service health status page, affected customers experienced issues with one or more of the following services:
Microsoft Teams (Access, chat, and meetings)
Exchange Online (Delays sending mail)
Microsoft 365 Admin center (Inability to access)
Microsoft Word within multiple services (Inability to load)
Microsoft Forms (Inability to use via Teams)
Microsoft Graph API (Any service relying on this API may be affected)
Office Online (Microsoft Word access issues)
SharePoint Online (Microsoft Word access issues)
Project Online (Inability to access)
PowerPlatform and PowerAutomate (Inability to create an environment with a database)
Autopatches within Microsoft Managed Desktop
Yammer (Impact to Yammer experiments)
Windows 365 (Unable to provision Cloud PCs)
After redirecting traffic to a healthy service to mitigate the impact, Redmond said its telemetry indicates that Microsoft Teams functionality started to recover.
“Service availability has mostly recovered with only a few service features still requiring attention,” Microsoft added on the service health status page and on Twitter two hours ago, at 4 AM EST.
“We’ll continue to monitor the service as new regions enter business hours to ensure the service health does not fluctuate while the remaining actions are completed.”
New survey reveals lack of staff, skills, and resources driving smaller teams to outsource security.
As business begins its return to normalcy (however “normal” may look), CISOs at small and medium-size enterprises (500 – 10,000 employees) were asked to share their cybersecurity challenges and priorities, and their responses were compared the results with those of a similar survey from 2021.
Here are the 5 key things we learned from 200 responses:
1 — Remote Work Has Accelerated the Use of EDR Technologies
In 2021, 52% of CISOs surveyed were relying on endpoint detection and response (EDR) tools. This year that number has leapt to 85%. In contrast, last year 45% were using network detection and response (NDR) tools, while this year just 6% employ NDR. Compared to 2021, double the number of CISOs and their organizations are seeing the value of extended detection and response (XDR) tools, which combine EDR with integrated network signals. This is likely due to the increase in remote work, which is more difficult to secure than when employees work within the company’s network environment.
2 — 90% of CISOs Use an MDR Solution
There is a massive skills gap in the cybersecurity industry, and CISOs are under increasing pressure to recruit internally. Especially in small security teams where additional headcount is not the answer, CISOs are turning to outsourced services to fill the void. In 2021, 47% of CISOs surveyed relied on a Managed Security Services Provider (MSSP), while 53% were using a managed detection and response (MDR) service. This year, just 21% are using an MSSP, and 90% are using MDR.
3 — Overlapping Threat Protection Tools are the #1 Pain Point for Small Teams
The majority (87%) of companies with small security teams struggle to manage and operate their threat protection products. Among these companies, 44% struggle with overlapping capabilities, while 42% struggle to visualize the full picture of an attack when it occurs. These challenges are intrinsically connected, as teams find it difficult to get a single, comprehensive view with multiple tools.
4 — Small Security Teams Are Ignoring More Alerts
Small security teams are giving less attention to their security alerts. Last year 14% of CISOs said they look only at critical alerts, while this year that number jumped to 21%. In addition, organizations are increasingly letting automation take the wheel. Last year, 16% said they ignore automatically remediated alerts, and this year that’s true for 34% of small security teams.
5 — 96% of CISOs Are Planning to Consolidate Security Platforms
Almost all CISOs surveyed have consolidation of security tools on their to-do lists, compared to 61% in 2021. Not only does consolidation reduce the number of alerts – making it easier to prioritize and view all threats – respondents believe it will stop them from missing threats (57%), reduce the need for specific expertise (56%), and make it easier to correlate findings and visualize the risk landscape (46%). XDR technologies have emerged as the preferred method of consolidation, with 63% of CISOs calling it their top choice.
The public anticipation surrounding Windows Autopatch has been building since we announced it in April. Fortunately for all, the wait is over. We are pleased to announce that this service is now generally available for customers with Windows Enterprise E3 and E5 licenses. Microsoft will continue to release updates on the second Tuesday of every month and now Autopatch helps streamline updating operations and create new opportunities for IT pros.
Want to share the excitement? Watch this video to learn how Autopatch can improve security and productivity across your organization:
What Is Autopatch? In case you missed the public preview announcement, Windows Autopatch automates updating of Windows 10/11, Microsoft Edge, and Microsoft 365 software. Essentially, Microsoft engineers use the Windows Update for Business client policies and deployment service tools on your behalf. The service creates testing rings and monitors rollouts-pausing and even rolling back changes where possible.
Windows Autopatch is a service that uses the Windows Update for Business solutions on your behalf.
The Autopatch documentation gets more granular if you want to learn more, and if you have questions, our engineers have created a dedicated community to answer your questions that may be more specific than are covered in our FAQ (which gets updated regularly).
Getting started with Autopatch
To start enrolling devices:
Find the Windows Autopatch entry in the Tenant Administration blade of the Microsoft Endpoint Manager admin center.
Select Tenant enrollment.
Select the check box to agree to the terms and conditions and select Agree.
Select Enroll.
Follow along with this how-to video for more detailed instructions on enrolling devices into the Autopatch service:
Microsoft FastTrack Specialists are also available to help customers with more than 150 eligible licenses work through the Windows Autopatch technical prerequisites described in the documentation. Sign in to https://fasttrack.microsoft.com with a valid Azure ID to learn more and submit a request for assistance, or contact your Microsoft account team.
Working with Autopatch
Once you’ve enrolled devices into Autopatch, the service does most of the work. But through the Autopatch blade in Microsoft Endpoint Manager, you can fine-tune ring membership, access the service health dashboard, generate reports, and file support requests. The reporting capabilities will grow more robust as the service matures. For even more information on how to use Autopatch, see the resources sidebar on the Windows Autopatch community.
Increase confidence with Autopatch
The idea of delegating this kind of responsibility may give some IT administrators pause. Changing systems in any way can cause hesitation-but unpatched software can leave gaps in protection-and by keeping Windows and Microsoft 365 apps updated you get all the value of new features designed to enhance creativity and collaboration.
Because the Autopatch service has such a broad footprint, and pushes updates around the clock, we are able to detect potential issues among an incredibly diverse array of hardware and software configurations. This means that an issue that may have an impact on your portfolio could be detected and resolved before ever reaching your estate. And as the service expands and grows, the ability to detect issues will get more robust.Microsoft invests resources into rigorous testing and validation of our releases. We want to give you the confidence to act. We have a record of 99.6%[1] app compatibility with our updates and an App Assure team that has your back in case you should encounter an application compatibility issue at no additional cost for eligible customers.
In some organizations, where update deployment rings are already in place, and the update process is robust, the appetite for this kind automation may not be as strong. In talking to customers, we’re learning how to evolve the Autopatch service to meet more use cases and deliver more value and are excited for some of the developments which will be announced in the upcoming months in this blog.
What’s ahead for Autopatch
One announcement we can make is that Windows Autopatch will support updating of Windows 365 cloud PCs. We’ll be covering this enhancement in the Windows in the Cloud on July 14th and that special episode will be available on demand on Windows IT Pro YouTube Channel later this month, so be sure to subscribe to the channel for updates.
We love hearing from you, during the past months, we have met with some of you, received feedback in our Windows Autopatch community, and during our ‘Ask Microsoft Anything’ event. We are working hard on addressing asks and improving the service–so please keep sharing feedback.
Please note that we have an evergreen FAQ page here and you can learn more about how Windows Autopatch works in our docs.
Microsoft Mechanics, who have been doing an incredible deep dive into update management, will be talking about Autopatch and endpoint management in a future episode, so be sure to subscribe to their channel, too.
The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.
Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.
The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:
The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:
Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
GCC has the -mindirect-branch, -mfunction-return and -mindirect-branch-register options
LLVM has the -mretpoline option
MSVC has the /Qspectre option
Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.↩
Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am
Microsoft has reminded customers that Windows Server 2012/2012 R2 will reach its extended end-of-support (EOS) date next year, on October 10, 2023.
Released in October 2012, Windows Server 2012 has entered its tenth year of service and has already reached the mainstream end date over three years ago, on October 9, 2018.
Redmond also revealed today that Microsoft SQL Server 2012, the company’s relational database management system, will be retired on July 12, 2022, ten years after its release in May 2012.
Once EOS reached, Microsoft will stop providing technical support and bug fixes for newly discovered issues that may impact the usability or stability of servers running the two products.
“Microsoft recommends customers migrate applications and workloads to Azure to run securely. Azure SQL Managed Instance is fully managed and always updated (PaaS),” the company said.
“Customers can also lift-and-shift to Azure Virtual Machines, including Azure Dedicated Host, Azure VMware Solution, and Azure Stack (Hub, HCI, Edge), to get three additional years of extended security updates at no cost.”
Redmond also reminded admins in July 2021 that Windows Server 2012 and SQL Server 2012 will reach their extended support end dates in two years, urging them to upgrade as soon as possible to avoid compliance and security gaps.
“We understand that SQL Server and Windows Server run many business-critical applications that may take more time to modernize,” Microsoft said.
“Customers that cannot meet the end of support deadline and have Software Assurance or subscription licenses under an enterprise agreement enrollment will have the option to buy Extended Security Updates to get three more years of security updates for SQL Server 2012, and Windows Server 2012 and 2012 R2.”
Regarding the pricing scheme for Extended Security Updates, Microsoft says that they will only cost for on-premises deployments:
In Azure: Customers running SQL Server 2012 and Windows Server 2012 and 2012 R2 in Azure will get Extended Security Updates for free.
On-premises: Customers with active Software Assurance or subscription licenses can purchase Extended Security Updates annually for 75 percent of the license cost of the latest version of SQL Server or Windows Server for the first year, 100 percent of the license cost for the second year, and 125 percent of the license cost for the third year.
SQL Server 2008/R2 and Windows Server 2008/R2 Extended Security Updates (ESUs) will also reach their end support on July 12, 2022, and January 10, 2023, respectively.
Customers who will require additional time to upgrade servers may re-host them on Azure for an additional year of free Extended Security Updates (ESUs).
As the cloud continues to expand into a ubiquitous and highly distributed fabric, a new breed of application is emerging: Modern Connected Applications. We define these new offerings as network-intelligent applications at the edge, powered by 5G, and enabled by programmable interfaces that give developer access to network resources. Along with internet of things (IoT) and real-time AI, 5G is enabling this new app paradigm, unlocking new services and business models for enterprises, while accelerating their network and IT transformation.
At Mobile World Congress this year, Microsoft announced a significant step towards helping enterprises in this journey: Azure Private 5G Core, available as a part of the Azure private multi-access edge compute (MEC) solution. Azure Private 5G Core enables operators and system integrators (SIs) to provide a simple, scalable, and secure deployment of private 4G and 5G networks on small footprint infrastructure, at the enterprise edge.
This blog dives a little deeper into the fundamentals of the service and highlights some extensions that enterprises can leverage to gain more visibility and control over their private network. It also includes a use case of an early deployment of Azure Kubernetes Services (AKS) on an edge platform, leveraged by the Azure Private 5G Core to rapidly deploy such networks.
Building simple, scalable, and secure private networks
Azure Private 5G Core dramatically simplifies the deployment and operation of private networks. With just a few clicks, organizations can deploy a customized set of selectable 5G core functions, radio access network (RAN), and applications on a small edge-compute platform, at thousands of locations. Built-in automation delivers security patches, assures compliance, and performs audits and reporting. Enterprises benefit from a consistent management experience and improved service assurance experience, with all logs and metrics from cloud to edge available for viewing within Azure dashboards.
Enterprises need the highest level of security to connect their mission critical operations. Azure Private 5G Core makes this possible by natively integrating into a broad range of Azure capabilities. With Azure Arc, we provide seamless and secure connectivity from an on-premises edge platform into the Azure cloud. With Azure role-based access control (RBAC), administrators can author policies and define privileges that will allow an application to access all necessary resources. Likewise, users can be given appropriate access to manage all resources in a resource group, such as virtual machines, websites, and subnets. Our Zero Trust security frameworks are integrated from devices to the cloud to keep users and data secure. And our complete, “full-stack” solution (hardware, host and guest operating system, hypervisor, AKS, packet core, IoT Edge Runtime for applications, and more) meets standard Azure privacy and compliance benchmarks in the cloud and on the enterprise edge, meaning that data privacy requirements are adhered to in each geographic region.
Deploying private 5G networks in minutes
Microsoft partner Inventec is a leading design manufacturer of enterprise-class technology solutions like laptops, servers, and wireless communication products. The company has been quick to see the potential benefit in transforming its own world-class manufacturing sites into 5G smart factories to fully utilize the power of AI and IoT.
In a compelling example of rapid private 5G network deployment, Inventec recently installed our Azure private MEC solution in their Taiwan smart factory. It took only 56 minutes to fully deploy the Azure Private 5G Core and connect it to 5G access points that served multiple 5G endpoints—a significant reduction from the months that enterprises have come to expect. Azure Private 5G Core leverages Azure Arc and Azure Kubernetes Service on-prem to provide security and manageability for the entire core network stack. Figures 1 and 2 below show snapshots from the trial.
Figure 1: Screenshot of logs with time stamps showing start and completion of the core network deployment.
Figure 2: Screenshot from the trial showing one access point successfully connected to seven endpoints.
Inventec is developing applications for manufacturing use-cases that leverage private 5G networks and Microsoft’s Azure Private 5G Core. Examples of these high-value MEC use cases include Automatic Optical Inspection (AOI), facial recognition, and security surveillance systems.
Extending enterprise control and visibility from the 5G core
Through close integration with other elements of the Azure private MEC solution, our Azure Private 5G Core essentially acts as an enterprise “control point” for private wireless networks. Through comprehensive APIs, the Azure Private 5G Core can extend visibility into the performance of connected network elements, simplify the provisioning of subscriber identity modules (SIMs) for end devices, secure private wireless deployments, and offer 5G connectivity between cloud services (like IoT Hub) and associated on-premises devices.
Figure 3: Azure Private 5G Core is a central control point for private wireless networks.
Customers, developers, and partners are finding value today with a number of early integrations with both Azure and third-party services that include:
Plug and play RAN: Azure private MEC offers a choice of 4G or 5G Standalone radio access network (RAN) partners that integrate directly with the Azure Private 5G Core. By integrating RAN monitoring with the Azure Private 5G Core, RAN performance can be made visible through the Azure management portal. Our RAN partners are also onboarding their Element Management System (EMS) and Service Management and Orchestrator (SMO) products to Azure, simplifying the deployment processes and have a framework for closed-loop radio performance automation.
Azure Arc managed edge: The Azure Private 5G Core takes advantage of the security and reliability capabilities of Azure Arc-enabled Azure Kubernetes Service running on Azure Stack Edge Pro. These include policy definitions with Azure Policy for Kubernetes, simplified access to AKS clusters for High Availability with Cluster Connect and fine-grained identity and access management with Azure RBAC.
Device and Profile Management: Azure Private 5G Core APIs integrate with SIM management services to securely provision the 5G devices with appropriate profiles. In addition, integration with Azure IoT Hub enables unified management of all connected IoT devices across an enterprise and provides a message hub for IoT telemetry data.
Localized ISV MEC applications: Low-latency MEC applications benefit from running side-by-side with core network functions on the common (Azure private MEC) edge-compute platform. By integrating tightly with the Azure Private 5G Core using Azure Resource Manager APIs, third-party applications can configure network resources and devices. Applications offered by partners are available in, and deployable from the Azure Marketplace.
It’s easy to get started with Azure private MEC
As innovative use cases for private wireless networks continue to develop and industry 4.0 transformation accelerates, we welcome ISVs, platform partners, operators, and SIs to learn more about Azure private MEC.
Application ISVs interested in deploying their industry or horizontal solutions on Azure should begin by onboarding their applications to Azure Marketplace.
Platform partners, operators, and SIs interested in partnering with Microsoft to deploy or integrate with private MEC can get started by reaching out to the Azure private MEC Team.
Microsoft is committed to helping organizations innovate from the cloud, to the edge, and to space—offering the platform and ecosystem strong enough to support the vision and vast potential of 5G. As the cloud continues to expand and a new breed of modern connected apps at the edge emerges, the growth and transformation opportunities for enterprises will be profound. Learn more about how Microsoft is helping developers embrace 5G.
We are excited to share that Azure Web Application Firewall (WAF) policy and Azure DDoS Protection plan management in Microsoft Azure Firewall Manager is now generally available.
With an increasing need to secure cloud deployments through a Zero Trust approach, the ability to manage network security policies and resources in one central place is a key security measure.
Azure Firewall Manager is a central network security policy and route management service that allows administrators and organizations to protect their networks and cloud platforms at a scale, all in one central place.
Azure Web Application Firewall is a cloud-native web application firewall (WAF) service that provides powerful protection for web apps from common hacking techniques such as SQL injection and security vulnerabilities such as cross-site scripting.
Azure DDoS Protection Standard provides enhanced Distributed Denial-of-Service (DDoS) mitigation features to defend against DDoS attacks. It is automatically tuned to protect all public IP addresses in virtual networks. Protection is simple to enable on any new or existing virtual network and does not require any application or resource changes.
By utilizing both WAF policy and DDoS protection in your network, this provides multi-layered protection across all your essential workloads and applications.
WAF policy and DDoS Protection plan management are an addition to Azure Firewall management in Azure Firewall Manager.
Centrally protect your application delivery platforms using WAF policies
In Azure Firewall Manager, you can now manage and protect your Azure Front Door or Application Gateway deployments by associating WAF policies, at scale. This allows you to view all your key deployments in one central place, alongside Azure Firewall deployments and DDoS Protection plans.
Upgrade from WAF configuration to WAF policy
In addition, the platform supports administrators to upgrade from a WAF config to WAF policies for Application Gateways, by selecting the service and Upgrade from WAF configuration. This allows for a more seamless process for migrating to WAF policies, which supports WAF policy settings, managed rulesets, exclusions, and disabled rule-groups.
As a note, all WAF configurations that were previously created in Application Gateway can be done through WAF policy.
Manage DDoS Protection plans for your virtual networks
You can enable DDoS Protection Plan Standard on your virtual networks listed in Azure Firewall Manager, across subscriptions and regions. This allows you to see which virtual networks have Azure Firewall and/or DDoS protection in a single place.
View and create WAF policies and DDoS Protection Plans in Azure Firewall Manager
You can view and create WAF policies and DDoS Protection Plans from the Azure Firewall Manager experience, alongside Azure Firewall policies.
In addition, you can import existing WAF policies to create a new WAF policy, so you do not need to start from scratch if you want to maintain similar settings.
Monitor your overall network security posture
Azure Firewall Manager provides monitoring of your overall network security posture. Here, you can easily see which virtual networks and virtual hubs are protected by Azure Firewall, a third-party security provider, or DDoS Protection Standard. This overview can help you identify and prioritize any security gaps that are in your Azure environment, across subscriptions or for the whole tenant.
Coming soon, you’ll also be able to view your Application Gateway and Azure Front Door monitors, for a full network security overview.
We examine Azure’s Managed Identities service and its security capability in a threat model as developers’ go-to feature for managing secrets and credentials.
Authentication and authorization play crucial parts when securing resources. Authentication verifies that the service or user accessing the secured resources has provided valid credentials, while authorization makes sure that they have sufficient permissions for the request itself.
Broken Access Control is listed among the top 10 OWASP prevalent web application issues from 2017 to 2021, and we have previously written about the importance of secrets management used for authentication. This occurs when an unauthorized user can access, modify, delete, or perform actions within an application or system that is outside the set permissions or policies, malicious or unintended. Broken access control has become the number one concern in the organization’s list, and in this article, we discuss Azure’s Managed Identities service inside the cloud service provider (CSP) to tackle the said web application issue.
Managing system and user identities
Managed Identities for Azure allows users to authenticate certain services available within the CSP. This is done by providing the cloud application a token used for service authentication. We distinguish between two types of managed identities: system-assigned identities and user-assigned identities. To differentiate, system-assigned identities are restricted from one to the resource, which means that different user roles can’t be applied to the same resource. On the other hand, user-managed identities solve this problem and we can imagine them as user roles.
Figure 1. Usage of Managed Identities
For instance, we want to use an Azure storage account within a serverless application for saving our application records. For this purpose, we decided to use a system-managed identity.
This practically means:
Enable managed identities inside a serverless function
Grant serverless functions the necessary permissions for storage account access
Figure 2. Enabling managed identities in a serverless function
After that, we can start using the managed identity for authentication to the storage account. In the following sections, we will look at how the managed identities interface is technically implemented within the serverless environment and the corresponding security implications based on our recent research.
Managing identities in the serverless environment
To make it work, the serverless environment runs a special .NET application process named “dotnet TokenServiceContainer.dll.” This process listens on a localhost and port 8081 to accept HTTP requests. The endpoint for requesting a token is http://localhost:8081/msi/token, and the required parameters specifies that the API version used and resource identifier for which the service requests the token. Optionally, it uses “client_id,” which is a parameter used when a managed user identity token is requested. The request also needs a specific X-IDENTITY-HEADER, and the needed value is present inside IDENTITY_HEADER or an MSI_SECRET environmental variable.
After receiving this token request, the request is delegated to the endpoint within the CSP (another service) and provides the requested token. The endpoint is publicly available and is a part of the *.identity.azure.net subdomain based on the region of the serverless application. By design and public access to the endpoint the service requires authentication, and this is done using a X509 client certificate. This certificate is unique to the specific application ID (meaning the serverless function has a one-to-one pairing of certificate and app ID) and valid for 180 days. If the request is successful, it returns a JSON response with a bearer token valid for one day.
From that perspective, the security standard is high, which is expected from a CSP service. However, there is one hidden danger and that is the certificate itself. The certificate can be leaked by leaking environmental variables.
The Managed Service Identity (MSI) certificate is part of the encrypted container context, which can be accessed inside using a URL-specified CONTAINER_START_CONTEXT_SAS_URI and decrypted using the CONTAINER_ENCRYPTION_KEY variable. Once the certificate is leaked, it can be used to obtain the token outside the scope of CSP services and successfully used for publicly available service endpoints as it would be called from the CSP service.
Threat model and scenario
Figure 4. PoC of getting token using leaked environmental variables from Managed Identity service
At this point, we should emphasize that to be able to abuse the retained token, a certain factor (or malicious actor) must first leak these environmental variables and there must be an assigned role within the requested resource, the pre-requisites being the identities enabled and the role set for the application. This means there are no default roles unless explicitly specified within the CSP settings.
However, as this example of potential compromise shows from a gap leaking environmental variables of a Linux endpoint, using environmental variables for storing sensitive information is not a valid secure approach as they are by default inherited into the child process. Considering that the information is available inside the environment itself and that the certificate contains all the information provided, the endpoint for getting the token now becomes publicly available. A threat actor can get the authentication token outside of the CSP’s service and get all the permissions as the original user.
In this example, the token provider service within the serverless environment is running under a different user. Why is the client certificate available not only for this user in the form of a file with permissions only for that user? This allows a compromised serverless function to leak it and obtain the access token from the external service. But while the unauthorized user can’t get additional privileges other than what the function has, this is enough to conduct activities inside the environment that can have a range of damaging effects. By moving a client certificate into the security boundary of token service user and setting access permissions for the token service user as read-only, we guarantee that even in case of a compromise, the client certificate could not be leaked and used outside the CSP service without additional lateral movement.
The security chain is only as strong as its weakest parts. And while CSP services are not inherently insecure, small design weaknesses put together with improper user configurations could lead to bigger, more damaging consequences. Design applications, environments, and all their related variables with security in mind. If possible, avoid using environmental variables. Following best security practices such as applying the principle of least privilege helps to mitigate the consequences of a breach.
What could the world achieve if we had trust in every digital experience and interaction?
This question has inspired us to think differently about identity and access, and today, we’re announcing our expanded vision for how we will help provide secure access for our connected world.
Microsoft Entra is our new product family that encompasses all of Microsoft’s identity and access capabilities. The Entra family includes Microsoft Azure Active Directory (Azure AD), as well as two new product categories: Cloud Infrastructure Entitlement Management (CIEM) and decentralized identity. The products in the Entra family will help provide secure access to everything for everyone, by providing identity and access management, cloud infrastructure entitlement management, and identity verification.
The need for trust in a hyperconnected world
Technology has transformed our lives in amazing ways. It’s reshaped how we interact with others, how we work, cultivate new skills, engage with brands, and take care of our health. It’s redefined how we do business by creating entirely new ways of serving existing needs while improving the experience, quality, speed, and cost management.
Behind the scenes of all this innovation, millions and millions of connections happen every second between people, machines, apps, and devices so that they can share and access data. These interactions create exciting opportunities for how we engage with technology and with each other—but they also create an ever-expanding attack surface with more and more vulnerabilities for people and data that need to be addressed.
It’s become increasingly important—and challenging—for organizations to address these risks as they advance their digital initiatives. They need to remove barriers to innovation, without the fear of being compromised. They need to instill trust, not only in their digital experiences and services, but in every digital interaction that powers them—every point of access between people, machines, microservices, and things.
Our expanded vision for identity and access
When the world was simpler, controlling digital access was relatively straightforward. It was just a matter of setting up the perimeter and letting only the right people in.
But that’s no longer sustainable. Organizations simply can’t put up gates around everything—their digital estates are growing, changing, and becoming boundaryless. It’s virtually impossible to anticipate and address the unlimited number of access scenarios that can occur across an organization and its supply chain, especially when it includes third-party systems, platforms, applications, and devices outside the organization’s control.
Identity is not just about directories, and access is not just about the network. Security challenges have become much broader, so we need broader solutions. We need to secure access for every customer, partner, and employee—and for every microservice, sensor, network, device, and database.
And doing this needs to be simple. Organizations don’t want to deal with incomplete and disjointed solutions that solve only one part of the problem, work in only a subset of environments, and require duct tape and bubble gum to work together. They need access decisions to be as granular as possible and to automatically adapt based on real-time assessment of risk. And they need this everywhere: on-premises, Azure AD, Amazon Web Services, Google Cloud Platform, apps, websites, devices, and whatever comes next.
This is our expanded vision for identity and access, and we will deliver it with our new product family, Microsoft Entra.
Video description: Vasu Jakkal, Corporate Vice President, Security, Compliance, Identity and Management, and Joy Chik, CVP of Identity, are unveiling Microsoft Entra, our new identity and access product family name, and are discussing the future of modern identity and access security.
Making the vision a reality: Identity as a trust fabric
To make this vision a reality, identity must evolve. Our interconnected world requires a flexible and agile model where people, organizations, apps, and even smart devices could confidently make real-time access decisions. We need to build upon and expand our capabilities to support all the scenarios that our customers are facing.
Moving forward, we’re expanding our identity and access solutions so that they can serve as a trust fabric for the entire digital ecosystem—now and long into the future.
Microsoft Entra will verify all types of identities and secure, manage, and govern their access to any resource. The new Microsoft Entra product family will:
Protect access to any app or resource for any user.
Secure and verify every identity across hybrid and multicloud environments.
Discover and govern permissions in multicloud environments.
Simplify the user experience with real-time intelligent access decisions.
This is an important step towards delivering a comprehensive set of products for identity and access needs, and we’ll continue to expand the Microsoft Entra product family.
“Identity is one of the cornerstones of our cybersecurity for the future.”
—Thomas Mueller-Lynch, Service Owner Lead for Digital Identity, Siemens
Microsoft Entra at a glance
Microsoft Azure AD, our hero identity and access management product, will be part of the Microsoft Entra family, and all its capabilities that our customers know and love, such as Conditional Access and passwordless authentication, remain unchanged. Azure AD External Identities continues to be our identity solution for customers and partners under the Microsoft Entra family.
Additionally, we are adding new solutions and announcing several product innovations as part of the Entra family.
Reduce access risk across clouds
The adoption of multicloud has led to a massive increase in identities, permissions, and resources across public cloud platforms. Most identities are over-provisioned, expanding organizations’ attack surface and increasing the risk of accidental or malicious permission misuse. Without visibility across cloud providers, or tools that provide a consistent experience, it’s become incredibly challenging for identity and security teams to manage permissions and enforce the principle of least privilege across their entire digital estate.
With the acquisition of CloudKnox Security last year, we are now the first major cloud provider to offer a CIEM solution: Microsoft Entra Permissions Management. It provides comprehensive visibility into permissions for all identities (both user and workload), actions, and resources across multicloud infrastructures. Permissions Management helps detect, right-size, and monitor unused and excessive permissions, and mitigates the risk of data breaches by enforcing the principle of least privilege in Microsoft Azure, Amazon Web Services, and Google Cloud Platform. Microsoft Entra Permissions Management will be a standalone offering generally available worldwide this July 2022 and will be also integrated within the Microsoft Defender for Cloud dashboard, extending Defender for Cloud’s protection with CIEM.
Additionally, with the preview of workload identity management in Microsoft Entra, customers can assign and secure identities for any app or service hosted in Azure AD by extending the reach of access control and risk detection capabilities.
Enable secure digital interactions that respect privacy
At Microsoft, we deeply value, protect, and defend privacy, and nowhere is privacy more important than your personal identity. After several years of working alongside the decentralized identity community, we’re proud to announce a new product offering: Microsoft Entra Verified ID, based on decentralized identity standards. Verified ID implements the industry standards that make portable, self-owned identity possible. It represents our commitment to an open, trustworthy, interoperable, and standards-based decentralized identity future for individuals and organizations. Instead of granting broad consent to countless apps and services and spreading identity data across numerous providers, Verified ID allows individuals and organizations to decide what information they share, when they share it, with whom they share it, and—when necessary—take it back.
The potential scenarios for decentralized identity are endless. When we can verify the credentials of an organization in less than a second, we can conduct business-to-business and business-to-customer transactions with greater efficiency and confidence. Conducting background checks becomes faster and more reliable when individuals can digitally store and share their education and certification credentials. Managing our health becomes less stressful when both doctor and patient can verify each other’s identity and trust that their interactions are private and secure. Microsoft Entra Verified ID will be generally available in early August 2022.
“We thought, ‘Wouldn’t it be fantastic to take a world-leading technology like Microsoft Entra and implement Verified ID for employees in our own office environment?’ We easily identified business opportunities where it would help us work more efficiently.”
Next, let’s focus on Identity Governance for employees and partners. It’s an enormous challenge for IT and security teams to provision new users and guest accounts and manage their access rights manually. This can have a negative impact on both IT and individual productivity. New employees often experience a slow ramp-up to full effectiveness while they wait for the access required for their jobs. Similar delays in granting necessary access to guest users undermine a smoothly functioning supply chain. Then, without formal or automated processes for reprovisioning or deactivating people’s accounts, their access rights may remain in place when they change roles or exit the organization.
Identity Governance addresses this with identity lifecycle management, which simplifies the processes for onboarding and offboarding users. Lifecycle workflows automate assigning and managing access rights, and monitoring and tracking access, as user attributes change. Lifecycle workflows in Identity Governance will enter public preview this July 2022.
“We were so reactive for so long with old technology, it was a struggle. [With Azure AD Identity Governance] we’re finally able to be proactive, and we can field some of those complex requests from the business side of our organization.”
—Sally Harrison, Workplace Modernization Consultant, Mississippi Division of Medicaid
Create possibilities, not barriers
Microsoft Entra embodies our vision for what modern secure access should be. Identity should be an entryway into a world of new possibilities, not a blockade restricting access, creating friction, and holding back innovation. We want people to explore, to collaborate, to experiment—not because they are reckless, but because they are fearless.
Visit the Microsoft Entrawebsite to learn more about how Azure AD, Microsoft Entra Permissions Management, and Microsoft Entra Verified ID deliver secure access for our connected world.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
Amplification attacks are one of the most common distributed denial of service (DDoS) attack vectors. These attacks are typically categorized as flooding or volumetric attacks, where the attacker succeeds in generating more traffic than the target can process, resulting in exhausting its resources due to the amount of traffic it receives.
In this blog, we start by surveying the anatomy and landscape of amplification attacks, while providing statistics from Azure on most common attack vectors, volumes, and distribution. We then describe some of the countermeasures taken in Azure to mitigate amplification attacks.
DDoS amplification attacks, what are they?
Reflection attacks involve three parties: an attacker, a reflector, and a target. The attacker spoofs the IP address of the target to send a request to a reflector (e.g., open server, middlebox) that responds to the target, a virtual machine (VM) in this case. For the attack to be amplified the response should be larger than the request, resulting in a reflected amplification attack. The attacker’s motivation is to create the largest reflection out of the smallest requests. Attackers achieve this goal by finding many reflectors and crafting the requests that result in the highest amplification.
Figure 1. Reflected amplification attack
The root cause for reflected amplification attacks is that an attacker can force reflectors to respond to targets by spoofing the source IP address. If spoofing was not possible, this attack vector would be mitigated. Lots of effort has thus been made on disabling IP source address spoofing, and many organizations prevent spoofing nowadays so that attackers cannot leverage their networks for amplification attacks. Unfortunately, a significant number of organizations still allow source spoofing. The Spoofer project shows that a third of the IPv4 autonomous systems allow or partially allow spoofing.
UDP and TCP amplification attacks
Most attackers utilize UDP to launch amplification attacks since reflection of traffic with spoofed IP source address is possible due to the lack of proper handshake.
While UDP makes it easy to launch reflected amplification attacks, TCP has a 3-way handshake that complicates spoofing attacks. As a result, IP source address spoofing is restricted to the start of the handshake. Although the TCP handshake allows for reflection, it does not allow for easy amplification since TCP SYN+ACK response is not larger than TCP SYN. Moreover, since the TCP SYN+ACK response is sent to the target, the attacker never receives it and can’t learn critical information contained in the TCP SYN+ACK needed to complete the 3-way handshake successfully to continue making requests on behalf of the target.
Figure 2. Reflection attack in TCP
In recent years, however, reflection and amplification attacks based on TCP have started emerging.
Independent research found newer TCP reflected amplification vectors that utilize middleboxes, such as nation-state censorship firewalls and other deep packet inspection devices, to launch volumetric floods. Middleboxes devices may be deployed in asymmetric routing environments, where they only see one side of the TCP connection (e.g., packets from clients to servers). To overcome this asymmetry, such middleboxes often implement non-compliant TCP stack. Attackers take advantage of this misbehavior – they do not need to complete the 3-way handshake. They can generate a sequence of requests that elicit amplified responses from middleboxes and can reach infinite amplification in some cases. The industry has started witnessing these kinds of attacks from censorship and enterprise middle boxes, such as firewalls and IDPS devices, and we expect to see this trend growing as attackers look for more ways to create havoc utilizing DDoS as a primary weapon.
Carpet bombing is another example of a reflected amplification attack. It often utilizes UDP reflection, and in recent years TCP reflection as well. With carpet bombing, instead of focusing the attack on a single or few destinations, the attacker attacks many destinations within a specific subnet or classless inter-domain routing (CIDR) block (for example /22). This will make it more difficult to detect the attack and to mitigate it, since such attacks can fly below prevalent baseline-based detection mechanisms.
Figure 3. Carpet bombing attack
One example of TCP carpet bombing is TCP SYN+ACK reflection, where attacker sends spoofed SYN to a wide range of random or pre-selected reflectors. In this attack, amplification is a result of reflectors that retransmit the TCP SYN+ACK when they do not get a response. The amplification of the TCP SYN+ACK response itself may not be large, and it depends on the number of retransmissions sent by the reflector. In Figure 3, the reflected attack traffic towards each of the target virtual machines (VMs) may not be enough to bring them down, however, collectively, the traffic may well overwhelm the targets’ network.
UDP and TCP amplification attacks in Azure
In Azure, we continuously work to mitigate inbound (from internet to Azure) and outbound (from Azure to internet) amplification attacks. In the last 12 months, we mitigated approximately 175,000 UDP reflected amplification attacks. We monitored more than 10 attack vectors, where the most common ones are NTP with 49,700 attacks, DNS with 42,600 attacks, SSDP with 27,100 attacks, and Memcached with 18,200 attacks. These protocols can demonstrate amplification factors of up to x4,670, x98, x76 and x9,000 respectively.
Figure 4. UDP reflected amplification attacks observed from April 1, 2021, to March 31, 2022
We measured the maximum attack throughput in packets per second for a single attack across all attack vectors. The highest throughput was a 58 million packets per second (pps) SSDP flood in August last year, in a short attack campaign that lasted 20 minutes on a single resource in Azure.
Figure 5. Maximum pps recorded for a single attack observed from April 1, 2021, to March 31, 2022
TCP reflected amplification attacks are becoming more prevalent, with new attack vectors discovered. We encounter these attacks on Azure resources utilizing diverse types of reflectors and attack vectors.
One such example is a TCP reflected amplification attack of TCP SYN+ACK on an Azure resource in Asia. Attack reached 30 million pps and lasted 15 minutes. Attack throughput was not high, however there were approximately 900 reflectors involved, each with retransmissions, resulting in a high pps rate that can bring down the host and other network infrastructure elements.
Figure 6. TCP SYN+ACK amplification attack volume on an Azure resource in Asia
We see many TCP SYN+ACK retransmissions associated with the reflector that doesn’t get the ACK response from the spoofed source. Here is an example of such a retransmission:
The retransmitted packet was sent 60 seconds after the first.
Mitigating amplification attacks in Azure
Reflected amplification attacks are here to stay and pose a serious challenge for the internet community. They continue to evolve and exploit new vulnerabilities in protocols and software implementations to bypass conventional countermeasures. Amplification attacks require collaboration across the industry to minimize their effect. It is not enough to mitigate such attacks at a certain location, with a pinpoint mitigation strategy. It requires intertwining of network and DDoS mitigation capabilities.
Azure’s network is one of the largest on the globe. We combine multiple DDoS strategies across our network and DDoS mitigation pipeline to combat reflected amplification DDOS attacks.
On the network side, we continuously optimize and implement various traffic monitoring, traffic engineering and quality of service (QoS) techniques to block reflected amplification attacks right at the routing infrastructure. We implement these mechanisms at the edge and core of our wide area networks (WAN) network, as well as within the data centers. For inbound traffic (from the Internet), it allows us to mitigate attacks right at the edge of our network. Similarly, outbound attacks (those that originate from within our network) will be blocked right at the data center, without exhausting our WAN and leaving our network.
On top of that, our dedicated DDoS mitigation pipeline continuously evolves to offer advanced mitigation techniques against such attacks. This mitigation pipeline offers another layer of protection, on top of our DDoS networking strategies. Together, these two protection layers provide comprehensive coverage against the largest and most sophisticated reflected amplification attacks.
Since reflected amplification attacks are typically volumetric, it is not only enough to implement advanced mitigation strategies, but also to maintain a highly scalable mitigation pipeline to be able to cope with the largest attacks. Our mitigation pipeline can mitigate more than 60Tbps globally, and we continue to evolve it by adding mitigation capacity across all network layers.
Different attack vectors require different treatment
UDP-based reflected amplification attacks are tracked, monitored, detected, and mitigated for all attack vectors. There are various mitigation techniques to combat these attacks, including anomaly detection across attacked IP addresses, L4 protocols, and tracking of spoofed source IPs. Since UDP reflected amplification attacks often create fragmented packets, we monitor IP fragments to mitigate them successfully.
TCP-based reflected amplification attacks take advantage of poor TCP stack implementations, and large set of reflectors and targets, to launch such attacks. We adopt our mitigation strategies to be able to detect and block attacks from attackers and reflectors. We employ a set of mitigations to address TCP SYN, TCP SYN+ACK, TCP ACK, and other TCP-based attacks. Mitigation combines TCP authentication mechanisms that identify spoofed packets, as well as anomaly detection to block attack traffic when data is appended to TCP packets to trigger amplification with reflectors.
Figure 7. Amplification attack detection
Get started with Azure DDoS Protection to protect against amplification attacks
Azure’s DDoS mitigation platform mitigated the largest ever DDoS attacks in history by employing a globally distributed DDoS protection platform that scales beyond 60Tbps. We ensure our platform and customers’ workloads are always protected against DDoS attacks. To enhance our DDoS posture, we continuously collaborate with other industry players to fight reflected amplification attacks.
Azure customers are protected against Layer 3 and Layer 4 DDoS attacks as part of protecting our infrastructure and cloud platform. However, Azure DDoS Protection Standard provides comprehensive protection for customers by auto-tuning the detection policy to the specific traffic patterns of the protected application. This ensures that whenever there are changes in traffic patterns, such as in the case of flash crowd event, the DDoS policy is automatically updated to reflect those changes for optimal protection. When a reflected amplification attack is launched against a protected application, our detection pipeline detects it automatically based on the auto-tuned policy. The mitigation policy, that is automatically set for customers, without their need to manually configure or change it, includes the needed countermeasures to block reflected amplification attacks.
Protection is simple to enable on any new or existing virtual network and does not require any application or resource changes. Our recently released Azure built-in policies allow for better management of network security compliance by providing great ease of onboarding across all your virtual network resources and configuration of logs.
To strengthen the security posture of applications, Azure’s network security services can work in tandem to secure your workloads, where DDoS protection is one of the tools we provide. Organizations that pursue zero trust architecture can benefit from our services to achieve better protection.
Windows Autopatch is a service that uses the Windows Update for Business solutions on your behalf.
