Subject: [scap_interest] Checking language needs

From: <[email-masked]>
Date: Tue, 14 Feb 2012 14:02:20 -0600

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<http://www.mcafee.com/>

---

From: Karen Scarfone <[email-masked]>
Date: Tue, 14 Feb 2012 15:11:21 -0500

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, <[email-masked]> 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.
>
> *Kent Landfield*
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
>
>

-- 
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]   (703)401-1018

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 14:30:27 -0600

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

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Karen Scarfone <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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, <[email-masked]<mailto:[email-masked]>> wrote:
All,

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]>   (703)401-1018

---

From: Luis Nunez <[email-masked]>
Date: Tue, 14 Feb 2012 15:33:45 -0500

This sounds like something that would be helpful is understanding the cooperative aspects of the specifications.  Looking at how these specifications (XCCDF, OVAL,...) interoperate from a relationship standpoint would be usefully and could help others in understanding. One of the toughest issues I have is explaining what SCAPOVALXCCDFCPECCEVECVESS is,  let along how they work in concert.

-ln

On Feb 14, 2012, at 3:11 PM, Karen Scarfone wrote:

> Web: www.mcafee.com

---

From: Luis Nunez <[email-masked]>
Date: Tue, 14 Feb 2012 15:45:12 -0500

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.

-ln

On Feb 14, 2012, at 3:30 PM, <[email-masked]> wrote:

> From: Karen Scarfone <[email-masked]>
> To: Kent Landfield <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Adam Montville <[email-masked]>
Date: Tue, 14 Feb 2012 20:50:27 +0000

Kent,

I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).  If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference – a person is targeted as the owner of the given system.

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Thoughts?

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Kent,

Karen

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

_______________________________________________ scap_interest mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/scap_interest

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 16:40:43 -0500

(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: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Tuesday, February 14, 2012 3:02 PM
To: [email-masked]
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.

I am looking for interest here and for those that might want to help me in
producing this draft specification.  

Kent Landfield

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/>

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 14 Feb 2012 16:47:44 -0500

The issues we are discussing can be grouped into the following separate, but related functional areas.  Each should be treated as a separate concern.  Here are some ideas on how to parse out each area:

1) Defining a "checking design pattern" - This de facto pattern is used without a formal specification in many specifications including: XCCDF and the CPE 2.3 Applicability Language.  If we define the pattern properly, establishing a contract between checking clients and checking systems, we can stabilize our existing uses and provide a new foundation for additional checking uses cases.  This may also have the effect of stimulating novel checking solutions for mobile and network devices.  It may also make sense to look at breaking up the logical evaluation capabilities that share some commonality across XCCDF, OVAL and OCIL into a separate specification.  We have talked in the past about using the results of one check system to drive the behavior of another.  This type of approach might provide a mechanism to support that.

2) Enterprise targeting of assets - We currently have no standardized way to associate a checklist and/or a collection of checks with a set of assets that need to be interrogated to determine compliance.  This is definitely a problem for OCIL, but the approach is not formalized for OVAL checks either.  The closest thing we have is the applicability approach used in XCCDF which is not a targeting solution.  I would argue that applicability is something altogether different from targeting.  Applicability allows machine readable guidance to be pre-qualified as being purposed for scanning specific software.  What we desire from a targeting perspective is assignment of a checklist to a collection of assets that contain the applicable software.  Applicability can be used to determine what CAN be assigned, but it is not THE assignment.  It serves a separate purpose.  If we confound applicability and assignment, we risk creating checklists that are specific to an asset instead of being applicable to many assets.  This will hinder content reuse and exacerbate content management challenges.

Instead, it might be better to develop a new higher-level concept that enables definition of organizational digital policy that links rules in a checklist or checks to the appropriate assets that need to be assessed perhaps using ai:asset constructs.  For OCIL the asset in question could be the systems admin that is responsible for a set of hosts.  For OVAL the asset mapping might be to a domain server that provides group policy for a collection of hosts, or a directory server that provides authentication capabilities.  This policy can also indicate the frequency, conditions and timing of assessments, allowing automated tasks to be dispatched based on this information to enact the policy.

3) Tasking and scheduling - Based on the digital policy from the previous item, automated tasks can be created external to scanning applications to instruct them to perform a single scan, a recurring scan, establish a schedule based on a calendar or other conditions (e.g., CPU utilization, network load, etc).  By defining tasking as a separate concern from the assessment content, an organization will have the ability to orchestrate the assessment of a checklists or a collection of checks against many different sets of assets (e.g., people, systems, networks, devices) using independent tasks.  They can also use the same standardized approach to orchestrate different scanning solutions within their environments. This further promotes content reuse and avoids the need to customize content for a specific scanning task or solution.

My hope is that the MILE GRC Exchange specification can be shapped to support a high-level framework that allows detailed task messages to be exchanged using more specialized models (e.g., assessment, remdiation, etc.) as GRC message payloads.

Dave Waltermire

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, February 14, 2012 3:50 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

Kent,

I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).  If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference - a person is targeted as the owner of the given system.

Adam

Thoughts?

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Kent,

Karen

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 16:17:49 -0500

Kent,

I would like to contribute to this effort. I work with the products at EMC to make them secure and enable security among them and other systems, and find SCAP a valuable initiative and set of standards.

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

All,

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 15:57:40 -0600

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?

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

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

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,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, February 14, 2012 3:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [scap_interest] Checking language needs

All,

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 16:53:14 -0600

Dave,

What is your definition of checking clients and checking systems?  I want to make sure I understand. I think we are on the same page but wanted to make sure…

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: David Waltermire <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:47:44 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [scap_interest] Checking language needs

Dave Waltermire

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, February 14, 2012 3:50 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Checking language needs

Kent,

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Thoughts?

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Karen Scarfone <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Kent,

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:
All,

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>   (703)401-1018

_______________________________________________ scap_interest mailing list [email-masked]<mailto:[email-masked]><mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/scap_interest

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 14 Feb 2012 18:14:35 -0500

A checking client would be something like an XCCDF or a CPE Applicability Language processor.

Dave

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 5:53 PM
To: Waltermire, David A.; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

Dave,

What is your definition of checking clients and checking systems?  I want to make sure I understand. I think we are on the same page but wanted to make sure...

Thanks.

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

Dave Waltermire

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, February 14, 2012 3:50 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Checking language needs

Kent,

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Cc: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Checking language needs

Thoughts?

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026

From: Karen Scarfone <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Checking language needs

Kent,

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>> wrote:
All,

Kent Landfield

Direct: +1.972.963.7096
Mobile: +1.817.637.8026