Proteger la información es más que una necesidad: es una prioridad, no sólo para las empresas sino para nosotros como individuos. Si estás trabajando (o es tu intención) como «software tester» o «agile tester», y quieres iniciarte en el campo de las «pruebas de seguridad», y si además estás trabajando en proyectos en los que se aplican metodologías ágiles seguramente ya sabes que antes de cada «Sprint Planning» resulta muy importante evaluar los riesgos y planificar las pruebas de seguridad a partir de los requerimientos que el equipo reciba representados por épicas y/o historias de usuario.
Hoy quiero compartir un poco de enfoque práctico y que pueda adaptarse a tu proyecto para ayudarte a identificar y priorizar aquellas áreas de mayor sensibilidad y riesgo que podamos detectar en los requerimientos.
Punto para reflexionar: El requerimiento del negocio representado por una épica o historias de usuario, debe tener en su alcance y/o en sus criterios de aceptación consideraciones referidas a temas de seguridad para que nosotros, los técnicos, podamos analizar y estimar nuestro esfuerzo durante las actividades de testing de seguridad. Si ésto no ocurriera, el equipo completo debería reunirse y tratar seriamente la situación con la intención de provocar el cambio que se necesita.
Primera pregunta que debemos formular: ¿Por qué es tan importante evaluar la sensibilidad de la información?
La sensibilidad de los datos determina el nivel de protección que se requiere. Por eso, antes de lanzar cualquier prueba de seguridad, es fundamental identificar cuáles son los activos críticos y datos sensibles, ya que esto te permitirá enfocar tus esfuerzos en las áreas más vulnerables. Por supuesto que esto debe estar definido en la épica e historias de usuario, desde un punto de vista macro al detalle que corresponda.
Segunda pregunta que debemos formular: ¿Cuál es el reto de planificar pruebas de seguridad?
El software tester o agile tester dedicado a pruebas de seguridad, debe cubrir diversas áreas: desde pruebas de penetración hasta evaluaciones de vulnerabilidades y análisis de riesgos. Ahora bien, ¿En qué nos pueden estar ayudando las IA Gen? Imagina tener una herramienta que, mediante un framework de prompts, nos ayude a analizar la épica o historias de usuario, clasificar los riesgos (alto, medio o bajo) y recomendarte las pruebas adecuadas. ¡Sería fantástico! ¿Cierto? Esto no solo agilizaría nuestro proceso de testing de seguridad, sino que también nos guiaría para detectar debilidades en los controles existentes y nos ofrecería estrategias para confirmar que los parches y actualizaciones se implementen correctamente a mediano / largo plazo.
Tercera pregunta que nos debemos formular: ¿Podemos tener una herramienta adaptable y genérica?
El valor de un framework de prompt (genérico) radica en su capacidad para adaptarse a cualquier situación o escenario que se nos presente. No importa si el requerimiento de negocio proviene de una nueva funcionalidad en la aplicación o de la actualización de un sistema antiguo; lo que cuenta aquí es que podrá extraer los datos relevantes y obtener recomendaciones precisas de forma automática, siempre y cuando esté correctamente estructurado. Este tipo de herramienta puede funcionar de manera independiente, pero también te puede sugerir cuándo integrar otras soluciones o herramientas específicas según el contexto.
Algunos acciones que puedes considerar para evaluar riesgos:
Recolección de información: Antes de cada «Sprint Planning», deberías solicitar que te compartan lo más pronto posible y con una cierta antelación la documentación funcional y técnica para analizar (p.e. el requerimiento del negocio) y/o la épica y/o las historias de usuario elaborada por el Product Owner para poder identificar los activos críticos y datos sensibles. Si es que están definidos, claro.
Evaluación y clasificación de riesgos: En la documentación debería estar definido los niveles de riesgo de cada elemento. Esto nos permitirá centrar nuestros esfuerzos en las áreas más críticas.
Planificación de pruebas: Con base en la clasificación, genera un plan de pruebas de seguridad que incluya acciones concretas como pruebas de penetración, evaluaciones de vulnerabilidades y seguimientos para la aplicación de parches.
Recomendaciones de mitigación y documentación: No olvides incluir acciones para mitigar las vulnerabilidades encontradas y documentar los resultados. Esto te ayudará a mejorar continuamente el proceso y a cumplir con normativas reconocidas, como NIST e ISO 27001.
Punto para reflexionar: Las acciones aquí mencionadas pueden ser conducidas mediante «frameworks de prompt».
Síntesis del contenido: Pruebas de seguridad y sensibilidad de la información
Concepto de sensibilidad de la información:
Se define como el grado en que la información requiere protección para garantizar su confidencialidad, integridad y disponibilidad. Se destaca que, según el Glosario NIST, la sensibilidad es clave para determinar el nivel de protección requerido, dado que la exposición de datos sensibles puede acarrear consecuencias que varían desde impactos menores hasta desastres.
Objetivos de las pruebas de seguridad:
El propósito principal es verificar que la implementación de seguridad en un sistema protege los datos y mantiene la funcionalidad prevista. Entre los objetivos se incluyen la evaluación de la eficacia de los controles de seguridad existentes, la identificación de debilidades y vulnerabilidades, y la puesta en marcha de una estrategia que contemple pruebas de confirmación para monitorear el progreso en la aplicación de parches y actualizaciones a largo plazo.
Limitaciones de las pruebas de seguridad:
Aunque las pruebas son esenciales para identificar vulnerabilidades, se reconoce que no pueden garantizar la eliminación total de riesgos o la ausencia completa de vulnerabilidades. Esto enfatiza la necesidad de complementar las pruebas con evaluaciones de riesgos continuas.
Rol del ingeniero de pruebas de seguridad (STE):
Se destaca que el STE debe basar la planificación y diseño de las pruebas en evaluaciones de riesgos de seguridad, aprovechando la sensibilidad de la información como fuente clave para priorizar áreas de alto riesgo y determinar el rigor de las pruebas a aplicar.
Enfoque y recomendaciones:
La evaluación de riesgos debe ser considerada una «instantánea» del estado actual, sirviendo para priorizar las pruebas de seguridad de acuerdo con el nivel de riesgo y la criticidad de la información. Además, se sugiere incluir ejemplos prácticos y comparativas con otros estándares de seguridad para enriquecer el análisis.
Respecto de los contenidos: «1.1.1. Assets and their corresponding protection level» y «1.1.2. Information Sensitivity and Security Testing».
Puntos en común
Importancia de la protección de activos: Ambas secciones subrayan la necesidad de proteger los activos de una organización. Los activos se definen ampliamente e incluyen personas, información, software y hardware.
Tríada CIA (Confidencialidad, Integridad y Disponibilidad): Ambas secciones resaltan la importancia de la confidencialidad, la integridad y la disponibilidad (CIA) como pilares fundamentales para determinar el valor de un activo y la necesidad de protección.
Necesidad de pruebas de seguridad: Ambas secciones enfatizan la importancia de realizar pruebas de seguridad para garantizar la protección de los activos y la información.
Sensibilidad de la información como factor determinante: Ambas secciones implican que la sensibilidad de la información de los activos debe ser un factor determinante para las pruebas de seguridad.
Puntos en que se diferencian:
Enfoque principal:
«1.1.1.» se centra en la clasificación de activos según su nivel de sensibilidad (alto, medio, bajo) y en la determinación del nivel de protección adecuado.
«1.1.2.» se centra en la relación entre la sensibilidad de la información y la necesidad de realizar pruebas de seguridad para verificar que se implementen los controles adecuados.
Profundidad en los niveles de protección:
«1.1.1.» describe los niveles de seguridad (alto, medio y bajo) y cómo estos influyen en los requisitos de protección.
«1.1.2.» no profundiza en los niveles de protección, sino que se centra en cómo la sensibilidad de la información justifica la realización de pruebas de seguridad.
Énfasis en la evaluación de riesgos:
«1.1.2.» destaca que una evaluación de riesgos de seguridad desde la perspectiva de la sensibilidad de la información es una fuente valiosa para planificar y diseñar pruebas de seguridad.
«1.1.1.» no menciona explícitamente la evaluación de riesgos.
Objetivos de las pruebas de seguridad:
«1.1.2.» enumera los objetivos de las pruebas de seguridad, incluyendo la evaluación de controles existentes, el descubrimiento de vulnerabilidades y el establecimiento de una estrategia de pruebas.
«1.1.1.» no detalla los objetivos específicos de las pruebas de seguridad.
Ejemplos:
«1.1.1.» proporciona ejemplos de activos (software, información, hardware, instalaciones físicas).
«1.1.1.» proporciona ejemplos de la relación entre el nivel de sensibilidad y la necesidad de pruebas de seguridad.
«1.1.2.» no incluye ejemplos concretos de activos o niveles de sensibilidad.
Ideas básicas para un Framework de Prompt
Te comparto algunas ideas para que explores la elaboración de tu propio Framework y puedas comenzar a implementarlo en tu proyecto.
Nota importante: Recuerda en todo momento las recomendaciones que vengo dando en los diferentes artículos publicados en relación con los sesgos, las alucinaciones, las interacciones que debes necesariamente tener, los refinamientos que deberás considerar, la gestión y tratamiento de los datos, entre otros.
Objetivo y Alcance del Framework
El framework debe funcionar como una “plantilla” que el ingeniero de pruebas de seguridad utilizará antes de cada Sprint Planning. Su objetivo es:
- Analizar la épica/historia de usuario para identificar activos críticos y datos sensibles.
- Evaluar riesgos de acuerdo a la probabilidad e impacto de vulnerabilidades, considerando los estándares (NIST, ISO 27001, entre otros).
- Priorizar áreas de riesgo para recomendar pruebas de penetración, evaluaciones de vulnerabilidades y estrategias de confirmación (seguimiento de parches y actualizaciones).
- Generar recomendaciones automatizadas tanto para la planificación de pruebas como para acciones de mitigación, además de una guía para la documentación de resultados.
Componentes Clave del Framework
Para lograr este objetivo, propongo estructurarlo en los siguientes módulos:
a) Recolección y Análisis Inicial
- Prompt de Contexto: Incluir una instrucción que permita al framework extraer de la épica o historia de usuario la descripción completa del requerimiento.
- Ejemplo: “Analiza la siguiente épica/historia de usuario y extrae los activos críticos y datos sensibles, considerando los requisitos de confidencialidad, integridad y disponibilidad (según NIST e ISO 27001): [Descripción].”
b) Evaluación de Riesgos y Priorización
- Análisis de Impacto: Generar un prompt que evalúe el riesgo de cada activo en función de su sensibilidad, impacto y probabilidad de explotación.
- Ejemplo: “Clasifica los riesgos identificados en niveles alto, medio y bajo, y justifica la priorización para las pruebas de seguridad (penetración, evaluaciones de vulnerabilidades y análisis de riesgos).”
c) Planificación y Ejecución de Pruebas
- Generación de Estrategias de Pruebas: Incluir un prompt que recomiende acciones específicas para cada nivel de riesgo detectado.
- Ejemplo: “Sugerir un plan de pruebas de seguridad que incluya pruebas de penetración en áreas de alto riesgo, evaluaciones de vulnerabilidades en áreas críticas y pruebas de confirmación para el seguimiento de parches, con recomendaciones de mitigación.”
d) Mitigación y Seguimiento
- Recomendaciones de Mitigación: Crear un prompt que no solo identifique vulnerabilidades, sino que también recomiende acciones para reducir o eliminar el riesgo (por ejemplo, reforzar controles o actualizar software).
- Ejemplo: “Genera una lista de acciones de mitigación basadas en estándares reconocidos para cada vulnerabilidad detectada.”
- Documentación de Resultados: Incluir una estructura para informes que permita documentar los hallazgos, las acciones tomadas y las métricas de evaluación (ver más abajo).
Punto para reflexionar: El framework de prompt a desarrollar debe ser genérico para que lo podamos adaptar a cualquier escenario que se nos presente. Por otra parte y no menor, la base de las estructuras de los prompts debe ser las definiciones contenidas en el programa de estudios y/o en ciertos estándares según corresponda. De esta manera lograremos tener prompts alineados con las mejores prácticas en cuanto a testing de seguridad.
Fuente de inspiración:
Toda la información analizada (1.1.2. Information Sensitivity and Security Testing) se fundamenta en el contenido extraído del ISTQB STE Syllabus.
