Enmascarar vs Truncar

En alguna ocasión, mientras llevaba a cabo una consultoría o una auditoría de PCI DSS, me he encontrado con personas que confundían truncar y enmascarar entendiéndolas como sinónimas. Si le echamos un ojo a las acepciones que da la RAE para ambos términos veremos que tienen significados diferentes:

truncar.

(Del lat. truncāre).

1. tr. Cortar una parte a algo.

2. tr. Dejar incompleto el sentido de lo que se escribe o lee, u omitir frases o pasajes de un texto.

3. tr. Interrumpir una acción o una obra, dejándola incompleta.

4. tr. Quitar a alguien las ilusiones o esperanzas. U. t. c. prnl.

5. tr. p. us. Cortar la cabeza al cuerpo del hombre o de un animal.

enmascarar.

1. tr. Cubrir el rostro con máscara. U. t. c. prnl.

2. tr. Encubrir, disfrazar. U. t. c. prnl.

Por mi parte, preferiría que me enmascararan a que me truncaran... :-)

En el contexto de datos informáticos, y más concretamente, en el de datos de titulares de tarjeta por lo que a PCI DSS se refiere, la diferencia entre truncar y enmascarar es relevante.

Usaremos el término enmascarar datos de tarjeta cuando, pese a almacenarlos en nuestra base de datos luego no lo mostramos entero, si no que encubrimos o disfrazamos una parte, normalmente utilizando un carácter alternativo como los asteríscos:

En nuesta base de datos tenemos almacenado el PAN (cifrado, por supuesto) 1234 5678 9101 1121 pero al visualizarlo o mostrarlo al usuario lo enmascaramos: 123456*****1121.

Por otro lado, hablaremos de truncar el dato cuando directamente descartemos la parte que no nos interesa y en nuestra base de datos guardemos únicamente una parte del mismo:

En nuestra base de datos directamente almacenamos 123456*****1121 no pudiendo recuperar por lo tanto el número de tarjeta completo.

Si analizamos que implicaciones tiene cada una de las dos opciones en PCI DSS, nos encontramos con que los datos enmascarados siguen estando afectados por el estándar PCI DSS en tanto seguimos almacenando el dato completo en nuestra base de datos. Sin embargo, nos permite cumplir el requerimiento 3.3 del estándar: "Oculte el PAN cuando aparezca (los primeros seis y los últimos cuatro dígitos es la cantidad máxima de dígitos que aparecerá)".

Por otro lado, el truncado de datos si se realiza de tal manera que no se mantienen más que los primeros 6 y los últimos 4 dígitos del número de la tarjeta, nos permite dejar fuera del alcance el almacenamiento, procesado o transmisión de estos datos puesto que ya no se consideran datos de titulares de tarjeta.

Por lo tanto, no se trata de términos sinónimos, y desde el punto de vista de la seguridad y del cumplimiento con PCI DSS siempre que sea posible, será preferible utilizar el truncado al enmascarado, en tanto que si no vamos a necesitar almacenar el dato completo por ningún motivo justificado, lo mejor es que directamente no lo guardemos para evitar el riesgo de un compromiso de los datos.

Actores en PCI DSS

El objetivo de esta entrada del blog es dar una (somera) visión sobre los diferentes actores y estándares que representan algún papel en la seguridad de los datos de titulares de tarjeta.

PCI DSS Council

Encontramos la definición de qué es el PCI Council en su propia web:

El PCI SSC (Payment Card Industry Security Standarads) es un foro mundial abierto creado en 2006 que desarrolla, mantiene y gestiona el estándar de seguridad PCI que incluye el DSS (Data Security Standard), el PA-DSS (Payment Application Data Security Standard) y el PTS (PIN Transaction Security).

Los estándares PCI DSS cubren todos los puntos, desde la entrada de datos de tarjeta en un sistema hasta como los datos son procesados através de aplicaciones de pago seguras. El Council busca proteger y educar a los actores de la industria (comercios, procesadores, instituciones financieras, y cualquier otra organización que almacene, procese o transmita datos de titulares de tarjeta en cualquier lugar del mundo.

Las empresas fundadoras de esta organización son American Express, Discover Financial Services, JCB International, MasterCard Worldwide y Visa, Inc. Estas empresas (conocidas como las marcas de tarjetas) han incorporado las PCI DSS como sus requerimientos técnicos dentro de sus programas de cumplimiento y seguridad. Cada miembro fundador reconoce además a los profesionales y las empresas (ASV y QSA) certificados por el PCI SSC como habilitadas para validar el cumplimiento de las normas PCI DSS, convirtiendo al Council en el centralizador de los estándares y servicios aprobados por las cinco marcas de pago.

Finalmente, cabe señalar que no está entre las atribuciones del Council validar el cumplimiento de las organizaciones con las PCI DSS ni el imponer ningún tipo de sanción por el no cumplimiento. Este tipo de acciones son responsabilidad de las marcas de pago y sus partners, nunca del PCI Council.

Adquirientes

Los adquirientes, son las entidades bancarias con las que tiene la relación contractual el comercio en el que hacemos el pago, y por lo tanto, la entidad que acabará haciendo el ingreso de la cantidad gastada en la cuenta del comercio.

Emisores

Los emisores, son las entidades bancarias que han emitido la tarjeta, es decir nuestro banco, caja o cooperativa de crédito que acabarán por cargarnos el importe de la compra realizada en nuestra cuenta corriente.

Comercios

El comercio es la entidad a la que le pagamos algún tipo de bien o servicio mediante nuestra tarjeta de crédito o débito.

Proveedores de Servicios

Proveedores de los comercios, los adquirientes o los emisores que prestan servicios que incluyen la transmisión, el almacenamiento, el procesado o la gestión de la seguridad de datos de titulares de tarjeta. Cabe señalar que para que una organización pueda cumplir con el estándar PCI DSS es condición sine qua non que sus proveedores de servicio hagan lo propio.

Veamos un ejemplo de proceso de pago para identificar que rol tiene cada uno de los actores participantes. Imaginemos que vamos con nuestra tarjeta de la Caja A, y pagamos nuestra cena en el restaurante X que trabaja con el banco B. En este ejemplo, tendremos los siguientes roles:

• Restaurante X: Comercio.
• Caja A: Emisor de la tarjeta.
• Banco B: Adquiriente de la tarjeta.

Hay que tener en cuenta que los roles de Emisor y adquiriente son intercambiables, o que incluso pueden recaer ambos en una misma entidad. Es decir, si vamos a pagar nuestra compra con una tarjeta del Banco B en un supermercado que trabaje con la Caja A, tendremos:

• Supermercado Y: Comercio.
• Caja A: Adquiriente de la tarjeta.
• Banco B: Emisor de la tarjeta.

Procesadores de pago

Se trata de un tipo particular de proveedor de servicio, ya que son las empresas que prestan en servicio de autorización del pago y su posterior regularización facilitando el intercambio de información entre el adquiriente y el emisor en cada pago. En el ejemplo anterior, habrá un procesador que se encargue de intercambiar la información entre la Caja A y el Banco B.

Auditores certificados (QSA)

Los auditores certificados como QSA son los únicos que están facultados para realizar auditorías on-site del estándar PCI DSS que permitan certificar el cumplimiento ante las marcas o las entidades bancarias (dependiendo de si se certifica un proveedor de servicios o un comercio). Cabe señalar que para que un auditor QSA pueda llevar a cabo su labor, no sólo debe haber obtenido la certificación, si no que su empresa debe estar también habilitada como empresa QSA por el PCI Council.

Empresa certificada como Aproved scanning Vendor (ASV)

Los ASV son organizaciones habilitadas por el Council para que pueden llevar a cabo escaneos de vulnerabilidades sobre los entornos publicados en Internet de los comercios o los proveedores de servicio para dar cumplimiento al requerimiento 11 del estándar PCI DSS.

Auditores certificados (PA-QSA)

Los fabricante de aplicaciones comerciales destinadas al procesado de pagos con tarjeta (por ejemplo aplicaciones de TPV) tienen la opción de certificarlas como PA-DSS. Esto permite que el comercio o proveedor de servicio que la utilice se ahorre el tener que cumplir algunos requerimientos del estándar (sobretodo temas de desarrollo seguro, auditoría del código, etc..) en lo que a dicha aplicación se refiere ya que han sido verificados y certificados por un auditor PA-QSA. Los auditores certificados como PA-QSA son los únicos facultados para certificar este tipo de aplicaciones a petición de los fabricantes, y tal y como ocurría con los auditores QSA, deben además pertenecer a una empresa certificada como QSA.

Investigadores Forenses PCI (PFI)

El programa de investigadores forenses PCI establece y mantiene las reglas y requerimientos que regulan la elegibilidad, selección y rendimiento de las compañías que pueden proveer servicios de investigación forense para garantizar que cumplen con los estándares de seguridad de PCI. Únicamente los profesionales certificados como PFI que pertenezcan a una empresa QSA pueden realizar las investigaciones forense que sean requeridas por las marcas o las entidades financieras como producto de un compromiso de datos de tarjeta.

Auditor de Seguridad Interna (ISA)

Los grandes comercios, los bancos adquirientes o los procesadores pueden estar interesados en el programa ISA, es decir, en disponer de sus propios auditores PCI DSS internos que les proporcionen especialización y aumenten la eficiencia en el cumplimiento con los estándares de seguridad. Estos auditores reciben formación y certificación del PCI DSS con objeto de mejorar el entendimiento del estándar por parte de la organización, facilitar las interacciones entre la organización y los QSA y mejorar la calidad y consistencia de las auto-evaluaciones realizadas por la organización.

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.