Freely subscribe to our NEWSLETTER

GS Mag: What are the common ways databases can be attacked?

Ulf T. Mattsson: Making your database secure is not an easy task. The challenges are coming from all angles, inside the organization as well as from the outside. As we look at database security, the starting point is always to know which threats your are addressing, and to ensure the measures you are considering are appropriate for the threats. Organizations are exposed to different threats to the data – via applications, databases, file systems, and backups. The primary vulnerability of pure database security and database encryption is that it does not protect against application-level attacks. For databases that need the highest level of protection, such as Internet-based database applications, consider using specialized intrusion detection and prevention tools to track and eliminate suspicious activities.

GS Mag: How should enterprises secure their databases to meet compliance requirements such as SOX, HIPAA, GLBA, PCI, SB1386, etc.?

Ulf T. Mattsson:While not all of these regulations specifically require the use of stored data encryption, many organizations are moving ahead with implementing encryption for their protected information since a judicial interpretation will likely refer to best practice standards that advise the use of encryption in conjunction with other security layers to protect PII. There is no single point solution that meets all the varied data protection compliance regulations. Every application needs to be accessed individually, and a variety of technologies will probably be required to satisfy compliance. It is clear, however, that requirements to encrypt data at rest have been the most difficult for companies to meet. While laws and regulations interpret "protecting privacy" in a number of ways, situations, any enterprise solution for protecting data - especially data at rest - must include the following components:
• Centralized security policy and reporting across different systems.
• Segregation of data administrative roles and security roles.
• Secure encryption technology to protect confidential data and careful management of access to the cryptography keys.

GS Mag: Should application security be integrated with database security? If so, why?

Ulf T. Mattsson: We continue to see a trend in the direction of more advanced attacks against databases. Synchronized and automated threat responses between the application level and database level provide an effective protection against external and internal attacks. Automated escalation of threat responses between the application level and database level directs the focus of countermeasures in time and between different IT system components, and also optimizes the balances among security level, performance aspects and ease of administration.

GS Mag: When it comes to database protection, are native DBMS security features good enough, or do enterprises need to supplement them with third-party security solutions?

Ulf T. Mattsson: The major DBMS products on the market provide many - but not all - of the key functions within the three major DBMS security categories. Thus, growing concerns about security vulnerabilities and regulatory requirements have created a need for specialized DBMS security vendors, particularly in the areas of encryption, vulnerability assessment, intrusion detection and prevention, and monitoring.

GS Mag: What are the key challenges and issues facing customers when dealing with database security?

Ulf T. Mattsson: Although database security is clearly the best approach to securing sensitive information while maintaining accessibility for the organization, there are always concerns about the level of impact a solution may have on performance, scalability, availability and administration. The challenge is to balance security and performance by narrowly focusing protection on the critical information that needs to be secured, and being aware how that information is used by various applications. Not all approaches to database security have comparable performance curves, but there are approaches that can minimize the impacts. A solution that can balance the security, performance and scalability is the key to any enterprise wide solution. Best practice is also to provide a centralized security policy and reporting across different systems.

GS Mag: Many enterprises want to protect private data from DBA’s - is this possible? If so, how can they go about implementing such separation?

Ulf T. Mattsson: This is not just a problem of trustiness, it is a principle. Technically, if we allow a DBA to control security without any restriction, the whole system becomes vulnerable because if the DBA is compromised, the security of the whole system is compromised, which would be a disaster. On the other hand, if we have a mechanism in which each user could have control over his/her own secrecy, the security of the system is maintained even if some individuals do not manage their security properly. Access control is the major security mechanism deployed in all RDBMSs. It is based upon the concept of privilege. A subject (i.e., a user, an application, etc.) can access a database object if the subject has been assigned the corresponding privilege. Access control is the basis for many security features. Special views and stored procedures can be created to limit users’ access to table contents. However, a DBA has all the system privileges. Because of her/his ultimate power, a DBA can manage the whole system and make it work in the most efficient way. In the mean time, she/he also has the capability to do the most damage to the system. With a separated security directory the security administrator is responsible for setting the user permissions. Thus, for a commercial database, the security administrator (SA) operates through a separate middle-ware, the access control system (ACS), which serve for authentication verification, authorization, audit, encryption and decryption. The ACS is tightly coupled to the database management system (DBMS) of the database. The ACS controls access in real-time to the protected fields of the database. Such a security solution provides separation of the duties of a security administrator from a database administrator (DBA). The DBA’s role could for example be to perform usual DBA tasks, such as extending table-spaces etc, without being able to see (decrypt) sensitive data. The SA could then administer privileges and permissions, for instance add or delete users. For most commercial databases, the database administrator has privileges to access the database and perform most functions, such as changing password of the database users, independent of the settings by the system
administrator. An administrator with root privileges could also have full access to the database. This is an opening for an attack where the DBA can steal all the protected data without any knowledge of the protection system above. The attack is in this case based on that the DBA impersonates another user by manipulating that users password, even though the user’s password is enciphered by a hash algorithm.
The major DBMS products on the market does not provide a segregation of data administrative roles and security roles. Third party products can solve this requirement and provide the needed secure encryption technology to protect confidential data and careful management of access to the cryptography keys. It is possible to prevent DBAs from accessing sensitive data that is stored in the database if column level encryption is used. It is also possible to give DBAs to access sensitive data and provide full accountability and tracking via the tamper resistant audit log in encryption system.

