You know you should be looking at a strategy to address the key areas of risk to the most valuable resource within your organisation – the data held on your databases. You also know you need to put in place controls to identify the immediate areas of threat to your databases, and give management an independent alerting and reporting process to put forward for accurate sign off to industry regulators and audit firms . But where do you start?
Should I look at assessing the vulnerability position of our databases as a first step? Or put in place a monitoring solution to track the activity of Privileged Users within the organisation? Or should I make sure that I can see what is happening on our key financial tables and sensitive data on our databases as a first challenge?
The truth is they could all have a valid argument for being the first steps in auditing what is actually happening on your databases which could put the organisation at risk. However, before you decide what areas of risk you need to monitor you need to know what risks you’ve got to the databases you have to enable you to put a proper strategic plan in place.
Privileged User activity monitoring (a huge area of potential risk to an organisations databases) is definitely an area of control which should be addressed at the beginning of any database auditing strategy but not totally at the expense of looking at where you could be potentially exposed to vulnerable positions on your databases where malicious activity could be taking place. Also, key financial tables or sensitive data should quite rightly be monitored at an early stage to alert and report to management on any anomalous activity.
However, first up, you should look at where all of your current areas of risk are on your databases to enable you to decide what action you should take first, and here are the steps we would recommend you take as part of any database auditing strategy you are considering –
1) Vulnerability Position – perform a detailed audit of your current database set up to assess the security position of your databases (not just critical security patch updates)
2) Review - define a plan to resolve, and remedy, any security vulnerabilities found against best practices to secure the source of the data first up
3) Immediate Audit Requirements – identify key Privileged Users and key databases you wish to audit
4) External Audit Requirements – identify key Regulatory, Compliance, and Audit requirements you need to meet
5) Internal Audit Requirements – identify key internal audit controls you need to implement
6) Specify – map Immediate, External and Internal Audit requirements to defined Policies and map to your database estate
7) Choose Audit Technology – look at marketplace to see which audit tool best meets the audit requirements which you have
8) Roll Out – deploy automated auditing and reporting solution of Audit Policies across your estate
9) Monitor / Compliance – implement Alerting, Monitoring and Review processes to report to management all areas of risk to the organisations databases as part of an automated IT controls framework
Whichever way you come at it, assess the total area of risk to your databases first and don’t just put a sticking plaster where you think there is a hole. You will end up trying to make a technology fit a specific area of risk without really seeing if is the right solution to fit the overall risk strategy for the organisation.