A estas alturas empieza a ser difícil encontrarse con una organización que no quiera invertir tiempo y esfuerzo en la seguridad. Aunque queda camino por recorrer, poco a poco la madurez en la seguridad está evolucionando desde el “si no falla ni nos han entrado, no pasa nada” al “debemos controlar el riesgo“, de modo que ha habido una migración en los últimos años en cuanto al foco de la seguridad. Ésta ya no se centra sólo en la disponibilidad de los servicios, sino también en la integridad de los mismos; las diferentes normativas que se han elaborado en estos años, como la LOPD o el Esquema Nacional de Seguridad ha ayudado mucho a que la seguridad esté cada vez mas presente en todas las organizaciones. Conceptos como “correlación”, “IPS”, “consola de gestión” o “monitorización” son cada día más conocidos y ya no suenan a jerga especializada.

Sin embargo, a pesar de esta mejora la seguridad sigue siendo vista no como un aspecto que debe envolver todos los demás, según una perspectiva holística, sino como otro elemento más en nuestra infraestructura de red (el firewall, un router, la VPN) o como una auditoría que nos revela fallos que solventamos. Es decir, como un elemento o acción puntual y aislada que nos permite incrementar nuestra seguridad o a veces tan sólo la percepción de seguridad. Existen varios efectos colaterales de esta manera “compartimentada” de abordar la seguridad, que les indico a continuación:

• Los beneficios del proyecto no se trasladan de manera efectiva a la organización, sino que se limitan a aquel departamento que ha promovido la iniciativa. No resulta nada raro que una organización decida abordar una auditoría 27002 pero el resultado efectivo sea la mejora de aquella parte de la seguridad de la que el departamento promotor es responsable, generalmente IT, por una simple cuestión de autoridad y competencias.
• Las implantaciones de nuevos sistemas, productos o elementos se quedan “cojas”, introduciendo incluso nuevos problemas de seguridad; un concentrador VPN es mucho más que un elemento de red que nos permite acceder remotamente a la organización: requiere procedimientos de alta y baja de usuarios, revisión periódica de usuarios, actualizaciones, políticas de utilización acceso remoto (y teletrabajo si es una de sus funciones), etc.
• El propio enfoque de la seguridad, unido a que se trata en muchos casos de iniciativas o proyectos “departamentales” e incluso en ocasiones casi personales, hace que no sea nada raro que el conocimiento y la experiencia que se deriva de estas iniciativas quede “atrapado” en el personal implicado en el proyecto. De este modo, no se incorporan al know-how de la organización, y se limita su utilización en posteriores iniciativas.

Aunque los tres efectos indicados son igualmente perniciosos, me gustaría incidir un poco más en el último. Si las lecciones aprendidas quedan dentro de las “cabezas pensantes” del personal de comunicaciones, el personal de sistemas, o tan sólo el responsable de IT, y no se traducen en documentos y acciones formales o incluso informales, no se tarda mucho en convertirse en departamentos reactivos, incapaces de responder de forma coordinada y sobre todo, anticipada y preventiva. Por utilizar una expresión que seguro que muchos conocen, el resultado es que nos limitamos a apagar fuegos. Claro que más de uno pensará: ¿Cómo demonios me voy a poner a pensar en detectores de humo cuando tengo una habitación llena de fuego? Pues haciendo que los cambios en la manera de trabajar se introduzcan de forma gradual, poco a poco. Es fantasioso pretender que elaborar procedimientos, documentación o introducir algo de necesaria burocracia en el día a día no vaya a afectar a nuestra manera de trabajar, tanto en la carga de trabajo que implica su elaboración e implantación, como en el rechazo que mostramos ante cualquier cambio de rutina, aunque su consecuencia sea positivo.

La cuestión, al final, radica en garantizar que el aprendizaje diario permanezca en la organización y no en la cabeza de esta o aquella persona, ya sea a través de procedimientos formales o informales, que permitan cumplir con la legalidad, retener el conocimiento, y que deben ser aplicables en el día a día de la organización. Esto en ocasiones puede entrar en conflicto con una mala concepción de la “imprescindibilidad” que algunas personas tienen, pero sólo de esta manera seremos capaces de transmitir el conocimiento de las personas a la organización, evitando caer en pequeñas parcelas de conocimiento y de poder, que sólo obstaculizan el normal funcionamiento de la empresa.

(Entrada elaborada en colaboración con Manuel Benet)

Nos despedimos de esta semana con un post de Pedro Quirós acerca de seguridad en SCADA, tan de moda estos días gracias a Stuxnet y a los medios de comunicación generalistas. Que pasen un buen fin de semana y vengan todos con las pilas recargadas para los últimos días previos al puente (sobre todo aquellos que no lo tengan ;)

A día de hoy hay pocos procesos productivos que no tengan una alta dependencia del ámbito TIC. Si bien en muchas organizaciones el número de usuarios de oficina es relativamente bajo y la complejidad es muy reducida, muchas veces disponen de entornos productivos con líneas de montaje que están controladas por equipos Scada. Estos equipos son auténticos ordenadores que controlan la operatividad y la eficiencia de las líneas de montaje o fabricación. Infraestructuras tan críticas con la nuclear, eléctrica, de alimentación, distribución de agua o de transporte usan entornos Scada a gran escala. Generalmente se consideran entornos seguros dado que suelen estar separados en áreas de la red diferenciadas, o incluso su propia subred. Muchos gestores las consideran “redes seguras” porque “no tienen acceso a internet”, además de considerarlos “entornos de bajo riesgo” dado que son entornos propietarios con un número muy limitado de expertos. Así que sus principales bazas eran el desconocimiento y el aislamiento.

