En general, el tratamiento de los registros de auditoría en sistemas operativos de uso generalista, como pueden ser Windows o las distintas distribuciones de Linux,
proporcionan cierto nivel de flexibilidad en cuanto a las opciones de
auditoría. Habitualmente, es posible configurar estas opciones incluso
al nivel de operaciones sobre un fichero o sobre las acciones de un
usuario concreto. Normalmente, de esta manera se consigue cumplir con
los requerimientos exigidos por la norma PCI DSS respecto a la generación de registros de auditoría.
En el caso del sistema operativo Solaris el módulo de auditoría es distinto y, para cierto tipo de opciones, también menos flexible. Por ejemplo, no permite activar trazas específicas para las modificaciones realizadas sobre un fichero o directorio concreto. Este tipo de controles deberán recaer sobre otro tipo de software, como, por ejemplo, un sistema de monitorización de integridad de ficheros.
Sin embargo, en lo que respecta a otro tipo de acciones (como pueden ser los intentos de acceso a los sistemas o las acciones realizadas por usuarios privilegiados) cuya auditoría es obligatoria de cara a la norma, Solaris permite activar filtros en relación con el tipo de actividad a monitorizar y las acciones de usuarios concretos. Estos filtros podrán ser activados según clases predefinidas de Solaris mediante el uso de flags.
En el caso de las acciones a auditar de forma general en el sistema y realizadas por cualquier usuario, el fichero a editar es /etc/security/audit_control, según el formato mostrado en la siguiente imagen.
Para establecer criterios específicos para usuarios concretos, como pueden ser las acciones realizadas por usuarios privilegiados tal y como específica el punto 10.2.2, el fichero a editar es /etc/security/audit_user, con el formato de la imagen que se muestra a continuación:
Hay que aclarar que estos parámetros especificados sobre ciertos
usuarios sobrescriben a los especificados en el fichero general
audit_control para dichos usuarios.
Los flags con su correspondencia sobre las acciones que monitorizan están definidos en el fichero /etc/security/audit_class. En función del sistema y de las acciones a monitorizar, habrá que depurar qué flags son requeridos en nuestro módulo de auditoría, teniendo en cuenta como mínimo los tipos de registros a generar exigidos por la norma PCI DSS:
/etc/security/bsmconv
Finalmente, el requisito 10.5.3 requiere el envío de los registros de auditoría a un servidor centralizado. El propósito de este envío es realizar una copia de seguridad de dichos registros, pero, adicionalmente, se debe poder utilizar esta información para la correlación de eventos y generación de alertas ante la aparición de incidentes de seguridad. Solaris, por defecto, genera los registros de auditoría en un fichero binario que debe consultarse mediante el comando praudit y cuyo formato normalmente no será entendido por un correlador de eventos. Por este motivo, Solaris proporciona la opción de redirigir los registros de auditoría por syslog. Para habilitarlo hay que añadir en el fichero /etc/security/audit_control los parámetros que se muestran en la imagen, especificando los flags de las acciones cuyos registros de auditoría se desea redirigir:
Para completar el proceso habrá que crear una línea en el fichero /etc/syslog.conf (en el caso de que ser quiera tener los registros de auditoría en local):
audit.notice /var/adm/auditlog
Y por último, reenviar esta información al servidor central añadiendo en este mismo fichero:
audit.notice @central_server
Para finalizar, el único punto donde puede resultar más difícil conseguir el cumplimiento con PCI DSS es en la depuración de los flags,
que establecen qué acciones registrarán los módulos de auditoría. Se
requiere un trabajo de conocimiento del sistema y de depuración de
dichos flags para obtener únicamente la información deseada,
puesto que el exceso de creación de registros de auditoría podría
convertir la información obtenida en inmanejable y, por lo tanto,
inútil.
Autor: Javier Lorrio - CISSP, CCSA, CCSE, CISA, PCIP
Departamento de Consultoría
En el caso del sistema operativo Solaris el módulo de auditoría es distinto y, para cierto tipo de opciones, también menos flexible. Por ejemplo, no permite activar trazas específicas para las modificaciones realizadas sobre un fichero o directorio concreto. Este tipo de controles deberán recaer sobre otro tipo de software, como, por ejemplo, un sistema de monitorización de integridad de ficheros.
Sin embargo, en lo que respecta a otro tipo de acciones (como pueden ser los intentos de acceso a los sistemas o las acciones realizadas por usuarios privilegiados) cuya auditoría es obligatoria de cara a la norma, Solaris permite activar filtros en relación con el tipo de actividad a monitorizar y las acciones de usuarios concretos. Estos filtros podrán ser activados según clases predefinidas de Solaris mediante el uso de flags.
En el caso de las acciones a auditar de forma general en el sistema y realizadas por cualquier usuario, el fichero a editar es /etc/security/audit_control, según el formato mostrado en la siguiente imagen.
Para establecer criterios específicos para usuarios concretos, como pueden ser las acciones realizadas por usuarios privilegiados tal y como específica el punto 10.2.2, el fichero a editar es /etc/security/audit_user, con el formato de la imagen que se muestra a continuación:
Los flags con su correspondencia sobre las acciones que monitorizan están definidos en el fichero /etc/security/audit_class. En función del sistema y de las acciones a monitorizar, habrá que depurar qué flags son requeridos en nuestro módulo de auditoría, teniendo en cuenta como mínimo los tipos de registros a generar exigidos por la norma PCI DSS:
- Todo acceso de personas a datos de titulares de tarjetas (Req. 10.2.1)
- Todas las acciones realizadas por personas con privilegios de raíz o administrativos (Req. 10.2.2)
- Acceso a todas las pistas de auditoría (Req. 10.2.3)
- Intentos de acceso lógico no válidos (Req. 10.2.4)
- Uso de mecanismos de identificación y autenticación (Req. 10.2 5)
- Inicialización de los registros de auditoría de la aplicación (Req. 10.2.6)
- Creación y eliminación de objetos en el nivel del sistema (Req. 10.2.7)
/etc/security/bsmconv
Finalmente, el requisito 10.5.3 requiere el envío de los registros de auditoría a un servidor centralizado. El propósito de este envío es realizar una copia de seguridad de dichos registros, pero, adicionalmente, se debe poder utilizar esta información para la correlación de eventos y generación de alertas ante la aparición de incidentes de seguridad. Solaris, por defecto, genera los registros de auditoría en un fichero binario que debe consultarse mediante el comando praudit y cuyo formato normalmente no será entendido por un correlador de eventos. Por este motivo, Solaris proporciona la opción de redirigir los registros de auditoría por syslog. Para habilitarlo hay que añadir en el fichero /etc/security/audit_control los parámetros que se muestran en la imagen, especificando los flags de las acciones cuyos registros de auditoría se desea redirigir:
Para completar el proceso habrá que crear una línea en el fichero /etc/syslog.conf (en el caso de que ser quiera tener los registros de auditoría en local):
audit.notice /var/adm/auditlog
Y por último, reenviar esta información al servidor central añadiendo en este mismo fichero:
audit.notice @central_server
Autor: Javier Lorrio - CISSP, CCSA, CCSE, CISA, PCIP
Departamento de Consultoría
