This year, Snyk and Cloud Foundry are working together to provide monthly posts focused on helping you stay more secure. This is the second installment. Read the first post here.
There’s a principle of software development called “secure by default,” which states that the default state of any application should be the most secure state. It’s a fantastic idea in theory, but in reality it is rarely true. Most of the time, applications will choose to prioritize usability over security for their default experience.
It makes sense: they want the first time users encounter their system to be as frictionless as possible. There’s also a limit to just how far these services can go: many security considerations require a more granular understanding of the specific application in use. Default configurations can only go so far.
Unfortunately, these security considerations are being overlooked frequently and the results aren’t very pretty. Stories of data breaches resulting from AWS S3 buckets are becoming frighteningly common. Wave after wave of ransomware attacks have taken advantage of an insecure default configuration in older versions of MongoDB.
The frustrating part is these attacks are relatively easy to prevent: one change in a configuration file somewhere and they would have never happened. Organizations need to keep careful track of the security of the solutions they use so they know exactly what the risks are and how to account for them.
There’s a lot of work that can be done to help minimize your risk when using third-party solutions. A good start is to keep three key principles in mind.
1. Assume any service you’re using is starting in an insecure state
Secure by default is a great idea, but as we’ve seen, it’s seldom reality. You should assume that any package or service you’re using is shipping with settings that aren’t as secure as they could be. As you’re choosing services to use, seek out their security documentation.
Specifically, you should be looking to answer questions such as:
- If there is a vulnerability in the system, how is it handled? How will you be made aware and how can you remediate?
- How is data that you store on the service encrypted? Do you need to specifically opt into encryption or is it provided by default?
- What controls does the system provide for you to limit access among different users and organizations?
- What sort of logging and monitoring does the system provide and how do you access that information?
- Does the system enable you to isolate different portions of your applications to limit your exposure?
- What data does the provider collect and how do they handle it on their systems?
Every vendor should have clear documentation about what they are currently doing for security, as well as recommendations for further configuration. The Cloud Foundry documentation is a good example. They clearly state what it is that they do out of the box to help you stay secure. They also provide a nice bulleted list of recommendations for further security enhancements you should consider.
Take whatever recommendations are available from your vendor and view them as checklist items of potential improvements. Each suggestion should be carefully considered so that you are fully aware of the risks if you decide not to follow them.
2. Cloud risk analysis
Speaking of risk, doing a risk assessment of your third-party setup is a critical step in improving your security posture. Third-party solutions provide a lot of value, but they also introduce new attack vectors. It’s critical to have a firm understanding of what could go wrong, so you know what to do to prevent it from happening.
The newly formed OWASP Cloud Security Project is a great place to start. The project’s goal is to provide threat and control stories specifically focused on securing products and services that run in the cloud.
Threat stories describe different risk scenarios from the attacker perspective. They look at how an attacker could take advantage of weaknesses in a system to accomplish anything from information disclosure to more active forms of attack. Here’s an example of a threat story for AWS S3 buckets:
# Id: OCST-1.2.1 # Status: Exploited # Service: AWS S3 # STRIDE: # - Spoofing # Components: # - Bucket versioning # References: # - http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html # - aws/s3/tools/s3bury Feature: Hiding malicious data within object version history In order to avoid detection As an attacker I want to hide malicious files for later use Scenario: Burying files in S3 object history Given an S3 bucket with version history enabled And a principal with the ability to write to the bucket When the attacker uses the s3bury tool for their malicious files Then the latest version of the object still returns the original object And the attacker has a pre-signed and versioned url to download their malicious file
You can see the story contains reference information, the attack scenario, and what the attack would accomplish.
Countering the threat stories are the control stories. Control stories have a defensive focus: they’re concerned with how you would defend or prevent various threats.
Here’s a control story focused on preventing versioning issues like the one described in the threat story above:
# Id: OCSC-1.2.1 # Status: Confirmed # Service: AWS S3 # Components: # - Versioning # Mitigates: # - OCST-1.2.1 @aws @s3 Feature: Malicious data cannot be hidden inside a bucket In order to prevent a spoofing attack An an engineer I want to prevent malicious files from being hidden within an S3 bucket @disabled Scenario: Detecting VersionId usage Given a bucket with versioning enabled And infrequent use of VersionId in GET Object requests When a GET Object request is made with VersionId as a parameter Then an alert should be generated @disabled Scenario: Prevent unauthorized users writing to a bucket Given a bucket And the list of permitted write actions And the list of authorized IAM principals And the list of all IAM entities When we simulate the write actions for each IAM principal Then only the authorized principals should allowed responses
The control story describes the goal (in this case, prevent malicious files from being hidden in an S3 bucket) and specific techniques and tools that should be used to accomplish this goal.
A detailed and well-thought out set of threat and control stories arms your entire team with the knowledge they need to ensure security is baked into the design of your system.
The OWASP Cloud Security Project is young, so there’s a very limited number of threat and control stories in place. They’re actively seeking contributions, however, and the framework works as a great starting point for any organization wanting to ensure the security of their systems.
3. The old rules still apply
We mentioned above that new tools means new attack vectors, but it’s just as important to remember that many of the old rules still apply.
For example, one of the oldest principles of security is the principle of least privilege: users, modules, applications should all be granted the minimum permissions they need to perform their work. The more permissions or access someone has, the better target they make.
Most platforms will attempt to provide at least some level of protection out of the box, but ultimately the configuration will come down to you. For example, Cloud Foundry provides some default isolation for your data and application, but they also provide isolation segments that allow you to limit the access different applications have with each other.
You likely have policies and processes in place to deal with security concerns you’ve been battling for years. It’s important to evaluate each of those against any third-party solutions to see if they apply, and if they do, if any adjustments are necessary.
Using third-party offerings securely
There’s a reason platforms like Cloud Foundry exist—they provide an incredible amount of value to organizations and can be a tremendous boost for productivity and efficiency.
But not all services are created equally. When evaluating these tools, keep a close eye on what security procedures are already in place. If you can’t find dedicated information about how that platform handles security, it’s a good sign you may want to look elsewhere.
And never take your security for granted. There’s a limit to how far these services can go to protect you out of the box. Arm yourself with a firm understanding of what could possibly go wrong, and then seek out the security documentation to see what additional precautions you can take to control those threats.
