Re: [scap_interest] IETF SCAP and ITU-T CYBEX synergies and cooperation

Tony Rutkowski <tony@yaanatech.com> Thu, 21 October 2010 17:49 UTC

Return-Path: <tony@yaanatech.com>
X-Original-To: scap_interest@core3.amsl.com
Delivered-To: scap_interest@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7D13A6A1B for <scap_interest@core3.amsl.com>; Thu, 21 Oct 2010 10:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+MLJWP6kfHD for <scap_interest@core3.amsl.com>; Thu, 21 Oct 2010 10:49:29 -0700 (PDT)
Received: from webmail.yaanatech.com (server1.yaanatech.com [66.135.59.213]) by core3.amsl.com (Postfix) with ESMTP id 42B403A68F3 for <scap_interest@ietf.org>; Thu, 21 Oct 2010 10:49:28 -0700 (PDT)
Received: from [192.168.0.11] (pool-71-171-109-164.clppva.fios.verizon.net [71.171.109.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by webmail.yaanatech.com (Postfix) with ESMTP id 93A4F1C78282; Thu, 21 Oct 2010 10:51:03 -0700 (PDT)
Message-ID: <4CC07D86.1070802@yaanatech.com>
Date: Thu, 21 Oct 2010 13:51:02 -0400
From: Tony Rutkowski <tony@yaanatech.com>
Organization: Yaana Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100831 Lanikai/3.1.2
MIME-Version: 1.0
To: Michael Chernin <mchernin@dtcc.com>
References: <OF067986D1.B61A5A12-ON852577C3.005C9E71-852577C3.005D8C79@dtcc.com>
In-Reply-To: <OF067986D1.B61A5A12-ON852577C3.005C9E71-852577C3.005D8C79@dtcc.com>
Content-Type: multipart/alternative; boundary="------------000909020308030903060407"
Cc: Malcolm Johnson <Malcolm.Johnson@itu.int>, scap_interest@ietf.org, Kent_Landfield@McAfee.com
Subject: Re: [scap_interest] IETF SCAP and ITU-T CYBEX synergies and cooperation
X-BeenThere: scap_interest@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: tony@yaanatech.com
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <scap_interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/scap_interest>, <mailto:scap_interest-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/scap_interest>
List-Post: <mailto:scap_interest@ietf.org>
List-Help: <mailto:scap_interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scap_interest>, <mailto:scap_interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 17:49:30 -0000

  Hi Michael,

> I am trying to wrap my head around the CYBEX standard. Is this 
> standard creating new standards that replace existing SCAP standards ? 
> Or is this standard using existing SCAP standards as it's core? Or 
> does this standard simply not care what standard is being used at it's 
> core, as long as its a standard? How does the CYBEX standard impact 
> the SCAP interest list and SCAP's future with the IETF?

First, the CYBEX work is not trying to replace anything!
It's attempting to establish a rough global consensus on
1) a comprehensive, coherent conceptualization of
cybersecurity, and 2) an interoperable, extensible set
of related structured information exchange and associated
discovery and trust specifications

Second, we found over the past year that the term "SCAP
standards" was used very differently in diverse forums
and seems to constantly evolve.   So our ITU-T group chose
to refer to these various usages as "security automation"
schema use cases or tools, and we've begun to avoid
using SCAP.  This also avoids any conflicts with NIST's
SCAP implementation(s) for US federal networks and systems.

In addition, CYBEX clearly encompasses much more than
just security automation.

If one assumes that the SCAP interest list and the resulting
IETF work involves potential application of the various
MITRE/CNIS/FIRST specifications to implementations of IETF
protocols, there is mutual interest in adopting common
conceptualizations and approaches to the extent desired.

There is also value in looking at how other bodies and
user communities are innovating with and implementing
these specifications.  The Japan ISOG-J/NICT example
is a notable one.  Trusted discovery of all the autonomous,
diverse security automation schema is a major emerging
challenge they are especially focussing on.

For reference purposes, it's also useful to know that those
specifications are also being instantiated in ITU-T versions
that will be available in six languages, freely available
online, and evangelized for global cybersecurity use.

Hope this helps.

--tony