Entrando en tema
El contenido correspondiente a la sección 1.1.1. Activos y sus Niveles de Protección, del Capítulo 1. Security Paradigms, del programa de estudios del ISTQB Security Testing (STE), lo estuve tratando en uno de mis artículos (ver «Cómo determinar el valor de un activo y su nivel de protección«) y quise profundizar un poco más este tema para ir cerrándolo conceptualmente cubriendo algunos aspectos que nos los tenía del todo claros como:
- conceptos básicos
- correlación con normas internacionales y estándares
- situaciones en las que se deben aplicar este tema
- acciones recomendadas que todo tester ágil debe tenerlas en cuenta
- riesgos que deben considerarse
- tratamiento de la gestión de cambios
Uno de los aspectos más importantes que rescato de la sección 1.1.1. es acerca de la determinación de los niveles de seguridad de los activos como una parte esencial de toda gestión de riesgos dentro de la organización.
Volviendo al concepto primario, un activo puede ser cualquier recurso con valor para la entidad (datos, sistemas, infraestructuras críticas o incluso la reputación).
Por tal motivo, en función de su criticidad y que la propia organización deberá evaluar y definir, se le asigna un nivel de seguridad que orienta las medidas de protección necesarias.
Aquí es donde debemos recordar que la protección de los activos esta vinculada con los principios de la triada CIA (Confidencialidad, Integridad y Disponibilidad), y que estos principios permiten clasificar a los activos en tres niveles de sensibilidad (baja, media y alta).
Independientemente de las nomenclaturas, en la práctica diaria debemos entender que el objetivo principal es poder conseguir relacionar de forma clara para todo el equipo de proyecto y stakeholders, la importancia de los activos con los controles de seguridad adecuados.
Reforzando conceptos anteriores
- Activo (Asset): Cualquier recurso valioso para la organización: datos, sistemas, infraestructura, propiedad intelectual, reputación, etc.
- Nivel de Seguridad (Security Level): La categorización de un activo según su criticidad y sensibilidad (por ejemplo, Alto, Medio, Bajo).
- Confidencialidad (Confidentiality): Asegurar que la información solo esté disponible para las personas autorizadas.
- Integridad (Integrity): Garantizar que la información y los sistemas se mantengan exactos y completos.
- Disponibilidad (Availability): Asegurar que los sistemas y datos estén disponibles cuando se requieran.
- Protección: Medidas de seguridad diseñadas de manera proporcional al nivel de riesgo y de valor del activo (p. ej., cifrado para datos altamente sensibles).
Correlación con normativas internacionales y estándares
La implementación de los distintos niveles de seguridad se logra a partir de conocer las diferentes estrategias de pruebas definidas en ciertos estándares y mejores prácticas internacionales. En este sentido, debemos considerar:
- ISO/IEC 27001: Define un Sistema de Gestión de Seguridad de la Información (SGSI) que ayuda a clasificar activos y asignar niveles de protección adecuados.
- NIST (National Institute of Standards and Technology): Proporciona guías para la clasificación de la información y la ciberseguridad (p.ej., NIST SP 800-53).
- OWASP (Open Web Application Security Project): En el caso de aplicaciones web, se centran en vulnerabilidades comunes y directrices para proteger activos digitales.
Estas normativas alinean la clasificación de los activos con la evaluación de riesgos y la implementación de controles específicos, lo que refuerza la importancia de la clasificación de seguridad en todo el ciclo de vida del software.
Niveles de seguridad que pueden evaluarse para implementar
Bajo (Nivel Básico):
- Ejemplo: Documentación interna con información no confidencial o datos de pruebas.
- Consecuencia si se filtra: Impacto leve sobre la organización, aunque puede dañar la imagen o provocar molestias.
- Protección recomendada: Controles de acceso genéricos, contraseñas robustas y monitoreo sencillo.
Medio (Sensibilidad Moderada):
- Ejemplo: Planes de proyecto, informes financieros de áreas específicas, información personal de empleados sin implicaciones críticas.
- Consecuencia si se filtra: Posibles implicaciones económicas o legales, daño reputacional moderado.
- Protección recomendada: Cifrado en tránsito, autenticación multifactor para usuarios clave, revisión de acceso periódico, copias de seguridad protegidas.
Alto (Sumamente Crítico):
- Ejemplo: Propiedad intelectual, bases de datos con información financiera de clientes, sistemas de control en infraestructuras críticas.
- Consecuencia si se filtra: Daño significativo a la continuidad del negocio, pérdida millonaria, impacto legal y reputacional severo.
- Protección recomendada: Cifrado fuerte en reposo y en tránsito, segmentación de redes, monitoreo constante, auditorías de seguridad internas y externas, planes de contingencia y recuperación ante desastres.
Punto para reflexionar: En cada uno de estos Niveles de Seguridad, podemos leer la Consecuencia que puede provocar si se llegara a filtrar y la Protección que se recomienda. Ahora bien, si nosotros como Testers Ágiles al recibir un requerimiento y luego de analizarlo y discutirlo con nuestros compañeros de equipo, llegamos a conclusiones del tipo proponer diferentes tipos de testing con un alcance que pueda cubrir algunos (o todos) de los niveles indicados, muy probablemente genere algún tipo de discusión o debate entre los miembros del equipo, incluyo al Product Owner y Scrum Master, ya que requiere «tiempo» para pensar, elaborar, ejecutar, controlar y seguir una tarea durante el Sprint que tal vez no había pensado, y que se suma al resto de las tareas propias del Sprint. Aquí es donde la madurez del equipo se nota.
Prácticas que se deberían implementar en cada etapa del ciclo del desarrollo de software
Planificación:
- Identificar y clasificar los activos desde la concepción del proyecto, a partir de los requerimientos que recibe el Product Owner.
- Realizar un análisis de riesgos iniciales y definir métricas de seguridad.
- Incluir historias de usuario orientadas a la seguridad junto con las funcionalidades principales, a partir de reuniones que tengamos con el Product Owner.
Punto para reflexionar: En relación a estas tareas, claramente debemos tener conocimiento en el tema como para poder identificar y clasificar los activos que deban ser protegidos mediante diferentes niveles de seguridad, como así también y más allá de tener conocimiento acerca del concepto de riesgos y riesgos de seguridad, cómo analizar los requerimientos con foco en los riesgos debiendo apoyarnos en el Product Owner quien debería tener muy claro el negocio, y de esa forma lograr elaborar épicas e historias de usuario correctamente alcanzadas con sus correspondientes criterios de aceptación y así permitir que todos los miembros del equipo de desarrollo puedan iniciar sus tareas durante el sprint y sprints sucesivos, ya que se entiende que el desarrollo será incremental.
Diseño:
- Incorporar principios de security by design: reducir superficies de ataque, usar patrones de cifrado y autenticación sólidos.
- Validar la arquitectura para asegurar que los componentes críticos estén debidamente aislados y protegidos.
Implementación/Codificación:
- Emplear buenas prácticas de codificación segura (validación de entradas, manejo adecuado de errores, etc.).
- Utilizar herramientas de Análisis Estático de Código (SAST) para detectar vulnerabilidades tempranas.
Punto para reflexionar: Además de nuestra participación como testers ágiles en las actividades indicadas, está claro que los desarrolladores deben tener conocimiento en desarrollo seguro y acompañarse con herramientas que garanticen los objetivos de los niveles de seguridad (p.e. SonarQube) sobre los activos que se hayan identificado y definidos.
Pruebas (Testing):
- Integrar pruebas de seguridad en los pipelines de integración continua.
- Realizar pruebas de penetración en los activos más críticos.
- Analizar la cobertura de las pruebas de seguridad y priorizar la corrección de vulnerabilidades de mayor impacto.
Despliegue:
- Configurar correctamente entornos de producción: protección de credenciales, segmentación de redes, minimización de servicios expuestos.
- Revisar los logs y usar herramientas de monitoreo para detectar comportamientos anómalos.
Mantenimiento:
- Actualizar parches y dependencias vulnerables de manera continua.
- Revisar la clasificación de los activos si cambian los requerimientos del negocio.
- Auditar procesos de seguridad de forma regular para asegurarse de que las medidas siguen siendo efectivas.
Riesgos que debemos considerar y atender con nuestro testing
- Acceso no autorizado:
- Intrusiones o filtraciones de datos si no se implementan controles de acceso adecuados (contraseñas débiles, sin MFA, etc.).
- Exposición de información sensible:
- Falta de cifrado o uso de protocolos inseguros puede exponer información de alto valor.
- Pérdida de integridad de los datos:
- Fallas en controles de versión, errores de software o ataques maliciosos pueden modificar datos críticos.
- Falta de disponibilidad:
- Ataques de denegación de servicio (DoS) o errores de configuración que dejan inaccesibles sistemas clave.
- Errores en la gestión de cambios:
- Cambios improvisados o mal documentados pueden introducir brechas de seguridad o interrumpir la protección de activos de nivel alto.
- Desconocimiento de amenazas internas:
- Empleados malintencionados o descuidados que podrían filtrar información sin darse cuenta.
¿Tenemos herramientas? Claro que sí 😎
- SAST (Static Application Security Testing): Detecta vulnerabilidades en el código fuente antes de compilar o durante la construcción.
- DAST (Dynamic Application Security Testing): Permite analizar la aplicación en tiempo de ejecución para descubrir problemas como inyecciones, configuraciones inseguras o exposiciones de datos.
- IAST (Interactive Application Security Testing): Mezcla de SAST y DAST, brinda visibilidad profunda de la ejecución de la aplicación.
- SCA (Software Composition Analysis): Verifica bibliotecas de terceros y dependencias en busca de vulnerabilidades conocidas.
- Herramientas de Monitoreo y Detección de Intrusos (IDS/IPS, SIEM): Indispensables para sistemas con activos de alto nivel.
¿Cuál debe ser nuestra participación como Testers Ágiles para prevenir y mitigar riesgos?
- Participación Temprana: Debemos colaborar con el Product Owner y el desarrollador desde el refinamiento de historias de usuario, identificando requerimientos de seguridad.
- Priorización Continua: Podemos contribuir a priorizar historias de seguridad en el backlog, asegurando que se atiendan oportunamente.
- Automatización de Pruebas de Seguridad: Debemos integra herramientas de análisis estático/dinámico en el pipeline de CI/CD.
- Inspección y Adaptación: Debemos revisar los resultados de las pruebas de seguridad y propone mejoras en cada sprint. No hay que esperar a las Retros para eso.
- Concientización del Equipo: Ayudamos a organizar o promover sesiones de capacitación sobre las últimas amenazas y vulnerabilidades, no sólo desde la perspectiva del testing sino que hasta se pueden realizar sesiones en conjunto con miembros con otros roles (p.e. product owners, desarrolladores, administradores de base de datos, devops, security administrators, otros)
Gestión de incidentes
- Detección Temprana: Configurar alertas y monitoreo continuo para identificar signos de intrusión o anomalías. Este proceso se puede iniciar mediante herramientas de automatización que arrojen resultados que luego estos alimenten indicadores en otras herramientas como puede ser Jira Software para que se vaya actualizando el dashboard correspondiente como un Radiador de Información a todos el equipo de proyecto y stakeholders.
- Respuesta Inmediata: Definir planes de contingencia, escalamiento y contención del incidente (aislar sistemas afectados, activar planes de recuperación). En este caso, debemos considerar elaborar los correspondientes planes de prueba (manuales y automatizados) necesarios para activarlos cuando el protocolo definido lo comunique. También debemos tener montado el correspondiente dashboard para la comunicación a todo el equipo con las respectivas alertas.
- Lecciones Aprendidas: Tras la contención, realizar análisis forense y documentar las causas para mejorar el proceso. Este análisis deberá llevarnos a corregir alcances de nuestros planes.
- Comunicación Clara: Notificar oportunamente a las partes interesadas (equipo, Product Owner, stakeholders) y, según normas legales, a las autoridades o a los usuarios afectados. Esta acción se logra con adecuados Radiadores de Información previamente definidos para que todas las partes involucradas reciban la información que esperan y necesitan de acuerdo a sus posiciones.
Algunas métricas que se deben tener en cuenta
- MTTD (Mean Time to Detect): Tiempo promedio para detectar una vulnerabilidad o incidente.
- MTTR (Mean Time to Respond/Resolve): Tiempo promedio para responder o corregir una vulnerabilidad o incidente.
- Cobertura de Pruebas de Seguridad: Porcentaje de módulos, endpoints o funcionalidades testeadas con técnicas SAST/DAST.
- Índice de Incidentes por Activo Crítico: Número de incidentes detectados en activos clasificados como de nivel alto.
- Costo de Corrección de Vulnerabilidades: Para medir la rentabilidad de las inversiones en seguridad (relacionado con el costo/beneficio).
Consideraciones sobre el costo/beneficio
- Análisis ROI de Seguridad: El Product Owner, junto con el tester y el equipo, evalúa cuánto se invierte en medidas de seguridad frente a las pérdidas potenciales por un incidente.
- Priorización de Inversiones: Centrar los esfuerzos en los activos de mayor valor o criticidad, evitando sobreproteger lo que no es esencial o subproteger recursos vitales.
- Planificación en el Backlog: Estimar el esfuerzo requerido para implementar controles de seguridad y balancearlo con las funcionalidades del producto.
En cuanto a la Arquitectura, ¿Qué debemos tener en cuenta?
- Diseño por Capas (Layered Security): Cada capa (presentación, lógica de negocio, datos) requiere controles de seguridad particulares.
- Componente de Autenticación: Vital para limitar el acceso a activos de alto nivel y asegurar la trazabilidad de acciones.
- Monitoreo en la Arquitectura: Incluir componentes de logging y monitoreo desde el diseño para detectar anomalías en cada capa.
- Validación de Integraciones: Cualquier servicio externo o API debe someterse a análisis de seguridad antes de su adopción.
Gestión de Cambios y algunas de las mejores prácticas que se recomiendan
- Documentación Continua: Cada cambio que afecte la seguridad requiere un registro claro (qué se cambió, por qué y con qué pruebas se validó).
- Revisión de Impacto: Analizar si un cambio reduce, mantiene o aumenta el nivel de riesgo de un activo; actualizar el plan de seguridad en consecuencia.
- Política de Rollback: Tener planes de reversión listos por si un cambio introduce vulnerabilidades o inestabilidades críticas.
Si me preguntaras, ¿Gus, podés llevarlo todo a un plano más práctico? Mi respuesta sería la siguiente:
- Debemos definir junto al equipo, en el caso de que no haya un Líder Técnico de Calidad o un área de QA, un proceso de gestión de cambios formal integrándolo con el backlog y con los workflows de control de versiones, donde cada cambio se revise en cuanto a su impacto en la seguridad, además del que ya debería haberse implementado en lo que refiere a los aspectos funcionales y no funcionales, ¿verdad?
- Cada vez que se modifique un activo o un sistema que esté relacionado con el mismo, debemos realizar un análisis de riesgos rápido para determinar si se requiere ajustar la clasificación de seguridad o añadir controles adicionales.
- Debemos pensar en mantener un registro de por qué se realizó el cambio y quién lo aprobó, de alguna forma práctica y sencilla y para eso están las herramientas de gestión de proyectos como Jira Software y de gestión de testing como Xray, para tomar registro además de las pruebas de seguridad efectuadas y los resultados obtenidos. Esto crea trazabilidad y facilita auditorías de seguridad posteriores.
- Hay que asegurarse, como protectores de la calidad que somos, que todos los miembros del equipo estén conscientes de los procedimientos relacionados al testing de seguridad y sus repercusiones de no seguir sus mejores prácticas, especialmente en activos de nivel alto.
Punto para reflexionar: Cada una de estas tareas, forma parte de una actividad y de un proceso que el equipo debe realizar y consecuentemente consumirá esfuerzos y tiempos. Por ese motivo es tan importante que estos temas sean tratados a nivel gerencial como para tener el respaldo y evitar frases de gerentes como «…no es necesario el testing para estos casos, con desarrollo seguro basta y sobra.«.
Mejores prácticas adicionales
- Capacitación Constante: Formar regularmente al personal en temas de seguridad (nuevas amenazas, protocolos de protección, etc.). Para nuestro caso como Testers Ágiles, tenemos el programa de estudios del ISTQB STE.
- Responsabilidad Compartida: Fomentar la cultura de “Shift-Left Security”, donde cada miembro del equipo asume un rol en la protección de los activos.
- Auditorías y Revisiones Periódicas: Realizar “security reviews” y “compliance checks” para garantizar que las medidas de seguridad estén vigentes y actualizadas.
- Pruebas de Respuesta a Incidentes: Programar simulaciones de incidentes (table-top exercises) para asegurar la eficiencia de los planes de contingencia.
Comentario final
Clasificar los activos y elegir las medidas de protección adecuadas son elementos esenciales que nos propone el ISTQB Security Testing. El tester ágil debe colaborar estrechamente con product owners, desarrolladores, y demás interesados para garantizar que la seguridad se integre en cada etapa del desarrollo de software, maximizando el valor para el negocio y minimizando los riesgos.
Todo suena muy bien, mucho concepto, muy claro todo, pero tu realidad puede ser distinta y tu madurez profesional y la de los miembros del equipo pueden estar aún lejos de todo lo escrito hasta aquí, pero lo importante es que comiences en algún momento a sembrar la semilla de incorporar testing de seguridad.
Al seguir estas recomendaciones –desde la planificación y el diseño hasta la gestión de incidentes y la documentación de cambios– tu equipo estará mejor preparado para enfrentar las amenazas actuales y futuras, manteniendo los niveles de seguridad requeridos y cumpliendo con los estándares internacionales más reconocidos.
En lo que pueda ayudarte, estoy a tus órdenes. Puedes contactarte conmigo a través de LinkedIn.
