|
SSL Certificate Request Generation for SQL Server
In V-79195, DISA requires confirmation that ForceEncryption is set in SQL Server's Configuration Manager, and that the certificate in use is issued by a valid Department of Defense Certificate Authority. ASSET, of course, checks these settings for you, and provides the necessary validation when ForceEncrytion is enabled and the SSL certificate in use is both valid and issued by a DoD CA.
...but what happens when no valid certificate can be found?
Obviously, you need to generate a certificate request, submit it to a DoD CA, and install your new certificate when granted.
ASSET, as you may know, strictly avoids making ANY changes to your SQL Server, but when an astute colleague of mine pointed out that we could have gone as far as generating the certificate request for him, without violating our "no changes" policy, I had to admit he was right.
Fast-forward to the present and you will find that if ASSET detects an expired, invalid, or missing SSL certificate, the findings details in your checklist will include a dynamically generated certificate request that meets the DoD's baseline standards. You simply copy this into your command's certificate request form (adding any subject alternative names, alias, or IPs you might require) and you'll be finished submitting your request in half the time.
If your application or command has specific requirements that go beyond the generic baseline, you might still need to generate your own CR, but in 95% of cases, our automatically generated CR should meet your needs.
|
|
ASSET's STIGViewer Version Converter
Okay, this isn't exactly a "hidden" feature, but since some of our customer's have indicated they did not know what our Delta STIG Checklist Conversion tool does, we thought it would be best if we provided a detailed explanation.
We are committed to keeping ASSET current with the latest SQL STIG checklist revisions, but there will be times when accreditation efforts or IA demands require you to use the latest DISA checklist revision—or a newer STIGViewer format—before we have updated our vulnerability suite to reflect these changes. When this happens, you can convert an older checklist to a newer revision with minimal effort.
To convert an older checklist to a new DISA revision or STIGViewer format, simply select File from ASSET’s menu bar, and then Delta STIG Checklist Conversion from the sub-menu below:
The checklist conversion form below will appear:
Select the Browse button next to the Checklist To Convert field and then select the older checklist you wish to convert.
Then, select the Browse button next to the New Checklist Template field. Now you will be able to select either an .xccdf or .ckl file as the template for the desired conversion.
If your IA department has requested a different STIGViewer version, for instance, than the one that ASSET is producing, you MUST create a .ckl template using the desired STIGViewer. With that blank .ckl file as a template, ASSET can usually convert all your information into the new format.
If you only need to convert your checklist to the latest STIG revision, the quickest and easiest way is to simply use the .xccdf file DISA provides with the latest revisions.
If you select the .xccdf option, the Choose xccdf Profile selection box will appear.
Simply select the appropriate MAC and Classification level before continuing.
Once you have made your selections, click the Convert button and when the conversion is complete, the new checklist will be renamed by convention to indicate it is a delta conversion of the original, and saved to the same folder as the original checklist.
When you open the new checklist with the desired STIGViewer, you will find all the results of your previous STIG check intact. For those vulnerabilities that changed from the old revision to the new, however, you will find the status has been cleared and the previous STIG results backed up to the Comments field. The Findings Details will be replaced with a message notifying the user that this vulnerability has changed from the previous revision, instructing the user to manually review those changes, and—if necessary—manually execute a new check with the appropriate revisions.
See the example below of a vulnerability that changed in the new revision, and the Delta Conversion results:
|
