©  2021  Mullins Consulting, Inc.   All Rights Reserved   Privacy Policy   Contact Us

The Role of the DBA in Cybersecurity

by Craig S. Mullins

Protecting sensitive data from criminals, hackers and other prying eyes is an important aspect of providing security for modern systems and applications. Data is central to business and whenever it is breached for any reason there will be repercussions, whether they be financial, regulatory, or otherwise. And the most important data is stored in a database management system. As such, database administrators are tasked with protecting the core data assets of their organizations.

The Current State of Data Security

Data security and privacy are top corporate initiatives these days. Instead of being ignored and relegated to IT staff as in the past, today executives are being held accountable for data protection. This change has been driven, in many cases, by regulatory requirements, but also as a reaction to the publicity and negative impact of the ever-increasing number of data breaches. This shift has elevated data security and protection planning to the executive level.

Of course, executives are not the implementers. For data security, DBAs are the technology experts who translate the specific requirements as outlined by the business into an actual implementation. But having executives involved with – and held accountable for – data security makes it easier for the DBA team to get visibility and funding for data security projects.

Furthermore, implementing security measures within IT systems has a more elevated status in organizations because customers are becoming increasingly suspicious of big companies in terms of what data is being collected and how businesses secure and protect their data. Most organizations could use improved techniques and tools for protecting data, and the big data trend only exacerbates the situation. Organizations must be able to quantify the business value of their data and categorize exposure and loss of data in terms of the reduction in value, impact to the company’s reputation, loss of potential trade secrets, etc.

Fortunately, DBMSes have gained more security features over the past few years and will continue to do so. Database security is much more than simple logon/password authentication and authorization, but now comprises multiple additional techniques and capabilities.

Improving Database Systems Security

An important database security feature for data protection is data encryption. When data is encrypted it is transformed using an algorithm to make it unreadable to anyone without the decryption key. The general idea is to make the effort of decrypting so difficult as to outweigh the advantage to a hacker of accessing the unauthorized data. There are two situations where data encryption can be deployed: data in transit and data at rest. In a database context, data “at rest” encryption protects data stored in the database, whereas data “in transit” encryption is used for data being transferred over a network.

Encrypting data at rest is undertaken to prohibit “behind the scenes” snooping for information. When the data at rest is encrypted, even if a hacker surreptitiously gains access to the data behind the scenes, without the decryption key the data is meaningless. Data at rest encryption most commonly is supported by using built-in functions, a DBMS feature such as Oracle Transparent Data Encryption or through an add-on encryption product.

Encrypting data in transit protects against network packet sniffing. If the data is encrypted before it is sent over the network and decrypted upon receipt at its destination, it is protected along its journey. Anyone nefariously attempting to access the data en route will receive only encrypted data. And again, without the decryption key, the data cannot be deciphered. Data in transit encryption most commonly is supported using DBMS system parameters and commands or through an add-on encryption product.

A growing number of DBMSs offer label-based access control (LBAC), which delivers a lower level of control over authorization to specific data in the database. With LBAC it is possible to support applications that need a more granular security scheme. LBAC can be set up to specify who can read and modify data in individual rows and/or columns.

LBAC is not for every application; it is geared more for top secret, governmental and similar types of data. For example, you might want to set up an authorization scenario such that each column and row has specific rules pertaining to which employees can see and manipulate the data. Setting up such a security scheme is virtually impossible without LBAC. An administrator configures the LBAC system by creating security label components, which are database objects used to represent the conditions determining whether a user can access a piece of data. A security policy, composed of one or more security label components, is used to describe the criteria for determining who has access to what data. The security administrator defines the policy by creating security labels that are composed of security label components. Once created, a security label can be associated with individual columns and rows in a table to protect the data held there. When a user tries to access protected data, that user’s security label is compared to the security label protecting the data.

Any attempted access to a protected column when the LBAC credentials do not permit that access will fail. If users try to read protected rows not allowed by their LBAC credentials, the DBMS simply acts as if those rows do not exist. This is important because sometimes even having knowledge that the data exists (without being able to access it) must be protected.

Consult your DBMS documentation for where and how to establish this hierarchy and how to use LBAC.

An additional technique for protecting database data is to deploy data masking and obfuscation. Data masking is the process of protecting sensitive information databases from inappropriate visibility by replacing it with gibberish or realistic but not real data (in the case of production data used in test systems). The goal is that sensitive personally identifiable information is not available outside of the authorized environment. Protecting sensitive data using data masking can prevent fraud, identity theft, and other types of criminal activities. A common usage of data masking is to comply with PCI-DSS regulations to show only the last 4 digits of a payment card number on a receipt.

Data masking can be done while provisioning test environments so that copies created to support application development and testing do not expose sensitive information. Valid production data is replaced with usable, referentially intact, but incorrect or obfuscated data. After masking, the test data is usable just like production data, but the information content is secure.

It is possible to mask data using a variety of techniques. A good data masking solution should offer the ability to mask using multiple techniques. Common techniques include substitution, shuffling, number and data variance, nulling out, encryption, and table-to-table synchronization. Data masking is supported by many DBMS offerings as well as by third party products.

Yet another useful technique available in some DBMS products is the concept of a trusted context. A trusted context is used to identify a specific location from which interactions between the DBMS and an application are authorized. This establishes a trusted relationship between the DBMS and an external entity, such as a middleware server. Without a trusted context connecting to these tiered platforms uses one system userid for establishing the connection, as well as for performing all transactions on behalf of every end user. That means that even though individual users authenticate at the application server, the application itself uses a generic authid and ­password, perhaps hard-coded into programs. The generic authid has the authority to access and modify data in application tables, which can cause problems if the password becomes common knowledge.

