👉 Esta actividad te ayuda a cumplir los siguientes requisitos:
TSC: Seguridad (Common Criteria): Principio 11 del Marco COSO y el criterio CC7.1.
¿Para qué me sirve esta actividad? 📚
Esta actividad te ayudará a implementar un procedimiento formal y cíclico para identificar, evaluar, remediar y monitorear las vulnerabilidades técnicas en tus sistemas. El objetivo de este procedimiento es reducir proactivamente la "superficie de ataque" de tu organización, identificar los riesgos asociados a las debilidades técnicas e implementar acciones de mitigación a tiempo, antes de que puedan ser explotadas por un atacante.
¿Qué tengo que hacer? 🚀
Para documentar un procedimiento robusto que cumpla con los criterios de SOC 2, te sugerimos considerar las siguientes actividades, que representan el ciclo de vida completo de la gestión de vulnerabilidades:
Identificación de vulnerabilidades
Esta es la fase de descubrimiento. El criterio CC7.1 requiere una combinación de evaluaciones. Tu procedimiento debe definir cómo identificas las vulnerabilidades, utilizando una variedad de métodos:
Escaneos de vulnerabilidades: Revisiones automatizadas y periódicas (por ejemplo, semanales o mensuales) de tus redes y aplicaciones en busca de debilidades conocidas (por ejemplo, software desactualizado, configuraciones inseguras).
Pruebas de penetración (Ethical Hacking): Evaluaciones manuales y profundas realizadas por expertos (al menos anualmente) que simulan un ataque real para encontrar vulnerabilidades complejas que los escáneres no detectan.
Inteligencia de amenazas: La suscripción a boletines de seguridad y fuentes de información que alertan sobre nuevas vulnerabilidades descubiertas en el software que utilizas.
Análisis y Clasificación
Una vez identificada una vulnerabilidad, debe ser analizada y clasificada para entender su riesgo real y priorizar su solución.
Acción: El procedimiento debe especificar que cada vulnerabilidad será clasificada según su severidad. Te recomendamos usar un estándar como el CVSS (Common Vulnerability Scoring System), que asigna una puntuación de 0 a 10 y una etiqueta (Crítica, Alta, Media, Baja). Esta clasificación objetiva es clave para la toma de decisiones.
Planificación de la remediación
Aquí se define el plan de acción. Para cada vulnerabilidad, especialmente las críticas y altas, se debe crear un plan que incluya:
La acción de remediación específica: (por ejemplo, aplicar un parche, cambiar una configuración, reescribir una parte del código).
El responsable asignado para ejecutar la acción.
Un plazo de remediación (SLA): Es una excelente práctica definir plazos máximos según la severidad. Por ejemplo: Crítica: 7-15 días, Alta: 30 días, Media: 90 días.
Remediación y pruebas de validación (Retest)
Esta fase incluye la ejecución de la acción planificada por parte del responsable. Una vez aplicada, es fundamental realizar un retest o un nuevo escaneo para verificar que la vulnerabilidad fue efectivamente solucionada. Un auditor de SOC 2 no solo querrá ver que planeaste la acción, sino la evidencia de que la solución funcionó.
Comunicación y registro
El procedimiento debe establecer que los resultados del ciclo completo (vulnerabilidades encontradas, planes de remediación y resultados del retest) deben ser comunicados al Comité de Seguridad. Además, toda la actividad debe quedar registrada en una herramienta similar, creando una base de conocimiento y un rastro de auditoría completo.
💡Los pasos a seguir para terminar la actividad dentro de la plataforma son los siguientes:
Una vez que nuestro equipo haya aprobado la actividad, debes subir el documento final en versión PDF (no editable).
Posteriormente, debes subir la evidencia de su aprobación.
Recomendamos que esta evidencia sea a través de una minuta de sesión de comité (en ese caso, debes subir el documento en PDF de la minuta), o con una captura de pantalla de la respuesta explícita de quién o quiénes lo aprobaron.
Esto debe realizarse por algún medio de comunicación interno de la empresa, como Slack, Teams o el correo electrónico organizacional.
Y por último, debes subir la evidencia de su comunicación.
Al igual que la aprobación, la comunicación del documento puede ser por cualquier medio formal interno de la empresa. Y para esto, debes subir una captura de pantalla donde se muestre que el documento fue comunicado a todos los colaboradores interesados.
Recomendaciones ✅
Define SLAs de remediación: Establecer plazos máximos para solucionar vulnerabilidades según su criticidad (por ejemplo, 15 días para las críticas) demuestra un proceso maduro y es muy valorado por los auditores.
Automatiza tus escaneos: Considera el uso de herramientas de escaneo automatizado que se integren en tu ciclo de desarrollo (DevSecOps) para detectar vulnerabilidades de forma temprana, antes de que lleguen a producción.
No olvides la evidencia del retest: La prueba de que la vulnerabilidad ya no existe después de la remediación es una de las evidencias más importantes que puedes presentar.
Prioriza sin piedad: Utiliza la clasificación de severidad (CVSS) y tus SLAs para enfocar siempre los esfuerzos de tu equipo en remediar primero las vulnerabilidades críticas y altas.
¡Califica este artículo 👇, esto nos ayudará a mejorar nuestro contenido para ti! Recuerda que también puedes contactarnos por nuestro chat de soporte y te brindaremos la atención que necesites.