To open the Scheduled Jobs ialog, click Jobs → Scheduled Jobs on the menu or the Scheduled Jobs icon displays the following panel on DACTool:

The panel displays a table with the following columns They are:

SAKA includes five jobs that assist with different aspects of key management. Four of the five jobs can be scheduled to run at a fixed frequency, or executed just once on demand. One job can only be executed once, on demand, and cannot be scheduled for frequent execution. The jobs are:

1. Delete Encryption Requests—allows a site to delete encryption request records from the internal database—along with all related ciphertext (encrypted data)—at periodic intervals if policy and/or business processes require it. Once deleted, the plaintext (unencrypted data) is never available again. The job is disabled by default and must be enabled through its configuration parameter before it can be scheduled to run. If the job is disabled in the configuration section, scheduling it on this panel will not execute the job. A report is generated each time the job is executed and stored in the STRONGKEYLITE_HOME/log directory.

2. Add Pseudo-Numbers—this job allows a site to switch from HMAC tokens to Pseudo-Numbers (PSN) (also known as tokens). An HMAC is a unique value generated by SAKA in combination with a symmetric cryptographic key and an algorithm for a sensitive data item. The HMAC cannot be reversed to arrive at the original value, but can be verified—given the original value, the cryptographic key, and the algorithm—by regenerating the HMAC again and comparing the preserved HMAC with the regenerated one. While fixed in length, HMACs do not resemble data such as credit card numbers or social security numbers. SAKA can be configured to generate numerical tokens that resemble the original data—but are not harmful if disclosed. If a site began using HMACs, but chose to switch to tokens at some point, this job will generate unique tokens for all existing records in its internal database. As the job is executed, a report is generated and stored in the STRONGKEYLITE_HOME/log directory.

3. Rotate HMACs—this job allows a site to rotate HMAC keys and re-generate new HMACs for existing records in the internal database when the HMAC keys change. Some regulations—such as the PCI DSS—require that symmetric encryption keys be changed at least once a year. While SAKA allows minimized risk of key compromise by using a new symmetric encryption key as frequently as every day, the regulation nonetheless requires a key rotation. While the symmetric encryption key can change automatically at customizable intervals, the HMAC key is configured to be used for a full year before it is rotated. However, in order to ensure that the rollover of the HMAC key does not bog down SAKA performance, this job allows the site DA to run the job at a time that is convenient to the site. The key rolls over at midnight of the new calendar year, every year. It is strongly recommended that this job is executed fairly soon—within the first week of the new year—after the key rolls over, lest the system get too critical for this maintenance activity at a busier time of the month/year. When the job is executed, a report is generated and stored in the STRONGKEYLITE_HOME/log directory.

4. Rotate Symmetric Keys—this job allows a site to rotate symmetric encryption keys and re-encrypt sensitive data automatically without the interruption of cryptographic services for client applications. This job is configured to run by default, but it must be scheduled by a site once SAKA is installed. Depending on whether the site's key duration policy is Daily, Weekly, Monthly, or Annually, this job can be scheduled to execute at the same frequency to ensure that keys that are a year old are rotated (for PCI DSS compliance). Sites needing a more aggressive key rotation policy can configure a key rotation schedule appropriate to their needs.

5. Rotate Symmetric Keys Range—this job allows a site to rotate symmetric encryption keys and re-encrypt sensitive data for a range of records, instead of for all records that might meet the default filter (cryptographic keys that are a year old). If configured, the job runs automatically without interrupting cryptographic services for client applications.

This job is useful after the first time a site imports existing records into SAKA. As an example, if the site has 10 million records and they are all imported in one batch job, it is likely that all records will have been encrypted by a single or at most two symmetric data encryption keys (actual time will depend on whether the site has deployed the standard or the high performance machine). While this is very useful from a performance point of view (because there are only one or two keys to use for decryption), this not only becomes a security risk—the more ciphertext existing for a single key, the more useful information a cryptanalyst might gain towards deciphering data—but can be a performance sink during the annual key rotation mandated by PCI DSS: millions of records will have to get re-encrypted within the 24–48 hour period.

Instead, if the 10 million records were encrypted by 350 symmetric keys, at most 29,000 objects are encrypted by any given key, and the key rotation can be spread out over 350 days, ensuring that the re-encryption job finishes in 5–10 minutes each day.

Four buttons are visible on one side of the panel. While they may appear enabled upon first entry to this panel, some buttons become disabled when a specific job is selected from the list. These buttons are: