As with all fact-based analysis, we need to be able to measure and compare, to take the appropriate action that circumstances dictate. To that end, we must decide on the metrics that we will measure for our security baseline. Obviously, what to measure depends on what resources you have deployed. Here are examples of possible metrics you might want to consider.

How much sensitive data is in your custody? Do you know? This can be broken down into at least two metrics. Firstly, knowing the landscape of your data in relation to your organization's data and privacy policies, you can measure how much data is being correctly classified. Secondly, how is that data protected? How many of your data stores, be they storage accounts or databases, are secure and are encrypted?

How many public-facing apps or web services do you have? How many of these are linked to sensitive data stores?

Record the number of attacks and attempted attacks. Also, try and quantify the intensity of the attack, like, how long did it last? What was the nature of that type of attack?

If you have virtual machines, how many of them have up to date virus protection and correctly configured firewalls? How frequently do you check for new OS and software security patches and install them?

Do you have outstanding security health recommendations? Azure makes quite a good attempt at notifying users of potential security issues, whether that is with dashboards or emailed threat assessments. You should act on these recommendations.

Having decided what to measure, you must then decide when to take action based on that metric, whether that is an absolute number or percentage increase. Here are examples of events that should trigger the adoption of appropriate security baseline policies.

If you are hosting sensitive data in the cloud, then you need a policy that formalizes how that data should be classified and protected against malicious and unforeseen events.

Persistent serious attacks against network infrastructure. A certain percentage of virtual machines don't have all required OS patches and security software installed, or the time they're unprotected exceeds X number of days.

If your company is in a highly security-oriented sector such as banking, medicine or government, you will need a security baseline before deploying to production. A security baseline statement is comprised of three parts. There is a summary of the technical risk it relates to, an explanation of what the policy requires, and an outline of the technical solution or recommendations to address those requirements. 

Security baseline policy statements should be concise and to the point. Each statement definition should include the following pieces of information:

• Technical risk: a summary of the risk this policy will address.
• Policy statement: a clear summary explanation of the policy requirements.
• Technical options: actionable recommendations, specifications, or other guidance that IT teams and developers can use when implementing the policy.

Here are what a couple of security baseline statements might look like. A data encryption statement would be:

• Technical risk: there is a risk of protected data being exposed during storage.
• Policy statement: all protected data must be encrypted when at rest.
• Potential design option: use Azure data-at-rest encryption. Additional controls such as in-account data encryption and control over how storage account settings can be changed should also be considered.

A network isolation policy statement could be:

• Technical risk: connectivity between networks and subnets within networks introduces potential vulnerabilities that can result in data leaks, disruption of mission-critical services.
• Policy statement: network subnets containing protected data must be isolated from any other subnets. Network traffic between protected data subnets is to be audited regularly.
• Potential design option: in Azure, network and subnet isolation is managed through Azure Virtual Networks.