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.

[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 :)

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

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

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

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.

Very easily fixed

[Anonymous Coward]

Put the application in its own domain.

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.

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: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:sudo

[wolverine1999]

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

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.

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.