Slashdot Mirror
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?"
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?"
Only give temporary access to allow agreed changes to take place. Superuser isn't required to diagnose problems, only to fix them. This also gives some stability as 3rd parties don't enter and alter things as they please.
The disadvantage is that there is an operational overhead -- but then there should be because if its a pain to change things then less gets changed.
What can you suggest?
Find some better vendors?
I have a similar configuration between two in house networks I use the firebox X700 in routing mode it allows me to open only the ports needed to be routed between the networks and also allows me to monitor all traffic to keep an eye on the test network side.
I have to agree. There's very little need for a vendor with a good-working product to have to have that kind of anytime access into your network and servers. And with nebulous new legal requirements like HIPAA (for medical companies) and Sarbanes-Oxley (which the government doesn't even know what it means yet) giving such access to vendors could give you serious trouble in an audit, even with the requisite NDAs and various contracts.
So, my advice is also to not do it. A vendor needs access to repair/upgrade a system? Arrange for a once-off remote access solution (like WebEx or something for Windows boxes) in a situation where you have control of the access and can monitor them. We had a vendor one time get real whiney about not having on-demand remote access into our system, but we put out foot down and they dealt with it. The reality is that you're the customer, and it's their job to adapt to your situation.
No, he just knows how to actually do the job he's being paid for. Once you graduate high school and eventually enter the *real* world of IT, you might understand this.
-- Lee K. Gleason, VMS sysadmin
Disclaimer: The opinions expressed are not necessarily my own, as I've not yet had my medication today.
With the internet and remote admin tools coming / have come to full potential, vendors keep coming to ask for this more and more.
:: Speed on Highway and Number and Color of Cars traveling in pack/line. Some great laughs later over some good wine.
I have been a software vendor for many years. With software that is correctly build and tested, the need have access to a forgien box is about 0.
That is not say that there were not times I wished I had access. Mainly language translation, English-French with neither tech being able to speak the other and a translator that did not understand techincal terms. Think Baud Rate and Partity Bit
Even when I went on site, I generally never touched a machine. I always had the local operator or manager do the actual typing. This way, they learned the what and how along with me, and how to fix it.
But back to today's world, IF and I MEAN IF the higher levels of company force/black mail you into a corner , setup a connection PC. Vendor connects to there, and that is terminal of them in your system. Log every thing. Turn off the PC when you can not be watching what happening.
When the only alternative to required software is working by hand (or a major reverse-engineering project), you just gotta suck it up and figure out how to protect the rest of your systems from their arrogance.
Generally speaking, it's a clear sign of laziness or incompetence on the part of a half-assed programmer to think he needs root for everything. Hell, Oracle doesn't need root to run, and it's a mighty damned complicated RDBMS suite. If you're stuck with one of these vendors, I urge you to make it clear to them that you are using their software because you are stuck with it, that given the chance you will jump ship in a heartbeat, and that the reason you'll never buy any of their other products is that their claim to "need" root is a sign of either ineptitude or a cavalier attitude towards their customers.
This is not my sandwich.
I work at for a large government contractor, where root privilage is truely guarded to only those who need to know as there is data that absolutely need to be protected. Allowing random people from random companies access is not an option. It is actually a criminal offense to let someone else use your account who does not also have an account on the system (it is still a security violation even if they do have an account and is possibly subject to disciplanary action, up to and including criminal punishment depending on what it was being used for).
Basically, the only people who have root are the actual system administrators. And that is even locked down in the sense that we are supposed to log in with our regular account first and "su" to root, or otherwise need to call up security and let them know what system you need to log into directly as root (login and audit logs are checked on a regular basis for any discrepencies).
Basically, like I said, if they need root, they go thru one of us to do something.
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
As one of those vendors for governments, I have to constantly deal with some moron admins who refuse to give me any access to the machine, yet CONSTANTLY call for support.
I don't generally need superuser access on the machine, since generally the only thing that gets screwed up is the data in the RDBMS (you know, user error).
I had one propellerhead go around in my database deleting tables and columns he felt they didn't need. He told me on the phone "we don't use timestamps here". One of those slam your head on the desk conversations. These are civil servants with lifetime jobs, and maybe they knew all about VAX in 1970, but goddamn if they aren't dense.
They tend to think that RAID is a magical "never need to backup ever" solution. I just love it when they call me up after their second RAID-5 drive failed, and I ask them when they last did a backup - and they go "uhhhh we don't need to backup we gots RAID".
Then I explain how RAID has nothing to do with archival or backups, etc, etc.. And I pull out the backup I made last time they had a major upgrade and tell them they have to reenter every parking ticket for the last 8 months, and they threaten and bitch how it's my fault and I tell them I'm not their admin, and if they really want to go to their bosses and fess up how incompetent they are they can go ahead.
Frankly, I'd love for some more competent clients. Of all of them, I can think of one who has any clue what to do with a computer.
But then sometimes they call with a problem that requires fixing on the machine. I'm not going to sit on the phone talking them through shit, I'm not going to email them scripts or code, etc. More than once I've had to tell them that if they don't give me access it wont get fixed.
If it's a problem for you, give them superuser rights when they need it, when they're done doing maintainance, take it away.
I don't need no instructions to know how to rock!!!!
1. Smaller niche vendors usually don't have the hardware or manpower to simulate your system. You went with them because they were half the price of dealing with IBM, remember? :)
2. Often, those applications that require Superuser for the installation are third party applications. Install it yourself. You may have more trouble on the outset, but you'll know what's going on with your machine.
3. Often, vendors have their programmers as installers. The bad news is that you see the problems you do with the installations. The good news is that they'll know exactly why they need root - and they'll tell you what they need done. This might need to be a tag team installation, of course.
4. Remember, you can always invite them up there if you want to pay them for their time. Remote access is requested because it's cheaper. Alternatively, put in the contract that you want installation instructions. It will take more time, but you're always welcome to pay more.
Many of these vendor problems are reduced to cost-cutting measures. If you want to pay more, then vendors will be willing to oblige.
Your vendors can already run arbitrary code on your systems. You must trust them.
The standard practice of firewalls to restrict access, and lower priviledge accounts are all good (and important). But the proper protection should have been negotiated into the service contract in terms of access the vendor requires and liability. Durring that negotiation process the technical authority should have considered the security concerns (and added costs). If the technical authority was inept the best you can do is minimize the risks now, and use this example to raise security concerns for the next contracts.
If you already have a Junipers in the shop, I'm guessing it is a sizeable network. Even if they are just M5's. (I'm assuming you don't have the new J-series boxes, and are already looking at replacing them).
You probably need to do some serious lab testing before considering replacing a $40K+ router including lots of custom ASIC backed routing functionallity, lots of well tested protocol support, extensive measurement data, and good redundancy features with a commodity PC and some Ethernet NICs.