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 have become a prime target for attack.
As databases become increasingly important for manufacturing facilities and critical infrastructure, it is imperative to take a security minded approach to them as part of your overall manufacturing technology stack.
This post will focus 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 (and after the initial configuration is completed), disable this default user. If full administrative rights are needed for a role, then set up a non-default user for this purpose. Ideally this should only be able to access the database server from specific computers and will not be used in any database integrations. Disabling the default user will reduce your overall cybersecurity risks because attackers already 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 the 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, apply the concept of least privilege. This means that 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 for the wrong users to delete tables and data, add new users to the system, or cripple your database infrastructure in harmful ways.
Access Control Lists
Once your users are set up with their relevant privileges, also consider setting up Access Control Lists on your network to prevent database access 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 usually occure over an ethernet connection, or in some cases connecting directly to the server where the database is installed. This means you will need to manage the ports your database is using. Database servers typically have a default port for communication. This makes it easy to set them up and manage them across many different use cases, however this also means that attackers know the default ports. In addition to using firewalls to lock down traffic on unused ports, it’s also a smart move to change your database ports to something other than the defaults. This adds yet another layer of effort for an attacker to gain access to your databases.
SQL Injection Attacks
A very common threat to all databases is a SQL Injection Attack. This type of attack lets someone put code into a SQL query causing malicious behavior. A fun easily understandable example is on this 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 leverages tools built into the database engine itself to parse out errors and malicious input and prevent these attacks from happening in the first place.
Specific to Ignition, query parameters are built into named queries and the system.db.runPrep* scripting functions. Using these approaches to query integration simplifies query development compared to using the comparatively unsafe system.db.run* function calls, and 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 add bindings to components on views using Named Queries.
Buffer Overflows and Input Validation
Similar to SQL Injection Attacks, another common database attack is a buffer overflow. This type of an attack is something that can still occur even when using SQL Query Parameters. Essentially, if you have a column with a fixed length (ex: a string with 255 characters), someone can write a string with 555 characters to the column. Depending on how the database is 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, then they can gain access to your system.
While this is a more complex attack than SQL Injection, and requires the attacker to have more information about the underlying structure of the database server, however it is still an easily preventable attack.
Managing buffer overflows requires additional effort on the development side by implementing input validation. From our basic example above, if the user is inputting a street address on a form field 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 getting written to memory and exposing your servers to the attacker.
You can also be diligent about the datatypes in your database to help simplify development, however you should always perform 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 so that people only have access to what they need (and their devices are secure in the first place). Even with the best cybersecurity risk mitigations 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 is why it’s also important to be diligent about password rotation for your users and not to store passwords in version control systems. When possible, don’t leave accounts logged into database management tools. Ideally, require additional access to another machine through a secure connection to make any database changes. While this means it might be easy to store all of your database connections in your database management tool with “Save Password” checked, this is also another way to open yourself up to attack.
It’s also a good idea to require two factor authentication if your employees need access to your systems from their workstations.
Backups and Data Encryption
Along with security concerns around connections to your live databases, it is also important to lock down access to your backups. 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 within the database itself, and as the data travels between your systems from its origin to the database. 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.
Encryption for data traveling through the network requires certificates and secure (https not http) connections. This can have some additional configuration and certificate management burdens. Typically, IT will need to be involved in the security of your network infrastructure to support it. You can also reach out to Corso Systems, as we can also help you set up your systems in the most secure way possible.
Wrapping Up
Databases are a critical component 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 provide customer service advantages compared to your competitors.
Unfortunately, because the information in databases has a highly valuable nature, databases are a prime target for cybersecurity threats and need to be carefully managed.
If you take a proactive approach to securing your network, the systems connecting across your network, and use 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.
Need help or advice securing your database and network?
Corso Systems can help!
Schedule an intro call with Cody Johnson in sales ASAP
Or contact us with your project details.
