Re: [scap_interest] Checking language needs

Karen Scarfone <> Tue, 14 February 2012 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 498F221E80E9 for <>; Tue, 14 Feb 2012 12:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.976
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b-6Ouv5z5D5J for <>; Tue, 14 Feb 2012 12:11:41 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 26FDD21E80EB for <>; Tue, 14 Feb 2012 12:11:26 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTzq/; Tue, 14 Feb 2012 12:11:40 PST
Received: by with SMTP id d3so357864lah.26 for <>; Tue, 14 Feb 2012 12:11:21 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id nl6mr15614331lab.15.1329250281331; Tue, 14 Feb 2012 12:11:21 -0800 (PST)
Received: by with HTTP; Tue, 14 Feb 2012 12:11:21 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 14 Feb 2012 15:11:21 -0500
Message-ID: <>
From: Karen Scarfone <>
Content-Type: multipart/alternative; boundary=f46d043086c0d61cfb04b8f232ed
X-Gm-Message-State: ALoCoQmav9vL4c9z9tALiRmwtUpv8VCRmelfgG3oCcEgw+raMTanYgbXZRBj07TZksehQafseUXT
Subject: Re: [scap_interest] Checking language needs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Feb 2012 20:11:45 -0000


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


On Tue, Feb 14, 2012 at 3:02 PM, <> 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: *
> _______________________________________________
> scap_interest mailing list

Karen Scarfone, Principal Consultant, Scarfone Cybersecurity   (703)401-1018