Referencia

Work
No. de ref.
Program
rea Riesgo Oracle DB Actividad de Control Descripcin del plan de prueba
Practice Aid
-BETA 9i y
10g

1 La ausencia de registros
de auditora en la base de
datos, aumenta el riesgo de no
detectar acciones no
autorizadas en el sistema, tales
como eliminacin y modificacin
de datos sensibles, o intentos
de acceso no autorizados.G1
Auditoria,
Logs y
monitoreo.
1 Existe un registro de auditora en la base de Verificar con el administrador de la base de datos y los dueos de las
datos el cual permite identificar actividades aplicaciones como se han definido las actividades de monitoreo sobre las
sospechosas o no autorizadas en el sistema. actividades realizadas directamente en la base de datos, considerar los
siguientes escenarios:
- Se utiliza el registro de eventos suministrado por la base de datos
ORACLE:
1) Revisar que se encuentre configurado el parmetro de "audit_trail" con
alguno de los siguientes valores:
DB or TRUE Los registros de auditoria son registrados en la tabla AUD$
en el schema SYS, con esta configuracin el DBA puede realizar cambios
a las bitcoras de auditora ya que se almacenan en una tabla dentro de la
base de datos.
OS - Los registros de auditoria son almacenados en un archivo del
sistema operativo, por lo que con una adecuada administracin de
accesos a estos archivos, el administrador de base de datos no podra
modificar las bitcoras de auditora.
Este valor se puede obtener ejecutando el siguiente SQL Statement:
SELECT * FROM V$PARAMETER WHERE NAME = AUDIT_TRAIL
2) Verificar que dentro de la tabla DBA_STMT_AUDIT_OPS se estn
auditando la utilizacin de los siguientes SQL statements:
INSERT TABLE (importante que este establecido para el DBA)
DELETE TABLE (importante que este establecido para el DBA)
UPDATE TABLE (importante que este establecido para el DBA)
DROP TABLE
CREATE TABLE
SELECT TABLE
3) Verificar que se haya establecido la auditora sobre la utilizacin de
comandos privilegiados en los objetos crticos de la base de datos (Ej.
ALTER, AUDIT, INSERT, DELETE, GRANT, and LOCK); esta informacin
es obtenida ejecutando el siguiente comando: SELECT * FROM
DBA_OBJ_AUDIT_OPTS. Antes de realizar esta prueba se deben
identificar los objetos crticos de la base de datos, como pueden ser las
tablas que son utilizadas por la aplicacin para el almacenamiento de
informacin financiera; tablas con las cuentas de usuarios y contraseas
de una aplicacin, etc.
4) Verificar que se audite la utilizacin de los comandos privilegiados
crticos de la base de datos dentro de la tabla DBA_PRIV_AUDIT_OPTS
(Ej. CREATE TABLE, SELECT ANY TABLE).
5) Verificar en la tabla DBA_AUDIT_SESSIONS que se encuentren
registrados los eventos de ingreso al sistema o los eventos fallidos de
ingreso al sistema.

- En caso de que se utilicen herramientas o triggers para realizar el registro

de eventos a la base de datos, se debe verificar:
1) El lugar en donde se encuentran almacenadas las bitcoras de
auditora; en el caso de que se realice con un trigger, difcilmente se puede
restringir el acceso al DBA ya que deben ser almacenadas en una tabla
dentro de la base de datos.
2) Que la utilizacin de los SQL statements se encuentre auditados
Auditoria,
Logs y
monitoreo.
2 Si los usuarios privilegiados,
como los DBA's que se
autentifican a la base de datos
directamente, puede acceder a
los registros de auditora o
cambiar la configuracin de
auditora sin supervisin se
puede eludir la auditora y hacer
cambios no autorizados sin que
sea posible la deteccin de los
responsables.
2 El acceso a las bitcoras de auditoria estn - Si se utiliza el registro de eventos suministrado por la base de datos
restringidos a los usuarios privilegiados ORACLE:
1) Revisar que se encuentre configurado el parmetro de "audit_trail" con
alguno de los siguientes valores:
DB or TRUE Los registros de auditoria son registrados en la tabla AUD$
en el schema SYS, con esta configuracin el DBA puede realizar cambios
a las bitcoras de auditora ya que se almacenan en una tabla dentro de la
base de datos.
OS - Los registros de auditoria son almacenados en un archivo del
sistema operativo, por lo que con una adecuada administracin de
accesos a estos archivos, el administrador de base de datos no podra
modificar las bitcoras de auditora.
Este valor se puede obtener ejecutando el siguiente SQL Statement:
SELECT * FROM V$PARAMETER WHERE NAME = AUDIT_TRAIL
- Si se utilizan herramientas o triggers para el registro de eventos
realizados en la base de datos:
1) Verificar con el administrador de la base de datos o el administrador de
la herramienta de monitoreo, en donde son almacenadas las bitcoras de
auditora; adicionalmente, verificar los mecanismos de control de acceso
que han sido establecidos para impedir que los usuarios finales y los
administradores de la base de datos puedan realizar modificaciones sobre
la informacin almacenada en las bitcoras de auditora.
 File System 3 Un usuario con acceso a lnea
