[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 <https://register.mitre.org/dev_days/>) 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
--Woj Matthew N. Wojcik [hidden email]
781 271-8056 office Remediation Standardization
617 872-6247 mobile CCE Project Lead
|Free forum by Nabble||Edit this page|