Mostrando entradas con la etiqueta Security. Mostrar todas las entradas
Mostrando entradas con la etiqueta Security. Mostrar todas las entradas

20 enero 2021

Oracle Database 12c R2 Nueva función: Cifrado de tablespaces en línea y automática


Transparent Data Encryption, en adelante TDE,  le permite cifrar datos confidenciales, como números de tarjetas de crédito o porcentaje de invalidez, dentro de la base de datos  Oracle 12C.



Oracle Database utiliza autenticación, autorización y mecanismos de auditoria para proteger los datos en la base de datos, pero no en los archivos de datos del sistema operativo donde se almacenan los datos. Para proteger estos archivos de datos, Oracle Database proporciona Transparent Data Encryption (TDE). TDE cifra los datos confidenciales almacenados en archivos de datos. Para evitar el descifrado no autorizado, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos, denominado almacén de claves.

El cifrado transparente de datos (TDE) permite cifrar datos confidenciales tales como números de tarjetas de crédito almacenados en tablas y espacios de tabla. Los datos cifrados se descifran de forma transparente para una aplicación o un usuario de base de datos que tenga acceso a los datos. TDE ayuda a proteger los datos almacenados en medios en caso de sustracción de los medios de almacenamiento o los archivos de datos. Oracle usa mecanismos de autenticación, autorización y auditoría para proteger los datos de la base de datos, pero no los archivos de datos del sistema operativo donde se almacenan datos. Para proteger estos archivos de datos, Oracle proporciona TDE. TDE cifra los datos confidenciales almacenados en los archivos de datos. Para evitar descifrados no autorizados, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos.

Estas son algunas de las ventajas del uso de TDE:

  • Como administrador de seguridad tendrá la tranquilidad de que los datos confidenciales estén protegidos en caso de sustracción de los medios de almacenamiento o de los archivos de datos.
  • La implementación de TDE ayuda a abordar los aspectos de cumplimiento reglamentario relacionados con la seguridad.
  • No es necesario crear desencadenadores ni vistas para descifrar los datos para una aplicación o usuario autorizados. Los datos de las tablas se descifran de forma transparente para la aplicación y el usuario de la base de datos.
  • No es necesario que las aplicaciones y usuarios de base de datos sepan que los datos a los que acceden están almacenados en modo cifrado. Los datos se descifran de forma transparente para las aplicaciones y usuarios de base de datos.
  • No hace falta modificar las aplicaciones para controlar los datos cifrados. La base de datos administra el cifrado y descifrado de datos.
  • Las operaciones de administración de claves están automatizadas. El usuario o la aplicación no necesitan administrar las claves de cifrado.

Oracle 12c

Para obtener más información sobre la configuración del cifrado de espacios de tablas de TDE, consulte la documentación de Oracle.

Configuración manual del TDE
El siguiente procedimiento muestra cómo configurar manualmente TDE.

  • Cree el directorio keystore.
        mkdir $ORACLE_HOME/admin/$ORACLE_SID/wallet

  • Modifique el archivo SQLNET.ORA si desea administrar la cartera de cifrado.
        La ubicación predeterminada de la cartera de cifrado es             $ORACLE_BASE/admin/<nombre_db_global>/wallet. Si desea permitir que Oracle administre una cartera en la ubicación predeterminada, no necesita establecer el parámetro ENCRYPTION_WALLET_LOCATION en el archivo sqlnet.ora.

Para Windows


ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)   (METHOD_DATA=
    (DIRECTORY=C:/oracle/admin/%ORACLE_SID%/wallet/)))

Para Linux


ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)   (METHOD_DATA=
    (DIRECTORY=/app/oracle/admin/$ORACLE_SID/wallet/)))

  • Compruebe el parámetro de inicialización COMPATIBLE para el número correcto de versión. Debería ser 12.x.
Nota:
Utilice SQL*Plus. No utilice Oracle SQL Developer.

ORA> sqlplus /nolog SQL> connect /as sysdba Connected. SQL> select instance_name,status,database_status from v$instance;
INSTANCE_NAME    STATUS       DATABASE_STATUS
---------------- ------------ -----------------
mcs1              OPEN         ACTIVE
SQL> show parameter compatible NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
compatible                           string      12.1.0.0.0
  • Cree el keystore.
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";


  • Abra el keystore basado en contraseña.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

  • Comprueba el estado 
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

  • Haga una copia de seguridad de un software keystore basado en contraseña.
ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'keystore_bkp' IDENTIFIED BY "mcs1$admin";
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
  • Cree la clave principal de cifrado.
