Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>

Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>
Saltar a la sección
Aunque GDPR parece aterrador y, sin duda, tiene el potencial de serlo, implementar un análisis estático utilizando la herramienta y las pautas adecuadas lo ayudará a proteger su programa. Continúe leyendo para descubrir cómo implementar un diseño seguro para GDPR mediante análisis estático.
Saltar a la sección
Saltar a la sección
Obtener el análisis estático configurado correctamente con la herramienta adecuada y las reglas correctas lo ayudará a proteger su software, demostrar que está haciendo lo correcto para los auditores y demostrar que está siguiendo los principios de seguridad por diseño y privacidad por diseño.
GDPR es grande y aterrador. En pocas palabras, GDPR significa que debe informar a los usuarios:
Y, oh sí, si no cumples, hay multas muy, muy grandes.
En teoría, GDPR se aplica solo a los ciudadanos de la UE, pero el alcance global de la mayoría del comercio en estos días requiere diligencia para cumplir con la regulación en todo el mundo. Esto deja una opción entre tratar a todos los usuarios de manera segura y privada versus, por ejemplo, tener un flujo de datos completamente segmentado para clientes de la UE y fuera de la UE, probablemente una propuesta más costosa. En este blog, explicaré cómo puede aprovechar el análisis de código estático para ayudar a mejorar la protección de datos y la privacidad.
Los objetivos generales de GDPR son limitar y proteger la información del cliente frente a la recopilación de datos a gran escala por parte de las organizaciones, predominantemente en Internet. Las leyes se implementan para los ciudadanos de la UE, pero el impacto será mundial ya que la mayoría de las organizaciones hacen negocios en países de la UE y/o con ciudadanos de la UE.
Estos son los principios clave.
El impacto de Cumplimiento GDPR sobre el desarrollo de software es importante, ya que tiene una serie de implicaciones para las prácticas de desarrollo de software. Un enfoque clave para los desarrolladores de software son las salvaguardias técnicas y organizativas necesarias para satisfacer los principios clave y garantizar la integridad y confidencialidad de los datos del usuario.
Cuando piensa en GDPR, protección de datos y otras regulaciones de datos asociadas como PCI DSS (Estándar de seguridad de datos de la industria de tarjetas de pago) o HIPAA (Ley de responsabilidad y portabilidad de seguros médicos), el pensamiento inmediato es la necesidad de más pruebas, análisis dinámicos y pruebas de penetración.
Si bien son necesarias e importantes, estas tecnologías de prueba disminuyen la posibilidad de enviar software inseguro, sin hacer que el software sea más seguro ni garantizar la privacidad en primer lugar. Pero la seguridad y la privacidad no se pueden "probar" en el software más que la calidad o el rendimiento. Por lo tanto, GDPR requiere conceptos llamados "Seguridad por diseño" y "Privacidad por diseño" (PbD), lo que significa crear un mejor software en primer lugar.
“El enfoque de Privacidad por Diseño se caracteriza por medidas proactivas en lugar de reactivas. Anticipa y previene eventos invasivos de privacidad antes de que sucedan. PbD no espera a que se materialicen los riesgos de privacidad, ni ofrece remedios para resolver las infracciones de privacidad una vez que se han producido; su objetivo es evitar que ocurran. En resumen, Privacy by Design viene antes del hecho, no después”.
-A. Cavoukiano. Privacidad por diseño: los 7 principios fundamentales, enero de 2011.
Menciono estos dos conceptos porque son el siguiente paso después de que se llevan a cabo las actividades normales de seguridad de la aplicación (cortafuegos, pruebas de penetración, equipos rojos, DAST, etc.). La parte "por diseño" también se puede leer como "construirlo". Esta es la idea de que, en lugar de hurgar en su aplicación y corregir dónde se encuentran los agujeros, crea una aplicación sin los agujeros en primer lugar... por diseño, por así decirlo. Por ejemplo, la inyección SQL (SQLi) sigue siendo uno de los exploits más comunes.
Existen muchas herramientas para intentar forzar una inyección a través de la interfaz de usuario (prueba de penetración) o simular el flujo de datos en un programa sin ejecutarlo para ver si los datos contaminados pueden llegar a una consulta de la base de datos (análisis de flujo).
Un enfoque "por diseño" significa envolver cualquier entrada, desde una base de datos, un usuario o cualquier lugar, dentro de una función de validación en el momento en que se adquiere la entrada. Esto reduce las posibles rutas donde los datos pueden pasar por alto a cero. Todavía necesita ejecutar las pruebas de penetración para asegurarse de que creó su software correctamente, pero la diferencia es que si una prueba de penetración tiene éxito, no solo soluciona la única debilidad que encontró. En cambio, mira hacia atrás y descubre POR QUÉ la prueba de penetración tuvo éxito y construye su software para que no tenga éxito.
Si una prueba de penetración encuentra muchas fallas de seguridad en su software, entonces no está creando un software seguro "por diseño". De manera similar a Privacidad por diseño, observamos quién/qué/dónde compartimos, y suponemos que todos los datos son importantes a menos que se indique lo contrario. Nuevamente, los programadores comúnmente asumen que los datos NO SON importantes a menos que estén especialmente marcados.
Usted ve esto en cosas como decisiones sobre si los datos se almacenan en forma simple o si los datos están encriptados. Encriptar todo es una forma de hacer privacidad por diseño. Uno de muchos concedido, pero esa es la idea básica. Si cifra todo, nunca tendrá que preocuparse por no cifrar algo que debería tener.
La papel del análisis estático no es para decirnos que nuestro software es vulnerable. Ese es el trabajo de probar. El papel del análisis estático es ayudar a garantizar que el software sea sólido en primer lugar... por diseño. Si bien el análisis de flujo se ha vuelto popular en los últimos 10 años como una técnica de prueba de seguridad, sigue siendo una forma de probar el software en lugar de una forma de fortalecer el software, o incorporar seguridad, o hacerlo "por diseño".
El análisis estático puede posicionarse de manera única para actuar como una técnica preventiva real si se usa correctamente. Además de las reglas de seguridad del análisis de flujo, por ejemplo, buscando datos contaminados, también habilitamos reglas que garantizan que el software se construya de manera segura. Teniendo en cuenta los dos casos anteriores, cuando hago privacidad por diseño, puedo tener reglas de análisis estático que marcan cuando:
Los datos se almacenan sin cifrarse primero.
Se utiliza un método de cifrado antiguo e inadecuado que se puede hackear en lugar de un cifrado fuerte.
Los usuarios intentan acceder a datos inapropiados para sus permisos esperados.
Aquí hay una breve descripción de una regla de muestra que impone el registro cuando se invocan métodos confidenciales. Esta regla de análisis estático no encontrará errores, pero lo ayudará a crear software que registre lo que sucede para que sea más seguro en producción. Esta regla es perfecta para PCI DSS y GDPR.
Asegúrese de que todas las invocaciones de métodos confidenciales estén registradas [SECURITY.BV.ENFL]
DESCRIPCIÓN: Esta regla identifica el código que no registra las invocaciones de métodos sensibles. Se informa de un error si algunas invocaciones de métodos confidenciales, por ejemplo, 'iniciar sesión' y 'cerrar sesión' de 'javax.security.auth.login.LoginContext'– no se registran cuando se utilizan.
Otro ejemplo de privacidad por diseño es esta regla que ayuda a evitar que usted filtre involuntariamente información personal o importante cuando ocurre un error en su software:
No pase mensajes de excepción a la salida para evitar que la aplicación filtre información confidencial [SECURITY.ESD.PEO]
DESCRIPCIÓN: Esta regla identifica el código que pasa mensajes de excepción a la salida. Se informa un error cuando una cláusula catch llama a un método de salida y la excepción que se detecta en la cláusula catch aparece en la lista de parámetros o se utiliza como el objeto de llamada.
Esta regla cubre OWASP Top 10, CWE, PCI DSS y GDPR, lo que significa que es una muy buena idea sin importar por qué está tratando de hacer seguridad.
Herramientas de análisis estático son útiles para respaldar los requisitos de protección de los datos de los usuarios en todos los niveles al mejorar la calidad, la privacidad y la seguridad de las aplicaciones. Específicamente, esto incluye:
Los puntos fuertes de las herramientas de análisis estático se encuentran en dos áreas clave.
GDPR no proporciona un estándar de codificación, ni describe explícitamente los errores de seguridad y privacidad para detectar y remediar. Sin embargo, si observa la compatibilidad con otros estándares relacionados, como PCI DSS, podemos reutilizar los mismos conceptos. Por ejemplo, se pueden detectar los siguientes tipos de problemas de protección de datos:
Además, Parasoft admite los siguientes estándares de codificación segura, de los cuales los desarrolladores pueden personalizar un conjunto único para su organización:
Debido a que GDPR no es un estándar de codificación, no existe una configuración de análisis estático simple que lo cubra. A menudo, el mejor punto de partida es encontrar reglas de análisis estático que se relacionen directamente con los problemas que encuentra actualmente en las pruebas, como problemas de XSS o SQLi. Dichos problemas generalmente tienen algunas reglas de análisis estático que actúan como buscadores de errores y proporcionarán una detección temprana de estos problemas antes de que lleguen a la prueba. Aún más importante, también habrá reglas asociadas, en este caso sobre la validación de entrada, que lo ayudarán a garantizar que SQLi simplemente no pueda suceder como mencioné anteriormente.
Buscar datos desde la entrada del usuario a través del almacenamiento es difícil. Programar para que la validación siempre ocurra es fácil. Programar para que el cifrado siempre ocurra es fácil de hacer y de probar. ¿Por qué hacerlo de la manera más difícil?
Una vez que haya encontrado y activado las reglas para los problemas que encuentra durante las pruebas, querrá ir aún más lejos. Sugeriría tomar prestadas ideas de otros estándares de codificación que ya cubren la privacidad y protección de datos. Algunas buenas opciones son OWASP, HIPAA y PCI DSS.
Si activa cualquier regla en su herramienta de análisis estático que se relacione con esos estándares, estará haciendo un buen trabajo para GDPR. De hecho, si ya cumple con PCI DSS, encontrará que al menos esta parte de GDPR debería ser relativamente fácil de preparar.
Si ya tiene otros requisitos de seguridad como CWE o CERT, puede asegurarse de que también los está siguiendo y ampliar su configuración para cubrir la protección de datos GDPR específica según sea necesario al encontrar cualquier elemento en esos estándares relacionados con la privacidad de datos, la protección de datos y cifrado.
Parasoft puede ayudarlo a obtener su código seguro y privado por diseño de varias maneras. Primero, todos nuestros motores de análisis estático tienen configuraciones para OWASP, CWE, CERT, PCI DSS, HIPAA, etc. Puede activar el conjunto exacto de reglas de seguridad que mejor se adapte a su organización y luego aplicarlas automáticamente.
Además, cuando integra Parasoft DTP con análisis estático, tiene capacidad de auditoría completa, automatizando el proceso de documentación de qué reglas se ejecutaron en qué código y cuándo. Puede probar que está probando o incluso demostrar que es seguro por diseño según las reglas que haya seleccionado.
Parasoft DTP también tiene algunos informes muy especiales. Si elige basar sus esfuerzos de seguridad en CWE, el panel de Parasoft CWE le brinda excelentes informes SAST, como problemas por gravedad, ubicación, tipo, historial y más.
Hemos ido un paso más allá e implementado los datos de impacto técnico en CWE. El impacto técnico (TI) es una investigación realizada en Mitre como parte del marco común de análisis de riesgo de debilidad (CWRAF) y lo ayuda a clasificar los hallazgos de SAST según el problema que pueden causar. Entonces, en lugar de un mensaje que dice que tiene un desbordamiento de búfer, que algunos podrían no reconocer como un problema de seguridad, TI le dice que el desbordamiento de búfer podría provocar una denegación de servicio.
Cada hallazgo de CWE le dice qué tipos de problemas pueden ocurrir. Hay gráficos especiales que lo ayudan a navegar por sus problemas de análisis estático en función de las áreas problemáticas más importantes para usted, no solo en los niveles de gravedad. Esta técnica innovadora lo ayuda a controlar lo que a menudo puede convertirse en una cantidad abrumadora de vulnerabilidades, especialmente si está trabajando en una base de código heredada. Concéntrese primero en los problemas que más le asustan.
Y, por supuesto, mientras me enfocaba en el análisis estático hoy como una forma de hacer seguridad por diseño, no olvide que Parasoft también tiene herramientas de prueba de penetración, prueba de API y virtualización de servicios, todos los cuales son una parte importante de un completo estrategia de desarrollo de software seguro.
GDPR parece aterrador y ciertamente puede serlo, pero configurar correctamente el análisis estático con la herramienta adecuada y las reglas correctas lo ayudará a:
Esto es algo que las pruebas de penetración por sí solas no pueden hacer. El beneficio adicional es que descubrirá que abordar la seguridad desde la perspectiva del "diseño" es mucho más eficaz que intentar probar su forma de proteger el software entre el control de calidad y el lanzamiento.
Pruebas Java más inteligentes con IA para mayor velocidad, cobertura y cumplimiento