Balancing Bad Applications vs. Network Security?

Darlok asks: "One of our clients recently purchased a new financial software package from a major vendor for their industry. This is not a small mom-and-pop software house. The problem is, like a lot of industry-specific software, there are a considerable number of bugs. What's shocking is that to work around a problem preventing users from logging on, the manufacturer's recommended solution is to grant -Domain Administrator- privileges to all users, and they refuse (or are is unable) to explain that need further (it's bad enough that an increasing amount software seems to require local administrator privileges). Considering the enormous costs involved, how do you explain to Management that they shouldn't run this software until the problem is resolved -- which could be a long time, costing even more money? How do you balance productivity versus security when ANY productivity would give away the keys to the city? What can make an industry-specific software manufacturer pay attention to larger issues when they already have something of a captive audience?"

Comments

Simple terms.

[babbling]

Management doesn't want to know the details. Just say there are 'major security concerns'.

You shouldn't usually sacrifice security for productivity, unless you don't need the security. I suppose Windows is a good example of businesses sacrificing security for productivity, though. In most cases they probably get away with it by having firewalls and the like.

Re:Simple terms.

[secolactico]

Management doesn't want to know the details. Just say there are 'major security concerns'.

Explaint to them that granting domain admin priviledges to everyone means that even the interns they hired to do data entry will have *full* access to every resource on the domain. That includes servers and workstation with sensitive information (incl. upper management's). And that it's just a matter of someone getting up to to go to lunch and not locking their workstation to leave the door wide open to any passerby.

Problem is, by now your data is in this tool and you need to use it to work. So you'll have to bite the bullet anyway.

Re:Simple terms.

[Philip K Dickhead]

Explain to them that they cannot acheive SOX compliance, and that violations are punishable by jail-terms for responsible c-level officers.

Re:Simple terms.

[corbettw]

That, sir, is pure genius. I'm stealing that one the next time something like this comes up at my work.

Re:Simple terms.

[mork]

You need simple analogies to explain this to management.
In the next meeting ask the boss for his house keys, then proceed to explain that you will now make copies of his house keys and along with directions to his house pass out the key copies to all employees.
When he freaks out explain this is the same as granting domain admin access to the systems.

That should help explain the importance of security :)

Re:Simple terms.

[91degrees]

You shouldn't usually sacrifice security for productivity, unless you don't need the security.

Not true. Computers owuld be more secure, and a lot less productive, if they weren't networked. Everything gets compromised

Re:Simple terms.

[larien]

You've given a one line answer which will carry the argument in the majority of situations... well done. Just mentioning SOX should be enough to bring managers out in a cold sweat :)

I'll take SUX2BU for $1000, Alex.

[Anonymous Coward]

"What is 'your job'?"

Give management an option

[Marxist Hacker 42]

A reasonable option in this situation is to give the experts who will use the industry specific software their own subnet; and save all files to a shared server that then backs up to a server on the regular LAN. The only point of contact should be that file transfer protocol- NOTHING else should be allowed through. Then hire an IT guy to help out the experts, and leave it at that.

Re:Give management an option

[Philip K Dickhead]

Yeah. Or isolate on a Citrix / Term Serv box, and buplish only over ICA/RDP.

Dodging the issue, but a workaround?

[MagicMike]

Definitely try to whip the vendor into shape, but have you considered running the application in a quarantine area, like a VMware VM?

It's trivial nowadays at least to set up separate little compartmentalized computers and networks, though I recognize that the carry-cost (virtual services are still supported services and need monitoring and troubleshooting and backups, etc etc) it would at least get around the privilege issue.

If this is totally non-helpful, sorry, it was the only thing I could think of :-)

Sounds familiar

[karlto]

We were told something similar with a new software package... turns out that a single registry key needed slightly different permissions. I wasn't too impressed with their suggestion that all users need to be administrators either!

I wonder if it's the same app...

[RingDev]

I have my own nightmeres from trying to support a 3rd party app like that. At this point I would suggest investigating the issue as much as possible. Set up a file request watcher(MS has one, but I can't recall its name), a port sniffer, keep an eye on the Active Directory. Log into the system and see what resources are being access that could require that kind of access. Is it updating the AD or trying to use LDAP? Is it performing some process remotely on the server? Is it trying to create/share/access some sort of network resource?

Find out what it is trying to do and open security only for that action to the users.

-Rick

Re:I wonder if it's the same app...

[Bios_Hakr]

You could also create a domain for users of that application only. Use VLANs and install a small domain controller. Prevent any cross-contamination between the two domains.

After that, just let the users have at it. Most likely, they won't fuck up too bad. And their curosity to go sniffing around will be sated once they find that all that's out there is X-number of PCs exactly like theirs. No e-mail. No personal documents. No pr0n.

Give those users a laptop or another desktop with a KVM switch so they can access the companies' real domain when they need to. Just make sure the wallpapers on the secure box show that they don't need to be fucking around.

Let's name NAMES

[Philip K Dickhead]

Oracle.

This is a big issue. IANAL, but I think there is a legal casse here. You may have signed this away by contract, so...

Under this configuration, there is no way that you company - if publicly traded - can meet the mandated compliance under SOX, etc. This doesn't touch the fact that you have now lowered authorization and access controls to a level that is inferior to MS-DOS.

And why does the DB vendor care? They assume all value is locked under their own controls - and the OS is insignificant. Bad shot. If you are a domain admin, you can always work your way into something - even put a keylogger on the financial controllers desktop, and capture the precious secrets for logging into the system.

Re:Let's name NAMES

[GoofyBoy]

>Oracle.

Exactly what product does Oracle require this permission?

Re:Let's name NAMES

[Philip K Dickhead]

I am just mitigating an oracle financials app that is hard-coded to have read/write access to files in the windows/system folder. Locally and on the server! Yowch.

Re:Let's name NAMES

[RingDev]

That still doesn't require domain access, just local read/write access to the local system folder and the server folder. You should also check to see if the server file activity is under the user's account or under the service account running on the server.

-Rick

Re:Let's name NAMES

[Philip K Dickhead]

You and I know that - but the solution of the consulant who built this was to add DOMAIN USERS to DOMAIN ADMINS.

Re:Let's name NAMES

[LurkerXXX]

So it isn't actually Oracle that is the problem, but moronic consultants. Lay the blame where it belongs.

Re:Let's name NAMES

[Philip K Dickhead]

World writable files in System and System32? For ordinary users? That's still a problem.

Re:Let's name NAMES

[RingDev]

"DOMAIN USERS to DOMAIN ADMINS"

Then the consultant is a MORON. If giving users Domain Admin access is the ONLY possible solution (which I highly doubt) there is still no reason to give the entire Domain Users group Domain Admin access. You would still only increase access for those users who need it. If we're going to name names, what is the name of the consultant who told this to you? Just so I know to make sure I don't inadvertantly wind up hiring him.

-Rick

Re:Let's name NAMES

[Philip K Dickhead]

This was someone who'd been at the customer over a year ago.

Whacking bad problem! All c$ shares and remote registry available to everyone, everywhere on a flat network! Even PT security guards in the middle of the night.

I don't know how they missed a worm infestation.

Re:Let's name NAMES

[Schraegstrichpunkt]

This doesn't touch the fact that you have now lowered authorization and access controls to a level that is inferior to MS-DOS.

No kidding! A domain admin can set security policies that effectively prevent *anyone* from logging in, and propagate those policies to all the workstations on the domain, thus disabling local logins on every machine in the company! All it takes is one malware program...

Use an analogy...

[fredklein]

how do you explain to Management that they shouldn't run this software until the problem is resolved

"What would you do if you got the door to the breakroom replaced, no one could open it, and the manufacturer's solution was 'Give every single employee a copy of the Master Key for the entire building'?? Well, it's 100 times worse than that."

Jail it off

[19thNervousBreakdown]

Speaking as someone who has had to support software written by people with no concept of security, if it is even remotely doable, even if it means a fair amount of work, take that machine off the domain. Jail and firewall the everloving snot out of it, don't let any data into it except through very controlled routes, and don't give it any privileges on the network, then give it all the admin rights it needs. Basically, just change it from a piece of software into an entire dedicated appliance.

Although you could spend the time to try and fix their problems, this kind of thing will come up over and over again. You'll save yourself time and effort if you nail it down now.

Difficult situation

[QuestorTapes]

Note: IANAL

> One of our clients recently purchased a new financial software package
> from a major vendor for their industry.

When a business purchases software (or anything else) the manufacturer implicitly warrants that the item is suitable for its intended purpose.

> What's shocking is that to work around a problem preventing users
> from logging on, the manufacturer's recommended solution is to grant
> -Domain Administrator- privileges to all users, and they refuse
> (or are is unable) to explain that need further

Time for the client firm to call in the lawyers. Write up a formal document explaining that this is unacceptable from a security standpoint. Period.

That your firm cannot and will not accept -any- responsibility for anything that goes wrong if the client's management uses the software in this fashion.

Then write up a formal recommendation that the company either (A) sue the vendor or (B) place the payment for the software in an escrow account, and explain it will be turned over in payment only after the software is made usable by fixing the defects. Choice B is a standard option in dispute resolution; it demonstrates that the client party has every intention of paying, but not until the responsibilities of the vendor are met.

Have -your- firms lawyers look over all these documents and recommendations carefully, and put the right spin on it.

> Considering the enormous costs involved, how do you explain to Management
> that they shouldn't run this software until the problem is resolved --
> which could be a long time, costing even more money?

Lay out the business details. Explain to them that under current federal law, the -management- of the client firm will be assuming any an all liability for using unsecure software against all the recommendations of your firm's people.

However, even with all this, the client's management may choose to give away the keys. Cover your own asses. If you support the client in this, you may be liable. In situations like this, the client may choose to go full steam ahead; you can't stop them, you can only CYA.

Re:Difficult situation

[Matt Perry]

When a business purchases software (or anything else) the manufacturer implicitly warrants that the item is suitable for its intended purpose.

You haven't read an end user license agreement lately, have you? In all the ones that I have seen the manufacturer doesn't guarantee that the software will do anything, including its intended purpose.

Re:Difficult situation

[QuestorTapes]

> You haven't read an end user license agreement lately, have you?

Actually, I have. ;>

> In all the ones that I have seen the manufacturer doesn't guarantee that
> the software will do anything, including its intended purpose.

The law (in the US) doesn't permit a person to waive -all- legal protections under licensing agreements. These kinds of dodges in license agreements are generally held to have limited effect on software designed and marketed for business purposes.

I'm not saying it's a slam-dunk; I'm just saying the business has the right to take action and let the courts decide.

Re:Difficult situation

[Anonymous Coward]

Speaking generally, implied warranties are disclaimable, while express warranties, once made are not. Second, this is not a sales contract, but a licensing, so even that may not apply. Next, everyone here seems to think that this is pretty normal for software to require this, so in fact even if the warranty of merchantability did apply, is seems fit for its ordinary purpose.

These limitations on contract normally apply only in consumer transactions. It is assumed that businesses are capable of protecting their own interests.

In addition, there is no "US law" in this situation. This is a garden variety contracts question, which is a state law question, so these assumptions may not apply.

Re:Difficult situation

[QuestorTapes]

> Speaking generally...

No comment, other than to state that this only affects whether there is a presumption of default on the part of the vendor; it doesn't affect whether you can sue (or escrow payments) or whether the suit can be brought.

> In addition, there is no "US law" in this situation. This is a garden variety
> contracts question, which is a state law question, so these assumptions may not
> apply.

With the additional point that contract law is governed by precedent under the common law, and thus there is a large body of law which is generally applicable anywhere in the US.

Thanks for your comments. I agree that this is not a foregone "vendor is clearly in default" situation. But it is, in my opinion, actionable.

Re:Difficult situation

[Anonymous Coward]

With the additional point that contract law is governed by precedent under the common law, and thus there is a large body of law which is generally applicable anywhere in the US.

No, this is not the way the common law works in the US. A decision concerning a state law question in Illinois is not binding on courts in Ohio (unless the Ohio court is applying Illinois law, but this is uncommon). It may be persuasive depending on the quality of the decision, however.

You are correct, someone may allege a breach of contract and sue. The plaintiff will absolutely find themselves named in a countersuit and should be in contact with their lawyers now. Acceptance of the product will lessen the number of remedies the buyer has.

Re:Difficult situation

[QuestorTapes]

My last post in this thread.

> No, this is not the way the common law works in the US. A decision
> concerning a state law question in Illinois is not binding on courts
> in Ohio (unless the Ohio court is applying Illinois law, but this
> is uncommon).

Quite correct; I did not intend to imply otherwise. However, this is an area in which the rules are similar in most states. The various state legislatures and courts have worked to keep a certain commonality. Among other things, it serves the interests of the business community.

The details vary greatly, of course, as does the likelihood of a specific ruling in a given state. But the basic principles tend to be referenced in most states.

Thank you for your comments.

I don't mean to be rude.

[Anonymous Coward]

And I may be completely off base and giving into my own ignorance. But it would seem to me that this is a great plausiblity gap. I would think that further persistance with the vendor would reveal an actual solution as opposed to a catastrophy in waiting that someone further down in the vendor's organization knows to restore functionality.

Also, could you post the names or stock ticker symbols of their competitors? And your company's competitors while you're at it?

Bring a translator.

[jonbritton]

Speak their language. Management types, around half the time, hear "security concern" and think you're some overstuffed loser with delusions of grandeur, afraid of THE HACKERS who care, at all, about your data. The other half are of the same ilk, but think you're suffering from a guilty conscience and are the "hacker" they need to worry about. Instead, warn them the security risks open the way for buzzword storms. Viruses! Worms! SPYWARE! SPAMMERS! Crashing servers! Cats and dogs, living together! Breaking Windows!

"It'll never happen to us!" is a mantra of the generation. It's what keeps sex feeling real, condomless good. It's what keeps us smoking those feel-nice cigarettes. It's what has us drive after that third beer. And, it's what has us open up port 3389 and upchuck admin privs to every dipshit who uses their first name and the number "1" as a password. Speak to their experience, and don't tell them what they want to hear (that you're a self-important geek.)

Tell them what they're most afraid of hearing.

Very easily fixed

[Anonymous Coward]

Put the application in its own domain.

Re:Very easily fixed

[Bios_Hakr]

VLANs are your friend. KVMs are useful too. Problem solved...

Investigate, and threaten litigation.

[ErikTheRed]

Here are some ideas you (and your management) can pursue, simultaneously if need be. Oh yeah, IANAL, but I've dealt with plenty of them.

1) See if you can figure out what requires Domain Admin access - usually it's file or registry issues. SysInternals RegMon and FileMon are excellent for spotting these - you just run the program with regular user privileges, and watch to see which requests fail.

2) If this is a large, contract-licensed piece of software, look to see if the contract's been breached. Even if the vendor indemnifies themselves thoroughly, a good lawyer might scare them into compliance - you never know which contract provisions a judge may find unenforceable. I've seen really strange things happen in court (both good and bad). If you're working with the vendor, you can use the "look, you've sold us unusable software - you have to either fix it now, or I have to turn this over to legal so they can get our money back, and try to recover compensation for the time and resources we've wasted" card. Don't rant and rave and scream and threaten - just be a nice, reasonable person and explain that they're not leaving you any alternatives. You need working software or you need compensation. Only a very stupid or very cocky vendor will refuse to work with you - nobody wants to be dragged into court. And you really don't want to go to court either, but you can't afford to get screwed

3) Another possible route is to get them to put in writing that their software will only run with Domain Admin priviliges or whatever. Tell them you just need it to cover your own butt. At that point, you can get your management to sign off on it as well, thus covering your butt completely, or your management can use it to help show they negotiated in bad faith while selling your company the software.

Whatever you do, don't let a vendor bully you into doing something stupid that violates your responsibilities as an admin.

Sig

[XanC]

Okay, this is off-topic, but I'm confused. Not that I'm saying I disagree with you, but when somebody places his hand on the bible and swears an oath, he's attesting that he means it because he believes in justice in the afterlife.

Basically, it means the Bible is more important than the Constitution.

So how does pointing this out help your case?

Re:Sig

[Philip K Dickhead]

Sometimes, a man's got to learn how to think.

Re:Sig

[XanC]

Sometimes, a man's got to learn how to think.

I guess I'm dense... Are you referring to me, yourself, the Senator from your anecdote, who?

Re:Sig

[Philip K Dickhead]

I don't mean really to be obscure, or provocative.

Just think about what these things mean. Assume the real believer's position. Swearing on the Bible is a promise to God, by God, before God. You don't make that promise lightly, nor if you do not intend to carry it out. If you find an inherent contradiction in the promise you are making - do not lie to God, and make it anyway.

The Bible has many strange and contradictory injunctions - especially if these are read as literal - or approached merely intellectually. Literally, intellectually, the Bible does NOT say "marriage" is between a man and a woman. The biblical position of Abraham and others is that marriage is between a man and two or more women. Also, eating shellfish is an abomination in the eyes of the Lord - equal in approbation to homosexuality.

A true christian believer, who takes the statements of Jesus to heart, will have little or nothing to do with the "Old Testament". The laws of Deuteronomy and Leviticus were written by the very Temple priests that Jesus decried and vilified. The covenant of Moses was superceded by the revelation of Jesus.

Matthew 26:28:
This is my blood of the new covenant, which is poured out for many for the forgiveness of sins.

Forgiveness of sins. Not the license to condemn others, by old religious law.

So. With discursion these are some points, that ought to be of concern to a beleiver, who constantly interrogates their own sincerity.

I am not a christian believer - but I do try to interrogate myself over my own sincerity. This is the way to the truth. Seeking this is the true aim of any religion in its enlightened form.

Re:Sig

[mooingyak]

Not having followed the link, I had guessed the quote was something more along the lines of separation of church and state.

Towards what you said though, I've always been a bit confused as to how religious Christians pick which parts of the old testament are still valid.

Re:Sig

[Philip K Dickhead]

"I've always been a bit confused as to how religious Christians pick which parts of the old testament are still valid."

Ususally, the parts endowing one's predjudices and fears with devine authority.

Re:Sig

[Schraegstrichpunkt]

It's only about 100 words. Follow the link.

Re:Sig

[mooingyak]

Now that I've read it, it meant exactly what I thought it would.

Re:Sig

[OhHellWithIt]

Towards what you said though, I've always been a bit confused as to how religious Christians pick which parts of the old testament are still valid.

Don't worry, they're confused about it, too. What's funny, of course, is that we see the same thing in Judaism, where there isn't some guy coming along and giving us a new law.

yeah, well...

[bobalu]

Speaking as someone who has to implement any number of crazy last-minute apps before processing millions of documents, the last thing I want to worry about is conflicting credentials and other security bullshit. Now obviously "Domain Administrator" is a pretty extreme example, but I recently had a half dozen critical machines down because some do-gooder idiot renamed the Administrator account and didn't give me the new password OR account name. ARRRRRGHH

These machines might as well be in a vault in the Bank Of England. There's a point where it's stupid.

Just my $0.02, and because bartenders blank out when you say that to 'em.

The art of saying "no".

[Pig Hogger]

In business, more than anywhere else, you have to know how to say "no". Sometimes you have to terminate a customer. This could be a good opportunity to do so.

Enjoy.

Maybe an obvious answer

[heinousjay]

Is it feasible to set up a domain for the software to run in? It's not a good answer, I know, but it may work, and the costs involved will probably be trivial if the software is critical enough.

I must admit, however, I'm having an incredibly hard time imagining what this software could be doing that requires Domain Administrator privileges. Poorly written doesn't even cover it.

fire the client

[corbettw]

Several people have already pointed out the legal issues re: SOX compliance when installing POS software like this. Another piece of advice is: if they don't listen and insist on installing this package, fire the client.

Some clients just aren't worth keeping. Ones who don't take your advice seriously, and are willing to do things that will put themselves, and possibly you, in legally precarious positions, just aren't worth hanging onto. If they insist on going this route, and you've done everything you can to show them why it's a bad idea to install software like this (and do make sure you've gone out of your way to explain the situation thoroughly, in terms they can understand), then you'll just have to let them know you cannot in good conscious support their decision, and are terminating your support contract.

Re:fire the client

[code addict]

Ha ha... Am I the only one who read "POS software" as "Point-Of-Sale software"?

Damn duplicate acronyms.

Oh, for the love of god...

[(H)elix1]

Here is an honest answer...

I'm pretty sure you are not talking about the kit I've worked on, but I sure know the type. My bane is DBA's *love* to screw with stuff because we allow them to manually run the setup if they like. Some claim it is to improve performance, some security... All in all, it makes for obscure errors and headaches later on when additional components are added to the system. It costs money to make a specific environment 'tested' year after year with all the possible permutations. Yes, a special snowflake can get their needs met, but I've found very few willing to pay the real cost (above and beyond the enterprise price tag). You want that type of loving? Add an extra zero to the check. But you can't, your the installer/maintainer. Till then, I'd call you a blocker - and being on the technical side, I'd wine and dine the decision maker who want to run the kit.

Maybe they want complete control.

[Futurepower(R)]

"... they refuse (or are is unable) to explain that need further..."

Maybe they want complete control over your computers remotely at all times. If they decide to put you out of business, in favor of a competitor, they can change their EULA (which they usually say they can do at any time) and uninstall or corrupt their software.

--
The movie Loose Change, 2nd Edition explores 9/11 issues.

always the vendor

[Anonymous Coward]

sometimes i have seen where the customer put insane demands and retardly short timlines to allow the vendor to properly complete all tasts.

I wonder if this is a case where they might have put to high of a demand and deadlines on the vendor AND expect everything to be totally perfect...

I really disslike it when customers do this type of stuff.... they complain about their boss doing this to them and they end up doing their vendors the same way.

Simple solution to getting the problem fixed

[Skapare]

There is a simple solution to getting the problem fixed. Just post the name of the software package, software company name, and link to their website. Slashdotters will ruin their reputation. And the hackers will find the network exploits that almost certainly exist in that package (and have instant Domain Administrator privilege). The company will either fix the problem or go out of business.

Re:Simple solution to getting the problem fixed

[eric76]

Remember what a little publicity did for Sony and their rootkit.

Maybe the customer should remind the vendor of that.

Don't shoot the messenger.

[twitter]

You don't like free information, do you?

Just post the name of the software package, software company name, and link to their website. Slashdotters will ruin their reputation.

The reputation is ruined by the faulty product, a substandard OS, and a lack of information. People who need to know about the package are going to find out. Better they find out here than waste their money and vow to never buy another program from the company again. Full disclosure protects your reputation.

... the hackers will find the network exploits that almost certainly exist in that package

What makes you think the hackers don't already know? Your ignorance won't protect you. Knowing about a problem will.

The company will either fix the problem or go out of business.

Now you're making sense. Companies with poor products don't last long. Hopefully, they port their fine application to systems that don't have problems.

Re:Don't shoot the messenger.

[Anonymous Coward]

WTF? He's saying that posting the information will cause the company to either fix the flaw or go out of business. Things balance themselves out. You repeated what he said, except that it took you twice as much typing. Do you have a reading comprehension problem? "substandard OS"? What the hell?

Re:Don't shoot the messenger.

[Skapare]

I think he was taking issue with what I said implying that hackers would not be able to crack the software unless the information is posted on slashdot. I could have worded it better. Hackers probably have already cracked it. It's just that we don't have a name of the product, yet, to associate what cracks are available in this particular case. But in the unlikly case it hasn't been cracked, yet, knowing that so many networks will be running it with Domain Administrator access will just make it doubly attractive to crack.

sudo

[Anonymous Coward]

Use sudo, http://www.gratisoft.us/sudo/ Oh Windows? Nevermind then.

Re:sudo

[wolverine1999]

Try RunAs instead.
What do you think?
http://www.microsoft.com/resources/documentation/w indows/xp/all/proddocs/en-us/runas.mspx

Re:sudo

[Anonymous Coward]

That seems more like su. You still need the admin password.

Re:sudo

[Anonymous Coward]

Well... if you did a runas towards an admin account in a different untrusted domain, you could get away with it.

Re:sudo

[Anonymous Coward]

We're talking Windows here - if it's on AD domain
1. Policy maker application security -> www.desktopstandard.com -> impersonation of admin
or
2. Fullarmor's Intellipolicy product ->www.fullarmor.com impersionation of admin
3. Application compatibility toolkits - make the appropriate s/w shim
or
4. workgroup like packages tcqrunas, netexec, runaspro etc. there's literally tons of apps like this to fix your "Domain Admin" pain points.
So why the discussion on new domains, RDP etc.?

Re:sudo

[woolio]

I think not.

That solves part of the problem

[Rhinobird]

But it doesn't address the fact that every user of the system (assuming a DB of some sort here) would be able to go in a screw up the application. If everyone using it is a domain admin, then they are able to change everyone else's passwords, then log in, scew with the data, and leave. They may not be able do that outside that particular domain, but now that application is still useless cause you can't trust its data.

Re:That solves part of the problem

[Jinjuku]

What is to stop a user with WRITE privs to the data base (db's are not much good if you can't input into them) from writing erronous data. I can hose a database with a SQL statement... You either trust someone at somepoint or you don't.

Or give them their own Domain entirely.

[mosel-saar-ruwer]

A reasonable option in this situation is to give the experts who will use the industry specific software their own subnet; and save all files to a shared server that then backs up to a server on the regular LAN.

If this financial software package is as expensive as "Darlok" makes it out to be, then just go to your local Microsoft rep and purchase a bunch of seats for a new Domain - the cost of the new seats would probably pale in comparison to the cost of the financial software package.

Then let their secondary accounts all be Admins within their own little domain, but with no special rights to the larger Active Directory tree.

Or do that old thing with NT 4.0 Domains, where Domain A trusts Domain B, but Domain B doesn't trust Domain A.

