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, <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