Defense in Depth: Securing Databases
Author’s Note: Our Defense In Depth series will demonstrate how over the past several years Corso Systems has helped companies implement security. The series includes relatively easy best practices like ensuring your systems are secured with user accounts, network segmentation with Firewalls to reduce the flow of traffic to only what is necessary to move between each part of your operation. We will also discuss more complex technologies such as threat detection, and backups/disaster recovery so you can get back up and running even in the worst case scenarios.
Most manufacturing and critical infrastructure systems (utilities, wastewater treatment, communications, dams, and many more) use databases to store configuration data, recipes, and important process data. With the widespread adoption of tools like Ignition making it easier than ever to connect databases to SCADA systems, databases are a prime target for attack.
As the importance of databases grows for manufacturing facilities and critical infrastructure it is imperative to take a security minded approach to your databases as part of your overall manufacturing technology stack.
This post focuses on securing databases, both from a user authentication perspective and a data integration perspective.
Database User Security
User Roles
Database platforms typically start with a fully unlocked default user with full administrative rights. This is useful for setting up the initial databases on the server, creating user roles, etc.
When possible this default user should be disabled after the initial configuration is completed and if full administrative rights are needed, a non-default user should be set up. Ideally this user should be locked down to only be able to access the database server from specific computers and should not be used in any integrations with the database. Disabling the default user will reduce your overall cybersecurity risks because attackers will know the default username for each type of database you are using and can more easily wreak havoc on your system if they can figure out the password. Removing this default user from the equation adds more steps to the process of gaining full access to your database systems.
In contrast, when setting up users for general database integrations you should apply the concept of least privilege, meaning you give users only the least amount of privileges they need to complete their tasks. This will reduce your overall risk by making it difficult to do things like delete tables and data, add new users to the system, or cripple your database infrastructure in harmful ways.
Access Control Lists
Once you have users set up with the relevant privileges they require you need to also consider setting up Access Control Lists on your network to prevent access to databases from anything other than previously specified computers or accounts. This will help reduce your risk of an attack by preventing someone from making changes to your databases from any computer on the network if they have gained access to your systems.
Database Integration Security
Networking
Integrations with your database will take place over an ethernet connection in most instances, or happen directly from the server the database is installed on in some cases. This means you will need to manage what ports your database is using. Database server typically have a default port they use to communicate. This makes it easy to set them up and manage them across many different use cases, however this also means attackers will know the default ports. In addition to using firewalls to lock down traffic on unused ports, it is a smart move to change your database ports from the default to something else. This adds another layer of effort required for an attacker to gain access to your databases.
SQL Injection Attacks
One very common threat to all databases is known as a SQL Injection Attack. This type of attack lets someone put code into a SQL query causing malicious behavior. An easily understandable example of this from an xkcd comic where a school’s database table with student information is dropped when they enter the cleverly concocted name of a student.
Most modern database integration tools let you easily prevent this type of an attack by using query parameters. This takes advantage of tools built-into the database engine itself to parse out these sorts of things and prevent them from happening in the first place.
Specific to the Ignition world query parameters are built into named queries and the system.db.runPrep* scripting functions. Not only does using these approaches to query integration simplify development of queries compared to using the comparatively unsafe system.db.run* function calls, it gives you access to SQL Injection Attack prevention with no additional effort. The Perspective Module helps ensure you use named queries by only allowing you to do bindings to components on views using Named Queries.
Buffer Overflows and Input Validation
Similar to SQL Injection Attacks another common attack on databases is known as a buffer overflow. This type of an attack is something that can still occur even when using SQL Query Parameters. Basically the idea is that if you have a column with a fixed length, say a string with 255 characters, someone can write a string with 555 characters to the column. Depending on how you have things set up if the attacker is clever about what they put into those extra 300 characters and the database writes them to the server’s memory they can gain access to your system.
Yes this is a more complex attack than SQL Injection, and may require more information about the underlying structure of the server your database is installed on, however it is an easily preventable attack.
Managing buffer overflows requires additional effort on the development side, doing something called Input Validation. From our basic example, if the user is inputting something from a form, say a street address with a maximum size in the database of 255 characters you need to take the input from the form, parse out all of the fields and limit any data sent to the database for the street address column to 255 characters. This will prevent the additional characters from being written and exposing your servers to the attacker.
You can also be diligent about what datatypes you use in your database to help simplify the development side of things, however you should always do some form of Input Validation to prevent these types of attacks from succeeding.
Auditing and Database Log Management
Databases will typically log all activities that happen with the database. From query execution, login attempts, both successful and unsuccessful, to configuration changes. It is important to activate logging tools in your database, as well as incorporate log management and monitoring tools to alert you of any weird behavior.
Another benefit of log audits and monitoring is they will help you discover and troubleshoot any issues your database has as part of normal day to day operation.
Device Security
In conjunction with database specific security best practices you should ensure device level security to ensure people only have access to what they need, and their devices are secure in the first place. Even with all of the best cybersecurity risk mitigation in place, if someone has access to a company computer and that computer has administrative level access to the database they can basically do whatever they want to your systems.
This means you need to be diligent about password rotation for your users and not storing passwords in version control systems. Where possible you should not leave accounts logged into database management tools, ideally requiring additional access to another machine through a secure connection to make any database changes. Yes, this means while it might be easy to store all of your database connections in your database management tool with “Save Password” checked this is one way to open yourself up to attack.
If you do need to have access to your systems set up on employee’s computers it is wise to require two factor authentication for them to login to your database systems.
Backups and Data Encryption
Not only do you need to be concerned about connections to your live databases, it is important to lock down access to your backups in a similar way. The specifics of how to do this could be its own series of posts, so we recommend working with IT to secure your backups, or reaching out to Corso Systems so we can help you get things squared away.
Another important consideration is data encryption, both in the database itself, and as data is being sent from the various systems where the data originates to the database itself. Data Encryption for data “at rest” or data in the database is a function of the specific database you are using and can be configured using the relevant tools.
Data encryption for data passing over the network requires the use of certificates and using https connections instead of http. This can have some additional configuration and certificate management burdens. IT will typically need to be involved on this aspect of security on top of all of the network infrastructure to support it and you can also reach out to Corso Systems so we can help you get things set up in the most secure way possible.
Wrapping Up
Databases are a critical aspect of most modern technology systems. They contain data and information vital to the operation of your company. The data can help manage regulatory reporting requirements, process optimization and quality management activities, and can often even provide customer service advantages compared to your competitors.
Due to the highly valuable nature of the information in databases they are a prime target for cybersecurity threats and need to be managed as such.
If you take a proactive approach to securing your network, the systems connecting across your network, and take advantage of the best practices in this post, your database security will keep your data safe for the long term.
Please take this post to heart and make sure you have everything you need in case disaster strikes, wherever it may come from.
