[ISN] ICSA - Certified Sites and Criteria Issues (reply)

From: cult hero (jerichoat_private)
Date: Mon May 31 1999 - 05:44:31 PDT

  • Next message: cult hero: "Re: [ISN] What's a Little Hacking Between Friends?"

    Reply From: Jon McCown <jmccownat_private>
    Originally To: BUGTRAQat_private
    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
    SVC0034:    Sensitive Information, as identified in HUF0007 is
    encrypted and uses protocols which are acceptable to both the host and
    [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
    - - Jon McCown, ICSA Labs
    Version: PGP 5.5.5
    -----END PGP SIGNATURE-----
    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