51 Things You Need to Stop Doing Now

Here’s a list of 51 things you need to stop doing NOW. Parse this list, and if anything on it lines up with how things are done in your environment, stop it. Trust me on this. Each and every one of these things is bad, wrong, or even dangerous, and while it may seem like the simple thing to do right now, it is going to cost you much more in the long term.

1. Using default passwords

It takes 10 seconds to change the password on any device. Do it, or don’t be surprised when someone owns your access points, or your printers start to display “Insert Coins to Continue…”

2. Using password policies that are either too strong or too weak

Password length, complexity, and expiration requirements should strike a balance between security and functionality. A password that must be changed every 30 days is probably excessive, and will lead to admins ticking the box so their password never expires. Not requiring complexity makes it trivial to brute force or crack using simple dictionary methods. You should neither assume you won’t be a target, nor think you work for the NSA when setting the password policy for your users.

3. Forcing password patterns

Randomness is good… forced patterns are bad. Users can come up with memorable passwords that are complex with just a little coaching, but even seasoned admins will have trouble remembering a password that MUST start with a Capital letter, be exactly eight characters long, and end with a punctuation mark.

4. Preventing users from using their email address as their account

If you provide services to customers, be they enterprise or consumer, and your customers need to create an account with a username, let them use their email address. It’s unique, it’s memorable, and it takes away the problem you will have of maintaining uniqueness and processing all those “forgot my username” clicks.

5. Using shared accounts

More often than not, I see admins sharing one main super user account. All the admins know the password and they use it regularly. Where’s the individual accountability with that approach? I’ll tell you where… Elvis has left the building. Each admin should have a regular account, a separate and unique admin account, and the Administrator/Root/Admin/Supervisor account should be locked in the safe for emergencies only.

6. Giving end users admin rights

Stop it. Stop it right now. Use software deployment solutions so they can get the extra applications they need, and don’t buy apps that require regular users to have admin rights.

7. Taking away rights from admins

At the same time, don’t lock down things so tightly that your admins cannot do their own jobs. All that does is make these people come up with “creative” ways to do their work and, trust me, they will find ways around what you have done. This invalidates your security, and leads to both disdain and distrust.

8. Changing defaults for no good reason

Defaults are there for a reason… the vendor thinks that they will work for most customers in most situations. If you have a good reason to change a default, then do it, but don’t start changing stuff without evaluating and testing the change in your environment.

9. Thinking that ticking more boxes makes you more secure

Security is not improved by clicking extra settings. There may be plenty of settings you want to make to help tighten things up but don’t just start making changes on the basis of more is better.

10. Using superfluous characters in naming

Why do you put hyphens and underscores and periods and leading zeroes in names if you are not going to actually use them? It doesn’t help with readability, but it does add to confusion. If you are going to verbally refer to a server as Exchange1 then name it “exchange1” and not “s-exch-01_virt”. Even worse, I once worked with a customer who made UPN “first.last” but made sAMAccountName “first-last” for absolutely no good reason. If you must have a separator, pick one character and stick with it.

11. Not enforcing standards

Set standards, use standards and enforce standards. That goes for everything from hardware configurations to user account creation to operating system deployments. Standards are good… consistency makes it much easier to administer and to troubleshoot. When someone goes off-script, it just makes it harder for someone else later to deal with.

12. Deploying unsupported configurations

Sure, you can deploy a system in a way that is not supported by the vendor. You can also drive north in the southbound lane. Sooner or later both decisions are going to bite you. If a vendor says something is not supported, it’s not because it can’t be done. It’s because other customers have tried that, failed to get it to work, and had extremely long and drawn out troubles getting things to work. Learn from their mistakes and avoid unsupported configurations.

13. Blindly applying hardening guides

