Internet Security Auditors organiza junto con la Cámara de Colombiana de Comercio Electrónico en unas jornadas sobre Protección de Datos

El próximo 13 de octubre se celebra en Bogotá una conferencia sobre Protección de Datos.

Internet Security Auditors tiene la oportunidad de colaborar en esta jornada junto con la Cámara de Colombiana de Comercio Electrónico. En el evento se tratarán diferentes temas, todos relacionados con la privacidad de los datos.

A continuación, el programa:
7:30 AM: Registro
8:00 - 9:00 AM: 'Aprendiendo de las Sanciones'.
9:00 - 9:45 AM: 'Habeas Data, más que una ley: la Seguridad TIC en la protección de datos'.
10:00 – 11:00 AM: 'Errores comunes en la identificación y declaración de BBDD en el RNBD.  Recomendaciones'.
11:15 AM: Cierre

Ponentes:
  • Esteban Jaramillo Aramburo
  • Daniel Fernández Bleda
  • Javier R. Amaya Madrid

Más información:
http://ccce.org.co/eventos/conferencia-sobre-proteccion-de-datos

Cambios en la versión 3.2 del SAQ A

Con la salida de la versión 3.2 del estándar PCI DSS, también se han actualizado los Self-Assessment Questionnaire (SAQ) asociados al mismo.

La mayoría de dichos cuestionarios solo han sido sometidos a pequeñas variaciones o ajustes, con el objetivo de reforzar las medidas de autenticación requeridas por los usuarios en dichos escenarios, proporcionar una mayor garantía a los comercios que externalizan parcialmente sus entornos de e-commerce, y simplificar los requerimientos de los comercios que utilizan soluciones de cifrado punto-a-punto certificadas por el PCI SSC (PCI P2PE).

No obstante, el SAQ que sin duda ha sufrido mayores cambios ha sido el SAQ A, con la inclusión de varios requerimientos del estándar PCI DSS que comentaremos a continuación.

Recordemos que dicho SAQ está orientado a entornos de pago con tarjeta no presenciales (e-commerce o entorno MOTO (mail-order/telephone-order)), que tienen todos sus procesos de pago externalizados a un proveedor, y que en ningún caso almacenan, procesan o transmiten datos de tarjeta en formato electrónico.

En el caso de que la externalización de los servicios de pago se dé en un e-commerce, y para que un comercio sea elegible para  rellenar un SAQ A, debe de realizarse una redirección web directa a la web del proveedor, o bien una entrada de datos de tarjeta en el entorno del proveedor a través de un iFrame, ya que si se envían formularios de entrada de datos de tarjeta creados en la web del comercio con POST, o bien se utilizan formularios dinámicos generados con JavaScripts, el comercio debería rellenar un SAQ A EP, más restrictivo que un SAQ A.

Así pues, vemos a continuación los nuevos requerimientos que afectan a la versión 3.2 del SAQ A:

Requerimientos 2.1.a y 2.1.b, que obligan a cambiar los parámetros por defecto de un sistema, y a eliminar los usuarios por defecto del mismo antes de su instalación en un entorno PCI DSS.


Requerimientos 8.1.1 y 8.1.3, que solicitan el uso de usuarios nominales y únicos para todos los accesos al entorno, así como un estricto control de la eliminación o desactivación de dichos usuarios cuando su propietario finalice su función de negocio en el entorno de cumplimiento.


Requerimientos 8.2 y 8.2.3, por los cuales debe habilitarse una autenticación de como mínimo un factor para todos los accesos al CDE (Cardholder Data Environment), así como implantarse una correcta política de contraseñas para dichos accesos, forzando el uso de contraseñas de como mínimo 7 caracteres de longitud y complejidad en su generación.


Requerimiento 8.5,  que prohíbe el uso de cuentas genéricas o compartidas para los usuarios existentes en el CDE, especialmente para fines administrativos.


Y finalmente, el Requerimiento 12.10.1,  que requiere la definición de un plan de respuesta a incidentes formal en la entidad, para identificar y responder de manera adecuada a los posibles eventos maliciosos ocurridos en el CDE.


