Requisitos de contraseña SOC 2 para el cumplimiento normativo

El control de contraseñas es fundamental para SOC 2, ya que una autenticación débil puede exponer datos de clientes, sistemas de producción, consolas de administración y herramientas internas. Sin embargo, SOC 2 no proporciona a las organizaciones una fórmula de contraseña fija, como sí lo hacen algunos estándares prescriptivos.

En cambio, SOC 2 evalúa si sus controles de acceso lógico están bien diseñados, se aplican de forma coherente y están respaldados por evidencia. La política de contraseñas, la autenticación multifactor (MFA), el bloqueo de cuentas, la configuración de inicio de sesión único (SSO), el aprovisionamiento y la revocación de accesos, y los controles de acceso privilegiado contribuyen a dicha evaluación.

Esta guía explica cómo definir los requisitos de contraseñas conformes a la norma SOC 2, qué pueden solicitar los auditores y cómo demostrar que sus controles de contraseñas funcionan correctamente en todos los sistemas incluidos en el alcance del estudio.

¿Qué dice la norma SOC 2 sobre los requisitos de contraseñas?

SOC 2 tiene cinco criterios de servicio de confianza Seguridad, privacidad, disponibilidad, confidencialidad e integridad del procesamiento. Las empresas tienen la flexibilidad de elegir los criterios que les correspondan según el tipo de servicio que ofrezcan.

Por ejemplo, si ofrece servicios financieros, la disponibilidad y la integridad del procesamiento son relevantes para usted, mientras que la confidencialidad y la privacidad son relevantes para las empresas del sector sanitario. 

No obstante, el principio de seguridad es fundamental y obligatorio independientemente del tipo de servicio que se ofrezca.

SOC 2 no exige una longitud de contraseña específica, una regla de complejidad ni un intervalo de rotación determinado. Los requisitos de contraseña suelen regirse por los Criterios Comunes para el acceso lógico, especialmente CC6.1, CC6.2 y CC6.3.

Estos criterios se centran en si la organización restringe el acceso lógico, emite y elimina credenciales correctamente y modifica el acceso en función de las funciones, las responsabilidades y los cambios del sistema.

CC6.1

La entidad implementa software, infraestructura y arquitecturas de seguridad de acceso lógico sobre los activos de información protegidos para protegerlos de incidentes de seguridad y cumplir con los objetivos de la entidad.

• Limite el acceso lógico a los activos de información, como software, datos, API, dispositivos de punto final y servidores, mediante sistemas de control de acceso y procesos de endurecimiento de la configuración.
• Identifique a los usuarios y sistemas autenticados, tanto remotos como locales, y proteja los activos de información mediante técnicas como la autenticación multifactor.
• Restringir el acceso a la información confidencial y personal únicamente al personal autorizado.

CC6.2

Antes de emitir credenciales de sistema y otorgar acceso al mismo, la entidad registra y autoriza a los nuevos usuarios internos y externos cuyo acceso es administrado por la entidad. Para estos usuarios, las credenciales de sistema se eliminan cuando el acceso deja de estar autorizado. Cree credenciales para proteger los activos de información de empleados, contratistas, proveedores, socios comerciales, sistemas y más.

• Elimine el acceso a las credenciales que ya no se utilizan o no son válidas. Por ejemplo, cambie las contraseñas de todos los sistemas a los que un empleado tuvo acceso después de su salida.

CC6.3

La entidad autoriza, modifica o revoca el acceso a datos, software, funciones y otros activos de información protegidos en función de las funciones, responsabilidades o el diseño y los cambios del sistema, teniendo en cuenta los conceptos de mínimo privilegio y segregación de funciones, para cumplir con los objetivos de la entidad.

• Implementar procesos para modificar el acceso a la información protegida en función de la autorización.
• Implementar procesos para revocar el acceso a la información protegida cuando ya no esté en uso.
• Implementar estructuras de control de acceso, como controles de acceso basados ​​en roles, para limitar privilegios y separar funciones incompatibles.

Sprinto te ayuda a configurar el control de acceso basado en roles para restringir el acceso a las redes según las funciones individuales dentro de la empresa. Al definir quién accede a qué, cuándo y cómo, puedes cumplir con los requisitos de auditoría SOC.

• Describe cómo proteger el inicio de sesión utilizando las herramientas de fortalecimiento del mecanismo de inicio de sesión de Sprinto.
• Configurar un control de acceso basado en tickets para gestionar las excepciones.
• Obtenga una visión detallada de las cuentas y el acceso en toda la organización, incluido el historial de estado.

