Things the auditor saw and what you can do to make sure they don’t see them again
By Roxana Bradescu on Feb 17, 2009
CIO Insight put together this great security slideshow: 10 Things the Security Auditor Saw based on Deloitte's 6th Annual Global Security Survey discussing the top priorities and problems revealed by internal and external audits.
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.