FAQ: Security Worlds and Admin Cards - Common Questions

Introduction

Security World admin cards are generated when building the Security World. Admin cards are only used when initializing a device into a Security World. Admin cards are not used on a day to day basis.

Frequently asked questions and answers related to the admin cards and Security Worlds are below.

  1. How many cards should be generated when creating the Security World?
  2. Where should the cards be stored?
  3. Can we replace the cards if lost?
  4. Can we add admin cards to the set?
  5. Can I check and/or change the passphrase of an admin card?
  6. How many admin cards can we generate?
  7. How many Security Worlds should we have?
  8. What is the Sentry bootstrap (.fsb) file?
  9. What is best practice for managing/storing the admin cards and the bootstrap file?
  10. How do Security Worlds impact the import/export/transfer of Sentry configuration files (FSX and FSG)?
  11. Where can I find more information?

  

Frequently Asked Questions

1. How many cards should be generated when creating the Security World?

Forum Systems recommends initializing at least 8 admin cards for every Security World. If Sentry appliances will be in multiple data centers, you should store at least 2 cards in each data center. If you plan on adding Sentry devices to additional data centers in the future, generate additional extra cards.

 

2. Where should the cards be stored?

Admin cards should be stored in each data center containing a Sentry appliance. Additional admin cards for the Security World should be stored in a safe that is offsite, easily accessible to the team who manage the Sentry instances.

 

3. Can we replace the cards if lost?

Admin cards can be replaced, but only if an existing admin card is available. It is not possible to generate a new set of admin cards for an existing Security World without one of the original admin cards. When replacing the set, you can only generate the same amount of admin cards that were generated initially. So if you only generated 1 admin card originally, when you replace you can only generate 1.

 

4. Can we add admin cards to the set?

No. You cannot generate additional cards for your set. You can only replace the entire set. When replacing the set, you can only generate the same amount of admin cards that were generated initially. So if you only generated 1 admin card originally, when you replace you can only generate 1.

 

5. Can I check and/or change the passphrase of an admin card?

Yes, you can both check and change the admin card passphrases. This is done via the CLI of one of the appliances in the Security World.

 

6. How many admin cards can we generate?

A total of 64 admin cards can be generated for each Security World.

 

7. How many Security Worlds should we have?

Most Sentry deployments with HSM appliances (4564 / 3564 models) have a single Security World for all devices. Some deployments choose to have separate Security Worlds for different environments (UAT, Prod, etc..) and/or different data centers. If the devices are in different Security Worlds, you are unable to share Sentry configurations between them. So if you plan on sharing policies between different systems in different environments and/or data centers, the devices need to be in the same Security World.

 

8. What is the Sentry bootstrap (.fsb) file?

The Sentry bootstrap file is a simple text file that contains the Security World information and the network settings of the appliance. The bootstrap can be exported via the CLI when connected via Serial Console only, using a ZModem transfer. It is not possible to download the bootstrap via the WebAdmin interface. The bootstrap file is used to provision a device into an existing Security World, via Zmodem transfer. The bootstrap file can be edited with a text editor to change the network settings for the target device. While the bootstrap file contains the network settings and Security World info, it cannot be used by itself to add a device into a Security World. The admin card (and card passphrase) are also required.

 

9. What is best practice for managing/storing the admin cards and the bootstrap file?

Forum Systems recommends storing the admin cards, with an admin card reader, in a recover box (safe, cash box, fire box). Also stored in the recover box should a USB or CD with the FSB file. Additionally, a  text file with the enable password, admin credentials, and/or contact info for the person(s) who created the Security World and has the passwords.

If the cards will have different passphrases, numbering the cards and listing them out in a spreadsheet with the passphrases is recommended.

Be sure to gather the passwords and card locations from any employees leaving the Sentry admin group.

 

10. How do Security Worlds impact the import/export/transfer of Sentry configuration files (FSX and FSG)?

With the Sentry HSM appliances (xx64 models), the keys are stored in FIPS 140-2 Level III encrypted format and can only be decrypted by HSM modules tied to the Security World. When a configuration is associated to a Security World, it can only be transferred into another Sentry instance that resides in the same Security World. This is applicable to both full and partial GDM transfers.

It is possible to transfer a full or partial configuration that is not associated to any Security World into a Sentry instance that is associated to a Security World. However, the reverse is not possible – you cannot transfer a full or partial configuration from a Sentry instance in a Security World to another Sentry instance not in the same Security World.   Once the import has been completed into a device with a security world, it becomes formatted and encrypted exclusively for that device, or other devices within the security world.

A common deployment option is to have development instances of Sentry running on non HSM appliances or as software instances (Windows, Linux, Solaris) while the production Sentry instances are HSM appliances. In this case, it is possible to build the policies in the development (non-HSM) instance and then transfer them into the production HSM instances.

So this is OK:


Software >> Appliance (Non-HSM)
Software >> Appliance (HSM)
Appliance (Non-HSM) >> Software
Appliance (Non-HSM) >> Appliance (HSM)

But this is NOT OK:

Appliance (HSM) >> Software
Appliance (HSM) >> Appliance (Non-HSM)
Appliance (HSM) >> Appliance (HSM but different Security World)

 

11. Where can I find more information?

Attached are a few guides that cover this information in more detail. If you have additional questions please open a new Help Desk ticket.

0 Comments

Article is closed for comments.