y Administracin de Accesosde comandos podra eludir
algunas bases de datos y
ejecutar binarios de Oracle o
modificar archivos de
configuracin.
4 Acciones no autorizadas sobres 5
los datos se den como
cambiarlos( update), copiarlos ,
insertarlos o removerlos.
3 El acceso desde el sistema operativo a los Verificar que los permisos otorgados a los archivos crticos de las bases de
archivos de la base de datos se encuentran datos limitan que usuarios no autorizados puedan realizar modificaciones
correctamente restringido.
logs (*.log or *.rdo), archive log files (*.arc)y a password file (*.pwd or as
Las relaciones de confianza en la base de
datos se encuentran adecuadamente
configuradas y han sido autorizadas
correctamente.
sobre los mismos:
a) Archivos de configuracin de la base de datos (init<sid>.ora), archivos
de datos (usually ends with *.dbf), archivos de control (*.ctl or *.con), redo
specified by the DBA). Se debe investigar con el administrador de la base
de datos la ruta en donde han sido ubicados dichos archivos.
b) Ejecutables de Oracle. Se debe investigar con el administrador de la
base de datos la ruta en donde han sido ubicados dichos archivos,
regularmente se encuentran en el directorio ORACLE_HOME/bin.
c) Directorio en donde se encuentren los scripts utilizados para
administrar la base de datos. Se debe investigar con el administrador de la
base de datos si existen scripts para la administracin de la base de datos.
Los privilegios deben estar establecidos de tal forma que solo los
administradores de la base de datos puedan realizar cambios sobre dichos
archivos; el usuario utilizado por la base de datos a nivel sistema operativo
debe ser el owner del directorio y los archivos utilizados por la base de
datos y el dbagroup debe ser el nico grupo con acceso a dichos archivos
y directorios.
Confirmar con mediante la tabla SYS.DBA_DB_LINKS si existen
relaciones de confianza en la base de datos, en caso de existan relaciones
de confianza se deben ejecutar las siguientes actividades:
- Verificar con el administrador de la base de datos la razn de las
relaciones de confianza existentes en la base de datos.
- Indagar y verificar el user ID as como los roles y privilegios asignados
para realizar las relaciones de confianza. (Verificar los privilegios de
acuerdo al plan de prueba del control No. 8 de esta matriz)
- Verificar que las relaciones de confianza se hayan autorizado
adecuadamente.
- Verificar que se haya definido adecuadamente la responsabilidad del
resguardo de las contraseas utilizadas para las relaciones de confianza.
Administraci 5 Los administradores del sistema 7
n de operativo y los que administran
Usuarios la base de datos podran no
estar segregados, eludiendo la
auditora y controles ganando
privilegios para cambiar los
datos financieros.
6 Existe un mayor riesgo si
existen UID genricos ya que
podra provocar el intercambio
de identificadores de usuario.
Se cuenta con una adecuada segregacin
de funciones entre el personal que
administra el sistema operativo y la base de
datos.
8 Los identificadores de usuario debe ser
nicos y personalizados.
a) Verificar que la persona que administra la base de datos no comparta
las responsabilidades de administracin del sistema operativo.
b) Verificar que los usuarios no tienen acceso a mas de una capa de la
infraestructura tecnolgica que soporta los sistemas:
- Sistema operativo (Windows: lista de usuarios, UNIX: /etc/passwd
- Base de datos: Contenido de la tabla "SYS.DBA_USERS"
- Aplicacin : Solicitar un listado de los usuarios en la aplicacin.
c) Verificar que las cuentas de usuario "SYS.DBA_USERS" en la base de
datos que cuentan con role DBA "SYS.DBA_ROLES" son adecuados para
realizar las actividades de administracin de la base de datos.
d) Asegurar que el nmero de usuarios existentes en el grupo DBA en el
sistema operativo son apropiados. UNIX: Revisar los archivos
etc/password y etc/group y verificar los usuarios con este acceso ( DBA),
En Windows: Verificar cual es la cuenta de usuario utilizada por el
manejador de la base de datos y verificar los grupos a los que pertenece;
asimismo, se debe verificar que usuarios se encuentran incluidos dentro
del grupo de administracin de la base de datos)
Verificar las cuentas existentes en la base de datos mediante la tabla
(SYS.DBA_USERS) y validar que solamente existan las cuentas de
usuario utilizadas por la aplicacin y las cuentas de usuario
correspondientes a los usuarios finales de la aplicacin (en caso de que
requieran ser creadas en la base de datos), validar que no existan cuentas
de usuarios genricos; es decir que sea utilizadas para obtener acceso a
la base de datos sin un responsable de su uso.
7 Los passwords de los usuarios 10
por default no han sido
cambiadas incrementando la
probabilidad de se puedan
presentar accesos no
autorizados a la Base de datos.
Las contraseas de los usuarios por default Verificar que las contraseas de las cuentas de usuario por default en la
han sido cambiadas. base de datos han sido cambiadas:
a) Obtener el listado de cuentas de usuario existentes en la base de datos
con la contrasea establecida (SYS.DBA_USERS)
b) Obtener el listado de contraseas por default en bases de datos Oracle
c) Realizar una comparacin de las contraseas establecidas a los
usuarios contra las contraseas por default.
*Nota: algunos scripts de PwC no obtienen la contrasea completa, por lo
que la comparacin se deber realizar manualmente.
8 Manejar privilegios de usuarios 11
independientes a los roles
incrementa la complejidad de la
administracin e incrementa la
posibilidad de que los privilegios
asignados sean mayores a los
requeridos para el cumplimiento
de sus funciones.
Se han configurado los accesos de los
usuarios para maximizar la seguridad y
reducir el riesgo de accesos no autorizados SYS.DBA_SYS_PRIVS Esta tabla contiene los privilegios asignados a
a los datos crticos.
Solicitar al DBA que entregue el contenido de las siguientes tablas:
los roles
SYS.DBA_ROLES and SYS.DBA_USERS Con estas tablas se puede
identificar los roles asignados a los usuarios.
SYS.DBA_TAB_PRIVS En esta tabla se puede determinar los
privilegios asignados a las tablas.
Verificar que los privilegios asignados a los roles y a los usuarios en la
base de datos, no les permitan realizar cambios sobre la informacin
existente en la base de datos.
Administraci 9 Configuraciones inapropiadas 14 Se cuenta con una adecuada asignacin de a) Obtener la tabla SYS.DBA_PROFILES e identificar los perfiles
n de de los perfiles utilizados por los perfiles para la administracin de definidos en la base de datos, verificar que se hayan definido
Passwords usuarios con acceso a la base contraseas y recursos de los sistemas. adecuadamente los siguientes parmetros:
de datos podran llevar a CONNECT_TIME
accesos no autorizados. IDLE_TIME
SESSIONS_PER_USER
FAILED_LOGIN_ATTEMPTS
PASSWORD_GRACE_TIME
PASSWORD_LIFE_TIME
PASSWORD_LOCK_TIME
PASSWORD_REUSE_MAX
PASSWORD_REUSE_TIME
PASSWORD_VERIFY_FUNCTION

