[10660] in bugtraq
ICSA - Certified Sites and Criteria Issues
daemon@ATHENA.MIT.EDU (Jon McCown)
Thu May 27 18:07:38 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Message-Id: <00e201bea87d$7fdb2800$330a1aac@straylight.icsa.net>
Date: Thu, 27 May 1999 16:14:17 -0400
Reply-To: Jon McCown <jmccown@ICSA.NET>
From: Jon McCown <jmccown@ICSA.NET>
To: BUGTRAQ@NETSPACE.ORG
-----BEGIN PGP SIGNED MESSAGE-----
While I am constrained by NDAs from discussing the specific issues of
any particular ICSA customer's security issues or policy, I will
respond "in general" to Lucky Green's posting regarding the use of
40-bit cryptography as part of an ICSA certified configuration.
Participants in our site certification program (TruSecure) are
required to meet in excess 200 criteria elements; covering such issues
as physical security, business continuity, personnel management,
network architecture, patches and updates, privacy, and sensitive
information handling. Nearly all of the criteria elements are
driven by the customer's security and operational policy-- which is
derived from their business objectives and risk management approach.
The 'specific' criteria elements which govern the use of cryptography
in the context of the customer site are (verbatim):
HUF0007: The handling procedures, security measures, and
classifications for sensitive information are documented in a
Sensitive Data Policy. The procedures identified in the policy are
in place.
HUF0014: The site's Internet Security Policy, as documented on form
TS012.01 - Security Posture and Policy, has been implemented
HUF0027: If client data is gathered by the target, then the site
must publish online its site visitor privacy, and user data security
policies.
SVC0034: Sensitive Information, as identified in HUF0007 is
encrypted and uses protocols which are acceptable to both the host and
user.
[in this context the "host" is the site operator and the "user" is
their client base]
In this context _is_ possible for a customer to mandate (via their
own policy) use of whatever levels of cryptography they view as being
appropriate to their business model and customer requirements. For
example, if a customer policy specifies 128-bit TLS,
client-certificates, and token-based auth-- they will be validated at
that level. And if validating the server's identity to the end-user,
or no-hassle compatibility with zillions of consumers' bargain-club-PC
40-bit browsers is a goal-- a different policy might well result.
Yes, we (ICSA Labs) do agree that 40-bit/8-second, and even 56-bit
encryption have become low-hanging-fruit on the confidentiality tree.
The Gilmore/EFF demonstrations and recent IETF SAG discussions have
put that writing on the wall. Do we need to add an "appropriate
crypto strength" element to the TruSecure criteria? Yes I guess we
do.
- - Jon McCown, ICSA Labs
-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5
iQCVAwUBN02nmaN04bWY62GPAQEwwgP/aJLdrxCNRkRJAtp9mdbVb2+tZttwiLbI
77gbVtbyrFG29iqp/qs0zIz4+ZS73+8fGqisaWgFyRiaM1FJhLXyjQbRVrUkAqJq
F/5cTmuTF9DOwsada+l8iq9ZO+VNk2AAo/TJnqaW3Y0/cNn2+XmA3edSgAEydO5D
Ox4VuVRLLCo=
=Mkwn
-----END PGP SIGNATURE-----
