Slashdot Mirror
When Sysadmins Go Bad
An anonymous reader writes "Here is a story about what can happen when you think you're being oh so clever. This sysadmin planted so-called logic bombs on the systems he was responsible for and then quit. He also tried to game the stock market, buying put options on his former company, hoping to cash in when the disaster he engineered struck. Who can companies trust if they're afraid that this kind of thing can happen? How can they prevent it?"
Obviously, in the sake of security, you should NEVER provide system administrators with dangerous tools such as root passwords!
Seriously though, security is a very delicate matter which is entirely built on trust.
Ways to improve security is to limit access to only what you actually need to use. In the case of system administrators and the like, it's not quite as easy as they obviously need a high level of access.
One solution would be to have third party audits of the systems, perhaps with read-only access in order to prevent tampering, but even then you need to trust the integrity and skill of the auditors.
Another thing to remember is to have a solid disaster recovery plan, but that's only good AFTER something happens and the person designing and implementing this plan will likely be the person that has the most access.
There's no universal answer to this problem. If I knew of one, I'd be rich as heck from selling it to companies.
Many years ago one of our staff left at the end of the summer. Our boss said "Thank you very much for working for us ... [pause as the door closed, then turned to a coworker] ... delete his account."
Slashdot monitor for your Mozilla sidebar or Active Desktop.
When you have reasonable salaries, reasonable work hours, and no one that runs everything.
First of all you'd have less disgruntled employees.
Second, you'd have less disgruntled employees.
Third, you wouldn't need to trust anyone 100%. Most egos of sysadmins wouldn't let them let someone else compromise their system. If you have 2 or more admins 100% responsible for the integrity of a system, and each performing checks on each other, you would reduce the occurences of these types of attacks.
I was disappointed to find that this was an article, and not a new show on Fox.
It's better to burn out than to fade away
> Who can companies trust if they're afraid that
> this kind of thing can happen?
Nobody.
> How can they prevent it?
They can't.
Employee misbehavior spans an entire spectrum of seriousness, from stealing paper clips to embezzling billions. You can't prevent a determined and dishonest sysadmin from sabotaging a system any more than you can prevent an accountant from diverting funds or an after-hours custodian from taking things off peoples' desks.
There is no panacea, technological or otherwise.
Preventing employee misbehavior has several parallels with Copy Protection. No affordable and practical scheme is bulletproof if the person is determined enough, so the best method is to remove the motivation. The same rules apply to all employees: treat and compensate people fairly and they will be less likely to want to hurt you.
But even that doesn't work in all cases. If your staff is large enough there will always be people who feel that you are mistreating them, or underpaying them, and who will feel compelled to get what is "rightfully theirs" in other ways, large and small. And many people steal/etc. without regard to the harm it causes the company or other employees; their motivation is purely selfish, so it doesn't matter how well they are treated and paid.
So even if you treat and compensate people fairly, and trust everybody you hire, you must monitor people's activity, investigate suspicious behavior, and, when necessary, prosecute wrongdoers to the fullest extent of the law.
I probably sound cynical, but I speak from experience.
Something similar happened to my Dad's business about 15 years ago. Back then, they just trusted the employees. For some reason I can't recall, they decided to fire the sysadmin that was running their billing systems and gave him a months notice. During that month, they let him take time off from work to interview at other places and were generally pretty nice about the whole thing.
A couple weeks after he left, the system started crashing and losing data. Apparently he used a rather well-known bomb because the company they used for support was able to dial in and found it rather quickly. He was charged, arrested, tried, and found guilty. It was a big deal because the state (South Carolina) had just passed some really though computer crime laws at the time, and the Attorney General wanted a "test case" for the law.
My Dad and his partner's requested that the guy not get any jail time since he had a wife and some kids, but he got major probation and a huge fine (something like $60,000, which was a lot back then). Plus he now has a felony charge on his record. Last I heard, he had gotten out of the computer biz and was working in a family business.
Anyway, the short lesson is: if you're a company firing someone with privileges, pay them the two weeks or whatever but don't let them back on site. And if you're the guy getting sacked, don't try to get revenge through sabotage; it's just not worth it.
As an aside: every place I've worked had a policy that whenever someone was fired they were led to their desk with a cardboard box, then escorted out of the building that very moment.
... pull a stupid crime and spend the rest of your life in a state-funded institution.
For critical systems, nothing gets changed without an approved change request. All changes must be examined, tested and approved by someone other than the programmer. You can also have a separate group to maintain the source libraries and to do builds.
Mea navis aericumbens anguillis abundat
SysAdmin, as the word says, it's the Administrator of the System.
there's no technical way to restrict their actions, or we should restrict the computer's capacity.
people do bad things for money, that's all, how could we prevent this happen? how could we prevent crime? how could we prevent people shoot each other? these are analog.
it's political or human issue. not technical.
Don't keep disgruntled employees or employees that you keep hidden away in a back room and ignore. Management that keeps good relationships with its employees don't have as many problems with this sort of thing.
This means:
1) Help work to keep employees happily employed (not with bribes - with real career paths, personal interest, etc.). If you keep wage-slaves, expect mutiny.
2) Actively replace employees who can't be kept happily employed. Get others who are competent and glad to have the spot (which shouldn't be too hard in this economy). Keeping people around who don't want the position isn't doing them any favors. If no one who would be qualified would also be glad to have the spot, rethink the position.
"Management" should be helping manage situations like this. If this guy had been disgruntled for a long time, it seems to be their fault for keeping him (and keeping him unhappy and ultimately vengeful). Sounds like someone did a bad job at people-management . . . sounds like the type of willfull neglect that is inexcusable but all too common. Many people think that "management" is watching the bottom line -- that is a lazy, oversimplified way of looking at an important job.
C'mon -- this is really small potatoes ...
Who can you trust?
Microsoft. Trustworthy computing.
At Microsoft, we make operating systems that administer themselves, so you don't have to hire those untrustworthy and expensive system administrators. Nearly any high-school graduate, or poo-flinging monkey, with the proper brainwa^H^H^H^H^H^H^H training can become a Microsoft-Only Operations Certified Omnipotent Worker. Get your own MOOCOW today, and let us handle your security problems. You shouldn't have to worry about these computer dealies - that's our job.
Microsoft. Trusted Computing since 2002.
My beliefs do not require that you agree with them.
Put option quick explaination:
Suppose that the stock of company FooBar is worth $80 today.
I buy the *option* of selling that stock at $80 in one weeks time (this of course cost me something since there is a risk involved for the entity that I buy this option from).
Let's say that priviledge costs me $1 (since everybody considers company FooBars stock prices to be quite stable).
Now, one week later the "bomb" has blown up their computer system and the stock has plunged to $40.
The option of selling one stock at $80 is now worth $40 since the stock is currently priced at 40$. I don't even have to own the stock since someone who does can buy the option from me instead.
In total I've made 39$ on an investment of 1$ in one weeks time.
All of this costs money, but think of it as cheap insurance, compared to the cost of rogue sysadmin. Is it worth penny-pinching on salaries and benefits, while maxing out the workload if that results in disgruntled employees who timebomb your systems as they head for a new job?
If you paid the sysadmins $1 million per year, there would be zero theft, zero funny business, and zero turnover. Of course, nobody can do that and stay in business. At some level less than $1 million and higher than fast-food wages, you can retain decent people and discourage malicious tactics. The key to avoiding a technological meltdown is to treat people well enough so that your recruiting process lets you avoid the marginal candidates. Once hired, a properly compensated person should feel as if the "have something to lose", and therefore you can expect such a person to act as a professional. Paying hamburger wages and putting a person in the sysadmin seat would be like staffing a nuclear power plant control room with random selections from the phone book.
This is a very interesting topic, especially right now. We are in a down market, and there is an irresistable temptation for some employers to make lowball offers to currently-unemployed candidates. This allows the employer to cheaply refill vacancies (or exert leverage against current employees). Those employers who are gung-ho about bottom-feeding are setting the stage for big trouble later. Employee turnover is just the tip of the iceberg.
Here in Venezuela, when the Oil strike begun some sysadmins blocked and placed logic bombs in the critical computers. It is costing the country an average of US$ 15 million a day. The computers that control the fuel-load process in the tankers where so sabotaged that any try to get the system up would end up spilling fuel on every "island" (the place where the fuel truck loads). The only way to stop the spill would be to activate the emergency system in the plant. Gladly (it's already very known worldwide) the goverment set up a "hackers team" to take over all the sabotaged industry computers. Most of them are running Solaris or Windows NT 4, so it wasn't too hard to break all the systems. If you calculate: US$ 15 Millions * 16 days = 240 Million US$ ... and most of it is because the admins who sabotaged the critical computers.
You must be inexperienced. I've set up systems where no one had root access. You set up sudo (or one of its commercial clones) to give specific people permission to do specific things, then you write a script to change the root password to a very random string and send it to a real printer. As soon as the printer delivers the goods (in the presence of one of more officers), it is folded and placed in an envelope (which everyone signs on the seal) and locked away. Any emergency big enough to require the password needs to be brought to the possessing officer's attention anyway, and anyone can look at the envelope to make sure that it hasn't been tampered with.
Nothing for 6-digit uids?
He can't. I've had this happen to me one or two times. I've been pushed in to sysadmining (dammit, Jim, I'm a programmer, not a sysadm!) in this small association (about 60 employees, about 60000 members), and initially just assumed the system I took over was OK. After a year or so I discover, quite by accident, the first horrible thing... Every user PC has a small script on it, that contains the root password to the main server in plaintext.
Apparently, no-one knew. I was responsible, even if it was my predecessor (or his) that had written that script. What to do? Go up to the boss and say "Hey Joe! Funny thing, any employee may have had root access to the DB in the last five years! Ain't that funny?". No. Fix it. Shut up.
There were a few almost as horrible things I fixed quietly over the next few months.
I also have to confess that I have did a horrible blunder myself, that has gone undetected. What do you do when you find that a bug in an old program you wrote has lead (over the last six months) to >4% of your members mailing addresses beeing slowly mangled? When membership dues are mostly collected by mail? Which has lead to large losses for the association, and great unhappiness among the members?
Fix the bug, correct the adresses as much as possible, delete the evidence, lie when confronted. That's what you do.