A chink in the armor
In the last post, we explored how to make password authentication more effective, as it is vital for maintaining the security of your ServiceNow instance. However, it’s an unfortunate fact that even the strongest passwords can be stolen with techniques like social engineering or phishing and used to gain unauthorized system access. These work by targeting humans (which can be more vulnerable than computers) and tricking them into revealing their credentials.
Passwords do not on their own provide truly robust protection. As low-hanging-fruit, they are the most frequent attack vector for any system compromise.
Fortunately, the risk can be significantly reduced by using Multi-Factor Authentication (MFA) and IP Address Authentication to add extra layers of protection – reinforcement – to the login process. This does not however, reduce the importance of password policy, which should be reviewed and strengthened, if necessary, as the first line of defense.
MFA improves security because successful authentication requires more than just the credentials. It means that two or more types of verification checks (factors) must be passed before access is granted.
Commonly used factors can be described as:
- something you know, e.g. a password
- something you own, e.g. code generator token/app, or SMS sent to your phone
- something you are, e.g. fingerprints, or
- somewhere you are, i.e. geolocation
Adding reinforcements
We recommend that you enable MFA on your ServiceNow instance (or any internet facing system) to help prevent unauthorized access. For local and LDAP accounts, it can be activated for use with Google Authenticator. SAML 2.0 IdPs can be integrated to allow 3rd party MFA, e.g. Okta, Azure, Symantec, etc. MFA requires hardware or software tokens to be distributed to users if they don’t already have them, or if SMS is not used.
You can add another layer of security by only allowing access to your instance from defined IP address ranges, similar to the way you'd use basic firewall rules. This can be very beneficial and is simple to set up. When using this method, consider the egress addresses from your internal networks to your instance, e.g. from firewalls and proxies. You will also need to think about any remote and roaming users, perhaps by using a VPN to backhaul traffic to your network.
In the next post…
Managing access is critical to securing your instance, but how do you control what happens once someone has legitimately logged in? In the next post we will look at ways to manage what data users can access and which parts of the application they can use.
1 Comment
