Compliance 101 for Oracle DBAs

Regulatory compliance issues are top-of-mind for today’s senior executives. New laws and industry regulations are changing how organizations acquire, store, manage, retain and dispose of data. Every Oracle DBA should be aware of these changes because of their sweeping impacts on the DBA job role.

Compliance goes hand-in-hand with security because regulations often mandate that organizations be able to attest or even prove that data—and therefore databases—are secure and controlled. In this context, Oracle DBAs are directly involved in implementing and managing the policies and technologies that support compliance.

What are some of the key regulations that impact Oracle DBAs? Here in the US, one of the most prevalent is Sarbanes-Oxley (SOX), aka the U.S. Public Accounting Reform and Investor Protection Act of 2002. SOX is meant to reduce fraud and improve financial reporting. Its impact on IT is sweeping. In particular, it holds the CFO responsible to guarantee the processes used to produce financial reports, which invariably involve software accessing data stored in databases via processes maintained by DBAs.

For healthcare organizations the major regulatory worry is HIPAA, the Health Insurance Portability and Accountability Act. HIPAA mandates security measures for patients’ personal health information (PHI)—to the extent that an organization must be able to document every time a PHI data element was viewed. HIPAA audits often focus on the processes that drive exception logs and reports. Database auditing is critical in this regard.

Here are some typical Oracle DBA tasks that directly relate to compliance:

  • Data quality and metadata management. Ensuring data quality is key to regulatory compliance. If data or metadata aren’t accurate, how can the right data elements be subject to the appropriate regulatory controls?
  • Database auditing. As mentioned above, robust database audit capabilities can be essential for compliance with HIPAA and other regulations and policies that mandate tracking database usage. What data was accessed when and by whom? Database audit software can tell you. Database auditing is also vital for overall information security and detection of security breaches, especially against internal threats.
  • Data masking and obfuscation. Data masking practices are generally used to render original data suitable for testing purposes. It looks and functions consistently with the original data, but no longer constitutes personally identifiable information or credit card data, etc. for regulatory purposes. It’s also important for protecting sensitive data from staff (e.g., third-party contractors) working in non-production environments.
  • Database archiving and long-term data retention. Regulations often mandate what data must be stored for what period of time. This is also important for legal/eDiscovery purposes.
  • Database recovery. Database recovery is also a compliance issue, because it relates to database integrity and availability. If data is lost and can’t be recovered, that can be as problematic as a security breach from a regulatory perspective.

If you’re not sure whether your Oracle database policies, procedures and controls are adequate to support regulatory compliance, Buda Consulting can help. Contact us to discuss a database security assessment to identify areas of noncompliance and provide whatever assistance you need to address them.

 

Database Security: Is Your Database Vulnerable To Internal Attack?

Database Security: Is Your Database Vulnerable To Internal Attack?

Enforcing Least Privilege To Enhance Database Security

The principle of least privilege refers to the practice of ensuring that each individual has only the privilege and access that is necessary to perform their job function.

In most IT shops that run an Oracle database, there are a group of individuals that need administrative access to the operating system and the database. These individuals include both operating system administrators and database administrators.

In order to ensure Database Security, particularly Oracle Security, it is critical that privileges for these individuals be limited and managed properly.

In many cases, these individuals are all given the username and password to a shared, privileged operating system account, such as root on the unix platform. Also in many cases, these individuals are also given the password to the oracle account which owns the oracle binaries.

The Risks

There are two critical problems with this approach that significantly reduce your ability to ensure your Database Security.

  1. By granting multiple users access to these shared operating system accounts, you compromise the effectiveness of any database auditing or operating system auditing that you may have in place. If data is accessed or modified, future forensics would only yield the shared account name, not the name of the individual that took the rogue actions.
  2. Oracle’s operating system authentication mechanism enables a user, once connected to an operating system account, to connect to oracle without a password. Furthermore, if the operating system account is highly privileged, such as an account that is in the osdba group, then the user can connect to Oracle as sysdba (using the Oracle SYS account), which is the most privileged account in Oracle. The oracle account is in the osdba group. This leads to numerous risks including an oradebug vulnerability, described in an excellent post by Pete Finnigan, that results in the ability to turn off auditing completely (without the turn-off action being recorded).

How to mitigate these risks:

