Category: Uncategorized

Introducción

PCI-DSS es una norma de seguridad publicada por las empresas de tarjetas de crédito (PCI es Payment Card Industry, y DSS significa Data Security Standard). Es un requisito obligatorio para cualquiera que procese tarjetas de crédito.

La versión 4.0.1 de PCI-DSS es un documento de casi 400 páginas, por lo que este artículo no lo sustituye. Pero ayudamos a traducir PCI-DSS a pasos prácticos de implementación en bases de datos Oracle y SQL Server para ayudarle a entender lo que necesita hacer. Sugerimos las mejores prácticas, metodologías y soluciones para ayudarle a cumplir la normativa.

El alcance de este artículo: Este artículo aborda las tareas realizadas por el equipo de DBA y no para administradores de red, desarrolladores de aplicaciones, etc. Supone que la base de datos está configurada y se utiliza de forma habitual, no es accesible desde Internet e, idealmente, se encuentra en una red interna segura. Tampoco abordamos los requisitos de la aplicación relacionados con la base de datos, como qué datos almacenar o cuánto tiempo conservarlos.

Las Buenas Prácticas del final resumen todo lo que hay que hacer.

Los Requisitos

A diferencia de la mayoría de las normativas de cumplimiento, PCI-DSS tiene requisitos precisos. Sin embargo, estos requisitos abarcan todo el entorno informático, incluidas redes, servidores, bases de datos, aplicaciones, etc.

Dado que no todos los requisitos se aplican a las bases de datos, este artículo sólo aborda los que son pertinentes para las bases de datos Oracle o SQL Server. Se trata de los requisitos 2, 3, 6, 7, 8, 10 y 11.

Requisito 2: Configuraciones seguras

El requisito 2 consiste en cambiar las configuraciones por defecto que puedan ayudar a un atacante a comprometer el sistema. Esto es especialmente importante para las contraseñas por defecto:

«Las personas malintencionadas, tanto externas como internas a una entidad, suelen utilizar contraseñas predeterminadas y otras configuraciones predeterminadas del proveedor para comprometer los sistemas. Estas contraseñas y configuraciones son bien conocidas y se determinan fácilmente a través de información pública.

La aplicación de configuraciones seguras a los componentes del sistema reduce los medios de que dispone un atacante para comprometer el sistema. Cambiar las contraseñas por defecto, eliminar el software, las funciones y las cuentas innecesarias, y desactivar o eliminar los servicios innecesarios ayudan a reducir la superficie potencial de ataque.»

Oracle y SQL Server son bastante seguros desde el principio. Además, obligan a establecer contraseñas de administrador personalizadas durante la instalación. La única mejora necesaria es activar el cifrado de la red. O más exactamente, hacer del cifrado un requisito del lado del servidor, ya que los clientes siempre pueden elegir cifrar las conexiones.

Es un buen punto de partida, pero tu base de datos no es nueva nada más sacarla de la caja. Eso significa que necesitarás asegurarte de que no has cambiado la configuración por defecto para que sea menos segura.

Por ejemplo, tras la instalación, las bases de datos Oracle contienen muchas cuentas en estado «EXPIRADO Y BLOQUEADO». Estos son usuarios como Scott/tiger, hr/hr, y más. Estas cuentas tienen una contraseña por defecto y pueden ser desbloqueadas, creando una vulnerabilidad de seguridad. Debes revisar la lista de cuentas, identificar las que no están en uso activo y desactivarlas. Puedes obtener la lista de cuentas y su estado usando un SQL como:

select username, account_status from dba_users;

Core Audit es una potente solución que le ayudará a identificar todas las cuentas configuradas en su base de datos y qué cuentas están activas.

SQL Server presenta retos diferentes debido a las numerosas funciones opcionales adicionales que se pueden instalar. Aunque no siempre es realista, debería intentar eliminar las funciones que no utilice. Además, si es posible, desactive xp_cmdshell.

Otro escollo en todas las bases de datos son las aplicaciones instaladas que requieren una cuenta. Debes asegurarte de que no utilizan una contraseña por defecto. Eso incluye aplicaciones de monitorización, software de ajuste, software empresarial y más.

Requisito 3: Almacenamiento de datos de titulares de tarjetas

El requisito 3 se refiere a la protección del almacenamiento de la información de los titulares de tarjetas:

«Los métodos de protección como el cifrado, el truncamiento, el enmascaramiento y el hashing son componentes críticos de la protección de datos de cuentas. Si un intruso elude otros controles de seguridad y consigue acceder a los datos cifrados de la cuenta, los datos son ilegibles sin las claves criptográficas adecuadas y son inutilizables para ese intruso… Por ejemplo, los métodos para minimizar el riesgo incluyen no almacenar los datos de la cuenta a menos que sea necesario, truncar los datos del titular de la tarjeta si no se necesita el PAN completo.»

El cifrado es una función incorporada tanto en SQL Server como en las bases de datos Oracle. Se denomina TDE (Cifrado Transparente de Datos) y debe configurarlo en cualquier base de datos que contenga datos de titulares de tarjetas.

Si tiene datos de titulares de tarjetas fuera de producción, debe utilizar el Enmascaramiento Estático de Datos para eliminarlos. El reto del enmascaramiento es que los datos enmascarados no sólo deben ocultar los datos de los titulares de tarjetas (como exige PCI-DSS), sino también ofrecer los resultados esperados. Por ejemplo, en el caso de los sistemas de control de calidad y desarrollo, las pruebas con los datos enmascarados deben ofrecer resultados similares a las pruebas con los datos originales. Conseguir un enmascaramiento eficaz no es trivial y recomendamos utilizar Core Masking de Blue Core Research.

Requisito 6: software seguro

El requisito 6 se refiere a la instalación de parches:

«Los actores con malas intenciones pueden utilizar las vulnerabilidades de seguridad para obtener acceso privilegiado a los sistemas. Muchas de estas vulnerabilidades se solucionan mediante parches de seguridad proporcionados por el proveedor, que deben ser instalados por las entidades que gestionan los sistemas. Todos los componentes del sistema deben tener todos los parches de software apropiados para protegerse contra la explotación y el compromiso de los datos de las cuentas por parte de individuos malintencionados y software malicioso.»

Instalar parches de bases de datos suele ser todo un reto. Esto se debe a que no siempre son compatibles con el software. También requieren pruebas en no producción y tiempo de inactividad en producción para instalarlos.

La buena noticia es que, aunque Oracle publica innumerables parches, este requisito sólo se refiere a los parches de seguridad. SQL Server tiene más parches relacionados con la seguridad, que deben instalarse.

Además, recuerde que también debe parchear todo el software utilizado en la base de datos, incluida la administración, el ajuste, la supervisión y todas las demás aplicaciones y herramientas.

Requisito 7: Restringir el acceso a los datos del titular de la tarjeta

El requisito 7 trata sobre la minimización de privilegios:

«Personas no autorizadas pueden acceder a datos o sistemas críticos debido a la ineficacia de las normas y definiciones de control de acceso. Para garantizar que solo el personal autorizado pueda acceder a los datos críticos, deben existir sistemas y procesos que limiten el acceso en función de la necesidad de conocer y de acuerdo con las responsabilidades del puesto.»

Se trata de un reto similar tanto en Oracle como en SQL Server. Debes reducir los permisos y privilegios en la medida de lo posible. Preste especial atención a los usuarios con el rol de DBA, privilegios sensibles (como ALTER USER o los privilegios «ANY» en Oracle) y permisos relacionados con tablas y columnas con datos de titulares de tarjetas.

El uso de Core Audit Level 1 puede ayudar a identificar estos tipos de privilegios y permisos para ayudarle a cumplir la normativa.

Requisito 8: Cuentas individuales

El requisito 8 consiste en tener cuentas individuales (no cuentas compartidas):

«Dos principios fundamentales de la identificación y autenticación de usuarios son 1) establecer la identidad de un individuo o proceso en un sistema informático, y 2) probar o verificar que el usuario asociado a la identidad es quien el usuario dice ser.

La identificación de un individuo o proceso … se lleva a cabo asociando una identidad con … un identificador … (también denominado «cuentas») … asignando una identificación única … para distinguir a un usuario o proceso de otro. … garantiza que se rindan cuentas de las acciones realizadas por esa identidad. Cuando existe tal responsabilidad, las acciones realizadas pueden ser rastreadas hasta usuarios y procesos conocidos y autorizados.

El elemento utilizado … para verificar la identidad se conoce como factor de autenticación. Los factores de autenticación son 1) … una contraseña …, 2) … un dispositivo token o tarjeta inteligente, o 3) … un elemento biométrico».

Las bases de datos suelen tener cuentas individuales. Las excepciones son algunas cuentas de administración (SYS y SYSTEM en Oracle y, posiblemente, SA en SQL Server) y la cuenta de aplicación. Debe asegurarse de que así sea.

Este requisito también incluye instrucciones sobre políticas de contraseñas, como contraseñas seguras (12 caracteres con números y letras), no reutilización de contraseñas, bloqueo de cuentas, etc.

Requisito 10: Registrar y supervisar todos los accesos

El requisito 10 se refiere a la auditoría de actividades:

«Los mecanismos de registro y la capacidad de rastrear las actividades de los usuarios son fundamentales para prevenir, detectar o minimizar el impacto de un compromiso de datos. La presencia de registros… permite un seguimiento, alerta y análisis exhaustivos cuando algo va mal. Determinar la causa de un compromiso es difícil, si no imposible, sin registros de actividad del sistema».