Como hemos podido observar, los comercios afectados por el SAQ A deberán implantar a partir de ahora nuevos requerimientos relativos al estándar PCI DSS, cosa que sin duda les traerá más de un dolor de cabeza. No obstante, seguro que una vez sean integrados a su negocio, los nuevos requerimientos proporcionaran un nivel de seguridad mucho más elevado a su CDE, que es lo que persigue el ecosistema de estándares del PCI SSC.


Referencias
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf
https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-SAQ-A.pdf
https://blog.pcisecuritystandards.org/pci-dss-3.2-saqs
http://www.pcihispano.com/todo-lo-que-siempre-ha-querido-saber-acerca-de-los-saq-cuestionarios-de-auto-evaluacion/
www.visaeurope.com/media/pdf/processing%20e-commerce%20payments%20guide.pdf


Autor: Guillem Fàbregas - PCI QSA, PCIP, CISSP, CISA, CISM, CRISC, ISO 27001 L.A.
Departamento de Consultoría.

Vicente Aguilera vuelve a participar en el programa 8aldia

El pasado viernes, Vicente Aguilera participó nuevamente en el programa 8aldia de Josep Cuní para hablar sobre el robo de 500 millones de cuentas robadas a finales de 2014 a Yahoo y la repercusión que este ha tenido, como por ejemplo la duración del mismo.

Las primeras noticias del mismo se tuvieron en 2014 aunque no ha sido hasta ahora, pasados dos años, que se ha confirmado el alcance del robo de datos.

Para los que queráis ver la entrevista al completo:
http://www.8tv.cat/8aldia/programes/8-al-dia-23-de-setembre-del-2016/

Aprobación oficial del marco Privacy Shield



Finalmente, a fecha de 12 de Julio de 2016, la Comisión Europea y el Gobierno de los Estados Unidos ha aprobado Privacy Shield, un nuevo marco internacional que regula las transferencias de datos personales de ciudadanos de la Unión Europea entre compañías de Europa y los Estados Unidos. Dicho marco pasa a ser vigente desde el 1 de Agosto de este mismo año.

Esta aprobación llega con retraso, pretendiendo llenar el vacío legal existente con las transferencias de información entre ambos países, desde que el acuerdo Safe Harbor fuera anulado en octubre de 2015.

El contexto que llevó a la Comisión Europea a la elaboración del marco Privacy Shield y las características más destacadas del mismo fueron analizadas en detalle en anteriores entradas de este blog:

Privacy Shield, nuevo marco internacional de transferencia de datos
Primer borrador de Privacy Shield

Para ofrecer orientación a los grupos afectados con este nuevo marco, el gobierno de los Estados Unidos ha habilitado un portal público oficial, con la siguiente información útil:
  • Orientación a las empresas de los Estados Unidos que deseen adherirse al nuevo marco.
  • Orientación a las empresas de Europa que por sus actividades comerciales deseen hacer transferencias internacionales de datos personales de ciudadanos europeos a empresas de los Estados Unidos.
  • Orientación a los ciudadanos de la Unión Europea sobre los derechos de protección de sus datos personales en base a las características de este nuevo marco.
  • Orientación a las autoridades de protección de datos locales europeas (como por ejemplo la Agencia Española de Protección de Datos), sobre como adaptar sus regulaciones y normativas locales de cada país miembro a las necesidades de este marco de seguridad.
  • Listados oficiales de empresas de los Estados Unidos adheridas a dicho marco de protección de datos internacional.
Al igual que ya pasaba con el acuerdo internacional Safe Harbor, el marco Privacy Shield es de obligada aplicación para compañías de los Estados Unidos que deban llevar a cabo transferencias internacionales de datos personales de ciudadanos de la Unión Europea en sus actividades comerciales, y el programa de cumplimiento va a ser mantenido por el Departamento de Comercio de los Estados Unidos, concretamente por la agencia ITA (International Trade Administration).

Las compañías de los Estados Unidos que deseen adherirse a dicho marco, deberán registrase en el portal oficial indicado anteriormente, e iniciar un proceso de auto-certificación online, donde deberán demostrar su adecuación al mismo. Además, también deberán pagar unas tasas anuales al Departamento de Comercio de los Estados Unidos, que variarán en función del nivel de ingresos de la compañía afectada.

Referencias
http://europa.eu/rapid/press-release_IP-16-2461_en.htm
https://www.commerce.gov/news/secretary-speeches/2016/07/remarks-us-secretary-commerce-penny-pritzker-eu-us-privacy-shield
https://www.privacyshield.gov
http://blog.isecauditors.com/2016/02/privacy-shield-nuevo-marco-internacional-de-transferencia-datos.html
http://blog.isecauditors.com/2016/03/primer-borrador-de-privacy-shield.html



