It’s been a rough couple of weeks for internet users. And an eye-opening one for IT engineers and security analysts.
Both the Cloudflare data leak and the Amazon Web Services crash were self-inflicted wounds. Add to that the internet of things (IoT), which is already delivering on its promise to change the way we do just about everything. But not in the way we hoped. Instead, even child’s toys — like CloudPets — can be a Trojan horse.
CloudPets lets parents and kids communicate through a cuddly stuffed animal. But those audio files have been living on a completely unsecured database, used frequently by app developers because it is flexible and free. Unfortunately, the hidden cost of “free” is the lack of security and user passwords, as well as the fact that the audio files themselves were freely accessible on the internet. While the 583,000 records that were unsecured in the CloudPets database may seem small, the bigger issue is the many thousands of app builders utilizing this and other free databases that are storing sensitive information with little or no security.
SC Media, a cybersecurity news service, reported that FireMon CTO Paul Calatayud had renamed the IoT to “the IoMT, as in the internet of malicious things.” The cuddly teddy bear exposure, he says, illuminates two big problems: the growing use of open-source databases that lack security, and putting devices on the internet.
For most of us, Cloudflare may have seemed a nonstory, but it was only because we didn’t really understand how deeply it might affect us.
Cloudflare is a company that provides enhanced security to nearly 5 million websites. Those websites have tens of millions of users, and you are probably one of them.
Techies now call the Cloudflare incident #cloudbleed to tie it to the disastrous #heartbleed attack in April 2014. Both incidents are leaks, not hacks. And they are the result of a bug among millions of lines of code, which exposed private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, and hotel bookings in the data that had been saved by search engines.
The exposure was a slow leak, and the bad code exposed data only about 0.00003 percent of the time. But when you are dealing with traffic on 5 million sites with an untold number of users for a six-month period — well, that’s a lot of hits. And a lot of errors. And although there is no evidence that any passwords or other sensitive information were definitely exposed, it must be assumed. If you have an account on Netflix, Uber, Medium, Yelp, or literally any one of millions of other sites, you should change your password. You can check to see if your frequently used sites — and certainly anywhere you have stored credit card information (never do that, BTW) — is a Cloudflare client at doesitusecloudfare.com.
And then there’s Amazon’s web services. Home to more than 150,000 websites and cloud services, the world notices when something goes wrong at Amazon, such as the four-hour outage last Tuesday. The company has had a significant outage just about every year, but this one was an unforced error.
It happened when an engineer made a typo that took out a large swath of Amazon’s servers across the country. If your website was not running on an Amazon server, you might still have had a problem. Much of the data — photos, videos, logos, and databases — used to populate websites were on crashed servers.
In some way, all of us were affected. The outage was mostly annoying for consumers, but a very big headache for big business. The Wall Street Journal reported that the outage “cost companies in the S&P $150 million,” according to Cyence Inc., a startup that specializes in estimating cyber-risks. A website-monitoring company said “54 of the internet’s Top 100 retailers saw website performance slow by 20 percent or more.”
Technology and cybersecurity analysts are working overtime trying to find the meaningful takeaway from these events. Some fall into “we’ve-created-a-monster” camp; others are in the “stuff-happens-don’t-sweat-it” group.
There’s a middle ground, however. Yes, we’ve become over-dependent on something we don’t understand, and sometimes it will rear up and bite us just to show us it can.
That was last week. We got bit.
As an IT executive, my post-event focus was to classify what happened and then determine if it was or could be within our capabilities to stop it. If not, what did we need to work on to develop workarounds and redundancies to ameliorate the problems the next incident would cause?
When the mass of interconnected devices, servers, toasters, furry toys, and Fitbits that we call the internet gets us back, there is little we can do while we’re in the thick of it. But when the dust clears, we can resolve to be smarter and, in turn, ask better questions, and demand better answers from ISPs, online services, and third-party vendors. How are you protecting my data? Have you ever been hacked? What did you change after the hack? Have you tested a total failure to see how long it would take to come back up?
The postmortem on Amazon’s server event is focusing on the lack of redundancy. Only the largest companies have enough money or foresight to distribute their data across multiple companies and servers so they can never lose access to everything. Fewer still maintain high availability with redundant servers in geographically diverse locations (such as East and West Coasts) that back each other up fully in real time. Those are expensive options.
But smaller regional and local business can still ask online cloud providers about redundancy. Most providers promise that they are doing daily backups. You might ask where the backups are located. They will be far less use to you if your backups are in the same building, even sometimes on the same server. It’s also important to ask how you can quickly switch over to a West Coast backup server if the East Coast goes down.
Most of us will muddle along, swearing under our breath, when once or twice a year the internet rears back and throws a sucker punch our way.