Cree una clave principal para la CBD y todas las PDB.

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_all_bkp' CONTAINER=ALL;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
Exporte la clave principal.

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";
  • Si lo desea, cree la contraseña principal para el contenedor actual. Puede omitir este paso si ha completado el paso anterior.
Base de datos de contenedor (CDB):

ALTER SESSION SET CONTAINER = CDB$ROOT;
SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_cdb_backup' CONTAINER=CURRENT;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
--export master key
ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";
Base de datos conectable (PDB): bathypdb

ALTER SESSION SET CONTAINER = bathypdb;
SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_bathypdb_backup' CONTAINER=CURRENT;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
--export master key
ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_bathypdb_exp.bkp' IDENTIFIED BY "mcs1$admin";

  • Comprobar estado
Select * from v$encryption_wallet;
select * from v$encryption_keys;
select wrl_parameter,status,wallet_type from v$encryption_wallet;
select key_id,keystore_type, creator,creator_instance_name, creator_pdbname from v$encryption_keys;

  • Establezca el keystore local de inicio de sesión automático.
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
--the cwallet.sso file appears in the keystore location. The ewallet.p12 file is the password-based wallet. --Note:
--Do not remove the PKCS#12 wallet (ewallet.p12 file) after you create the auto login keystore (.sso file). 
--You must have the PKCS#12 wallet to regenerate or rekey the TDE master encryption key in the future. 
--By default, this file is located in the $ORACLE_HOME/admin/ORACLE_SID/wallet directory.

  • Abra el keystore de inicio de sesión automático.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN CONTAINER=ALL;
-- check the status
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
Sugerencia:
Para cerrarlo, puede usar la siguiente instrucción.

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

  • Se recomienda que verifique el estado de la configuración TDE utilizando las instrucciones SQL siguientes.
Select * from v$encryption_wallet;
select * from v$encryption_keys;
select wrl_parameter,status,wallet_type from v$encryption_wallet;
select key_id,keystore_type from v$encryption_keys;
select key_id from v$encryption_keys;
select keystore_type from v$encryption_keys;
select wrl_parameter from v$encryption_wallet;
select status from v$encryption_wallet;
select * from v$encrypted_tablespaces;
select tablespace_name, encrypted from dba_tablespaces;
select * from dba_encrypted_columns;

21 febrero 2018

Oracle E-Business Suite: registro y auditoría (seguimiento de acceso a la página)

La auditoria de inicio de sesión solo registra la actividad de formularios profesionales; no registra la actividad del usuario de Oracle Applications Framework (OAF). El seguimiento de acceso a la página es necesario para registrar la actividad OAF. Una vez habilitado, el nivel de registro debe establecerse, así como marcar las aplicaciones para que se registren y tiene una sobrecarga insignificante.

Para configurar el seguimiento de acceso a la página, use la siguiente navegación: System Administration -> Oracle Applications Manager -> Site Map > Monitoring > Applications Usage Reports > Page Access Tracking..

Una vez habilitado, el seguimiento de acceso a la página requiere la ejecución de dos programas simultáneos. La migración de datos de seguimiento de acceso de página del programa se debe ejecutar para mover los datos de las tablas intermedias a las tablas de informes. Esto generalmente se hace a diario. Para purgar los datos de forma periódica, ejecute el programa de datos de depuración de seguimiento de acceso de página.

Los niveles de registro son:

  • Información de la sesión
  • Información de sesión y cookies
  • Información de sesión, cookies y parámetros de URL
  • Información de sesión, cookies y todos los parámetros

Una vez configurados, los informes se pueden ejecutar para los siguientes tipos de actividad:

  • Sesión
  • Fecha
  • Formar
  • Usuario
  • Solicitud

¿Cómo saber si el seguimiento de página de acceso está activado?


  • Compruebe la opción de perfil del sistema JTF_PF_MASTER_ENABLED y si se establece en TRUE para supervisar el acceso web
  • Verifique la opción de perfil del sistema JTF_PF_LEVEL. Esto se establecerá para cada aplicación. Además, se puede establecer para Responsabilidades y usuarios:

JTF_PF_LEVEL
Descripción
22
Session info
118
Session Info and Cookies
254
Session Info, Cookies and URL Parameters
126
Session Info, Cookies and All Parameters

¿Qué tablas almacenan el registro del acceso a cada pagina de la E-Business Suite?

