domingo, mayo 30, 2010

Análisis de Impacto de Negocios / Business Impact Analysis (BIA)



Una vez se tiene el análisis de riesgos, este se convierte en el punto de partida del Análisis de Impacto de Negocios y/o Business Impact Analysis (BIA). Este BIA se constituye asi en el pilar sobre el que se va construir el Plan de Recuperación de Negocios. El BIA será la guía que determine que necesita ser recuperado y el tiempo que tarde dicha recuperación, actividades que en el Plan de Continuidad de Negocios se convierten quizás en las más difíciles y criticas por realizar adecuadamente. El apoyo del BIA es invaluable para identificar que esta en riesgo una vez se presente un riesgo permitiendo así justificar los gastos que se requieran en protección y capacidad de recuperación. Usualmente se habla de "critico" o "esencial" cuando se listan las actividades desarrolladas en una Organización.

Al hacer un BIA quizás resulte mas útil hablar de "tiempos inactivos", puesto que ninguna organización contrata un empleado para que realice labores "no esenciales", cada labor tiene un propósito, pero hay unas labores que son mas exigentes en su tiempo de ejecución que otras cuando hay limites de recursos o tiempos apretados de entrega para su realización. Veámoslo de este modo: Un banco que haya sufrido un percance por un pequeño incendio en la bodega puede detener su campaña publicitaria pero no podrá detener los procesos de retiros y depósitos de sus clientes. La campaña publicitaria del banco es esencial para su crecimiento a largo plazo, pero cuando se presenta una emergencia o desastre puede ser aplazada no por su criticidad sino por que su "tiempo de inactividad" puede ser mucho mayor y no afectar la operación del banco.
La organización debe revisar cada una de las tareas que se realizan con el mismo patrón de referencia. Por cuanto tiempo puede dejar de realizarse esta actividad sin que ello cause perdidas financieras, quejas de los clientes, y/o penalizaciones legales o contractuales? Cuando se trata el tema de continuidad, todo gira alrededor del impacto. Es acerca de sostener la operación básica de la Organización mientras que lo demás se puede dejar en espera. Es centrarse en las operaciones que le permiten sobrevivir a la Organización. Todos los procesos de la Organización, así como los recursos tecnológicos en los que se soportan tales procesos deben ser clasificados de acuerdo a su prioridad de recuperación. Los tiempos de recuperación de los procesos para una organización están medidos por las consecuencias de no poder ejecutarlos.

De que consecuencias estamos hablando? Demandas en contra de la Organización por el incumplimiento de una entrega en una fecha determinada, perdida de reputación, etc. Generalizando, los impactos de un desastre pueden ser financieros, legales, o de retención/perdida de clientes.


Ahora, como realizar el análisis de impacto de negocios (BIA)? Se inicia identificando los procesos que se realizan en la organización, y asignándoles un líder; siendo ideal que ya exista un Sistema de Gestión en el que ya se haya hecho esta actividad. Con los lideres de proceso se puede conformar un "equipo de planeación" que hará la evaluación del proceso que tengan asignado. Una vez identificados procesos y sus lideres, se debe listar cada una de las actividades que se realiza para cada uno de los procesos para entender cual es el propósito de los mismos, y aquí se debe analizar cada actividad que se ejecute en tres aspectos: riesgo financiero de no ejecutar tal actividad, riesgo regulatorio o legal de no ejecutar tal actividad, y el riesgo reputacional o con el cliente de no ejecutar tal actividad.
Aclaremos cada uno de los riesgos:
  • Financiero: incluye perdida de ingresos, pérdida de intereses con entidades bancarias, costos de pedir dinero prestado para hacer caja, perdida de ingresos por ventas no realizadas, penalizaciones por no cumplir compromisos contractuales o niveles de servicio, y oportunidades perdidas durante el tiempo inoperante.
  • Regulatorio: incluye perdidas por no presentar reportes financieros o de impuestos en las fechas indicadas, demandas o penalizaciones por incumplir requerimientos obligatorios en las actividades de la Organización (por ejemplo ambientales), o la obligación de tener que retirar productos en venta por falta o in suficiencia en la realización de pruebas del producto antes de ponerlo a disposición del consumidor final.
  • Reputacional o con el cliente: incluye la perdida de confianza por parte de los clientes y del mercado, reclamaciones de responsabilidad, clientes insatisfechos por el servicio, apariciones en las noticias por quejas de los clientes, perdida de reputación, y perdidas de ventajas competitivas.
Una vez que el Equipo de Planeación tienen una lista de todas las actividades y sabe que pasa si no se realizan, la siguiente respuesta a obtener es que tan pronto veremos el impacto? Será tan pronto se deje de hacer una actividad? Un callcenter que sea evacuado por un posible incendio deja de funcionar inmediatamente. A menos que haya un callcenter alterno donde se pueda operar para seguir recibiendo llamadas, el impacto a los clientes es inmediato. Que tan significativo sea dicho impacto depende enteramente del negocio o actividades que maneje una Organización: cuantas llamadas se reciben y que servicio busca cada una de ellas.

A manera de ejemplo, un callcenter en promedio puede recibir 1.200 llamadas en promedio por hora, 72% de ellas finalizan con una venta de U$57 dólares, asi que haciendo cuentas 1200 x 0.72 x $57 = $49,248 cuesta cada hora de servicio que el callcenter este fuera de operación. Si los clientes o potenciales consumidores encuentran lo que desean comprar en una pagina de internet, realizan la orden y el sitio deja de funcionar, hay un impacto inmediato. El impacto depende estrictamente de la actividad que realice una Organización, de cuantas ordenes de trabajo se reciben, que cuesta cada orden, y saber si el cliente esta dispuesto a esperar a realizar su pedido hasta que se restablezca el servicio o ira a solicitarlo a otro proveedor (siempre pueden ir con la competencia!!!).


Cuando el equipo de planeación tiene la lista de actividades, una idea de que ocurre cuando dejan de ejecutarse, y en que tiempo empezaran a ver el impacto, es hora de cuantificar el impacto. Se pueden utilizar medidas cuantitativas como dólares por minuto, hora o día de inactividad, o medidas cualitativas que permitan predecir resultados basados en el conocimiento o experiencia de los miembros del equipo de planeación o compañeros de trabajo. Una vez se completa esta actividad ya tenemos una vista general de todo lo que realiza la compañía, que impacto tiene para la organización que no se ejecute un proceso o una actividad, que tan rápido se sentirá ese impacto y que tan fuerte impactara a la organización. Esta información será el punto de partida para desarrollar estrategias de recuperación para cualquier organización.


Ya con esta información recopilada, se hace necesario determinar en una escala los tiempos de recuperación óptimos. A manera de ejemplo, se puede determinar que estas son las categorías a emplear:


Categoría 1: Procesos Misionales y/o Críticos (0 a 12 horas)


  • Funciones que pueden realizarse sólo si las capacidades se reemplazan por otras idénticas.
  • No pueden reemplazarse por métodos manuales.
  • Muy baja tolerancia a interrupciones.
Categoría 2: Vitales (13 a 24 horas)
  • Pueden realizarse manualmente por un periodo breve.
  • Costo de interrupción un poco más bajos, sólo si son restaurados dentro de un tiempo determinado (5 ó menos días, por ejemplo).
Categoría 3: Importantes (1 a 3 días)

  • Funciones que pueden realizarse manualmente por un periodo prolongado a un costo tolerable.
  • El proceso manual puede ser complicado y requeriría de personal adicional.
Categoría 4: Menores (Mas de 3 días)
Funciones que pueden interrumpirse por tiempos prolongados a un costo pequeño o nulo.


En este momento es que empezamos a hablar de los tiempos de recuperación, y entran en escena varios de ellos: RTO, RPO, MTD y WRT. Vamos con cada uno de ellos:


Los RTO y RPO, son parámetros específicos que están íntimamente relacionados con la Recuperación de Desastres y tienen que ser tomados en consideración para que un plan de este tipo pueda ser implementado. El RTO (Recovery Time Objective) es el Tiempo objetivo de recuperación, en otras palabras cuanto puede permanecer la Organización sin ejecutar una actividad, el uso de una aplicación (hardware y/o software) o información relevante. Frecuentemente es asociado con el tiempo máximo de inactividad. El RTO se utiliza para decidir cada cuanto se deben realizar respaldos de información o backups; también es útil para decidir que infraestructura es requerida para reiniciar operaciones, por ejemplo un centro de cómputo alterno de similares especificaciones al existente en la Organización, o un callcenter paralelo en una ubicación diferente a la que se utiliza de manera permanente. Si en su organización hay un RTO con valor CERO (no puede ser inferior a esta cifra), inevitablemente su Organización tendrá que contar con una infraestructura redundante con respaldos de información en sitios alternos y así sucesivamente. Ahora, si se tiene un RTO de 48 o 72 horas entonces un respaldo de información en cinta será suficiente para esa aplicación en particular.

El RPO es ligeramente diferente. Este parámetro nos dice que cantidad de información puede la Organización perder. En otras palabras, si su organización realiza respaldos nocturnos de información todos los días a las 7:00 PM y el sistema colapsa al día siguiente a las 4:00 PM, toda actualización que se realice desde su último respaldo se perderá. El RPO para este contexto será el respaldo de información que haya realizado en el día anterior. Ahora, si estamos hablando de un banco que hace transacciones en Internet, el RPO debe ser prácticamente igual a cero, incluyendo la última transacción y el último bit de información que se haya manejado. Así las cosas, el RPO nos dice que clase de protección se requiere para la información que se maneja en su Organización.

Así las cosas, el RTO y el RPO influyen por completo en la infraestructura de soporte y respaldo que vaya a utilizar en su organización. Entre mas se reduzca e RTO y el RPO, mas dinero debe invertirse en seguridad.


Maximum Tolerable Downtime (MTD) o Maximum Tolerable Outage (MTO) Tal como suena, es el tiempo máximo de inactividad que la organización puede tolerar la ausencia o no disponibilidad de una función o proceso. Diferentes procesos o tareas dentro de la organización pueden tener diferentes MTD. Si una función de la Organización esta categorizada dentro de la Categoría 1, obviamente tiene el MTD mas corto. Hay una correlación entre la criticidad de las funciones o procesos de la organización y su tiempo máximo de inactividad. A mayor criticidad, menor tiempo de espera a que se reinicie la operación en ese proceso o función. El tiempo de caída o de inoperancia se constituye por dos elementos: el tiempo de recuperación del sistema y el tiempo de trabajo en recuperación o WRT. Así las cosas, MTD = RTO + WRT.

Work Recovery Time (WRT) Tiempo de trabajo en Recuperación. Este segmento comprende el máximo tiempo de inactividad posible o MTD. Si su MTD es de 3 días, probablemente el día 1 sea el RTO y los dias 2 y 3 pueden ser los WRT. Como es de esperar, toma tiempo hacer que las funciones criticas de la Organización estén nuevamente operando (hardware, software, configuraciones necesarias, etc), y este es un tema que usualmente se ignora en las etapas de planeación, especialmente por Sistemas o IT. Si los sistemas están nuevamente funcionando, eso es todo desde la perspectiva de sistemas o IT. Pero que ocurre desde una perspectiva de negocios? Hay pasos adicionales a tenerse en cuenta antes de que los sistemas estén operando como conseguir una ubicación alterna, conseguir los equipos, conexión a banda ancha, etc, etc y que tienen que ser obligatoriamente contemplados en la definición del MTD; y si no se tiene en cuenta se esta poniendo en riesgo a la organización al no haber tomado tales tiempos en consideración.

Veamos como interactúan estos tiempos:




Punto 1: RPO La máxima cantidad de información que se puede perder de acuerdo al cronograma de realización de copias de respaldo y/o necesidades de información que se presenten.
Punto 2: RTO Tiempo requerido para que los sistemas críticos de la Organización estén nuevamente operando

Punto 3: WRT Tiempo requerido para recuperar la información perdida (Basado en el RPO), así como de ingresar al sistema todos los datos que se generaron durante la caída del sistema.

Punto 2 y 3: MTD La duración del RTO mas el WRT
Punto 4: Pruebas, verificación e inicio normal de operaciones


Durante la ejecución normal de operaciones, usualmente hay una diferencia entre el último respaldo de información realizado y el estado actual de la información. En algunos casos, este lapso puede ser de minutos u horas, pero en la mayoría de casos siempre será de horas o días. Este marco de tiempo es el punto objetivo de recuperación. En muchas organizaciones este es precisamente el lapso de tiempo que existe entre cada una de las copias de respaldo que realizan. Observando el circulo con el numero 1 se aprecia la diferencia existente entre la realización de la ultima copia de respaldo y el estado actual de la información, justo antes de la caída del sistema. Ese es el momento en el cual uno o más de los sistemas críticos dejan de estar disponible y se inicia el Plan de Continuidad y/o de Recuperación de Desastres. La primera fase del MTD (tiempo máximo de inactividad que la organización puede tolerar la ausencia o no disponibilidad de una función o proceso) es el objetivo a cumplir. En este marco de tiempo los sistemas se evalúan, reparan, reemplazan y reconfiguran. El RTO finaliza cuando los sistemas nuevamente están en línea y la información es recuperada hasta el último respaldo de información disponible. Justo allí es cuando empieza la segunda fase del MTD.


Es en esta fase cuando la información es recuperada através de procesos automatizados y/o manuales. Hay dos elementos en la recuperación de información, el primero es la restauración de la información perdida, y la segunda es la carga de la información recopilada de manera "artesanal" por que no había manera de ingresarla al sistema. La mayoría de empresas realizan las dos fases mencionadas en ese mismo orden, pero habrá casos en los que el Plan de Recuperación pueda dictar lo contrario. Aquí la clave es entender que hay un retraso entre el momento en que los sistemas vuelven a estar completamente operativos y el momento en el que se pueden reasumir las operaciones normales. Durante los periodos indicados con los círculos con los números 2 y 3, se hará el trabajo con mecanismos alternos y/o manuales. Estos procesos se reactivaran posteriormente de acuerdo a lo que se defina en el Plan de continuidad. Por ejemplo, si una base de datos financiera esta inaccesible, como se podrán registrar los pagos, las ventas, y todas las actividades relacionadas por todo el equipo de trabajo? Es necesario definir eso en el proceso de planeación. El Circulo con el Numero 4 indica la transición entre recuperación de desastre y continuidad del negocio de nuevo hasta la operación normal. Es probable encontrar que sea necesario realizar procesos manuales que deberían ser automatizados, pudiendo planear el regreso a la normalidad por quizás departamentos de la organización o zonas geográficas.

Para finalizar, los dejo con un diagrama que explica las entradas y las salidas de un BIA:

miércoles, mayo 12, 2010

Gestión de Riesgos


Teniendo entendido que para la gran mayoría de Organizaciones actualmente la Gestión u Administración de Riesgos se constituye como parte fundamental de la Gerencia de la Organización que pretende respaldar eficientemente a la identificación, análisis, tratamiento, comunicación y monitoreo de los riesgos del negocio; este análisis se convierte en tema de obligatorio cumplimiento cuando se habla de un Sistema de Gestión de Seguridad de la Información.

Por años este tema estuvo regido por la Norma Australiana AS/NZS 4360, la cual sirvió de guiá a muchísimos profesionales que querían hacer un análisis de riesgos en sus labores cotidianas; y si hablamos específicamente en Colombia dicha norma fue adaptada bajo el nombre de NTC 5254 en el año 2006 la cual se convirtio en texto obligado al momento de hacer evaluaciones de riesgos para las diferentes Organizaciones en Colombia. Que incluye dicha norma? Básicamente orienta al lector en la necesidad de identificar riesgos que impacten su Organización, Como analizarlos midiendo consecuencia y probabilidad, Evaluar el impacto que tiene la materialización de cada uno de los riesgos identificados, Identificar opciones de manejo de los riesgos (Plan de tratamiento de riesgos); y por ultimo la Medición y análisis de los riesgos.
Actualizacion 2013: La norma actual de gestión de riesgos es la ISO 31000, estandar que realiza un manejo identico de la gestion de riesgos al presentado en esta entrada.

Pero que es todo este tema del Análisis de Riesgos, Mapas de Riesgos y demás? Veamos paso a paso como se hace esta evaluación.


IDENTIFICACIÓN DE RIESGOS.

En la identificación de riesgos se debe determinar la posibilidad de ocurrencia de riesgos potenciales, lo cual pueda entorpecer el normal desarrollo de las funciones de la Organización.

Para esto podemos elaborar un listado de los riesgos inherentes a las actividades o procedimientos que se llevan a cabo en cada proceso, priorizándolos según el grado en que estos afecten los objetivos misionales del mismo.


ES MUY IMPORTANTE TENER EN CUENTA QUE PARA REALIZAR LA IDENTIFICACIÓN DEL RIESGO ESTE NO SE HAYA MATERIALIZADO.


ANÁLISIS DE FACTORES DE RIESGO.


En el análisis de factores de riesgo es necesario tener en cuenta aquellos que pueden incrementar la probabilidad de que un riesgo ocurra. Inclusive, es posible generar riesgos nuevos como por ejemplo la integridad, la ética de las personas involucradas, el tamaño y la complejidad de las transacciones involucradas en el proceso, así como, los cambios en los sistemas o en el personal clave; adicionalmente se debe tener en cuenta los factores de carácter externo que pudieran llegar a afectar la Organización como son los económicos, sociales, legales o de cambio tecnológico.


CLASIFICACIÓN DEL RIESGO.

La clasificación del riesgo permite realizar una mejor identificación de los riesgos inherentes a los procesos de la Organización, ya que delimita los parámetros a seguir por el responsable. Esta seria una posible clasificación:

  • Riesgo estratégico
  • Riesgo operativo
  • Riesgo de control
  • Riesgo financiero
  • Riesgo de tecnología
  • Riesgo de incumplimiento
  • Riesgo de fraude
  • Riesgo de ambiente laboral
Que riesgos analizar? Esta imagen es de gran ayuda para visualizar los "anillos del riesgo" a los cuales se expone una Organización:



PONDERACIÓN DEL RIESGO
La ponderación del riesgo consiste en establecer los niveles adecuados de calificación, tanto de la probabilidad como del impacto, para determinar realmente el nivel de vulnerabilidad en la Organización ante situaciones previsibles. También se debe tener en cuenta los factores de riesgo enunciados durante el proceso de identificación.

  • Probabilidad de ocurrencia: para determinar este ítem se debe considerar los controles utilizados hasta el momento y la efectividad de los mismos, así como, la frecuencia en la que ocurren los riesgos y en la que se van a analizar.
  • Impacto: en este ítem se evalúan las consecuencias en caso que el hecho que originó el riesgo se materialice. También analiza el grado en que afecta los objetivos de los procesos involucrados o, inclusive de manera general a la Organización.
MANEJO DEL RIESGO.

Después de realizar la ponderación de los riesgos se debe elaborar un plan de manejo de los mismos. En la elaboración de dicho plan se debe tener en cuenta la relación costo/beneficio del riesgo que se desea tratar, así como, las consecuencias y las posibles acciones que se van a implementar. Se debe tener claro que existen varias posibilidades en cuanto a manejo del riesgo, las cuales se describen a continuación:

  • Evitar el riesgo: es realizar modificaciones a los procesos o a las actividades generadoras del riesgo, para generar los controles pertinentes, adecuados y efectivos para el tipo de riesgo que está revisando.
  • Reducir el riesgo: es aplicar controles directamente para reducir la probabilidad o el impacto del riesgo. Este manejo se da cuando dicho riesgo no puede ser evitado, por lo que se trata de utilizar medidas correctivas en los procesos que ayuden a minimizar el riesgo inherente de las actividades involucradas.
  • Transferir el riesgo: es trasladar el riesgo a otra área de la Entidad o adquiriendo seguros que cubran estos riesgos, de esta manera se logra que el tercero los asuma.
  • Compartir o diversificar el riesgo: es distribuir el riesgo, por ejemplo, guardar varias copias de un documento en lugares diferentes para que de esta manera se evite que la pérdida de un documento origine la nulidad del proceso que respalda.
  • Retener, asumir o aceptar el riesgo: es una decisión que el área de donde proviene el riesgo debe tomar, y para hacerlo debe necesariamente haber llegado a la conclusión que la relación costo/beneficio no es viable, es decir, que el costo de implementar los controles es mayor al costo que puede originar la materialización del riesgo. Esta situación puede ocurrir además cuando el riesgo no es reconocido o cuando al reducir el riesgo queda una parte residual, originando consecuencias que son asumidas por cada área.
Teniendo claro los posibles manejos que se le da a cada riesgo se deben formular acciones para su realización, estableciendo responsables de estas y fijando fechas para su desarrollo. Los responsables también deben velar por el cumplimiento en el desarrollo e implementación de los puntos de control.

DESCRIPCIÓN DE LA MATRIZ DE RIESGOS.

Básicamente una matriz de riesgos puede ser como la siguiente:




Pero la información que se debe manejar al administrar riesgos seria idealmente la siguiente:
  • Riesgo: es la posibilidad de ocurrencia de aquella situación que pueda entorpecer el normal desarrollo de las funciones de la Organización y le impidan el logro de sus objetivos.
  • Impacto: son las consecuencias que puede ocasionar a la Organización la materialización del riesgo.
  • Probabilidad: es la posibilidad de ocurrencia del riesgo.
  • Control existente: en este ítem se debe especificar cual es el control que la Entidad tiene implementado para combatir, minimizar o prevenir el riesgo.
  • Nivel De Riesgo: es el resultado de la aplicación de la escala escogida para determinar el nivel de riesgo de acuerdo a la posibilidad de ocurrencia, teniendo en cuenta los controles existentes.
  • Causas: son los medios, circunstancias y agentes que generan los riesgos.
  • Acciones: es la aplicación concreta de las opciones del manejo del riesgo que entraran a prevenir o a reducir el riesgo y harán parte del plan de manejo del riesgo.
  • Responsables: son las dependencias o áreas encargadas de adelantar las acciones propuestas, también se debe determinar en cabeza de quien va a quedar el compromiso del cumplimiento del cronograma.
  • Cronograma: son las fechas establecidas para implementar las acciones por parte del grupo de trabajo.
  • Indicadores: se deben usar para evaluar el desarrollo de las acciones implementadas y pueden ser de tipo cuantitativo o cualitativo, pero deben permitir emitir un juicio mediante su utilización.
ESCALAS PARA LA DETERMINACIÓN DE PROBABILIDAD E IMPACTO DE CADA RIESGO.

Tomando los criterios establecidos para la evaluación de los riesgos en la Norma NTC 5254: Norma Técnica Colombiana de Gestión de Riesgos, se construye una tabla donde se describen los riesgos; se muestra el resultado del cruce de las variables de impacto o consecuencia versus probabilidad de ocurrencia del riesgo, y mediante colores se representa la severidad del riesgo.

PLAN DE MANEJO DEL RIESGO

Tal como se menciono previamente se encuentran las diferentes alternativas del manejo del riesgo, las cuales seran tenidas en cuenta para el Monitoreo de los Riesgos y son las siguientes:
  • Evitar el riesgo: es realizar modificaciones a los procesos o a las actividades generadoras del riesgo, para generar los controles pertinentes, adecuados y efectivos para el tipo de riesgo que está revisando.
  • Reducir el riesgo: es aplicar controles directamente para reducir la probabilidad o el impacto del riesgo. Este manejo se da cuando dicho riesgo no puede ser evitado, por lo que se trata de utilizar medidas correctivas en los procesos que ayuden a minimizar el riesgo inherente de las actividades involucradas.
  • Transferir el riesgo: es trasladar el riesgo a otra área de la Entidad o adquiriendo seguros que cubran estos riesgos, de esta manera se logra que el tercero los asuma.
  • Compartir o diversificar el riesgo: es distribuir el riesgo, por ejemplo, guardar varias copias de un documento en lugares diferentes para que de esta manera se evite que la pérdida de un documento origine la nulidad del proceso que respalda.
  • Retener, asumir o aceptar el riesgo: es una decisión que el área de donde proviene el riesgo debe tomar, y para hacerlo debe necesariamente haber llegado a la conclusión que la relación costo/beneficio no es viable, es decir, que el costo de implementar los controles es mayor al costo que puede originar la materialización del riesgo. Esta situación puede ocurrir además cuando el riesgo no es reconocido o cuando al reducir el riesgo queda una parte residual, originando consecuencias que son asumidas por cada área.
Teniendo claro los posibles manejos que se le da a cada riesgo se deben formular acciones para su realización, estableciendo responsables de estas y fijando fechas para su desarrollo. Los responsables también deben velar por el cumplimiento en el desarrollo e implementación de los puntos de control.

EJECUCIÓN DEL PLAN DE MANEJO DE RIESGOS

Dentro de esta secuencia de actividades ya se cumplió con la identificación, análisis y evaluación de riesgos, quedando por ejecutarse el Monitoreo de los riesgos identificados inicialmente. Se realizará un monitoreo de las matrices de riesgos de las diferentes áreas en reuniones periódicas; en donde cada uno de los responsables de los procesos de la Organización estará encargado de complementar y actualizar sus matrices a medida que surgen nuevos riesgos o si los controles aplicados logran reducir o incluso eliminar los riesgos existentes.

Las modificaciones a las matrices después de su oficialización deben ser debidamente aprobadas. Pasos a seguir por proceso para realización del monitoreo:
  1. Revisar cuidadosamente la última matiz de riesgos aprobada.
  2. Listar las medidas existentes o planeadas para reducir la ponderación del riesgo. Se listaran medidas para reducir la probabilidad y para reducir el impacto.
  3. Evaluar si los riesgos y las causas que los originaron persisten, de ser así confirme que los controles de estos riesgos no se hayan modificado o tergiversado con el tiempo.
  4. Proponer nuevos controles para los que son obsoletos.
  5. Considerar el (los) riesgo(s) que han desaparecido y con base en esto elaborar un informe explicando su apreciación para que éste sea retirado del mapa oficial del área.

A continuación se enumeran las metodologías más conocidas de análisis y gestión de riesgo. La mayoría de ellas constan de documentos que desarrollan los conceptos necesarios y luego se especifican los pasos a ser llevados a cabo para realizar el relevamiento completo. Algunas de ellas también disponen de planillas, matrices, tableros y reportes de ejemplos que pueden utilizarse como base.

Herramienta OCTAVE
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) se encuentra disponible gratuitamente (en inglés) y es un conjunto de herramientas, técnicas y métodos para desarrollar análisis de riesgos basados en gestión y la planeación estratégica de la organización.
Son todas las acciones que necesitan ser llevadas a cabo dentro de la organización para realizar la gestión de activos, conocer posibles amenazas y evaluar vulnerabilidades.
Herramienta MAGERIT
MAGERIT es una metodología de Análisis de Riesgos de carácter público elaborada por el Ministerio de Administraciones Públicas, siendo probablemente la metodología más utilizada en España.

El nombre de MAGERIT responde a "Metodología de Análisis y Gestión de Riesgos de IT”, y es un método formal orientado a activos, cuya misión es descubrir los riesgos a los que se encuentran expuestos nuestros sistemas de información y recomendar las medidas apropiadas que deberían adoptarse para controlar estos riesgos.

La metodología MAGERIT ha sido elaborada por un equipo interdisciplinario del Comité Técnico de Seguridad de los Sistemas de Información y Tratamiento Automatizado de Datos Personales, SSITAD, del Consejo Superior de Informática.

MAGERIT persigue los siguientes objetivos generales:

  • Concienciar a los responsables de los sistemas de información de la existencia de riesgos y de la necesidad de atajarlos a tiempo.
  • Ofrecer un método sistemático para analizar tales riesgos.
  • Ayudar a descubrir y planificar las salvaguardas oportunas para mantener los riesgos bajo control.
  • Apoyar a la Organización en la preparación de procesos de evaluación, auditoría, certificación o acreditación, según corresponda en cada caso.
MAGERIT está estructurado en tres partes diferenciadas:
  • Libro I: Método.
  • Libro II: Catálogo de Elementos.
  • Libro III: Guía de Técnicas.
Puede descargarse la metodología desde la web del Ministerio de Administraciones Públicas de España.
Herramienta EAR/PILAR
Como herramienta informática para el análisis de riesgos, basado en MAGERIT, disponemos de PILAR. Este software puede descargarse gratuitamente, en su versión de prueba, desde el enlace www.ar-tools.com/pilar.

PILAR dispone de una biblioteca estándar de propósito general, y es capaz de realizar calificaciones de seguridad respecto de normas ampliamente conocidas como son:
  • ISO/IEC 27002:2005 - Código de buenas prácticas para la Gestión de la Seguridad de la Información.
  • SP800-53:2006 - Recommended Security Controls for Federal Information Systems.
  • Criterios de Seguridad, Normalización y Conservación del Consejo Superior de Informática y para el Impulso de la Administración Electrónica.
Herramienta CRAMM
CCTA Risk Analysis and Method Management (CRAMM) es una metodologia creada en 1987 por la Central Agency of Data Processing and Telecommunications del Gobierno del Reino Unido.

Esta metodología comprende tres fases:
  • Fase 1: Establecimiento de objetivos de seguridad
  • Fase 2: Análisis de riesgos
  • Fase 3: Identificación y selección de salvaguardas
CRAMM es actualmente la metodología de Análisis de Riesgos utilizada por la OTAN, el Ejército de Holanda, y numerosas empresas de todo el mundo.

En la dirección www.cramm.com podemos encontrar la más completa información sobre esta prestigiosa metodología.
Otras metodologías conocidas son:
  • Mehari, desarrollada por CLUSIF (Club de la Sécurité de l’Information Français). Es gratuita y se encuentra disponible en varios idiomas
  • METRICA3 específica para desarrollo de software (Software Life Cycle Processes)
  • Desarrollada en español y gratuita
  • The Security Risk Management Guide de Microsoft, en inglés y gratuita
  • COBRA, con costo y en inglés
  • Callio, con costo y en inglés
  • MARION, Méthodologie d'Analyse des Risques Informatiques et d'Optimisation par Niveau, desarrollada en Francia por el Club de la Sécurité Informatique Français (CLUSIF).
  • ISAMM, Information Security Assessment & Monitoring Method, desarrollada en Bélgica por Telindus N.V.
  • IT-Grundschutz, desarrollada por la Bundesamt für Sicherheit in der Informationstechnik (Oficina Federal para la Seguridad de la Información) de Alemania.
Todas estas metodologías pueden ser implementadas en cualquier organización, pero cada una deberá realizar un análisis pormenorizado para adaptar el modelo a la organización que se trate.

A futuro: Tendremos la Norma ISO 31000, la cual ya esta disponible en idioma Ingles, pero que saldra obviamente en nuestro idioma.

Para terminar, los dejo con el ciclo del análisis de riesgo:

lunes, mayo 10, 2010

La familia ISO 27000

Hasta el momento he hablado bastante de las ISO 270001 e ISO 27002 dejando de lado la serie ISO 27000 que es la que realmente cobija todo lo relacionado con la seguridad de la información, asi como ocurre con la ISO 9000 para todo el tema de calidad.

Complementando le norma ISO 27001, existen otros miembros de la familia, los que proporcionan lineamientos y apoyo para el desarrollo, implementación y mejora de los SGSI que cumplen con la ISO 27001. La familia incluye la norma fundadora ISO 27002, publicada en 1995.


Otra norma de lineamientos es la ISO 27005, que proporciona guías sobre la gestión de riesgos. El proceso de gestión de riesgos en la seguridad de la información es un componente clave en el modelo PHVA (Planear-Hacer-Verificar-Actuar) de cualquier Sistema de Gestión relacionado con una Norma ISO..

Nuevas guías

Recientemente se han sumado a la familia las normas ISO 27003 y 27004. La ISO 27004 trata de la medición de la eficacia de los SGSI implementados, lo que permite a la gerencia monitorear el desempeño relacionado con la seguridad de su SGSI. La ISO 27004 trata sobre el “qué”, “cuándo” y “cómo” realizar mediciones en la fase “verificar del ciclo PHVA– o sea durante la fase de monitoreo y análisis del proceso de mejora continua. La ISO 27003 proporciona lineamientos en apoyo de la ISO 27001 respecto al proceso de planificación e implementación de los procesos del SGSI.

Normas de auditoría

La familia también tiene normas que dan lineamientos para la acreditación y para los auditores, en relación con auditorías a SGSI. La norma de acreditación ISO 27006 es una versión de la ISO 17021-1. La norma ISO 27006 proporciona lineamientos sobre cómo los organismos de certificación deben interpretar la ISO 17021-1 en el contexto de auditorías a SGSI, en cumplimiento con la norma ISO 27001
Actualmente están siendo desarrolladas dos normas de lineamientos para auditorías, las ISO 27007 e ISO 27008. El trabajo en estas normas está siendo llevado a cabo en colaboración con miembros de los grupos involucrados en la revisión de las normas ISO 19011 e ISO 17021-2. La norma ISO 27007 trata de las auditorías según la norma ISO 27001, (actualmente las auditorias se hacen de acuerdo a la ISO 19011 que no satisface todos los requisitos de un SGSI) cubriendo temas tales como el alcance y la complejidad, la gestión de riesgos, la selección de controles y la competencia de los auditores de SGSI. La norma ISO 27008, por otro lado, trata de aspectos técnicos de los controles de seguridad definidos en el Anexo A de la ISO 27001. Según lo planeado, estas dos normas serán publicadas en el año 2011.

Normas para sectores específicos

Se está desarrollando un nuevo rango de normas que analizan los requisitos específicos de sectores y distintas aplicaciones que están adoptando la ISO 27001. Estas normas que no tiene como proposito sustituir a la ISO 27001, proporcionarán definiciones de requisitos adicionales específicos para ciertos sectores. El programa, actualmente, incluye:
ISO 27010 – para comunicaciones entre sectores
Esta norma considera varios requisitos de seguridad referidos a aquellos sectores y organizaciones involucrados en la infraestructura a nivel nacional. Incluye la seguridad de temas tales como el control de supervisión y la adquisición de datos.
ISO 27011 – para organizaciones de telecomunicaciones
Basada en la ISO 27002, esta norma fue emitida en el año 2008 y ha sido publicada en forma conjunta con el Sector de Normalización de Telecomunicaciones bajo el código X.1051. 
ISO 27013 – integración de la ISO 20000-1 y la ISO 27001
Esta norma proporciona lineamientos para aquellas organizaciones que deseen integrar los sistemas de gestión de los servicios de TI y los de seguridad de la información, para beneficiarse de los elementos comunes en ambas normas. Por ejemplo, esta norma combina los sistemas de documentación, los de manejo de incidentes y los procesos de prestación de los servicios de seguridad, de monitoreo y de revisión. En otras palabras, esta Norma integra el conocido ITIL que bajo estándares ISO es la Norma ISO 20000 y los sistemas de gestión de seguridad de la información o ISO 27000.

ISO 27014 – marco de gobernabilidad de la seguridad de la información
Esta norma da apoyo al aspecto de la seguridad de la información referido al marco de gobernabilidad corporativa. La norma ISO 27001 es un marco ideal para la seguridad de la información ya que incluye los tres elementos clave de la gobernabilidad: gestión de riesgos, sistemas de control y la función de auditoría. 
ISO 27015 – para el sector financiero y de seguros
Esta norma trata de los requisitos específicos de aquellas organizaciones de los sectores financiero y de seguros que están adoptando la norma ISO 27001.
Este es el estado actual de la familia ISO 27000, cualquier novedad al respecto sera oportunamente publicada.

Tomado de http://spain.irca.org

viernes, mayo 07, 2010

ISO 27001 e ISO 27002: Dominio 15 Cumplimiento



Continuando con los Dominios de la ISO 27002 (Numeral 15) o Anexo A de la ISO 27001 (Anexo A15), hoy vamos a revisar el Cumplimiento. Que dicen la ISO 27001 e ISO 27002? Bien, incluye tres objetivos de control:

15.1 CUMPLIMIENTO DE REQUISITOS LEGALES

Objetivo: evitar el incumplimiento de cualquier ley, de obligaciones estatutarias, reglamentarias o contractuales y de cualquier requisito de seguridad.
El diseño, el uso, la operación y la gestión de los sistemas de información pueden estar sujetos a requisitos de seguridad estatutarios, reglamentarios y contractuales.

Se debería buscar asesoría sobre los requisitos legales específicos de los asesores jurídicos de la organización o de abogados practicantes calificados. Los requisitos legales varían de un país a otro y pueden variar para la información creada en un país y que se transmite a otro (es decir, el flujo de datos transfronterizo).


15.2 CUMPLIMIENTO DE LAS POLÍTICAS Y LAS NORMAS DE SEGURIDAD Y CUMPLIMIENTO TÉCNICO

Objetivo: asegurar que los sistemas cumplen con las normas y políticas de seguridad de la organización.
La seguridad de los sistemas de información se debería revisar a Intervalos regulares.

Dichas revisiones se deberían llevar a cabo frente a las políticas de seguridad apropiadas y se deberían auditar las plataformas técnicas y los sistemas de información para determinar el cumplimiento de las normas aplicables sobre implementación de la seguridad y los controles de seguridad documentados.

15.3 CONSIDERACIONES DE LA AUDITORÍA DE LOS SISTEMAS DE INFORMACIÓN


Objetivo: maximizar la eficacia de los procesos de auditoría de los sistemas de información y minimizar su interferencia.


Deberían existir controles para salvaguardar los sistemas operativos y las herramientas de auditoría durante las auditorias de los sistemas de información y minimizar su interferencia.


Deberían existir controles para salvaguardar los sistemas operativos y las herramientas de auditoría durante las auditorias de los sistemas de información.
También se requiere protección para salvaguardar la integridad y evitar el uso inadecuado de las herramientas de auditoría.
La Norma busca que para todos los proyectos desarrollados por la Organización, en el diseño, operación, uso y gestión de los sistemas de información se debe evaluar si deben estar sujetos a obligaciones estatutarias, reglamentarias y contractuales de seguridad. De ser así se debe evitar el incumplimiento a cualquier ley civil o penal, obligaciones estatutarias, reglamentarias o contractuales de cualquier requisito de seguridad. Veamos un poco mas:
Todas las actividades que realicen los funcionarios o proveedores de servicios externos de la Organización, en donde utilicen los activos de información del la Organización deben acogerse a la política de seguridad y de cumplimiento técnico corporativo que le aplique. En la Organización se debe asegurar que los sistemas de información con los que se interactúa cumplen con las normas y políticas de seguridad de la organización.
Para asegurar la protección de los sistemas operativos y las herramientas de auditoría durante las auditorias del sistema se deben establecer los controles respectivos y necesarios.
Ahora profundizando:

1. Cumplimiento de los requisitos legales
Para cada sistema de información en la Organizacion se deben definir, documentar específicamente y mantener actualizados los requisitos estatutarios, reglamentarios y contractuales, se deben definir los controles, medidas y responsabilidades específicos para su cumplimiento.

Para la definición y cumplimiento de los requisitos legales específicos en la Organizacion se debe buscar el soporte de los asesores jurídicos de la organización. Sobre la utilización de software patentado y/o utilización de material en el cual pueden existir derechos de propiedad intelectual en la Organizacion, se deben implementar procedimientos apropiados para el aseguramiento del cumplimiento de los requisitos legales, reglamentarios y contractuales. (Ejemplo: licencias, software legal, etc).

Los registros importantes, confidenciales o sensibles de la Organización se deben proteger contra la pérdida, destrucción y falsificación, por lo tanto se deben guardar de forma segura, para cumplir con los requisitos estatutarios, legales, contractuales y de la organización.


Los funcionarios de la Organización y usuarios de terceras partes deben estar informados que no es permitido otro acceso que no sea el autorizado a los sistemas y servicios de procesamiento de información.
Los controles criptográficos o de cifrado que se utilicen en la Organización deben cumplir con todos los acuerdos, leyes y reglamentos pertinentes con el país donde sean aplicados o donde se traslade información cifrada.

2. Cumplimiento de las políticas y las normas de seguridad y cumplimiento técnico

Se debe asegurar el cumplimiento de los sistemas con las políticas y normas de seguridad estipuladas por la Organización.
Cada responsable de los procesos en la Organizacion debe garantizar el correcto funcionamiento de todos los procedimientos de seguridad que se encuentren dentro de sus responsabilidades para lograr el cumplimiento con las políticas y normas de seguridad.

Se deben realizar revisiones regulares al menos una por año y/o de acuerdo a la programación de las auditorias internas, a todas las áreas de la Organización y a los propietarios de sistemas de información para asegurar el cumplimiento de las políticas, normas y cualquier otro requisito apropiado de seguridad.


Para determinar el cumplimiento con las normas de implementación de seguridad, los sistemas de información deben ser verificados periódicamente. Una verificación del cumplimiento técnico asegura que los controles y medidas de hardware y software han sido implementados correctamente en los sistemas operativos de la Organización. Este tipo de verificaciones las deben realizar o supervisar únicamente personas competentes y autorizadas.

3. Consideraciones de la auditoría de los sistemas de información
Durante las auditorias del sistema se deben establecer controles para la protección de los sistemas operativos y de las herramientas de auditoría, para maximizar la eficacia de los procesos de auditoría de los sistemas de información y minimizar su interferencia.


Para minimizar el riesgo de interrupciones de los procesos de negocio de la Organización, se deben planificar y acordar detalladamente los requisitos y las actividades de auditoría lo cual implica verificaciones de los sistemas operativos.


Para evitar el uso inadecuado o evitar poner en peligro las herramientas de auditoría de los sistemas de información, éstas deben estar protegidas, deben estar separadas de los sistemas de desarrollo y de producción, no se deben mantener en librerías de cintas o áreas de usuario, salvo que estén debidamente protegidas.



domingo, mayo 02, 2010

ISO 27001 e ISO 27002: Dominio 14 Gestión de la Continuidad del Negocio




Continuando con los Dominios de la ISO 27002 (Numeral 14) o Anexo A de la ISO 27001 (Anexo A14), hoy vamos a revisar la Gestión de la Continuidad del Negocio. Que dicen la ISO 27001 e ISO 27002? Bien, incluye un objetivo de control:
14.1 ASPECTOS DE SEGURIDAD DE LA INFORMACIÓN EN LA GESTIÓN DE CONTINUIDAD DEL NEGOCIO

Objetivo: Contrarrestar las interrupciones en las actividades del negocio y proteger sus
procesos críticos contra los efectos de fallas importantes en los sistemas de información o contra desastres y asegurar su recuperación oportuna.

Se debería implementar un proceso de gestión de la continuidad del negocio para
minimizar el impacto y la recuperación por perdida de activos de información en la organización (la cual puede ser el resultado de, por ejemplo, desastres naturales, accidentes, fallas del equipo y acciones deliberadas) hasta un nivel aceptable mediante la combinación de controles preventivos y de recuperación. En este proceso es conveniente identificar los procesos críticos para el negocio e integrar los requisitos de la gestión de la seguridad de la información de la continuidad del negocio con otros requisitos de continuidad relacionados con aspectos tales como operaciones, personal, materiales, transporte e instalaciones.

Las consecuencias de desastres, fallas de seguridad, perdida del servicio y disponibilidad del servicio se deberían someter a un análisis del impacto en el negocio. Se deberían desarrollar e implementar planes de continuidad del negocio para garantizar la restauración oportuna de las operaciones esenciales.

La seguridad de la información
debería ser una parte integral de todo el proceso de continuidad del negocio y de otros procesos de gestión en la organización.

La gestión de la continuidad del negocio deberla incluir controles para identificar y
reducir los riesgos, además del proceso general de evaluación de riesgos, limitar las consecuencias de los incidentes dañinos y garantizar la disponibilidad de la información requerida para los procesos del negocio.
Como se puede interpretar, la Norma busca que la información de la Organización SIEMPRE este disponible, y cuando no pueda estarlo, su tiempo de no disponibilidad sea lo mas reducido posible para no afectar las operaciones, al cliente, etc. Profundicemos en los requisitos:
Para llevar a cabo la gestión de continuidad del negocio en la Organización se debe definir e implementar un proceso para reducir la interrupción causada por desastres naturales, accidentes y fallos de seguridad por medio de la combinación de controles preventivos y de recuperación.

Para el aseguramiento de la restauración de los servicios y sistemas de procesos manejados en la Organización en plazos requeridos para el aseguramiento de la continuidad del negocio, se deben desarrollar e implementar planes de contingencia, los cuales deben ser probados para que se integren con todos los demás procesos de gestión.


Las consecuencias causadas por desastres naturales, fallos de seguridad y pérdidas de servicio deben ser analizadas.
Se deben definir e implementar normas y controles para la identificación y reducción de riesgos, limitar las consecuencias de incidentes dañinas y asegurar la reanudación, a tiempo, de las operaciones esenciales.
Pero que debería incluir el Plan de Continuidad de Negocio?

Se debe seguir una estrategia de recuperación alineada con los objetivos de negocio, formalmente documentada y con procedimientos perfectamente probados para asegurar la restauración de los procesos críticos del negocio, ante el evento de una contingencia.

Esta estrategia debe mantener una estructura unificada para asegurar la consistencia de todos los planes y considerar los requisitos de seguridad de la información de forma consistente. Cada Responsable de los procesos de la Organización con el acompañamiento del área del Sistemas debe diseñar, implementar, probar y mantener su Plan de Continuidad. El plan de continuidad debe considerar los siguientes aspectos:
  1. Procedimientos de contingencia. Los cuales describen las acciones a tomar cuando ocurre un incidente que interrumpe las operaciones del negocio, proporcionando mecanismos alternos y temporales para continuar con el procesamiento.
  2. Procedimientos de recuperación. Los cuales describen las acciones a seguir para trasladar las actividades del negocio a un centro alterno de recuperación.
  3. Procedimientos de retorno. Los cuales describen las acciones a seguir para regresar las operaciones normales a las instalaciones originales.
  4. Programación de pruebas. Las cuales describen la periodicidad en que el plan de continuidad debe ser probado.
  5. Actualización periódica. El plan debe actualizarse cuando cambios realizados en el ambiente operativo impacten su funcionalidad. Un análisis de impacto al negocio debe ser realizado como mínimo una vez al año, con el objeto de determinar la necesidad de la disponibilidad de la información en el grado y escala de tiempo requeridos después de una interrupción de las funciones críticas de la Organización.
  6. Consideraciones de seguridad. Es importante que el plan sea diseñado para mantener los controles de seguridad establecidos por la Organización, aún cuando se opere en modalidad de contingencia. Es responsabilidad de la Coordinación de Seguridad de la Información asegurar que estas consideraciones sean efectivamente contempladas en el plan.
  7. El Plan de Continuidad debe estar alineado con los riesgos identificados que puedan causar interrupción al servicio. Para este caso, se debe tener en cuenta las posibles consecuencias para la seguridad de la información.
Cuando se realicen pruebas, simulacros o se tengan contingencias reales, los resultados y sugerencias deben ser entregadas a los responsables de la información quienes deben actualizar sus planes y mantenerlos al día conforme los riesgos de disponibilidad lo dictaminen. Al menos cada seis meses, se deben realizar ejercicios regulares y diagramados de recuperación del sistema para probar la efectividad del plan de continuidad del negocio.

El objetivo de realizar pruebas de los planes de continuidad, es probar que el plan se
encuentre debidamente actualizado, que los procedimientos funcionan adecuadamente y que se obtiene la recuperación requerida en el tiempo programado.

Como se puede observar, idealmente un Plan de Continuidad de Negocios contiene procedimientos de contingencia, de recuperación, de retorno, de pruebas, debe ser actualizado con una periodicidad preestablecido cuando la situación lo amerite, y muy importante, estar alineado con los riesgos que se haya identificado cuya materialización u ocurrencia desemboque en interrupciones de servicio.