La auditoría de bases de datos es un reto tanto en SQL Server como en Oracle. El problema es que el uso de las funciones integradas de auditoría de bases de datos genera una importante sobrecarga de rendimiento y no cumple algunos aspectos del requisito 10 (como la seguridad de los datos de registro).

Tenemos artículos completos que revisan las opciones de auditoría de Oracle y SQL Server. La conclusión es que recomendamos utilizar Core Audit, ya que puede capturar toda la actividad con una sobrecarga insignificante, asegurar el registro de auditoría, generar los informes y alertas necesarios, y mucho más.

En términos de qué auditar, probablemente necesitará auditar al menos toda la actividad del DBA y todos los accesos a tablas que contengan datos de titulares de tarjetas.

Requisito 11: Comprobar periódicamente la seguridad de los sistemas

El requisito 11 se refiere a la exploración de vulnerabilidades y las pruebas de penetración:

«Las vulnerabilidades son descubiertas continuamente por individuos malintencionados e investigadores, así como introducidas por nuevo software. Los componentes del sistema, los procesos y el software a medida y personalizado deben probarse con frecuencia para garantizar que los controles de seguridad siguen reflejando un entorno cambiante.»

Hay muchas soluciones que buscan vulnerabilidades y rara vez encuentran algo significativo en la mayoría de las bases de datos. La razón es que es poco probable penetrar en una base de datos moderna sin credenciales. Del mismo modo, es poco probable que un pentest interno o externo revele nada nuevo.

Sin embargo, es necesario seguir estos pasos, y tiene sentido hacerlo dada la naturaleza de la seguridad: siempre hay un agujero esperando a ser encontrado.

Buenas Prácticas

1. Alcance. El primer paso para cumplir la normativa PCI-DSS es reducir el alcance de las bases de datos, servidores y redes que contienen datos de titulares de tarjetas. Si una instancia de SQL Server contiene varias bases de datos y una de ellas contiene datos de titulares de tarjetas, toda la instancia está sujeta a PCI-DSS. La base de datos tampoco debe estar conectada directamente a Internet, lo ideal es que se encuentre en una red interna segura. Aislar los datos de los titulares de tarjetas en bases de datos, servidores y redes que contengan poco más reducirá significativamente el esfuerzo de cumplimiento.
2. Cuentas. Hay varios pasos para asegurar las cuentas, y deben rehacerse al menos cada seis meses.
   • Inventario de cuentas. Haga una lista de todas las cuentas de la base de datos, identifique a las personas o aplicaciones asociadas a esas cuentas y determine cuáles siguen activas. Recomendamos utilizar Core Audit.
   • Cuentas inactivas. Cierre o desactive todas las cuentas inactivas.
   • Cuentas individuales. Asegúrese de que todas las cuentas son cuentas individuales (excepto las cuentas administrativas integradas compartidas y las cuentas de aplicaciones).
   • Mínimos privilegios. Asegúrese de que todas las cuentas tienen los permisos mínimos necesarios para que las personas realicen sus tareas. En particular, debe haber restricciones de acceso significativas a los datos de los titulares de las tarjetas (lo ideal sería que sólo la aplicación y los DBA).
3. Contraseñas.
   • Contraseñas por defecto. Asegúrese de que ninguna de las cuentas tiene una contraseña por defecto. En caso de duda, cambie la contraseña.
   • Política de contraseñas. Contraseñas fuertes (12 caracteres con números y letras), no reutilizar contraseñas (al menos 4), bloqueo de cuentas (no más de 10 intentos y bloqueo durante al menos 30 minutos).
4. Cifrado. Activa el cifrado de red y el cifrado de disco (TDE – Transparent Data Encryption).
5. Enmascaramiento. Utilice la Máscara Estática de Datos para enmascarar los datos de los titulares de tarjetas fuera de producción. Recomendamos utilizar Core Masking. En general, debe asegurarse de que todas las copias de datos de titulares de tarjetas fuera de la base de datos de producción (como copias de seguridad, exportaciones, etc.) estén enmascaradas o cifradas.
6. Parches. Instale todos los parches de seguridad para la base de datos y todo el software asociado. Se trata de una actividad continua.
7. Auditoría. Audite los inicios de sesión fallidos, la actividad del DBA, el acceso a las tablas que contienen datos de titulares de tarjetas y los DCL (DDL relacionados con cuentas). Recomendamos utilizar Core Audit.
8. Escaneos de vulnerabilidad y Pentesting. Realice escaneos de vulnerabilidades internas y externas (hay soluciones que lo hacen), y realice pruebas de penetración (hay empresas externas certificadas que debe contratar para ello).

Resumen

PCI-DSS sigue prácticas de seguridad estándar, especialmente cuando se trata de bases de datos. Aunque siempre se puede hacer más, estos pasos son esenciales para mantener los datos seguros y deben seguirse en cualquier entorno que contenga datos sensibles.