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

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 incorporar 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 desarrollen y prueben en las primeras etapas del desarrollo de la aplicación, por ejemplo. Así como la seguridad no se puede probar más adelante 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 para los sistemas y aplicaciones de TI y no se debe suponer que se "activará" más tarde con las 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 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.

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

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.

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

Cómo Empezar

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 conclusiones clave

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 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.