What we can learn from 2016: the year of the security breach

Ryan McGeehan, who specializes in helping companies recover from data-breaches, reflects on the worst year of data breaches (so far) and has some sound practical advice on how to reduce your risk and mitigate your losses: some easy wins are to get your staff to use password managers and two-factor authentication for their home computers (since everyone is expected to work in their off-hours, most home computers are an easy way to get into otherwise well-defended networks); and stress-test your network for breach recovery.

Another important observation that's harder to fix is that the startup model of tech incubation produces deep security problems: a startup with six months' runway has no rational reason to invest in security as opposed to continued operations, since shutting down the business is a worse failure-mode than a breach in the distant future (to have a breach, you have to survive). Most startups fail before they can breach, but most successful businesses were once startups incurring this technology debt, and few have resolved it.

This is especially urgent because firms that are uncertain of their future business models often make their offerings maximally surveillant, gathering data on their users on the off-chance that this turns out to be commercially useful in some theoretical future.

Nearly all of the organizations I assisted this year had an outlier area of staggering technical debt.

This leads me to believe that companies that consider "debt" as part of engineering process are usually highly disciplined organizations, with lower risk.

Here's why: A startup can move fast. They can cut corners. They can compete aggressively and take risks.

During development and a successful launch, a difference from one company to the next is how well they've documented the shortcuts and have had a "retrospective" on what their debt level has become.

Then they pay back their debts.

Rarely do I see a team eliminate all of their debt, but the organizations that at least respect their debt never get so far behind that they can no longer be helped in a breach.

Debt comes in many forms: scale, development speed, site reliability, customer churn, manual work before automation, and security.

The problem is that security debt is silent. Every other form of debt causes errors, customer complaints, expenses, and engineer rage. Security debt only results in breaches and is near impossible to quantify. It requires manual effort or a technology harness to surface security debt.