X
BLOG

Uso del análisis estático para lograr "seguridad por diseño" para el RGPD

Uso del análisis estático para lograr "seguridad por diseño" para el RGPD Tiempo de leer: 7 minutos
Configurar correctamente el análisis estático con la herramienta adecuada y las reglas adecuadas lo ayudará a proteger su software, demostrar que está haciendo lo correcto para los auditores y demostrar que sigue los principios de seguridad por diseño y privacidad por -diseño.

GDPR es grande y aterrador y cada día se acerca más. Una parte de mí quiere creer que todos estaremos listos para el 25 de mayo.th fecha límite, pero la mayoría de mí cree que el verdadero impulso para cumplir ocurrirá DESPUÉS de esa fecha. Si no tiene claro qué es realmente el RGPD o si le importa, eche un vistazo a mi último blog para una descripción más amplia. En pocas palabras, significa que debe informar a los usuarios qué datos está recopilando, cómo los usará, hacer todo lo posible para protegerlos, ser transparente cuando se produzcan infracciones y eliminar los datos del usuario por completo si lo solicitan. Y sí, si no cumple, hay grandes multas.

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 o tener un flujo de datos completamente segmentado para clientes de la UE y fuera de la UE, por ejemplo (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.

Seguridad por diseño y privacidad por diseño

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 portabilidad y responsabilidad de seguros de salud), la idea inmediata es la necesidad de un mayor número de pruebas y análisis dinámicos. y pruebas de penetración. Si bien son necesarias e importantes, estas tecnologías de prueba reducen la posibilidad de enviar software inseguro, sin realmente hacer que el software sea más seguro o 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, el RGPD requiere conceptos llamados "Seguridad por diseño" y "Privacidad por diseño" (PbD), lo que significa, en primer lugar, desarrollar un mejor software.

 “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 han ocurrido; su objetivo es evitar que ocurran. En resumen, la privacidad por diseño viene antes del hecho, no después "

A. Cavoukian. Privacidad por diseño: los 7 principios fundamentales, enero de 2011.

Traigo estos dos conceptos porque son el siguiente paso después de que se llevan a cabo las actividades normales de seguridad de las aplicaciones (firewalls, 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 tocar la aplicación y arreglar el lugar donde se encuentran los orificios, se construye una aplicación sin los orificios en primer lugar ... por diseño, por así decirlo. Por ejemplo, la inyección de 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 pasar a una consulta de base de datos (análisis de flujo). Un enfoque "por diseño" significa envolver cualquier entrada (de la base de datos, del usuario o de 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 a cero. Aún necesita ejecutar las pruebas de penetración para asegurarse de que creó su software correctamente, pero la diferencia es que si pentest tiene éxito, no se limita a corregir la única debilidad que encontró. En su lugar, mira hacia atrás y descubre POR QUÉ pentest tuvo éxito y construye su software para que no tenga éxito.

Si pentest encuentra muchas fallas de seguridad en su software, entonces no está construyendo software seguro "por diseño". Similar a Privacy by Design, observamos quién / qué / dónde compartimos, y asumimos que todos los datos son importantes a menos que se indique lo contrario. Una vez más, los programadores suelen hacer suposiciones de que los datos NO SON importantes a menos que estén especialmente marcados. Puede ver esto en cosas como decisiones sobre si los datos se almacenan en forma simple o si los datos están encriptados. Cifrar todo es una forma de proteger la privacidad por diseño. Uno de los muchos concedidos, pero esa es la idea básica. Si encripta todo, nunca tendrá que preocuparse de no haber encriptado algo que debería tener.

¿Qué papel juega aquí el análisis estático?

El papel del análisis estático no es decirnos que nuestro software es vulnerable (ese es el trabajo de las pruebas). La función 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 la seguridad o hacerlo "por diseño".

El análisis estático se puede posicionar 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, es decir, la búsqueda de 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 ser encriptados primero, o cuando se usa un antiguo método de encriptación inapropiado que es pirateable en lugar de encriptación fuerte, o cuando los usuarios son tratando de acceder a datos inapropiados para sus permisos esperados.

A continuación, se incluye una breve descripción de una regla de muestra que impone el registro cuando se invocan métodos sensibles. Esta regla de análisis estático no encontrará errores, pero lo ayudará a crear un software que registre lo que está sucediendo 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.

Cómo comenzar

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 está encontrando actualmente en las pruebas, como XSS o problemas de SQLi. Estos 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 en torno a 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?

¿Cuáles son algunas otras reglas de análisis estático?

Una vez que haya encontrado y activado las reglas para los problemas que encuentre 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 los datos. Algunas buenas opciones son OWASP, HIPAA y PCI-DSS. Si activó alguna 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 del GDPR debería ser relativamente fácil de preparar.

Si ya tiene otros requisitos de seguridad como CWE o CERT, puede asegurarse de que los está siguiendo también 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, datos protección y cifrado.

¿Qué más puede hacer Parasoft por usted?

Parasoft puede ayudarlo a que su código sea 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, HIPPA, etc. Puede activar el conjunto exacto de reglas de seguridad que se adapten bien a su organización y luego hacerlas cumplir automáticamente.

Además, cuando integra Parasoft DTP con análisis estático, tiene capacidad de auditoría completa, automatizando el proceso de documentar qué reglas se ejecutaron en qué código y cuándo. Puede demostrar que está realizando pruebas o incluso seguro por diseño en función de las reglas que ha seleccionado.

Parasoft DTP también tiene algunos informes muy especiales, y 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, etc. dio un paso más e implementó los datos de impacto técnico en CWE. Technical Impact (TI) es una investigación realizada en Mitre como parte del Marco de análisis de riesgo de debilidad común (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 del búfer, que algunos podrían no reconocer como un problema de seguridad, TI le dice que el desbordamiento del búfer podría conducir a la denegación de servicio.

Cada hallazgo de CWE le dice qué tipo de problemas pueden ocurrir, y hay gráficos especiales que lo ayudan a navegar por sus problemas de análisis estático en función de las áreas de problemas 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 abrumadora cantidad de vulnerabilidades, especialmente si está trabajando en una base de código heredado. Concéntrese primero en los problemas que más le asustan.

Y, por supuesto, aunque hoy me enfocaba en el análisis estático como una forma de hacer seguridad por diseño, no olvide que Parasoft también tiene herramientas de prueba de penetración, pruebas de API y virtualización de servicios, todas las cuales son una parte importante de una estrategia integral de desarrollo de software seguro.

Resumen

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 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. Esto es algo que las pruebas de penetración por sí solas no pueden hacer. El beneficio adicional es que encontrará que abordar la seguridad desde la perspectiva del “diseño” es mucho más efectivo que intentar probar su camino para proteger el software entre el control de calidad y el lanzamiento. Para sumergirse más profundamente, lea la guía: Uso de análisis estático para seguridad y privacidad de datos GDPR de diseño seguro.

Nuevo llamado a la acción

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft