Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

David,

 

Excerpting directly from SP-800-63-1 in the Purpose/Introduction, my interpretation of the guidance at step 4 is that completing an SP-800-53 assessment (FISMA) is acceptable for validating that the required controls for the appropriate assurance level have been met.

 

OMB guidance outlines a 5 step process by which agencies should meet their e-authentication assurance requirements:

 

1.      Conduct a risk assessment of the government system

 

2.      Map identified risks to the appropriate assurance level [OMB M-04-04]

 

3.      Select technology based on e-authentication technical guidance

 

4.      Validate that the implemented system has met the required assurance level – As some implementations may create or compound particular risks, agencies should conduct a final validation to confirm that the system achieves the required assurance level for the user-to-agency process. NIST SP 800-53A [SP 800-53A] provides guidelines for the assessment of the implemented system during the validation process. Validation should be performed as part of a security authorization* process as described in NIST SP 800-37, Revision 1 [SP 800-37].

 

5.      Periodically reassess the information system to determine technology refresh requirements

 

This is just a small piece from SP-800-37.

*Security authorization is the official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.

 

Supplemental Guidance: The security authorization package contains: (i) the security plan; (ii) the security assessment report; and (iii) the plan of action and milestones. The information in these key documents is used by authorizing officials to make risk-based authorization decisions. For information systems inheriting common controls for specific security capabilities, the security authorization package for the common controls or a reference to such documentation is also included in the authorization package. When security controls are provided to an organization by an external provider (e.g., through contracts, interagency agreements, lines of business arrangements, licensing agreements, and/or supply chain arrangements), the organization ensures that the information needed for authorizing officials to make risk-based decisions, is made available by the provider.

Additional information can be included in the security authorization package at the request of the authorizing official carrying out the authorization action. The contents of the security authorization package are protected appropriately in accordance with federal and organizational policies. Organizations are strongly encouraged to use automated support tools in preparing and managing the content of the security authorization package…

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu

 

 

From: [mailto:] On Behalf Of David Walker
Sent: Thursday, April 25, 2013 1:28 PM
To:
Cc: DHW
Subject: Re: [AD-Assurance] Applying FISMA to 800-63

 

Jeffrey,

A lot of good information!  Here are some thoughts...

• Regarding using multi-factor to get around passwords, 800-63 is pretty clear that a level 3 or 4 token can be used to satisfy level 2, and those can be multi-factor.  In the AD context, that would mean that wouldn't use the AD password at all for LoA-2 authentication, only the LoA-3/4 token, which seems to be NASA's strategy for LoA-4.  There are also the single-factor, non-password, tokens that are described in 800-63-2, as you've mentioned.  It's my hope that these devices will help many institutions achieve Silver, particularly when Silver certification is required only for a subset of the institutions' communities.
• You're right that there are still password requirements for multi-factor tokens (when one of the factors is a password).  I'll note, though, that they are considerably less stringent than single-factor passwords.  Those are described in FIPS 140-2.
• I'm not sure what you mean by "800-63 says if you follow 800-53, you will meet 63."  Do you mean for specific 800-63 requirements?

David