Autor: Guillem Fàbregas - PCI QSA, PCIP, CISSP, CISA, CISM, CRISC, ISO 27001 L.A.
Departamento de Consultoría.

Vicente Aguilera participará en Catosfera: “Punt de trobada de la Internet catalana”

Las Jornadas de la Catosfera son un ciclo de debates en profundidad sobre las novedades tecnológicas y del mundo de Internet organizadas por el Ayuntamiento de Girona y Tirabol Producciones. Esta nueva edición de la Catosfera se celebrará en Girona, en el Centro Cultural de La Mercè, que cuenta con una capacidad de 252 asistentes, durante los días 13, 14 y 15 de Octubre de 2016.

Vicente Aguilera participará como ponente en las charlas del día 15 hablando sobre redes sociales, los riesgos que afectan a nuestra privacidad, y su uso como parte de investigaciones OSINT.


Más información en:
www.catosfera.cat

Vicente Aguilera participará nuevamente como jurado en el Hackathon del CyberCamp 2016

INCIBE, el Instituto Nacional de Ciberseguridad de España, organiza la edición 2016 de CyberCamp, el gran evento de ciberseguridad que nació con el objetivo de reunir a los mejores talentos en materia de ciberseguridad. Este año, el evento se llevará a cabo del 1 al 4 de diciembre, en León.

Después del éxito del año pasado, el evento vuelve a repetir el Hackathon, donde distintos equipos competirán para desarrollar o mejorar herramientas de seguridad open-source.
Hackathon, es un encuentro presencial de desarrollo colaborativo de software (o hardware) en un corto periodo de tiempo.  Tendrá lugar durante 42 horas aproximadamente, distribuidas en los diferentes días asociados al evento CyberCamp 2016.

Vicente Aguilera ha sido invitado otro año más a formar parte del experto jurado del Hackathon, compuesto por 6 miembros.

Más información:
https://cybercamp.es/competiciones/hackathon

Los nuevos retos que nos trae PA DSS en la versión 3.2.

Siguiendo su ciclo de tres años, este año el PCI SSC se ha adelantado y ha publicado nueva versión de sus estándares más importantes como lo son el PCI DSS y el PA DSS, en ambos (la versión anterior era la 3.1) han publicado entre los meses de Abril y Mayo la nuevas versiones PCI DSS 3.2 y PA DSS 3.2. Pero, ¿qué nos trae de nuevo esta versión de la norma? Para aclarar esto, primero abarcaremos los cambios que nos trae esta nueva versión para luego revisar el detalle y poder identificar los retos que implica llegar al cumplimiento de las aplicaciones.

Para detallar cuales son los nuevos cambios que incorpora la norma y los retos que eso nos implica, es necesario entender los tipos de cambios que se presentaron en la nueva versión:
  • Aclaraciones: Explicaciones de la intención de los requerimientos.
  • Guías Adicionales: Explicaciones, definiciones o instrucciones que aumentan el entendimiento de la norma.
  • Requerimientos que evolucionan: Cambios a la norma que aseguran que el estar está actualizado a las nuevas amenazas y cambios en el mercado.
Dicho esto,  el PCI SSC hizo un cambio importante con respecto a las versiones anteriores en cuanto a la exigencia de migración de los protocolos SSL e implementaciones tempranas de TLS, a protocolos seguros. En esta nueva entrega, se otorga un plazo a las entidades de migrar hasta junio del 2018, sin embargo las aplicaciones que deseen tener el cumplimiento en PA DSS no deben usar o soportar estos protocolos inseguros dado que no son considerados criptografía fuerte tal como lo menciona la norma “…SSL e implementaciones tempranas de TLS no se consideran criptografía fuerte. Las Aplicaciones de pago no deben usar, o apoyar el uso de SSL e implementaciones tempranas de TLS. Las aplicaciones que utilizan o soportan TLS no deben permitir un retroceso a SSL…” .Inclusive PCI DSS v3.2. tiene un ANEXO A2 que abarca la exigencia de la migración. Esta migración es necesaria dado las diferentes vulnerabilidades encontradas en estos protocolos.

