Resticting Top Secret SCA signon access

Products

• Top Secret

Issue/Introduction

How do you limit where the SCA can signon to limit potential exploitation?

Resolution

 

To limit the potential exploitation of the SCA, restrictions should be placed on the acid to limit where it can be used.

 

1. Restrict its use by FACILITY

 

TSS ADD(sca_id) FAC(facility_name)

 

SCA will be allowed to sign on only to the designated FACILITY.

 

2. Restrict it by SOURCE

 

TSS ADD(sca_id) SOURCE(terminal/IP)

 

Note:

• The application requesting the signon must pass the terminal/IP address.
• There will only be SOURCE checking if this information is present on the RACROUTE VERIFY signon call.
• Top Secret cannot control whether the terminal/IP is passed on the RACROUTE VERIFY. The 3rd party application is responsible for passing the terminal/IP.

 

3. Restrict it by CPU

 

TSS PER(sca_id) CPU(CPU)

 

SCA will only be able to sign on to the specified CPU.

 

4. Limit SCA TSS ADMIN privileges on "as-needed" basis.

 

Example:

If the SCA is only resetting passwords, then only that TSS ADMIN privilege should be given and not allow updating the user privileges.

 

CASECAUT admin control

TSS ADMIN command

 

5. If the SCA uses CA LDAP to read and update the Top Secret Security File, SSL should be configured in CA LDAP to establish a secure connection.

 

6. If the SCA will be used for a started task region acid, recommend creating the acid with the PROTECTED attribute.

 

Acids with the PROTECTED attribute do not have passwords and can ONLY be used with started tasks or batch jobs.

Since the SCA doesn't have a password, it cannot be used to signon to a terminal.