I work with a number of software and design agencies that host Software-as-a-Service solutions or other forms of web based applications. Part of what I do is assess how secure the application is, and how privacy may be affected. In performing these assessments, we dive in to how the application is put together, but also how it is secured from an infrastructure point of view. What I have found is that while companies are generally really good at taking security into consideration, the approaches to security are often out of date or based on bad advice. Here are three of the most frequent misconceptions I encounter.

Changing default ports

This is “security by obscurity”, and definitely will not deter an attacker. Often I’ll see RDP and SSH moved to different ports, which, while admirable, does little to increase security. When someone scans an external IP, chances are they’re going scan all the ports available. Depending on the type of scan that is run, it’ll often return the type of service that a port is running, regardless of the port number. So changing the number does nothing but slow an attacker down by a few minutes.

There are far better ways to secure your RDP or SSH access rather than relying on a changed port. VPNs, IP restrictions, bastion servers, certificate based sign-in, and multifactor authentication are better approaches here if you need to access remote management (or other services).

Monthly forced password resets

Frequent password resets for users is less effective than training people to implement strong passwords. If you have folks resetting passwords on a regular basis, they often resort to much less secure methods of password generation, simply appending a number or letter to the previous password, or some other easy to remember (and guess) approach.

Rather use secure password generation, coupled with a password manager like 1Password, Dashlane or LastPass. My passwords are generally around 20-30 characters long, and are unique to each service (thanks to 1Password). Another approach is to use passphrases. Pick four random words, and separate them by hashes, dashes or similar. This builds a really secure password that is easy to remember, yet incredibly difficult for a computer or hacker to break. Consider that “Baobab1Modem2Aircon3Hedge$” combines upper and lowercase letters, has special characters, has numbers, and is 26 characters long!

“Proof of Concept” / Sandbox / Test servers need less attention

In most cases, test servers (or proof of concept, sandbox, staging, development and any other plethora of non-production names) are not configured with the same security as a live server. The justification for this is often that it “only contains dummy data” or “the data is anonymised”.

The trouble is that the data is dummy data, until it’s not. Invariably I see situations where to test a bug, show off a new feature, or give a customer a temporary environment, live data is pushed through to test. If your test server is not as secured as your production environment, you’re running a tremendous risk. And hackers know this, it’s often much easier to attack a test server or backup environment than a full production server.

Ross G Saunders Consulting offers a number of solutions that can drive your compliance and security maturity; from affordable 16 week group coaching programmes to comply on your own, through to advisory retainers and full programme management. To find out more about the offerings available, book time directly with Ross using the calendar below.


Share This

Share this post with your friends!