Herramientas para cumplir y mantener la conformidad SOC 2

Cumplir las normas de los Controles de Sistemas y Organizaciones (SOC) 2 es algo más que un simple proceso aplicado una vez para superar una auditoría. Los cambios permanentes en los procedimientos son tediosos y requieren mucho tiempo, pero son necesarios para garantizar que la organización pueda superar una auditoría SOC 2. Es algo más que facilitar un rastro de papel a un contador público. Debe disponer de los controles y herramientas adecuados para mantener el cumplimiento de forma permanente o arriesgarse a infringir las normas de cumplimiento. Perder el cumplimiento de la norma SOC 2 no es una opción para la mayoría de las organizaciones, pero las herramientas adecuadas mantendrán el cumplimiento y ayudarán a facilitar el cumplimiento continuo en futuras auditorías.

Contenido

1. Breve descripción de SOC 2
2. Cumplimiento de las normas SLA
3. Métricas de seguimiento para determinar el cumplimiento
4. KPI que afectan a otras métricas
5. Herramientas para cumplir la normativa
6. Conclusión

Breve descripción de SOC 2

Para las organizaciones que están estudiando actualmente el cumplimiento de las normas SOC, puede resultar abrumadora la cantidad de información a tener en cuenta. Puede parecer que todo necesita una revisión. La mayoría de las organizaciones trabajan para conseguir la certificación SOC 2 o SOC 3 SOC 3. La principal diferencia entre la conformidad SOC 2 y SOC 3 es que los informes de auditoría SOC 3 se ponen a disposición del público. Los requisitos para ambos tipos son los mismos, pero los SOC 3 suelen distribuirse públicamente en el sitio web del proveedor. Por ejemplo, la plataforma en la nube de Google cumple la norma SOC 3 y los informes pueden leerse en su sitio web.

Las auditorías SOC 2 se centran en la capacidad de su organización para proteger los datos y en los controles utilizados para garantizar la disponibilidad y la integridad continuas de los datos de sus clientes. Los cinco principios fundamentales de una auditoría son:

• Privacidad: ¿Mantiene su organización la privacidad de los datos mediante controles de acceso, autenticación multifactor (MFA) y cifrado?
• Seguridad: ¿Bloquea el acceso de los atacantes a los datos mediante cortafuegos, detección de intrusiones y MFA?
• Disponibilidad: ¿Incluye su infraestructura supervisión del rendimiento, recuperación en caso de catástrofe y capacidad para gestionar incidentes?
• Integridad del proceso: ¿Incluyen su ciclo de vida de desarrollo de software (SDLC) y control de cambios la garantía de calidad y la supervisión del proceso?
• Confidencialidad: ¿Incluye el almacenamiento de datos encriptación, controles de acceso y cortafuegos para protegerlos de usuarios no autorizados?

Tenga en cuenta que la conformidad SOC 2 no es una certificación como otras normas de conformidad. Es una auditoría de sus procedimientos e infraestructura actuales para garantizar que cumple una norma de alto nivel de seguridad y disponibilidad de los datos. 

Cumplimiento de las normas SLA

A menudo, con las prisas por revisar y aumentar la infraestructura de ciberseguridad, se pasan por alto las normas de los acuerdos de nivel de servicio (SLA). Los SLA son las promesas que usted hace a sus clientes, y estas promesas son contractuales y deben cumplirse. Por ejemplo, si se da a los clientes un plazo de resolución de 5 días para un problema de nivel medio, debe resolverse en ese plazo o se incumplirá el objetivo del SLA.

En KernelCaresomos a la vez clientes y proveedores. Prestamos servicios a los clientes, pero nuestro personal informático interno debe dar soporte a los empleados internos y cumplir los SLA establecidos por nuestras propias normas y promesas hechas a los empleados internos. Al ser tanto un cliente como un proveedor, comprendemos la importancia de cumplir los SLA y también la importancia de establecer expectativas razonables.

Los SLA pueden negociarse, pero una vez firmado el contrato, es imperativo que las organizaciones se esfuercen por cumplir los requisitos de los SLA. Los requisitos y métricas de los SLA suelen controlarse en aplicaciones internas como los sistemas de tickets. Uno de estos requisitos de SLA es el tiempo de actividad y cubre el principio de auditoría SOC 2 para la disponibilidad.

Métricas de seguimiento para determinar el cumplimiento

Para las organizaciones que se esfuerzan por cumplir la normativa, uno de los primeros pasos es elaborar informes y recopilar métricas en forma de Indicadores Clave de Rendimiento (KPI). Los KPI se utilizan para medir varias métricas distintas en todos los sistemas informáticos. Los KPI pueden indicarle dónde destaca y dónde puede mejorar. También pueden indicarle dónde necesita centrarse en mejores estrategias y eliminar los cuellos de botella.

Un KPI común utilizado en el cumplimiento de SOC 2 es la medición del tiempo de actividad. El tiempo de actividad (o tiempo de actividad del sistema) es la cantidad de tiempo que un sistema está disponible a lo largo del año. El sistema puede ser un servidor, un equipo de red o un sistema de almacenamiento. Cualquier tiempo de inactividad va en contra de esta métrica, incluido el mantenimiento programado que desconecta el servicio y requiere un reinicio. 

