Base a new project on an existing STIG

[aaronlippold]

No description provided.

[ejaronne]

For example, a user might be building a new STIG based largely on a previous STIG, such as going from Windows 2016 to Windows 2019. While re-accounting for NA and inherently meets is still important wrt the original SRG, jump-starting the process by re-using rules from a previous STIG saves a lot of time!

[rlakey]

I don't think Aaron was referencing that type of use case.

The copy component workflow allows someone to copy a component from one project to another to do what you are describing, and jump start the process.

[ejaronne]

For example, a user might be building a new STIG based largely on a previous STIG, such as going from Windows 2016 to Windows 2019. While re-accounting for NA and inherently meets is still important wrt the original SRG, jump-starting the process by re-using rules from a previous STIG saves a lot of time!

[ejaronne]

Simplifying the ask to get this workflow moving

[rlakey]

Seems to be a duplicate of #416 then.

To be more specific we don't need to base a new "project" on an official STIG we need to be able to create a "component" from an official STIG.

Once the official STIG is imported then you could copy/duplicate component to a new component to then begin your work.

[ejaronne]

The only problem is that the STIG does not have the original SRG content (SRG Requirement, SRG VulDiscussion, SRG Check, SRG Fix), but the new Project still needs full original context.

[aaronlippold]

What I really mean by this is 'close / related' requirement linking with a modal/screen with the ability to 'copy from' to simplify reuse.

If I have a database component on linux - being able to reference / see the same requirement (SRGID) from PostgreSQL or Oracle see how it was done there makes a lot of sense.

This won't have the full set of course but it does shorten my workflow.

We do this often with STIGVIwer just trying to bring that work pattern more directly into the Vulcan UX

[rlakey]

@ejaronne Just like with import from spreadsheet we choose an SRG to import against in the workflow. We would do the same with importing an official STIG. Import RHEL 8 or whatever, pair it with the GPOS SRG, and any requirements not covered in the STIG are added and set to Not Yet Determined.

I'm using the terms "project" and "component" to be more specific to the constructs in Vulcan. A project is just a collection of components and what you are wanting to import and create is a component and not a project.

[aaronlippold]

exactly, we are using Solution of Equations by Interpolation given that each uses a common root - the SRG - to help inform our new solutions on validated ones in the same solution space.