Lots of really smart people produce hardening guidelines, and almost all have their merits. But these hardening guidelines are built around specific use cases and scenarios. The hardening guide someone published for individual server roles running Exchange 2007 SP2 is not something you can just apply to a multi-role Exchange 2010 SP3 server. They are different products deployed for different purposes, and trying to make a guide for an internal only system fit an Internet facing system is only going to break things.

14. Setting small system drives

Disks are cheap, and operating systems manufacturers know it. If you are deploying Windows servers with a standard 40GB C: drive, you’re going to run out of space. Don’t be that guy.

15. Deploying systems without scanning them

Before any system gets into production, it should be scanned to ensure it is fully patched, antivirus is running, backup agent is installed, and both operating system and apps are all configured per your standards. If you aren’t confirming systems meet your standards before deployment, you could be facing interesting times ahead.

16. Deploying systems with a single point of failure

Redundancy means never having to take a call at 2:00 in the morning. All systems crash at some point in time, and single point of failure systems leave you high and dry. RAID drives, clustered or load balanced systems, UPS systems, disaster recovery or secondary datacenters, and other redundancies mean that when bad things happen, users and customers aren’t left hanging while you scramble to recover.

17. Not monitoring systems

Which is better? Your phone alerts you to a system running out of space, or your boss calling you to ask why the application won’t let him save because it’s full. Exactly; there are so many monitoring solutions out there, from on-premises to cloud-based solutions, that there is no reason why companies of any size cannot have monitoring in place for their critical systems.

18. Using HOSTS files to get around broken DNS

HOSTS files server two purposes… to troubleshoot issues and to provide name resolution for systems that cannot use DNS. If you are using HOSTS files for anything else, such as to resolve a problem within DNS, they you are doing it wrong.

19. Patching without testing

Sometimes good patches do bad things. Deploying a patch without testing it first is just asking for trouble.

20. Not patching

But that is not to say that you should not patch. By the time a patch is available, you should just assume someone else is working on an exploit. Patching all of your systems is a critical part of security, and should just be considered a normal part of your job.

21. Patching in the middle of the night

But patching in the middle of the night is just wrong. See the item above about redundancy, and then you can do patching during the day without impacting users. Patching at 2:00 Saturday morning is bad for several reasons, not the least of which is someone has to stay up all night to do that patching. What if something goes wrong? No one else is around and awake to assist. If the vendor does offer 24×7 support, you can bet that it’s a skeleton crew, possibly not their senior support people, and someone else is already called into the queue. The best time to patch is early Friday morning. It’s not that much of an impact to your team, most of whom will be awake and even in the office shortly; the vendor will be fully staffed shortly after you start; and Fridays are usually slow around the office in case there is user impact.

22. Manual patching

Why are you doing things the hard way? Patch management applications let you patch 100 servers with about as much effort as manually patching one. They also let you test, document and, when required, revert patches.

23. Making changes in production

We all are guilty of this, and it’s usually because what we are changing shouldn’t have caused a problem. Stop making changes in production unless you have first tested them to be sure there are no surprises.

24. Making changes without documentation

I know, we all hate documentation, but we all have to do it. And we have to do it with enough detail that someone coming behind you can figure out what you did.

25. Using a change control process that takes longer than the change

Change control processes and documentation are both absolutely necessary, but if it takes longer to fill out the ticket and submit the request than to do the actual change, you have a bad system. Change control should be quick and easy to comply with-not a burden admins look to avoid.

26. Supporting legacy

Stop it. Stop it right now. If that system is no longer supported by the vendor, requires you to use a five year old version of a browser, or is holding you back from upgrading to the current operating system, it’s time to put it out to pasture. Identify those legacy systems, put a sunset date on them not more than another year out, and start doing whatever it takes to replace them. I had a customer who was keeping all their users on Windows XP and IE6 because one financial app that only a handful of their users even need was so old, it wouldn’t work with anything else. Imagine hundreds of users on old, vulnerable platforms because ten users needed an app. If you can’t do anything else, consider virtualizing the system or the client components to at least get users’ mainstream systems up-to-date.

