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.
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.