Blog / BAD DAY AT THE BREACH – How to Respond to a Security Breach
Data Breaches are a fairly common thing these days. Part of my own routine is to keep tabs on the news. A lot of what I watch for are high profile vulnerabilities and issues that may affect the TRINUS Client base. At the same time, I look out for things that are less obvious, but may be of interest to our IT Support Technicians.
Along the way I see all sorts of articles about Data Breaches with various companies. Some of these are big (Yahoo, EQUIFAX, etc.); others are small. Some of them get disclosed quickly; others do not. The things that go wrong and how these Breaches are handled, vary wildly. Whether or not a company handles it well or not, is not dictated by it’s size. It might be that the larger the company is, the bigger even a small mistake becomes, but they tend not to handle Breaches very well at all. The errors are numerous (lengthy delays in disclosure, poor information release, etc.)
Here’s a recent example of a rather odd data Breach from a company that does Security cameras.
Basically, the company has Internet-capable Security cameras that store data in the Cloud. You receive alerts on your phone and can access the videos from there. SOMEHOW, camera videos on some Users were being sent to the wrong people!
Now then, there was no leak of Personal Information; at least directly. However, the implications of this are pretty serious when you think about it:
How many other cameras are sending their information to the wrong people?
What if the cameras sent their information to someone who could use the video feed to plan a break-in?
Taking all these Breaches into consideration, I have some advice for what if/when your own organization has a Breach of Information:
1) Be prompt about making the Breach public.
All too often, companies take months (or sometimes years) to disclose that a Breach has occurred. The EU has laws that impose a strict rule on how quickly this information needs to be made public. While there currently is no such rule in Canada, the PIPEDA regulations have a placeholder section about disclosure timelines, which is currently being updated.
You need to make sure that all of your employees know that if they suspect or discover a Breach Incident, they need to immediately report the situation to their Managers, who also need to know that this information needs to get escalated quickly. It’s not about a witch hunt for who is responsible; it’s about protecting the people whose information has been compromised.
2) Don’t be afraid to include Technical Information in your Public Explanations.
Do you remember EQUIFAX? The information they released included the exact CVE (Common Vulnerabilities and Exposures) – that was exploited. In the case of the article I referenced above, they mentioned Security keys. Now I can be fairly certain that 95% of the people who read this information and are affected by it, have no idea what either of those things really are.
However, that stills leaves a lot of people who do. Not the least of those people work for the Office of the Privacy Commissioner. In case you didn’t know, they’re the people you are legally required to notify, in the event you have a Breach of Personal Information.
3) Don’t try and falsify details in your Public Statements (at least, make sure the details make sense.)
“Don’t lie” sounds pretty straight forward, right? Well, if you read the article I linked earlier, you’ll find that the company gave 2 different responses for the 2 incidents that were reported. No big deal, right? 2 incidents, having 2 different root causes seems fine.
The problem is that the explanation for the second incident doesn’t make sense (to me, to the person who wrote the article, as well as the Security Researcher they interviewed.) Now maybe they are being truthful, or maybe not. The thing is, the explanation on the root cause for the first incident, is possible (a slight stretch, but not beyond the realm of reason.) Now if we put that next to the explanation for the second incident, it makes you question how honest the company was with the first disclosure.
Do they even know what went wrong at all? If they don’t know what happened, how can you trust them? These are the kinds of questions this brings up. Such sort of behaviour is self-defeating, because it eats away at peoples’ opinions.
There’s a lot of other advice I could give, but most of it is rather Technical (enable these settings, set up this capability, etc.) You need to remember that if you have to bring in a 3rd party to investigate the incident, that is a labour-intensive activity. A lot of the advice I would give should be looked at as a way of directly reducing costs. The average cost of a Breach these days is in the millions of dollars. Breaches are not something to take lightly!
If you have any questions about How to Respond to a Security Breach, you can always reach out to your TRINUS Account Manager for some stress-free IT.
Thanks!
Karl Buckley
Cyber-Security Supervisor
TRINUS
stress-free IT
