Security optimize

Three common IT consultant security blunders

IT consultants cannot afford to make a mistake when it comes to security. Erik Eckel offers a refresher on basic security fundamentals.

IT consultants cannot afford to make a mistake when it comes to security. Erik Eckel offers a refresher on basic security fundamentals.

----------------------------------------------------------------------------------------------------

Humility is an important quality in IT consultants. The industry has a way of knocking consultants down a peg and reminding professionals to mind their fundamentals when overconfidence sets in. Security, however, is an area in which consultants can't afford lapses, especially since Sarbanes-Oxley, HIPAA, and data sensitivity have become critical issues.

When I inherit systems, servers, workstations, and networks developed and administered by others, I see other IT consultants' mistakes. I've also seen security failures at the companies where I've worked.

Some security errors are simple brain-dead mistakes, such as affixing administrative usernames and passwords to a server via a Post-it note; other security offenses are less subtle, such as using the same password structure for each client. (Because of one competitor's administrative password naming scheme, I can now log on to any of their clients' systems replicating a simple password pattern.)

Of all the security failures that I've seen, there are three common ones that stand out. Review your consultancy's practices to ensure clients are protected from these blunders.

1: Permitting simple passwords

I'm truly shocked at how many so-called IT professionals permit users and colleagues to set simple passwords that consist of just letters and even words found in common dictionaries. Simple passwords are easily hacked, which can lead to identity theft, unauthorized use of proprietary data, embarrassing leaks, and federal data standard violations.

In racing, when newbies complain of the cost of a good helmet, the seasoned veteran answers, "If you have a ten-dollar head, wear a ten-dollar helmet." If a client has gone to the trouble of investing heavily in firewalls, encryption applications, and additional security parameters, they should invest in requiring complex passwords. Whether the client is protecting a router, a user account, an email address, or another system, you need to insist that employees use eight character or longer passwords that use all of the following: uppercase letters, lowercase letters, numbers, and special characters.

Sure, such passwords are inconvenient, but that's the point. Passwords are a critical component of typically multiple-tiered security systems that are all too often negated as a result of nonchalance. If I can memorize the 26 phonetic alphabet codes, and coworkers can commit to memory the 486 tongue-twisting words to the I Am The Very Model Of A Modern Major General song from The Pirates of Penzance, users can memorize eight to 10 or more characters.

Also, be sure your passwords don't follow the same naming patterns because that's too simple, even if you use complex characters. For example, if one discovers that Acme's server administrative password is Acme*123, it's not going to be too difficult to determine that the Smith company's administrative password is Smith*123, is it?

2: Deploying equipment using default passwords

IT consultants who deploy business-class equipment using default passwords should return whatever service fees they collect to their clients. Exhaustive lists of default passwords are a simple Google search away. This is exponentially more important when deploying routers, firewalls, and other systems that are accessible from the Internet.

As I explain to clients, your data or company doesn't need to be all that sexy to be of interest -- far from it. Hackers write robotic programs that scour the Internet for nodes that respond. Once a node responds, the device becomes a target for attack. This is true whether the device is stationed inside a plumber's office or a bank.

When organizations need to ensure remote administration of devices is possible, your office can work to restrict authorized connections via originating IP addresses to tighten security. But whenever a security device or any node is connected to the Internet, default passwords should be changed. By using tough-to-crack passwords on equipment, you make it difficult for unauthorized users to gain access, whether those unauthorized users are bored internal employees, angry and disgruntled ex-workers, or black hat criminals.

3: Sharing passwords via unencrypted email

It never fails. Organizations invest in enterprise-class firewalls, deploy disk encrypting software, and institute multiple-tiered logins -- which each require different usernames and passwords that must regularly be reset and cannot match previously used passwords -- and then someone emails the keys to the kingdom via unencrypted email. Forwarding administrative passwords via unprotected email, even to authorized users or colleagues, is a practice all IT consultants should eliminate.

Email is inherently insecure. Messages pass not only through the sender's email server but to the recipient's server and through an inestimable number of systems in between. Each step in the chain offers the potential for unauthorized users.

I used to be more cavalier regarding security, but years of IT consulting and experiencing the myriad and shocking ways in which businesses battle competitors, disgruntled staff, and others, I place a much greater emphasis on following security fundamentals. One excellent security fundamental that will help keep systems safe is avoiding sending passwords via clear text email. Just don't do it.

Related IT security resources on TechRepublic

About Erik Eckel

Erik Eckel owns and operates two technology companies. As a managing partner with Louisville Geek, he works daily as an IT consultant to assist small businesses in overcoming technology challenges and maximizing IT investments. He is also president o...

15 comments
spage
spage

These are DUMB practices that can easily be avoided by engaging the thought process. What's worse: I bet nearly every IT Professional has been guilty of at least one of these in the past year. Point taken. Good article!

pjboyles
pjboyles

