by Robert Buda | Jun 9, 2011 | Best Practices, Database, Database Security
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.
by Robert Buda | Mar 17, 2011 | Best Practices, Database Security, Oracle
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.
by Robert Buda | Mar 17, 2011 | Best Practices, Database Security
Strong Database Security
Today’s database systems have sophisticated security mechanisms designed to enable the protection of data and the tracking of the viewing and modification of the data. For example, Oracle has database roles that govern what database objects a user can see and edit. Oracle also has auditing features that enable us to track the activity of users. SQL Server has similar security features. When implemented properly, these features can be very effective at helping us secure our data.
Generic Application Logins
Unfortunately, the design of many applications, especially web applications, results in a circumvention of these sophisticated security mechanisms. Many applications are designed to use just one highly privileged login to the database for all users. In these scenarios, users log in to the application and the application controls the security from that point on.
Application security schemes generally allow the administrator to specify which functions a user can access or execute, instead of which database objects they can see or edit. Access to these functions is generally provided by means of a role or profile.
This arrangement makes it very difficult to know which users actually have access to a specific database object and it makes it even more difficult to track such activity.
Bridge the Gap
When applications are designed in this manner, it is critical to ensure that we understand what objects can be accessed by users in order to protect sensitive information. This involves a number of things:
- User Rights Data: A list documenting which roles or profiles each application user has been assigned to. Ideally, this information would be kept in a table that could be queried for this information.
- Role or Profile Rights Data: A list documenting which functions each application role or profile have access to. Ideally, this information would also be kept in a table that could be queried for this information.
- System Function Metadata: A list documenting each function in the application, which database objects that function provides access to, and the type of access (update,delete,etc). Ideally, this information would be kept in a meta data table that could be queried for this information.
- A cross reference that combines the above three sets of data and maps each application user to the database objects they can access, as well as what level of access they have to the object.
For packaged applications, most of this information is likely available in tables in the database, but the challenge may be finding out where it is kept. For applications that are developed in-house, it is important to document the location of this information so that it can be used for auditing purposes.
Make it Accessible
Best practice is to develop an application that can access this detailed user privilege information and provide easy report and query functionality. This is the cross reference data that combines the rights data and the system function meta data described above. Making this information easily available (and of course securing it) can help bridge the gap between database and application security.
How has your organization dealt with this issue? Let us know what methods you have used and what areas you found challenging.
Contact Buda Consulting to see how we can help you design an effective strategy for securing your data.
by Robert Buda | Mar 17, 2011 | Best Practices, Cloud, Database Security
Cloud Database Security Issues And Challenges
The benefits of cloud computing, including reduced IT ownership and operating costs and improved resource utilization, are just too good for many organizations to pass up. More and more businesses of all sizes are moving a wide range of applications to cloud environments.
But database security concerns remain a significant barrier to cloud adoption. When your applications are running on a cloud provider’s infrastructure, the provider is responsible for ensuring that its operations, facilities, network, hosts and other components are secure. But responsibility for securing your data ultimately rests with you, as do the consequences of failure.
Will a public cloud be more or less secure than your on-premise environment? What new and different security issues do cloud environments present?
Cloud database security issues and challenges fall into three basic categories:
- Data access control
- Regulatory compliance
- Physical/network control
In this post I’ll talk about access controls, and will touch on the other issues in subsequent posts.
Access Control Issues In The Public Cloud
Loss of access control is a primary threat to data security. External threats are certainly a concern, but more and more studies show that the majority of access control threats (some say up to 80%) are internal. In a public cloud environment, internal threats can potentially come not only from your employees who have (or had) valid access to your DBMS, but also employees of the cloud provider.
You can address some access control concerns as you’re evaluating cloud providers. Find out how the DBA services that providers offer are structured, not only in terms of services provided but also around Segregation of Duties. Do the provider’s DBAs (and operating system administrators) have full DBA privileges giving them easy access to your data? How well vetted are the people working with your data? Is there full transparency around how many are involved, who they are, and where they’re located?
The bottom line is how much control do you have over the level of access administrators have to your data, if the cloud provider will be performing database administration. It may be more secure to maintain your own trusted database administration services.
Database Auditing Can Help!
How can you really know who is accessing your cloud-based data? Robust database auditing is vitally important. You need full visibility into database activity regardless of where your data resides.
What is database auditing? Basically, it’s the ability to consistently (and securely) record and report on all the actions of database users. Audited databases produce audit trails that can specify what objects were accessed or changed, how they were changed, and when and by whom.
Auditing is especially crucial when you need to pinpoint an unauthorized access from an authorized user. But it’s also helpful for compliance with regulations and corporate governance policy.
Of course, a weakness of database auditing is that it tracks what’s already happened. Ideally, your cloud-based database security solutions will include intrusion detection capabilities such as Pivot Point Security’s Oscar to identify suspicious activity before it results in any data loss or theft.
Another challenge around database auditing is performance degradation. Auditing needs to be structured appropriately so that useful details aren’t lost in a sea of data whose acquisition bogs down performance and/or storage.
Auditing By A Trusted Third Party
In addition to auditing databases with software, a trusted third party should conduct an audit to find vulnerabilities in your databases and environment, including a cloud environment. Third-party auditors use specialized tools like AppDetectivePro to identify and address security challenges like the following (and many others):
- Whether the database software is patched and configured in the most secure manner.
- Whether default passwords have been changed.
- Whether the users that have access to the data are the ones who actually should have access, according to the business security policy.
- Whether all machines in an environment (development, QA and production) have the same configuration and the same level of protection against vulnerabilities
Contact Buda Consulting to learn more about how to secure your data whether it is housed in house or in the cloud.
by Robert Buda | Jan 3, 2011 | Best Practices, Database, Database Security
As the New Year begins, many of us take the beginning of a new calendar year as a cue to to clean out and shred our old files and reorganize our storage spaces so that we have room for all the new supplies and equipment we will need in the new year.
We do this because we know that if we did not do this each year, the task would get overwhelming and would likely not get done at all.
We know that clutter is bad. Clutter slows us down when we need to find something. Clutter can cause injuries as we step over old boxes. Clutter can cause us to lose track of important files and may prevent us from securing sensitive files properly.
As we do this with our physical files in our file cabinets and with the supplies in our closets, we should take the same steps with our database systems.
A thorough database security audit should be performed each year and one deliverable of the audit should be a list of potential items to be removed.
Clutter in our database system takes various forms. This includes user clutter and object clutter.
- Obsolete user accounts (accounts for terminated employees or contractors).
- Unused test accounts.
- Obsolete tables and columns.
- Unused stored procedures and functions
- Unused database links
Of course, these items should be cleaned out more often than once per year. In a perfect world, we would never have obsolete user accounts or unused tables in any database. But performing an annual cleanup ensures that nothing gets missed.
This cleanup should be performed on both Production and Development databases. There will likely be more object clutter (unused tables or stored procedures) in the development database than in the production database. The production database will likely have more user clutter (obsolete user accounts).
Obviously, extreme care must be taken when performing such a cleanup. Appropriate backups should be performed beforehand as with any maintenance task.
When cleaning up obsolete users, you can start by asking your HR department for a list of employees that have been terminated during the year. Check to see if their corresponding accounts have been removed.
It is common to find that the account of a terminated employee is still in use by employees that have assumed his duties. In this case, the privileges (and any objects) of the terminated user should be transferred to the user that remains and the account should be removed.
When identifying obsolete objects, look for the following as potential candidates for removal:
- Tables with names indicating a temporary nature. Tables with Test or Temp as part of the name
- Tables with a persons name attached.
- Tables with a date attached.
- Tables that do not follow the naming convention for the system.
- Empty tables
Before removing any table, check with the development team and the application owners to see what they know about it. Of course backup any table or other object individually before removing it. Also check for any foreign key constraints involving the table.
Keeping your database clean in this fashion will make it more secure and easier to maintain and understand as the years go by. A fifteen or twenty year old system can accumulate a surprising amount of clutter if left unchecked. Just like that storage space in the basement.
Happy New Year!
