In the first part of our series, we discussed the myths that arise in organizations by having different groups of people with different perspectives on cloud risks. In part two, we’ll be tackling the Processes.
Not without reason, security has been synonymous with either saying no or missing project deadlines. Therefore, during key app-refactoring projects, security must adopt new processes and find the right balance between the compliance needs of security and the business needs of agile sprints.
An Automation Mindset
First, it is imperative for security to embrace automation and put as many security controls as possible directly into the pipelines. Automated security tools (that are accessible via APIs) can provide many security measures like compliance checks, static and dynamic security checks (SAST or DAST), vulnerability scannings, and more. Although they are prone to false positives, they act as the first line of defense.
Secondly, security officers need to be an integral part of the DevOps community by participating, to the extent of their capabilities, in the coding process and in the creation of “Hacker/Abuse stories” (potential hacker scenario simulations.) This way, they have the opportunity to be listened to by the rest of the team and considered as a cooperative resource inside the organization.
Finally, infrastructure changes (also known as merged-requests) are first validated under the 4-eyes principles and then by automatic compliance checks are defined and run in a production (e.g. check that a file bucket is not publicly accessible) that would alert the support department immediately in case of a failed compliance.
The other takeaway implicit in all the 3 points above is that there is a shift in responsibilities from a single person overseeing security to the whole DevOps team, which ultimately really becomes a DevSecOps team at the moment that is in charge of the security stream collectively.
Rapid Risk Assessment
We all know that security ultimately comes down to risks. Without considering corner cases where the risk assessment procedure has become just “ticking a checkbox.” Quite frankly companies these days do not treat risks properly. This is due to several factors, some being that security teams are always understaffed, overwhelmed or simply missing the necessary technical depth/breadth for these projects. In fact, in these circumstances, sometimes it’s easier to run an external pentest or risk assessment, effectively delegating responsibilities outside of the organization, which could have risk implications in and of it themselves.
Instead, it is more advisable to create an even tighter connection between security and DevOps processes by integrating risk assessments inside pipeline processes. In literature and in the field, there are more and more examples of Agile Risk Assessments (see for example the RRA-project in Mozilla), where single DevOps stories are created for each risk after a short assessment (max 30/45 mins) made by two to three people from technical and business backgrounds.
This way not only is there collective ownership of risks by all members of the team but most importantly, visibility and transparency of risks are finally achieved throughout the whole lifecycle of the project (which wasn’t necessarily the case before.)
Even if all the processes described above were done by-the-book, this might still not be enough if security lacks proper management support: as discussed previously, security is indeed dug in tight into DevOps and Business processes, but it must also have a direct link and sponsorship at the Cx level throughout the whole project to highlight potential risks to the board.
Furthermore, security should be greatly incentivized with bonuses and rewards by management to prioritize, for example, critical bug fixes against other Business/App processes. This will increase the spirit from the engineering teams towards security because it’s not a mystery that security is mostly conceived by many departments as a mere extra burden that sits on top of what they already need to do. This way engineers won’t see security solely as a checkbox-tasks dictated from above, but as a real added value to the organization for protecting core assets, businesses and, ultimately, reputation.
This second article focused on a fundamental aspect of public cloud security: processes. It is in these processes where we see the incubation of many breakthrough ideas that – once established – will totally reshape the concept of the current security landscape and potentially lead the way for the DevOps community to transform other IT and business functions of organizations.
In the third and final article, after introducing the key requirements to make the public cloud secure, we will see how the landscape of security tools has changed to adhere to the new cloud-native design principles. Stay tuned for Technology.
He started his career as an academician in cryptology and security before moving into a more practical side of technology across different industry sectors and countries.
- Data Security as a Business Enabler - June 15, 2021
- “Security and Cloud, What Is the Right Recipe?” The Technologies - May 9, 2019
- “Security and Cloud, What Is the Right Recipe?” The Processes - April 23, 2019