Help Reduce Risk with Oracle Database 19c Privilege Analysis

Compromised user accounts are a factor in almost every database security breach. No matter how often experts caution users about following best practices, being wary of emails with links or attachments, and taking advantage of endpoint protection, we still find that compromised user accounts are the most common source of a database breach.

That’s why it’s important to be proactive when managing user privileges. The principle of least privilege has been around since the dawn of the internet age – it’s simple in theory, but devilishly difficult in practice. The drive for least privilege is a constant source of internal friction between security teams and end users. Users naturally attempt to acquire the highest level of privileges possible because it makes their jobs easier and reduces the chance they will be blocked due to insufficient privileges. Security administrators inherently attempt to minimize privilege assignments to reduce the damage done if an end user’s account is compromised.

One major reason for the friction involved in enforcing least privilege is that it’s a guessing game on both the security administrator and the end user’s part. Security administrators can’t be sure that users don’t need their privileges, yet the end-users rarely know precisely what privileges they really need to do their jobs.

This is where Oracle Database 19c Privilege Analysis comes into play. A database privilege model can be quite complex, with tens of thousands of privilege combinations possible. Privilege analysis lets the security team take the guesswork out of managing least privilege by monitoring which privileges a database user actually consumes. With privilege analysis, there is no guesswork involved – if a database user has privileges they never use, then those privileges aren’t required and can be safely removed without impacting the user’s ability to do their job.

Privilege analysis is pretty easy to work with – simply enable privilege capture for the user or users you wish to work with. If desired, privilege analysis can be configured to monitor ALL users in the database.

Allow privilege capture to work in the background for a sufficient period of time to capture the user’s normal work activity (more on this later).

Stop the privilege capture and generate a report on privileges granted but not used. These are visible in two data dictionary views – DBA_USED_SYSPRIVS and DBA_UNUSED_OBJPRIVS. These privileges are candidates for removal – since the database user isn’t using them, they are an unnecessary risk if the user’s account is compromised.

Remember when I said I’d come back to “sufficient period of time to capture the user’s normal work activity?” That is unfortunately not as easy as it sounds because some privileges may be used very infrequently. For example, the database user may only perform end-of-year analysis once during a year - kind of makes sense doesn’t it? That’s why the caption on that diagram above says “do not use” – because if you just revoke those unused privileges there is a good chance you’ll find out that you are removing a privilege that actually IS needed, just very seldom.

To mitigate that risk, we add two extra steps to our flow:

We use the output of the privilege analysis report to identify privileges that are candidates for removal. From that, we create an audit policy to track the use of those privileges. Then we monitor the audit trail to see if/when those privileges are used – and we may monitor for a LONG time, perhaps even a full year. The monitoring phase mitigates risk for us in two different ways:

1. If a user’s account is compromised and those candidates for removal are used, we’ll have a better chance of spotting the compromised account

2. If we detect usage of those privileges and it turns out that the usage is legitimate, then we know NOT to revoke the privileges at the end of the monitoring period.

Once we’re confident that those privileges really can be safely removed, only then do we revoke them.

Source: oracle.com