Re: [scap_interest] Checking language needs

<> Tue, 14 February 2012 23:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DEBF21E80D4 for <>; Tue, 14 Feb 2012 15:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iBx1no-dS4pM for <>; Tue, 14 Feb 2012 15:04:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8F16A21E800E for <>; Tue, 14 Feb 2012 15:04:04 -0800 (PST)
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EN43l2030927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 18:04:03 -0500
Received: from ( []) by (RSA Interceptor); Tue, 14 Feb 2012 18:03:47 -0500
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id q1EN3llx031397; Tue, 14 Feb 2012 18:03:47 -0500
Received: from ([]) by ([]) with mapi; Tue, 14 Feb 2012 18:03:47 -0500
From: <>
To: <>, <>
Date: Tue, 14 Feb 2012 18:03:46 -0500
Thread-Topic: Checking language needs
Thread-Index: AczrbOd6uRbJl+gYSBCNuDwP2hKpaA==
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 23:04:05 -0000

Some of the challenges my team stumbled on adopting (and adapting to) SCAP were the sheer volume of formats and lack of clarity knitting all the disparate pieces together. For example, you mentioned OVAL and OCIL, and how the latter has limited adoption. I found the idea of OCIL is good, but the execution of how to properly and concretely stitch it together with XCCDF and/or OVAL can be confusing; in an older version of the SCAP/XCCDF reference material, OCIL is mentioned as a supported check language in an opening paragraph but not in any example later in that document. I also think there is a "missing link" that accurately/clearly describes the methods for coordination between multiple check systems (if there is such a guide I would be interested to understand it).

Part of the specifications that you are suggesting should include information on the development of "primitives" in the check language - at the very least with a clear indication of how these building blocks are to be used, how they interact, and basic supported interfaces for interaction. The specification(s) should be clear to new adopters, to encourage new adoption, as well as innovation, and perhaps to enable better decision making in the future around when a new check language (or policy language, etc) is necessary compared to adapting an existing mechanism.

At the very least, the process of producing specifications can help identify areas for improvement in things like documentation or guidance, to help new folks and those already familiar with the vast body of knowledge.

Just some initial thoughts as someone relatively new to this process.

--Matthew Coles | Product Security Office | RSA, the Security Division of EMC

-----Original Message-----
From: []
Received: Tuesday, 14 Feb 2012, 16:58
To: Coles, Matthew []; []
Subject: Re: Checking language needs

Hi Matthew,

Great, I'll take you up on that! I do think that we need to discuss what a specification like I suggested below would contain. I see a few posts that suggest the need is there but we may want to discuss the focus of the document a bit more. 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

From: "" <>
Date: Tue, 14 Feb 2012 15:40:43 -0600
To: Kent Landfield <>om>, "" <>
Subject: RE: Checking language needs

(Resending after joining the mailing list officially.)


I would like to contribute to this effort, in whatever capacity that would be valuable. I work with the products at EMC to make them secure and enable security
among them and other systems, and find SCAP an important initiative and set of standards.

Thank you,

Matthew Coles | Product Security Office | RSA, the Security Division of EMC

From: []
On Behalf Of
Sent: Tuesday, February 14, 2012 3:02 PM
Subject: [scap_interest] Checking language needs


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

--Matthew Coles | Product Security Office | EMC Corporation