Executive Series: How Secure is your Data?

September 4, 2017

We started this executive series with "HACKED, are you next?" where we covered the two primary types of software vulnerabilities: code and data. That article only covered the basic, and yes obvious, principals of code security. If you didn’t catch it, you'll want to read it after this article.


There's gold in them thar data


 Despite everything you hear about software and hacking, there's a sad reality in the software industry that this article aims to divulge. You hear it over and over from techies, developers, and media about code being hacked. News flash, code is rarely hacked; data is. In fact, it's not even hacked, it's just taken because it's left unsecured right there on your servers awaiting a hacker's arrival. Despite all of the talk about code being hacked, the reality is who cares about code? Hackers sure don't. They rarely break into a company's systems to steal code; they are there for the data.


Is it true? How can this even be true that such a massive industry-wide data vulnerable architecture can be in wide use? Well, the proof is in the pudding. You tell us, how in the world could J.C. Penney, Sally Beauty, Neiman Marcus, CNET and Target (twice!) be hacked, just to name a few (see for yourself)? Well, we're not really sure why architects the world ever permit this data immune-deficiency to continue, but it does and is likely lurking in your data store at this very moment.


Within the confines of this article lies the savior of your data. Right this second, your data lays there trustingly yet susceptible to prying eyes, vulnerable to the least sophisticated of hackers, so much so I strain to even call them that. By the end of this article, you'll be aghast at the fact that your data is left there to be accessed by any would-be attacker that can get past the slightest chink in your security-armor.


Not Knox, Who's there?


What if you went to the bank to open an account and right in the entry way sat the entire bank's heap of money? Would you open an account or keep on moving until you found a bank that knew how to secure your valuable possessions? Maybe you're expecting it by now, but would you be surprised if this is exactly how your data is secured?

The most common architecture in the industry is referred to as the multi-tier, N-tier, or 3-tier architecture. The tiers break down as follows: Presentation, Application (aka business logic/middle tier) and Data. Remember, the Data is the Securable, we have to make sure it's safe and sound. The Application tier is the one that makes a connection to the data store, retrieves data within the Data tier to return to the Presentation layer, applies business logic or inserts/updates/deletes data within the Data tier on behalf of the Presentation layer.


This is where the grievous mistake takes place within this decades old architecture, so pay attention. What if we assumed that the Application tier was on a 100% secure server? You know, what if the glass door entering the bank was all we needed for security? What kind of decisions would that lead us towards from an architectural perspective? Well, we could just make the assumption that the code being run from the Application tier is the code we assumed should be running and it hasn't just been taken over with some other code. In that case, it wouldn't much matter how we ensured things like authentication (which user is connecting) and authorization (which Securables they have access/privilege to). We could easily just write up some logic in our Application tier, make sure that code works, and we'd be golden. We're here to tell you, this fallacious thought process is at the very core of the 3 tier architecture and is what makes it systemically susceptible to hackers. Just like the bank with the heap of money in the foyer, your data is sitting there just waiting for an attacker to get past just one simple vulnerability and the jig is up.


Hard Knox Life


What if we, instead, assumed that the Application tier not just could be broken into but we assume it will be broken into. Now all of a sudden, this puts the Application tier into a whole new light. In the event of an attack, we can't just assume that the data will be kept secure by the Application tier. A few things become immediately apparent that can't be done within the Application tier:

  • Authentication

  • Authorization

  • Data Encryption/Data Decryption

If we do Authentication/Authorization within the Application tier, then this means that the data store isn't performing this itself and is left trusting whatever is sent to it from the Application tier. The same applies to encryption and decryption of data. If the Application tier is left performing encryption and decryption, then any hacker who gains access to a server running the Presentation layer will have access to the encryption keys by just executing code under the service account for the Presentation layer, a trivial task for even novice developers on [name a technology] (ASP.NET, Java, PHP, Ruby on Rails, etc., etc.).


If you haven't yet read our article "Hacked, are you next?", now's the time. The combination of the vulnerability multiplication within the Application tier and the inherently unsecured Data tier means your data is rife for the taking.


Sadly, many, many companies have propagated what are actually terrible data security practices by developing tools for enabling developers to get easier access to data from within the Application tier. Tools such as Object Relational Mappings are plentiful in the market and make it easy for developers to code up unsecured data solutions.

Major technologies are based on these vulnerability laden principles including but not limited to:


.NET, Java, PHP, WordPress, Drupal, Magento, Joomla, vBulletin, Expression Engine, DotNetNuke, etc., etc.


If you like this article, please share it.


Jeff Fischer

Please reload

Recent Posts

Please reload


Please reload


Please reload