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

Mision CriticaPara seguir con la tradición de esta sección, tocaré en este artículo un problema con el que frecuentemente me encuentro en muchas organizaciones: los responsables de seguridad informática están demasiado enfocados a conocer, evaluar y comprar nuevas tecnologías, pero muy pocos se ocupan de administrarlas y operarlas de manera adecuada. Propondré una clasificación de madurez para que usted se autoevalúe y luego retaré su evaluación, tratando de convencerlo de que es muy probable que le falte “algo” para mejorar la seguridad y que ese “algo” tiene más que ver con los procesos o la conciencia de la seguridad que con la tecnología.

.

Caso 1: El Águila Descalza

El Águila Descalza (a la que llamaremos solamente AD) es una empresa industrial con oficinas corporativas en Monterrey y sucursales en 10 estados del país. En días pasados su sitio Web fue hackeado y los atacantes, autonombrados “Hackers Anónimos”, hicieron mucha publicidad del ataque. Al saber del ataque, la primera reacción del personal técnico responsable fue negar esa posibilidad: “¡No puede ser! Si tenemos todo: firewall, sistema de prevención de intrusos, filtros de contenido y antimalware. Debe ser otra cosa”. Pero el efecto era muy claro, el contenido de la página había sido alterado, y se habían dejado mensajes amenazadores como “Tenemos acceso a toda su información. Ni se preocupen en rastrearnos”.

El director general de AD estaba descontrolado por no saber qué hacer, y apenado por la imagen de la empresa, así es que – para conocer cómo fue el ataque y saber el grado de seguridad (o de exposición) de AD- decidió contratar a la empresa Expertos en Seguridad, a la que llamaremos ES. Los especialistas de ES empezaron a hacer diversos análisis y pruebas; los siguientes fueron sus principales hallazgos:

  1. El personal responsable (2 personas) posee buenos conocimientos técnicos, conocen de protocolos, saben configurar los dispositivos de seguridad y entienden cómo trabajan los principales tipos de ataques.
  2. AD no ha implementado un proceso de control de configuraciones para los dispositivos de seguridad. Solo lo ha implementado para los servidores que se consideran críticos.
  3. El servidor Web y el de aplicaciones tienen varias vulnerabilidades, muchas de ellas asociadas con versiones no actualizadas de software. Una de esas vulnerabilidades en el servidor Web fue la que explotaron los atacantes para acceder al servidor, sustraer información y modificar el contenido.
  4. El firewall no está bien configurado, por lo que no bloquea todo el tráfico inválido.
  5. La bitácora del mencionado firewall contiene mucha información reciente sobre escaneos de la red y diversos ataques que fueron bloqueados por dicho equipo. Todos esos ataques fueron originados desde el mismo grupo de direcciones IP, pero el personal de AD no se había percatado dado que nadie revisa las bitácoras.
  6. AD no hace un monitoreo continuo de su seguridad, más bien cuando sospechan que hay algún comportamiento anómalo en la red o en algún servidor, el personal técnico verifica si hay “algo” en las consolas de seguridad que pueda ser importante.
  7. Las pocas veces que AD ha detectado un incidente de seguridad, los responsables han actuado conforme a su criterio, pero no bajo un proceso formal para manejar dichos incidentes, pues no lo han definido.

En cuanto los responsables de AD entendieron que los atacantes se aprovecharon de una vulnerabilidad en el servidor Web, de inmediato sugirieron: “¡Perfecto!, parchemos el sistema y problema resuelto”. Afortunadamente los consultores de ES pensaban diferente y así lo expresaron: “mmmh, verán, la causa raíz del problema no es la vulnerabilidad que existe en el servidor; en realidad esta situación es el efecto de la carencia de una disciplina de operación que, desde nuestro punto de vista, es la verdadera fuente de este problema y de muchos otros que podrían surgir”. Aunque en primera instancia el personal técnico no estuvo de acuerdo, después de varias sesiones de discusión y de mostrarles los beneficios de contar con mejores prácticas de operación, al final aceptaron la conclusión y se comprometieron a ir implementando todo un marco metodológico para operar la seguridad.

.

Caso 2. Su Crédito Fácil

Este caso sucedió hace algunos años pero me gusta referirlo porque es muy ilustrativo de algunas deficiencias que son comunes cuando el énfasis de la seguridad está en la parte tecnológica. En aquella época estábamos haciendo un diagnóstico de seguridad a una empresa financiera a la que llamaremos Crédito Fácil, o solamente CF. Como parte del proyecto había que efectuar un “hackeo ético” para determinar si podíamos penetrar desde Internet hacia la red interna de CF. Llevamos a cabo varios intentos con escaneos y ataques diversos a su infraestructura de Internet, pero no podíamos entrar. Por ello decidimos probar con otra estrategia: recolectaríamos la información usando el engaño, es decir, utilizaríamos ingeniería social como herramienta. Y así lo hicimos, diseñando el engaño en dos partes:

Primera parte. Hacernos pasar como clientes potenciales.- A través de una empresa filial nuestra, contactamos al personal comercial de CF y fingimos ser clientes potenciales. Además de atendernos muy amablemente, nos contestaron todas las preguntas sobre seguridad informática que, como “clientes preocupados por el tema”, les efectuamos.

Segunda parte. Fingir ser empleados del proveedor de Internet ante el personal técnico de CF.- Para realizar esta fase, necesitábamos primero cierta información adicional que tenía el personal técnico de CF. Para ello, primero llamamos al proveedor de Internet de CF, con la finalidad de saber el nombre de la persona que normalmente atendía a CF (para simplificar, digamos que se llamaba Chanchis, un nombre genérico); después nos comunicamos con el personal técnico de CF haciéndonos pasar por Hugo, un supuesto nuevo empleado que trabajaba con Chanchis; generamos la confianza y averiguamos los datos que requeríamos para perpetrar el “ataque”, sin levantar la mínima sospecha. Después de lo anterior, logramos entrar a la red del cliente desde Internet.

En este caso el personal técnico estuvo muy contento por saber que sin ingeniería social no habíamos podido entrar (aunque debo decir también que en ese tiempo nuestro equipo de hackeo ético no estaba tan completo como actualmente), pero sentía que habíamos hecho un poco de trampa. Los altos ejecutivos estuvieron muy contentos y, a sugerencia nuestra, empezaron a implementar mejoras en su programa de cultura de seguridad.

Pero ¿A qué queremos llegar con estas historias?  Pienso que nosotros, los especialistas y responsables de la función informática en las organizaciones, incluidos los de seguridad, le hemos otorgado mucho peso a la tecnología y no tanta prioridad a la forma en que operamos y usamos dicha tecnología.

En otras palabras, nos preocupamos más por elegir e implementar los distintos productos de hardware y software, pero no tanto por controlar de manera rigurosa sus configuraciones y los cambios que estas sufren, o por monitorear su desempeño y disponibilidad en forma permanente, por mencionar un par de cuestiones.

En el caso de la seguridad, la mayoría de los especialistas sentimos que es indispensable adquirir firewalls, sistemas de prevención de intrusos, filtros de contenido, antivirus, controles de acceso, etcétera, pero no vemos indispensable el tema de la administración de la seguridad.

Entonces ¿Cuál es problema? ¿Por qué debemos preocuparnos, y ocuparnos, de una adecuada operación y gestión de la seguridad? Las dos historias anteriores pretender responder a ello. Si no existe una disciplina de operación y una conciencia en los usuarios, ninguna tecnología de seguridad es suficiente.

De hecho, el reto se aplica no solo a seguridad informática sino a todo TI. Si no hay una operación bajo un enfoque de procesos, tomando como base marcos de mejores prácticas como ITIL o ISO-20000, entonces no podremos garantizar –entre otros factores- la disponibilidad, el desempeño y la seguridad, y –casi inexorablemente- terminaremos impactando de una manera muy seria a la organización.

Pero, ¿por qué si parece tan lógico que haya una disciplina para administrar las TI se ha avanzado tan poco en este aspecto? ¿Por qué, en muchos casos, no nos quita el sueño responder a preguntas como quién configurará los distintos elementos, quién realizará los cambios a las configuraciones, vigilando que dichas configuraciones estén correctas y no se debilite la seguridad; quién hará el monitoreo continuo de estos equipos y revisará sus bitácoras, quién y cómo detectará eventos de seguridad importantes y cómo actuará cuando sucedan? O bien preguntas como ¿Qué conocimientos de seguridad necesitan los usuarios finales? ¿Cómo debemos motivarlos para que conozcan y cumplan las políticas de seguridad?

Tratando de entender por qué existe esa preferencia hacia la tecnología vs la disciplina de administración y la concientización, polemizaré un poco, que es uno de los objetivos de esta sección, proponiendo cuatro posibles respuestas, no necesariamente excluyentes:

  1. La mayoría de las personas que nos dedicamos a las TI somos hombres, y a los hombres nos gusta comprar juguetes toda la vida. En otras palabras, a nuestra mente masculina y lúdica le gusta comprar tecnología porque la vemos como juguetes para grandes (esta explicación le encanta a mi esposa, aunque yo todavía tengo mis dudas). Me acuerdo de una tienda de tecnología en Estados Unidos que se llamaba “Expensive Toys for Big Boys” (juguetes caros para niños grandes).
  2. En las carreras informáticas, sobre todo las que son de ingeniería, hay gran cantidad de materias tecnológicas (por ejemplo: redes, bases de datos, arquitectura de computadoras, sistemas operativos) en donde se enfatiza en la parte de hardware y software. En muy pocas de estas carreras se subraya la disciplina de operación de TI, y mucho menos en la operación de la seguridad. En general, un recién egresado sabe muy poco de marcos de referencia como ITIL o CoBIT, de lo que significan los acuerdos de niveles de servicio (SLA por sus siglas en inglés) y de las formas de implementar y brindar un servicio de TI para cumplir dichos niveles de servicio, por citar solo algunos ejemplos.
  3. La gran mayoría de los proveedores de hardware y software resaltan su tecnología y casi no mencionan los retos en su operación.
  4. Algunos ejecutivos del negocio siguen sin entender las ventajas de tener una operación de TI disciplinada y con altos niveles de servicio o, mejor dicho, no han entendido que para obtener altos niveles de servicio es necesaria una operación disciplinada y que eso significa –entre otras cosas- que todos los involucrados (incluso ellos, los altos ejecutivos) deben cumplir las reglas. Por ejemplo, la ejecución de un cambio en una infraestructura crítica puede no ser viable en el momento en que el alto ejecutivo lo ordena, sino hasta después de planear adecuadamente una ventana de mantenimiento. Por cierto, pienso que la responsabilidad de educar a estos ejecutivos está en el director de sistemas o el CIO (chief information officer).

Pese a los sesgos tecnológicos mencionados, en honor a la verdad, un gran número de áreas de TI ya están esforzándose por operar bajo un marco de mejores prácticas. Así, podría dividirse a los departamentos de TI en tres grandes grupos:

  • Los inconscientes o inmaduros. En este grupo están aquellas personas que no conocen de mejores prácticas como ITIL o, aun a sabiendas de su existencia, simplemente no han tomado conciencia de lo que representan y no les importa. Estas personas solo se orientan a tener la mejor tecnología, pensando que su operación es una función de la gente más técnica, y creen que no están obligados a seguir procesos, procedimientos ni políticas.
  • Los semiconscientes o madurando. Aquí se agrupan aquellas personas que conocen ITIL (incluso podrían estar certificadas en el nivel inicial), ISO-20000 u otro marco de referencia similar y que están intentando poner en práctica uno o más de los procesos recomendados.
  • Los conscientes y maduros. En esta clasificación estarían las poquísimas personas que no solo dominan ITIL o ISO-20000, sino que los aplican con éxito en cada uno de los procesos, incluso para administrar y monitorear su seguridad. De hecho, esa conciencia les ha permitido darse cuenta de que hay ciertos procesos, como el monitoreo y manejo de incidentes de seguridad, que no están muy “aterrizados” en estos marcos, y han trabajado para corregir estas deficiencias.

De  acuerdo con la clasificación anterior, ¿cómo anda su conciencia en la disciplina de manejo y operación de TI, y en la administración y operación de la seguridad?

Si usted contestó que pertenece a la clasificación “C” (conscientes y maduros), lo invito y lo reto a seguir leyendo y a confirmarlo o modificarlo pues, créame, he visto muy pocas organizaciones que califiquen para el nivel “C” en la parte de seguridad, y me ha tocado visitar muchas. Aun si están certificados en ISO-20000, es probable que sus procesos de seguridad no estén completos.

Entonces ¿Qué significa que tenga una operación y gestión de la seguridad de acuerdo a mejores prácticas? Sin querer ser exhaustivos, voy a mencionar algunos de los procesos más importantes que se deberían tomar en cuenta. Si usted ha implementado exitosamente todos o casi todos los procesos listados a continuación, puede jactarse de que trabaja en una organización consciente y madura en temas de seguridad.

.

Administración de riesgos

Recordemos que un riesgo es la probabilidad de que una amenaza (factor externo) explote una vulnerabilidad (factor interno) en alguno de nuestros sistemas e impacte en la organización. De esta forma, la administración de riesgos es el proceso continuo que permite analizar o conocer esos riesgos (por tanto tener evaluadas las amenazas y las vulnerabilidades), priorizarlos de acuerdo a algún criterio, definir qué controles se aplicarán para su mitigación o, incluso, si no serán mitigadas y serán riesgos no cubiertos por alguna razón, aplicar esos controles, monitorear su cumplimiento y repetir el análisis de manera periódica.

