Introducción
En el contexto de las pruebas de seguridad de software, es fundamental comprender los niveles de protección de los activos (assets) y su importancia dentro de una organización. La seguridad de los activos se basa en los principios de confidencialidad, integridad y disponibilidad (conocidos como la triada CIA), que ayudan a clasificar los activos y determinar los controles de seguridad adecuados.
Clasificación de los Activos y su Nivel de Protección
Un activo puede ser cualquier recurso valioso dentro de una organización, incluyendo:
- Activos de software: Aplicaciones, sistemas operativos y bases de datos.
- Activos de información: Datos personales, planes de negocio y documentación interna.
- Activos de hardware: Servidores, dispositivos de almacenamiento y redes.
- Activos físicos: Instalaciones y equipos críticos.
Punto para reflexionar: Nosotros como testers en particular deberemos enfocarnos en los «activos de software» y «activos de información» que ya con eso tenemos mucho. Imaginate que deberemos considerarlos para cuando estemos analizando requerimientos y/o historias de usuario, para luego estimar y realizar el resto de nuestras actividades. 🙂
Relación con la Triada CIA
La protección de un activo se determina con base en los siguientes principios:
- Confidencialidad: Protección contra el acceso no autorizado.
- Integridad: Prevención de modificaciones o eliminaciones no autorizadas.
- Disponibilidad: Garantizar el acceso oportuno cuando se necesita.
Punto para reflexionar: Hay que entender aquí que debemos tener acceso a base de datos y por ende, debemos tener conocimiento en manejo de base de datos y tratamiento de datos, además de contar con los permisos que correspondan para poder realizar nuestro trabajo sin ninguna restricción y/o dependencias, cosa que a veces no es tan sencillo encontrar y lograr y que obliga a tener varias reuniones para justificar «los porqués» y fundamentalos, y otras hasta tener que demostrar que sabemos lo que debemos hacer.
En función de estos principios, los activos se clasifican en tres niveles de sensibilidad:
- Baja sensibilidad: Activos donde la disponibilidad es prioritaria (ej. información de tráfico pública).
- Media sensibilidad: Activos donde la integridad es clave (ej. registros financieros que deben ser exactos y auditables).
- Alta sensibilidad: Activos donde la confidencialidad es crítica (ej. datos de pacientes en el sector salud).
Punto para reflexionar: Estos niveles de sensibilidad deben estar definidos por el equipo de proyecto y/o de desarrollo y debemos estar involucrados desde el minuto 0(cero) como para poder entender el origen de todo y hasta incluso y dependiendo de nuestra experiencia, aportar valor con nuestros comentarios y/o sugerencias y así lograr un mejor refinamiento del requerimiento a desarrollar.
Estrategias para la Protección de Activos
Para proteger estos activos, se implementan distintos niveles de seguridad y estrategias de pruebas, alineadas con los estándares y mejores prácticas internacionales:
- ISO 27001: Establece un Sistema de Gestión de Seguridad de la Información (SGSI) para proteger activos según su nivel de riesgo.
- NIST SP 800-53: Define controles específicos para salvaguardar la información dentro de sistemas críticos.
- OWASP Top 10: Proporciona metodologías para la detección y mitigación de vulnerabilidades en aplicaciones web.
Punto para reflexionar: Debemos estar conscientes que hay mucho para leer, estudiar, investigar y que la inteligencia artificial generativa nos puede ayudar y mucho para estos casos. Lo cierto es que debemos conocer estos temas como para ampliar nuestro horizonte y contar con más herramientas.
Deberemos diseñar pruebas que verifiquen la implementación correcta de estos controles y garantizar que los activos estén protegidos según su clasificación.
Punto para reflexionar: Tengamos en cuenta que estas definiciones deben surgir de los requerimientos para luego estimar nuestro esfuerzo de prueba. Ahora bien, el requerimiento original puede no tener información que resulte en estas definiciones que más tarde debiera tener la historia de usuario, por eso es muy importante que contemos con este conocimiento y práctica de ser posible, como para aportar ese valor que antes estaba mencionando en las reuniones en las que nos estén invitando y así cubrir estos aspectos. ¿Se va entiendo la dificultad del tema verdad? ¿Te imaginas cómo lograrlo en tu proyecto? ¿Se encuentra lo suficientemente maduro tu equipo para lograrlo?
Ejemplos de Aplicación en la Industria
Ejemplo 1: Sector Bancario
En una institución financiera, los datos de transacciones bancarias deben garantizar integridad y confidencialidad. Para validar esto, un tester de seguridad realiza:
- Pruebas de integridad de datos: Asegurando que las transacciones no puedan ser alteradas por usuarios no autorizados.
- Pruebas de cifrado: Verificando que la transmisión de datos esté protegida con protocolos seguros como TLS 1.3.
- Simulación de ataques internos: Evaluando cómo un usuario con acceso puede intentar modificar transacciones fraudulentamente.
Ejemplo 2: Industria de la Salud
En un hospital, los registros electrónicos de salud contienen información crítica que debe cumplir con altos niveles de confidencialidad y disponibilidad. Un tester de seguridad podría:
- Realizar pruebas de control de acceso: Verificando que solo el personal autorizado pueda acceder a los registros de los pacientes.
- Pruebas de disponibilidad: Simulando una sobrecarga de peticiones para evaluar la resistencia del sistema a ataques de denegación de servicio (DDoS).
- Validar normativas: Asegurar que el sistema cumple con regulaciones como HIPAA para la protección de datos médicos.
Conclusión
Comprender los niveles de protección de los activos es fundamental para diseñar y ejecutar pruebas de seguridad efectivas. Aplicar estrategias alineadas con estándares internacionales como ISO 27001, NIST y OWASP permite a los testers evaluar los controles de seguridad en función del riesgo asociado a cada activo. Mediante la aplicación de pruebas en escenarios reales, los testers pueden detectar vulnerabilidades críticas y reforzar la seguridad del software, garantizando la protección de la información en distintos sectores industriales.
Fuente de inspiración: 1.1.1. Asset and their corresponding protection level (ISTQB CT-STE)
