1 |
- "4.1.2 Interpretation of IAP requirement, S=
ection 4.2.3.4 - Stored
Authentication Secrets"
"We interpret this requirement to mean that encryption softwa=
re that
decrypts disk sectors (and not just individual Authentication=
Secrets)
as they are accessed would meet the requirement of "only decr=
ypt(ing)
the needed Secret when immediately required for authenticatio=
n" as
spelled out in this section, presuming such software uses App=
roved
Algorithms for the encryption process."
As written, this would be overbroad, e.g., decrypting a neede=
d secret
for one individual might result in the decryption of MULTIPLE=
secrets, e.g., the one for that individual AND ones used by o=
thers.
As such, that would violate the requirement that passwords mu=
st
"only [be] decrypted when immediately required for authentica=
tion"
because you're also potentially decrypting OTHER passwords th=
at are
not needed at all. This would represent a failure to meet the=
requirement, at least from my POV.
In the extreme case, imagine a person proposing to use boot t=
ime
whole disk decryption: while off, the disk may be encrypted w=
ith an
Approved Algorithm, but upon boot, the entire disk is decrypt=
ed,
including the password store, which is then "immediately" (an=
d
intermittently) used until the system is eventually shut down=
. Would
that be satisfactory/sufficient to meet the requirement? I do=
n't
think so.
Remember that presumably the goal is to limit the exposure of=
passwords to unauthorized access or misuse. If the passwords =
are
routinely held in non-encrypted form whenever the system is "=
live",
except briefly during boot time when the system is coming up,=
it
isn't clear to me that the encryption protects against any ex=
posure
except theft of the disk from a quiescent system. Any attack =
against
the password store while the system is live would not require=
the
attacker to decrypt the password store if the password store =
is
routinely decrypted at boot time.
Thus, I explicitly reject the argument advanced in 5.1.1 late=
r in
the document.
-- "5.1.2 Remove Insecure (LMHASH) Stored Secrets"
Good to see you recommend removing LMHASH'd passwords. Howeve=
r,
unfortunately, you ALSO insist that NTLM ALSO not be used,
consistent with:
http://msdn.microsoft.com/en-us/library/cc2367=
15.aspx
http://technet.microsoft.com/en-=
us/library/dd560653%28WS.10%29.aspx
Note that you will run into issues if you have an environment=
that
uses antique versions of Windows (Vista, 2008, XP, etc.), but=
those
systems should be getting upgraded or taken off the wire anyh=
ow.
If you can't break use of NTLM entirely, at least break NTLMv=
1, see
http://support.microsoft.com/kb/2793313
[Oh! I see that you talk about this in 5.3.2, as well... but =
you
imply that NTLMv2 is "reasonably secure" -- it isn't]
-- "5.2.1 Transmission of Authentication Secrets Between Credential
Stores"
In the bulleted item, the text current reads "select one of t=
he AES
options"
There are only two options: AES128_HMAC_SHA1 and AES256_HMAC_=
SHA1
Of the two, AES256_HMAC_SHA1 would be preferable, but it stil=
l uses
SHA1 which is deprecated/will be deprecated as the document i=
tself
notes at 2.3 in bold text. <=
br class=3D"atl-forced-newline">
This section also requires use of LDAPS (TLS/SSL), but more <=
br class=3D"atl-forced-newline">
specificity is needed when it comes to explaining what consti=
tutes
an acceptable version of TLS (e.g., is TLS 1.0 good enough? I=
t
shouldn't be treated as such). Require TLS 1.2 with an approp=
riate
cipher suite (that should be a whole section of its own)
The Microsoft references in document section 5.3.1 ("Section =
4.2.3.6.2
requirements") really don't clear this up, either.
-- 5.3.4
How would a "temporarily compromised" account be rehabilitate=
d? If an
account is every "temporarily compromised," it would need to =
have a
thorough security audit before being re-enabled, but my worry=
is that
in some cases folks may just require a password change, and t=
hat
obviously wouldn't be enough to ensure that a "temporarily
compromised" account has been restored to a trustworthy state=
.
Trivial example: assume that while "temporarily compromised" =
a
backdoor was installed, or access controls were weakened, all=
owing
persistent access and abuse, even if the password's changed. =
Also, this doesn't treat the possibility of a privileged acco=
unt
being "temporarily compromised", in which case the entire sys=
tem
(or even multiple systems, in the case of transitive trust
relationships) may need to be audited and remediated.
-- 6. "Alternate Controls and Alternative Means Statements"
When I try to access the link in this part, I get an access f=
ailure.
-- 7.1
Repeats the unsatisfactory use of a full disk encryption tool=
approach. Still not okay.
-- 7.3
is the bold text "need to validate algorithm to see if this i=
s
good enough" an author's note that was meant to be resolved p=
rior
to publication?
I also have a concern about the 72 hour window mentioned in t=
he
last paragraph of that section. 72 hours is an eternity for a=
n
attacker, and might as well be six months if you're going to =
make
it 72 hours.
As suspected, too, I note that the "temporarily compromised" =
account is just required to have credentials reset. That's no=
t
enough, as previously discussed.
-- 7.4
Practical attacks against NTLMv2 exist.
Example.
Repeats the unacceptable "temporarily compromised" language. =
(yes, Zack is in the running for one of the top 10 most annoy=
ing
presenters of all time, but still)
-- 7.6
If a persistent password is used, how does it preclude a repl=
ay
attack? The persistent password is the same thing this time, =
and
next time, and the time after that, etc.
A replay-resistent credential would be something like a one-t=
ime
crypto fob -- you can't replay that credential because it's d=
ifferent
every time you use it...
-- Appendix A
Recommend removal/decommissioning of all Windows XP systems. =
-- Appendix B
Has the Cisco issue been filed with Cisco Security Intelligen=
ce
Operations? If not, a case should be opened. See
http://tools.cisco.com/security/center/home.x <=
/td>
| Joe St Sauver |
Oct 2, 2013 |
6. FIXED |