Cloud security risks: Why you should make apps Secure by Design

More cloud-native web applications are using containers and serverless infrastructure than ever. On the one hand, this is great! You can now run and build applications quickly, without thinking about servers too much. On the other hand, all this added capability also opens up the door to a lot of potential security risks.

In this article, we explain the principles of Secure by Design, and why you should apply them when making your next web application.

The Open Web Application Security Project (OWASP) has published a list of the top 10 cloud-native application security risks. As of 2021, these are, in order of risk:

1. Broken access control
2. Cryptographic failures
3. Injection flaws
4. Insecure design
5. Security misconfigurations
6. Vulnerable and outdated components
7. Identification and authentication failures
8. Software and data integrity failures
9. Security logging and monitoring failures
10. Server-side request forgery (SSRF).

While some items on this list like injection flaws involve malicious output, other security risks are simply the result of administrative misconfiguration. However, many of these risks can be prevented or mitigated with a cloud architecture that is Secure by Design.

Secure by Design (SBD) is a design principle and architectural approach that integrates security at all levels of the architectural design. For cloud architects, this would involve designing a cloud environment with security in mind at the start of the architectural design process. 

Cloud-native web application developers can implement SbD by using the DevSecOps methodology during development and performing security testing early on during the software development lifecycle.

There are 11 core principles of Secure by Design, according to OWASP. These include (but are not limited to) the principle of least privilege, reducing or minimizing the surface attack area, applying “Defense in Depth”, least privilege, separation of duties, open design, and weakest link.

The principle of least privilege is where user privileges are restricted to the minimal amount necessary for that user to perform their role duties.

Reducing or minimizing the attack surface is a core principle based on attack prevention and focuses on removing unnecessary services or components so that they cannot be leveraged for exploitation by an adversary. 

This is also known as “Economy of Mechanism”, or somewhat more colloquially as “Keep It Simple, Stupid.” (KISS).

Applying multiple security controls at multiple levels is a principle known as “defense-in-depth” and presents adversaries with multiple defenses in protection of an asset. 

Requiring authentication to access a cloud asset, encrypting the data-at-rest within that asset, and enabling Data Loss Prevention (DLP) services to prevent data exfiltration from that asset is an example of applying defense-in-depth. Even if an adversary accessed the cloud asset, they would still have to bypass the DLP service and decrypt the data in order to access the confidential data stored on the asset. 

By making sure one person can’t perform everything, the less risk there is of someone being able to act fraudulently. The successful completion of a single task should be dependent on two or more conditions, each of which cannot be performed individually. This is also known as compartmentalization. 

This is making sure that access requests by a subject for an object are completely mediated each time, and not circumvented on subsequent requests.

When designing your app, the security of the mechanism shouldn’t depend on the secrecy of the design or its implementation. If it does, then if these designs are leaked for any reason, your security is in turn compromised.

This is minimizing the amount of mechanisms common to more than one user and depended on by all users. For example, you want to disallow mechanisms that operate at different levels of privilege, as these may be abused to unintentionally compromise security.

The default state should always be secure. For example, unless a subject is given explicit access to an object, it should be denied access to it. This means if there is a failure for whatever reason, the app should remain secure by default.

It’s important that any security functionality is adopted and accepted by the user. If it makes their life more difficult, they’ll look to circumvent it (Like propping open a fire door). Security mechanisms should be easy to use and transparent to provide the best user experience.

As part of the principle of reducing surface area mentioned earlier, you want to reuse existing software components, code, and functionality. This will prevent additional vulnerabilities being introduced

Your app is only as strong as its weakest component, whether that’s your interface, code, or the underlying service. 

If you’re a cloud architect looking for an introduction to SbD and how to apply its core principles to the three major cloud service providers, I suggest starting the course “Security by Design Thinking for Cloud Architects”. This course takes a look at IAM, firewall infrastructure, container security, DevSecOps and applying security on AWS, Azure, and GCP cloud environments.