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

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.

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:

• Qué datos estás recopilando.
• Cómo lo usarás.
• Haz tu mejor esfuerzo para protegerlo.
• Sea transparente cuando se produzcan infracciones
• Elimine cualquier dato de usuario por completo si lo solicitan.

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.

Comprender el RGPD y su impacto en el desarrollo de software

Principios clave del RGPD

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.

• Legal y transparente. La recogida de datos debe realizarse de forma lícita, lo que implica el cumplimiento del RGPD y cualquier otra legislación de recogida de datos en la jurisdicción del usuario. El uso de los datos debe ser transparente para el usuario y obtenido legalmente y con permiso explícito.
• Minimizar el tiempo de almacenamiento. Los datos del usuario solo se pueden conservar durante el tiempo que sea necesario y no más. Los datos del usuario deben eliminarse o anonimizarse cuando ya no se necesiten.
• Minimizar la cantidad de datos. La cantidad de datos recopilados solo debe ser la necesaria y respalda la intención original de la recopilación de datos.
• Precisión de los datos. Los datos del usuario deben ser exactos y estar actualizados. Los datos inexactos deben ser corregidos o eliminados.
• Propósito específico y limitado. Los datos del usuario solo se pueden recopilar para satisfacer el propósito original. Los datos no se pueden retener y reutilizar para otros fines.
• Garantías técnicas y organizativas. La recopilación de datos implica que las organizaciones deben proteger los datos personales contra el acceso no autorizado a través de medios ilegales o accidentales. Se requieren soluciones tecnológicas apropiadas para mantener la integridad y la confidencialidad. Implícito en este principio está la responsabilidad organizacional de las medidas de seguridad adecuadas para proteger los datos del usuario.

Impacto en el desarrollo de software

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.

• Asegurar una cobranza lícita y transparente. Como hemos visto con la gran cantidad de ventanas emergentes de sitios web, las organizaciones deben asegurarse de recopilar datos de usuarios de manera legal, describir completamente cómo se utilizan y recopilar el consentimiento de los usuarios antes de recopilarlos. En muchos casos, esto agrega requisitos a las interfaces de usuario y las interfaces de aplicaciones.
• Medidas organizativas para garantizar la protección de datos. Los datos de los usuarios deben considerarse confidenciales y tratarse como tales a lo largo de su vida dentro de los sistemas de una organización. Esto se alinea con la tríada de confidencialidad, integridad y accesibilidad de la CIA. La filosofía es fundamental para la seguridad de la información y el enfoque ahora se necesita para los datos de los clientes en los sistemas de TI comerciales. Bajo GDPR, las organizaciones deben tomar medidas en todos los niveles para proteger los datos de los clientes, lo que tiene implicaciones para el desarrollo de software, los sistemas de TI, el comportamiento organizacional y la postura de seguridad.
• Protección de datos desde el diseño y por defecto. Es necesario integrar la seguridad para cumplir con los principios de protección de datos del RGPD. Esto implica que la seguridad y la protección de datos se desarrollan y prueban en las primeras etapas del desarrollo de aplicaciones, por ejemplo. Al igual que la seguridad no puede probarse posteriormente en el ciclo de vida de un producto, lo mismo ocurre con la protección de datos del RGPD. Además, la protección de datos debe ser la configuración predeterminada de los sistemas y aplicaciones de TI, y no debe darse por sentado que se activará posteriormente mediante opciones de configuración, por ejemplo.
• Los datos personales se procesan de manera adecuada y transparente. Los datos personales dentro de las aplicaciones y los sistemas de TI deben estar protegidos en tránsito y en reposo. Esto implica el cifrado adecuado de los datos en la mayoría de los casos y solo usarlos en texto claro cuando sea absolutamente necesario. Como la mayoría de las personas han experimentado violaciones de datos de alto perfil, la tecnología y las prácticas deficientes de almacenamiento de datos han llevado a la exposición de datos de usuario altamente confidenciales.
• Limite el uso y el tiempo de almacenamiento. Los desarrolladores de software deben asegurarse de que existan límites de tiempo para el almacenamiento de datos del cliente y limitar el intercambio de estos datos más allá de su intención original. Por ejemplo, si los clientes no interactúan con su aplicación durante 30 días, debe eliminar por completo la información almacenada, lo que agrega importantes requisitos nuevos al almacenamiento de datos. Además, depende de la organización asegurarse de que los datos de los clientes no se utilicen internamente para otros fines. Por ejemplo, recopilar detalles de atención al cliente y luego compartirlos con ventas o marketing. A menos que se dé un consentimiento explícito para este intercambio, no se puede hacer

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 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 reducen la probabilidad de distribuir software inseguro, sin aumentar su seguridad ni garantizar la privacidad. Sin embargo, la seguridad y la privacidad no se pueden probar en el software, al igual que la calidad o el rendimiento. Por lo tanto, el RGPD exige los conceptos de "Seguridad por Diseño" y "Privacidad por Diseño" (PbD), lo que implica desarrollar un mejor software desde el principio.

El enfoque de Privacidad por Diseño se caracteriza por medidas proactivas en lugar de reactivas. Anticipa y previene eventos que invadan la privacidad antes de que ocurran. La Privacidad por Diseño no espera a que se materialicen los riesgos para la privacidad ni ofrece soluciones para resolver las infracciones una vez ocurridas; su objetivo es prevenirlas. En resumen, la Privacidad por Diseño se implementa antes de los hechos, 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 las actividades normales de seguridad de aplicaciones (firewalls, pruebas de penetración, equipos rojos, DAST, etc.). La parte "por diseño" también puede interpretarse como "integrarlo". Esta idea consiste en que, en lugar de analizar la aplicación y corregir las vulnerabilidades, se crea una aplicación sin ellas desde el principio... 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" implica encapsular cualquier entrada (de una base de datos, un usuario o cualquier otro lugar) dentro de una función de validación en el momento en que se adquiere. Esto reduce a cero las posibles rutas por las que los datos pueden eludir la normativa. Aun así, es necesario ejecutar pruebas de penetración para asegurarse de que el software se diseñó correctamente, pero la diferencia radica en que, si una prueba de penetración tiene éxito, no se corrige simplemente la debilidad detectada. En cambio, se analiza el por qué de la prueba de penetración y se diseña el software para que no tenga éxito.

Si una prueba de penetración detecta numerosas vulnerabilidades de seguridad en su software, no está desarrollando software seguro "por diseño". Al igual que en la Privacidad por Diseño, vigilamos quién, qué y dónde compartimos, y damos por sentado que todos los datos son importantes a menos que se indique lo contrario. De nuevo, los programadores suelen asumir que los datos NO son importantes a menos que se marquen específicamente.

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.

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

La sección papel del análisis estático No pretende 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 robusto desde el principio… por diseño. Si bien el análisis de flujo se ha popularizado en los últimos 10 años como técnica de pruebas de seguridad, sigue siendo una forma de probar el software, no una forma de reforzarlo (o integrar la seguridad) o hacerlo "por diseño".

El análisis estático puede ser una herramienta única para actuar como una verdadera técnica preventiva si se utiliza correctamente. Además de... seguridad del análisis de flujo Reglas, por ejemplo, para buscar datos contaminados, también habilitamos reglas que garantizan que el software se desarrolle de forma segura. Considerando los dos casos anteriores, al implementar la privacidad por diseño, puedo tener reglas de análisis estático que indiquen cuándo:

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.

Beneficios de usar el análisis estático para GDPR

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:

• Detección temprana de vulnerabilidades de seguridad. El análisis estático ayuda a prevenir, a través de estándares de codificación seguros, el desarrollo de software de mala calidad que conduce a vulnerabilidades que luego pueden explotarse. Estas herramientas también detectan e identifican posibles vulnerabilidades de seguridad en las primeras etapas del ciclo de vida del desarrollo de software antes de que el software se implemente en producción. Esto permite a los desarrolladores abordar estas vulnerabilidades antes de que se conviertan en un problema de seguridad o privacidad.
• Prevención de malas prácticas de privacidad y seguridad. Las herramientas de análisis estático se pueden configurar para buscar prácticas específicas de seguridad y privacidad deficientes que son comunes en las violaciones de datos. Por ejemplo, se puede marcar el uso de técnicas criptográficas deficientes conocidas.
• Mejora de la calidad del software. Una mejora general en la calidad del software es esencial para eliminar la posibilidad de futuras filtraciones de datos y vulnerabilidades de seguridad.

Problemas comunes de protección de datos abordados por el análisis estático

Los puntos fuertes de las herramientas de análisis estático se encuentran en dos áreas clave.

1. Prevención de malas prácticas de codificación a través de la aplicación de estándares de codificación.
2. Detección de bugs y vulnerabilidades por errores de lógica en el código.

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:

• Defectos de inyección, incluidas inyecciones de SQL, comando, LDAP y Xpath
• El buffer se desborda
• Funciones criptográficas inseguras
• Comunicación de datos insegura
• Manejo inadecuado de errores
• Control de acceso inadecuado
• Cross-site scripting
• Falsificación de solicitudes entre sitios
• Autenticación y gestión de sesiones rotas

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:

• SEI CERT C y CERT C++
• CWE Top 25 errores de software más peligrosos, CWE en la cúspide
• Top 10 de OWASP, Top 10 de seguridad API de OWASP

Primeros Pasos

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?

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

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.

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

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.

Resumen y principales conclusiones

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:

• Asegure su software.
• Demuestre que está haciendo lo correcto para los auditores.
• Demuestre 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 lograr. La ventaja adicional es que descubrirá que abordar la seguridad desde una perspectiva de diseño es mucho más efectivo que intentar probar el software para protegerlo entre el control de calidad y el lanzamiento.