Sin embargo no es necesario tener acceso directo a internet para presentar un problema, pues, como lamentablemente todos sabemos, hay otras muchas formas de infectar un equipo. En primer lugar, para un control de la producción en tiempo real, es necesario el envío de información desde cada uno de los equipos a un centro de control, que puede estar expuesto, con lo que exponemos a todo nuestro entorno productivo. Por otro lado no dejan de surgir ataques, especialmente virus como el ya famoso Stuxnet, que ataca directamente a entornos de producción en plataforma Siemens. El método de contagio es una simple llave USB, que a primera vista no representaba ninguna amenaza porque en entornos Microsoft no se detectaba ningún tipo de virus. Otros ataques típicos son el fingerprinting a través del puerto TCP 502, ataques a implementaciones ICCP, etc. Muchas veces estos entornos son especialmente vulnerables dado que los equipos de control utilizan sistemas operativos con soporte descontinuado, dado que “para el uso que se les da, no necesitan nada mas”. Este motivo explica por qué podemos encontrar PLCs que son auténticos agujeros de seguridad.

Es importante entender que un entorno SCADA no es un entorno seguro “per se”, requiere de la misma atención -o más- que un equipo de oficina, y que el simple aislamiento no resuelve la seguridad. La monitorización desde el punto de vista de la seguridad es indispensable. Ya es hora de empezar a contemplar estos equipos como una capa más en nuestra infraestructura dado que, como todos sabemos, una organización es tan segura como su eslabón mas débil. ¿Qué medidas habéis tomado en vuestras organizaciones?

Acaba de publicarse la noticia de que Microsoft dejará de actualizar la seguridad de los equipos con Windows XP y Service Pack 2 el próximo 13 de Julio, para actualizar únicamente las versiones mas modernas de este operativo. No han querido valorar cuántos equipos dejarán de estar actualizados, pero esta noticia revela la importancia de disponer de un repositorio centralizado para las actualizaciones de los equipos, y sobre todo de monitorizar que dichas actualizaciones se aplican correctamente.

En muchas organizaciones se siguen políticas centralizadas para la instalación de los parches del sistema operativo, para ciertas aplicaciones corporativas, para el uso de los antivirus corporativos con reglas restrictivas, para el uso de accesos externos a la empresa como VPN, etc. Sin embargo, no hay que dejar de lado que la mayor parte de las aplicaciones no permiten una actualización por políticas centralizadas, y que en la mayor parte de los entornos, un equipo suele tener instalados una infinidad de programas (necesarios) cuya actualización no es para nada sencilla, y que van mucho más allá del sistema operativo, Microsoft Office y el navegador. Tampoco conviene olvidar que la aplicación final de las actualizaciones suele depender del usuario, por varias razones.

En primer lugar, aunque las actualizaciones del SO se descarguen e incluso instalen de manera automática, el reinicio posterior que a menudo es necesario suele postergarse días o incluso semanas, porque esa es una de las cosas que al usuario más le molestan; tampoco es recomendable que dicho reinicio se fuerce, porque eso puede provocar algún que otro roce y problemas con personal interno. En segundo lugar, muchos usuarios evitan las actualizaciones de programas de adobe, o los propios navegadores, aunque son relativamente sencillas, ya sea por el consabido “si funciona no lo toques”, por simple pereza o por evitarse interrupciones “innecesarias”. En tercer lugar, tenemos aquellos programas que no proporcionan una actualización a través de una opción “Buscar actualizaciones”, sino todo lo más avisan de la existencia de ésta, tras lo cual es necesario ir a la página del producto en cuestión y volverlo a instalar; ni que decir tiene que si en las situaciones anteriores el usuario evita por todos los medios una actualización relativamente sencilla y transparente, en este caso las molestias son casi inconmensurables. En cualquier caso, hasta aquí el usuario tiene un medio, más o menos fiable, más o menos rápido, más o menos transparente, de actualizar sus aplicaciones y sistema operativo, y el que no lo hace es porque no quiere. Ahí es donde entran las herramientas de inventario automático y las campañas de concienciación y sensibilización de los departamentos de TI.

No obstante, hay un cuarto caso mucho más complicado que el resto, y cuya actualización puede suponer, justificadamente, un dolor de cabeza para usuarios experimentados. Este es el caso de algunas aplicaciones Open Source para Windows, con dependencias específicas de librerías, versiones de programas, entornos, etc. Es decir, básicamente lo que sucede en los entornos GNU/Linux, que han sabido solucionar a través de herramientas como APT, que se encargan de verificar las dependencias de librerias, programas, incompatibilidades, etc. Sin embargo, parece lógico que esto no existiese para Windows, por ser en teoría la antítesis de los entornos Open Source; aunque Microsoft proporciona la herramienta WSUS para la centralización de actualizaciones, lo cierto es que ésta se limita a sus propios programas y al sistema operativo, algo que resulta normal después de todo.

Afortunadamente, para eliminar o mitigar en lo posible este problema, Garret Serrack, desarrollador del departamento de código abierto de Microsoft, ha desarrollado CoApp, que viene a solucionar lo que nos puede suponer un gran quebradero de cabeza, proporcionando un sistema por paquetes similar al APT, pero para entornos Windows. La idea es facilitar la actualización de las aplicaciones de código abierto que tengamos instaladas, solucionando conflictos con múltiples versiones de librerías o 32/64 bits, e incluso ayudar a la actualización conjunta de programas y librerías. Si ustedes hacen un uso habitual de estas herramientas, vale la pena que le echen un ojo, seguro que les resultará interesante.

Como ven, a veces, la seguridad no depende de grandes proyectos, sino de pequeños pasos. Pasen un buen fin de semana, les vemos el lunes.