… when it comes to their IT security behavior.
This famous quote from John Chambers is very well known and probably in everyone’s mind:
There are only two types of organizations: Those that have been hacked and those that don’t know it yet!
John Chambers
It already describes the situation in the market very well. But nonetheless, I disagree that there are only two types of organizations. Why? Because reality has shown that there are at least two other types. It also has something depressing thinking that this simple fact of just two types, both had incidents, which has a lot of truth in it, is the entire reality. I rather like to speak of the four types of organizations:
Table of Contents
1: The (unimportant) Unicorns
The Unicorns are the organizations that have never been hacked before and advertise with it. The reason for this too often is, that they have never been targeted by an attack because their target is not worthwhile. The motivations of hacking companies are either to get ransom, get money out of the stolen data, or have the reputation of having hacked a difficult target. So, the goal of hacking those organizations doesn’t overweigh the effort of doing so. – It doesn’t mean that they can’t be hacked and that they won’t get hacked.
This usually means, there is no focus on that company because they are too small, have a too low market share, or just have low-value data. They are simply flying under the radar. Apple has been a good example of this in the past. Their market share in the early 2000s was too small and the focus of hackers was on the far larger Windows operating system. With the rising popularity of macOS in the late 2010s, also their security incidents went up by some margin. The felt security superiority of macOS over Windows from the early 2000s most likely wasn’t just because it was more secure but mainly due to the priorities of attackers.
Being a customer of a Unicorn is difficult because you would never know if they are not targeted yet and if their security mechanisms actually would withstand a serious hacking attempt. But more importantly, you would not know if they are a type 2 or 3 organization – a much higher threat to IT security than any other category.
Of course, there are not only the “unimportant” Unicorn organizations. Also, the real Unicorns that have never been hacked are claimed to exist. But just like Unicorns, nobody has proof they exist! Some claim to have seen them – but no one ever took a picture or has proof. But they could still exist! The main problem is, that you usually cannot prove the non-existence of something – you cannot prove that Unicorns do not exist! That is also the reason why there still are rumors of Bigfoot, Lochness, the Yeti, and Alien visitors. They might exist “somewhere” and you cannot check everywhere at once – So who knows? An organization can not prove it hasn’t been hacked – but: Who knows?
But things to look out for, if you think you have found one, is if they have a well-documented security model, security certifications, and, even more importantly, an official bug bounty program. This ensures that there are at least some hackers interested in doing security research on that software because they might be able to earn money from it.
2: The Clueless
The organizations that have been hacked but don’t know they have been hacked are a serious threat and the least favorable to be a customer of. This is the most dangerous group of companies because no communication with customers can be conducted, no containment or countermeasures can be taken, no learnings follow from an incident, and not even the customers can react to it. Mostly this is due to a lack of monitoring systems, due diligence, or simply a culture of closing the eyes to reality.
Sadly, if they don’t know they have been a victim of an attack, you can’t know either. Also, they are very hard to distinguish from groups 1 or 3! Mostly the clueless and their customers will know a lot later about the attack – when data surfaces or is being used to target the customers. This, of course, is far too late to react or contain a breach.
3: The Cover Uppers
This is the group you also don’t want to be a customer of: the ones that know they have been breached but don’t make it public – for whatever reason. Sure, internal measures to contain a breach mostly are taken but the customers are left in the dark. Often times hacks get intentionally or unintentionally public months or even years later – there are plenty of examples of “number 3” companies – Here are two:
An example of a covered up / or at least the try of covering up a data breach has been Uber. They tried covering up a data breach affecting over 57 million users and also paid the hackers $100,000 to keep the incident under wraps. The hack exposed the private information of 600,000 US drivers and more than 50 million customers across the world. Compromised data included full names, email addresses, phone numbers, and driver registrations. The incident happened back in 2016 and it took until 2022 for it to surface.
An example of delayed response is the recent incident with Cisco. On May 24, 2022, Cisco identified a security incident targeting Cisco’s corporate IT infrastructure. The incident was quickly contained and luckily no customer data has been affected. However, it took Cisco 3 months and 19 days to disclose what has happened. A report was filed on September 11, 2022. There are two sides to this, however: The incident didn’t involve customer data, so Cisco wasn’t obliged to disclose the incident to the public. Secondly, they probably wanted to wait until the end of the investigation to publicize the entire report at once with all findings. While these two arguments are of course in their favor, it nonetheless is an example of a very late disclosed incident. Whether this was to not disturb ongoing sales cycles, or if it just had other reasons.
There are rules and regulations for disclosing incidents like the above. In the US, security breach notification laws or data breach notification laws have been irregularly enacted in all 50 U.S. states since 2002. The European Union’s General Data Protection Regulation (GDPR) and Australia’s Privacy Amendment (Notifiable Data Breaches) Act 2017 (Cth), of course, have added data breach notification laws as well.
For example, according to Article 33 of the GDPR, organizations must notify the Data Protection Authority (DPA) of a breach within 72 hours of becoming aware of the breach. There is one big “but” in this, however. Most of these laws only apply to “customer data” or “personally identifiable information” involved in an incident – not a general breach or, as in Cisco’s case, an incident just targeting the corporate infrastructure. Here, no such data was stolen, manipulated, or deleted which is why they didn’t fall under this 72-hour regulation and weren’t obliged to disclose the incident at all. This is why they most likely won’t be fined a GDPR violation fine. Nonetheless, in my opinion, customers need to know about these types of incidents as well. But more to that in category 4.
In any case, being a customer of a type 3 organization is not favorable. Surely if nothing gets disclosed for whatever reason or if they even try to actively cover up incidents.
4: The Reactive
It takes 20 years to build a reputation and few minutes of cyber-incident to ruin it.
Stephane Nappo
Lastly are organizations that had a notified breach. And here again, I don’t follow the quote above, in which the reputation, built over 20 years is gone in minutes. At least it definitely shouldn’t be. Referring back to the initial quote, that there are only two types of organizations, the ones who know and those who don’t know, means, that a breach in some form is inevitable. How trustworthy would Microsoft be after a decade of partly serious security incidents and security bugs?
In a nutshell: If we exclude the few Unicorns, every organization has had a security incident at some point in its history. Same as every restaurant, as good as it might be, has delivered a bad meal at some point. And this is the point I want to make: It’s not the “IF” you should judge an organization on when it comes to security incidents, it’s the “HOW”. The HOW they deal with it, it’s the HOW they communicate, the HOW quick they are in containing an incident.
Important here is timely and open communication to customers and prospects about what has happened, how the incident has been contained, what data was affected, what countermeasures have been taken, and what long-term consequences follow to prevent anything similar from happening in the future.
Trust doesn’t develop from always doing the right
Simon Sinek
thing. Trust comes from taking responsibility when we
do the wrong thing.
This openness and teaming up with its customers ultimately is a skill that many organizations still have to learn – but it is those skills that build trust! You can count on the software vendor to act as a trusted partner when an incident occurs and trust that they will do the right things.
Of course, no one wants to be a victim of a security incident in any form – not as a customer and also not as an organization. But past incidents of a potential vendor of IT systems can be a good (or bad) advertisement for how the company deals with this sort of disastrous challenges – and is surely no reason to immediately lose trust in minutes. You for sure know that the organization you deal with does not belong to the most dangerous groups 2 and 3! And that’s already a big relief!
Conclusion
It isn’t the presence of known breaches that should make you suspicious, it’s the absence or non-communication which should. You can judge a company on its behavior in a security incident and not by the absence of them.
What can we learn from this? Don’t judge companies who had security incidents by just the fact that they had an incident. Judge companies by their response to an incident and get suspicious if they claim to never have had one. Unicorns are extremely rare and unimportant companies seldomly produce software that is desirable of using on a larger scale.
Don’t measure a company by the fact that they have had an incident or not. Measure a company by it’s reaction to it and get suspicious if they have never disclosed one.
Peter van Zeist
Evaluate organizations by their security standards but also make sure they have an effective, active, and well-respected bug bounty program as well as read through the documentation and response of past security incidents. Things to look out for there are:
- How long did it take the organization from the incident to the time they made it public?
- Were sufficient details given about the affected data and systems?
- Were customer data affected and were those customers notified?
- Are the steps the organization took to contain the incident well documented?
- Did the organization disclose learnings what it will implement to prevent further incidents like these from happening?
- How long was the time from the actual incident until the organization reached the step where they knew all the details, contained the incident, and implemented countermeasures?
Ultimately a company has to decide which organization to trust and which not to – and there is, of course, not one truth to the story. I hope that, with the above thoughts on the topic, I could give some guidance and maybe a new perspective if you either choose the red or the blue pill.
Please share your ideas and thoughts about the four organizational types in the comments. I am happy to hear from you.