On 11/11/13, 11:02 PM, Jeffrey Blank wrote:
It is also important to note that NIST 800-53 is not a requirements
document.  It is a catalog of security controls (designed to provide a
common vocabulary), from which parties can choose the controls they
wish to implement, often in order to create policy.  CNSSI-1253 is one
such example; DISA SRGs (which are being synchronized with Common
Criteria Protection Profiles) are another example as these represent a
DoD selection from the NIST catalog.

The NIST controls mapped in
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rhel6-nistrefs.html
are subject to great deal of interpretation.  Future patches may bring
these much more in line with DISA's approach (used for the STIG),
which is based on their CCI list (which is itself a deconstructed
version of 800-53, and was created in order to provide the information
from 800-53 in a granular and machine-parseable form).  This approach
seems like a more reasonable way to use 800-53.

Vague association with an 800-53 control, or several 800-53 controls,
as featured in the other table, is not a policy-driven approach; it is
more like a policy-decorated approach, assuming there is any such
policy requiring the implementation of the controls listed there.

Of course, in the absence of any authoritative guidance on how to
effectively use 800-53, it's very much choose your own adventure.  I
suggest choosing one with a degree of clarity, and in which the
benefits outweigh the costs.

From a policy perspective you're correct, NIST 800-53 is just a catalog of controls. For those of us fielding systems, NIST 800-53 has evolved into requirements.

Our information systems are categorized against some CIA level. Depending on the level we're told what NIST 800-53 controls we must follow and given refine values (e.g. password lengths, audit retention, etc), generally in some master control spreadsheet. For example, on a project I'm currently working with, a snippet from our 486 rows of 800-53 requirements:

AC.7.a (U) Red Hat information systems shall enforce a limit of not more than 3 consecutive invalid login attempts by a user during a time period of not more than 15 minutes, regardless of whether the login attempt occurs via a local or network connection.   [Source:  NIST SP 800-53 AC-7, ICS 500-16)]
AC.7.b (U) Red Hat information systems shall automatically lock an account/node for not less than 15 minutes when the maximum number of unsuccessful attempts is exceeded, regardless of whether the login attempt occurs via a local or network connection.  [Source:  NIST SP 800-53 AC-7, ICS 500-16]

(U) Red Hat information systems shall automatically lock the account/node until released by an administrator, after 3 consecutive invalid access attempts by a user, regardless of whether the login attempt occurs via a local or network connection.  [Source:  NIST SP 800-53 AC-7(1), ICS 500-16]
AC.8.a (U) Red Hat information systems shall display a system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance that states:
a. (U)  The user is accessing a U.S. Government information system;
b. (U)  System usage may be monitored, recorded, and is subject to audit;
c. (U)  Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and
d. (U)  Use of the system indicates consent to monitoring and recording.
[Source:  NIST SP 800-53 AC-8]


To demonstrate compliance with AC.8.a, I need to scan against and remediate for set_system_login_banner, enable_gdm_login_banner,  set_system_login_banner.

For AC.7.a, I need deny_password_attempts and accounts_passwords_pam_fail_interval

For AC.7.b, deny_password_attempts_unlock_time

I'm not sure how there is really any room for interpretation that you called out above as the mappings seem cut and dry. Mapping directly against STIG identifiers works great for those who follow the STIG, however that's a small percentage of the broader community. Most need mappings directly against NIST 800-53.