Introduction

OpenFISMA contains a built-in script for setting up automated backups of system data. The backup facility provides a reactive measure against security incidents involving unauthorized modification or destruction of data. For example, if an agency has a policy of backing up OpenFISMA on a nightly basis, then no more than 1 days's worth of work can ever be lost in the application, even if the application is completely compromised.

The built-in backups should be used in parallel with standard backup procedures. Most standard backups will involve backing up the complete contents of the system; the OpenFISMA, backup, however, backs up only the application data and source code. The result is that the OpenFISMA backup can be used to very rapidly bring the application back to a stable state, compared to a system-level backup which might take several hours to restore.

Usage

The backup script is contained in the /scripts/bin folder of the OpenFISMA project. The script is configuration based, meaning that most functionality is specified in a separate configuration file rather than on the command line. Before using the script for the first time, edit the included file called /bin/backup-restore.cfg. At a minimum, you should configure the following parameters:

• dbUser
  • The username that the backup script should use when connecting to your database instance. For security reasons, this account should have access restricted to the minimum -- see the Best Practices section for more details.
• dbPassword
  • The password that the backup script should use when connecting to your database instance.
• dbSchema
  • The name of the application schema.
• appRoot
  • The root of the openfisma application. Everything under this directory tree will be included in the backup.
• backupRoot
  • Where to store the backup archives. Ideally this path would be mounted on a different file system -- see the Best Practices section for more details.
• retentionPeriod
  • The number of days an archive is allowed to age before being purged. See the Best Practices section for more details.

The syntax for running the command is very simple because most of the options are handled in the configuration file:

PERL5LIB=/bin/ /usr/bin/perl <appRoot>/bin/backup.pl

Substitute the path to the application root for <appRoot>. The "PERL5LIB" notation sets up a temporary environment variable so that the script can find it's local libary.

When running the script as an automated job (for example, a cron job), the following syntax addition is suggested:

PERL5LIB=/bin/ /usr/bin/perl /bin/backup.pl 2>&1 >> /var/log/openfisma.log

This syntax will log all script output and/or errors into an openfisma.log file.

Incident Recovery

In the event that an incident occurs and the application needs to be recovered, the following process should be used. (There is currently no automated process for recovery, although that feature is scheduled for future development.)

1. [optional] Run the backup.pl script
   1. Backup the system in it's compromised state. The backup might be useful for later analysis of the incident.
2. Copy the backup archive file into the server's web directory
   

   cp /var/backup/<backupname>.tgz /var/www/openfisma.tgz

3. Extract the archive
   

   cd /var/www
   tar -xzf openfisma.tgz
   cd openfisma

4. Load the application schema.
   1. Login to mysql as a user with enough privileges to create and delete schemas:
      

      mysql -u <user> -p

   2. It may be necessary to first drop the existing application schema:
      

      drop schema <
      appSchema>;

   3. Recreate the application schema and load the backup data.
      

      create schema &lt;appSchema&gt;;<br />source schema.sql;

5. Point the server web root at the /public directory of the backup and restart the web server:
   1. The syntax for this depends on which webserver you are running.
   2. Alternatively, rename the backup to the same name as the existing application.

Recommended Best Practices

The following are considered best practices for OpenFISMA application backups.

• Use a read-only account for the backup script.
  • The read only account needs the following permissions on the application schema: SELECT, LOCK TABLES
  • GRANT SELECT, LOCK TABLES TO 'backup_readonly'@localhost IDENTIFIED BY ''
• Set the backup root to a directory which is hosted on a different file system than the application.
  • In the event of a disk hardware failure, the backups will be intact.
• Automate backups on a nightly basis.
  • Using cron or some other scheduler, execute the backup script once per day.
  • The suggested backup window is at night; the backup script will lock certain tables while backing up, and any users logged in at the time may experience slow performance as the application blocks for access to those tables.
  • Log the automated output to a central log file, and periodically check the log file to make sure the backups are running smoothly.
  • If the application is not used on weekends, then set the backups to only run on week nights; this will save disk space by reducing redundant backups.
• Set the retention period to 19 days.
  • This will ensure at least 15 business days of backup. If an incident is discovered several days later, the backups can be used to understand what the data looked like at any point in the last three weeks.
  • Ensure that you have enough available disk space for this many backups.