Este es, en mi opinión, el proceso más difícil de implementar y mencionaré  algunas de las razones para ello. Por un lado, para que funcione debe estar patrocinado por los altos ejecutivos de la organización. Idealmente esos mismos ejecutivos deben estar reunidos para ir estableciendo estrategias de mitigación y aprobar los recursos asociados con la implementación de medidas de seguridad (controles). Lo que comúnmente encontramos es que no se cuenta con este proceso, o se le asignó a un auditor sin mucha voz ni voto en la empresa, o los ejecutivos no entienden bien de riesgos informáticos y por lo tanto no dirigen los recursos hacia las medidas de seguridad más efectivas.

Otro error común es solo analizar los riesgos en forma anual o semestral, pero no como un proceso completo y continuo (evaluación, priorización, determinación de controles, implantación y supervisión de controles). Y quizás el error más grave es únicamente enfocar los riesgos hacia vulnerabilidades tecnológicas, suponiendo que hablar de “riesgos en nuestros sistemas” solo se refiere al hardware y al software, sin  considerar a las personas y sus procesos de trabajo.

.

Administración de las vulnerabilidades

En realidad este proceso debe estar inmerso en uno más global de administración de riesgos. El proceso suele iniciar con un análisis de vulnerabilidades en los sistemas, sin olvidar que cuando hablamos de sistemas nos referimos a todos los elementos tecnológicos, humanos y de procesos de trabajo. El análisis generalmente incluye una relación de las vulnerabilidades encontradas, así como las formas para corregirlas o remediarlas.

Con base en lo anterior, a partir de algún criterio establecido, se priorizan las vulnerabilidades y se estructura un plan de acción que incluye tiempos, responsables y medidas para remediarlas. Después se lleva a cabo el plan de remediación y se vigila su cumplimiento. Por cierto, este tema es tan importante y conformado por tantos detalles, que bien vale la pena un artículo dedicado enteramente a él. Por lo pronto vale la pena comentar que, sobre todo en la  parte técnica, es un proceso que se relaciona con otros, como la administración de cambios y configuraciones que es típico que involucre a varias personas y responsabilidades; además, para automatizarlo debe caminarse con pies de plomo y ser paciente, pues hay relativamente pocas herramientas que ayuden a la automatización y existe un riesgo muy alto de que “le salga más caro el caldo que las albóndigas”.

En resumen, el objetivo más relevante de este proceso es garantizar que en todo momento entendemos dónde están las vulnerabilidades de nuestros sistemas y estamos tomando acciones para remediar o resolver la situación, de acuerdo a la priorización de dichas vulnerabilidades y conforme a las políticas, procesos y procedimientos de la organización.

Cuando realizamos un análisis de vulnerabilidades, un escaneo o, incluso, una prueba de hackeo ético, contribuimos a una parte fundamental del proceso (la evaluación de las vulnerabilidades) pero no quiere decir que ya implementamos todo el proceso. De forma similar, si después de ejecutar un escaneo decidimos aplicar un plan de remediación a un grupo de servidores, pero no lo hacemos como un proceso continuo y no abarcamos vulnerabilidades en otras partes de la infraestructura, ni consideramos las vulnerabilidades en la gente y los procesos, entonces no podemos hablar de un proceso completo.

.

Administración de cambios y configuraciones

Sin abundar demasiado en estos dos procesos, pues se han discutido en artículos previos de Magazcitum y son más conocidos por el personal de sistemas, su objetivo general es que toda la infraestructura se configure de manera adecuada y que los cambios que se efectúen a dichas configuraciones sean necesarios, planeados y no provoquen ninguna degradación de los servicios.

A pesar de que muchas personas saben de los beneficios de implementar estos procesos, las urgencias y el sesgo técnico hacen que frecuentemente el personal de seguridad “se los salte”.

.

Monitoreo de la seguridad

El objetivo de este grupo de actividades es revisar en forma continua, las 24 horas del día y durante todo el año, la información relevante de seguridad para determinar si un evento es un incidente de seguridad y disparar el proceso correspondiente. En este caso dicha información puede estar en:

  • Las consolas de los firewalls, IPS, filtros de contenido Web y correo.
  • Los eventos de las bitácoras de diversos servidores, sistemas operativos, bases de datos y aplicativos.
  • Cualquier otro tipo de evento o alerta relevante.

