Gestión de claves para el cifrado con Oracle TDE en Entornos PCI DSS (Parte 2)

Como comentábamos en la anterior entrada, las claves de Oracle TDE se dividen en la Oracle Master Key, las Table Key y la contraseña del Oracle Wallet. De éstas tres, solo la contraseña del Oracle Wallet es gestionada de forma manual (ya dijimos que el uso del auto login Wallet no permite cumplir con PCI DSS) y por tanto es la única clave que estaría bajo el requerimiento 3.6.6 de PCI DSS. Éste requerimiento establece la necesidad de que la gestión de dicha clave se realice bajo control dual y conocimiento compartido, pero esto no es nada fácil en la operativa diaria.

En esta entrada os dejamos unos scripts que permiten la introducción de dos componentes (que conforman la contraseña del Oracle Wallet), de forma que un custodio no vea el componente del otro, si es que las tareas se realizan mediante comandos en lugar de con el Enterprise Manager u Oracle Wallet Manager. La ventaja de usar los scripts es básicamente rapidez además de no requerir tener un entorno gráfico, mientras que la ventaja de usar Enterprise Manager u Oracle Wallet Manager es que no es necesario conocer los comandos específicos para cada acción, además de que la introducción de las claves ya aparece enmascarada por defecto.
  • Para la apertura del Wallet, de forma que no sea visible el passphrase, se puede emplear el siguiente script (open_wallet.sh y open_wallet.sql) para abrir el wallet:
open_wallet.sh
#!/bin/bash
get_pwd() {
echo “Introduce Primera Componente: “
stty -echo
read pwd1
stty echo
echo “Introduce Segunda Componente: “
stty -echo
read pwd2
stty echo
}
open_wallet() {
sqlplus /@keyholder @open_wallet.sql $pwd1$pwd2
}
get_pwd
open_wallet
open_wallet.sql
set termout off;
alter system set encryption wallet open identified by “&1”;
set termout on;
exit
  • Para el cambio de Wallet, de forma que no sea visible el nuevo passphrase, se puede emplear el siguiente script:
change_pwd_wallet.sh
#!/bin/bash
get_pwd() {
echo “Introduce Contraseña Antigua: “
stty -echo
read pwd0
stty echo
echo “Introduce Primera Componente Nueva: “
stty -echo
read pwd1
stty echo
echo “Introduce Segunda Componente Nueva: “
stty -echo
read pwd2
stty echo
}
change_pwdwallet() {
orapki wallet change_pwd -wallet <RUTAWALLET> -oldpwd $pwd0 -newpwd $pwd1$pwd2
}
get_pwd
change_pwdwallet
  • Se puede emplear el siguiente script (‘set_key.sh’) para crear un nuevo wallet (si no existe) y añadir la nueva clave maestra de cifrado TDE al wallet o efectuar el procedimiento de re-keying:
set_key.sh
#!/bin/bash
get_pwd() {
echo “Introduce Primera Componente: “
stty -echo
read pwd1
stty echo
echo “Introduce Segunda Componente: “
stty -echo
read pwd2
stty echo
}
set_key() {
sqlplus /@keyholder @set_key.sql $pwd1$pwd2
}
get_pwd
set_key
set_key.sql
set termout off;
alter system set encryption key identified by “&1”;
set termout on;
exit

Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría

Gestión de claves para el cifrado con Oracle TDE en Entornos PCI DSS (Parte 1)

A continuación hacemos un repaso sobre los requerimientos de gestión de claves de PCI DSS (Req 3.5.1, 3.5.2, 3.6, 3.6.1, 3.6.2, 3.6.3, 3.6.4, 3.6.5, 3.6.6 y 3.6.7) y cómo estos pueden cubrirse con una base de datos Oracle 11g mediante Transparent Data Encryption (TDE) usando Oracle Wallet y cifrando a nivel de columna:

Cifrado a nivel de columna con Oracle TDE (Transparent Data Encryption)

El cifrado de columna de TDE cifra de forma transparente los datos confidenciales escritos en las columnas de las tablas de aplicación. Esto se puede lograr mediante el marcado de columnas sensibles como ' encrypted ' en Enterprise Manager, o añadiendo la palabra clave " encrypt " en la declaración SQL DDL. Los tipos de datos existentes siguen siendo los mismos por lo que el cifrado es completamente transparente para las aplicaciones existentes. Cada tabla con una o más columnas cifradas tiene su propia clave de cifrado, las cuales se almacenan en el diccionario de datos, cifrado con la clave maestra.


Figura 1.

