Security Manager's Journal: Reining in network accounts

Many accounts exist that aren't associated with individual people, and theyve gotten out of control

After my discovery that we hadn't been doing a great job of removing the network access rights of ex-employees, I looked deeper to see how we could improve things. First, we instituted a new process to compare the active employee list and termination requests to the user accounts configured in our in-house and software-as-a-service offerings. As I explained last month, my team already does an account review every quarter to comply with SOX requirements, but we had only been comparing the active user accounts to the termination list to ensure that everyone who was supposed to be removed no longer had access. Now we are also doing a comparison of active user accounts to the list of active employees.

But in doing these comparisons, the focus has been on people -- the employees and contractors who are associated with each user account. I ignored accounts not associated with people. Now I'm going back and taking a closer look at those other accounts. They generally fall into four categories: service accounts, training accounts, test accounts and built-in administrator accounts.

Service accounts are used by software to connect to services with proper authentication and associate the correct set of rights with the software. I found two problems with these accounts. One is passwords, and the other is privileges.

Many of the service accounts I looked at have simple, easy-to-guess passwords assigned. For example, there is a service account called "oracle" that has a password that anyone could readily guess. But you wouldn't have to guess. The scripts our developers wrote for the oracle account have the password embedded in them, and that password is sent in the clear over the network when those scripts run. And who knows how long that password has been around? I'd bet that several system administrators have come and gone since that password was assigned. And since the password is set to never expire, it will remain like it is until somebody like me comes along and forces it to be changed (our system administrators value convenience over security). For now, I've asked them to change the password to something less guessable, and to find a way to obscure it in the scripts and over the network. I'm also looking into off-the-shelf products that can do this in a more automated way.

The other problem with the service accounts is excessive rights. Many of the Windows service accounts are part of the Domain Admins group, which gives them far more access privileges than they need. And some of the Unix service accounts are root-equivalent, which is also excessive in some cases. This is not easy to fix. Developers have to research best practices and recommendations from the vendors, which are rarely helpful. Then they have to make changes, test the functionality of the software services that use those accounts and try to fix whatever breaks because of the reduced privileges. Our developers are already overworked on business projects, so my concerns may stay on the back burner for a while, at least until some insistent requirement comes along that makes the problem a priority.

Training accounts are somewhat easier to address. We have roughly 100 Windows user accounts that are called train1, train2, etc. These are used by employees and customers who go through our training programs to learn how to use various software platforms. You'd easily be able to guess their passwords as well, but at least their privileges aren't excessive. I had the training department and system administrators work together to choose better passwords, and set them to expire every 90 days. I still don't like shared accounts like this, but I can comfort myself that their privileges are limited and the passwords are better now.

Test accounts had the same problem as training accounts. Scores of IT people over the years had created such accounts for various purposes. Some of these were easy to track down because they had "test" in the name. Others were more difficult to find, because some administrators created additional accounts in their name or accounts with other unexpected names. I was able to find these by subtracting all the known account names and looking at what was left. I instituted a new policy of naming test accounts after the people who use them, forcing the passwords to expire every 90 days and disabling the accounts when they are not actively being used.

Built-in administrator accounts are the final frontier. I'll talk more about those next time.

This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at

Join in

To join in the discussions about security, go to

Read more about security in Computerworld's Security Topic Center.

Join the CSO newsletter!

Error: Please check your email address.

Tags data securitysecuritydata protection

More about BuiltTopic

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by J.F. Rice

Latest Videos

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

  • 150x50

    IDG Live Webinar:The right collaboration strategy will help your business take flight

    Speakers - Mike Harris, Engineering Services Manager, Jetstar - Christopher Johnson, IT Director APAC, 20th Century Fox - Brent Maxwell, Director of Information Systems, THE ICONIC - IDG MC/Moderator Anthony Caruana

    Play Video

More videos

Blog Posts