¿Cuáles son los 10 mejores de OWASP?

El OWASP Top 10 es un informe actualizado periódicamente que describe la lista de los 10 principales problemas de seguridad para la seguridad de las aplicaciones web.

El informe ha sido elaborado por un equipo de expertos en seguridad de todo el mundo. OWASP se refiere al Top 10 como un "documento de concienciación" y recomienda a todas las empresas que incorporen los hallazgos del informe en los procesos de ciberseguridad.

¿Qué es OWASP?

El Open Web Application Security Project (OWASP) es una organización internacional sin ánimo de lucro dedicada a mejorar la seguridad de las aplicaciones web.

OWASP produce artículos, metodologías, documentación, herramientas y tecnologías disponibles gratuitamente, lo que hace posible que cualquier persona mejore la seguridad de sus aplicaciones web.

El OWASP Top 10 es uno de sus proyectos más conocidos.

¿Cuáles son los 10 principales riesgos de seguridad de las aplicaciones web?

1. Inyección

Los ataques de inyección ocurren cuando se envían datos no validados o no confiables a un intérprete de código a través de la entrada de formularios u otro campo de envío de datos a una aplicación web.

Los ataques de inyección exitosos pueden resultar en fugas de datos, corrupción de datos, violaciones de datos, pérdida de responsabilidad y denegación de acceso.

Casi cualquier fuente de datos puede ser un vector de inyección, incluidas las variables de entorno, los parámetros, los servicios web externos e internos y todo tipo de usuarios.

Por ejemplo, un atacante podría inyectar código SQL en un formulario que espera un nombre de usuario de texto sin formato. Si el desarrollador de la aplicación web no ha desinfectado correctamente la entrada, podría resultar en la ejecución del código SQL. Esto se conoce como ataque de inyección SQL.

La inyección SQL no es el único defecto de inyección. Las vulnerabilidades comunes incluyen XPath, NoSQL, inyecciones LDAP, así como comandos del sistema operativo, analizadores XML, encabezados SMTP, lenguajes de expresión y consultas ORM.

En general, una aplicación es vulnerable si:

La entrada del usuario no se valida, filtra ni desinfecta
Las consultas dinámicas o las llamadas no parametrizadas sin escape contextual se utilizan directamente en el intérprete
Los datos hostiles se utilizan dentro de los parámetros de búsqueda de mapeo relacional de objetos (ORM) para extraer registros confidenciales
Los datos hostiles se usan o concatenan directamente, de modo que el SQL o el comando contienen la estructura y los datos hostiles en consultas dinámicas, comandos o procedimientos almacenados

Para evitar ataques de inyección, la entrada del usuario debe validarse y/o desinfectarse y, cuando sea posible, utilizar una API que evite por completo el uso del intérprete.

Para la entrada del lado del servidor, la validación de entrada de la lista blanca y el uso de LIMIT y otros controles SQL dentro de las consultas para minimizar la cantidad de datos confidenciales que se pueden exponer.

Para obtener más información sobre cómo prevenir los ataques de inyección, OWASP recomienda:

Controles proactivos de OWASP: Parametrizar consultas
OWASP ASVS: Validación y codificación de entrada V5
Guía de pruebas de OWASP: inyección SQL, inyección de comandos e inyección de ORM
Hoja de trucos de OWASP: Prevención de inyecciones
Hoja de trucos de OWASP: Prevención de inyecciones SQL
Hoja de trucos de OWASP: Prevención de inyecciones en Java
Hoja de referencia de OWASP: Parametrización de consultas
OWASP Amenazas Automatizadas a Aplicaciones Web - OAT-014
CWE-77: Inyección de comandos
CWE-89: Inyección SQL
CWE-564: Inyección de hibernación
CWE-917: Inyección de lenguaje de expresión
PortSwigger: Inyección de plantillas del lado del servidor

2. Autenticación rota

Los sistemas de autenticación son algunos de los sistemas peor diseñados y/o implementados en muchas aplicaciones web. Además, la gestión de sesiones es la base de cualquier sistema de autenticación y control de acceso y está presente en todas las aplicaciones con estado.

Estas vulnerabilidades pueden ser detectadas por un atacante utilizando medios manuales y explotadas mediante herramientas automatizadas, ataques de fuerza bruta y herramientas de ataque de diccionario. Lee nuestra publicación completa sobre los ataques de fuerza bruta aquí.

