Re: [scap_interest] Checking language needs

[<[e-mail]>]

(Resending after joining the mailing list officially.)

 

Kent,

 

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: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Tuesday, February 14, 2012 3:02 PM
To: [e-mail]
Subject: [scap_interest] Checking language needs

 

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: [phone]
Web: www.mcafee.com <http://www.mcafee.com/>