On Mon, Mar 26, 2007 at 06:45:37PM +0000, Dave wrote: > I'd counter that a sysadmin who installs software should do a > background check to ensure that the thing isn't riddled with > security holes unless the program was specifically requested by the > system owner. He should do it whether or not it was requested by the owner, because that's simply part of a system administrator's job. If the owner wants a peice of software that the sysadmin knows is bad or wrong for the job, it's his *job* and his *duty* to make sure he tells the owner. If the software breaks, and the company loses money because of it, it's the sysadmin who will get fired, not the owner. The owner may choose not to listen, but you have to cover your own a$$. Get it in writing, whenever possible. [Yes, seriously. If you're a sysadmin working for a manager/owner who insists on making really bad decisions that you know will cause serious problems, write down the problems you think it will cause, and get him to sign off on it. If you can not do this, you should carefully consider whether you should continue to work there. Asking him to sign off on his decision might save you your job, and might even convince him that he's potentially making a grave mistake. CYA.] That said, even if the sysadmin does this, there still may be undiscovered bugs. He should not be expected to be held responsible for those. There may also be undiscovered weaknesses inherent in the design of the program which can be exploited by local users to gain access to data they should not have. Most system administrators are not software engineers, and can not be expected to identify these. Especially when the software they're managing is not Open Source, which is quite often the case. > (Basically, the owner is always right, as far as the sysadmin is > concerned. If the owner wants advice, it's his own responsibility > to ask for it. If the sysadmin can't live with himself and with his > duty to the owner of the system he's in charge of, then he should > give up one or the other.) This is just stupid. Utterly and completely. Owners hire sysadmins because a) they don't know how to do the job and/or b) they have more important things to do than keep track of all the stupid security bugs in the software they use, e.g. running the business and makind sure the business stays profitable. If that weren't true, they'd do it themselves. In a publicly traded company, the owners are the stock holders. The vast majority of stock holders are not interested in what software runs on the machines the company uses, or who the sysadmins are. They don't care one iota about whether a particular peice of software honors $PATH, and couldn't care less what security model the infosec guy uses, as long as it doesn't negatively impact the share price. Having a business degree, I can tell you that it's the business owner's responsibility to oversee the overall success of the company, by delegating different aspects of running the business to people who are good at those tasks. If he fails to delegate the right responsibilities to the right person, the business will fail. Having been a system admin/security engineer for 12 years, I can tell you it's the sysadmin's job to make sure that the software the company is using won't shut down the company, get all its proprietary data stolen, or otherwise cause the company to lose money. If he fails, he will be *fired*... unless he can legitimately show that the fault lies with the programmer, which in most cases is true (lucky us). The only time the system admin should trust the owner to make the right decision is when the system admin is the owner, and he has the knowledge and experience to do the job, and the time to maintain it (which is basically never). Otherwise, he needs to find someone else to do that for him, and trust in the sysadmin's decisions. That's how business works. > > In *your* case, the doesn't own the system. There are other places > > where the user partly owns the system (well, participates to the > > decisions, at least). > > If users on a particular system also have other roles (partners in > the entity that owns the system, voters in an entity with an > advisory role to the entity that owns the system, etc.), those are > separate roles. Pure doublespeak. User's roles are whatever they are. Often they are decision-makers, and often they are not. It doesn't matter... in the end, if the code is written weakly, and someone who has sufficient legitimate access (which may be none, or may be some, depending on the case) wants to exploit that weakness, they're going to do it. Who the decision-makers are, and what their titles are, is totally irrelevant. If a user opens holes in the system which can be exploited, he is at least partially to blame, whether he's the janitor or the president, whether he has a security clue or not. If the programmer fails to make adequate protections against the user doing those things, he also is at least partially to blame. But the programmer should know better, whereas the user can not be trusted at all... because he just might be the janitor. The only question is, what is the appropriate level of paranoia? The answer depends entirely on the situation, and usually, just as here, agreement is hard to come by. > Said otherwise, the sysadmin has the domain of setting systemwide > policy within the guidelines of the system owner, while the user has > the domain of setting userwide policy within the guidelines of the > sysadmin. More doublespeak. The sysadmin's job is to make sure the users have the computing resources they need to do their job, while protecting the company's assets (data and intellectual property). Period. As a matter of practicality, this often means enforcing security policies, because security breaches result in breach of confidentiality of company secrets, or loss of availability of the computing resources or data stored therein. The IT role is primarily a service role; the sysadmins do what the users want. The security department sets security policies, though often the security department is the sysadmin. In a well-run company, there must be agreement between the security people about what level of security is required to protect the company, while allowing the users flexibility required to do their work. Neither group is solely responsible for making that decision, except when the two groups are one in the same, as with a person's private PC, or perhaps in extremely security-sensitive businesses, where the infosec group has been given complete autonomy by the ownership to do whatever they feel is necessary, i.e. if the security of the company is breached, the company very likely will cease to be functional. Still, uneducated users continue to complain because their PC gets broken into, or they lose data because of something stupid they did. Hang around a PC store, you'll meet them. You'll hear them complaining; and you'll note that they're not complaining about how stupid they are... they're complaining that the software wasn't written better to protect them -- poor, ignorant users that they are. And sure, most of those are Windows users, because that's what PC stores sell. Hang around enough mailing lists for OSS software, and you'll see them there, too. You, sir, have not the slightest of clues. The only area where these things often don't hold up is the public sector, where up is down and people operate by their own fantasy rules, as at most government agencies. You'd fit right in there. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgp4e4HWXWO83.pgp
Description: PGP signature