La siguiente tabla identificó las tablas utilizadas para almacenar los datos de seguimiento de acceso a la página. Recuerde que los programas concurrentes de Page Access Tracking Data Migration y Page Access Tracking Purge Data, respectivamente, insertan datos y eliminan datos de estas tablas.

Tablas de seguimiento de acceso a páginas

  • JTF.JTF_PF_SES_ACTIVITY
  • JTF.JTF_PF_ANON_ACTIVITY
  • JTF.JTF_PF_APP_SUMM
  • JTF.JTF_PF_HOST_SUMM
  • JTF.JTF_PF_PAGE_SUMM
  • JTF.JTF_PF_USER_SUMM

Pantallas de configuración de Page Access Tracking







04 diciembre 2017

¿Hay vida más allá de Oracle? Lista de verificación de compatibilidad GDPR


La GDPR, o Reglamento General de Privacidad de Datos (UE) 2016/679, entrará en vigor en mayo de 2018. Tiene el potencial de alterar significativamente la forma en que las empresas gestionan y almacenan datos. Con más de 200 páginas, la regulación consolida y reemplaza las numerosas leyes locales de protección de datos, como la Ley de Protección de Datos del Reino Unido de 1998, la Privacywet belganuestra LOPD o la Bundesdatenschutzgesetz (BDSG) alemana. Las principales diferencias radican en la severidad de las posibles multas y nuevos requisitos tales como notificación de incumplimiento, derecho de acceso, derecho a ser olvidado, etc.

El objetivo principal de GDPR es fortalecer la seguridad y la protección de la privacidad de las personas. Mientras que GDPR comparte muchos principios de sus predecesores, que consta de 11 capítulos, 99 artículos y 187 considerandos, no es de ninguna manera una adaptación menor.

¿Quién esta sujeto a la GPRD?

El GDPR impone obligaciones legales a todos los controladores y procesadores de datos. se llama controlador de datos como la entidad que determina los propósitos y los medios de procesamiento de los datos personales, el procesador de datos se define como la entidad que procesa los datos personales en nombre del controlador. La GDPR se aplica al procesamiento llevado a cabo por organizaciones dentro del La UE y las organizaciones fuera de la UE que procesan o controlan los datos relacionados con residentes o nacionales de la UE.

Se centra principalmente en datos individuales, que se define en dos categorías de "Datos personales" y "datos personales confidenciales". Los datos personales incluyen datos tales como direcciones de correo electrónico y físicas, así como cualquier información que pueda usarse como un identificador en línea, una dirección IP. Los datos personales confidenciales arrojan una mayor neto y cubre elementos de datos tales como datos de salud, biométricos o genéticos.

Si todavía no cuenta con las herramientas y controles de seguridad necesarios, su la organización tendrá que implementar varios controles de seguridad nuevos, políticas, y procedimientos para demostrar el cumplimiento de GDPR. Por seguridad y organizaciones conscientes de la privacidad, la nueva regulación no debería provocar demasiado mucha sobrecarga técnica Para aquellos que aún no han logrado el cumplimiento de las leyes de protección de datos que GDPR reemplaza, el impacto será mucho mayor.

La GDPR requiere que las organizaciones mantengan un plan para detectar una violación de datos, evaluar regularmente la efectividad de las prácticas de seguridad y documentar evidencia de cumplimiento. En lugar de una dirección técnica específica, la regulación pone la responsabilidad en las organizaciones para mantener las mejores prácticas para la seguridad de los datos.


Punto1: Implementar una herramienta de Información de Seguridad y Gestión de Eventos con gestión de registros capacidades que cumplen con los requisitos de cumplimiento.

El Artículo 30 del GDPR establece que cada controlador y, cuando corresponda, el representante del controlador deberá mantener un registro de actividades de procesamiento bajo su responsabilidad.

Un SIEM (Herramienta de Información de Seguridad y Gestión de Eventos) suele ser una herramienta de seguridad fundamental para muchas organizaciones. Al implementar un SIEM, las compañías pueden monitorear a todos los usuarios y actividad del sistema para identificar el comportamiento sospechoso o malicioso. Esto se logra centralizando registros de aplicaciones, sistemas y establecer una red y correlacionar los eventos para alertar dónde se detecta actividad indeseable.

A continuación, puede investigar la causa de la alarma y crear una vista de lo que ocurrió al determinar si un método de ataque en particular se utilizó, mirando los eventos relacionados, la dirección IP de origen y destino, y otros detalles. También debe tener en cuenta los datos almacenados o procesados ​​en entornos de nube. Si los datos personales están en la nube, están dentro del alcance de GDPR, y por lo tanto es beneficioso elegir un SIEM que pueda mantener un registro de actividad en su nube pública y privada infraestructura, así como en las instalaciones.

