As I mentioned in my earlier HOW-TO on "Fast Track to Federation for Web Sites", the first step in that process is to conduct a web site risk assessment and use the results to determine the type and strength of credentials you will accept at your web site. The risk assessment provides a mechanism to evaluate each web site using a consistent criteria, and provides a contextually driven mechanism that balances the need for protection of the information with the responsibility to share that information with the appropriate audience. While this process is equally applicable to internally facing web sites, it is absolutely critical for externally facing web sites that need to accept federated credentials.
The combination of "E-Authentication Guidance for Federal Agencies (OMB-M04-04) [PDF]" and "FIPS 199 Risk/Impact Profiles [PDF]" are the mechanisms used by the US Government in assessing its own web sites, and have become one of the most widely used mechanisms for how to conduct a web site risk assessment. Yet, many people are either not aware of this excellent (and free) resource or discount it as being too "heavy-weight". I hope to, in this blog post, provide an overview of this process and show you through a worked example how it is possible to apply it very easily in the majority of cases.
Risk from authentication error is a function of two factors: (a) potential harm or impact and (b) the likelihood of such harm or impact. The categories of harm and impact as well the three potential impact values (Low, Moderate or High) are given below:
- Inconvenience, distress or damage to standing or reputation (Low/Moderate/High)
- Financial loss or organization liability (Low/Moderate/High)
- Harm to an organization's programs or public interests (Low/Moderate/High)
- Unauthorized release of sensitive information (Low/Moderate/High)
- Personal safety (Low/Moderate-High)
- Civil or criminal violations (Low/Moderate/High)
Risk Analysis - Worked Example
Given below is an example of the evaluation criteria applied to a web site that has resulted in specific and contextual choices by the evaluator (Please follow the category links above to see definitions of what Low, Moderate and High mean). Note that there exists sensitive information on the web site, that if released improperly, could have a "Low" impact on the organization (i.e ... cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced)
As such, due to the low impact of unauthorized release of sensitive information due to an authentication error, a credential issued in a manner that provides a Level of Assurance (LOA) 2 (i.e. "Some confidence in the asserted identity's validity)" is needed at a minimum.
Once the minimum needed LOA has been determined, it is straight forward to map that to the type of credentials that can support the needed LOA using the "NIST Electronic Authentication Guideline (SP 800-63-1) [PDF]". But I will emphasize a specific point that is often glossed over or de-emphasized when it comes to this mapping. The term "assurance" has a specific meaning here and is defined as
- the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued (i.e. the identity proofing component) and
- the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued (i.e. the "technical strength" of the credential itself)
The combination of both factors determine the particular credential type that can support a specific LOA, as shown in the table below.
- Likelihood of Alien Invasions and Assurance Levels
- HOW-TO: Incorporate Risk Management into Assurance Level Determination
- HOW-TO: Fast Track to Federation for Web Sites
- How do you define step up authentication?
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.