by drmunozcl
Share
Por drmunozcl
Compartir
El Fuzzing es una técnica de prueba automatizada que envía entradas aleatorias, mutadas o generadas a un objetivo para provocar fallos y descubrir vulnerabilidades. En ciberseguridad, el Fuzzing permite detectar errores de memoria, validación deficiente de datos y estados inesperados en binarios, parsers, protocolos, APIs y firmware. Su eficacia radica en la ejecución masiva y guiada por cobertura, lo que revela defectos que escapan a pruebas tradicionales.
Cómo funciona el Fuzzing
A grandes rasgos, el flujo de trabajo del Fuzzing es el siguiente:
- Definir el objetivo: binario, biblioteca, parser, protocolo o endpoint HTTP.
- Preparar un harness y un corpus de semillas representativo; instrumentar con cobertura y sanitizadores como ASan y UBSan.
- Ejecutar el fuzzer en bucle; muta o genera casos de prueba y prioriza rutas nuevas mediante cobertura.
- Monitorizar resultados: registrar bloqueos, timeouts y aserciones; reproducir y minimizar casos que fallan.
- Triaged y corrección: deduplicar por backtrace y cobertura, priorizar impactos y automatizar en CI CD para evitar regresiones.
Tipos de Fuzzing y herramientas
- Basado en mutación: altera entradas reales para explorar variaciones rápidamente. Ejemplos: AFL y AFL++, honggfuzz.
- Basado en generación: crea entradas con conocimiento del formato o protocolo, útil para gramáticas complejas.
- Guiado por cobertura: instrumenta el código y favorece casos que abren nuevas rutas. Ejemplos: libFuzzer, AFL++.
- Ecosistema: OSS-Fuzz ofrece infraestructura en la nube para proyectos open source y acelera la detección de fallos críticos.
Métricas y buenas prácticas de Fuzzing
- Cobertura alcanzada y funciones no ejercitadas.
- Crashes únicos y calidad del corpus minimizado.
- Rendimiento del fuzzer en ejecuciones por segundo y estabilidad.
- Integración en CI CD, sandboxing y limitación de recursos.
- Harnesses pequeños y deterministas; registro de semillas que reproducen fallos.
Conclusión
El Fuzzing aporta una defensa proactiva al encontrar vulnerabilidades desconocidas con alta probabilidad de explotación. Integrarlo en el ciclo de desarrollo seguro complementa SAST y DAST, reduce deuda técnica y eleva la resiliencia de software y servicios.
Relacionado
MANTENTE INFORMADO
Suscríbete a nuestro newsletter gratuito.
Cuando un ciberataque, una caída de proveedor o un error humano detienen la operación, cada minuto cuesta. Pero no todos los procesos valen lo mismo ni requieren el mismo tiempo de recuperación. Ahí entra el análisis de impacto del negocio (BIA): la herramienta que revela qué es realmente crítico, cuánto daño produce una interrupción y en
RPO (Recovery Point Objective u Objetivo de Punto de Recuperación) es la cantidad máxima de datos que tu organización acepta perder cuando ocurre un incidente, medida en tiempo. Por ejemplo, un RPO de 15 minutos implica que, ante un desastre, como máximo perderás los últimos 15 minutos de transacciones. No necesitas una máquina del tiempo,
El MTPD (Maximum Tolerable Period of Disruption) o periodo máximo tolerable de interrupción define cuánto tiempo puede estar interrumpido un proceso crítico antes de que el impacto en el negocio resulte inaceptable. En continuidad de negocio y disponibilidad, el MTPD marca el límite de tiempo para evitar pérdidas financieras, regulatorias o reputacionales serias. ¿Qué es
El RTO (Recovery Time Objective o Tiempo Objetivo de Recuperación) define el tiempo máximo aceptable para restablecer un proceso, aplicación o servicio tras una interrupción. En continuidad del negocio, el RTO marca cuánto puede estar fuera de línea un servicio antes de que el impacto sea inaceptable. Optimizar el RTO protege la disponibilidad del servicio,