Preguntas a responder:
  • ¿Tiene una forma de centralizar, analizar y almacenar datos de registro de todos sus entornos?
  • ¿Está alertado en tiempo real sobre cualquier actividad sospechosa o anómala?
  • ¿Tiene una forma de almacenar de forma segura los datos de registro sin formato y para garantizar su integridad?

Solución con Oracle

La interfaz de Audit Vault Server proporciona resúmenes gráficos de alertas. Estos incluyen un resumen de la actividad de alerta y las principales fuentes por cantidad de alertas. Puedes mediante un clic en los gráficos de resumen, acceder a informes más detallados. Para informar, las alertas se pueden agrupar por 
  • Fuente. 
  • Categoría de evento.
  • Gravedad del evento. 
También puede especificar notificaciones para las alertas generadas, por ejemplo, enviar automáticamente un correo electrónico a un usuario, como un oficial de seguridad o una lista de distribución. Las alertas también se pueden reenviar a syslog para facilitar la integración con un SIEM.



Un ejemplo de solución SIEM de terceros es HP ArcSight Security Information Event Management, que es un sistema centralizado para registrar, analizar y administrar mensajes de diferentes fuentes. Audit Vault Server reenvía mensajes al sistema ArcSight SIEM desde los componentes Audit Vault Server y Database Firewall.

No es necesario instalar software adicional para admitir esta integración. Se configura a través de la consola de Audit Vault Server y una vez habilitada la configuración se aplica inmediatamente. No es necesario reiniciar el servidor de Audit Vault.

Integración Oracle Audit Vault - Remedy y ArcSight

Integrar Oracle Audit Vault y Remedy Ticket System


Oracle Audit Vault 12c incluye una interfaz estándar para los sistemas de ticketing de BMC Remedy. Puede configurar Oracle Audit Vault para conectarse a BMC Remedy Action Request (AR) System Server 7.x. Esta conexión permite a Oracle Audit Vault generar tickets de problemas en respuesta a las alertas de Audit Vault.

Solo se puede configurar un servidor Remedy para cada instalación de Oracle Audit Vault. Después de que se haya configurado la interfaz, un auditor de Audit Vault necesita crear plantillas para mapear y manejar los detalles de la alerta.

Integración HP ArcSight


El sistema de administración de eventos de información de ArcSight Security de HP (SIEM) es un sistema centralizado para registrar, analizar y administrar mensajes de diferentes fuentes. Oracle Audit Vault puede reenviar mensajes a ArcSight SIEM.

No se necesita ningún software adicional para integrarse con ArcSight. La integración se realiza a través de configuraciones en la consola de Audit Vault Server.

Los mensajes enviados a ArcSight SIEM Server son independientes de cualquier otro mensaje enviado desde Audit Vault (por ejemplo, feeds de Syslog).

Hay tres categorías de mensajes enviados:
  • Sistema: mensajes de syslog de los subcomponentes de Audit Vault Server
  • Info: Registro de cambios específicos de la información del componente de Firewall de base de datos de Oracle AVDF.
  • Debug: una categoría que solo debe usarse bajo la dirección de Oracle Support.
Si quieres más información mira este video.


Punto 2: crea un inventario de todos los activos críticos que almacenan o procesan datos confidenciales para permitir para controles más estrictos que se aplicarán.

El GDPR es expansivo y cubre todos los sistemas de TI, redes y dispositivos, incluidos los dispositivos móviles. Por lo tanto, es esencial que hace un inventario de todos los activos en su infraestructura y establece dónde se guardan los datos personales.

Es importante inventariar todos los activos y ubicaciones que procesan o almacenan datos personales, una tarea que parece simple en su superficie, pero a menudo es un área donde las organizaciones luchan. Esto es especialmente cierto en entornos de TI dinámicos, como la nube pública y en casos donde los empleados están usando BYOD o activos no aprobados por IT. Vale la pena señalar que su empresa podría ser expuestos a ataques y multas reglamentarias si los empleados procesan o almacenan datos personales en dispositivos no aprobados.

Sin prácticas sólidas de gobierno en su lugar, puede ser fácil perder el control de los activos. Por tanto, es importante para muestrear sus sistemas, redes y almacenes de datos para determinar si los datos personales están expuestos fuera de los flujos y entornos de datos definidos. Tenga en cuenta que este es un proceso. Los inventarios necesita actualizarse constantemente a medida que cambia su negocio y tecnología.

