How to Create a Security Baseline for a Cloud Resource?

Writing a security baseline is about providing major information for stakeholder consumers on configuring the service using their provider of choice (Azure Console/Portal).  

For example, let’s say you open an Application Gateway load balancer in the Azure Portal.   

At the time of creation, you will be prompted to provide information regarding your Azure subscription type, what resource group it is in, the network details it ought to be associated with, the ports that are opened or closed, and the related tags for integration, and so on. The choices you make in configuring that service should be made in compliance with security guidelines based on your cybersecurity control framework (like CCM, the CSA Cloud Control Matrix).  

There are a lot of considerations to be made here to comply with accepted standards. How do you ensure that you’ve done the right thing?  

Well, once the baseline is written for an Azure service, your stakeholder would have teams that review the baseline. A team structure could involve groups like an Enterprise Architect Team, a Security Team, and a CloudOps Team.  

Enterprise Architects would verify whether the architecture of the service is in place or not.  

The Security Team would verify whether security standards (varied per organization) are in place or not.  

CloudOps would verify whether the actual operation of the service is in place or not.  

Next, once the service is reviewed and approved by your stakeholder, Enterprise Architects, Security, and CloudOps, you can begin provisioning resources.  

Terraform is a popular tool, along with its solution browser, Terraform Registry, for automatically provisioning the resources specified by your baseline document. It can also be used for testing.  

Once your Terraform build is tested, you must apply Azure policies for that specific service.   

Some examples of Azure policies include denying public IP access to your service, denying resources that are not tagged to the service, and denying resources that are not created to specifically defined locations as the one that your initial baseline specifies.  

At this point, you’re finally finished, and your Cloud resource has been provisioned concerning your organization’s security documents, maintaining security compliance and ensuring that you are both organizationally sound and safe from unwanted agents.  

Here is a flowchart diagram of the process we’ve detailed above.