| 4 min de lectura
Sin duda, los recientes acontecimientos en relación con la vulneración de la privacidad, tales como el robo de información personal de celebridades, los ciberataques sobre Sony, Target y Equifax, y el gran ransomware que afectó a Telefónica, nos hacen reflexionar sobre cómo las organizaciones protegen su información.
En una economía ampliamente influenciada por la era digital, en la que las plataformas tecnológicas se integran cada vez más en las empresas y en la que los cambios y los tiempos de salida al mercado tienen que ser cada vez más rápidos, los riesgos de ciberseguridad para las compañías están en aumento. Más aún cuando estas se centran únicamente en cumplir con estándares de seguridad exigidos en lugar de ser realmente conscientes de lo que está ocurriendo y de aquello de los que se están protegiendo.
En un afán por sentirse seguras a un costo muy bajo, muchas compañías incurren en grandes riesgos al ejecutar “buenas pruebas de seguridad”. Creen que estas evaluaciones baratas son suficiente para demostrar que son seguras, que pueden satisfacer las necesidades de negocio y que es adecuado lanzar su software a producción.
Es aquí donde entran en juego los llamados "lamers", que son esencialmente individuos u organizaciones que no solo afirman tener una determinada pericia que en realidad no poseen, sino que además no están dispuestos a aprender. Las sociedades tecnológicas acuden a llamarles la atención y a tacharlos de incompetentes. En términos sencillos, un lamer es alguien que tiene conocimientos por debajo de la media, algunas herramientas a su disposición y, obviamente, sabe utilizar Google.
Pero, ¿qué tiene que ver un lamer con la sensación de seguridad de tu compañía?
Las pruebas de seguridad se encuentran entre los procesos y controles que las empresas implementan para protegerse. Las organizaciones creen que están cumpliendo con los estándares de pruebas de seguridad requeridos cuando implementan herramientas específicas que realizan escaneos de vulnerabilidades para cumplir con lo que sus áreas de seguridad exigen a los equipos de desarrollo para aprobar cada lanzamiento de software. Sin embargo, si no está clara la diferencia entre escaneo de vulnerabilidades y hacking ético o pentesting se puede crear una falsa sensación de seguridad, poniendo en riesgo a las organizaciones.
Un escaneo o análisis de vulnerabilidades es una prueba realizada por una herramienta automatizada para verificar si el objetivo de evaluación (ToE, por su nombre en inglés) tiene vulnerabilidades conocidas previamente reportadas en una base de datos central como el CVE (Common Vulnerabilities and Exposures). Esto implica que el escaneo de vulnerabilidades por sí solo no es capaz de descubrir vulnerabilidades de día cero. Cualquiera (un lamer) es capaz de ejecutar una herramienta automatizada. Sin embargo, el trabajo más difícil viene después, analizando los resultados y descartando los falsos positivos (cerca del 35% de lo que es reportado).
Un escaneo de vulnerabilidades suele identificar servicios expuestos con contraseñas por defecto, controles de autenticación débiles, software desactualizado, parches faltantes, etc. Las pruebas de seguridad basadas en herramientas automatizadas (escaneo de vulnerabilidades con explotación selectiva) no pueden detectar fallas de diseño arquitectónico e implementación desde el punto de vista del atacante. Por lo tanto, la explotación de vulnerabilidades que algunos vendedores pueden hacer a partir de estas pruebas se basa únicamente en los resultados obtenidos por los escáneres y no en la astucia y capacidad de interpretación del entorno por parte de los atacantes.
Exploit de SQL injection por acuberos@fluid.la.
A diferencia del escaneo de vulnerabilidades, el pentesting pretende simular un escenario de ataque real para evaluar el rendimiento de los controles de seguridad implementados y los impactos potenciales en los sistemas y activos de una empresa. Las pruebas de penetración permiten correlacionar vulnerabilidades, que es como un atacante trataría de causar el mayor daño posible a una empresa. Dado que los equipos de desarrolladores pueden estar modificando constantemente los sistemas de una organización, es aconsejable realizar pentesting continuos para que puedan desplegar versiones significativamente más seguras de lo que lo harían de otro modo.
Ejemplo de correlación de vulnerabilidades para ataques.
Uno de los factores más críticos que el hacking ético pretende evitar es el de los efectos potenciales de la explotación de vulnerabilidades. Esto puede lograrse ejecutando el hacking ético con una cobertura del 100%, es decir, evaluando completamente el objetivo.
La única forma de determinar la cobertura de la evaluación es delimitar correctamente la prueba que se va a realizar. Para ello debe existir una medida estándar, por lo que proponemos delimitar el hacking ético mediante un alcance conocido y previamente establecido.
La forma de lograr esto es normalizando los factores en los que se basan las pruebas. Así, si vamos a realizar pruebas de seguridad de aplicaciones, debemos determinar el número de campos de entrada. Si vamos a ejecutar pruebas de seguridad de la infraestructura, debemos establecer el número de puertos abiertos. Por último, si vamos a ejecutar análisis de código fuente, debemos definir el número de líneas de código.
Una vez definidos claramente los alcances anteriores, podemos sentirnos seguros de que todo lo relacionado con los objetivos se evaluará adecuadamente. Esto difiere de las pruebas con herramientas automatizadas, que están limitadas en función del tiempo de ejecución y solo explotan una parte de las vulnerabilidades notificadas.
A continuación, una tabla que nos ayuda a sintetizar todos los elementos descritos anteriormente:
Pentesting vs. escaneo de vulnerabilidades
Criterios | Pentesting (Fluid Attacks) | Escaneo de vulnerabilidades (otros) |
---|---|---|
Método | Híbrido (herramientas automatizadas + inteligencia de expertos) | Estático (herramientas automatizadas) |
Modelo | Red teaming | Análisis de vulnerabilidades con explotación selectiva |
Cobertura | Variable | Variable |
Definición del alcance | Basado en puertos TCP abiertos, campos de entrada de formularios visibles o invisibles y cabeceras de aplicaciones | Basado en IP/hosts y URLs |
Perfil profesional | OSCP, OSWP, CEH | CEH |
Reevaluación | Si | No |
Explotación | 100% | Variable |
Falsos positivos | No | Si (~20%) |
Creación de exploits propios | Si | No |
Vulnerabilidades de día cero | Si | No |
Tipos de hallazgos | De un impacto empresarial específico: prácticas de programación inseguras y adecuación a las normas o reglamentos de seguridad | Basado en firmas y sintaxis |
Fugas | 0% of the target of evaluation | ~65% of the target of evaluation |
Tipos de evidencias | Imágenes, GIFS o videos cortos | Resultados de las herramientas automatizadas e imágenes |
Entregables | Pruebas de explotación y sugerencias de remediación de alto nivel | Informe resumido |
Afortunadamente, cuando el pentesting se realiza con Fluid Attacks, nuestros cualificados ingenieros pueden crear fácilmente sus propios exploits gracias a sus conocimientos de programación. En muchos casos, esto les permite explotar vulnerabilidades de día cero y notificarlas lo antes posible para que las empresas puedan implementar rápidamente los controles de seguridad necesarios. Además, al realizar continuamente pruebas de penetración, las responsabilidades de seguridad no ralentizan la velocidad de desarrollo de software en las organizaciones. En resumen, el pentesting, dentro de una estrategia de gestión de vulnerabilidades, es una técnica muy beneficiosa para mejorar la detección de problemas de seguridad en los sistemas informáticos.
A partir de ahora, cuando sea necesario realizar pruebas de seguridad porque la organización o las normativas vigentes así lo exigen, pregúntese, ¿quiero protegerme contra un lamer o contra un hacker?
Comparte
Blog posts recomendados
Quizá te interesen los siguientes posts similares.
Introducción a la ciberseguridad del sector de la aviación
¿Por qué calcular riesgos de ciberseguridad con nuestra métrica CVSSF?
Nuestra nueva arquitectura de pruebas para el desarrollo de software
Protegiendo tus TPV de las ciberamenazas
Los siete ciberataques más exitosos contra esta industria
Retos, amenazas y buenas prácticas para los comerciantes
Sé más seguro aumentando la confianza en tu software