Database Security: The Other First Steps
Going through my feed reader this morning when I ran across this post on Dark Reading about Your First Three Steps for database security. As these are supposed to be your first steps with database security, the suggestions not only struck me as places I would not start, it offered a method that I would not employ. I believe that there there is a better way to proceed, so I offer you my alternative set of recommendations. The biggest issue I had with the article was not that these steps did not improve security, or that the tools were not right for the job, but the path you are taken down by performing these steps are the wrong ones. Theoretically its a good idea to understand the scope of the database security challenge when starting, but infeasible in practice. Databases are large, complex applications, and starting with a grand plan on how to deal with all of them is a great way to grind the process to a halt and require multiple restarts when your plan beaks apart. This article advises you start your process by cataloging every single database instance, and then try to catalog all of the sensitive data in those databases. This is the security equivalent to a ‘cartesian product’ with a database select statement. And just as it is with database queries, it results in an enormous, unwieldy amount of data. You can labor through the result and determine what to protect, but not how. At Securosis, we’re all about simplifying security, I am a personal advocate of the ‘divide and conquer’ methodology. Start small. Pick the one or two critical databases in your organization, and start there. Your database administrator knows which database is the critical one. Heck, even your CFO knows which one that is: it’s that giant SAP/Oracle one in the corner that he is still pissed off he had to sign the $10 million dollar requisition for. Now, here are the basics steps: Patch your databases to address most known security issues. Highly recommended you test the patch prior to operational deployment. Configuring your database. Consult the vendor recommendations on security. You will need to balance these suggestions with operational consistency (i.e. don’t break you applications). There are also third party security practitioners who offer advice on their blogs for free, and free assessment tools that will help a lot. Get rid of the default passwords, remove unneeded user accounts, and make sure that nothing (users, web connections, stored procedures, modules, etc) is available to the ‘public’. Consider this an education exercise to provide base understanding of what needs to be addressed and how best to proceed. At this point you should be ready to a) you can document what exactly your ‘corporate configuration policies’ are and b) develop a tiered plan of action to tackle databases in descending order of priority. Keep in mind that these are just a fraction of the preventative security controls you might employ, and does not address active security measures or forensic analysis. You are still a ways off from employing more intermediate and advanced security stuff … like Database Activity Monitoring, auditing and Data Loss Prevention. Share:
