Johannesburg, 16 Oct 2017
Database activity monitoring is the backbone of database security. If you don't know what is going on in your database, then you have no control over the sensitive data in your custody.
Without monitoring, you will have no idea of what has happened to your database or what is happening to your database. You will have no knowledge of data theft, fraud or malicious activity.
Not having control over sensitive data is the biggest risk an organisation can face, and without effective database activity monitoring, organisations will flounder in a sea of cyber crime.
Some critical questions to ask yourself!
1. Do you monitor traffic to your database for unexpected activity, such as unauthorised access and privileges or role escalation?
2. Can you prove to auditors that only authorised business owners have access to information?
3. Can you prove to your auditors that you are blocking threats from reaching any of your databases?
4. Can you prevent your system and database administrators from reading or tampering with sensitive information in your payroll, HR, financial or any other sensitive business applications?
5. Can you prevent users from bypassing applications and gaining access to application data directly?
6. Would you know if someone made an unauthorised configuration change?
7. Do you know who did what, when, and how, to data in real-time?
8. Can you prove that privileged users are not abusing their authority?
9. Can you detect or prevent privileged users hiding their tracks?
10. Is your audit reporting automated?
11. Do you have real-time data breach alerting?
12. Have you implemented segregation of duties at the IT level?
Doubts?
If you have answered 'no' to any of the above questions, then you are definitely at risk and you should read on.
Privileged user abuse
Application security alone is insufficient to prevent unauthorised access to sensitive data as there are many ways to log into a database without an app or front end. Privileged user abuse is made very easy with the availability of a wide selection of products and tools that simply circumvent application security and thereby gain unauthorised access to sensitive data.
Database administrator
The DBA is the ultimate power user who can view any table in the database and also typically manages database functions such as security and auditing. You can immediately conclude that this creates a massive conflict of interest.
You may trust your current DBA explicitly, but people come and go and the replacement resource may not be as trustworthy. Hackers also target privileged accounts which make the DBA top of the list, so security based on trust is a data breach waiting to happen.
Systems administrators
Edward Snowden was a systems administrator. Enough said.
Segregation of duties
Even though systems administrators and database administrators are the 'all powerful' users, it is important to remember their job function has absolutely no requirement for them to view sensitive data and such activity should be monitored and blocked.
Database activity monitoring needs to be implemented and managed by security resources other than your system administrators and database administrators. This is crucial for the enforcement or segregation of duties and ensuring data integrity, otherwise unauthorised activity is easily covered up or deleted.
Insider threat
Insider threat is one of the biggest security concerns for organisations today and this is the most important reason to monitor access to sensitive data and for enforcing segregation of duties.
2016 security statistics revealed 59% of employees steal sensitive information when they resign!
https://www.pcworld.com/article/160041/two_thirds_ex_employees_steal_data.html
Authorised access to sensitive data
Of course, users do have legitimate access to sensitive data as required by certain job functions, but on the flip side, it also opens up an opportunity for undetectable data theft. To mitigate this risk as much as possible, access should be defined by certain rule sets, such as time and day of week, type of connection, IP address and volume of data accessed. Access to sensitive data within these rule sets should be considered 'normal' work activity and not raise any exceptions, but access to sensitive data outside of these rule sets should be considered an exception and should be investigated immediately.
What should be monitored?
This is not an exhaustive list, but presents some core monitoring requirements:
1. Data manipulation language (DML) activity against sensitive data.
2. Data definition language (DDL) activity - create/alter/drop.
3. Data control language (DCL) activity - grant/revoke.
4. Database structure changes, parameter changes.
5. Excessive or large volume access to sensitive data.
6. Logins/failed logins/brute force attempts.
7. Unauthorised connections, ie, TOAD/ODBC/JDBC/Excel/Access/report writing tools.
8. Unauthorised data dumps, backups, bulk extracts.
9. Connections from unauthorised sources.
10. Connections from unauthorised binaries or programs.
11. Out of hours access.
Change control processes
There is inherent risk in making any type of change to a database or an application. The majority of errors or outages occur because something has been changed. Being able to monitor and report on such changes gives an organisation the opportunity to reconcile these with the change management process to determine if the changes were authorised or not.
General rules
If you monitor too much database activity and/or unnecessary database activity then it is very likely that your monitoring solution will get overloaded and you will no longer be able to extract value from it. You need to fine-tune your activity monitoring so that there are as few false positives as possible. Too many false positives will eventually lead to audit and alerting messages being ignored.
1. Don't monitor authorised activity; this is what users are supposed to be doing. These messages are unnecessary and clog the system.
2. Only monitor unauthorised activity; that which users should not be doing.
3. Monitor in detail only if you suspect something.
4. Monitor exceptions.
5. Do not audit DEV, TEST, UAT or any other non-production environment. Rather mask any sensitive data in these environments. Monitoring other environments will generate a lot of false positives and flood the audit trail. This will make analysis time consuming or next to impossible and in turn devalue the security solution and render it ineffective.
Solution
Encryptech can implement a database activity monitoring solution on-premises, or it can offer you a database activity monitoring solution as a service.
For more information on its data activity monitoring services, please contact Encryptech on:
info@encryptech.co.za
+27 11 593 2394
http://www.encryptech.co.za/
Share