Preguntas a responder:
  • ¿Qué activos están conectados a mi entorno en un momento dado?
  • ¿Estos activos procesan o almacenan datos personales?
  • ¿Qué puertos y protocolos se usan al transmitir o acceder a información personal?

Solución con Oracle

Los sistemas DAM (Gestión de activos digitales) nos ayudan a controlar todo el ciclo de vida de las imágenes, documentos y ficheros multimedia. Nos ahorran inversión en TI ya que centralizan el repositorio de objetos facilitando el acceso mediante bancos, álbumes y vistas, logrando la eficiencia operativa de los usuarios en casi cualquier organización que emplee ficheros de imagen o audiovisuales como parte de sus procesos de negocio.

Oracle DIVAdirector es un sistema de administración de activos digitales que le brinda control total de los activos alojados en Oracle DIVArchive a través de una interfaz familiar, de modo que puede ubicar, acceder y administrar rápidamente los medios.


Mediante este producto podrás:
  • Visualizar mediante credenciales de inicio de sesión y etiquetar contenido para una variedad de propósitos.
  • Integrar con los servicios de edición y acabado
  • Habilitar restauración parcial basada en código de tiempo (Timestamp)


Punto 3: Emprender el escaneo de vulnerabilidades a identificar dónde existen debilidades que podrían ser explotado.

La verdad sea dicha descubrimos y lo más preocupante, los atacantes descubren nuevas vulnerabilidades en sistemas y aplicaciones surgen casi diario. Por lo tanto, es esencial que su organización se mantenga alerta. Estas vulnerabilidades pueden existir en:
  • El software (Java, PHP, Javascript y que decir de nuestro querido .NET)
  • Configuración del sistema (Base de datos, servidor de aplicaciones, servidor web)
  • En lógica de negocios. (BPM, SOA)
  • En lógica de procesos. 
Así es importante considerar todos los aspectos de las vulnerabilidades y dónde ellos pueden existir Sin embargo, simplemente encontrar una vulnerabilidad a menudo no es suficiente. Hay muchos factores que deben considerarse como tales como si los sistemas están en el alcance de GDPR y lo que el la crítica al negocio es si se han intentado intrusiones y cómo los atacantes explotan la vulnerabilidad en el salvaje.

La evaluación efectiva de la vulnerabilidad requiere el escaneo continuo y el monitoreo de los activos críticos sobre los cuales los datos personales reside o es procesado. Es igualmente importante monitorear los entornos de la nube además de los entornos locales.

Al descubrir una vulnerabilidad, nos tenemos que preguntar:
  • ¿Cuántos registros personales podrían estar expuestos?
  • ¿Se han intentado intrusiones o exploits en el activo vulnerable?
  • ¿Cómo es explotada la vulnerabilidad por los atacantes en la naturaleza?


Punto 4: Realice evaluaciones de riesgos y aplique modelos de amenazas relevantes para su negocio.


El artículo 35 del GDPR requiere que las organizaciones realicen una evaluación de impacto de la protección de datos (DPIA) o similar. Considerando que el artículo 32 de la regulación requiere que las organizaciones "implementen medidas técnicas y organizativas apropiadas para asegurar un nivel de seguridad apropiado para el riesgo ".

El uso de un marco de seguridad de la información puede ayudar proporcionando un punto de partida para que las organizaciones comprendan mejor los riesgos que enfrenta el negocio. Los marcos existentes como NIST, ISO / IEC 27001 o estándares similares pueden ayudar a las empresas en emprender y apoyar el proceso DPIA.

Si bien GDPR no especifica un marco para las evaluaciones de riesgo o el modelado de amenazas, una empresa el cumplimiento de cualquier norma bien establecida e internacionalmente reconocida demostrará el cumplimiento de los artículos 32 y 25 es mucho más probable en caso de incumplimiento.

Preguntas a responder:
  • En caso de una violación de datos, ¿puedo demostrar que se implementaron los controles de seguridad adecuados?
  • ¿Sé a qué amenazas se enfrenta mi organización y la probabilidad de que se materialicen?
  • ¿Estoy al tanto de qué sistemas y unidades de negocios son de alto riesgo?

Punto 5: Realice pruebas regularmente para asegurarse de que los controles de seguridad funcionan según lo previsto.

El artículo 32 de la GDPR cubre la seguridad del procesamiento de datos personales. Entre los ejemplos que proporciona, se solicita un proceso para regularmente probando, evaluando y evaluando la efectividad de las medidas técnicas y organizativas para asegurar seguridad del procesamiento.

