Conseguir que tus aplicaciones sean seguras (o al menos, intentarlo) 2

Si limitar las aplicaciones que tus usuarios pueden utilizar te parece divertido, posiblemente no hayas pensado en lo que se te viene encima. Ahora tienes un conjunto de aplicaciones en las que centrarte y te toca hacerlo. Para empezar, tendrás que monitorizar los problemas de seguridad que pudieran afectar a cada instalación particular que tengas de cada software.

¿De dónde pueden venir los problemas? Poca cosa:

• Vulnerabilidades del propio software.
• Dependencias. Por ejemplo: que el software sólo funcione con una versión obsoleta de Java o de Flash. O que utilice una librería a la que se han encontrado fallos, como el reciente problema de Imagemagick.
• Software mal configurado.
• Fallos del software que obliguen a utilizar una configuración insegura. Como que no funcione correctamente el uso de contraseñas a la hora de acceder a carpetas compartidas y haya que establecer en éstas permisos del tipo "acceso total para todo el mundo".
• Interrelaciones entre software que supongan merma para la seguridad. Por poner un caso: quizá nuestro software tenga que conectarse con un servicio web. Si éste no funciona sobre HTTPS, el uso de HTTP supondría el correspondiente riesgo de intercepción y/o modificación de peticiones y respuestas
• etc.

Pero si conocer dónde puede estar el problema es importante, no lo es menos enterarse de que existe. Y aquí también tenemos distintas opciones. Ten en cuenta que no son excluyentes entre sí, de modo que tienes que ir preparando unos cuantos canales. Entre ellos:

• Pruebas realizadas por tu organización: análisis de vulnerabilidades, tests de intrusión internos, etc.
• Repaso de logs que pudieran encontrar ataques, ya fueran estos exitosos o no.
• Información proporcionada por los distintos CERT.
• Boletines de seguridad de los desarrolladores.
• Repositorios de vulnerabilidades tipo CVE.
• Otras organizaciones y fuentes de información (blogs, foros,...) relacionadas con la seguridad de la información.
• Notificaciones por parte de profesionales de, y aficionados a, la seguridad que pudieran encontrar las vulnerabilidades. Dado que por este conducto puede llegarnos información muy cualificada (al menos, a veces) es muy importante cuidarlo y asegurarnos de que existan dos cosas y de que estén claras desde el principio:
• Un cauce para que estas personas puedan realizar las comunicaciones.
• Un marco en el que se deje claro qué se les permite y qué no hacer y cómo se va a tratar la información proporcionada.

A este respecto se me viene a la cabeza un antiguo artículo de Chema Alonso sobre la propuesta de un archivo "hackers.txt". Algo similar al "robots.txt", pero para gente de este mundillo.
 
Por no acabar este post sin poner otro par de listas, un elemento que puede complicarte la vida es lo variado de los tipos de software con los que puedes terminar trabajando. Una posible clasificación sería:

• Software libre, en distribuciones originales o modifados por terceros.
• Software libre modificado por tu organización. 
• Software hecho a medida, bien por tu organización o por terceros.
• Otro software propietario.

Dependiendo de en cuál puedas catalogar el sistema que presenta la vulnerabilidad, y de la naturaleza de ésta, tendrás una serie de opciones para corregir la situación:

• Modificar la configuración del software. Posiblemente estés deseando que sea esto lo que haya que hacer.
• Obtener una nueva versión del producto, o de las dependencias afectadas, y aplicarla. En este caso, la fuente de esta nueva versión podría ser:
• El desarrollador del software afectado. Esta solución suele ser la mejor pues ofrece mayores garantías de continuidad en el futuro. Téngase en cuenta que el resto de opciones puede suponer tener que seguir manteniendo el software en el futuro sin el soporte de su desarrollador, quizá con medios propios. Y medios no siempre sobran...
• Un tercero que ofrezca modificaciones del software (forks). En este caso, mejor que elijas algo fiable y con garantías de futuro.
• Una modificación o desarrollo propio. O una modificación o desarrollo contratada a un tercero. Ya sabes que ésta te seguirá dando qué hacer durante mucho tiempo...
• Plantearte la sustitución del producto afectado por otro que proporcione las mismas funcionalidades, pero que sea más seguro.

Tanto si obtienes una nueva versión y la aplicas como si cambias de software tendrás que actualizar la lista de software aprobado.

Eso, como se comentaba en el post anterior, tenía necesariamente su complejidad admistrativa. Pero no nos olvidemos de la parte técnica: ¿cómo elegir o, en su caso, desarrollar el software?