Subject: [scap_interest] Targeting assessments (Was "RE: Checking language needs")

From: "Schmidt, Charles M." <[email-masked]>
Date: Mon, 20 Feb 2012 23:43:38 +0000

Hello all,

Just to follow up a bit on this thread, particularly on
scheduling/targeting/applicability testing of assessments. These topics have
all been touched on, to a greater or lesser extent, in the XCCDF
discussions. I add these comments mostly to give a little perspective - not to
say that the issues have been decided for good. In general the core question
came down to "what belongs at the XCCDF level vs. what belongs above it."
One of the use scenarios for XCCDF is to have Benchmarks published by some
vendor/authority and then used by many parties. XCCDF incorporates specific
structure to control local tailoring of a published Benchmark, but the
intent is that users should not need to go in and start manually re-writing
the Benchmark's XML before they can use it. Because of this, when the topic
of "scheduling" was raised, the community felt that this would be very
enterprise-specific and, as such, should not be embedded into an XCCDF
document - scheduling requirements from a third party would likely need to
be re-written or new structures would have to be added to XCCDF to allow
enterprise tailoring of scheduling details. The community felt that it would
make more sense for scheduling information to be stored at a level above
XCCDF (either in an even higher-level standard that was used to control
enterprise assessment, or simply in the vendor-proprietary solutions that
did this job).

Using the same yardstick, one can see that applicability, as Dave very
nicely describes it, belongs in XCCDF because that is not going to change
across enterprises - an XP assessment question is always going to be an XP
assessment question no matter who runs it. However, as noted previously,
while XCCDF does a decent job of indicating platform applicability (through
CPE references), there are other types of applicability that it does not
handle as well. These include technical role-based applicability (e.g.,
"these checks are for web-servers", "these checks are for workstations with
high-security requirements") and human role-based applicability (e.g.,
"these questions are for the department web developers"). We did have a
discussion of this gap at a developer session last year, but didn't get too
far. We noted that there were, in effect, two distinct ways in XCCDF to
denote applicability of a set of checks: the automatic CPE applicability
tests (based on platform) and the manual selection of an XCCDF
Profile. The former represent binary applicability (either the target
machine has IE10 installed or it doesn't) while the latter covers set-based
applicability (where a set of Rules might be relevant to several roles). At
the XCCDF developer session we discussed how it might be possible to allow
the automatic selection of a Profile. Briefly, the community considered this
as two problems: labeling of Profiles to designate their roles, and then
automated procedures that mapped a target to a set of roles. Creating
universally meaningful systems for either of these problems was a
significant challenge and, to my knowledge, there hasn't been progress on
this since that meeting.

Targeting then is the ugly step-child of applicability and
enterprise-specific customization. The naive solution would be the
scatter-shot approach: send the XCCDF-based assessment to every possible
target and let applicability checks (and here I am assuming that the
automated Profile selection problem has been solved) ensure that the right
combination of Rules runs on every target. However, this assumes that every
target needs to get assessed on the same schedule, that the XCCDF document
has some applicable checks for every target, and/or that the enterprise's
network can handle a lot of unnecessary traffic. A more, well, targeted
approach to targeting would be the marriage of some higher-level structure
(such as is used to control the scheduling) with some enterprise-internal
tracking system that maps targets (human or platform) to specific XCCDF
Benchmarks so that targets are sent the appropriate assessments at the
appropriate intervals. This, however, suggests a mechanism operating above
the level of the XCCDF Benchmark itself. In our developer discussion, the
example was given of a database that mapped network resources to the
appropriate Benchmark(s).

In the end this all comes down to the overall architecture that XCCDF is
intended to support - what exists above it and what exists below it (the
latter being related to Kent's thread on Checking language needs, which is a
whole other topic). There is currently an SCAP architecture in which XCCDF
is placed and this works well, but, as noted by many of the other messages
on this thread, there are still several open issues. Thus, while solving
many of the challenges outlinedin this and preceding threads are probably
long-term goals, consideration of the higher-level model (or "contracts" 
between
components, as Dave described them) into which we want any proposed XCCDF
standard to reside is probably something good to hash out at the very
beginning of any broadly-scoped effort.

Charles

>-----Original Message-----
>From: [email-masked] [mailto:scap_interest-
>[email-masked]] On Behalf Of Waltermire, David A.
>Sent: Tuesday, February 14, 2012 3:48 PM
>To: Adam Montville; [email-masked];
>[email-masked]
>Cc: [email-masked]
>Subject: Re: [scap_interest] Checking language needs
>
>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 bei
> ng 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:scap_interest-
>[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
>
>From: kent_landfield
><[email-masked]<mailto:[email-masked]>>
>Date: Tue, 14 Feb 2012 14:30:27 -0600
>To:
><[email-masked]<mailto:[email-masked]
>m>>
>Cc: <[email-masked]<mailto:[email-masked]>>
>Subject: Re: [scap_interest] Checking language needs
>
>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: www.mcafee.com<http://www.mcafee.com/>
>
>From: Karen Scarfone
><[email-masked]<mailto:[email-masked]
>m>>
>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,
>
>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/>
>
>_______________________________________________
>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]
>m>   (703)401-1018
>
>_______________________________________________ scap_interest mailing
>list [email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/scap_interest
>
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest