Re: Security and the DBA - Page 2

shaggyDBA · ‎02-15-2018

Maybe someone can shed some light on this for me.

I've been doing database-related security work for ~6 years and it seems there there is no "formal" guidance concerning databases. Sure there are plenty of consultants out there capable of assisting and there certainly is no shortage of guidance from the likes of DISA on what you should be doing, but I haven't seen anything formalized as to "here's how you should secure your database" and, more concerning "here's how you should manage a forensic investigation of a database in the event of a breach".

I'm from an Oracle background, so I know David Knox & company have a ton of material out there. I also know Pete Finnigan has recently published a fantastic book "Oracle Incident Response and Forensics". But I rarely see anything from (ISC)2 beyond data security recommendations.

Data generation and consumption is increasing at an exponential rate and it is up to the DBA to maintain the CIA of said data. But how does the DBA respond to a breach? What factors should the DBA be considering? These are the things I don't see much of in the public domain, whether it be (ISC)2, SANS, etc.

Very curious about this and interested in hearing others insight/experience on this topic.

Shawn

shaggyDBA · ‎02-28-2018

The database may be a sliver, but isn't the data held therein the theoretical prize?

So here's my concern (and I openly accept that this might be naive) - let's say a breach has occurred and an investigation is underway. How does one state with any level of confidence what data was compromised without investigating the database internals?

If I'm depending on file access or log analysis how can I be assured that I have an accurate picture of what was compromised? What if sensitive data is logically separated (via different schemas), but still exist in a datafile with non-sensitive data? How would we determine which schema had been compromised as part of our analysis? Or do we move under the assumption that if a datafile was accessed any data in said file could've been accessed?

I'm not trying to stir a pot or make databases the end-all-be-all, but I do have some concerns/questions about the how for narrowing the scope of a data breach.

Thanks to all for the feedback on this!

Baechle · ‎02-28-2018

@shaggyDBA

Your scenario and questions are not naive at all. And I say what I have to say from the standpoint that based upon my training and experience, I am confident in the methods that I would employ right now. That could change based upon a best practice that comes out as soon as I post this reply.

I would say that your first step is to stop. Take a deep breath. Verify that you’re conducting a forensic investigation and not incident response, and if the answer is a forensic investigation then answer this question: What predicated your belief that there was a data breach?

Sincerely,

Eric B.

@shaggyDBA wrote:
The database may be a sliver, but isn't the data held therein the theoretical prize?

So here's my concern (and I openly accept that this might be naive) - let's say a breach has occurred and an investigation is underway. How does one state with any level of confidence what data was compromised without investigating the database internals?

If I'm depending on file access or log analysis how can I be assured that I have an accurate picture of what was compromised? What if sensitive data is logically separated (via different schemas), but still exist in a datafile with non-sensitive data? How would we determine which schema had been compromised as part of our analysis? Or do we move under the assumption that if a datafile was accessed any data in said file could've been accessed?

I'm not trying to stir a pot or make databases the end-all-be-all, but I do have some concerns/questions about the how for narrowing the scope of a data breach.

Thanks to all for the feedback on this!

JoePete · ‎03-01-2018

@shaggyDBA an interesting wrinkle on your scenario is rather than thinking of a database sitting on some physical volume. Think of it as a database on a virtual machine, that itself is a database record, in some larger virtualization application, that sits, dispersed, on some cloud-based object storage. Moreover, the always connected, always-on world of the cloud diminishes the requisite of permanent storage - for example a temporary database or even complete virtual environment held nowhere else than in the RAM of thousands of interconnected devices. I am not sure "database forensics" is a full or accurate topic, but what's a database other than breaking complex data into discreet chunks and then relying on a schema to keep track of and assemble that data on demand? That model is repeating itself as we now use new data types and technologies to increase our computing capacity.

yevgeng · ‎03-03-2018

You need to look at infrastructure and organization as a whole and see how databases fit into organization-wide security effort. Securing your databases is essentially applying certain techniques at the expense of some other aspect. Let's consider an account to access database over non-encrypted internet connection. If we revoke this kind of access we reduce possibility of all kinds of man-in-the middle attacks as well as data leak to third party. By doing this we give up convenience because now you need to get to db server somehow, execute commands locally and then get the output into a suitable place for further processing. If we encrypt client to server connection then we reduce the risk that someone might snoop at our session traffic. What do we lose--most likely bandwidth and some endpoint resources that will be spent on encryption\decryption. The perceived benefits in turn might be negated if connection is established from a non-patched application server which could be easily exploited. Or you might be on a dedicated vlan that doesn't take outside public connections directly (the traffic goes through firewalls, specialized IDS,IPS, packet analyzing appliances and is subject to heavy white/black-listing).

That's why enterprise-wide security effort and posture of entire organization needs to be considered against potential threats.

In regards to breach response, most likely you will be involved as subject matter expert during breach investigation or be a member special task force team that will be formed by security leadership specifically for breach investigation (3rd party resources might also be included).

Baechle · ‎03-05-2018

As far as a DBA is concerned, I 100% agree with @yevgeng. Conducting a reactive investigation is about identifying, generating, and following specific leads. How you answer, "What predicated your belief that your system was compromised?" often changes what you do next as an investigator - as opposed to trying to diagnose the database system itself.

@yevgeng wrote:

In regards to breach response, most likely you will be involved as subject matter expert during breach investigation or be a member special task force team that will be formed by security leadership specifically for breach investigation (3rd party resources might also be included).