La entrada en vigor de la nueva regulación europea de Protección de Datos, GDPR, va a suponer un antes y un después en la forma en la que las empresas han venido entendiendo los aspectos relacionados con su seguridad. Esta norma va mucho más allá de marcar unos parámetros de protección de la información que manejan empresas y organismos para llevar a cabo su actividad, sino que supone la aparición de un verdadero espacio común europeo de ciberseguridad.
Así, la GDPR viene a poner orden en un escenario en el que cada organización actuaba de acuerdo a sus intereses, recursos o conocimientos. A partir del próximo 25 de mayo esto ya no vale. Ahora, las empresas tendrán que poner a la seguridad en lo más alto de sus prioridades, alcanzando un nivel mínimo común para todas ellas.
Como consecuencia de la GDPR, las empresas tienen que evaluar el riesgo de ciberseguridad para poder protegerse convenientemente de unas amenazas cada vez más numerosas y sofisticadas. Lo que no dice la norma es lo que cada organización debe hacer para conseguir cumplirla. Es así cómo llegan la incertidumbre y la confusión a una multitud de compañías y organismos que no disponen de los conocimientos y el criterio necesarios para tener la certeza de si las medidas que están tomando son adecuadas, y que se sienten perdidas ante la gran variedad de propuestas de prevención de vulnerabilidades que encuentran en el mercado.
Ante este panorama, no debe cundir el pánico. Como casi siempre en esta vida, lo más conveniente suele ser empezar por el principio.
Cómo hacer las cosas bien desde el principio
Según datos del National Institute for Standard and Technology (NIST), el 92% de las vulnerabilidades están en el software. Según SAP, el 84% de los ciberataques se centran en la capa de aplicación. Según BlackDuck, el 67% de las aplicaciones contienen vulnerabilidades de código abierto… Estos son solo algunos datos que podemos encontrar haciendo una sencilla búsqueda en Internet. La búsqueda puede ser todo lo exhaustiva que queramos, pero siempre va a apuntar en la misma dirección: nuestros negocios dependen cada vez más de las aplicaciones; las aplicaciones se han convertido en la puerta de entrada preferida de los hackers; como consecuencia, deberíamos centrarnos en desarrollar aplicaciones seguras. Ese puede ser un buen punto de partida.
Por lo tanto, a la hora de plantearnos cumplir con la GDPR y de garantizar la seguridad de la organización, el primer factor que deberíamos afrontar es saber si estamos construyendo un software seguro, pero ¿Cómo se hace esto?
Al abordar el desarrollo de nuestras tecnologías, ya sea internamente o encargándole el trabajo a un proveedor externo, es necesario que el factor seguridad se tenga en cuenta desde las primeras fases del proceso, desde el establecimiento de los requisitos. No solo ocupándonos de definir correctamente los requisitos funcionales, es decir, lo que tiene que hacer la aplicación, sino definiendo también los requisitos de seguridad.
A partir de este momento, si se quieren hacer las cosas bien para cumplir con la GDPR, el factor seguridad deberá tenerse en cuenta en cada una de las fases de desarrollo de las aplicaciones, identificando y corrigiendo vulnerabilidades de forma continua y a lo largo de todo el proceso de producción del software. Ya no vale desarrollar primero la aplicación y luego probarla.
Lo mejor para poder garantizar la seguridad integral de las aplicaciones, que es tanto como garantizar la seguridad del negocio, es implantar un Ciclo de Vida de Desarrollo Software Seguro (SSDLC – Secure SW Developpment Life Cycle), empleando herramientas eficaces de prevención de vulnerabilidades a lo largo de todo el proceso de desarrollo de la aplicación que ayuden a los equipos de desarrollo y seguridad a identificar y mitigar vulnerabilidades asociados al código abierto de todo el portfolio de aplicaciones de la organización.
Ciclo de Vida de Desarrollo Software Seguro
A la hora de producir software seguro, es conveniente que cada organización aborde la implantación de un Ciclo de Vida de Desarrollo Software Seguro (SSDLC), que ayudará a la prevención de vulnerabilidades, identificándolas y corrigiéndolas a medida que se vaya especificando, diseñando y programando la aplicación.
Así conseguiremos un software mucho más seguro que si solamente se aplican pruebas de seguridad (penetration testing) al final del ciclo de desarrollo. Además de ayudarnos con el cumplimento de la GPDR, esta aproximación permite alcanzar una serie de beneficios, como es la reducción drástica de costes de desarrollo y mantenimiento.
En un Soporte Seguro al Ciclo de Vida de Desarrollo Software estándar se tienen en cuenta:
- Actividades de desarrollo SW seguro recomendadas: análisis de riesgos, elaboración de requisitos de seguridad, diseño SW empleando librerías de terceros seguras, revisiones de requisitos, diseño y código, pruebas dinámicas de penetración y protección en tiempo real de los sistemas de explotación.
- Mejores prácticas de aplicación producida por OWASP: ASVS (Application Security Verification Standard) y Testing Guide.
- Herramientas comerciales y Open Source que cubran las tres aproximaciones a las pruebas de seguridad SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing) e IAST (Interactive Application Security Testing).
La implantación de un SSDLC debe ser estructurada, y para ello es conveniente acudir a marcos metodológicos probados como SAMM, un marco de referencia abierto que ayuda a las organizaciones a formular e implementar una estrategia para la seguridad del software adaptada a los riesgos específicos de cada organización. Los recursos facilitados por SAMM ayudarán a:
- Evaluar las prácticas de seguridad software existentes en las organizaciones.
- Construir un programa de aseguramiento de la seguridad software equilibrado en iteraciones bien definidas.
- Demostrar mejoras concretas al programa de aseguramiento de la seguridad.
- Definir y medir las actividades relativas a seguridad de una organización.
Por Luis Redondo
Responsable del Área de Ciberseguridad de MTP