Cuando se escriben datos en una columna cifrada, los valores sensibles se cifran inmediatamente antes de escribirse en el disco. Cuando un usuario autorizado selecciona datos de la base de datos, los datos se descifran de forma automática y se presentan en texto claro. Al igual que con el cifrado de tablespace de TDE, el cifrado a nivel de columna protege contra el acceso directo a los medios por los usuarios privilegiados del sistema operativo como cintas y/o discos perdidos o extraviados.
Para aumentar el rendimiento cuando se procesan los datos cifrados, cada tabla tiene su propia clave de tabla que se utiliza para todas las columnas cifradas en esa tabla específica. Estas claves de tabla se descifran con la clave maestra antes de procesar los datos cifrados, y permanecen descifrados por la duración de la transacción.

Oracle Wallet

Para efectos de protección de la información almacenada en las bases de datos Oracle se emplea cifrado simétrico usando Transparent Data Encryption (TDE) de la suite Oracle Advanced Security. La operación de cifrado/descifrado  en Oracle depende de dos factores:
  • Claves de cifrado a nivel de columna (Table Keys), que son cifradas a su vez con la clave de cifrado maestra y almacenadas en la tabla de diccionario (dictionary table) en la base de datos.
  • Clave de cifrado maestra, almacenada en Oracle Wallet, cuya operativa es discutida en este documento.

Figura 2.

Consideraciones Seguridad en Oracle Wallet

Las siguientes consideraciones de seguridad deben ser tenidas en cuenta en el momento de implementar el Wallet:
  • Crear un Wallet independiente para TDE: por defecto, la base de datos asume el Wallet general (compartido con el resto de componentes de la base de datos). Es recomendable crear un wallet independiente para el proceso de TDE de datos de tarjetas de pago, de forma que el acceso a las claves de cifrado esté limitado y restringido al mínimo personal y que las actuaciones que se realicen sobre wallets usados para otros fines tengan impacto sobre la gestión de las claves de cifrado. Tener en cuenta que el definir una nueva ubicación implica modificar también el fichero sqlnet.ora bajo el parámetro ENCRYPTION_WALLET_LOCATION.
  • Definir una clave robusta para el Wallet: A pesar que el Wallet por sí mismo ya implementa una política de contraseñas (mínimo 8 caracteres, debe contener caracteres alfabéticos, números o caracteres especiales), es importante que no se escojan contraseñas basadas en diccionario ni de fácil adivinación, aumentando a 20 caracteres el passphrase y siguiendo las directivas de gestión de contraseñas establecida por la política de seguridad de cada organización. Hay que tener en cuenta que un atacante en posesión de los datos cifrados, con acceso al wallet y con conocimiento de la clave puede cifrar y descifrar datos sin restricción.
  • Hay que tener en cuenta que la contraseña del wallet es diferente a la master key del TDE; un generador pseudo-aleatorio genera la clave maestra, mientras que la contraseña del wallet es usada como clave para cifrar el wallet.
  • Almacenamiento del Wallet: El Wallet puede ser almacenado en diferentes ubicaciones
    • Como una estructura del registro de Windows (aplica únicamente a bases de datos instaladas sobre sistemas operativos de Microsoft)
    • Exportado a LDAP
    • Almacenado en el filesystem
