Oracle databases are commonly used across many businesses to manage and store a large amount of data in a multiuser environment, so that many users can concurrently access the same data.

Even though these databases hold a large amount of sensitive information, they are regularly forgotten about when it comes to security monitoring. To fix that, here are 7 SIEM rules to monitor for malicious or suspicious behavior.

Required Logging

Before we can set up these rules, you need to ensure that the databases are sending the correct logs to your SIEM of choice. Talk to your Oracle database administrator and ensure the following events are being logged to syslog.config by the Oracle RDBMS Audit Record.

CREATE USER, DROP USER, ACCOUNT LOCK, ACCOUNT UNLOCK, DROP DATABASE

All messages containing SYS.AUD$ and “SYS”.”AUD$”

All messages starting GRANT

All messages starting STARTUP and SHUTDOWN

You can find more information at the auditing database activity post by Oracle here. All of the above should be enabled by default however as above please check with Oracle administrators.

Once you have checked and tested that the all of the above logs are coming into your SIEM, there is one final step. You will want to setup an indexed field which parses the action being made in the database, as this will be used in every rule.

Now lets get into the rule logic – these are not complicated in anyway however are very valuable in terms of security monitoring.

User Added or Removed

The first thing we want to monitor for is any users being added or removed from a database. Any user being created or deleted should be verified to ensure the behavior is legitimate and not malicious.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action is CREATE USER or DROP USER

Account Locked or Unlocked

Next up, we want to monitor for any database accounts being locked or unlocked. Any unlocks should be verified and any lockouts could indicate brute force activity against an account.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action is ACCOUNT LOCK or ACCOUNT UNLOCK

Database being deleted

Any database being deleted should be investigated further for obvious reasons. Changes such as this should be validated as it could be an attacker covering their tracks, causing disruption or a disgruntled employee.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action is DROP DATABASE

Database being stopped or started

Another important activity to monitor for is anytime a database is stopped or started. This could indicate that someone is making changes to a database and attempting to perform a restart to enforce these changes. A fresh start could also indicate a new database being created. There are lots of reasons here really – it is just important we confirm that a database being stopped or started was a legitimate activity.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action matches this regular expression ^(?i)STARTUP|SHUTDOWN (This is looking for the action starting with STARTUP or SHUTDOWN, regardless of case.)

Account being granted SYSASM or SYSDBA

This is the most critical use case here. SYSASM allows administration over storage whereas SYSDBA allows administration over the database itself. It is therefore important we monitor for any accounts being granted these rights.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action matches this regular expression ^(?i)GRANT SYSDBA|GRANT SYSASM

Database rights being granted

It is also important that we monitor for any other rights being granted on a database, not just those above.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action matches this regular expression ^(?i)GRANT
• Oracle Action DOES NOT MATCH this regular expression ^(?i)GRANT SYSDBA|GRANT SYSASM

Changes being made to database audit table

Finally, it is important to monitor any changes being made to the audit table. This is to ensure no logs are modified or deleted – a common behavior of attackers to cover their tracks.

• Log Source is Oracle RDBMS Audit Record
• Oracle Action contains either SYS.AUD$ or “SYS”.”AUD$”

What next?

You have the correct logs coming in and monitoring set up – what next? I recommend ensuring you have clear way of verifying database changes, whether this be direct contact with the team or via a ticketing system such as Service Now.

This will ensure you can act upon alerts quickly and verify if behavior and changes are legitimate or not.

I hope you found this article helpful. Feel free to contact me at https://twitter.com/blueteamblog with any further comments or questions.