Por otro lado, la norma (PA DSS) tiene otros principales cambios que son importantes de remarcar:



Req
Cambio
Tipo
-
Se retiran ejemplos de protocolos fuertes
Aclaración
2.2
Remarca la necesidad de tener una justificación de negocio (business need) para mostrar PAN no enmascarado y ejemplos de enmascaramientos de PAN
Nuevo Requerimiento
2.3.a (procedimiento de test)
Cuando se requieran logs de depuración de la aplicación y estos contengan PAN, deben ser protegidos de acuerdo a lo requerido por PCI DSS, desactivados tan pronto como se finalizan las tareas de depuración y eliminados de forma segura una vez no se necesitan
Nuevo Requerimiento
5.1.7
La capacitación a los desarrolladores debe estar actualizada y realizarse anualmente
Aclaración
7.2.3
Instrucciones en la Guía de Implementación en cómo instalar los parches y actualizaciones en forma segura
Nuevo Requerimiento
8.3, 10.1
Aclaración del término autenticación por multi-factor.
Aclaración
Requerimiento  12
Requerimiento 12 cuenta con un nuevo nombre: Asegurar todos los accesos administrativos que no son por consola
Aclaración
12.2
Todos los accesos que no son por consola deben utilizar autenticación multi-factor
Nuevo Requerimiento
Apéndice  A
Actualizaciones al apéndice A (Resumen de contenido de la Guía de Implementación) teniendo en cuenta todos los cambios en la norma
Aclaración


En consecuencia, la norma nos plantea nuevos retos que deben ser adecuados para las solicitudes de certificación a partir del 31 de Agosto del 2016, fecha en la que el estándar PA DSS 3.1 deja de ser válido y entra en vigencia únicamente la versión 3.2. Por lo tanto, es necesario entender estos nuevos ajustes que fueron presentados, desglosando los cambios para entender mejor su implicación y qué tareas será necesario llevar a cabo para poder lograr su cumplimiento.

En la nueva versión se retiran los ejemplos de protocolos de seguridad o seguros. Los protocolos de seguridad son protocolos de red designados para asegurar las transmisiones de datos, por ejemplo, y no limitado a, TLS, IPSEC, SSH, HTTPS, etc. Se retiran los ejemplos debido a que no se tiene certeza lo que a un futuro sea un protocolo fuerte de cifrado, por lo tanto los fabricantes de software deben estar actualizados en cuanto a las vulnerabilidades de los protocolos utilizados o soportados por su aplicación y en caso de contar con alguno vulnerable, se debe realizar la migración a alguno si considerado como seguro. Para mantenerse el día en este tipo de noticias es recomendable estar  afiliados a boletines de noticias de seguridad como lo son el del US CERT (https://www.us-cert.gov/ncas/bulletins), AU CERT (https://www.auscert.org.au/render.html?cid=1), entre otros. Para aplicaciones que están en su primera solicitud de certificación es indispensable que en la valoración de riesgos de la aplicación (labor a realizar en el momento del diseño de la aplicación) se identifiquen estos tipos de requerimientos o dependencias para garantizar que la aplicación no use o soporte protocolos inseguros.

Por otro lado, la norma aclara en el requerimiento 2.2 que debe obligarse a tener autorización para visualizaciones del PAN (Primary Account Number, es decir el número de la tarjeta) completo, y el que no cuente con dicha autorización, debe verlo enmascarado. Se aclara que el PA QSA debe validar en las pantallas donde se muestra el PAN y validar como se configura la aplicación para poder garantizar que sólo las personas con la necesidad legítima de negocio pueden verlo completo. Esto implica que se debe definir un proceso para dicho fin y se debe poder configurar a nivel de aplicación qué usuarios pueden ver el PAN completo y cuales lo deben ver enmascarado, puede ser definiendo diferentes perfiles y requiriendo autorización para poder asociar el perfil con vista completa a los usuarios definidos. Así mismo, dicho procedimiento de cómo realizar esta labor debe estar documentado en la Guía de Implementación. Complementando eso, se define los requerimientos de enmascarado en donde se puede mostrar máximo los 6 primeros de la tarjeta (BIN – Bank Identification Number) y los cuatro últimos, especificando que si sólo se requieren los últimos 4 se pueden mostrar sin necesidad del BIN.

Así mismo, se complementó el procedimiento de test 2.3.a para incluir que sí está habilitada la depuración de la aplicación (por ejemplo para solución de problemas) y el PAN es incluido en los logs de depuración, estos log deben ser protegidos de acuerdo a lo mencionado por PCI DSS. Esto implicaría que estos logs deben almacenarse cifrados, deben ser protegidos para que no sean alterados y debe restringirse su consulta sólo al personal con la necesidad de conocer, deshabilitarse una vez se hayan solucionado todos los problemas y borrado seguro sobre todos los logs generados. Por tanto, se debe incluir en la guía de implementación una descripción del proceso de los pasos mencionados anteriormente y así mismo modificar las aplicaciones para que se cumpla con lo requerido para estos logs de depuración.

Otro cambio exigido por la nueva norma en el requerimiento 5.1.7, es que la capacitación a los desarrolladores referente a implementar seguridad en el ciclo de vida del desarrollo de software, codificación segura, revisión de código, manejo de información sensible en memoria, pruebas de seguridad y técnicas de valoración de riesgos a las aplicaciones se realicen anualmente y se encuentre actualizada a los nuevos retos, tecnologías, vulnerabilidades, amenazas, etc. que hay en el mercado. Estas capacitaciones pueden ser impartidas por personal interno capacitado o terceros,  en sitio o virtuales.

Otra aclaración que la norma implementó es sobre la autenticación utilizando diversos factores, donde se habla de multi-factor. En la autenticación existen diferentes tipos de factores los cuales son:
  • Algo que se sabe (p.e. usuario/contraseña, passphrase )
  • Algo que se es (p.e. huella digital)
  • Algo que se tiene (p.e. Token, Certificado digital, tarjeta de coordenadas)
En versiones anteriores, la norma daba como válida la autenticación de doble factor, en donde se debía utilizar dos factores para autenticaciones remotas, sin embargo en esta nueva versión, aclararon que la terminología correcta es “multi-factor” en donde es posible utilizar dos o más factores en el momento de autenticar conexiones remotas. Tema que también nos lleva a hablar sobre el nuevo requerimiento 12.2, el cual exige que todos los accesos administrativos que no sean por consola, deben ser mediante autenticación multi-factor. Por lo tanto las aplicaciones deben proveer este tipo de autenticaciones, como por ejemplo validar tokens, certificados digitales, tarjetas de coordenadas, etc. adicionalmente a la validación de usuario y contraseña o poder soportar de otras herramientas para estos tipos de autenticación.

Un nuevo requerimiento planteado en la norma es el 7.2.3. Este numeral requiere instrucciones sobre cómo instalar de forma segura los parches y/o actualizaciones. Para lo cual los fabricantes de software deben documentar las instrucciones en cómo se va a notificar a los clientes sobre parches y actualizaciones, cómo van a ser distribuidos de forma segura e instrucciones en cómo debe instalarse de manera segura para que no se pierda la integridad del código. Esto implica que se debe incluir en la Guía de Implementación pautas para este requerimiento y el reto principal es definir mecanismos y procedimientos para poder entregar las modificaciones en el código a los clientes sin que se impacte la seguridad del mismo.

Finalmente, se hacen aclaraciones en la norma como el cambio de nombre del requerimiento 12 para que refleje más la intención del requerimiento, el cual es el proteger las conexiones administrativas dado que se maneja información sensible (como credenciales de los administradores). Y, otras aclaraciones son sobre el Apéndice A (resumen del contenido de la guía de implementación) para reflejar los cambios en todos los requerimientos que cambiaron y que impactan la guía.

Como conclusión se puede observar que los cambios sobre la norma están orientados a proteger las comunicaciones entrantes y salientes de las aplicaciones, proteger la información sensible y estar al día con las amenazas emergentes y cambios en el mercado. Sin embargo, los cambios no son de gran impacto para aplicaciones ya certificadas o en proceso de certificación ya que la mayoría de los cambios son aclaraciones y los impactos nuevos, en su mayoría recaen sobre la guía de implementación. Por tanto, el reto y el mayor impacto afecta a la actualización de la guía de implementación y muy pocos cambios sobre el diseño y/o codificación de las aplicaciones.


Referencias


Autor: David A. González - PCI-QSA, PA-QSA, PCIP
Departamento de Consultoría.