Uno de los grandes retos para implementar con éxito este proceso es encontrar ágilmente, sin tener un ejército de personas involucradas, los eventos más importantes dentro de un cúmulo de miles o millones de ellos, que –además- proceden de distintas fuentes de información. Por ejemplo, ¿cómo un especialista en seguridad puede hallar un evento relevante si tiene que revisar las bitácoras de dos firewalls, cinco IPS  y varios ruteadores, que suman entre todos más de 500 mil eventos diarios?

Una tecnología que ayuda en esta tarea es la correlación de eventos, llamada SIEM (del inglés security information and event management), que permite revisar en línea miles de eventos de distintas fuentes y señalar aquellos que cumplen con ciertas reglas específicas (reglas de correlación). Arcsight de HP o Sentinel de Novell son dos ejemplos de este tipo de herramientas.

.

Administración de bitácoras

Este proceso es similar al anterior, pues también se trata de revisar diversas bitácoras de eventos, pero en este caso se almacenan y, mediante un proceso posterior (offline), se generan reportes de aquellos eventos que representan alguna anomalía o no cumplen con cierta regla o patrón. El proceso debe incluir no solo la obtención de esos reportes sino también la activación de las acciones respectivas.

Manejo de incidentes de seguridad

El objetivo principal de este proceso es responder oportunamente a los distintos incidentes que afectan o pueden afectar la seguridad de una organización; por lo general es disparado desde el monitoreo de seguridad o la administración de bitácoras e incluye –entre otras tareas- la tipificación del incidente, contención, recuperación del servicio, investigación, erradicación y las lecciones aprendidas.

.

Administración de la identidad y acceso de los usuarios

Aunque puede ser muy amplio, de forma mínima contempla el manejo de la identidad y de los derechos de acceso de los usuarios en las aplicaciones, datos y recursos del sistema durante el ciclo de vida de estos usuarios en la organización. Debe contestar a la pregunta ¿Quién es este usuario y a qué tiene derecho?

.

Desarrollo de aplicaciones seguras

Aunque este tema es extenso y ha sido abordado en otros artículos de Magazcitum, solo permítanme recordarles que en la medida en que una organización no está desarrollando aplicaciones seguras, no está atacando el problema desde su origen.

Hacer pruebas de penetración a las aplicaciones o usar un analizador de código para detectar vulnerabilidades (como OunceLabs de IBM o Fortify de HP) son controles muy útiles para mejorar la seguridad de las aplicaciones, pero un proceso completo abarca prácticas de seguridad en todo el ciclo de vida del desarrollo de software, desde el análisis de requerimientos hasta la liberación final, pasando por el diseño, desarrollo y pruebas. Les recomiendo leer los libros de Gary McGraw y empezar a usar el marco de referencia que este autor expone, denominado “los 7 puntos de encuentro” (touchpoints).

.

Programa de educación y conciencia en seguridad

Adicionalmente a todos los procesos anteriores, si nuestra meta es administrar en forma integral la seguridad debemos implementar un programa de conciencia y educación en seguridad informática.

Generalmente el programa de conciencia, llamado en inglés “awareness program”, observa un enfoque más mercadológico: las sesiones a los usuarios son muy genéricas y se incluyen campañas continuas a través del correo electrónico, protectores de pantalla, pósters, trípticos, etcétera. En dichas campañas se refuerzan mensajes cortos y muy dirigidos; por ejemplo un mensaje típico es “tus contraseñas son como el cepillo de dientes: personales, no se prestan, y se cambian cada dos meses”.

Por otro lado, un programa de educación en seguridad informática suele ser un poco más profundo y se complementa con el conocimiento y difusión de las políticas y procedimientos de seguridad de la organización. Típicamente comprende un curso de medio día o día completo, semestral o anual, o antes si sucede algún cambio en las políticas o se determina algún nuevo riesgo que lo amerite.

Ahora sí le vuelvo a preguntar ¿En qué nivel de madurez califica a su organización? Si cumple con todos los procesos de seguridad comentados, cuenta con un programa de educación y conciencia de seguridad para los usuarios, es periódico y hay evidencias de su ejecución, entonces lo felicito pues de verdad está en una empresa en la que existe plena conciencia de la seguridad. Si no es así, espero entonces que esta primera parte del artículo le haya brindado algunas ideas sobre qué tipo de procesos debería implementar y, sobre todo, la motivación para hacerlo, internamente o con apoyo de terceros. En este último caso, creo que la siguiente parte del artículo le va a ayudar a recorrer el camino hacia una verdadera administración de la seguridad.

Hasta pronto. Que tenga un excelente 2013.

[email protected]

.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.