Mostrando entradas con la etiqueta PCI-DSS. Mostrar todas las entradas
Mostrando entradas con la etiqueta PCI-DSS. Mostrar todas las entradas

23 de febrero de 2011

¡Luchamos contra el fraude!... a nuestra manera.

Como supongo que todos vosotros, de vez en cuando compro por internet, es cómodo, ágil, rápido y requiere de un esfuerzo físico cercano a 0. ¿Por qué no hacerlo?, además si eres un consumidor responsable que sigue los consejos básicos de seguridad y precaución, o no se, te gusta jugar a las 7 diferencias con páginas de phishing por que estás aburrido ya de darle a la granja del Facebook pues, mejor que mejor. Incluso si tu negocio está en Internet hay muchas guías básicas para decirte como tienes que proteger los datos de tus clientes, como cumplir con los requisitos de seguridad que las normativas internacionales exigen, por ejemplo esta guía de INTECO es de mucha utilidad, aunque los propios emisores de tarjetas de crédito / débito tienen sus propias guías también, más o menos la referencia es el Payment Standard Industry (PCI-DSS) del cual se publicó la versión 2.0 en Octubre del año pasado y que ya adelantamos por aquí.

En definitiva, Internet es algo bueno, cómodo, con la sensibilidad y responsabilidad conveniente con respecto a las distintas amenazas puede ser tan seguro como ir a la tienda física real. Entonces, ¿por qué los comercios lo vuelven inseguros?, lo mejor de todo es que lo hacen para cumplir con directrices que en teoría vienen impuestas por MasterCard, Visa, etc. Y nos plantan clausulas como las siguientes:

Para evitar fraudes con tarjetas que hayan sido captadas en establecimientos físicos, XXXXX puede solicitar documentación adicional que certifique la identidad del comprador.”

Es decir, que aparte de pedirte todos tus datos personales, los datos de tu tarjeta de crédito y número de seguridad, luego te solicitan más datos. Fue en una conocida casa de apuestas la primera vez que me ocurrió esto, no había problema para iniciarte en el mundo de la ludopatía, metías tus 30€, te daban otros 30 de bienvenida y a volverse rico. Sin embargo, oh sorpresa, te disponías a retirar tus cuantiosos beneficios y te lo prohibían bajo esta condición:

Debido a la política de MasterCard, ya no es posible realizar reintegros de fondos en una tarjeta MasterCard (crédito o débito) registrada fuera del Reino Unido. Como resultado, su tarjeta debe ser "validada" antes de que usted pueda realizar cualquier reintegro de sus ganancias mediante un sistema de pago alternativo tal como una transferencia bancaria. Esto se indica mediante S (validada) o N (no validada) debajo de su tarjeta. Su tarjeta se valida automáticamente después de su primer depósito, o manualmente si envía prueba de titularidad de la tarjeta.

¡Pardiez!, ¿Qué es esto?, cegado por mis múltiples ganancias accedí a lo que un señor amablemente me pidió por correo electrónico: DNI escaneado por las dos caras y Tarjeta escaneada (solo por delante).

No le di más importancia, paranoia de estos ingleses, vete tu a saber. Hace 1 mes sin embargo fue el fin de semana “SIN IVA” en múltiples establecimientos, la competencia hizo que algunos superaran ese 18% de descuento llegando incluso a ofrecer un 20% en primeras marcas de tecnología (ejem, apple). Cual es mi sorpresa cuando tras comprar un portátil y cargármelo en mi cuenta bancaria en escasas horas, 3 días más tarde, me piden “verificar mis datos” por correo electrónico. Esta fue mi respuesta, un poco en caliente y poco técnica como se ve:

Disculpen mi insistencia pero no veo sentido a que por un procedimiento de seguridad se solicite información para confirmar un pedido cuando ustedes ya lo han cobrado, supongamos que efectivamente estoy suplantando la identidad de una persona, ¿le van a devolver el dinero?. No quisiera poner en duda sus procedimientos pero es efectivamente la solicitud de esta información la que levanta sospechas sobre un presunto phising, scam, etc.

Les remitiré la información que solicitan pero por favor, revisen este procedimiento que en lugar de facilitar al cliente recibir el producto en su casa lo entorpece. Si hubiese venido especificado en la página web habría ido al local comercial de XXXXXX sin dudarlo o habría realizado mi compra en otro lugar.

A lo que me remitieron a la página de condiciones donde lo ponía bien grande y en negrita:

Pago con Tarjeta de Crédito :
Aceptamos el pago con las principales tarjetas de crédito (Visa, Mastercard, 4B, American Express). En el proceso de compra se le pedirá tres datos, Número de tarjeta, Fecha de caducidad y su número identificativo o CVC2. En determinados casos, y para evitar fraudes con tarjetas que hayan sido captadas en establecimientos físicos, XXXXX solicitará documentación adicional que certifique la identidad del comprador.”

Nada que objetar, como buen consumidor, no leo las clausulas (prometo mejorar). Ahora bien, como consultor de seguridad me irrita, ¿introduce este procedimiento más seguridad?, ¿genera nuevos riesgos?, la respuesta es SI a ambas preguntas. ¿Por qué?, por que estás enviando tus datos personales y tu información bancaria a través de un canal inseguro (Internet), con todo lo que ello supone y que no explicaré aquí. Ahora centrémonos en alguna de las cosas que estas compañías deben cumplir para gestionar, almacenar y tratar esos datos:

- L.O.P.D.

- PCI-DSS

La LOPD y en concreto su reglamento de medidas de seguridad dice en su artículo 104:

La transmisión de datos de carácter personal a través de redes públicas o redes inalámbricas de comunicaciones electrónicas se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros.

Lo que ocurre es que esto solo aplica a datos de nivel alto (lo que podríamos discutir largo y tendido, pero “es lo que hay”), así que con esto en principio cumplen ya que sería difícil sacar datos de salud, vida sexual, etc. de una casa de apuestas o de una tienda de informática. Eso si, en caso de hacer compras en un sex-shop, encargar un Corán en Amazon o meter todos los dias 200€ en la casa de apuestas podremos deducir algo de eso. Pero supongamos que la AEPD les da la razón en esto último, DNI y tarjeta de crédito, todo junto, son datos de nivel medio pues suponemos que entran dentro de los datos financieros que indica la LOPD, si nos ponemos quisquillosos quizás de nivel básico. Con todo ello seguiremos teniendo un artículo que indica dos requisitos de seguridad:

- Mecanismos que eviten el acceso a datos o recursos con derechos distintos de los autorizados.

- Concesión de permisos de acceso sólo por personal autorizado.

¿Se puede asegurar esto en datos enviados a través de líneas públicas?, NO.

Ahora nos vamos al PCI-DSS 2.0, un solo requisito nos hace falta:

"Encrypt sensitive traffic over public Networks."

Está claro que con este requisito se cumple cuando utilizas la aplicación de compra, normalmente y dependiendo de la tienda surgirá un pop-up (seguro) de una tercera aplicación que hará de pasarela entre tu banco y el de la tienda, si es 3D Secure te pedirán un password y fin de la historia. Si no lo es y para luchar contra el fraude te pedirán que confirmes los datos, pero no te ofrecerán un mecanismo seguro para hacerlo, bastaría con que en tu perfil de usuario de la tienda se disponga de la capacidad de cargar los ficheros de tus datos escaneados, sobre HTTP-S por ejemplo, autenticando que el servidor al que estamos escribiendo es quien dice ser. Pero no, se valen del robusto protocolo SMTP para pedirte que les mandes todo, ¿así se lucha contra el fraude?, ¿a consta de quien?

La mayor de mis críticas a este tipo de procedimientos de seguridad que hacen flaco favor a su nombre y a la seguridad del comercio electrónico, además bajo un dudoso cumplimiento de la legislación actual y los estándares de pago electrónico.

Salu2

16 de febrero de 2011

Controles de Seguridad en la nube.

¡Buenos días!, hoy os traigo un pequeño documento que puede ser las delicias de muchos consultores de seguridad. Seguramente en vuestra empresa también estén migrando “a la nube”, no precisamente por que la gente esté en la parra, sino que por que es una moda tecnológica con consabidos beneficios económicos y de rendimiento que no analizaré. El problema es como adecuar la seguridad de nuestros sistemas tradicionales a la nube, ¿cómo debo modificar mis controles de seguridad?, ¿Qué nuevos requisitos debo considerar?, bueno los análisis más simplistas dirán “todo es igual” solo que virtualizado, aplica los mismos controles que tenías antes, eso nos puede dejar medianamente satisfechos pero no es del todo cierto. Para que lo comprobéis os dejo este Excel que, aunque se queda a muy alto nivel, os puede ser de mucha utilidad. Os explico por qué:

