The Unhappy Employee
-
This really is disturbing, a security officer planting pornography on a client computer specifically to get someone fired. As much as I dislike proxys and monitoring, that might be the only way you could prove this wasn't something you downloaded.
For a short summary, a security officer examined an executive's PC and "discovered" pornography on it. The executive denied it and after an investigation, it was discovered that the files were planted by the security officer. Not something that you'd expect to happen on a regular basis and in this case, the motive was revenge, not money.
As DBAs, we're entrusted with taking care of data for corporations. This means that we need to be sure we don't ever abuse that trust so that we can be counted on to maintain the integrity of data. And that means that we would not add or alter data without cause.
The problem with this case is that we have an auditing system (the security officer), who might not have had much oversight in terms of ensuring that auditor acted correctly. It was discovered in this case, but what about others?
I don't think we want to get into these endless cycles of person A checking Person B but being checked by Person C who is audited by Person D. However there definitely need to be methods of appeal and ways to independently backtrack investigations to be sure that the proper procedures were followed.
As DBAs this means that we should be careful to ensure that any auditing or tracking that we do of systems is done properly and that the data is secured. It would be easy to change or alter records ourselves, so I'm not sure of the best solution. Do we have our log records and audit trails written to files that we cannot change? Should the AD guys secure our records to prevent us from tampering with them?
It's a tough situation and one that works 99.9% of the time. But when it doesn't, it can be a mess to straighten out.
-
I believe that a system of checks and balances is a necessary evil to keep quality and integrity at high levels but because of ENRON and SOX compliance I also think there is such a thing as going too far.
We get audited constantly it seems. We have interal auditors and external auditors and none of them are able to tell us the right way to do something but they can easily point out what is wrong.
It has become an industry unto itself. Yes, we need to track what we are doing on a daily basis if not for any other reason than showing your value as an employee and a department with a quantifiable number, but when it comes to the point where work is not being done because you are too busy documenting what you have already done, it is time to rethink the process. In many cases, it takes longer to document what the problem is and what I did to solve it than it does to actually fix the problem.
-
In my case I actually really like the idea of having every action that is taken within a sql server instance written to some sort of audit log that is read only and can't be changed by anyone. Is this sort of thing even possible with sql server? I certainly don't see any thing wrong with doing this as it can be useful in many ways and I don't see any reason why not to do it.
-
I am a late IT bloomer. My degree is in accounting. Audits are necessary, auditing auditors is not. While I will never rise to the level of knowledge regarding IT that I would like, I have enough understanding to know that the security officer in the stated example should probably been given (at most) read permissions on the computer he was auditing. If he needs write permissions on any part of the machine, it MUST be separate from those parts the user naormally uses. To say it another way, the auditor (in finance as well as IT) cannot be allowed to change what is being audited. They must be limited to reviewing an reporting what they find. I think proper network policies and workstation permissions would have gone a long way to preventing the scenerio described.
It is impossible to completely prevent fraud or other unseemly behavior. But proper controls and procedures on the front end is ALWAYS the best place to start. I think those controls and procedures were missing in the scenario described and therefore, the security officer had write access to areas he should not have been able to alter.
Proper use of AD policies and security features may have prevented the false accusation of this executive.
-
When I worked at the bank, everyone could change the data had to take turn to take 2 weeks off at audit time. This way, they said if you had changed the procedures, the data, it would show up. That's what the auditors said.
Of course if you want to get someone fired, you can do anything. In my old company one auditor went around and told the managers he saw 79 people surfing the web instead of working, he even wrote down the name of the employees. For God sake, most of those people were web developers.
Or you said you had heard someone made racist remarks or sexist remarks. One of my friend had a very harsh manager, she did not know anything but pretended to know everything, she did not trust anyone. I helped my friend to write a procedure that worked. She refused to use it becuase she thought she could write a better one. Three weeks later, nothing showed up. She put the blame on my girl friend. My girl friend had enough an decide to retire. She was 55 years old. A week before she retired, she got a call from her manager one morning and told her she did not have to come to work, she was fired.
What's the point?
-
You could set up an audit log that was write only (insert only), but the problem is at some point the admin (sa) could change things, drop the trigger to do something and add it back, or delete rows from the table. The best way is to use profiler to write to a folder that only it has rights to write to, meaning the SQL Service account has write rights. And not read or change rights. And make sure the SAs can't get to that folder.
Doesnt' work great in small companies, because the sysadmin of the database might admin the AD. But in larger companies, you can do some sort of separation.
-
Looks to me like some basic premises are wrong here. The real job of a "security officer" in a company is to protect the company and it's employees, not to be a self-appointed agent of FBI/IRS/SEC/local-church etc. etc.
Therefore, one can easily stipulate that unless there's a capital crime or terrorism planning involved (as in someone's going to die if a thing is not reported early) any pretence of "whistle blowing" by employees with special access to computers and other facilities should be considered malicious an untrusted by default - to the point of being inadmissible to the court unless supported by additional, independent evidence or a witness. The equivalent of unwarranted search by a police officer, exactly because they are given powers that are easy to abuse.
Also, since government agencies investigating real crimes do have surveillance and forensic tools these days that allow access/reconstruction without any self-appointed "helpers", it's the time to question the practice of anyone but the actual user of a computer having the admin access (when not supervised by the user itself and for the purpose of repair). The questioning based on basic human rights starts with privacy and ends with freedom of expression. Again, this is not 10 or 20 yr old world and all historical rationalizations are void - on both legal and technical level.
From the business point of view, the culture of intrusive, big-brother, network admins and alikes (like "auditing" people instead of records and "auditing" things that are not financial) actually hampers productivity and morale and discourages employee learning. Say Microsoft or Honda and Toyota for that matter didn't make their fortunes by building layers of auditors and "security officer" - just a thing to think about ...
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply