An audit trail is the easiest countermeasure or control that can be added to a database because if you do not have any audit trails then you don't know what is happening in the database. We have a audit toolkit called PFCLATK that can be used to design and implement audit trails really easily and quickly.
This toolkit and service is a set of PL/SQL and meta data that allows policy based audit (not the same as Unified audit) to be added. We can also use it with Unified audit or syslog as well. We combine different sources with audit and different policies and events. The toolkit is policy based and each policy is split in two. The policy includes what raw audit to collect and then how to test if an audit event has come true. So, an example could be:
@@check.sql "CORE: Create EVE.1.10 Policy"
begin
-- ---------------------------------------------------------------------------
-- create the policy
-- ---------------------------------------------------------------------------
pfclatk.createpolicy('EVE.1.10');
-- ---------------------------------------------------------------------------
-- create the rules to collect data
-- ---------------------------------------------------------------------------
pfclatk.createandaddrule('EVE.1.10','EVE.1.10:All Statements by special user','CORE-P','all statements',pfclatk.getfactor('SPECIAL-USER'));
pfclatk.createandaddrule('EVE.1.10','EVE.1.10:LOGON','TRIG-S','LOGON');
-- ---------------------------------------------------------------------------
-- create the filter
-- ---------------------------------------------------------------------------
pfclatk.addfilter('EVE.1.10:SPECIAL-USER','EVE.1.10','HALFDAY',
'[Alert] A Special user has performed actions',
'select ''{''||a.action_name||''} used by {''||a.username||''} using IP {''||p.ip_address||''} with error code {''||a.returncode||''}'' from dba_audit_trail a, pfclatk_audit p where a.username in ('||pfclatk.getfactorc('SPECIAL-USER')||') and a.sessionid=p.sessionid and p.audit_type=''LOGON''');
-- ---------------------------------------------------------------------------
-- enable the policy
-- ---------------------------------------------------------------------------
--pfclatk.enablepolicy('EVE.1.10');
end;
/
In this example the policy is created and is aimed at detecting if a defined special user has connected and then all statements that they execute. You can specify what a special user is. It could be a performance monitoring user or a third party connection user or what ever you choose. The policy is split into two sections; the first creates the collection rules in this case a logon trigger and also all statements. You specify the special users with factors that are used here. An example factor is:
...
pfclatk.addfactor('SPECIAL-USER','SCANNER');
pfclatk.addfactor('SPECIAL-USER','MONITOR');
...
The second half of the policy specifies the event filter. This checks if the event has occurred and this can be run on specified intervals such as ever few minutes, half a day or once a day or...
The PFCLATK toolkit takes care of running the filters. Enabling or disabling a policy turns on the lower level audit or trigger or....
So, this toolkit and service is great as we can help customers get a useful audit trail up and running very fast so if you have not got an audit trail and do not know who and what is going on in your database talk to us so that we can help you reduce your risk and worry.
So, back to the main part of the story. If we have a simple to use and comprehensive audit trail where we can easily specify what we want to audit and we can easily enable and disable individual events then this fact alone allows us to design and implement adaptive audit trails. Everyone (even us non Americans) have heard of the DEFCON levels, where DEFCON 5 is relatively safe and DEFCONE 1 could mean the outbreak of nuclear war. The USA has never been at DEFCON 1 as far as I know but was at DEFCON 2 during the Cuban missile crisis. We can imagine similar levels of audit trail in a database.
Audit level 5 would mean its safe, no sign of attacks and we should capture lighter audit. The heavier the audit the more audit data is created and then its more storage and more processing and more costs. So imagine that we are at AUDIT LEVEL 5 and we detect a lower level of attack signs. We can then increase the AUDIT LEVEL to 4 and turn on or enable more policies that capture more audit data. We can go right up to AUDIT LEVEL 1. Imagine that we know there is an attack we can then audit everything at AUDIT LEVEL 1. This would be onerous normally but necessary if we know there is a major issue.
The key idea here is we create some AUDIT LEVEL policies that use the same type of audit rules and events/filters/factors as above and we use these to detect potential changes in AUDIT LEVELS. The toolkit can handle an alert being detected automatically and the payload can be to enable or disable audit. So we have an adaptive audit system that could be used if needed. I would recommend that you set up a comprehensive audit first and enable it and use it before thinking about adaptive audit of course.
Because we can create a policy based audit where we can use events to take actions this means that we could/can also implement adaptive security using the same techniques and triggers (not database triggers). We can have different levels of database security and use audit levels to trigger changes in the actual Oracle database security. Of course you should not even consider this until you have a good level of Oracle security implemented already. We could have a situation where the database runs with a lower level of security (I don't mean no security) and if there is an attack detected we can raise the security level. For instance under normal security we allow connections from most IP addresses and most applications but if we decided to raise the security level we may only allow access to the database from critical applications and block others.
We can also link these ideas of adaptive audit and adaptive security across the whole estate of databases. If one database detects a possible AUDIT LEVEL that could mean an attack then it can signal all or groups of databases and they could increase their audit level or security level.
This is a really interesting area and can be powerful to implement.