La tasa de éxito de estos ataques puede ser alta. Cientos de millones de combinaciones de nombres de usuario y contraseñas han quedado expuestas en grandes filtraciones de datos. Y muchas personas reutilizan contraseñas en todos los servicios o no se molestan en cambiar las credenciales de inicio de sesión administrativas predeterminadas.

Además, los ataques de gestión de sesiones, como el secuestro de cookies, son bien conocidos y fácilmente explotables.

OWASP afirma que una aplicación web tiene una autenticación deficiente si:

Permite ataques automatizados, por ejemplo, relleno de credenciales
Permite ataques de fuerza bruta u otros ataques automatizados
Permite contraseñas predeterminadas, débiles o conocidas (lea nuestra lista de verificación de seguridad de contraseñas)
Utiliza flujos de recuperación de credenciales débiles o ineficaces u olvido de contraseñas, que se basan en respuestas basadas en conocimientos que pueden exponerse en las redes sociales.
Utiliza contraseñas de texto sin formato, sin cifrar o con hash débil
Tiene autenticación multifactor faltante o ineficaz (por ejemplo, sin 2FA y biometría)
Expone los ID de sesión en la dirección URL
No rota los ID de sesión después de iniciar sesión
No invalida correctamente los tokens de sesión

Hay varias formas de prevenir los ciberataques que explotan la autenticación deficiente o rota, entre ellas:

Autenticación multifactor que evita el relleno automatizado de credenciales, la fuerza bruta y los ataques de reutilización de credenciales robadas
Nunca usar credenciales predeterminadas
Comprobaciones de contraseñas débiles que no permiten las 10.000 peores contraseñas y las expuestas en filtraciones de datos conocidas
Alinear las políticas de longitud, complejidad y rotación de contraseñas con las directrices de NIST 800-63 B en la sección 5.1.1 para secretos memorizados
Garantizar que el registro, la recuperación de credenciales y las rutas de API estén protegidos contra ataques de enumeración devolviendo el mismo mensaje para todos los resultados
Limitar y/o aumentar el retraso de los intentos fallidos de inicio de sesión
Registrar todos los errores de inicio de sesión y alertar a su equipo de seguridad cuando se detecte relleno de credenciales, fuerza bruta u otros ataques.
Uso de la administración de sesiones integrada, segura y del lado del servidor que genera un nuevo ID de sesión aleatorio con alta entropía después del inicio de sesión
No exponer los ID de sesión en la URL
Invalidación de sesiones de usuario en tiempos de cierre de sesión, inactivos y absolutos

Para obtener más información sobre cómo prevenir ataques de autenticación rota, OWASP recomienda:

Controles proactivos de OWASP: Implementación de controles de identidad y autenticación
Estándar de verificación de seguridad de aplicaciones OWASP: autenticación V2
Estándar de verificación de seguridad de aplicaciones OWASP: gestión de sesiones V3
Guía de pruebas de OWASP: Identidad, autenticación
Hoja de trucos de OWASP: Autenticación
Hoja de trucos de OWASP: relleno de credenciales
Hoja de trucos de OWASP: Olvidé mi contraseña
Hoja de trucos de OWASP: Gestión de sesiones
Manual de amenazas automatizadas de OWASP
NIST 800-63b: 5.1.1 Secretos memorizados
CWE-287: Autenticación incorrecta
CWE-384: Fijación de sesión

3. Exposición de datos confidenciales

Muchas aplicaciones web y sus API no protegen suficientemente los datos confidenciales, como las finanzas, la PHI y la PII.

Esto significa que, en lugar de atacar el cifrado directamente, los atacantes pueden robar claves, ejecutar ataques de intermediario o robar datos de texto sin cifrar del servidor, mientras están en tránsito, del navegador de la víctima y, cada vez más, de un proveedor externo que tiene poca seguridad de la información.

A medida que las organizaciones almacenan y procesan más datos confidenciales y se introducen leyes de protección de datos en todo el mundo, esto se convierte en un mayor riesgo de ciberseguridad para cualquier aplicación web. El error más común es simplemente no cifrar los datos en absoluto.

Cuando se emplea el cifrado, la generación y administración de claves débiles, el uso débil de algoritmos, protocolos y cifrados son comunes, particularmente técnicas de almacenamiento de hash de contraseñas débiles.

La falta de protección de los datos confidenciales puede dar lugar a espionaje industrial, daños a la reputación, costes financieros y, cada vez más, medidas regulatorias. Impulsado por nuevas leyes y regulaciones, como GDPR, LGPD, CCPA, PIPEDA, HIPAA y CPS 234 que requieren la protección de PII, PHI y otra información confidencial.

