24 abr 2019

Seguridad y modelado en el desarrollo de software: cuanto antes, mejor

Si nos remontamos a los primeros desarrollos de software, o no tan atrás, a hace 10 años, estos desarrollos tenían como objetivo conseguir que el software tuviera las características solicitadas por un cliente, pero nadie se centraba en que ese software fuera eficiente, de calidad o seguro. Con el tiempo, se empezó a extender el concepto de calidad, algo necesario en la industria y, finalmente y a base de palos, se ha conseguido dar a entender que la seguridad necesita estar presente en cualquier desarrollo.

Hace no mucho, apenas 2 años atrás, cuando trabajaba en el equipo de seguridad de aplicaciones de Accenture Security, y en reuniones con diferentes clientes, algunos comentaban que ellos ya tenían contratados a un equipo de hacking ético para revisar la seguridad de sus aplicaciones, y que con eso era suficiente, otros además agregaban un análisis estático del código (SAST) al finalizar el desarrollo. Sin duda, son tareas necesarias en el mundo del desarrollo de aplicaciones, pero se realizan al final, cuando si se detecta un bug o problema, puede ser demasiado tarde, por que lo detecte un atacante o la modificación de la aplicación requiere rehacerla por completo. La seguridad en el software se debe incluir desde el minuto 1, que es en la captura de requisitos. En el siguiente esquema se puede ver la aproximación a alto nivel de la que estoy hablando.
Aproximación a alto nivel imagen
Las tareas fundamentales para llevar tener un código lo más seguro posible son los siguientes:
  • Recogida de información que afecte a la seguridad (por ejemplo, ¿qué normativas pueden afectar a este desarrollo?
  • Modelado de amenazas.
  • Establecer contramedidas.
  • Durante el desarrollo implementar las contramedidas y pasar un SAST.
  • Al finalizar el desarrollo, realizar las pruebas de seguridad correspondientes (SAST, DAST, ethical hacking).

Recogida de información

Debe de existir una buena comunicación, la seguridad es responsabilidad de todos, en primer lugar, reuniones entre los equipos de seguridad, arquitectura y negocio son imprescindibles. Es necesario obtener entre otros datos: el tipo de datos que se va a manejar, los usuarios, dónde se desplegará el software, (país, Intranet, cloud, etc.), componentes o flujos.

Modelar amenazas

Teniendo en cuenta toda la información recolectada, para facilitar el trabajo se pasa a hacer el diagrama de flujos, donde saldrán las zonas de confianza, los componentes de la aplicación y los flujos que existirán entre componentes y zona, a partir de este diagrama podemos pasar a identificar amenazas que afectan al proyecto. Puedes seguir distintas metodologías: STRIDE, PASTA, Trike, etc.

Contramedidas

Las amenazas se deben tener en cuenta a la hora de desarrollar, y para ello es necesario definir unas contramedidas que los desarrolladores tengan en cuenta. En este punto no se entra en detalle, se trata de un enunciado a alto nivel, del tipo: “Parametriza las consultas a la base de datos”. Para aportar un gran valor a estas contramedidas a la hora de validar que se están llevando a cabo en el desarrollo, se puede hacer un mapeo con estándares de seguridad, como son CWE o ASVS.

Implementaciones

Las contramedidas se ha comentado que son a alto nivel, en este caso, teniendo en cuenta la tecnología a usar en el proyecto, se puede decir cómo llevar a cabo esa contramedida. Por ejemplo, en PHP, llevar a cabo la parametrización:
$test = $db->prepare("INSERT INTO TEST (mytest) VALUES (:mytest)");
$test->bindParam(':mytest', $mytest);
De primeras puede parecer un trabajo pesado, así pasaba, nos encontrábamos con equipos que comentaban que esto les generaba perdida de tiempo que no entregaban a tiempo… Hay que dejar claro, que esta tarea requiere de la colaboración de todos, y la estimación se tiene que hacer teniendo la seguridad en mente. Con la colaboración de todos y la experiencia nos fuimos encontrando mucho mejor feedback.

Podemos ver que es un trabajo "repetitivo", por lo que, generando una base de conocimientos a la larga, se va a poder reducir mucho el tiempo dedicado a encontrar amenazas y definir contramedidas, bastará con establecer componentes de la aplicación, datos, flujos, etc. Y tendremos el listado de contramedidas e implementaciones.

Existen herramientas en la red que pueden ser de gran ayuda a la hora de llevar a cabo este trabajo, unas gratis, otras con diferentes licencias, dejo un pequeño listado:
  • Irius Risk: aún les queda trabajo por hacer, quizás el punto más débil es el tema de implementaciones, pero es de las más completas que he usado, permite personalización y agregar nuestro contenido, pero además ya dispone de muchos datos. No es gratuita.
  • Microsoft Threat Modelling Tool: herramienta gratuita para pequeños desarrollos o para comenzar a aprender no está mal, pero de cara a algo “profesional” no la recomiendo. Dejará de tener continuidad en octubre del 2019.
  • Threat Dragon: herramienta de OWASP, para hacer el diagrama nos puede servir, pero no para mucho más.
  • Drawio: esta herramienta no la he podido probar, pero el aspecto visual que ofrece es muy bueno, si alguien la conoce o la quiere probar y dar su opinión se lo agradecería.
  • Threat Modeler: una herramienta potente, no es gratuita.
No dejes la seguridad de tus desarrollos para el final, aunque te parezca que el proyecto te va a requerir más esfuerzo, tiempo y dinero, a la larga va a ser todo lo contrario, recuerda esto: arreglar un problema encontrado en una aplicación que ya se encuentra en producción es muchísimo más caro que arreglar uno encontrado en la fase de diseño.

Fuente: ElevenPaths

Suscríbete a nuestro Boletín

0 Comments:

Publicar un comentario

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!