Evaluar y evaluar la efectividad de los controles de seguridad no es una hazaña fácil. Por lo general, cuanto mayor es el entorno TI, cuanto más dispares sean las pilas de tecnología, y cuanto más complejo sea el entorno. Por lo tanto, más difícil es ganar garantía.

Existen tres amplias técnicas para validar la efectividad de los controles de seguridad:
  • Manual de cumplimiento. Esto implica auditorías, revisiones de aseguramiento, pruebas de penetración y actividades del Equipo Rojo (el término Equipo Rojo se usa tradicionalmente para identificar a grupos altamente calificados y organizados que actúan como rivales ficticios).
  • Productos de seguridad integrados y consolidados, de modo que es necesario administrar e informar menos productos puntuales.
  • El uso de tecnologías de aseguramiento automatizadas.

Con estos métodos, puede obtener una medida de seguridad de que sus sistemas
están asegurados según lo previsto. Sin embargo, vale la pena recordar que la seguridad no es un esfuerzo de una sola vez, sino un proceso continuo y repetible.

Preguntas a responder:
  • ¿Qué nivel de confianza tiene en sus herramientas de seguridad?
  • Si una herramienta o sistema falla, ¿se alertaría automáticamente?
  • ¿Se están utilizando todas las herramientas de seguridad como se ha definido?

Punto 6: Implemente controles de detección de amenazas para informarle de manera oportuna cuando ocurra una infracción.

La GDPR requiere que las organizaciones informen al organismo regulador dentro de las 72 horas de estar al tanto de la infracción. Para alto riesgo eventos, el controlador debe notificar a los interesados ​​sin demora indebida (Artículo 31). El tiempo de compromiso típico continúa midiéndose en minutos, mientras que el tiempo de descubrimiento permanece en semanas o meses, en tales circunstancias, es esencial tener capacidades integrales de detección de amenazas que puedan detectar problemas tan pronto como ocurren.

Las amenazas pueden materializarse internamente en la empresa (normalmente) o externamente. Pueden estar en las instalaciones (on premise) o en entornos de nube (on cloud). Por lo tanto, es importante poder recopilar y correlacionar eventos rápidamente; y complementa la información con inteligencia de amenazas confiable para estar al tanto de las amenazas emergentes.

No hay un solo lugar o herramienta que sea apto para todos los propósitos. A veces se descubre una amenaza en el punto final, el perímetro o analizando el tráfico interno. Por lo tanto, los controles deben colocarse en consecuencia en el ambiente para aumentar la probabilidad de detectar amenazas tan pronto como ocurran.

Preguntas a responder:
  • ¿Podrás identificar y responder a una violación tan pronto como ocurra?
  • ¿Conoce los tipos de ataques a los que su empresa está sometida?
  • ¿Conocen los empleados cómo informar una infracción?

Punto 7: Supervisar el comportamiento de la red y del usuario para identificar e investigar incidentes de seguridad rápidamente.

La GDPR se centra en garantizar que los datos de los ciudadanos se recopilen y utilicen de manera adecuada para los fines que se establecieron. Por lo tanto es importante enfocarse no solo en amenazas externas o malware, sino también para detectar si los usuarios están accediendo a los datos adecuadamente. 



El contexto es crítico cuando se evalúa el comportamiento del sistema y la red. Por ejemplo, una gran cantidad de tráfico de Skype en la red utilizada por su equipo interno de ventas es probablemente una parte normal de las operaciones. Sin embargo, si el servidor de la base de datos alberga su lista de clientes de repente muestra una explosión de tráfico de Skype, algo es probable que esté mal.



Hay muchos métodos que se pueden implementar para monitorear patrones de comportamiento. Un método es utilizar el análisis de NetFlow, que proporciona las tendencias de alto nivel relacionadas con qué protocolos se usan, qué hosts usan el protocolo y el ancho de banda uso. Cuando se utiliza en conjunto con un SIEM, puede generar alarmas y recibir alertas cuando su NetFlow va por encima o debajo de ciertos umbrales.


Preguntas a responder:
  • ¿Sabes cómo se ve el tráfico "normal" en tu red?
  • ¿Sería capaz de detectar si un usuario legítimo está extrayendo datos de clientes?
  • ¿Un aumento o caída en el tráfico elevará las alarmas?

Punto 8: Tener un plan de respuesta a incidentes documentado y practicado.

