-----BEGIN PGP SIGNED MESSAGE----- I'm taking it upon myself to respond for Jon who's busy trying to have a life outside the office. As he did, I'm going to try to steer clear of a specific discussion of any of our customers. We thank the open review process of the total crypto community for bringing this to our attention. We will include this discussion in our ongoing process to maintain the TruSecure criteria. I'd like to restate what I feel is the most pertinent criterion that bears on this issue: the criterion requires encryption and protocols acceptable to both the host and the client. As a practical matter, for web activity this is either 40-bit SSL or 128-bit SSL. The TruSecure customers have the flexibility to choose, and their customers, in turn, decide if this is "acceptable." Clearly, most of the readers of these lists regard 128-bit SSL as the minimum they would find acceptable. However I think those same readers would acknowledge that the majority of users on the Internet worldwide today are using a 40-bit version of the popular browsers. A business has every right to decide if 40-bit SSL is the level of security they feel is appropriate for the information they are processing. A TruSecure customer may make a business decision that 40-bit SSL is "acceptable" for the communication of data from their hosts to their clients. Once this decision is made, they may configure their systems for 40-bit only. It should be clear from Jon's previous message that, in the abstract, 128-bit SSL is preferable to 40-bit SSL. However, 40-bit SSL for all it's faults, protects data in transit from the client to the host from all but a targeted attack by an experienced, well-resourced adversary. 40-bit SSL provides superior security than the majority of meatspace exchanges of sensitive information. At 07:53 PM 5/27/99 -0400, David Schwartz wrote: > > So does ICSA certification mean simply that a company has met its own >requirements? (As opposed to some set of objectively validated or >ICSA-imposed requirements?) Certification requires compliance with our criteria. The best web page we have describing this is: http://www.trusecure.net/process.html If you want the nitty gritty details, browse to http://www.trusecure.net/ and either go to the library or click the "contact us" link. ICSA helps customers address risks across multiple categories (physical, hacking, malicious code, spoofing, eavesdropping, lack of knowledge/awareness, lack of trust, DoS, privacy-user by site & data subject, lack of interoperability). We developed a methodology to focus on high risk/cost categories and follow this methodology with our customers. When addressing the issue of privacy, ICSA approaches the matter by addressing the risk of capturing customer information across the wire and as it resides on the customers server. We do require the use of encryption but choose to let the customer to decide the level based on the assets they are protecting, the impact to their business, and the fact that the real concern is the data residing on the server un-encrypted. ICSA therefore works with our customers to set up multiple layers of synergistic controls that not only address the use of encryption but also those mentioned above. We rely on addressing our customers' issues not only from a technology perspective, but from a business level one as well. When deploying security, ICSA will always address how technology impacts our customers operations and costs. At 07:31 PM 5/27/99 -0400, Adam Shostack wrote: >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? > For the purposes of site certification we would not certify a site with phf in the cgi-bin directory. Our criteria do restrict this. However, we have customers who have purchased TruSecure but have "good business reasons" for ignoring or violating one or more of our criteria. ICSA has a process to review these occurrences and have withheld certification from some of these customers. Indeed, we have customers who are quite satisfied with their TruSecure purchase without achieving certification. Without turning into a sales/marketing droid, we try to emphasize TruSecure as a process to provide acceptable security to the customer; many customers are satisfied without completing certification and know this before their purchase. >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? > Certified sites must post a privacy and user data security policy as part of our criteria. We do not require the site to post their security policy. Most enterprises would be reluctant to post an un-santitized version of their security policies which opens the question of how much sanitization is necessary or desirable. I don't believe it would be wise to require they post the nitty gritty details of their policies. One would not want details such as these widely known: Inbound telnet is blocked except from IP xxx.xxx.xxx.xxx to yyy.yyy.yyy.yyy which is permitted so Y Inc can review progress reports on Project Z. Employees assigned to our office in Sri Lanka will use PPTP to host at zzz.zzz.zzz.zzz to access the company intranet. At 07:36 PM 5/27/99 -0400, Russ wrote: >However, the bottom line is that; > >- They are *NOT* employing "sophisticated encryption", they're employing >the least sophisticated deployable. > I can't respond to this directly. >- They also say ICSA "examined every aspect of our security >precautions", but in fact, you only examined those aspects defined in >their policies. For any customer, we examine every aspect defined by *our* criteria, which includes examining their security policies and implementations, but these two aspects are but a handful of the 200+ criteria we include in TruSecure. > >- They also claim that because of your certification, their customers >"know ConsumerInfo.Com's security measures are state-of-the-art" when in >fact their *NOT*. This issue is with the semantics on a page not maintained by ICSA. > >I will not, at this time, question the integrity of ICSA. Nor will I >suggest that ConsumerInfo.Com is out and out lying. > >I will, however, suggest that ICSA is tacitly allowing ConsumerInfo.Com >to mislead their customers via the ICSA Web Certification approval. By >ICSA not being permitted, by NDA, to discuss certification they have >performed, it renders, IMNSHO, the certification itself *worthless*. It >would appear that ConsumerInfo.Com has been allowed to say anything they >want about their work with ICSA and, by NDA, ICSA cannot rebuke it. > The way this paragraph is constructed makes it impossible to respond to it. We would like to respond, and explain how certification is not as you say, "worthless," but to do so would be to reveal confidential information about a customer. At 07:36 PM 5/27/99 -0400, Lucky Green wrote: > >Now I am really getting worried. From your post it is clear that you, a >representative of ICSA, are unaware that by enabling 128 bit TLS/SSL on a >server you by no means prevent users limited to 40 bit crypto from accessing >it. > Incorrect, we understand this fact. Again, the criteria require encryption and protocols acceptable to both the host and the client. Popular browsers provide the capability for users to click on an icon and determine the encryption being used, if any. Undoubtedly that's how this thread started. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQCVAwUBN07+V/GfiIQsciJtAQECrgQA3IsyfP6AEWV4OarIG5xs46sIWP/IdSYQ sWvEYaENjbFdyu8tOH2hq5y1bm9/ALM8nITz94zYs/kZupJ2XZR5GYFhOpyfbG2v 4qzL1pml8Ht2aKsJ+r6Ghf9cp2qOfCejigSWcHTfRLNhgoI2u1CL6G6ua3OkDBS8 5KVOeNhwDK0= =GqTy -----END PGP SIGNATURE----- Regards, David Kennedy CISSP Director of Research Services, ICSA Inc. http://www.icsa.net Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench. Gene Spafford
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:47:33 PDT