jueves, 12 de marzo de 2015

Modelado de amenazas en la vida real

Estos últimos días he tratado de llevar a la práctica lo que aprendí leyendo el libro de Threat Modeling y me han ido surgiendo varios problemas que, contrastado con posteriores lecturas en diversos foros, son los más habituales. 
Vamos a ver con calma todos estos problemas y sus posibles soluciones.

Cuando llegamos tarde.
El primer problema que podemos encontrarnos es la dinámica habitual de los proyectos, te acaban de mandar a un proyecto y llegas tarde, ya han realizado las primeras entregas y está todo muy avanzado como para ponerte a realizar ahora análisis previos de vulnerabilidades. 
No luches contra el viento, el mejor consejo es adaptarse a la situación que tienes, ¿han realizado labores de análisis? Busca al arquitecto de Software, invítale a una cerveza o cómprale flores :) pero trata de que te deje ver todos los diagramas que haya hecho o la documentación donde plasman que hace cada función o como ha de funcionar cada pieza de la aplicación.
Si es desarrollo tradicional, estas de suerte, tiene que existir documentación en alguna parte, búscala. Si es desarrollo ágil, puede que no te estén mintiendo cuando dicen que no hay mucha documentación. En ese caso, la recomendación es que solicites el código y te pongas a revisarlo manualmente. No hace falta que te metas en el código en profundidad, queremos hacernos una idea de cómo está pensada la arquitectura y cuáles son sus funcionalidades principales. Pregunta, pregunta y luego vuelve a preguntar. 
No van a salir modelos de 10, pero al menos que lo tengas todo claro y puedas ir viendo por donde van a venir los primeros problemas.
Lo bueno de tu situación es que cuando les vayas avisando de problemas que van a surgir a futuro, o les van a dar mucho trabajo una vez salgan, te agradecerán que les hayas podido avisar con anterioridad.

Solo ante el peligro.
Otro problema habitual cuando tratas de hacer esto es que estas solo ante el peligro. No existe arquitecto de software. 
El proyecto está en fase temprana pero nadie va a realizar ningún modelado.
Esto va a ser el 90% de los casos con los que vas a encontrarte. Nadie modela nada, los programas crecen alrededor de los gestores de actividades y algunos documentos que fluyen.
En esta ocasión te encuentras en una tesitura parecida a la anterior, ¿Qué puedes hacer? Pues la solución es muy parecida, pregunta por todos lados.
Trata de acceder al código, los programadores suelen comenzar declarando las clases y proyectos que va a tener su aplicación, sobre eso puedes hacer reingeniería y ya puedes ir viendo que piezas forman el puzzle. Hay aplicaciones para los diferentes lenguajes que te hacen reingenierías (más o menos logradas) con las que sacan diferentes diagramas a partir del código. Parea tener un comienzo... mejor que nada, es.
Si logras conectar con el repositorio podrás ir viendo cómo crecen esas funciones y lograras hacer algunos diagramas donde empezaran a surgir los primeros problemas de seguridad.
Tienes que tener varias cosas en cuenta:
-       Los laboratorios llevan un reloj encima de sus cabezas, los requisitos de seguridad, si no se hacen desde el principio luego son tediosos de cambiar por lo que podemos convertirnos en un lastre para ellos. 
-       La primera fase de un desarrollo seguro es la formación, si no se ha realizado esto correctamente los laboratorios no entenderán gran parte de lo que les pides y, además, no estarán concienciados con los peligros. Si no les an dado una correcta formación trata de explicarles porque les pides los cambios, si lo entienden estarán mucho más contentos con el trabajo que les generamos.
-       Nivel de seguridad del proyecto. ¿Qué nivel de seguridad tiene el proyecto? Si tiene criticidad 1 hay que ser consecuente con ello y no exigir como si fuera criticidad 3. No vas a poner una BBDD DB2 con todas sus licencias a una tienda que vende flores solo porque sea “más seguro” que un Postgre. Como se suele decir “no matemos moscas a cañonazos”.
-       “El que hace los dibujos”. Ojo, tu función es la de auditor de seguridad, no te vayas a convertir en arquitecto de software y de repente te veas desempolvando los apuntes de UML, TOGAF o lo que sea para hacerles la arquitectura.
 
UML No es DFD
¿Qué es UML?
Según la Wiki:
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

¿Qué es DFD?
Según la Wiki:
Es una representación gráfica del flujo de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos.

Ya desde la misma definición podemos ver las diferencias. UML es un lenguaje de modelado, los elementos, normas y tipos que sustenta y a partir de los cuales puedes hacer tus diagramas.
Mientras que DFD es un tipo de diagrama en sí mismo. Viene de los años 70 y es un diagrama al que todo el mundo quiere mucho pero…
-       DFD no es un tipo de diagrama englobado por UML, es un diagrama en sí mismo.
-       DFD no es un estándar.
-       DFD no es usado en la generalidad de empresas.
DFD es muy simple por ello es muy sencillo modelar con él y que un usuario pueda comprenderlo, tiene solo un puñado de elementos y no esta sostenido por una normativa como es
UML, pero es muy eficaz.

¿Dónde está el problema? Me he leído una gran cantidad de documentación sobre modelado de amenazas ¿Por qué todo el mundo habla de modelar en DFD cuando apenas nadie lo usa en sus entornos de trabajo? Lo ideal es que cuando entremos en un desarrollo nos sentemos con los equipos, allí hay varios roles y, entre ellos, el arquitecto de software que ya te dará los diagramas de la aplicación sobre los que puedes empezar a trabajar. 

