So if you needed yet another reason to invest in DevOps, making security easy is a big one. As we’ve seen across the news and across the industry, security is a Big Deal and needs to be taken seriously. But I’ve said it before, and I’ll say it again. Security doesn’t have to be hard. In fact, it can be easy. At least, it can be if you have invested in your infrastructure automation. So this is assuming a couple of things, namely that you have a software-defined data center, with infrastructure-as-code, and you have a CI pipeline and source code control wrapped around said code. If you have these in place, then integrating security becomes much more straightforward. The following tenets, if followed, show how security doesn’t have to be a mysterious black art.

Bring in Security in the Beginning; Treat as Requirements

So although I have a lot of IT experience, my real background is in software. I’ve been developing code specifically for datacenters for almost my whole career. As a software guy, I tend to look at datacenter operations through the lens of a developer, i.e. as requirements to be met and features to be built. And if your datacenter and infrastructure is managed as code then it can be managed as a software product. So in this scenario all you have to do is make sure your security experts are involved from the beginning, and your security capabilities are defined as requirements. For example:

• All systems must perform periodic, automated operating system vendor patching
• All system and application logs must be configured to forward to a centralized logging system

Software developers, from a certain perspective, look at development as simply meeting requirements. Tell them what they need to code, and they’ll go do it. So if you have software developers writing code that constructs your infrastructure environment and systems, then by laying out security-specific requirements and giving the requirements the proper priority, then the developers will make sure that the systems being created are properly hardened and configured for security.

The hard part here, of course, is getting the security people involved from the beginning and ensuring they can communicate those requirements to the infrastructure developers. I’ve met a lot of security people who can point at things and say, “That’s not secure! That doesn’t meet the controls!” but then when you ask, well what can we do to the system to fix that, they can’t really tell you. The solution here is to find talent in both the security and development roles who can communicate and cross-train effectively.

Treat Security as Software Projects

If your systems and infrastructure capabilities are all defined as code and treated as software projects, then you just need to make sure that the proper projects are defined and prioritized to ensure that your security framework is in place. Security isn’t something that will “just happen”, you have to be intentional about it. For example, having the requirement for all your application servers to forward their logs to a centralized logging system for monitoring and SIEM analysis doesn’t work if you don’t have a centralized logging system.

Some example high-value, fundamental projects are:

• Initiate a project to stand up a centralized logging service (i.e. Splunk or ELK)
• Initiate a project to interrogate the environment and ensure all ports, protocols, and services (PPS) are in compliance with your organizational policy
• Initiate a project to construct dashboards to analyze the logs for certain key security-related events

This can sometimes be a hard sell to management that is focused on customer delivery, but you need to invest the time in server projects that are not necessarily end-user-facing products and services. Think of it as a risk reduction activity, like backups. There’s not necessarily a direct customer capability being delivered but the cost of failure can be astronomic.

Automated Security Validation as Part of CI

If your systems and servers are being constructed automatically with scripting and code, then make sure that security validation is built into that code. There are many, many tools available for system scanning and checking for security compliance and vulnerability assessment. Have those tools built into your CI pipelines for when systems are deployed. For example, OpenScap can be used to check whether a system has many various security controls implemented. Put an OpenScap run into your system bootstrap, with reporting and alerting built in to your CI pipeline dashboard. Security issues or vulnerabilities are just as important as failed unit tests or failed system functionality validation, so put those checks in.

Security doesn’t have to be a frustration point for your system administrators. Many times the frustration appears because builders construct an application server, then in order to be approved for deployment a security engineer comes in near the end of the engineering lifecycle and examines the system, only to come back with a huge list of problems. But if you roll your security requirements in from the beginning, and just treat security like any other part of the software development pipeline, then your security needs can be met just like any other capability in your datacenter.