My thinking is that the passwords would remain in AD and be used for the things they're currently used for. The federation only cares about compliance for assertions sent with the Silver IAQ, so only those transactions need to use a separate authentication method (2-factor, 1-factor, even another password). From the point of view of the IAP, it really doesn't matter if that other authentication is done by AD or a separate verifier, as long as it's possible to map everything to the same set of attributes about the same people.
David
On Thu, 2013-04-25 at 17:52 +0000, Brian Arkills wrote:
From what I've seen of the Microsoft 2 factor AD Support, you can't actually turn off password (single factor) based authentication for a given user account. You can enable 2 factor. You can require that 2 factor be used for all interactive logons, but that isn't the same as requiring it for *all* logons.
Maybe there's an angle here that I'm missing, but every time I hear someone suggest that you could use 2 factor authN to get the IAP requirements specific to passwords, I wonder if folks realize that passwords are still going to be in AD, and they will still be a valid way to get a logon token.
There are ways to mitigate some of that, and I've even initiated a thought exercise among a few folks here at the UW around how we might get creative in trying to prevent password based AD authentication on an account with 2 factor authN enabled. But I don't see anyone talking about that, and frankly, the results of our thought exercise suggested that it might be costly and prohibitive to mitigate. Because of this, I've been thinking that one ask we'd have to Microsoft is that they add a user control that requires 2 factor authN on all logons for that user.
Finally, I'd call attention to something relatively new in the Microsoft authentication technology space called virtual smart cards: http://www.microsoft.com/en-us/download/details.aspx?id=29076. Requires Win8 clients and leverages a computer TPM to store the virtual smart card. Definitely lowers the bar in terms of the cost of deploying 2 factor, but at the cost of using Win8.
From: [mailto:] On Behalf Of David Walker
Sent: Thursday, April 25, 2013 10:28 AM
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
On Wed, 2013-04-24 at 19:06 +0000, Capehart,Jeffrey D wrote:
Because Federal Government systems must be NIST/FISMA compliant*, we have questioned how they can be using Active Directory and still comply with FISMA and specifically the SP 800-63 eAuthentication. 800-63 says if you follow 800-53, you will meet 63. Federal Gov’t is required to follow FIPS and FIPS 200 says you have to follow NIST SP800-53. I have consolidated everything I found from multiple documents in this summary:
800-63 at Level 2 Assurance stipulates that the LOW baseline** security controls for 800-53 are to be used (at a minimum). This works for LOA2 (and Silver). At the MOD and HIGH baselines, multi-factor authentication is required. (For LOW impact systems, multi-factor is only required for administrators with privileged access. See supplementary info on IA-2.)
So, can you get around passwords with multi-factor? No. If you use passwords, you still have to meet the same requirements in both 800-53 and 800-63: Encrypted transmission/storage, as well as Approved Algorithms. This is very clearly stated (see excerpts). However, you could use the “multi-factor” hardware device as a single-factor and eliminate passwords from the user and meet LOA2.
The NIST SP-800-53 controls that cover password encryption for storage and transmission are:
IA-2 User Identification and Authentication (Users)
IA-5 Authenticator Management
There is also an “A” version of 800-53 that offers a guide for assessing controls. The old 53A document provided supplemental guidance such as this statement below, but it is no longer in the current guide as updated for 2010.
“Unless a more stringent control enhancement is specified, authentication for both local and remote information system access is NIST Special Publication 800-63 level 1 compliant.”
FISMA Security Controls are being updated and reviewed with some 200 new controls being added. NIST anticipates the release of Special Publication 800-53, Revision 4 by the end of April 2013****.
The current 800-53 Rev3 has the following (specific) requirements under IA-5: (and not much changes in the Rev4 draft)
[IA-5]Control:The organization manages information system authenticators for users and devices by:
[…]
h. Protecting authenticator content from unauthorized disclosure and modification; and
i. Requiring users to take, and having devices implement, specific measures to safeguard authenticators.
Supplemental Guidance:
The requirement to protect user authenticators may be implemented […] by controls AC-3, AC-6, and SC-28 for authenticators stored within the information system (e.g., passwords stored in a hashed or encrypted format, files containing encrypted or hashed passwords accessible only with super user privileges). [note: Control SC-28 is PROTECTION OF INFORMATION AT REST. ]
In addition to standard controls for IA-5, the following Control Enhancement (1) is required. As you can see in (1)(c), passwords must be encrypted in storage and transmission.
[IA-5] Control Enhancements:
(1)AUTHENTICATOR MANAGEMENT|PASSWORD-BASED AUTHENTICATION
The information system, for password-based authentication:
(a) Enforces minimum password complexity of [Assignment: organization-defined requirements for case sensitivity, number of characters, mix of upper-case letters, lower-case letters, numbers, and special characters, including minimum requirements for each type];
(b) Enforces at least [Assignment: organization-defined number of changed characters] when new passwords are created;
(c) Stores and transmits only encrypted representations of passwords;
(d) Enforces password minimum and maximum lifetime restrictions of [Assignment: organization-defined numbers for lifetime minimum, lifetime maximum];
(e) Prohibits password reuse for [Assignment: organization-defined number] generations; and
(f) Allows the use of a temporary password for system logons with an immediate change to a permanent password.
Supplemental Guidance:This control enhancement applies to single-factor authentication of individuals using passwords as individual or group authenticators, and in a similar manner, when passwords are part of multifactor authenticators. This control enhancement does not apply when passwords are used to unlock hardware authenticators (e.g., Personal Identity Verification cards). The implementation of such password mechanisms may not meet all of the requirements in the enhancement. Encrypted representations of passwords include, for example, encrypted versions of passwords and one-way cryptographic hashes of passwords. Password lifetime restrictions do not apply to temporary passwords.
Related control: IA-6.
Additionally, IA-7CRYPTOGRAPHIC MODULE AUTHENTICATIONis required at all levels and is the piece that requires Approved Algorithms for encryption. FIPS 140-2 is the requirement, via reference, because FIPS is required for Federal Gov’t.
[IA-7] Control:The information system uses mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.
References:FIPS Publication 140-2;
So, in summary, there is nothing specific for Microsoft Active Directory, but my reading of all these documents left me with a reasonable expectation that Assurance Level 2 could be achieved with compliance to NIST SP-800-53 at the LOW impact level. Anything higher (MOD/HIGH impact or Assurance Levels 3-4) would require multi-factor for all users.
I also discovered some interesting guidance for passwords on industrial control systems, but typically that guidance was suggested for non-network connected systems (i.e. air-gap) and relying on increased physical security.
Jeff
Supplementary Info:
NIST SP 800-53 Security Control Baselines** are rated for (LOW, MOD, HIGH) impact systems as determined by performing a NIST SP 800-30 Risk Assessment*** on the information system using the 800-37 Risk Management Framework (RMF). OMB 04-04 has a table for Assurance Level to Impact Level mapping.
IA-2 (User Identification and Authentication)requires control enhancement (1) at all levels.
Therefore at least one multi-factor enhancement is required. HOWEVER, for the LOW level, the multi-factor only applies to privileged accounts (usually administrative access). The IA-2 control is a PRIORITY 1 control which means Implement First. Control enhancements (2), (3), (4), (8), and (9) only apply to the MOD and HIGH as shown in this table excerpt for IA-2.
|
P1
|
LOWIA-2 (1)
|
MODIA-2 (1) (2) (3) (8)
|
HIGHIA-2 (1) (2) (3) (4) (8) (9)
|
Control Enhancements:
(1) The information system uses multifactor authentication for network access to privileged accounts.
(2) The information system uses multifactor authentication for network access to non-privileged accounts.
(3) The information system uses multifactor authentication for local access to privileged accounts.
(4) The information system uses multifactor authentication for local access to non-privileged accounts.
FOOTNOTES:
*While federal agencies are required to follow certain specific NIST Special Publications in accordance with OMB policy, there is flexibility in how agencies apply the guidance. Federal agencies should apply the security concepts and principles articulated in the NIST Special Publications in accordance with and in the context of the agency’s missions, business functions, and environment of operation. Consequently, the application of NIST guidance by federal agencies can result in different security solutions that are equally acceptable, compliant with the guidance, and meet the OMB definition of adequate security for federal information systems. When assessing federal agency compliance with NIST Special Publications, Inspectors General, evaluators, auditors, and assessors, should consider the intent of the security concepts and principles articulated within the specific guidance document and how the agency applied the guidance in the context of its mission/business responsibilities, operational environment, and unique organizational conditions.
**Organizations have flexibility in applying the baseline security controls in accordance with the guidance provided in Special Publication 800-53. This allows organizations to tailor the relevant security control baseline so that it more closely aligns with their mission and business requirements and environments of operation.
***50The execution of the RMF includes the selection of an initial set of security controls employed within or inherited by an organizational information system followed by a control tailoring and supplementation process. The tailoring and supplementation process will likely change the set of security controls that will be contained in the final security plan. Therefore, the selection of assessment procedures from the catalog of available procedures is based solely on the content of the security plan after the tailoring and supplementation activities are completed.
**** FISMA NEWS
{Jan. 18, 2013} – NIST anticipates the release of Special Publication 800-53, Revision 4, Security and Privacy Controls for Federal information Systems and Organizations (Final Public Draft) on Tuesday, February 5th. The final public comment period will run from February 5th through March 1st. Final publication is expected by the end of April. Update from Ron Ross: Rev 4 to be released April 30, 2013.
Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882
http://oia.ufl.edu
|
