Your security approach needs to change: A modest proposal

Data breaches have become commonplace these days, and it doesn't appear there will be any slowing down. Companies keep making headlines because either their data is ransomed, or it's been discovered that their data storage isn't properly locked down. Big, global brands are suffering at the hands of these attacks, and we are starting to see some common patterns emerge that might help us identify a new, different approach to cloud security.

One has to wonder if anyone is learning anything in the midst of all this hacking. How much high profile content must be leaked, and how many credit card numbers have to be exposed before someone says, "All the effort we're putting into security and compliance can be dismantled with a single, unnoticed misconfiguration. How can we avoid that?"

There are best practices we feel that organizations need to follow, and of course, awareness is usually the best first line of defense of hack attempts. But we also feel there is a need to bring a fresh mindset to cloud security. It's a mindset of preparedness within the repositories you manage, but also of taking into account that cloud environments now encompass activity and storage beyond just your own environment.

Maybe it's best to think about it in these terms:

Storage and data repositories are dynamic

There's a well-worn story about infamous bank robber Willie Sutton; when asked why he robbed banks, he replied, "'Cuz that's where the money is." Old Willie's comments are actually rather prophetic for our current digital age. Fast forward to the flurry of recent high profile ransomware attacks and you could ask a hacker why he targets databases and AWS S3 buckets. A reasonable answer might be, "'Cuz that's where the data is."

The targets are databases, S3 buckets, and other data repositories. Companies naturally store customer and financial data here because there is so much of it and because it can sit in both structured and unstructured formats. In a cloud environment, files can be accessed when needed, but like all those boxes in your garage, you may not even realize what's in them, so they are ignored. The problem, however, is that the configurations used to set up those repositories may now be outdated. Yet, because it's a storage unit, companies keep putting files there because it’s become so easy to migrate data in and out of repositories, and to integrate with applications that may use that data. More data, more files, and not a single bit of additional attention.

Data may become static, but the cloud is, by definition, dynamic. Because the cloud is facilitating connections and integration and scalability, and everything else that makes it the right platform for the digital age, it has to be given constant security attention. The sense one gets from learning about all these breaches is that cloud security is too often treated as an afterthought. Security has to be the default approach before application development, integration, or any other element of the environment is considered. The way one builds an enterprise infrastructure should be dependent upon always applying strict security and compliance controls, and by having continuous insight into everything happening in your cloud.

I always advocate that enterprises should be using a Security by Design (SbD) approach, which can automate security controls and improve audit processes. Implementing SbD will encourage users to configure and manage their cloud assets in a way that is unique to their needs, which improves reliability in the security posture across the AWS environment.

Monitor and assess -- continuously

We keep seeing the same story -- a server was left completely open and vulnerable to anyone who could access it. The offending asset in these high profile cases, storage bucket or database, has usually been misconfigured or just generally has an inappropriate level of protection around it.

Clearly, S3 bucket management presents an interesting situation for AWS users; it can be complex because it offers so many ways to be configured, but if configured correctly, the technology can be rock solid. At the same time, this can't just be blamed on lazy administrators. What we're seeing is a classic 'paradox of choice.' AWS provides so many options for bucket configurations, permissions, and settings, which means it provides great flexibility, but it also means there are a lot of ways to inadvertently neglect or misconfigure your accounts.

The same thing is true for MongoDB; NoSQL makes it easy to prototype and develop applications, but therein lies a problem. Being too easy means too easy to ignore or overlook security as well. Because MongoDB makes the process of building so simple, developers often deploy without going back to add in layers of security to their prototype. The key is to get over the false notion that a company can accurately operate off a single snapshot of it’s security state. What’s needed is continuous visibility into the status of their cloud environment because it is always changing. Only then can an organization understand where they are vulnerable.

SLAs for partners

What many don't realize is that while Verizon, TimeWarner Cable and other major brand names get the headlines, these companies actually have sophisticated and successful security programs in place, so attackers are not as likely to directly face them. The problem is that it's often their partners who are at fault for the breaches that exposed customer and employee data.

It's normal for companies to share data with partners, and most do so under rigorous data privacy rules. Yet, once that data is shared, there is little or no oversight into how it's managed. Companies are effectively losing control not just of the data, but how the data is being transacted and stored. This is a huge problem for organizations that work with partners; how can you understand your complete business risk profile if you don't have visibility into partners' risks that could impact your data? If a breach occurs, the bigger brand is the one that makes headline and gets saddled with the perception that it was careless with customer information. Companies need to demand that partners adhere to strict security and compliance policies and provide proof of the adherence. Ensuring that agreement is met requires standardizing on a single continuous monitoring and reporting solution.

The time has come to consider partner SLAs specifically for security. It's a logical way to specify expectations and keep those organizations in your ecosystem compliant with the controls you need to provide to customers you provide a secure environment for their data. To win business, a partner must be able to prove adherence to SLA-mandated practices, and agree to continuous monitoring. In this way, major brands will be doing their job of keeping data safe irrespective of where it is used.

There’s nothing revolutionary in here; it’s really about making a commitment to approach security with purpose. Maybe it’s about jump-starting a new way of thinking about cloud security -- including your data and information that is in someone else’s cloud. Whatever it is, we have to move beyond seeing key rotation, multi-factor authentication, access controls, encryption, and the host of other security controls as merely items on a checklist. The things we do to prevent attacks also instill in us, and in the stakeholders in our ecosystem, a perspective of prevention and continuous alert.

Image credit: Rawpixel.com / Shutterstock

Tim co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.