Este es el primer post de una serie donde aprenderemos los conceptos e implementaciones del Modelado de Amenazas para crear Software más seguro.

Todos tenemos algo que proteger, sin embargo, es dificil saber con seguridad cuales son las cosas mas efectivas para llevar nuestro propósito a cabo.

Verificamos que la puerta principal de nuestro hogar tenga los seguros puestos, al estacionarnos, nos cercioramos que nuestro coche tenga la alarma activada, y aún así, el robo de autos y casa habitación sigue ocurriendo cada día. Los ladrones entienden todos estos mecanismos a los cuales la mayoría estamos entrenados casi automáticamente en hacer, sin embargo, ellos solo ocupan encontrar una forma de poder violar cualquiera de los mecanismos de seguridad que en muchas ocasiones asumimos son suficientes.

Esto nos lleva a comprender que muchos de los retos a los que nos enfrentamos al momento de proteger algo que apreciamos conlleva aspectos que difícilmente pudieramos preveer sin, vaya, dedicarnos a ese rubro.

En el mundo de la Seguridad de Información, esto no es nada diferente. Día con día, una cantidad considerable de incidentes ocurren donde información personal, desde tarjetas de crédito a credenciales de acceso son adquiridas por personsa o grupos criminales con intenciones cuestionables.

La mayoría de los incidentes de seguridad son oportunísticos.

Un gran número éstos incidentes pudieron haber sido prevenidos en caso de tomar medidas de seguridad que algunos llamarían "sentido común", sin embargo, éstos no suelen ser tan obvios para todo mundo como sería activar la alarma de un carro o agregar una cerradura adicional.

Por lo tanto, es importante aplicar modelos mentales que nos permitan tener una mejor oportunidad para estar preparado ante estas posibles amenazas y encontrar medios mas efectivos de proteger lo que más nos importa. Y en caso de que estos ocurran, minimizar el impacto que conllevan.

Paradojas de Enfoque

Es posible que en alguna ocasión hayas escuchado frases como: "Piensa como si fueras el atacante" o "Ponte en los zapatos del enemigo" entre otras variantes. Desgraciadamente, intentar adoptar el mindset de un atacante, y en especial uno experimentado, es tan útil como aconsejar "Cocinar como un Chef" o "Jugar como un Futbolista Profesional". Claro, podemos hacer el intento, pero difícilmente será lo más efectivo que podamos hacer tomando en cuenta que no solo ésto requiere una forma distinta de interactuar con el Software, sino tambien conlleva una experiencia y una intuición que solamente se adquiere con práctica deliberada de muchos años.

Esto es incluso más complicado como desarrolladores, ya que presentamos un prejuicio por defecto en la forma de evaluar los sistemas que nosotros mismos construímos. Los desarrolladores podrán ver esto al momento de crear sus pruebas unitarias o funcionales, donde el reto conlleva seguir lineamientos que nos permitan probar las cosas de la manera mas imparcial posible y no nada mas las rutas las cuales estamos mas acostumbrados.

Por lo tanto, necesitamos una estrategia que nos ayude a remover el bias y nos haga concentrarnos en como poder crear software más seguro de una manera estructurada que nos evite "tirar balas al aire".

Sin embargo, antes de comenzar con cualquier estrategia, es importante dejar muy claro nuestro propósito, es decir, ¿qué es lo que esperamos lograr?.

Existen 4 preguntas esenciales las cuales buscamos responder en el proceso de crear Software seguro.

  1. ¿Qué es lo que estamos construyendo?
  2. ¿Qué es lo que puede salir mal?
  3. ¿Qué podemos hacer al respecto cuando éstas ocurran?
  4. ¿Qué tan fiable es nuestro diagnóstico de todo esto?

Si bien podemos contestar a grandes rasgos cada una de estas preguntas, difícilmente vamos a ser exhaustivos. Por eso es importante aplicar un modelo que nos permita cubrir las cosas mas importantes.

Modelado de Amenazas

El Modelo de Amenazas se refiere al proceso por el cual identificamos, enumeramos y prioritizamos cualquier tipo de amenaza relevante con algún sistema o producto. Éste proceso nos permite llevar a cabo un análisis sistemático acerca de los posible vectores que pueden ser usados por un atacante y posteriormente prioritizar el impacto para poder determinar el riesgo.

En pocas palabras, es el uso de abstracciones para eficientar el análisis de los riesgos.

STRIDE

STRIDE es un nemónico que representá varias de las cosas que pueden salir mal en la seguridad de un sistema. Tiene su origen utilizado en Microsoft como una herramienta para facilitar el razonamiento de las posibles amenazas que un sistema puede enfrentar.

  • [S]poofing
    Pretender ser alguien o algo que no eres.

    Un ataque de phishing donde te haces pasar por un sitio legítimo utilizando uno réplica es una forma de hacer un spoof y engañar a los usuarios que se conecten permitiendo el robo de contraseñas.

  • [T]ampering
    Modificar algo que no deberías poder modificar.

    El hecho de que un estudiante sea capaz de modificar su boleta de calificaciones en la base de datos de su escuela.

  • [R]epudiation
    Afirmar que no fuiste responsable de alguna acción, incluso cuando así fue el caso.

    ¿Que sucedería si un usuario efectuó una compra por medio de nuestra plataforma de marketplace pero no contamos con bitácoras de cuando y como se llevó a cabo?

  • [I]nformation Disclosure
    Exponer información que no deberían ser vista por otros.

    Un ejemplo de esto es cuando aplicaciones web permiten el acceso a archivos dentro del Document Root y éstos pueden ser vistos sin requerir autenticación alguna.

  • [D]enegation of Service
    Evitar que un sistema sea capaz de proveer su servicio.

    Un ataque de denegación de servicio puede ocurrir cuando se abusa de manera indiscriminada algún recurso que imposibilita que usuarios puedan acceder de forma legítima. Bloquear un usuario al intentar múltiples intentos de Login es una forma de provocar esta denegación en algunas plataformas.

  • [E]levation of Privilege
    El hecho de que un programa o individuo sea capaz de asumir privilegios a recursos que no debería originalmente.

    Un ejemplo sería una vulnerabilidad que falle en enforzar permisos de solo lectura a un usuario de pocos privilegios permitiendole modalidad de escritura en recursos que originalmente no debería de poder modificar.

    En el siguiente post...

    Ahondaremos mas en el concepto de Modelado de Amenazas aplicando STRIDE en ejemplos mas concretos.

Referencias