June 3, 2015 at 8:19 pm
Comments posted to this topic are about the item Architecture for Auditing
June 4, 2015 at 1:51 am
+1 for this. On 2 separate occasions in my relatively short career (<10 years) I've seen system access and audit logs that appeared to have been tampered with after a system outage. And those were the times I actually saw the logs before and after said tampering - no telling how often it has actually happened. Never had any proof beyond a syslog I'd copied to my pc before the 'tampering' took place which could just as easily have been a file that I'd mocked up to get someone in trouble so I never had hard evidence to prove it happened nor could I prove who did it.
In my current company we have a syslog server, all machines capable of it have redirected their syslog output to that machine so as soon as something happens, it gets logged. This means that anyone who might want to cover up a mistake or accident would not be able, but it's not perfect if someone has premeditated some action - if you have the time and the physical access you can still pull the nics, do your thing, delete the pending syslogs and then reconnect the nics. We have CCTV in our machine room too though so we're pretty much covered!
Ben
^ Thats me!
----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
June 4, 2015 at 5:21 am
I agree with Steve wholeheartedly. Having spent over 15 years doing a variety of operational auditing professionally for the Air Force and then Martin Marietta, I recognize the need for an audit structure outside the control of DBAs. One way of accomplishing this is to create a role between the system administrator role and the general user that allows DBAs to do all their work but limits them from full admin rights on audit triggers and the tables used to store audit data.
In a position I had several years ago, we discovered through the audit process, an account manager who was downloading all the contact information for the small not-for-profit we worked for. His intent was to set up a company to compete with the NFP. He did not know about the audit process. Had he known about it, he would have tried to manipulate the data.
Companies are at risk by not having a secure audit process as there are now legal requirements to store data about company finances, emails and the like. Not having a secure audit process in place can lead to accusations of Obstruction of Justice and conspiracy to tamper with evidence in the case of civil or criminal investigations.
June 4, 2015 at 5:48 am
Hi Steve
I think you're definitely right. Like many forms of security, it's not a "concern" even for the business side of the organisation. It's boring, and they just want legal compliance as soon as possible so that they can get on with their main job.
At the very least they do have legal compliance somewhere in their minds, so if the responsible business person could specify the level of audit and put it into effect, the risk of administrators trying to second-guess how much is retained, and for how long, would be avoided.
Regards
June 4, 2015 at 7:47 am
All I can say is $$$$$$$. With over 200 RDBMs installs we were quoted for over $300,000 for auditing software (Oracle). Of course the 2 DBAs would be responsible for all this. We couldn't afford it. I think we're almost to the point to start going back to paper for lots of stuff.
June 4, 2015 at 8:18 am
If you work in an industry that handles PCI/DSS data, you'd better have an audit system that provides hard separation of audit functions from those who administer the data systems. The systems that do so are very, very expensive. But so is compromise of sensitive data. Pick your poison.
June 5, 2015 at 12:50 am
I used to work for a company, which implemented audit via an appliance which sniffed network traffic connecting to the databases. The initial implementation reported on any connecting ID with admin rights which performed any type of update, and for each such update, the owner of the ID was asked to supply the incident number which led to the update.
The people who managed the solution were on a different continent from most of the DBAs and were not DBAs themselves. That neatly satisfied the requirement for database audit to be outside the control of the DBAs and not be managed by friends of the DBAs. There were a few drawbacks, mostly around the total lack of understanding of the audit managers of what they were dealing with.
For example, the appliance in question could only monitor by IP address, not by DNS name. This led to demands from the audit managers that we should start up our DR instances (while production was still running), so that the appliance could verify the DR IP addresses.......this was one time when the DBA response was less than positive (and we made it stick). Also, there was no evidence that they checked the incident reports to ensure that the number provided tallied with the update it was supposed to cover.
There was certainly the germ of a great audit solution there, limited only by the human factor.
June 8, 2015 at 7:22 am
Thanks for the tips on auditing. We're going through something called SSAE-16 (I think) and self-auditing of work is part of it.
June 8, 2015 at 9:26 pm
Three options:
1.) Give up. It's hard and you're not really protecting that much anyway. Just your company & its clients data. (Sounds like many of you already have.)
2.) Spend some money - $$$ Guardium or http://www.imperva.com/Products/DatabaseSecurity
3.) Invest time & effort in SQL Audit, SQL Policy, and automation. It's not an easy solution but the tools are there. You can use SQL Audit to monitor the key pieces of your business that you want to watch/protect the most & then leverage the EPM Framework (free on CodePlex) and policies to deliver key indicators letting you know if anything looks out of place.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply