Implementando el Requerimiento 1 de PCI DSS (II)

Continuando el análisis del primer requerimiento del estándar PCI DSS iniciado en la entrada previa, ahora nos toca analizar el requerimiento 1.3:

1.3 Prohíba el acceso directo público entre Internet y todo componente del sistema en el entorno de datos de los titulares de tarjetas.

1.3.1 Implemente un DMZ para limitar el tráfico entrante sólo a aquellos componentes del sistema que proporcionan servicios, protocolos y puertos con acceso público autorizado.

1.3.2 Restrinja el tráfico entrante de Internet a las direcciones IP dentro del DMZ.

1.3.3 No permita ninguna conexión directa de entrada o salida de tráfico entre Internet y el entorno del titular de la tarjeta.

1.3.4 No permita que las direcciones internas pasen desde Internet al DMZ.

1.3.5 No permita que llegue tráfico saliente no autorizado proveniente del entorno de datos del titularde la tarjeta a Internet.

1.3.6 Implemente la inspección completa, también conocida como filtrado dinámico de paquetes. (Es decir, sólo se permite la entrada a la red de conexiones establecida).

1.3.7 Coloque los componentes del sistema que almacenan datos de titulares de tarjetas (como una base de datos) en una zona de red interna, segregada desde un DMZ y otras redes no confiables.

1.3.8 No divulgue direcciones IP privadas ni información de enrutamiento a partes no autorizadas,

• Traducción de Dirección de Red (NAT)
• Ubicar servidores que contengan datos de titulares de tarjetas detrás de servidores proxy/firewalls o cachés de contenido,
• Eliminación o filtrado de anuncios de enrutamiento para redes privadas que emplean direcciones registradas,
• Uso interno del espacio de dirección RFC1918 en lugar de direcciones registradas.

El objetivo de disponer de firewalls de perímetro es proteger y controlar las conexiones entre los sistemas públicos y el entorno de datos de tarjeta, por lo que no deben existir conexiones directas (que no estén siendo filtradas por los firewalls) entre Internet y el entorno de datos de titulares de tarjeta) ya que anularían la eficacia de las defensas perimetrales.

La organización debe contar con una DMZ que gestione las conexiones entre Internet u otras redes no confiables y los servicios internos que deban ser públicamente accesibles, como los servidores web, los frontales de correo electrónico, etc.. Todas las conexiones que se inicien desde Internet u otras redes no confiables deben tener como destino direcciones IP pertenecientes a la DMZ, no debiéndose permitir en ningún caso el acceso directo a equipos de la red interna de la organización. Esto nos permitirá monitorizar y restringir el tráfico o el contenido previniendo el libre acceso entre redes no confiables y redes que sí lo son. Así mismo, todos los elementos que almacenen datos de tarjetas deberán estar siempre alojados en la red interna y segregados (mediante firewalls o routers con ACLs) de la DMZ, Internet o cualquier otra red no confiable.

Adicionalmente, deberá evitarse las conexiones directas, tanto en sentido entrante como saliente, entre internet y el entorno de datos de tarjeta. Por lo tanto, además de limitar este tipo de conexiones al mínimo indispensable por motivos de negocio, se deberá utilizar siempre algún dispositivo o sistema que actúe como proxy o proxy inverso y que esté alojado en la DMZ para habilitar este tipo de conexiones.

Por otro lado, el estándar obliga a que los firewalls perimetrales se configuren para bloquear cualquier paquete que llegue desde internet cuya IP de origen se haya “spoofeado” para que coincida con alguna dirección del rango interno de la red de la organización. Así mismo, los firewalls deben configurarse con la característica de “stateful inspection” habilitada para garantizar que tan sólo permitan “respuestas” a conexiones que efectivamente hubieran sido iniciadas anteriormente.

Por último, el requerimiento 1.3.8 intenta evitar que se facilite información de enrutamiento o de red a terceros que pueda ser utilizada por un potencial atacante para conseguir sus objetivos de una manera más sencilla. Por ello, el estándar propone la utilización de NAT, o de cualquier otra técnica que permita garantizar que no se revela el direccionamiento interno de los sistemas de nuestra organización en los paquetes de comunicaciones que se envían a terceros.

Y por fin llegamos al último subrequerimiento del requerimiento 1 del estándar:

1.4 Instale software de firewall personal en toda computadora móvil o de propiedad de los trabajadores con conectividad directa a Internet (por ejemplo, laptops que usan los trabajadores), mediante las cuales se accede a la red de la organización.

Este requerimiento exige que se instale firewall personal en los siguientes grupos de equipos:

• En los equipos portátiles propiedad de la empresa que se vayan a conectar a la red corporativa.
• En los equipos portátiles propiedad de los trabajadores que se utilicen para acceder a la red de la organización (por VPN o físicamente en la red local).
• En los equipos de sobremesa propiedad de los trabajadores que se utilicen para acceder a la red de la organización (por ejemplo, vía VPN).

Además, el requerimiento obliga a que las reglas del firewall personal sean mantenidas por la organización y que se garantice que los trabajadores no pueden alterar dichas reglas ni deshabilitar el software instalado.

El objetivo de este requerimiento es evitar que equipos que se hayan conectado directamente a Internet sin contar con la protección de las defensas perimetrales de la organización puedan ser un foco de infección y anular la efectividad de dichas medidas en la empresa.

Como vemos, dependiendo de la organización y el escenario en el que nos movamos, puede ser harto complicado cumplir este requerimiento si no impedimos que los usuarios puedan acceder a la red de la organización con equipos de su propiedad. De todas formas, se nos presentan múltiples alternativas para abordar el cumplimiento de este requerimiento. Dos ejemplos de estrategias que podrían ser válidas para algunas organizaciones:

• Prohibir la conexión a la red de la organización de ordenadores que sean propiedad de los trabajadores (ya se sabe, muerto el perro...).
• En caso de que sea indispensable que los usuarios se conecten con ordenadores de su propiedad vía VPN, utilizar concentradores VPN que incorporen análisis de cumplimiento de políticas por parte de los clientes (para que verifiquen que el antivirus y el firewall personal estan habilitados y bien configurados antes de permitir el acceso a la red de la Organización.

Por otro lado, es importante recordar que se deben establecer reglas estrictas en el firewall personal, y que estas reglas deben ser mantenidas por la organización impidiendo en todo caso que los usuarios las puedan cambiar o deshabilitar, por lo que se hará necesario contar con un software que no pueda ser administrado por los usuarios que permita la configuración y gestión centralizada de las reglas a establecer.

Para finalizar esta segunda entrada sobre el requerimiento 1 de PCI DSS, me gustaría dar mi visión sobre el cumplimiento del mismo por parte de las organizaciones. Si bien es cierto que estos son requerimientos que, en mayor o menor medida ya se cumplen en la mayoría de organizaciones a poco que tengan una mínima madurez en seguridad de la información (pocas organizaciones me he encontrado que no dispongan de firewalls implementados en todas sus conexiones a Internet, aunque siempre hay alguna...) lo más frecuente es que la documentación (requerimiento 1.1) brille por su ausencia. También es muy frecuente que al analizar las reglas implementadas en un firewall aparezcan uno o varios “permit any” que impedirían la certificación PCI y cuya sustitución por reglas concretas suele dar más de un quebradero de cabeza al departamento de comunicaciones de la organización. Por último, como ya hemos comentado, el requerimiento 1.4 puede ser también un hueso duro de roer en función de la cultura existente en la organización en relación al uso de portátiles y/o ordenadores que sean propiedad de los trabajadores.

Implementando el Requerimiento 1 de PCI DSS (I)

El primer requerimiento del estándar (Instalar y mantener una configuración de firewall para proteger los datos de tarjeta) se centra en la seguridad perimetral de la red con objeto de que se instale y se mantenga una infraestructura de firewalls y otros dispositivos de red que supongan un primer nivel de protección frente amenazas que provengan del exterior de la red de nuestra organización.

Analicemos a continuación las implicaciones que se derivan de implantar cada uno de los subrequerimientos enunciados por PCI DSS para alcanzar este objetivo.

1.1 Establezca normas de configuración para firewall y router que incluyan lo siguiente:

1.1.1 Un proceso formal para aprobar y probar todos los cambios y las conexiones de red en la configuración de los firewalls y los routers.

1.1.2 Requisitos para tener un firewall en cada conexión a Internet y entre cualquier zona desmilitarizada (DMZ) y la zona de red interna.

1.1.3 Descripción de grupos, roles y responsabilidades para una administración lógica de los componentes de la red.

1.1.4 Documentación y justificación de negocio para la utilización de todos los servicios, protocolos y puertos permitidos, incluida la documentación de funciones de seguridad implementadas en aquellos protocolos que se consideran inseguros. Entre los servicios, protocolos o puertos no seguros se incluyen, a modo de ejemplo, FTP, Telnet, POP3, IMAP y SNMP.

1.1.5 Requisito de la revisión de las normas del firewall y el router, al menos, cada seis meses.

Los firewalls y los routers son elementos claves en la arquitectura defensiva de la red de la organización ya que controlan y gestionan tanto la entrada como la salida de la misma bloqueando los accesos no deseados. Es importante disponer de normativas y procedimientos adecuadamente implementados que describan cómo se deben configurar los firewalls y los routers por parte del personal responsable.

En primer lugar, es necesario disponer de un procedimiento documentado que incluya un proceso formal para probar y aprobar cualquier cambio en las reglas de los firewalls o los routers con objeto de prevenir problemas de seguridad derivados de este tipo de cambios. Es importante señalar que los flujos de datos que se produzcan entre sistemas virtualizados deberán ser regulados por estas normativas y procedimientos como si se trataran de datos que realmente se transmitieran por la red física.

Por otro lado, debemos contar con diagramas de red actualizados que permitan identificar claramente la situación de todos los elementos de red y los flujos de datos de titulares de tarjeta que se produzcan a través de la red, incluyendo los flujos que se produzcan entre sistemas virtuales alojados en un mismo host físico.

Como vemos en el punto 1.1.3, el estándar exige que las normativas internas obliguen a que siempre se use un firewall para controlar y monitorizar cada conexión, entrante o saliente, de la red de la organización.

Además, las normativas de gestión de los dispositivos de red deben incluir la descripción de roles y responsabilidades garantizando que se defina claramente de quien es la responsabilidad de gestionar la seguridad de todos los componentes de red.

Así mismo, la normativa y los procedimientos deben documentar claramente qué servicios, protocolos y puertos son necesarios para el negocio de nuestra organización. Las reglas configuradas en los firewalls y/o routers de la organización deben garantizar que únicamente estos servicios, protocolos o puertos sean permitidos en la red. Así mismo, la configuración de los firewalls debe ser en modo “deny all” permitiendo únicamente el tráfico explícitamente autorizado (y documentado).

Por otro lado, hay que tener en consideración que es muy común que el negocio necesite servicios, protocolos o puertos “inseguros”, es decir, que son frecuentemente usados por individuos maliciosos para tratar de comprometer la red de sus objetivos (telnet, FTP, SNMP, NetBIOS, etc..). En estos casos, lo que exige el estándar es que el riesgo de utilizar estos servicios, protocolos o puertos debe ser claramente entendido, aceptado y justificado por el negocio, debiéndose documentar los controles de seguridad adicionales que hayan sido implementados para proteger a la organización de los riesgos derivados del uso de estos protocolos.

Finalmente, es necesario que la normativa obligue a la revisión semestral (aunque es aconsejable hacerla trimestral o incluso mensual) de las reglas implementadas en los firewalls y routers de la organización con objeto de validar que las reglas siguen vigentes y detectar cualquier regla obsoleta, incorrecta o innecesaria que deba ser eliminada o modificada garantizando que únicamente se permita el tráfico necesario, documentado y justificado por el negocio.

Echémosle ahora un vistazo al subrequerimiento 1.2:

1.2 Desarrolle configuraciones para firewalls y routers que restrinjan las conexiones entre redes no confiables y todo componente del sistema en el entorno de los datos del titular de la tarjeta. Nota: Una “red no confiable” es toda red que es externa a las redes que pertenecen a la entidad en evaluación y/o que excede la capacidad de control o administración de la entidad. 

1.2.1Restrinja el tráfico entrante y saliente a la cantidad que sea necesaria en el entorno de datos del titular de la tarjeta. 

1.2.2 Asegure y sincronice los archivos de configuración de routers.

1.2.3 Instale firewalls de perímetro entre las redes inalámbricas y el entorno de datos del titular de la tarjeta y

configure estos firewalls para negar o controlar (en caso de que ese tráfico fuera necesario para fines de negocio) todo tráfico desde el entorno inalámbrico hacia el entorno del titular de la tarjeta.

El requerimiento 1.2 busca garantizar que se asegura correctamente la red instalando, configurando y manteniendo firewalls entre la red interna y cualquier red no confiable (incluyendo redes de partners o proveedores).

El requerimiento 1.2.1 exige que se limite todo el tráfico entrante y saliente del entorno de datos de titulares de tarjeta al mínimo imprescindible para el funcionamiento del negocio. Adicionalmente, el estándar exige que todos los firewalls incluyan una regla que deniegue todo el tráfico, tanto entrante como saliente, que no haya sido explícitamente permitido por ser necesario.

El requerimiento 1.2.2 indica que se debe asegurar y sincronizar los archivos de configuración del router. Lo que busca este requerimiento es garantizar que los archivos de arranque de los routers tengan las mismas reglas y configuraciones de seguridad que se hayan establecido en las configuraciones “on-line” de los routers, de manera que ante un reinicio de los dispositivos se conserven dichas conexiones seguras.

Finalmente, el requerimiento 1.2.3 exige que siempre haya un firewall instalado entre las redes inalámbricas y el entorno de datos del titular de la tarjeta habiéndose configurado dicho firewall para negar o controlar todo el tráfico existente entre el entorno inalámbrico y el entorno de datos de titular de la tarjeta. Hay que tener en cuenta que las tecnologías inalámbricas son un camino frecuentemente explotado por individuos maliciosos para obtener acceso no autorizado a la red de las organizaciones o al entorno de datos de titulares de tarjeta. La ausencia de firewalls entre los entornos inalámbricos y el entorno de titulares de tarjeta permitiría a un atacante que haya obtenido acceso a la red inalámbrica acceder a si vez al entorno en el que se almacenan, transmiten o procesan los datos de titulares de tarjetas de pago. Por ello, el estándar obliga a que se instalen firewalls entre el entorno de datos de tarjeta y cualquier red inalámbrica de la organización, negando todo el tráfico entre ambos existentes salvo aquel que esté debidamente justificado y documentado por motivos de la operativa de negocio.

Dejaremos para la próxima entrada el análisis del resto de los subrequerimientos 1.3 y 1.4.

Evolución de las amenazas en las Infraestructuras Críticas

Hasta no hace tantos años, los sistemas que controlaban las infraestructuras críticas eran sistemas de control aislados o, en todo caso estaban conectados a redes de sistemas de control que permanecían aisladas. Por este motivo, la seguridad lógica nunca ha sido un pilar básico en el diseño del software que incorporan estos sistemas. De hecho, muchos de ellos carecen de cualquier tipo de medida de seguridad lógica, no contando ni siquiera con métodos básicos de control de acceso. También es práctica común el uso de protocolos inseguros como telnet o FTP, la total ausencia de trazas o logs, y el uso de sistemas operativos sin parchear u obsoletos como Windows NT, Windows 98 o en algunos casos especialmente preocupantes, incluso Windows 95…

Sin embargo, estas redes que antes estaban totalmente aisladas, se han ido conectando progresivamente a redes de administración y redes de usuario, tanto para alimentar con datos adquiridos sistemas ubicados en estas nuevas redes, como para facilitar la monitorización y administración remota de los sistemas de control. Y obviamente, estas nuevas redes están conectadas con Internet. Esta interconexión de redes provoca que los sistemas industriales que controlan algunas infraestructuras críticas sean mucho más vulnerables ya que potencialmente pasan a ser accesibles desde cualquier PC del mundo que cuente con conexión a internet.

Por otro lado, el escenario mundial en el que nos encontramos actualmente también ha sufrido una gran evolución desde el final del siglo XX. Los ataques deliberados desde internet ya no proceden de tecnólogos adolescentes con ganas de demostrar su habilidad. Actualmente, los atacantes pueden ser tan variados como naciones rivales, mafias o grupos terroristas. Y es que a pesar de que la motivación para perpetrar un “ciberataque” suele ser económica, también nos podemos encontrar con móviles políticos o sociales, por lo que la amenaza terrorista ha de ser tenida especialmente en cuenta en la seguridad de las infraestructuras críticas. Las amenazas están creciendo exponencialmente en los últimos años.

Así mismo, a nadie se le escapa que vivimos en una sociedad cada día más dependiente de la tecnología, pues existen cada vez más servicios esenciales que presentan una fuerte dependencia de sistemas de control digitales para su correcto funcionamiento. Por ello, el impacto potencial que un incidente pueda tener en estos sistemas es cada vez mayor, y es totalmente previsible que esta tendencia se acentúe en los próximos años.

De hecho, existen numerosos ejemplos públicamente conocidos de incidentes de seguridad ocurridos en infraestructuras críticas. Por poner algunos ejemplos concretos:

• EEUU (Agosto de 2003): El gusano “Slammer” infecta una red informática de una central nuclear. Como consecuencia queda desactivado durante cinco horas un sistema encargado de monitorizar que la planta estaba operando bajo condiciones de seguridad.
• EEUU (Diciembre de 2005): La central hidroeléctrica de Taum Sauk sufrió un fallo durante el proceso rutinario nocturno de llenado del embalse. El proceso de llenado no paró cuando se había acumulado ya el agua suficiente, sobrepasándose incluso la capacidad máxima de la presa. El incidente se debió a incongruencias entre mediciones que se transmitían por medio de radio enlaces.
• Polonia (Enero de 2008): Un adolescente polaco de catorce años de edad consigue realizar a voluntad el cambio de agujas en el sistema de tranvía de la ciudad, con la elaboración de un simple mando a distancia casero. Como consecuencia cuatro tranvías descarrilaron y doce personas resultaron heridas.
• EEUU (Marzo de 2008): En una central nuclear, se produce una actualización de un servidor que era utilizado para la monitorización de datos químicos y de diagnóstico asociados con uno de los sistemas de control primarios de la planta. Tras la instalación de la actualización, el ordenador fue reiniciado, lo que derivó en falta de información de monitorización, que a su vez fue malinterpretada por los sistemas de seguridad de la planta, que dispararon un apagado de emergencia de la misma.
• Global (2010): Aparece Stuxnet, el primer malware diseñado específicamente para infectar sistemas industriales. Es un software diseñado para atacar un modelo concreto de Siemens que utiliza 4 vulnerabilidades de tipo “Zero day” inéditas hasta la fecha. Además, utiliza certificados digitales robados para legitimar su contenido malicioso. La complejidad de su diseño pone de manifiesto que se tuvieron que invertir vastos recursos en su desarrollo. Adicionalmente, se especula con que su objetivo pudiera ser el sabotaje del programa nuclear iraní.
• EEUU (Febrero 2011): McAfee detecta una serie de ataques con origen en China dirigidos a los sistemas de varias compañías energéticas de EEUU a los que bautiza como “night dragon”. Estos ataques se basan en técnicas, herramientas y vulnerabilidades conocidas con objeto de obtener información altamente sensible de las organizaciones atacadas, como documentos financieros, información sobre exploraciones de nuevos yacimientos y negociaciones confidenciales entre directivos.
• Global (Octubre 2011): Symantec detecta un nuevo software que está aprovechando vulnerabilidades “Zero day” de Windows con objeto de recopilar información de los sistemas infectados. El malware es bautizado como “duqu” y comparte partes de código con Stuxnet. Como Stuxnet, también utiliza certificados robados para legitimar su contenido y se auto-elimina en los sistemas 36 días después de la infección. Se especula que el objetivo de este nuevo malware es obtener información suficiente para perpetrar un nuevo ataque a infraestructuras críticas siguiendo el modelo de Stuxnet.

Así pues, podemos constatar que tanto las vulnerabilidades como las amenazas y el impacto aumentan, por lo que por definición, el riesgo lo hace también. Como respuesta a esta nueva realidad, el legislativo español ha aprobado el Real Decreto 704/2011, de 20 de mayo, por el que se aprueba el Reglamento de protección de las infraestructuras críticas. Este RD establece el Reglamento que desarrolla la Ley 8/2011, por la que se establecieron las medidas para la protección de infraestructuras críticas y que fue aprobada tan sólo un mes antes, en abril de 2011. El principal objetivo de esta nueva Ley es preparar a las Administraciones Públicas para prevenir y reaccionar de manera óptima ante la materialización de amenazas que puedan afectar a las infraestructuras críticas.

En esta misma Ley, se definen las Infraestructura Críticas como las instalaciones, redes, sistemas y equipos físicos o tecnologías de la información cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su perturbación o destrucción tendría un grave impacto sobre los servicios esenciales. A su vez, define como servicios esenciales aquellos necesarios para el mantenimiento de las funciones sociales básicas, la salud, la seguridad, el bienestar social y económico de los ciudadanos, o el eficaz funcionamiento de las Instituciones del Estado y las Administraciones Públicas.

Uno de los requerimientos que la legislación establece para los operadores de Infraestructuras Críticas, es la realización de un análisis de riesgos que garantice la continuidad de los servicios proporcionados por dicho operador y en la que se recojan los criterios de aplicación de las diferentes medidas de seguridad que se implanten para hacer frente a las amenazas tanto físicas como lógicas identificadas sobre cada una de las tipologías de sus activos. Por lo tanto, es necesario que la metodología de análisis de riesgos aborde de una manera unificada, coherente y global todas las amenazas a las que esté sujeta la infraestructura, con independencia de que su origen pueda ser físico o digital. Otro aspecto relevante a señalar, es la necesidad de que la metodología utilizada tenga una consideración especial para con los riesgos que afecten a la disponibilidad de los servicios, primando dicha disponibilidad sobre la confidencialidad y la integridad de la información.

Otro aspecto de vital importancia para mejorar la seguridad de nuestras Infraestructuras Críticas, pasa por establecer arquitecturas de red seguras, siguiendo el modelo que los americanos han llamado “defensa en profundidad” y que consiste en definir diferentes segmentos de red en los que se agrupan los activos digitales en función de su criticidad. De esta manera, se deben garantizar unos mínimos controles de seguridad a cumplir en cada uno de los niveles definidos de acorde a su criticidad, así como controlar adecuadamente los flujos y protocolos de información que se permiten entre los diversos niveles definidos. Por ejemplo, se deberían segmentar los sistemas de control de las redes de administración, estas a su vez de las redes de usuario, de las DMZ, y de las redes externas no confiables, ya sean de proveedores, socios o Internet. Esta adecuada segregación de redes nos permitirá establecer unos controles de seguridad mínimos con objeto de garantizar la seguridad de los sistemas críticos que soporten las infraestructuras críticas.

Adicionalmente, opino que la figura del auditor externo deberá tomar un papel de especial relevancia en las futuras estrategias de protección de las infraestructuras críticas, como garante de que los operadores están alcanzando y manteniendo un adecuado nivel de seguridad en sus infraestructuras.

Por lo tanto, ha llegado la hora de que los operadores de infraestructuras críticas prioricen la seguridad en sus hojas de ruta, ya que además del crecimiento del riesgo, ahora también se ven sometidos a nuevas presiones legislativas a las que deben dar respuesta de una manera eficiente y en las que será especialmente relevante la coordinación con las administraciones públicas y las Fuerzas y Cuerpos de Seguridad del Estado.

Seguridad Basada en Riesgos

En la actualidad, y cada vez en mayor medida, las organizaciones invierten gran cantidad de dinero y recursos en seguridad. Sin embargo, en muchos casos, los propios promotores de dicha inversión no se muestran muy seguros de que las medidas implantadas vayan a evitar realmente la ocurrencia de incidentes de seguridad. No en vano, uno de los principales problemas con los que se puede encontrar una organización a la hora de invertir en seguridad de la información, es encontrar el punto de equilibrio en el que dicha inversión maximice su beneficio. Y es que son muchos los aspectos a tener en cuenta: cual es la información a proteger, de qué tipo de ataques la tenemos que proteger, cual es la mejor manera de hacerlo o cuanto nos debemos gastar para lograrlo.

Es bien sabido que calcular el ROI, o lo que es lo mismo, conocer qué beneficio nos reporta un proyecto de seguridad, es una tarea compleja. La inversión realizada en seguridad no suele devolver beneficios tangibles, ni tan siquiera ahorrar en costes existentes, si no que nos permite ahorrar los costes potenciales que supondría la ocurrencia de un incidente de seguridad en caso de no contar con las medidas de seguridad a implementar en el proyecto.

Una posible alternativa para calcular dicho ROI es ponderar el coste que supondría el incidente que estamos securizando con la propabilidad de ocurrencia del mismo. Sin embargo, esta aproximación presenta dificultades significativas ya que suele ser complicado establecer con precisión la probabilidad de que se materialice un riesgo concreto y, por otro lado, hay que tener en cuenta que conocer el coste que podría suponer un incidente de seguridad sobre un determinado activo no es una tarea trivial.

Si pensamos, por ejemplo, en un incidente que afecte a la disponibilidad de un activo de información, puede ser hasta cierto punto sencillo calcular su coste, ya que podemos calcular cuanto nos cuesta cada segundo que el proceso que utiliza dicha información está parado. Un ejemplo claro sería el coste que supone cada minuto de parada de nuestra web de venta electrónica.

Este cálculo, sin embargo, se complica si el incidente afecta a la integridad o a la confidencialidad de la información. ¿Qué coste tiene para nuestra organización el robo de nuestra base de datos comercial? ¿Qué pérdidas nos supondría que nuestra competencia conozca nuestro plan estratégico a corto y largo plazo? Realmente es complicado cuantificar estos costes, aunque estarán de acuerdo conmigo en que sin duda son elevados.

Pese a estas dificultades, la principal herramienta con la que contamos para ayudarnos a decidir cómo y por dónde empezar (o continuar) a implementar la seguridad de nuestra organización es el análisis de riesgos. Es por ello que éste es el pilar en el que se basan los principales sistemas de gestión de la seguridad, de manera que permiten adoptar estrategias de seguridad orientadas a gestionar adecuadamente los riesgos a los que está sujeta nuestra organización, abordando en primera instancia aquellos riesgos más críticos que puedan ser mitigados con un menor esfuerzo o desembolso.

Existen múltiples metodologías y estándares para llevar a cabo el análisis de riesgo de una organización. Unos son más complejos y otros más simples. Los hay que realizan un análisis a alto nivel o a “vista de pájaro”, mientras que otros entran a un nivel de detalle realmente profundo. Podemos realizar análisis cuantitativos, esto es, estimando costes monetarios pese a las dificultades antes expuestas para realizar este tipo de valoraciones, o podemos realizar análisis cualitativos en los que obtendremos una visión relativa de los riesgos.

Por lo tanto, el optar por una u otra metodología de análisis de riesgos deberá hacerse en base al tipo de resultados que deseemos obtener del mismo, así como del presupuesto, tiempo o recursos disponibles para realizar el propio análisis de riesgo. Es importante utilizar una metodología con la que nos sintamos cómodos y obtengamos un resultado confiable, determinista y repetible que pueda ser la base para la definición de la estrategia de gestión de riesgos de nuestra organización y la planificación de la seguridad a corto, medio y largo plazo.

Así pues, el principal motivo para llevar a cabo un análisis de riesgos de seguridad en nuestras organizaciones es la posibilidad que ofrece de identificar los principales riesgos a los que se encuentra expuesta nuestra organización, permitiéndonos seleccionar las medidas a implantar para reducir dichos riesgos atendiendo a criterios de coste – beneficio. Esto posibilitará que nuestra inversión en seguridad maximice sus beneficios, abordando la seguridad desde una óptica estratégica, preventiva y coherente con los objetivos de negocio de nuestra organización.

Ingeniería Social 2.0

Con la irrupción de la web 2.0 y el auge de las redes sociales en los últimos años, la participación pública en los contenidos de la red se está incrementado de manera exponencial. Hoy en día, la información fluye sin límite, desde y hacia los propios usuarios de internet. Esta evolución, ha cambiado completamente la realidad de la red, modificando tanto la manera en la que los usuarios hacen uso de sus contenidos, como el modo en el que las organizaciones la utilizan para lograr sus objetivos de negocio.

Este cambio de paradigma en internet conlleva, a su vez, una serie de nuevos riesgos que no deberían ser ignorados por las organizaciones. La enorme cantidad de información que podemos encontrar en la red, no sólo de las propias organizaciones, sino también de las personas que trabajan en ellas, puede ser utilizada para engañar o manipular a los empleados con el objetivo de acceder a información confidencial u obtener otro tipo de beneficios de manera ilícita.

Este tipo de ataques, conocidos habitualmente como ataques de ingeniería social, aprovechan el eslabón más débil de la seguridad de cualquier sistema: las personas que lo operan. De este modo, pueden hacer uso del engaño y la manipulación de los empleados para lograr sus objetivos que pueden ir desde obtener información interna o confidencial hasta conseguir acceso a la red o los sistemas internos de la organización.

Según Kevin Mitnick, gurú de la ingeniería social, el éxito de este tipo de ataques se basa en las siguientes premisas:

• Todos queremos ayudar.
• El primer movimiento es siempre de confianza hacia el otro.
• No nos gusta decir “No”.
• A todos nos gusta que nos alaben.

Realmente es muy sencillo utilizar la información que encontramos en la red para potenciar la confianza a la que hace referencia la segunda premisa de Mitnick. Internet nos proporciona todo tipo de datos sobre las organizaciones y las personas que pueden ser aprovechadas por los atacantes para preparar y personalizar sus ataques.

Por ilustrar este tipo de ataques con un ejemplo, podemos imaginar que mediante el acceso a una red social como pueden ser Facebook, Linkedin o similares, podemos conseguir identificar a un usuario que cuente con la confianza de nuestra potencial víctima y ingeniárnosla para conseguir su dirección de correo electrónico. Con este simple dato, podríamos enviar un mail fraudulento haciéndonos pasar por el conocido de nuestra víctima, ya que modificar el remitente de un mail es una operación trivial. Además, podríamos personalizar y dar mayor realismo al mail gracias a la información que encontráramos sobre ambos en la propia red social, en blogs personales, o en cualquier otra fuente públicada en internet.

Son muchos los métodos de ingeniería social que utilizan los atacantes haciendo uso de nuestra información pública. No sólo se pueden valer del mail, sino que también pueden servirse de otros canales como el teléfono o incluso de la interacción directa, haciendo uso de los datos recabados para dar mayor veracidad al fraude o engaño perpetrado.

Uno de los sectores especialmente vulnerables ante el uso de técnicas de ingeniería social, es el de los servicios de atención al cliente, o call center, que generalmente poseen información confidencial de la empresa o de sus clientes, y cuyos miembros, debido a su relación continua con agentes externos a la organización pueden llegar a bajar la guardia ante llamadas malintencionadas o fraudulentas. Una de las técnicas más utilizadas para obtener información de este tipo de departamentos consiste en suplantar a algún usuario lícito de la organización para obtener información privada del mismo. Es en este segundo caso, cuando la información obtenida de Internet puede ser de gran utilidad para los atacantes a la hora de engañar al operador.

Igual que ocurre con el resto de ámbitos de seguridad de la información, la implicación y el impulso por parte del consejo de dirección, son vitales para que las iniciativas que pretendan aumentar el nivel de seguridad de las organizaciones ante ataques de ingeniería social lleguen a buen puerto. Para poder hacer frente de manera efectiva a este tipo de amenazas, es necesario definir y establecer políticas de seguridad que marquen las directrices a seguir en el trato con agentes externos a la organización. Además, estas políticas y procedimientos deberán ser adecuadamente divulgados para que puedan ser conocidos y tenidos en cuenta por todos los miembros de la organización.

Es importante señalar que, auditar de manera periódica la respuesta de nuestra organización ante ataques de ingeniería social como complemento a las auditorías más técnicas, es básico para poder obtener una visión global y fidedigna del nivel de seguridad de nuestra organización. 

Por otro lado, se debe tener presente que el medio más efectivo del que disponemos para protegernos de este tipo de ataques pasa por realizar acciones continuadas de concienciación y formación del personal, con el objetivo de evitar en lo posible que los empleados de la organización puedan caer en este tipo de fraudes o engaños.

En conclusión, la evolución y el crecimiento de Internet ha dotado a los atacantes maliciosos de una cantidad mucho mayor de información y herramientas con las que llevar a cabo su actividad. Las organizaciones deben ser conscientes de los riesgos existentes y actuar en consecuencia, anticipándose y preparándose para afrontar esas nuevas amenazas a las que están expuestas.

Ciber granitos de arena

Cuando oímos hablar de Ciberseguridad en infraestructuras o servicios críticos, es frecuente pensar que se trata de una materia muy compleja y totalmente ajena a nosotros. Sin embargo, esto no se totalmente cierto. Obviamente, se trata de una disciplina compleja debido al continuo avance de las tecnologías de la información, así como al efecto globalizador y “anonimizador” que supone Internet. Pero esto no quiere decir que nos sea ajena. Todo lo contrario, como veremos a continuación.

En la actualidad la gran mayoría de servicios que utilizamos día a día requieren directa o indirectamente de los sistemas de información. La emisora de radio que nos despierta por la mañana, la empresa distribuidora que lleva nuestra marca de café preferida al supermercado de nuestro barrio, la empresa municipal que gestiona los semáforos o el sistema de transporte público de nuestra ciudad, o las grandes generadoras y distribuidoras eléctricas que producen y transportan la energía que necesitamos en nuestra casa y en nuestra oficina. Hoy día no es posible funcionar sin hacer un uso intensivo de sistemas de información.

Por lo tanto, al tratarse de servicios que dependen de los sistemas de información para su correcto funcionamiento, son servicios que tienen un cierto nivel de riesgo de verse afectados por un ciberataque. Riesgo que en caso de materializarse puede afectar directamente a nuestro día a día al quedarnos sin radio, suministros alimentarios o energía, entre otros muchos servicios que pueden verse afectados por un ciberataque. 

 Así pues, como vemos, la Ciberseguridad no nos es tan ajena como podríamos pensar. Más aún, todos tenemos parte de responsabilidad en mantener y mejorar la Ciberseguridad de nuestro país. Y no me refiero tan sólo a exigir a las autoridades y organizaciones que inviertan los recursos suficientes para proteger los servicios que nos prestan, sino también a cuidar la seguridad de nuestros propios sistemas de información.

¿Y qué tendrán que ver nuestros ordenadores, tablets o Smartphones con la seguridad de las Infraestructuras y los servicios críticos? Pues más de lo que en un primer momento podríamos imaginar.

Una de las principales amenazas que afectan a los sistemas de información de las organizaciones, son los ataques distribuidos de Denegación de Servicio (DDoS en inglés). Este tipo de ataques consisten en inundar los equipos de la organización objetivo del ataque con tal cantidad de peticiones que no sean capaces de procesarlas y acaben bloqueándose. Por ejemplo, imaginemos la página web de un banco en la que se ofrecen servicios de banca on-line y que está preparada para dar servicio hasta a 100.000 usuarios concurrentes. Si un atacante consigue que se realicen peticiones por parte de, por ejemplo, 10 millones de usuarios a un mismo tiempo, sin duda la página web del banco no será capaz de procesar todas las peticiones y acabará bloqueándose.

Sin embargo, un atacante no se comprará 10 millones de ordenadores para perpetrar este tipo de ataque, si no que utilizará una botnet, o lo que es lo mismo, una red de ordenadores ‘zombies’. Este tipo de redes, se componen de ordenadores personales que han sido infectados por un programa malicioso y que pueden ser utilizados para, entre otras funciones, colaborar en este tipo de ataques sin que el propietario de la máquina sea consciente de ello.

Por tanto, cuando tenemos nuestro ordenador de casa infectado, podemos estar siendo cómplices involuntarios de ciberataques u otros tipos de delitos telemáticos.

Así pues, todos podemos colaborar en aumentar la seguridad de los servicios e infraestructuras críticas de una manera sencilla, tomando una serie de medidas de seguridad básicas en nuestros propios ordenadores para evitar que pasen a formar parte de una de estas redes zombis. A continuación, enumeraremos algunas de estas medidas sencillas que podemos adoptar para mejorar la seguridad de nuestros equipos:

1. Mantén siempre tu sistema operativo actualizado.
2. Mantén siempre tu navegador web actualizado.
3. Instala y mantén actualizado un programa antivirus en tu equipo.
4. Evita acceder a enlaces o páginas no confiables.
5. Nunca descargues ni ejecutes archivos desde páginas no confiables.
6. No descargues ni abras adjuntos sospechosos en correos electrónicos.
7. Evita conectar tus lápices USB en ordenadores no confiables.
8. Toma, al menos, las mismas precauciones en la red que tomarías en el mundo real.
9. Usa tu sentido común también en Internet.
10. No dejes de visitar blogs relacionados con la ciberseguridad :)

ISO27001 vs ISO27002

Es muy frecuente que todo aquel que se interesa por primera vez en la serie ISO 27000, se encuentre con algún problema al delimitar y entender las fronteras y los ámbitos de las dos principales normas que la componen.

El primer concepto que debemos tener claro para aclarar nuestras dudas, es el de SGSI. Un Sistema de Gestión de la seguridad de la Información (SGSI) consiste en un conjunto de políticas y procedimientos que normalizan la gestión de la seguridad de la información, bien de toda una organización, bien de uno o varios de sus procesos de negocio. Es importante tener siempre en mente que por seguridad de la información se entiende el triple vector de confidencialidad, integridad y disponibilidad de la misma. Un SGSI debe abordar de forma integral estas tres vertientes de la seguridad de la información.

Existen diversos estándares, marcos de trabajo o metodologías para implantar y mantener un SGSI, pero sin duda la más socorrida es la serie ISO 27000. Este estándar internacional comprende todo un conjunto de normas relacionadas con la seguridad de la información, de entre las que destacan la ISO 27001 y la ISO 27002.

Y según mi experiencia, aquí es donde empieza el lío para aquellos que se enfrentan por primera vez a este estándar. ¿Qué diferencias hay entre ambas o cómo se relacionan entre sí?

En primer lugar, la ISO 27001 establece el marco de trabajo para definir un SGSI centrándose en la visión de la gestión de la seguridad como un proceso continuo en el tiempo. Para certificar un proceso u organización es necesario analizar y gestionar los riesgos fundamentales a los que están expuestos.

Una vez se han identificado estos riesgos, se hará necesario establecer la estrategia a seguir para cada uno de ellos. En este sentido, las diferentes alternativas que tenemos para cada riesgo son:

• Evitar el riesgo, abandonando el proceso o actividad que lo genera cuando el riesgo excede a los beneficios que nos aporta.
• Traspasar el riesgo a terceros, por ejemplo, mediante cláusulas contractuales o pólizas de seguros.
• Gestionar el riesgo, estableciendo contra-medidas que mitiguen o limiten el riesgo, reduciendo la probabilidad de que se materialice y/o las consecuencias que de este se puedan derivar.
• Asumir el riesgo, aceptándolo cuando el establecimiento de las contra-medidas supere en coste al que pueda suponer la materialización del propio riesgo.

Otro aspecto básico de la ISO 27001 es la gestión de la Seguridad de la Información mediante procesos basados en el método de mejora continua PDCA (Plan, Do, Check, Act), también conocido como círculo de Deming.

Este método establece un procedimiento cíclico mediante el cual se definen las medidas y controles de seguridad a implantar (Plan), se procede a su implantación (Do), se verifica y evalúa el éxito de los controles implantados para detectar errores o áreas de mejora (Check) y finalmente se modifican dichas medidas y controles en base a las desviaciones detectadas en el paso anterior (Act).

Por otro lado, la ISO 27002 consiste en una guía de buenas prácticas que permite a las organizaciones mejorar la seguridad de su información. Con este objetivo, define una serie de objetivos de seguridad que deberían ser perseguidos por las organizaciones distribuidos en diferentes dominios que abarcan de una forma integral todos los aspectos que han de ser tenidos en cuenta por las organizaciones.

Estos dominios que estructura la ISO 27002 son:

• La política de seguridad
• Los aspectos organizativos de la seguridad de la información
• La gestión de activos
• La seguridad ligada a los recursos humanos
• La seguridad física y ambiental
• La gestión de las comunicaciones y las operaciones
• Los controles de acceso a la información
• La adquisición, desarrollo y mantenimiento de los sistemas de información
• La gestión de incidentes en la seguridad de la información
• La gestión de la continuidad del negocio
• Los aspectos de cumplimiento legal y normativo

Se debe señalar que la única norma a certificar de la serie es la ISO 27001. No así la ISO 27002 que como hemos comentado tan sólo establece una serie de recomendaciones y buenas prácticas.

También hay que tener presente que para lograr la certificación en ISO 27001 no es necesario implantar todos los controles recomendados por la ISO 27002, si no que la organización debe priorizar y seleccionar aquellos controles que se alineen con su estrategia de riesgo, teniendo en cuenta la capacidad presupuestaria de la organización y sus necesidades de negocio.

