To all:
While XCCDF may be able to provide for remediation, the use of the fix tag or other
mechanism has not been decided upon. There is limitations to the use of the fix tag only,
and It has been my experience that other methods have been proposed that may require a
modification to the XCCDF specification.
Note that since that CRE is “name spaced” it will require cross references for
remediation/mitigation solutions to be able to reference your CRE123 against my CRE123
since there is no centralized management or assignment for CRE. It would be useful if
those that used it to posted their listings to an open source web site for cross
reference.
Mike Kinney
From: remediation-dev-bounces(a)nist.gov [mailto:remediation-dev-bounces@nist.gov] On Behalf
Of david.oliva(a)verizon.net
Sent: Sunday, April 07, 2013 8:25 PM
To: lnunez(a)mitre.org; scap-security-guide(a)lists.fedorahosted.org; slukasik(a)redhat.com;
sacm(a)ietf.org
Cc: remediation-dev(a)nist.gov; open-scap-list(a)redhat.com
Subject: Re: [remediation-dev] [Open-scap] Remediation Scripts
To all:
In reading IR 7670 (Enterprise Remediation) and CRE (IR 7831) the following possibilities
are perhaps noteworthy.
1. "Initial discussion of the requirements for Remediation Policy Specification
suggests XCCDF could potentially be used for this purpose" paragraph 2.5 IR 7650.
2. CRE identifies two kinds of remediation. One is for software patching and the other is
"mitigation workaround" solutions.
XCCDF may be used for patching or for mitigation workarounds (or compensating
mechanisms).
3. It may be possible to associate CRE with CCE when a software vulnerability is not
addressed by patching, but by modifying the configuration of a second security mechanism
(such as a firewall, or router).
David Oliva
On 03/27/13, Nunez, Luis K<lnunez(a)mitre.org> wrote:
This is good a conversation worth informing others on. I am cross posting to the
Open-SCAP-list and Remediation-dev mailing lists.
I’ve noticed pockets of remediation discussions in the various email-lists and would
like to align them to a forum where can work as a collective.
I don’t want to stifle this effort or conversation but would like to move the discussion
to the remediation-dev list. The remediation-dev list, is an open list for all to
participate, was setup to inform and to foster capabilities to enable automated enterprise
remediation. The list members constitute industry vendors and government constituents. It
contains experience and knowledge from previous attempts at remediation capabilities.
Some observations on the current discussion. The OpenSCAP remediation capability addresses
part of the problem. The current discourse (OpenSCAP XCCDF remediation) is beginning to
touch on various Remediation Architectural issues (Workflow, tasking, reporting, OVRL,
etc…). As you know the subject of Remediation is broad with many perspectives and
implications. Before we spiral out control, I’ve seen it happen many times before with
this subject, lets break them down into manageable sets.
For lack of better reference material on Remediation Architecture, I would like to propose
the NIST IR 7670 as a frame of reference for topic of discussions. The NIST IR 7670 is by
no means a standard, but it is something to reference form a work flow and use cases.
Certainly the NIST IR 7670 is subject to revision to suit the needs of the community as it
evolves and it invites any and all for critics to make it better.
And so using the “Derived Requirements†from the IR 7670 I believe we can have
meaningful discourse and solutions. The current discussions on “Remediation Scriptingâ€
seems to originate and is related to DR 5 – Remediation Policy specification. It would
be great to leverage the existing capabilities in OpenSCAP as a way to prototype and
exercise elements in the XCCDF specification for remedial needs. We could also use this
effort to propose revisions in specifications and guidance as needed. The prototype
working code and content will be the mechanism by which a rough consensus from the
community is achieved.
Going forward I would like to invite thoughts and ideas to further innovate remediation
capabilities.
Thank you.
Link to NIST IR 7670
http://csrc.nist.gov/publications/drafts/nistir-7670/Draft-NISTIR-7670_Fe...
Link to Remediation (dev) Discussion list
http://scap.nist.gov/community.html
Luis Nunez
G022 - IA Industry Collaboration
The MITRE Corporation
www.mitre.org<http://www.mitre.org/>
-----Original Message-----
From:
scap-security-guide-bounces@lists.fedorahosted.org<mailto:curity-guide-bounces@lists.fedorahosted.org>
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Truhn, Chad M CTR
NSWCDD, CXA30
Sent: Wednesday, March 27, 2013 11:14 AM
To: Simon Lukasik
Cc:
scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
Subject: RE: Remediation Scripts
I think every option has it's good and bad sides and no clear 'winner' appears
to me. I'll try to comment on my feelings of each.
(*) Remove the fix element from that source XCCDF document
I think this way is always an option. It isn't necessarily graceful, but IMO any admin
worth their weight should be able to manage this. But I think this would be a short term
'hacky' way of handling it. It isn't a solution as much as a work around.
I'm not saying this is bad, but I don't think it can be called a solution. This
might actually work nicely for some scenarios where you know that you don't want Fix
ABC on every machine you can just remove it from the source XCCDF and then use that as
your 'baseline' XCCDF for the remediation of the rest of the machines. When
running on 100s of machines if you can save 5 steps from each that turns into substantial
savings.
(*) Create new (inherited) profile for this special machine
which has the given Rule unselected. This option is getting
easier, as Martin has recently added tailoring file support
into OpenSCAP -> thus your new profile may be in external file.
This might be a workable way to do it. Especially if you are doing offline remediation.
Run the initial scan to find out what's broke, review the output, disable the check
(which disables the fix), run the remediation, re-run the full scan (no remediation) for
final analysis. This doesn't scale well though.
(*) Use CPE identifier assigned to the fix. If the CPE does not
match
on given system, the fix will not be executed.
Moreover, I can think of having some file like /etc/NONCRITICAL on
all my non critical systems. And then having CPE identifier which
matches this exact file. That way, no fix (with this CPE) will be
executed unless the machine has /etc/NONCRITICAL.
I think I like this train of thought. More on this below...
I would comment similar to the one above about inherited profiles. Scan, review, modify,
remediate, scan
(*) Wait for new SCAP-Workbench, which should allow users to select
fix elements in GUI.
I can see where this is useful, but I think the majority of users won't have/use a
true GUI. I think the concept is valid though.
(*) File a feature request against OpenSCAP for interactive
(like: Yes/No/Quit) remediation.
Again, this can be useful especially if you just have a machine or two to handle. This
doesn't scale well to large enterprises though, but I definitely think it has it's
merits. Maybe if we can create some kind of answer file to automate this it might scale a
bit better. But that answer file would have to be handled carefully since every machine
might not be identical. You can't just say "Question 1: yes", "Question
2: no", etc because the first question on System A might not be the first question on
System B. If the answer can be mapped to a specific identifier and somehow manage the
outliers manually it could work. Again, I would have to spend more cycles of thought about
it and I'm not software developer so I have no idea how hard/easy this is. I'm
just spitballing here.
> Without thinking about it too much I can't think of a good
way to do
> that without it being cumbersome. But I can say that in my years
> working with security measures I have never been able to take the
> 'recommended' solution and fit 100% of it to my system.
> There are always outliers.
I understand this. What of the above mentioned approaches would be
the viable for You? Or can You see any other?
So building on your /etc/NONCRITICAL topic from above...
I had a similar thought, but I am not sure how feasible it is. In my head the first thing
I jump to is a include or exclude file. Kind of hosts.allow/hosts.deny type of thing.
1) Specify a particular id in scap.deny which doesn't get run and either no entry or
something like 'All' in scap.allow
2) Deny 'All' with the exception of what is specified in the scap.allow.
This way I can custom tailor which particular remediation steps I want done per box. If
the scan decides it wants to remediate ID 1234, it checks the list to see if it should or
not, then proceeds based on that input. Now as an admin I just have to read through the
checks one time and make a list then I can run the scan/remediation at any time in the
future without having to re-invest time in the applicability of the content again.
In MY perfect world (I am sure others would disagree) I would like if the check was
performed regardless of the statement in allow/deny and only the remediation step be
concerned with it. I have to show every check to my security guys so I am OK with a failed
check and no remediation being done. But, again, I have no idea how that would be handled
within the content or if it is even really an option. This way I would be pretty OK with
having oscap make the changes automatically because I have already declared that the
listed elements are OK to be changed.
I could do this within the bash remediation content as well if there is an ability to
import functions or if the function declaration is persistent throughout the run (declare
it once at the top). If there is some way to check this outside of the bash remediation
content (built into some part of the SCAP content or something like that) I think we could
skip some issues that would arrive when doing this through the bash content (what happens
if I skip the remediation step that declares this function?).
I'm just an admin with no real software development experience so feel free to tell me
to go away.
Thanks again,
Chad
_____
_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com<mailto:Open-scap-list@redhat.com>
https://www.redhat.com/mailman/listinfo/open-scap-list