La Seguridad de la Información en el desarrollo

Es complicado trabajar en el mundo de la seguridad. Estaba pensando emplear la palabra “duro”, en lugar de complicado, pero para ser justos creo que debemos dejar ese tipo de términos para otros trabajos que son “realmente duros”. Lo dejaremos simplemente en complicado.

Normalmente, los que nos dedicamos a estos menesteres, trabajamos para evitar que las cosas sucedan. Somos trabajadores incansables y silenciosos. Lo mejor es que se sepa que estamos pero que no se note. Este suele ser nuestro trabajo, pero digo suele porque no en todas las disciplinas nos ocurre lo mismo, como luego comentaremos. En los sistemas en explotación distribuimos sensores para enterarnos de las cosas, bastionamos equipos, configuramos redes y sistemas, diseñamos arquitecturas seguras, dibujamos nuestras trampas en las redes para que los “malos” caigan en nuestras redes y podamos “pillarlos con las manos en la masa”, compramos y ponemos hardware y software específico para levantar murallas virtuales (más feas que las de Carcassonne —véanlo ustedes mismos en la imagen adjunta— pero murallas al fin y al cabo). Todo con el fin último de defender nuestros bienes más preciados: nuestra información, nuestro conocimiento.

Trabajar para que no pase nada solía ser muy difícil de justificar, por no decir imposible, pero la verdad es que, poco a poco, directivos y empresarios, se van concienciando de que la Seguridad de la Información es una de esas actividades necesarias para proteger el patrimonio de las organizaciones de todo el mundo sea cual sea su actividad y tamaño y que no requiere un ROI (*) o un ROSI que lo justifique. Por decirlo de otra forma, son parte del peaje que debemos pagar por el uso que hacemos de la tecnología.

Ahora creo que toca empezar por el principio para evitar situaciones como las que nos encontramos con cierta frecuencia a la hora de hacer auditorías. Nos gusta hacer nuestro trabajo y aportar soluciones, pero en el caso de las auditorías de aplicaciones, en ocasiones, resulta muy complicado. ¿Por qué? Creo que la respuesta general la debemos buscar en la forma de afrontar el inicio del ciclo de desarrollo de las mismas. Cuando iniciamos un proyecto lo que creo que queda claro, o al menos debería quedar claro, es la funcionalidad que se desea conseguir, ¿qué es lo que queremos hacer? Desgraciadamente no es muy habitual que en el equipo de desarrollo de estos proyectos o aplicaciones intervengan equipos independientes o profesionales independientes especializados capaces de diseñar, a partir de unos requisitos funcionales, los Requisitos de Seguridad de la Información en todos sus frentes: seguridad organizativa, física, lógica y legal.

El resultado en bastantes casos es el que sufrimos cuando se nos solicita que llevemos a cabo una auditoría contra redes, sistemas y aplicaciones de una organización. En ese momento nuestro trabajo ya es reactivo y la capacidad para la acción de nuestro cliente suele ser, desgraciadamente, baja. La situación con la que nos encontramos es desalentadora para nuestro equipo, ya que planteamos un problema a nuestro cliente y sabemos de antemano que la solución, en el caso de detectar una vulnerabilidad grave en una aplicación, es difícil, costosa y a veces inviable a corto o medio plazo.

Nuestro equipo de seguridad “reclama”, en el buen sentido del término, la oportunidad para trabajar donde nuestro trabajo es más creativo, donde podemos aportar para evitar que lleguemos a situaciones como las descritas, donde en definitiva somos capaces de aportar más valor a nuestros clientes, ya que de eso se trata, ¿no?

Sirva este pequeño post como introducción de una nueva sección en el Blog de Seguridad de S2 Grupo. Una sección en la que llevamos ya algún tiempo trabajando y que podríamos denominar “Seguridad de la Información en el Desarrollo” (el nombre de la categoría tendrá que ser algo más breve). Una sección en la que nuestro equipo de de seguridad y desarrollo, dirigido en esta ocasión por nuestro Director de Desarrollo, Daniel de los Reyes, nos contará sus vivencias e impresiones sobre estos temas.

