Annotated Bibliography

DATABASE SECURITY

New approaches to securing the database

Databases hold much of the most sensi- tive and valuable data – information about customers, transactions, financial performance and human resources. Despite this, databases remain one of the least-protected areas in a company. While perimeter and network security measures create a barrier against some type of attacks, they are inadequate against attack vectors that take advan- tage of database-specific vulnerabilities. Also, they offer little or no protection from insider abuse, especially when dealing with privileged users who are not only inside the perimeter but are also capable of circumventing applica- tion-level security.

SQL injection, buffer overflow attacks and other ‘zero-day’ hacks can cut right through web firewalls, applica- tion firewalls and intrusion detection systems (IDS), and create opportunities for data theft, unauthorised modifica- tion or destruction of data, or breaches of privacy and personally identifiable information.

Database management systems are complex, supporting an ever-growing set of requirements and platforms, with the addition of new features. Subsequently, they develop gaps in security – vulnerabilities – that are constantly being discovered by users, ethical hackers and non-ethical hackers too. Such vulnerabilities are reported to DBMS vendors who do their best to patch them, but this is a process that currently takes several months on aver- age, years in some cases. This time lag is an open invitation to exploit the vul- nerability and breach the database.

Identifying the true cost of a breach At a practical level, tools to identify devel- oping threats and averting actual threats are valuable to any organisation. While external threats have caused significant financial losses, the impact of insider threats cannot be underestimated. The 2008 FBI/CSI Survey notes that the insider abuse of networks was, at 44%, the second most-frequently occurring. It was also reported that 57% of implicated insid- ers had privileged access to data at the time of the breach. It is therefore evident that perimeter and network security measures are not enough to stop such breaches.

Finally, legislation and regulatory require- ments such as Sarbanes-Oxley for public companies, healthcare’s HIPAA, financial services’ GLBA and the credit card indus- try’s PCI DSS all mandate that companies and organisations take certain measures to ensure the privacy, integrity and security of sensitive data. Most compliance require- ments stress the importance of monitoring privileged users, and having full traceability and accountability of their actions.

The evolution of security threats vis- à-vis the existing infrastructure paints a clear picture: databases need protection on a granular, intimate level, using tools that can handle database-specific threats on the one hand and deal with the insider privileged user on the other.

Existing components of database security A wide array of technologies and tools is currently in use for securing various

aspects of database use. As with other areas of IT security, no single tool can provide ironclad defence against all threats and abuses. It is always recom- mended to employ a combination of tools to achieve adequate security.

Following is a brief overview of exist- ing categories of tools that can be found in use across enterprises large and small.

Authentication and access control Pros: Establishes roles and privileges,

the most basic level of security Cons: Difficult to enforce properly,

over-liberal granting of access, privilege creep, open to hacking, privileged users have free reign.

The ability to designate roles, logins and passwords is the most basic level of database security and is widely used. It establishes the basic privileges of dif- ferent users and ensures each user and application only accesses the database to the extent they need to.

“While external threats have caused significant financial losses, the impact of insider threats cannot be underestimated”

However, this mechanism assumes that users are generally well behaved and that their access rights are managed according to policy. But this is often not the case. Granting of excessive privileges is com- monplace, as is ‘privilege creep’, where users gain privileges over time without having redundant ones revoked. It is also common to have group usernames and passwords and to forget to revoke privi- leges of employees who no longer need them. So while such mechanisms are nec- essary, they do not suffice even to limit authenticated user access. Additionally, they are vulnerable to exploits (e.g. SQL injections that escalate privileges).

4 Network Security November 2009

Sudha Iyer, CISSP

Much of the effort in recent years to secure corporate IT infrastructure has focused on the perimeter – how to defend the enterprise from external intrud- ers, hacking and malicious attacks. The corporate network has also seen its share of improvements in security, providing a further layer of protection. The data layer, however, remains the soft underbelly of enterprise IT infrastructure.

Sudha Iyer

DATABASE SECURITY

Native database audit tools Pros: Provides a granular audit trail

and forensics of database activity Cons: Can have a negative impact on

