6 Business continuity planning

MyID is designed to be a critical part of enterprise security architecture and needs to be fully integrated into a disaster recovery plan. The critical part of any disaster recovery system is advanced preparation.

In practice each system deployment is different, with its own characteristics. While this document can provide a high-level outline plan, we recommended that you contact Professional Services at Intercede to design a full disaster recovery capability.

6.1 Phase 0: pre-disaster

Ensure you have backed up the live data.

• Backup the MyID databases on the existing live server.

• Backup the MyID data in the upimages folder on the live web server, if necessary.

• Backup the MyID windows registry information on the live application server.

• Ensure any security credentials are backed up. For example: authentication or signing credentials to access a PKI system, or HSM data.

• Store copies of the MyID application software, plus any local customization and patches, in a secure location, off-site.

6.2 Recovery

Disasters can happen on many levels, from losing just one disk on one server through to an entire server infrastructure being lost. This section describes rebuilding a full three-server MyID installation. You can use portions of this information if the disaster is confined to a specific server.

Warning: Before attempting any system recovery, we recommend that you contact Intercede’s support team to validate your recovery plan.

6.3 High-level recovery plan for re-building a three-server architecture

Note: This section assumes a standard three-server architecture without advanced configuration such as a DMZ.

6.3.1 Phase 1: Prepare new servers

1. Install Windows Server on three new servers: web, application and database.

   • SQL Server should be installed on the database server.
   • All three servers should be members of the same Windows domain.
   • Ensure that the time on the new database server is synchronized with the time on the previous database server.
2. Restore any third party systems that MyID requires access to, for example a directory or certification authority (CA).
3. Restore any credentials needed to access the third party systems: for example PKI keys, HSMs.
4. Install the MyID web, application and database components on the appropriate servers. Follow the installation documentation but incorporate any site-specific deviations that you made for the original installation.
5. Install any local customizations and patches.

6.3.2 Phase 2: Restore backed-up data

1. Restore data from the upimages folder on the live web server to the web server.

   If you are using an external server as an image store, you may not need to carry out this step.

2. Restore the MyID registry files from the live application server to the new application server. This will overwrite the existing registry settings, with the appropriate key information relating to the backed up database.
3. On the database server, replace the newly installed MyID databases with the backed up database from the live system.
4. Replay any transaction log data from the live system to the new database to ensure data is restored up until the point of failure.
5. Check the Configuration tab on the System Status report and update any configuration options that refer to specific server names or IP addresses.
6. Reboot the three new servers to ensure they are using the new registry and databases.

6.3.3 Phase 3: Test new system

1. Test basic MyID operations. For example, can Operators logon with their smart cards.
2. Test end-to-end card production.
3. Assuming everything is functioning correctly, backup the new MyID database.

6.4 Two-server and one-server architectures

The procedure for two-server and one-server architectures is essentially the same as for a three-server architecture. Apply the appropriate steps to the relevant co-located server.

6.5 System integration

MyID is designed to interact with third party systems, such as directories and certification authorities. Depending on the scope of the disaster, these systems may need to be restored as well.

This introduces a complexity in the recovery timing that needs to be carefully planned to ensure the security integrity of the overall system. Care needs to be taken to ensure that the recovered system has end-to-end data integrity.

For example consider a three-component system, containing a directory, a CA and MyID. To issue a PKI credential, the user must be known to all three components.

In a disaster where data recovery is required, it is important to ensure that MyID, the directory and the CA are all restored to exactly the same point in time. If not:

• The directory may contain users not in MyID, if the database was recovered from a later period than MyID.

• The CA may have records of certificates issued that are not known to MyID and so cannot be revoked by MyID. This would happen if the CA was recovered from a later period than MyID.

• MyID may have knowledge of credentials issued that are not known to the CA, if the CA was recovered to a period of time before MyID. This is a critical security issue as in principle a live certificate has been issued by MyID that cannot be revoked, as the CA has no knowledge of it.