A WORD TO THE NERD

THE GREAT CLOUD HEIST (AND HOW TO FOIL IT)

The cloud isn't less secure than, say, your personal hard drive. In many ways it's much more secure: it's professionally managed, probably uses good encryption by default, and is less likely to be accidentally dropped in your toilet.

However, because cloud systems centralize large amounts of data, the actions of a single hacker can be devastating. Like the 2013 Yahoo breach that exposed more than one billion user accounts, or Dropbox's 68-million-user barf that ended up with hackers selling the stolen accounts on the dark web for bitcoin. Leave a server online with an unprotected Internet port, or upload data to a data storage bucket without password protection, and you're pretty much asking to have your entire company held for ransom, as in the attack that destroyed the web hosting outfit CodeSpaces in 2014.

Even if the bad guys can't break into cloud systems, they can still take them down using an attack called a distributed denial of service (DDoS). They'll flood your servers with billions of junk network packets from all directions, overloading the application and forcing it offline. Cloud apps can actually be vulnerable to a unique flavor of this attack that I call a “billing DDoS”: even if your servers can handle all the bogus traffic, the cloud's magical scaling powers could cause you to consume so many expensive cloud resources that the attack empties your wallet.

Hackers don't just target caches of data held by big companies, though. They'll also go after your personal accounts, like the guy who tricked multiple Hollywood celebrities into sharing their iCloud passwords with him back in 2012 (a process known as “phishing”) and then stole their private photos from the backup service. In that case, the cloud system worked as designed. The problem was human error—well, celebrity error, but close enough.

Actually, that's par for the course. A recent Gartner study predicted that 99 percent of cloud security breaches over the next five years will be the customer's fault. It's that darn shared responsibility model again. The cloud providers are handing you power tools; it's up to you not to slice your hands off.

Preventing Data Breaches

The good news is that proper cloud security isn't some arcane mystery. As with most difficult things, like eating vegetables or working out, it's simple, good for you, and a little boring.

Use Proper Login Hygiene

Whether you're an individual or a professional system administrator, don't live and die by the strength of your password alone. Use multifactor authentication (MFA) to require something else on login, like a code from your phone or a scan of your fingertip. That way, even if the bad guys skim your password, they won't be able to do anything with it.

All the normal password advice applies too: use an unpredictable passphrase (not your dog's birthday or “Password123”); don't reuse passwords across sites (a password manager can help with that); and, of course, flip your passwords over four times a year. Or maybe that's mattresses. Oh well, it can't hurt.

It's also a good idea to enter your email address at haveibeenpwned.com and see if it's been exposed in any known breaches. (Don't worry, I didn't just send you to a phishing site, though at this point you're right to be suspicious!)

Encrypt Everything

There are two ways to encrypt cloud data: at rest, meaning while the data is being stored somewhere, like in a database, and in transit, meaning while the data is flying through the Internet in little packets. Encryption at rest is like putting money in a safe; encryption in transit is like putting it in a Brinks truck. Both are necessary to protect important data. (What data is important? You're on your own there, pal.)

Encryption algorithms are notoriously tricky to implement correctly, so we can all be thankful that many cloud services handle this out of the box these days. Make sure you are using SSL for your network communications (look for the “https://” at the front of secure links), and enable encryption on data stores if necessary, though at this point a lot of them do it by default.

Use the Principle of Least Privilege

Human users aren't the only entities with cloud logins. Software systems have them too. The cloud servers running your social media app or food delivery service have system credentials that let them talk to each other and share data as needed.

That's because cloud applications are often made up of microservices: little mini-systems that communicate with each other over the network. Each microservice is supposed to do a separate, unique piece of work, like sending emails or generating reports. The thing that sends you a text message when your hair salon is running a special is probably a microservice.

From a security standpoint, the challenge with microservices is making sure they only have access to do the things they are supposed to do. It's much easier for cloud developers to leave system credentials unrestricted, avoiding the possibility of an error when a request between services gets denied. But, of course, when you leave permissions open too wide, you increase the risk that a hacker who compromises one microservice can jump to others, causing very macro amounts of damage.

I think I learned in school that the Titanic sank because the watertight compartments in the hold were supposed to be individually sealed, but when the iceberg hit, water spilled from one compartment to the next until the whole ship went down. You don't want your app to be the next Titanic, so obey the principle of least privilege: give applications and services (as well as users) only the rights they need to accomplish their specific task. By layering these permissions, you create defense in depth: a strategy minimizing the chances of exposure, like wearing three pairs of socks with holes in different places.

Detect as Well as Protect

In 2015, hackers broke into the U.S. Office of Personnel Management's databases and stole more than 4.2 million personnel files of current and former government employees. The breach targeted the sensitive information that workers submit for security clearance, not just Social Security numbers but also the names and addresses of family, interviews with college friends, and mental health history. The kind of soul-baring confessions that could be used to blackmail key government figures. So, yeah, important data.

But here's the worst part: the leaks went on for more than a year before Office of Personnel Management (OPM) noticed. They only figured it out when a third-party contractor accidentally stumbled on the breach during a sales demo of a forensic tool, which must have been either the greatest or worst demo in the history of mankind.

Oh, and the method of the hack? It wasn't some evil genius laying waste to a network firewall. The attackers just phished an employee's password. At the time, the OPM did not require multifactor authentication.

Moral of the story: Check for abnormal access patterns in your system, like sessions from unusual IP addresses. Automate those checks if possible. And, of course, require MFA! The alternative is a hack that destroys your business, or at least leads to costly and embarrassing mitigations.

I should know; I was an OPM hack victim myself. The government is still paying to send me credit monitoring notices.