As part of our recent Microsoft Defender for Cloud Blog Series, we are diving into the different Security Controls within MDC's Secure Score. In this post we will be discussing the “Enable encryption at rest” Security Control.
This Security Control contains up to 3 recommendations, depending on the resources you have deployed in your environment, and it is worth maximum whopping points of 4 (6%) that counts towards your overall Secure Score. These recommendations are meant to keep your resources safe and improve your security hygiene where continuous teamwork must be placed.
Without further delay (and in no particular order), Enable encryption at rest contains one or more of the following 3 recommendations, depending on your environment:
Like the rest of the Security Controls, all these recommendations must be considered in order to get the full points and drive up your Secure Score (you can review all the recommendations here). Also, some might have a Quick Fix! button as well! It simplifies remediation and enables you to quickly increase your secure score and therefor improve your environment’s security.
Category #1: Disk encryption should be applied on virtual machines
When working with production data it is highly recommended to implement encryption in order to protect it from unauthorized access and fulfil compliance requirements for data-at-rest encryption in your organization. Microsoft Defender for Cloud disk encryption monitoring identifies non-compliant virtual machines (VMs) and recommends enabling disk encryption for these VMs in order to enhance data protection.
The way that Microsoft Defender for Cloud disk encryption recommendation (we have support for both native VHD and managed disk solutions) works is:
Azure Disk Encryption for Windows virtual machines (VMs) uses the BitLocker feature of Windows to provide full disk encryption of the OS disk and data disk. Additionally, it provides encryption of the temporary disk when the VolumeType parameter is All.
Make sure to check the list of unsupported scenarios here
Category #2: Transparent Data Encryption on SQL databases should be enabled
As more and more businesses go digital and towards the cloud, security is more important than ever. Transparent Data Encryption is SQL’s form of encryption at rest. It encrypts data files at rest for SQL Server, Azure SQL Database, Azure SQL Data Warehouse, and APS. The term “data at rest” refers to the data, log files, and backups stored in persistent storage. It performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest without requiring changes to the application. TDE performs real-time I/O encryption and decryption of the data at the page level. Each page is decrypted when it's read into memory and then encrypted before being written to disk. TDE encrypts the storage of an entire database by using a symmetric key called the Database Encryption Key (DEK). On database startup, the encrypted DEK is decrypted and then used for decryption and re-encryption of the database files in the SQL Server database engine process. DEK is protected by the TDE protector. TDE protector is either a service-managed certificate (service-managed transparent data encryption) or an asymmetric key stored in Azure Key Vault (customer-managed transparent data encryption).
Turing Off Transparent data encryption will result in decryption of the complete database and will leave your data vulnerable. When Transparent data Encryption is turned off or not configured, Microsoft Defender for Cloud will identify the risk and give you this recommendation. The configuration is a very simple toggle between ON and OFF as shown in Image 2.
This recommendation comes with a Quick Fix option, that helps you ‘turn on’ the data encryption on the unhealthy resources in a single-click. Alternately, you may also refer to our github repository and find various ways (PowerShell, LogicApp, Azure Policy) to resolve the “Enable transparent data encryption on SQL databases” recommendation in Microsoft Defender for Cloud.
Category #3: Automation account variables should be encrypted
Azure Automation is a tool that allows you to automate various processes in Azure using PowerShell, Runbooks and Automation Modules. Account variables in Azure Automation are values available to all runbooks and DSC configurations within your Azure Automation account and they are preserved even when a runbook or DSC configuration fails. Therefore, it is important to protect this information, especially when these values contain sensitive information. When creating variables in Azure Automation, variables containing sensitive data need to be stored as a secure asset. Upon creation, secure assets, which include credentials, certificates and connections are encrypted using a key that is unique to each Automation account and stored in Azure Key Vault until ready for use. Azure Automation secure assets uses two models of encryption. By encrypting your organization’s sensitive information, another barrier of defense is created to protect your organization’s data. The process of encryption converts sensitive information into code that can only be deciphered by someone who has access to the encryption key, making it significantly harder for a third party to also access this information.
Even data-at-rest is at risk of outside attack. Encryption is one approach to preventing the visibility of your data from unauthorized access. The “Enable encryption at rest” Security Control kicks off these efforts within your organization by helping you protect the confidentiality of your data and resources. Try it out and let us know how it goes!
Thanks to Future Kortor, Program Manager, to collaborate in writing Category 3 section.
Thanks to Yuri, Principal Program Manager, for reviewing the article and for his inputs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.