Every year has its share of security gaffes, breaches, and hacker “shenanigans.” As we enter into the new year, it is inevitable that we will see articles in the mainstream and trade press recapping the worst of them.
There are two reasons why these lists are so prevalent. The first is human nature: fear gets attention. Just like a product vendor using FUD (fear, uncertainty, doubt) to boost sales, so too can fear drive journalistic readership. So, it’s natural that the trade media would cover this. If we’re honest about it, there’s probably also an element of schadenfreude. High-stakes roles like assurance, governance, risk, and security are hard – and stressful. There’s an element of “thank goodness it wasn’t us” that happens to practitioners when reading about a breach that happened to some company other than our own.
All this is to be expected of course, but at some level when I see the inevitable year-end “breach recaps,” I feel like we’re missing an opportunity. Why? Because focus on the outcome alone leaves out an important part of the discussion – specifically, the lessons learned that inform how we can improve.
I’ll give you an example of what I mean. Say that I told you that the death toll from the Black Plague in the 14th century was about 50 million. Horrible, right? But does that give you any information about how to prevent disease? Measures to treat or diagnose them? Information about carriers or transmission vectors? No. Sure, a statistic like that is attention-grabbing ... but other than for a very small segment of practitioners (such as those doing pathogen statistical analysis), it doesn’t foster future disease prevention. If you spell out that the reasons for the rapid spread of the disease during this time period were (simplified of course) related to hygiene/sanitation, population density, and maritime trade, well that starts to tell you something that can inform prevention.
My point is, it’s useful to look at the worst/scariest events of the year to the extent that we draw out the lessons learned and takeaways that inform future efforts. With this in mind, and as a counterpoint to lists you might see in other venues, we’ve put together a list of five security “events” from this year that we think contain useful lessons. These aren’t the biggest breaches, or the scariest, or those with the biggest financial impact. Instead, these are the events that carry important lessons it behooves practitioners to learn from.
#1 – Facebook Account Data Compromised
The first one of these relates to the discovery of 540 million user records (about 150GB worth) from Facebook found exposed on the internet via several third-party companies. The root cause? Improperly secured S3 buckets. There are three important lessons here. The first and most obvious is the lesson about securing – and validating – permissions on cloud storage buckets (this is a big one). But there are other lessons beyond this. First, the importance of software (“application”) security. Tools like application threat modeling as we know can find and flag potential application design, configuration, or implementation issues early. Therefore, it remains an important tool in our security arsenal. Another lesson? The third-party angle – specifically, liability. In this case, the collection was facilitated by third parties and not Facebook itself; but yet, who is highlighted in the headlines? Facebook itself. Never forget that if you have the primary customer relationship, you ultimately wind up holding the bag.
#2 – Facebook Plaintext Passwords
The second one I’ve chosen to highlight is also from Facebook – in this case, the storage of Instagram passwords in the clear. Note that I’m not intentionally picking on Facebook by including them twice; in fact, this one is actually a “success story” for them (at least from a certain point of view). Specifically, in this case, a “routine security review” found passwords stored in plaintext. While analyzing and remediating that, they found more situations of passwords stored in log files as well. So, what’s the lesson? The main one I’d highlight is the value of technical assurance efforts, specifically the value of specifically validating cryptography use. These are areas often overlooked but that can have real, tangible security value. “Stuff happens” – and no company can ever do anything 100% perfectly all the time; but having a mechanism to find and fix those issues when they happen can mean the difference between minor egg on the face and major catastrophe.
#3 – Source Control Shenanigans
Next up, attackers downloading Git repositories, scrubbing them, and holding the source code for ransom. This event itself isn’t all that interesting from a tradecraft perspective: the vector here was run-of-the-mill account compromise (e.g., leaked or stolen passwords, API keys, etc.) What makes this interesting is the fact that it targets source control specifically. In days gone by, vetting source control platforms (both the configuration as well as whether they contain secrets like cryptographic keys or passwords) took a lot of time and occupied quite a bit of practitioner attention. As platforms become standardized and Git becomes ubiquitous, attention from practitioners can waver. Don’t let that happen. Staying vigilant about source control is still important – even in the GitHub era when everything is centralized and standardized.
#4 – Malware Fully Loaded
Germany’s BSI (Bundesamt für Sicherheit in der Informationstechnik) warned about Android smartphones coming “out of the box” with malware embedded (in this case, embedded in firmware). This isn’t the first time that we’ve seen phones (or other products for that matter) ship with malware pre-installed. It’s not even the first time we’ve seen BSI warning about stuff like this. It is, however, a great example of information sharing and the value of government keeping citizens’ information secured. The BSI is specifically chartered with warning people about security issues in technology products (section 7 of the BSI Act) and investigating products (see section 7a). The lesson? There’s a role that governments can play in ensuring the security of products sold within its jurisdiction, and that role can be highly effective.
#5 – Disgruntled
Last up, a dismissed IT staff member of a transportation service company was jailed for targeting and sabotaging his former employer’s AWS systems. Long story short, after he was let go back in 2016, he used an administrative account to begin systematically sabotaging and disabling AWS assets of his former employer; as a result, the company lost a few key customer contracts. There are a few lessons here. First, once again note the earlier lesson about securing cloud assets. Beyond hammering on that again, though, this event also highlights internal threats and privileged account use. We would all do well to maintain awareness of internal threats. As technology becomes more prevalent and more business-critical, a rogue or disgruntled employee (even former employee) has the potential to do significant damage. Likewise, cloud can make privileged accounts more complicated since it can add account types we didn’t have before (in addition to root and Administrator users, we now also have cloud administrator accounts to keep track of). Continued management, monitoring and protection of these accounts is important.
