[FEATURE] Unable to import XCCDF 1.2 results files from OpenSCAP

[ssbn]

Describe the bug We're automating our deployment of the DISA STIGs as we prep for FedRAMP. Using OpenSCAP 1.2, we are running scans using the latest STIGs (Jan) for Red Hat Enterprise Linux. When I go to upload the XCCDF XML file in OpenRMF, I receive the following error:

You had 0 Checklists uploaded successfully! There were 1 failed checklists. Check that they have a valid Hostname and format. ( d-xx-aa-bbbb-2021-01-25-results.xml ) Click OK to continue!

When I take the same XCCDF file and import it into STIG Viewer, I can then turn around and export the CKL file, which then imports correctly. This is obviously cumbersome, so trying to understand what OpenRMF is looking for to successfully import the XCCDF formatted files.

To Reproduce Steps to reproduce the behavior:

1. Go to Upload
2. Add System with name xx-aa-bbbb.fqdn.example.us
3. Choose Files, select XCCDF file produced by oscap xccdf eval --profile xccdf_mil.disa.stig_profile_MAC-1_Sensitive --results /root/oscap/{{ name }}-{{ date }}-results.xml --fetch-remote-resources /usr/share/xml/scap/ssg/content/U_RHEL_7_V3R2_STIG_SCAP_1-2_Benchmark.xml"
4. Click Upload and Save
5. See error

Expected behavior Results file succesfully uploads, and checklist generated for selected system.

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome
• Version 87.0.4280.88

[Cingulara]

OpenSCAP is currently not a supported SCAP result we can verify that we parse correctly. We have on the upload page (to the right of the upload form) a message "DoD SCAP as well as Nessus SCAP files should work fine" for that reason. Those two work well. Nothing else has been tested actually, including the OpenSCAP file result XML. I have not used that tool and have not tested but if you say it does not work, then it does not. The SCAP scanner at DISA definitely works as that is the first one we did. I believe you need a CAC to get to that but if you are federal or DoD you can do that (@degthat8412 can verify). Nessus's SCAP was the other one we got our hands on and that fix was fairly easy. They have the same format, but different named XML elements.

Someone needs to study the format of the OpenSCAP XML and then compare it to the current tool code. The file https://github.com/Cingulara/openrmf-api-upload/blob/master/src/Classes/SCAPScanResultLoader.cs is the code that loads those XML files. I have not seen contents of the XML for OpenSCAP so I am not in a place to say how a fix would happen. I will have time to look at this in a few weeks as I am in the middle of 2 other things. But the code above may clue you or another developer in if the XML is in a similar format as the other two.

I wish all these "SCAP" tools would export in the same format and be consistent across everyone. But obviously that is too much to ask. :) So more than likely the code would need an update. And we would need to install that tool in REL 7.9 or 8.x and do some testing. Going to leave this open until we (or someone else that forks the code) can do just that.

[ssbn]

Don't you just love it when 'standards' have this wiggle-room in them?

Thank you for linking the code. This is exactly what I was hoping to see: it appears the code is written right now to parse the target-fact tags, and looks for the host_name in a name attribute. The scan I have, utilizes the target tag, and supplements this with target-address for adding IP addresses (including localhost).

This I believe will give me enough to use sed on the output files and get the scans into something that can be read.

I'll update the thread. Thanks for your reply!

[Cingulara]

Right. Everyone has a standard. They just are not the same. :)

Let me know what you find out thanks!

[Cingulara]

The web UI calls the Upload API, the Upload API then pulls the XML file, parses if XML (if it can) then works to match that to a checklist template using the MSG-Template client w/ the latest templates. If it gets one, it fills out by the vuln and STIG info.

Keep in mind @ssbn that the newer benchmarks w/ the newer scans match to newer VULN IDs but the same STIG ID / Rule Ver numbers. So the benchmarks at least for the DISA tool and the checklist STIG version/release have to match. Now that they changed VULN IDs on several STIG CKL files.

[ssbn]

I'm assuming that what you are saying is to make sure OpenRMF is installed as latest version to handle the new VULN's?

Update regarding OpenSCAP: The output from the --results parameter creates a file that... doesn't quite look like a proper XCCDF document. All of the tags are missing the xccdf: prefix.

I'm trying to determine if this is 'pre-XSL' conversion, or simply the state of how OpenSCAP provides results. What's interesting is that when using the --results-arf parameter, the datastream is properly defined with xccdf: tags, but then the reports and other container data uses unprefixed tags.

Trying to wrap my head around what they're doing and why- as you know, this stuff is not clearly documented.

