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... > (*) Use offline remediation and proceed as described at https://www.redhat.com/archives/open-scap-list/2013-March/msg00016.html 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