Una vez expuestos, los números de tarjetas de crédito, los registros de salud, la información personal y los secretos comerciales dan lugar a fraude, robo de identidad, pérdida de posición en el mercado y delitos cibernéticos.

Para evitar la exposición de datos confidenciales, OWASP recomienda:

Clasificación de los datos procesados, almacenados o transmitidos en cubos de confidencialidad en función de las leyes, las normativas y las necesidades empresariales
Aplicación de controles adecuados para la clasificación de datos
No almacenar datos confidenciales a menos que sea necesario
Cifrado de datos confidenciales en reposo
Garantizar que los algoritmos de cifrado estén actualizados y sean sólidos
Uso de una gestión de claves adecuada
Cifrado de datos en tránsito con protocolos seguros (por ejemplo, TLS)
Aplicación del cifrado a través de HTTP Strict Transport Security (HSTS)
No almacenar en caché datos confidenciales
Almacenamiento de contraseñas utilizando funciones de hash seguras, adaptables y saladas, por ejemplo, Argon2, scrypt, bcrypt o PBKDF2.
Verificación de la eficacia de la configuración y los ajustes

UpGuard BreachSight puede ayudarle a detectar credenciales filtradas y datos expuestos antes de que caigan en las manos equivocadas. Pudimos detectar los datos expuestos en un repositorio de GitHub por un ingeniero de AWS en 30 minutos. Pudimos hacer esto porque descubrimos activamente conjuntos de datos expuestos en la web abierta y profunda, rastreando buckets de S3, repositorios públicos de GitHub y servidores RSync y FTP no seguros.

Para obtener más información sobre cómo prevenir la exposición de datos confidenciales, OWASP recomienda:

Controles proactivos de OWASP: Proteger los datos
Estándar de verificación de seguridad de aplicaciones OWASP (V7, 9, 10)
Hoja de trucos de OWASP: Protección de la capa de transporte
Hoja de trucos de OWASP: Protección de la privacidad del usuario
Hoja de trucos de OWASP: contraseña y almacenamiento criptográfico
Hoja de trucos de OWASP: HSTS
Guía de pruebas de OWASP: Pruebas de criptografía débil
CWE-220: Exposición de información sensorial a través de consultas de datos
CWE-310: Problemas criptográficos
CWE-311: Falta el cifrado
CWE-312: Almacenamiento de texto sin cifrar de información confidencial
CWE-319: Transmisión de texto sin cifrar de información confidencial
CWE-326: Cifrado débil
CWE-327: Cripto rota/arriesgada
CWE-359: Exposición de Información Privada (Violación de la Privacidad)

4. XML Entidades Externas (XXE)

Los atacantes pueden aprovecharse de los procesadores vulnerables del lenguaje de marcado extensible (XML) que cargan XML o incluyen contenido hostil en un documento XML.

Esto se debe a que muchos procesadores XML antiguos permiten la especificación de una entidad externa, por ejemplo, un disco duro.

Esto significa que, al igual que los ataques de inyección, se puede obligar a los analizadores XML a enviar datos a una entidad externa no autorizada, que a su vez pasa los datos confidenciales directamente a un atacante.

Estas fallas también se pueden usar para ejecutar solicitudes remotas desde el servidor, escanear sistemas internos y realizar ataques de denegación de servicio.

Para evitar ataques XXE:

Utilice formatos de datos simples (como JSON) y evite la serialización de datos confidenciales
Parchear o actualizar todos los procesadores y bibliotecas XML en uso
Deshabilitar el procesamiento de entidades externas XML y DTD en analizadores XML
Entrada del lado del servidor de la lista blanca
Valide, filtre o desinfecte la entrada para evitar datos hostiles dentro de documentos, encabezados y nodos XML
Compruebe que la funcionalidad de carga XML y XSL valida el XML entrante mediante la validación XSD o algo similar
Revise manualmente el código y utilice las herramientas SAST para ayudar a detectar XXE en el código fuente.

Para obtener más información sobre cómo prevenir los ataques XXE, OWASP recomienda:

Estándar de verificación de seguridad de aplicaciones OWASP
Guía de pruebas de OWASP: Pruebas para la inyección XML
Vulnerabilidad de OWASP XXE
Hoja de trucos de OWASP: Prevención XXE
Hoja de trucos de OWASP: Seguridad XML
CWE-611: Restricción indebida de XXE
Ataque de mil millones de risas
Ataque a entidades externas XML de seguridad SAML
Detección y explotación de XXE en interfaces SAML