Or create two separate domains entirely [with no ambient Active Directory tree and no trust relationships], and just make everyone memorize two different user names and two different passwords.

That'll get management's attention.

Another NAME

[Anonymous Coward]

Sage Software(formerly Best)

Full read/write permissions in the Windows folder for Crystal Report libraries.
Full read/write permissions on the program directories.
Disable real-time virus scanning of the program directories.
The read/write permissions aren't even documented because you can--and this is a direct quote from support--"just make the user a local admin."

Re:Another NAME

[Philip K Dickhead]

I have had to accept Local Admin for their WS. This is done by machine GPOs, with a machine startup script that add them for the duration of the session:
NET LOCALGROUP /ADD Administrators INTERACTIVE

They are local admin, until logoff. This doesn't extend the privilege to any kind of Remote Auth (unless you count terminal services), and the user can't access C$ across the net to another host where they may also be logged in.

It's a compromise, and I noted the risks in my report.

It's Funny...

[thegrassyknowl]

..that I have been saying for a while that software sucks. Most Windows software requires local admin rights to get anything done these days. So many wankers keep correcting me and saying "we run a large enterprise site and we don't need to give our users any admin rights".

What they neglect to say is that they also don't give their users anymore than a basic suite of apps like Office and a web browser. When the user needs more (specialised software) there is usually an uphill battle against some anal retentive Windows admin (who should have stayed in his parents basement) and the staff who need some software that needs local admin. Usually the BOFH wins and the staff are left going without, again.

Fortunately where I work they have realised this and we can pretty much do whatever we want. The admin understands that most users are savvy enough to not bollocks things, and most of the time things don't get bollocksed. I think I work for a bunch of wierdos though because they're the only place who will actually give me local admin on my box.

Also, fortunately for me, I admin a Unix server so the joys of Winbites don't come up to haunt me too often... yay!

I think that you should explain to your boss that giving users of moderate computing skill domain-level admin privs is just asking for trouble if a worm or virus makes its way into your network. Just explain that if they don't have admin rights then the damage is localised to their files on their pc. IF they have admin rights the damage can potentially spread to every PC in the enterprise VERY easily!

Get onto the software company and cancel the cheque/credit card payment. You wouldn't pay for a car that required you to leave your garage unlocked 100% of the time. Why pay for their shit software? For a "large" operation, they certainly sound like a two-bit shit box of a company!

Easy...

[ebrandsberg]

Threaten to the sales guy who's commission is on the line if you threaten to sue for a defective product if they don't accept a return of the licenses. Nothing will scream louder than someone that will have to return part of his paycheck if someone else doesn't follow through with resolving a problem that is their job to fix.

Re:Easy...

[platos_beard]

Oh yeah, we programmer's get all choked up when a salesman's gonna lose some commission.

Actually, I do have a couple serious things to say about this situation...

First, what a support department says has to be done has more to do with what's easy for support personnel that with what is really necessary. They don't care if all that needs to be changed is one registry key setting somewhere, it's easier to say to make everyone an admin and you know you've sidestepped all permissions issues. I've even found that automating ways to allow the minimum amount of priveleges for legacy code to execute has limited effect -- it's still easier for support people to continue with their old habits.

Second, about that legacy code. One of our programmers (not one involved in creating some of the legacy code that has security problems, BTW) pointed out that in relatively recent times, the official "Microsoft way" to do things involved practices which today are recognized as requiring extremely lax security. So even teams that make every effort to do things the 'right way' (with MS) end up with insecure code (or rewriting lots of code).

sounds like quickbooks

[way2trivial]

there are ways to enable quickbooks by giving permissions on certain reg keys.. a major PITA

Quickbooks

[mfarver]

Intuit's Quickbooks requires local Administrator priviledge for some reason. This is exceptionally annoying becuase the finance folks in many businesses are the ones with just enough computer knowledge to be dangerous.

It is possible to get it to run without it, but it is less than fun:

http://www.sbslinks.com/lua2.htm

crappy hosptial ware

[engagebot]

Needing users to be local admins is turning out to be a pain.

Being at a hospital, we have TONS of specialized software. Every flippin department has their own contracted 3rd party stuff, and all of it sub-par software which requires users to be local admins.

I did figure out that they don't need to be admins for Citrix though. Just a permission change on a registry key (MSLicensing) and they're good to go. But jeez...

regmon and filemon are your friend

[arkarumba]

Use regmon and filemon from http://sysinternals.com/. Export log to CVS and use a spreadsheet to sort the far column and check out any ACCESS DENIED errors.

Windows Terminal Services

[arkarumba]

Perhaps run the app over RDP on a Windows Terminal Server. Place it behind a firewall that allows RDP through.

I won't pretend that it's simple to explain

[anomaly]

But there are some components of "the law" (broad term covering the old testament) which were civil or ceremonial in nature, others were moral, and some were universally appropriate to all cultures.

A good discussion of this can be found here:
http://www.tektonics.org/lp/lawrole.html

----- Begin from that page

If one then happens to ask, "On what basis do you then continue to say that these laws are still valid morally?" -- beyond the "all agree" level of things like murder, and in the category of things like homosexuality and adultery -- the answer is that when a superior writes a contract, even if you are not a party to it, the contract will still give you an idea what values the superior holds to. We no longer enforce the penalties, but we still know what actions displease God.

