You can ISO9001 certify the process of shooting yourself in the foot, so long as the process is documented and reliably produces the proper result. Do you require certified sites post their security policy? If not, how do I know that the policy doesn't explicitly accept the presense of phf in /cgi-bin? Would it be possible to have that in my policy and still get certified, if I have good business reasons for putting it in place? This flap may be a result of certifying compliance to policy, but the relying parties on your mark should not be expected to be able to read and understand those policies; they should be able to rely on your mark to say that the policies make sense. Incidentally, do you require sites to post these policies to which you certify compliance? I think that the high level message here (and from the TRUSTe/Microsoft crap) is that what organizations like ICSA and Truste are certifying is not what people who may be expected to rely on those marks expect is being certified. Adam On Thu, May 27, 1999 at 04:14:17PM -0400, Jon McCown wrote: | -----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----- -- "It is seldom that liberty of any kind is lost all at once." -Hume
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:47:26 PDT