5. Control de acceso roto

El control de acceso se refiere a los sistemas que controlan el acceso a la información o funcionalidad.

Una implementación deficiente del control de acceso permite a los atacantes eludir la autorización o realizar tareas como si fueran usuarios privilegiados.

Por ejemplo, una aplicación web puede permitir a un usuario cambiar la cuenta en la que ha iniciado sesión cambiando parte de la URL, sin ninguna verificación adicional.

Las vulnerabilidades comunes de seguridad del control de acceso incluyen:

Omitir las comprobaciones de control de acceso modificando la URL, el estado interno de la aplicación, el HTML de la página web o mediante una herramienta de ataque de API personalizada
Permitir que la clave principal se cambie a otro registro de usuario, permitiendo la visualización o edición de la cuenta de otro usuario
Ataques de escalada de privilegios que se hacen pasar por un usuario o permiten que un usuario se haga pasar por un administrador
Manipulación de metadatos, como la reproducción o manipulación de un token web JSON (JWT), un token de control de acceso, una cookie o un campo oculto
Configuración incorrecta de CORS que permite el acceso no autorizado a la API
Forzar la navegación a páginas autenticadas como un usuario no autenticado o a páginas con privilegios como un usuario estándar

Para evitar el acceso al control de acceso, asegúrese de que las comprobaciones de control de acceso y los metadatos no se puedan modificar mediante:

Denegar el acceso de forma predeterminada (el principio de privilegios mínimos)
Implementar mecanismos de control de acceso una vez y reutilizarlos en toda la aplicación
Aplicar la propiedad del registro en lugar de aceptarlo, los usuarios pueden crear, leer, actualizar o eliminar cualquier registro
Deshabilitación de la lista de directorios del servidor web
Garantizar que los metadatos y los archivos de copia de seguridad no estén presentes en las raíces web
Registrar los fallos de control de acceso y alertar al equipo de seguridad cuando sea necesario
Limitación de velocidad de las API y el acceso a los controladores para minimizar el impacto de los ataques automatizados
Invalidación de tokens JWT al cerrar sesión

Para obtener más información sobre cómo evitar vulnerabilidades de control de acceso, OWASP recomienda:

Controles proactivos de OWASP: Controles de acceso
Estándar de verificación de seguridad de aplicaciones OWASP: control de acceso V4
Guía de pruebas de OWASP: Pruebas de autorización
Hoja de trucos de OWASP: Control de acceso
CWE-22: Limitación incorrecta de un nombre de ruta a un directorio restringido ('recorrido de ruta')
CWE-284: Control de Acceso Inadecuado (Autorización)
CWE-285: Autorización indebida
CWE-639: Omisión de autorización a través de KeyPortSwigger controlado por el usuario: Explotación de la configuración incorrecta de CORS

6. Configuración incorrecta de la seguridad

Los atacantes pueden aprovechar las vulnerabilidades de las aplicaciones sin parches o acceder a cuentas predeterminadas, páginas no utilizadas, páginas no protegidas y directorios para obtener acceso no autorizado a un sistema o recopilar información sobre él.

La configuración incorrecta puede ocurrir en cualquier nivel de una pila de aplicaciones, incluidos los servicios de red, la plataforma, el servidor web, el servidor de aplicaciones, la base de datos, los marcos, el código personalizado, las máquinas virtuales preinstaladas, los contenedores y el almacenamiento.

Para evitar errores de configuración:

Implementación de una política de gestión de configuración automatizada
Ejecute un proceso de protección repetible que facilite la implementación de otro entorno seguro. Consulte nuestra lista de verificación de protección de Windows Server
Utilice una plataforma mínima sin características, componentes, documentación ni ejemplos innecesarios
Implementar procesos de gestión de vulnerabilidades
Segmente la arquitectura de aplicaciones para separar componentes o inquilinos con segmentación, contenedorización o grupos de seguridad en la nube

La configuración incorrecta no termina con su organización. Utilice UpGuard Vendor Risk para enviar cuestionarios de seguridad a terceros y sus calificaciones de seguridad para detectar automáticamente problemas y vulnerabilidades de configuración de primeras, terceras y cuartas partes.

Para obtener más información sobre cómo evitar errores de configuración, OWASP recomienda:

Guía de pruebas de OWASP: Gestión de la configuración
Guía de pruebas de OWASP: Pruebas de códigos de error
Guía del NIST para la protección general del servidor
CWE-2: Fallas de seguridad ambiental
CWE-16: Configuración
CWE-388: Manejo de errores
Guías/puntos de referencia de configuración de seguridad CIS
Detección y enumeración de buckets de Amazon S3

7. Secuencias de comandos entre sitios (XSS)

Las secuencias de comandos entre sitios (XSS) se producen cuando las aplicaciones web permiten a los usuarios agregar código personalizado a una ruta de URL o a un sitio web que será visto por otros usuarios.

Estas vulnerabilidades se pueden aprovechar para ejecutar JavaScript malicioso en el navegador de la víctima.

Por ejemplo, un atacante podría enviar un correo electrónico de phishing a una víctima que parezca ser de su banco, con un enlace al sitio web legítimo del banco.

Si el banco no evita el scripting entre sitios, el atacante podría agregar JavaScript malicioso al final de la URL y ejecutarlo cuando se haga clic en el enlace.

Los atacantes también pueden usar XSS para detener cualquier defensa automatizada de falsificación de solicitudes entre sitios (CSRF).

Para evitar el scripting entre sitios:

Utilice marcos modernos que escapan a XSS por diseño, como Ruby on Rails o React
Conozca las limitaciones de la protección XSS de un marco y maneje adecuadamente las excepciones
Escape de solicitudes HTTP que no son de confianza
Valide, filtre o desinfecte el contenido generado por el usuario
Uso de una política de seguridad de contenido (CSP) como control de defensa en profundidad

Para obtener más información sobre cómo prevenir el XSS, OWASP recomienda:

Controles proactivos de OWASP: Codificación de datos
Controles proactivos de OWASP: Validar datos
Estándar de verificación de seguridad de aplicaciones OWASP: V5
Guía de prueba de OWASP: Pruebas de XSS reflejado
Guía de pruebas de OWASP: Pruebas para XSS almacenado
Guía de pruebas de OWASP: Pruebas para DOM XSS
Hoja de trucos de OWASP: Prevención de XSS
Hoja de trucos de OWASP: Prevención de XSS basada en DOM
Hoja de trucos de OWASP: Evasión de filtro XSS
Proyecto de codificador Java OWASP
CWE-79: Neutralización incorrecta de la entrada suministrada por el usuario
PortSwigger: Inyección de plantillas del lado del cliente

8. Deserialización insegura

Este riesgo de seguridad web se dirige a las aplicaciones web que serializan y deserializan datos con frecuencia.

La serialización es el proceso de traducir estructuras de datos o estados de objetos a un formato que se puede almacenar o transmitir, y luego reconstruir más tarde.

La deserialización es lo contrario, ya que convierte los datos serializados en objetos que la aplicación puede usar.

Cuando se deserializan los datos de una fuente que no es de confianza, pueden dar lugar a ataques DDoS y a la ejecución remota de código.

Para evitar la deserialización insegura:

Implemente comprobaciones de integridad, como firmas digitales, en cualquier objeto serializado para evitar la creación de objetos y la manipulación de datos
Aplicación de restricciones de tipo estrictas durante la deserialización y antes de la creación de objetos
Aísle y ejecute código de deserialización en entornos con pocos privilegios
Registrar excepciones y errores, como cuando el tipo entrante no es el tipo esperado o cuando se produce una excepción
Restrinja y supervise el tráfico de red entrante y saliente de contenedores o servidores que deserializan
Supervise la deserialización y alerte a DevOps si un usuario se deserializa constantemente

Para obtener información sobre cómo evitar la deserialización insegura, OWASP recomienda:

Hoja de trucos de OWASP: Deserialización
Controles proactivos de OWASP: Validar todas las entradas
Estándar de verificación de seguridad de aplicaciones OWASP
OWASP AppSecEU 2016: Sobreviviendo al apocalipsis de la deserialización de Java
OWASP AppSecUSA 2017: Viernes 13 Ataques JSON
CWE-502: Deserialización de datos que no son de confianza
Seguridad del Deserializador de Java
OWASP AppSec Cali 2015: Clasificación de pepinillos

9. Uso de componentes con vulnerabilidades conocidas

El uso de bibliotecas y marcos está en aumento, lo que puede introducir componentes vulnerables que los atacantes pueden explotar.

Estos componentes aceleran el desarrollo de software, lo que ayuda a los desarrolladores a evitar el trabajo redundante y proporciona la funcionalidad necesaria.

