During a recent conversation, I used the phrase rows of data, to which I received a question from a compliance...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
officer: "What is a row?"
At the time, I had made the assumption that everyone knows about databases and how they are organized. But afterward, as I thought more about this exchange, it became clear that sometimes those who are tasked with protecting data don’t really know much about it. When it comes to databases, there isn’t always much awareness of the security-related issues lurking in and around them. As a matter of fact, many enterprise databases are leaking data as you read these tips. To make matters worse, most of these databases contain sensitive and personally identifiable information.
So, why is it that organizations spend millions of dollars on securing their perimeters and their desktops, and virtually nothing on database security?
There are many reasons for this. Let’s examine them:
1. “Out of sight, out of mind.” Databases are generally "silent." They are not in the daily news, and they generally miss the daily IT status report unless they are down or exhibiting slow performance.
2. “Black box syndrome.” To most compliance officers, databases are the black boxes that store data and provide it to us when we ask. There is a general lack of knowledge in data architecture and database configuration, factors that greatly affect database security.
3. “If you have the access, you are welcome.” Having been a database administrator myself, I can safely say that I have not yet met a rogue DBA. But the problem is, the DBAs are not the only ones who have privileged access to the data within the database. Also, a DBA’s job is to maintain the database and tune its performance, not monitor and manage security. DBAs are fine as long as the user has received approval to access the database.
4. “We are in good hands." Most large databases are supported by the database vendor. As databases are complete systems involving many hardware/memory/software considerations, specialized skills are often needed and provided by the database management system (DBMS) vendor. This again creates a barrier between the compliance officers and the databases, because there typically is no need for them to get involved with the database issues.
The adage “what you don’t understand, you cannot manage” is so true with the databases. So what can compliance officers do to ensure their organization’s database security without having to take DBA training?
The following tips are designed to help focus on key database security issues that, if remediated, will improve the database security posture greatly.
Enforce password policies. Many of the databases either don’t enforce password policies or exempt certain users from these policies. Experience has shown that most applications that access databases are exempt from organizational password policies. DBAs also exempt themselves from password restrictions for the fear that they may be locked out.
Discourage user account sharing. Many times, a DBA group will share a single account for the reasons of providing 24/7 support -- or so I am told. A great example is that many of the Oracle DBMS users utilize an “Oracle” user account for their database access. While it makes their lives easier, it makes it extremely difficult to relate a certain database activity to a specific user. And an “Oracle” user id is powerful enough that if used inappropriately, users could corrupt the database.
Log and monitor database access. Historically, organizations have had to choose between database performance or database logging. Even those organizations that created database audit logs weren’t very successful in reading and reviewing them. However, a new breed of tools, known as database activity monitoring products, has changed that. Most of these products have software taps or agents that reside on the same server as the database and send all database activity data to the appliance for analysis. These products can capture all database transactions while hiding the sensitive data, providing an audit trail of who did what and when.
Conduct database scans. The traditional audit method for databases requires a dump of many systems tables and may cause the databases to crash during the data extract. Despite this, they can’t tell if the database is vulnerable to Web-based flaws such as SQL injections. A newer breed of tools, such as the ones mentioned above, provides the capability to scan databases and provide readable reports on database vulnerabilities. Tools such as Nessus can also scan the databases, but one must select the appropriate plug-ins and ensure that the scan has run successfully. Compliance officers should obtain the database scan reports and ensure that the databases are configured securely.
Compliance officers should obtain and review lists of privileged users periodically, and also review the roles they are assigned.
Review the list of privileged users. Most organizations have two sets of DBAs -- application DBAs and system DBAs that have a genuine need for privileged access. However, other users may obtain the privileged level access and keep it beyond necessity. Compliance officers should obtain and review lists of privileged users periodically, and also review the roles they are assigned. It is possible in database management systems to grant fine-grained access, and the compliance officers should insist upon it.
Remove terminated user accounts. DBMSes such as those from Oracle Corp., generally manage users separate from the enterprise access management system. As a result, terminated or transferred users are not deleted, leaving the database susceptible to unauthorized access. Compliance officers should review the list of database users on a weekly basis and ensure that the accounts for users who no longer have a business need for accessing the database are promptly removed or disabled.
These are some of the things a compliance officer can add to his list of continuous monitoring controls for databases, realizing that without adequate database security, application security is an uphill battle and data security does not exist.
Meenu Gupta, CISA, CISM, CISSP, CIPP, is president of Mittal Technologies Inc. and specializes in IT solutions engineering and IT security architecture development. Gupta consults with the U.S. government and teaches at the University of Maryland University College. Let us know what you think about the story; email Ed Scannell, Executive Editor.