database performance, no separation of duties, is easy to turn off and manipu- late, provides only after-the-fact forensics and has no prevention capabilities

Most database management systems (DBMS) come with features that enable granular auditing of particular database activities. In the case of highly transac- tional environments, however, or when data manipulation language (DML) statements need to be audited, the impact on performance can be detrimen- tal. For this reason, auditing is only used very selectively.

Furthermore, because auditing is a native DBMS feature, it is administered by DBAs, which does not maintain segregation of duties, mandates by most security and compliance policies. Auditing is not a viable solution for monitoring the DBAs themselves, as well as other users with privileged access rights to the DBMS, because they can turn auditing on and off as they please, or manipulate the logs after the fact.

Vulnerability assessment Pros: Detects weak database configu-

ration and security holes Cons: Is run periodically (not ‘always

on’), does not offer remediation of security gaps and cannot detect abuse of privileges

Vulnerability scanners and other tools that provide a more comprehensive assessment of database configuration are a valuable addition to database security. However, since they are used periodically (every month or once a quarter), it leaves many gaps in between scans.

Ultimately, a vulnerability assessment may tell you where there are potential security holes in your database, but it will not tell you whether they have already been exploited or not, and it will not fix them for you. This makes the hardening of a large-scale database deployment an arduous chore.

Encryption Pros: Protects sensitive data Cons: Slow and expensive to imple-

ment correctly, key management over- head, has an impact on performance and is difficult to manage

Column-level or table-level encryption within the database ensures that sensitive data such as credit card numbers cannot be viewed by users who have general access to the database (e.g. via a CRM application), as well as segregation of duties.

Column-level encryption is a two- to three-year project for most companies, when it comes to encrypting existing databases. This makes it both impractical and expensive for many applications.

In addition, encryption alone is insuf- ficient, because it is often decrypted for communication with applications, and this creates an opportunity for accessing the encrypted data.

New developments in database security Sometimes referred to as database intru- sion prevention or extrusion prevention, database activity monitoring is a rela- tively new level of protection targeted specifically at databases.

We have seen that the range of security tools commonly available for databases are helpful in managing user rights, pro- tecting sensitive data and finding faults in the database configuration. However, those tools fail to provide (separately or combined) several important aspects that are required for regulatory compli- ance and adherence to best practice in IT security. These are: segregation of duties between security and database administration and development; misuse or abuse of privileges given to insiders (and required for their jobs); and attacks on the database that exploit vulnerabili- ties and cannot be stopped by perimeter security mechanisms.

Database activity monitoring was invented to address those gaps and pro-

vide visibility into the activity that takes place in databases, issue alerts when sus- picious activity is detected and, in some cases, prevent or stop such activity from taking place.

Network approach to monitoring The first generation of dedicated DAM tools was largely made up of network- based appliances. These solutions moni- tor network traffic, looking for SQL statements and analysing the statements based on policy rules to create alerts on illegitimate access to the database and attacks. Because the appliances monitor only the network, they do not look at local database activity, leaving a data- base vulnerable to insiders who either have local access or are savvy enough to bypass the appliances.

In order to provide adequate cover- age, the appliances must be deployed at every choke point on the network from which the database is accessed. For mission-critical databases that are often tied into a multitude of applica- tions (ERP, CRM, BI, billing etc.), this significantly raises the cost of an already-expensive process.

Apart from cost, the network approach has several fundamental flaws. It does not cover local access to the database. If you are capturing and ana- lysing packets from the network, local access using IPC mechanisms (or even TCP) will not be visible. As a solution, some vendors have introduced host- based agents as add-ons to their net- work appliances. This approach (both installing on the host itself and in the network infrastructure) removes the only advantage that network appliances

November 2009 Network Security 5

Figure 1: An example of why it is not enough to monitor a database by capturing network traffic.

DATABASE SECURITY

have – the fact that their installation is more or less non-intrusive.

Worse still, local agents can monitor TCP traffic on the host or IPC com- munications, but they suffer from being even more intrusive since they have to be implemented as a kernel module, mak- ing them hard to install and maintain. To truly monitor a database, it is not enough to capture network traffic, even if you are able to monitor IPC kernel calls.

