[BreachExchange] Your security approach needs to change: A modest proposal

[Audrey McNeil]

https://betanews.com/2017/10/27/your-security-approach-needs-to-change/

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171027/7d53b750/attachment.html>