Que es una carta de riesgo ?

Que ocurre cuando se necesita ejecutar un proceso que no cumple con la política de seguridad de la compañía pero que es vital para el negocio ?


Para estos casos "excepcionales" existe lo que se llama una Carta de riesgo.


Esta carta o formulario, identificara los riesgos asociados con esta practica fuera de los estandares y los perjuicios que esta practica generen, seran responsabilidad de los firmantes.

A modo de ejemplo, IBM cuenta con un Documento de Controles de Seguridad de la Información (denominado GSD331) que acuerda y revisa con cada cliente cuando se firma un outsourcing.

Cuando un cliente no esta compliance con las recomendaciones de este manual, entonces IBM emite una carta de riesgo firmada por el cliente de manera de cubrirse ante los posibles problemas. ( Hay penalidades por QoS )

Por ejemplo, tenemos un server Unix bajo outsorcing, el cual es administrado por el equipo tecnico de IBM, el server tiene una aplicacion que debe ejecutar como root.

Esto no estara en compliance con la GSD331, ante lo cual se emitira una carta de riesgo.


Otro ejemplo es este template utilizado por el DoD de EEUU para la transmision de documentos sin encryptar, se puede notar que ademas de mencionar el riesgo, se mencionan los pasos a dar para mitigar el riesgo en caso de problemas :


ACKNOWLEDGEMENT OF RISK LETTER TEMPLATE


Unencrypted File Transfer

Unencrypted Terminal Sessions

30 August 2004

Version 1.1


We, the undersigned, acting as the Office of Primary Responsibility for [system/application name] and local Designated Approvinig Authority, have read the appropriate Operating System Security Technical Implementation

Guide(s) (STIGs), which discuss the risks inherent in the use of (unencrypted file transfer or unencrypted terminal sessions) to perform (data transfers or terminal sessions) as part of an automated system to system interface. We have evaluated the alternatives to using (FTP or telnet) and have determined there are no currently available alternatives that meet our operational requirements. We have reviewed the risks associated with using unencrypted (file transfer or terminal sessions) and the controls that are in place to mitigate this risk. The primary risks and controls are reiterated in the following paragraphs (the following are examples, you should detail the risk and controls below):


1. Maintaining automated scripts that contain userid/password pairs in a file on a system increases the potential for their compromise. As a mitigating control, we will ensure all scripts; JCL, Executive Control Language (ECL), programs, and/or data files containing one or more userid/password pairs are secured. In addition, we the office responsible for the scripts, JCL, ECL, programs, and/or data files will restrict access to the files to the fewest practical number of personnel.


2. The use of (FTP or terminal sessions) requires the userid/password and application data to be transmitted
to/from the host system in clear text, across unsecured communication lines. While some data transfer can
encrypt the data from point of source to destination, not all data transfer tools do. This increases the potential
for compromise by various means (e.g., a sniffer program). The primary risk to the data source is disclosure of data to unauthorized persons, and the primary risk to the data destination is interception and modification of
data by an unauthorized person. There is no direct mitigating control for this risk, but the office responsible for
installation and configuration of the userid used for this interface will ensure the userid is configured with the
lowest privilege level possible in order to limit the damage that it can do if compromised.


3. The compromise of the userid/password or application data could remain undetected for a long period of time. The password for this data transfer userid can (if justified/documented) be set to “ an extended expiration,” providing a procedure is developed and implemented, in coordination with the DAA and data owner, to manually change the password at least once a year or when an administrator with knowledge of the password leaves. The use of an extended expiration password increases the window of exposure to the system in the event the userid and password are compromised. This risk can be mitigated by periodic password changes even if the password is set with an extended expiration.
We will ensure the mitigating controls that must be implemented are accomplished. We will acknowledge any risks associated with not properly implementing these controls. We understand that any security violation traced back to a (FTP or telnet) may result in the suspension of system access for that userid and the security violation will be referred to the proper authorities for further investigation and action. We will ensure a copy of this letter is filed with the System Security Authorization Agreement (SSAA). This letter will be reviewed at least every 18 months or until some or all of the information below becomes outdated, or until the use of (FTP or telnet) is terminated.