b) Revisar en el archivo init<sid>.ora de la BD. revisar que el parmetro

RESOURCE_LIMIT esta habilitado como TRUE.

c) Verificar que los perfiles de usuarios existentes en la base de datos se

encuentran definidos para ser utilizados por los usuarios.

*NOTA: En los casos en que los usuarios no se logean directamente en la

base de datos, puede ser que no sea requerida la configuracin de perfiles
en la base de datos.
10 Si los usuarios se autentican por 16
el Sistema Operativo los
controles de autenticacion
residen el en servidor del S.O.
Por lo tanto la autenticacin en
la Base de Datos solo depende
de la seguridad del S.O.
11 Asignar privilegios al rol PUBLIC 17
incrementa el riesgo de se
asignen privilegios no
autorizados
Los mecanismos de autenticacin de
usuarios a la base de datos son provedos
por el manejador de la base de datos; la
autenticacin por mecanismos del sistema
operativo se encuentra restringido.
No se han definido privilegios para el rol
PUBLIC.
Autenticacion de usuario:
Verificar que el parmetro REMOTE_OS_AUTHENT se encuentra
establecido en FALSE
Autenticacion de recursos:
Verificar que el parmetro OS_ROLES y asegurarse que esta configurado
en FALSE.
En caso que el parmetro se encuentre habilitado, verificar el prefijo de
autenticacin de los usuarios:
REMOTE_OS_AUTHENT=OPS$
Verificar que usuarios en la tabla "SYS.DBA_USERS" cuentan con este
prefijo, ya que son los usuarios que se autenticaran con los mecanismos
del sistema operativo.
Verificar en la lista de usuarios del sistema operativo la existencia de
dichos usuarios y verificar el motivo de su existencia con el administrador
de la base de datos.
Verificar que el role PUBLIC no cuente con ningn privilegio asignado en la
base de datos:
a) Solicitar al DBA que ejecute las siguientes sentencias SQL:
SELECT OWNER, TABLE_NAME, GRANTOR, PRIVILEGE
FROM SYS.DBA_TAB_PRIVS
WHERE GRANTEE = PUBLIC
AND GRANTOR <>SYS; AND GRANTOR <> SYSTEM;
SELECT GRANTED_ROLE
FROM SYS.DBA_ROLE_PRIVS
WHERE GRANTEE = PUBLIC;
b) Solicitar al DBA la explicacin acerca de cualquier privilegio PUBLIC
que haya sido asignado.