Call for participation in emerging remediation specifications

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Call for participation in emerging remediation specifications

Matthew N. Wojcik
[This list has obviously been stagnant, but I thought it was worth one more cross-post of this announcement to catch anyone who's not on the scap-dev or emerging-specs lists.]


I'd like to invite participation in the development of emerging
specifications for enterprise IT security remediation.  The broad aim
of our work is to enable for remediation the same kind of benefits
that SCAP and related standards have brought to assessment.

In particular, there is a session scheduled on remediation at the
upcoming Security Automation Developer Days Winter 2010, Feb 22 - 24
(see <>) at NIST.  Registration is
still available through 4:00pm EST tomorrow, Friday, Feb 12.

Our goal for the remediation session is to get community input on
topics regarding both technical issues and questions about existing
remediation practices.  Discussions will also be held on the
[hidden email] list, so even if you can't attend Developer
Days, please do participate.

We are currently concentrating on approaches for uniquely identifying
remediation options (similar to CVE or CCE; currently referred to as
CRE), and defining what additional metadata about remediations are
critical to support remediation workflows.  Those who attended
Developer Days at MITRE last June or the remediation sessions at the
ITSAC conference in Baltimore last October have already seen something
of our work.

We need input from a wide range of practitioners at various points in
the remediation / change management lifecycle, including:

 - Primary-source vendors and third parties that provide information
   about remediation options to their customers.  For example, authors
   of security bulletins, patch advisories, vulnerability alerts,
   hardening or configuration guides.  Our focus is on the description
   of remediation, mitigation or workaround options (the "fix" as
   opposed to the "problem" side), and what information is provided.

 - Patch, Remediation, and Configuration Management tool vendors.
   We'd like technical input from those who implement remediation
   automation methods, and also an understanding of what metadata is
   kept regarding remediations, including what information and options
   are made available to users.

 - Remediation policy makers, those who decide what remediations are
   mandatory or optional in their organizations under various
   circumstances.  We seek insight into what information about
   remediations are used to define remediation policy, how remediation
   decisions and assessment activities interact, how policy is
   communicated to IT managers or end users, and what requirements for
   compliance and reporting are involved.

 - IT managers or system administrators.  How is remediation policy
   received, evaluated, and acted on in light of operational
   requirements?  What data is used or would be helpful in
   decision-making about the functional requirements and operational
   impact of, and interaction between, remediation options?

We have several areas where we have specific questions for remediation
practitioners, including questions about "cross-platform"
remediations, how remediations are grouped and related, remediation
prerequisites, supersession, parameters, and provenance.  More details
will be sent to the Emerging Specs list before Developer Days.

The core team currently consists of Chris Johnson of NIST, Matt Kerr
of G2 Inc., and John Wunder and myself from MITRE.  We look forward to
your input.

--Woj                  Matthew N. Wojcik                 [hidden email]
781 271-8056 office                        Remediation Standardization
617 872-6247 mobile                                   CCE Project Lead