Mostrando entradas con la etiqueta vulnerabilidades. Mostrar todas las entradas
Mostrando entradas con la etiqueta vulnerabilidades. Mostrar todas las entradas

viernes, 30 de enero de 2015

Algunos "Quickwins" en seguridad de la información

En algunas organizaciones existe una fe ciega en que el mejor camino para mejorar la seguridad es gastar más y más dinero en hierro y licencias. Más firewalls, más IDS y el WAF más caro. Sin embargo, en este post me gustaría repasar tres actividades básicas para mejorar la seguridad de una organización, que no necesariamente requieren comprar ningún hardware o software adicional.



La primera de estas actividades es el bastionado de los sistemas. Bastionar o asegurar correctamente un sistema no es una tarea complicada. Existen multitud de guías específicas sobre cómo bastionar sistemas concretos, pero incluso realizando un bastionado básico se puede incrementar en gran medida la seguridad de una infraestructura sin tener que invertir un esfuerzo desmesurado en ello. Los pasos básicos a seguir para bastionar un sistema son:
  • Elimina o al menos deshabilita los servicios de red y los programas innecesarios, dejando únicamente habilitados aquellos que son necesarios para que el sistema desempeñe su labor. De esta manera se reduce drásticamente la superficie de exposición del sistema.
  • Revisa los usuarios existentes en el sistema, cambiando contraseñas por defecto y minimizando los permisos de cada usuario de manera que tengan los mínimos necesarios para desarrollar sus actividades.
  • Documenta los servicios de red necesarios y los puertos usados por cada uno de estos servicios. Esta documentación será de mucha utilidad para diseñar las reglas a implementar en los firewalls de red.
  • Mantén el sistema actualizado al último nivel de parches de seguridad publicados por el fabricante. Esta actividad es básica para prevenir que un atacante utilice vulnerabilidades conocidas para comprometer la seguridad del sistema.
  • Instala y mantén un firewall en el servidor (puede ser el propio firewall de Windows o un IPtables en el caso de linux) permitiendo únicamente el tráfico entrante y saliente que sea estrictamente necesario. Filtrar el tráfico entrante permite garantizar que aunque algún servicio no necesario se haya dejado habilitado por error, éste no será accesible desde la red. Filtrar el tráfico saliente puede permitir mitigar el impacto causado por una infección de malware que intente abrir conexiones salientes, y prevenir la fuga de datos usando conexiones de red a servicios que el servidor realmente no requiere.

Otra actividad básica a desarrollar es definir, implementar y mantener un programa de gestión de vulnerabilidades adecuado para la organización.

Si queremos gestionar las vulnerabilidades de nuestros sistemas, debemos seguir los siguientes pasos básicos para su correcta gestión: detectarlas, clasificarlas, priorizarlas, asignarlas, resolverlas y verificar su correcta resolución: 

  1. Detectar: Hay múltiples fuentes o vías que debemos usar para detectar las vulnerabilidades existentes en nuestros sistemas. Las más comunes serán los avisos de alerta temprana de CERTs o de los propios fabricantes, los resultados de los escaneos de vulnerabilidades periódicos que se deberían realizar sobre la infraestructura y las aplicaciones y los resultados de las pruebas de penetración que se realicen.
  2. Clasificar: Una vez detectada una vulnerabilidad, el siguiente paso a realizar debería ser clasificarla según el riesgo que suponga para nuestra organización. Para ello, se deberían considerar factores como el impacto que podría suponer, y la facilidad de explotación. Dado que la resolución de vulnerabilidades es un proceso que puede llevar días, semanas o incluso meses, aquellas vulnerabilidades que sean consideradas más críticas deberían ir acompañadas de un plan de acciones compensatorias para mitigar el riesgo que suponen hasta que sean definitivamente solventadas.
  3. Priorizar: Una vez clasificadas según su riesgo, deberán priorizarse. Estos es, definir un tiempo límite en el que cada vulnerabilidad debería estar resuelta. El estándar de seguridad en datos de tarjetas de pago PCI DSS propone un mes de tiempo límite para las vulnerabilidades más críticas y tres meses de tiempo límite para el resto. En cualquier caso, tanto los niveles de clasificación como los tiempos de resolución deberían adaptarse a la realidad de cada organización.
  4. Asignar: El siguiente paso es asignarlas. Es decir, determinar de quien es la responsabilidad de resolver cada una de las vulnerabilidades dentro del plazo correspondiente.
  5. Resolver: El responsable de resolver cada vulnerabilidad deberá encontrar la solución a la misma, seguir el proceso de la organización para la gestión de cambios, es decir, probarla adecuadamente para descartar cualquier impacto negativo derivado de ésta y proceder a su resolución.
  6. Verificar: Por último, se debe verificar que la solución resuelva la vulnerabilidad de manera eficaz.



