Full Scapolite example of a Windows security baseline published on github.com

[B Grobauer]

Dear all,

as agreed during the SCAPv2 workshop a month ago, I have made available a first complete example of what SCAP content would look like

when authored and maintained in Scapolite:

https://github.com/scapolite/example_iase_win_server_2016_v1r7

The repository also contains examples of what exports of this Scapolite content to PDF, XLSX and SCAP could look like.

Please use this mailing list for any questions/comments you might have (that being said: I will be mostly offline during the upcoming  two

weeks, so it will take me a while to respond -- I apologize for that.)

Regarding the (draft) Scapolite format specification: I am in the process of finding out whether the format description could be

published as IETF draft in order to be eventually turned into an RfC.

Kind regards,

Bernd

[David Ries]

Hello Bernd (and fellow Benchmark Enthusiasts), 

Thank you for putting this together. I have spent some time reviewing the example and revisiting your presentations and I have some high-level thoughts, questions and concerns about the general utility of Scapolite.

Thought: Decomposition definitely has benefits

I can see that decomposing the content into rule-based folders and files makes some tasks much easier, for example: using tools like git to track rule changes or which rule(s) are affected by changes to OVAL check logic; reviewing a specific rule’s check logic; etc.

Concern: It also has a cost

However, this decomposition comes at a significant cost. Instead of 1 file, we have 633 files in 209 folders. The Scapolite .md files are significantly more verbose than the corresponding XCCDF content. We’ve traded 8K lines of XCCDF for 23K lines of YAML. Note: I excluded blank lines, there are also 2X the number of words and even 8% more characters despite YAML being much more succinct than XML by eliminating namespaces, end tags, quotes, etc. (see comparison here). 

And, we’ve duplicated 40% of the OVAL check content. Obviously, this increase in file/content "mass” and duplicated content makes many maintenance tasks more difficult.

Question: Is Scapolite YAML an improvement over XCCDF XML?

I like YAML better than XML, but the Scapolite YAML doesn’t seem simpler than the XCCDF XML. Compare these excerpts (edited down to comparable content):

XCCDF version: 

<xccdf:Rule id="xccdf_mil.disa.stig_rule_SV-87943r1_rule" severity="medium" weight="10.0”>

YAML version:

scapolite:
    class: rule
id: SV-87943
id_namespace: mil.disa.Windows-Server-2016-STIG
applicability:
  - weight: 10.0
    severity: medium