Algunos ejemplos comunes son los frameworks de front-end como React, los frameworks de back-end como Ruby on Rails, los iconos compartidos o las soluciones de pruebas A/B.

Los componentes más populares son utilizados por millones de sitios web, lo que significa que si los atacantes pueden encontrar problemas de seguridad en uno, pueden dejar expuestas millones de aplicaciones web.

Los desarrolladores de componentes emiten parches y actualizaciones de seguridad de software para corregir o mitigar vulnerabilidades conocidas (como las enumeradas en CVE), pero los desarrolladores no siempre instalan parches ni utilizan la versión más reciente de los componentes.

Para minimizar este riesgo, los desarrolladores deben eliminar los componentes no utilizados y asegurarse de que reciben componentes de una fuente de confianza, ya que los sitios maliciosos pueden publicarse como proyectos de código abierto para propagar malware.

Para evitar vulnerabilidades conocidas, OWASP recomienda:

Estándar de verificación de seguridad de aplicaciones OWASP: Arquitectura, diseño y modelado de amenazas V1
Comprobación de dependencias de OWASP (para bibliotecas Java y .NET)
Guía de pruebas de OWASP - Arquitectura de aplicaciones de mapas (OTG-INFO-010)
Mejores prácticas de parches virtuales de OWASP
La desafortunada realidad de las bibliotecas inseguras
Búsqueda de vulnerabilidades y exposiciones comunes (CVE) de MITRE
Base de Datos Nacional de Vulnerabilidades (NVD)
Retire.js para detectar bibliotecas de JavaScript vulnerables conocidas
Avisos de seguridad de bibliotecas de nodos
Base de datos y herramientas de asesoramiento de seguridad de Ruby Libraries

10. Registro y monitoreo insuficientes

Muchas aplicaciones web no toman las medidas necesarias para detectar violaciones de datos. De hecho, el tiempo promedio de descubrimiento para la detección de brechas fue de 206 días en 2019.

Esto puede dar a los atacantes mucho tiempo para causar daños antes de que los planes de respuesta a incidentes puedan ponerse en marcha.

OWASP recomienda que las aplicaciones:

Asegúrese de que todos los errores de inicio de sesión, control de acceso y validación de entrada del lado del servidor se registren con suficiente contexto para identificar cuentas sospechosas o maliciosas y se mantengan durante el tiempo suficiente para permitir un análisis forense retrasado
Tener registros generados en un formato que pueda ser fácilmente consumido por una solución de administración de registros centralizada
Disponer de un registro de auditoría para las transacciones de alto valor con controles de integridad para evitar la manipulación o la eliminación, como las tablas de base de datos de solo anexar
Contar con un monitoreo y alertas efectivos para que las actividades sospechosas puedan ser detectadas y respondidas de manera oportuna
Establecer un plan de respuesta a incidentes y un plan de recuperación ante desastres como se describe en NIST 700-61 rev 2

Para leer más, OWASP recomienda:

Controles proactivos de OWASP: Implemente el registro y la detección de intrusiones
Estándar de verificación de seguridad de aplicaciones OWASP: registro y monitoreo V8
Guía de prueba de OWASP: Prueba de código de error detallado
Hoja de trucos de OWASP: Registro
CWE-223: Omisión de Información Relevante para la Seguridad
CWE-778: Registro insuficiente

UpGuard Vendor Risk puede minimizar la cantidad de tiempo que su organización dedica a evaluar los controles de seguridad de la información relacionados y de terceros mediante la automatización de cuestionarios de proveedores y el suministro de plantillas de cuestionarios de proveedores.

Podemos ayudarlo a monitorear continuamente los controles de seguridad externos de sus proveedores y proporcionar una calificación de seguridad imparcial basada en el análisis de 70+ vectores de ataque, que incluyen:

Susceptibilidad a los ataques de intermediario
Certificados SSL/TLS inseguros
Ajustes SPF, DKIM y DMARC
Seguridad de transporte estricta HTTP (HSTS)
Riesgo de suplantación de identidad y phishing por correo electrónico
Vulnerabilidades
Susceptibilidad al malware
Puertos innecesarios de administración abierta, bases de datos, aplicaciones, correo electrónico y uso compartido de archivos
Exposición a filtraciones de datos y filtraciones de datos conocidas
Software vulnerable
Accesibilidad HTTP
Configuración segura de cookies
Resultados de los cuestionarios de seguridad inteligente