Online Exclusive: X is to Y is to Z – Breaches are Cheaper than Security Investments...

One thing to consider, when facing the virtual ban hammer of budget land, is that there are plenty of open source tools available for use.

• By Corey Wilburn
• Oct 20, 2016

The term “Too Big To Fail” is a commonly heard saying, made prominent by the economic crash in the 2008-2010 era.  I’ll save you the detailed explanation of where this statement came from, as I am sure you are quite familiar with it.  What is of interest to me is that the general format for this statement, when broken down, is (X is too Y to Z).  The evaluation of this format becomes interesting when we see it being used to form statements relevant to the work that we do as security practitioners. 

 Let’s make some statement examples, using the format above, and see how they feel:

• X(My budget) is too Y(small) to Z(to implement specific security controls).
• X(My company) is too Y(obscure) to Z(to be targeted by adversaries)

Just as the statement “Financial institutions are too big to fail” – the examples I gave hopefully stir up a bit of unease.  Yet, it is not uncommon to hear these statements when discussing the need to establish appropriate and often times reasonable information security best practices and standards.

When speaking to colleagues in the field, some common elements come up in conversations.  Luckily many people that I speak to, “get it”.  There are still some outliers in the mist, that will make, what appear to be reasonable at the time, statements using the (X is too Y to Z) format. Bottom-lines, budgets, cost, and ROI – are all valid business justifications for determining acceptable risk thresholds in an organization, and basing decisions on what is considered a good security investment vs a bad security investment.  Assessing risk and mitigating controls to ascertain the true value of an investment takes a bit of operational overhead if it is not already a component of the business culture.  So we end up seeing (X is too Y to Z) as a means justify side-stepping the issues at hand.

How do we shift from the (X is too Y to Z) mindset to one that better serves the organizations that we protect?  I don’t know if there is a single answer to that question, and for most, it takes a breach, or some other security concern to challenge individuals to take the actions that (X is too Y to Z) steered them away from.

One thing to consider, when facing the virtual ban hammer of budget land, is that there are plenty of open source tools available for use.  Many of these tools do great things, with the only investment needed being a little elbow grease and perhaps some fractions of compute.  They can help offset budgets and fill gaps, when you run into roadblocks put up by (X is too Y to Z).  Many of these offer some actionable metrics that should enable you to turn the tables on the (X is too Y to Z) objection and perhaps allow you to use the format to motivate upper management; X(Our exposure to risk) is too Y(great($Metric)) to Z(to continue operating in this manner.)

 In the meantime, we can continue to hope that the (X is too Y to Z) concept will be a passing fad.  That instead of hearing, “My company is too small to be breached… too obscure to be breached… too this or that to be something”, we will see a continued trend of more companies escalating security from merely a perimeter, or infrastructure viewpoint, and coming to understand that the principled exercise of practicing security enables business, instead of disabling it.