viernes, 18 de abril de 2008

Gestión de Riesgo en Procesos de Negocios

La presencia de amenazas que comprometen el sistema deben ser analizadas y a su vez evaluadas las probabilidades de que una amenaza aproveche esas vulnerabilidades.
Como supo definir Gene Spafford, el único sistema que está seguro es el que se encuentra debidamente apagado y dentro de una caja ignifuga.
Seguramente al leer esta introducción surgen algunas dudas que aclaramos a continuación:
Activo: Como en los aspectos contables existe el activo y el pasivo, la información ahora posee un valor importante y por eso se lo considera un activo. Si un alumno posee el trabajo fi nal de grado y no posee un backup o resguardo en otro dispositivo, ese activo corre un serio riesgo de sufrir algún daño irrecuperable.
Amenaza: todo aquello que pueda provocar un daño a nuestro activo. Por ejemplo, si un virus corrompe el ordenador en donde el alumno tiene su trabajo final, no podrá acceder al momento de presentarlo y tal vez lo pierda.
Vulnerabilidad: Son las inseguridades que posee el activo tanto por problemas tecnológicos, como problemas de procedimientos. Está demostrado que la gran mayoría de pérdidas de activos son por falta de procedimientos o desconocimiento. El alumno no ha realizado copias de su trabajo en otros medios.
• Riesgo: es la probabilidad que una amenaza aproveche una vulnerabilidad. Siguiendo el caso del ejemplo, supongamos que el equipo no posee una descarga a tierra y en una noche tormentosa el equipo sufra una descarga y se queme el disco.

La problemática actual
Los análisis de riesgo, test de vulnerabilidad o test de penetración son prácticas muy frecuentes como herramientas de evaluación para analizar el estado de seguridad de una infraestructura. Los consultores que utilizan COBIT evalúan las redes con un listado conteniendo ítems que deben ser verificados entendiendo que un escenario tiene o no tiene políticas, normas, procedimientos e implementaciones de seguridad, cumplen o no cumplen y de esa manera surge el informe final. En la NORMA ISO/IEC 27001:2005 los especialistas que encaran el proceso de análisis, revelan todos los recursos y servicios de la compañía haciendo un análisis de las vulnerabilidades de seguridad de la compañía y en base a esto verifican cual es la brecha para lograr la normalización.
Debido a esto, podemos observar dos tipos de sondeos:
Técnica pura: instalar herramientas de intrusión en la red y atacar cuanto dispositivo se encuentra conectado a la misma. No hay una metodología clara, no se analiza el riesgo que puede llevar un ataque desmedido y por último se obtiene un informe con gran cantidad de información que no se sabe como ordenar y por dónde empezar.
Política pura: se analiza si la compañía posee implementada políticas, normas, procedimientos y a que estándar se alinea (ISO, BS, ITIL, COBIT, etc). Si cumple o no con las leyes locales y en base a eso, se genera un informe cuyo resultado final es la implementación de una cantidad de políticas y normas sin los pasos adecuados en donde se termina acosando al usuario de la red para que las cumpla.

Análisis versus gestión

La seguridad aun no ha sido un factor de maduración en muchas compañías y menos aún en los usuarios hogareños. Para evaluar que tan seguro es un escenario, se llevan a la práctica pruebas similares a las que realiza un intruso (más conocidos como hackers, pero recuerde que debe denominárselos según el tipo de intrusión o ataque que realiza). En muchas compañías cuando sufren un problema de seguridad o ante una auditoría externa, la misma encara el análisis de seguridad de la infraestructura. Luego de este análisis se genera el informe correspondiente y un plan de implementación de medidas para subsanar las vulnerabilidades encontradas. ¿Cómo sabrá el gerente de sistemas si las implementaciones fueron acordes a lo estipulado?Cómo sabrá el jefe de tecnología si fueron adecuadas las medidas para mitigar los riesgos? Es allí en donde surgen una gran cantidad de dudas.
La NORMA ISO/IEC 27001:2005 y ciertos niveles de maduración como ITIL, PMI, CMMI, hacen referencia a la gestión de un proceso de madurez.¿Por qué no se implementan estos niveles de gestión en las compañías? Muchas veces por una cuestión de que la seguridad no es un asunto importante en la compañía y por ello,no se desea perder el tiempo en la burocratización de los procesos de negocios.
La gestión permite en todos los procesos, evaluar si las decisiones fueron las acertadas y a su vez indica donde hay que realizar ajustes para lograr los objetivos deseados.

Un proceso de Gestión de Riesgo va a permitir a la compañía entender cuál es su situación a nivel de seguridad actual, le va a permitir una toma de decisiones adecuada para mitigar los riesgos, podrá evaluar qué medidas se implementan a largo y corto plazo y luego podrá evaluar si las decisiones fueron las correctas.

En base a este último punto, se vuelve a empezar con el análisis y pasar por las etapas nuevamente permitiendo a la compañía madurar en cuanto a seguridad de la información se refiere.

Proceso de Gestión de Riesgo clásico
Podemos definir entonces, que Gestión de Riesgo es un proceso que involucra 4 estadios:

Situación actual: Un análisis de la situación de seguridad de la compañía para entender cómo se están tratando los activos,que niveles de seguridad existen, que leyes se están cumpliendo y cuáles no. Es lo que denominamos La FOTO.
En esta etapa, suele llevarse a la práctica los clásicos test de vulnerabilidad o test de penetración. Los mismos deben ser rigurosos y muy bien planificados, ya que muchas veces, hay profesionales con el afán de demostrar todos sus conocimientos de intrusión provocan caídas de servicios que ponen en riesgo a la compañía a nivel funcional.
Definir pasos a seguir: En base a un informe detallado de la situación actual, un comité formado por los responsables de sistemas,RRHH, legales y la gerencia, deberán definir cuáles son los pasos a seguir para atacar el riesgo.
Implementación: en base a las decisiones tomadas, se implementan las normas, procedimientos,actualizaciones y ajustes que sean requeridos y que fueron aprobados por el comité. La misma debe ser rigurosamente planificada, ya que hay puntos que deben ser tenidos en cuenta para no impactar en los procesos de negocios.
Monitorear: Analizar el éxito de la implementaciones llevadas a cabo, verificar qué desvíos surgieron y planificar un nuevo análisis en un periodo acorde en la compañía.

Este proceso puede alinearse al año calendario o fiscal y realizarse una vez al año. Obviamente que los responsables de seguridad de la compañía deberán recomendar qué implementaciones deben llevarse a cabo de manera urgente, ya que no pueden esperar un año fiscal para implementarlos. Esto dependerá del negocio y del nivel de madurez alcanzado por el mismo.

Defensa en profundidad
El concepto de Defensa en profundidad permite un diseño, análisis e implementación de la seguridad atacando diferentes capas de la infraestructura. Así como tenemos las 7 capas del modelo OSI (Open System Interconnection – Sistema de interconexión abierto) sugerido por ISO en el año 1977 y que hoy es el estándar de comunicación, el modelo de Defensa en Profundidad provee capas para enfocar el análisis y la prevención. Este modelo fue pensado originalmente por National Security Agency cerca de 1977.

Podemos organizar la Infraestructura de la compañía en las siguientes capas:
• CAPA FISICA
• CAPA DE RED
• CAPA DE EQUIPOS
• CAPA DE PLICACIÓN
• CAPA DE DATOS
En base a la distribución de las capas, se organizan los activos de las compañías en cada una de las capas y se analizan los problemas de seguridad.

Proceso de Gestión de Riesgo en Procesos de Negocio
Basados en el clásico Proceso de Gestión de Riesgo y en el modelo de DoD (Defense of Depth - Defensa en Profundidad), tomamos lo mejor de ambos y armamos un nuevo modelo, denominado Proceso de Gestión de Riesgo en Procesos de Negocio.

