0

Modelado de amenazas

seguridad-hacker-cibercriminal7 errores que probablemente esté cometiendo

El Proyecto de seguridad de aplicaciones web abiertas (OWASP, por sus siglas en inglés) describe el modelado de amenazas como un enfoque estructurado para identificar, cuantificar y abordar los riesgos de seguridad asociados con una aplicación. En esencia, implica pensar estratégicamente sobre las amenazas al construir o implementar un sistema, para que los controles adecuados en prevención o mitigación de las amenazas se puedan implementar más temprano en el ciclo de vida de la aplicación.

El modelado de amenazas como concepto ciertamente no es nuevo, pero pocas organizaciones lo han implementado de manera significativa. Las mejores prácticas para los modelos de amenazas aún están surgiendo, señala Archie Agarwal, fundador y CEO de ThreatModeler Software. “El mayor problema es la falta de comprensión acerca de qué se trata el modelado de amenazas”, añade. Existen múltiples formas de hacer modelos de amenazas y las empresas a menudo pueden tener problemas para descubrir cómo verlo como un proceso y cómo escalarlo. “Todavía hay una falta de claridad en todo el asunto”.

Aquí, de acuerdo con Agarwal y otros, hay siete errores que probablemente cometa al hacer un modelado de amenazas:

1- Estar demasiado centrado en la aplicación
Uno de los errores más comunes que cometen las organizaciones cuando construyen un modelo de amenaza es centrarse únicamente en la aplicación en sí, anota Agarwal. Con el modelado de amenazas, debe tratar de comprender el panorama general y no solo una aplicación aislada, añade.

Considere la infraestructura, la base de datos, los componentes compartidos, las interacciones de terceros y el entorno de despliegue. Las amenazas pueden variar en función de si una aplicación es local o si se está ejecutando en la nube, o si se puede acceder mediante dispositivos móviles y otros puntos finales de computación.

Si se está moviendo a la nube, necesita un modelo de amenaza para la nube. ¿Sus aplicaciones y datos se ejecutarán en una infraestructura dedicada o servidores y bases de datos compartidos? Es fundamental recordar que cuando se modela la amenaza, no solo se debe mirar a la aplicación sino a todo lo que la toca, indica Agarwal. Los desarrolladores necesitan pensar en algunas soluciones cuando construyen una aplicación y las operaciones que necesitan manejar cuando se implementa la aplicación.

2- Enfocarse en las vulnerabilidades y no en las amenazas
Un error que pueden cometer las organizaciones es centrarse demasiado en las vulnerabilidades y no lo suficiente en las amenazas, señala Pete Lindstrom, analista de IDC. Sin duda, es importante observar el flujo de datos y el flujo de control y saber qué vulnerabilidades pueden existir en sus aplicaciones. Además, debe analizar las amenazas de manera más explícita e identificar las entradas y salidas donde pueda estar en riesgo. Debe pensar en todas las oportunidades que tiene un atacante para impedir que sus controles afecten la confidencialidad, la integridad, la disponibilidad, la productividad y la naturaleza propietaria de sus datos.

“En este momento estamos hablando de que Meltdown y Spectre son ataques contra la confidencialidad”, señala Lindstrom. “Pero, ¿qué pasa con la integridad o la disponibilidad? ¿Hay formas para que los atacantes manipulen esas tablas de memoria o inserten datos?” El hecho de que tenga controles contra un exploit específico, no significa que un atacante no encuentre nuevas formas de aprovechar un error.

3- Enfocarse demasiado en la amenaza del día
No se apresure después de las últimas amenazas ni preste demasiada atención a actores o tipos de actores específicos de amenazas al construir modelos de amenazas, señala John Pescatore, director de tendencias de seguridad emergentes en el Instituto SANS. El software ransomware y cryptomining podría presentar las mayores amenazas actuales a su seguridad. En lugar de modelar específicamente contra estas amenazas, concéntrese en los controles para mitigar cualquier amenaza a la confidencialidad, integridad y disponibilidad de sus sistemas.

Del mismo modo, realmente no importa si las amenazas en su contra provienen de actores chinos, rusos o serbios, indica Pescatore. El enfoque en la atribución y los piratas informáticos y las bandas delictivas patrocinadas por el estado es menos importante que saber cómo protegerse de las amenazas que representan. “Que le digan que los actores chinos le persiguen es menos importante que saber qué hacer al respecto”.

Su enfoque debe estar en construir procesos repetibles para que cada vez que algo cambie, esté preparado para ello. La clave es tener un proceso o metodología estándar que se haga de la misma manera en cada momento, independientemente de la novedad de una amenaza. Debe saber qué es lo que estás tratando de proteger y comenzar desde allí, añade Pescatore.

