• July 25, 2014

Carts and Horses (A reoccurring series)

Guest Author

Putting the Cart Before the Horse

In my years of experience I’ve had the opportunity to engage
so many different customers that I’ve lost count. In my professional life I have
spent maybe 9 or 10 years total as a contractor. If you assume that I have
engaged one new customer every 4 weeks as a contractor (which seems somewhat
accurate in my head), then that would be about 12 customers a year. That adds
up to some 120 customers in the 10 years – and to be honest that number seems pretty
low. I’m going to guess that number is
well over 150 or more – maybe even 200. The point is, I’ve seen an awful lot
out there. This gives me what I think is a unique prospective on things.

I am engaged in a discussion on LinkedIn.
In this discussion, the original poster (OP) asked a very basic question:

have two tables in single schema EMP1 and EMP2 with same structure. How can i
synchronize data bi-directionally in both of the tables ?

I engaged in the discussion, suggesting solutions and
shooting down other solutions. At the same time period, I was at a customer
meeting where it was clear that they had put the cart before the horse with
respect to their infrastructure, application and in particular, security.

As I was working these two situations together, it occurred to
me how they really define what I think is a very common problem in IT – Putting
the cart before the horse. In fact, I’d say that in many cases we put the cart
several MILES before the horse.

First, let’s look at the question that was asked on
LinkedIn. Do you see any problems with what is being asked, or are you just
chomping at the bit to provide a solution? If you’re a member of the later
faction, you are not alone. It’s easy to go there. We live in a day and age
when the technology solutions, hardware and software, are simply amazing. We
have solutions to problems that are exciting and I think that many of us love
the position of the designer, the solution provider and the creator. Indeed, we
love to create.

However, in both cases I think that solutions and deployment were premature. Important questions had not been asked and basic infrastructure requirements not addressed. Thus, the cart was put before the horse.

So it is, with these two events, that the idea of a series on "The Cart Before the Horse" came to be. In this light, the first thing I thought I'd address is security.

What is the cost of putting the cart (the application) before the horse (security architecture)?

In the zeal to create, we sometimes forget that everything we
create must have a solid foundation. I take you back to your childhood and the three
little pigs. The pigs that built the houses of straw and wood I believe might
well represent a lot of IT organizations.

Two of the pigs wanted to stand their houses up
fast, for little money and they did not properly perceive the threat in the
form of the Big Bad Wolf. It leaves you wondering, why did they ignore the Big
Bad Wolfs clear and present danger?The last pig, well he planned well, probably spent a bit more money for right foundation and architecture and survived the test of the Big Bad Wolf.

Sometimes I think it's just that there was not enough experience to understand that there was a big bad wolf, and he's out to get you. Sometimes, you understand that the big bad wolf is out there, but you don't know what you don't know. So you plan in ignorance. A little bit of research might have taught the pig who built his house of straw that straw does not withstand the normal forces of big bad wolf huffs and puffs. Perhaps that Pig might have hired a security consultant and found out what he didn't know.

Maybe the second pig saw what the first pig did, and thought to himself - This does not look very strong. Thus, by looking at the perceived mistakes of the first Pig, the second pig improved on the infrastructure of the first pig. However, it seems again that our second pig was working by the seat of his pants, not really knowing how to put together a structure that would survive big bad wolfs.

The third pig? I'm sure that he studied some architecture, learned about the physics of building and the loads that various materials would take. He probably talked to experts in the field. Most importantly, he took the Big Bad Wolf very seriously, and prepared for his arrival. He knew, at the end of the day, it was very hard to mitigate the failure of his little house as he was being turned over the spit. He had one opportunity to get it right, and he made the best of it.

How is it then that so many in IT, fully aware of the Big Bad Wolf and all the risks associated with the Big Bad Wolf, plan like being roasted on the spit once he huffs and puffs our house down is not a big deal? Here are my thoughts:

  1. We feel safety in numbers – The Big Bad Wolf is
    out there, but he will get someone else. We feel that just because he’s never
    attacked us before, that we are somehow immune from his attack now. Perhaps our
    little pigs figured that a 3:1 pig to wolf ratio would save them. At the end of
    the day, that little bit of bad planning almost cost them their lives, and
    certainly cost them two homes.
  2. We feel safety in our walled up environments –
    Usually we have built this castle, with what we think is an awesome moat, around our systems in the form of firewalls
    and other network related issues. The fact that we feel are systems are isolated
    from the outside world tends to reduce our concerns about exposure to risk
    vectors. Perhaps the three little pigs thought that with so many other pigs around,
    that they would probably get over looked. Perhaps they felt that the wolf would
    avoid them just because they had erected any kind of structure, looking for the
    easiest pig to eat. Either way, their ignorance about the nature of the wolf
    was very costly.
  3. We feel pressured to deliver – The little pigs,
    no doubt, were in a hurry to get a shelter over their heads, and we are often
    in just as much of a rush to get our application into production. Sometimes we
    get target fixation on our delivery goals, and forget that there is a serious
    cost to delivering something that works, but that isn’t secured. When something
    works well, when it works fast and all of the data is in good shape, that just
    means that the information a hacker can usurp is all that much better. In his
    mind, the hacker will thank you for all that you did to improve performance
    without impeding his work.

