We are working with a software solution and setting up the SQL Server and general installation configuration for this environment and I stumbled on something that really caught my attention.
They were describing their security (all because SQL Server was involved, not because of their configuration and installation options by the way) and one of the qualifications of their security was simply “government-level security.” Huh?
Who decides what’s appropriate security? To me, it’s us, the data folks responsible, but when claims like this are made, I tend to see red and want to strangle someone. It’s just too vague and meaningless. And I’ve seen customers make actual purchase decisions based on this type of wild, odd claim too. “Most secure data protection!”
Oh my. Don’t get me started.
These are serious claims that require some real work on the back end. SQL Server supports all sorts of security measures of course. From encryption to user access controls and even development methodologies. Are all of those in play on the installation? What about connections? What about data at capture, transit and backups and all of that?
Somehow the people that shouldn’t have to know details need to be able to trust in claims. Somehow we, as data professionals, have to take this hill of trust. Trust in claims about our systems. We have to own statements made about our systems as well – so when someone says “kid tested and government approved” it has some sort of real meaning to it.
Perhaps we need a better way of conveying the core covenants of data protection are in place. Encryption, protection, recovery and such. We’d have to identify them, and in this world of “sorry, didn’t read the whole thing, tell me what it says” we need a way of saying “this is a 5 padlock implementation.” I’m not sure how we’d “enforce” that, but it’s critical that someone that flips the switch on a SQL Server on a cloud provider not be considered the same as someone that has deployed good web application firewalls, encryption, SQL injection protections, AI for abusive access and the like.
Remember to do a deep dive for the platforms you’re deploying. SQL Server has many different tools for determining security, for applying security, checking on configurations and such. There are many different tools you have for classifying information, for identifying unknown tables of information that should be protected differently, for encryption, for access controls. It’s all there, but it’s not a matter of “hey, I can connect!“