on "How to avoid a breach"
the journal of Michael Werneburg
twenty-seven years and one million words
I recently saw a LinkedIn post to an article titled, "Data breaches – how to effectively avoid them and manage them if they happen". It's a typical "GRC" treatment of the matter focusing on policies.
The article's coverage on responding after a breach is spot-on. Scenario planning and tests are key to drilling home the "who does what" lesson. It's costly and disruptive, but it works as demonstrated in the case of the Anthem breach, listed in the linked article.
But I'm afraid that the "kill chain" in cases like Anthem show that we've fairly recently gone back to a technology arms race that nullifies policy matters. There are fairly common and cheap means of defeating both the segregation of access by role and awareness training. The battle has moved from the server environment to the end-point (desktops, laptops, etc).
In these "advanced persistent threat" attacks, the first activity is typically identifying the most privileged users (e.g. by profile here on LinkedIn) and targeting them with a very well-known technical attack (spear phishing) by which the user's end-point system is captured simply by having users activate malware sent in an email. In these cases systems credentials across the enterprise are harvested. Tens of millions of full suite PII captured with negligible cost. Awareness training must be augmented by actual tests of user behavior, such as testing response to spear phishing emails. Also, robust end-point security has to be in place to enforce the segregation of user rights in the first place - especially for the most privileged users. Public Safety Canada has followed the lead of the Australian government in drawing up a list of the most important steps in preventing this sort of attack. SANS has published a very similar list. Again, the expense here is non-trivial.
Secondly, I suspect the abundance of data stored by organization frequently exceeds the needs of the firm. The credit card firms, for instance, are moving to tokenizing transactions to "de-risk" the data by withholding the credit card details themselves in the transaction. I suspect that we're also in the twilight of the dual purpose of a tax identifier (SIN, SSN) for credit bureau purposes. The dual use adds "street value" to what should otherwise be an inert tax identifier. This makes too many databases an attractive target, and makes too many organizations responsible for costly counter-measures.
The article raises a good point about insurance. I've found it necessary to understand exactly what's covered by errors & omissions and "cyber" insurance when it comes to a data breach, and to understand the insurer's view on what constitutes adequate prevention and response capability. To back-stop this, it's important to get a strong sense of just where the dollar impacts from a breach occur, and here I've turned to a method called "Factor Analysis of Information Risk". Early days, yet, but the initial results have been encouraging.