GS Mag: With more enterprises wanting to encrypt their databases, what are the benefits and challenges of data-at-rest database encryption?

Ulf T. Mattsson: Database-layer encryption protects the data within the DBMS and also protects against a wide range of threats, including storage media theft, well-known storage attacks, database-layer attacks, and malicious DBAs. Deployment at the column level within a database table, coupled with access controls, will prevent theft of critical data. Application-layer encryption requires a rewrite of existing applications, which is impractical due to limited IT resources, lack of access to source code, or a lack of familiarity with old code. Rewriting applications is also very costly, risky and introduces an implementation time delay factor. Lastly, all applications that access the encrypted data must also be changed to support the encryption/decryption model. Storage-layer encryption alone can only protect against a narrow range of threats, namely media theft and storage system attacks.

GS Mag: What does a comprehensive database security solution consist of?

Ulf T. Mattsson: A comprehensive best practice database security solution is based on segregation of duties and consists of encryption, assessment, alerting and auditing, and is tightly integrated with other technology stack components. A comprehensive enterprise data protection solution should protect against external and internal threats by combining security solutions at the application level, database level and file level. The field level encryption approach is very useful when dealing with EDI/FTP/Flat files being transferred between the disparate systems. At no time is sensitive data in an unencrypted state at rest on any of the systems. This type of solution is well suited for data elements (e.g. credit cards, email addresses, critical health records, etc.) that are processed, authorized, and manipulated at the application tier. If deployed correctly, application-level encryption protects data against storage attacks, theft of storage media, and application-level compromises, and database attacks, for example from malicious DBAs. Some column level encryption solutions rely on database triggers to intercept the encrypted data and invoke a stored procedure, which, depending on the solution, may require an API call outside of the database server. In fact, some column level encryption solutions require a network round trip to perform the cryptography operation on a hardware box. The network latency that this entails is orders of magnitude slower than performing cryptographic operations on data in memory. Each of these steps to “hook into the database” cause substantial performance penalties that may be many times larger than the actual cryptographic operation. Scaling and system performance is critical to meeting the needs of an enterprise. Introducing another variable into the infrastructure that prevents scaling in a predictable manner can bottlenecking the flow of data and prevent the organization from achieving the forecasted returns on its IT investment. Encryption should be implemented in such a way as to leverage the existing, high-performance infrastructure and scale with that infrastructure.

GS Mag: Majority of enterprises have heterogeneous DBMSes. What are the best practices to secure databases in such environments?

Ulf T. Mattsson: Best practice is to provide a centralized security policy, key management, and reporting across different systems. Implementing a data privacy solution can be done at multiple places within the enterprise. There are implementation decisions to be made as well. Where will you perform the data encryption — inside or outside of the database? Your answer can affect the data’s security and critical operational aspects. Choosing the point of implementation not only dictates the work that needs to be done from an integration perspective but also significantly affects the overall security model. The sooner the encryption of data occurs, the more secure the environment—however, due to distributed business logic in application and database environments, it is not always practical to encrypt data as soon as it enters the network. Encryption performed by the DBMS can protect data at rest, but you must decide if you also require protection for data while it’s moving between the applications and the database. How about while being processed in the application itself, particularly if the application may cache the data for some period? Sending sensitive information over the Internet or within your corporate network clear text, defeats the point of encrypting the text in the database to provide data privacy. Good security practice is to protect sensitive data in both cases – as it is transferred over the network (including internal networks) and at rest. Once the secure communication points are terminated, typically at the network perimeter, secure transports are seldom used within the enterprise. Consequently, information that has been transmitted is in the clear and critical data is left unprotected. One option to solve this problem and deliver a secure data privacy solution is to selectively parse data after the secure communication is terminated and encrypt sensitive data elements at the SSL/Web/application/database layers. Doing so allows enterprises to choose at a very granular level (credit-card numbers, usernames, passwords, etc.) sensitive data and secure it throughout the enterprise.

GS Mag: How can production data be securely used in a test system?

Ulf T. Mattsson: Production data is in many cases need to ensure quality in system testing. Key data fields that can be used to identify an individual or corporation need to be cleansed to de-personalize the information. Cleansed data needs to be easily restored (for downstream systems and feeding systems), at least in the early stages of implementation. This therefore requires a two-way processing. The restoration process should be limited to situations for which there is no alternative to using production data (eg. interface testing with a third party or for firefighting situations). Authorization to use this process must be limited and controlled. In some situations, business rules must be maintained during any cleansing operation (e.g. addresses for processing, dates of birth for age processing, names for sex distinction). Scrambling should be either consistent or variable with different cleansings. There should also be the ability to set parameters, or to select or identify fields to be scrambled, based on a combination of business rules. A solution must be based on secure encryption, robust key management, separation of duties, and auditing.