VMware STIG automation import to Stigman

[blac9216]

I am attempting to use VMware's compliance automation to do the work of running the checks via Chef Inspec and creating the CKLs using SAF-CLI using the code and instructions found here:

https://github.com/vmware/dod-compliance-and-automation

I'm having trouble massaging the data into a form that Stigman will take. I had to change the inspec.yml ID and Title for the checks otherwise I get an error saying that the benchmark doesn't exist in the library. Once I did that to (presumably) match the benchmarks correctly I get a new error that I have no idea how to troubleshoot.

cannot read properties of undefined (reading 'match')

I'm not sure where to get the full logs to see what the actual property it's looking at is.

Has anyone successfully set up VMware's dod compliance and automation with Stigman? I'm curious if using SAF to convert from the native inspec HDF json to CKL is the best path or how I can manipulate the data into a form that can be uploaded.

[parkrz]

I've done some work on this and can only provide you with a workaround and some limited explanation as to why this is happening.

BLUF
SAF convert leaves you with a checklist with some formatting issues that stig-manager doesn't like. You can do a side-by-side diff to see the differences. STIG Viewer will open the checklist but stig-manager doesn't like it.

To get my saf converted checklists to import and create the asset in stig-manager, I have to first create a new checklist in STIG Viewer using the create checklist from marked STIGs then do an import "Checklist Data..." and provide it the saf converted ckl file. Save this checklist and import it to stig-manager.

A few observations I've made along the way are...

When converting the json to ckl using saf convert, I've found that using the --vulidmapping=gid switch helps by using the actual vulnerability ID, ex. V-#######, in the Vul ID column as opposed to the STIG ID, ex, VCSA-80-######, which gets put in the Vul ID column otherwise. I'm sure this is there is a use for the later but it's of no help to me. However, this checklist will still not import to stig-manager with this change alone.

Also, to get stig-manager to create the asset on import, make sure the saf convert command uses the hostname switch -H <hostname>. This will populate the hostname field in the checklist.

My saf convert command looks similar to this example.
saf convert hdf2ckl -i <filename.json> -o <filename.ckl> -H <hostname> -F <hostname.FQDN> --vulidmapping=gid

I've played around with the saf generate ckl_metadata -o metadata.json but to get this to work I would have to create a unique metadata file for each host. There still may be a solution here but I've not found it.

I hope this helps.

[blac9216]

Thanks for looking into it. I went down the same road as you did with no luck, and my next move would be to create an XML or JSON (CKLB) template for the various baselines and do a transcription of the inspec results into the template instead of using saf cli for that portion, but I really didn't want to have to do that.

[csmig]

Hi, I'm a maintainer, we appreciate the report. Our goal is to handle any CKL which STIG Viewer opens. If you could please, provide an example of CKL output that STIG Manager is not handling but STIG Viewer does.

Tracking this in the stig-manager-client-modules repository.

[blac9216]

I can get approval to get you an example from our testing environment for each baseline of a vSphere 8 environment if you need more samples than @parkrz has for you. Thank you for opening the issue!

[parkrz]

Do you have a.mil address? If so send me the address and I will send you a checklist via DoD safe. Sent from Proton Mail Android

…

-------- Original Message --------

