If you put your customers or users at risk, you won't be in business for a long time. And that starts with a more proactive approach to infrastructure security — one that does not rely on typical 3rd party security tools or reactive ones, but builds security in your infrastructure from the ground up.
As your company moves to the cloud, it has a chance to start afresh and rethink who and what is responsible for security in your environment. You also want to be able to integrate security processes into your development pipeline and maintain consistent security configurations while your applications are constantly changing. This has led to the rise of Security by Design.
Security by Design (SbD) is a security approach that allows you to formalize infrastructure design and automate security controls so that you can build security in every part of the IT management process. In practical terms, this means that your engineers spend time developing software that controls your system's security in a consistent manner 24×7 instead of spending time manually building, configuring, and patching individual servers.
This approach to system design is not new, but the rise of the public cloud has made it much easier for SbD to execute. Cloud Service Providers have recently been actively promoting and formalizing the approach to the cloud audience. Many vendors promote similar or related concepts, often referred to as Secure DevOps or Security Automation or Security-as-Code or SecOps. Practice becomes more important as your environment becomes more complex, and vendors actually have many native services that, if configured and orchestrated correctly, create a system that is more secure than a manually configured on-site environment.
Not at all. When security professionals adopt this approach, they have a far greater impact than in the past. In fact, this is an opportunity for security professionals to get what they've always dreamed of: introducing security earlier in the development process. Rather than retroactively implementing security policies— and always being behind — they are part of the architecture planning process from Day 1, they can encode their desired specifications into templates, and they always know that their desired configurations are being implemented. They no longer need to be consulted on each and every change in infrastructure, they only need to be consulted when the infrastructure templates change significantly. That means less repetitive busy-work, more focus on real issues.
As you can imagine, the SbD approach has significant positive impacts on compliance efforts. The hardest thing to do in terms of infrastructure compliance is not to set up and configure security and logging tools, but to maintain those standards over time. In the old world, systems rarely changed with long lead times, and GRC teams could always spend 2-3 weeks evaluating and documenting changes manually (usually in spreadsheets). In the cloud, when code is pushed weekly and infrastructure is scalable, this manual compliance approach can severely restrict the success of cloud projects, slow down DevOps teams, and frustrate both business and IT.
Running cloud applications requires a new approach to compliance. Ideally, we need a system that empowers developers and engineers to work agilely while maintaining safety and compliance standards; we need a toolchain that
a) makes it easier to build compliant environments;
b) provides security guards to prevent engineers / developers from deploying resources outside compliance parameters; and
c) provides on-going documentation.
The toolchains that we have already described— template, configuration management, monitoring — allow us to launch new compliant environments trivially, ensure very limited access to the environment and full documentation of any changes. Together, this means a significantly reduced risk of undocumented configuration change, error or lack of adequate knowledge of where sensitive data resides, and therefore significantly reduced risk of non-compliance.
When systems are complex, an equally powerful set of management tools and processes must be in place to enforce and maintain configurations. Continuous compliance is only possible if you use your infrastructure as a code. If your infrastructure can be programmed, your security and compliance parameters are just a piece of code that can be changed more flexibly, versioned in Git like any piece of software, and automated to auto-correct errors.