Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

>>I also agree that “should” vs. “must” is an important distinction, as I pointed out back in August. 

>>However, I don’t have a feeling for how auditors would look at the difference.  I hope to persuade them on the point.

 

I found the normative reference!  [SKIP DOWN FOR FULL DEFINITIONS]

 

MUST   == REQUIRED

SHOULD == RECOMMENDED (but you can wiggle out of it)

MAY    == OPTIONAL

 

Direct your auditors this way to the official language. Be sure there are “valid reasons”, that “full implications are understood”, and that you can document that you “carefully weighed before choosing” and you should be OK.

 

…[on 4.2.3.6.2]

>campuses could choose not to use Protected Channels for these operations and claim compliance because it’s not required though that means there’s no standard for positively meeting the requirement if Protected Channels are not used.

 

Now, considering this is Silver == MODERATE ASSURANCE, who wants to make that call (and justify it for all members) in the cookbook?

 

I know some of you don’t like to put examples in the cookbook, but, for example, a statement could be “although this particular item isn’t absolutely required, the reason we think the item is specified (Approved Algorithm) is to protect the data.  We are doing the part that says to use encryption, it just isn’t a Protected Channel but we think the encryption is good enough because…”

 

[Here’s where to create supporting statements that document your valid reasons and give implications and careful weighing.  Feel free to add your own suggestions.  These are merely provided for brainstorming, not as actual rationalizations.]

·         the encryption being used is strong (128 bit) encryption

·         the non-approved algorithm (RC4, NTLMv2) has not been demonstrated to be broken/cracked based on the way we are using it

·         the network paths where the authentication events occur are restricted to our internal network only, which is a switched network, limiting ability for interception by casual users

·         it is not practical to require non-IdP authentication events to use HTTPS protocol to ensure a protected channel in Microsoft AD DS

·         protecting all channels using IPsec is not practical within our environment

·         we have upgraded all our windows environments to prefer Kerberos authentication with approved algorithms but Microsoft can’t guarantee all Windows authentication events will use Kerberos and our environment is too large to upgrade to the 2012 version until our 5 year hardware replacement cycle is completed

·         we are monitoring for authentication events that use NTLMv1 and dropping the assurance level for users with violations within 72 hours when detected

·         the secret, if it were intercepted, would only be usable within a small timeframe, thus limiting risk and exposure

·         our secrets are minimum length X which would require Y days to guess with a powerful computer by which time the user would have changed their password

·         we interpret “services” in this section to mean services on a computer server, as in “client – server” computing, and not authentication events originating from an end user desktop, laptop, or mobile device

 

-Jeff

 

 

[RFC 2119] Best Current Practice

RFC Key Words

March 1997

 

 

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the

   definition is an absolute requirement of the specification.

 

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the

   definition is an absolute prohibition of the specification.

 

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there

   may exist valid reasons in particular circumstances to ignore a

   particular item, but the full implications must be understood and

   carefully weighed before choosing a different course.

 

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that

   there may exist valid reasons in particular circumstances when the

   particular behavior is acceptable or even useful, but the full

   implications should be understood and the case carefully weighed

   before implementing any behavior described with this label.

 

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is

   truly optional.  One vendor may choose to include the item because a

   particular marketplace requires it or because the vendor feels that

   it enhances the product while another vendor may omit the same item.

   An implementation which does not include a particular option MUST be

   prepared to interoperate with another implementation which does

   include the option, though perhaps with reduced functionality. In the

   same vein an implementation which does include a particular option

   MUST be prepared to interoperate with another implementation which

   does not include the option (except, of course, for the feature the

   option provides.)

 

 

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

http://oia.ufl.edu