[10672] in bugtraq
Re: ICSA - Certified Sites and Criteria Issues
daemon@ATHENA.MIT.EDU (David Kennedy CISSP)
Fri May 28 17:53:28 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3.0.5.32.19990528163903.00802970@pop.site1.csi.com>
Date: Fri, 28 May 1999 16:39:03 -0400
Reply-To: dmkennedy@COMPUSERVE.COM
From: David Kennedy CISSP <dmkennedy@COMPUSERVE.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199905271936_MC2-7761-A04E@compuserve.com>
-----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