Ahí está el problema. Es muy difícil que te den dichos diagramas, por lo que imagínate lo difícil que es que te den un DFD. ¿Qué piensas hacer ahora? ¿Pasar todos los diagramas UML a DFD? Hay herramientas que hacen el proceso inverso de DFD a UML pero no es lo que necesitamos.
Vale, ya entendemos el problema con que nos vamos a encontrar ¿Qué hacemos ahora?
No hay una solución exacta, o al menos yo no la he encontrado. Lo que sí puedo decirte es que no trates de pasar esos UML a DFD, es trabajar más sin necesidad.

Que es lo que sí se puede hacer, trabajar sobre el UML. El libro de Threat modeling ya lo enumera como una posibilidad, y hace una brevísima reseña a algo inminente: Faltan elementos, tendrás que inventarte los tuyos. Me explico.

El diagrama UML más parecido a un DFD es el Diagrama de Actividades (adjunto imagen de ejemplo), estos diagramas están preparados para mostrar el flujo de trabajo. Por lo que no vas a encontrar en él a los actores o zonas de confianza u otros elementos que te ayuden a señalar las posibles vulnerabilidades. Eso tendrás que representarlo e inventártelo tú mismo.
Al final con el tiempo cada uno acaba haciendo su librillo de modelado con estos elementos (así nació en su día UML) puede que con el tiempo acabe haciéndose una pequeña normativa para poder solucionar este problema (si alguien se anima nos ponemos a ello xD). 

Por el momento... es lo que tienes.

¿Has intentado modelar las amenazas? ¿Con que problemas te has encontrado tú? ¿Te has encontrado con proyectos donde estaban bien modelados? ¿Con UML o DFDs?

PD: Se que existen UMLSec y derivados pero por el momento son solo textos de estudio, no conozco ningún proyecto que figure con su herramienta de modelado, si lo conoces por favor házmelo llegar :)

Fuentes de interés:

http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
http://en.wikipedia.org/wiki/Activity_diagram
http://es.wikipedia.org/wiki/Diagrama_de_flujo_de_datos
http://arxiv.org/ftp/arxiv/papers/1102/1102.4162.pdf

lunes, 2 de marzo de 2015

Libros sobre desarrollo seguro. Parte III



Quienes me tengan en Linkedin habrán visto que hace un par de semanas cambié de trabajo (un gran abrazo a todo mis viejos compis), el principal cambio es que he pasado de estar dando vueltas con el coche a la tranquila vida del transporte público.
Os cuento eso porque dos horas al día de lectura/estudio dan para mucho por lo que puede que estéis una temporada viendo este tipo de posts sobre libros interesantes de leer.
Hoy os traigo un 2x1 dos libros en un solo post.
¿Quién no conoce OWASP? Seguro que casi todos los que estáis leyendo este blog sabéis que es OWASP y sabéis que tiene una barbaridad de proyectos, todos ellos relacionados con la seguridad.
Algunos de esos proyectos se acaban materializando en guias fantásticas y de eso quiero hablaros hoy:

Uno de los textos que nacieron durante los años más prolíficos de OWASP (2008) una maravilla de guía que nos da todo un paseo sobre cómo revisar código.
Después de unos temas de introducción aborda esas partes, que casi todo programa tiene, y son un punto de interés: Autenticación, Autorización, Administración de sesiones, entrada de datos, control de errores, criptografía...
Quienes hicieron esta guía se tomaron muchas molestias en que todo estuviera ilustrado con ejemplos de código, encima doble ya que todos los puntos tienen ejemplos tanto de Java como de .NET lo cual es una maravilla para los que estamos empezando en temas de desarrollo seguro.
Como crítica dos cosillas:
- Desactualizado en algunos puntos, desde 2008 a hoy han cambiado cosas e incluso código. La buena noticia es que si buscas el proyecto hay una Alpha por lo que parece que está en camino la nueva versión de esta guía. Os animo a quienes sepáis de estos temas a que colaboréis os dará reputación y formareis parte de una de las joyas de la corona de OWASP.
- Checklist: AL final de documento si lista una serie de órdenes a revisar pero se echa une falta una buena checklist. Lo bueno es que ando acabando otro libro que si incluye la mejor checklist que he visto hasta ahora, espero podéroslo subir dentro de poco. 

OWASP Guide
Este documento está traducido al castellano como "Una guía para construir aplicaciones y servicios web seguros".
Trata de otra de las estrellas de OWASP, este aún es más antiguo que el anterior, su versión traducida al castellano data de 2005 pero es toda una maravilla.
Al igual que la guía anteriormente dicha pasa por autenticación, autorización, manejo de sesiones... Pero en este caso desarrolla más los contenidos dando pautas de las diferentes vías por donde pueden venir los problemas y cómo prevenirlos.
Es mucho más teórica, apenas contiene ejemplos d código pero dada lo antigua que es eso la hace más útil hoy en día.
Una autentica maravilla de texto, del cual creo que también hay un proyecto para actualizarlo y espero que alguien se anime a colaborar.
Por resumirlo es una checklist gigante pero desarrollando todos los puntos enormemente.
Una maravilla, sus más de 300 páginas os parecerán poco.

Espero que con este post os haya acercado un poco más las guías que tiene OWASP, tiene tantos proyectos que navegar entre sus páginas y saber que hay puede acabar siendo una locura pero OWASP es una comunidad abierta, os animo a que nadéis en ella y, si os veis con fuerza, apuntaros a algún proyecto.