Security posture and compliance validation roadmap for Azure Stack
Security considerations and compliance regulations are important drivers for people that choose to control their infrastructure using private/hybrid clouds while using IaaS and PaaS technologies to modernize their applications. Azure Stack was designed for these scenarios, and as a result, security and compliance are areas of major investment for Azure Stack.
Before starting implementing, we asked our customers what they expect from security for a solution like Azure Stack. Not surprisingly, the majority of the people we talked to told us that they would strongly favor a solution that comes already hardened and with security features specifically designed and validated for that solution. Additionally, people said that compliance paperwork is a top frustration.
We listened.
This post will walk you through the security posture of the Azure Stack infrastructure and how it addresses the feedback we received. It also describes the work that we’ve done to accelerate the compliance certification process and reduce paperwork overhead.
Security posture
The security posture of Azure Stack is designed based on two principles:
Assume breach.
Hardened by default.
Assume breach is the modern approach to security, where the focus extends from not only trying to prevent an intrusion, but to also detect and contain a breach. In other words, we not only included measures to prevent a breach, but we also focused on solid detection capabilities. We built the system so that if one component gets compromised, it does not directly result in the entire system getting taken over.
Because of the elevated set of permissions associated with it, the administrator role is typically the most often attacked. Following the assume breach principle, we created a predefined, constrained administration experience so that if an admin credential is compromised, the attacker can only perform actions for which the system is designed, instead of having unrestricted access to every component in the infrastructure. Doubling down on the same concept, we removed any customer-facing domain admin accounts in Azure Stack. If you want to further break down the admin role, Azure Stack offers very fine-grained, role-based access control (RBAC), allowing for complete control of the capabilities exposed to each role.
The Azure Stack infrastructure is completely sealed both from a permission (there is no account to log into it1) and network point of view, making it very hard for unauthorized users to get in. Network access control lists (ACLs) are applied at multiple levels of the infrastructure, blocking all the unauthorized incoming traffic and all unnecessary communications between infrastructure components. The ACL policy is very simple, block everything unless it is necessary.
To boost detection capabilities, we enabled security and audit logs of each infrastructure component and we centrally store them in a storage account. These logs offer great visibility into the infrastructure and security solutions (e.g. Security Information and Event Management) can be attached to monitor for intrusion.
Since we define the hardware and software configuration of Azure Stack, we were able to harden the infrastructure by design, the hardened-by-default principle. In addition to following industry best practices like the Microsoft SDL, Azure Stack comes with encryption at-rest for both infrastructure and tenant data, and encryption in-transit with TLS 1.2 for infrastructure network, Kerberos-based authentication of infrastructure components, military-level OS security baseline (based on the DISA STIG), automated rotation of internal secrets, disabled legacy protocols (such as NTLM, SMBv1), Secure Boot, UEFI, and TPM 2.0. Additionally, we enabled several Windows Server 2016 security features like Credential Guard (credential protection against Pass-the-Hash attacks), Device Guard (software whitelisting), and Windows Defender (antimalware).
There is no security posture without a solid, continuous servicing process. For this reason, in Azure Stack, we strongly invested in an orchestration engine that can apply patches and updates seamlessly across the entire infrastructure.
Thanks to the tight partnership with the Azure Stack OEM partners, we were also able to extend the same security posture to the OEM-specific components, like the Hardware Lifecycle Host and the software running on top of it. This ensures that Azure Stack has a uniform, solid security posture across the entire infrastructure, on top of which customers can build and secure their application workloads.
To add an additional layer of due diligence, we brought in two external vendors to perform extended penetration testing of the entire integrated system, including the OEM-specific components.
We also understand that our customers will want to protect their Azure Stack deployments with additional 3rd party security software. We are working with some of the major players in the industry to make sure that their software can easily interoperate with Azure Stack. If there is specific security software that you want Azure Stack to work with, please fill out this survey.
Regulatory compliance
Customers told us that compliance paperwork is a major frustration. To alleviate that, Azure Stack is going through a formal assessment with a 3PAO (3rd-Party Assessor Organization). The outcome of this effort will be documentation on how the Azure Stack infrastructure meets the applicable controls from several major compliance standards. Customers will be able to use this documentation to jump-start their certification process. For the first round of assessments, we are targeting the following standards: PCI-DSS and the CSA Cloud Control Matrix. The former addresses the payment card industry while the latter gives comprehensive mapping across multiple standards.
Concurrently, we have also started the process to certify Azure Stack for Common Criteria. Given the length of the process, this certification will be completed sometime early next year.
It is important to clarify that Microsoft will not certify Azure Stack for those standards, except for Common Criteria, because several controls within those standards are the customer’s responsibility, that is, people- and process-related controls. Microsoft is formally validating that Azure Stack meets the applicable controls. As a result of this validation, Microsoft, via the 3PAO, will produce pre-compiled documentation that explains how Azure Stack meets the applicable controls.
In the coming months, Azure Stack will continue to expand the portfolio of standards to validate against. The decision about which standard to prioritize will be based on customer demand. To express your preference about which standard Azure Stack should prioritize, please fill out this survey.
More information
Are you attending Microsoft Ignite this year in Orlando? Do not miss the session on Azure Stack Security and Compliance with our chief architect Jeffrey Snover and myself:
BRK3089 – Microsoft Azure Stack security and compliance
Lastly, the Azure Stack team is extremely customer focused and we are always looking for new customers to talk too. If you are passionate about Hybrid Cloud and want to talk with team building Azure Stack at Ignite please sign up for our customer meetup.
1Except for some predefined privileged operations exposed via a PowerShell JEA endpoint
Quelle: Azure
Published by