A trusted context solves this problem by granting the privileges for dynamic SQL activity to a ROLE, instead of to a general authid. The ROLE, available only within the trusted context, provides context dependent privileges. The privileges granted to the role can be exercised only through the trusted connection.

Database auditing, sometimes referred to as Data Access Monitoring (DAM), is yet another data protection technique that is growing in adoption. Database auditing is the process of monitoring access to and modification of selected database objects and resources within operational databases and retaining a detailed record of the access that can be used to proactively trigger actions and can be retrieved and analyzed as needed.

Sensitive corporate data cannot be fully protected by simply setting up database authorization using the controls within the database software. This is so because it is not possible to guarantee that surreptitious access to sensitive data is blocked with simple database authorization mechanisms. And secondarily, it is possible for authorized users to nefariously access data. Database auditing can help protect data in both of these situations.

All of the major RDBMS products offer built-in capabilities for auditing databases, but ISVs offer more capable software with more flexible capture technology, prepackaged compliance reports, and multi-DBMS support. Database auditing software can comprehensively track the usage of database resources and authority. When auditing is enabled, each database operation produces a detailed audit trail of information, tracking what data was accessed, who accessed it, and when. Operators can analyze the audit trail and generate reports showing access and modification patterns against the sensitive data in the DBMS.

Database auditing helps answer questions such as “Who accessed the payment account details for Mr. Jones?” or “When was Mrs. Smith’s appointment time changed?” as well as “Who changed that appointment time?” It is even possible to answer more detailed questions such as “What was the old appointment time prior to the change?”

Of course, database auditing can create management issues. First we have the need for separation of duties, which means that audited individuals should not be involved in managing the audit process. But DBAs typically control the starting and stopping of audit traces. What is to stop a DBA with hacking on his mind from stopping the audit trace before he does so? Implementing privileged user auditing can manage this issue.

Another problematic area is performance management. One of the long-standing issues with such approaches is the large amount of resources that auditing can consume. When auditing is enabled it can slow down database performance. But if you tackle the task appropriately, by pinpointing who and what needs to be audited – and possibly using advanced software to minimize the overhead – performance issues can be mitigated.

Unfortunately, even though all of these features are commonly available in many of the most popular RDBMSes, they have not been adopted as widespread as is needed. Time is required for DBAs to learn and implement new and advanced security options, and this is the current state of database security in most shops.

The Role of the DBA

The DBA is tasked with managing the organization’s database systems. Most DBAs have significant IT experience and have worked their way into a trusted position as a DBA. Nevertheless, DBAs are a significant insider threat in most organizations because they have elevated authority to access data and make changes to database structures. DBAs are, for the most part, trustworthy and want to do a good job in terms of managing and protecting their company’s data. But there are always exceptions, and that is why one of the most common forms of database auditing implemented today is privileged user auditing.

DBAs, typically with high-level authority such as DBADM or SYSADM privileges, may have carte blanche access to the database instance and all its data. DBAs are trusted agents and should not abuse the overarching privileges they are granted. The general maxim of “trust, but verify” applies in this case. DBAs need a high degree of authorization to do their job, but that also brings the opportunity for nefarious activity. Implementing privileged user auditing to track every action taken by such users is a wise course of action. Using a database auditing solution to enforce privileged user tracking can ensure that trusted users are acting appropriately.

The DBA should be an advisor to the business in terms of the types of database security that can be enbled. At a high level, this boils down to being able to answer four questions:

 Who is it? (authentication)

 Who can do it? (authorization)

 Who can see it? (encryption)

 Who did it? (audit)

And how to ensure that these questions are implemented technologically in the DBMS. DBAs are not required to understand business-specific regulatory requirements, but must be able to understand the regulations that are communicated to them and translate that into actual DBMS functionality, if it exists, to satisfy the requirement.

The Future

The near-term future must be spent on understanding and implementing the database security and protection measures that are already available to us. As we make progress there, the next step is to protect more types of data and to make more use of autonomics and analytics.

In terms of more types of data, it is not just relational data but also data in NoSQL databases and big data platforms, which are becoming more common, that also need to be protected. In many cases, security is often an afterthought, if it is thought of at all in many of these systems. As more types of non-relational data stores get implemented integration of security methods and protocols across disparate, heterogeneous DBMSes will need to be implemented. Administering security separately for each DBMS in use (e.g. Oracle, SQL Server, MongoDB, and Cassandra) will be burdensome and overarching techniques will be desired.

Higher transaction velocities will result in more real-time event processing. This can have a profound impact on data protection and security. For example, fraud detection benefits from being as close to real time as possible, in order to perhaps become fraud prevention. And real-time processing of large data streams is another aspect of big data projects that is likely to be a challenge for DBAs.

But keep in mind that big data projects typically are accompanied by powerful predictive analytics. By analyzing reams of data and uncovering patterns, intelligent algorithms can make reasonably solid predictions about what will occur in the future. This requires being adept enough to uncover the patterns before changes occur, but not necessarily in real time. An expert system that recognizes data access patterns can have a big impact on improving data protection procedures. More usage of, and reliance on, AI and machine learning capabilities will bolster our ability to protect corporate data. These improved threat detection capabilities will be able to recognize patterns of attack on data and stop them automatically – before your data has been compromised.

The bottom line, though is that there will be an ever-increasing number of threats to our databases. Why is that so? Well, it is like the old saying goes: “Why did you rob that bank? Because that’s where the money is!” So hackers will target databases because that is where the data is. That means that we need to be diligent in implementing the security measures currently at our disposal to stop the current onslaught of potential hacking, but also to be prepared to implement new and improved database security methods and procedures as they become available.

May 2017

From Information Today, Cybersecurity Sourcebook 2017.

© 2017 Craig S. Mullins,