Best way to handle " Not Reviewed" items?

[Bwall95]

I understand that STIG Manager allows configuring multiple import options for "Not Reviewed" (NR) items, but I’m having trouble achieving the workflow I need. Specifically, I want to import "Not Reviewed" findings only if the corresponding data in STIG Manager does not already have a comment/review status other than NR. If a finding in STIG Manager has a comment or has already been reviewed, the existing data in STIG Manager should take precedence over what is being imported. However, the current behavior seems to handle this in the opposite way. The default import logic overwrites data by importing all "Not Reviewed" findings from the checklist, regardless of whether there is an existing comment or reviewed status in STIG Manager. The second option will only import NR’s if there’s a comment, which there will never be from Evaluate-STIG unless an answer file populated one, and the third option ignores NR’s, which I definitely don’t want.

In our workflow, we import checklists directly into STIG Manager using Evaluate-STIG. This process results in no comments for "Not Reviewed" items in the .cklb files, meaning all NR findings are imported and overwrite the data in STIG Manager. I want to avoid manually modifying answer files before importing them into STIG Manager, as this adds unnecessary overhead to the process. Ideally, I want STIG Manager to compare imported NR’s against existing data and, if an item has already been reviewed or has a comment, ignore the imported NR status for that finding and retain the existing data. If no comment or review data exists, the finding should be imported as NR, because it truly, hasn’t been reviewed. Which to me seems like the correct workflow?

The only solution I can think of is to import all checklists and import all NR’s, and then for future imports, change the setting to never import NR’s or only import with a comment, which won’t overwrite the existing data in STIG Manager. BUT, once STIG revisions occur, or Evaluate-STIG gets updated, I need NR’s imported again. And can’t do so without overwriting existing data.

Is there a way to configure STIG Manager to handle imports based on existing comments or review data in this way? If this workflow isn’t directly supported, is there an efficient alternative? How do others handle this?

Thank you for the hard work as the application is great and we almost have our entire RMF process automated.

[cd-rite]

Hi @Bwall95
The Collection Import Options are a way to specify to the client the way you would like Reviews to be imported, and are not enforced by the API.
The client can choose to obey or ignore these guidelines, and make requests to the API specifying any legal review state they want, and the API will change the Review to reflect that request. The API does not make decisions about what to do with a Review it has been told to update. It expects the Review specified by the client to be the desired state of that Review. The only exception to this is the "Reset to Saved upon change to: Result/Any Review Field" option.

It sounds like your workflow would be satisfied by by just "Never" importing Not-Reviewed rules. A rule that has been explicitly marked "Not Reviewed" is treated exactly the same as one that has never been touched at all.
Any Rule that does not have a Review is already in a Not-Reviewed state, like when a new STIG is assigned to an Asset, or an assigned STIG is updated and introduces new Rules. Those Rules will already be NR so it's not clear to me why you would need to import an NR Review in that case?

Also, just to clarify, the "having comments" option is referring to either finding details or the comments field, not just the comments field:

[Bwall95]

I'm just looking at STIG Manager to be my one stop shop for everything STIG. And not have to worry about answer files or scripts to modify the results for NR's.

Currently, we have a process called adjudication. Evaluate-STIG produces checklists for all of our machines. And a script will compare the new .CKL's to the ones on the share. Any items that are not reviewed, will look for an answer in the current checklists on the share. All of the NR's are updated, and then replace the checklists on the share.

I was hoping to eliminate that process by using STIG Manager. The admin would review the NR, set a status, and then moving forward STIG Manager would not revert that back to NR when the next checklist was imported. But I understand the application is just updating the information it's given.

[Bwall95]

Wait, I just read your reply a few times and I think it clicked. If I chose to never import NR's, those "NR's would still exist in STIG-Manager because they're a part of the STIG attached to the asset.

So we could just review the item, and it would never get overwritten because I'm not importing NR's correct?

For some reason I was thinking the only data in the application is what I was importing. If STIGs are attached to an asset, the only information I need to import to the app is "reviewed" items. Right? lol.

[cd-rite]

Hi @Bwall95 Yep, that's exactly it!
That's one of the main reasons STIGMan needs its library of "Reference" STIGs. That way, it can just care about individual Reviews for Rules (reviewed manually or imported from incomplete .ckl files), but calculate stats based on the entire STIG that is assigned to the Asset. Internally, STIGMan does not track data as "checklists." It has a set of Reviews associated with an Asset, and constructs checklists on the fly based on the current revision of the STIG applied to that Asset from the applicable Reviews. This also helps us carry forward Reviews for Rules that may slightly change between STIG Revisions as long as they have the exact same check content as the version that the Review was originally applied to.

We offer those other import options because in some cases Eval STIG will produce helpful commentary in its .ckl output but will not be able to resolve to an actual Result for that Review. The "Not Reviewed with Comments" option is for Users who want to import that commentary so they can use it when they manually Review that Rule, but not everyone has that process! Those users are usually more likely to use Eval STIG Answer Files to guide it to produce a .ckl with a Result already determined for those checks, so they don't have to manually Review it again after an import, but continue getting that "informational" commentary.

Glad the tool is working for you!