Analytics

jueves, 26 de junio de 2014

Niveles, listas y certificados de cumplimiento PCI DSS: luces y sombras

Aunque PCI DSS es una de esas normas de las que todo el mundo habla cuando hace mención al cumplimiento legal o normativo, al igual que de la Protección de Datos, la LPIC, la ISO 27001 o de otras muchas, PCI DSS se lleva el premio a ser una de las normas sobre las que todavía hay más desconocimiento en algunos aspectos clave relacionados con las particularidades de su cumplimiento.

Si tuviéramos que describir PCI DSS la tarea sería sencilla: es una norma que recoge un conjunto de requerimientos de seguridad que deben cumplir todas las empresas que traten, transmitan o almacenen datos de tarjeta de pago. Eso es fácil. Pero si preguntamos: ¿Usted debe certificarse? ¿Usted está certificado? La empresa X, ¿está certificada? Entramos en el meollo de las grandes dudas. Intentemos resolver algunas....

•    PCI DSS no tiene grados de cumplimiento.
Como nos gusta decir a nosotros, es una norma binaria o en blanco y negro: o se cumple o no se cumple y cuando el cumplimiento sea parcial, según PCI DSS, la situación será de incumplimiento. PCI DSS no contempla grados de cumplimiento ni gamas de grises entre el blanco y el negro. Podrá decidirse asumir el riesgo de que existan grises, pero debe ser consciente que se estará asumiendo un riesgo. ¿Qué riesgo? El riesgo de que mienta a un tercero si dice que cumple y el riesgo de que en caso de un compromiso de datos de pago se confirme su cumplimiento parcial. El problema de esto es que se hubieran hecho esfuerzos no concluidos de adecuación que no sirvieran de nada en caso de compromiso.

•    PCI DSS no tiene niveles de cumplimiento.
Existe un error común en pensar que los niveles de clasificación de las empresas, definido por las marcas de tarjetas pero no por la propia norma, determinan la rigurosidad con la que se debe cumplir PCI DSS. Esta interpretación es errónea: estos niveles únicamente determinan los requerimientos de validación de cumplimiento, es decir, cómo comercios (con cuatro niveles) y proveedores de servicio (con dos niveles) demuestran que su cumplimiento es del 100%. Pero siempre deberemos tener en mente lo explicado en el punto anterior, no existirán grados de cumplimiento sea cual sea el requerimiento de validación que aplique sea la Auditoría On-Site de un QSA (para los niveles 1 de ambos tipos) o un Cuestionario de AutoEvaluación (Self Assessment Questionaire, SAQ) cumplimentado por uno mismo (para el resto de niveles). Si "creemos" que nuestro cumplimiento es menor por estar rellenando un SAQ siendo permisivos seguramente lo que suceda es que haya incumplimientos.

Dada esta situación es "común" escuchar frases como "yo me quedo en el nivel 2" o "no voy a ser nivel 1 todavía" considerando, por interpretaciones incorrectas de estos niveles, que uno elige el nivel donde "se queda" y que ese nivel reduce la complejidad del cumplimiento. Por desgracia, esto es un error. Obviamente, al auditor QSA se nos ve como alguien que revisará el cumplimiento con ojos críticos, aunque siempre pretendemos ser constructivos (por qué otra actitud no tendría sentido), pero siempre más críticos que cuando uno mismo ha de rellenar un Cuestionario de Auto-Evaluación.

Ser "flexible" es una cosa, ser "concesivo" es otra. La primera puede permitir "estirar" lo que la norma exige para alcanzar el cumplimiento con vías "imaginativas" pero dentro de lo que la norma permite, pero la segunda puede llevar a dar por bueno algo que no lo es. Es por ello que contar con un QSA que nos asesore en el proceso de adecuación y sepa aportar su visión y experiencia de otros casos es, cuanto menos, recomendable. Después, podremos decidir qué hacer con esas recomendaciones, siendo conscientes de la realidad sin dulcificaciones y con pragmatismo.

Situaciones en las que el cumplimiento hubiera sido resultado de excesiva concesión puede ofrecer una falsa sensación de tranquilidad. Pero como QSA debemos ser sinceros: en caso de incidente y de existir un compromiso de datos de pago, el incumplimiento desembocará en penalizaciones que pueden ser significativas que, aunque sujetas a la decisión unilateral de las marcas de tarjetas, pueden ser millonarias.

Que  no existan niveles de cumplimiento no quiere decir que no podamos llevar a cabo un alineamiento progresivo. En Internet Security Auditors planteamos Planes de Adecuación empleando modelos alineados con los programas “Safe Harbour” de VISA. Este modelo aporta dos beneficios:
  1. Identifica los incumplimientos que implican mayor riesgo para el negocio con el fin de abordar primero su implementación, reduciendo que amenazas con mayor impacto puedan materializarse en un compromiso de datos de pago.
  2. Emplea un modelo que, habiendo sido aceptado por las marcas de tarjetas, demuestra la diligencia debida por parte de la empresa y, alcanzado el cumplimiento de los controles hasta nivel 4 (de 6), permitiría reducir drásticamente las sanciones en caso de compromiso.

•    Todas las "certificaciones" PCI DSS no son "públicas".

Este es, sin duda, el punto más delicado (y oscuro y confuso y ....) alrededor de PCI DSS. VISA es la marca de tarjetas que mantiene de forma más rigurosa las listas de empresas proveedoras de servicios "certificadas" en el cumplimiento de PCI DSS. Aunque siendo estrictos deberíamos usar el término "auditadas" dado que el concepto de certificado "global" no está definido de forma unificada: un Auditor QSA puede emitir un certificado y este tendrá validez global pero sin que el informe de Auditoría sea revisado por las marcas este tendrá una validez particular y así debe reflejarse en el certificado.

En el caso de comercios no existe ninguna lista pública de empresas auditadas y éstos sólo recibirían petición de sus Informes de Auditoría (RoC, Report of Compliance) por parte de sus entidades adquirientes (o eso dice la teoría).

VISA y Mastercard, históricamente, mantienen unas listas en sus sitios web de Visa.com, VisaEurope.com y Mastercard.com de, únicamente, proveedores de servicio que hayan gestionado su proceso de alta directamente con ellos o a través de una entidad bancaria a la que den servicios de pago, que hayan pagado los correspondientes pagos para el alta y que hayan remitido la correspondiente información tras superar una Auditoría de Cumplimiento por parte de un QSA. Cuando VISA dé el visto bueno a ese informe y a ese alta, se pasará a estar en las listas de Proveedores de Servicio "Certificados" en el cumplimiento de PCI DSS "públicamente". Sin duda ese es el que podría considerarse "estatus summum" de cumplimiento o "Certificación" dado que tanto el QSA como un tercero (VISA y/o MC) han validado el cumplimiento.

El año 2007, Visa Europe empezó a anotar públicamente la proliferación de proveedores de servicio que no estaban dados de alta en sus listas de Visa.com y VisaEurope.com, básicamente, porque no eran proveedores de servicios de pago para entidades bancarias y estas no llegaban a tener relación con ellos dado que sus servicios los prestaban a los comercios clientes de las entidades. Eso conducía a que existiera un creciente volumen de empresas que trataban, transmitían y almacenaban datos de tarjeta en gran cantidad, que para las marcas, estaba fuera de su "control". Para intentar regular esto, Visa Europe creo una nueva lista o registro: VisaMerchantAgents.com. En este nuevo portal se pretende que todos los proveedores de servicio para comercios u otros proveedores de servicio, estuvieran "inventariados" (con su alta, pago de fees correspondiente -sin una fórmula o parámetros claros que determinen su importe y sólo con un máximo conocido y nada despreciable de 5000 euros-).
Esto deja claro que SÓLO los proveedores de servicio que quieran publicar su certificación podrán hacerlo, principalmente y dependiendo de su tipo de cliente (bancos o comercios/proveedores de servicios), en los sitios web de VISA y MC comentados antes.
Desde Internet Security Auditors tenemos experiencias en los procesos de alta y los problemas comunes de estos procesos por lo que, podemos asesorar a las empresas que deban registrarse según sea el listado que les corresponda.

Según lo explicado hasta ahora se generan varias cuestiones:
¿Qué sucede si un QSA hace una auditoría pero su cliente no tramita el alta en las listas porque no quiere hacerlo, no lo necesita o no se le ha informado de la existencia de éstas?
El QSA que haya realizado la Auditoría On-Site podrá emitir un certificado que claramente defina el ámbito de procesos auditados, fechas de validez y si ese certificado se ha emitido con o sin la revisión de alguna de las marcas de tarjetas.

¿El certificado de un QSA es válido globalmente?
Si el certificado incluye la información que hemos mencionado será válido dado que los QSA tenemos reconocimiento global -aunque sólo regiones de operación (Europa, LAC, África, Asia, USA, etc.)- y de todos nosotros se espera que hagamos las auditorías con la más alta profesionalidad según los requerimiento firmados con el PCI SSC en el momento de nuestra homologación y cuando el PCI SSC va regulando las condiciones de homologación como pasó a finales del año 2013.

¿Qué sucede con las entidades adquirientes y los comercios que hayan pasado auditorías?
Públicamente no podrá conocerse quienes han superado auditorías con un QSA, dado que no existen listas oficiales similares a las de proveedores de servicio. La razón, es desconocida y, tras el paso de los años, se ha demostrado como otro de los hándicaps que incentiven y favorezcan la transparencia del cumplimiento en todo el ecosistema PCI DSS.

Cualquier empresa, incluidas entidades financieras y comercios, pueden "presumir" de haber implantado y mantener sistemas de calidad según ISO 9001, o de seguridad como ISO 27001 con sellos oficiales de las entidades certificadoras. Porqué razón no existe un sello de PCI DSS Compliance oficial, registrado y regulado sigue sin ser comprensible. Hasta el momento, incluir el certificado emitido por el QSA sería la mejor herramienta para demostrar el cumplimiento a terceros.

¿Por qué el PCI SSC y las marcas de tarjetas (que sí tienen sellos para otros usos como 3D Secure, Verified by Visa o SecureCode) han permitido que prolifere en Internet un sello informal de "PCI DSS Compliance" que induce a la equivocación del usuario y siguen sin asumir este error y corregirlo?  Muchas empresas, que se esfuerzan para alcanzar el cumplimiento también se hacen esta pregunta.

Es de esperar que en un futuro se mejore el proceso de gestión de las certificaciones de cumplimiento de PCI DSS y que, como pasó con las aplicaciones de pago bajo PCI PA-DSS, se centralice su registro y revisión desde el PCI SSC. Los beneficiados, sin duda, serán los afectados por el cumplimiento de la norma, los Auditores QSA y los usuarios y clientes.

miércoles, 18 de junio de 2014

Crónica del VIII OWASP Spain Chapter Meeting

El pasado viernes 13 de Junio de 2014 tuvo lugar la  VIII OWASP Spain Chapter Meeting 2014, en El Campus Barcelona de la Salle. El evento reunió a unos 150 asistentes y albergó un total de ocho presentaciones de distinta índole.

El evento comenzó con una bienvenida por parte de Josep Maria Ribes, Director d’Enginyeria de La Salle Campus de Barcelona. Josep destacó la larga relación entre el capítulo español de OWASP y La Salle, mostrando su deseo firme de mantenerla. Posteriormente realizó un recorrido del centro en su apuesta por la seguridad, integrada en sus estudios de grado y máster.

Vicente Aguilera Díaz, OWASP Spain Chapter Leader, Socio y Director del Departamento de Auditoría de Internet Security Auditors, introdujo la jornada mostrando su agradecimiento a La Salle por acoger un año más el evento, así como agradeció la colaboración a los patrocinadores (Internet Security Auditors), a los ponentes y a los asistentes. Posteriormente realizó un recorrido del proyecto OWASP y del capítulo español, así como las formas de colaboración.

Ashar Javed, Research Assistant en la Ruhr University Bochum (Alemania) ofreció una práctica y detallada presentación con el título “On Breaking PHP-Based Cross-Site Scripting Protection Mechanisms In The Wild” donde destacó la relevancia en la actualidad de los ataques Cross-site Scripting (XSS) y el grado de extensión de los servicios web basados en PHP. Posteriormente justificó a través de varias noticias recientes sobre incidentes de seguridad (ataque DoS a twitter, etc.), las importantes consecuencias que pueden derivarse de este tipo de ataques.

El ponente consiguió hacer la presentación compresible para todo el público e introdujo el concepto básico del contexto (HTML, attribute, script, URL y style), relativo al tipo de elemento donde se refleja la entrada de un usuario en una aplicación web. Posteriormente describió la metodología desarrollada durante su investigación, para poder romper cada uno de los contextos y finalmente lograr la inyección de código.

Además, enumeró los errores más frecuentes que en la actualidad comenten los programadores, cuando intentan proteger sus aplicaciones contra ataques XSS. Entre ellos destacó: la definición de listas negras de palabras clave, la utilización de funciones de filtrado/saneamiento en los contextos equivocados, y la definición de expresiones regulares incompletas.

Finalmente, realizó diversas demostraciones de lo fácil que resulta evadir las protecciones establecidas por los programadores web de importantes organizaciones (India Times, Electronic Arts, etc.). Adicionalmente mostró los resultados de su estudio, en relación al análisis de seguridad de las principales funciones y frameworks más utilizados en la actualidad.   

Durante su ponencia, éste investigador propuso un reto XSS con una recompensa de 250$ para el primero que lograra resolverlo correctamente. Reto que 5 días más tarde seguía sin resolverse y la recompensa de la cual se vio incrementada en 300$ llegando a los 550$.

Pau Oliva Fora, Mobile Security Engineer de ViaForensics, empezó describiendo la estructura general de las aplicaciones Android en su presentación sobre “Reversing & Protecting Android Applications”. Posteriormente describió las diferentes formas de obtener estas aplicaciones exportándolas a la SD, a través de ADB, a través de APIs…), para posteriormente poder realizar análisis de ingeniería inversa (reversing)

Pau describió las diferentes formas de decompilar una aplicación Android a lenguajes de alto nivel como Smali y Java. También, enumeró las principales herramientas y distribuciones utilizadas para decompilar y analizar las aplicaciones (apktool, Procyon, Androguard/DAD, Santoku Linux, etc.)
Además, enumeró los errores más frecuentes que en la actualidad comenten los programadores de este tipo de aplicaciones. Entre ellos destacó: no cifrar los datos de la aplicación (para evitar que otras aplicaciones puedan acceder), no establecer conexiones seguras (tales como SSL) realizando pinning de certificados (evitar ataques MitM), no validar los datos de entrada (evitar ataques de inyección Sqlite, Path traversal, etc.) y no limpiar los datos sensibles almacenados en memoria volátil tras ser utilizados.

Finalmente, estableció un conjunto de recomendaciones para proteger correctamente estas aplicaciones: evaluar en primer lugar el nivel de riesgo de los datos (para posteriormente establecer las medidas de seguridad adecuadas), utilizar librerías de cifrado, establecer timeouts en las sesiones activas (para limpiar los datos de memoria volátil) y comprobar la firma del desarrollador. También, recomendó establecer otras medidas adicionales como la ofuscación de código, con el objetivo de dificultar el trabajo a los atacantes.    

Inicialmente, Frank Ruiz Arenas, Threat Intelligence Analyst de FoxIT, y Manu Quintans, Manager de Intelligence de Deloitte/Buguroo, en su presentación “50 Shades of Crimeware” destacaron la importancia de ser críticos con las noticias publicadas sobre el descubrimiento de nuevos malware utilizados por los cibercriminales. En ocasiones, estas no reflejan el descubrimiento de nuevos malware sino de nuevas versiones de malware conocidos, y reflejan más los intereses comerciales de algunas empresas de seguridad. Esto sucede debido a la necesidad de las empresas de ciberseguridad de descubrir malware para hacerse lugar en el mercado.

En segundo lugar, describieron la estructura actual de las organizaciones criminales categorizándolas en distintas capas (iniciados/novatos, semiprofesionales, profesionales y profesionales antiguos) estableciendo las diferencias entre ellas en función de: el tamaño de los grupos, la facilidad de incorporación de nuevos miembros, el grado de organización, la capacidad de industrialización de malware y los canales de comunicación utilizados (foros, infraestructura propia, etc.)

Posteriormente, enumeraron los principales cambios que se están produciendo en la actualidad en este tipo de organizaciones, derivados de: las detenciones de altos cargos, la proliferación de bloguers que publican perfiles de criminales y los insider researchers (que se infiltran y extraen información). A su vez, también destacaron las consecuencias de los leaks realizados por terceros, que en ocasiones pueden entorpecer y dificultar las investigaciones de los cuerpos policiales. Principalmente estos cambios consisten en que las organizaciones cada vez son más cerradas, resultando más difícil poder obtener información de ellas.

