Cloud

6/21/2018
02:30 PM
Jason McKay
Jason McKay
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Templates: The Most Powerful (And Underrated) Infrastructure Security Tool

If your team is manually building cloud instances and networks for every application, you're setting yourself up for a data breach.

Forty-eight percent of companies have experienced application downtime, and 20% of companies have experienced a security breach resulting from errors during a manual security-related process. In other words, someone fat-fingered a network or server configuration, or forgot to install a web application firewall on one of thousands of servers. As a result, systems were hacked.

In the cloud, your risk of manual misconfiguration is greater than ever. Your IT team is asked to launch new cloud instances more frequently, on tighter deadlines, and for a wider variety of applications. If they're building a new cloud network for every new application manually, each network will be a snowflake.

The good news is that you no longer need to manually configure cloud environments. If networks and load balancers can be created from the command line, then you can write a program that creates your "ideal" infrastructure stack, complete with networks, security groups (firewalls), server sizes, bandwidth, etc., all with code. This code – usually written in JSON using a templating tool such as AWS CloudFormation, Azure Resource Manager, or a third-party tool like Terraform – is what people mean when they talk about "infrastructure-as-code."

It doesn't matter whether you have legacy applications, custom configurations, or significant technical debt. You, too, can (and must) use cloud infrastructure templates.

Let's Write Some JSON
An infrastructure template is a very simple concept. You tell the cloud platform what you want the environment to look like (in JSON), and the platform takes care of performing the manual actions of provisioning those services. Hand-coding JSON is not a pleasant experience, but it's not complicated. And you can get a head start with prebuilt templates.

In an ideal world, your systems engineers create these templates and then version-control them, either in a GitHub repository or using a tool like AWS Service Catalog. You're not just using these templates to build out an environment once; rather than manually changing your environment, your engineers will change the template and relaunch the entire stack. That means your template is always a true reflection of the configuration of your live systems. Security professionals love this, and your auditors will, too.

Another of the many benefits of this process is that it's easier for security teams to get involved early in the system architecture process, rather than a lengthy review period after build-out. Instead of reviewing test, development, and production environments in a live system, they can review the templates to ensure that all systems built from this template have MFA installed, encrypted volumes attached, and log shipping and hostnames properly configured. For true DevSecOps teams – where security is integrated into application development rather than as a last-minute review – this is critical.

Lessons Learned from Real Teams
Unfortunately, it’s almost always faster to make a quick manual change in the console than to change your template. Wasn't the point of infrastructure-as-code to move faster? Will your developers get mad when it takes an hour to make a change versus two minutes?

In the long term, you're sacrificing a little bit of speed and flexibility for consistency. But there are some speed benefits, too. If you ever want to spin up a test or dev environment that's an exact replica of production, you can do it instantly. Want to test a new product? Your engineers can create an ideal, secure "test" environment, and you can spin it up and down multiple times a day. In order for your IT team to get on board with templates, they need to understand that the benefits of templates outweigh the administrative overhead.

Another common issue is how to organize multiple templates. The answer is to organize multiple "sub-stacks" rather than having a single, global template. Create separate templates by environment type (one for QA, one for Stage, etc.) or by service (one for networks, one for access controls, one for compute instances, etc.). Modular templates mean that it's easier to make a small change without having to affect an entire stack.

The final – and perhaps most painful – limitation of AWS CloudFormation and Azure Resource Manager is that JSON is not a real programming language; you can’t have dynamic variables. That's why these tools are rapidly being replaced by ones that can dynamically generate in JSON using a proper programming language. Examples include Troposphere, cfndsl, and many others. A quick search on GitHub will bring up many projects that generate CloudFormation in a variety of languages, including Ruby, Python, JavaScript, Java, and even Scala. In a few years, we will look back and remember the time we had to hand-code a ton of JSON.

Of course, you can also skip over the AWS CloudFormation or Azure Resource Manager entirely and use an open source tool such as Terraform, which interacts directly with the cloud resources.

Next Step: Infrastructure-as-an-Application
As we add multiple layers of abstraction on top of networking, compute, and storage, we're beginning to treat our infrastructure more and more like an application. Just as the website you're reading now has gone from handwritten HTML to a dynamically generated, flexible web application, infrastructure is following the same evolutionary path.

Infrastructure-as-code is an exciting field where new tools are constantly being developed. Take the time to experiment. Your engineers – and your security team – will thank you.

Related Content:

Why Cybercriminals Attack: A DARK READING VIRTUAL EVENT Wednesday, June 27. Industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Go here for more information on this free event.

Jason is responsible for leading Logicworks' technical strategy including its software and DevOps product roadmap. In this capacity, he works directly with Logicworks' senior engineers and developers, technology vendors and partners, and R&D team to ensure that Logicworks ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Devastating Cyberattack on Email Provider Destroys 18 Years of Data
Jai Vijayan, Freelance writer,  2/12/2019
Up to 100,000 Reported Affected in Landmark White Data Breach
Kelly Sheridan, Staff Editor, Dark Reading,  2/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8354
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.
CVE-2019-8355
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.
CVE-2019-8356
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.
CVE-2019-8357
PUBLISHED: 2019-02-15
An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.
CVE-2013-2516
PUBLISHED: 2019-02-15
Vulnerability in FileUtils v0.7, Ruby Gem Fileutils <= v0.7 Command Injection vulnerability in user supplied url variable that is passed to the shell.