Para cumplir con las regulaciones de GDPR, las organizaciones deben tener un plan para detectar y responder a una potencial violación de datos para minimizar su impacto en los ciudadanos de la UE. En el caso de un ataque o intrusión, un proceso simplificado de respuesta a incidentes puede ayudarlo a responder de manera rápida y eficaz para limitar el alcance de la exposición.



Si tiene procesos y controles unificados de detección de amenazas para alertarlo sobre un incidente, su plan de respuesta a incidentes debe poder determinar de forma rápida y precisa el alcance del impacto. Debe investigar todos los eventos relacionados en el

contexto de otra actividad en su entorno de TI para establecer una línea de tiempo, y la fuente de ataque debe ser investigada para contener el incidente.



Una vez que haya contenido el incidente, debe evaluar si se produjo una posible infracción de los datos personales y decidir si se requieren informes según GDPR. Luego, debe priorizar y documentar todas las tácticas de respuesta y reparación. Asegúrese de verificar que las actividades de respuesta a incidentes hayan solucionado correctamente el problema. Tendrá que informar al regulador de todos los pasos dados y, cuando sea necesario, informar a los ciudadanos de la UE afectados.


Preguntas a responder:
  • ¿Están todas las partes relevantes informadas y conscientes de qué hacer en caso de un incidente?
  • ¿Se practica el plan de respuesta a incidentes para garantizar que funcione en escenarios del mundo real?
  • ¿La documentación está completa y actualizada?

Punto 9: Tener un plan de comunicación para notificar a las partes relevantes.

En caso de incumplimiento, su organización debe informar al organismo regulador dentro de las 72 horas de haber tenido conocimiento de la infracción. Para eventos de alto riesgo, el responsable del tratamiento debe notificar a los interesados sin demora (Artículo 31).



La notificación a la autoridad que supervisa la GDPR, en cada país, es requerida por lo menos para:

  • Descripción la naturaleza de la violación.
  • Proporcionar el nombre y los datos de contacto del responsable de protección de datos de la organización, normalmente el CSO.
  • Describir las posibles consecuencias de la violación.
  • Describir las medidas tomadas o propuestas a tomar por el controlador de datos para abordar la violación y mitigar sus efectos adversos.
Preguntas a responder:
  • ¿Puedo identificar si los sistemas en el alcance de GDPR se ven afectados en una violación?
  • ¿Tengo los detalles de contacto del organismo regulador que debo notificar?
  • Si es necesario, ¿tengo un mecanismo confiable para contactar a los clientes afectados?

Punto 10:  ¡Enhorabuena! Estas preparado para el desafío de la GDPR.





27 noviembre 2017

Mejoras de auditoría (DBMS_AUDIT_MGMT) en Oracle Database 12c

La introducción de políticas de auditoría y la pista de auditoría unificada son las dos novedades, que aparecen en esta entrega de nuestra base de datos favorita. Que simplifican la configuración de la auditoría de bases de datos en Oracle 12c.  La nueva funcionalidad de auditoría también se puede usar para crear políticas de auditoría de muy sencillas a muy complicadas, pero no creo que sea la forma en que la mayoría de la gente querrá abordarla,  Una vez que hayas aprendido a andar, puedes empezar a correr y complicar tus políticas de auditoria, eso sí, bajo tu responsabilidad.

Si quieres saber más en profundidad acerca de la auditoria unificada en Oracle 12c, te recomiendo que sigas lo artículos de Joel Perez, Aman Sharma, Karan Dodwal y Sebastián D'Alessandro, en la technetwork de Oracle:

  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte I
  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte II
  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte III

Creando Políticas de Auditoría

Al igual que la auditoría estándar anterior, que mencionamos en mi anterior artículo, la auditoría unificada se puede utilizar para crear reglas de auditoría extremadamente complejas. Como la documentación de Oracle para administrar las políticas de auditoría es muy buena, en lugar de tratar repetirla aquí, solo mostraré algunos ejemplos sencillos para despertar la curiosidad del lector.

Es mejor crear una política de auditoría que contenga todas las auditorías necesarias para una sesión, en lugar de usar varias políticas pequeñas. El uso de múltiples políticas genera una mayor sobrecarga de inicio de sesión, un mayor consumo de UGA y una funcionalidad de verificación de auditoría interna menos eficiente.


Una política de auditoría se compone de varias cláusulas distintas, algunas de las cuales son opcionales.

