Clearing the way
One topic covered in the previous post was the importance of not sharing user accounts and passwords; each user should have an individual account for their sole use. Depending on your situation, there may be anything from a few dozen to hundreds of thousands of users accessing your ServiceNow instance. Good security practice means staying in control of excess accounts because they can present a security risk if not managed effectively.
Unused accounts could be targeted for unauthorized use, e.g. by malicious attackers with stolen credentials, or by disgruntled ex-employees. These can also be at risk of compromise if they have weak or easily-guessed passwords assigned, and this is especially true of any standard, inbuilt local and demo accounts. Some simple housekeeping can help.
Shields up
Your instance includes a feature that - when enabled - allows user accounts to be created automatically based on emails it receives. Used carefully for the right purpose, this can be very handy, e.g. so that your customers can log tickets by email without having to create accounts first. However, if it's not controlled properly, this facility could be misused by attackers to create bogus accounts.
To maintain high levels of security and reduce the risk of compromise, you should give attention to unused accounts and the auto-creation feature. This will help you to reduce the attack surface.
Phasers to stun
- Disable unused accounts - You should regularly find and lock out or remove any unused or unwanted accounts. Deleting or disabling accounts should also be part of the HR off-boarding process, to make sure that ex-employees no longer have access.
- Secure any default & demo accounts - It is important that non-default, strong passwords/passphrases are set for standard local and demo accounts. You can adjust password requirements in line with your organization’s security policy.
- Evaluate automatic user creation - Think carefully about whether you need the automatic user creation feature. If you do, make sure it's restricted to only operate on defined and trusted email domains. The feature should be disabled altogether if it’s not needed, to avoid the risk of bogus accounts being used to gain unauthorized access to your instance.
In the next post…
User account hygiene is a simple, effective - but often overlooked - aspect of information security. Keeping your system's accounts in order reduces opportunities for bad actors to gain access. But how can you check that there's nothing dubious going on with your instance? In the next post, we will discuss how you can use monitoring to look out for potentially suspicious activity.
