Secure Identity Verification of End-Users
Know the positioning, international standards, and workflow
Government organizations in many countries want to improve IT security as part of the expansion of public digitalization strategies. An important element is trust in identities.
Documents, standards and regulations are at the forefront in setting the standard for how government bodies—e.g., NIST (National Institute of Standards and Technology) in the USA and the Government Digital Service (part of the Cabinet Office in the UK)—must prove the identity of citizens and consumers, and also in meeting the national requirements of other countries.
Organizations need to prove the identity of their employees too, and there are similarities with proving citizens’ identities. There are, however, also differences. When organizations want to validate, prove the identity of, or verify an employee, each organization needs its own specific guidelines, though some very good inspiration can be found in the official guidelines. With other regulations of this type, we have seen that public organizations demand similar guidelines or regulations are followed by their private partners, and we will then see the same principles applied everywhere. If this is the case, then this document will have value for both public and private organizations.
When organizations want to validate, prove the identity of, or verify an employee, each organization needs its own specific guidelines
Our ambition with this white paper is to inspire managers with security and compliance responsibility to design a logical system for user verification which can be planned and executed.
Even managers of operational units, such as service desks, who perform verification procedures can benefit from this document. All decisions made by organizations must respect efficiency and speed in addition to security. This white paper also suggests a best practice for the use of FastPass Identity Verification Client (IVM) where organizations have to comply with national or international standards to achieve secure identity verification.
What you can get from the whitepaper:
Identity Verification Positioning
controls what IT resources a person can use. It depends on title, role, hierarchy and other organizational characteristics. The IT resources can’t see people, so it is translated to a user identity. We then assume that only the employee can use this specific identity.
then ties the person to the user identity. This is done with credentials. A good credential is unique to the person and can be read and understood by the IT system. The Access Management system will also have control of the directories where we link the credentials to the user-identity. This process is called authentication. It can be 1-factor or multi-factor authentication (MFA).
is the process used to ensure that the person is who he/she claims to be! When we work with credentials, then identity verification must guarantee that the person owns the user identity. The credentials must be administrated by trusted (privileged) persons or systems, which issue the credentials after the person’s identity has been adequately verified.
See workflows on how you can simply verify persons for different levels of secure or sensitive systems according to international standards based on different regions
Proposed model of Identity Verification for end users
Most companies already have an overview of their systems relative to their risk profile. As is the case in the United States and UK, it seems reasonable to work with four categories. For some systems/applications, the user’s rights are determined inside the application based on the user’s position or role.
Decide what category each system or application belongs to, unless it can only be determined by the user profiles.
For each user group, find out the highest security level the group has access to. This will then determine which identity verification process to apply to the entire group.
Because of this review, groups might be modified to reflect a specific level of security level that should represent the common denominator for all groups in the future.
Will a user’s access rights depend on the credentials he/she uses? As examples:
- The user has different passwords for different applications;
- The user only needs to use a password for some applications but a password plus token for other applications or situations.
If end-users use different credentials for different situations, we must use applications/systems as the principal dimension for determining the level of security testing required.
Next, the three first steps are consolidated. While this may be very complex, we provide a sample overview in the full whitepaper
With different passwords for different applications, we can allow the verification process to follow the application. If we only have one password for all levels of security, the verification process must follow the user groups. In some situations, it will be possible and desirable to even combine the two principles.
What information and tokens does the organization already have or can be made available at small and reasonable cost? How strong are the different elements?
If we require 100 points to be verified, how many points will we credit to the different categories? As part of the description of each category we have used some indicative values. With FastPass IVC, every customer can configure their own values.
- Company information
- Biometric information
- Individual protected information
- Dynamic and contextual data
- Manager/colleague approval
After considering the points given for the different tests, we must then define how much represents adequate proof, depending on the situation.
Each organization will make its own decisions. See our sample table in the full whitepaper //link to whitepaper//of how to set values for different tests for different security groups.
The national standards and regulations call for compliance reporting. Where Step 6 describes how the identity verification must be done, then this step is about proving that we comply with the descriptions.
An automatic event log of every single verification step/test is necessary. The information about the tests and the results of the test, combined with user-identity and supporter identification and other system information, will make it easy to produce the necessary reports for the compliance audit.
All IVC event logs can be integrated/transferred to the customer’s reporting tool and there integrated with other actions taking place at the service desk.
The format and frequency must be decided together with the auditing and compliance team (internal or external).
The critical part of the password reset process is identity verification.
How can the service desk agent confirm that it is the legitimate user? This task is taken over by IVM, which will control what actions to take and decide when the verification is OK, based on specific knowledge about each user.
As societies are moving to a higher degree of digitalization, it is becoming obvious that security for persons and their user-identities is a prerequisite. Many countries are implementing new regulations to enforce this. But even without legal enforcement, it would be wise for any organization to protect the relationship between users and their user-identities.