Los ejemplos de los usos se dan en las secciones a continuación, pero aquí hay un resumen rápido de ellos.


  • privilege_audit_clause: se usa para especificar una lista de privilegios del sistema para auditar.
  • action_audit_clause: define las acciones que necesitan ser auditadas. Estas pueden ser standard_actions, como DELETE, o específicas del objeto, como DELETE ON schema.table. También pueden ser componentes_actividades que se dirigen a funciones específicas como Data Pump o SQL * Loader.
  • role_audit_clause: especifica una lista de roles. Todos los privilegios del sistema otorgados a través de esos roles son auditados.
  • When ... Evaluate per: permite definir una condición de auditoría para determinar cuándo se realizará esta. La condición se puede evaluar para cada sentencia SQL, sesión en a base de datos o instancia de base de datos, según el nivel de granularidad que requiera la condición.
  • CONTAINER: determina si una política de auditoría es específica para un PDB individual (CURRENT) o común a todos los AP (ALL).
Esto puede sonar un poco confuso, pero si alguna vez ha utilizado la auditoría de bases de datos en versiones anteriores, rápidamente se verá bastante familiar. Lo más importante que debe recordar es que en lugar de emitir los comandos AUDIT / NOAUDIT directamente, usted crea una política de auditoría que contiene las piezas relevantes, luego la habilita y deshabilita usando los comandos AUDIT / NOAUDIT.

Algunos de los siguientes ejemplos requieren estos tres usuarios de prueba.


En algunos casos, el contenido de la pista de auditoría unificada se ha purgado entre las pruebas para mantener el resultado simple y específico para la funcionalidad que se prueba.

Auditoría de privilegios


Como su nombre lo indica, la auditoría de privilegios le permite auditar el uso de los privilegios del sistema. La vista SYSTEM_PRIVILEGE_MAP identifica los privilegios del sistema que se pueden auditar.





Si queremos auditar la creación de tablas y secuencias por parte del usuario de ARTOS, podríamos hacer algo como lo siguiente.














Muestra la configuración de la política.










Conéctese con el usuario de ARTOS y cree algunos objetos.









Verifique la pista de auditoría. Si está en modo de escritura diferida (delayed-write), es posible que necesite vaciar la pista de auditoría antes de poder ver los registros de auditoría.

Deshabilitar la política y eliminarla.







Componente de Auditoría de Acciones

En lugar de auditar acciones en objetos específicos, en su lugar puede auditar acciones relevantes para funcionalidades o utilidades específicas, tales como Oracle Label Security (OLS), Real Application Security, Database Vault, Data Pump o SQL * Loader. Hay dos ejemplos de auditoría de componente_acción vinculados a continuación.

  • Auditoría de Operaciones de Data Pump
  • Auditoría de las cargas de ruta directa de SQL * Loader


Administración Unificada de la Pista de Auditoría

La administración de la auditoría unificada puede parecer un poco complicada al principio, pero hay algunas cosas que se deben tener en cuenta.

  • La auditoría unificada funciona de manera predeterminada, por lo que no necesita hacer nada para comenzar.
  • La configuración predeterminada es correcta. Probablemente solo deba centrarse en sus políticas de auditoría específicas.
  • Configurar un proceso de archivado y depuración necesitará algo de reflexión, pero probablemente solo lo haga una vez en la vida de su base de datos, así que no se asuste por este aspecto de la auditoría.

En los artículos referenciados más arriba encontrareis información en profundidad acerca de esta materia. 

Seguridad de las pistas de auditoria

El mantenimiento del seguimiento de auditoría y las políticas de auditoría se limita a aquellos usuarios a los que se les haya otorgado el rol AUDIT_ADMIN.

La función AUDIT_VIEWER se puede otorgar a los usuarios que necesitan ver la información de auditoría, pero no administrar el seguimiento de auditoría o las políticas de auditoría.


Bajo la auditoría unificada, los usuarios ya no pueden crear políticas de auditoría contra sus propios objetos. Para la compatibilidad con versiones anteriores, esto aún es posible para la auditoría tradicional. Esta es posiblemente una razón para alejarse de la auditoría en modo mixto.


Actualizaciones en 12.2


Una de las principales críticas de la auditoría unificada en 12.1 fue el rendimiento. En 12.2, la pista de auditoría unificada ahora reside en una tabla convencional llamada AUDSYS.AUD_$_UNIFIED. Cuando actualiza una base de datos, puede optar por migrar la información de auditoría existente a esta tabla utilizando TRANSFER_UNIDED_RECORDS en el DBMS_AUDIT_MGMT, que debería proporcionar un mejor rendimiento.