Deje de comprar tecnología de seguridad (segunda parte)

En la primera parte comenté sobre el sesgo que los responsables de seguridad comúnmente tienen hacia la tecnología y por lo que es frecuente que no exista un balance adecuado entre gente, procesos (incluyendo particularmente la disciplina de operación de la seguridad) y tecnología. Este desbalance es la inspiración para el título de este artículo.

También enumeré los principales procesos que deberían tomarse en cuenta y las tareas que cada uno de ellos debe contemplar, para que el lector cuente con herramientas para evaluar el nivel de madurez de su organización a este respecto.

En esta ocasión abordaré algunas ideas y sugerencias de cómo implementar esos procesos y mejores prácticas. Para ello utilizaremos el caso hipotético de Gigi.

.

Nuestro caso de estudio

Gigi es la responsable de seguridad de la información (o CISO, por las siglas en inglés de Chief Information Security Officer) de una empresa en el ramo de seguros. En los últimos años ha tenido algunos incidentes de seguridad que han hecho que los altos ejecutivos estén más conscientes de la necesidad de protección de su información y le soliciten a Gigi mejores resultados en esa tarea.

Lo anterior ha hecho que Gigi se sienta muy presionada, pues no sólo le han exigido mejorar la seguridad sino que le han aprobado, con ciertas limitaciones, las iniciativas de mejora que ha propuesto. El año pasado, por ejemplo, le autorizaron reforzar la seguridad en Internet y en los servidores críticos de bases de datos. Para estos dos proyectos Gigi adquirió varios dispositivos, incluyendo un firewall de bases de datos, y dos personas de su equipo tomaron los cursos de los fabricantes respectivos.

No obstante, el mes anterior hubo un incidente de seguridad relacionado con fuga de información y, para colmo, la base de datos usurpada era una de las que supuestamente estaban protegidas. Cuando se le reclamó al proveedor del equipo, este argumentó a su favor que (a) los firewalls de bases de datos habían enviado ciertas alertas a la consola, pero nadie las estaba monitoreando en ese momento, (b) la configuración de los mismos no estaba completa pues faltaba aplicar ciertas reglas para detectar algunos comportamientos anómalos, y (c) los administradores de bases de datos no tenían bien configurados los permisos, lo que aumentaba las vulnerabilidades en el sistema. En resumen, la tecnología no podía suplir errores y omisiones humanas. Parecía que Gigi y su equipo necesitaban “algo” más.

Leyendo la primera parte de este artículo, Gigi se dio cuenta de lo que había estado haciendo en los últimos meses: había estado tratando de resolver los retos de seguridad poniendo demasiado peso en las herramientas, poco peso en la gente que las opera, y prácticamente ninguno en los procesos para su gestión y monitoreo. Lo que narraré a continuación son las diversas actividades que Gigi y su equipo realizaron para mejorar sus procesos y prácticas de seguridad.  El lector se dará cuenta de que las fases en que dividió Gigi el proyecto pueden servir de base para proyectos similares en su organización y conformar un marco metodológico general que pueda ser fácilmente aplicable.

.

Tomando conciencia

El lunes siguiente Gigi llegó a su oficina con una tarea en mente: hacer que su gente entendiera la importancia de los procesos y prácticas de seguridad. Afortunadamente todo el equipo había leído y entendido el mensaje: “Hay que implementar buenos procesos y prácticas de seguridad”.

Todos estaban de acuerdo en el “qué”, pero no sabían “cómo” atacar el problema. Después de revisar varias alternativas, Gigi propuso establecer algunas preguntas clave:

• Primera etapa (entendiendo el problema)-¿Dónde estamos? ¿Qué tenemos? ¿Qué implicaciones hay?
• Segunda etapa-¿Qué queremos lograr?
• Tercera etapa-¿Qué opciones tenemos?
• Cuarta etapa-¿Qué hay que hacer?

Todos aceptaron la idea de usar como base estas preguntas y se pusieron a trabajar. Veamos lo que fueron logrando en cada etapa.

.

Primera etapa (entendiendo el problema)

¿Dónde estamos? ¿Qué tenemos? ¿Qué implicaciones hay?

Dado que el objetivo de esta etapa es entender mejor el problema, después de una breve discusión todos estuvieron de acuerdo en hacer un análisis de brechas de los procesos. Esto es establecer el estado actual de cada proceso y después definir “la brecha” (aquello que le falta) para llegar al nivel de madurez deseado[1]. El equipo de trabajo se dio cuenta de que ellos mismos conocían el estado de la mayoría de los procesos por lo que casi no necesitarían consultar fuentes externas y esta labor sería relativamente rápida.

Para hacer un poco más concreto el análisis de brechas, decidieron crear un modelo de madurez de procesos con los niveles siguientes:[2]

    0. Inexistente. No hay un proceso implementado ni prácticas equivalentes.

1. Básico. El proceso es muy simple, no está documentado en forma completa y tiene alcances limitados (podrían, incluso, no estar muy claros esos alcances). No está integrado con otros procesos, además de que hay  muchas inconsistencias y errores asociados a su ejecución.

2. Intermedio. La documentación y alcances son mejores que los del nivel anterior pero aún es incompleta o todavía hay inconsistencias, ya sea en su ejecución, entre lo documentado y la práctica, etcétera. Los niveles de sistematización y automatización tampoco son los mejores.

3. Avanzado. Los alcances son los que pragmáticamente requiere la organización, aunque no cumplan rigurosamente con los estándares o prácticas internacionales. La documentación es completa y consistente con la ejecución.  El nivel de sistematización y automatización puede no ser el mejor pero el proceso es eficiente.

4. Ideal. Cumple con las mejores prácticas a nivel internacional. El proceso está completamente documentado, todos los involucrados lo conocen y lo siguen, por lo que hay total consistencia en su ejecución y se llevan métricas de la misma (a veces llamados KPI: Key Performance Indicators). Hay evidencias claras de su utilización. Está sistematizado y su automatización se ha llevado al máximo nivel. Está integrado con los demás procesos.

Al continuar con la preparación decidieron asociar una implicación a la brecha (¿Qué nos ha pasado o nos puede pasar por no tener bien implementado ese proceso o práctica de seguridad?) y acotaron el alcance de la tarea: los procesos asociados con administración de identidades, administración de vulnerabilidades  y desarrollo de aplicaciones seguras los dejarían para un futuro.

Aunque las definiciones de niveles de madurez anteriores no son exactamente iguales a modelos más conocidos, esas fueron las que Gigi y su equipo definieron y con las que estuvieron a gusto. Veamos a continuación sus hallazgos para algunos de los procesos.

.

Proceso de administración de riesgos.

• ¿Dónde estamos? ¿Qué tenemos?: se hace un análisis de riesgos anual y se establecen prioridades de atención así como un plan concreto de acción.
• ¿Qué implicaciones hay?: el equipo se dio cuenta de que uno de los elementos que les faltaba era tener una realidad única sobre los riesgos de la información. También se dieron cuenta de que no contaban con métricas claras para establecer el nivel de riesgo de la empresa y determinaron que otra brecha importante era convertir el análisis de riesgos en un proceso continuo de administración de riesgos, que no tenían.

Determinar las implicaciones de lo anterior resultó muy sencillo. Se percataron de que su proceso estaba en el nivel básico y que al no tener una cobertura integral y no ser continuo aumentaba su nivel de exposición, pues solo una vez al año están haciendo un análisis razonablemente completo.

Adicionalmente, al no contar con métricas de seguridad, cada uno de los involucrados tiene percepciones y opiniones distintas sobre el nivel de riesgos de la información de la empresa, lo que se está haciendo para su manejo y, en general, acerca del estado de seguridad de la organización.

.

 Proceso de administración de vulnerabilidades.

• ¿Dónde estamos? ¿Qué tenemos?: se dieron cuenta de que el nivel de madurez era muy básico. Hoy contratan a un externo para hacer pruebas de hackeo ético desde Internet y después de cada prueba se establece, con apoyo del tercero, el plan de remediación de las vulnerabilidades encontradas.
• ¿Qué implicaciones hay?: el plan de remediación que establecen después de cada prueba es muy concreto y no es un proceso continuo. Adicionalmente, las remediaciones no se “insertan” en el proceso de control de configuraciones y no hay nadie revisando continuamente nuevos ataques o amenazas en Internet.

Al no tener un proceso continuo y con mayor cobertura que incluya un escaneo en toda la infraestructura tecnológica y aplicaciones, así como en los procesos y en el personal, es altamente probable que haya vulnerabilidades de las cuales no están conscientes, lo que aumenta su exposición a distintos riesgos.

.

Procesos de administración de cambios y configuraciones.

 

