Cloud Autonomy and Security with Guardrails

For over 15 years, the cloud supporting unparalleled scalability, agility, and affordability enables competitive advantage for businesses of all sizes and compartments.

The adoption and migration processes for the theme never stronger, so fast for security, but for the next theme. Occasionally not being a new phenomenon, the lack of a security framework has created many expensive by-products in the form of data breaches. If you look at the year 2020, this is pretty evident.

Although data breaches deliver serious problems that cost millions of companies, they often generate to increase speed in their infrastructure, often to increase speed in their infrastructure and their products, end up leaving safe security time only in final phase of the build/delivery cycle, thus postponing the application of these security policies. Most modern data trends are not new or fantastic hacks. It is typically the result of configurations defined in the identities and/or poorly managed data stores. Developers’ operations without the development lifecycle and malicious operations throughout the development lifecycle

DevSecOps is the model that very well addresses the solution to this bottleneck, but how to deal with security governance and give autonomy for the times, let us talk today about guardrails (safeguards).

Making a quick analogy to reality. When we are driving on a highway, guardrails bring us security to avoid several types of accidents, and of course, gives us autonomy to follow the best path for your trip. That is exactly what we have come to expect from the times that build cloud products and cloud infrastructure for the cloud.

Guardrails are automations that continuously monitor your deployment issues, find deviations from desired baselines, and can even correct them automatically. However, even as cloud-native they can become problematic if they are not planned correctly.

Building good cloud guardrails

?Here are some steps I learned along the way with cloud projects following DevSecOps best practices:

Define the problem: I like to start by defining the business outcome we want and then move on to the technical problem. I used to start with a narrow technical problem to solve, but I found it did not always lead me to the right result. For example, the problem is that we want to stop all access to port twenty-two facing the internet, or the actual result is that we do not want to expose the internet facing admin servers to the open internet and we want to use a guardrail to restrict our corporate IPs acquaintances? In this way, the business will boost the construction and evolution of guardrails. As a suggestion, you can use the OKRs model where the objectives (O) run through the business problems that will be addressed and the key results (KRs) will translate the indicators and the shape of the guardrails.

?Define the scope: Whether it is a multi-cloud, multi-signature, multi-operating system environment, the first step is to determine the scope of guardrail you want, which will also define your technical requirements. A quite simple example deals with isolating network access from non-productive environments to production. At the same time, how can I allow storages to exist (temporarily) to dump a database or production log file to other environments. These are particularly important definitions for the design phase. Also try to group your business contexts by technology stack. This will allow you to insert guardrail usage into multiples increasing the range of benefits while validating that the component has become generic enough for enterprise use.

Build or Choose Deployment Model: The DevSecOps model promotes tight integration between the development, operations, QA, and security worlds. A second benefit of this model comes from the “Shift-Left” where the entire team (squads) bring their perspective in requirements format, enriching the design model and maturing components and products. With that in mind, seek to build delivery models based on pipelines (e.g., linear, blue green, canarian, etc.) and that teams themselves can insert the necessary guardrails for their process. This way, in addition to creating major bottlenecks in the adoption process, it also allows for a healthy level of autonomy once the use of guardrails starts from a development environment.

Determine Triggers: We have a wide range of trigger options on leading cloud platforms today. The main categories are time-based assessments and event-based triggers.

Analyze the collected data and define automatic actions: this is the hard part of the process. Based on the triggers, collect the information we need and, in combination with our scope and filters, make a decision. For example, if we find port twenty-two open to the internet, if it is a Dev environment, we might decide to update the security group to restrict to known corporate IP addresses. If it is in Prod, we can delete the rule completely unless it was implemented through an IaC (Infrastructure as Code) model that went through an approval process. It is important that there is always an automatic action option, which can be performed if the communication model is still slow.

Send notifications: Even when you have fully automated protection, you probably want a parallel notification. They can go straight to email / MSTeams / Slack or enter a ticketing system. For security guardrails, I also recommend uploading them to your SIEM or other security alert/management system. If you like, you can turn this into the first step of a ChatOps process.

Establish distributed governance: Knowledge management and learning have never been more important. We will need a multidisciplinary team that knows the technologies involved and can define the scope and requirements of each guardrail. This can quickly become a bottleneck if you do not distribute the construction and multiplication of this knowledge. Have product team members participate in the construction and help facilitate the adoption of these guardrails.

Conclusion

This is not about building secure software or infrastructure. We are talking about a fantastic (and not easy) journey here to deliver products quickly, continuously, safely, and valuable to your customers.

Many paradigms and silos need to be broken, but the results achieved on a continuous basis will be incredible.

I hope this quick article can motivate you to pursue this transformation.

And feel free to share your experiences and feedback on the topic.

Original posted in portuguese: ?https://www.dhirubhai.net/pulse/autonomia-e-seguran?a-na-nuvem-com-guardrails-diego-gabriel-cardoso/