12. Exporting Your Content
12.1 Exporting Your Content
At this point, we have tailored two requirements from the original SRG into STIG-ready content, marked one as also satisfying another requirement, and peer reviewed them. Let's imagine that our team has completed the process of tailoring each SRG requirement into a STIG requirment, and that each requirement has been peer reviewed. Perhaps we have even already created some automation for these requirements. In other words, we have a complete security guidance document!
Let's discuss what we can do with our components after we finish the requirement writing and reviewing.
12.2 Exporting the Guidance Document
We have a few ways of exporting the content from Vulcan once it is written.
Use the "Projects" link in the Vulcan navbar to return to the projects list page. Then click on your RHEL9 project to return to your project view.
On the right-hand side, the overall project summary now reflects that we made edits. You'll see a number of buttons alongside the bottom of the Component we have been editing.
From left to right, those buttons will:
- Lock all Component controls from further editing
- Export the Component's InSpec code as an archive of an InSpec profile
- Export the Component as an XCCDF XML file
- Export the Component as a comma-separated values file (CSV)
- Release the Component -- note that this option is not enabled unless all controls have been locked from further editing
- Duplicate the Component -- this creates a copy of the Component within the same Project; useful for creating a new release of the same Component without having to change the original
- Remove the Component -- Careful with this one!
- Open the Component -- Takes us to the editing screen
12.2.1 Notes on Releasing
A component can only be released if every requirement is locked. Requirements are only locked from further editing when they have undergone peer review, or when someone with administrator permissions locks a requirement regardless of review status. Note that even admins cannot lock a requirement unless it at least has a status determination (i.e. it is set to a status other than "Not Yet Determined," so we cannot lock our RHEL9 component just yet). Therefore, releasing a component should only happen when all authorship is complete.
Importing a Released Component
Once a Component is released, it can be imported into a different Vulcan project as a building block.
One of our purposes with Vulcan is to avoid duplicating effort wherever possible; if the guidance is already written, we want to be able to access it!
12.2.2 Notes on Exporting
Unlike a formal release, the Component does not need to be locked to be exported (in any format). You are not required to keep your editing workflow inside Vulcan (though we do, of course, recommend keeping your workflow inside Vulcan where you can).
Note
This means, for example, that we can export our InSpec profile regularly to test our code against test systems throughout the authorship process.
We can also export the InSpec profile for a Component even if we haven't written a single line of InSpec code for it. Recall that Vulcan can automatically use our security documentation to create metadata for automated tests. Exporting the profile will give you a "skeleton" profile that has files for each requirement with the metadata tags applied correctly; this alone can be a huge time saver!
12.3 Diff Viewer
We have spent quite a bit of time discussing how to use Vulcan to make initial authorship easier. However, Vulcan also has features intended to make the maintenace of your guidance documentation easier.
This is why we have a Duplicate Component button available on the Component card, for example.
12.3.1 Creating a Different Component
We will not be releasing the Component in this class because that would require us to at least have made a Status Determination for each requirement. We can, however, create a Duplicate of the component. Let's do that now.
Why are we duplicating the Component?
In a complex system with many software components, it may make sense to create multiple Components in one project, all of which have a shared source SRG.
For this example, we are duplicating the Component to mimic the release process.
Click the "Duplicate the Component" button on your Component for RHEL9. You will see a pop-up that is similar to the one you saw when creating the first Component from an SRG.
This time, we want to mark this Component as Version 1, Release 2, to represent the next release of STIG-ready content for the same software. Since we have created a new Component, we should change something inside it. Let's open up the component and edit another one of the controls. Any will do.
Save the edit, just like you would in the first release. Go back to the Project page and click the Diff Viewer tab. You'll get a menu asking you which two Components you want to compare.
Let's pick our two different releases of our RHEL9 component (make sure you pick your own project's RHEL9 component if you are using the training class instance of Vulcan). We get a side-by side comparison view of our components, highlighting changes.
Duplicating a Component automatically generates empty InSpec stubs inside the new component, but a new-from-scratch Component does not automatically generate InSpec code. This is why the Diff viewer shows no InSpec code in the V1R1 version of the document, and why it believes that every requirement has a change. Note also that we are actually comparing the InSpec code for each requirement so that we can take advantage of the style of comparison used by code editors.
How do I use this?
The Diff Viewer's main use is for comparing completed released components. You can compare releases to tell at a glance what has changed in a piece of guidance, which traditionally would require tracking everything in a changelog manually.
At this point, we have gone over most of the processes you would use in Vulcan to develop your own security guidance content. To close, let's review the process for formally publishing a STIG.