Logic bombs, Part 2

It is very difficult to stop a determined inside attacker from modifying production code to install logic bombs. Preventing such bombs requires a thoroughgoing commitment to quality assurance and strict separation of duties.

Here are some well-known principles for making the logic bomber's task more difficult:

- Segregate operations from programming and testing.

- Institute a carefully controlled process for moving code into production.

- Give only operations staff write-access to production code.

- Lock down your production code - source and executable - so that it is as close to impossible as you can get for unauthorized people (users, programmers, anyone) to modify programs.

- Assign responsibility for specific production programs to named positions in operations.

- Develop and maintain a list of authorized programmers who are allowed to request implementation of changes to production programs.

- Require authorization from the authorized quality assurance officer before accepting changes to production.

- Keep records of exactly which modifications were installed when, and at whose request.

- Use hash functions on entire files in the production library.

- Recompute all hashes against a secure table to ensure that no one has altered production files without authorization and documentation.

- Keep audit trails running at all times so that you can determine exactly which user modified which file and when.

- If possible, ensure that audit trails include chained hash functions. That is, the checksum on each record (which must include a timestamp) is calculated not only on the basis of the record itself but also using as input the checksum from the previous record. Modifying such an audit trail is much more complicated than simply using a disk editor to alter data in one or two records.

- Back up your audit files and keep them under high security.

Join the newsletter!

Error: Please check your email address.
Show Comments

Market Place