Hoy en día es innegable la tendencia de las organizaciones a contratar servicios externalizados (outsourcing) y prueba de ello son las cifras que firmas como Select e IDC dan. Por ejemplo, Select estima que entre 2007 y 2010 se incrementarán en 25% los servicios externalizados de seguridad y en 18% los de aplicaciones, hospedaje y redes, así como 12% el de centro de datos. El valor del mercado, según esta misma firma, alcanzará para 2010 los $4,000 millones de dólares[i]. Por otro lado el “Decreto de Austeridad” lanzado por el gobierno mexicano en diciembre de 2006 ha dado un fuerte impulso a los servicios externalizados y ha hecho que las dependencias aumenten el número de proveedores con los que trabajan bajo este esquema.

Como se mencionó anteriormente, uno de los segmentos que crecerá más significativamente es el de la externalización de la seguridad, siendo éste un mercado aún inmaduro, con un número creciente de proveedores y cada uno de ellos con enfoques distintos.

Que una organización contrate este tipo de servicios, denominados comúnmente como Seguridad Administrada o MSS (Managed Security Services), implica que una buena parte del proceso de manejo de incidentes de seguridad, que explicaré de manera general más adelante, esté en manos de tercero, por lo que es necesario asegurarse que dicho proceso tenga los elementos mínimos indispensables en sus organizaciones para que funcione de manera adecuada y oportuna. Si además agregamos el hecho de que no sólo se está externalizando la seguridad sino también otras aplicaciones y funciones críticas para la organización, veremos que la situación se torna aún más compleja.

 En este artículo busco mostrar algunos elementos básicos a tomar en cuenta cuando existan ambientes externalizados y que sirvan como referencia para poder definir una interacción adecuada con los proveedores de seguridad administrada (en adelante “PSA”) y también con los demás proveedores (outsourcers) que puedan existir en una organización para la ejecución del proceso de manejo de incidentes de seguridad. Es importante aclarar que, dado que cada organización es única, y por lo tanto también lo son su infraestructura de TI y su operación, podrá haber sugerencias que no necesariamente apliquen o tengan sentido para una situación en particular.

El proceso de manejo de incidentes de seguridad

Primero daremos un repaso rápido sobre algunos conceptos que son sumamente importantes para sentar las bases de análisis:

Un evento es cualquier ocurrencia observable de un sistema o red. Por ejemplo: Un usuario se conecta a un sistema, un intento fallido de un usuario para ingresar a una aplicación, el firewall que permite o bloquea un acceso, etc. No necesariamente un evento tiene un efecto perjudicial, puede ser simplemente informativo. Por otro lado una actividad sospechosa, es un evento o conjunto de eventos relacionados que indican la posible ocurrencia de un incidente de seguridad. Normalmente se requiere hacer una investigación para poder determinar si realmente se trata o no de un incidente de seguridad.

La definición de lo que es un incidente de seguridad varía dependiendo de la fuente, citaré dos de las más relevantes y posteriormente la que hemos adoptado en Scitum.  Por un lado, el CERT[ii] lo define como el acto de violar una política de seguridad explícita o implícita. El SANS[iii], por su parte, lo define como un evento adverso en un sistema y/o red, o la amenaza de ocurrencia de dicho evento. Un incidente de seguridad implica hacer daño o la intensión de hacerlo. En Scitum hemos definido un incidente de seguridad como: una violación o amenaza inminente de violación a las políticas de seguridad informática; al uso aceptable de políticas; y de prácticas de seguridad estandarizadas.

Ahora revisaremos la definición general del proceso de manejo de incidentes de seguridad, que es el conjunto de actividades encaminadas a detectar, analizar y reportar los incidentes de seguridad así como responder para minimizar su impacto en la organización.

Es importante aclarar la diferencia entre respuesta a incidentes de seguridad y, manejo, que suelen usarse de manera indistinta, pero que tienen alcances diferentes. La respuesta se refiere exclusivamente a las acciones tomadas como respuesta ante la ocurrencia de un incidente de seguridad, mientras que el manejo de incidentes de seguridad es mucho más amplio e incluye, además de la respuesta, otras actividades como el reforzamiento de configuraciones, monitoreo, detección, etc. Es decir, que la respuesta es un subconjunto de actividades del manejo de incidentes de seguridad.

El proceso de manejo de incidentes de seguridad tiene 4 grandes etapas, cada una de ellas se componen de subprocesos y actividades específicas a realizar:

Preparación

Considera todas las actividades iniciales que hay que hacer con los dispositivos y sistemas para fortalecer las configuraciones así como para la habilitación de mecanismos de monitoreo (por ejemplo, la actualización y afinación de reglas de los sistemas de prevención de intrusos o IPSs) y de rastreo en caso de incidentes (por ejemplo, la activación de bitácoras o logs).

Aunque esta etapa se considera como un punto de partida, el proceso requiere que de manera periódica se vuelva a realizar, en especial si ha habido un incidente.

Una actividad de suma importancia, que aunque parezca obvia muchas de las veces no se realiza, es la de recolectar la documentación necesaria sobre las redes y los sistemas para que en el momento de un incidente se pueda consultar fácilmente. Hay que tener, entre otras cosas información de qué aplicaciones corren en cada sistema, qué direcciones IP y MAC tiene cada dispositivo, diagramas de conexión de la red, servicios activos, etc.

Detección

El objetivo de esta etapa es poder confirmar la presencia de un incidente de seguridad e iniciar las acciones inmediatas de respuesta. Los principales subprocesos incluidos en la detección son:

  • Monitoreo. No requiere de mucha explicación, implica la revisión permanente (7×24) de los eventos.
  • Identificación. Aquí es donde se comprueba si hay actividades sospechosas y/o incidentes de seguridad para determinar, en su caso, el tipo de incidente, el origen, los sistemas objetivo, los sistemas y aplicaciones afectadas, etc.
  • Contención inicial.  Acciones inmediatas que se pueden tomar para contener el incidente desde la infraestructura de seguridad (firewalls, IPSs, etc.) y de comunicaciones (ruteadores, switches, etc.).
  • Notificación. Hay que reportar la ocurrencia del incidente a las personas responsables dentro de la organización. Si con la contención inicial se ha logrado detener, no se solicitará ninguna acción adicional.

Respuesta

El objetivo es limitar al máximo los efectos del incidente de seguridad en la organización así como restablecer los servicios afectados lo más pronto posible. Los principales subprocesos a considerar son:

  • Contención final. Acciones orientadas a reducir las consecuencias del incidente a través de acciones de mayor impacto y trascendencia que las realizadas en la contención inicial.
  • Investigación. Analizar a detalle las causas (vulnerabilidades, errores de configuración, etc.) y el origen del incidente así como los impactos, reales o posibles, del mismo.
  • Erradicación. Eliminar los huecos de seguridad encontrados para evitar que el incidente pueda ocurrir nuevamente. Se deberán considerar tanto controles preventivos como detectivos y correctivos.
  • Recuperación. Actividades a realizar para poner nuevamente en funcionamiento los sistemas que hayan sido afectados por el incidente de seguridad o por el propio subproceso de contención.

Mejora continua

El objetivo es llevar a cabo una revisión posterior al incidente para encontrar áreas de oportunidad en el proceso, comúnmente esta actividad se conoce como «lecciones aprendidas».

A lo largo de todas las etapas y actividades se requiere realizar un seguimiento adecuado para garantizar el flujo oportuno y sin contratiempos del proceso.

Consideraciones a tomar en cuenta cuando se externalizan los servicios de seguridad

A continuación analizaremos brevemente qué actividades son sujetas de externalizar con base en los elementos descritos en la sección anterior.

Preparación

En la etapa de preparación, que involucra muchas actividades distintas, es viable que la mayoría de ellas sean externalizadas, ya sea como proyectos puntuales o como servicios recurrentes (outsourcing). Algunos ejemplos:

  • Fortalecimiento de equipos, donde el proveedor puede trabajar con una muestra específica cada mes de tal forma que pasados “N” meses se haya cubierto toda la infraestructura.
  • Definición de líneas básicas de configuración (baselines), donde se pueden definir las configuraciones de referencia por plataforma ya sea para hacer el fortalecimiento o para auditorías posteriores.
  • Actualización y afinación de reglas de seguridad, donde el proveedor puede inventariar, analizar y evaluar las reglas de seguridad en dispositivos específicos  para determinar si es necesario realizar algún cambio a efectos de mejorar el nivel de seguridad.

Sin embargo, existen algunas otras actividades que deberán ser realizadas preferentemente por la propia organización, por ejemplo la definición de la política para el manejo de incidentes, en la que se definan aspectos como quiénes pueden declarar la existencia de un incidente; quién puede comunicarse con otras entidades en caso de un incidente de seguridad (autoridades judiciales, áreas legales, medios, un CERT externo, etc.); quién maneja internamente los casos de mal uso o abuso de los sistemas  por parte de empleados, etc.

Detección

Uno de las subprocesos que es factible de externalizar prácticamente al 100% es el de monitoreo, de igual forma el de identificación. Sin embargo, siempre quedará un pequeño componente de vigilancia del lado de la organización sobre todo lo relacionado a la identificación de incidentes a través de desviaciones en la operación habitual del negocio.

La contención inicial es también factible de externalización, sin embargo, lo común es que ésta no sólo dependa de la participación del PSA sino también de otros proveedores de outsourcing de TI y de la propia organización. Por ejemplo, es muy común que la seguridad esté asignada a un proveedor y la red a otro, por lo que en caso de requerirse tomar acciones (de contención), el primero deberá tomar las acciones asociadas a dispositivos de seguridad, mientras que el segundo deberá hacer lo respectivo en los equipos de comunicaciones.

Respecto a la notificación, será una actividad ligada al monitoreo, por lo que si éste se asigna a un tercero, lo mismo deberá suceder con la notificación. Normalmente el responsable será el PSA. En caso de requerirse la notificación a otro proveedor, responsable de otros elementos de TI, para su involucramiento en la contención es factible que el mismo PSA lo haga.