Este proceso consta de un análisis pormenorizado de los procesos críticos de negocio de la compañía. Para ello se recomienda realizar las siguientes tareas:
• Reunirse con la gerencia de la compañía o un referente con el fin de obtener cuales son los procesos críticos de negocio. Se recuerda que son aquellos procesos que si son interrumpidos,pueden provocar pérdidas en todos los aspectos (confianza
ante terceros, productividad, negocios, dinero, etc.).
• Reunirse con personas responsables de los procesos críticos de negocio y obtener toda la mayor información posible del proceso. Algunos de los datos relevantes son: hora reloj en el que el proceso puede estar fuera de línea, cantidad de minutos u horas de interrupción permitidas por el negocio, responsables del monitoreo del proceso, relación del proceso con otros dentro de la misma compañía y externos, recursos tecnológicos que participan en el proceso, como para mencionar los más relevantes.
• Armar un esquema de análisis de riesgo para los procesos, ordenando los recursos tecnológicos según el modelo de DoD.
• Confeccionar las planillas de análisis de riesgo, ordenándolas por proceso.
• Encarar la Gestión de Riesgo como se refi ere en el punto 4, pero sólo haciendo foco en los activosque participan en el proceso de negocio de la compañía.
• Ordenar los resultados según las capas del DoD.
• Realizar un tablero de control,ordenado por proceso y por capa del modelo de DoD.

En cada conexión del tablero pondremos el nivel de riesgo observado en cada proceso de negocio. Se puede identificar los riesgos, como lo hace el semáforo: ROJO(riesgo alto), AMARILLO (riesgo medio) y VERDE (riesgo bajo).

En base a estos resultados, tendremos los estados de riesgo de los procesos críticos de negocio y en qué capa del modelo de DoD se encuentra el riesgo. Es más simple para corregir, prever o asumir los riesgos, a diferencia del modelo de gestión de riesgo convencional.
A su vez, la gestión le permitirá observar en las diferentes etapas, cómo fueron cambiando los estados de riesgo en cada una de ellas y de esa manera se tiene el estado real de riesgo y no una percepción.

A diferencia del modelo clásico de gestión de riesgo, este enfoque permite obtener un estado real de los activos que forman parte de los procesos de negocio, llevar a cabo tareas correctivas y planificar a futuro las mejoras. Si se tienen en cuenta estándares como ITIL, estos resultados permiten mejorar la entrega de soporte (Service Support)y la entrega de servicios (Service Delivery).

Factores críticos de éxito
El modelo es simple, pero para lograr el éxito en su implementación, requiere:
• Apoyo explicito de la gerencia.
• Conocer los procesos críticos de negocio de la compañía y qué activos intervienen en los mismos.
• Conocer el modelo de Gestión de Riesgo.
• Entender el modelo de DoD, para colocar adecuadamente los activos en cada capa.
• Realizar el proceso completo de gestión y no la iniciativa de la Foto.
• Implementar los cambios sugeridos que permitan mitigar los riesgos.

Conclusiones
Este modelo que hemos llevado a la práctica hace más de 4 años, ha permitido reducir los tiempos de mitigación de riesgo, enfocando las actividades en los procesos críticos de los negocios. No quiere decir que el resto de los activos deban ser ignorados, simplemente permite definir prioridades y atacarlas con el fin de mitigar los riesgos de la compañía.
Como las buenas prácticas en su mayoría sugieren, los resultados de este modelo serán entornos más seguros,disponibilidad de los activos, y reducción de costos.

Enrique Dutra - MVP Windows Security
Este artículo ha sido publicado en el nro 33 de la revista Hakin9.

jueves, 10 de abril de 2008

LIGA DE HEROES DE IT











Una mirada divertida para todos los profesionales de IT, que finalmente fuimos ascendidos a la categoría de HEROES IT, en nuestra lucha por salvar al mundo cada dia. Hasta contamos con una Liga de Heroes IT y todo!!
No dejes de visitar el sitio www.heroesit.com

Saludos!!

Quique