Eating our own dog food: cuando la ciberseguridad se prueba a sí misma

Si no lo usas, no funciona

Existe una práctica en la industria del software que debería ser obligatoria en ciberseguridad: dogfooding — usar tu propio producto antes de exigírselo a los demás.

El término viene de la expresión anglosajona “eating your own dog food”, popularizada en los años 80 cuando Microsoft comenzó a exigir que sus empleados usaran sus propios productos en fase beta (Cusumano & Selby, 1995). La lógica es brutal en su simplicidad: si no confías lo suficiente en tu producto como para usarlo tú mismo, ¿por qué debería hacerlo alguien más?

En ciberseguridad, la pregunta equivalente es devastadora:

¿Tu equipo de seguridad cumple con las políticas que redactó?

El problema que nadie quiere admitir

He visto equipos de seguridad que exigen MFA a toda la organización pero internamente usan cuentas de servicio compartidas sin segundo factor. Que redactan políticas de clasificación de información y guardan sus propios documentos sensibles en carpetas sin restricción. Que implementan EDR en cada endpoint del negocio pero dejan sus propias estaciones de trabajo con excepciones “temporales” que llevan meses.

No es mala intención. Es inercia. Es la presión del día a día. Es el sesgo de que “nosotros sabemos lo que hacemos”.

Pero el resultado es el mismo: una brecha de credibilidad que erosiona toda la estrategia de seguridad.

Harrison (2006) ya lo señalaba desde la ingeniería de software: si el equipo que construye el producto no lo usa, pierde la perspectiva del usuario real. Hasani et al. (2023) lo confirman en el dominio de ciberseguridad: el soporte directivo y la adopción interna son factores determinantes en el éxito de los programas de seguridad organizacional. Los controles que no son adoptados internamente sufren resistencia significativa en su despliegue.

Dogfooding como metodología de validación

El dogfooding no es solo una cuestión ética o de credibilidad. Es una metodología de validación operativa que expone problemas que ninguna auditoría de escritorio puede detectar.

Lo que descubres cuando comes tu propia comida

Cuando el equipo de seguridad se somete a sus propios controles, aparecen verdades incómodas:

La política de contraseñas es impracticable. 16 caracteres con rotación cada 30 días suena bien en el documento, pero en la práctica genera post-its en los monitores. Si tu propio equipo no puede cumplirla sin un gestor de contraseñas, el resto de la organización tampoco. NIST (2025) recomienda explícitamente eliminar la rotación periódica obligatoria y privilegiar contraseñas largas sin requisitos artificiales de complejidad.
El proceso de solicitud de accesos tarda demasiado. Si tu analista SOC necesita 5 días para obtener acceso a una herramienta crítica durante un incidente, el proceso está roto. Y si nunca lo experimentaste en carne propia, nunca lo vas a arreglar.
Las alertas generan fatiga. Configuraste 200 reglas de detección. Llegan 3.000 alertas diarias. Tu propio equipo ignora el 80% porque son falsos positivos. Eso no es monitoreo — es ruido disfrazado de seguridad. Tariq et al. (2025) documentan que la fatiga de alertas es uno de los principales desafíos en los SOC modernos, donde el volumen de falsos positivos reduce drásticamente la efectividad de detección real.
La capacitación de awareness es aburrida. Si tu propio equipo se salta el curso anual de concientización o lo completa en modo automático, imagina lo que hace el resto de la organización.

El framework del dogfooding en ciberseguridad

Propongo un enfoque estructurado para implementar dogfooding como práctica formal dentro del programa de seguridad.

1. Someterse primero

Toda política, control o herramienta nueva debe ser adoptada primero por el equipo de seguridad. Sin excepciones. Sin plazos especiales. Sin configuraciones “lite”.

Si la política dice que los usuarios deben reportar correos sospechosos en menos de 5 minutos, el equipo de seguridad debe hacerlo primero. Si el procedimiento de respuesta exige documentación en tiempo real, el equipo debe probarlo en un simulacro antes de exigirlo en producción.

2. Documentar la fricción

Cada punto de dolor que el equipo experimenta al usar sus propios controles debe quedar registrado. No como queja, sino como hallazgo:

Hallazgo	Impacto	Acción
VPN corporativa desconecta cada 15 min	Pérdida de productividad, usuarios la desactivan	Ajustar timeout a 8 horas con revalidación
Aprobación de excepción tarda 10 días	Excepciones informales sin registro	Crear fast-track para excepciones de bajo riesgo
DLP bloquea envío legítimo de reportes	Equipos usan canales alternativos no monitoreados	Ajustar reglas, agregar listas blancas por contexto

3. Iterar antes de escalar

La versión que llega al resto de la organización no debería ser la versión 1.0. Debería ser la versión que sobrevivió al escrutinio interno. Kim et al. (2021) argumentan que los sistemas de seguridad deben tratarse como productos sujetos a ciclos de mejora continua, no como mandatos estáticos.

4. Medir la brecha interna