There are a number of steps we can take to significantly reduce (though not eliminate) the risks outlined above.

  1. Grant all system and database administrators their own operating system account and do not grant access to any shared administration account (including root and oracle) except when absolutely necessary.
  2. Ensure that the passwords of administrative accounts such as root and oracle are changed regularly. This protects you in the event that passwords had to be given out to resolve an emergency.
  3. Restrict Oracle DBAs that perform operational functions such as backups, or space management, to connect as sysoper or asmadmin instead of sysdba. This can be controlled by placing their operating system accounts into the osoper or osasm group or instead of dba group.

These steps will not completely eliminate the risk of a data breach. However, it will significantly reduce the potential for a breach, and will further reduce the potential of a breach that can avoid detection.

Contact Buda Consulting for more information about how to enhance your Database Security and Database Compliance.

Please reply with other risks that you have found that are caused by similar database management issues.

Database Security Issues in the Cloud, Part 2: Regulatory Compliance

As the number of databases moving to public, private and hybrid cloud computing infrastructure increases, security concerns are a significant and growing problem. Organizations will do well to scrutinize the security practices of cloud providers and other third parties that store their data. But wherever databases are running, responsibility for the security and integrity of data ultimately rests with the organization that owns the data – even when it resides with a service provider.

As I outlined in Part 1 of this post, cloud database security concerns fall into three basic categories: data access control (covered in Part 1), regulatory compliance, and physical/network controls. This post discusses regulatory compliance issues.

Regulatory compliance issues in the cloud

Much has been written about concerns with physical control of data in cloud environments. Cloud providers frequently need to reconfigure and/or move the virtual servers hosting your data, possibly across multiple data center locations.

How can you demonstrate to auditors that your data is secure if you don’t know exactly where it resides? The answer lies in having clear visibility into database activity relative to applicable regulations. You need to:

  • Put the necessary policies in place to meet compliance requirements;
  • Audit your databases against your policies and against all the regulations that apply to you, whether the data resides in a cloud environment or not; and
  • Make sure you can generate all the reports on database activity that you need to demonstrate compliance to auditors.

At Buda Consulting we use automated tools including Application Security’s Appdetective Pro to assess the vulnerability of clients’ databases and audit them against a host of regulations. The following list from the Appdetective documentation describes some of the key audit policies that we check in regulated environments:

  • Basel II – ideal for a Basel II compliance assessment
  • Best Practices for Federal Government
  • DISA-STIG Database Security Configuration – leverages the configuration parameters outlined by the DISA-STIG for SQL Server and Oracle
  • Gramm-Leach-Bliley Act – structured according to GLBA standards and recommended for GLBA compliance assessment
  • HIPAA – structured following NIST standards and best practices for databases security; highly recommended for use in a HIPAA compliance assessment
  • PCI Data Security Standard – recommended for use in PCI compliance assessments
  • Sarbanes-Oxley – follows CoBIT and ISO 17799 standards; recommended for use in a SOX compliance assessment

Using tools like App Detective Pro, auditors and advisors can perform a database security assessment against the organization’s policies and against applicable regulations, capture results for manual verification, and generate compliance reports.

Some of the scans will be difficult or impossible to run in a cloud environment without the assistance of the cloud provider. In particular, scans that require privileged operating system accounts will not be possible without cloud provider cooperation.

Therefore, it is important to obtain from the cloud provider documentation ensuring that they have the necessary controls in place to satisfy the applicable regulations.

This may be more difficult than it sounds. Some cloud providers refuse to give out any information about their security policies and procedures, indicating that doing so may compromise security. Others may withhold specifics, but instead point to the fact that they have undergone a SAS 70 type II audit. While passing a SAS 70 type II audit can be a valuable criterion to use when evaluating a provider, you must be sure to review which controls are included in that audit. These audits do not have to include every control that may be important to the pertinent regulations impacting your business.

Contact Buda Consulting to learn more about how to ensure the security of your data in the cloud.

Secure The Database, Inside and Out

Secure The Database, Inside and Out

It has been a relatively short time since I wrote my last post on database security but so many breaches have occurred since then that it seems like much longer.