Requisitos de contraseña SOC 2

SOC 2 no prescribe un estándar de contraseña único para todas las organizaciones. Su política debe definir una base de referencia sólida y demostrar que dicha base se aplica en todos los sistemas incluidos en el alcance de la auditoría.

Como mínimo, sus controles de contraseña y autenticación deben abarcar la longitud, la complejidad o las listas de bloqueo, los cambios de contraseña, la protección contra intentos de inicio de sesión fallidos, la autenticación multifactor (MFA) y la evidencia de su cumplimiento.

1. Longitud de la contraseña

SOC 2 no exige una longitud específica para la contraseña. Los auditores suelen buscar una política razonable, una aplicación coherente y pruebas de que la norma se aplica a los sistemas incluidos en su alcance.

Se considera un mínimo de 8 caracteres cuando las contraseñas se utilizan con autenticación multifactor (MFA). Para contraseñas de un solo factor, cuentas privilegiadas y sistemas que almacenan datos confidenciales, un mínimo más largo facilita la protección. La guía actual de identidad digital del NIST exige al menos 15 caracteres para las contraseñas utilizadas como factor de autenticación único y al menos 8 caracteres cuando se utilizan únicamente como parte de la MFA.

Tu política también debería permitir contraseñas más largas. Evita establecer límites de longitud máxima demasiado cortos que impidan a los usuarios crear credenciales seguras. Si tu proveedor de identidad lo permite, autoriza contraseñas de al menos 64 caracteres.

Para estar preparado para la auditoría, documente la longitud mínima y conserve capturas de pantalla, exportaciones de configuración o ajustes del sistema que demuestren que la regla se aplica en SSO, proveedores de identidad, VPN, aplicaciones en la nube, consolas de administración, dispositivos de punto final y otros sistemas incluidos en el ámbito de aplicación.

2. Complejidad de las contraseñas y listas de bloqueo

Las reglas de complejidad de contraseñas deberían hacer que las contraseñas sean más difíciles de adivinar sin empujar a los usuarios hacia patrones predecibles como Password1! or Password@123.

Las reglas de complejidad tradicionales exigen el uso de letras mayúsculas, minúsculas, números y símbolos. Si bien estas reglas aún son comunes, no deberían ser el único control. Las recomendaciones actuales sobre contraseñas dan mayor importancia a la longitud, las listas negras, la limitación de frecuencia, la autenticación multifactor (MFA) y el almacenamiento seguro.

Un enfoque más sólido alineado con SOC 2 combina los requisitos de contraseña con:

• Longitud mínima de la contraseña
• Listas de bloqueo para contraseñas comunes, comprometidas o fáciles de adivinar.
• No se permite la reutilización de contraseñas para sistemas empresariales.
• Autenticación multifactor para sistemas incluidos en el ámbito de aplicación y sistemas privilegiados.
• Limitación de la tasa de solicitudes o bloqueo de la cuenta tras repetidos intentos fallidos.
• Almacenamiento seguro de contraseñas mediante hash y salting para los sistemas que usted crea o administra.
• Cambios de contraseña cuando hay evidencia de compromiso

Si su organización aplica reglas de tipo de carácter, documéntelas claramente e indique dónde se aplican técnicamente. Si utiliza contraseñas, documente la justificación y muestre los controles compensatorios que reducen el riesgo de vulneración de credenciales.

3. Rotación de contraseñas

La rotación periódica de contraseñas ya no es la práctica recomendada por defecto para todas las cuentas. Los restablecimientos forzados cada 30, 60 o 90 días pueden llevar a los usuarios a crear variaciones predecibles de la misma contraseña.

Un enfoque más adecuado consiste en exigir cambios de contraseña cuando existan indicios de una vulneración de seguridad o un cambio significativo en el acceso. Algunos ejemplos incluyen la posible exposición de credenciales, el phishing, el intercambio de contraseñas, la rescisión de contratos laborales, los cambios en roles privilegiados, la baja de un proveedor o un incidente de seguridad que afecte a un sistema incluido en el alcance de la medida.

Para credenciales compartidas, de servicio, de emergencia o de administrador, defina reglas de rotación más estrictas. Estas cuentas conllevan un mayor riesgo y deben gestionarse por separado de las cuentas de usuario normales.