If it will help, I can provide a santized example of the --results parameter output from OpenSCAP. For the most part, it appears that the parsing code that's already implemented to handle xccdf: tags in SCAPScanResultLoader.cs would carry over to the OpenSCAP output, just sans the xccdf: prefix in each of the tags. Additionally, there would be some need to detect the target tags and parse those.

[Cingulara]

My point above: use the newer benchmarks w/ the newer checklists as their VULN IDs match.

On the OpenSCAP piece, if you can share sanitized examples that will help yes. It is a PITA they don't all match a freaking standard. Creating their own silo. It is very annoying...

Yes, it would be interesting to compare it to several other SCAP scan results I have yes. So if you can, you can attach here OR email me: dale.bingham@cingulara.com. I appreciate you digging into this to see what fix we could have.

[ssbn]

Here's a sanitized file, straight from the usage of the --results parameter from OpenSCAP 1.2.17. I haven't used a later version as it will require compilation for use on CentOS 7.

test-results.txt

Note the use of <rule-result> instead of <xccdf:rule-result> and similar... interpretations of the XML language. Also the use of <target>, <target-address>...

[Cingulara]

Got it. I will have to look at this in the next couple of days. I see they have 1.2.x and 1.3.x so I probably should look at all them. I don't have a CentOS VM but I can make one quickly to find out any differences.

[Cingulara]

So right now at first glance, I look for "cdf" or "xccdf" as the DISA SCAP uses cdf and the Tennable Nessus. So that will make it fail right away as there are neither. OF COURSE NOT, WHY WOULD THERE BE RIGHT!?!? :-)

Similarities on fields if we can get pas the cdf/xccdf thing to make sure it knows it is OpenSCAP v DISA scanner v Tennable scanner:

• title tag
• target-address tag
• scanner name and version
• rule-result
• idref
• result (pass or fail)

So it looks like with minimal work and a lot of testing, OpenSCAP could be a "beta" feature while we see if it works for you. It would not be a heavy lift really. Which is what I was hoping...since I cannot hope that people will use one standard...and not their own standard.

I do know from talking to @degthat8412 that the DISA SCAP tool is pretty verbose in all it does compared to Nessus. I have not used OpenSCAP so I cannot say what it can / cannot do. But I know the DISA SCAP requires a CAC which not everyone has and can get/use.

[ssbn]

That's the situation I am in. We're pursuing FedRAMP, and need to meet the standard, but getting the ATO from a non-DoD agency- yet need to be prepared for that when the time comes. Catch-22.

However, the big piece that I was hoping to achieve was to automate the entire compliance/risk gathering process. We utilize SaltStack, and I've written the code to run the scans automatically, collect the results, and prepare them. The intent was to use the API in OpenRMF to even automatically upload the scans, if that was possible.

[Cingulara]

If I can get time later with all I have going on, I am going to test the file you gave me w/ OpenSCAP XML to test my hypothesis. If not today, tomorrow.

As for having an external entity hit the API, right now the APIs expect the web to send a JWT, validated in Keycloak from their UI, to make sure the login is valid to call the API. And verify the user, the role, etc. There is no external way to do what you ask out of the box. Yet. I have not had the time honestly. I have to pay bills. :)

The example I did a while ago https://github.com/Cingulara/openrmf-ext-api-score uses Kong API GW and code to talk to the same DB I use for the Score I think. So something like this could be easily built to call the API, validate via a token or something with Kong API GW Plugins, and then get the data into the system. That is not a 1 hr job, but it is doable.

[Cingulara]

@ssbn Ok I got this working locally. And in doing so, cleaned up some code on reading in the DISA SCAP and the Tennable/Nessus SCAP as well. I am still testing locally to make sure I got this right.

For the REL STIG you gave me, it matched to the V3 R2 22 Jan 2021 release of REL 7. And I got numbers for high/medium/low as well as NaF, N/A, and Not Reviewed numbers. I won't show those out loud here of course. You can hit me up via email or do a Google Meet to discuss if you need.

Hopefully in the next few days I can release the OSS version of the update for the Upload piece of OpenRMF 1.x so we can get you to test and verify.

[ssbn]

That's fantastic news. I'll keep an eye out for the release, or link it, and I'll redeploy on our Docker. I have a handful of different DISA STIGs to run through, so I think I'll have a good test set to confirm the parser.

[Cingulara]

@ssbn working to finalize this today and get v1.4 of OpenRMF OSS out the door. I need to test locally a bit more and then get it packaged up, into DockerHub, merge to master/main in GH, and then publish the release.

[Cingulara]

into 1.4, processing now.