tripwire-open-source VS book

Tripwire's open source distribution specifically. It supports SHA1, MD5, HAVAL and CRC32. All individually are not cryptographically secure but the combination of them makes it unlikely that an attacker could modify a single file in such a way as to find a collision on multiple hashes.

I'm looking at current options, this[1] for example is packaged for Fedora, which is my daily driver.

But then I got to thinking, if I'm going to do a clean Fedora install for the tripwire (it's best practice) I might as well try Fedora Silverblue[2]. Silverblue is an immutable system so it kinda makes a tripwire less useful because no one can change any system files. Only files in your home directory and /etc can be modified statefully.

1. https://github.com/Tripwire/tripwire-open-source/

2. https://silverblue.fedoraproject.org/

Active Measures - Includes (IDS/IPS) such as open-source Suricata or Snort on pfSense, and File Integrity Monitoring (FIM), such as the commercial Tripwire and dated, open-source Tripwire, or the open-source Wazuh installed on servers. These can be combined into a Security Information and Event Management (SIEM) system like the open-source solution, Security Onion. Wazuh itself has evolved into a SIEM.

This reminds me of the general idea behind [Tripwire](https://github.com/Tripwire/tripwire-open-source) for macOS. I last looked into it back in 2005 (we went with other approaches), so it may have changed since then, but it monitors for changes, and allow you to revert them or deploy them to other computer (as in a lab, etc).

Yes, tripwire. https://github.com/Tripwire/tripwire-open-source

> For details on how I use Qubes specifically see: https://github.com/hashbang/book/blob/master/content/docs/se...

How is this not a contradiction?

>6. Manual PRIVILEGED SYSTEM mutations MUST be approved, witnessed, and recorded

>7. PRIVILEGED SYSTEM mutatations MUST be automated and repeatable via code

Some of my clients pay to do double review of all dependencies.

Others go as far as distributed deterministic builds to ensure CI/CD systems themselves are not compromised.

Here are the latest public iterations of my recommendations.

https://github.com/talos-systems/rfcs/blob/main/001-software...

Also here are complimentary practices to ensure the production engineers that must have access to CI/CD systems etc don't themselves become a weak link in the supply chain (which happens a -lot-).

https://github.com/hashbang/book/blob/master/content/docs/se...

Shameless plug: My company Distrust (short for Distributed Trust), offers auditing, consulting, and support so companies can avoid single points of failure in their supply chains from third party libs to the hands of end users. Happy to chat with anyone that wants some outside eyes in this area!