System-wide marking should be available. [Asset-wide marking is complete.]

[TheCleverEpithet]

Version Tested: "STIGQTer_Nightly" (1.1.4 BETA?) Downloaded 2022-04-01

It appears that the "MARKING" displayed in STIGQter is "System-Wide" (I.e., one value for the entire current database) at the top of the overall GUI for all CKLs imported.

This should be asset or host based (like the Hostname or IP attribute from the STIG CKL file is treated for each asset). There could be single authorization boundaries that have assets/hosts whose data could have different markings requirements. For Example:

• One network with both Classified and Unclassified devices within the authorization boundary (e.g., using an approved CDS or bulk encryptors), requiring some CKLs to be marked "CUI" and other "SEKRIT"/Etc.

• CUI requires marking as defined in DODI 5200.48 Section 3, which requires control information including a point of contact which could be different depending on which individual created the CKL file or who the POC is for the technology or asset. For example, the Marking field should be able to contain the string: "CUI [Controlled by: <ORG/OFFICE NAME>; Category: ISVI; Limited Dissemination Control: FEDCON (D); POC: Bob E. Jones, (999) 999-9999]"

• Classified files are required to be marked with Derivative Classification information as required DODM 5200.01-V2 Enclosure 3, which includes the SCG or source document, the name of the derivative classifier, the source or section of the SCG, and the declassification date. All of this should be included in the Marking field after "SEKRIT" or whatever the classification marking is. This could also conceivably vary if the section or name of the SCG being used for certain components was different, or (more likely) the name of the individual performing the derivate classification is different for certain files or assets/technologies, and/or the declassification date which will change based on the date that the single classified file was created (e.g., "plus 45 years from the date"). For Example: the Marking field should be able to contain the string "TIP SEKRIT [Classified By: First MI. Last; Derived From: SCG, Section 8.12, Reason 1.9x, Dated 1 JAN 2020; Declassify On: 2099-04-02]"

Currently this build does not appear to allow import of CKLs unless all of the CKLs have the same text in all Marking Fields which is problematic.

[TheCleverEpithet]

The Marking text should be maintained/associated with the Asset/Host object in the database; for example, when using the "Reports > ... STIG CKLs" export option the Host-Based Marking text should be populated in the exported STIG Checklists files.

[squinky86]

I went back and forth on this regarding if the marking should be system or asset specific. I think you're right - I can think of systems where the marking information should be different between a non-tactical and tactical asset. I am wondering if there should also be a system classification marking as well. Any thoughts?

[squinky86]

OK, I've moved it to the Asset level and took out the checks to make sure imported CKLs are at the same classification level as the system. The system now no longer displays a marking, and the user can enter whatever they want. I'm still playing with some ideas (as the generated reports currently do not maintain the marking and are at the system level), but if the marking is a free-text field, it's going to be difficult to correctly mark generated reports or determine which asset has the highest classification. I'm going to leave this open to see if you have any ideas. I know the mainline STIG Viewer doesn't handle this either for now.

[TheCleverEpithet]

Yes an overall classification marking for the data base being used would a good feature. As you mentioned this could then be used to correctly mark reports and out put from the tool containing a mix of all data for that system. I agree that it would difficult if not impossible to parse this out of the single free text Marking field from the CKL, though. Perhaps there could be a configuration option (e.g., text input with 6 text fields/lines, which should accommodate CUI or SEKRIT control information (ignoring blank or unused fields)) somewhere in the tool where the user could fill in that information manually without depending on marking fields from the ckls? If they choose not to use it it could be ignored?

Edit: although any detailed control information marking to the TRE for eMASS would have to be done in fields or cells that are ignored by eMASS upon import to not break that functionality. Same for the POA&M I would expect.

[squinky86]

Changing this so that I can track it. For 1.2.0, I'd like to have a system-level marking for reports. If you upload a STIG checklist of a different marking, a warning should be thrown if the imported marking is higher than the system level marking. While free text entry, STIGQter should understand the basic markings (PUBLIC RELEASE, UNCLASSIFIED, FOUO, CUI, CONFIDENTIAL, SECRET, TOP SECRET). The logic/pseudocode I plan to implement is:

if classification starts with U, assume unclassified. If starts with F, assume FOUO. If starts with CUI or CONTROLLED, assume CUI. If starts with CO, assume CONFIDENTIAL. If starts with S, assume SECRET, and if starts with T, assume TOP SECRET. For all other entries, assume PUBLIC RELEASE.

If imported CKL is > classification than system, display a warning pop-up about classification mismatch but continue the import.

Display system classification across all tabs, regardless of which CKL is open.