The past decade has seen great change in the application development space – the move to Agile was huge, and the introduction of DevOps. DevSecOps, is of course, the next evolution of that process.
But there’s another concept that’s been steadily growing in popularity for the past 10 years which is much simpler to implement than other major digital transformations (like moving to Agile), and could have great benefits to a burgeoning DevSecOps team.
It’s called infrastructure as code, but what is it, and what can it do?
Not sure what DevSecOps is? Here’s an introduction.
Let’s define infrastructure as code
Infrastructure as code (IaC) is a bit of a magic wand for digital professionals looking to establish new virtual machines. It reduces servers to simple configuration files – that is, config files with human-readable text – which can be uploaded to software such as TerraForm to rapidly produce new virtual machines in your chosen cloud service. In fact, you could theoretically have a new server up and running in as little as 15 minutes using a config file.
Infrastructure as Code (IaC)
Reduces servers to simple config files which can be used to rapidly produce new, secure virtual machines in as little as 15 minutes.
IaC config files as a single source of truth
These files act as a single source of truth for all things related to the configuration of the server. There’s no logging into a console to manually build, configure, change, or check information. It’s all presented there in a readable text format, and this text can be configured right down to the service by service level.
As we explore below, this is going to create a lot of simplicity and consistency for when the DevSecOps teams need to review or debug their apps, especially teams working in highly regulated environments with a lot more complexity.
Why DevSecOps teams need infrastructure as code
In DevSecOps, the goal is to be faster and more efficient without sacrificing quality (perhaps even improving it). These teams must be able to set up multiple environments very rapidly – like development environments, testing, etc. – as well as places to host their apps. Such environments have to be consistent and secure.
This is, essentially, what IaC does for DevSecOps teams – it improves both speed and consistency.
Another key consideration is that it’s very easy to access IaC. Learning how to use it is not difficult, and then implementing it is generally even easier. So, it’s arguably essential in any modern business that is trying to digitally transform; because it’s so useful and so easy to implement relative to other transformations, there’s almost no excuse for not moving to IaC.
Read more: “How to implement digital transformation“
Benefits of IaC for Ops:
- Fast to implement: Thanks to the simplicity of implementation, IaC allows operations teams to spin up new virtual machines very fast – as little as 15 minutes in some cases.
- Less errors: It’s quite easy to rapidly check through a config file for errors. You only really need a couple of team members to check it. With this, there’s less chance that a bug will make it through to implementation without having been spotted, and there’s less chance two servers which were meant to be the same will come out differently.
- Standardization: With IaC you can more easily standardize the creation of servers, thus removing their configuration as a variable for other teams when programming or debugging.
- Track changes: When you keep your IaC files in a secure repository (i.e. git repository), you can keep track of what versions are running at what time. For example, six months ago you know that this service was on V3.2, then three weeks later you changed to another service running V12.1. It’s treated as any other cold file, the only difference being this code is your infrastructure.
- No login required: If the server’s configuration is accessible in a simple config file, it means different Ops members don’t require login access to the console in order to check settings. They just open the file, and whatever’s running should be right there in the file.
Benefits of IaC for Dev
- Rule out server issues: Much like for the Ops team, when developers are trying to figure out if a server is causing problems with their new app they don’t require console login access and, therefore, an Ops person for assistance. They can open up the same config file and investigate.
- Faster debugging: The ability for Dev teams to quickly understand server configurations can help when debugging applications – enabling them to scan through to look for potential problems and, if necessary, easily test different configurations.
Benefits of IaC for Sec
- All of the above: The same benefits that apply to the Dev team also apply to security teams. There is no need for them to log in to check for, say, unnecessary services. They just have to open the config file. From here, they can quickly inform the Ops team what needs to be switched on or off, patched, and so on.
Note: In order to successfully utilize IaC from a security point of view, your security team members will need to be familiar with reading config files to be able to quickly identify potential problem areas. This may require additional training, or the hiring of personnel with the right expertise.
Important security challenges of infrastructure as code
This all sounds too good to be true, which must mean there’s a catch. Well, as with all things in technology there are security challenges to consider with IaC.
When we reduce the configuration of important virtual machines to a config file, we create a single point of failure. If any outside actors should gain access to this file, they gain access to your servers and every detail of their setup. For anyone, this is a massive red flag – for developers working on extremely sensitive or regulated apps, it’s even more so.
Three strategies to solve this problem
1. Access management
Good access management is the first bulwark against any outside entity gaining access to your sensitive config files.
Access and identity management (IAM) policies that include all the core best practices can maintain a base level of security that works hard to prevent people who shouldn’t be able to touch these files from ever getting near them. Such best practices include:
- A clear joiners, movers, leavers (JML) policy that governs access levels to anyone joining the company, moving within it, or retiring access when they leave.
- Multi-factor authentication, which means even if someone gains the password of an admin they still can’t break into their accounts.
- Only assigning permissions on a temporary basis, so even if you forget to retire someone’s access the system will do it for you at an agreed upon time.
- An auditing process that reviews all of the above on a regular basis, to ensure your IAM policies are always fit for purpose and utilize the best practices of the time.
Download our PDF to learn more: Identity and access management: A guide to best practices
2. Version histories
We mentioned earlier that there is great benefit to storing your config files in a secure git repository. This was so Ops teams could easily review the version histories of everything they are running.
Of course, this has security benefits, too.
When you can easily see who has changed what, when, you can keep an active eye out for tampering, misuse and accidents. This might help you spot criminal activity in your system earlier, understand when criminal activity took place in hindsight (in the event of investigating after a breach), or identify accidental misuse that shows you who in the company requires more training.
In the development of apps, often this repository will be the same as where the project’s code itself is stored.
3. Manage rights to the provisioning application
What’s left, then, from a security challenge point of view, is managing access rights to the provisioning application, i.e. TerraForm.
Again, you don’t want just anyone to be able to access this software and read or implement your config files. Here we would relate you back to our point on access management above – but applying it specifically to TerraForm (or whatever other software you use).
In summary
Infrastructure as code is a relatively simple digital transformation that can greatly improve the day-to-day lives of busy DevSecOps teams. It enables server configuration to be consistent, error-free and easier to check when debugging or hunting security vulnerabilities.
Of course, config files also create a single point of failure, and so they must be protected – kept secure in a safe repository, accessible only by privileged few.
For anyone developing, monitoring or securing apps, IaC is vital. This is especially true for those working with highly sensitive information in regulated environments, where even small errors can be far more critical. Knowing you can produce consistency and quality is one more element of peace of mind when it comes to protecting your data.
Need help setting up your DevSecOps teams? We’re here for you
At dig8ital, we’re experts in determining how individual businesses – and all the unique requirements therein – can make the change to a DevSecOps environment and begin utilizing modern practices such as infrastructure as code.
For a free maturity consultation, contact us today.
