You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our understanding of declass guidance was wrong. Declass date should be 25 years from the date the document was generated. This applies to any exported data type - eChecklists or .ckls. I think the right way to do this is to base it on the date of the source data (i.e., date fields in Nessus/nmap scans, SCC results, imported .ckls, eChecklist, or host data/configs). Using the source scan date precludes the problem of moving declass dates (i.e., declass date shifting depending on when the data was exported or imported). Overall date should be the latest of any source data used in the generation of the export (i.e., if the eCheclist is completed 3 days after the SCC, the eChecklist date + 25 years should be used the next time an eChecklist or .ckl is exported).
Of course, this will mean we no longer need to configure a "Declassify On" value in the config file, setup.php, and database.
The text was updated successfully, but these errors were encountered:
I think we need a more static date. What if we were to go based on the ST&E assessment ending date? The problem with using the file dates is that some of the exports are based on more than one import. And those imports could take place over several days. Overall, you're talking no more than a couple days difference. The most problematic thing with this approach is the final reports that would take place after that. You guys give your self, what, 14-30 days to churn out the reports? Maybe some of the report formats declass date would be based on the report generation date (if they take place after the end of the ST&E)?
I think ST&E end would work for eChecklist exports. As for the report, you should probably just use the date the report exports. It's going to be changed after export anyway and coordinated, so the ultimate date will be based on the date of the signed report anyway (which will likely always be an unknown amount of time later than the date exported form Sagacity)
Our understanding of declass guidance was wrong. Declass date should be 25 years from the date the document was generated. This applies to any exported data type - eChecklists or .ckls. I think the right way to do this is to base it on the date of the source data (i.e., date fields in Nessus/nmap scans, SCC results, imported .ckls, eChecklist, or host data/configs). Using the source scan date precludes the problem of moving declass dates (i.e., declass date shifting depending on when the data was exported or imported). Overall date should be the latest of any source data used in the generation of the export (i.e., if the eCheclist is completed 3 days after the SCC, the eChecklist date + 25 years should be used the next time an eChecklist or .ckl is exported).
Of course, this will mean we no longer need to configure a "Declassify On" value in the config file, setup.php, and database.
The text was updated successfully, but these errors were encountered: