ENTRANDO EN TEMA
La seguridad no es un estado y vayamos al punto central para comenzar bien y no confundirnos, debemos entender y asociar el concepto con la gestión de riesgos en donde un cierto porcentaje de empresas aún finge realizar hasta que el desastre ocurre. ¿Y quiénes lo pueden identificar de manera temprana? Un PM, PO, y/o Agile Tester capacitado en la práctica de «Security Testing». Para entender los niveles de seguridad de activos, primero debemos observar dónde sangran los proyectos reales.
LA REALIDAD DE CIERTAS SITUACIONES EN DONDE SE COLAPSAN LOS PRODUCTOS DIGITALES
Antes de hablar de certificaciones, hablemos de estar atentos a no caer en la negligencia técnica / operativa. Estas son algunas de las anomalías que provocan muchos problemas (humanos y/o técnicos y/o económicos y/o financieros y/o de reputación de imagen) en proyectos diariamente:
- La ilusión del entorno de desarrollo: se asume que lo que no es «producción» no requiere seguridad, dejando bases de datos reales en manos de desarrolladores con contraseñas como «123456».
- El «excel» de los secretos: credenciales de bases de datos, llaves de API y certificados SSL almacenados en un archivo compartido o, peor aún, hardcodeados en el repositorio de Git.
- Privilegios de «deidad«: otorgar permisos de administrador a cada integrante del equipo «para que no haya bloqueos», ignorando el principio de mínimo privilegio.
- La deuda técnica zombi: librerías de hace cinco años que nadie se atreve a actualizar por miedo a romper el build, pero que tienen vulnerabilidades críticas conocidas.
- Seguridad como postre: intentar «inyectar» seguridad al final del ciclo de vida del desarrollo, cuando la arquitectura ya es inherentemente débil.
- El teatro del cumplimiento: empresas que se preocupan por pasar una auditoría en papel, pero cuyos procesos reales son un caos de excepciones y parches manuales.
- La confianza ciega en el perímetro: creer que porque hay un firewall, el tráfico interno es seguro, ignorando que la mayoría de los ataques hoy ocurren «desde adentro».
- Negación de la sensibilidad: tratar un catálogo de productos público con el mismo nivel de protección que los datos médicos o financieros de los clientes.
- Falsa sensación de protección por terceros: asumir que usar la nube (AWS, Azure) hace que tu aplicación sea segura automáticamente, olvidando la responsabilidad compartida.
- El factor humano ignorado: invertir millones en software de seguridad y cero en entrenar al personal para no caer en un phishing básico por Telegram o Slack.
Diez puntos de dolor: la realidad del colapso
Un análisis crudo de las anomalías y conflictos que comprometen la seguridad en el desarrollo de productos digitales modernos.
Impacto estimado por categoría
Clasificación del daño potencial a la infraestructura y reputación de la empresa basado en los fallos comunes del ciclo de vida.
Origen de las anomalías
¿De dónde vienen los problemas? Distribución de los 10 puntos según su naturaleza fundamental.
Anatomía de la negligencia técnica
Ilusión del desarrollo
Creer que «no ser producción» justifica el uso de contraseñas débiles o datos reales expuestos.
Excel de secretos
Llaves de API y credenciales en archivos compartidos o repositorios de Git sin protección.
Privilegios de deidad
Administradores por doquier para evitar bloqueos operativos, violando el mínimo privilegio.
Deuda técnica zombi
Librerías obsoletas con fallos conocidos que nadie actualiza para no romper el build.
Seguridad como postre
Intentar parchear la seguridad al final del proyecto sobre una arquitectura ya viciada.
Teatro del cumplimiento
Cumplir la norma en el papel pero operar en un caos de parches y excepciones manuales.
Confianza perimetral
Suponer que el Firewall basta, ignorando que los ataques más letales nacen en la red interna.
Negación de sensibilidad
Igualar la protección de un catálogo público a la de datos financieros o médicos sensibles.
Protección de terceros
Asumir que estar en AWS o Azure nos exime de nuestra responsabilidad compartida de seguridad.
Factor humano ignorado
Invertir solo en herramientas y nada en capacitar al personal contra ataques de phishing.
¿Alguna de estas situaciones te suenan familiares? Si la respuesta es SI, entonces vamos por buen camino porque probablemente me puedas compartir tu experiencia y así entre ambos lograr mayor entendimiento en esta área. Recuerda que he comenzado a estudiar el programa de estudios del ISTQB Security Testing y por ese motivo estoy publicando este tipo de contenidos no solamente por aquí sino también por LinkedIn donde me puedes contactar por privado (DM).
EL ACTIVO DE INFORMACIÓN Y LA TRIADA DE LA PROTECCIÓN
En el cotidiano -como quien dice-, un activo de información es cualquier cosa que, si se pierde, se altera o se filtra, le cuesta dinero o reputación a la organización. No protegemos «bits», protegemos valor de negocio. Este aspecto muchas veces no se logra entender bien porque no se transmite bien, básicamente.
Para poder identificar riesgos, debemos entender el concepto de la frase Tríada CID (CID son nomenclaturas):
Confidencialidad (debemos asociarlo con la frase: «no es para ojos ajenos»)
Es asegurar que la información solo sea accesible por quienes tienen permiso (Nota personal: y así y todo, ¡cuidado!).
- Ejemplo cotidiano: tu historial de chat. Si cualquiera pudiera leerlo, tu privacidad (confidencialidad) se rompe.
- Riesgo técnico: una base de datos de usuarios sin cifrar.
Integridad (debemos asociarlo con la frase: «que no lo toquen»)
Es garantizar que la información sea exacta y no haya sido alterada de forma no autorizada.
- Ejemplo cotidiano: el saldo de tu cuenta bancaria. Si alguien puede cambiar un $10 por un $10.000 sin que te des cuenta, la integridad ha muerto.
- Riesgo técnico: un atacante modificando los precios de un carrito de compras antes de pagar.
Disponibilidad (debemos asociarlo con la frase: «que funcione cuando lo necesito»)
Es asegurar que los sistemas y datos estén listos para ser usados cuando se requiera.
- Ejemplo cotidiano: el botón de «llamar» de emergencias. Si el sistema está caído, no sirve de nada que sea confidencial e íntegro.
- Riesgo técnico: un ataque de denegación de servicio (DoS) que tumba el servidor de login.
PARADIGMAS DE SEGURIDAD SEGÚN EL ISTQB
A continuación, describiré de manera crítica el concepto de los pilares de la unidad 1.
1.1. Niveles de seguridad de activos
No todos los activos valen lo mismo. Clasificar es sobrevivir. Un ingeniero de pruebas debe priorizar:
- Alta sensibilidad: datos personales, secretos industriales. Requieren pruebas de penetración exhaustivas.
- Sensibilidad media: reportes operativos internos.
- Baja sensibilidad: información pública. El rigor aquí es menor para no desperdiciar recursos.
1.2. Auditorías de seguridad
La auditoría es el «examen de conciencia» de la organización. Es una evaluación formal de si las políticas de seguridad se están cumpliendo. Mientras que el Security Testing busca fallos técnicos, la Auditoría busca fallos en el cumplimiento y el proceso. Es la diferencia entre probar si una puerta cierra (test) y revisar si el protocolo dice que la puerta debe estar cerrada bajo llave (auditoría).
1.3. El concepto de confianza cero
El modelo Zero Trust asume que la red ya está comprometida. Su lema es «nunca confiar, siempre verificar». En este paradigma, no importa si estás conectado a la VPN de la oficina o a un Wi-Fi de un aeropuerto: cada solicitud de acceso debe ser autenticada, autorizada y cifrada. En las pruebas de seguridad, esto nos obliga a testear cada microservicio como si estuviera expuesto a la internet pública.
1.4. Software de código abierto (SCA)
Casi todo software moderno es un rompecabezas de piezas de código abierto. El Software Composition Analysis (SCA) es la práctica de analizar estas dependencias para identificar vulnerabilidades conocidas (CVEs) y conflictos de licencias. Ignorar el SCA es como construir una caja fuerte con piezas usadas que compraste en un callejón: no importa qué tan buena sea tu cerradura si las bisagras ya vienen oxidadas.
SecTestGuide
Niveles de Seguridad de Activos Del Caos a la Estrategia Zero Trust
La seguridad no es un estado, es una gestión continua de riesgos. La mayoría de los proyectos digitales viven en una ilusión de protección hasta que ocurre el desastre. Esta guía visual desglosa la realidad del colapso técnico, la importancia crítica de clasificar activos y la transición obligatoria hacia nuevos paradigmas de seguridad.
1. La Realidad: 10 Puntos de Dolor
Antes de hablar de teoría, observemos dónde sangran los proyectos reales. Estas son las anomalías más comunes que destruyen productos digitales, mapeadas por su probabilidad de ocurrencia y el impacto catastrófico que generan.
🔥 Top 3 Anomalías Críticas
-
🔐
El «Excel» de los Secretos:
Credenciales hardcodeadas en Git o compartidas en texto plano. Un clásico del desastre.
-
🧟
Deuda Técnica Zombi:
Librerías obsoletas con CVEs conocidos que nadie actualiza por miedo a «romper el build».
-
🎭
Teatro del Cumplimiento:
Pasar auditorías en papel mientras los procesos reales son un caos manual.
Insight Crítico: La mayoría de los ataques no son «hacks» sofisticados, sino la explotación de estas negligencias básicas (Factor Humano, Entornos de Desarrollo inseguros).
Matriz de Riesgo: Probabilidad vs. Impacto de los 10 Puntos de Dolor. (Datos estimados para fines educativos)
2. Activos de Información y Tríada CID
No protegemos bits, protegemos valor de negocio. Un activo es cualquier cosa que, si se pierde, cuesta dinero o reputación. La clasificación es clave: no se protege igual un catálogo público que una base de datos médica.
Confidencialidad
Solo quienes tienen permiso pueden ver.
Fallo: Leer chats ajenos.
Riesgo: DB sin cifrar.
Integridad
La información es exacta y no alterada.
Fallo: Cambiar $10 por $10k.
Riesgo: Inyección SQL.
Disponibilidad
Funciona cuando se necesita.
Fallo: Caída en Black Friday.
Riesgo: Ataque DDoS.
Jerarquía de Sensibilidad
En una organización típica, no todo es «Top Secret». Tratar todo como crítico es tan peligroso como no proteger nada, porque diluye los recursos.
- Alta (15%): Datos PII, Secretos Industriales. Requiere Penetration Testing exhaustivo.
- Media (35%): Reportes internos, correos operativos. Requiere controles de acceso estándar.
- Baja (50%): Información pública (Web marketing). Requiere protección de integridad (anti-defacement).
3. Paradigmas de Seguridad: El Cambio Necesario
El modelo tradicional de «Castillo y Foso» (Firewall perimetral) ha muerto. El nuevo estándar es Zero Trust: «Nunca confiar, siempre verificar». Asumimos que la red ya está comprometida.
Comparativa de Enfoques
Enfoque Tradicional
Confianza ciega en el perímetro. «Si estás dentro, eres bueno». Auditorías anuales aburridas.
Enfoque Moderno (Zero Trust)
Microsegmentación. Autenticación continua por solicitud. Auditoría automatizada y constante.
4. El Riesgo Invisible: Software de Código Abierto (SCA)
El desarrollo moderno es un rompecabezas. Casi el 80% del código en producción no lo escribiste tú; son librerías de terceros. Ignorar el SCA es construir una caja fuerte con piezas oxidadas.
¿Qué es SCA?
Software Composition Analysis es la práctica de escanear tus dependencias (node_modules, pip packages) en busca de vulnerabilidades conocidas (CVEs).
El Peligro de la «Caja Negra»
Tu equipo escribe código seguro (Propietario), pero importa una librería de logueo de 2018. Resultado: Log4Shell. La seguridad de tu activo depende del eslabón más débil de tu cadena de suministro.
COMPARATIVA DE PARADIGMAS Y ENFOQUES
| Concepto | Enfoque tradicional | Enfoque moderno (crítico) | Impacto en pruebas |
|---|---|---|---|
| Perímetro | Muralla exterior (Firewall) | Microsegmentación y Zero Trust | Probar cada endpoint individualmente |
| Activos | Todos se protegen «igual» | Clasificación por sensibilidad | Pruebas basadas en el riesgo |
| Auditoría | Evento anual aburrido | Evaluación continua y técnica | Verificación de controles automatizados |
| SCA | «Es gratis y funciona» | Riesgo de cadena de suministro | Escaneo obligatorio de dependencias |
Momento para reflexionar: Si no podemos identificar qué estamos protegiendo y por qué alguien querría robárselo, nuestras pruebas de seguridad son solo una pérdida de tiempo y dinero, y este pensamiento lo debemos transmitir y compartir a todo el equipo para que TODOS lo logren comprender, desde el Project Manager, pasando por el Product Owner y hasta los Developers. Es super importante para la calidad del producto final, en el sentido amplio del concepto «calidad».
La fuente de consulta e inspiración para este artículo ha sido el programa de estudios del ISTQB Security Testing (ISTQB Certified Tester – Security Test Engineer Syllabus, v 1.0.1)
