According to Verizon’s 2017 Data Breach Investigations Report (DBIR), “81% of hacking-related breaches leveraged either stolen and/or weak passwords.” The National Institute of Standards and Technology (NIST) understands this. This is why, I believe, they are taking a tougher approach to identity risk than to other areas of network security. As proof I would point to the differences between the NIST 800-63 Digital Identity Guidelines and the NIST 800-30 Guide for Conducting Risk Assessments. NIST’s tougher approach to identity risk will require organizations to invest heavily in their Identity and Access Management (IdAM) infrastructures.
I know, I know, everybody loves a post about NIST guidelines. However, we thought this post was necessary due to the interest we received from our white paper detailing the updated NIST 800-63 and the number of views the accompanying video has received on youtube, which broke the record for most views of a non-cat, NIST video.
To give a brief background, the updated NIST 800-63 separates digital identity into Identity Assurance Level (IAL), Authenticator Assurance Level (AAL) and Federated Assurance Level (FAL). Within each Assurance Level, NIST defines 3 risk levels. The higher the level of risk the more restrictions that are placed on the organization (e.g., in-person vetting, multi-factor authentication, Holder of Key, etc.).
The main question that we receive from customers is, “How do I determine which Assurance Level applies to my organization?”
The NIST guidelines provide flow charts to help determine assurance level by judging risk on a scale of low, medium and high. If an organization judges any of the risks to be high (or medium for risk to Personal Safety) the Assurance Level is IAL3, AAL3 or FAL3 resulting in large IdAM changes for the organization.
The problem with judging risk is that it is subjective. If asked to take the risk of financial loss or criminal violation wouldn’t we be risk-averse and select high? To alleviate this issue the guidelines point to NIST 800-30 which was designed to help organizations perform risk assessments in a more analytical manner.
While reviewing the 800-30 guidelines we were struck by a few core differences which we believe highlights NIST’s tougher approach to identity risk.
During a risk assessment NIST 800-30 guides organizations to view all elements of risk including threat, vulnerability and impact. However, NIST 800-63, “asks agencies to look at the potential impacts of a federation failure. In other words, what would occur if an unauthorized user could compromise an assertion?”
The reason this is important is that by focusing on impact without threat and vulnerability, organizations disregard several key points. For instance judging threat includes an assessment of who has the capability to perform the attack and do they have the desire to do so. Additionally judging vulnerability includes an assessment of existing security controls which may prevent the attack. Both threat and vulnerability serve to tamper the impact of an attack. If we only look at impact we will most likely take a tougher approach.
Another example is the number of risk categories. NIST 800-30 recommends 5 risk categories with semi-quantitative values for each (e.g., Very High is 96-100 while High is 80-95). NIST 800-63 only has 3 categories, or 2 for Personal Safety. This reduces granularity and leads to the selection of higher Assurance Levels.
What is the reason for NIST’s tougher approach to identity risk? Perhaps it is that for all of the fear of hackers cracking firewalls, the DBIR proves that the majority of attacks are still due to stolen credentials and privilege misuse. By creating a subjective risk assessment model that skews towards higher Assurance Levels, perhaps NIST is telling organizations that they should invest more heavily in IdAM security. Perhaps organizations should pay attention.
Eric Sharret is Vice President of Business Development at TELEGRID. TELEGRID has unique expertise in secure authentication, PKI, Multi-Factor Authentication (MFA) and secure embedded systems.
Disclaimer: The opinions expressed here do not represent those of TELEGRID Technologies, Inc. TELEGRID Technologies, Inc. will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.