Por último, creo importante el recordar las principales ventajas que una certificación como la ISO 27001 puede aportar a las organizaciones que decidan abordarla:

• Establece un marco de gestión de la seguridad consistente e internacionalmente reconocido.
• Se garantizan los controles internos, los controles de requisitos de gestión corporativa y de continuidad de la actividad de negocio.
• Se demuestra el cumplimiento de leyes y normativas que apliquen a la organización.
• Ofrece interesantes ventajas competitivas al mostrar a los clientes que la seguridad de su información es primordial, promoviendo a su vez la confianza en las relaciones con terceros.
• Reduce los riesgos de seguridad de la información estableciendo un marco de gestión de la seguridad y sus riesgos.
• Demuestra el compromiso de la cúpula directiva de la organización con la seguridad de la información.

La multiplicación de los PANes y los PCs

A estas alturas deben ser ya pocos los profesionales del mundo IT que no hayan oído hablar, para bien o para mal, del estándar PCI DSS. Para los pocos despistados que aún no sepan de qué se trata, el estándar PCI DSS (Payment Card Industry Data Security Standard) tiene como principal objetivo mejorar la seguridad de los datos de titulares de tarjeta de pago y está suscrito y patrocinado por las principales marcas de este tipo de tarjetas (Visa, Mastercard, 4B, Amex, etc.). 

Existe así mismo el PCI Security Santards Council, foro creado en 2006 con la responsabilidad de elaborar, gestionar, educar y sensibilizar en los estándares de seguridad de PCI.

Implantar este estándar en los sistemas de una Organización, ya sea un comercio, un banco o un procesador de pagos, es un proyecto complejo. Y es que uno de los principales problemas con el que se topan las Organizaciones al plantearse el cumplimiento del estándar es la gran dispersión que suele darse en el almacenamiento y en el tratamiento de los datos de titulares de tarjeta. 

Al iniciarse un proceso de consultoría para la implantación del estándar PCI DSS se da un proceso curioso en el que invariablemente se descubren nuevas localizaciones en las que se almacenan los PANs¹, así como multitud de usuarios adicionales que acaban utilizando los datos de tarjeta respecto a los que en un inicio los responsables de seguridad de la organización tuvieran constancias. Este es el dudoso milagro al que debe su nombre la presente entrada; “la multiplicación de los PANes y los PCs.”

No obstante, no es necesario tirar la toalla antes de empezar, ya que por suerte disponemos de dos vías principales y complementarias que nos permiten reducir y limitar el alcance de los sistemas que deben cumplir estos requerimientos: la segmentación y la tokenización.

La tokenización consiste en utilizar tokens en lugar de los números de tarjeta de pago siempre que no sea necesario realizar el cobro. De esta manera, las aplicaciones que traten tokens en lugar de los números de tarjeta pueden dejarse fuera del alcance del estándar. El punto clave en este caso, es asegurar convenientemente todo el proceso de generación de tokens, así como el proceso que permite, dado un token determinado, recuperar el número de tarjeta de pago que tiene asociado. Este método nos permite además reducir en gran medida la cantidad de localizaciones en las que almacenamos datos de titulares de tarjeta, facilitándonos la protección de dicho almacenaje, así como el control en el acceso a este tipo de datos.

Por otro lado, la segmentación de red nos permite dejar fuera del alcance del estándar todos los servidores y dispositivos que no transmitan, procesen o almacenen datos de tarjeta y que no estén directamente conectados con equipos incluidos en el alcance. Para ello, hemos de separar estos servidores o dispositivos en segmentos de red o VLAN’s separadas de los que sí participan en el proceso de tratamiento de datos de titulares de tarjeta. Para que dicha segmentación sea válida y efectiva, es necesario que filtremos el tráfico entre los segmentos incluidos en el alcance y los segmentos que no lo están, ya sea mediante reglas de firewalls o mediante ACLs en los routers, de manera que únicamente permitamos el tráfico estrictamente necesario entre los segmentos, documentando y justificando dicha necesidad.

Vemos a continuación cuales son los objetivos de control y los requerimientos del estándar PCI DSS:

A. Desarrollar y mantener una red segura	1.Instalar y mantener una configuración de firewall para proteger los datos del titular de tarjeta
	2. No usar contraseñas de sistemas y otros parámetros de seguridad por defecto
B. Proteger los datos del titular de tarjeta	3. Proteger los datos almacenados del titular de la tarjeta
	4. Cifrar la transmisión de los datos del titular de la tarjeta en las redes públicas abiertas
C. Mantener un programa de administración de las vulnerabilidades	5. Utilizar y actualizar con regularidad software antivirus
	6. Desarrollar y mantener sistemas y aplicaciones seguras
D. Implementar medidas sólidas de control de acceso	7. Restringir el acceso a los datos del titular de la tarjeta según la necesidad de saber que tenga la empresa
	8. Asignar una ID exclusiva a cada persona que tenga acceso por cada sistema
	9. Restringir el acceso físico a los datos del titular de la tarjeta
E. Supervisar y evaluar las redes con regularidad	10. Rastrear y supervisar todos los accesos a los recursos de red y a los datos de los titulares de las tarjetas
	11. Probar con regularidad los sistemas y procesos de seguridad
F. Mantener una política de seguridad de la información	12. Mantener una política que aborde la seguridad de la información para todo el personal de la Organización

Cabe señalar que por reducido que acabe siendo el alcance de servidores y dispositivos, implantar el estándar seguirá sin ser tarea sencilla, ya que si analizamos en detalle los sub-requerimientos y procedimientos de test que incorporan los 12 requerimientos de PCI DSS, apreciamos enseguida que adecuar una organización para que cumpla las exigencias del estándar PCI DSS requiere llevar a cabo cambios profundos que incluyen tanto aspectos tecnológicos como organizativos o procedimentales.

Por tanto, es muy importante la labor de priorizar adecuadamente las tareas a abordar para lograr el cumplimiento y para ello el documento Prioritized_Approach_V2.0 publicado por el PCI Council es una excelente base. En este documento se agrupan los subrequerimientos del estándar en 6 hitos de cumplimiento, ordenados en función del grado de riesgo que mitiga su cumplimiento.

Así pues, los principales aspectos que debemos considerar a la hora de iniciar una adecuación al estándar son:

• Identificar correctamente todos los flujos de datos de titulares de tarjetas existentes en la organización, así como todas las ubicaciones en las que está siendo almacenado.
• Limitar el alcance lo máximo posible mediante segmentación de red o tokenización.
• Priorizar adecuadamente las acciones necesarias para la adecuación con objeto de conseguir una implantación ordenada, eficiente y orientada a la mitigación de los principales riesgos y a la consecución de ‘quick wins’.

1^ PAN: Primary Account Number (Número de la tarjeta de Pago)