Version Tracking

[damacguy]

Could there be an option to append custom info to the items (policies, EAs, scripts, etc) being uploaded to Jamf. I'm thinking that compliance settings should be reviewed, if not updated, on at least an annual basis if not more frequently. Obviously the items have the OS release name, but what about if there are updates to an existing release. I'm thinking maybe a date stamp?

Currently an example is "Sonoma_cis_lvl1_compliance.sh", but maybe Sonoma_cis_lvl1_[240509]_compliance.sh (indicating May 9, 2024 (abbreviated take on ISO 8601).

[georgalis]

I strongly support this tracking. As a consumer and integrator of security tools, I can speak from experience, running hardening tools is not sufficient for compliance verification. This is roughly related to #375 for which I've gathered extensive followup notes, which I intend to eventually reduce to something more of a chapter, verses a book legnth---the gist of which is the disposition of a public consumer vs a mandate directed author is very likely 180 degrees apart. There can be no consensus if the terminology is ambiguous, or even if there is expectation that the consumer embrace the authors perspective and depth. Nor, if the author refuses to consider the consumer's depth. An example irony, "stepping into the direction of developing a complete CDM-like solution, [is] not the intent of the MSCP" and "the actual implementation of security configuration settings is not in scope of this project" is precisely contrary to a public consumer's perspective of what this project is about. A full regression of NIST documentation should not be required of the public for clarity on that; indeed, I don't believe that interpretation is stated, rather can only be inferred by the fact that it is not mandated.

I am obviously bias towards preservation of artifacts indicating "files changed" in the course of benchmark construction. If for no other purpose than to facilitate the application of the benchmark! That does not mean I am looking for a configuration management solution, in fact I am totally opposed to any new solutions like that. Nevertheless, the authors of this project are uniquely qualified to produce benchmark artifacts for integration with any site configuration management tools already in place. (And, changed file listings would be especially useful for sites which do not have any configuration management.)

Here is an example of how this Version Tracking option could improve compliance certification. Sites implemented a STIG on RHEL systems. I believe it was this one https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2022-09-07/finding/V-230349 however, the example therein is malformed. While the STIG intent of session lock management with tmux is perfectly reasonable, that example implementation (which is what people use) doesn't connect new logins to prior sessions, rather it simply spawns a new tmux session for EVERY login, typically the login times out and the session never ends. So you have a scenario where Trellix EPo is connecting, on an interval, to all of the servers for a security scan or update, spawning a new shell and tmux session, each time and they never close. Eventually you have many 100s unattached sessions, and nobody noticing 100s of processes using up resources, until Trellix EPo fails to update, then fails to connect, etc. Typically the security group monitors endpoint agent failure reports, but this case is special, the alerts were created (and working) when this system was setup, but when the system becomes so degraded the agent cannot run properly, that's just an error in the logs, not a monitored alert.

When everyone is (only) following their mandate, nobody notices stuff like this, and eventually updates aren't applied to the system and the site degrades because nobody considers STIG deprecation, or otherwise catches the misconfiguration. This STIG has been retracted, but just now, I cannot figure out how that would be determined, or what would trigger proactive STIG rollback? When I discovered the problem, I was told it was a STIG compliant system. The only practical solution was to find the broken code fragment in /etc, manually fix it, scan and remediate all the other broken systems, before they became critical.

It is difficult enough to approach double-entry bookkeeping in resource provisioning, likewise it is not reasonable to expect security to certify that all systems are not out of compliance (CDM?)---we generally only test if they are within compliance. If we rely on benchmarks without change artifacts, I for one would certainly appreciate some version annotation, indicating for example whether a particular MSCP revision has addressed a deprecated STIG, or similar unanticipated remediation type. Short of that type of validation notification/communication, the alternative path for improved readiness, is more frequent deployment iteration (or a robust CDM).