Ejemplo de Análisis de Riesgos

Introducción

Este post tiene como objetivo el explicar en detalle una metodología propia de análisis de riesgos. En el pasado he utilizado esta metodología con éxito en la realización de diversos análisis de riesgos de Seguridad de la Información. Aunque, obviamente, guarda similitudes y ha nacido a la luz de otras metodologías ampliamente utilizadas como Magerit o ISO31000, posee peculiaridades que posibilitan realizar análisis de riesgos rigurosos pero muy sencillos de comprender y ejecutar.

Empezemos explicando el escenario (ficticio) que utilizaremos como ejemplo para desarrollar el análisis de riesgos.

La empresa Mascultura es una libreria online. Se dedica exclusivamente a la venta de libros (físicos, no en formato digital) a través de su página web. No tiene stock de libros, si no que los adquiere directamente a un mayorista. Dado que su negocio se basa en la venta online, y por tanto en la información, ha decidido llevar a cabo un análisis de riesgos para tener claro qué riesgos tiene y qué puede hacer para disminuirlos.

Catálogo de Amenazas

Lo primero que vamos a hacer será elaborar el catálogo de amenazas a considerar. Para ello, lo que normalmente hago es partir de un catálogo amplio, como por ejemplo el que tiene Magerit y eliminar aquellos que no son relevantes en ese caso concreto. Además, suelo agrupar algunas amenazas similares para simplificar el proceso de analizar los riesgos. Hay que tener en cuenta que trabajar con un catálogo muy amplio, aunque permitirá un análisis más riguroso, también multiplicará los esfuerzos y el tiempo necesario para llevar a cabo dicho análisis. Mi recomendación es tratar de no sobrepasar las 10 amenazas en nuestro catálogo.

En el caso de Mascultura, para simplificar al máximo en análisis, estas son las amenazas que vamos a considerar:

• Desastres Naturales
• Errores de los usuarios
• Errores de los programadores
• Errores en la administración de los equipos
• Malware
• Ataques intencionados

Aunque agrupemos amenazas para reducir su número, es importante que todas las categórias de amenazas que realmente puedan afectar a la información del negocio estén recogidas en nuestro catálogo para que el análisis sea riguroso y no menospreciemos riesgos relevantes. Asimismo, para elaborar el catálogo se debería considerar en contexto en el que opera la organización, tanto interno como externo. Por ejemplo, según qué tipo de organización estemos analizando tendrá sentido o no hablar de fraude interno, robo de activos o desastres industriales como amenazas a considerar.

Siguiendo con nuestro ejemplo, ahora que tenemos nuestro catálogo de amenazas, vamos a darle un valor de probabilidad estándar para cada una de ellas. Este será el valor de probabilidad que consideraremos por defecto, aunque podrá verse modificado en cada activo en función de sus vulnerabilidades. Para evaluar la probabilidad (y el resto de valores evaluables) voy a utilizar una escala de 5 valores. En función del grado de detalle que queramos para nuestro análisis se podrían utilizar únicamente 3 valores, o irnos a un modelo de más valores (7, 10 o incluso más):

5- Extremadamente probable
4- Muy probable

3- Probable
2- Poco probable
1- Probabilidad prácticamente despreciable

Así, nuestro catálogo de amenazas quedará de la siguiente manera (entre paréntesis la dimensión o dimensiones a las que puede afectar la amenaza):

• Desastres Naturales (Disp): 1
• Errores de los usuarios (Conf, Int, Disp): 4
• Errores de los programadores (Conf, Int, Disp): 3
• Errores en la administración de los equipos (Conf, Int, Disp): 3
• Malware (Conf, Int, Disp): 5
• Ataques intencionados (Conf, Int, Disp): 4

Mapa de Procesos

Ahora que ya tenemos nuestro catálogo de amenazas definido, vamos a realizar el BIA (Business Impact Analysis). Para ello, si no disponemos ya de uno, necesitaremos el mapa de procesos de nuestra empresa.

Para simplificar el ejemplo, vamos a considerar que únicamente existen los siguientes procesos, aunque en cualquier empresa real existirían muchos más procesos transversales o de soporte. Asimismo vamos a identificar las aplicaciones que soportan cada proceso:

• Proceso de venta de libro a los clientes:
  • Aplicación web de venta de libros.
  • Mail corporativo para la atención al cliente/resolución de dudas.
  • Aplicación para la facturación al cliente. (se cobra únicamente con tarjeta de crédito)
• Proceso de compra de libros al mayorista:
  • Aplicación web de venta de libros (la aplicación envía un pedido directamente al mayorista utilizando el mail corporativo)
  • Mail corporativo
• Proceso de entrega del libro al cliente
  • Aplicación web de venta de libros (la aplicación envía un pedido a la empresa de mensajería indicando qué libro recoger en el mayorista y a qué dirección entregarlo).
  • Mail corporativo

BIA (Business Impact Analysis)

Procedamos ahora con nuestro Análisis de Impacto al Negocio. Para ello vamos a valorar el impacto que tendría un compromiso en la Confidencialidad, Integridad o Disponibilidad de la información asociada a cada uno de los procesos de negocio que acabamos de identificar. Esta valoración, además, considerará diferentes ámbitos en los que puede existir un impacto.

