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?"

44 of 487 comments (clear)

  1. Sheesh! by tigress · · Score: 5, Insightful

    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.

    1. Re:Sheesh! by oliverthered · · Score: 4, Interesting

      Sheesh exactly, so, what happened here.
      1: The sys-admin had enough access to the systems that he could change the configuration and clean up and prevent the changes from being detected.
      2:
      The company didn't have proper procedures inplace to stop 1 happening.

      Examples of good procedures could be.
      *Systems provide automated roll back.

      *Changes can only be applied through a script that is run by xyz and required GOD access (say knowlage of a password that changes daily)

      *System should be configured to audit any changes that take place

      *A review process, where by any changes are reviewed by another member of staff

      etc.......

      the sysadmin was bad the company was useless, I'm not supprised he quit and tried to take the company down.

      --
      thank God the internet isn't a human right.
    2. Re:Sheesh! by arivanov · · Score: 5, Insightful

      No comments on the company as it happens to handle the stock options of one of my previous employers...

      One comment on the sysadmin - cretinous moron. If he wanted make money on the options he should have been much more subtle. A sudden surge of damage makes everyone go to the backup tape rack. Everything is restored to pristine state in a day or so and the perpetrator is easily caught.

      Compared to this slow corruption and small logical errors in the nth sign after the decimal are much harder to pinpoint and deal with. A similar case in germanyt a while ago operated for more then 5 years before negotiating a settlement. He did not even get caught.

      Overall - what a greedy cretinous idiot. They should have fired him earlier for stupidity.

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    3. Re:Sheesh! by void* · · Score: 5, Insightful

      Now wait a minute

      Examples of good procedures could be. *Systems provide automated roll back.

      This isn't a procedure. This is a potential feature of the system itself. When I was a unix admin, I versioned config files, because unix doesn't provide automatic versioning of files, allowing rollback of config changes. However, as the person who set up the versioning system, if I had gone bad I would have been able to sabotage the files under revision control as well. Unless the system itself enforces this (i.e, the system keeps all versions of all files and does not allow an admin to change, in any manner, old versions), this sort of precaution can be bypassed.

      *Changes can only be applied through a script that is run by xyz and required GOD access (say knowlage of a password that changes daily)

      This, also, sounds good. However, on some Unix systems, at least, there have been issues with setuid scripts related to how the system loads and executes them, allowing race conditions that can lead to root access. Note that the issue I'm talking about is -not- a bug in the script, but rather a side effect of how #! loading is handled by some systems. A large percentage of the Unix S.A.s I know rightly disallow the use of setuid scripts for this reason, and the fact that it's easy to write a script that allows things like /tmp races and other bugs that lead to root access and/or clobbering of files.

      *System should be configured to audit any changes that take place.

      Again, not a procedure, but a potential feature of the system. If the system doesn't allow this directly, how do you propose to implement it?

      *A review process, where by any changes are reviewed by another member of staff

      "Hey Dave, I'm sabotaging the system -- Can you review my change for me? Thanks!" - Do you really think someone's going to let a change like that get into the queue for a review process? Are you advocating a line-by-line code/config review of -everything- every single time a change is made, and do you realize how impractical that is, especially if the deployed system is complex or the number of deployed machines is large? Do you understand that it is possible to make a change that cannot be reviewed?

      You can do things to attempt to prevent this sort of thing, but you have to understand that there is no procedural solution for this problem -> the best you can do is reduce the odds that someone can do this and not get caught. This is a laudable goal, but, while in pursuit of this goal, the practical limitations need to be kept in sight.

      The moral of the story is, it's very easy to post on Slashdot saying 'x, y, and z would have prevented this', with x, y, and z being impractical/impossible to implement, and through some twist of logic, come to a conclusion such as:

      the sysadmin was bad the company was useless, I'm not supprised he quit and tried to take the company down.

      --


      Code or be coded.
    4. Re:Sheesh! by Arandir · · Score: 4, Insightful

      Are you advocating a line-by-line code/config review of -everything- every single time a change is made, and do you realize how impractical that is

      Departments do this all the time, with much more complex code. Those departments are collectively called "Software Engineering". It may be impossible to grasp by IT departments, but it is possible, and desired, to review every line of code making its way into the system.

      To be fair though, IT has different requirements. When the system is down, you don't have time for a review. But that's no reason not to do a post-fix review.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    5. Re:Sheesh! by SectoidRandom · · Score: 5, Insightful

      There is one option that far too many companies almost refuse to consider. That is; Treat employee's nice. Yes it's a hard one, and for most companies (and many people) it's easier to rebuild the entire network after every sysadmin change!

      Sad but true all too often.

      I had a friend who after being with a company for three years was the victim of a whole lot of drummed up charges, it was clear that the real motive was cut backs, I guess HR and many others didnt like the fact that he earned more than all of the rest of the administrators combined. So one day he was escorted out of the building, after which they literally unplugged the network, the whole Australian network (3000+ users) was offline for three days while the rest of the admins rebuilt every server!

      Did it do any good? No, of course not. A typical simple minded HR view, after spending probably many thousands of dollars in time (and consultants) rebuilding the network not only was he still able to gain access, but he won a big unfair dismissal payout!

  2. Sounded cruel at the time. by FTL · · Score: 5, Insightful

    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.
    1. Re:Sounded cruel at the time. by Anonymous Coward · · Score: 5, Insightful

      Never ever delete an account before you're damn sure you won't need it (say one to five years after last use, no kidding). Just disable it, backup the home directory and log any access attempts.

    2. Re:Sounded cruel at the time. by ergo98 · · Score: 5, Informative

      How is that cruel? That is absolutely, completely normal administration, and anything less is gross negligence. Indeed, it should be common practice to reset any administrative password that a former employee might have had, and any coworkers password that they may have known: It has nothing to do with trust of mistrust, and even if it was the Pope who just left your employ that is standard protocol.

    3. Re:Sounded cruel at the time. by $rtbl_this · · Score: 5, Interesting

      Gets my vote. I saw this blow up at my current workplace when a former IT drone's account was deleted (not suspended) as soon as she left the building, without anyone realising it was used as the service account for many things, including the backup server. It took many hours to track down all the things it was used for and to furnish them with saner accounts. I think this probably counts as an accidental logic bomb.

      The really sad part of this is tale that it took over a fortnight for anyone to notice in the first place. Weep.

      (I'm not part of the local IT department, so I'm blameless with respect to this particular fuck-up. I commit enough fuck-ups of my own without claiming responsibility for anyone else's!)

      --
      "Are you being weird, or sarcastic?" said Emma. I said I didn't know because I get the two feelings mixed up.
    4. Re:Sounded cruel at the time. by Tet · · Score: 4, Informative
      I've been asked to lock out employees (including my boss at the time) as they were being told they were being made redundant.

      Yep. Standard practice at several places I've worked is for me to be asked to watch for a certain person to walk into the HR department. As soon as they're through the door, disable the account. That way, by the time they know they're being made redundant, they've already lost their access to the system. At a bank I worked at, that was followed by the unlucky victim being frogmarched to their desk by security, allowed to collect their personal artifacts, and then being escorted from the building...

      --
      "The invisible and the non-existent look very much alike." -- Delos B. McKown
    5. Re:Sounded cruel at the time. by scoove · · Score: 4, Interesting

      without anyone realising it was used as the service account for many things, including the backup server

      This absolutely screams of bad process design and the blame must go to inept management.

      Some suggestions I'd pass along (having learned the hard way the first time, as well have having played on both tech and manager side of the fence):

      - use role accounts/contacts, not personal ones: Domain registration, administrative accounts on servers, contact email addresses for company stuff, etc. should all point to a generic role contact or account. It's easy to map these to the appropriate individual accounts, but avoids the hell of deleting accounts when someone leaves. I've had to personally intervene with countless companies that have had their Internet domains registered in an employee's name (individual, not role) and experienced all sorts of nonsense when the employee left.

      - require documentation (and if you're a tech, provide it and maintain even if you're not asked): Too many tech folks act as if knowing and not sharing process information, passwords, etc. is job security. It's not - it only ensures that when you go, they'll get rid of you like ripping off a bandaid, rather than offer obligatory goodies (severance, consulting contracts, etc.). I've been an advisor to many of these episodes where some tech had attained too much system control and refused to share it. The slightest demand for special treatment from these techs usually creates a knee-jerk reaction, but in the end, the tech always loses (so what if he downs the company's server for a few days - he just ensures bad references will spread and he'll be unemployable at any real job). Share your information! Document your password. Give copies to your boss. Being open like this creates trust and you'll be rewarded by knowing more things not usually shared, or in the even of a downturn, you'll probably get favorable treatment or even be retained (because they can trust you).

      *scoove*

    6. Re:Sounded cruel at the time. by Anonymous Coward · · Score: 5, Funny
      Never ever delete an account before you're damn sure you won't need it (say one to five years after last use, no kidding). Just disable it, backup the home directory and log any access attempts.

      Please, please, please take his advice!
      I would be extremely disappointed if my cron jobs that sabotage the company did not run after I left!

    7. Re:Sounded cruel at the time. by Courageous · · Score: 5, Informative

      At my place of work, if you are given a termination notice, you continue to be paid for a month, and have access to your office and electronic accounts the entire time. You aren't expected to conduct company work during this time. Instead, you have free use of your office to hunt for another job.

      C//

  3. You *could*... by veddermatic · · Score: 4, Insightful

    Have two sysadmins, who work in different areas, and who a la "missle key firing system" both have to approve additions to important code bases.

    Obviously, you could get two bad apples and have the same thing happen, but odds are slim.

    Problem is, it tough to find ONE good admin, much less two, esp. with tough times for business... having to dole out twice the budget to protect yourself "just in case". Then again, it would double the job market =)

    OR mabye CVS everything, and look through all changes an employee made after they quit... then again, the clever get around this, etc.....

    *sigh* People just suck sometimes.

    --
    Department of Homeland Security: Removing the rights real patriots fought and died for since 2001
    1. Re:You *could*... by afidel · · Score: 4, Insightful

      You must be a student.
      No one who has ever worked in the real world would come up with such a thing! I'm just a lowly tech and I need root on the workstations I work on on a several time per day basis. If every time I wanted to do something I had to track down another person and have them be in the same physical place as me it would be insane. Now think of the sysadmins out there who get paged at 3am when something blows up. Now not only do they have to get up but so does someone else and they both have to believe that the other person will show up. The reality is you screen applicants, make sure you have some kind of regular contact with your employees, and finally have some system for angry people to vent without fear of reprisal. On my team I established an email list for bitching and complaining and made sure that no managers were on the list but also made sure management was aware of the lists existance.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    2. Re:You *could*... by vrmlguy · · Score: 5, Interesting

      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?
  4. Staff your IT department by Anonymous Coward · · Score: 5, Insightful

    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.

  5. Damn by Sandman1971 · · Score: 5, Funny

    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
  6. What can be done? by perfects · · Score: 5, Insightful

    > 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.

    1. Re:What can be done? by Twylite · · Score: 4, Insightful

      For some reason technical people tend to ignore many years of experience of similar problems in other domains. Quite simply, there are several effective mechanisms for preventing this type of abuse, but very few people which sufficient know-how to implement them.

      The business rules for prevention of white collar crime are division of responsibilities, and cross checking (or auditing). The rules do not change just because you are working with computers.

      The first thing to realise is that on most "enterprise" operating systems other than standard unix, the system administrator is NOT god. On NT, 2000, Novell and Trusted Solaris (amongst others) there is provision for delegating administrative privlidges and locking out the original administrator in an irrevocable manner. On most other Unix systems you can use "sudo" (or an equivalent) to selectively grant privlidges, and lock down root logon or "su" to the console only. Coupled with dual-key physical access control, this prevents any single person from becoming god ((s)he can't even modify hardware or reinstall because of physical controls). This scenario presumes procedures/rules (never leave just one admin in the room, watch and verify all operations, etc).

      Many admins baulk at this idea, but if you're serious about security, there has to be a physical barrier preventing complete power over the system. In the absence of computer systems designed for dual authentication for privledged operations, physical controls (and associated procedures) must be used.

      When responsibilities are divided, there needs to be an analysis of which privledges can interoperate, and which should not (because they could cause a security risk). The privledge of clearing log files should be limited to "god" - i.e. physical access to the console, which requires two people. Backups should be encrypted, if possible in such a manner that the key for recovery is split between two people (there is software to handle this sort of thing).

      Auditing is also essential. Every so often, external experts should be brought in and allowed to inspect the system, under the supervision of one or more of the administrators. It is likewise important that administrators be forced to take time off (instead of infinitely accuring annual leave) -- this is when fraudulent activity is usually stumbled upon.

      Does this offer complete protection? No. It won't work in organisations where there is only one admin (unless another technically savvy person can hold the second key for physical access), and it breaks down when two admins cooperate in the fraud. But it provides a whole lot more protection than the current practices, and in time can be improved (by drawing on other business and accounting practices).

      --
      i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
    2. Re:What can be done? by Lumpy · · Score: 4, Insightful

      BINGO!

      you hit it on the head.... A "bad" sysadmin is far less dangerous than your "bad" accountant..

      many MANY companies were robbed blind by a bad accountant embezzling money yes you dont hear this sensationalized like this article. it doesnt matter, from the janitor to the CEO EVERY EMPLOYEE has the ability to completely ruin your company.. anyone that is paranoid about it means they know they are screwing their employees and are sure they are disgruntled and TRYING to get back at them.

      if you want to reduce the risk of having disgruntled employees screwing your company there are 2 things you need...

      1 - Pay them fairly and treat them well. this is the MOST important thing. they will NOT respect you or your company if you don't respect them.

      2 - critical parts of your company need redundancy.. if you have 15 computers and 1 sysadmin... HIRE AN ASSISTANT FOR THE SYSADMIN. less sneaky stuff happens when someone has a shadow. same as Accounting... have your books audited by someone else on a regular basis.. wow now is a good time to actually LEARN how to run your business instead of playing golf or having your Mercedes detailed.

      99% of all bad things that happen in a business is the managemet's fault. their inattentiveness or apathy coupled with ignorance and sometimes just being a plain old asshole to their employees.

      --
      Do not look at laser with remaining good eye.
  7. similar story by KirkH · · Score: 5, Interesting

    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.

  8. A novel way to pay for retirement... by constantnormal · · Score: 5, Interesting

    ... pull a stupid crime and spend the rest of your life in a state-funded institution.

  9. Configuration Control by Detritus · · Score: 5, Informative

    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
  10. Tech plan = Good; Financial plan = Bad by ohboy-sleep · · Score: 4, Funny

    With the Paine Webber guy, I was amazed this guy didn't think the SEC could put 2 and 2 together.

    "Hmmm, there's the guy who had access to the company's computers and made all those put options, but I don't know if there's any way we can prove motive or opportunity."

  11. Who can you trust? by Anonymous Coward · · Score: 4, Interesting

    Trust in God; Everybody else pays cash

    Who can you trust? -- Nobody. As our master said:

    For of men it may generally be affirmed, that they are thankless, fickle, false, studious to avoid danger, greedy of gain, devoted to you while you are able to confer benefits upon them, and ready, as I said before, while danger is distant, to shed their blood, and sacrifice their property, their lives, and their children for you; but in the hour of need they turn against you. The Prince, therefore, who without otherwise securing himself builds wholly on their professions is undone.
    Machievelli, The Prince Ch 17.
    The answer to the question is no one, not even your mother. If you are not secure against being hacked by an insider, you are not secure. And that means everybody, Newspapers are full of headlines about CEO's ripping off their companies. Stories about long-time trusted employees who embezzle a few hundred thousand dollars are so common that they usually wind up on page 7 of the Metro section.
  12. they can never prevent this happen by z01d · · Score: 5, Insightful


    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.

  13. How to avoid this problem by puppetluva · · Score: 5, Insightful

    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.

  14. Sysadmins? by Titusdot+Groan · · Score: 5, Funny
    Luckily it's only sysadmins that do stuff like this and not traders, accountants or the CEO!

    C'mon -- this is really small potatoes ...

    1. Re:Sysadmins? by Iamthefallen · · Score: 5, Insightful

      yeah, but the difference is, the sysadmin is a criminal, a CEO that's stealing is just unethical...

      --
      Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
  15. Easy answer... by gosand · · Score: 5, Funny
    Who can companies trust if they're afraid that this kind of thing can happen?

    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.

  16. Re:This article isn't very good. Neat story though by Alphix · · Score: 5, Informative

    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.

  17. Sysadmins hell, I want to kill the execs; story by SeattleSluggo · · Score: 4, Interesting

    Forget the sysadmins hosing the company, how many friggin execs run the thing into the ground looking to pad their stock options, then leave?

    At a big EDA firm I worked at the sysadmin got into big trouble (I think he was fooling around on his old lady and was trying to run away with some other chick). He decided to hose the backups by placing a small magnet on the read/write head (IIRC). Then he did real backups, which he hid in the drop-down ceiling. His stupidity led him to try to blackmail the company (gold coins). The episode ended badly--high speed chase, crash, prison. Now that I think about it, yeah, a Fox mini-series!

    doug

  18. What can be done? by Confused · · Score: 4, Insightful

    >> How can they prevent it?

    > They can't.

    They can at least reduce the chance a lot with redundency.

    If you have a team of sys-admins, you have a good chance that the other might catch the bad one before it's too late. And if they feel treated well by the company and don't share the sentiment of the saboteur, the damage is usually contained.

    Another policy I've seen in some banks is that all employees have to take 2 continuous weeks paid vacation each year (the rest of the paid vacation time can be distributed at will). This promotes cross-training and redundancy.

  19. Prevention is not all that hard by Anonymous Coward · · Score: 5, Insightful
    • Reasonable salaries, benefits, and work hours
    • If someone is to be canned, you provide reasonable severance pay, and immediately lock them out of everything (including the physical building itself). Give them a month's pay, one week at a time, with the understanding that professional behavior is expected and they are to answer whatever questions might arise during this one month period.
    • Maintain some level of operational redundancy. Relying 100% on a single sysadmin is asking for trouble. They might be dishonest, or they might die in a car crash.

    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.
  20. On a related thought... by Chagatai · · Score: 4, Interesting
    Here's a question that is related in part to what this numbskull did: suppose you are a sysadmin responsible for some set of vital systems like this guy was. You are fired/terminated/leave the company. However, during the course of your stay, you never documented anything (and I'm not talking about deleting documentation because you were pissed off and left). Consequently, your employer is definitely set back trying to figure out what you had in place. What are the legal ramifications from this?

    My take on it would simply be that your employer did not pay enough attention to your activities abd subsequently due to their mismanagement you would not be at fault. Comments?

    --
    --Chag
  21. Oil Strike in Venezuela by Anonymous Coward · · Score: 5, Interesting

    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.

  22. Time bombs by Anonymous Coward · · Score: 4, Interesting
    There are a few examples of this in my past:

    1985: A travel company with several offices (local big group) had only one sysadmin for their computerized booking system. He was this nasty guy who was related to one of the founders, and no one wanted to fire the guy because only he knew how to run the damn things. Not that he did a good job. He was lazy, rude, and demanding. Well, one day, new management got sick of him, and tried to get an "assistant" for him (read "learn his job so we can fire him"). Sysadmin was wise to that, and basically they went through several employees in as few months. Finally, they decided to fire the guy, and hire a contractor to replace the systems. The firing was ugly, they ex-admin had to get dragged out by the police in the end. Days later, the whole system went down. Guess what? No backups. No one knew how it ran, and years of data was lost, chaos among their customers ensued, and six months later the company went out of business.

    1996: Our company bought out a competetor. They guy in charge of the call center was the only one we didn't lay off right after the merger because he was the only one who knew what went where, and he used this knowledge to leverage his job security. He was impossible to work with, never did anything on time, never answered his pages, and did just enough work not get fired, but it was really, really hard to get him to do anything else. Finally, we gathered a team of experts (our staff plus vendors) to go as a group, figure out what he was doing, then fire him. His response? He deleted all the call center tables, databases, and destroyed all paperwork... then quit. We had him arrested, but he posted bail, and we never found him again. It took half a month to get everything working right, which meant we had to tell 300 call center employees they couldn't come to work or get paid until we called them back. Boy, was that a clusterfuck.

    I saw this button once, "Now that I have changed the master password for the database, it is time to discuss my salary." Heh.

    1997: The head of our HR department was fired due to some political bullshit. Standard procedure was to take an ex-employee's computer, wipe it, and give it back to the tech department. Guess what we lost because no one thought about it? All employee records for the department. Backup was on a single floppy that wouldn't load, and she hadn't done backup since the first of the year anyway. We had to have every employee resubmit 1099s and W4s, plus tell us honestly what vacation and sick they already took.

    1999: Same company, same situation, but this time it was the guy who kept the entire tech department hardware inventory records. It took a year to recount what we had, and re-enter serial numbers and license keys into a new database. The stupid thing was, this guy made regular backups on the network drive... which was on a server they wiped by accident. Doh!

    2001: After a round of layoffs, one of our more brilliant and inspired programmers had "expiration dates" on all his compiled software. He wrote most of the tools we still use today. Months after he was laid off, all of them stopped working on September 17th, 2001 at 12:00 midnight. The only way we got saved was that no one wiped his original desktop box (which had the source code on it, which is how we found out about the "expiration date"). So we recompiled without the date, and everything worked again. Due to WHEN it happened, our whole company thought we'd been attacked by terrorists (the clever generic error only said there was a "network failure") until the truth was revealed. Later we found 9/17 was his birthday, and it was just coincidence it happened so close to 9/11; the layoffs were in March, and they were unexpected and sudden. I doubt this guy had Al-Queda (sp?) connections, so he must have been planning this "job security" (as the comment in the code labeled it) way in advance.

  23. Re:How does this profit? by The+Wing+Lover · · Score: 4, Informative

    Not quite. You've described a short sale.

    With a "short sale" you can borrow stock that you don't own, sell it, then later on, after the value has fallen, buy it, and give it back to its owner. Think of borrowing your neighbour's lawnmower in April when lawnmowers are expensive. Sell it for $200. Then in November when lawnmowers are cheap, buy a lawnmower on clearance for $100 and give it back to your neighbour.

    Options (a put option is one of two kinds of option) are a bit different in that you don't actually buy any stock. You only buy *the right* to buy (call options) or sell (put options) the stock at a given price.

    What's the difference?

    Well, for options, you have a limited risk (it's impossible to lose more money than you put in -- the worst that can happen is that your options become worthless and you throw them away). But with a short sale, the risk is potentially limitless, since it's possible for the stock price to be infinitely high when you have to buy them back and repay the lender.

    --

    - In Capitalist America, law violates YOU!

  24. Jurassic Park Lesson by billtom · · Score: 4, Funny


    Remember the lesson of "Jurassic Park":

    If you don't pay your programmers enough money, a tyrannosaurus rex will eat your lawyer.

  25. Re:On a somewhat related note... by Anonymous Coward · · Score: 5, Interesting
    What if the employee is a good guy? What if they have discovered one or more security flaws in the company's systems(s)? [...] How does the employee tell the company without getting in trouble?

    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.

  26. Re:On a somewhat related note... by proberts · · Score: 4, Informative

    If you discover them in the normal course of business, you explain what you were doing and how you discovered them. Do it on paper, sign and date the paper, keep a copy on your person, send a copy to your boss and whoever else it makes sense to send it to.

    If you took it upon yourself to "audit" the system without specificly getting permission, then you probably violated a policy and potentially broken the law. The real answer is "don't do that."

    Obviously "good" is tied to "doing what you're authorized to do," NOT "finding things that could potentially be held over someone's head but not yet taking advantage of them.

    The company is repsonsible for ensuring its shareholder value is protected from people who violate policies and laws.

    Randall Schwartz got a felony conviction- I don't believe anyone argued that he was going to maliciously use the information he gathered, but he violated policy and the current law in that jurisdiction. Exceeding your authority accessing computer systems is wrong. If you want to look around *get written permission* from someone who's authorized to grant it.

    I do computer forensics relatively often on behalf of corporate clients. If something ominous happened to a machine you'd just probed that evidence wouldn't do you any good- even if you weren't linked to the orginal problem.

    If the work environment is right, go in and admit improper access, explain why it won't happen again without permisson and explain the findings. Otherwise, an unrelated event could put a bad spin on it that could do you real damage.

    Paul

    --
    http://www.pauldrobertson.com
  27. Re:Logic Bomb? by Ymerej · · Score: 4, Informative
    In this case, although it may have seemed like the writer of the article was sensationalizing it, they were actually using the term correctly. We have no idea whether or not it was a Trojan horse, and it may or may not have been a time bomb, but it was definitely a logic bomb. From Charles P. Pfleeger's "Security in Computing" 2ed. p 197:
    A Trojan horse is a piece of malicious code that, in addition to its primary effect, has a second, nonobvious malicious effect. An example of a computer Trojan horse is a login script that solicits a user's identification and password, passes the identification information on to the rest of the system for login processing, but also retains a copy of the information for later, malicious use. In this example, the user sees only the login occurring as expected, so he or she has no evident reason to suspect anything else.

    A logic bomb is a class of malicious code that "detonates" or goes off when a specified condition occurs. A time bomb is a logic bomb whose trigger is a time or date.