Data is King, Security is Queen

Data and Security should go together like king and queen, peanut butter and jelly. They should be stuck side by side with security oozing from the edges. 

Many years ago when the Internet and I were young I noticed the value of data and then security. I was a young Airman in the Air National Guard attending the annual Air Force IT Conference in Montgomery Alabama in 1997. The Air Force was just getting started with its "Paperless" initiative. I was networking with other Network Administrators and vendors on how we can use the web to improve efficiency and decrease repetitive data entry.  

I told one of the IT Leaders in Washington DC that the Air Force spends way too much time and effort on duplicating the visual elements of forms and signatures of the past and instead needed to focus on the data within the forms. I knew then that the data was king and everything else should serve the king. I had a bone to pick about this topic because we were filling out electronic forms, printing them, scanning them and then submitting them. We had the capability to electronically sign forms but that was not acceptable in any case and not possible in most cases because the forms were not enabled for that. What's more is that nobody seemed to care. 

I had already called the Air Force Electronic Publication office and questioned why Digital Signatures were not enabled. They had a simple answer, it was not part of their contract to include Digital Signatures. However, they did tell me that it would be possible for me to work with the Air Force Department that owns the form to enable Digital Signatures. That is what I started doing but it wasn't easy. 

I had a quest to change Air Force (or at least the Air National Guard) thinking about forms and data. I constantly argued that the current implementation of electronic forms were useless and costly. The cost of storing the data was much cheaper than storing the static image of a form. I also knew that we could reduce repetitive data entry by storing common data and then only storing the important information, the intent of the form and not the form itself. 

My second concern was Security of the data in relation to the CIA Triad (before I even knew what it was). I wanted to separate data from the user interface, provide security for the data itself without too much concern for duplicating the visual representation. I was a firewall administrator so a lot of my ideas came from how a firewall worked. You are denied access by default unless someone has given you access to certain data and you could only perform certain actions. I also wanted the date to be compartmentalized with some sort of control in a process I called "Blue Ink." 

The idea behind Blue Ink was that there would be one true original of data and only one. Any copy of the data would result in "Black Data" to indicate it was a copy. Various applications could use data from the other sources but the Blue Ink data would not change except by the owner of the original. 

In addition, end users would not need to see or modify common data because that information already existed. There would be no reason to provide home address, Social Security Number, department or supervisor. However, in addition to providing authentication credentials for the transaction, there may be some data needed in order to validate user authentication.  

Fast forward to today and a lot of things have changed but the challenges still remain. Things are much more automated, systems are more integrated and data is everywhere. With the amount of data available, the ease of access to data and value of data, the protection of it has increased. Authenticated access, data integrity and availability are more important now than ever.  

The availability of data is a current trend with Ransomware on the rise. Hackers are not focused on the value of the data on the black market but the value of data to the owners. They cannot only lock the data itself, but also lock access to the data.  

If Ransomware does anything positive, it should wake people up to the need to follow sound security practices. There are always risks that cannot be fully eliminated but by incorporating security into all processes, the risks are manageable and reduced. Separating data from other application tiers is only as good as the security around the entire application. Security can be applied to any application framework but needs to be a part of every tier from the beginning. I am not a Developer but think each tier should have its own Security Engineer who ensures security integration within that tier as well as security interoperability between tiers. As elementary as it sounds, security is often the lowest priority and sacrificed in order fulfill delivery. 

Data will continue to grow at an astounding pace. Data markets will thrive as data becomes more consumable, more standardized, more timely and more valuable. Analytics will increase in step and bring about more accuracy. Security will change in order to continue providing confidentiality, integrity and availability for data. 

Date and security are stuck together to the end. You will not be able to take a byte without tasting both. Data and security are in for a wild ride. Data just needs to tell security, "Be my queen if you know what I mean and let us do the wild thing!