Collections Losing Assigned STIGS and importing XCCDF Files

[lowtechninja]

Hi,
Has anyone had any issues with assigned STIGs going missing? The deployment that im working on will randomly have the STIGs go missing, and when you reassign the STIGs, the data is repopulated as if nothing had happened. I'm sure if it is a bug or just my deployment. I noticed it with releases 1.1.0 and upgraded to 1.2.2 with the same thing happening. Im also unable to import XCCDF files but CKLs are fine.

Setup is.
ESXi Host 6.7
RockyOS VM 8.4 (4CPU/6GB/60gb) Non-Harden
Docker

Portainer Managing

• nuwcdivnpt/stig-manager:latest
• nuwcdivnpt/stig-manager-auth
• mysql:8.0

The system is used by four admins, which has been observed with Firefox and Chrome.
The system has 20 Collections and about 40k controls items

[csmig]

Thanks for engaging with the project!

You bring up two different topics and it will become awkward to discuss both in the same thread. Please open a second thread for "Im
unable to import XCCDF files but CKLs are fine." Much appreciated.

Regarding the Asset-STIG assignment concern:

We don't have other reports of this behavior. A few questions:

• Is it possible to provide steps to reproduce?
• Which part(s) of the web app are missing the STIG assignments? Are they missing from both the Navigation Tree and the Collection Management tab?

It would also be helpful to know if this is an issue in the API or the web app or both. Suggestions to check if the problem is limited to (one instance of) the web app:

• When you first notice a missing assignment but before re-adding the assignments, refresh the page. This restarts the app. Does that resolve the issue?
• If not, then start another instance of the web app in an Incognito or Private session (or in another vendor's browser) and see if the problem is repeated there.

Please report back to us and we'll dig further. Thanks.

[lowtechninja]

I will do on the XCCDFs.

As for reproducing it, I would say just uploading the CKLs to collections and seeing if they stay would be a good starting point. The part that is missing is the STIG section under the Collections -> Manage. I can build an Asset out and assign it STIGs, and it will take. I'll come back a few days later, and the STIGs are missing. You can add the STIGs back, and the data is there, but it seems odd that it is missing in the GUI and reports in the web app.

We are using the web app 1.2.2. We can add an asset to a collection, then log out, and it will be there. Even login in with a new browser will be there. But a few days later, you come back some STIGs are missing. We have cloned the VM with no one touching it after the assets and STIGs added to the same results. We have tried all the main steam browsers with the same results. Restarting the server when you see a missing STIG has the same results.

[csmig]

There are organizations that have used the tool for over a year and have done as you suggest -- upload many thousands of CKLs and observe if they stay. We don't have other reports of data or configuration losses, so I can't point you to any past issues. I also can't think of a scenario where the data could change during a period when the web app is not in use and the API is not being called.

You might review the API logs for the period you believe there was no activity, maybe there was some. Look for requests that modify an Asset. Here's a jq script that filters and transforms records for all write requests to the Asset endpoints:

jq -s 'map (
    select (.component == "rest") |
    select (.data.request.method == "PUT" or .data.request.method == "PATCH" or .data.request.method == "POST") |
    select (.data.request.url | test ("/assets")) |
    {
        date: .date,
        username: .data.request.headers.accessToken.preferred_username,
        url: .data.request.url,
        method: .data.request.method,
        body: .data.request.body
    }
)' <path_to_your_log_file>

In the current release, the body: property will be null most of the time. This week's release 1.2.3 will start to include the request body when logging with STIGMAN_LOG_LEVEL = 4. I'm hopeful the logging records will eventually help us resolve this issue.