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

40 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 stinky+wizzleteats · · Score: 2, Insightful

      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.

      Right on the money. This situation is yet another good reason why you should have a large enough IT staff.

      I also couldn't help noticing that only *nix is capable of meeting your system change policy with any degree of reliability. Fancy that.

    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 wobblie · · Score: 3, Insightful

      wait .. you forgot

      * treat employees with respect and dignity and they won't want to fuck you over

      Oh no - that'll never happen.

    4. 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.
    5. 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
    6. 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 Phil+Gregory · · Score: 3, Insightful

      As others have mentioned, disabling accounts is significantly better than deleting them. A very good paper on the process of dealing with the termination of a system administrator is Matthew Ringel and Tom Limoncelli's Adverse Termination Procedures.



      --Phil (I highly recommend Limoncelli's other papers, too, especially "Deconstructing User Requests".)
      --
      355/113 -- Not the famous irrational number PI, but an incredible simulation!
  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 Hanashi · · Score: 3, Insightful
      Actually, I don't think it's nearly as easy as you make it sound. Ok, assume we have set up such a dual-approver system. It has to run on some computer, right? There has to be someone somewhere who can administer that computer. The super user can always tamper with the software in ways you won't be able to detect.

      Even assuming the absence of an all-powerful superuser, there are problems. Someone has to be responsible for installing, maintaining and perhaps upgrading the application that manages the dual-approver system, so there's at least one person who doesn't need any confirmation before setting you up the bomb.

      And even if you solve that problem, there's the problem with untrustworthy hardware. Someone somewhere has physical access to the box, which would provide them with the ability to, say, take the disk drive "for maintenance", mount it in their own box, diddle whatever code they want, and return the "fixed" drive to service.

      And that brings up the problem of... and then the problem of... not to mention the problem of... it just keeps going. With our current technology, it's literally impossible to eliminate the issue of trust in our computing environments. They say everyone has their price. Scary thought, isn't it?

      --
      Check out my eclectic infosec blog at InfoSecPotpou
    2. 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.
    3. Re:You *could*... by vrmlguy · · Score: 3, Insightful
      And how do you defend against opportunity situations like reboot? One could take over the shell (linux) or insert an install CD.
      If any of my servers go down, a trouble ticket is opened, the on-call sysadmin gets a page, and email is sent to several PHBs, all in less time than it takes the BIOS to finish its POST.
      Its also vulnerable by any available service vulnerable to a root priv escalation attack.
      True, but that's a vulnerability to more people than just rogue sysadmins. Hopefully there's only a small window of opportunity between finding out about an attack and getting it patched. And heaven help anyone internal caught exploiting such an attack.
      I believe the only flaw with this system is to believe that it makes subverting the system impossible. Its not a bad psychological device to discourage "hacking".
      Kinda like putting locks on doors discourages breaking and entering?
      But this kind of procedure can only implementable with a disciplined production/engineering environment.
      I've implemented environments like this with only two Unix sysadmins. In that case, I was the junior guy. The senior guy had been with the outfit for seven years and was pretty disciplined, but I was replacing a guy who considered himself a "hax0r" and it wasn't too hard to get things locked down even tighter. It helped that the company was in a business that gave them access behind their customers' firewalls, so security was very important to the owners.
      Regular root access with auditing will accomplish almost as much as sudo.
      True, but sudo with regular auditing accomplishes even more.
      --
      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. 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.
  6. ...so? by TrumpetPower! · · Score: 3, Insightful

    How is this different from any other kind of sabotage by employees or ex-employees? As long as there have been accountants, there has been embezzlement. A short-order cook could forget to wash his hands. A construction contractor can use sub-standard building materials.

    You gotta trust somebody; just make sure it's somebody worthy of trust.

    As for preventing this particular kind of sabotage, use the same principles as everywhere else: supervision, audits, bonds, insurance, and the threat of jail time if the rest fails. Oh--a good disaster recovery plan sure doesn't hurt, either.

    Cheers,

    b&

    --
    All but God can prove this sentence true.
  7. 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.

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

  9. don't put all your security eggs in one basket by HealYourChurchWebSit · · Score: 3, Insightful

    If systems are so critical and secure, then you need to separate responsibilities, and dispense information to those holding the keys on a need to know basis.

    --
    --- have you healed your church website?
  10. Unfortunately by Anonymous Coward · · Score: 2, Insightful

    It is not equivalent to a real bomb. There was no destruction of property, no casualties. It's in a completely different league. The real solution here is to treat your employees with respect and not treat them as slaves.

  11. 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
  12. Re:similar story by eam · · Score: 2, Insightful

    > and a huge fine (something like $60,000, which
    > was a lot back then).

    Wow. I must not be making enough money, because I think that is still a lot.

  13. Insider Threat by herwin · · Score: 3, Insightful
    This general problem is quite common--80+% of the attacks on e-commerce systems involve insiders. You either have to trust your people or watch them. Unfortunately, watching them (using intrusion detection technology) is not very effective at present. You either have to program the IDS to detect the specific signatures of malicious acts (not well understood at present), or you have to train the system to detect anomalies. The training problem is very hard because:
    1. The training data may include an attack. Then hacking will be considered normal.
    2. New things happen on networks all the time.
    3. Successful retraining of an existing AI system to handle this is a hard problem, worth a PhD.
    4. Categorization of attacks requires expert input.
    5. False positives are common.
    6. Attack indicators are brittle, so that hackers can sneak past them.

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

  15. 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.
  16. Good story until... by Anonymous Coward · · Score: 0, Insightful

    You know, this story was fairly well reported as this type of technology story goes... until they got to this part:

    Duronio's logic bomb, the government charged, deleted files and led to $3 million in costs for PaineWebber to assess and repair the damage.

    To which I say Bullshit. If $3 million was done by this thing, it's their own damned fault for not having a backup system, and I'm sure they DO have a backup. There is no way that there was $3 million in damages done, because they should just have needed to load their backup. Sure, they would have needed to audit their code to find the crap he put in there, but that couldn't possibly have cost $3 mil.

    1. Re:Good story until... by The+Wing+Lover · · Score: 3, Insightful

      When you are a huge corporation, even a day's downtime to restore backups can cost $3m in lost productivity and business opportunities.

      --

      - In Capitalist America, law violates YOU!

  17. Not possible... by leeet · · Score: 2, Insightful

    You must not be a sysadmin...Or you must be working for the government?

    This is unrealistic. When the fire is burning, you can't take 5 minutes to sit down and follow the procedures, you just jump in and fight it.

    --
    -- Leeeter than leet
    1. Re:Not possible... by void* · · Score: 2, Insightful

      Suppose I pre-prepare a security comprimising change with the express intent of waiting for the fire, so I can slip it in with a fix, and I slip it in while fixing something that has -nothing to do with the security comprimising change- (i.e., the review wouldn't catch it because the reviewer wouldn't think to look in that portion of the system/code/etc)? The fix is still documented, procedures were still followed, there is a rollback, yet security would still be comprimised, no? (Note that I'm not saying that it wouldn't be hard, just that it's possible).

      --


      Code or be coded.
  18. How can you prevent it? by Call+Me+Black+Cloud · · Score: 3, Insightful

    You can't. Next question.

  19. Always be kind to your sysadmins... by Anonymous Coward · · Score: 2, Insightful
    ...for they can make or break your company.

    "Be kind to your enemies; be peaceful. But if they lay a finger on you, send them to the cemetary."

  20. Re:20 years by BigFire · · Score: 2, Insightful

    I presumed you're the type that think that corporate CEO who looted pension fund shouldn't get any time in jail, since they didin't actually use physical violence?

  21. A Decent Deterrent by ReadParse · · Score: 2, Insightful

    ...is 20 years in prison. It doesn't hurt to have national press coverage of the guys who have tried this and have failed. It's not like you can get away with this very easily.

    Let's see? Who has had access to all of these systems? Who has recently quite or been fired? Who just sold a boatload of stock when we got hit? A smart admin realizes that there are other admins as smart or smarter. People can piece these things together, and obviously this employer and the government are taking this crime very seriously.

    RP

  22. Re:20 years by BattleTroll · · Score: 2, Insightful

    20 years seems harsh only when viewed in the context of a "victim-less" crime. However, most white collar crime has the potential to affect a larger number of innocents than most people consider.

    Consider the consequences of an irrevokable malicious act on a trading company. If damage is broad enough the perp shuts down said company for days on end. Thousands of clients are unable to do anything during this time. Employees waste thousands of man hours attempting to rebuild wasted systems. If the damage is extensive enough, it could put the entire company out of business.

    Just take a look at the fallout of the Enron situation and you'll find countless people who have lost entire life savings because of some "victim-less" white collar crimes. Not only is Enron dead, their consulting firm has died, thousands of people are out of work, numerous support companies have gone under, and thousands of people have lost millions upon millions of dollars in retirement savings. The consequences of Enron's illegal practices touch many people who did not have anything to do with the crimes being commited.

    Don't assume because a crime doesn't physically harm someone that it has fewer consequences or requires lesser punishment. In the broad perspective of total social impact, white collar crimes have the potential to an aweful lot of harm to a large number of people.

  23. Don't delete, disable... by Spoing · · Score: 3, Insightful

    As a rule I never delete an account or remove user identification information.

    Nuking an account kills part of your auditing trail and/or proper file associations when you do it. Besdies, if you need to check something as a specific user it can be a bear to undo the dammage. Temporarily suspending access can happen just as often depending on the environment, so why not simplify it to one process?

    Besides the practical option of re-enabling the account if the person comes back, disabling accounts is a good habit preventing nasty problems fixing mistakes (John Smith vs. Johan Smith).

    --
    A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
  24. Re:This article isn't very good. Neat story though by alkali · · Score: 2, Insightful
    The foregoing is correct: buying options, in this case puts, is a good way to make an enormous return on large short-term movements in stock prices ...

    ... which is why the SEC investigates any large options purchases which occur shortly before large short-term movements in stock prices. If you're one of these lucky devils, they will probably get your name and address from your broker and see if you are employed by the company in question, if you work for a law or accounting firm retained by that company, if you have the same last name or home address as someone who works for the company, etc., etc.

    There is nothing sinister about this kind of investigation; it's routine police work. (Likewise, if you're the town layabout, and the day after a masked man robs the town bank you start spending money like it was going out of style, the sheriff will probably peg you as a suspect.) What is amazing is that people do not realize that it is the SEC's job to do this sort of investigation: they just blithely go ahead with their stupid criminal plans. Even lawyers, who ought to know better even if they are unwilling to behave better, do this sometimes.

    The perfect inside trader would have 10 loyal friends located around the country willing to make small purchases of options on his behalf, to forward him all the profits, and to stonewall the SEC investigators who come knocking. Believe me, you don't have 10 friends like that.

  25. Re:Sheesh! EXACTLY by Anonymous Coward · · Score: 1, Insightful

    Part of the problem is "lone ranger sysadmins". No serious system should be vulnerable to the whims of a single individual with the root password. The root account should only be allowed to activate if two separate passwords are typed in (one for each person). You can have a pool of admins each with their own password, but at least two of them would be needed to log in as root. You then require via company policy that for the duration of the session that both persons are present for the work that needs to be done.

    You still need some sort of emergency brake so that a lone admin can stop a haywire system from further corrupting itself, but to actually fix or change the system there should be oversight.

    At the same time, forcing two people to do this work means that you get all the other advantages of pair programming: 1) two heads are usually better than one, 2) two people are now familiar with the status quo, 3) less mistakes due to simple errors (as one person can catch typos, etc, before they're committed to disk), 4) others? There is plenty of documentation that programming in pairs is a highly successful strategy, and I suspect that it's a good idea to do major systems administration in pairs as well.