Carts and Horses (A reoccurring series)

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:

I 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 system.

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 remediation.”


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?


Post a Comment:
  • HTML Syntax: NOT allowed

Welcome to Robert G. Freeman's Oracle Blog. My specific interest is with Oracle Database and Oracle Exadata. I've been involved with Oracle databases for over two decades and have worked for Oracle now for over 4 years. Site Meter

  • Subscribe by Email
  • Search

    « July 2016