You can find many DAM definitions and be a little bit confused about dozens different features mentioned there but some of them is always indicated and can be considered as key requirements (DAM sensu stricto):
- 100% visibility of the access to data
- monitoring completely independent of database administrators
- analysis made on SQL level
- real time and correlated incident identification
- audit of events related with incidents
- support of forensic analysis
Some other features are not native for DAM but its popularity is now widely recognized as a DAM (DAM sensu lato):
- access blocking (this feature is generally part of DAMP – Database Activity Monitoring & Protection known also as DBF – Database Firewall)
- database user authorizations reporting
- sensitive data identification
- dynamic data masking (on database level)
- vulnerability management (whatever does it mean for requestor 😉 )
We can also identify some non-functional requirements related for any security solution:
- minimal influence on performance the monitored system
- support the heterogeneous database environment
- support for the enterprises
It is very difficult to compare solutions. Be sure that you compare “apples” to “apples” instead of “apples” to ” pears”. Very often the requested DAM feature works on different layer and it is covered by other solution (WAF, IPS, NG-Firewall, CM management).
Ask rather for solution support of your case and requirements than for the list the functions included in the vendor box.
#2 – Agent-base or Agent-less monitoring?
In case of DAM the answer on this question can be only one. 100% data traffic visibility is not possible if we will base on network sniffer (agent-less) because you are not able to monitor local sessions.
How your database is accessed:
- remotely (TCP, network pipes, encrypted connection)
- locally (TCP, shared memory, network pipes)
Only agent resided on managed environment can see local session and non-tcp protocols. It is hard to start up the polemics with this obvious statement. However some remarks are important:
- agent installed on monitored system has affect on it – but the question is about acceptable level of this performance influence and not about choice between agent-base and agent-less architecture
- agent requires updates, reconfiguration, database and system restarts – it can be true for particular solution but is false in case of Guardium
Only the agent-base monitoring ensures the DAM requirements coverage. Check your platform and protocols supportability. Check performance overload on your database.
Even you will be able to disable any local access to database you still assume that your network configuration is stable and all session are visible for sniffer what is not true at all.
#3 – Does your DAM prevent SQL Injection?
I love this stuff. This question is completely unrelated to SQL level, it is question about protection of web application.
If you would like to stop SQL Injection attacks the solution is easy – use WAF or IPS/NG Firewall. These types of solution work on network layer and are able to HTTP/S data de-encapsulation, parsing and identification of dangerous content (injected SQL string or its meta-form).
It is clinical example how use the one common known word in the name leads to misunderstanding the clue of the problem and its resolution.
SQL Injection must be analysed on HTTP/S layer. It has not related to DAM protection.
If your WAF or IPS will not able block the attack, the DAM will be still able to analyse the SQL syntax, session context and data reference. It is normal DAM task and should not be mistaken with SQL injection protection.
#4 – Can we build the Virtual Patch protection with DAM?
In many parts the answer is similar to SQL injection case but I will describe it deeper.
VP is a security approach to create protection outside vulnerable system. Some examples:
- system can be exploited but patch does not exist or it cannot be installed
- vulnerable functionality has to be available for particular subject only
- service has low reputation and whitelisting for activity required
There is many possibilities where DAM can provide VP protection:
- blocking access to vulnerable store procedure
- restrict access only from defined clients
- acceptance only defined list of SQL’s and operations on object
but if vulnerable element resides on database we need to consider situation that exploitation can lead to uncover other vector of attack. That is why VP should be defined on network layer using IPS and NG-firewall primarily.
DAM can act as an auxiliary in building VP. Network in-line protection should be considered mainly
#5 – What is your DAM data collection architecture?
Some solutions do not work in real-time and use DB logs or additional event collection mechanism to provide SQL visibility. If we do not need blocking this architecture could be accepted but this logging is dependent on DB administrators and does not provide any segregation of duties (for example, insider can modify or switch off the logging mechanism).
How the audit data are stored and managed by DAM is another architectural question. Would you like to switch from one audit console to another to check status of your monitored environment? Would like to remember which DAM box contains data required to current analysis? And the most important do you know what kind of stored audited data will be a key in your forensic searches?
DAM solution usually monitors heterogeneous environments, cover dozens databases and gathers terabytes audit archives in the retention period.
That is why I suggest consider this:
- possibility to manage DAM environment from one console
- possibility to aggregate data in case of de-duplication and performance distraction
- central reporting from all DAM boxes
- cross-reporting based on any parameter of the audit event
- offline forensic on restored archives
DAM is a key element of your security infrastructure. Be sure that its architecture limitation will not close possibility of development and integration
#6 – Why I do not see user names in DAM?
On SQL session level we see DB user name only. If you would like to get information about application user name related to particular SQL you need understand that this relation is created and managed by application server (queue manager).
Each DAM faces with this challenge and provides different solutions but every time it requires deeper analysis and sometimes application modification.
Guardium delivers many different solutions for Application User Translation in the pool of connection which are described here – “Guardium – App User Translation”.
Application User Translation (AUT) is a correlation process between application user and his SQL’s inside anonymised pool of connection.
Be sure that AUT does not work on simple correlation between time stamps in application and database. This kind of mapping in the multi-session channel is incredible and have no legal value.
#7 – I have SIEM, why I need DAM?
Security Information and Event Management (SIEM) systems are responsible for correlation the security events in the IT infrastructure to identify incidents. These tools base on the monitored system security logs, network activity, recognized vulnerabilities and reputation lists.
SIEM manages the security events delivered to it in the predefined schema, it is not able to understand HTTP requests of your appplication, SQL logic of your database transactions, commands executed by your administrator and so on. It expects that the monitored system will prepare the standardized output included relevant information which can be normalized and analyzed over the incident identification rules inside SIEM correlation engine.
Only DAM has ability to analyze each SQL and identify access to sensitive data, monitor privileged activity, correlate access to tables, predict the effect of taken by DML/DDL/DCL actions.
In most cases the SIEM licensing is based on EPS (Event per Second) metric. Even SIEM will contain the DAM intelligence and we would like to analyze all SQL’s inside it the cost of such a solution will be astronomical.
DAM delivers to SIEM analyzed security events in a constant data format, which enables their correlations with other monitored sources
DAM blocking capability is often requested but it should be considered very carefully. Most application traffic to database is related to transactional statements, where set of SQL’s and their order affects the analysis carried out and its effect. If we block one of calls in this sequence we can get an exception or worse, loss of data consistency.
The business security primates – confidentiality, integrity and availability (CIA) – leads to one possible conclusion that only session reset is safe method to block access because it avoids execution incomplete transactions.
However this method is useless in the pool of connection – reset of the SQL session kills the transactions from different application sessions.
That is why blocking was actively used only for non-application access to database while the application access was monitored with whitelisting.
Guardium 10 with Query/Rewrite feature redefined this approach. Now we can analyze SQL and replace it but not in order to change transaction’s body but to inform that it is suspicious activity and cancel its execution.
BEGIN TRANSACTION ... END TRANSACTION
BEGIN TRANSACTION ... (suspicious SQL) -> (redacted to set @PARAMETER) ... (@PARAMETER validation to cancel execution) END TRANSACTION
It requires small changes in the application but provides “blocking” on transaction level.
Only connection reset is acceptable form of blocking in most cases. For application traffic use Query/Rewrite