Every Microsoft Windows computer on the network has a number of Local User Accounts that can be used to login to the PC without needing to know a Username and Password on the overall Practice network security domain. These local accounts are often overlooked or forgotten. Often they may have blank passwords when the computer is shipped to you. Hackers and viruses can exploit these accounts, so it is important that they are secured or deleted.
How do they get created?
By default there are usually two local logins: Administrator and Guest. Back in the days of Windows XP and Vista, manufacturers (like Dell and HP) would ship the PC with a blank Administrator password and the Guest account disabled. The blank Administrator password is a HUGE vulnerability. Creating additional local accounts was optional.
More recently with Window 7 & 8, the Administrator account is also disabled by default. When the computer is initially setup, it asks you for a Username (Bob for example) and then it creates a local user named Bob with Administrator level privileges. The problem is, most people don’t realize that this Bob account has those rights, and often they forget that they even created the Bob account.
It’s a fairly normal practice that your IT people may create themselves a local Administrative level account so they can login to any PC for maintenance purposes. Problem is, when you changed IT people, have you gone around and removed all these backdoors?
If you’ve ever had Spyware on your PC, some of these infections attempt to create their own local Administrative user, or enable the Guest account, or change the actual Administrator password.
An obvious best practice is to eliminate any potential back door accounts, and keep close track of the accounts that do exist.
Periodic Review
I think it would be wise to periodically check (Annually at least) the local PCs of your Practice for Rogue accounts. It’s not difficult if being performed by an IT person or someone with the knowledge of what should and should not exist. They should document that it’s been done. It should take less than 5 minutes per PC.
What to do
If you are already a believer and plan to just assign this to your IT person and don’t care to know the gory details, just skip down the article to the section on adding this to your IT Policy.
Here are the steps I would recommend be done on every PC:
Set or verify the Local Administrator Account Password
As a security feature Windows doesn’t allow you to just see what the current password is. This can be done by either just setting the account password again (ignoring what it was) or actually logging in to test that the account and password are as expected. Also I would:
- Ensure that it is Enabled (for use in future troubleshooting)
- Ensure that the password meets your Password Complexity requirement
- Document the password in your Password Storage Database
- Optionally the account could be renamed to something else or disabled and an alternate local administrator account created. Document this if done.
Review the Local Administrators Group Membership roster
- This is the group of users that is granted full privileges to the local PC.
Every entry should have a specific purpose in this group, and you should know that each account in this group has a hard password (and that it’s documented). - Typical membership would include these individual Local accounts:
- Administrator
- An account for your current IT Provider
- Domain Admins if your network uses a Microsoft Security Domain
- Look for Rogue accounts that don’t belong.
- Previous IT people
- Follow-up and disable or delete accounts that shouldn’t be there
- If you are finding accounts and you don’t know how they got there, you need to be concerned and try and work out what happened. Could be a sign of a larger hack or spyware. Don’t just delete and go ‘huh – that was weird’
Disable the built in Windows ‘Guest’ account
This idea was from a long ago when the risks of hacks was very minor. Today there is no practical use for this within the Practice so ensure it is either disabled or deleted.
Caveats
You need to be logged into the PC with local Administrative privileges when you perform these steps.
You need to have at least one local account with Administrative privileges. If you were to leave the local Administrator account disabled, and delete the ‘Bob’ administrator account (from my example), you’d have no way to access the system as an Administrator for future changes. This is why I recommend enabling the local Administrator account.
Make this part of your IT Policy
I have been on a crusade of sorts to help get Practices organized to take reasonable security precautions to protect their data and help with HIPAA compliance, and this topic is one of them. In a previous post I have outlined the need for maintaining a simple IT Policy document using the example of Maple Leaf Orthodontics. I have prepared a new section called ‘Local Workstation Security Accounts Review’ that you can take and incorporate into your policy. You can download it here.
I have prepared an Annual Local Workstation Security Accounts Review Checklist as well. This is a simple form to streamline the process of the annual audit so your IT Person should be able to complete it in a matter of minutes. You can download it here.
With a little more effort you can turn the checklist into an Adobe PDF form to make it super easy to fill out and save each year – check out this example.
Please subscribe to the blog to get a notice of when the next article is posted. Sign up to get updates by email as soon as we add them.
If you’d like a little help with your Local Workstation Accounts or IT Policy and its implementation please consider MME, it’s what we do. We can customize the complete document for the steps applicable to your Practice, and take care of the IT steps to implement them (we are nerds after all). Just give us a call at 866-419-1102 or check us out online at www.mmeconsulting.com.
