> At some point it makes sense to create a unique fix directory, similar > to the OVAL check directory, and drop unique scripts in there to be > merged during the make process.
Depends on what output you're making, but that's the basic idea. > We just have to convince Jeff to drop > his objections on including fix content... ;) Well, my objection was toward automated fix content preceding the creation and QA of guidance/checking content. High-quality guidance and checking content is very hard to create, and it is also difficult to create remediation content for baselines which do not exist. But anyway, looks like the time is getting closer. Several important scoping questions must be considered: 1) Is the intent to provide a collection of remediation modules/scripts, which are parameterized when needed, and which would be activated through some kind of selection mechanism? IIRC, this would be different from the current Aqueduct approach, which is to maintain separate directories for each baseline. 2) Is there interest in providing remediation modules in formats other than bash, such as Puppet or Chef? Whether we wanted such flexibility would influence our approach. 3) Would we prioritize (or only) create fixes for those things that do not pass "out of the box"? 4) Should much/any attention be paid to CRE? It may be worth a quick glance at Appendix C here: http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-7831.pdf Is it desired as an output? I'm just trying to think aloud about what this would look like, since I think it's really important for us to synchronize on goals before building anything. I also consider some familiarity with scap-security-guide, Aqueduct, and secstate to be prerequisites for technical discussion. I need to review the Aqueduct and secstate code sometime over the next week to familiarize myself with their approaches. At present I would not feel qualified to start integrating code/scripts for remediation. (I'm not sure if it's proper Netiquette to email multiple lists at once, but this is certainly relevant to Aqueduct and OpenSCAP too.) _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
