8 Ways to Improve Internet Performance With Better Security

July 17, 2015 Andrew Sullivan

If you are outsourcing any part of your infrastructure, you can't think of the security of the service as a "set-it-and-forget-it" matter. 

Your vendor's main priority is to keep their service running, not to ensure perfect security, and they might make decisions that reduce their support call burden, but also increase security risks.

Here are some things you can do.  Most of these will seem like common sense, but you'd be surprised how often they're overlooked.

1. When evaluating a vendor, find out whether they use or permit obsolete technologies like SSLv3 or RC4.

If so, raise it with them. For example, SSLv3 is now officially deprecated by the Internet Engineering Task Force, and it's known to be compromised.  For the most part, you need to treat your vendor's security policies as something you inherit, and if you can't find out what they are you can't do anything about them.

2. If multi-factor or multi-stage authentication is available to you in the service, use it.  

Weak passwords remain the easiest way to attack a service.

If your attacker can take over the administration of your domain name at your registrar, for instance, then your entire online presence is in the hands of someone else.

3. Speaking of weak passwords, you need strong ones.

In general, a longer password is better.  Numbers, capital letters, special symbols, and so on help, but a short password is just easier to recover. It goes without saying that you should also check how your vendor stores these things. If the vendor can send you the password itself, that means they're storing the password in a recoverable way. If your vendor can get the password, so can an attacker who obtains your vendor's database.  Find another vendor.

4. For the same reason, don't re-use passwords across accounts.

This prevents the takeover of one account from turning into the takeover of several.  Also, avoid the use of shared accounts whenever possible: if multiple people are using the same account, you can't audit who is initiating action.

5. Get a baseline of normal behaviour, and audit your logs.

Nothing is worse than those reports that keep emerging of companies that have been subverted for ages and can't say how long they have had a problem.  Regular audits will at least allow you to contain damage if it happens, and you might detect an attacker before the attacker has actually done any real damage.

6. Good defense is a defense in depth.

Don't assume that a firewall is going to protect everything on your network.  Firewalls can be penetrated and accounts can be recovered.  "Internal" systems that are themselves vulnerable represent a vulnerability to everything else, even if you think nobody can get to them.

7. Never retain data about your users if you are not sure you need it.

The computing power available today and the availability of lots of compromised databases means that even small amounts of user data can be put together with those other databases to build profiles of your users.  You don't want data you retained but didn't need to contribute to identity fraud against your own users.

8. Finally, make sure your security policies are sane and realistic.

If the policies are too strict and make people's jobs harder to do, your staff will just circumvent them.  Everyone needs to understand the reasons for a policy, the consequences of not following it, and the justification for how that policy helps the business.  Buy-in and consistency are important, because if everyone knows what "normal" looks like, they will notice the abnormal and you'll catch a problem before it gets out of hand.

About the Author

Andrew Sullivan

Andrew Sullivan is the Director of Architecture for Dyn, a cloud-based Internet Performance company that helps companies monitor, control, and optimize online infrastructure for an exceptional end-user experience. Follow us and like us to get involved in the conversation.

More Content by Andrew Sullivan
Previous Article
Protocols, the IETF, and Dyn
Protocols, the IETF, and Dyn

Matt Larson explains the Internet Engineer Task Force and how Dyn is involved.

Next Article
INFOGRAPHIC: The Importance of Having a Business Continuity Plan
INFOGRAPHIC: The Importance of Having a Business Continuity Plan

Check out how brands like Acura, Coke, Realtor.com and more all experienced headline-worthy outages. What w...