| |
Es posible mejorar la calidad de los controles, en cuanto a ejecución como a contenidos.
El entorno financiero y operacional consiste en personas, procesos
y tecnología que trabajan conjuntamente para soportar las operaciones
del negocio. El uso de controles sirve para hacerse cargo de los riesgos
de esos componentes.
En nuestra labor diaria es común encontrarnos con clientes que
cuentan con un nivel importante y desarrollado de controles. Por cuestiones
históricas, regulatorias y de tendencias internacionales
esto es marcadamente notorio en las entidades financieras.
En paralelo podemos observar que también es común ver
bajos niveles de automatización de estos controles, ya sea por
complejidad de la infraestructura o por que los controles no están
diseñados para que sean fácilmente adaptables. Es decir,
que muchos de los controles se realizan manualmente o de forma semi-automática
(con fuerte intervención humana). Este tipo de controles genera
tareas repetitivas, susceptibles a errores y donde muchas veces la intervención
manual aporta poco o ningún valor.
En otros casos hemos observado que se cuenta con herramientas automáticas
sub-utilizadas, con las configuraciones básicas entregadas por
el fabricante. Un ejemplo clásico es el de enviar por correo
electrónico alertas con niveles de sensibilidad o definición
inadecuada. Esto deriva en que casi todo evento se convierte en una
alerta, que dispara el envío de un correo, que termina en la
casilla de un analista que no puede llegar a procesar todos los correos
que recibe por día. En este “mar” de correos podría
haber un verdadero incidente grave, que se ve “ahogado”,
y se pierde por el exceso de información de menor relevancia.
Otra práctica habitual es contar con indicadores que se creen
métricas, pero que en realidad solo son un dato sin demasiada
utilidad práctica (aunque dejaremos este tema para otra nota).
Automatizando controles
Hemos hablado de los controles manuales o semi-automáticos.
Muchas veces parece la única forma de realizarlos. La realidad
demuestra que casi siempre es posible automatizarlos o al menos
llevarlos a niveles de automatización donde solo se requiere
de intervención humana en los momentos donde la persona aporta
valor (por ejemplo cuando se debe disparar acciones o tomar una decisión).
Un claro ejemplo de este tipo de casos es el control de configuraciones
basadas en un estándar o en valores del sistema esperados.
La realización de estos controles consta en general de los siguientes
pasos:
- Recolección de información de configuración
- Comparación de los valores reales de configuración contra el patrón estándar definido
- Reporte de resultado de la comparación
- Acciones de corrección de desvíos
Los tres primeros pasos suelen ser excelentes candidatos para la automatización.
Como efecto colateral, en general al automatizar el control el mismo
se estandariza, lo que permite crecer rápidamente en cantidad
de dispositivos del mismo tipo que pueden ser monitoreados. Es decir,
una vez resuelto el problema para el primer dispositivo/plataforma de
un tipo, replicar el control es relativamente simple.
Veamos un ejemplo que puede clarificar lo expuesto. Supongamos que se
quiere controlar que se cumplan ciertos parámetros de configuración
en un servidor. La forma manual de hacerlo es ingresar interactivamente
y verificar estos parámetros sobre el servidor. Si quisiéramos
repetir el mismo control para 200 servidores, el tiempo necesario se
multiplicaría por 200. Esto termina generando que por lo general,
se analice una muestra de los servidores y no la totalidad, y que la
ventana de tiempo entre ejecuciones sea amplia.
Ahora suponiendo que seguimos el esquema propuesto de automatización,
se podría contar con una herramienta que recolecte y centralice
las configuraciones. Posteriormente en forma automática verifique
las configuraciones extraídas contra los parámetros configurados
que se consideran correctos. En caso de encontrar divergencias, se notifica
inmediatamente. Una vez diseñada la automatización, podría
implementarse para todos los servidores y la realización del
control no representaría esfuerzos adicionales incluso si se
agregaran nuevos servidores.
Por otra parte si uno quisiera, podría minimizarse la ventana
entre verificaciones, llegando a tener visibilidad cercana al tiempo
real.
Categorizando la información de monitoreo
Abordemos ahora la situación de exceso de información.
Como mencionamos precedentemente, la información de utilidad
debe poder destilarse de información poco útil.
Por otro lado puede decirse que dentro de la información útil,
la misma no tiene el mismo nivel de criticidad o urgencia. Por ejemplo:
el abuso de privilegios administrativos por parte de un DBA que realiza
una modificación de un saldo puede considerarse un incidente,
mientras que la misma modificación realizada por el software
que administra las cuentas puede no serlo. Es por eso que parece
importante clasificar los tipos de eventos que pueden surgir.
Priorizando la atención mas urgente de aquellos eventos más
críticos y viendo con mayor tranquilidad aquellos eventos que
se consideren normales. Una primera aproximación o clasificación
podría ser:
Tipo de evento |
Descripción |
Periodicidad de revisión |
Requiere notificación automática (Si/No) |
Alarma |
Una alarma es una secuencia de eventos que por sus características conforma un incidente de seguridad. |
Instantánea |
Si |
Advertencia |
Un conjunto de eventos son una advertencia cuando se agrupan comportamientos anormales, que requieren de un análisis posterior, para identificar si representan o no un incidente de seguridad. |
Semanal |
No |
Normal |
Un evento o conjunto de eventos es normal cuando se reporta la actividad considerada de rutina, pero que debe ser monitoreada y revisada periódicamente. |
Mensual |
No |
El mismo tipo de eventos o mismo tipo secuencia de eventos puede encontrarse
en mas de una categoría dependiendo del contexto, aunque no puede
encontrarse en 2 categorías en simultaneo. Recordar el
ejemplo del DBA, la actividad de update realizada por éste debería
ser una alarma, mientras que los updates de la propia aplicación,
pueden considerarse de nivel normal.
Es esperable que las alarmas tengan como contrapartida una acción
inmediata por parte del analista de controles, mientras que los niveles
de eventos inferiores puedan ser revisados por ejemplo semanalmente
para eventos anormales (no asociables en forma directa a un incidente)
y mensualmente para los que son claramente actividad normal.
La mayoría de las herramientas de administración de eventos
pueden configurarse para conseguir este objetivo. Para lograrlo
es conveniente:
- Realizar una definición de requerimientos adecuada
- Identificar y clasificar correctamente cada tipo de evento o secuencia de eventos
- Validar la correcta implementación de los requerimientos
- Verificar que la información entregada por la herramienta es suficiente para dar seguimiento al evento o secuencia
- Realizar ajustes post-validación (de ser necesarios) a las configuraciones para que se adapten lo mejor posible a la especificación de requerimientos
Como hemos visto, es posible mejorar la calidad de los controles, en
cuanto a ejecución como a contenido. Es solo cuestión
de poder detenerse y pensar si existe una mejor manera de hacer lo que
estamos haciendo o de comenzar a hacer algo que no hacemos sin comprarnos
un nuevo problema (o un gran volumen de nueva actividad operativa).
La automatización y correcta categorización de la información
manejada, son dos enfoques posibles de mejora que permiten facilitar
la labor de mantener y generar nuevos controles.
*Socio de Porto, Trentalance, Antúnez & Asoc.
|
