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-
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-
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-
A growing number of DBMSs offer label-
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-
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-
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-
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-
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-
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-
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-
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-
Higher transaction velocities will result in more real-
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-
From Information Today, Cybersecurity Sourcebook 2017.
© 2017 Craig S. Mullins,