Azure Solution Security Checklist – thought process
Few months ago, I thought about preparing a security checklist for Azure Solutions as an essential step for the teams designing Azure solutions in order to consciously make security-related decisions and to avoid forgetting critical areas when securing their cloud solutions, which are usually comprising of multiple distributed components.
Why a Checklist?
There were two main reasons that inspired me to start working on this checklist. First, I read an excellent book describing the importance of checklists across many industries called: “The Checklist Manifesto: How to Get Things Right” by Atul Gawande.
The author sheds light on an interesting aspect of how we, as humans, tend to forget and eventually skip the most basic, and sometimes critical, steps in our daily work. In some industries, this could lead to catastrophic consequences. The author also presented several real-world cases, and showed that by using a checklist, as simple as it may sound, it will actually protect us from making these inevitable failures.
The other reason to come up with the security checklist was that I wanted to have a consistent security knowledge among our teams in the company when designing their Azure solutions. That way, the checklist will not only help these teams not to miss the main security controls in their design, but it will also create awareness for them over the different security controls available in Azure solutions, this in turn will instigate the right questions prior to the design.
Setting Azure Security Checklist Main Goals
Before heading to the checklist structure, first, I needed so set what is to be expected from this checklist, so that it can live up to its main purpose and can become truly beneficial.
I set the following goals for the checklist, as guidelines for structuring it.
- The checklist should provide a comprehensive set of key Azure security controls
- The checklist should have a good coverage at different security levels
- The checklist should accommodate for different solutions contexts
- The security controls should be fine-grained enough to be useful
- The security controls should be coarse-grained enough not to be overwhelming
- The selected Action for a security control should clearly represent a decision
- The justification for the selected Action should be a brief statement (for example: one sentence)
- The checklist should be regularly updated with newly-introduced/deprecated Azure services or features
- The checklist should be regularly enhanced based on the teams feedback
There are few points worth explaining in the aforementioned goals.
Checklist right granularity level
The most challenging part in the structuring the checklist was the level of granularity of the checklist items. The checklist needs to be comprehensive to be useful, but this should be applied at the right granularity level.
That is, getting too much granular into each and every service along with each and every possible security feature available on Azure would be impractical for teams to use, which will probably lead them to abandon the checklist altogether. On the other hand, if the checklist is too abstract, it would render it useless.
Furthermore, I decided to create the security checklist only for Azure rather than having a general-purpose security checklist for all possible platforms, as this would have led the checklist to inevitably become too abstract to be generic enough for these different platforms.
Clear Actions and their Rationale
The Actions values should be simple (for example: Yes, No, or Not Applicable), therefore it can clearly reflect the decision made without ambiguity.
The Actions it should accommodate for different solution contexts, for instance, one solution solutions might require customer-managed keys for the data encryption at rest in a storage account, while for another solution, data encrypted with Microsoft-managed keys might suffice.
The ‘Not Applicable’ value is used to be able to group multiple services under one category, as not all Azure services will have the same security control features. This helps in the setting a higher level and practical grouping of services in the checklist.
Capturing Security Decision Records
The checklist actions also acts as historical records for the selected security controls and the brief rationale statement behind these decisions, which is greatly beneficial when you start documenting your design, in which you can expand on these decisions and the rationale behind them.
The checklist also captures the security controls you didn’t select and why, which can be included in the documentations as previously assessed and rejected alternatives.
Keeping the Checklist updated
In order for the checklist to remain useful, it should regularly be revised based on the continuous changes in Azure services and the security features, and also based on the feedback from the teams using it.
Azure Security Checklist Structure
Guided by the aforementioned checklist goals, I had the following main categories (first-level) for the checklist structure:
Now, let’s look at the sub categories (second-level) for the checklist main categories:
- Identity Provider
- Azure AD main security features
- Network and Firewalls
- Network
- Firewalls
- Hybrid Integrations
- Data Stores
- Access Control, Resource protection & Accountability
- Native resource-level firewall
- Data Confidentiality
- Data Integrity
- Resource Certificates/Secrets Protection
- Data Threat Protection & Accountability
- Applications
- Access Control, Resource protection & Accountability
- Native resource-level firewall
- Resource Certificates/Secrets Protection
- Data Confidentiality
- Hybrid Integration Security Options
- Security Operations
- Resource-level Operational Auditing via Activity Logs
- Monitoring resources’ security logs via Azure Monitor
- Security posture management and threat protection via Azure Security Center
- Security Information and Event Management via Azure Sentinel
- Organizational standards & Compliance via Azure Policy
Azure Security Checklist Sample
You can download a sample checklist which is based on the proposed structure and the aforementioned guidelines. Please note that it is far from being a mature Azure security checklist.
Azure_Security_Checklist_V0.4.xlsx
Final Thoughts
In this article, I explained the thought process for constructing an Azure security checklist that would help teams designing Azure solutions to practically leverage the required security controls to enhance the security posture for these solutions.
I would love to hear your feedback, you can drop me a message with your thoughts about the checklist scope, structure, security control items, and the selected level of granularity of these controls. We can also have a call, over a cup of coffee.