Database security is a funny thing-- most everyone 'should' be implementing it and we assume they are, yet those who are not are highly likely NOT to admit it, which I believe calls into question any data security survey published to date where respondents are asked to answer questions on whether or not they secure sensitive data. Over the past several years, I have noticed a trend in database security, which has become more like a large wave. 'Way back when' in the open systems world, it was perfectly acceptable to perform an installation with Administrator or even root privileges, use generic userid's that everyone shared, sometimes even post them with sticky notes on the side of a computer monitor, and give the DBA full access to the entire system, data included. As the number and impact of breaches has increased, so has the awareness of how important it is to implement security controls on the database. Awareness, yes, implementation....... well not so much! It's even more shocking to me, since databases are by far the largest source of compromised records. According to the latest Verizon Business Risk Team Survey for 2012,
while only 7% of breaches involve a database server, they account for a whopping 96% of compromised records and 98% for larger organizations. (Full study is here: http://tinyurl.com/btrasnu
I have also observed that organizations who rely on mainframes tend to have much cleaner security and housekeeping rules, even around things like change control. The irony of it is that those systems are also much harder to breach! How many hackers do you know who can write assembler code? The clients I work with (who shall rename nameless) vary in their approaches and level of controls used. At one end of the spectrum, I had a former client who used the same password for all DB2 instance owners across all systems. That password was also shared by a large number of DBA's and developers both. Very convenient, yes.... also very risky! At the other end, is a company who has completely segregrated the DBA work from any systems work. Even creation of the database is completely locked down. Good controls, yes, though they did slow us down for a couple of days while we waited for the database creation request. This organization is also in the process of rolling out Database Activity Monitoring across the enterprise as well as Data Privacy (Masking) for Test Data. On top of that, they have very strong support for Information Governance from the executive level on down. That company, I might add, had previously experienced a major breach, actually two, so are now actively engaged in ensuring proper controls are implemented.
Breaches can be expensive, embarrassing, and costly in terms of corporate and brand reputation. Just like with physical security, there is also no silver bullet or single way to implement database security. Case in point- a jewelry store. A high end jewelry store will employ many methods to secure its valuable assets. First, perimeter security- making sure there are no hiding places, shrubbery, or easy access methods like open windows or roof vents; Second, one or more alarm systems or motion detectors around the permises, or even on specific items or cases. Third, security personnel at the door, and inside the store. Forth, security practices such as having the salesperson only take out a certain number of items at a time. Lastly, security cameras to record activity. If you think of database monitoring in this way, you can see that multiple methods and practices must be employed.
In a recent article entitled "Establishing a Strategy for Database Security Is No Longer Optional", Jeffrey Wheatman of Gartner brings database security to prime time. In this paper, he does a good job of laying out the different aspects of database security, along with some basic best practices recommendations. I especially appreciated how he defines the different categories: Administrative Controls, Preventive Controls, and Detective Controls ( though I would rename Detective to Investigative Controls). If you would like a copy of this paper, follow this link: https://www14.software.ibm.com/webapp/iwm/web/signup.do?lang=en_US&source=sw-infomgt&S_PKG=500021641&S_CMP=Guardium_Gartner_data_security_not_optional_analyst_lib
One area that Wheatman did not cover, which would seem obvious and critical, is the need for process controls, even extending to hiring practices and sharing of credentials. We all like to think that IT personnel are law-abiding citizens. However, there has been more than one case where DBA's and other personnel with criminal records went and 'borrowed' sensitive customer data, incuding credit cards and account numbers. The good news is there is now a certain level of maturity in the database marketplace to provide the needed multiple levels of security for organizations to lock down their valuable data assets. Most every RDBMS now supports roles and privileges, auditing, non-administrative installation, as well as column/row level security. Combined with preventive controls such as encryption and masking, investigative controls such as database activity monitoring, and process controls, organizations can now design and implement a stringent database security practice that meets the needs of business and regulatory requirements.
Data Security: http://www.darkreading.com/
Database Privacy and Masking: http://www-01.ibm.com/software/data/optim/protect-data-privacy/
Database Monitoring, Security, Encryption: http://www-01.ibm.com/software/data/guardium/
Next, do you know where your sensitive data is located?