Para estar preparado para una auditoría, conserve pruebas de sus reglas de restablecimiento de contraseñas, eventos de restablecimiento, registros de revocación de acceso y cualquier excepción aprobada para cuentas privilegiadas o de servicio.

4. Protección contra inicio de sesión fallido

Los atacantes suelen probar las credenciales robadas o adivinadas mediante repetidos intentos de inicio de sesión. La protección contra intentos fallidos limita la cantidad de intentos permitidos antes de que el sistema ralentice, bloquee o solicite la autenticación del usuario.

Esto se puede implementar mediante el bloqueo de cuentas, la limitación de inicios de sesión, la autenticación adaptativa, CAPTCHA o desafíos de autenticación multifactor (MFA) basados ​​en riesgos. El objetivo es reducir el riesgo de ataques de fuerza bruta y de relleno de credenciales sin generar bloqueos innecesarios para los usuarios legítimos.

Documente el umbral de intentos fallidos de inicio de sesión, la duración del bloqueo o la regla de limitación de acceso, así como los sistemas donde se aplica el control. Para las cuentas privilegiadas, utilice un sistema de monitoreo y alertas más estricto.

5. Autenticación multifactor

La autenticación multifactor (MFA) reduce el riesgo de que una contraseña robada pueda utilizarse para acceder a los sistemas incluidos en el alcance de la certificación. Para SOC 2, la MFA es especialmente importante para el inicio de sesión único (SSO), las VPN, las consolas en la nube, los sistemas de producción, los repositorios de código, las herramientas de seguridad, los sistemas financieros y las cuentas privilegiadas.

Su política de autenticación multifactor (MFA) debe definir qué sistemas requieren MFA, qué factores están permitidos, cómo se aprueban las excepciones y cómo se supervisa la inscripción en la MFA.

Para accesos de alto riesgo, considere opciones resistentes al phishing, como claves de seguridad o autenticadores de plataforma, siempre que sea posible. Como mínimo, conserve pruebas de que la autenticación multifactor (MFA) está habilitada y supervisada en los sistemas incluidos en el alcance.

Extra: Aquí tienes una lista de verificación de cumplimiento de SOC 2.

¿Dónde deben aplicarse los controles de contraseñas SOC 2?

Una política de contraseñas solo es útil si se aplica a los sistemas incluidos en el alcance de su certificación SOC 2. Comience por identificar dónde se autentican los usuarios y dónde se puede acceder a los datos de los clientes o a los sistemas de producción.

Entre los sistemas comunes que se deben revisar se incluyen:

• Proveedores de identidad y herramientas de inicio de sesión único (SSO)
• VPN y herramientas de acceso remoto
• Plataformas en la nube como AWS, Azure o Google Cloud
• Consolas de administración de producción
• Repositorios de código y herramientas de CI/CD
• Bases de datos y almacenes de datos
• Dispositivos de punto final y herramientas MDM
• Herramientas de seguridad y plataformas de registro
• Aplicaciones de finanzas, recursos humanos y atención al cliente
• Cuentas de emergencia, compartidas, de servicio y de proveedores

No confíe únicamente en el proveedor de identidad. Si los usuarios pueden autenticarse directamente en una aplicación, consola de administración, base de datos o dispositivo local, es posible que ese sistema requiera su propia contraseña y comprobante de autenticación multifactor (MFA).

Consejos para asegurarte de cumplir con los requisitos de contraseña SOC 2

Cumplir con los requisitos de contraseñas SOC 2 implica combinar personas, procesos y tecnología. Ahora que conoce los requisitos, siga estas recomendaciones para cumplirlos:

Utilice un gestor de contraseñas para las credenciales empresariales.

Los gestores de contraseñas ayudan a los empleados a crear y almacenar contraseñas largas y únicas sin tener que reutilizar las credenciales en diferentes herramientas. Son especialmente útiles para sistemas que no admiten inicio de sesión único (SSO) o para credenciales compartidas aprobadas que requieren acceso controlado.

Para cumplir con la norma SOC 2, documente su política de gestión de contraseñas y muestre cómo se otorga, revisa y revoca el acceso. Si utiliza bóvedas compartidas, restrinja el acceso por rol y mantenga registros del acceso a las credenciales cuando estén disponibles.

Los auditores pueden solicitar pruebas de que los empleados están obligados a usar el gestor de contraseñas, de que el acceso al almacén de contraseñas está limitado y de que las credenciales se eliminan cuando los usuarios abandonan la empresa o cambian de función.

Capacitar a los empleados en seguridad de credenciales

La formación debe centrarse en las situaciones en las que los empleados cometen errores con sus credenciales: reutilizar contraseñas, aprobar solicitudes inesperadas de autenticación multifactor (MFA), compartir credenciales, almacenar contraseñas en notas o herramientas de chat e introducir credenciales en páginas de phishing.

Conserve los registros de capacitación como evidencia SOC 2. Los auditores pueden preguntar si los empleados completaron la capacitación sobre concientización en seguridad y si esta abarca la higiene de contraseñas, el phishing, la autenticación multifactor (MFA) y la notificación de incidentes.

El módulo de capacitación de Sprinto ayuda a cumplir con los requisitos de capacitación en cumplimiento. entrenamiento de cumplimiento Esta guía describe el proceso de seis pasos para crear un programa eficaz, desde la evaluación de riesgos hasta el monitoreo y la mejora continuos. Personalice el módulo según sus necesidades, añada módulos de capacitación adicionales, verifique el estado de finalización, marque las excepciones y recopile evidencias de la capacitación completada.

Conectar los controles de contraseña con el control de acceso.

Los controles de contraseñas deben funcionar con el principio de mínimo privilegio, el acceso basado en roles, las revisiones de acceso y la revocación oportuna de permisos. Una contraseña segura no sirve de nada si los usuarios conservan accesos que ya no necesitan.

Para SOC 2, mantenga evidencia de que el acceso se aprueba antes del aprovisionamiento, se modifica cuando cambian los roles y se elimina cuando los empleados, contratistas o proveedores se marchan. Esto es especialmente importante para las cuentas privilegiadas y los sistemas que almacenan datos de clientes.

Implementar el bloqueo de pantalla en los dispositivos finales.

El bloqueo de pantalla ayuda a reducir el riesgo de acceso no autorizado cuando un dispositivo se deja desatendido. Esto es especialmente importante para equipos remotos e híbridos que utilizan portátiles fuera de entornos de oficina controlados.

Defina el tiempo de espera por inactividad en la política y aplíquelo mediante MDM, administración de terminales o configuración del sistema operativo. Mantenga constancia de que el bloqueo de pantalla está habilitado en todos los dispositivos de los empleados incluidos en el alcance.

La herramienta de gestión de empleados de Sprinto analiza la configuración del sistema para detectar configuraciones no conformes, como la ausencia de un valor asignado para el bloqueo de pantalla o la falta de contraseña al iniciar el sistema. Automáticamente, alerta a los administradores del sistema para que notifiquen al usuario afectado.

Cambie las contraseñas predeterminadas antes de usarlas.

Las contraseñas predeterminadas de las nuevas herramientas, dispositivos, bases de datos, enrutadores, consolas de administración y electrodomésticos deben cambiarse antes de que el sistema se utilice en producción.

Para SOC 2, documente el proceso de incorporación de nuevos sistemas y conserve pruebas de que las credenciales predeterminadas se modificaron o deshabilitaron. Esto puede incluir listas de verificación de configuración, políticas de MDM, capturas de pantalla de la configuración o registros de incidencias.

La política de contraseñas no es la meta final: demuestre su cumplimiento.

Una política de contraseñas indica a los auditores qué espera la organización. Las pruebas demuestran si esas expectativas se cumplen.

Para SOC 2, recopile evidencia de los sistemas donde realmente se realiza la autenticación. Esto puede incluir:

• Configuración de contraseña del proveedor de identidad y de inicio de sesión único (SSO)
• Capturas de pantalla de la aplicación de la MFA o exportaciones de configuración
• Configuración de autenticación de VPN y aplicaciones en la nube
• Controles de cuentas privilegiadas y de emergencia
• Configuración de bloqueo o limitación de acceso por inicio de sesión fallido
• Política del gestor de contraseñas y registros de acceso
• Configuración de bloqueo de pantalla del punto final
• Acceda a los registros de revisión de cambios de rol y usuarios dados de baja.
• Tickets que muestran restablecimientos de contraseña, eliminaciones de cuenta o aprobaciones de excepciones.

Con piqueLos equipos pueden asignar los requisitos de control de acceso SOC 2 a los sistemas conectados, supervisar el estado de los controles, recopilar evidencia y realizar un seguimiento de las excepciones desde un único lugar. Esto ayuda a los equipos a demostrar que se aplican los controles de contraseña y autenticación, en lugar de depender únicamente de las políticas escritas.

Preguntas frecuentes