(*) ¿Acaso requiere el cálculo de un ROI la decisión de implantación de un ERP en una organización? Sin entrar a valorar qué ERP, en mi opinión la inversión está sobradamente justificada. Lo que sí deberemos analizar es el ERP que implantamos pero no si lo necesitamos o no.

Comments

  1. En efecto Pepe, lo que describes es cierto. No recuerdo ningún cliente pidiendo que el producto a desarrollarle cumpliese la ley tal o cual, o un nivel de seguridad determinado, en unos casos porque no conocen los riesgos y en otros porque prefieren no añadir costes a los presupuestos limitados con los que trabajan. El “despues ya veremos” es muy frecuente pero muy costoso.

  2. Yo lo solía llamar Ciclo de Desarrollo Seguro, que era algo así como incluir procesos de seguridad dentro del Ciclo de vida tradicional que la Ingeniería del Software nos ofrece. La conclusión principal era que el Desarrollo Seguro dismunía riesgos, ayudaba a obtener unos requisitos más completos y proporcionaba mayor calidad al producto final, toda una serie de beneficios importante por un “pequeño” gasto más.

    Enhorabuena por el blog.

    Salu2

  3. El post da de lleno en gran parte del alto precio que por (IN)seguridad se está pagando a día de hoy. Muchos de los vectores de ataque se basan en la ausencia de control sobre la información de entrada a la aplicación.

    En el post http://seguridad-de-la-informacion.blogspot.com/2008/06/publicada-la-iso-270052008.html quise destacar un cambio en el planteamiento que empiezan a hacer desde la Administración a la hora de exigir seguridad.

    “La legislación suele pecar de ambigua a la hora de hablar de seguridad. En general se venía diciendo que los procesos telemáticos deben garantizar la disponibilidad, integridad y confidencialidad de la información, sin establecer mínimos (A excepción de la legislación en materia de protección de datos de carácter personal que lo regula vía reglamentaria). Como mucho aparece que las medidas de seguridad serán proporcionales a los “riesgos y el estado de la tecnología”.

    Pues bien, he hallado una nueva redacción a estos requisitos en la Orden PRE/1551/2003, de 10 de junio, por la que se desarrolla la disposición final primera del Real Decreto 209/2003, de 21 de febrero, por el que se regulan los registros y las notificaciones telemáticas, así como la utilización de medios telemáticos para la sustitución de la aportación de certificados por los ciudadanos y en la ORDEN PRE/3949/2006, de 26 de diciembre,por la que se establece la configuración, características, requisitos y procedimientos de acceso al Sistema de Verificación de Datos de Identidad donde para determinar la seguridad de la información necesaria aparece el siguiente texto:

    Adopción de las medidas de seguridad, organizativas o técnicas, de los dispositivos y aplicaciones de registro, notificación y de la prestación del servicio de dirección electrónica única.

    1. Con carácter general se aplicarán a los dispositivos y aplicaciones de registro, notificación y de la prestación del servicio de dirección electrónica única las medidas de seguridad, conservación y normalización que se detallan en los Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades aprobados por el Consejo Superior de Informática y para el impulso de la Administración Electrónica y accesibles en su sitio web.

    Dichas medidas de seguridad, conservación y normalización vendrán determinadas por el resultado del análisis y gestión de riesgos que se realice, recomendándose a estos efectos la utilización de la metodología Magerit.

    Lo triste es que como otros de los requisitos formales que exigen algunas regulaciones, será saltada a la torera.

  4. En efecto, tener en cuenta todos los aspectos de seguridad pertinentes, en todas las fases del desarrollo de software, en vez de hacerlo sólo al final, es la mejor vía para reducir fallos de seguridad. Hay un libro titulado “Geekonomics: The Real Cost of Insecure Software” que nos explica las verdaderas consecuencias de realizar software como se hace en la mayoría de empresas del sector.

    Felicidades por el blog, de los mejores que he encontrado últimamente. Un saludo