Securing Servers & Databases

In a recent podcast interview with Hillarie McClure, Multimedia Director of Cybercrime Magazine, Robert E. Johnson III, Cimcor CEO/President, discusses how to properly secure your servers and databases. The podcast can be listened to in its entirety below.

Welcome to The Data Security Podcast sponsored by Cimcor. Cimcor develops innovative, next-generation file integrity monitoring software. The CimTrak Integrity Suite monitors and protects a wide range of physical, network, cloud, and virtual IT assets in real-time while providing detailed forensic information about all changes. Securing your infrastructure with CimTrak helps you get compliant and stay that way. You can find out more about Cimcor and CimTrak on the web at cimcor.com/cimtrak. 

Q: Joining us today is President and CEO, Robert E. Johnson III. Robert has been a pioneer in the development of next-gen system integrity monitoring, self-healing systems, and cybersecurity software. Robert, welcome back. Looking forward to our conversation today.

A: Thank you, Hillarie. I always love being on your show. You always ask a lot of interesting questions, and we have so much to talk about.

Q: Yeah we do, we do, and I'm glad that you find my questions interesting. So for today, first interesting, hopefully interesting question for today: You know, we've heard so many people discuss problems with databases not being secure, so I'd like to do it. I feel like we've been doing a lot of deep-dives lately, but I think this is another good topic for a deep dive, you know. To start off - What is database security, and why is it important?

A: Well, database security is the process of ensuring that only the right resources have access to the correct pieces of data. I would not say that databases are inherently not secure. In fact, I think that most of the databases out there have all the tools necessary to allow them to be secure. The issue is that typically those databases are not configured, by default, in the most secure configuration.

When you think of a database, you typically only think of the data. You know, some people think "Well, it just holds all my data." A database actually has four key layers that somehow need to be protected. The first layer, and the obvious layer is all of the data. These are the records and information that are being stored, and what you typically think about in terms of a database. But there are other layers, other components of a database that we need to speak about, that are often neglected. For instance, the communication layer. This is a layer of logic that allows the database to send data or transmit and receive data from other applications, or to the user that requires certain information out of that database. So that's a critical area to protect. The next layer is the meta layer or a metadata layer. This is the layer that has all of the schema files and metadata associated with the database.

So examples, because most people don't actually know what a schema is, or a metadata. Examples of schema data would be the users of that database or table definitions, or many organizations store a lot of business logic, in-store procedures. So in-store procedures are a piece of that schema and part of that meta layer. And then, finally, that the fourth layer is the file layer. Every database in the end is a set of executable files and configuration files that actually comprise that database product. That's a very sensitive and important part to protect. So each of these layers are important, and each must be secure in one fashion or another.

Q: Robert, I've heard the concept of database activity monitoring isn't enough. So can you, I guess, as the next part of this deep dive into securing servers and databases - Can you elaborate on that?

A: Yes, that's correct. Database activity monitoring is not enough. That helps a little bit at the data layer, and it's a great way to create this audit trail of transactions at that data layer. However, there's so much more that should be considered. A good starting point is actually to perform system hardening of the database itself. Now, that means that you would be making changes to database configuration settings in order to configure that database in a hardened state according to best practices. Now, how do you know what those best practices are? Well, a great example of those best practices are defined by the CIS Benchmarks. CIS Benchmarks exist for many databases, such as Oracle and SQL Server, MySQL, and many more. Hardening the database helps secure the communication layer, and to an extent, helps secure the meta layer. However, you also need to consider that file layer, and that's where you really need a tool like file integrity monitoring, or, preferably, system integrity assurance software. So because that would allow you to monitor all of that key metadata that may be in your schema, such as those store procedures that may hold that critical business logic, and database users, and to ensure that there are no malicious or unexpected changes to them, or to the files.

In addition, the files associated with that database could be monitored, and, ideally, detect any changes to those configuration files or executable files in real-time.

Q: We also seem to be hearing about the risks organizations take when steps are not taken to secure their databases. But, ultimately, I guess, Robert, where should an organization start to begin managing database security?

A: Securing databases has traditionally been very difficult. Very few tools exist to help. At Cimcor, you know, we identify this as a problem that we really wanted to help solve. So our product, The CimTrak Integrity Suite can monitor those forgotten database security layers. For instance, that metadata layer or the file layers. It can monitor them for unexpected changes. It can also leverage CIS Benchmarks in order to continuously assess all of the configuration data of those databases to ensure that it's configured in the most secure way possible according to current best practices. CimTrak supports the most popular databases, such as Oracle and DB2 SQLServer, and several others. So you know, I think this issue is critically important and often ignored in our industry. And, Hillarie, we really want to help you and your audience solve this problem. So if anyone has an interest in trying this on your own databases, protecting those forgotten layers, please contact us at www.cimcor.com, and we'll be glad to provide you or your audience with a free trial or free demo.

Q: Wonderful. Well, Robert, thank you so much, as always, for taking the time to come on and lend us your expertise. Really appreciate it. And it was very nice speaking with you.

A: It was great speaking with you as well, Hillarie, and I look forward to seeing you again on the next episode of your show.

Q: That sounds great. Thank you, Robert.

A: Thank you.