También, enumeraron las principales tendencias del cibercrimen: el malware para POS (venta de kits o en modalidad SaaS) para el robo de tarjetas, el malware móvil (troyanos bancarios que capturan los SMS de los bancos y los datos de la SD), el malware que utiliza las redes anónimas como TOR, y la minería de monedas virtuales.

Describieron los diferentes tipos de infraestructura de las botnets, así como las nuevas formas que están adquiriendo estas en la actualidad: conexión directa, mono proxy, doble proxy, fastflux, proxy fastflux, TOR, P2P, etc. Además, destacaron la existencia de los bulletproof hostings, que aseguran la disponibilidad del servicio, independientemente de la legalidad de las actividades derivadas de su uso.

Finalmente, realizaron una demostración del robo de datos de tarjetas, para su posterior clonado y uso en establecimientos comerciales. En la demostración utilizaron el troyano POS Soraya.  
Antonio González Castro, CISO de Pragsis Technologies, realizó una introducción al concepto de Big Data exponiendo el problema de procesar grandes cantidades de datos. Indicó que actualmente estas tecnologías son utilizadas por grandes empresas (Google, Facebook, NSA, etc.) en su interesante presentación bajo el título “Big Data y Seguridad, un matrimonia de futuro”.

Posteriormente, describió que una de las principales diferencias con respecto al modelo clásico de procesamiento de datos, es precisamente la ubicación donde se realiza, justo donde estos se encuentran. También presentó Hadoop, un framework de software que soporta aplicaciones distribuidas bajo una licencia libre y una de las tecnologías más utilizadas en la actualidad.
Antonio expuso que estas tecnologías presentan muchos problemas y retos de seguridad, ya que esta no se tuvo en cuenta en sus diseños. Destacó la no existencia de sistemas de autenticación y autorización, así como de cifrado de datos.

Expuso los beneficios de utilizar este tipo de tecnologías en el ámbito de la seguridad: la disponibilidad inmediata de gran cantidad de logs, la centralización de los eventos, la detección de incidentes y ataques, etc.

Para  finalizar su ponencia mostró una demo de Hadoop. En él se describió el proceso de importación y perfilado de datos, y el de definición de reglas, con el objetivo de obtener información útil a partir de los datos. Además, se presentó la capacidad de la aplicación para la generación de gráficas y estadísticas.  

Daniel García, Security Researcher and Pentester, miembro del Golismero Project y Navaja Negra Conference Organizer, se encargó, en la presentación con el título “GoLismero Project: A revolutionary security framework” de llevar a cabo una introducción a la herramienta, definiéndola como un escáner Open Source orientado a la web, pensada para la detección de vulnerabilidades, la realización de auditorías de seguridad y la minería de datos (metadatos). Posteriormente, realizó una descripción de sus características principales (multiplataforma y centrada en la facilidad de uso) e hizo un repaso de cada uno de sus componentes.

Junto con Raúl Requero, presentaron las principales novedades de la herramienta: los plugins (para el desarrollo funcionalidades no cubiertas por otras herramientas) y su nuevo IDE (integrado en el navegador), y la generación de informes de auditoría (autocontenidos, fácilmente editables y exportables).

Daniel también describió las líneas de trabajo futuro: la corrección de errores, la gestión dinámica de plugins, el funcionamiento en cualquier plataforma (incluidas las móviles) y, el funcionamiento en clúster y la cooperación entre múltiples instancias de la herramienta, con el objetivo de ser utilizadas conjuntamente como una única plataforma de auditoría.

Xavier Panadero Lleonart, Director de Operacions del Centre de Seguretat de la Informació de Catalunya (CESICAT) inició la ponencia sobre “Equipo de Respuesta a Incidentes del CESICAT” exponiendo la diferencia entre una incidencia (caída del rendimiento, etc.) y un incidente de seguridad. Después, expuso en qué consistía el proceso de categorización de un incidente, indicando que esta se realiza en función de la tipología del incidente, su criticidad (en función de la actividad del cliente) y su prioridad (en función de los recursos y tiempo disponible para su resolución).
También, destacó la necesidad de profundizar en las medidas necesarias para evitar que un incidente vuelva a suceder. Así como la limitación de investigación de los incidentes (no todos pueden ser investigados).

