[10664] in bugtraq

home help back first fref pref prev next nref lref last post

Re: ICSA - Certified Sites and Criteria Issues

daemon@ATHENA.MIT.EDU (David Schwartz)
Thu May 27 19:45:59 1999

Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <000401bea892$85efa800$021d85d1@whenever.youwant.to>
Date: 	Thu, 27 May 1999 15:44:47 -0700
Reply-To: David Schwartz <davids@WEBMASTER.COM>
From: David Schwartz <davids@WEBMASTER.COM>
X-To:         Jon McCown <jmccown@ICSA.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <00e201bea87d$7fdb2800$330a1aac@straylight.icsa.net>

	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?)

	DS

> 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.
[snip]
> 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.
[snip]

home help back first fref pref prev next nref lref last post