Para lograr excelentes reseñas de disponibilidad de tiempo de actividad, los proveedores se esfuerzan por conseguir un número de nueves. Cuantos más nueves haya en el porcentaje de tiempo de actividad, mejor calidad de tiempo de actividad y disponibilidad podrá ofrecer un proveedor a sus clientes. Por ejemplo, una organización que puede prometer sólo 52,60 minutos de inactividad al año tiene un porcentaje de disponibilidad o tiempo de actividad del 99,99% o cuatro nueves. Cuanto menor sea el tiempo de inactividad, mayor será el porcentaje de tiempo de actividad. Todas las organizaciones se esfuerzan por alcanzar el 100%, pero la realidad es que surgen problemas que interrumpen inesperadamente un servicio, aunque sólo sea durante unos milisegundos, y la supervisión, las alertas y la respuesta del personal son fundamentales para solucionar los SLA.

El tiempo de actividad no es la única métrica utilizada en las revisiones de cumplimiento. Normalmente, las organizaciones tienen varios KPI que siguen para determinar la eficacia de los procedimientos actuales. Algunas otras métricas incluyen:

• El número de aplicaciones que resultaron ser vulnerables a los CVE (Common Vulnerability Exposures) separados por nivel de gravedad (por ejemplo, Alto, Medio, Bajo).
• Tiempo medio que se tarda en parchear los programas vulnerables, incluido el sistema operativo
• Disponibilidad por servicio
• Carga y latencia del host o de la red

Indicadores clave de rendimiento que afectan a otras métricas

En algunos casos, es posible que tenga KPI contradictorios que enturbien las aguas y dificulten la determinación de lo que está sucediendo. Un KPI común es la infame "brecha de vulnerabilidad", que es el tiempo que se tarda en parchear un sistema una vez que un análisis detecta que el software es vulnerable o está desactualizado. Esta brecha aumenta por cada hora que pasa y el sistema está sin parchear. 

Las organizaciones que retrasan la aplicación de parches podrían considerar que esta métrica es demasiado alta para el cumplimiento. Lo que suele ocurrir es que la aplicación de parches se programa para un día concreto cada mes (o posiblemente cada semana). El problema es que ahora las vulnerabilidades se conocen públicamente y algunas se anuncian con código de explotación. Al retrasar las actualizaciones del software, el servidor sigue siendo vulnerable y abierto a los exploits. En 2019, el 60% de las filtraciones de datos fueron causadas por vulnerabilidades para las que había un parche disponible. 

Una métrica KPI puede afectar a otra y echar por tierra varios objetivos. Por ejemplo, la brecha de vulnerabilidad y los parches que se aplican pueden afectar al tiempo de actividad si hay que reiniciar el servidor. Cada día se anuncian nuevos CVE y se despliegan parches, por lo que puede resultar difícil para las organizaciones mantenerse al día y evitar un reinicio, lo que a su vez genera un tiempo de inactividad que afecta a los SLA. Por ejemplo, si debe aplicar parches a un sistema en un plazo de 30 días y cada sesión de aplicación de parches programada requiere un reinicio, su porcentaje de tiempo de actividad disminuye.

Herramientas para cumplir la normativa

Una buena estrategia para cumplir la normativa y respetar los requisitos de los SLA es utilizar la automatización. La automatización puede detectar muchos problemas antes de que se conviertan en infracciones críticas o violaciones del cumplimiento. También puede utilizarse para remediar algunos problemas, como la aplicación de parches. Las herramientas de automatización de la gestión de parches se integran bien con muchas de las herramientas de exploración de vulnerabilidades del mercado, por lo que pueden utilizarse conjuntamente para mejorar la brecha de vulnerabilidad.

Cuando las vulnerabilidades se parchean manualmente, puede resultar abrumador para los administradores. Deben leer informes, determinar la versión de software adecuada, probar los parches y, a continuación, desplegarlos en producción. Para una organización con cientos de servidores, esto requeriría un equipo entero que gestionara los parches a tiempo completo. Este sistema supondría un despilfarro de recursos para la organización cuando existen herramientas de automatización. En lugar de aplicar los parches manualmente, las herramientas de automatización ahorran tiempo y recursos.

Estas son algunas de las herramientas que utiliza KernelCare para cumplir la norma SOC 2 y mejorar la seguridad en todos los servidores:

• Tenable Nessus: Nessus es uno de los escáneres de vulnerabilidades más populares del mercado. Escaneará su red y encontrará vulnerabilidades, incluyendo software sin parchear.
• Ivanti: Ivanti descubrirá activos y gestionará la automatización de parches. 
• KernelCare: Utilizamos nuestro propio producto para mantener parcheado el software, incluidas las bibliotecas de terceros y el kernel de Linux. Además de parchear automáticamente el software, KernelCare es una solución sin reinicio, lo que significa que los servidores no necesitan reiniciarse después de parchear. Este servicio mantiene nuestra métrica de tiempo de actividad lo más alta posible sin perder puntos porcentuales debido al tiempo de inactividad por reinicio.

Conclusión

Mantener los servidores actualizados con los últimos parches de vulnerabilidad es necesario para cumplir la normativa, pero también lo es mantener los SLA de tiempo de actividad. Este conflicto puede dificultar que las organizaciones encuentren las herramientas adecuadas y desarrollen procedimientos que cumplan todos los requisitos. Con la automatización, que incluye la aplicación de parches sin reinicio, las organizaciones pueden mantener un alto porcentaje de tiempo de actividad y, al mismo tiempo, aplicar parches a los sistemas vulnerables en un plazo de 30 días. El resultado es que estas herramientas le acercan mucho más al cumplimiento de la norma SOC 2 después de pasar por una auditoría.