In any given week, security researchers discover caches of data on cloud servers that are completely open to the public, usually containing the most sensitive information about a company’s customers. Leaks were found earlier this summer that revealed data coming from Avon as well as from Ancestry.com. This latter leak wasn’t the first breach for Ancestry — it had an earlier 2017 leak here.
In September, another leak at an unsecured container if Digital Point revealed more than 800,000 users’ data. And in Sysdig’s annual container security report published this month, they found more than half of the containers they scanned had root privileges: definitely a no-no! While the survey found that more developers are doing security scans at the beginning of their projects, about half of those surveyed had known security vulnerabilities.
One researcher has made a name for himself with these discoveries — Chris Vickery of Upguard.com. You can see a long list of companies he has found with unsecured online storage that dates back several years. It is worth reading some of his blog entries just to see how frequently this happens. And there are plenty of others who are interested in this area, some of whom are so well-intentioned. There are many hackers trying to exploit these open containers.
The problem is simple to describe and appears — at least at first glance — simple to fix. When you initially set up your online storage, you are asked who has access and what rights are accorded to each user. However, developers have hundreds if not thousands of containers to keep track of, and sometimes they forget to lock all of them down.
Cloud-based storage has been around for more than a decade, and it only continues to get more popular. You can now rent a piece of storage in the sky for pennies a day. And that is their attraction: they are easy and they are cheap. At least until someone finds data that shouldn’t be available to the entire world. Then the cost to fix this mistake can be significant.
There are a series of discovery tools that are used by security researchers to locate these open containers. These all have both web and programmable interfaces that can scour the online world, or be limited to just your own particular domain:
You should try one of them and develop a regular habit of using it to see what it finds.
Your next step should be to try to prevent the open container technology situation from happening at the time they are created by your developers. Your developers should be familiar with ways to segregate groups of users and machines and to set up virtual private networks and virtual firewalls.
The cloud providers themselves are a good place to start with their own tools, including:
Some, such as Azure Security Center, are general-purpose security tools and not specifically designed for containers. Amazon has done the best job in this area and has a series of security-related services for many years, including CloudTrail (which logs its API usage), CloudWatch (which monitors your resource usage), Macie (to discover sensitive data using machine learning techniques), GuardDuty (which is used for threat detection) and Config (that tracks changes to your configuration). And finally, there is Amazon’s Trusted Advisor, which analyzes your environment and makes recommendations on best practices. Again, these are general-purpose security tools, but it is nice to have all of them.
If some of these services aren’t familiar to you, you might want to start by reading the online documentation and to try them out with your Amazon Web Services (AWS) installation. That’s great, and certainly, you can protect many things inside AWS. But what is missing is a more holistic view of your entire operation. That started to change when AWS added a series of S3 security checks, as detailed in Jeff Barr’s blog post here. These include how you set up encryption by default, what happens when you move storage across Amazon regions, and showing the encryption status of each object in a simple dashboard. These features made it easier to review the access status of your buckets, as shown with the “public” or “not public” icons in this screenshot below:
Finally, you need to take a step back and realize that you need to have developers who think about security by design, meaning before they write a single line of code. The longer you wait to secure anything, the harder it will be to come back and bolt something on later in the development cycle. This means thinking carefully about your development workflows, your access rights across your development team, and what rights your users need to have to run the resulting applications. A good place to learn more about this is at Sysdig. They have a series of excellent tutorials (using their software of course as models) that walk you through some of the common security use cases, such as auditing runtime code for odd behaviors, performing forensic analysis and examining vulnerabilities.
And as always, remember that Network Solutions has your back when it comes to online security. We’ll help you protect your online presence from malicious cyber actors.