“To truly monitor a database, it is not enough to capture network traffic”

Where v_cust is a view based on the ‘customers’ table. For monitoring tools to actually catch this, they will have to load and cache all views from the data- base and understand that the ‘v_cust’ view is actually selecting from the ‘cus- tomers’ table. This deficiency extends to other objects such as synonyms, triggers and stored program units (functions, procedures and packages).

To understand whether a procedure is accessing a specific table, it means pars- ing the procedure and understand all procedure branches and cases. No net- work monitoring tool has ever done this, and neither is it feasible (the monitoring product would need to possess a lot of the DBMS’s internal logic to do this).

Pattern matching does not work Another area in which the network approach is lacking is in trying to per- form pattern matching to catch suspi- cious activity. For example, a monitoring tool can be configured to catch ‘grant dba’ commands. When a hacker tries to mount an SQL injection attack using a known Oracle vulnerability, for example, most monitoring tools will issue an alert, because they will match the pattern of ‘grant dba’ and the existence of a vulner- able package.

If the hacker is smarter than that, he will try to evade detection by performing the same attack differently, as in Figure 2a:

Notice that there is no longer ‘grant dba’ in the text and the network bases protec- tions will be blind to what is really going

on. To complicate things further, a hacker could also disguise the call to the vulner- able function using the same technique.

The challenge of data- in-motion encryption Database traffic can be encrypted using vendor-supplied tools or custom-made tools such as SSH tunneling. As soon as data leaves the DBMS, it is encrypted. For network-based monitoring tools to capture this type of traffic, an enterprise must compromise its private keys and

share them with the monitoring appli- ance or application.

This is only one part of the data-in motion encryption problem – database code can also be encrypted, and decrypt- ing it in real time is not possible even if the encryption algorithm is known (and for some vendors like Oracle it is not public). If we create a function such as the following, it will raise the suspicion of the monitoring tools.

However, creating the function using the built-in wrap utility will not sound any alarms, as shown in Figure 5:

6 Network Security November 2009

Figure 2: Most monitoring tools would catch this ‘grant dba’ hack.

Figure 3: Dodging the ‘grant dba’ string will fool many tools.

Figure 4: This function will raise a red flag.

DATABASE SECURITY

November 2009 Network Security 7

Virtualisation is a growing trend in enterprise IT, and specifically in the data centre. The cost savings on hardware, reduced energy consumption and flex- ibility in pooling resources mean that many environments will become virtual- ised, including mission-critical produc- tion environments.

When dealing with virtualisation secu- rity, we are essentially tackling two chal- lenges: protecting the host machine itself and protecting the virtual machine (VM).

It is clear that the network-based approach, while initially benefiting from ease of deployment, misses out on some of the base requirements for which data- base need to be monitored and protected.

Given the blind spots the network- based approach presents, a host-based solution could be much better, if it did not suffer from the overhead in perform- ance associated with older technologies. Such an approach would need to use a novel, non-intrusive method of accessing a database.

Older host-based approaches were met with disapproval for having a negative impact on database performance. This was because host-based tools either relied on turning native auditing on or used the DBMS kernel APIs to interface with a database, a technique that is slow and intrusive as it places itself in the transac- tion path.

A novel method is to directly access the memory allocated to the DBMS by the operating system, especially the shared cache memory (known in Oracle as SGA and in MS SQL as procedure cache).

Advantages of a sensor monitoring shared memory

A memory-monitoring host-based sen- sor is a standalone process written in C++ and running on the database host machine. It is installed using standard platform tools (RPM, PKG, EXE etc.) in a separate OS user account that is part of the SYSDBA (ora_dba on Windows) group on the system.

The sensor should be made to operate independently of the server, and will then

be extremely hard to circumvent or dis- able without generating alerts. The sensor automatically identifies all instances on the machine and can monitor multiple instances on the same host. When run- ning, the sensor attaches itself to the instance shared memory (SGA in the case of Oracle) and begins a polling loop of monitoring by sampling the memory multiple times per second. For every sam- ple cycle, the sensor analyses the currently running and previous statements for each session in the database instance and determines using pre-defined rules and

