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

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.

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.

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.

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.

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.

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