The S**t Software Vendors Say

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.

Conclusion

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.

Laziness, Ingorance & Stupidity Make The Internet Miserable

The internet is an incredible thing. When you really think about how it works, this massive, ever-expanding network of devices all talking to each other is astounding. Like a knife though, it’s both a very useful tool AND very dangerous weapon.

Everything is connected to the internet now and consumers are far too trusting in technologies to make their life easier. What they fail to notice, or indeed care about, are the security flaws in the kettle they can control from their smart phone. Technology companies actively exploit this unearned trust to peddle more cheaply developed crap into the homes of consumers.

What consumers probably don’t realise is that the CCTV camera systems, video door bell, or cheap “smart” light bulbs connected to their wi-fi are incredibly insecure. They are probably a part of a botnet, designed specifically to target Internet of Things devices with known hardcoded passwords or vulnerabilities.  Then they complain when Playstation Network or Xbox Live is offline due to a huge DDoS attack, orchestrated by a douche bag somewhere, commanding their CCTV cameras, video door bell and “smart” lightbulbs to flood the servers hosting the gaming platforms with garbage data.

Of course having your CCTV system used in a botnet to bring down services on the internet isn’t worse case scenario to most people. What about the creepy guy sitting in his stained Y fronts in front of his old CRT monitor with his box of cleanex, watching you sunbathe in your bikini on your own CCTV cameras? Or watching what you and your better half get up to on the sofa via your internet connected, smartphone controlled nanny cam, while the kids spend the night at their grand parents house. Worrying isn’t it?

So who’s to blame for the situation the internet is in at the minute? Is it the hackers? The technology companies? The consumers? In my opinion it’s all of the above.

The hackers are a diverse cross-section of society. Some of them hack people for financial gain, some for fun and some just to be A holes and show off to their friends.

The consumers need to stop looking for the easy solution, and start thinking about the effect their cheap, insecure devices have on their privacy, their neighbour’s privacy, and the impact on the rest of the world. After all, if your CCTV camera is part of a botnet that targets services as big as PSN, you’re partially responsible for the inconvenience caused to millions of people around the world, all because you didn’t change the password to something other that “password” when you set your new gadget up.

Technology companies don’t do enough to secure their products. Don’t get me wrong. I am well aware that some vulnerabilities in devices arise from vulnerabilities found in widely used services and protocols, such as SSL. The main boggle I have with the technology companies is when they release devices with the obvious and simple weaknesses built-in for the convenience of either the consumer or technical support. Things like hard-coded passwords and wi-fi passwords stored in plaintext in configuration files on devices. These shortfalls in security just play right into the hands of the hackers and make their life easy. They are also inexcusable.

I personally believe the problem is only going to get worse unless the technology companies step up the mark and actually start designing products with security in mind. People might say Apple are obnoxious, self-righteous pricks for locking their HomeKit system down and preventing smaller manufacturers from entering the eco system unless they pay apple for the privilege. In reality though, at least they are bothering to do something to try to address the security issues.

The whole top and bottom of the problem is, consumers are ignorant, technology companies are lazy and hackers are stupid. I say stop making product setup workflows as easy as possible and guide consumers through the process of securing their new gadgets by adding steps like mandatory password changes into devices during the setup process. If the technology companies made the effort, and consumers made the effort, then maybe at least some of the script kiddies out there would give up because of the extra effort involved in continuing to make people’s lives miserable.