Tripwire Enterprise (TE) is at its heart a baselining engine. It’s been built to take information, create a baseline of it, and show when that baseline has changed. (It’s called a “version” in TE terms.)

TE starts with a baseline version designated by an organization’s security teams. At some point, a change version with new information (file, registry entry, RSoP, command output, or data captured in some other way) emerges. If the change was expected, TE helps customers to promote the change to the baseline. The current state of the information then becomes the new baseline.  The baseline for each system is the current system state.

DevOps Experience

Change Management: Not All Changes Are Equal

When it comes to change management (aka file integrity management), however, not all changes are equally interesting for security, risk and compliance, or IT. There are files that change on a system constantly. These include log files, cache files, database records, and the like. Are there any security implications when those files change? Are there any change management implications of changes to those files? 

Why yes, yes there are important reasons to track changes to those files. But not so much for the content changes. For log files, you should have processing in place to immediately send those to a centralized logging and alerting solution (like Tripwire Log Center, for instance). That way, even if someone tampers with the logs on a system, Tripwire Log Center or another solution has already received, hashed, and secured the real logs. This helps to preserve the real log files as the source of truth, thereby recognizing that cache files and temporary “tmp” files are not normally tracked for content changes.  

Given that the logs are preserved, do you even need to track the log files? (Read more...)