• ¿Dónde estamos? ¿Qué tenemos?: se dieron cuenta de que en el área de sistemas casi toda la infraestructura posee un buen nivel de madurez en estos procesos; están definidos, son conocidos por los responsables y se siguen rutinariamente. Sin embargo, en la configuración de bases de datos e infraestructura de seguridad estos procesos no son tan maduros pues su definición no está completa, las guías de apoyo están desactualizadas o no existen, no pasan por la planeación de los cambios y nadie garantiza que los elementos involucrados estén con configuraciones autorizadas y actualizadas.
• ¿Qué implicaciones hay?: la principal implicación es inestabilidad, que tratándose de dispositivos de seguridad se manifiesta como inseguridad.

 

.

Procesos de monitoreo de la seguridad y manejo de incidentes de seguridad.

• ¿Dónde estamos? ¿Qué tenemos?: todo el equipo de Gigi tuvo que reconocer que en estos procesos el nivel de madurez era prácticamente nulo. Aunque se habían implementado las consolas de firewalls, IPS (sistemas de prevención de intrusos), antivirus y filtros de contenido, no había ningún responsable de su monitoreo y, por tanto, nadie lo hacía de manera continua.

Por otro lado, se dieron cuenta de que tampoco existían acciones predefinidas para el manejo de actividades sospechosas o incidentes de seguridad.

• ¿Qué implicaciones hay?: no se monitorea el comportamiento de la infraestructura de seguridad y las acciones derivadas de un incidente de seguridad tienen resultados aleatorios, pues cada persona actuará como mejor crea conveniente o conforme le dicte su experiencia.

.

Segunda etapa

¿Qué queremos lograr?

En esta etapa al preguntarse ¿Qué queremos lograr?, el equipo definió su VISIÓN: “Deseamos implementar una operación de la seguridad más estable, que sea proactiva para detectar y manejar oportunamente los incidentes de seguridad”.

Como ya se imaginarán, a continuación precisaron definir varios de los términos de la visión anterior:

• Operación estable. La definieron como una operación en donde:
  • Los procesos de control de cambios y configuraciones son claros, bien establecidos y alineados a ITIL.
  • 99 de cada 100 cambios se ejecuten conforme a lo planeado.
  • Los dispositivos de seguridad involucrados estén actualizados.
• Detección oportuna. Concluyeron que para detectar oportunamente y ser más proactivos debían:
  • Implementar un proceso de monitoreo y detección de incidentes de seguridad apegado a las mejores prácticas.
  • Detectar todos los incidentes de seguridad que la tecnología permita en un lapso menor a 10 minutos y contenerlos en los siguientes 60 minutos.
  • Monitorear diversos sitios de Internet para conocer, el mismo día, nuevas vulnerabilidades y nuevas amenazas (incluyendo, entre otras, ataques de día cero y amenazas persistentes avanzadas) para aplicar las medidas necesarias.

Ahora bien, al intentar establecer el marco de mejores prácticas e indicadores más específicos, se dieron cuenta de que el monitoreo y detección de incidentes de seguridad no están bien definidos en ITIL, además de que requerían una mayor experiencia. Por ello, para no abarcar demasiado, decidieron dejar para un futuro el análisis de los procesos de administración de riesgos y vulnerabilidades, no por no ser importantes sino porque todo proyecto debe acotar sus alcances.

.

Tercera etapa

¿Qué opciones tenemos?

Como ya se comentó, se decidió trabajar en los procesos de administración de configuraciones, cambios, monitoreo de seguridad y manejo de incidentes de seguridad.

Al decidir que se buscaba un nivel de madurez avanzado en menos de un año, el equipo de Gigi estableció las alternativas para desarrollar el proyecto y definió que había tres variables importantes para jugar con las opciones:

• Cobertura: ¿Qué procesos queremos cubrir?
• Madurez: ¿A qué nivel de madurez aspiramos llegar en los procesos elegidos?
• Forma: ¿Quién lo desarrollará? ¿El equipo de Gigi, un externo calificado o una combinación para tener un equipo mixto?

El resultado del análisis se resume en la siguiente tabla:

Cobertura	Nivel de madurez deseado	¿Quién lo desarrollará?
Administración de cambios y configuraciones. Basado en ITIL versión 3.En la primera etapa se cubrirán solamente los firewalls y sistemas de prevención de intrusos (IPS) de la salida a Internet. Posteriormente se cubrirán otros dispositivos.	Nivel 3: avanzado	El equipo interno desarrollará e implementará estos procesos debido a que tienen los conocimientos y experiencia suficiente en ITIL.
Monitoreo y manejo de incidentes de seguridad. Utilizarán la metodología de un proveedor externo (la cual está basada en el CERT y en SANS). El enfoque será hacia los firewalls (incluyendo los de bases de datos) e IPS. Posteriormente hacia otros dispositivos e integración de herramientas de correlación (SIEM).	Nivel 3: avanzado	El equipo del proveedor externo realizará las adaptaciones a su metodología.