Algunos ejemplos de ámbitos posibles son:

• Económico
• Legislativo/regulatorio
• Operativo
• Ambiental
• Daño a las personas
• Daño a la imagen de la empresa o pérdida de confianza de sus clientes
• Etc..

En nuestro caso, como algunos ámbitos no son de aplicación (daño medioambienta, o daño a las personas), vamos a valorar únicamente los impactos en los siguientes ámbitos:

	Económico	Legislativo/ regulatorio
Muy Bajo	Menos de 500€	-
Bajo	Entre 500€ y 2500€	-
Medio	Entre 2500 y 7500€	Apercibimiento
Alto	Entre 7500 y 20000€	Multa o sanción
Muy Alto	Más de 20000€	Revocación de la licencia de comercialización.

La escala de valores que utilicemos deberá estar alineada con las cifras de negocio que maneje la organización que estamos analizando. Las cuantías establecidas en el ejemplo son considerando que se trata de una pequeña empresa para la que sufrir una pérdida de 20000€ sería una pérdida de gran impacto, mientras que para otras organizaciones, una pérdida de esta misma cuantía estará catalogada como un impacto muy bajo.

Analicemos por tanto el impacto para cada uno de los procesos de negocio:

Si analizamos la confidencialidad del proceso de venta a los clientes, podemos ver que un compromiso en la confidencialidad de la información del proceso tendrá un impacto económico muy alto, puesto que la aplicación trata con los datos personales de los clientes y las multas de LOPD en su rango más bajo pueden alcanzar los 40.000€. En lo que se refiere a impacto legislativo, estaríamos en un nivel Alto, puesto que se pueden dar multas o sanciones también de tipo LOPD.

Realizaremos un análisis similar para la Integridad y la Disponibilidad (en este caso valoraremos el impacto de que el proceso no funcione durante 1 hora, 1 día o 1 semana):

Proceso de venta a los clientes		Económico	Legislativo
Confidencialidad		Muy Alto (5)	Alto (4)
Integridad		Muy Alto (5)	Alto (4)
Disponibilidad	1 hora	Muy Bajo (1)	-
	1 día	Bajo (2)	-
	1 semana	Medio (3)	-

Finalmente, para cada una de las dimensiones nos quedamos con el impacto más alto de entre las categorías que estamos valorando. Nuestro BIA quedará de la siguiente guisa:

	Confidencialidad	Integridad	Disponibilidad
			1 hora	1 día	1 semana
Venta	5	5	1	2	3
Compra	1	5	0	0	1
Entrega	5	5	0	0	2

Nivel de Riesgo Tolerable

Una vez finalizado el BIA ya estamos en disposición de establecer cual es el nivel de riesgo tolerable para nuestra organización. Es decir, dónde vamos a establecer la linea que separará los riesgos aceptables de aquellos que requieran acciones urgentes para su resolución. Establece este umbral teniendo en cuenta que no desea aceptar riesgos que superen los 7.500€ o puedan suponerle multas o sanciones ni, por supuesto, la revocación de su licencia para vender libros online, es decir, que no se tolerarán riesgos con un valor de 4 o 5.

Inventario de activos y Mapa de Dependencias

Ahora que ya tenemos nuestro BIA finalizado y el umbral de riesgos definido, necesitamos disponer del inventario de activos y el mapa de dependencias antes de iniciar propiamente el análisis de riesgos.

Veamos nuestro inventario de activos (simplicado, ya que no vamos a considerar ubicaciones o personal):

Aplicaciones:

• Aplicación Venta de libros (APP_Venta)
• Mail corporativo (App_Mail)
• Aplicación de facturación (App_facturación)

Bases de datos:

• Base de datos de clientes (BD_clientes) (SQL Server)
• Base de datos con maestro de libros (BD_Maestro)(SQL Server)
• Base de datos histórico de operaciones (BD_Operaciones)(SQL Server)

Sistemas:

• Sistema A (Linux + Apache)
• Sistema B (Windows XP)
• Sistema C (Windows 2008 Server)

Las aplicaciones se ejecutan en el Sistema A, el Sistema B aloja el correo electrónico y el Sistema C tiene el SQL Server con las bases de datos identificadas.

Veamos ahora nuestro mapa de dependencias:

Proceso de VENTA -> App_venta -> Sistema A

                                    -> BD_clientes -> Sistema C

                                    -> BD_Maestro -> Sistema C

                                    -> App_Mail -> Sistema B

                                    -> App_facturación -> Sistema A

                                    -> BD_clientes -> Sistema C

Proceso de COMPRA -> App_venta -> Sistema A

                                        -> BD_Maestro -> Sistema C

                                        -> App_Mail -> Sistema B

Proceso de ENTREGA -> App_venta -> Sistema A

                                         -> BD_clientes -> Sistema C

                                         -> BD_Operaciones -> Sistema C

                                         -> App_Mail -> Sistema B

                                         -> App_facturación -> Sistema A

                                         -> BD_clientes -> Sistema C