It seems like we’ve changed the encoding format without actually simplifying things. It’s still very brittle, but now we don’t have a validation mechanism. And, in either case, authors will require training to understand the content (what is “id_namespace” or "Rule@id”) and/or some kind of content management system that abstracts all that away into a friendly user interface.

Question: can we do better?

I think we all agree these formats could be simplified to make the content easier to create and maintain. I’m just not sure that Scapolite goes far enough. It seems to move the complexity and change the encoding but… is that enough?

I’d love to see a bigger change that address Benchmark authoring as well as check authorizing and more obviously simplifies it all.

Alternate Iterative Improvements

A relatively simple script (python, JS, etc.)  should be able to do a rule-oriented diff of two benchmark versions: identify new/missing rules, compare rule metadata and identify checking logic changes. 

We do need a mechanism to override rule metadata (title, descriptions, etc.) and checks (OVAL, SCE, etc.). Perhaps we should consider expanding Profile-based overrides to allow, for example:

<xccdf:Profile id="my_org_overrides_l1”>

   <xccdf:select idref="xccdf_mil.disa.stig_rule_SV-87891r1_rule”>

      <xccdf:title>My Custom Title</xccdf:title>

      <check system="http://open-scap.org/page/SCE">

         <check-content-ref href=“custom_check.ps1" />
      </check>

   </xccdf:select>

   ...

Then, organizations could create and maintain Tailorings (external Profiles) to more fully customize 3rd-party Benchmarks. Because the Tailorings are separate from the Benchmark, they don’t require editing the Benchmark itself and should be much easier to create/maintain even as the underlying Benchmark is revised.

-David

--
To unsubscribe from this group, send email to scap-dev-author...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-authoring
---
You received this message because you are subscribed to the Google Groups "scap-dev-authoring" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-author...@list.nist.gov.

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

[David Ries]

It looks like I can’t share the Google Doc I created with my work account. I’ve attached a copy in case anyone is interested.

[Grobauer, Bernd]

Hi David,

 

sorry for the late answer due to my vacations during the past two weeks.

 

Thank you for your feedback!

 

I am glad that you also  find that the de-composition has benefits: indeed, both we at Siemens and  the OpenSCAP/Compliance-as-Code project

have found it challenging if not impossible to author and maintain SCAP content without such a de-composition in the absence of a dedicated authoring application.

 

Regarding the cost: your main points are (1) number of files, (2) size, and (3) duplication of content.

 

The current scope of this working group is (at least according to what we discussed at the breakout session)
to work on a representation of SCAP content fit for authoring and maintenance rather than

communication of SCAP content to tools such as the jOVAL scanner and all the other tools that are able to process SCAP. In other words,

we are looking for something that helps authors and maintainers to collaborate on baselines, the result of which would then be

compiled to XCCDF or an update of XCCDF in XML. Therefore, the number of files and the size of the files do not concern me particularly
(though for the IASE example, with its somewhat strange structure of putting each single rule into a dedicated group,

I probably should have embedded each rule object in the single encompassing group object, thus considerable reducing the number of files).

 

That being said, I understood some comments made by Redhat during the SCAP workshop such that some of their customers would

rather have something non-XML based all the way from creation to processing – I guess, that comes from frameworks like Ansible being

YAML-based rather than XML-based.  If Scapolite or a derivation of Scapolite were to completely replace XCCDF, then
the number of files would indeed be a factor. Just like for SCAP, one would then have to think of something akin to the SCAP datastreams;

that could be, for example, a Markdown file which contains all files represented as Markdown with a YAML preamble represented

as a code-block or something similar. But like I said above: at the SCAP workshop, the workgroup agreed to look primarily at

an alternative representation for authoring and maintenance, so that is my current focus.

 

Regarding the duplication of OVAL content: as I wrote in the comment included in each OVAL file with duplicate entries: that

was just the way I structured the content during the conversion from SCAP into Scapolite. As an alternative, shared bits of OVAL

could be factored out rather than duplicated.

 

>Question: Is Scapolite YAML an improvement over XCCDF XML?

> I like YAML better than XML, but the Scapolite YAML doesn’t seem simpler than the XCCDF XML. Compare these excerpts (edited down to comparable content):

(…)

>Question: can we do better?

> I think we all agree these formats could be simplified to make the content easier to create and maintain. I’m just not sure that Scapolite goes far enough. It seems to move the complexity and change the encoding but… is that enough?

> I’d love to see a bigger change that address Benchmark authoring as well as check authorizing and more obviously simplifies it all.

 

Although I do think that some aspects of SCAP are a bit overengineered, I fear that many of the complexities of, e.g.,  XCCDF are there for the very reason

that it is complex to represent security-baselines: for example, you need hierarchy and thus you need nested groups, you need identifiers, you need lists of things

etc. It may very well be that I have overengineered things also in Scapolite; maybe a namespace is not necessary (though we need some mechanism

to distinguish between two rules of the same identifier from different publishers, so then we would have to make the identifier more complex, I guess).

 

So, yes, authors would need to learn about writing Scapolite just as they have to learn about SCAP (or Ansible, Chef or whatever).

 

(Some of the problems of writing Scapolite syntax could be reduced with a syntax-checking plugin for editors such as VSCode and ATOM.

Some time ago, Patrick from Technical University of Munich has written

a proof-of-concept definition of Scapolite in XText (https://www.eclipse.org/Xtext/), from which such plugins can be generated automatically. The problem then was that XText

was unable to deal with the specific YAML-Syntax for text blocks, we have to see whether that has changed in the meantime.)

 

But if I have completely overengineered stuff, I am more than happy to consider simplifications! And if there are ideas for drastically simplifying everything, I would love to hear about it!

 

>Alternate Iterative Improvements

>A relatively simple script (python, JS, etc.)  should be able to do a rule-oriented diff of two benchmark versions: identify new/missing rules, compare rule metadata and identify checking logic changes. 

 

I have written such scripts for comparing SCAP content (converting it to Scapolite first), but my experience shows that from one release of a benchmark to another (be it from CIS or IASE), you

always have enough syntactical changes (typos, changed wording, etc.) that require a human to look at the content and see whether something of significance has changed – that could, in my opinion,

only be change by per-rule-history information maintained by the authors. Using a single file per rule in Scapolite would not change that basic problem, which is intrinsic to human-readable content

I fear (at least until we have AI systems that automatically tell us what changes really matter … but by that point, it is probably the AI which authors and maintains the benchmark anyways ;)

 

>We do need a mechanism to override rule metadata (title, descriptions, etc.) and checks (OVAL, SCE, etc.). Perhaps we should consider expanding Profile-based overrides to allow, for example:

 

Indeed, a more powerful tailoring mechanism is a top item on my list of requirements for improved maintenance of SCAP(olite) content … but still somebody has to author and

maintain the baseline that is being tailored … and for that purpose I very much prefer Scapolite to SCAP ;)

 

But I think the main questions of your email that need to be answered are:

(1) Question: Is Scapolite YAML an improvement over XCCDF XML? and (2) Question: can we do better?

 

Regarding (1): like I said: if there are ideas for something drastically simpler, then I would be all ears!

 

If we do not come up with ideas for a substantial simplification: I would then rephrase (2) as
Is Scapolite YAML ENOUGH OF an improvement over XCCDF XML to make work on standardization worthwhile?

 

I would say yes (but then, I am obviously biased J ): both we at Siemens and the Redhat/Compliance-as-Code project found an alternative representation of what is essentially XCCDF content

essential for authoring and maintenance of security baselines without a massive investment into an authoring application and came up with similar approaches based on de-composition

and YAML. If Siemens and Redhat/Compliance-as-Code are alone in this, then we probably should try to pool resources and see whether we can evolve Scapolite into something that works for us both.

 

But: are we alone???

 

Kind regards,

 

Bernd

[David Ries]

Hello Bernd,

Perhaps I am confused about the scope of the Scapolite project.

Based on your presentations (and my fuzzy memory!), I thought that Scapolite was developed primarily for customizing existing content packages, for example: changing rule titles in a CIS benchmark package; changing a check implementation for a specific rule; tracking changes to a rule made by the upstream provider (CIS); etc.

Is Scapolite intended for authoring complete content packages, starting from a blank screen? If so, would that include created the rules (currently XCCDF) as well as the checks (currently OVAL)?

-David

(1) Question: Is Scapolite YAML an improvement over XCCDF XML? and (2)Question: can we do better?

[Grobauer, Bernd]

Hi David,

 

it is the latter: Scapolite is intended for authoring what is essentially XCCDF, allowing the inclusion of checks as is handled

by XCCDF via an extensible check mechanism.

 

We have not looked at changing OVAL other than making OVAL a bit more

easy to handle by allowing OVAL to exist in a number of small files rather than one large file so that a rule-specific

OVAL file can be used. (Another little change I have done experimentally is to allow OVAL to be nested (i.e. pushing

state and object into a test rather than having them all in parallel with references to each other – when generating SCAP-content,

the nesting is removed during the generation.)  

 

But modifications to OVAL are not the focus of Scapolite – though, what we are very interested in is to specify security requirements

wherever that is possible in such a way that both the implementation and the check can be derived from the specification via automated

mechanisms, e.g., deriving an OVAL registry-check from the machine-readable specification of a Windows GPO policy setting

via a transformation from the GPO setting into the underlying registry setting.

[David Ries]

Hi Bernd,

I am surprised to hear Scapolite is intended as a general purpose XCCDF authoring approach. I am sorry that I didn’t understand that. Somehow I was under the impression that your team at Siemens was using upstream, existing content packages (e.g. CIS Benchmarks) and Scapolite was intended as a way to track upstream changes and apply local customizations. That is a need we have encountered.

However, I am more confused than ever about what Scapolite is for. We author a lot of SCAP content and we do SCAP authoring training. And, although I don’t speak for them, I have been speaking with and collaborating with many of the other main SCAP content authors (CIS, Red Hat, DISA, NIST, SecPod, ALTX-Soft, and others) for many years. I’m not aware of challenges authoring XCCDF. The challenging part is the OVAL.

And, everyone I know who authors XCCDF also creates the check the OVAL. I’ve never heard of someone only creating an XCCDF/Benchmark without writing the checks.

If we are going to come up with a new, easier-to-learn and manage format, shouldn’t the focus be on the challenging part: the checking language, OVAL? I think that XCCDF should come along for the ride (i.e. the new format should allow expression of benchmark as well as checks).

I don’t even understand how you could create a new benchmark in Scapolite—unless the checking content already happened to all exist in OVAL or SCE or some proprietary checking language your organization used.

I don’t mean to be difficult—I know you have a real use case and are using Scapolite for important projects. Clearly you’ve done a ton of work on it. I am clearly missing something.

-David

[Gabriel Alford]

> I’m not aware of challenges authoring XCCDF. The challenging part is the OVAL.

Yes. XCCDF authoring is a problem as albeit a smaller one than OVAL. A couple of years ago, Red Hat demoed XCCDF in an OpenControl (https://github.com/opencontrol) stylized YAML format to a wide

swath of SCAP users and those who would like to create more SCAP content but refrain because of its complexity. This was so that one could author both SCAP content inside of the OpenControl spec itself.

When we demoed at our Defense in Depth conference, attendees were happy and excited to see the readability and simplicity of the SCAP in YAML format. They were asking for more the SCAP standard to be YAMLized.

And yes, serialization matters for readability and ease-of-use for end users who are not SCAP experts. Scapolite is a derivation of the ComplianceAsCode project which is an OpenControl YAML version of XCCDF (certain XML components have yet to be removed from the project). We (Red Hat) have yet to approach making OVAL in YAML format partially because it was felt that there would be loss of experience and technical expertise with pure OVAL.

> And, everyone I know who authors XCCDF also creates the check the OVAL. I’ve never heard of someone only creating an XCCDF/Benchmark without writing the checks.

Not necessarily true. DISA and some others do just create a manual benchmark with no checks with separate OVAL and DS released at later dates and sometimes never released.

> If we are going to come up with a new, easier-to-learn and manage format, shouldn’t the focus be on the challenging part: the checking language, OVAL? I think that XCCDF should come along for the ride (i.e. the new format should allow expression of benchmark as well as checks).

Actually, the simplest is often best because not only does it build momentum, but it also allows breaking up the challenging pieces. Plus, most of the solutions for making OVAL easier to author come from developers who want to make into some sort of code style language. In my opinion, this also downgrades SCAP which is currently coding language agnostic which is a huge plus. This ends up not helping the end users aka security officers who are not developers and who want an easy to read and write method to OVAL. This is an important part to make because we (Red Hat) have been asked by those security officers and daily users to make SCAP easier hence, once again, a YAMLized style.

Gabriel Alford

Member of the technical staff

office of the chief technologist

red hat Public Sector

Red Hat

ral...@redhat.com    T: 972-707-6483    M: 303-550-7234    

[David Ries]

Hi Gabriel,

Thanks for bringing up the “manual STIGs” that DISA creates. They illustrate the utility of an XCCDF without checks (e.g. OVAL, SCE). They are labelled “manual” because they do not support automated checking. End users can, for example, load them into a tool like the STIG viewer, read through them and “manually” click check boxes to complete them.

Is that what Scapolite is for? To create manual checks that do not support automation? I assume not… but maybe I’m missing something.

Here are some guesses that probably illustrate my confusion about how Scapolite could be used to author a new benchmark. First, the Scapolite rule is created, then:

1. The rule has no checking content (e.g. “manual” STIG). 
2. The rule uses existing check content created by a third party (it seems very unlikely to me that this content will already exist for the desired rule).
3. The Scapolite rule author writes the checks in Scapolite (Is this possible? I don’t think this would be practical for any but the most trivial checks).
4. The Scapolite rule author creates the corresponding OVAL checks (this one doesn’t make much sense to me because if the author can write OVAL already, then writing XCCDF shouldn’t be an obstacle, so why Scapolite?).
5. The Scapolite rule author writes the checks in some other technology (Puppet, NASL, Chef, Ansible, etc.). This is certainly possible, but then we don’t have a general purpose, implementation-neutral checking checking standard.

The ComplianceAsCode project includes non-YAML check content like OVAL alongside rules to support automation (example here)—options 4 & 5 from my list above. Is that how Scapolite will work?

-David

[Gabriel Alford]

I think it is important to remember that scapolite was written for Siemens' needs, and was just recently released to the public.

There is work that has yet to be done to bring it into alignment with XCCDF which means that handling checking content has yet to be addressed.

Not having yet had the time to look at the scapolite in depth, the goal would be to create XCCDF, OCIL, and OVAL without having to use the different formats you see in scapolite.

I also think that it important to note that Puppet, Chef (except Inspec), Ansible, etc. are better suited for remediations and not check engines like OVAL. I completely agree with you

about having and maintaining an implementation-neutral checking standard to validate the remediations done with GPOs, Puppet, Ansible, etc.

I hope that this answers your questions. I think that it might be better to explain what how our group decided moving forward on the call to remove confustion.

Gabriel Alford

Member of the technical staff

office of the chief technologist

red hat Public Sector

Red Hat

ral...@redhat.com    T: 972-707-6483    M: 303-550-7234    

[Grobauer, Bernd]

Hi,

 

Gabriel already has provided some of the answers to David’s questions.

 

So yes, the first objective of Scapolite is to provide a format for authoring XCCDF in a X-as-code approach

by allowing authors to create XCCDF content as separate files under version control, using standard text editors.

It is true that compared to writing OVAL, writing XCCDF in XML is a breeze, but authoring and manipulating XCCDF XML blobs

is still complicated/off-putting enough so that everybody who is serious about authoring XCCDF has found some way

of not dealing directly with XCCDF-XML: CIS and IASE have custom-made authoring applications, Redhat/Compliance-as-Code
is using a build-chain which compiles XCCDF from a file-tree containing, amongst other files, YAML representations of what

are XCCDF rules, profiles etc. Scapolite essentially tries to formalize the Compliance-as-code approach by providing an explicit semantics of

a YAML-based representation of something XCCDF-like rather than having some implicit semantics as, e.g.,

defined through the way the Compliance-as-Code tool chain works.)

 

So yes, initially, Scapolite aims quite a bit lower than trying to come up with the all-encompassing method to write checks in something

that is not OVAL. But as Gabriel said: “the simplest is often best because not only does it build momentum, but it also allows breaking up the challenging pieces”.

If Scapolite is not completely off with respect to what would be required of a YAML-based format for authoring XCCDF-like things,

then based on Scapolite, it should be relatively fast to come up with the required modifications, that would make it a first stepping stone

towards further work in the field of authoring machine-readable security baselines.

 

That maybe brings us to the question/scenario from David’s mail:

“3. Scapolite rule author writes the checks in Scapolite (Is this possible? I don’t think this would be practical for any but the most trivial checks)”

 

That kind of depends on where Scapolite stops and possible extensions start  -- just as is the case for XCCDF.

 

XCCDF does not care about machine-readable implementations other than defining an extension point for the ‘fix’ element. XCCDF cares about machine-readable checks
to the extend that XCCDF defines the semantic of how results of checks in complex checks (using selectors and what not) are to be combined into an overall check-result.
The real work, however,  is factored out to the OVAL standard.

 

Now, the most useful SCAP content by far is the content provided by Compliance-as-Code for RHEL, because it provides the user both with a way of checking and

of implementing, rule by rule. I think, we need more of that; therefore, we should try to step back and at least think about where it might be possible to specify in a machine-readable way

what our security requirements are and how we can derive both an implementation mechanism and a check mechanism.

 

In many cases, this will not be possible. But in some cases, it is. The Scapolite-examples that we have published

show how we go from a machine-readble specification of required GPO settings to machine-readable specifications of registry/secedit settings.

From which we can derive implementation mechanisms such as Powershell scripts as well as check mechanisms. For example, for everything

that boils down to registry-entries (which is the vast majority of Windows GPO settings), the corresponding OVAL check could be created on the fly.

 

So with a well-defined semantics of an extension system  ‘org.scapolite.implementation.win_gpo ‘ ,

 

the author writes

 

      - system: org.scapolite.implementation.win_gpo

        ui_path: Computer Configuration\Administrative Templates\Google\Google Chrome\Content

            Settings\Default Flash setting

        value: Click to play

        verification_status: Checked.

 

from which the following can be derived (making use of Microsoft ADMX template definition files):

 

      - system: org.scapolite.implementation.windows_registry

        config: Both

        registry_key: Software\Policies\Google\Chrome

        value_name: DefaultPluginsSetting

        action: DWORD:3

 

from which then, in turn something like the OVAL code at the end of this message could be derived automatically

rather than having the author write it.

 

But did an author actually write that definition? Probably not – probably, CIS has a mechanism in its workbench for

going at least from a simple definition of a registry check to an OVAL check. So in effect, there is a CIS-internal

extension of XCCDF used by the CIS workbench to specify certain check types for which OVAL can be easily generated;

if so, the bare data kept in instances of this extension probably look a lot like the contents of the  org.scapolite.implementation.windows_registry
automation shown above. Why not create a common standard and start sharing also on that level of abstraction
(and ideally also the higher level of abstraction provided by the ‘org.scapolite.implementation.win_gpo ‘ automation?)

 

Could we start thinking about these issues with XCCDF rather than a YAML-based representation? Yes, we certainly could,

but as stated above, but having a format that allows joint work on these topics in a X-as-code approach would be

extremely helpful, should be possible to deliver relatively quickly, and might indeed build some more momentum.

 

Why do I think we might get some more momentum by moving to YAML? You may find it silly, but choice of format matters for getting

people excited about using and maybe even contributing. Around the turn of the century (read: “a long, long time ago” )

XML was all the rage and you could not sell a product that did not state ‘XML inside’ somewhere. Now, YAML is

not quite as hot as “blockchain” (today, it seems you cannot fund a startup without a “blockchain inside”  label ;)

but Ansible et al have taught IT folks to expect information that has to do with configuring stuff in YAML or at least

JSON in a readable layout. XML is, for all its benefits, a turn off for people when it comes to files that somebody
actually needs to read, author and maintain.

 

Take STIX as an example: the XML specification of STIX 1.x was completely reworked into a JSON-based specification of STIX 2.0.

In my opinion, there was not much of a “technological” case of switching from XML to JSON for STIX, because STIX really is a format

for interfacing repositories of threat intelligence and probably nobody is going to maintain STIX content

in a X-as-code approach, using editors and files under version control. And yet, STIX made the switch:

some early adopters said that the first thing they did with STIX XML was to convert it into a JSON format used
in internal processing and wanted to have the complete chain in JSON rather than XML.

 

Again, one may find this silly and from a technological point of view, Compliance-as-Code’s initial approach of

splitting up XCCDF into small XCCDF-chunks which are than combined by the build-chain would be less invasive

and would solve some of the problems of authoring XCCDF without a CIS workbench or the substantial (I would assume)
IASE-internal tooling that MITRE built for them. But if we touch the specification, I think we should go all the

way: evaluate what is needed in XCCDF and what is not really used, decide on what we need in addition
to support collaborative authoring and maintenance and improve support for automated implementation,
and then define a YAML-based format. If the community is interested, Siemens will offer Scapolite as a basis for
this effort, to be modified and further developed in some kind of standards body, e.g., the IETF, a FIRST working group, or similar.

 

 

Kind regards,

 

Bernd

 

PS: Below the OVAL-snippet taken from CIS’ Benchmark for Google Chrome  for the registry item from above:

 

 

 

 

<?xml version="1.0" ?>
	<def-group>
	<definition class="compliance" id="oval:org.cisecurity.benchmarks.a_google_chrome:def:36974700" version="1">
	<metadata>
	<title>(L1) Ensure 'Default Flash Setting' is set to 'Enabled' (Click to Play)</title>
	<reference ref_id="xccdf_org.cisecurity.benchmarks_rule_2.1_L1_Ensure_Default_Flash_Setting_is_set_to_Enabled_Click_to_Play" ref_url="http://benchmarks.cisecurity.org" source="xccdf_org.cisecurity.benchmarks_benchmark_2.0.0_CIS_Google_Chrome_Benchmark"/>
	<description>(L1) Ensure 'Default Flash Setting' is set to 'Enabled' (Click to Play)</description>
	</metadata>
	<criteria negate="false" operator="AND">
	<criterion negate="false" test_ref="oval:org.cisecurity.benchmarks.a_google_chrome:tst:36974700"/>
	</criteria>
	</definition>
	<win:registry_object comment="Ensure 'DefaultPluginsSetting' is 'Windows: Registry Value' to '3'" id="oval:org.cisecurity.benchmarks.a_google_chrome:obj:36974700" version="1">
	<win:hive>HKEY_LOCAL_MACHINE</win:hive>
	<win:key operation="case insensitive equals">SOFTWARE\Policies\Google\Chrome</win:key>
	<win:name>DefaultPluginsSetting</win:name>
	</win:registry_object>
	<win:registry_state comment="Ensure 'DefaultPluginsSetting' is 'Windows: Registry Value' to '3'" id="oval:org.cisecurity.benchmarks.a_google_chrome:ste:36974700" version="1">
	<win:type>reg_dword</win:type>
	<win:value datatype="int" operation="equals">3</win:value>
	</win:registry_state>
	<win:registry_test check="all" check_existence="at_least_one_exists" comment="Ensure 'DefaultPluginsSetting' is 'Windows: Registry Value' to '3'" id="oval:org.cisecurity.benchmarks.a_google_chrome:tst:36974700" version="1">
	<win:object object_ref="oval:org.cisecurity.benchmarks.a_google_chrome:obj:36974700"/>
	<win:state state_ref="oval:org.cisecurity.benchmarks.a_google_chrome:ste:36974700"/>
	</win:registry_test>
	</def-group>

[David Ries]

Thanks, Gabriel. I’m looking forward to the call. -David

[David Ries]

Hello Bernd,

Thank you, as always, for your thoughtful responses. I hope this conversation is helpful to others in the community. It’s certainly been helpful for me!

I seem to have given the impression that I see this as an XML vs. YAML question or that I prefer XML and I want to assure you that’s not the case. I love YAML when it’s a good fit for the problem being addressed. 

In fact, I designed a YAML-based SCAP content authoring spec and associated tooling that converts the YAML to SCAP XML. We have customers using this toolset: editing a directory of YAML-expressed rule files and converting them into custom SCAP compliance content.

Perhaps I missed it in the examples, but is there any sort of documentation publicly available for the Scapolite implementations.automations section and available extensions (org.scapolite.implementation.*)?

-David

<?xmlversion="1.0" ?>

Gabriel Alford 

MEMBER OF THE TECHNICAL STAFF

OFFICE OF THE CHIEF TECHNOLOGIST

RED HAT PUBLIC SECTOR

 

Gabriel Alford

MEMBER OF THE TECHNICAL STAFF

OFFICE OF THE CHIEF TECHNOLOGIST

RED HAT PUBLIC SECTOR

[Grobauer, Bernd]

Hi David,

 

• I seem to have given the impression that I see this as an XML vs. YAML question or that I prefer XML and I want to assure you that’s not the case. I love YAML when it’s a good fit for the problem being addressed. 

 

No, I did not suppose you that you are a  die-hard XML aficionado. I think that you are questioning whether switching from one representation (XML) to another (YAML)

is really worth the effort associated with it. And you are right to question this: cost vs benefit of what we set out to do must be properly assessed. I am arguing that in this case, the benefits will outweigh the cost.

 

• In fact, I designed a YAML-based SCAP content authoring spec and associated tooling that converts the YAML to SCAP XML. We have customers using this toolset: editing a directory of YAML-expressed rule files and converting them into custom SCAP compliance content.

 

That is great! Is this a complete representation of OVAL in YAML, or have you  created this mechanism for certain check types that occur again and again?

 

Either way: suppose, your YAML-based OVAL-authoring format was standardized as an extension to Scapolite or something Scapolite-like. Even if you “only” have a mechanism for certain check-types, it would make things

so much easier for authors: I would guess that for certain baselines, they would be able to specify the vast majority of the checks in your easy YAML-base language and only would have to resort to OVAL-XML for

a few more complicated checks. When exporting to XCCDF-XML for ingestion by SCAP-scanners, the tooling for authoring would then read the YAML specification and generate OVAL on the fly.

 

Again, this is something which could be achieved relatively fast but  would make a huge impact regarding the accessibility of SCAP for content authors and maintainers!

 

• Perhaps I missed it in the examples, but is there any sort of documentation publicly available for the Scapolite implementations.automations section and available extensions (org.scapolite.implementation.*)?

 

No, you haven’t missed it, we have not published the specification of Scapolite yet, I am still looking for how to get it published in a way that would lead towards some kind of standard, maybe as an IETF draft
or similar.  For the implementation extensions that we currently use in the Windows world, the syntax is derived from the corresponding Windows mechanisms for specifying/implementing configuration settings.

 

• for the GPO automation: the ui_path field must correspond to the policy path specified in Windows in locale ‘en-US’;
  the value must correspond to the admissible values as can be derived from the Windows ADMX-templates (for non-ADMX-policies,
  the set of admissible values had to be collected from other sources).
• the registry automation mirrors the syntax of how registry-actions are specified in Microsoft’s LGPO.exe tool
• the Windows audit automation is based on a collection of  identifiers with which targets of the auditing mechanism can be specified
• the Windows INF-file automation is based on the syntax of Windows INF files.

 

Until tomorrow in the telco!

[David Ries]

Hi All,

I hope that, as a group, we can document our objectives early on. What are the specific problems that we are trying to address and opportunities we are trying to realize. What key requirements do we have? 

So far, I’ve heard:

• Problem: XCCDF is challenging for authors to collaborate on because the content is not organized in a rule-centric way. Most authoring is done in rule-centric context. And, a rule-centric, nicely-diffable format can take better advantage of version control systems to support collaboration, audit history, etc.
• Opportunity: we want to add support for machine-readable remediations
• Problem: XML is a turn-off and YAML is hip
• Requirement: it’s important to retain an implementation-neutral checking standard for security automation use cases

I’d like to add this one:

• Problem: it’s hard to customize many aspects of XCCDF Benchmarks authored by other organizations in a way that can maintained while the “upstream" Benchmark is versioned.
• Specific needs include:
• Customizing the XCCDF metadata (titles, descriptions, etc.) 
• Adding rules and/or checks
• Converting hard-coded OVAL values into parameters that can be specified at scan-time
• This comes up often when organizations attempt to use the SCAP STIGs as general-purpose hardening assessments. The content is terrifically useful, but the metadata is often very wonky/DoD. End-users can rewrite the metadata, but then when the STIG is versioned, all those rewrites would have to be carefully ported to the new version.

-David

[Bill Munyan]

All, 

• Problem: XML is a turn-off and YAML is hip

I'd like to potentially reframe this problem, because the serialization shouldn't matter.  Some people are fine with XML formats, YAML has it's own set of rules/challenges as well.  One person's complexity is another's ease-of-use.  The format of the content shouldn't matter as long as it contains all the information elements needed to express the content.  Perhaps we can reframe this problem as an opportunity to "Define a serialization-neutral information and data model to express checklist (XCCDF), collection and evaluation (OVAL/OCIL) content".  Then any authoring tools can generate content in whatever serializations they want to support.

The XSDs are currently a great data model, but imply the coupling to XML.  Can that set of data elements be extracted from the XSDs and expressed in a serialization-independent format?

Cheers, 

-Bill M (CIS)

[David Ries]

Hi Bill,

At a minimum, I think it would be useful to distinguish model-related issues from serialization/format-related issues. For example, adding automation-friendly remediations is primarily a model-related issue.

But, I’m struggling to wrap my head around the idea of having a model without deciding on a common format. Is there a good example of this in another domain? I’m imagining HTML with a model and no <HTML>. How would browsers be able to read anyone’s model-compliant serialization?

Wouldn’t we lose critical benefits of a shared format including, for example:

• Content authors can re-use each other’s content, collaborate on content repositories, etc.
• Content consumers can consume content from many different sources, tailor it, etc. 
• Interpreters can process content written by third parties
• Model moderators can create and maintain examples in a common format
• Tooling, tutorials, documentation, etc. can be developed to support learning the format

In theory, all of these could happen even if there were multiple formats (Ruby, YAML, JSON, JS, etc.) but wouldn’t that require tooling that could convert between all of them so, for example, if I wrote in Scapolite and you wrote in Cisolite and I wanted to re-use or consume your content without also learning/implementing Cisolite, I would have to convert it to Scapolite first?

In this scenario with many formats and many converters, wouldn’t it be easier to pick a primary/reference format of some sort and require all others to convert to/from it? And the moderation community and community repositories could use this reference format? 

But… if we do all that, don’t we end up right where we are? We have a specification model and serialization format. The other formats and converters serve the function of authoring tools for authoring the primary format.

-David

[Lubell, Joshua (Fed)]

Hi everyone,

 

Sorry I’m chiming in so late in the game. I think Bill and David are both correct. Models *and* their serializations both matter.

 

The SCAP data models with which I’m most familiar, the source data stream collection model in SP 800-126 and the XCCDF Benchmark document model in NISTIR 7524, are both gnarly XML schemas. The SDSC model’s gnarliness results from the need to losslessly package and unpackage components, plus a desire to leverage XML catalogs to map relative URIs from within components to links between component references in a data stream. The Benchmark model’s gnarliness arises from the desire to give benchmark authors lots of freedom in grouping and parameterizing rules, creating profiles, and choosing a check language. Additionally the Benchmark model is a *big* schema with lots of elements. Finally, both data models require long globally unique identifiers in lots of places, which is great for protecting against broken references and for preserving provenance, but a headache for authors.

 

Yet another SCAP authoring issue is that constraints come from multiple sources: the component specifications (XCCDF, OVAL) as well as SP 800-126. An author-friendly data model should capture all of these constraints such that an authoring tool implementing the data model can provide validation-while-you-type in real time.

 

I think it’s important to recognize that none of the above concerns have anything to do with serialization. Serialization choices have their own set of pros and cons. XML is verbose and a pain to author without XML-aware tools, but has a robust set of standards-based tools for validation, querying and transformation. Markdown with YAML is easier to author with a vanilla text editor, but validation and transformation are more problematic precisely because the source lacks (verbosity-causing) delimiters that make structures more explicit. Just as XML-aware tools can mitigate some of the issues with XML authoring, tools and recommended authoring practices developed by the ComplianceAsCode and Scapolite projects can mitigate some of the issues with YAML/Markdown validation and transformation.

 

I think most of us agree that one XCCDF data model is not enough, which is why our group’s goal is (at least in my mind) to develop a standard XCCDF authoring data model (that is transformable to the NISTIR 7524 data model).

 

To me, the question of whether one serialization method is enough is unsettled. Since tools can mitigate serialization issues, it’s conceivable that authors might accept a common serialization method as long as they have the tools they need to work efficiently and produce valid content. On the other hand, some people have strongly held serialization preferences, for example hatred of angle brackets or discomfort with having to worry about indentation.

 

-Josh

 

Joshua Lubell

Systems Integration Division

National Institute of Standards and Technology

100 Bureau Drive, Stop 8260

Gaithersburg MD 20899-8260 USA

 

-David

 

 

 

-David

 

 

 

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

 

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

 

 

-- 
To unsubscribe from this group, send email to scap-dev-author...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-authoring
--- 
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-author...@list.nist.gov.

 

-- 
To unsubscribe from this group, send email to scap-dev-author...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-authoring
--- 
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-author...@list.nist.gov.

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

 

-- 
To unsubscribe from this group, send email to scap-dev-author...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-authoring
--- 
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-author...@list.nist.gov.

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

 

-- 
To unsubscribe from this group, send email to scap-dev-author...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-authoring
--- 
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-author...@list.nist.gov.

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com

 

 

--
To unsubscribe from this group, send email to scap-dev-author...@list.nist.gov
Visit this group at https://list.nist.gov/scap-dev-authoring
---
To unsubscribe from this group and stop receiving emails from it, send an email to scap-dev-author...@list.nist.gov.

David E. Ries
Co-Founder, Business Development
ri...@jovalcm.com