In the days when data breaches regularly occur, in quite
public ways, I’m still amazed at the resistance I get when I come into a
customer and I point out all of the holes in their security schema that exist.
Risk vector here, risk vector there, and so on – while the risks mount the desire
to acknowledge and mitigate these risks seems lacking too. Instead – there is
tunnel vision on delivery and budgets and a myriad of other technical hurdles
that face them. Somehow the notion of security seems to be an afterthought, or
something to be dealt with once things are in place and people can use the

This befuddles me. Releasing an application without giving
the security risks prudent analysis is very risky. The number of environments
that I’m aware of this practice just scares the willies out of me. The costs of
these breaches have been the subject of a number of studies. A 2013 study done
the Symantic Corporation and the Poneman Institute offer some guidelines as to
the cost. These companies do a yearly report on the impacts of data breaches. You
can find the report here.
Note that the report studies the average breach – not the huge breaches that
the press likes to paint pictures of. Any breach of over 100,000 records is
removed from the report because these outliers skew the report and are not representative
of normal breaches.

In the US, which had some of the most costly breaches, the
cost per record of a breach was $188.00 per record. The average organizational
cost of a data breach in the US was over five million dollars. If you complain
that your budget isn’t big enough, and your delivery timelines are not gracious
enough to factor in additional security work, does your company have an extra 5
million dollars hanging around to pay for the breach that will occur later down
the road?

$188.00 per record is quite expensive if you have lost 100,000
records ($18,800,000). That’s enough to break the smaller organization. Note
that if you are in certain high risk industries, like health care or
financials, your average cost per record is quite a bit higher than the
industry average ($233 and $215 per record on average).

If you are a larger organization, and you are dealing with
millions of records with PCI data, then the costs are going to be much higher.
Add to this that if you consolidate all of the causes of the breaches, the
highest reason for a breach in the U.S. was due to criminal attacks. Fully 41%
of attacks in the US are criminal in nature (as opposed to human error or
system error). Add to this that the cost of a malicious breach is actually
higher (around 25% higher) than the cost of other types breaches.

This means that someone is out there and they are actively looking
for your data, exploiting the holes that you have left in place. Looking for
your cart without a horse (or for the horse since it might be of more value).

What is more interesting is that the report identified the
factors that reduced the costs of breaches. In the US, the report indicates
that the biggest single factor in reducing the cost of breaches was:

“…by having a strong security posture [and] incident
response plan and CISO appointment.”


“..from the engagement of consultants to support data breach


I find the first statement the most compelling. It’s all
about being pro-active. It’s about acknowledging the risk, mitigating it from
the beginning and having an organization that deals with security issues.

The second statement is about accepting the breach has occurred
as quickly as possible and dealing with it. The benefits of these factors – a strong
security posture, a response plan, a CISO appointment and engaging experts all combine
together to reduce the average cost of a breach significantly.

Yet, the cost of architecting a system before it’s breached
is going to be much less than the cost of all of those consultants who will be
getting calls after the breach. Trust me on that one.

There is a lot more that the report discusses, and it’s
worth reading. In a world where the number of data records, especially those
with private data in them, is growing considerably – then the costs of data
breaches are going to grow as well. It’s my guess that these costs will not
scale in a linear way either for a number of reasons.

So, as I stand in a room and make the case for security. As
I think about the numberless breaches that have occurred in the public sector
alone – I can’t help but wonder what anyone is thinking when the response I get
is equivalent to: “We will get to that after we get into production.".

Indeed – the cart is before the horse. In fact, I’m not sure
there really is a horse anywhere to begin with… I think the horse is a mythical
being, just like the mythical environment is in many places and will be until it’s
too late.

Then – the old adage that you can pay me now – or you can
PAY me later – really applies.

So…. What are you going to do?

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.