Control DG-07

“Security mechanisms shall be implementd to prevente data leakage”.

Áreas de Implementación:

SaaS, IaaS, PaaS, Service Provider

  • COBIT à COBIT 4.1 DS 11.6
  • ISO/IEC 27001:2005 à A.10.6.2, A.12.5.4
  • NIST à NIST SP800-53 R3 AC-2, NIST SP800-53 R3 AC-3, NIST SP800-53 R3 AC-4, NIST SP800-53 R3 AC-6, NIST SP800-53 R3 AC-11, NIST SP800-53 R3 AU-13, NIST SP800-53 R3 PE-19, NIST SP800-53 R3 SC-28, NIST SP800-53 R3 SA-8, NIST SP800-53 R3 SI-7
  • PCI-DSS à PCI DSS v2.0 3.1, PCI DSS v2.0 3.1.1, PCI DSS v2.0 3.2, PCI DSS v2.0 9.9.1, PCI DSS v2.0 9.5, PCI DSS v2.0 9.6, PCI DSS v2.0 10.7

En la lista de 100 controles propuestos, mapeados con diferentes dominios (que no coinciden con los de la ISO 27000, aunque son parecidos), te indica donde es obligatorios que lo implantes si quieres cumplir a su vez con los controles del resto de normativas o estándares de referencia. Por tanto desde el punto de vista del Gobierno de la Información así como de garantizar el cumplimiento con las distintas auditorías este Excel que tan bien se ha trabajado la Cloud Security Alliance puede ser el maná.

Salu2

PD: No dejéis de ver otros documentos como la guía de la nube o las amenazas sobre esta (por ejemplo, que los chinos te bombardeen para sacarte el agua).

16 de agosto de 2010

Payment Card Industry Data Security Standard v2

Buenos días,

Para empezar la semana una de evolución normativa / regulatoria. En Octubre se va a publicar la siguiente versión del estándar de seguridad de la industria de pago con tarjeta (la del dinero de plástico, vamos), algunos cambios ya se han adelantado a alto nivel, los cuales os pego por aquí. Todo ello dentro de un ciclo de vida que se ha extendido de 2 a 3 años, más acorde con los criterios de madurez en el gobierno de la información actuales:

Requirement Impact

Reason for Change

Proposed Change

Category

PCI DSS Intro

Clarify Applicability of PCI DSS and cardholder data.

Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN.

Align language with PTS Secure Reading and Exchange of Data (SRED) module.

Clarification

Scope of Assessment

Ensure all locations of cardholder data are included in scope of PCI DSS assessments

Clarify that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment.

Additional Guidance

PCI DSS Intro and various requirements

Provide guidance on virtualization.

Expanded definition of system components to include virtual components.

Updated requirement 2.2.1 to clarify intent of “one primary function per server” and use of virtualization.

Additional Guidance

PCI DSS

Requirement 1

Further clarification of the DMZ.

Provide clarification on secure boundaries between internet and card holder data environment.

Clarification

PCI DSS

Requirement 3.2

Clarify applicability of PCI DSS to Issuers or Issuer Processors.

Recognize that Issuers have a legitimate business need to store Sensitive Authentication Data.

Clarification

PCI DSS

Requirement 3.6

Clarify key management processes.

Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge.

Clarification

PCI DSS

Requirement 6.2

Apply a risk based approach for addressing vulnerabilities.

Update requirement to allow vulnerabilities to be ranked and prioritized according to risk.

Evolving Requirement

PCI DSS

Requirement 6.5

Merge requirements to eliminate redundancy and Expand examples of secure coding standards to include more than OWASP.

Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications.

Include examples of additional secure coding standards, such as CWE and CERT.

Clarification

PCI DSS

Requirement 12.3.10

Clarify remote copy, move, and storage of CHD.

Update requirement to allow business justification for copy, move, and storage of CHD during remote access.