Ahora vamos a hacer que los activos hereden la clasificación de impacto según este mapa de dependencias. El resultado de impactos que obtendremos será el siguiente:

	Confidencialidad	Integridad	Disponibilidad (1 día)
			1 hora	1 día	1 semana
Venta	5	5	1	2	3
Compra	1	5	0	0	1
Entrega	5	5	0	0	2
APP_Venta	5	5	1	2	3
APP_Mail	5	5	1	2	3
APP_Facturación	5	5	1	2	3
BD_Clientes	5	5	1	2	3
BD_Maestro	5	5	1	2	3
BD_Operaciones	5	5	0	0	2
Sistema A	5	5	1	2	3
Sistema B	5	5	1	2	3
Sistema C	5	5	1	2	3

El siguiente paso a realizar es coger cada uno de los activos de nuestro inventario (o tipología de activo si se quiere simplificar) y analizar si son o no vulnerables a cada una de las amenazas identificadas en nuestro catálogo:

	Aplicaciones	Bases de Datos	Sistemas
Desastres Naturales	No Vulnerable	No Vulnerable	Vulnerable
Errores usuarios	Vulnerable	No Vulnerable	No Vulnerable
Errores de los programadores	Vulnerable	No Vulnerable	No Vulnerable
Errores en la administración	No Vulnerable	Vulnerable	Vulnerable
Malware	No Vulnerable	No Vulnerable	Vulnerable
Ataques intencionados	Vulnerable	Vulnerable	Vulnerable

Vamos ahora a calcular el riesgo intrínseco que soportan los activos de nuestro inventario, es decir, el riesgo sin tener en cuenta los controles de seguridad que existen para disminuir el impacto o la probabilidad de los riesgos. Para no alargar en exceso este post, realizaremos el ejemplo sobre un único activo; el sistema A.

Para calcular el Riesgo usaremos la siguiente matriz en función del Impacto y la probabilidad. Esta matriz es una propuesta totalmente adaptable en función del tipo de negocio que se esté analizando, puesto que en determinados sectores, puede tener sentido dar un mayor peso al impacto que a la probabilidad con objeto de considerar los posibles 'cisnes negros'.

		Impacto
		5	4	3	2	1
Probabilidad	5	5	5	4	3	2
	4	5	4	4	3	2
	3	4	4	3	3	2
	2	3	3	3	2	1
	1	2	2	2	1	1

Veamos pues el riesgo inherente de nuestro 'Sistema A':

Sistema A – Riesgo inherente	Impacto	Probabilidad	Riesgo
Desastres Naturales	Disponibilidad: 2	1	1
Errores usuarios	No Vulnerable
Errores de los programadores	No Vulnerable
Errores en la administración	Confidencialidad: 5	3	4
	Integridad: 5
	Disponibilidad: 2
Malware	Confidencialidad: 5	5	5
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	4	5
	Integridad: 5
	Disponibilidad: 2

Por lo tanto, vemos que el riesgo inherente de nuestro Sistema A es muy Alto (5). Veamos ahora qué controles tiene implementados el sistema para calcular cual es su riesgo efectivo:

• Antivirus actualizado y con actualización diaria de firmas. (reduce considerablemente la probabilidad de la amenaza de malware).
• Alojado en red interna separado de la DMZ y de Internet mediante firewalls bien gestionados. (reduce la probabilidad de ataques intencionados).
• Se le realiza un análisis de vulnerabilidades anual, y aunque en el último mostraba vulnerabilidades, las más críticas ya están corregidas. (dado que es anual, se decide no bajar aún más la probabilidad de malware o ataques intencionados. Si el proceso fuera al menos trimestral con corrección de las vulnerabilidades en corto espacio de tiempo, se podría reducir aún más la probabilidad de estas amenazas).
• La organización dispone de un procedimiento de gestión de cambios sólido que reduce la probabilidad de errores de administración y también su impacto, puesto que siempre se cuenta con un procedimiento de 'marcha atrás'.

Por lo tanto, el riesgo efectivo de nuestro sistema será el siguiente:

Sistema A – Riesgo efectivo	Impacto	Probabilidad	Riesgo inherente	Riesgo Efectivo
Desastres Naturales	Disponibilidad: 2	1	1	1
Errores en la administración	Confidencialidad: 4	2	4	3
	Integridad: 4
	Disponibilidad: 2
Malware	Confidencialidad: 5	3	5	4
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	3	5	4

Plan de Tratamiento de Riesgos

Ahora que ya tenemos nuestro mapa de riesgos (inherentes y efectivos) para todos los activos o grupos de activos de nuestra organización, podemos proceder a elaborar el plan de tratamiento de riesgos. A tal fin, determinaremos acciones a realizar para aquellos riesgos que sobrepasen el umbral que hemos definido como tolerable en nuestra organización (4 en el caso de ejemplo).

Para cada uno de estos riesgos tendremos las siguientes alternativas:

• Evitarlo: Dejar de efectuar la actividad que origina el riesgo. En el caso de ejemplo, apagar el Sistema A, desconectarlo de la red y darlo de baja de nuestra organización.
• Asumirlo: Asumir que no se puede hacer nada para paliar este riesgo, y que por lo tanto la Organización prefiere mantenerlo. Esta estrategia puede ser válida cuando el activo está a punto de ser dado de baja o cuando las alternativas existentes para rebajar su nivel de riesgo son excesivamente costosas y podrían superar incluso el coste potencial de la materialización del riesgo.
• Transferirlo: En ocasiones, existen riesgos que pueden transferirse a terceras empresas mediante la contratación de un seguro o la externalización de determinados servicios.
• Mitigarlo: En la mayoría de los casos esta será la estrategia óptima. Consiste en establecer o mejorar los controles de seguridad del activo para reducir sus riesgos hasta niveles aceptables, bien por reducir la probabilidad de las amenazas o bien por reducir el impacto que estas tendrían en caso de materializarse.

En nuestro ejemplo, los riesgos a tratar son dos:

Sistema A	Impacto	Probabilidad	Riesgo inherente	Riesgo Efectivo
Malware	Confidencialidad: 5	3	5	4
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	3	5	4

Y el plan de tratamiento asociado en este caso, podría ser el siguiente:

• Aumentar la frecuencia de escaneos de vulnerabilidades en el equipo para realizarlos mensualmente.
• Adquirir el compromiso de resolver todas las vulnerabilidades que se detecten en el sistema en un plazo máximo de 2 meses.
• Hardenizar el servidor para eliminar todos aquellos servicios que no sean necesarios.

Lo ideal, a la hora de establecer el plan de tratamiento de riesgos será priorizar las acciones en función del riesgo que ayuden a mitigar y, siempre que sea posible, agruparlas en proyectos transversales que permitan mitigar los riesgos de toda una tipología de activos en lugar de abordarlos de manera individual en cada caso.

Tras analizar los efectos que estas medidas tendrán sobre los riesgos, establecemos cual será el riesgo residual, es decir, el riesgo efectivo que permanecerá una vez implantadas las medidas definidas:

Sistema A – Riesgo Redidual	Impacto	Probabilidad	Riesgo Efectivo	Riesgo Residual
Desastres Naturales	Disponibilidad: 2	1	1	1
Errores en la administración	Confidencialidad: 4	2	3	3
	Integridad: 4
	Disponibilidad: 2
Malware	Confidencialidad: 5	2	4	3
	Integridad: 5
	Disponibilidad: 2
Ataques intencionados	Confidencialidad: 5	2	4	3

Espero que hayáis encontrado útil este post. Como siempre, si encontráis cualquier error en el mismo, queréis proponer cualquier mejora al respecto del tema tratado o simplemente queréis dejar un comentario opinando sobre el mismo, no dudéis en hacerlo!

Twitter: @omarbenjumea

http://about.me/omarbenjumea

Auditing Security of a Linux System

The purpose of this post is to detail what type reviews will be performed on a linux computer to determine if it meets the security requirements of the PCI DSS standard. To do this, whenever possible, I will detail the commands to use in each case.

However, although the main purpose is to audit compliance with PCI DSS, the proposed revisions can be used as a starting point for any security audit of a linux computer you want to perform.

All the commands in this post have been tested on Ubuntu 12.04 computer, so it is possible that some of them need to be modified to work properly on other Linux distributions. We can use the lsb_release-a command for the exact version of the system we are reviewing, or obtain it from the /etc/os-release.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

The command

Iptables -L -v

will show the firewall rules used in the system. In case of a laptop, you should review compliance with PCI DSS 1.4 that required to install and mantain a personal firewall. In any case, you should review the rules defined in the fw because in certain circumstances can serve as a compensating control in the absence of compliance with other requirements of the standard.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

To verify some aspects

To verify some aspects of compliance with this requirement, we can use the following commands:

Dpkg -l

This command allow us to list all installed packages in order to detect unnecessary packets that should have been uninstalled.

route -n

This command allows us to list all the routes defined in the system.

Additionally, analysing the following files we could determine if it has changed the name resolution of the system:

/etc/resolv.conf

/etc/hosts

/etc/nsswitch.conf

Also, you must check the next file to detect if exist unnecessary or predefined user accounts that should have been deleted or disabled:

/etc/passwd

Likewise, you should check out the company's hardening guide and identify any additional evidence that should be adquired to ensure it is being properly applied.

It is also important to identify which is the primary function of this server, and use the review to identify any package or service that does not make sense for that primary function. For example, if the primary server role is to act as a web server, it makes sense that we locate apache packages installed, but would not have it we found packages of Oracle or Nessus. The existence of these packages could make us suspect that the server is being used for more than one primary function and therefore the requirement 2.2.1 is not in place.

We can use the following command to list all running processes and services listening on the UDP and TCP ports to verify that there are no processes or unnecessary services running and all that are running are adequately documented and justified:

ps -edf

Lsof -i UDP -n -P

Lsof -i TCP -n -P

We should aldo review this folder to detect scheduled tasks:

/var/spool/cron/crontabs

Additionally, we review this list of processes and services to identify insecure protocols (such FTP, Telnet, etc.) and check that they have been documented and implemented additional security measures for these protocols.

Finally, to complete the review of this requirement, we will review the following file to check the existing SSH configuration on the server:

