Protecting Your Enterprise Network from Vendor App Servers?

anomaly wonders: "I work for a company with a large IT infrastructure. We have lots of applications in our environment. For a number of applications, vendors provide the apps, and provide core support to those app servers. Our vendors are notorious for demanding superuser access to the boxes that support their applications. To protect our enterprise network from attacks allowed in by well-meaning but less-than-perfectly-competent vendors, we have set up a quarantined network for each vendor. This works well when the model is ASP-like and all of the components live on a single box, but fails when the application needs to be connected to one or more enterprise applications (RDBMS, smtp, they want backup, etc) or when it needs to be connected to lots of target systems inside our environment on lots of different ports. How can I restrict a vendor/application server's access to our enterprise network while still providing platforms to make the applications productive for our user community?" "Frequently vendors can't restrict their applications to run on a limited set of ports. Most of the time they stare blankly when we want their application to run as something less than superuser.

Our biggest challenge is keeping track of all of the dependencies and managing what ports need to be allowed to which destinations. Of course, when security is tight our business-types say 'you're breaking my application.'

What can you suggest about how to provide access to applications, patch/protect the OS on the app server, and protect the enterprise network? What does your organization do?"

Comments

Layer 7 Firewall

[passthecrackpipe]

You need a Layer 7 Firewall, a.k.a. an application level firewall. Something like Zorp is a good start, but you probably need something with a bit more intelligence about the applications you are talking about though.

L7 Firewalls usually get a bad rap because they tend to be pretty fussy in setup, something you can't really avoind with this kind of stuff. Also, if I was in your shoes, I would learn to stop worrying and start loving tight-ass SLA's...

Tell them to screw off..

[Heem]

Seriously.

I built a network for vendor lab equipment that was it's own netowrk, connected to the main network via a file server with 2 nics and NO routing. Therefore, file could be transfered from the lab network to the file server, and then from there to any of the main networks, of course after they had been scanned for viruses and such, since anti virus software usually would not run on their equipment. My rules were firm and backed by higher-ups - if you couldnt get your equipment to work in the enivroment given, or with only minimal flexibility from me (for example i'd write scripts to move their files automatically to the main, backed up network or something simple like that) - then we will find another vendor to provide us a solution that fits. Period. I never had any problem with a vendor once they heard the terms. They won't make money off us if they can't make the system work in our environment.

Switch vendors

[31415926535897]

Our vendors are notorious for demanding superuser access to the boxes that support their applications.

There are a few things you can do in this case:
1. Get a different vendor (if the application truly does require su for vendor support).
2. Reqest different support staff from the vendor (do this if the app doesn't require su but the support staff is too lazy).
3. Learn how to support the app in-house

I am very serious on these points. You do not want to give root access to people that should not need it. If they say they need it, they have an awful application.

The place I work has a vendor area fenced off from the rest of the server room, and the vendors only have access to what they need. If they need more privileges, the IT guys watch them like a hawk until they're done.

I go through this all of the time

[flying_monkies]

From the vender side.

First: It's amazing how many people haven't got a CLUE. "Don't give it to them or get another vender" isn't an option. When you're running a 24x7x365 system and expect sub 1 hour response time from your venders (our customers do) you're going to have to give some.

All of the boxes we hook up have phone lines into them. If security is an issue on dial-in access, we set it up as follows:

Modem is enabled dial-out only, no dial in access.
If the box dials home, we contact the administrator, identify who we are and which box has troubles and have them enable access to the server/hardware and reset the root password temporarily on the box. This occurs only if it's something we haven't already configured to work with sudo.
We then keep logs of the entire session, then email it to the customer when we're done.
When we're done, we have them reset the root password and disable dial-in on the modem again.
If we require access to a network resource from the machine, we're onsite with the customer shoulder surfing.

We do this at secure military sites, financial institutions, etc. and have yet to have an issue in 20 years.