Database Security is More than Just Compliance Controls
Databases, which hold more than just corporate IP, usually have standard controls in the form of firewalls, web application protection, and data masking/encryption/tokenization, etc. Is it enough? While these controls can help you with compliance, and as we know all too well, compliance does not always equal security, especially when it comes to databases. These baseline and compliance controls are a good first step in protecting the information in your databases, however there is more work to be done. The hard database security challenges most organizations face include:
• Lack of visibility of data and access. Not knowing where sensitive data is located and who is accessing the database. It’s easy if there is only one potential location but, in most environments, there are more than just one or even a few databases in use. Between staging, development and production environments it’s easy to see why it can become difficult. Awareness is half the battle and that certainly applies to knowing where the sensitive data is located and who is accessing that data.
• Regulatory Compliance. There is not a single year going by where there isn’t new regulation introduced or older regulation updated. With that in mind, organizations are constantly under pressure to comply with new or changing regulations. Having the ability to be compliant with the database infrastructure provides the “peace of mind” and frees up time and resources to concentrate on other security or compliance projects.
• Malware intrusions. SQL Injections, Ransomware and a lot more. Those are known and rising problems for all data center endpoints, including databases. Adding additional layers of security is a necessity.
Nearly all databases are network-accessible, a security threat to any component within or with access to the network infrastructure is also a threat to the database. Additionally, any attack impacting a user’s device or workstation can also be a threat. Database security must extend far beyond the confines of the database alone.
When architecting database security in your environment, it is important to establish the business drivers and the required desired business attributes (e.g. security, privacy, availability, compliance) to achieved these. These will help you determine the security controls that need to be implemented. However, the ability to operate these controls at the application and database level without being intrusive to operations and performance need to be considered, especially is performance is a required business attribute. To properly secure the database environment from malicious code and data loss, consider each of the following areas:
• Administrative and network access controls: The least privilege rule applies here. What is the practical minimum number of users should have access to the database? Their permissions should be restricted to the minimum levels necessary for them to do their jobs. Likewise, network access should be limited to the minimum level of permissions necessary.
• End user account/device security: Always be aware of who is accessing the database and when and how the data is being used. Data monitoring solutions can alert you if data activities are unusual or appear risky. All user devices connecting to the network hosting the database should be managed with security posture checks performed before they can connect to the database.
• Discovery of all databases within the enterprise: You can’t protect something if you don’t know it exists. Building solid security around databases begins with two important steps: finding them all, and then figuring out where the associated weak spots are.
• Monitoring activity for unauthorized access: All databases respond to commands. If a command is appropriate for the user requesting data, it will be successful. As attacks and tools become more sophisticated, attackers can evade typical detection techniques and escalate privileges. Weak access controls make the job of an attacker even easier.
• Encryption: ALL data—including data in the database, and credential data—should be protected with best-in-class encryption while at rest and in transit. All encryption keys should be handled in accordance with best-practice guidelines.
• Application/web server security: Any application or web server that interacts with the database can be a channel for attack and should be subject to ongoing security testing and best practice management.
• Backup security: All backups, copies, or images of the database must be subject to the same (or equally stringent) security controls as the database itself. This also includes encryption of the backups, if possible.
• Auditing: Record all activity, including logins to the database server and operating system, and log all operations performed on sensitive data as well. Database security standard audits should be performed regularly. Keep in mind, that native logging and auditing capabilities of databases fall far short of providing the right visibility. Most will not capture changes made, privileges used, respective administrators, or any system-level changes. Further, logging and auditing activities integrated within the database can hinder database performance. Designed for monitoring, not security, administrators can also turn these features off, eliminating any value the native tools might have provided.
• Proof of compliance with industry, government, and internal standards. Depending on the role of your database, it may need to adhere to, report against, and maintain policies for a range of regulations, such as GDPR, PCI DSS, Sarbanes-Oxley, etc.
Avocado Systems can help you protect your databases and the systems that make up the full application workload stack. Let us show you how we do it.