Conforme con ello, la alternativa es almacenarlo en el filesystem, teniendo en cuenta que dicho fichero deberá contar con permisos de lectura/escritura del usuario Oracle (del sistema operativo):
$ chown oracle.oracle ewallet.p12
$ chmod 600 ewallet.p12
Debido al almacenamiento en el sistema operativo, se deben establecer controles de protección a ficheros sensibles, tales como:
Restricciones de acceso a nivel de filesystem (permisos en el fichero)
Monitoreo de integridad del fichero ewallet.p12
  • Auto Login Wallet: Cada vez que se apaga o reinicia la base de datos y se arranca, es necesaria la intervención humana para ingresar la contraseña para abrir el Wallet. Se puede crear un wallet que no requiere el ingreso de la contraseña (auto login wallet), que simplemente crea una copia ofuscada del wallet original en el sistema operativo (‘cwallet.sso’) y es protegida por permisos a nivel de ficheros, de tal forma que un usuario de sistema operativo puede accederla. Esta configuración no debe implementarse en entornos PCI DSS, al quedar desprotegida la master key contenida en el Wallet.
  • Backup y copias de seguridad: por lo general, dentro de los backups de la base de datos automáticos (empleando RMAN/OSB) se incluyen los datos cifrados y el fichero .p12 del wallet. Por consideraciones de seguridad, se DEBE excluir del backup de base de datos los ficheros de wallet (exclude name *.p12) y respaldarlos en un proceso independiente, según las buenas prácticas descritas en (http://www.oracle.com/technetwork/database/security/twp-transparent-data-encryption-bes-130696.pdf - pg 6) y http://www.oracle.com/technetwork/database/security/tde-faq-093689.html#A13022.
  • División de la clave del Wallet entre diferentes custodios: Con el fin de cumplir con el requerimiento 3.5.1 y 3.6.6 al realizar operaciones en claro con el passphrase del Oracle Wallet, es necesario dividir el conocimiento de la clave del Wallet entre diferentes custodios, ya que como se explicó anteriormente, el DBA (por lo general el usuario “Oracle”) tiene acceso al filesystem donde se almacena el Wallet y a los datos cifrados, de tal forma que con el sólo hecho de conocer la clave de apertura del wallet puede ver los datos en texto claro y se convertiría en un punto único de fallo de seguridad en toda la arquitectura. Esta contraseña  protege la Master Key almacenada en el Wallet, por lo que se considera una KEK (Key Encryption Key) o clave de cifrado de claves, y por ello será necesario establecer controles robustos para proteger este passphrase en el almacenamiento, custodia, transmisión, etc.
  • Emplear las consideraciones generales de protección y control de acceso a la información con base en el need-to-know (necesidad de conocer).
  • Tener en cuenta que los datos/claves de cifrado/descifrado permanecen en la base de datos de forma completa (contenedor de claves, claves de columnas, datos cifrados, ficheros de base de datos) por lo que si el sistema operativo o la base de datos es comprometida con privilegios administrativos la seguridad completa del sistema se puede ver vulnerada. Por ello, es indispensable bastionar el sistema operativo, base de datos como cualquier otra aplicación y/o servicio que esté instalado en el mismo servidor, tal y  como requiere PCI DSS en el requisito 2.2, así como llevar a cabo el resto de actividades periódicas que establece el estándar: Escaneos de vulnerabilidades/Test de Intrusión (Requisito 11), Monitorización de logs (Requisito 10), etc.

Almacenamiento y Custodia de las claves

Oracle Master Key
Ningún custodio tiene acceso a la Oracle Master Key en claro, dado que ésta reside en el Oracle Wallet. Por lo que la custodia de dicha clave, reside en aplicar los mecanismos de seguridad descritos anteriormente en “Consideraciones Seguridad Oracle Wallet”, así como realizando una copia de seguridad cada vez que dicho Wallet sufra modificaciones.
Respecto a la retención, no deberán eliminarse Master Keys del Oracle Wallet, para poder permitir los procesos de backup y recuperación, aunque en ningún momento deberán usarse dichas claves para el cifrado de datos una vez hayan sido cambiadas.

Oracle Table Key
Ningún custodio tiene acceso a las Oracle Table Key en claro, dado que éstas residen en la base de datos y su uso es automático por parte del TDE de Oracle.
Respecto a la retención de dichas claves, una vez se procede con el cambio, se vuelven a cifrar todos los datos con las nuevas claves, por lo que la única retención existente sería el remanente en las copias de seguridad y que en ningún caso serían vueltas a ser utilizadas para el cifrado de datos.

Password Oracle Wallet
Este punto dependerá de la implantación del requerimiento 3.6.6, en referencia al control dual y el conocimiento compartido, y de cómo se divida la contraseña del Oracle Wallet en componentes y cómo estos son almacenados.
Respecto a la retención de passwords de Oracle Wallet cambiados, una vez comprobado que la nueva contraseña funciona correctamente, no es necesario retener los antiguos valores de cada uno de los componentes.

Generación de claves de cifrado

Todas las claves de cifrado, deben generarse de forma que se garantice el uso de algoritmos seguros y aceptados por las buenas prácticas de la industria, así como una longitud de clave suficiente que permita considerar la clave de cifrado como fuerte o robusta (ver NIST Special Publication 800-57 (http://csrc.nist.gov/publications/)).
A continuación se describe cada uno de los pasos a llevar a cabo para la generación de claves:
Oracle Master Key
Con el siguiente comando se genera la clave maestra para Oracle TDE:
SQL> alter system set encryption key identified by "wallet_password";
No obstante, también puede realizarse mediante Oracle Enterprise Manager:


Figura 3.


Figura 4.

Oracle Table Key
El proceso de generación de las Oracle Table Keys es automático en el momento de configurar el TDE.

Oracle Wallet
Del mismo modo que para la Master Key, si el Wallet no existe, el siguiente comando crea el Wallet en la ubicación predeterminada:
SQL> alter system set encryption key identified by "wallet_password";
No obstante, también puede realizarse mediante Oracle Enterprise Manager:


Figura 5.


Figura 6.

Procedimiento de Cambio de Claves

Una vez superado el tiempo de vigencia de las claves de cifrado, o bien deba sustituirse una clave por sospechas de compromiso de la misma o por que la integridad de la misma se ha visto afectada, será necesario llevar a cabo los siguientes pasos para cambiar la clave de cifrado por una nueva:

Oracle Master Key.

El proceso de cambio de la Oracle Master Key nunca se realiza en texto claro. Adicionalmente, hay que tener claro que cambiar la password del wallet no implica que se regenere la master encryption key del TDE.

Changing the wallet password does not re-key the TDE master encryption key” documentado en http://www.oracle.com/technetwork/database/security/tde-faq-093689.html#A15033.
El cambio de la Oracle Master Key puede llevarse a cabo mediante:
  • Enterprise Manager enviando a ejecución el job de cambio de clave maestra:

    Figura 7.
  • La siguiente sentencia:
    • SQL> alter system set encryption key identified by "wallet_password";

Oracle Table Key

Por cada tabla que contenga columnas cifradas, deberá ejecutarse el siguiente comando:
SQL> ALTER TABLE TABLACIFRADA REKEY;

Password Oracle Wallet
Adicionalmente a los controles que se lleven a cabo para garantizar el control dual y conocimiento compartido que establece el requerimiento 3.6.6, dicha contraseña puede ser renovada como se muestra a continuación:
  • Mediante Oracle Wallet Manager:

    Figura 8.
  • Mediante Enterprise Manager:

    Figura 9.
  • Mediante el siguiente comando:
    • orapki wallet change_pwd -wallet <rutawallet> -oldpwd <oldpwd> -newpwd <newpwd>
      • Evidentemente el uso de este comando, puede suponer el almacenamiento de las contraseñas en logs o incluso en el historial del sistema operativo, por lo que será necesario tomar medidas que impidan que ocurra dicho almacenamiento. En la segunda parte de esta entrada, proporcionaremos algunos scripts que permiten solventar este problema.

Distribución de claves de cifrado

La distribución de claves debe llevarse a cabo únicamente por los custodios designados y nunca en texto claro.

Oracle Master Key
La Master Key contenida en el Oracle Wallet no es distribuida en ningún momento.

Oracle Table Key
Estas claves son internas de Oracle, por lo que en ningún momento son distribuidas.

Password Oracle Wallet
En este caso, la distribución de la clave estará basada en el número de componentes en los que esté dividida la password de Oracle Wallet y en los requerimientos de cambio de dicha contraseña.
En los casos en los que esta contraseña deba ser transmitida (en modo de componentes o completa) a personas distintas a los custodios, por ejemplo para su uso inmediato por incidencias graves o situaciones de emergencia, la recomendación es proceder a un nuevo cambio de la Password de Oracle Wallet tras solventar la situación, de forma que vuelva a recuperarse el control sobre dicha contraseña.

Sustitución de las claves

En relación a la sustitución no autorizada de las claves, el propio funcionamiento de Oracle TDE previene que exista una sustitución no autorizada. Un cambio de Wallet no permitiría levantar la base de datos y un cambio de master key no permitiría descrifrar las Table Key correspondientes.
Aun así, para estar alerta ante cualquier intento de modificación, se recomienda monitorizar la integridad de los ficheros de Oracle Wallet, de modo que se genere una alerta cada vez que dicho fichero cambie en alguno de sus atributos y/o contenido.

Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría

Controles Manuales en el Cumplimiento de PCI DSS

En ocasiones el cumplimiento del estándar PCI DSS se vuelve “imposible”, no por la complejidad del estándar, ni por la dificultad en la operativa diaria, ni siquiera por los costes, simplemente por las limitaciones técnicas que pueden presentar algunos componentes de sistema del Entorno PCI DSS. 

Aunque a estas alturas los fabricantes deberían tener en cuenta las buenas prácticas en seguridad, no son pocos los elementos que carecen de posibilidades de configuración básicas que impiden mantener un nivel de seguridad aceptable, no únicamente para el cumplimiento de PCI DSS. Como ejemplo, podemos encontrar switches, cabinas de almacenamiento, IDS/IPS, Firewalls, tarjetas ILO, etc.

Bastante común es que estas limitaciones técnicas estén relacionadas con el control de acceso, o mejor dicho, la política de contraseñas del estándar PCI DSS, aunque también existen tecnologías que a día de hoy no permiten modificar parámetros por defecto, cuentas de usuario genéricas, obtener la hora de un servidor central o incluso el reenvío de logs a un servidor central.

Todas estas limitaciones técnicas suponen un desafío para el cumplimiento de PCI DSS, y por ello se hace necesario el desarrollo de técnicas y/o procesos (en ocasiones de controles compensatorios debidamente validados por un QSA) que permitan suplir estas carencias técnicas por controles manuales, en ocasiones conjuntamente con otros mecanismos de monitorización y auditoría.

Algunos ejemplos simples de estos controles pueden ser los siguientes:
  • Generar alertas cuando se detecte el uso de usuarios genéricos (Requerimiento 8.5.8) o de emergencias mediante la correlación de eventos, forzando el cambio de la contraseña después de cada uso y estableciendo un procedimiento controlado para la custodia de dicha contraseña.
  • Usar generadores de contraseñas complejas (Requerimiento 8.5.11) cada vez que vaya a procederse a cambiar la contraseña en un componente que no fuerce la complejidad establecida por el estándar, por ejemplo con herramientas como KeePass o Password Boy. Además, se podría complementar mediante revisiones periódicas que mediante el uso de técnicas de password cracking permitan verificar que la contraseña cumple con la complejidad y longitud necesaria.
  • En aquellos componentes que no permiten bloquear intentos de acceso fallidos (Requerimiento 8.5.13), que podrían detener un ataque de fuerza bruta, se recomienda aumentar significativamente la longitud mínima de la contraseña y añadir complejidad extra a la contraseña. Además de crear políticas de correlación que permitan generar alertas en caso de detectar intentos de inicio de sesión cercanos en el tiempo o incluso monitorizar los propios eventos de sesión fallida (si es que la tecnología es capaz de registrar apropiadamente dichos eventos).
  • Registro de las últimas contraseñas usadas en una base de datos segura y cifrada, para asegurarse que no se repita ninguna de las últimas 4 contraseñas usadas (Requerimiento 8.5.12), dejando anotado la fecha de uso y cambio de cada una de las contraseñas. Complementando dicho registro con pruebas periódicas de password cracking para validar que las contraseñas del histórico no están en uso de nuevo.
Obviamente cada entorno es distinto y será necesario buscar qué controles son más adecuados. Pero no hay que olvidar que se tratan de controles manuales y su uso debe limitarse ya que suponen un riesgo y que deben ser eliminados tan pronto como puedan eliminarse las carencias técnicas existentes en cada uno de los componentes de sistema del entorno PCI DSS. El no aplicar controles de seguridad suficientes, únicamente porque la tecnología no lo permite, no es admisible desde el punto de vista de seguridad y por supuesto para el cumplimiento de PCI DSS.


Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría

Internet Security Auditors se convierte en la empresa española QSA y ASV con más cobertura geográfica

Internet Security Auditors fue la primera empresa española en superar los requerimientos de validación de los exigentes programas de homologación del Payment Card Industry Security Standards Council (PCI SSC) de Qualified Security Assessor (QSA), Approved Scanning Vendor (ASV) y Payment Application QSA (PA-QSA) entre los años 2007 y 2009. Actualmente es la empresa de referencia en las normas de la familia PCI (DSS, PA-DSS, PIN, etc.) y ha desarrollado cerca de un centenar de proyectos sobre estas normas en todo tipo de sectores. Tres de las cinco certificaciones listadas en el portal de VisaMerchantAgents.com son resultado de colaboraciones llevadas a cabo por Internet Security Auditors.

Dentro del proceso de expansión de la compañía en el asesoramiento de empresas en Lati-noamérica, Caribe y Estados Unidos, se ha ampliado la cobertura regional a LAC (Latino América y Caribe) convirtiéndonos en la empresa 100% española con mayor capacidad de ejecución de proyectos relacionados con las normas PCI DSS (en más de 60 países).

Si quiere contar con expertos para asesorarle en el cumplimiento de PCI DSS, para la cumplimentación de Cuestionarios de Cumplimiento (QSA) o reporte del cumplimiento a terceros, para colaborar en procesos de Adecuación, ofrecerle soporte para la integración y cumplimiento con proveedores de servicio y terceras empresas, realizar Análisis de Vulnerabilidades y su gestión (ASV) y, en general, superar y mantener con éxito el cumplimiento de PCI DSS sea cual sea la complejidad de sus procesos afectados por el cumplimiento y tamaño de su empresa, no dude en contactar con nosotros.