Introducción

En la actualidad las empresas, sin importar el tamaño y, dada la alta tecnificación en la que se desenvuelven en mayor o menor medida, están sujetas a riesgos de TI.

El desafío es que, en lugar de intentar evitar los riesgos relativos a la tecnología, las empresas más aventajadas están aprendiendo a manejarlos para que el negocio avance, apoyándose en innovaciones estratégicas en materia de seguridad. Esto no implica solamente hardware y software sino también planes de concientización en materia de seguridad.

Ahora bien, para las amenazas que son detectadas en los análisis de riesgos que se realizan, se diseñan planes de acción para su mitigación parcial o completa.

Una amenaza que se materializa constituye, en la mayoría de los casos, un riesgo operacional, dado que dicha materialización supone una pérdida económica para la organización.

.

Definiendo el riesgo de TI

La siguiente fórmula es la que usualmente se toma en cuenta para analizar el nivel de blindaje que posee una compañía frente al riesgo de TI:

Riesgo residual = riesgo inherente – mitigantes

El riesgo inherente es el riesgo latente que toda empresa tiene: es la amenaza en su estado más puro y potenciado.

Los mitigantes son las acciones que la organización decide encarar para atacar ese riesgo inherente, ya sea tomando acciones orientadas a reducirlo (el riesgo no desaparece se atenúa), de transferencia (las acciones para atacar las amenazas son transferidas a otra empresa), asumir el riesgo aceptando la amenaza (riesgo asumido, que es muy diferente al riesgo no identificado) o bien la máxima, que es la remediación total.

El board de toda organización es el responsable de fijar el “apetito de riesgo” que la compañía va a poseer, lo cual es una declaración implícita del nivel de riesgo que está dispuesta a asumir ¿Por qué el board es el responsable?, porque las acciones que se proponen tomar desde las gerencias tecnológicas suponen en la mayoría de los casos acciones/inversiones/servicios que deben ser aprobados por las máximas autoridades de la compañía.

Esta situación es aún más crítica cuando la empresa está sujeta a inspecciones de entes reguladores, como es el caso de las entidades financieras.

.

Definiendo el riesgo operacional

El Comité de Basilea define al riesgo operacional como al riesgo de pérdidas resultantes de la falta de adecuación o fallas en los procesos internos, de la actuación del personal o de los sistemas, o bien de aquellas que sean producto de eventos externos.

En pocas palabras, es el riesgo en el que incurre una empresa por su operación, que no está ya clasificado como riesgo de crédito o de mercado, o los otros ya tradicionales, y que ha cobrado gran notoriedad dada la mayor participación de operaciones tercerizadas, sistemas tecnológicos complejos, productos derivados y estructurados, y una mayor diversidad de negocios financieros.

Cuando hablamos de un adecuado proceso de gestión del riesgo operacional, se entiende por “gestión” al proceso de “identificación, evaluación, seguimiento, control y mitigación” del riesgo operacional. Estos cuatro elementos reflejan el enfoque principal de la gestión de riesgos presente en todos los documentos y mejores prácticas del Comité de Basilea y, por ende, en las normativas sobre riesgo operacional de todos los países avanzados del mundo.

.

Integrando riesgo de TI con riesgo operacional

Por definición, el riesgo operacional recoge la perdida potencial derivada de deficiencias significativas en la integridad o confianza del sistema, pudiendo surgir de un mal uso del cliente, un diseño inadecuado de un sistema o bien un sistema mal implantado.

Por lo expuesto, el riesgo operacional se encuentra en estrecha relación con los riesgos de TI.

Cuando se realiza un análisis de riesgo de TI se detectan distintos tipos de amenazas que están relacionadas usualmente a:

  • Instalaciones
  • Proveedores
  • Recursos humanos clave
  • Telecomunicaciones
  • Hardware
  • Sistemas operativos
  • Aplicaciones

Toda vez que son detectadas, es importante tomar acciones a fin de eliminarlas o bien minimizar el impacto si estas se produjeran.

.

Utilizando CobiT

La elaboración de un marco de trabajo para efectuar el análisis de riesgos de los activos informáticos, requiere la consideración de las siguientes entradas, según los procesos basados en el estándar internacional CobiT 4.1:

PO01 – Definición de planes estratégicos y tácticos de TI.

PO10 –  Plan de administración de proyectos.

DS02 – Administración de servicios de terceros.

DS04 – Continuidad de servicio (BIA).

DS05 – Seguridad de los sistemas.

ME01 – Monitoreo y evaluación del desempeño de TI.

ME04 – Gobierno de TI.

A su vez CobiT 4.1 se podría combinar con MAGERIT (Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información) – Ministerio de Administraciones Públicas de España – ya que este es un estándar internacionalmente reconocido para la estimación del grado de exposición a que una amenaza se materialice sobre uno o más activos, causando daños o perjuicios a la organización.

.

Conclusión

Es importante llevar a cabo revisiones periódicas de los riesgos de TI y de los controles implementados a fin de:

  • reflejar los cambios en los requerimientos y prioridades;
  • considerar nuevas amenazas y vulnerabilidades;
  • corroborar que los controles siguen siendo eficaces y apropiados.
  • analizar si alguna amenaza de TI se materializó en el área operacional, dado que de suceder esto significaría que hay que evaluar nuevamente los mitigantes que se aplicaron ya que al materializarse significa que los controles implementados no funcionaron en forma adecuada.

.

[email protected]