Reply From: Jon McCown <jmccownat_private> Originally To: BUGTRAQat_private -----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----- -o- Subscribe: mail majordomoat_private with "subscribe isn". Today's ISN Sponsor: OSAll [www.aviary-mag.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:24:07 PDT