Top on the list was excessive access rights. Often times organizations grant individuals or applications access to more information then they really need to perform their function. Since databases are the primary repositories for information in most organizations, this is actually most often the case at the database level. This is exactly why Oracle developed Oracle Database Vault. With Oracle Database Vault organizations can enforce least privilege by setting up protection realms inside their database that restrict access to data to any user, including privileged database users such as DBAs or applications with DBA privileges. So for example using Oracle Database Vault, an organization can allow a DBA to manage a database without actually being able to read or change the information that in that database. Oracle Database Vault does not require any changes to existing applications so it represents a very cost-effective and easy to deploy way to remediate this issue.

Second on the list was segregation of duties since lack of segregation of duties allows people to circumvent controls. Oracle Database Vault also enforces segregation of duties. Out of the box, Oracle Database Vault separates responsibilities and functions that conflict with one another such as database account creation, privilege grants, and other database management functions. Oracle Audit Vault can also be used as a detective control for segregation of duties by allowing a separate organization or IT auditor to monitor database activity across all Oracle and non-Oracle databases in the organization. Oracle Audit Vault can detect and alert on unauthorized activities such as account creation or access to application data that circumvents the application by any user even privileged users.

Third on the list was access control to ensure users only have access to the systems and information they need to do their jobs. Managing user access to systems can be achieved at the enterprise level using an identity management solution or at the database level using an Oracle Database Vault “connect” rule. But restricting system access is not enough since it’s not just the system we’re trying to protect - we need to protect the information. Organizations need to look at database controls to ensure users only have access to the information that they need to do their job. With Oracle Database Vault you can setup command rules that take into account multiple factors such as time of day, application being used to access information in the database, where the application is running, etc. to determine whether to grant access to information. For example, access to HR information might only be granted during business hours to HQ users accessing the data through the HR application. Users trying to access that data using an ad-hoc reporting tool or from a remote location would be denied access. Oracle Advanced Security can also be used for strong authentication to restrict access to the database to users that have been issued a PKI certificate or a physical device like an OTP token or smart card.

Number four on the list was lack of audit trails/logging with number seven being lack of review of audit trails. As you can see from past blog posts, between 30-50% of the folks we survey still don’t have database auditing turned on and many who do don't don't actually monitor the database trail. Everyone should have native auditing turned on and be monitoring for at least the basic stuff like failed logins, DDL changes, direct access to sensitive/data, etc. Of course if no one is looking at that audit trail that’s not going to help a lot. Again this is where you want to consider the use of Oracle Audit Vault. With Oracle Audit you can automate the collection and analysis of that audit data. You can setup alerts on exceptions and you can centrally manage audit policies across multiple databases to make sure you are generating audit trails for all your databases.

Number six was excessive developer access to production data and number nine was the use of production data in testing. We already talked about how user access to systems can be restricted so you can keep developers out of production environments, but the challenge is really around keeping production data out of development environments. With Oracle Data Masking, sensitive production data such as credit card or social security numbers can be replaced with realistic values, allowing production data to be safely used for development, testing, or sharing with out-sourcing partners or off-shore organizations for other non-production purposes. Oracle Data Masking uses a library of templates and format rules, consistently transforming data in order to maintain referential integrity for applications.

So if your auditor saw any of these issues, you can make sure they don’t see them again.

One of the polls was "Are you encrypting sensitive information such as credit card and social security numbers in all databases across your organization?" We had 61 responses, and 34 answered NO. Although 27 of the folks on our webcast answered yes, the 2008 IOUG Data Security Report a few months back actually indicated that number out there is more like a third. One of the main reasons is we find is the use of production data containing live social security numbers or credit cards being copied to non-production databases for development and test purposes.

We are going to be talking more about this topic in a live webcast on how to "Protect Sensitive Data Using Encryption and Masking" this Thursday at 2:30 EST/11:30 PST. You can register here.

The second question we asked was "Are you using native database auditing to detect failed logins, DDL changes, or other suspicious activities?" with a follow-up question of "Are you monitoring database audit logs to detect security threats in real-time?" We had 67 responses, 32 indicated they were auditing their databases, but only 25 were actually monitoring those audit logs.

In the webcast, we discussed the importance of using tools like Oracle Audit Vault to automate the monitoring of audit data in order to detect and alert on security threats in real-time. Also having all that audit data securely stored in a centralized warehouse saves lots of time and money when generating regulatory audit reports. If you want to see a demo of Oracle Audit Vault, you can register here to attend one of our weekly demos in February.

Well that's it for now, I will be posting some follow-up to some of the questions asked on this and other recent webcasts. Stay tuned...