"Well, then, why aren't Christians out sacrificing animals and eating kosher?"

The reason is simple for this one: All of the ceremonial laws has been superseded by Christ.

----- End from that page
It's not a "pick and choose as we like" kind of thing, although many people believe that it is.

Regards,
Anomaly

Re:I won't pretend that it's simple to explain

[mooingyak]

Thank you. That is by far the most lucid response I've heard on the subject.

Care to violate HIPAA?

[Anonymous Coward]

I dare not name names, but I'm familiar with an Oracle-based Electronic Medical Records server that, in its default install on a vendor-supplied server, has:
* Scanned images and client installer in a share with share permission: everyone/full and file permission everyone/full
* No password required to install the client
* Requires all users to run as local admin on their workstation

Cutting back the file permissions to "domain users"/full typically has no bad operational effect.
Cutting back user permissions to run as a normal user on the workstation only affects quarterly client software updates... Once a quarter I have to touch every workstation as admin to upgrade the client app. (Aside from that, they don't even need to be a power user.)

Most clinics using this software do not have inhouse IT staff to fix the default settings. Break such a clinic's wireless security, and you have SMB access to all scanned images. (Like entire pre-EMR charts!) You can hit the database. You can install the database client. If you sniff or guess an oracle username/password combo, you've got that user's access level... and there's a hidden default support user built in that uses one of two default passwords and has full access to all records. I know these passwords, because their helpdesk told me once.

Too few secrets!

You are absolutely right

[LunaticTippy]

Every single place I've worked has lost more time/money/data to security measures than to breach of security.

Makes you think.

Re:You are absolutely right

[Steinfiend]

Being IT Manager for a financial company, I know what you are talking about. Users are always coming to me complaining about the complex passwords they have to remember, and the way they can only get to the systems when they are logged in locally, not from home or from a remote site. "Its not as if anyone has hacked in" they tell me.

And that is my vindication that the security measures are working. I would be worried if they had lost more time/money (data is debatable) to a breach than security measures. If someone loses 5 minutes of productivity because of a forgotten password then thats 5 more minutes than should, and has, ever been lost due to a breach.

LOL - Lexis Nexis

[Anonymous Coward]

Your comment would have been helpful had your lawyer's firm not been totally owned because the Lexis Nexis firm management software that they rely on works in exactly the same fashion.

Administrator privileges required on the workstation, sucks but common. Administrator privileges required on the server, totally ridiculous and unacceptable but, also increasingly common.

The moronic developers sales droids of these apps say; 'Oh, don't worry, we have security built into the application.' Translated, this means yet another directory for the admin to have to manage and yet another password for the users to remember or paste on their monitor. All this as opposed to integrating security into the existing enterprise directory(NDS, ADS, LDAP). But none of this "security" prevents the casual user from accidentally deleting the database file containing 5 years worth of mission critical business data! Or my favorite, dragging the .exe to their local desktop so that everyone else loses access to the app. Doh! LOL!!!

I remember way back in the "old days" of the mid 90's when Novell was used for the servers and applications came with a page or two of installation instructions for setting file access privileges for the apps. Read, File Scan, and Executable access for EXE's and DLL's. Modify and Delete Inhibit access to the data files. Create and Erase access for administrators only. Every app beyond shareware came like that. Then Microsoft came along and now nothing works with Everyone Full Control, Microsoft's default security setting.

That's not a fix at all

[WebCowboy]

Your "solution" of creating a separate, isolated domain for the offinding application is completely inappropriate. It reminds me of when the police did a crackdown on prostitution in a notorious inner-city neighbourhood in our city. On the surface they were very successful--hookers and Johns are dramatically less visible in "the beltline" now, and the developers are falling all over each other to buy out all the slumlords, tear down the decades-old shacks and put up shiny new executive condominiums.

In reality the crackdown was mostly a failure. It did nothing whatsoever to reduce prostitution or related organised crime. Prostitutes and their pimps just found another 'hood for a hangout. Unfortunately the new hangout was probably even less appropriate for that kind of activity than the old one: an older, working-class neighbouthood with significantly more children residing in the area than were present in the old strolls. Schoolgirls not even in high school waiting to cross the street are targeted by some Johns now and gang activity and drug trafficking are also growing at accelerated rates in the area.

Your proposing the electronic equivalent of simple chasing the hookers and pushers into another neighbourhood and it ignores the root problem: YOU STILL HAVE MAJOR SECURITY ISSUES--they are just slightly less limited in scope. If the offensive application is a mission-critical app it is still unacceptable:

* Disgruntled employees could use their domain admin rights to sabotage the system
* Unscrupulous users could use admin privleges to impersonate other users and compromise audit trails
* Incompetent users could accidentally damage or destroy the system with unlimited rights on the domain (erase the wrong files, alter configurations, etc).

A number of people have already suggested an answer to the question posed in the article: You don't "deal with" such a badly written application--you make the vendor fix it our do everything in your power to have it removed completely from your company, and when dealing with management you do not present a technical case beyond stating that the application presents "serious weaknesses in security", you present a BUSINESS case:

* taking measures to "work around" the seciruty risks will cost $x thousands to implement and $x thousans/year extra to maintain (don't need to mention firewalls, VPMs, separate domains etc or you'll lose them)

* taking measures to secure the bad application will mean it will not work as well (or not at all) with other business systems. This means wasted time and money because employees will have separate logins, have to enter information twice or manually copy data, etc (managers hate the idea of having to remember more than one login, and the big push in a lot of companies is to "integrate business systems" so suggesting that you have to move away from that goal will be convincing)

* even after taking all these measures, if your company is an American-based, publicly-traded company, YOU WOULD BE BREAKING THE LAW if you followed the vendors suggestions. Sarbanes-Oxley requires such companies to maintain proper audit trails and put in place adequate protections against circumventing such mechanisms. If an application requires administration rights of any kind there are NO protections of any kind against potential fraudulent manipulation of records. The same is true about shared logins, and both practices also violate regulations in healcare, food/beverage, and other industries as well.

There are bad applications and there are BAD applications. What the article described is unacceptable bad to the point that you do not try to "balance with security" or otherwise deal with it...your plan of action should be a plan to migrate very quickly AWAY from the app.

Does the application really need Domain Admin?

[botsmaster25]

Something like this happened at my work. An application required Domain Admin rights for its service account. When the vendor was pressed as to why they needed full read/write access rights to AD (schema changes, value changes, etc.) they also couldn't explain why. Their answer was that their install documentation said so.

When their SE was onsite to do the install I asked him again why his company's application needed Domain Admin rights he was able to give one reason. During the install the application did a one-time user account lookup on AD and then inserted the results into a SQL DB.

Thanks to AD's openess, any Domain User account can get that information. He was willing to try the install the application and test it as a Domain User and it ended up running fine.

Probably what happened with the application and probably what happened to the application you are running is that the devs have Domain Admin access on their dev environments and that ended up turning into a requirement as the application moved to QA and then to the customers. It was probably never tested with Domain User or no access to AD.

I recommend testing the application with less access and see if it still works.

You're welcome

[anomaly]

I don't pretend to have all of the anwers, but if you (or any other reader) has sincere questions about the Christian faith, I'd be honored to search for answers with you.

Christianity is the only world view that fully works, as far as I'm concerned.

For what it's worth, even as a devoted Christian there are things about Christianity that perplex me, but I have two comments about that:
1) There are far larger and far more questions related to *every* other world view I have examined, and