27. Not planning for the next version

The other side of the coin with legacy is that new versions come out, and eventually you will start to use them. I’m not saying that you should be putting all your users on Windows 8.1 right now (well, you should, but I won’t say that) but since you know new machines you buy starting soon will come with that preinstalled, you should start your planning and evaluation as soon as you can so that you can start to phase in new things once they become mainstream.

28. Using single layers of defense

Using only a firewall to protect your company from Internet threats is foolhardy. Counting on antivirus installed on the desktop to protect users from email-transmitted malware is too. Defense in depth, or layered security, uses multiple safeguards to reduce the risk. No single product is infallible.

29. Using a firewall to control Internet egress

If you are using a blacklist of IP addresses to keep your users from visiting bad places, you’re doing it wrong. A firewall is a port based filter, and you should use it to keep them from sending SMTP traffic from non-mail servers, or making outbound NetBIOS connections, but if you need to protect your users from the Internet (and you do) then you need to use Internet filtering solutions like a proxy server that can analyze URLs and actual content, not just what ports are in use.

30. Only using a firewall to control Internet ingress

A firewall in front of a web server has to allow TCP 80 in from the Internet. Guess what port ALL attacks against vulnerable websites use? A firewall should be one layer of defense, blocking inbound traffic to ports that are not approved for exposure, but the real work of securing the website needs to happen on the webserver itself.

31. Ignoring the cloud

I know, I know, I still think coming down from the trees was a bad idea and the Internet is just a fad. But what if I am wrong? “The Cloud” is today what “the Web” was back in the mid-nineties, and if you are not yet looking into it, you are way behind my friend. Whether it is right or wrong for your company today, you still need to be aware of it, because that is where all the action is and will continue to be for years to come. It’s the next big thing.

32. Ignoring IPv6

If you are not using IPv6 internally now, and if you are not asking your service provider every month when they will be able to provision you with an IPv6 connection, you are once again behind the curve.

33. Using cleartext protocols

Whether you are using telnet to configure your routers or IMAP to fetch your mail, you are exchanging traffic that is trivially easy for others to intercept and read. HTTP is fine for a website whose content is 100% public, but if you have users log on, you should be using HTTPS to protect their credentials and their privacy.

34. Using proprietary solutions

Whether it is technology that requires a plugin, or encryption that uses a custom algorithm, proprietary solutions are bad news. At best they are a supportability challenge, and at worst they are a security nightmare. Use standards everywhere you possibly can.

35. DNS open zone transfers

If your DNS servers will transfer your entire zone to anyone who asks, you’re just making the bad guys jobs all the easier. On the Internet, zone transfers should only be permitted between your servers.

36. Using SPF soft fails

If you care enough to use SPF, then use hard fails so others can effectively shut down folks spoofing your domain. If it breaks something…GOOD! You just identified something in your environment that you didn’t know existed.

37. Using non-standard ports

You might not be using firewalls to control Internet egress (and good for you) but that doesn’t mean your customers aren’t. Non-standard ports aren’t reachable unless they are specified, and permitted, and that means when you put an app on a port other than the one for which it’s known, you’re breaking something for someone somewhere.

38. Declaring policy without documenting policy

“That’s against policy!” “Really? Show me.” Blink. Blink. If I had a dime for every time someone got a deer in the headlights look after I called them on a declaration that something was against some non-existent policy… well, I would have a lot of dimes. Policies are good, important, integral parts of your overall infrastructure, but if they don’t exist, don’t invoke them. If you find a situation that calls for a policy, go revise or create as needed.

39. Using unencrypted media

Laptop hard disks, USB keys, SD cards in mobile devices, backup tapes… anything carrying data that can walk out of your office should be encrypted. Period. Hard stop. No exceptions.

40. Emailing NPI

Non-Public Information, or Personally Identifiable Information (PII) should never be emailed back and forth. It’s far too easy for it to be lost, accidentally forwarded, or otherwise compromised, and that can cost you more than just customers. If NPI must be sent using email, it must be encrypted.