La notificación también incluye, en la mayoría de los casos, el avisar a los altos directivos de la organización, y eso seguramente es algo que usted no querrá dejar en manos de otro, por lo que esta parte será mejor que se quede dentro de la organización. Será lo mismo para el caso en que el incidente requiera notificación a entidades judiciales o a medios de comunicación.

Respuesta

Para la contención final, la probabilidad de que el PSA pueda ejecutar las acciones requeridas es relativamente baja, dado que normalmente implica tomar acciones en servidores y aplicaciones fuera del ámbito de su responsabilidad.

Típicamente estas actividades están en manos de otros proveedores y del área de sistemas, lo que sí debe considerarse como responsabilidad del PSA es la coordinación y seguimiento de todas las acciones de respuesta.

La investigación es, definitivamente, una actividad a realizar por el PSA con la colaboración, cuando se requiera, de otros proveedores o del mismo cliente.

Por su parte, tanto la erradicación como la recuperación son tareas que serán responsabilidad compartida entre todos los responsables de la administración de la infraestructura de TI incluyendo al PSA, donde la participación dependerá del ámbito de responsabilidad de cada uno.

Mejora continua

Esta actividad, aunque puede ser realizada por el PSA, lo mejor es que sea llevada a cabo por el cliente, sobre todo cuando hayan intervenido varios proveedores. Independientemente de esto, cada proveedor deberá realizar de manera individual un ejercicio similar pero acotado a sus alcances y responsabilidades.

Seguimiento

El seguimiento suele hacerlo el PSA en coordinación con el cliente.

Consideraciones a tomar en cuenta cuando se externalizan otros servicios de TI

Cuando se externalizan otros servicios del área de TI es indispensable que se consideren los requisitos de seguridad y en particular, los requisitos mínimos que el proveedor deberá cumplir al momento de la ocurrencia de un incidente.

Los requisitos mínimos a considerar son:

  • Formalizar su compromiso para participar, con base en su ámbito de responsabilidad, en el proceso de manejo a incidentes, sobre todo en la etapa de respuesta.
  • Proporcionar al cliente, o a quien éste designe, la información necesaria para la correcta ejecución del proceso. Tanto en la etapa de preparación como en las actividades de monitoreo, contención, erradicación y recuperación.
  • Participar en el análisis de información, cuando así se requiera, para determinar el posible origen de un ataque, así como las posibles vulnerabilidades explotadas y los posibles objetivos del ataque.
  • Establecer tiempos compromiso para la ejecución de acciones de contención, erradicación y recuperación.
  • En caso de detectar un incidente, seguir los conductos oficiales (acordados) para su notificación.
  • Compromiso para apegarse a las políticas, procesos y procedimientos establecidos para el manejo de incidentes.

Conclusiones y recomendaciones

  • La ejecución del proceso de manejo de incidentes, de por si compleja, se ve afectada por el involucramiento de múltiples entidades, en mucho casos externas a la organización (outsourcers).
  • No basta con que el PSA cuente con un proceso de manejo de incidentes robusto, pues su cobertura será en cualquier caso parcial. La organización deberá estar preparada para responder a incidentes fuera del alcance del PSA o donde se involucre a otras entidades.
  • El proceso involucra interacciones complejas y multi-entidades, por lo que requiere de definiciones previas, pero sobre todo claras, para cada parte involucrada.
  • Aunque muchos componentes del proceso son sujetos de externalizar, no se puede delegar al 100% en un proveedor.
  • Hay que asegurarse de que están definidos claramente los alcances del PSA respecto al proceso de manejo de incidentes. Por ejemplo: Definir quién es responsable de qué acciones, definir hasta dónde llega su responsabilidad, definir qué apoyos requerirá del cliente, definir qué dependencias hay con otros proveedores del cliente, definir el esquema de clasificación y priorización, definir qué esquema de escalaciones utilizará, etc.
  • Definir claramente los niveles de servicio a los que se comprometerá, por ejemplo: Tiempo para detección de incidentes, efectividad en la eliminación de falsos positivos, tiempo de notificación, tiempo de contención, tiempo de erradicación, número máximo de incidentes con impacto para la organización en un periodo determinado.
  • Debe estar claramente definido un responsable del manejo de incidentes tanto en el PSA como en la organización.

[email protected]

[i] Datos obtenidos de artículo de Netmedia del 10 de septiembre de 2008 publicado en su página web.

[ii] CERT. Inicialmente se creó el CERT como un programa de investigación y desarrollo establecido  como parte del Software Engineering Institute (SEI) del Carnegie Mellon University.  Posteriormente se creó el CERT/CC (Coordination Center) como un centro para coordinar la comunicación entre expertos durante emergencias de seguridad y prevenir futuros incidentes. Hoy en día el programa CERT desarrolla y promueve el uso de tecnologías y prácticas de administración de sistemas adecuadas para resistir ataques, limitar el daño y asegurar la continuidad de los servicios críticos.

[iii] SANS Institute. El SANS (SysAdmin, Audit, Network, Security) Institute es el organismo internacional de mayor reconocimiento en investigación cooperativa y educación en temas de seguridad de la información.