Database Reference
In-Depth Information
So the action was recorded, but the identity of the user is ambiguous due to use of the shared SYS account. Most
DBA activities still take place using SYS, which is where privileged power, and thus security risk, lies. Therefore it is
well worth trying to move away from the default 12c OFF setting for auditing SYS operations, as shown in the following
excerpt:
SQL> show parameter audit
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /home/oracle/app/oracle2/admin
/orcl3/adump
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string DB
unified_audit_sga_queue_size integer 1048576
Personally I would have left the audit-trail architecture as it was and simply worked on trying to get SYS auditing
ON by default. The SYS audit trail is pivotal as that is where the unaccountable privilege risk lies. The real key to
securing Oracle is being able to differentiate between normal system usage of the SYS account and potentially
unauthorized human usage of the SYS account. Both usage types may look similar. One way to distinguish them is to
prevent human usage of SYS for a period of time and to record all system usage as known-good, i.e., whitelisting. Then
any other activities that happen above that known system activity can be put into the “inspect closer” category. There
are a number of DB auditing solutions that completely omit all SYS activity due to the large volume. That avoids the
real problem. Monitoring SYS is the highest priority for security-risk reduction. The beauty of Oracle syslog is that it is
possible to monitor all SYS activity due to the lightweight protocol.
While the old SYS auditing is still turned off by default, greater complexity has been added to the new UAT.
As an example, “conditional auditing” can define an audit rule that will only fire dependent on factors like the source
IP address. There are actually some interesting benefits from conditional auditing; for example, one of the biggest
concerns with real-world database audit trails is that the rules are generally system wide, so they end up auditing
application accounts that are very busy and don't have human interaction anyway, as no human knows the password.
Because the account is so busy, its audit trail is effectively a denial of service attack on the local machine so that
auditing has to be turned off completely. Conditional auditing will enable the exemption of an account from
system-wide auditing settings. However, in comparison to the main priority of auditing SYS, it is of low priority.
On the positive side, we can see that UAT has improved upon the already present DB-based audit trail and has
not removed the much more scalable OS audit-trail mechanisms such as centralized syslog. The new unified audit
trail is great for pulling together RLS and DV audit trails and is actually very well designed for querying within the
DB. My concern is that the ability to send all audit trails to a single syslog machine and grep through it could be
lost if customers allow Oracle to remove syslog audit trails from the DB in the long term. So speak to your Oracle
representative and ask them to keep the ability to send the audit trail through centralized syslog. This may save your
organization from an incident and can certainly increase internal transparency, which will make the organization
healthier and more secure.
Privilege Analysis
Privilege analysis is part of 12c along with database vault. It's an interesting feature giving the ability to monitor
the privileges used by an application account and “
diff
” that list against the privileges it has in order to identify
unused privileges that can be removed safely. This is a very intelligent feature, as any Oracle DBA who has had to
work their way through being a developer will know, the quickest way to make an application work is to grant the
application account the DBA role, and given time pressures that role may not get revoked afterwards. Automating
the process of precisely calculating the actual required privileges will reduce risk, so nice work, Oracle! Of course,
database vault is chargeable, so this is not a free feature.