administrator-defined rules what state- ments it should be alerted on. The suspi- cious statements are sent to the server for further analysis and alerting.

“Virtualisation is a growing trend in enterprise IT, and specifically in the data centre”

Another advantage of a sensor that monitors shared memory is that it can then be configured to terminate sessions on specific violations and to quarantine users. It is non-intrusive and consumes

Figure 5: Using the wrap utility enables the database hacker to fly under the wire.

Figure 6: Sensors monitoring shared memory can be configured to terminate sessions on specific violations.

RECYCLING

only a negligible percentage of CPU resources, with zero impact on disk I/O. The sensor prevention capabilities are implemented using DDL triggers that optionally delay DDL and DCL state- ments for a few milliseconds, allowing the sensor to terminate the offending statements in time.

Policy rules can be sent to such host- based sensors. The policy rules apply to types of SQL statements, database objects, time of day or day of the month, specific user profiles and the applications used. The action taken when the condi- tions of a rule are met can be as simple as logging an event, sending an alert to a security incident management system

via SNMP, or an XML API, sending an email or SMS, terminating a user session to prevent malicious activity and even quarantining users.

Conclusions Database security is a critical component of any information protection strategy. The technology required to monitor and block suspicious database activity has come a long way, and has evolved from native audit through network monitoring to ever-more sophisticated host-based sensors. With threats on the rise and technology maturing, now is the right time for organisations to seri-

ously review the security protecting their database.

About the author

Sudha Iyer is the director of product manage- ment at LogLogic and focuses on database security and compliance solutions. Prior to this, she has held security and technol- ogy product management and engineering management positions at Adobe Systems and Oracle Corporation. Her focus in the last eight years has been on security and identity management solutions that help enterprises improve their security and manage risk and fraud effectively. She is a Certified Information Systems Security Professional and has an MBA from Santa Clara University.

8 Network Security November 2009

Unfortunately, when it comes to what happens to the ICT at the end of its useful life to the organisation, the story changes quite dramatically. What used to be an asset that was controlled and accounted for, and managed by a dedicated team of system managers and security staff, has suddenly become a liability that has no value and takes up valuable space.

The underlying tenet of information security is that it has to be from the inception of the project, through its design and deployment, to its working life and its disposal. Most organisa- tions manage the middle bit reasonably well, but are poor at the early and last stages. How often in the procurement of a new system has the security been added either at the last minute, or retro-fitted?

While we have to address the imple- mentation of security before (or in some cases shortly after) the system comes into

service, the security of information that has accrued on the system during its working life is often overlooked when it comes to disposing of the equipment.

There are a number of reasons for this. The first is that, as mentioned above, the computers (and the storage media they contain) have become a lia- bility. The second is that while system administrators and security staff were responsible for the systems while they were in use, once they become redun- dant they will often be passed over to the storesperson or logistics personnel until they are disposed of.

It is unrealistic to expect that these members of staff will either have knowl- edge of the technology or where it has been used within the organisation. As a result, they are not likely to be aware of, or concerned about, the value of the data or the potential damage that would be caused were it to fall into the wrong hands.

Legislation and data protection

Laws and regulations require organisa- tions to take reasonable care of informa- tion of certain types, the most obvious being that which relates to people (Data Protection Act 1998). But the obvious legislation is merely the tip of the ice- berg. Other relevant legislation includes the Financial Services Act 1986, whose requirements include effective access con- trol plans (difficult if you are not in con- trol of the media). Then, depending on the sector an organisation is operating in, there is also likely to be additional sector- specific legislation and regulations such as the Basel II accord HIPPA, the California state law on disclosure, to comply with.

“The consequences of business plans or intellectual property falling into the hands of a competitor could be disastrous”

The people in charge of organisations also have a responsibility to their stake-

Recycling more than your IT equipment Dr Andy Jones, BT

These days, most organisations have well-documented policies for the procure- ment and the use of information and communications technologies (ICTs). In some organisations the policies are even kept up to date and distributed to the workforce, which enables them to comply with the requirements.

Andy Jones