Por último, quisiera hablar de la concienciación en seguridad de la información dirigida a los empleados y proveedores de la organización.


Más de una vez he oído a profesionales de seguridad argumentando que las acciones de concienciación no son efectivas y que por mucha concienciación que se realice, el factor humano seguirá siendo el principal riesgo de cualquier organización. Mi opinión al respecto es que la concienciación sí es efectiva e indispensable,  aunque no por ello suficiente. Dicho de otro modo, es cierto que concienciar al personal no elimina los riesgos de seguridad que provienen de errores humanos pero sin duda los mitiga y en todo caso evita que los usuarios puedan escudarse tras el desconocimiento al perpetrar ciertos tipos de acciones que comprometan la seguridad de los activos de información de la organización.


Por supuesto, existen más acciones que se pueden llevar a cabo sin una gran inversión económica para aumentar el nivel de seguridad de las organizaciones, como por ejemplo segmentar correctamente la red, establecer procesos de desarrollo seguro, de gestión de cambios, de respuesta ante incidentes, etc. Sin embargo, los tres propuestos considero que son una excelente base por la que empezar a mejorar la seguridad de nuestra organización.

jueves, 27 de noviembre de 2014

Sistemas Industriales: ¿Parchear o no parchear?


Muchas son las peculiaridades que deben tenerse en cuenta al considerar la seguridad de los sistemas industriales y los sistemas SCADA. Una especialmente relevante  es el parcheo o actualización de los sistemas o del software que éstos soportan. Cuando en una evaluación de la seguridad de este tipo de sistemas se llega a la pregunta: “¿Y cómo realizáis el mantenimiento de los sistemas para solventar las vulnerabilidades conocidas que hayan sido resueltas por el fabricante?” nos podemos encontrar con respuestas de lo más variado. Algunas posibilidades son:
Opción 1: Cara de póker
“- Nosotros no aplicamos parches de seguridad. No es necesario puesto que nuestra red industrial está totalmente aislada y de todas formas, la mayoría de los fabricantes que utilizamos no publican actualizaciones de seguridad. Por otro lado, en ocasiones la actualización del software implica también cambio de hardware, por lo que las restricciones presupuestarias no permiten aplicar dichas actualizaciones.”
Esta respuesta o respuesta similares es bastante común. Y no me parece una estrategia descabellada a seguir la de no aplicar parches de seguridad siempre y cuando se cumplan los siguientes condicionantes:
1.       Se realice un análisis de riesgos para comprender claramente cuáles son las amenazas que nos pueden afectar por el hecho de no parchear nuestros sistemas y qué impacto podrían suponer dichas amenazas en caso de materializarse. Téngase en cuenta que no me refiero a realizar un ejercicio superficial de análisis de riesgos, si no que me refiero a analizar los riesgos en profundidad. Es decir, conocer exactamente qué vulnerabilidades son las que no estoy parcheando, como podrían ser explotadas por un atacante y qué medidas compensatorias al parcheo estoy implementando en mi infraestructura para paliar estos riesgos. A la hora de considerar las amenazas se debe prestar especial atención al perímetro de los sistemas industriales, los puntos de interactuación con las redes tradicionales y los puntos de acceso que son fácilmente accesibles por visitantes o por el público en general.

2.       Una vez realizado dicho análisis de riesgos, se vea que los problemas, costes o dificultades derivados de aplicar los parches sean superiores al riesgo que se mitigaría en caso de parchear.