Posteriormente, describió la estructura general de los CERTs (basada en niveles y en el proceso de escalado de incidentes), su modelo documental (basado en políticas, normas, procedimientos e instrucciones) para trabajar de forma eficiente, y los servicios que ofrecen a organizaciones y ciudadanos (respuesta remota a incidentes, soporte in-situ, análisis de laboratorio, etc.). Además, destacó la estrecha colaboración entre CERTs a través de otras organizaciones (FIRST, ENISA, CSIRT.es, etc.) y el auge en la creación de estos equipos (actualmente 304 equipos con presencia en 66 países).

Xavier, realizó un repaso de las herramientas de soporte y de laboratorio utilizadas. Además, mostró con cifras la capacidad de gestión de incidentes del CESICAT, frente  al rápido crecimiento anual del número de incidentes de seguridad. También, indicó que las principales causas de los incidentes eran la obsolescencia del software y el despliegue de botnets por parte de organizaciones cibercriminales.
Finalmente, expuso detalladamente todo el proceso de investigación de un incidente de seguridad que involucraba a una pequeña cooperativa eléctrica, que disponía de un PLC conectado a Internet. Este PLC era vulnerable, otorgando al potencial atacante la capacidad de desconectar a sus clientes de la red eléctrica (ataque DoS).

Simon Roses Femerling, CEO & Fundador de Vulnex, situó la presentación “Tus binarios hablan, ¿escuchas?” en la fase de Verificación dentro del Ciclo de desarrollo seguro de software. Indicó la existencia en el mercado de diferentes marcos de desarrollo seguro como Microsoft SDL, etc.
Además, justificó la necesidad de invertir en el desarrollo seguro como una forma de ahorrar costes. Para ello, presentó el coste que supone la corrección de un error en cada una de las distintas fases de un proyecto de desarrollo de software, destacando que cuanto más tarde se detecta, se incurre en más costes para poder solucionarlo. También, indicó otros beneficios derivados del desarrollo seguro, como el aumento de la calidad del producto, que puede permitir comercializarlo a un precio superior, incrementando así el margen de beneficios.

Posteriormente, presentó la herramienta BinSecSweeper que su equipo está desarrollando. Esta herramienta permite realizar el análisis estático completo de binarios. Simon destacó su característica multiplataforma (manteniendo una experiencia uniforme), la capacidad de análisis masivo de binarios (todos los binarios de un S.O., etc.), su extensión a través de plugins (detección de packers, uso de funciones inseguras, etc.) y la generación de informes intuitivos. Entre sus posibles usos, destacó la posibilidad de verificar que un producto cumple unos criterios estandarizados, evaluar todo el software de una organización, y el análisis de malware.    

Inicialmente, Marc Rivero López, Security Researcher de Barcelona Digital, incidió en su presentación “Ecrime Team, What, Why, and How” en el hecho de que el dinero es la principal motivación del cibercrimen. Posteriormente, describió la evolución de estas organizaciones criminales, que en sus inicios consistían en pequeños grupos segregados que posteriormente se unieron para conjuntar diferentes nichos de mercado, hasta alcanzar el nivel de profesionalización que les caracteriza en la actualidad.

Posteriormente realizó un repaso de los principales malware utilizados por estas organizaciones (Stuxnet, Duqu, Flame, etc.) y de las  noticias relacionadas más recientes (operación Game Over Zeus). Marc, indicó que la principal vía para combatir estas organizaciones es a través de los CERT.
También, justificó la introducción de estas organizaciones en el sector móvil a causa de la implantación de medidas de autenticación de doble factor, que involucran a este tipo de dispositivos.
Además, describió como las infraestructuras de estas organizaciones han ido evolucionando para dificultar la detección de sus actividades (fastflux, doble fastflux, P2P, bulletproof servers, etc.). Así como la introducción de medidas de protección adicionales en sus infraestructuras, como el bloqueo de rangos de direcciones IP correspondientes a empresas del sector de la seguridad.

Finalmente, Marc expuso en base a su propia experiencia, la estructura que debe tener un equipo de ecrime completo. Este equipo debería estar formado por: auditores/pentesters, reversers (ingeniería inversa), analistas de malware y analistas de inteligencia. También, enumeró algunas de las herramientas imprescindibles para el equipo: cuckoo (sandbox, para el análisis de malware) y urlQuery.net (un servicio de análisis de malware web). 

