Re: [scap_interest] Checking language needs

Karen Scarfone <karen@scarfonecybersecurity.com> Tue, 14 February 2012 20:11 UTC

Return-Path: <karen@scarfonecybersecurity.com>
X-Original-To: scap_interest@ietfa.amsl.com
Delivered-To: scap_interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498F221E80E9 for <scap_interest@ietfa.amsl.com>; Tue, 14 Feb 2012 12:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-6Ouv5z5D5J for <scap_interest@ietfa.amsl.com>; Tue, 14 Feb 2012 12:11:41 -0800 (PST)
Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with SMTP id 26FDD21E80EB for <scap_interest@ietf.org>; Tue, 14 Feb 2012 12:11:26 -0800 (PST)
Received: from mail-lpp01m010-f53.google.com ([209.85.215.53]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKTzq/6bhtpz2aHYZG0pSBz7Q4DJOcyPLU@postini.com; Tue, 14 Feb 2012 12:11:40 PST
Received: by mail-lpp01m010-f53.google.com with SMTP id d3so357864lah.26 for <scap_interest@ietf.org>; Tue, 14 Feb 2012 12:11:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.128.38 with SMTP id nl6mr15614331lab.15.1329250281331; Tue, 14 Feb 2012 12:11:21 -0800 (PST)
Received: by 10.112.129.167 with HTTP; Tue, 14 Feb 2012 12:11:21 -0800 (PST)
In-Reply-To: <CB6019EB.2C4E5%kent_landfield@mcafee.com>
References: <CB6019EB.2C4E5%kent_landfield@mcafee.com>
Date: Tue, 14 Feb 2012 15:11:21 -0500
Message-ID: <CAAfuYh-yyDTU6i-OewgtAOxUwv5M01hw253TK5znqrMmPOhfYg@mail.gmail.com>
From: Karen Scarfone <karen@scarfonecybersecurity.com>
To: Kent_Landfield@mcafee.com
Content-Type: multipart/alternative; boundary=f46d043086c0d61cfb04b8f232ed
X-Gm-Message-State: ALoCoQmav9vL4c9z9tALiRmwtUpv8VCRmelfgG3oCcEgw+raMTanYgbXZRBj07TZksehQafseUXT
Cc: scap_interest@ietf.org
Subject: Re: [scap_interest] Checking language needs
X-BeenThere: scap_interest@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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/options/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: Tue, 14 Feb 2012 20:11:45 -0000

Kent,

I'd be happy to help with the publication/editing side of specification
development.


Karen

On Tue, Feb 14, 2012 at 3:02 PM, <Kent_Landfield@mcafee.com> wrote:

> All,
>
> One of the missing pieces we have right now is a standardized approach to
> developing new checking languages.  Within fielded XCCDF-enabled products
> today there are multiple checking languages in use. One of them grew up
> with XCCDF (OVAL) and another (OCIL) was developed without much concern for
> how it might be called and used from XCCDF.  The later's adoption rate has
> been seriously impacted because of that.  Additionally, vendors have at
> times introduced their own checking mechanisms to support customer needs
> that could not be supported with the existing checking languages.
>  Scripting is also being done directly from XCCDF benchmarks by multiple
> vendor products.
>
> As we are starting to expand security automation uses, it is important we
> enable innovative approaches to check execution. Not everything can be done
> using the existing model and existing means.  Continuous monitoring uses
> are going to require more flexibility by requiring different means to check
> certain areas than exist today.  Forcing implementers to have to dig thru
> the XCCDF specification to have to figure out how to properly integrate
> with it is an inhibitor. We need to foster alternative means so integrating
> into the the existing security automation architectures and products is not
> so daunting.  Even in areas where something as simple as scripting is used,
> I would be very surprised if two existing implementations could execute the
> same script content because of incompatible implementation approaches.
>  Yes, OVAL is interoperable today but we need to make sure additional
> checking languages have that same potential for interoperability.
>
> From my perspective, the key to the success in fielding a useful framework
> is assuring the right building blocks are in place.  We need to be able to
> leverage those building blocks to expand standards based security
> automation. It is important we document the proper way to develop new
> checking mechanisms if we are to have content and solutions that
> interoperate effectively.  By specifying the practices and items  new
> checking languages need to support, we can expand what is possible with
> security automation using already fielded tools and environments.
>
> I am looking for interest here and for those that might want to help me in
> producing this draft specification.
>
> *Kent Landfield*
> Director Content Strategy, Architecture and Standards
>
> *McAfee | An Intel Company*
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com
>
> _______________________________________________
> scap_interest mailing list
> scap_interest@ietf.org
> https://www.ietf.org/mailman/listinfo/scap_interest
>
>


-- 
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
karen@scarfonecybersecurity.com   (703)401-1018