Why do I care about someone else’s data breach?
Because as the size of your organization increases, the probability that an individual employee’s company email is in that breach rises to 1. That lone employee is going to be suffering some unfortunate impacts, from identity theft, financial scams, blackmail, and even death threats (as seen in the Ashley Madison breach). There’s an organizational impact as well: a single compromised account can serve as a launching point for reconnaissance, phishing waves, or a pivot point for a further attack. But wait? What if the exposure is a company webmail that is isolated from the main corporate network? There will be an employee who reuses their password. But what if your company has a policy against that? Then there will definitely be employees who reuse their passwords. Unless your organization uses password managers, a single breached account has a very good chance of being a pivot point for more serious attacks.
Email isn’t the end of sensitive data loss, unfortunately. Stack Overflow, a perennial favorite for developers working out knotty problems, frequently has proprietary code cut and pasted into the site, sometimes with network configuration data attached. Pastebin can and does have network details and code with misconfigured expiration dates, waiting to be scooped up. And LinkedIn is an absolute goldmine for mapping potential accesses to employees. So how do you go about plugging leaks? A three-point strategy can get you started.
1. Legal – This is most important for an internal data protection policy because there are some hard limits to what you can and cannot tell employees to post online. Consulting with an attorney can set some appropriate bounds for what sort of mitigations you want to implement. Further, a lawyer well briefed on cyber threats can be a valuable asset in issuing takedowns of offending material.
2. Stovepipe breaking – Communicating directly with first line managers to discover how and why data leaves your organization should constitute the bulk of any data loss mitigation plan. With the exception of the lone knucklehead who signs up for an inappropriate site with a company email (you have one of these, I promise) most data loss occurs because businesses use cases do not align to existing security policy, and users are going to find a workaround. Does your default computing environment have tooling sufficient for developers to do their job or are you 2 versions behind industry standards? How does your security team get a piece of malware off an infected host and onto a test machine? What’s the default attachment size on the corporate mail instance? And if you run on a virtualized environment, what’s the default memory allocation and how much hassle does an employee have to suffer to get it raised? These may appear on the surface to be small, too in-the-weeds type questions. They are in fact very predictable preludes to data loss or a full on breach, because in each instance an employee is incentivized to break policy to get their job done. This is fortunately preventable – talk to your first line management and gather use cases, before policy gets set.
3. SOC feedback – Last but also important is to have your security team aware of company data when it lands in public view. This doesn’t have to be onerous or time consuming; simple crawlers with a list of vetted keywords and domains run as a cron job can go a long way towards finding data where it shouldn’t be. Of course the best case scenario is to prevent leaks before they happen, but swift detection and takedowns (remember you spoke to your lawyer?) can mitigate damage.
3rd party data breaches are happening at an accelerating pace and show no signs of abating. Secondary effects of these breaches tend to spread tendrils of insecurity much further than the individual site in question. Take some time now to talk to managers, your legal department, and your SOC now, and you can make sure that the next breach won’t be catastrophic for you as well.