Resumen de opciones para los procesos a cubrir en la fase 1 del proyecto

.

Cuarta etapa

¿Qué hay que hacer?

Se decidió dividir el trabajo en dos grupos: un equipo interno enfocado a los procesos de administración de cambios y configuraciones, y un equipo híbrido dedicado al proceso de monitoreo y administración de incidentes de seguridad.

Las principales acciones que se definieron para el equipo interno fueron las siguientes:

1. Capacitar a dos personas en el nivel inicial de ITIL.
2. “Aterrizar” los procesos de control de cambios y configuraciones. Esto incluye determinar los flujos específicos con las tareas que le corresponden a los roles involucrados, ajustar los indicadores (KPI), entre otras tareas.
3. Hacer guías básicas de configuración de los firewalls y de los IPS, de acuerdo a las marcas y modelos que tiene la empresa instalados hoy en día.
4. Realizar revisiones simuladas de los procesos, donde se prueben con algunos cambios “controlados” y se recorran los procesos respectivos.
5. Ajustar los procesos de acuerdo a lo observado en la actividad anterior.
6. Implementar los procesos.

El cronograma general lograron establecerlo para seis meses como lo muestra la figura siguiente:

Cronograma para la implementación de los procesos de control de cambios y configuraciones

.

Para el segundo equipo las actividades principales se estipularon así:

• Levantamiento de información.  El objetivo es que el proveedor se familiarice con la forma actual de operar la infraestructura, pero –sobre todo- con la visión específica del proyecto y lo que se desea obtener en estos procesos.
• Revisión de alcances. En esta actividad se debe realizar un documento completo sobre los alcances, generalmente llamado “SOW”, por las siglas del inglés de scope of work.
• Adaptación de los procesos. Esta tarea es realizada fundamentalmente por el externo, y el objetivo es ajustar los procesos de su marco metodológico a las necesidades y particularidades del cliente, incluyendo procedimientos, guías, roles, funciones y demás definiciones y documentos que acompañan a dichos procesos y que son necesarios para la operación completa.
• Transferencia de conocimientos, que abarca:
  • Talleres y cursos para el entendimiento de los procesos y los documentos complementarios.
  • Operación conjunta, que incluye un período de apoyo (coaching) muy personalizado a cada integrante del equipo del cliente, así como un periodo de operación de transición.
  • Liberación, que incluye un periodo de observación y evaluación de la operación autónoma del cliente.

La tabla 2 muestra el cronograma para este equipo híbrido.

Cronograma para la implementación de los procesos de monitoreo y administración de incidentes de seguridad

.

Conclusiones

Para no repetir lo que he dicho arriba, resumiré las conclusiones en cinco recomendaciones:

1. No olvide el triángulo de la seguridad Tecnología + Gente + Procesos. En otras palabras, DEJE DE COMPRAR TECNOLOGÍA hasta que no tenga balanceada la fórmula.

2. No sea demasiado optimista, antes de decir “ya tenemos ese proceso implementado en la organización”, mejor revise si el nivel de madurez es el adecuado.

3. Recuerde que, por lo general, la gente más técnica no es la más ordenada. Esto significa que, salvo excepciones, los líderes de ciertos procesos no necesariamente son las personas que saben más técnicamente, sino los mejor balanceados.

4. Es importante que involucre a los altos ejecutivos de la empresa, pero no los inunde con tecnicismos ni detalles que no entienden o que no son relevantes para el negocio.

5. Fortalezca día a día el rol del responsable de seguridad con mejores formas de operar y, sobre todo, asociando los proyectos y tareas de seguridad con las necesidades del negocio.

Aquí nos despedimos. Espero que les haya sido de utilidad y nos seguiremos viendo en esta sección.

[email protected]

[1] Un análisis de brechas también se puede hacer contra mejores prácticas o contra un estándar o normatividad determinada.

[2] Los niveles definidos por Gigi y su equipo están inspirados en el modelo de madurez de capacidades (Capability Maturity Model, CMM) definido por el Instituto de Ingeniería de Software (SEI) de la Universidad de Carnegie Mellon. CMM se aplicó originalmente para desarrollo de software pero hoy en día, con ciertas adecuaciones, se usa en distintos ámbitos de la informática.