2) The big questions have been answered for me, and the ones that remain are less important. I can give God the benefit of the doubt in areas of lesser importance where I don't fully understand.

Regards,
Anomaly

Re:You're welcome

[mooingyak]

FWIW, while I don't share your beliefs (I'm more or less non-theistic), I've always been irritated by people who feel the need to be dismissive of those who are religious.

I've only casually looked at the material you've provided, but I intend to read more about it.

Been there!

[cerebralpc]

We are running a $75M government project and brought ourselves a simple issue tracking application that cost $800 bucks

It wasn't til I tried to get it hosted on our corporate servers ($1000/month) that we found out it requires admin rights on the server to run. Also the software requires the database and the web server have to be on the same machine.

After spending god knows how much money testing/configuring/getting 10 managers to sign a piece of paper we said TO HELL WITH THIS - and put the application on a server with one of our IT outsourcing companies.

Unfortunately there are too many options for bad design of applications - I wonder if it would be possible to have an framework or standard architecture that would sort these problems out?

Microsoft CRM 3.0 is awful

[lucm]

Recently I've been installing Microsoft CRM 3.0 for a customer, and I found the implementation guide quite puzzling.

Actual requirement: "You must be logged in with Domain Administrator and Local Administrator privileges when running Microsoft CRM Setup".

Also, two Active Directory requirements that look suspiciously mutually exclusive:
-Active Directory must be in native mode before you can install Microsoft CRM.
-For the Microsoft CRM servers to have access to Active Directory Organizational Units where users are located, you will add the following accounts to the Pre-Windows 2000 Compatible group in Active Directory: (various groups listed)

Other odd points:
-The computer name of the Microsoft SQL Server cannot contain an underscore (_)
-Microsoft CRM Server is supported only with a default instance of SQL Server. Named instances of SQL Server are not supported with Microsoft CRM.
-Microsoft CRM cannot access SQL Server with TCP/IP, only named pipes.
-The setup won't succeed if the "Error reporting" service is stopped. That is the service that is giving the "opportunity" to send error messages to Microsoft when something goes wrong.

This setup was looking very suspicious to me, so I prepared a risk assessment and required the customer to sign it before I installed the package.

Three simple words

[l0rd]

If you have any clout and people value your opinion you can just use three simple words:

"Not my responsibility"

Make clear to them that they shouldn't bitch and moan and should certainly not hold you accountable for problems arising from said software after you've given them adequete warning. It may seem drastic, but sometimes you have to have a firm hand with managers to help them lose bad habits ;-)

Two solutions that should work

[frankbenjones]

RunAS Pro - users don't have to know the password for admin/domain admin, etc. App runs with needed priv's: http://mast-computer.com/c_9-l_en.html I've used it to get a brain dead app used for Trust managment to run without giving users Domain Admin rights. Another option which I've not tried but looks very nice (and I'm sure is costly) is PolicyMaker from http://www.desktopstandard.com/ApplicationLevelSec urity.aspx Basically you tell management they must SPEND more money so that you can manage the app and can maintain security (keep everyone out of HR's stuff, accouting, etc). They just have to deal with it. Hopefully they're smart enough to spend the money on one of these solutions.