In my line of work I deal with a lot of ridiculous bullshit, especially from customers and Jr. sys admins acting like they know the lay of the land because they read some article somewhere that provided some tidbit of information, automatically deeming them a security expert. I see the same level of ridiculousness from “experts” employed with other hosting and consultation companies that practice a one-size-fits-all concept across everything without actually understanding the underlying problem they are trying to solve or avoid. So I’ve taken the liberty of listing some examples of what I’m talking about so if you’re one of the people guilty of violating something on this list, you can appear smarter the next time you pretend to know what you’re talking about.
Something should be so secure it’s practically unusable
This is by far one of the biggest tug-of-war contest among system architects and engineers – balancing usability vs. security. Any time you’re dealing with a system that is accessed by end users, plugged into a network, or nevertheless powered on, you’ve already decreased the security of that system.
One thing that certainly needs to be managed is the weight of what is insecure vs. how valuable it is. I’ll use FTP as an example. FTP is the most commonly-used methods for customers to transfer files to and from a server. Yes, there are better and more secure ways to do this. Do you expect most customers to understand that? No. You close FTP access, the customer gets frustrated at the idea of having to learn something new, and they go to another host. While FTP is in general considered to be insecure, on a properly-configured system, the security impact would typically be limited to that user alone. So their FTP account gets hacked, shit gets uploaded to their account, you remove it, shame the user for using “xxxporn” as their password, and life goes on.
To further my point, let’s say you have a mail server where both secure and insecure POP access, but your SSL certificate is set up incorrectly for the service thus causing customers to get certificate warnings in their mail clients ever time they open it up. After a certain amount of time, the customer is going to get annoyed and likely switch back to using a non-SSL to not have to deal with it any more. So the attempt to make something more secure was negated by the inability to use the service, causing the customer to instead choose something insecure.
PCI compliance actually means something
There are issues with PCI compliance that vendors are not necessarily going to share, but I will. PCI compliance, in many aspects, is a joke. You go along with it because your credit card processing company forces you to, and then passing the scan gives you some sort of feeling of accomplishment that your server or website is oh so secure. I certainly appreciate the effort though, because without it, you’ see banks running a Jooml1 1.5 backend over PHP 4. The purpose of said compliance is often misunderstood and over-credited, however. The concept was created by a council established to protect payment processing companies against fraud, by means of establishing some sort of security standards and baselines for companies using their services. For example, if you’re accepting credit card information on your website, the merchant processing those payments probably requires you to pass a PCI scan to help protect themselves against loss. So while PCI compliance then becomes a requirement, it certainly is not a means of verifying security. No server is 100% secure unless it is turned off, and no service is able to accurately claim that it is in fact secure – this includes PCI scans, which perform a number of scripted and predictable tests to check for certain conditions that could be cause for concern. With that in mind, sometimes these tests are inaccurate or allow you to bypass certain requirements with adequate justification. So while you may pass a PCI scan, it doesn’t mean that your server and/or website applications are secure. It just means that some third-party scanner wasn’t able to find anything wrong.
SSL certificates make your stuff secure
It’s important to understand what an SSL certificate actually does and what role it plays in the security of a website and other services that may use one. SSL certificates are used to encrypt data transmitted between systems, for example, when you fill out a form on a website to transmit the data in that form to the server. This does not mean that a website using SSL is inherently secure. It can still be vulnerable to any number of exploits that exist on the server, network, the website’s application, or even the SSL protocol itself.
“Security through Obscurity”
I’m not sure I’ve ever heard of a more ridiculous concept. Generally speaking, you shouldn’t make it a point to expose sensitive information, thus making some level of obscurity necessary. However, if the exposure of certain information would lead to a security breach, you should be addressing the possibility of said breach rather than spending time trying to hide avenues for it to occur. Hiding information may be a good idea in some cases, but should not be considered a security measure regardless of any other measures you have in place. I’ve never met a qualified security professional that considers obscurity to be an acceptable means of securing information.
You can just set and forget
As a Sr. Architect and owner of my own server consulting business, I see frequent cases where a company will not want to pay for managed services, so will instead purchase a “one-time” server setup or security audit service, never to be heard from again until they have a security incident and accuse you of not doing your job right the first time. Security is a process, not a task or a project.
“Well, no one would ever think of that”
When I first started working at my first hosting company, one of the previous admins had a firm belief that disabling things like wget and SSH would make any sort of noticeable difference in security. Guess what? Shit was still happening. And it was because we seemed to be under the assumption that hackers didn’t know how to use things like cURL or lynx. Not only that, but customers who needed to use these tools would have issues and we’d have to create ugly workarounds. Eventually it was determined that the concept of slowing a hacker down from an inevitable action was not worth it. Don’t assume that even script kiddies are idiots – either close the access, or find a better way to secure it.
So, to conclude, security is a complex web of logic that not everyone is qualified to specialize in, regardless of their level of technical or field knowledge.