Clarification

PA DSS

General

Payment Applications on Hardware Terminals.

Provide further guidance on PA-DSS applicability to hardware terminals.

Additional Guidance

PA-DSS

Requirement 4.4

Payment applications should facilitate centralized logging.

Add sub-requirement for payment applications to support centralized logging, in alignment with PCI DSS requirement 10.5.3.

Evolving Requirement

PA-DSS

Requirements

10 & 11

Merge PA-DSS Requirements 10 and 11

Combine requirements 10 and 11 (remote update and access requirements) to remove redundancies.

Clarification


Esto se traducirá en Objetivos de Control, Controles y requisitos de seguridad. Hay cosas curiosas como no basarse solo en OWASP para los test de intrusión de aplicaciones web, gestión del ciclo de vida de claves criptográficas, mayor separación de capas y clara definición de las DMZ, etc.

Habrá que estar atentos en los próximos meses. Más información aquí.

5 de marzo de 2010

SSL Harden

En estos días donde parece que nada es seguro la tendencia es a cifrarlo todo, esto muchas veces no aplica solo a transferencias por redes inseguras (dice ser, Internet). Si no que también nos ocurre que comunicaciones por redes privadas como, una macrolan entre empresas, una conectividad intra-cpd, etc. requiere de ser cifrada. Con el uso cada vez menor de las VPN – IPSec que, por lo general, son consideradas menos seguras (hay quien diría que cómodas) que las VPN – SSL parece que la Secure Socket Layer se ha convertido en la panacea del cifrado para la transmisión de datos. Portales Web, conexiones a listeners de BBDD, redes privadas virtuales, etc. Nada más lejos de la realidad.

Hoy os presento una herramienta, SSL Harden que nos muestra todos los modos que SSL / TLS soporta, con los distintos algoritmos de intercambio de claves así como de cifrado simétrico soportados. Esta aplicación se basa en el paquete de SCHANNEL de Microsoft para detectar la forma en que implementa esta capa. Así podrá escanear un servidor y obtener toda la información sobre la configuración del servicio, detectando por ejemplo el soporte a Modolus 1, el cual si está activado hará que un servidor / cliente permita comunicaciones en las cuales la clave pública de RSA tiene exponente 1, estando la clave privada a 1 también. Esto es comunicaciones que parecen estar cifradas no lo son, van en claro.

Para escanear máquinas en el dominio necesitareis ser administrador del mismo, la aplicación si tiene los privilegios suficientes podrá configurar tu equipo editando las entradas de registro.

El SSL-Harden está en beta por lo que hay veces que se cuelga de forma absurda, aun así merece la pena echarle un ojo.

Salu2!

27 de octubre de 2009

Spider Windows


¡Hola!, Hoy os presento una herramienta interesante, todos conocemos spiders web que buscan y rastrean información valiéndose del motor de Google, Yahoo, Bing, etc. La herramienta de hoy hace algo similar pero en la máquina que le digamos, que puede ser local o estar en la misma red. Se llama Spider Windows y es muy sencilla:


Spider Windows buscará números de tarjeta de crédito, de teléfono, DNI, etc. en la partición o unidad que le indiques, esto incluirá por supuesto ficheros ocultos. Esta búsqueda es configurable permitiendo añadir los patrones que queramos:

Con los resultados que encuentre generará un fichero de log con el PATH de los ficheros que contienen información sensible, este será depositado en la ubicación elegida, si es un servidor externo lo enviará valiéndose del protocolo SYSLOG. ¡Es sorprendente las cosas que uno almacena en su equipo!, yo me he encontrado con números de teléfono que ni recordaba andaban por ahí. En un ambiente un poco más profesional esto nos puede valer por ejemplo para saber que información sensible tenemos en una máquina, para ayudarnos en el cumplimiento de PCI-DSS, LOPD, etc. Si hacemos una auditoría con los patrones apropiados encontraremos qué información está expuesta para un usuario no-administrador en un servidor (por ejemplo).

Hay una alternativa Linux que incluye funcionalidades forenses detectando archivos borrados también, está incluida dentro de la distribución de Helix y se llama Spider Linux. Habrá que tenerla en cuenta también en el análisis de incidentes.

Salu2