Why it’s time to make continuous cloud security part of your developer journey

Source: cloudcomputing-news.net

Cloud computing hasn’t always been synonymous with great security. However, despite early fears that it was less secure than data centres, the cloud is now considered a useful – and secure – solution for most critical business functions. While some of its earliest adopters could afford to be somewhat blasé about security, that’s no longer the case. The latest generation of cloud entrants mainly operate in finance and government sectors, meaning that security and compliance are at the very top of their agendas.

This emphasis on cloud security has also been sped up by the series of significant data breaches which have affected consumers in recent years. Security has been thrown into the legal spotlight more than ever before too, particularly after GDPR was introduced in Europe, giving strict regulation for businesses to either comply with or face direct consequences.

But while the development and operations departments of businesses have largely embraced the dynamic world of the cloud, for the security team it presents a whole new set of challenges. They no longer work with controlled environments that they can carefully assess and manage as they did before. Instead, with cloud platforms and application code so tightly integrated, development teams must now incorporate security requirements into their code itself to enforce in the platform.  

As cloud platforms often change daily, the potential risk of a misconfiguration is significant. According to Gartner analysis, by 2020, 80 percent of cloud breaches will be due to customer misconfiguration, mismanaged credentials, or insider theft – not cloud provider vulnerabilities. 

Solutions do now exist that can help the security team with these challenges. These solutions allow them to define their policies (PCI-DSS, CIS, NIST, HIPAA) against the cloud environments and, then, to present them to the development team in a concise way.

Reducing the unnecessary overheads incurred in maintaining security policies can aid an organisation enormously. It lowers the risk of misinterpretation, narrows the margin for human error, and allows the development team to work safely within the guardrails established by the security team. This means that they do not constantly need to be aware of the latest changes on the cloud platform and how they correspond to the written security policies. Free from their security role, they can code without wading through pages of policy.

At my organisation, we faced this exact challenge. We found that the existing tools for multi-cloud environments were poor and that any remediations were lacking. In order to address these gaps, we created a solution named Cloud Security Guardian (CSG) and, now, our workflow follows a clearly-defined pattern:

• Deployment: Stand up a new Azure subscription or AWS account 
• Permission: Create the IAM controls and give them to security teams to allow them to configure CSG in order to inspect the new environment
• Definition: The security team can create or apply the compliance policies that they require the cloud solutions to meet. This can be easily changed as the environment expands or as the compliance requirements evolve
• Building: The development team can now start making their cloud deployments into the environments. For these initial ones, the developers can focus on function as this will be evaluated in real time. 
• Consumption: Query CSG via the API and find out exactly where that new deployment fails to match the security policy. If the deployment matches it perfectly, then you now have the report to prove it.
• Remediation: If there is at least one thing to remediate, the violations can be fixed with another quick call. The corrected template can then be pulled back into the repo or the API can provide the JSON to integrate independently. (Those who like GUIs can review the alerts and remediate from the GUI instead)
• Report: As the project progresses, the reports can be shared with stakeholders. These can prove invaluable when performing risk analysis and will assist with sprint planning because they show which areas should be focused on

For developers, this process provides information throughout the entire integration cycle. It can point out the risks in smoke, make quick remediations in UAT, or provide validation in staging. Once in production, this could then be handed over to the operations team to monitor for manual changes or for configuration drift.

Of course, the security team can use this tool too. It allows them to have an immediate overview of the security of all cloud environments and to keep an eye on short-lived environments in order to assess the risk they may have presented as well. Once the security team can view the system’s entire infrastructure, they can easily see how its components interconnect and identify its weak points. 

When it comes to carrying out company-wide reviews of security practice, it allows the security team to quickly make a report on compliance status at any given point in time. It also provides them with a full audit trail. Every change made to the system can be monitored in real time and alerts can be sent to Slack, Sumo Logic, or email whenever something falls out of compliance. 

Making continuous security part of the cloud lifecycle can benefit a company’s security and development teams in equal proportion. It allows them to operate the cloud environments and to manage their compliance requirements as one joined entity using the methods that best suit each team.