cat /etc/ssh/sshd_config

In this file we can verify which port SSH is running, what versions are allowed (should only be permitted v2 because v1 is vulnerable) and what encryption protocol is being used to ensure that is a sufficiently robust protocol. Additionally, you should check that the value of AllowTcpForwarding is "no", unless is justify the need to use this server as jumping server to manage other systems.

Requirement 6: Develop and maintain secure systems and applications

To check this requirement, we have to validate that there are no unsafe versions of software on the system. With this purpose in mind, we can use the following commands:

Uname -a

This command allow us to know witch kernel version is used and verify that there are not know vulnerabilities for that version, or in other words, that the kernel is correctly patched.

In the other hand, with the next command we can list all the packages installed in the system and their versions, so we can also check if there are any package vulnerable in the system. Remember that to meet this requeriment you must to install security patches for all the software included in the PCI DSS scope:

Dpkg -l

Last, but not least, we shoud review the next file to verify that there are not developers or testing user accounts. This kind of accounts must be deleted before the system or the apps are deployed in production environment:

/etc/passwd

Requirement 7: Restrict access to cardholder data by business need to know

In order to verify compliance with the PCI DSS requirement 7, you can perform the following checks:

/etc/sudoers

/etc/pam.d/sudo

/etc/pam.d/su

In these files we can check which users have permission to increase their privileges to root and under what conditions they can. All cases should be properly documented and justified.

We should also review the perms of the next file and any backup that it could have to be sure it can not be open or edited for any user:

/etc/shadow

On the other side, we should check that the setuide files can not be edited by don't authorized users to increase their system privileges. We could use next command for this purpose:

find / -perm -4000 -ls 2> /dev/null

Next commands allow us to list all files that can be open or edited by any user and are not located on /proc folder:

find / -type f -perm -006 2>/dev/null | grep -v /proc

find / -type f -perm -002 2>/dev/null | grep -v /proc

We should analyze these files to check if exists a justification for the privileges that are defined in each case.

In addition, we should review the next file to verify what shell have assigned each account:

/etc/passwd

Also, we should review next file to check if are defined any restriction to the users login:

Así mismo, se deberá revisar el fichero

/etc/security/access.conf

This file allow to limit the kind of access that some accounts can have. In example, you can configure it to prohibit the remote access to the root account or the console access to some user or app accounts.

Finally, you should review the next file to verify that the line “none *” exists and is not commented, as well as there are no users with extra capabilities without a justified reason for it:

/etc/security/capability.conf

Requirement 8: Identify and authenticate access to system components

To check the major part of PCI DSS requirement 8 we should review the next file:

/etc/pam.d/common-password

In this file we can find what algoritm is used to hash the passwords stored in /etc/shadow and verify if it is used pam_cracklib.so to configure a password policy that meets requirement 8.2.1 of PCI DSS.

Requirement 10: Track and monitor all access to network resources and cardholder data

To analyze compliance with this requirement of PCI DSS must be reviewed two aspects; time configuration and syslog settings.

Reviewing next file we know the UTC time zone being used by the system:

/etc/timezone

This other command allow us to verify the NTP Servers configuration for the time synchronization of the system:

Ntpdate

On the other side, next command allow us to know if syslog process is running:

ps -edf | grep syslog

Reviewing the next file we can know if syslog is configured to receive events from other systems or devices and what permits will have the generated log files:

/etc/rsyslog.conf

Finally, reviewing this file (or its equivalent defined in first lines of the file /etc/rsyslog.conf) we can know what events are generated and where they are saved or sent. On this way, we can verify if all the security events included on the PCI DSS scope are stored centralized as the standard requires:

/etc/rsyslog.d/50-default.conf

Requirement 11: Regularly test security systems and processes

Check what type of file integrity monitoring solution is installed. Depending on the type of solution being used, we must do appropriate revisions to ensure that the requirement 11.5 of PCI DSS. ie, at least weekly, the solution should check the changes made to files considered critical as system executables, application executables, parameter files, etc.

I hope you enjoy and find useful this post. If you have found any error or you wish propose any improvement, please, don't hesitate to propose it in a comment.

Twitter: @omarbenjumea

http://about.me/omarbenjumea

Auditar la seguridad de un sistema Linux

El propósito de este post es detallar qué tipo de revisiones se deben realizar en un equipo linux para determinar si cumple con los requisitos de seguridad del estándar PCI DSS. Para ello, siempre que sea posible, vamos a detallar los comandos a utilizar para obtener la información necesaria en cada caso.

No obstante, aunque el propósito principal sea auditar el cumplimiento de PCI DSS, las revisiones propuestas pueden utilizarse como punto de partida para cualquier revisión de seguridad de un equipo linux que se quiera realizar.

Todos los comandos indicados en este post han sido probados en un equipo Ubuntu 12.04, por lo que es posible que algunos de ellos deban ser modificados para que funcionen correctamente en otras distribuciones de linux. Podemos utilizar el comando lsb_release -a para conocer la versión exacta del sistema que estamos revisando, o bien obtenerla del archivo /etc/os-release.

 

Requisito 1: Install and maintain a firewall configuration to protect cardholder data

El comando

Iptables -L -v

mostrará las reglas de firewall utilizadas en el equipo. En caso de tratarse de un equipo portátil, se debería revisar el cumplimiento del req 1.4 de PCI DSS que exige que se instale y se mantenga un firewall personal en este tipo de equipos. En todo caso, es aconsejable revisar las reglas de fw definidas en el equipo ya que en determinadas circunstancias pueden servir como control compensatorio ante la ausencia de cumplimiento de otros requerimientos del estándar.

 

Requisito 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Para verificar algunos aspectos del cumplimiento de este requisito, podremos utilizar los siguientes comandos:

Dpkg -l

Nos permitirá listar todos los paquetes instalados con objeto de detectar paquetes innecesarios que debieran haber sido desinstalados.

route -n

Nos permitirá listar todas las rutas definidas en el sistema. Adicionalmente, el análisis de los siguientes ficheros nos permitirá determinar si se ha modificado la resolución de nombres del sistema o si se ha personalizado el encaminamiento:

/etc/resolv.conf

/etc/hosts

/etc/nsswitch.conf

Adicionalmente, se debería revisar el archivo

/etc/passwd

para detectar la existencia de cuentas de usuario innecesarias o por defecto que deberían haber sido ser borradas o deshabilitadas.

Así mismo, se debería revisar la guía de hardening documentada por la organización para este tipo de sistemas e identificar cualquier comprobación adicional que deba ser realizada para garantizar que está siendo correctamente aplicada.

También es importante identificar cual es la función primaria de este servidor, y aprovechar la revisión para identificar cualquier paquete o servicio que no tenga sentido para dicha función primaria. Así, por ejemplo, si la función primaria del servidor es la de actuar como servidor web, tendrá sentido que localicemos paquetes de apache instalados, pero no lo tendría que encontráramos paquetes de Oracle o Nessus. La existencia de dichos paquetes nos podría hacer sospechar que el servidor se está utilizando para más de una función primaria y por lo tanto se está incumpliendo el requisito 2.2.1.

Podemos utilizar los siguientes comandos para listar todos los procesos en ejecución, así como los servicios escuchando en los puertos UDP y TCP con objeto de verificar que no hay procesos o servicios innecesarios ejecutándose y que todos los que se están ejecutando están adecuadamente documentados y justificados:

ps -edf

Lsof -i UDP -n -P

Lsof -i TCP -n -P

También se debería revisar el contenido de la carpeta

/var/spool/cron/crontabs

para detectar la existencia de tareas programadas.

Adicionalmente, deberemos revisar este listado de procesos y servicios para identificar protocolos inseguros (FTP, Telnet, etc..) y verificar que se hayan documentado e implementado medidas de seguridad adicionales para estos protocolos.

Finalmente, para terminar con la revisión de este requisito, revisaremos el siguiente fichero para revisar la configuración de SSH existente en el servidor:

cat /etc/ssh/sshd_config

En este archivo podemos verificar en qué puerto se ejecuta SSH, qué versiones se permiten (únicamente debería estar permitida la v2, ya que la v1 es vulnerable) y qué protocolo de cifrado se está utilizando para garantizar que se utiliza un protocolo suficientemente robusto. Adicionalmente, se debería revisar que el valor de AllowTcpForwarding sea “no”, al no ser que se justifique la necesidad de utilizar este servidor como salto para administrar otros equipos.

 

Requisito 6: Develop and maintain secure systems and applications

Para revisar este requisito, tenemos que validar que no existen versiones inseguras de software en el sistema. Con este propósito en mente, podemos utilizar los siguientes comandos:

Uname -a

Este comando nos permitirá conocer la versión del kernel y verificar que no existan vulnerabilidades conocidas para esta versión, es decir, que el kernel esté correctamente parchedo.

Por otro lado, con:

Dpkg -l

listaremos todos los paquetes instalados en el sistema y sus respectivas versiones, por lo que podremos realizar la misma operación buscando versiones para las que existan vulnerabilidades conocidas y que por lo tanto debieran estar parcheadas o actualizadas para cumplir este requisito de PCI DSS.

Finalmente, se deberá analizar el fichero

/etc/passwd

para verificar que no existen cuentas de usuario correspondientes a personal de desarrollo ni cuentas de pruebas o testing que no hayan sido borradas en la puesta en producción del sistema.

 

Requisito 7: Restrict access to cardholder data by business need to know

Con el propósito de verificar el cumplimiento del requisito 7 de PCI DSS, se pueden realizar las siguientes revisiones:

/etc/sudoers

/etc/pam.d/sudo

/etc/pam.d/su

En estos ficheros podremos revisar qué usuarios tienen permiso para aumentar sus privilegios a root y en qué condiciones pueden hacerlo. Se deberá comprobar que todos los casos estén debidamente documentados y justificados.

Se deberá revisar que ni el fichero

/etc/shadow

ni sus posibles backups puedan ser leídos por los usuarios.

Por otro lado, se deberá comprobar que los ficheros setuid no puedan ser editados por usuarios no autorizados para aumentar de esta manera sus privilegios en el sistema. Podemos utilizar el siguiente comando para dicha revisión:

find / -perm -4000 -ls 2> /dev/null

Los siguientes comandos nos permitirá listar los ficheros que pueden ser leídos por cualquier usuario y que no están ubicados en /proc:

find / -type f -perm -006 2>/dev/null | grep -v /proc

find / -type f -perm -002 2>/dev/null | grep -v /proc

Se deberán analizar los ficheros obtenidos para ver si existe una justificación para los permisos que tienen establecidos.

Por otro lado, se deberá revisar el fichero

/etc/passwd

para verificar qué shell tiene asignada cada usuario y qué usuarios no tiene asignada ninguna shell.

Así mismo, se deberá revisar el fichero

/etc/security/access.conf

para comprobar si existen restricciones en el login de usuarios. Este fichero permite configurar limitaciones al tipo de acceso que puedan tener determinadas cuentas, por ejemplo, impidiendo el acceso remoto a la cuenta root, o el acceso mediante consola a determinadas cuentas de usuario o aplicación.

Finalmente, se deberá revisar el fichero

/etc/security/capability.conf

para confirmar que existe la linea “none *” no comentada (sin #), y que no se han asignado capacidades extras a usuarios sin que exista un motivo justificado para ello.

 

Requisito 8: Identify and authenticate access to system components

Para verificar la mayoría de los aspectos incluidos en el requisito 8 de PCI DSS será necesario revisar el archivo

/etc/pam.d/common-password

En este archivo podremos revisar qué algoritmo se está usando para el hash con el que se guardan los passwords en /etc/shadow y verificar si se está usando pam_cracklib.so para configurar una política de contraseñas suficiente para dar cumplimiento al requisito 8.2.1 de PCI DSS:

 

Requisito 10: Track and monitor all access to network resources and cardholder data

Para analizar el cumplimiento de este requisito de PCI DSS debemos revisar dos aspectos; la configuración de tiempo y la configuración de syslog.

Revisando el siguiente archivo podremos conocer la zona de tiempo UTC que está siendo utilizada por el sistema:

/etc/timezone

Mediante el siguiente comando, podremos verificar la configuración de servidores NTP que está siendo utilizada para la sincronización horaria del sistema:

Ntpdate

Por otro lado, el siguiente comando nos permitirá saber si el proceso de syslog está habilitado:

ps -edf | grep syslog

Revisando el fichero

/etc/rsyslog.conf

se puede verificar si está habilitado el servicio syslog para recibir eventos de otros sistemas o dispositivos y qué permisos van a tener los ficheros de logs generados.

Finalmente, mediante la revisión del fichero

/etc/rsyslog.d/50-default.conf (o su equivalente indicado al principio del fichero /etc/rsyslog.conf)

podremos identificar qué eventos se están generando y en qué rutas se están guardando estos ficheros de logs (o a qué servidores se están enviando). De esta manera, podremos verificar si se está cumpliendo el requisito de centralizar todos los eventos de seguridad generados por los sistemas incluidos en el alcance de PCI DSS.

 

Requisito 11: Regularly test security systems and processes

Revisar qué tipo de software de monitorización de integridad de ficheros tiene instalado el sistema. En función del tipo de mecanismo que se esté utilizando, se deberán realizar las revisiones pertinentes para garantizar que se cumple el requisito 11.5 de PCI DSS, es decir, que al menos semanalmente se comprueban la modificaciones realizadas en ficheros considerados críticos como ejecutables del sistema, ejecutables de aplicaciones, ficheros de parámetros y configuraciones, histórico de logs u otros archivos que no deban cambiar frecuentemente y se consideren críticos para la seguridad del sistema o de los datos.

Espero que la entrada os guste y os sea de utilidad y, por supuesto, si alguien detecta algún error o tiene alguna sugerencia de mejora de cara a realizar este tipo de auditorías, se agradecerá cualquier aportación al respecto.

¿Aún no me sigues en twitter?: @omarbenjumea
http://about.me/omarbenjumea

PCI DSS & Incident Response Planning

No organization is safe from suffering a security incident. It may take more or less suffer and solve it, be more or less severe, or even can not find out you're having a security incident (no, I will not talk about APTs this time), but at some point your organization will need to respond to an incident.

Therefore, every organization should have an incident response plan consistent with the potential safety impact of a security incident can result for your business. The absence of a response plan security incidents can significantly increase the response time to an incident and may even cause a not adequate response that finish aggravating the incident's impact.

Paragraph 12.10 v3 PCI DSS requires organizations affected by the standard to implement a response plan and be prepared to respond immediately to any compromise on their systems. In this sense, what is required by the standard is the plan includes within its scope all the key elements that are necessary for the organization to respond effectively in the event that the incident might affect the cardholder data. But considered in developing a response plan, I think it is ridiculous to stick only to the scope of PCI DSS because with little more effort we can have a response plan that reaches across the organization and enable us to respond in a effective and efficient way in case of an incident.

Let us see the steps to follow to develop a plan that allows us to meet the requirement of PCI DSS 12.10 but at the time we prepared to act on incidents involving other areas of our organization.

Preparation

In the preparation phase we carry out the following main activities :

1. Clarify the scope of our Plan. Not the same prepare a Security Incident Plan to limit the scope only to incidents of Information Security, safety, property security , etc. To comply with PCI DSS, the scope of the Plan must include, at least, all critical systems within the scope of processing, storage and transfer cardholders data.
2. It should define and document the roles and responsibilities of all participants in the Incident Response Plan.
3. While many management methodologies proposed security incidents conducting a risk analysis, including the recently published NIST cybersecurity framework, I prefer making only one BIA (Business Impact Analysis ) that allows us to be clear what impact can have a incident in different fields (legal, financial , operational, human damage , reputation ). There are different methodologies or approaches for a BIA but my recommendation, especially in a first implementation of the Plan, is to opt for one that is simple enough to have a realistic BIA in a short space of time. Importantly, the BIA should not just analyse incidents that impair the availability of information, since it is not preparing the Plan Business Continuity, otherwise you have to take into account the impacts in terms of loss confidentiality and integrity of information.
4. Define scenarios of incidents that can occur based on the analysis in the BIA. Ie document all those events that can cause major impacts identified in the previous section. It is recommended in a first draft of the Plan will not be overambitious and unify and group enough to guarantee the volume of scenarios is manageable. We did not do any useful if document 500 possible casuistic and then we will take 5 years to write response procedures for each of it...
5. Document the mechanisms established to detect the realization of the scenarios defined in the previous phase. At this stage it is very likely that deficiencies or impossibilities in the detection of some of the scenarios are identified. In cases where feasible, prepare an improvement plan designed to implement controls or improvements to the detection of these scenarios in a tolerable time. In considering the elements that can trigger the process of incident management, PCI DSS requires that, at least, the monitoring systems of the organization are considered, such as IDS / IPS, firewalls or file integrity systems (FIM) events.
6. Documenting the criteria for classification of incidents. You must define a taxonomy and criteria for classifying a potential incident in the relevant category. Again my recommendation is to prime the simplicity. We should not have more than 10 categories for the first level of classification of incidents.
7. Documenting the action procedures in case of realization of each type of incident.These procedures should include or reference the BCP procedures that must be followed if the incident affects the business continuity. Additionally, to comply with PCI DSS, you must include or reference procedures for backup of data as well as any aspect or legal requirement to consider in case of incident. The procedures must include details of actions to be performed for:
1. Contain the incident.
2. Solving the incident.
3. Recover normal operation
8. Document strategies and procedures for communication to a security incident . Ie , what to say, who to say and how to say in each case, or in any case, clearly define who is responsible for making these decisions in case of incident. The damage to the image or reputation of the company can vary greatly depending on what is communicated and how to communicate following a security incident. To comply with PCI DSS these strategies should include, at a minimum, the procedure to communicate any compromise of card data to the payment card brands.
9. The Plan must be communicated and distributed to all concerned and should ensure their availability for a potential incident. That is, if one of our scenarios is that by reason of a DoS we fall our corporate systems, we should not store our Incident Response Plan just in corporate systems, since we can not retrieve it when needed. Also, if one of the scenarios considered is the lack of access to the office, we did not do any good if we only have it printed on our desktop.
10. It should define and establish the necessary way for anyone to notify the responsible occurrence of a possible incident. These routes should be simple, quick and have alternatives in case one of them fails.
11. The incident response team should be adequately trained and with a 24x7 availability to act in case of an incident materialize to prevent the delay in resolution might aggravate their impact and consequences. On the other hand, have well documented procedures and team training are vital to prevent the activities undertaken to resolve the incident may degrade or corrupt the evidence necessary for proper forensic investigation of the incident.
12. You need to plan a test plan that allows a high degree of assurance that the proposed Plan works correctly in case of incident. Testing will be performed at least annually, are critical to ensure that the defined procedures are truly effective and that all affected personnel have necessary knowledge thereof.

During the incident.

During the incident should note the following:

1. It must follow the procedures defined in the Plan in each case.
2. You must keep a detailed log of all the events and actions carried out during the incident.
3. You should prioritize containment incident.
4. Once content, you must proceed to its resolution.
5. Finally, once resolved, should proceed to the recovery of the affected systems.

Continuous Improvement.

PCI DSS requires that a specific section of continuous improvement is included in the incident response plan so that the action and resolution in each security incident is analysed to detect areas improvement in the processes of incident detection or response.

To do this, you must analyse the outputs, understanding what happened and why it happened, for each of the incidents suffered as well as the tests done and analyse what improvements can be made in the Plan in several areas:

• Improvements in the prevention of incidents.
• Improved detection of incidents.
• Improved containment and resolution of incidents.
• Improved recovery of equipment or business.
• Improvements in the test plan.
• Improvements to the defined incidents scenarios.
• Improved staff training or awareness.

Finally , it is also important to consider the plan within the change management of the organization, so that the Incident Response Plan is updated whenever changes in systems or in the organization leave obsolete any of the incident response procedures.

In short, it is to have a documented plan, distributed, tested and known to allow act in the best way and in the shortest possible time when a security incident happen in order to minimize the impact and consequences that the incident can cause to the organization.