4- Mapeo de amenazas confusas para modelar amenazas
Si su idea de crear un modelo de amenaza funciona a partir de una lista de amenazas y ver si su aplicación tiene alguna de ellas, lo único que está haciendo es un mapeo de amenazas, señala Agarwal. “Digamos que tiene una aplicación de banca en línea y hace una serie de preguntas como ‘¿está usando Flash?’ o ‘¿está usando Java?’ o ‘¿está haciendo autenticación?’, anota Agarwal. Lo que está haciendo aquí no es modelar amenazas, porque realmente no tienes contexto alrededor de las amenazas. No sabe cómo está usando Flash o dónde lo está usando.

Del mismo modo, el hecho de que tenga una base de datos no significa automáticamente que deba preocuparse por la inyección SQL como un vector de ataque. La inyección SQL se convierte en una preocupación potencial solo si también tiene una aplicación web que acepta la entrada desde una fuente externa. Este tipo de matiz es fácil de perder cuando se toma un enfoque de lista de verificación para evaluar las amenazas, indica Agarwal.

Para construir un modelo de amenaza adecuado, es crítico un diagrama de arquitectura. Debe mostrarle la base de datos, el servidor web, la capa del sistema operativo, y la infraestructura en la que se ejecutará la aplicación y a través de la cual se accede. Debe mostrar dónde fluyen todos los datos y la comunicación, dónde están los puntos de entrada y qué tipo de información proviene de esos puntos de entrada. Un diagrama de arquitectura muestra el panorama general y también los casos extremos, indica Agarwal.

5- No llevar al usuario al modelo de amenaza
Hay una tendencia a centrarse demasiado en cómo un adversario puede atacar el código, y no lo suficiente en otras formas que pueden utilizar para obtener sus aplicaciones y datos. “Es buena idea amenazar el modelo de cómo los chicos atacan el código”, indica Pescatore. “Pero la protección contra un ataque de phishing no es algo que pueda incorporar a la aplicación”.

Debe incluir al usuario en el modelo de amenaza y considerar las diferentes formas en que las acciones de los usuarios pueden afectar la seguridad. Necesita ver cosas como administración de privilegios y acceso basado en roles. Debe considerar posibles amenazas cuando los usuarios accedan a la aplicación en la nube, o a través de una aplicación móvil que podría ser parte de un esquema de comercio electrónico más grande, indica Pescatore.

5- Tomando un enfoque de ‘una vez y listo’ para modelar amenazas
Un modelo de amenaza no puede ser estático. No puede tomar una aplicación crítica, hacer un modelo de amenaza una vez y asumir que ha terminado, advierte Agarwal. Si su organización es como la mayoría, se está llevando a cabo una actividad continua de desarrollo. A medida que su aplicación cambia, su perfil de amenaza también lo hace. Eso significa que su modelo de amenaza actual estará obsoleto en tres meses. “Su modelo de amenaza debe ser un documento vivo”, anota Agarwal. “No se puede simplemente construir un modelo de amenaza y olvidarse de eso. Sus aplicaciones están vivas”.

6- No tener en cuenta cómo es que sus sistemas afectan a otros
Al construir un modelo de amenaza, es buena idea considerar qué tan confiable es digitalmente. Una vez que haya contabilizado todas las amenazas que enfrenta, y haya determinado los controles o mitigaciones para ellas, observe cómo los sistemas de su organización podrían afectar a otras personas que entran en contacto con ellas.

Debe prestar atención a cómo es que sus resultados pueden afectar la postura de seguridad de los demás, indica Lindstrom. “Podría, por ejemplo, albergar un sitio del mercado negro o alguien podría estar ocupando sus dominios o rebotando paquetes DDoS de sus sistemas de la IoT”. Es posible que no acepte bloqueadores de anuncios, pero ¿qué sucede si un anuncio malicioso en su sitio infecta sistemas de clientes? A medida que coloca las cosas en línea, es su responsabilidad mantenerlas limpias para que los usos posteriores no se vean afectados por el uso de sus sistemas. Dicha diligencia debe ser parte de su modelo de amenazas, tanto desde el punto de vista de confiabilidad digital como de responsabilidad, indica Lindstrom.

Como parte del ejercicio de modelado de amenazas, asegúrese de comprender los riesgos asociados con el software de código abierto y los componentes de terceros, no solo para su organización, sino también para los usuarios intermedios de sus servicios. Si está ofreciendo mashups, por ejemplo, debe pensar en cómo sus datos o servicios pueden afectar los resultados de otras personas. “Si alguien más está confiando en los datos del GPS que provienen de usted, debe estar pensando en la integridad y confiabilidad de esos datos”, señala Lindstrom.

Jaikumar Vijayan, CSO.com – CIOPeru.pe

 

Ordenado por: Seguridad Tags: 

TOT

 

 

Contenidos recomendados...

Comparta esta publicación

Artículos relacionados

Escriba su comentario

Ud. tiene que estar conectado para publicar comentarios.

Red de publicaciones IDG en Latinoamérica: Computerworld Ecuador - Computerworld Colombia - CIO Perú // Contáctenos
© 2018 Computerworld Venezuela - All rights reserved ---- WordPress - Tema adaptado por GiorgioB