On 3/25/25 17:29, csmig wrote: Hi, I'm a maintainer, we appreciate the report. Our goal is to handle any CKL which STIG Viewer opens. If you could please, provide an example of CKL output that STIG Manager is not handling but STIG DuckDuckGo removed one tracker. [More](https://duckduckgo.com/-AmpMMwPPd2yRLeOWHmdIaXUgvU_5IddwHCRAFbyZJKHnsEydBnHp0aG4xZ-oz0yeVYKJnRixlbSoNVZUKQmLLToWS8r_AmVCH-2cVP-TN90fILBLpxXcK8O3IKwgTLsQQcVMS87Xm6S3HOGqSRQ7_Hu3QctqOYokNXYPsDWA_8DU6PBj2bquy87u7ijfmuB9LQoF52bHA9PevIElxGb4TASEXVqmCFl-VuAp9iJmMQQc) [Report Spam](https://duckduckgo.com/-AmpMMwPPd2yRLeOWHmdIaXUgvU_5IddwHCRAFbyZJKHnsEydBnHp0aG4xZ-oz0yeVYKJnRixlbSoNVZUKQmLLToWS8r_AmVCH-2cVP-TN90fILBLpxXcK8O3IKwgTLsQQcVMS87Xm6S3HOGqSRQ7_Hu3QctqOYokNXYPsDWA_8DU6PBj2bquy87u7ijfmuB9LQoF52bHA9PevIElxGb4TASEXVqmCFl-VuAp9iJmMQQc) Hi, I'm a maintainer, we appreciate the report. Our goal is to handle any CKL which STIG Viewer opens. If you could please, provide an example of CKL output that STIG Manager is not handling but STIG Viewer does. Tracking this in the [stig-manager-client-modules](NUWCDIVNPT/stig-manager-client-modules#33) repository. — Reply to this email directly, [view it on GitHub](#1553 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BAHE4HWVN74HAQ2DQIZM7O32WHKEJAVCNFSM6AAAAABYRVOVY6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRSGEYDCMQ). You are receiving this because you commented.Message ID: ***@***.***>

[cd-rite]

Hi @parkrz You can send it to the address specified in our security policy. Note that mailbox is shared with a couple other teams developing RMF tools for Navy, so please reference STIG Manager in the subject line.
Thanks!

[cd-rite]

Hi @parkrz @blac9216
Thanks for sending that file.
There are 2 problems with that file that would prevent proper import (Assuming it has been created using the options suggested by @parkrz above ) .
For now, these issues should be easily addressed by tweaking your .ckl files to include the proper data/strings, and we will consider what changes we could/should make in our code to handle these outliers:
1:
The SI_DATA block for releaseinfo is missing a SID_DATA element:

<SI_DATA>
  <SID_NAME>releaseinfo</SID_NAME>
</SI_DATA>

vs

<SI_DATA>
   <SID_NAME>releaseinfo</SID_NAME>
   <SID_DATA>Release: 2 Benchmark Date: 30 Jan 2025</SID_DATA>
</SI_DATA>

We do not require that a specific version/release of the STIG be present in order to import, but our parser does want that element to exist and be populated. This is the source of the "match" error you received and could be addressed in our parser.

2:
The stigid block is using a different STIG ID string than the one DISA releases:

<SI_DATA>
   <SID_NAME>stigid</SID_NAME>
   <SID_DATA>VMware vSphere 8.0 vCenter STIG</SID_DATA>
</SI_DATA>

vs

<SI_DATA>
   <SID_NAME>stigid</SID_NAME>
   <SID_DATA>VMW_vSphere_8-0_vCenter_STIG</SID_DATA>
</SI_DATA>

We will consider whether it makes sense to allow imports of Reviews that we cannot associate with a particular STIG in the system. In theory, if we know about the RuleId from a .ckl, we could associate it with a Review for an Asset. However, we will not be able to associate the STIG itself with that Asset, so the Review would be "orphaned" unless you manually assign the equivalent STIG to that Asset.

TLDR:
Your files should import if you:

• change the STIG ID to the string DISA uses to identify the STIG (If you've imported the DISA reference stigs into stigman, this is listed as the benchmarkId in the UI). In the case of the sample file, VMW_vSphere_8-0_vCenter_STIG

• Add the SID_DATA element to the releaseinfo SI_DATA block:
  <SID_DATA>Release: 2 Benchmark Date: 30 Jan 2025</SID_DATA>

[blac9216]

Thanks @cd-rite for the work around.

For the STIG ID, I edited the inspec.yml for the profiles and ran all the benchmark profiles individually. name in the yml corresponds to the STIG ID in the saf cli generated ckl.

Looks like the SID_DATA element just needs to be there for now and doesn't necessarily need anything in it. Since I am using PowerShell as a runner for the inspec checks and the saf cli conversions I just add the element in the right place after the ckl is created and everything imports fine. I tried using the --releasenumber option from saf convert but it doesn't seem to actually do anything so I might go over to the saf folks to see what's up with that. I see other options to change the profile name and so on that would be useful so that we don't have to edit the inspec profiles.

@csmig I see the issue has been resolved, thank you very much for that. I'm looking forward to the release that includes this fix to clean up my runner.

Thanks all!