DBA Training Week 5 - Risk, Governance, and Compliance

Risk isn't just a fun board game. Download the SQL Server Compliance Guide. It's an old 92-page whitepaper circa 2008, but it might just be the best (and most timeless) technical document that Microsoft has ever produced. I only need you to read pages 7-13. In those six pages, you'll understand the differences between risk management, governance, and compliance. Risk management means knowing what risks the company is taking with the data, governance means the actions taken to address the risks, and compliance means someone is double-checking that we're actually doing the governance stuff we say we're doing. Your job as a DBA involves all three, but when you're just getting started with compliance, focus on risk management. We need to get a quick idea of the different ways we could lose data, or that supposedly secure data could get into the wrong hands. (Yes, your developers are probably the wrong hands, but that's a different story.) Homework: Look for Risky BusinessOdds are, nobody in the company has an inventory of the data we're storing in ridiculously unsafe ways. Here's a quick way to check your own database looking for dangerous fields: SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME LIKE '%password%' OR COLUMN_NAME LIKE '%social%' OR COLUMN_NAME LIKE '%credit%' Feel free to change out those keywords for other terms that are relevant to your business - fields that are sensitive, and that would hurt if they got out into the wild. Then look at the contents of those tables - is the data being stored unencrypted? Who has access to it? If we're storing unencrypted passwords in the database, for example, then every database backup we've ever done is dangerous. If anybody gets access to any backup file, like our offsite tape backups, then we could be on the front page of the news tomorrow. When you find it, email the developers and the business contact for that database. Explain that the data is not encrypted, and use examples from the SQL Server Compliance Guide to show how this is a risk for the business. Compliance: Knowing Who's Accessing WhatIt's unusual for me to assign homework first in the email, and then go on to talk about other things, but I want you to be aware of other things that companies usually do around their secure data. Often management will say, "We need to audit everyone who changes or accesses secure data." Technically, SQL Server has features that can accomplish this goal - things like SQL Server Auditing. In practice, though, this is a problem for hard-core security teams because the very same DBA who manages the servers also has permissions to change the SQL Server audits. A greedy DBA could easily disable auditing, get the necessary data, and then enable it again. With seriously ambitious work, you can lock auditing down so that can't happen, but ... it's really, really hard. As a result, most seriously secure companies end up with a completely different auditing solution that lives outside of the DBA's realm. The security team buys third party hardware appliances like IBM Guardium or Imperva that act like a network firewall between everyone and the SQL Server. The appliance logs everything that happens in the SQL Server, and then the security team can review those logs without you (the DBA) knowing about it. These solutions are typically six figures and up. They're expensive because they have to be absolutely bulletproof - if they fail, you can't have the access to the database suddenly stop. Plus, you'll need them in place for not just your production environment, but also your disaster recovery environment. If you just want to check a box and make the auditors think you're secure, that's easy and cheap, but seriously good security is seriously expensive. Let me know what you think of the SQL Server Compliance Guide. Enjoy, and see you next week!