Por Qué la Clasificación de Riesgos de Aplicaciones Importa para las Organizaciones Reguladas
Las organizaciones reguladas operan docenas — a veces cientos — de aplicaciones, cada una con un perfil de riesgo diferente. Sin un marco de clasificación estructurado, los recursos de seguridad se dispersan demasiado: las aplicaciones críticas reciben el mismo nivel de escrutinio que las utilidades internas, y los auditores encuentran imposible evaluar si los controles son proporcionales al riesgo real.
La clasificación de riesgos de aplicaciones es el fundamento que conecta el riesgo empresarial con los requisitos de controles de seguridad. Para auditores y oficiales de cumplimiento, responde a una pregunta directa: ¿sabe la organización qué aplicaciones son más importantes y aplica los controles en consecuencia?
Los reguladores esperan esto cada vez más. DORA (Digital Operational Resilience Act) requiere que las entidades financieras clasifiquen los activos ICT por criticidad. NIS2 exige medidas de seguridad proporcionales al riesgo. PCI DSS exige que los entornos de datos de titulares de tarjetas reciban controles mejorados. Sin un marco de clasificación defendible, una organización no puede demostrar cumplimiento con ninguno de estos regímenes.
Un marco de clasificación bien implementado también previene dos fallos comunes de auditoría: la sobreclasificación (donde todo se etiqueta como «crítico» y se desperdician recursos) y la infraclasificación (donde aplicaciones genuinamente críticas se tratan como rutinarias).
Criterios de Clasificación de Riesgos
Un marco de clasificación robusto evalúa las aplicaciones en múltiples dimensiones. Ningún criterio único es suficiente por sí solo — la clasificación debe reflejar el perfil de riesgo combinado.
Sensibilidad de los Datos
La naturaleza de los datos procesados, almacenados o transmitidos por la aplicación es el principal determinante de clasificación. Considere:
- Información de Identificación Personal (PII): Nombre, dirección, números de identificación nacional, datos biométricos
- Datos financieros: Números de tarjetas de pago, datos de cuentas bancarias, registros de transacciones
- Información de salud: Expedientes de pacientes, datos de diagnóstico, información de prescripciones
- Datos empresariales confidenciales: Secretos comerciales, planes estratégicos, actividad de fusiones y adquisiciones
- Credenciales de autenticación: Contraseñas, tokens, claves API, certificados
Alcance Regulatorio
Las aplicaciones que caen dentro de mandatos regulatorios específicos conllevan obligaciones de cumplimiento inherentes:
- DORA: Sistemas ICT que apoyan funciones críticas o importantes en servicios financieros
- NIS2: Sistemas operados por entidades esenciales o importantes
- PCI DSS: Cualquier sistema dentro del entorno de datos de titulares de tarjetas
- GDPR: Sistemas que procesan datos personales de residentes de la UE
- Regulación sectorial específica: Salud (equivalentes a HIPAA), energía, telecomunicaciones
Criticidad Empresarial
¿Qué tan esencial es la aplicación para las operaciones empresariales continuas? Considere:
- Impacto en los ingresos si la aplicación no está disponible
- Función orientada al cliente vs. soporte interno
- Objetivo de Tiempo de Recuperación (RTO) y Objetivo de Punto de Recuperación (RPO)
- Obligaciones contractuales vinculadas a la disponibilidad de la aplicación
Exposición
La superficie de ataque varía significativamente según cómo se accede a la aplicación:
- De cara al público: Accesible desde internet sin autenticación
- Externo con autenticación: Accesible por internet pero requiere inicio de sesión (portales de clientes, APIs de socios)
- Interno: Disponible solo dentro de la red corporativa
- Interno restringido: Accesible solo desde segmentos de red o estaciones de trabajo específicos
Complejidad de Integración
Las aplicaciones con numerosas integraciones conllevan un riesgo elevado porque un compromiso puede propagarse:
- Número de conexiones de sistemas ascendentes y descendentes
- Acceso a bases de datos compartidas o data lakes
- Exposición de API a terceros
- Uso de cuentas de servicio o credenciales compartidas
Niveles de Clasificación
El siguiente modelo de cuatro niveles proporciona un marco práctico. Las organizaciones deben adaptar los criterios específicos a su contexto, pero debe preservarse el principio de controles diferenciados.
| Nivel | Etiqueta | Criterios | Ejemplos | Controles Requeridos |
|---|---|---|---|---|
| Nivel 1 | Crítico | Procesa datos altamente sensibles (PII a escala, transacciones financieras); sujeto a múltiples mandatos regulatorios; de cara al público; crítico para el negocio con RTO inferior a 4 horas; amplias integraciones con terceros | Plataforma bancaria principal, sistema de procesamiento de pagos, portal de salud orientado al cliente, plataforma de negociación | Suite completa de pruebas de seguridad (SAST, DAST, SCA, pruebas de penetración); modelado de amenazas requerido; firma de seguridad para cada versión; monitorización continua; revisión de auditoría trimestral |
| Nivel 2 | Alto | Procesa datos sensibles; sujeto a al menos un mandato regulatorio; de cara al exterior con autenticación; impacto empresarial significativo si se ve comprometido; complejidad de integración moderada | Sistema de gestión de relaciones con clientes, plataforma de RRHH con PII de empleados, pasarela de API de socios, informes financieros internos | SAST y SCA en cada compilación; DAST trimestral; pruebas de penetración anuales; modelo de amenazas para cambios importantes; revisión de seguridad para versiones significativas |
| Nivel 3 | Moderado | Datos sensibles limitados; alcance regulatorio directo mínimo; de cara al interior; impacto empresarial moderado; integraciones limitadas | Herramientas internas de gestión de proyectos, intranet corporativa, sistema de gestión documental, plataformas internas de comunicación | SAST y SCA en cada compilación; DAST anualmente; revisión de seguridad para cambios de arquitectura; gestión de cambios estándar |
| Nivel 4 | Bajo | Sin datos sensibles; sin alcance regulatorio directo; de cara al interior con acceso restringido; bajo impacto empresarial; sistema aislado | Entornos sandbox de desarrollo, wikis internos con contenido no sensible, entornos de prueba (sin datos de producción) | SCA para vulnerabilidades de dependencias; prácticas estándar de codificación segura; revisión periódica |
Cómo la Clasificación Impulsa los Requisitos de Controles de Seguridad
El propósito completo de la clasificación es crear un mapeo defendible y proporcional entre el riesgo y los controles. El principio es directo: las aplicaciones de mayor nivel requieren más controles, pruebas más frecuentes, gestión de cambios más estricta y recopilación de evidencia más rigurosa.
Este mapeo debe estar documentado en una política, no dejado al criterio individual. Los auditores buscarán un estándar claro y escrito que especifique qué controles son obligatorios en cada nivel.
| Área de Control | Nivel 1 (Crítico) | Nivel 2 (Alto) | Nivel 3 (Moderado) | Nivel 4 (Bajo) |
|---|---|---|---|---|
| Frecuencia SAST | Cada confirmación / pull request | Cada compilación | Cada compilación | Periódico / bajo demanda |
| Frecuencia DAST | Automatizado semanal + antes de cada versión | Trimestral | Anualmente | No requerido |
| Frecuencia SCA | Monitorización continua | Cada compilación | Cada compilación | Trimestral |
| Pruebas de Penetración | Semestral (mínimo) | Anual | Basado en riesgos / bienal | No requerido |
| Modelado de Amenazas | Requerido; actualizado por cambio importante | Requerido para cambios importantes | Recomendado | No requerido |
| Aprobación de Versiones | Firma del responsable de seguridad requerida | Revisión de seguridad para cambios significativos | Gestión de cambios estándar | Gestión de cambios estándar |
| Retención de Evidencia | 7 años (o mínimo regulatorio) | 5 años | 3 años | 1 año |
| Cadencia de Revisión de Auditoría | Trimestral | Semestral | Anual | Como parte de la revisión periódica del programa |
Modelo de Gobernanza para la Clasificación
La clasificación no es un ejercicio puntual. Requiere un modelo de gobernanza que defina la propiedad, la cadencia de revisión y los procedimientos de escalada.
Quién Clasifica
El propietario de la aplicación (normalmente un gerente de línea de negocio o propietario del producto) propone la clasificación inicial basándose en los criterios anteriores. Esto no debe dejarse únicamente a los equipos de desarrollo, que pueden carecer de visibilidad sobre las dimensiones de riesgo regulatorio y empresarial.
Quién Revisa y Aprueba
La clasificación propuesta debe ser revisada y aprobada por:
- Equipo de Seguridad de la Información / Seguridad de Aplicaciones: Valida la evaluación de riesgos técnicos
- Función de Cumplimiento / Riesgos: Confirma que el alcance regulatorio está correctamente identificado
- Liderazgo empresarial: Confirma la evaluación de criticidad empresarial
Proceso de Escalada
Cuando el propietario de la aplicación y el equipo de seguridad no están de acuerdo sobre la clasificación, el asunto debe escalarse al comité de riesgos o al CISO para la determinación final. Todas las decisiones de escalada deben documentarse con su justificación.
Disparadores de Reclasificación
Las aplicaciones deben reclasificarse cuando:
- La aplicación comienza a procesar una nueva categoría de datos sensibles
- Se aplica un nuevo mandato regulatorio (por ejemplo, la organización queda sujeta a DORA)
- La aplicación pasa de exposición interna a externa
- Se produce un incidente de seguridad significativo que involucra a la aplicación
- Cambios arquitectónicos importantes alteran el perfil de integración
- El ciclo de revisión anual identifica un cambio en la criticidad empresarial
Qué Deben Verificar los Auditores
Al evaluar el marco de clasificación de riesgos de aplicaciones de una organización, los auditores deben verificar lo siguiente:
- Política de clasificación documentada: Existe una política formal y aprobada que define los criterios de clasificación, los niveles y los requisitos de controles asociados
- Inventario completo de aplicaciones: Todas las aplicaciones están clasificadas — no solo las que la organización considera importantes
- Aplicación coherente de criterios: Aplicaciones similares están clasificadas en el mismo nivel; no hay evidencia de clasificación arbitraria o inconsistente
- Los controles coinciden con el nivel: Tome muestras de aplicaciones en cada nivel y verifique que los controles mandatados estén realmente en funcionamiento — no solo documentados, sino operativos
- Se mantiene la cadencia de revisión: Evidencia de que las clasificaciones se revisan con la frecuencia requerida, con resultados documentados
- Registros de reclasificación: Donde las aplicaciones han sido reclasificadas, evidencia de que se identificó el disparador, se realizó la revisión y se ajustaron los controles
- Registros de gobernanza: Actas de reuniones de revisión de clasificación, decisiones de escalada con justificación, registros de aprobación
Señales de Alerta
Los siguientes hallazgos deben generar preocupación inmediata durante una auditoría:
- Todas las aplicaciones clasificadas en el mismo nivel: Esto indica que el marco no se está aplicando de manera significativa. Es estadísticamente implausible que todas las aplicaciones tengan el mismo riesgo.
- Sin proceso de reclasificación: Si ninguna aplicación ha sido reclasificada nunca, o el proceso no existe o la organización no está monitorizando los cambios en el perfil de riesgo.
- Controles no diferenciados por nivel: Si las aplicaciones de Nivel 1 y Nivel 3 reciben pruebas de seguridad idénticas, el marco de clasificación es decorativo en lugar de operativo.
- Clasificación realizada únicamente por equipos de desarrollo: Sin aportación empresarial y de cumplimiento, es probable que las clasificaciones subvaloren el riesgo regulatorio y empresarial.
- Sin evidencia de supervisión de gobernanza: Existen decisiones de clasificación pero no hay registro de revisión, cuestionamiento o aprobación por parte de las funciones de seguridad o riesgos.
- Clasificaciones obsoletas: Aplicaciones clasificadas hace dos o más años sin evidencia de revisión, a pesar de los cambios conocidos en el entorno.
Lectura Adicional
Para orientación relacionada sobre gobernanza de seguridad de aplicaciones y prácticas de auditoría, consulte:
- Descripción General de Seguridad de Aplicaciones
- Fundamentos del SDLC Seguro
- Cómo los Auditores Evalúan los Controles de Seguridad de Aplicaciones
Relacionado para Auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- Arquitectura de Seguridad NIS2
- DORA Artículo 28 Explicado
- Controles Básicos de Seguridad CI/CD
¿Nuevo en la auditoría de CI/CD? Empiece con nuestra Guía para Auditores.
