The Green Team solves high-risk, systemic security issues for Microsoft Azure
In the past, I’ve spoken at length on the criticality of assuming breaches can and will occur rather than simply seeking to focus solely on preventing breaches from occurring. Dating back to 2009 this security strategy, called Assume Breach, has historically been executed by two core groups in Microsoft: The Red Team (attackers) and the Blue Team (defenders). We now introduce the Green Team (fixers).
In 2016, we continued to evolve Assume Breach and established both the concept as well as the function of Green Teaming in Microsoft Azure. An industry first, the Green Team consists of dedicated resources focusing on remediation and solving classes of high-risk and systemic security vulnerabilities for the azure platform. The Green Team works closely with the Red and Blue Teams to understand what high-risk, systemic security issues exist – specifically focusing in on those that enable or lead to breaches – and by performing root cause analysis identify and address these issues at scale. The team continuously implements the latest best practices to help secure the azure platform and help protect customer data and workloads. To see some of their best practices in action, let’s look at an example of how this team helps protect credentials stored in source code.
Credentials in source is a high-risk and systemic security issue. Red Teams, like real adversaries, find and use leaked credentials (i.e., passwords, API keys, and more), such as those hard-coded in source code, and then use those credentials to easily gain access to systems and/or pivot within a target’s environment.
Unfortunately, all too often developers are tempted to put credentials in source code. While the Green Team developed and contributed to Get Green and Stay Green, security controls to help identify and remediate credentials already in source code, they simultaneously sought a Green-by-Design solution. This would more easily result in developers meeting an internal security requirement to store credentials in Azure Key Vault, so that access to credentials is restricted, monitored, and more easily managed.
Access to Key Vault is based on Azure Active Directory (AD) authentication. A root-cause analysis, performed by the Green Team identified the Green-by-Design solution was eliminating the need for developers to create an Azure AD application, an associated credential, and the code required to acquire a token.
To make the solution simple and easy to deploy, the Green Team collaborated with Visual Studio, Azure CLI, and the Managed Service Identity teams and developed the App Authentication Library. This library uses the developer's identity from Visual Studio/Azure CLI to authenticate to Key Vault during local development scenarios, and when the solution is deployed to Azure, automatically switches to using Managed Service Identity.
Visual Studio Connected Services for Key Vault uses this library. As a result, storing and retrieving credentials from Key Vault is much easier than before. It’s as simple as moving your credentials from your configuration file to Azure Key Vault.
In the past year, the App Authentication library has been downloaded over a million times and the Green Team has received a lot of positive feedback about its simple design and how it helps users be Simply Secure™.
This is just one example of what the Green Team does. Suffice it to say the Green Team continues to contribute to Microsoft’s Assume Breach evolution while striving for Simply Secure. If you are interested in making a big impact on security, please reach out for engineering and program management openings. To learn more about what our other security teams do at Microsoft to help secure the azure platform, watch our latest Microsoft Mechanics video.
Source: Azure Blog Feed