On Wednesday, February 20, 2013 7:48 PM, Gary Gapinski wrote: > I don't think XCCDF should be levied on content authors, rather, > something useful that can be competently turned into XCCDF should be > provided. Accompanied by a schema. It can be better than XCCDF; the > shortcomings of such a transformation can be noted so that the > proto-XCCDF/OVAL content can be dumbed-down as and if necessary.
So the complexity of writing SCAP content is an issue that's been periodically raised in various parts of the community. Is anyone aware of what the current recommended best-practice is? I'm not so sure that solving the problem of overly-complex XML by adding yet another layer of XML is really solving the problem; at some point (usually troubleshooting) it just becomes added complexity. At some point early in our involvement with SCAP we mucked around with doing something similar, but with a non-XML-based domain-specific language called SC [1] (and its compiler, SCC. This was before we knew there was a scanning tool out there of that name; early days, etc.). The goal was to have a more human-readable syntax for authoring content which would then be compiled into OVAL. At the time we hadn't started tackling XCCDF. At some point I even rolled up an Eclipse plug-in to allow for auto-completion and dropdown-niceties for the SC language, though that plug-in never made it to a releasable state. The project itself is neither here nor there, but from past experience going down the road of "Let's add another authorship layer to make this easier" there are some pitfalls to look out for. The primary one is the problem of testing your end-content that has been produced. To drop into the narrative for a moment: So you [the content author/protagonist here] author your content in a simpler manner. You have some auto-complete, the syntax is simple, life is good. You then run some magic to get the end content compiled (or transformed via XSLT). Now you've got your messy XCCDF/OVAL/whatever, but thanks to your easy-authorship approach you don't really have to look at that. You test the content out in your tool-of-choice, but drat! It didn't do what you expected. What went wrong? Was it: A ) The original content you wrote has a bug B ) The transform/compiler you leveraged has a bug C ) The tool you leveraged has a bug In order to track this down you really need an in-depth knowledge of the XCCDF/OVAL. That's what your tool is consuming, so to figure out if the problem is that content or if it's the tool requires really looking at the XCCDF/OVAL. In order to debug content, your content author will still need to have some deep knowledge of XCCDF/OVAL. I'm sure everyone on this list has written a lot more XCCDF & OVAL than myself, so I'll defer to the community's expertise here. I'm just not sure there's a practical way to avoid having XCCDF be levied on content authors; the best solution may be to just get a good editor UI set up. I believe SCAP Workbench [2] takes that approach. - Francisco [1] SCC - http://oss.tresys.com/projects/scc/wiki/GettingStarted [2] SCAP Workbench - https://fedorahosted.org/scap-workbench/ _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
