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/