Standalone Configuration

Samhain (standalone)

  • Monitors local host
  • Uses local baseline database
  • Reports to (e.g.) syslog, log file, or email.

For larger installations, you may want to consider a Basic Client/Server or a Full installation.

Change Control Process Integration

Production machines have scheduled changes
...and those should not raise alerts

In most production environments, there are more or less frequent changes owing to a number of reasons, such as:

  • the installed software needs to be patched for security vulnerabilities.
  • new software packages have been requested by users, or
  • configuration files need to changed.

These changes can make the use of file integrity monitoring very awkward, especially if the environment is volatile or the number of monitored systems is large, unless by integration into the change control process one can avoid alerts for scheduled changes.

Samhain can integrate into your change control process

When we say »integrate into your change control process« we mean that Samhain provides the required feature set to meet the following list of criteria.

  1. The whole procedure can be run in an automated way, i.e. it can be executed by scripts and without human intervention, once a list of affected files is available.
    • It is expected that the change control process will yield the list of affected files from the development or quality assurance stage.
  2. The feature set provided by Samhain is rather generic and not tied to any particular change control software.
  3. Immediately before a change is implemented, the affected files can be tested for their integrity. I.e. it can be verified that the system is in a »known-good« state before the change is put into effect.
  4. After a change is implemented, the baseline, i.e. the database of »known-good« file signatures, can be updated.
  5. The approval of the change(s) performed can be securely communicated to the running Samhain daemon on the affected machine(s), such that a subsequent file integrity check will raise no alerts.

Use cases

The feature set provided by Samhain has been drafted as the result of a workshop with the participation of iSAX, among others. The use cases that were discussed are as follows:

Case I: Machine taken offline for a large patch

This case is best handled by a comple re-initialisation of the baseline database. The running Samhain daemon would perform an on-demand file system scan immediately before the machine is taken offline to ensure a valid state, the database would be initialized after the patch has completed, and the Samhain daemon would re-start when the machine goes online again.

Show me the details
Case II: Installation of a new package

In this case, because the package is not installed yet a "pre-flight" scan may be deemed unneccessary. After installation of the package, a »DeltaDB« (delta database) containing the added files would be generated and transferred to the server. There, it would be merged into the existing baseline database.

The approval of the file system changes would then be done by the server asking the client to download the DeltaDB. For security, there is no client-side mechanism to trigger an approval of the file system changes.

Show me the details
Case III: Configuration change / Package upgrade

This case differs from Case II insofar as there are already installed files, and therefore it is desirable to verify the integrity of those files before the change is put into effect. To perform this check, one would generate on the server a »PartialDB« (partial database, containing only data for affected files) from the full baseline database, transfer it to the client and perform a verification scan.

If the affected files are found to be in a consistent state, one would proceed as in Case II then.

Show me the details