Meeting the InCommon Assurance profile criteria using Active Directory

["Rank, Mark" <>]

Wouldn't the AAC be a recognized technical authority? 

Mark

--------------------------------------------------

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

--------------------------------------------------

---

From: [] on behalf of Eric Goodman []
Sent: Monday, April 29, 2013 8:48 AM
To:
Subject: RE: [AD-Assurance] Applying FISMA to 800-63

Hmm… Maybe a call with Kantara would make sense? I note that their guidance is the same as we’ve seen elsewhere:

 

660 AL2_CO_SCO#010 Secure remote communications

 

661 If the specific service components are located remotely from and communicate over

662 a public or unsecured network with other service components or other CSPs which

663 it services, the communications must be cryptographically authenticated, including

664 long-term and session tokens, by an authentication method that meets, at a

665 minimum, the requirements of AL2 and encrypted using a [FIPS140-2] Level 1-

666 compliant encryption method or equivalent, as established by a recognized national

667 technical authority.           

 

My emphasis. Anyone know any recognized national technical authorities? :)

 

I do note that this is a little looser than what we’ve been discussing, as it only applies to intra-IdP-service communication over public and unsecured networks.

 

--- Eric

 

From: [mailto:] On Behalf Of Rank, Mark
Sent: Monday, April 29, 2013 8:37 AM
To:
Subject: RE: [AD-Assurance] Applying FISMA to 800-63

 

 

+1

 

--------------------------------------------------

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

--------------------------------------------------

---

From: [] on behalf of Ann West []
Sent: Monday, April 29, 2013 7:59 AM
To:
Subject: Re: [AD-Assurance] Applying FISMA to 800-63

Just want to make sure we're not over thinking this…We are bound by InCommon's specs, not the US Government's. Looking to other docs for ideas on how to address the gaps is certainly appropriate, but we have to be careful not to conflate those with ours.

 

Kantara's specs, another FICAM-approved trust framework, might be just as useful, for instance. 

http://kantarainitiative.org/confluence/display/GI/Identity+Assurance+Framework

 

Ann

 

 

 

From: <Capehart>, Jeffrey D <>
Reply-To: "" <>
Date: Thursday, April 25, 2013 5:19 PM
To: "" <>
Subject: RE: [AD-Assurance] Applying FISMA to 800-63

 

Yes, 800-63 refers to 53 for the controls/assurance, which then refers back to 63 for the technical guidance.  Seems like a circular reference.

 

However, my main point was that the 800-63 needed controls for LOA[1,2,3,4] *SHOULD* be tested/evaluated under an 800-53 (FISMA) audit.  And, I was able to pin-point the specific ones.  In 53, the controls are somewhat generalized, so that’s why the specific guidance refers back to 63. 

 

At the end of the day, the Federal agencies all turn on the FIPS mode and I suspect any technology using Windows probably also requires the FIPS mode be turned on.  Bitlocker is always at least AES-128 CBC.  In FIPS mode, it goes to AES-256.  In non-FIPS mode, it uses an “Elephant diffuser” but the underlying data is still AES-CBC-128.

 

I also found a third-party product which tunnels authentication over a TLS encrypted channel using an agent on clients and the AD domain controller.  The vendor says that just a few of their more than 60 federal customers are NIH, NASA, NIST, NOAA, DOD, US ARMY, Dept. of Commerce, Dept. of Energy…

 

Jeff

From: [] On Behalf Of David Walker
Sent: Thursday, April 25, 2013 5:08 PM
To:
Subject: Re: [AD-Assurance] Applying FISMA to 800-63

 

Oh.  I read that differently.  I think it's a statement of requirements beyond those mentioned explicitly in 800-63, not that 800-53 (a security standard) could be used in lieu of 800-63.  The statement is a little redundant, anyway, as federal agencies are already bound by 800-53.

Maybe we should touch on this during tomorrow's call?

(FYI, I may be a little late for tomorrow's call, as I have another call just before ours.)

David

On Thu, 2013-04-25 at 18:09 +0000, Capehart,Jeffrey D wrote:

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: [] 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