Making passwords overly complex has been shown to trigger people to write down and post their passwords at their computer. Making passwords expire too quickly triggers people to use sequential passwords and write them down. A better strategy: one upper, one lower, one non alpha, minimum of X characters expires every 120 or 180 days. I still favor 7 as the minimum (old sweet spot for NTLM hash 7 or 14). Safeguarding should be a multi-pronged approach and the backend security is much more effective than the password policy. * Failed login lockouts (make it 10 attempts and 10 minutes (preferred) or 5 minutes without an attempt (allows password lockout DOS)) * Detecting attacks (you can't react if you don't know) * IP hold-downs (lock out an attacking IP address) * Eliminate easily guessable passwords * Password reuse limit of not in last 3 passwords. (Who remembers beyond that?) * Protecting against capture Sending a password in an unencrypted e-mail without the ID and requiring a change on login should not cause a large exposure (even better when the system is not accessible from outside the business). Oh, because there are some people who can easily (or not so easily) memorize things do not assume the general population can.

ancient.drive
ancient.drive

Password complexity and normal people don't mix.

apotheon
apotheon

Instead of pandering to the desires of users to use the same password everywhere, and make it as simple and easy to crack as possible, we should be teaching them how to use password managers. This provides the best of both worlds: effectively using the same (strong) password everywhere, in terms of convenience, and effectively using a unique, strong password in each place, in terms of security. Don't give up on security just because your users don't give a damn. Instead of compromising security for convenience, figure out how to make strong security more convenient for your users.

bkindle
bkindle

I'm a consultant, I notice things like these all the time. Although I see them, it's not always what I was hired for. I mention the need for stronger passwords, but always am met with angry stares and, "We can do that." It's frustrating, but what do you do?

tbmay
tbmay

The ball's in their court then. Contrary to the opinion of some of our brethren here, it's not always our call. Make sure you're on record with your concerns. Put it in writing if it really concerns you. Then leave it up to them.

reisen55
reisen55

Whew. And my passwords, while following a known syntax in my offices, are relatively complex without being a burden. Last year my server was actually being password-blasted from China, an IP address from the Beijing Railroad!!!! I have a good, easy to remember (for me) sequence and it worked. I made it a bit tougher though.

robo_dev
robo_dev

Point #1 is not logical. Since you don't have knowledge of other people's passwords, how do you "allow" others to set weak passwords? You don't. If the system allows it to happen, you have no control over this, unless everybody tells you their password, which would be a security issue, obviously. You typically do not have the time or opportunity to test the strength of user passwords, and it's not really practical to do that on most systems. As an IT consultant, you can set password complexity rules on systems that support this, to enforce password complexity. This makes it impossible for a user to set a weak password. For example, Sun Solaris allows you to force passwords to be a certain length, contain numbers and letters, and can limit password reuse. Sharing passwords via unencrypted email is not the worst thing in the world, provided that the policy requires that the user change their password immediately upon email receipt, and preferably, the system is set to force a password change at next login. The more fatal mistake is when administrators use the same password for everything.

Erik Eckel
Erik Eckel

If a client requires encryption to protect data and information that possesses legislated security controls (ie, HIPAA data, Securities and Exchange Commission-regulated information, social security numbers, credit reporting data, etc.), a consultant's sending the encryption key or password via an unencrypted email message is a terrible idea. One fell swoop eliminates all the controls the organization invested heavily to implement, no?

Bruce Epper
Bruce Epper

Ever hear of l0phtcrack? Users don't need to tell you anything. Just run it against the servers on the network and you can test all of the passwords used by all users of the system. You can even schedule it to run password audits on a regular basis so you don't need to be troubled to run it yourself. I am sure that there are other tools out there that can be used for password auditing. I used to use l0phtcrack across the entire corporate network for a previous employer. I still couldn't get upper management to do anything about the abysmal results I would get with over 60% of the passwords being crackable in under 10 seconds, but that's another issue entirely.

Neon Samurai
Neon Samurai

If you don't have permission to crack the user's passwords (eg. contract client), running l0phtcrack may not be a good idea.

apotheon
apotheon

1. If you do not set password complexity rules in password protected systems, you have allowed people to use weak passwords. As such, that is not really a flaw in the article. 2. Even if you force password reset on first login after emailing the password to the user, you have sent the password in the clear, and if it is intercepted before the end user gets the email, damage can still be done. I'm not sure I see that as a flaw in the article, either.

Ron_007
Ron_007

"Permitting" simple passwords can have a couple of meanings. - by not advising client to require complex passwords - by not turning on password complexity rules - by submitting to client demands to turn off complexity rules. But in the end, all we can do is recommend security best practices. If they client refuses your advice, just make sure to get it in writing. CYA only works if you can support it with paper. The simplest way I have found of not deploying devices with default passwords is to simply go ahead and change the default as part of configuration and installation process. If they decide to change it back to default, that is not your fault. I once went into a client's office to do some other work. Right there on a bulletin board, in 3 inch high letters was the following note: "SAP password is *******". Oops! And the password was dictionary words in a simple pattern to guess, even it was changed.

Jellimonsta
Jellimonsta

The article mentioned sending administrative passwords in clear text as a no-no. Not mailing a user a password in-house to some site or application.

tbmay
tbmay

...more more stringent. In a nutshell, many of my clients got angry. They didn't WANT hard passwords. When I pressed, they got all the more frustrated. I do like your $10 head comment though. Might just use that next time.

Editor's Picks

IT Buying Cycle

Learn more