En numerosas ocasiones, cuando pensamos que estamos construyendo medidas de protección, realmente cometemos errores graves. No tanto porque las medidas sean perniciosas, sino porque puedan crear una falsa sensación de confianza.
Infosec ha publicado recientemente un artículo realmente sorprendente, al menos en su título: Worst practices developing security (Las peores prácticas en el desarrollo de seguridad). Lo que contiene en su interior no son instrucciones infalibles (bueno, habría que decir en este caso, absolutamente erróneas), ni una visión rompedora con planteamientos novedosos sobre lo que debe hacerse o no al plantear una protección en nuestros Sistemas de Información.
Pero lo que sí es destacable del artículo es que aporta un resumen bastante claro y concreto de cuales son los errores más frecuentes en Seguridad Lógica, que en numerosas ocasiones nos van a provocar fuertes dolores de cabeza y que, si somos capaces de preverlos, podríamos resolverlos con previsión y con un esfuerzo limitado.
Algunos de los errores que se tratan en el artículo son los siguientes:
Solo el software importante merece ser protegido. Añadiría que no solo el software, sino los sistemas en su conjunto. Este argumento es bastante frecuente, y sería razonable entender que debe haber mayor o menor criterio de protección del sistema, según sea más o menos crítica la información y la actividad a proteger. Pero en una red, y más aún en redes expuestas, la robustez de la red es la del eslabón más débil.
Priorizar el cumplimiento de plazos por encima de la calidad del sistema. Esto no es únicamente aplicable a la seguridad, sino que esta "calidad" cubre la estabilidad, la eficacia en el acceso a bases de datos, etcétera. En cuántas ocasiones se han multiplicado los errores, los problemas, la necesidad de corregir el sistema, las prisas y, como consecuencia, los costes, por culpa de una desacertada definición de prioridades. Y permitanme una pequeña puya. La responsabilidad no es únicamente del departamento de TI, sino de quienes tienen capacidad para aportar presión, quienes frecuentemente se fijan únicamente en el cumplimiento de plazos, lo cual tiene como consecuencia el sacrificio de otras características a esa prioridad máxima.
Dejar que las decisiones relativas a la gestión del riesgo las realice exclusivamente el departamento de Tecnologías de la Información. Si es cierto que la unidad de Sistemas aporta el soporte a la gestión del negocio, e incluso en muchos casos, la capacidad diferenciadora de una compañía respecto de su competencia, también es cierto que es una unidad que trabaja para el resto de la compañía, por lo que la gestión del riesgo debe ser tratada como un problema de toda la compañía.
Considerar la seguridad del sistema únicamente en el momento de la implantación. La seguridad debe formar parte de un sistema desde las etapas de diseño, de manera que podamos aportar los niveles de protección requeridos a lo largo de todo el proceso de desarrollo.
Asumir que no vamos a ser atacados. El artículo menciona que todos los sistemas van a ser atacados. No se si tanto, pero deberíamos considerar, al menos, que todos pueden ser atacados. Los de nuestras redes protegidas y, especialmente, los que se encuentran en redes expuestas.
Plantear la protección siguiendo el principio "a la seguridad por la oscuridad". Esto tiene dos aspectos. Uno es el hecho de ocultar nuestra presencia al conectarnos a Internet. Si los potenciales atacantes no perciben nuestra presencia, mejor para nosotros. Y si al intentar un acceso no revelamos el tipo de sistema que les atiende ni el sistema operativo, servidor web,... pues realmente nos evitaremos facilitar el trabajo a visitantes "no deseados". Pero a la hora de definir nuestros mecanismos de protección, y resulta meridianamente claro al hablar de cifrado, resulta más eficaz utilizar tecnologías públicas que inventar nuestras propias medidas. No solo por la calidad de la protección en sí misma, sino porque mostraremos justamente la robustez de nuestras medidas de protección. Evidentemente, para que esto funcione, debemos elegir las medidas adecuadas.
Como he mencionado más arriba, no se trata de descubrir recetas mágicas, aunque sí hay que reconocer al autor del informe, el mérito de realizar una buena compilación de recetas que, por encima de todo, deben empujarnos en el esfuerzo de reflexionar sobre la calidad de las medidas que tenemos desplegadas.
Eduardo Mendez
Marcadores