Si tu equipo de seguridad tiene un nivel de cumplimiento del 95% con sus propias políticas, tienes una línea base realista. Si tiene un 60%, tienes un problema de diseño, no de cultura. El indicador más honesto de la viabilidad de un control es la tasa de cumplimiento del equipo que lo creó.

Casos reales donde el dogfooding habría cambiado el resultado

El caso del MFA selectivo

Una organización implementó MFA obligatorio para todos los usuarios. Excepto las cuentas de administración del equipo de seguridad, que quedaron exentas “por operatividad”. El atacante lo sabía. Comprometió una cuenta de administrador sin MFA y tuvo acceso privilegiado a toda la infraestructura de seguridad.

Si el equipo hubiera sido el primero en usar MFA — incluyendo sus cuentas privilegiadas — habrían descubierto que necesitaban tokens hardware, no solo la app en el teléfono. Y habrían estado protegidos.

El caso de la política de parches

El equipo de seguridad exigía que todos los sistemas estuvieran parcheados en un máximo de 72 horas para vulnerabilidades críticas. Sus propias herramientas — el SIEM, el escáner de vulnerabilidades, la consola de EDR — llevaban 6 meses sin actualizar. Un adversario explotó una vulnerabilidad conocida en la consola del SIEM y obtuvo acceso a todos los logs de la organización.

Dogfooding y cultura organizacional

El beneficio más profundo del dogfooding no es técnico. Es cultural.

Cuando el equipo de seguridad practica lo que predica, genera un efecto cascada:

Credibilidad. “Nosotros también lo hacemos” es el argumento más poderoso para la adopción de controles. Schein (2017) establece que la cultura organizacional se forma a partir de lo que los líderes practican, no de lo que declaran.
Empatía. Experimentar la fricción de los controles genera comprensión real de los problemas de usabilidad que enfrentan los usuarios. Esa empatía se traduce en controles mejor diseñados.
Mejora continua. El dogfooding convierte cada política en un producto vivo, sujeto a retroalimentación constante desde adentro.
Confianza bidireccional. La organización confía más en el equipo de seguridad cuando ve que no pide nada que no esté dispuesto a hacer primero. Y el equipo confía más en sus propios controles porque los ha validado en condiciones reales.

Cómo empezar mañana

No necesitas un programa formal. Empieza con tres preguntas:

¿Nuestro equipo cumple al 100% con la política de contraseñas que redactamos? Si la respuesta es no, ahí tienes tu primer hallazgo.
¿Pasaríamos nuestra propia auditoría interna? Hazte la auditoría. En serio. Con el mismo rigor que se la haces al negocio.
¿Usamos las herramientas que desplegamos? Si implementaste un sistema de gestión de incidentes pero tu equipo sigue usando correo electrónico y hojas de cálculo internamente, el sistema no funciona. O no lo estás usando bien. Cualquiera de las dos es un problema.

Reflexión final

La ciberseguridad que no se aplica a sí misma es teoría disfrazada de práctica.

El dogfooding no es humildad — es rigor metodológico. Es la diferencia entre diseñar controles en un laboratorio y validarlos en el campo de batalla. Entre escribir políticas que suenan bien y construir políticas que funcionan.

La próxima vez que tu equipo implemente un nuevo control, hazlo primero. Sufre la fricción. Documenta los problemas. Mejóralo. Y entonces sí, despliégalo con la autoridad de quien sabe que funciona.

Porque si no estás dispuesto a comer tu propia comida, no se la sirvas a nadie.

Referencias

Cusumano, M. A., & Selby, R. W. (1995). Microsoft secrets: How the world’s most powerful software company creates technology, shapes markets, and manages people. Free Press. https://books.google.com/books/about/Microsoft_Secrets.html?id=pj8K-a4ewx4C

Harrison, W. (2006). Eating your own dog food. IEEE Software, 23(3), 5-7. https://doi.org/10.1109/MS.2006.72

Hasani, T., O’Reilly, N., Dehghantanha, A., Rezania, D., & Levallet, N. (2023). Evaluating the adoption of cybersecurity and its influence on organizational performance. SN Business & Economics, 3(5), Article 97. https://doi.org/10.1007/s43546-023-00477-6

Kim, G., Humble, J., Debois, P., Willis, J., & Forsgren, N. (2021). The DevOps handbook: How to create world-class agility, reliability, & security in technology organizations (2.a ed.). IT Revolution Press. https://itrevolution.com/product/the-devops-handbook-second-edition/

National Institute of Standards and Technology. (2025). Digital identity guidelines: Authentication and authenticator management (NIST SP 800-63B-4). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-63B-4

Schein, E. H., & Schein, P. A. (2017). Organizational culture and leadership (5.a ed.). Wiley. https://www.wiley.com/en-us/Organizational+Culture+and+Leadership,+5th+Edition-p-9781119212041

Tariq, S., Chhetri, M. B., Nepal, S., & Paris, C. (2025). Alert fatigue in security operations centres: Research challenges and opportunities. ACM Computing Surveys, 57(6), Article 155. https://doi.org/10.1145/3723158