Requisitos y estándares de evaluación
Dos evaluaciones pueden usar el mismo escáner y necesitar evidencias diferentes. Una busca comprobar requisitos contractuales sobre el entorno de datos de tarjetas. Otra alimenta la gestión de parches de una red interna. Una tercera intenta validar la superficie de una aplicación antes de publicarla. La herramienta observa. El requisito explica qué debe demostrarse.
Conviene distinguir cuatro capas:
- obligación: ley, regulación o contrato aplicable
- marco de gestión: resultados y procesos que la organización adopta
- metodología de evaluación: forma de planificar, ejecutar y comunicar pruebas
- estándar técnico: requisitos verificables para una tecnología o control
Llamar «cumplimiento» a las cuatro conduce a afirmaciones incorrectas. También puede convertir una evaluación de seguridad en una lista de controles desconectada del riesgo.
PCI DSS: requisitos contractuales concretos
Sección titulada «PCI DSS: requisitos contractuales concretos»El Estándar de Seguridad de Datos para la Industria de Tarjetas de Pago (PCI DSS, por su nombre en inglés) aplica a entidades que almacenan, procesan o transmiten datos de titulares de tarjeta o que pueden afectar a la seguridad del entorno de datos del titular de la tarjeta (CDE). Su autoridad procede de los programas de las marcas de pago y de contratos del ecosistema, no de ser una ley general.
PCI DSS 4.x incluye requisitos específicos de escaneo interno y externo, periodicidad, cambios significativos, repetición de escaneos y cualificación del proveedor externo cuando corresponde. La evidencia depende del alcance del CDE, su segmentación y la función de cada sistema.
Una evaluación para PCI necesita confirmar:
- inventario y límites del CDE
- sistemas conectados o con capacidad de afectar al CDE
- segmentación efectiva
- tipo de escaneo y escáner requerido
- periodicidad y evento que dispara una nueva prueba
- tratamiento de hallazgos y nuevos escaneos
- conservación de informes y evidencias
La puntuación pública tampoco decide por sí sola el tratamiento. PCI permite contextualizar el riesgo según sus propios requisitos y el entorno. La interpretación necesita documentarse.
HIPAA: análisis de riesgo, no una frecuencia universal de escaneo
Sección titulada «HIPAA: análisis de riesgo, no una frecuencia universal de escaneo»La Ley de Portabilidad y Responsabilidad de los Seguros Médicos (HIPAA, por su nombre en inglés) y su regla de seguridad exigen que las entidades cubiertas y sus entidades colaboradoras protejan la información sanitaria electrónica. La guía del Departamento de Salud y Servicios Humanos de Estados Unidos (HHS) exige un análisis preciso y completo de los riesgos y vulnerabilidades para la confidencialidad, integridad y disponibilidad de la información protegida.
HIPAA no prescribe una herramienta concreta ni una frecuencia universal de escaneo trimestral. Una organización puede utilizar escaneos como evidencia dentro de su análisis de riesgo, pero debe justificar alcance y recurrencia según cambios, activos y amenazas.
Confundir el requisito de análisis con «ejecutar Nessus cada trimestre» deja fuera sistemas, datos, procesos y controles que el escáner no observa.
FISMA y el ecosistema NIST
Sección titulada «FISMA y el ecosistema NIST»La Federal Information Security Modernization Act (FISMA) establece responsabilidades para programas de seguridad de sistemas federales estadounidenses. Su aplicación se apoya en estándares y publicaciones de NIST, autorizaciones y supervisión federal.
No existe una única «checklist FISMA» equivalente para cualquier organización. El sistema, su categorización, controles seleccionados, plan de evaluación y autorización determinan la evidencia. NIST SP 800-53A desarrolla procedimientos para evaluar controles. NIST SP 800-115 ofrece guía técnica para pruebas y evaluaciones.
Fuera de ese contexto, esas publicaciones siguen siendo referencias útiles. No conviene declarar cumplimiento FISMA sin el proceso y autoridad que lo sustentan.
ISO/IEC 27001: un sistema de gestión basado en riesgo
Sección titulada «ISO/IEC 27001: un sistema de gestión basado en riesgo»ISO/IEC 27001 especifica requisitos para un sistema de gestión de la seguridad de la información (ISMS, por su nombre en inglés). La organización determina su contexto, riesgos, tratamiento, controles, objetivos, auditoría y mejora.
La norma no establece de forma general «escaneos internos y externos trimestrales» para cualquier organización certificada. Esa afirmación mezcla un requisito concreto de otros estándares con un sistema de gestión basado en riesgo.
Un escaneo puede proporcionar evidencia para gestión de vulnerabilidades, seguridad técnica o revisión de controles. La certificación evalúa el ISMS y su aplicación, no la mera existencia de un informe del escáner.
Metodologías de pruebas
Sección titulada «Metodologías de pruebas»NIST SP 800-115 organiza pruebas técnicas y evaluación. PTES propone fases para pentesting. OSSTMM estructura medición y pruebas a través de varios canales. OWASP mantiene guías y estándares especializados.
Su utilidad depende de la tarea:
| Referencia | Uso principal |
|---|---|
| NIST SP 800-115 | planificación y ejecución de pruebas técnicas |
| PTES | flujo comunitario de un pentest |
| OSSTMM | metodología y métricas de pruebas operativas |
| OWASP WSTG | casos de prueba para aplicaciones web |
| OWASP ASVS | requisitos verificables de seguridad de aplicaciones |
| OWASP MASVS/MASTG | requisitos y pruebas para aplicaciones móviles |
OWASP Top 10 es un documento de concienciación sobre categorías de riesgo. No proporciona por sí solo cobertura suficiente para una evaluación web. WSTG y ASVS responden a tareas más precisas.
La metodología no reemplaza el alcance y las reglas de enfrentamiento. Ayuda a construir la prueba. El contrato decide qué partes aplican.
Auditoría, evaluación y certificación
Sección titulada «Auditoría, evaluación y certificación»Una auditoría obtiene evidencia y la compara con criterios definidos. Una evaluación de vulnerabilidades identifica y valida debilidades dentro de una cobertura. Un pentest demuestra rutas e impacto. Una certificación es una decisión formal de un organismo respecto a un esquema.
Pueden compartir observaciones sin ser intercambiables. Un pentest puede aportar evidencia a una auditoría. No certifica por sí solo el sistema. Un escaneo puede cubrir un requisito. No demuestra que el programa de gestión funcione.
Los modelos de evaluación separan además pentest, Red Team, Purple Team, posición e información inicial. Liderazgo y gobierno explica quién interpreta obligaciones y acepta riesgo.
Traducir un requisito a controles comprobables
Sección titulada «Traducir un requisito a controles comprobables»Para cada obligación registra:
- fuente, versión y fecha de vigencia
- entidad, sistema y datos a los que aplica
- texto o identificador del requisito
- criterio observable
- activo y responsable
- método de prueba
- evidencia y limitaciones
- frecuencia o evento de repetición
- tratamiento de desviaciones
La evidencia debe responder al criterio. Un PDF de 500 páginas no demuestra que todos los activos del CDE fueran alcanzables. Un panel sin alertas no demuestra que las credenciales tuvieran privilegios.
Estándar como suelo, contexto como dirección
Sección titulada «Estándar como suelo, contexto como dirección»El estándar reduce ambigüedad y favorece comparaciones. El entorno determina dónde una comprobación necesita mayor profundidad. Un activo fuera de un requisito formal puede seguir siendo crítico para la organización. Una vulnerabilidad sin CVE puede incumplir un requisito de configuración. Una excepción aceptada puede seguir apareciendo en el informe y necesitar caducidad.
La pregunta final no es «¿qué plantilla ejecuta este estándar?». Es «¿qué evidencia permitiría afirmar que el requisito se cumple en estos activos y qué incertidumbre conserva la prueba?».