Slashdot Mirror
Security Responsibility Without the Authority?
Slashdot reader jamie submits this story about security administration. If you have the responsibility for security without the authority to make changes, your only role is to be the fall guy when something goes wrong.
I work at a Large Bank, and more often than not, we'll implement an expensive, suboptimal product because a) Someone Else Did It or b) Gartner Said It Was Good. It's all about preconfiguring the blame, it is always someone else's fault - this way, if there's ever a problem and the Gubmint comes looking for tail, we can always point the finger. On a small scale, this reduces to individual admins being force to do stupid things, because Thats What The Project Requires.
I want to delete my account but Slashdot doesn't allow it.
Doesn't matter that Redhat and everyone else offer support.
But what happens when one can set rules and enforce them at the same time? That'll be too much power.
Usually in a company, IT department takes care of the adminstration of IT-related stuff, and HR takes care of the rules/policies.
If these two departments don't compliment each other, that's the problem to be fixed, instead of mixing two different roles together.
That's my personal experience anyway, I find it easier to tell the users to take to HR (or vice versa) than having to deal with (punish) or explain certain policies to users.
Rock that crushes, Paper & Scissors that don't matter.
as with any job where you might be in a delicate .. do your due
position or 'the target' should things go wrong
that are beyond your control ( whether due to
lack of authority or lack of omniscience ),
Document, Document, Document
diligence, report any possible vulnerabilities,
suspicions of attack and recommended changes to
your immediate boss, your IT/CIS team and their
managers. Be public, but don't be patronizing.
This 'paper trail' will help you immensely should
you be terminated over some security breach should
you be able to prove that, were your suggestions
implemented, the breach could have been prevented.
Security work is ridden with chance : if there is
a flaw in the hardware or software that had not
been documented at the root of a breach, report
that this is a new issue with that particular
system and that a patch is available and has ( or
should, if you lack even the authority to patch )
be applied immediately, or that a patch is not
yet available. I'm not a litigious person by
nature but I wouldn't hesitate to sue on the
grounds of wrongful termination if i could present
evidence that i had made those in power aware of
the problem and had not received authorization
to make the changes that would have prevented the
breach.
If you're the security guy, you Are the fall guy
by default, but if you don't leave a document
trail behind to show due diligence you will have
no cushion for your fall.
Follow the same basic guidelines that the medical
profession uses - document anomalies, perform
frequent monitoring, document changes. All of
this will help greatly should you be in the
unfortunately position of having to take legal
action against a former employer.
That this is necessary is sad, but it Is
necessary.
Relate this back to the industry. You're either at the top-level or you're in the trenches. A good security admin will bridge the two as best he/she can. Security fundamentally affects (and is affected by) almost every facet of an organization. I've seen through personal experience a "silo-like" mentality to security policy execution. The secadmins were in their own private bubble that attempted to be dictatory and impervious to external influence. This is wrong, wrong, wrong!
Unfortunately, the needs of the job amount to being a little political. The decisions must be participatory, or at least giving the appearance of being participatory. That is what gives you buy-in from your users. You might say, "Why should I?" Well, if you're saying that, then you might want to find another job. Its a necessary evil if you care about keeping your org secure. If not, you might be the one complaining after the fact, "They never listened to me". Even if you're merely sitting there explaining why you are doing what you're doing - at least people are involved. You might even be giving them bad news, but at least you're telling them that you're giving them bad news before you change their lives. The real challenge here is finding the right people to involve. :-)
Good security as much depends on the "how" of security versus the "what" of security. If your methodology is technically correct, cheap, and does the job, but you've dumped it on the organization, then guess what. It ain't gonna fly!
The article, in its efforts to be concise, has not really justified its claims. Trying to sway the course of one of the largest governments in the world indeed sounds like a recipe for frustration, but does not necessarily map back to the industry in general. Those seem like radically different things. I remember Richard Clarke seeming positively perky during the days of his assumption of cyber-security czar role. Look at him now.
Sadly I am the blame guy at my job, AKA, the bitch.
It goes like this at my job. I am "in charge" of network security and maintaining our Microsoft and Linux servers. You would think that my office would be located at the central office where all the servers are. This is not the case. Instead my boss, the IT manager, is located at the central office. Whenever he thinks something is not working right he makes changes to our production servers during business hours. My boss has no training in IT security. He's an MBA that has limited knowlege in security but thinks he knows more than he does.
Here's how most situations go. One person calls and complains that the finance database is slow or our inventory database is not working correctly. My boss then logs into the server and makes changes without documenting anything or telling me. You can image what happens next. Yeah, I get blamed for problems that occured after he changed something. I then have to go back and try to trace what he did. I know I can't ask what changes he made since that might seem like I am blaming him for the problem he created.
After going through this senario four times I decided to remove his login to our production servers. Big mistake.
I got a call from my boss two days later asking why he couldn't login to our production servers. I had prepared ahead of time and had a story made. I told him that I had noticed someone was logging in to our production servers and making changes during business hours which is against our IT policy. I went on saying that the changes made during these logins were responisble for the problems. I then told him for better security I should keep his account off the production servers so that the person who was making changes could no longer do so. He then said, "In the future could you please let me know when you make changes so we can be on the same page." I told him that I always documented the changes I made in the server logbook. I told him that I would reactivate his account with a different password. Since then he has not made any changes to the system.