3.       Que esta decisión sea llevada a cabo de forma informada y consciente por el propietario del riesgo,  es decir, por el responsable del proceso de negocio que sufriría las consecuencias en caso de que estos riesgos se materializaran.
Por otro lado, está claro que hay que presionar a los fabricantes para que implementen procesos de gestión de las vulnerabilidades de sus productos y la calidad de los mismos debería ser un criterio clave en la selección de este tipo de tecnologías para que este problema no se perpetúe en el tiempo.

Opción 2: El hombre tranquilo
“- Pues depende del fabricante, del dispositivo, y del técnico que se encargue de la actualización. No lo tenemos realmente documentado, pero usamos métodos diversos como la descarga directa desde la página web del fabricante de los ficheros de actualización (quien por cierto no publica un hash del fichero para verificarlo tras su descarga, y si lo publica no lo verificamos). A veces, para ganar tiempo incluso lo descargamos desde nuestra propia casa dónde el ancho de banda es mayor que en la oficina. Lo grabamos en nuestro USB y lo conectamos a la red de sistemas industriales que está totalmente aislada de la red de IT. Otras veces, es un partner o el propio fabricante quien viene con su USB o con sus portátiles y se conectan directamente a nuestra red industrial para aplicar las actualizaciones o realizar cualquier otro tipo de intervención.”

En estos casos, como podéis imaginar, el problema radica en que el ‘aislamiento’ deja de ser tal cuando el USB, el portátil o el CD de turno se conecta a nuestra red aislada. Algunas amenazas a las que se exponemos nuestros sistemas con éstas prácticas son:
·         Malware que pueda causar problemas de rendimiento o incluso una denegación de servicio en estos equipos.
·         Malware avanzado capaz incluso de permitir el control remoto o el robo de datos. Aunque a priori esto parece imposible en una red aislada, en la actualidad podemos encontrar numerosas pruebas de concepto sobre cómo se podrían realizar estos ataques sorteando el ‘Air GAP’.
·         Actualizaciones fraudulentas descargadas de internet cuyo funcionamiento será diferente al esperado.
·         Terceros que se conectan a nuestra red utilizando sus propios sistemas que pueden tener un nivel de seguridad inferior al nuestro. Además, si no controlamos qué actividades realizan en nuestros sistemas pueden ser una fuente de amenaza a tener en cuenta. No olvidemos que es muy probable que nuestros partners trabajen también para nuestra competencia directa, por lo que es una fuente de riesgo a tener en cuenta.

Opción 3: El precavido
“En nuestra organización disponemos de procesos documentados y seguros para llevar a cabo la actualización de todos nuestros sistemas industriales. Tenemos diversos sistemas para estar informados de cualquier nueva vulnerabilidad que se descubra que puede afectar a nuestros sistemas. Realizamos un análisis comparativo de los riesgos que supone llevar a cabo la actualización comparándolos con los que supone dejar los sistemas sin parchear, de manera que el propietario del proceso puede establecer el criterio a seguir para tomar la decisión de si se debe parchear y en qué plazo debe hacerse. Una vez decidimos que un parche debe aplicarse, lo obtenemos de una fuente segura verificando su integridad y autenticidad, lo desplegamos en nuestros entornos de prueba para verificar que la actualización no comprometerá la funcionalidad ni la seguridad de los sistemas y, sólo después de esto, y bajo nuestro estricto control y supervisión, la actualización se despliega en producción dentro del plazo establecido por el propietario del proceso.”

Pues si te vienen con estas, poco vas a tener que decir salvo asentir y felicitar al cliente. Sin embargo, hasta el momento no me he encontrado con el caso, aunque no pierdo la esperanza…
En conclusión, los procesos de gestión de vulnerabilidades son un aspecto crítico a considerar en cualquier evaluación de seguridad que se realice, pero especialmente si lo que estamos evaluando son sistemas industriales y/o sistemas SCADA. No actualizar significa acumular vulnerabilidades, mientras que el proceso de actualizar puede ser en sí mismo una amenaza si no se realiza de manera adecuada. Por lo tanto, planificar, documentar y establecer un ciclo de mejora continua sobre los procesos de gestión de vulnerabilidades debería estar en la agenda de cualquier responsable de seguridad que pretenda mejorar la protección de su organización.