41. Taking days to process unsubscribe requests

If you use email for marketing, always have an easy to find unsubscribe link in the footer of your emails, and then process those requests IMMEDIATELY. If your response to an unsubscribe request is either to send more emails asking for confirmation, or to claim it may take several days to process (during which time you send more marketing emails) you are just going to enrage someone. If that someone can ban your domain from their corporate system, you will lose customers who might actually want to receive your emails. Unsubscribe requests simply, politely, and above all else, immediately.

42. Emailing files back and forth

Which version of the file are you looking at? The one I have doesn’t have that value. Oh wait, let me email you the latest version. NO! Stop using email to transfer files back and forth. One time sharing is okay, but if the intent is to collaborate or the file is going to be updated, put it on SharePoint and send a link. That way, everyone will be looking at the right version of the file.

43. Putting security second

“Build it now, we’ll lock it down later” was the last thing the captain of the Titanic said just before setting sail. Well, not really, but the net result will be the same. Security should be included at the beginning and incorporated into every step to minimize the chance of introducing a vulnerability into anything you deploy.

44. Ignoring BYOD

Whether it’s regular users wanting to get email on their phones, or the CEO wanting to use her new tablet, BYOD is going to get into your system whether you want it to or not. Rather than ignoring it, embrace it, control it, and make sure you are prepared for it. Both you and your users will be the happier for it.

45. Securing the device, or the data, but not both

And because of that, you need to make sure that you are securing both the devices and the data they access. Just because it is BYOD don’t assume you cannot help to secure it. ActiveSync policies can do a great deal to help secure devices, and users who want BYOD need to accept the need for additional security, like PINs and remote wipe.

46. Using Java

Stop it, stop it, stop it right now. If your app uses Java, you are alienating users left and right. Considering the number, frequency, and impact of security vulnerabilities in Java it’s hard to imagine why anyone thinks it’s okay to ship a product that requires Java to run.

47. Using Silverlight and Flash

Even Microsoft seems to be moving away from Silverlight, and while it’s a nice alternative to Flash, it’s also almost as limited. HTML5 should be where you focus for media solutions.

48. Using Pop-ups

What is this, the 90’s? If your website required pop-ups to deliver content, then please smack yourself in the head and realize every single browser alive today blocks pop-ups by default for a reason.

49. Using self-signed certificates

Back in the days when SSL certificates cost thousands of dollars, it might have made financial sense to use self-signed certs, or to deploy your own internal CA. When you control all the clients, it’s easy to get them to trust your certs. But between BYOD and cheaper certificates, there’s no reason to keep rolling your own. Now we just need to get vendors to make it easy to replace their self-signed certs in things like VMware!

50. Trying to do in-house what it makes sense to out-source

Managed services are available for almost everything, and sometimes you can get better and cheaper by paying someone else to do it. If your team struggles to do something like maintain telephony, you might save money by outsourcing that to a service provider so your team has more time to work on the things that are core to your business.

51. Pretending domains in a forest or admin groups in an organization are autonomous

In a forest, all the domains within a forest interact with one another, even if the users do not. In an Exchange organization, all the administrative groups must interact with all the others. In both cases, there are some things that require users with full administrative rights to do, which is why we have groups like the Enterprise Admins and Organization Management. When child domains start to pull those rights from their own little corners of the world, they are setting up the entire enterprise for costly, time consuming and end user-impacting events. If you are pulling EAs from your local administrators group, or removing rights from the Organization Management role, please put the mouse down and walk away from the keyboard.

Seasoned admins reading this list probably recognized a few things they have seen others do, or you may have been looking for your own favorite only to find it missing from this list. Please leave a comment if you have a war story to share, or another tip to add to the list. We’ve got 51 above; can we get another 51 below?

Like our posts? Subscribe to our RSS feed  now and be the first to get them!