AIS is pleased to announce the availability of the NIST SP 800-53 Rev 4 Azure Blueprint Architecture.

(NIST SP 800-53 security controls could be an entire series of blog posts in itself…so if you want to learn more than I cover here, check out NIST’s website.)

The NIST SP 800-53 Rev 4 Azure Blueprint Architecture applies a NIST SP 800-53 Rev 4 compliant architecture with the click of a button to the Azure Government Cloud subscription of your choice. Okay, maybe there are a few clicks with some scripts to prep the environment, but I swear that’s it!  This allows organizations to quickly apply a secure baseline architecture build to their DevOps pipeline. They can also add it to their source control themselves to accompany their application source code. (If you want assistance in implementing this within your greater cloud and/or DevOps journey, AIS can help with our Compliance and Security Services offering.)

DevOpsSec or Secure DevOps is a phrase that has been floating around the blogosphere for some time now. The phrase refers to the attempt to embed your security practices within your DevOps process to enable security at DevOps speed. In the past. it’s been introduced through nebulous processes and proclamations with no real tooling. But with this reference architecture, we created Azure Blueprints. In other words, we’ve attempted to give DevOpsSec some teeth, and some tooling to truly introduce security within your production pipeline.

With malicious data breaches and infectious malware attacks on the rise, the need for highly-secure networking infrastructure is critical, regardless of what level of security your application needs. Not only that, the ability to quickly deploy applications and networking infrastructure that are pre-configured to a specific level of baseline security is extremely valuable. In recent years, the need to do this in a cloud environment has risen into high demand.

[pullquote]Still, deploying a cloud infrastructure that contains several virtual machines, databases, and load balancers etc. was usually a manual process and prone to human error, which led to inconsistent behavior and unexpected results.[/pullquote]Microsoft Azure is one of the leading platforms in the industry that provides a vast collection of integrated cloud services related to analytics, computing, networking, data storage, and much more. Azure also offers a user-friendly web interface called Azure Portal where you can manage individual cloud services. Still, deploying a cloud infrastructure that contains several virtual machines, databases, and load balancers etc., was usually a manual process and prone to human error, which led to inconsistent behavior and unexpected results.

To alleviate the burdens that come along with these potential inconsistencies, Azure offers a feature where you can deploy cloud resources with a JSON (JavaScript Object Notation) template that functions as a deployment configuration file. With nothing but a terminal or a PowerShell session, you can spin up an entire cloud infrastructure with a few commands. This JSON template is basically a large JavaScript object that functions as a deployment template. This template contains several other JavaScript objects that function as either nested deployments or specific cloud resources like virtual machines or databases. Even though you might spend some time creating this initial template, subsequent deployments of that same infrastructure will be much faster — and more consistent — than deploying with Azure Portal alone. Azure calls these templates ARM templates, or Azure Resource Manager Templates.

Azure provides example ARM templates for a variety of different cloud infrastructure patterns. You can check some of them out here.

There is a lot of material available online regarding how to properly create these templates yourself. I’ve provided some links below to help guide you:

Authoring Azure ARM Templates

Best Practices for authoring Azure ARM Templates

Azure ARM Template Functions

Without getting too specific on details surrounding the ARM templates themselves, it is important to understand that these ARM templates allow you to configure individual components of an application network in a variety of ways and combinations.

With the help of these templates, Microsoft was able to develop a product called Azure Blueprints. You can think of Azure Blueprints as a set of ARM templates, PowerShell DSC configuration files, and other configuration scripts strung together in a “one-click” deployment model to give you access to an application network that adheres to a specific level of security that you can choose.

Here at AIS, we developed a blueprint for a notional architecture of a web application with a database backend, similar to the diagram below. The architecture includes a web tier, data tier, Active Directory infrastructure, application gateway and load balancer. Virtual machines deployed to the web and data tiers are configured in an availability set and SQL Servers are configured in an AlwaysOn availability group for high availability. Virtual machines are domain-joined, and Active Directory group policies are used to enforce security and compliance configurations at the operating system level. A management jumpbox (bastion host) provides a secure connection for administrators to access deployed resources.

The solution was constructed by creating a nested hierarchy of ARM templates and custom PowerShell scripts. Each resource in the diagram above has some form of an associated JSON object with configurable parameters tied to it. Some of these parameters allow you to reference other resources or even nest resources inside one of another. For example, we could deploy an ARM template for a Virtual Network, create subnets on that network, and then deploy virtual machines to those subnets.

The majority of our work at AIS was done creating and associating “Extension” resources with each of the virtual machines in the network infrastructure. This “Extension” resource could come in the form of a PowerShell Desired State Configuration (DSC) file or just a regular PowerShell script. With the help of these scripts and files, we were able to configure an entire application system to meet a set of specific NIST 800-53 controls.

For example, take a look at the NIST 800-53 SI-3 control. This control is specifically for protecting a system from malicious code attacks. Within our Azure Blueprint solution, were able to satisfy this requirement by deploying host-based anti-malware protection for all deployed Windows virtual machines using the Microsoft Anti-malware virtual machine extension and a few custom PowerShell scripts. We also configured this extension to perform both real-time and periodic scans (weekly), automatically update both the anti-malware engine and protection signatures, perform automatic remediation actions, and provide notifications through an operational management and diagnostics dashboard.

Custom PowerShell scripts, in addition to DSC configuration files, essentially give us the freedom to assign and customize security restrictions across a set of machines within our network. With the help of these scripts, we were able to apply and configure things like a Group Domain Policy for password and user account information, Anti-Virus / Anti-Malware mechanisms, an application gateway / load balancer, a highly available (always on) SQL system, an internal system clock standard for an entire network, and even a patching schedule where a set of computers can be configured to receive important updates on a consistent basis.

Once you have deployed this secure architecture, you need to validate the security controls are in place and document them. The next steps in our DevOpsSec journey include using the cloud platform (Azure in this case) and scripts for validation and then some open source tools to assist in automating documentation. These topics are too large to tackle here and such we will have to leave them for another post. It is important to add security in your DevOps pipeline early and often because security much like development is an iterative process. Reference architectures like the NIST SP 800-53 Rev 4 Azure Blueprint provide organizations with a secure baseline to add security from the beginning of their process.

Visit our website to find out more about our Microsoft Azure Government Compliance & Security Services, or contact AIS today to get started with Azure Blueprint!