It is important to invest in security where it benefits you the most and ensure that there is as much security-enhancing effect as possible for the investments that need to be made. Introducing MFA is an effective way to supplement and strengthen possibilities for other forms of protection by guaranteeing identity. It is also a good way to protect the company against end-users being attacked.
Before introducing MFA, it is important to map out your applications and systems. There are also many aspects to consider in order of choosing a good MFA platform that supports the business in a good way. A thorough requirements analysis should be done to avoid pitfalls or limitations that make the implementation less successful. It is extremely important that a solution is accepted by users. It may be helpful to have the help of experienced experts when introducing an MFA system.
Security from the user perspective
Most “regular” IT users in our organizations do not work with IT security at all. Ordinary users create, consume, change, and share information as part of their work. The safety awareness of our users in these times is significantly higher than before, but it is still not possible to relax and close your eyes because the user himself is often the biggest concern in security work. The biggest so-called attack vectors are still email and web surfing. The eternal issues of confidentiality, integrity, and accessibility (CIA) are as current as ever, and then there is the identity issue. Perimeter protection does not have its focus on identity, but without a validated identity our protection can’t be enhanced, and then the damage will still be great.
Focus on strengthening user security
Most companies have already secured basic user security with the help of password policies and elementary user security. However, many companies do not have enhanced user authentication, an area where security can often be strengthened and provide a significantly higher level of security.
Multifactor authentication (MFA) adds extra security when other security systems fail to perform the task or when an unauthorized individual manages to access a user’s computer, login name, and password. It is relatively easy for a hacker to find out a username and a password.
If the attacker has accessed a user’s computer, then the issue is to prevent it from entering the company’s system. User security is an area that does a great deal for the overall security with a relatively reasonable investment and effort. It should be a high priority.
”Principle of Least Privileged” access
Generally, a user should not have more access to systems and data than is required for their tasks under the “Least Privileged Access” principle. This is to minimize any damage if the user’s accounts are intentionally or unintentionally abused for accessing applications, data, and systems. This should be taken seriously, and routines and systems to continuously evaluate this should be introduced.
Password policy, user data and directory services
Furthermore, password policies should be implemented with a good structure of the password design and routines to replace them. User data and associated directory service security is also an important part of working with protection. In addition, this is linked to regulatory requirements such as the GDPR and related legislation. These are some examples of the basic parts of user security (and there are several more) and perhaps a matter of course for many. This creates a certain level of security from a user perspective, but is this enough?
Introduction to Multifactor Authentication (MFA)
Implementing Multifactor Authentication (MFA) greatly improves user security. This should be done before accessing all business-critical applications, data, and systems. Both in the cloud environment and in the datacentres of the company. In an MFA context, you talk about knowledge factors and possession factors.
Typical knowledge factors are usernames and passwords. Knowledge is relatively easy to acquire for a hacker. An example of this might be a so-called “keylogger”, a malicious functionality that can be included with malicious code that an attacker managed to get into a compromised computer. A “keylogger” records the user’s keystrokes and saves them. Often there are many other features included in the malicious code to communicate with the infected computer from a remote location and to perform certain forms of ready attacks.
In this way, an attacker can relatively easily get to know the user’s logon and in addition, run applications from the compromised computer with his user’s login information and thus gain access to a company’s applications, data, and possibly other systems. Implementation of the principle of “least privileged access” to systems has a clear purpose when putting it in a context like the one described earlier. It reduces the extent of damage in the event of an infringement.
By adding one or more components of the possession factors, it is getting significantly more difficult for an unauthorized person to log in with stolen usernames and passwords, since he then also need to be in possession of the third competent in addition to the username and password in order of logging in.
The third component is often a mobile phone with an app, a connected device, one-time codes (connected / not connected), or biometrics. There are many technical solutions that are considered possession factors.
To put things in the right perspective – Which private person would accept that his internet bank only used username and password? The answer is given. Today, no one would accept that level of security to protect their own private assets. A multifactor authentication with a bank box that generates one-time codes is nowadays basic on an Internet bank and several other well-known applications and platforms used for private use.
Yet many companies do not fully or only partially have multifactor authentication for access to their assets such as applications, data, and systems. Does the company have full control over which assets are protected by MFA?
Where should MFA apply?
What business-critical systems need MFA, and where should these systems/data be used? There are two basic questions that need to be answered by identifying business-critical systems and where they are in the company’s IT environment.
A risk analysis needs to be performed to classify and prioritize the applications. Business-critical applications are identified, then risks are analysed from a business perspective, and last, but not least, the results are prioritized. This process needs to be followed in order of determining wherein the company’s IT environment and in what order MFA needs to be implemented.
Normally, when conducting a transparency/risk analysis, many more safety-enhancing activities than MFA are considered. For companies that work methodically and structured with safety, this is usually already a continuous routine.
For companies that are not really “there” yet, who haven’t a clear organization and lack processes and a methodical working method, it is important to see this from a more pragmatic point of view. Applications, data, and systems still need to be identified and then prioritized. It determines where in the IT environment MFA should be implemented and in what order.
Where do you start introducing MFA?
The most common occurrence is that MFA is implemented first in the VPN gateway which is to protect access to the data centre and the applications and data stored there. MFA in a VPN gateway provides protection against network access, not the applications themselves. Similarly, it does not apply to those who have access to the network, other than VPN. If an attacker is physically present or has taken over a user’s computer on the internal network using, for example, malicious code and “keylogger” as described earlier in the text.
However, it is significantly better than nothing, but today MFA is also required to be introduced further as there may be more inputs than the VPN gateway, and today many applications are in the cloud.
Examples of various parts of the company’s IT environment that should be protected with MFA:
SaaS applications or other publicly accessible applications should be MFA protected. In these cases, there is usually not even protection against network access, but anyone who has managed to come across usernames and passwords has access to log in because they are accessible to anyone with the right application and internet access.
Applications in the private/internal network in your own data centre as well as applications implemented using IaaS cloud-based services such as AWS, Azure, etc. should also be protected with MFA. Access to these can be done by unauthorized persons either through some type of remote access obtained via malicious code, or simply, that unauthorized persons have gained access to the internal network.
Infrastructure such as servers (including virtualized environments) wherever they are. Network equipment (FW, routers & switches) should all have MFA implemented to ensure that equipment cannot be reconfigured and used to advance in the internal IT environment.
What to consider when introducing MFA
Below are examples of things that may be worth considering when choosing a multifactor authentication system.
Installation and roll-out of “on-premise” solutions can cause real challenges. Cloud-based authentication services are quite simpler. They usually do not require hardware and software installation and are much simpler than solutions where systems and applications are in the company’s own data centre. The complexity of implementation increases in IT environments where both the cloud and the data centre are used in a hybrid environment.
Most people working with IT security do not want to write their own integration code. Choose platforms where drop-in integration is available for commonly used VPN solutions, Linux / Unix, and Microsoft as well as published SDKs and APIs. A solution that easily integrates with all types of systems and where you don’t have to be first.
The smoothest two-factor authentication services utilize something that the user already has, such as their mobile phones. Ensure that it is possible to obtain the solution with support for fixed connections and hardware tokens.
Evaluate the connection processes for new users. This can differentiate a lot from platform solutions to platform solutions. It is worth considering in order of avoiding time-consuming start-up processes. You can choose a platform that has self-service to avoid manual work for the administrator of the MFA platform. This makes it easier for everyone, both administrator and user.
Evaluate user licensing models and choose one that is flexible if you need to add more users.
Try to find an MFA platform that will be accepted by users and gain general acceptance. If the MFA platform obstructs users too much, the purpose is counteracted, and alternative solutions and paths arise which means that the purpose of the entire MFA platform is lost and thus leads to a deterioration in security. For example, the use of mobile phones with a well-designed app can keep the added complexity to a minimum.
Users should have the opportunity to add themselves to the system and be able to change their own equipment to use the MFA platform.
The authentication process should be part of the user’s usual login process. Look for “live status text” to make it easy to follow and understand.
Test and evaluate the end-user experience of the platforms based on speed and ease of management. If it is too complicated for the users, there will be complaints and dissatisfaction.
Ensure that the solution also works with fixed connections and without mobile coverage. In these cases, even the hardware vendor may be needed as a supplement to certain types of businesses and users.
End users should be able to make different choices. Allow them the flexibility to use the best authentication method for any given occasion and their situation and circumstances, for example depending on where they are. The risk is that non-flexibility will counteract the purpose of the system of adding additional security.