Data Theft and AWS Deployments

Data theft: no one’s immune

Because, in conformance with their Shared Responsibility Model, AWS does such a good job protecting their physical infrastructure, many of the kinds of data theft that plague locally-hosted operations aren’t likely to threaten your cloud-based servers.

data theftConsider, as an example, the unauthorized individual who just sat down in front of that workstation over there… the one right behind the room divider. See how easily he’s able to bypass network checkpoints by posting his freshly encoded data to social networking accounts or fax-to-email services? I’ll bet you’ll never see anything like that happening inside an Amazon server farm.

But not so fast with the smug grin: this definitely doesn’t mean you’re off the hook. Not even close. After all, the kind of disaster that recently hit Morgan Stanley – and 350,000 of its customers – could just as easily have happened on an AWS-hosted system. Data theft (sometimes called “data exfiltration”) is a serious threat to all networked systems, and you’ve got responsibilities to your customers, investors, and society at large to do your part to prevent it.

Data theft: preventative solutions

Here’s a checklist of steps you can – and should – take to both harden your deployment and, in general, tighten the way you interact with your cloud resources:

  • IAM. The less access to your resources you provide to team members and applications, the lower the chances that your data will go missing. Through their Identity and Access Management (IAM) service, AWS allows you to expose your individual compute and data resources to specific purpose-built users and roles, rather than to all and sundry who might be associated with your account. Use it.
  • Penetration-testing. When asked in advance, AWS will provide permission for you to launch simulated attacks against your cloud infrastructure. Using specialized operating system distributions like Kali Linux, you’ll get a first-hand look at how well your ACLs, security groups, and VPCs are configured, and how easy it will be for the bad guys to blow past them.
  • Anti-phishing training. All the stealth technology in the world won’t do much good if someone on your team clicks on the “fix the problem” link in the fake “your account needs resetting” email he just received.
  • Secure your own local infrastructure. You can’t very well blame Amazon if the gentleman at Data Theft Incorporated got your account authentication data through a keystroke tracker installed on the compromised PC you’re using, can you?
  • Log monitoring. System access and event logs exist for a reason. Hint: it might have something to do with keeping track of system access and events.
  • CloudWatch. Haven’t got the time or patience to properly monitor your logs? Once you set them to trigger alarm notifications upon detection of unusual activity, the friendly electrons at Amazon’s CloudWatch will be only too happy to do it for you.

Data Leak Prevention technology

Besides those more integrated approaches, there’s also Data Leak Prevention (DLP) technology, an entire class of software solutions aimed at data theft protection. DLP systems use machine learning heuristics, user activity monitoring, and sometimes honeypots to monitor a network.

They’ll particularly focus on analyzing data when it’s in motion (network), at rest (archived), and in use (endpoints). Should you feel the need is pressing enough, there’s no reason you can’t install such a package on part of your cloud infrastructure to keep watch over your account resources.

Of course, DLP systems are available from many of the usual suspects like Symantic and McAfee. But it’s the Linux-based open source packages, MyDLP and, perhaps, OpenDLP that should interest us the most because they’re likely to be flexible (and Linux-friendly) enough to fit comfortably into the AWS environment.

The bottom line? The tools we’ll need to defend our cloud deployments against data theft are available. We’ve just got to decide to use them.

Cloud Academy