EC Cloud
Be Future ready with Security by Design - Extreme Compute
18 Nov 2020
Security is Mandatory for All Companies
If you put your customers or users at risk, you won’t be in business for long. That starts with a more proactive approach to infrastructure security — one that does not rely on typical third-party security tools or reactive ones, but builds security into 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 Approach
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 into every part of the IT management process. Practically, this means that engineers spend time developing software that controls your system’s security in a consistent manner 24×7 instead of 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 actively promoted and formalized this approach for the cloud audience. Many vendors promote similar or related concepts, often referred to as Secure DevOps, Security Automation, Security-as-Code, or SecOps. Practice becomes more important as your environment becomes more complex, and vendors provide many native services that, if configured and orchestrated correctly, create a system more secure than a manually configured on-site environment.
Does This Replace Security Professionals?
Not at all. When security professionals adopt this approach, they have a far greater impact than before. This is an opportunity for security experts to introduce security earlier in the development process. Rather than retroactively implementing security policies—and always being behind—they can participate in architecture planning from Day 1, encode specifications into templates, and ensure desired configurations are implemented consistently. They only need to be consulted when infrastructure templates change significantly. This means less repetitive busy-work and more focus on real security issues.
Compliance + Design Security
The SbD approach has significant positive impacts on compliance efforts. Maintaining compliance over time is often the hardest part—not setting up or configuring tools. In the old world, systems rarely changed with long lead times, and GRC teams could spend 2-3 weeks evaluating and documenting changes manually. In the cloud, with weekly code pushes and scalable infrastructure, manual compliance can severely restrict cloud projects, slow DevOps teams, and frustrate 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. This requires a toolchain that:
- Makes it easier to build compliant environments;
- Provides security guards to prevent engineers/developers from deploying resources outside compliance parameters;
- Provides ongoing documentation of all changes.
The toolchains already described—templates, configuration management, monitoring—allow us to launch new compliant environments trivially, ensure very limited access, and fully document changes. Together, this reduces the risk of undocumented configuration changes, errors, or insufficient knowledge of where sensitive data resides, significantly reducing the risk of non-compliance.
When systems are complex, equally powerful management tools and processes must enforce and maintain configurations. Continuous compliance is only possible if you use infrastructure as code. If your infrastructure is programmable, security and compliance parameters are just code: they can be versioned in Git, changed flexibly, and automated to auto-correct errors.