©2018 BY SOFTWARE BUSINESS BOOTCAMP

Executive Series: HACKED, are you next?

September 4, 2017

Home Depot, Target, J.C. Penny, Sally Beauty, Ebay, Neiman Marcus, CNET, all hacked, are you next?

 

 

Every day I find myself more thankful than the last for a keen sense of numbers. Am I mathematical genius? Absolutely not. I am, however, keenly aware of scales and magnitudes of order. It's a constant focus for me. Something that seems to be an awkward to identify, yet highly valuable, skill. Throughout my career as a software developer there has been an underlying, unspoken and largely unidentified theme that I have recognized that I will share with you today. You'll want to read this article because it could very well mean the demise of your business if you don't. Just today, Home Depot Hacked - let's make sure your business isn't next.

 

Why me?

 

Anybody on LinkedIn could write an article on software and hacking, especially an opinion piece. This is not an opinion piece. After 17 years in the industry including 5 as an FTE at Microsoft, I've had the pleasure of working on some of the largest, highest availability and highest performance websites in the world from the frontend to the backend. I've found a single-request major vulnerability on an e-commerce site that grosses $500M/yr that was immediately fixed upon identification. Oh, and there's that awkward to identify skill I mentioned above. What lives within this series of articles is 100% fact. Most developers aren't going understand it and those that do, won't like it.

 

Break it down

 

There are two primary types of vulnerabilities within the software industry: Code and Data. This particular article is completely oriented around architectural coding practices and says very little about data. It is extremely important (likely more important) that you also read our accompanying article "How Secure is your Data?" to fully understand the gaping holes you likely have in your data security.

 

The code multiplies like bunnies

 

I can help you understand the problem with the software industry's coding practices and how they lead to security vulnerabilities in less than 10 seconds. Which of these building types is more secure, A or B (all of them combined)?

 

A.

 

B.

 

I bet it just took you 2 seconds to identify 1/2 of the software industry's security issues. It's not rocket science to identify the security vulnerability here, right? Option B is likely 100,000x less secure than Option A. We'll do a brief pass through the list: B has hundreds or thousands of attack surfaces; the material used in B is less secure; there's likely a wide variability of people applying different techniques to each Securable (files, tables, views, procedures, functions, etc); there are a wide variety of skill levels used to build each Securable.

 

Surprisingly, this simple example completely eludes the software industry as a whole. I find it surprising primarily because it defies the laws of reason and wisdom, which unfortunately seem to be a waning skill in today's culture.

 

MORE! (is less)

 

Want the general rule of thumb for how large your software attack surface is? The easiest way to gauge whether your team is writing secure code or not is simply by the software team size. How large is your team?

  1. Between 1 and 5 people

  2. Between 6 and 10 people

  3. Between 11 and 50 people

  4. Between 51 and 100 people

  5. More than 100 people

Once you understand how software is developed and how security is built into software, you quickly realize that the larger your team gets, the exponentially more difficult it is to secure your software. Option 1 is the only truly secure option and even if you chose option 1 you'd also have to choose Option A (above) and ensure that the team members are each security conscious to ensure proper Code Security. Allow me to explain.

Back on the homes analogy, if you were you planning on building a secure home would you plan that prior to beginning construction or would you try to create a secure home once the home is finished being built? Despite the fact that code can't be secured this way, the software industry most often does the latter of these two. That's if it does a security review at all!

 

Given the fact that post-securing any software is a recipe for disaster, now you can realize what a challenge creating secure software from a large Software Development team holds. There are a few realities with regard to a Software Developer's security knowledge. Software Developers have both varying levels of skill as developers and varying levels of security skill. You know you can't secure software after the fact, so what happens when one of the developers you hire literally writes new security vulnerabilities into the software they're creating? Just like with Option B in the first example, you end up with varying levels of security throughout your Securables.

 

The other fundamental reality of software is that the more developers you have, the more code they write (and consequently have to maintain/bug fix) because you wouldn't have more developers if they weren't writing lots of code. The more code they write (and maintain/bug fix), the more attack surface they create just like Option B above. There is absolutely no way around this, it is an unequivocal law of software. So, what are the solutions to these problems?

 

Help-Less!

 

Well, small teams are the starting point. Small teams enable you to hire experienced professional developers who are adept at writing secure code from the ground up. Starting with and keeping a small team will force code to be written correctly using an engine-style development approach that won't create a growing-ever-larger code base which is the Achilles Heel of secure, fast time to market, high performance/scale and extremely extensible software projects the world over. Engine-style development creates between tens and hundreds of thousands less attack surface area within the codebase, which is consequently extremely secure. Small teams also enable appropriate communication, planning and preparation which is exponentially more complicated on increasingly larger teams. These human factors are seemingly under-estimated within the software industry. All combined, the result should be extremely secure code that is substantially faster to market.

 

To those with large teams, the question to you isn't so much whether you have vulnerabilities or not since, as I've described here, the probability is extraordinarily high that you do. The question is whether you are in someone's sights either now or as you grow larger whether you will land in someone's sites. The larger your business grows (and the more data you have to steal), the more incentive there is to be attacked whether for financial gain or media attention.

 

The very best way to grow a software team is not to grow one at all. The reality is that it takes years to build an excellent (especially highly security conscious) software team and can be the difference for many companies between being extraordinarily successful or not (or worse, broke from a security breach).

 

I can't tell you how many times I've heard business owners say and justify unsecured solutions or lack of security testing with, "It hasn't happened to me." That one little word they always seem to forget is "yet". It hadn't happened to Target until 2007, but when it did it cost them $265M or more than 10x the original estimate. Their being 90% inaccurate on their estimate means they likely had absolutely no idea what kind of risk they were taking on (even after the breach had happened!!) and what the accurate cost of a breach would be. What is the risk in dollars to your business of a hack? Just remember, you may end up multiplying that number by more than 10 times.

 

Just something to let simmer. What could Target have paid some high value developers to thwart this attack? If we take only the cost of Target's 2007 attack (not the 2013 hack), they could have paid 2 contract developers $12.5M/yr for 4 years (between 2003 and 2007) and still come out $165M ahead, assuming they could have thwarted that attack. So, the next time you go to hire a developer (hopefully a vendor), ask yourself if you should pay them $12.5M/yr to ensure you don't end up with a $256M unexpected loss and who knows how much loss of goodwill.

We have an article on How to build a Software Team coming soon, so stay tuned.

 

One final parting comment to leave you with. Despite the importance of your code, it is best to recognize that very, very few companies in the world have valuable code. 99% of companies have one thing of value that hackers want - Data. Ensuring that your data is secure is tantamount to the success of your business. Don't forget to read our article "How Secure is Your Data?" to ensure you understand the core principles surrounding this subject.

 

If you like this article, please share it.  Thanks for reading.

 
Jeff Fischer
Please reload

Recent Posts

Please reload

Archive

Please reload

Tags

Please reload