In just the past few months, Sony’s gaming system was shut down for two weeks, a nuclear facility in Iran was physically damaged by nefarious code introduced into the system, the SecureId system at Lockeed Martin was compromised, and google’s mail system was hacked again. The list goes on and on.

Two things are becoming clear;  With the current state of network security, no computer systems are completely safe from attack. And the reasons for attacks are becoming more varied.

Suspected reasons for recent attacks have ranged from personal vengeance against a company, to likely state-sponsored espionage, to the more common stealing information for personal or corporate gain.

Some recent attacks came from the outside. But others, notably, the attack on the Iranian nuclear facility, is believed to have been introduced inside the network, possible via an infected flash drive.

This tells us we must use a defense in depth approach whereby we secure the individual components of our information technology infrastructure in addition to the overall network and physical environment — if we want to protect data that is stored in a database, then we must secure the database directly!

Databases from every database software vendor are subject to database vulnerabilities caused by misconfiguration, poor security procedures, or bugs in the database software.

The first step in eliminating these vulnerabilities is to identify them. This can be done using database vulnerability scanning tools such as Application Security Inc’s AppDetective Pro, which we use at Buda Consulting, to help secure our client’s databases.

After the vulnerabilities are identified, they should be resolved or designated as acceptable risks, and then another scan should be performed to ensure that all of the vulnerabilities have been addressed.

Finally, we must audit database activity and monitor the audit logs on a regular basis to identify potential attacks. Database security is not a one-time activity. It is an ongoing process that must be performed on a regular basis.

 

Download our Database Security Roadmap to help guide you through the process of securing your database.

Oracle Security: Oracle’s Audit All Command Doesn’t Really Audit All

Oracle Security: Oracle’s Audit All Command Doesn’t Really Audit All

When attempting to make their Oracle database as secure as possible, many organizations turn on Oracle’s auditing feature. Oracle has a very robust auditing feature that enables us to log every action taken in the database. We can audit connections, object creation, data updates, deletes, and many other database activities.

Some organizations turn on auditing in order to comply with regulations or corporate security policy and may not actually review the logs that are produced until there is suspected breach of security.

These organizations may be in for a surprise if they use a shortcut that Oracle provides for configuring auditing. Shortcuts are an easy and fast way to configure auditing. Instead of specifying each individual activity to be audited, they can be used to specify a group of them at one time. These shortcuts can be deceiving, however. One of these shortcuts is: Audit All.

Despite the comprehensive sound of Audit All, there are some important activities that Audit all does not capture. These include renaming and altering tables, and other system activities. They also do not audit any operations on the audit tables themselves.

So when configuring auditing, be sure to capture everything you want by specifying the activities that you wish to audit individually.

The following list from Oracle Documentation describes the activities that are not audited when you specify Audit All:

  • ALTER SEQUENCE
  • ALTER TABLE
  • COMMENT ON TABLE table, view, materialized view
  • COMMENT ON COLUMN table.column, view.column, materialized view.column
  • DELETE FROM table, view
  • Execution of any procedure or function or access to any variable, library, or cursor inside a package.
  • GRANT privilege ON directory
  • REVOKE privilege ON directory
  • GRANT privilege ON procedure, function, package
  • REVOKE privilege ON procedure, function, package
  • GRANT privilege ON sequence
  • REVOKE privilege ON sequence
  • GRANT privilege ON table, view, materialized view
  • REVOKE privilege ON table, view, materialized view
  • GRANT privilege ON TYPE
  • REVOKE privilege ON TYPE
  • INSERT INTO table, view
  • LOCK TABLE table, view
  • Any statement containing sequence.CURRVAL or sequence.NEXTVAL
  • SELECT FROM table, view, materialized view
  • UPDATE table, view

It may not be appropriate to enable auditing on all of the above actions. Auditing some of these actions, such as inserts and updates, can have a negative impact on system performance, so be sure to consider that when deciding whether to audit those activities.

Also, be sure to audit the audit trail itself as follows:

  • Audit Insert,Update,Delete on sys$aud$ by access;

The potential misunderstanding caused by the misleading name of the audit shortcut is one more good reason to review your audit trail periodically even before there is a suspected breach. By examining the audit trail you can be sure about what activities actually being tracked.

Download our database security roadmap to secure your database.

Audit configuration should also be checked during annual security audits. Contact Buda Consulting for more information about database auditing.