Lifting rocks and seeing what dangers lurk beneath

I'm still getting acquainted with my new company. As a security manager, that means I'm seeking out all the risks that are lurking in various functional areas.

Trouble Ticket

At issue: Bit by bit, the risks facing the company are coming into focus. Many of them involve access to the network.

Action plan: Use every possible means to track down unaddressed threats, then prioritize them and set them right.

There are many ways to ascertain risk: assessments, audits, penetration testing, surveys, document reviews. And sometimes you just have to keep your ears open. That was the case the other day, during a meeting with the executive vice president for human resources. We were discussing my training and awareness program, but the topic of remote access came up, which led her to mention that she had a temporary password for the VPN.

This company requires two-factor authentication for remote access. I'm an advocate of that, and I was happy to see it in place here. Now, though, I was being told that access was possible without one of the factors: the token. It seems that when the HR executive had been traveling six months earlier, she had forgotten to take her authentication-token key fob, so the help desk provided her with a temporary password to gain access. But that password is still enabled.

Immediately after that meeting, I sent an e-mail to the administrator of the two-factor authentication infrastructure asking about the password bypass option. In emergencies, he said, users were given a password. OK, then, who has this bypass enabled, and how long has it been provisioned in each case? The answers were startling. This bypass was being used in lieu of key fobs as a quick way to provide remote access not only to forgetful employees, but also to distributors, partners, suppliers and contractors. And some accounts had been in place for more than a year. The existence of two-factor authentication had given me a sense of security that was entirely misplaced.

This issue with the VPN spurred me to take a closer look at our VPN configuration. We use VPN concentrators, which can be tied to Microsoft Active Directory, and that in turn allows us to set rules that limit access to only the parts of our internal infrastructure that any particular user needs. The result of this inquiry wasn't just startling; it was groan-inducing: Everyone has the same level of access. That includes people who no longer have any need to access our network at all!

Well, then, I thought, perhaps it would be a good idea to audit some of our other account management processes. Most IT organizations give administrators privileged accounts that let them handle functions related to domain account administration, e-mail management, backups and restores, and so on. In a Microsoft environment, certain policies can be applied to restrict administrative access to only the required privileged functions. You probably know where I'm going with this. The good news was that I found that our IT admins had taken the time to define two types of administrative accounts, for employees and contractors. The bad news: Both types are given the same amount of administrative access. Of our 80 IT employees, about 30 have administrator accounts that give them access any employee's mailbox, home directories and sensitive data repositories. Luckily, our financial and HR applications, with their salary data and other personal information, are protected with other access controls, but this is still a huge risk. I wasn't merely groaning now; I just about fell over.

As the security manager, I am like a gardener lifting the rocks placed among the plants. I might find grubs and other threats to the plants under some of them, but I have to put the rocks back and prioritize which threats to deal with first.

And so, as time goes on, I will adjust or write policies and processes to deal with the various issues that I have uncovered. And I'll keep lifting those rocks.

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark