Re: [scap_interest] Checking language needs

Luis Nunez <> Tue, 14 February 2012 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3042421E80E2 for <>; Tue, 14 Feb 2012 12:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uLOBGewsPVHk for <>; Tue, 14 Feb 2012 12:45:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D7CBF21E8018 for <>; Tue, 14 Feb 2012 12:45:14 -0800 (PST)
Received: by ghbg16 with SMTP id g16so338181ghb.31 for <>; Tue, 14 Feb 2012 12:45:14 -0800 (PST)
Received: by with SMTP id u73mr29164639yhh.99.1329252314393; Tue, 14 Feb 2012 12:45:14 -0800 (PST)
Received: from [] ( []) by with ESMTPS id l2sm1202256anq.12.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 12:45:14 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FB1772F-2054-4A49-BE65-36E8D93A047F"
From: Luis Nunez <>
In-Reply-To: <>
Date: Tue, 14 Feb 2012 15:45:12 -0500
Message-Id: <>
References: <>
To: <>
X-Mailer: Apple Mail (2.1257)
X-Gm-Message-State: ALoCoQmZFE3cfauHeIbbXmO37xOMwhkgJKMD3frpm3zbBx4MYsCXPyeed2Cht1qQyemrE9IFqlUG
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:45:16 -0000

I would think "targeting and scheduling for interrogative checking..." would be part of the document.

XCCDF is the benchmark for security automation checking.
OCIL is the human intervention for checking.

The Security Technical Implementation Guide (STIG) as an example has both automation (XCCDF) and manual verification checks (OCIL). Although the the most STIGs come in XCCDF format I know of no OCIL that accompanies it (Yet). It would be good to have guidance on how one would cover both.


On Feb 14, 2012, at 3:30 PM, <> wrote:

> Thanks Karen!  I'll take you up on that!
> From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?
> Thoughts?
> 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:
> From: Karen Scarfone <>
> Date: Tue, 14 Feb 2012 14:11:21 -0600
> To: Kent Landfield <>
> Cc: "" <>
> Subject: Re: [scap_interest] Checking language needs
>> 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, <> 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
> _______________________________________________
> scap_interest mailing list