En el cierre y despedida Vicente Aguilera agradeció a los ponentes, asistentes, colaboradores y esponsors su participación del que ha sido el evento del capítulo OWASP Spain más multitudinario de la historia y que, meeting tras meeting, reúne a más profesionales y amantes de la seguridad. Este evento ha sido el más internacional de los realizados hasta el momento tanto por los ponentes como por los asistentes, que han incluido personas de Europa y América. La Fundación OWASP, que mantiene alrededor de 200 capítulos en más de 100 países de todo el mundo, es sin duda, el referente mundial en eventos de este tipo y, desde Internet Security Auditors esperamos seguir colaborando con el capítulo español que tanto en Barcelona como en Madrid consigue superarse en cada encuentro.

Autores: Carlos Antonio Sans & Laura Blasco
Departamento de Consultoría.

martes, 10 de junio de 2014

Participamos en las Presentaciones asignatura "IT Security" de La Salle Campus

El pasado viernes 6 de junio, se celebró en La Salle Campus (Universitat Ramon Llull) de Barcelona, el evento para encontrar profesionales de ITSec en el que tuvimos el placer de participar por invitación de esta universidad, referente en el mundo de la Seguridad TIC desde hace años como promotora de Masters y Certificaciones de Seguridad y la inclusión de esta materia en sus Grados Técnicos.

El evento consistió en una rueda de entrevistas en la que participan alumnos de la asignatura 'Seguridad en las TIC' al acabar el curso. Las empresas y consultoras se sientan cada una en una mesa, creando un círculo, y los alumnos, en grupos de dos, tienen diez minutos para exponer su trabajo de curso a cada empresa. Vicente Aguilera, Director del Depto. de Auditoría, tuvo la oportunidad de conocer los talentos que quieren dedicarse al mundo de la Seguridad TIC.

La periodista de elMundo.es Mercè Molist, que ha participado desde hace más de diez años en eventos de mundo del hacking y ciberseguridad TIC por toda Europa, publicó el domingo 8 de junio un artículo para este periódico, la crónica de este interesante encuentro.

miércoles, 4 de junio de 2014

Volvemos a participar en uno de los grupos de especial interés de PCI SSC en 2014

Los Grupos de Especial Interés (Special Interest Groups - SIG's) son grupos de trabajo coordinados por el PCI SSC con el objetivo de encontrar soluciones y mejoras,  a las diferentes normas de PCI SCC, sobre aspectos específicos de determinado sector o industria así como aspectos tecnológicos no contemplados anteriormente.

El objetivo final de los SIG's es elaborar guías, recomendaciones, clarificaciones y mejoras en los diferentes estándares de PCI SSC. Este año 2014 el PCI SSC ha seleccionado únicamente dos grupos de trabajo de especial interés: Penetration Testing Guidance Security Awareness Program: Best Practices for Implementing a Formal Security Awareness Program. Como ya hicimos en 2013, colaborando en dos SIG's, Internet Security Auditors vuelve a colaborar este año 2014 con PCI SSC. En esta ocasión, Vicente Aguilera Díaz participará en el grupo de trabajo "Penetration Testing Guidance", aportando su experiencia y conocimientos en esta área.

El objetivo del grupo Penetration Testing Guidance es el de actualizar el actual documento "Information Supllement: Requirement 11.3 Penetration Testing" realizado en 2008, de forma que se incluyan los siguientes aspectos: Desarrollar buenas prácticas y recomendaciones para actividades de pentest Considerar pruebas en modo autenticado utilizando varios roles, de forma que se asegure que el acceso a los datos de tarjeta está restringido a los privilegios asignados al rol Desarrollar una guía para crear plantillas de informes Desarrollar las mejoras prácticas para verificar un informe de pentest Documentar casos de estudio ilustrativos La publicación de este documento actualizado, está prevista para finales de este año 2014.

Referencias: 
  • PCI SSC Special Interest Groups:  
https://www.pcisecuritystandards.org/get_involved/special_interest_groups.php
 
Information Supplement: 
  • Requirement 11.3 Penetration Testing 
https://www.pcisecuritystandards.org/pdfs/infosupp_11_3_penetration_testing.pdf