Software vendors can be really knowledgable, helpful and a pleasure to work with. As with any professional community though, there are those who let the collective down with a lack of knowledge, communication skills or common sense. Here are some of the classic queries I have had from vendors and consultants over the years, and the best way to deal with them.
“Our application requires sysadmin privilege on the database server to work properly”
I’ve brought up this point first because it is by far the most common I have come across over the years. The answer is simple, NO application should require sysadmin. Even the most poorly coded application should only need dbowner privilege on its own database at a very push, and even then it’s not ideal from a security perspective.
If you receive this query, I implore you to refuse the request and ask them to provide the actual required privileges. Ask them to escalate it to their developers if need be. You’d be surprised how few permissions the application usually needs to function.
Requiring sysadmin is one of those things that should raise a red flag instantly. I’d seriously question the competence of the vendor if they continue to insist this point. Even if the database server instance is dedicated to the application, secure it. It’s the smaller database installations that tend to get breached first, and their application probably stores your users’ passwords in there. Probably the same password they use to log on to every system in your network.
“Our application HAS to use that database password” or “We can only use the SA account on the database server”
Don’t let vendors dictate the password or user account used to access your database server. Using a generic password for all installations, or requiring the SA password on your SQL box just isn’t cricket. It just shows complete incompetence of the vendor and / or the developers.
Enforce your password policy on them just like any other service account. There is no excuse they can give for not being able to accommodate it except shear laziness.
Even if the database server instance runs locally on the application server, enforce password policy. The vast majority of breaches involve a leaked password, and the vast majority of those are default passwords.
“We support virtualisation. Just plug this license dongle into one of your hosts”
Just no. If software needs a license dongle, it doesn’t support virtualisation. Granted, the application will run, but the major selling point of virtualisation is high availability, which fails the second the host with the dongle plugged in goes down for any reason.
Unfortunately there isn’t much that can be done about his problem. Just make sure you communicate to your company that all that metal they bought to support HA, can’t protect the seriously outdated software that still relies on an archaic licensing technology.
“We need XX amount of RAM for the application, even though its virtualised”
In rare occasions this statement is true. The vast majority of the time though most applications don’t need 48GB of RAM assigned to the virtual server that runs a simple service.
As a general rule of thumb, a VM actually uses a fraction of the memory allocated, filling the rest with cached data that it never accesses. Check your VM performance charts for memory and you’ll see the active memory usage.
I generally kick back on the consultant / vendor to produce some sizing reports based on our companies projected usage. If in doubt, or they won’t supply the information, I allocate the memory as requested, but gradually reduce the amount allocated during maintenance windows to find the “happy medium” between performance and wasted memory allocation.
“We only support remote support via [insert free remote access services here].”
Just say no. I’ve lost count of how many times a consultant or vendor has tried to install some agent based remote access technology like Logmein or TeamViewer on a server. Don’t allow it. The last thing you want is an agent based remote access service tied to your vendors remote access service running inside your network.
Imagine if the vendor decided to fire one of their helpdesk engineer, who has the username and password to their logmein account? It’s not worth thinking about.
The best way to deal with this is to provide your own method of remote access to your server, with an account you control. Then write a policy that you make vendors sign before allowing access. It might seem like more work for you, but it’s a much more secure arrangement than most of the options provided by the vendor.
This solution doesn’t have to be complicated or expensive. You could use Microsoft’s Remote Desktop Gateway for example, which is a role of windows Server so doesn’t cost anything to use (providing you have enough server licenses of course).
“We don’t support HTTPS”
Sack them off immediately. Any software that doesn’t support he most basic security protocols like HTTPS, doesn’t belong in enterprise IT.
What they usually mean is they don’t know how to enable HTTPS in IIS, Apache or Nginx. Do you want to use an application developed by a company who don’t know the technology their application runs on? Nope.
“We can’t resolve your email server at address (192.168.20.3 ) Can’t you take a look?”
This isn’t a common one to be fair. I only recently came across it. For starters it’s an IP address and doesn’t need to be resolved. Secondly you have a space in it, which probably means your application is treating it as a string and trying to resolve it in DNS, thus causing your problem.
This point nudges back at that common sense (or lack of) I mentioned earlier. It amazes me when we pay tens of thousands for consultants, and they struggle with even the simplest of everyday administrative tasks.
I know this post is a bit of a rant. It was meant to be to be fair. I also know I paint a bad picture of software vendors and consultants, so I should probably point out that not all vendors, consultants or helpdesk engineers are cut from the same mould. Some of the vendors I have dealt with have been excellent and great to work with. Unfortunately it’s the bad ones that burn experiences into your memory, and not the ones you can just rely on to do a good job.
One thing I have taken away from my experiences is not to allow vendors or consultants to do what they want, and don’t let them back you into a corner when it comes to best practise or security. At the end of the day, it’s your desk your boss will be standing over when shit hits the fan.
Unfortunately we will never eradicate bad vendors or consultants, because they are the ones that don’t mind bullshitting your executives and project managers to win the work. Thats just the way enterprise software goes, so embrace it, and enjoy making them look like idiots when they CC the world into an email conversation, trying to blame their poor performance on you, your department or your infrastructure.