Descuento en la inscripción al curso CCFP

Internet Security Auditors lleva impartiendo cursos de la certificación CISSP desde el año 2006 y de las certificaciones de concentraciones CISSP-ISSAP, CISSP-ISSMP y CSSLP, incorporando este año la nueva certificación de investigación forense CCFP (Certified Cyber Forensics Professional).
Esta nueva certificación demuestra experiencia en técnicas y procedimientos forenses, procedimientos estándares y principios éticos y legales para asegurar una exacta, completa y fiable evidencia digital que sea admisible en un tribunal de justicia. También garantiza que su poseedor tiene la capacidad de aplicar técnicas forenses a otras disciplinas de la Seguridad de la Información, tales como el e-discovery, análisis de malware o la respuesta ante incidentes.

Las empresas requieren de profesionales CCFP que demuestren sus competencias y conocimientos a través de un organismo común a escala mundial que define estándares de conocimiento en la disciplina forense, así como los nuevos retos, como mobile forensics, cloud forensics, anti-forensics, etc. Es por eso que hemos llegado a un acuerdo con la Asociación de Peritos Judiciales Tecnológicos de Andalucía (APJT) para ofrecer un descuento del 10% a sus socios en las inscripciones al curso de CCFP, por que en tiempos de crisis, la formación es importante.

http://www.isecauditors.com/certified-cyber-forensics-professional

PRECIO NORMAL
Inscripción anticipada: 2.095 € (IVA no incluido).
Inscripción normal: 2.595 € (IVA no incluido).

PRECIO APJT
Inscripción anticipada (precio APJT +10% dto.): 1885.50€ (IVA no incluido).
Inscripción normal (precio APJT +10% dto.): 2335.50€ (IVA no incluido).

PCI Card Production ¿Seguirá el camino de la PCI DSS?

Remontándonos a los inicios del estándar PCI DSS, vemos que sus antepasados eran los programas de seguridad propios de cada una de las marcas involucradas en tarjetas de pago: Visa Card Information Security Program, MasterCard Site Data Protection, American Express Data Security Operating Policy, Discover Information and Compliance, y JCB Data Security Program. Dado que cada uno de los programas anteriores tenía unas metas y perseguía unos objetivos de seguridad parecidos, se conformó el PCI SSC (Payment Card Industry Security Standards Council), y en 2004 se creó la PCI DSS, que alineaba los programas de cada una de las 5 principales marcas de tarjetas en un solo estándar.

Desde su aparición, se ha necesitado asesores QSA (Qualified Security Assessors), validados por el mismo PCI SSC, para la realización de auditorías presenciales en las empresas implicadas. Las auditorías realizadas por los QSAs son reconocidas por las diferentes marcas de tarjetas de pago, por lo que como es lógico, una sola auditoría es suficiente para dicho estándar.

De forma similar, y ya entrando en la materia que nos ocupa, hasta hace poco cada una de las marcas de tarjetas de pago disponía de su propio programa de seguridad para empresas de producción de tarjetas de pago. Como muy bien explica el siguiente artículo:

http://www.pcihispano.com/una-vision-general-a-los-requerimientos-de-seguridad-para-la-produccion-de-tarjetas-de-pago/

Hasta hace pocos años las empresas que creaban y personalizaban tarjetas de pago debían cumplir con el estándar PCI DSS, que al estar orientada a comerciantes, no se acababa de adaptar a los requerimientos de estas empresas. En base a esta necesidad, se fueron añadiendo “parches” a la PCI DSS para intentar abarcar algunos de los aspectos concretos de dichas empresas personalizadoras, como se puede ver, por ejemplo, en la nota que añadieron en la PCI DSS 2.0:

Requerimiento 3.2 de PCI DSS: "… Nota: Es posible que los emisores de tarjetas y las empresas que respaldan los servicios de emisión almacenen datos confidenciales de autenticación si existe una justificación de negocio y los datos se almacenan de forma segura… "

A pesar de dichas modificaciones, tanto Visa como Mastercard disponían de su propio programa de seguridad al que debían adherirse las entidades afectadas. Estas marcas requerían que los productores de tarjetas efectuaran periódicamente auditorías conforme a sus programas específicos, y que se llevaran a cabo por auditores certificados por las propias marcas. Así pues, en ese momento los productores de tarjetas debían aplicar un mínimo de tres manuales para demostrar que sus medidas de seguridad en la gestión de los datos de tarjetas de pago eran correctas, además de pasar las tres auditorías correspondientes: PCI DSS, Visa y Mastercard.

Esta situación no tenía mucho sentido, ya que cada una de las tres normas perseguía unas metas y unos objetivos de seguridad similares, además de que, a pesar de los parches, la normativa PCI DSS no acababa de encajar con los requerimientos funcionales de una empresa productora de tarjetas de pago. Así pues, y a partir de estas necesidades, el PCI SSC lanzó en mayo de 2013 la PCI Card Production. Dicho estándar está conformado por dos documentos:
  • Card Production Logical Security Requirements v1.0
  • Card Production Physical Security Requirements v1.0
A partir de ese momento, tanto Visa como Mastercard confirmaron que adoptaban el nuevo estándar, que remplazaba los programas de seguridad propios que cada marca tenía establecido hasta la fecha.

No obstante, y debido a que no existe actualmente una certificación del PCI SSC para este tipo de estándar, ni una figura parecida al QSA, el cumplimiento del mismo sigue estando controlado por las diferentes marcas de tarjetas. Además, por el momento en Europa no hay un consenso entre Visa y Mastercard, por lo que cada una de las dos marcas efectúa su propia auditoría del estándar con sus propios auditores. Así pues, hemos pasado de los tres estándares o programas de seguridad requeridos para los productores de tarjetas a solo uno, pero sigue siendo necesario pasar dos auditorías para el mismo (Visa y Mastercard).

Esta situación sigue sin tener mucho sentido, ya que tenemos dos marcas de tarjetas de pago auditando un mismo estándar, cada uno por su parte, con los consiguientes gastos que esto supone para el cliente. Por hacer un símil,  en este escenario es como si pagamos a dos mecánicos diferentes para que hagan un chequeo de nuestro coche en base a las mismas pruebas de seguridad, y aunque es cierto que se gana algo más de confianza, no será la suficiente como para pagar dos veces por el mismo trabajo.

En Estados Unidos este problema se atenúa un poco ya que las dos marcas principales (Visa y Mastercard) se han puesto de acuerdo para auditar una sola vez el estándar. Eso sí, con sus propios auditores.

La pregunta a hacerse ahora por los productores de tarjetas es: ¿llegarán a existir unos asesores parecidos a los QSA con potestad por el PCI SSC para certificar la PCI Card Production? O en caso contrario, ¿se pondrán de acuerdo en Europa las dos principales marcas de tarjetas para efectuar una sola auditoría del estándar por su parte?

La lógica dice que sí, aunque sólo el tiempo lo dirá. De momento lo principal para este tipo de entidades es adecuarse correctamente al estándar PCI Card Production, por lo que contar con empresas como Internet Security Auditors, con amplia experiencia en este estándar, siempre es una garantía de buenos resultados.


Autor: Guillem Fábregas - PCIP
Departamento de Consultoría

Cumplimiento del requisito 10 de la norma PCI DSS en sistemas Solaris

En general, el tratamiento de los registros de auditoría en sistemas operativos de uso generalista, como pueden ser Windows o las distintas distribuciones de Linux, proporcionan cierto nivel de flexibilidad en cuanto a las opciones de auditoría. Habitualmente, es posible configurar estas opciones incluso al nivel de operaciones sobre un fichero o sobre las acciones de un usuario concreto.  Normalmente, de esta manera se consigue cumplir con los requerimientos exigidos por la norma PCI DSS respecto a la generación de registros de auditoría.

En el caso del sistema operativo Solaris el módulo de auditoría es distinto y, para cierto tipo de opciones, también menos flexible. Por ejemplo, no permite activar trazas específicas para las modificaciones realizadas sobre un fichero o directorio concreto. Este tipo de controles deberán recaer sobre otro tipo de software, como, por ejemplo, un sistema de monitorización de integridad de ficheros.

Sin embargo, en lo que respecta a otro tipo de acciones (como pueden ser los intentos de acceso a los sistemas o las acciones realizadas por usuarios privilegiados) cuya auditoría es obligatoria de cara a la norma, Solaris permite activar filtros en relación con el tipo de actividad a monitorizar y las acciones de usuarios concretos. Estos filtros podrán ser activados según clases predefinidas de Solaris mediante el uso de flags.

En el caso de las acciones a auditar de forma general en el sistema y realizadas por cualquier usuario, el fichero a editar es /etc/security/audit_control, según el formato mostrado en la siguiente imagen.
Auditoria con Solaris: /etc/security/audit_control


Para establecer criterios específicos para usuarios concretos, como pueden ser las acciones realizadas por usuarios privilegiados tal y como específica el punto 10.2.2, el fichero a editar es /etc/security/audit_user, con el formato de la imagen que se muestra a continuación:

Auditoría con Solaris: /etc/security/audit_user
Hay que aclarar que estos parámetros especificados sobre ciertos usuarios sobrescriben a los especificados en el fichero general audit_control para dichos usuarios.

Los flags con su correspondencia sobre las acciones que monitorizan están definidos en el fichero /etc/security/audit_class. En función del sistema y de las acciones a monitorizar, habrá que depurar qué flags son requeridos en nuestro módulo de auditoría, teniendo en cuenta como mínimo los tipos de registros a generar exigidos por la norma PCI DSS:
  • Todo acceso de personas a datos de titulares de tarjetas (Req. 10.2.1)
  • Todas las acciones realizadas por personas con privilegios de raíz o administrativos (Req. 10.2.2)
  • Acceso a todas las pistas de auditoría (Req. 10.2.3)
  • Intentos de acceso lógico no válidos (Req. 10.2.4)
  • Uso de mecanismos de identificación y autenticación (Req. 10.2 5)
  • Inicialización de los registros de auditoría de la aplicación (Req. 10.2.6)
  • Creación y eliminación de objetos en el nivel del sistema (Req. 10.2.7)
Mediante el siguiente comando se habilita la auditoría general de Solaris y se utilizan los parámetros especificados en los ficheros de auditoría (requisito 10.1):
/etc/security/bsmconv

Finalmente, el requisito 10.5.3 requiere el envío de los registros de auditoría a un servidor centralizado. El propósito de este envío es realizar una copia de seguridad de dichos registros, pero, adicionalmente, se debe poder utilizar esta información para la correlación de eventos y generación de alertas ante la aparición de incidentes de seguridad.  Solaris, por defecto, genera los registros de auditoría en un fichero binario que debe consultarse mediante el comando praudit y cuyo formato normalmente no será entendido por un correlador de eventos. Por este motivo, Solaris proporciona la opción de redirigir los registros de auditoría por syslog. Para habilitarlo hay que añadir en el fichero /etc/security/audit_control los parámetros que se muestran en la imagen, especificando los flags de las acciones cuyos registros de auditoría se desea redirigir:

Auditoría con Solaris: /etc/security/audit_control


Para completar el proceso habrá que crear una línea en el fichero /etc/syslog.conf (en el caso de que ser quiera tener los registros de auditoría en local):
audit.notice       /var/adm/auditlog

Y por último, reenviar esta información al servidor central añadiendo en este mismo fichero:
audit.notice       @central_server
Auditoria con Solaris
Para finalizar, el único punto donde puede resultar más difícil conseguir el cumplimiento con PCI DSS es en la depuración de los flags, que establecen qué acciones registrarán los módulos de auditoría. Se requiere un trabajo de conocimiento del sistema y de depuración de dichos flags para obtener únicamente la información deseada, puesto que el exceso de creación de registros de auditoría podría convertir la información obtenida en inmanejable y, por lo tanto, inútil.


Autor: Javier Lorrio - CISSP, CCSA, CCSE, CISA, PCIP
Departamento de Consultoría

Participamos en la mesa redonda de la NcN

En el marco de la No cON Name 2013, la organización ha querido invitar a un miembro del equipo, en este caso a Daniel Fernández, para participar en la mesa redonda que tendrá lugar el viernes a las 16:00.

La temática principal de la mesa redonda versará acerca de las noticias que se han difundido estas últimas semanas en relación a las filtraciones de Snowden sobre las capturas masivas de información de ciudadanos relevantes (y no tan relevantes), de cómo los Estados utilizan las herramientas a su alcance para controlar la actividad de los usuarios de las tecnologías y servicios de la comunicación e Internet, en algunos casos, como parece, superando las fronteras de la legalidad y las respectivas Constituciones.

Para favorecer el debate se enfrontarán ambos lados, con un enfoque de defensores y detractores de la vigilancia y control de la información y del uso del Big Data, de forma profesional pero desenfadada y en la que se contará con la moderación de Ruth Sala (Legalconsultors) y la participación Luis Ángel Fernández Hernana (lab_RSI),  Eduardo López-Román (ICAB) y Daniel Fernández Bleda (Internet Security Auditors).

Novedades PCI DSS v3.0 (Parte II): Mejores Prácticas hasta Julio de 2015

Siguiendo con la serie de artículos que analizan la nueva versión de PCI DSS, en esta segunda entrada del blog, se analizarán los nuevos requisitos añadidos que serán buenas prácticas hasta julio de 2015. Debido a las implicaciones que tiene la implantación de estos nuevos requisitos, el PCI SSC deja un año y medio a las empresas para implantarlos.

Estos nuevos requisitos los podemos agrupar en los siguientes apartados:
1. Nuevas vulnerabilidades a verificar en el desarrollo seguro de aplicaciones
Respecto al desarrollo seguro de aplicaciones, esta nueva versión añade dos vulnerabilidades nuevas a verificar antes de que el código pase a producción. La primera vulnerabilidad a verificar es el “manejo inseguro de datos sensibles en memoria”. Lo que se pretende es evitar que se produzcan robos de información por una mala gestión de los datos en memoria, pudiendo ser estos datos robados por diferentes canales, como, por ejemplo, si se accede a los datos en memoria debido a que éstos no se eliminan una vez ya no se utilizan (se libera el espacio en memoria pero el dato sigue estando en memoria), o se fuerza el error en memoria, recogiendo los datos volcados a fichero en disco.

Para proteger las aplicaciones de esta vulnerabilidad se recomienda no almacenar el dato en memoria si no es necesario (si no tenemos el dato, no nos lo pueden robar), borrar los datos una vez que no sean necesarios, o asociar el atributo “private” a estos datos en caso de utilizar programación orientada a objetos.

La segunda vulnerabilidad añadida es “pérdida de autenticación y gestión de sesiones”. Se debe verificar que las funciones relacionadas con la autenticación y gestión de sesiones se implantan correctamente para evitar que terceros puedan apropiarse de identificadores de sesión, contraseñas en claro, etc. con el objetivo de robar cuentas de usuarios.

Para evitar esta vulnerabilidad, algunas de las medidas que se recomiendan son almacenar las credenciales utilizando hash o cifrado, no mostrar los identificadores de sesión en la URL, forzar la caducidad de las sesiones, marcar los tokens de sesión (por ejemplo, cookies) como “seguro”, o enviar credenciales a través de conexiones TLS. En resumen, evitar la manipulación de los parámetros de sesión establecida.

2. Terminales punto de venta (TPV)
Posiblemente, los requisitos referentes a la seguridad física en TPVs atendidos o desatendidos serán de los que más impacto tengan en las organizaciones, y de los más costosos de implementar, en tiempo y recursos. Debido al creciente aumento de fraudes en dichos terminales, las organizaciones deben poner controles adicionales a los TPVs que permitan gestionarlos de forma segura. Se deberán inventariar todos los TPVs, incluyendo al menos la marca y modelo, la ubicación y el número de serie. Si no se sabe qué es lo que uno tiene, es complicado protegerlo.

Se deben establecer procedimientos para realizar revisiones periódicas de los TPVs, verificando que éstos no han sido manipulados, y no se han colocado skimmers u otro tipo de dispositivos que permitan capturar los datos de tarjeta.

Por último, se deberán desarrollar procedimientos para gestionar el mantenimiento de los TPVs. Es decir, se debe identificar a los proveedores que realizan el mantenimiento, evitando posibles ataques de ingeniería social, alertar a quien corresponda en caso de detectar comportamientos extraños de individuos alrededor del TPV o verificar que el reemplazo del TPV en su totalidad o alguna pieza ha sido autorizado previamente.

Además de establecer estos procedimientos, se deberán impartir formaciones a los empleados para que conozcan estos procedimientos, conozcan los posibles ataques que pueden sufrir los TPVs, y las situaciones en las que deben alertar a sus responsables.

3. Test de intrusión
Se debe desarrollar una metodología para la ejecución de tests de intrusión. Esta metodología, debe basarse en las buenas prácticas de la industria como por ejemplo, NIST SP800-115, Open Source Security Testing Methodology Manual (OSSTMM), OWASP (para aplicaciones web), etc., tener en cuenta todo el entorno de datos de tarjeta, validar la segmentación, revisar las vulnerabilidades que hayan aparecido en los últimos 12 meses, especificar el periodo de retención de los resultados de los tests de intrusión y las actividades derivadas del plan de remediación, y al menos verificar que los sistemas no son vulnerables a las vulnerabilidades que aparecen en apartado 6.5.x (inyecciones SQL, buffer overflow, etc.).

Aunque se mantiene que se debe hacer al menos una vez al año, o tras un cambio significativo, un test de intrusión interno y otro externo a nivel de aplicación y a nivel de red, sí se especifica que para este último se deben evaluar todos los componentes que soportan la red así como sus sistemas operativos.

4. Gestión de proveedores externos
Se exige más compromiso a los proveedores de servicio en el cumplimiento del estándar. Como vimos en el artículo anterior, las organizaciones deben identificar los requisitos cuyo cumplimiento depende de los proveedores, depende de la organización o depende de ambos. Los proveedores que procesen, transmitan o almacenen datos de tarjeta en nombre de la organización deben comprometerse con las organizaciones a cumplir con todos los requisitos PCI DSS que les afecten. Además de incluirse en el clausulado del contrato, la organización deberá auditar a sus proveedores para asegurar que el compromiso es efectivo.

En caso de que el proveedor haya certificado su servicio, éste deberá proporcionar evidencia de que eso es así, bien saliendo publicado en las listas de VISA y MasterCard en caso de pasar la auditoría, o bien entregando el SAQ relleno y firmado por el banco.

Y por último, se pretende aplicar la misma política de control de acceso de los usuarios internos a los proveedores  otorgando cuentas individuales a cualquier proveedor que acceda al entorno PCI DSS. El proveedor debe ser consciente de que está prohibido el uso de cuentas genéricas y compartidas, independientemente de que el acceso sea puntual o habitual. De esta manera se pretende “atar en corto” a los proveedores, y garantizar la imputabilidad a un individuo de todas las acciones que se ejecuten en el sistema.

Con estos requisitos el PCI SSC da una vuelta de tuerca (algunos dirán que dos o tres) al estándar, aumentando la seguridad del entorno no tanto en la parte técnica, sino en la parte administrativa y documental. Lo que se busca es aumentar la seguridad en la gestión de los controles, cerrando agujeros que, en función de la interpretación de las organizaciones y QSAs, podrían causar serios problemas de seguridad.


Autor: Carmen de Alba - CISA, CISM, PCI QSA, PA QSA
Departamento de Consultoría

Volvemos a patrocinar la No cON Name 2013 (#ncn2k13)

La No cON Name ( NcN ) es el congreso de seguridad informática y hacking más antiguo en España. Con una periodicidad anual reúne tanto a nuevas promesas del sector, expertos, así como a profesionales en el campo de la informática en general, redes telemáticas, programación o ingeniería de protección de software.

Un año más, volvemos a colaborar como sponsor en la No cON Name 2013 que se celebrará en Barcelona los días 1 y 2 de noviembre.

Recordad que los días 30 y 31 de octubre podéis disfrutar de talleres y formaciones.
A continuación os dejamos el programa:
1 de noviembre de 2013
  • 08:00 – Apertura
  • 09:30 - Inauguración X Edición
  • 10:00 -  Cloud Computing, Big Data, Smart Cities... ¿y las personas? Ruth Sala Ordoñez
  • 11:05 – Coffee Break
  • 11:35 - One FlAw Over the Cuckoo’s. Iñaki Rodríguez / Ricardo J. Rodríguez
  • 12:20 – La defensa de Chewbacca. Vicente Aceituno
  • 13:15 – Comida
  • 15:00 – Pinout & flashing a Nokia pone. Carlos Fouz
  • 16:00 - Mesa Redonda
  • 17:00 – Descanso
  • 17:15 – Securización de servicios con OAuth. Jordi Giménez
  • 18:15 - A journey into userland rootkits for Android. Sebastián Guerrero
2 de noviembre de 2013
  • 8:30 - Apertura
  • 9:00 – Tu PO**A through the NFC. Ricardo J. Rodríguez
  • 10:00 – Ofuscación y estenografía de binarios. David Guillén
  • 10:55 – Coffee Break
  • 11:35 - Mesa Redonda
  • 12:30 – Client-Side password encryption the 8oolb Gorilla is your sysadmin. Pedro Fortuny / Carlos Amieva
  • 13:15 - Comida
  • 15:00 - /*!Bypass Web Application Firewall*/. Omar Palomino
  • 16:05 -  Keep your sandbox for malware analysis unnoticed. Alberto Ortega
  • 17:00 – Descanso
  • 17:25 -  Defeating WhatsApp's Lack of Privacy. Jaime Sánchez / Pablo San Emeterio
  • 18:30 -  All your content providers are belong to me. Sebastián Guerrero
  • 19:00 - Ganadores CTF / CLAUSURA

Novedades PCI DSS v3.0 (Parte I)

El 7 de noviembre sale la versión 3.0 de PCI DSS. El PCI SSC ha empezado a distribuir los borradores de la norma entre los QSAs (Qualified Security Assessors) y he aquí las primeras conclusiones sobre el borrador. Esta nueva versión viene con una profunda revisión de todos los requisitos, derivada de la necesidad de ir evolucionando y perfeccionando la filosofía del estándar con el paso del tiempo, pero, en ningún caso, desdice o invalida requisitos de la versión anterior y la estructura de los 12 requerimientos sigue siendo la misma.

Aunque se han incluido varios requisitos (alrededor de 30 nuevos), se puede decir que la nueva versión requiere un esfuerzo extra por parte de las organizaciones en la parte documental. El PCI SSC da por hecho que la red se segmenta, que se recogen logs de todos los componentes, que los sistemas son bastionados, etc., pero la parte documental y procedimental no está correctamente desarrollado o implantado, y en este aspecto se centran la mayoría de los cambios y aclaraciones introducidos.

Analizando el borrador se puede decir que, en primer lugar, se han modificado un gran número de requisitos para eliminar ambigüedades en aquellos que permitían interpretaciones diferentes, tanto en QSAs como en el personal de las organizaciones. Y en segundo lugar, se han desarrollado nuevos requisitos que pretenden cubrir ciertas carencias que tiene la versión 2.0. De entre estos nuevos requisitos añadidos cabe destacar aquellos que, por el impacto que tiene su aplicación en el entorno PCI DSS, hasta junio de 2015 serán considerados como buenas prácticas y a partir de esta fecha serán requisitos de obligado cumplimiento.

En este primer artículo se analizan por requerimientos los nuevos requisitos más significativos, dejando para posteriores artículos los requisitos que son buenas prácticas hasta junio de 2015 y los requisitos modificados.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Respecto a los mapas de red detallados, se exige que en éstos aparezcan los flujos de datos de tarjeta a través de las redes y sistemas.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Para mantener un control estricto de todos los componentes del entorno, se requiere mantener actualizado un inventario de activos al nivel de hardware y de software. Este requisito está relacionado con el mapa de red. Con un inventario completo de los componentes y tecnologías del entorno PCI DSS, es más sencillo verificar que en el mapa de red se han tenido en cuenta todos los componentes del entorno sin inconsistencias.

Requirement 3: Protect stored cardholder data
En relación a la visualización de los datos de tarjeta en claro, se incluye un nuevo requisito que exige que todos los roles de las personas que accedan a los datos de tarjeta en claro deben estar identificados. Este nuevo requisito enlaza con los requisitos de control de acceso del requerimiento 7, obligando a las organizaciones a tener una relación entre aplicaciones, ficheros, logs, etc. que contienen datos de tarjeta, y los roles autorizados para cada uno de ellos.

Por lo tanto, deberá existir una “Matriz de Acceso al PAN Completo”, donde se justifique, para cada uno de los roles autorizados, la necesidad de acceder al dato en claro, y cualquier otro rol que no aparezca en esta matriz deberá ver los datos de tarjeta enmascarados.

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs.
Para aquellos equipos que no sean susceptibles de ser afectados por malware (mainframe, sistemas UNIX, etc.), se deberá realizar un análisis periódico, en el que se analicen si los riesgos actuales podrían afectar de algún modo  a dichos equipos. Esto implica que se deben revisar las publicaciones de los fabricantes de dichos equipos, las publicaciones de los fabricantes de antivirus, las publicaciones de seguridad de distintas organizaciones expertas en temas de seguridad, que permitan identificar si estos componentes corren el riesgo de verse afectados por cualquier tipo de malware.
Además, las organizaciones deberán tener en su repositorio documental las características de los antivirus activos en el entorno PCI DSS, en el que se pueda verificar que dichos antivirus protegen los componentes del entorno y detectan y eliminan todo tipo de software malicioso conocido.

Requirement 7: Restrict access to cardholder data by business need to know
Para cada uno de los componentes del entorno, se deben identificar los roles que necesitan acceso, así como los privilegios que tienen. Lo más recomendable es establecer una matriz de control de acceso. Este requisito viene a completar la gestión de accesos de los usuarios del entorno PCI DSS.

A pesar del trabajo adicional que implica documentar para cada componente del entorno, los roles y permisos asociados, este control permite tener una gestión eficaz y ordenada de los roles y usuarios.

Requirement 8: Identify and authenticate access to system components.
En esta nueva revisión se ha incluido la gestión de credenciales para el control de acceso físico. Por lo tanto, se deberá establecer un procedimiento de altas y bajas de los usuarios, en los que se tenga en cuenta que si a un empleado se le entrega una tarjeta inteligente, un token u otro dispositivo de autenticación, éste deberá ser devuelto en el momento en que el usuario cause baja en la empresa o cambie el puesto de trabajo.

También se especifica que, cualquier dispositivo físico de autenticación entregado a cualquier empleado, es de uso personal e intransferible, y que deberá verificarse que dichos dispositivos no son compartidos entre varios usuarios.

Requirement 9: Restrict physical access to cardholder data.
En la versión 2.0 se obligaba a controlar y gestionar los accesos físicos a CPDs de las visitas. A partir de ahora, también deberá gestionarse y controlarse los accesos físicos del personal interno y externo de la organización. Como todo lo relativo al control de acceso, los permisos de acceso deben basarse en función de su trabajo, y éstos deben ser revocados de manera inmediata cuando un empleado cause baja en la empresa o cambie de puesto de trabajo (y ya no sea necesario tener acceso a zonas específicas).

Respecto a la gestión de destrucción de soportes, la nueva versión puntualiza que, aquellos contenedores que almacenen información con datos sensibles, deberán securizarse asegurando que no podrán ser accesibles por personal no autorizado.

Requirement 10: Track and monitor all access to network resources and cardholder data.
Tanto para las alertas generadas por la plataforma de centralización y correlación de logs como para las alertas generadas por la aplicación de monitorización de archivos críticos, se debe establecer un proceso de revisión y gestión de alertas. Es decir, debe haber unos procedimientos documentados que permitan gestionar el ciclo de vida de las alertas, desde el momento en que un operador las detecta hasta que éstas se cierran.

Requirement 11: Regularly test security systems and processes.
A los tests de intrusión se le añade una nueva funcionalidad: verificar de forma global, que la segmentación es efectiva y los controles implantados están operativos y funcionan de acuerdo a lo establecido, aislando los componentes dentro del entorno de otras redes y componentes no confiables.

Requirement 12: Maintain a policy that addresses information security for all personnel.
Respecto a la gestión de proveedores, para cada servicio prestado por los proveedores, se deberán mapear los requisitos que son responsabilidad del proveedor de servicios, los requisitos que son responsabilidad de la organización, y los requisitos cuya responsabilidad sea compartida por el proveedor de servicios y la organización.

Por último, cabe destacar que el requisito 12.2 (“Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures)”) de la norma ha sido eliminado, y en su lugar, al final de cada requerimiento, se ha incluido un requisito que exige documentar y distribuir a todos los empleados internos y externos las políticas, los procedimientos, las instrucciones de trabajo, etc. para que puedan operar de acuerdo a éstos.


Autor: Carmen de Alba - CISA, CISM, PCI QSA, PA QSA
Departamento de Consultoría

BYOD: Bring your Own Device (parte I)

BYOD (Bring Your Own Device)

¿Qué es el BYOD?

“El BYOD (Bring Your Own Device) es una política empresarial en donde los empleados llevan sus propios dispositivos a su lugar de trabajo para tener acceso a recursos de la empresa tales como correos electrónicos, bases de datos y archivos en servidores así como datos y aplicaciones personales.”

En entornos corporativos esta política se conoce desde hace ya tiempo.  Se calcula que en Estados Unidos más del 70% de las compañías dan soporte a programas de BYOD de algún tipo.
Actualmente, con la evolución que está sufriendo la tecnología, este fenómeno ha aumentado y cada vez es más difícil pedir a los trabajadores que se hagan un downgrade  tecnológico cuando llegan a su puesto de trabajo.

Problemática

El BYOD está produciendo grandes cambios en las organizaciones y los negocios, creando dos tipos de tendencias: una entre los que creen que ayuda a los empleados a ser más productivos, y otra en la que piensan que eleva la moral de los empleados ya que permite más flexibilidad dentro de la empresa. Pero esta forma de funcionar genera un problema asociado que es el de rastrear y controlar el acceso a las redes privadas y corporativas. Para poder llevar a cabo esta política empresarial, los dispositivos deberían tener configurados unos protocolos de seguridad para evitar accesos no deseados, ya que de lo contrario el resultado podría ser perjudicial para la empresa debido a las fisuras que podrían aparecer, como filtraciones de información o introducir aplicaciones perniciosas a la red corporativa que pueden infectar al resto de equipos de la empresa. Por ejemplo, si un empleado utiliza su smartphone para acceder a la red de la compañía y luego lo pierde, la información confidencial guardada en el teléfono podría llegar a manos no confiables y esta situación podría derivar en multitud de problemas incluyendo pérdidas económicas además de una pérdida de imagen corporativa.

Ventajas e Inconvenientes

Como con cualquier otra política corporativa el BOYD tiene sus pros y sus contras.
Ventajas:
  • Mayor productividad
  • Flexibilidad
  • Uso del dispositivo en cualquier momento y lugar
  • Mejor atención al cliente

Por lo tanto, con BYOD se tiene más flexibilidad para poder conectarse a los recursos de la organización desde el propio dispositivo del empleado y, sobre todo, se podrá hacer uso de la velocidad de conexión al emplear las comunicaciones de la empresa en lugar de la conectividad del propio dispositivo.
Inconvenientes:
  • Riesgo en la seguridad y la privacidad de la información
  • Requiere nuevas políticas de control de accesos
  • Precisa recursos de red suficientes para soportar la llegada de los dispositivos
  • Necesidad de soporte TI para multitud de dispositivos, aplicaciones y software

Si se analiza desde el punto de vista de la seguridad corporativa, el llegar al puesto de trabajo y conectar el dispositivo (ya sea smartphone, tableta o portátil) a la red de la organización ya supone un riesgo. Hay que tener en cuenta que el mismo dispositivo que se utiliza para uso personal, se está conectando directamente a la red de la empresa. Por otro lado, si se permite a los empleados conectarse con su dispositivo se puede perder el control sobre la información corporativa e incluso una fuga de la misma. En este sentido, se pueden implementar medidas como, por ejemplo, una solución DLP que inspeccione este tipo de acciones.

Como conclusión se puede decir que son varias las ventajas que proporciona BYOD, siempre y cuando se apliquen las mismas medidas de seguridad a los dispositivos personales que al resto de equipos de la organización.

REFERENCIAS

El blog de Enrique Dans - BYOD e informática corporativa
Hacking-ético -  BYOD: Ventajas e inconvenientes – Problemas de seguridad
Computing.es - BYOD, historia de dos posturas TIC enfrentadas

La Protección de Infraestructuras Críticas y la Ciberseguridad Industrial

El Centro de Ciberseguridad Industrial ha publicado el documento en el que se ha estado trabajando los últimos meses "La protección de Infraestructuras Críticas y la Ciberseguridad Industrial". El documento analiza las similitudes y divergencias entre la "Protección de Infraestructuras Críticas" y la "Ciberseguridad Industrial", tratando de aclarar el alcance de cada una de estas expresiones o ámbitos, los puntos en común, objetivos, principales responsables en cada ámbito con su correspondiente descripción, principales problemas en ámbitos como por ejemplo algo tan básico como la formación y especialización de los profesionales en ciberseguridad, algo que es escaso actualmente.

Particularmente destacable es la sección de estado del arte de este documento, digna de mención por el trabajo de investigación y recopilación de información, ya que se detallan las iniciativas existentes en Estados Unidos, Europa, Latinoamérica, así como iniciativas más concretas como las de España, Holanda y Reino Unido.

El documento se ha dividido en dos versiones, una versión pública y una versión completa de pago. Ambas versiones pueden obtenerse a través del siguiente enlace:
http://www.cci-es.org/web/cci/detalle-evento/-/journal_content/56/10694/43073#.

Del mismo modo que con el "Mapa de Ruta de la Ciberseguridad Industrial En España" publicado en Junio 2013, Internet Security Auditors también ha colaborado activamente en el desarrollo de este nuevo documento y que ha sido publicado en Octubre 2013.


Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría.

iKAT – Interactive Kiosk Attack Tool

1. Introducción

iKAT, Interactive Kiosk Attack Tool, es una herramienta diseñada para facilitar a los consultores de seguridad la tarea de auditoría en entornos de navegación “restringidos”, tales como terminales de quioscos que proveen acceso a Internet, así como a terminales Citrix, WebTVs, etc, proporcionando métodos para acceder al sistema operativo subyacente y realizar una escalada de privilegios local de forma automática.

Presentado como un sitio web SaaS (Software como servicio), ofrece un gran número de técnicas para evadir dichos entornos de navegación y lograr obtener una ejecución de comandos en sus sistemas.

Además de poder descargarlo y configurarlo en nuestra propia máquina, también existe la posibilidad de utilizar su versión online a través de la dirección http://ikat.ha.cked.net.

2. Funcionamiento

Su funcionamiento es bastante sencillo. A la hora de auditar un quiosco tan sólo hay que establecer una conexión al lugar donde se esté ejecutándose iKAT. Una vez realizada la conexión, la herramienta identifica el sistema operativo que está siendo usado en el quiosco, poniendo a nuestra disposición un menú con las distintas categorías de técnicas disponibles para el mismo.

Figura 1. Menú principal iKAT (Entorno Windows)


3. Módulos de la herramienta

Las categorías que incluye esta herramienta son las siguientes:
Auto Exploitation (Autoexplotación)
Técnicas que se aprovechan de forma automática de las distintas vulnerabilidades conocidas en los navegadores, cuyo objetivo es el de lograr ejecutar comandos en el sistema. Tiene la opción de hacer uso del módulo Browser AutoPwn de Metasploit Framework, que puede ser útil para realizar posteriormente tareas de post-explotación.

Reconnaissance (Reconocimiento)
Herramientas para obtener información del objetivo, como puede ser el navegador usado, plugins y variables del mismo, configuración de flash, etc.

File System Links (Enlaces al sistema de ficheros)
Listas de enlaces accesibles desde el navegador a archivos y directorios útiles del sistema de ficheros local, como unidades de disco, recursos de red, herramientas administrativas, escritorio, etc. Para ello se aprovecha, entre otras cosas, de los handlers disponibles de Windows Shell.

Common Dialogs (Diálogos comunes)
Distintas opciones con el fin de lograr salir del entorno controlado a través de cuadros  de diálogo comunes, como puede ser guardar, guardar como, abrir, importar, exportar, ayuda, buscar, imprimir, etc.

URI / File Handlers (Manejadores de ficheros / URI)
Lista de enlaces a los manejadores de archivos y protocolos más comunes, cuyo fin es el de averiguar las aplicaciones instaladas que están asociadas a distintos ficheros y/o protocolos.

Browser Addons (Complementos del navegador)
Applets de Java, .NET ClickOnce, controles ActiveX y plugins de Firefox para intentar obtener una ejecución de comandos sobre el sistema.

iKAT Tools (Herramientas iKAT)
Arsenal completo de herramientas diseñadas para ayudar en la explotación de este tipo de entornos, como métodos para intentar descargar ficheros y ejecutarlos, binarios de Win32 (cmd, netcat, wget), documentos de Office y PDF para aprovecharse de vulnerabilidades del software, etc.

Figura 2. Ejemplo de explotación mediante plugins del navegador
Crash a Kiosk (Denegación de Servicio)
Técnicas que se aprovechan de vulnerabilidades y plugins del navegador con el fin de bloquear la aplicación del quiosco, consiguiendo de esta manera exponer el sistema operativo subyacente.

En resumen, iKAT es sin duda alguna una gran herramienta para auditar este tipo de entornos restringidos de una manera sencilla y potente.


Autor: Daniel García
Departamento de Auditoría.

Las nuevas versiones de la norma ISO / IEC 27001 y 27002 pasan a ser Borradores Finales

Cuando se cumplen ahora 20 años del origen de la norma ISO 27001 (antes BS 7799), la nueva versión de 2013 ha llegado al estado de borrador final.

¿Qué quiere decir esto?
El estado de borrador final (FDIS, Final Draft International Standard) implica que las nuevas versiones de la norma ISO / IEC 27001 y 27002 serán publicadas a finales de este año como estándar internacional. La versión actual se completó a principios de septiembre, y después de las modificaciones realizadas, está listo para su lanzamiento el próximo mes de octubre. El período de revisión al que estaban expuestos los borradores de las normas internacionales finalizó el pasado 23 de marzo de 2013. Los comentarios fueron analizados y los capítulos nacionales votaron a favor del avance de las nuevas normas para su publicación.

¿Qué ha cambiado en la 27001?
El cambio más llamativo en esta nueva versión es la disposición de la misma. Ya no hay requisitos duplicados y el texto es menos prescriptivo, dando más libertad a las empresas en el momento de aplicar los requisitos para adaptarse a los mismos. La siguiente figura muestra la relación entre la versión de la norma del 2005 y el actual FDIS.

Actualización de la norma ISO/IEC 27001


¿Cuáles son los principales beneficios de la nueva edición?
La norma se ha actualizado teniendo en cuenta las experiencias de los usuarios que han implementado o se han certificado empleando la ISO 27001:2005, con la intención de proporcionar un enfoque racionalizado y más flexible que debería conducir a una gestión eficaz del riesgo.
También se han realizado una serie de mejoras en los controles de seguridad para asegurar que la norma sigue siendo actual y es capaz de hacer frente a los riesgos de hoy, como el robo de identidad, los riesgos relacionados con los dispositivos móviles y otras vulnerabilidades on-line.

Por último, se ha modificado la nueva norma ISO 27001:2013 para que se adapte a la nueva estructura de alto nivel utilizada en todas las normas de sistemas de gestión, por lo que su integración con otros sistemas de gestión es más sencilla y de esta forma se ayuda a las organizaciones que deseen implementar más de un sistema de gestión a la vez. La similitud en la estructura entre las normas ahorrará a las organizaciones tiempo y dinero, ya que pueden adoptar políticas e integrar procedimientos. Por ejemplo, una organización puede querer integrar su sistema de gestión de seguridad de la información (ISO/IEC 27001:2013) con otros sistemas de gestión, tales como la gestión de continuidad del negocio (ISO 22301), la gestión de servicios TI (ISO/IEC 20000) o la gestión de la calidad (ISO 9001).

¿Qué ha cambiado en la 27002?
En la actualidad existen sólo 114 controles en contraposición con los 133 de la versión original. Además, los controles se enumeran en catorce capítulos en lugar de los once originales. Muchos controles no han cambiado desde la versión de 2005, aunque el texto sí se ha actualizado. Algunos controles se han eliminado ya que no se siguen considerando válidos. Otros se han fusionado, ya que representaban lo mismo explicado de diferentes maneras. También se han añadido once controles nuevos, a saber:
- A.6.1.5 Information Security in Project management
- A.12.6.2 Restrictions on software installation
- A.14.2.1 Secure development policy
- A.14.2.5 Secure system engineering priciples
- A.14.2.6 Secure development enviroment
- A.14.2.8 System security testing
- A.15.1.1 Information and comunication technology supply chain
- A.16.1.4 Assessment of and decisión on information security events
- A.16.1.5 Response to information security incidents
- A.17.2.1 Availability of information processing facilities

Seguidamente también se muestra la nueva disposición de los catorce dominios de control que han quedado en la norma de 2013 sin contar con los introductorios:
- 5 Security Policies
- 6 Organization of information security
- 7 Human resource security
- 8 Asset management
- 9 Access control
- 10 Cryptography
- 11 Physical and environmental security
- 12 Operations security
- 13 Communications security
- 14 System acquisition, development and maintenance
- 15 Supplier relationships
- 16 Information security incident management
- 17 Information security aspects of business continuity
- 18 Compliance

Como se puede observar ahora la criptografía tiene su propio apartado (10) e igualmente las relaciones con los proveedores (15). Communications and operations management se ha dividido en dos dominios (12 y 13). El dominio sobre la gestión y el tratamiento del riesgo se ha eliminado.

Estoy certificado con la norma ISO 27001:2005 ¿qué significará esta revisión para mí?
Las organizaciones certificadas con la edición de 2005 de la norma tendrán que actualizar su sistema de gestión de seguridad de la información para cumplir con los requisitos de la nueva versión de la norma. El período de transición para la actualización aún no se ha decidido, pero es probable que sea de dos años desde que se publique la nueva edición.

¿Cuánto esfuerzo se necesita para pasar de la versión antigua a la nueva versión?
La actualización a la nueva edición de la norma ISO 27001:2013 no debería resultar especialmente problemática. El período de transición ayuda, ya que el esfuerzo requerido puede ser parte del programa de trabajo organizado e integrado en las actividades de mejora continua y auditorías de seguimiento planificadas.

Referencias

http://www.bsigroup.es

Recordatorio de fechas del ciclo de vida para PA-DSS

Con motivo de la próxima publicación de las versiones PCI DSS 3.0 y PA-DSS 3.0 del PCI SSC, el consejo ha decidido realizar una comunicación formal con las fechas de vigencia de PCI PA-DSS tanto de la nueva versión y como de la actual. Es importante tener en cuenta este recordatorio de las fechas del ciclo de vida de las normas ya que, como se documenta en la guía del programa PA-DSS 2.0, todas las validaciones 1.x PA-DSS expiran el 28 de octubre de 2013, y los cambios menores sólo se podrán presentar y ser aceptados hasta esa fecha.

Las fechas clave tras la publicación del nuevo estándar 3.0 y su cohabitación durante un cierto período de tiempo con la versión 2.0 son las siguientes:
  • ¿Hasta cuándo se puede auditar empleando v2.0? 31 de diciembre de 2014
  • ¿Hasta cuándo será válida una certificación v2.0? 28 de octubre de 2016
  • ¿Desde cuándo se puede auditar empleando v3.0? 1 de enero de 2014
  • ¿Hasta cuándo será válida una certificación v3.0? 28 de octubre de 2019 (*)
(*) Aplicable para el caso de una app que no sufriera ningún cambio desde el momento de certificación. Sólo requeriría el pago administrativo anual de renovación para mantenerse en las listas. Este fee aplicará a todas las apps.

IMPORTANTE: Estas fechas SÓLO aplican a PCI PA-DSS.

OWASP EU Tour 2013 Barcelona

La organización OWASP (Open Web Application Security Project) está presentando durante el año 2013 una serie de conferencias a lo largo de toda Europa, siendo Barcelona una de las ciudades elegidas. La conferencia OWASP EU Tour 2013 Barcelona se celebró en el mes de junio y reunió a cerca de 130 asistentes presentándose un total de cinco exposiciones de diferente temática. El evento comenzó con una bienvenida por parte de Josep María Ribes (Director de Ingeniería del campus de La Salle en Barcelona) y con una introducción por parte de Vicente Aguilera Díaz (líder de OWASP Spain Chapter).

La primera ponencia vino a cargo de Selva María Orejón Lozano y expuso casos controvertidos en los que había participado a lo largo de su carrera profesional, comentando detalles de cómo se inició cada caso, los pasos intermedios, y hasta cómo se terminó solucionando. La temática se centró en las redes sociales y cómo éstas pueden llegar a afectar de forma negativa tanto a una empresa como a un individuo, así como qué herramientas existen para gestionar esa imagen dañada.

La siguiente conferencia trató sobre cómo PCI DSS afecta a los desarrolladores de software y la impartió Fabio Cerullo. El estándar PCI DSS se conoce como una norma a cumplir en la mayoría de los casos sobre un entorno ya existente en producción. Fabio Cerullo en su exposición orientó a los desarrolladores para que vieran qué puntos deben tener en cuenta al desarrollar código, de tal forma que no se encuentren incumplimientos en las aplicaciones a la hora de pasar este tipo de auditoría.
A la mitad de la conferencia apareció Chema Alonso para hablar sobre por qué los malos siempre ganan. La presentación comenzó con casos reales de cibercrimen para demostrar su teoría, entre los que se encontraban tanto Operación Aurora como Flame entre otros. A continuación presentó una serie de posibles problemas que permiten dar lugar a estas situaciones, como, por ejemplo, que la configuración de seguridad está generalmente enfocada a usuarios con un elevado conocimiento técnico, que se realizan malas prácticas en el uso de los metadatos por parte de las empresas y, finalmente, la existencia y mal gestión de los zero days entre otros. La exposición finalizó con dos ideas interesantes, por un lado el pentesting by design en la que los sistemas se deben diseñar teniendo en cuenta una cierta carga que se va a destinar a soportar ataques y revisiones de seguridad legítimas, y por otro lado el pentesting continuo en la que los sistemas se van auditar de forma continua, pasando una batería de pruebas en la que para cada iteración probablemente habrá cambios, ya sea por la adición de alguna prueba de seguridad nueva, o porque los sistemas habrán sufrido alguna modificación.

Por fin llegó el turno de la presentación de nuestro compañero Albert López con el interesante tema de Exploiting Linux Heap. A pesar de ser la presentación más técnica del día, se realizó de una manera compresible para todo el público asistente no dando por sentado cierto tipo de conocimientos. No sólo se presentó la teoría de exploiting de glibc, sino que se explicó su evolución temporal (los descubrimientos, soluciones iniciales y contramedidas encontradas a dichas soluciones) y se demostraron las vulnerabilidades con dos ejemplos en tiempo real en la misma exposición.
Para finalizar, Marc Rivero y Dani Creus hablaron sobre la evolución del fraude en Internet. Se trataron temas diversos desde las brechas de seguridad que provocan el afán de conocimiento hasta los ataques a gran escala que roban datos de usuario de forma masiva. Explicaron el fraude de los troyanos bancarios así como la historia del fraude en seguridad física de cajeros, incluyendo skimmers, el lazo libanés y el caso Roman Vega entre otros contenidos. Ambos demostraron el buen trabajo de campo que habían realizado, profundizando sobre los foros en los que se acostumbran a vender este tipo de servicios ilícitos, así como un poco de historia sobre la compra venta de datos bancarios y varias anécdotas policiales. Una charla muy variada, para todos los públicos, expertos o no.


Material

Bienvenida
Introducción a la jornada
Seguridad en Redes Sociales
PCI DSS para desarrolladores
Why cyberspies always win
Low Level Miseries when Exploiting Linux Heap
Mesa redonda 


Autor: Giovanni López - CEH
Departamento de Auditoría

Participamos en los grupos de trabajo del Centro de Ciberseguridad Industrial

Internet Security Auditors participa en los grupos de trabajo del Centro de Ciberseguridad Industrial (CCI). La primera sesión se inició el pasado miércoles 11 de septiembre.

Los grupos de trabajo en los que se trabajará inicialmente son ingeniería (EPC), infraestructuras críticas industriales y smart metering. Internet Security Auditors participará en todos los grupos de trabajo, apoyando la iniciativa del CCI y aportando la experiencia en ciberseguridad de sus integrantes.

El CCI aspira a convertirse en un punto de encuentro independiente para los organismos (públicos y privados) y profesionales relacionados con las prácticas y tecnologías de la ciberseguridad Industrial, así como en la referencia hispanohablante para el intercambio de conocimiento, experiencias y la dinamización de los sectores involucrados en este ámbito.


Autor: Marc Segarra - CISM, CISA, CISSP, PCI QSA, PCI PA QSA, ISO27001 Lead Auditor
Departamento de Consultoría

Nuevo artículo descargable de la revista SiC: OWASP Top 10 2013: actualización de los riesgos más extendidos asociados a las aplicaciones web

Nuevo artículo publicado en nuestra sección de prensa: “OWASP Top 10 2013: actualización de los riesgos más extendidos asociados a las aplicaciones web”.

La revista SIC publica, en su número 106 (septiembre 2013), este artículo elaborado por nuestro socio y Director del Departamento de Auditoría Vicente Aguilera.

En este artículo, Vicente comenta la reciente actualización de uno de los proyectos más emblemáticos de OWASP. Con una mentalidad de divulgación y con el claro objetivo de educar, tanto a las organizaciones como a todas aquellas personas que, de una u otra manera, están implicadas en el ciclo de vida de las aplicaciones, el Top 10 enumera y describe los diez riesgos más críticos y extendidos que sufren las aplicaciones web en la actualidad. Respecto a su anterior versión, la de 2010, cabe destacar la incorporación de una nueva categoría para considerar el riesgo asociado al uso de componentes vulnerables conocidos.

Asimismo, Vicente valora el impacto que hoy está causando el traslado de las aplicaciones corporativas a la nube y los riesgos que se derivan, tanto por la pérdida de control de nuestra información como los debidos a deficiencias en la configuración o ejecución del servicio en la nube.
Puedes encontrar el artículo en nuestra sección de prensa

I Congreso Brand Care en España: Defiéndete y protege tu marca

El pasado mes de julio se celebró en La Salle Campus Barcelona el primer Congreso de España sobre Reputación, Seguridad y Legalidad (Brand Care).

El Congreso nace de la necesidad de mejorar la protección y el cuidado de las marcas tanto personales como comerciales en el ámbito de la reputación online, la seguridad, y la legislación digital, y su objetivo: aprender a proteger, cuidar y defender la marca.

El Congreso se dividió en tres partes: reputación, legalidad y Seguridad, un triángulo inseparable que conforma la nueva realidad latente en Internet.

Estos tres pilares que conformaron el evento fueron abordados por los principales expertos españoles, entre los que destacaron: el abogado Xavier Ribas, Carlos Fernández Guerra que es Community Manager de la Policía Nacional, y Vicente Aguilera que es Socio-Fundador y Director de Auditoría de Internet Security Auditors, entre otros participantes.

REPUTACIÓN
La primera parte de las charlas trataba sobre la reputación online, tanto de personas como de marcas. Donde nos quedó claro que la reputación no es algo que podamos gestionar, sino que es la percepción que tenemos de las personas y marcas lo que hemos de trabajar. También se trataron temas tan interesantes como el desposicionamiento de contenidos negativos o las técnicas de SEO negativo utilizadas por algunas personas y empresas para hacernos perder posiciones en los buscadores.

LEGALIDAD
En este segundo bloque del evento se confirmó algo que ya sabíamos: la tecnología avanza mucho más rápido que las leyes. También se trató un tema de creciente actualidad que es el derecho al olvido, del que de momento debemos relegar ya que choca de frente con otros derechos fundamentales como, por ejemplo, el derecho a la información.

SEGURIDAD
En el último bloque se presentó eGarante, un sistema para certificar por un tercero tanto correos como páginas webs o documentos de forma que pueden ser presentados como pruebas en un procedimiento legal.

Marc Rivero nos hizo un repaso a los delitos más comunes en las redes sociales, uno de los vectores de ataque preferidos por los ciberdelincuentes.

Ya en la recta final se habló del malware en dispositivos móviles, y por otro lado, se presentó una iniciativa que puede resultar muy útil para formar a futuros expertos en seguridad informática: Lostproject, un proyecto impulsado por profesores y alumnos de la Universidad Ramon Llull que persigue la formación de profesionales en hacking ético.

Para concluir el acto se organizó una mesa redonda moderada por Selva Orejón y Rosalía de la Cruz donde participaron los diversos ponentes y se expusieron casos actuales.



MATERIAL
Reputación
Legalidad
Seguridad

Autor: Lidia Buendia
Departamento de Marketing


El PCI Council avanza nuevos cambios para PCI DSS y PA DSS

Hoy, el PCI Security Standards Council (PCI SSC), foro global y abierto para el desarrollo de estándares en materia de seguridad de tarjetas de pago, ha publicado PCI Data Security Standard (PCI DSS) and Payment Application Data Security Standard (PA-DSS) 3.0 Change Highlights, un PDF con las principales modificaciones, para la versión 3.0, del estándar de seguridad de datos de aplicaciones de pagos (PA-DSS) y el estándar de seguridad de datos (PCI DSS), dónde podremos encontrar un anticipo de la nueva versión de los estándares, cuya publicación está prevista para noviembre de 2013.

Los cambios que se realizarán en los estándares han sido clasificados en tres categorías:

Aclaración (Clarification): Cambios principalmente en el texto descriptivo del control, orientado hacia una mejor explicación del objetivo. 

Guía adicional (Additional Guidance): Introduce ejemplos, instrucciones o definiciones adicionales que permiten aumentar el entendimiento o proporcionar mayor información en relación con algún aspecto del requisito.

Evolución del requisito (Evolving Requirement): Modificaciones completas o parciales del control que implican un cambio importante con el fin de adaptarse a las amenazas emergentes y/o cambios en el mercado.

A continuación se enumeran los cambios más importantes en cada uno de los estándares. Sin embargo, este listado está sujeto a modificaciones hasta que se realice la publicación final.

Cambios previstos en PCI DSS v3.0

Entre los principales cambios previstos en PCI DSS v3.0 se encuentran:
  • Mantener un diagrama de red que describa los flujos de datos de tarjetas de pago
  • Mantener un inventario de componentes de sistema dentro del alcance de cumplimiento (ver Cardholder Data Matrix)
  • Evaluar las amenazas provenientes de malware para sistemas que no son comúnmente afectados por malware
  • Actualización de la lista de vulnerabilidades comúnes para alinearse con OWASP, NIST, SANS, etc. para ser incluidas en prácticas de desarrollo seguro de software
  • Consideraciones adicionales de seguridad para mecanismos de autenticación tales como tokens físicos, smart cards y certificados
  • Protección contra manipulación o sustitución de terminales TPV (POS) y otros dispositivos
  • Implementar una metodología para la ejecución de pruebas de penetración y ejecución de este tipo de pruebas para verificar que los métodos de segmentación son operacionales y efectivos
  • Mantener información acerca de los controles de PCI DSS gestionados por proveedores de servicio y por la entidad. Los proveedores de servicio deben reconocer y aceptar su responsabilidad en el mantenimiento de los controles de PCI DSS que les aplican

Cambios previstos en PA DSS v3.0

Entre los principales cambios previstos en PA DSS v3.0 se encuentran:
  • Mejoras en los requerimientos orientados a los procesos de desarrollo de sistemas incluyendo revisiones de seguridad periódicas, verificación de la integridad del código fuente, una metodología de gestión de versiones, uso de técnicas de aplicación orientadas a modelado de amenazas en aplicaciones (application threat-modeling techniques) y un proceso de autorización formal antes de la publicación (release) final.
  • Actualización de la lista de vulnerabilidades comúnes para alinearse con OWASP, NIST, SANS, etc. para ser incluidas en prácticas de desarrollo seguro de software
  • Nuevos requerimientos para vendedores de aplicaciones de pago para proveer “Release Notes” en todas las actualizaciones
  • Nuevos requerimientos para la formación y entrenamiento de integradores/distribuidores (integrators/resellers) y personal de ventas

Fechas clave en el despliegue de las normas:

  • 4 - 5 Sept - Preparing for PCI DSS and PA-DSS 3.0: Standards Change Highlights Webinar (general public)
  • Early Sept - Draft versions of standards shared with PCI community
  • Sept, Oct, Nov - Community Meetings - Standards Discussed
  • 7 Nov - Standards Published
  • 1 Jan 2014 - Standards Become Effective

El listado completo de todos los cambios previstos se puede encontrar en el documento “Version 3.0 Change Highlights“.
Descárgate el pdf

Referencias

http://www.pcihispano.com



Autor: David Eduardo Acosta - CISSP, CISA, CISM, PCI QSA, CCNA Security, OPST, CHFI Instructor, BS25999 Lead AuditorDepartamento de Consultoría

A vueltas con las Fugas de Datos

Information is Beautiful ha publicado una infografía donde podemos revisar donde se han llevado a cabo ataques informáticos a consecuencia de los cuales se han producido importantes fugas de datos.

A vueltas con  las Fugas de Datos
http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/


Este tipo de situaciones ponen al descubierto la ineficacia o insuficiencia, de las medidas de seguridad que las empresas adoptan para su protección.

Si bien estas noticias suelen causar bastante alarma en la red, en general los responsables de las empresas lo ven como un tema “que afecta a otros” y nunca se ven a sí mismos como la  víctima de este tipo de situaciones.

Debemos recordar que implantar medidas técnicas y organizativas que garanticen la seguridad de la información es una necesidad pero también una obligación.

La Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, y el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la LOPD, es la normativa de referencia en materia de seguridad en el tratamiento de datos personales e impone una serie de obligaciones al respecto.

Su incumplimiento, si bien acarrea graves consecuencias económicas a las empresas infractoras tiene otra grave consecuencia, el deterioro de la imagen pública de estas empresas.

Pero no solo debemos preocuparnos por los Datos de carácter Personal sino en general por toda la información de nuestras organizaciones, aplicando medidas correctivas. Una auditoría de nuestra red perimetral o una revisión interna puede evitarnos muchos quebraderos de cabeza, y evitar andar a vueltas con las fugas de datos en nuestra empresa.


Autor: María del Carmen Areces
Departamento Comercial


Learning by doing

Una de las principales características de un buen pentester es la capacidad de mantener una formación continuada.

No es ningún secreto que para ser eficiente y efectivo como pentester debes estar actualizado y al corriente de las nuevas vulnerabilidades y de las nuevas metodologías de ataque y defensa. Un modo de conseguirlo es leer. Leer toda la información que seas capaz e intentar absorber los conocimientos que puedas. Leer libros, papers, blogs, advisories, noticias, etc. Sin embargo, una cosa es leer y la otra es interiorizar esos conocimientos.

Es cierto que cuando uno lee un artículo, obtiene unos conocimientos generales que le permiten saber de lo que se está hablando dada una situación que lo requiera, sin embargo, el trabajo de un pentester va más allá de entender las cosas por encima. Un pentester debe ser capaz de poner en práctica los conocimientos adquiridos y entender todos los detalles involucrados para ser capaz de llevar a cabo una intrusión exitosa. Y es aquí donde entran en juego los wargames.

Un wargame no es más que un juego que nos permite poner en práctica los conocimientos que hemos obtenido de artículos, papers, advisories, etc. Nos permite llevar a cabo los ataques que de otro modo no podríamos probar. De esta manera, practicando, es como los conocimientos arraigan y nos permiten tener la seguridad de que somos capaces de realizar un ataque que podría ser complejo técnicamente.

Hay diferentes tipologías de wargames. Tienes wargames en los que accedes a una aplicación web y se te presentan diferentes retos, otros wargames en los que accedes a máquinas externas vía SSH y otros en los que te descargas máquinas virtuales que ya están preparadas para ser vulnerables. A continuación se describen alguno de los wargames más completos que podéis encontrar en la red y que, en conjunto, os pueden servir como guía para ir obteniendo conocimientos de vulnerabilidades a nivel de aplicación, a nivel web, vulnerabilidades de red o hasta vulnerabilidades relacionadas con aspectos criptográficos.

Over the Wire

El primer wargame que presentamos es Over The Wire. Este es el wargame por antonomasia. Over The Wire está dividido en varios sub-wargames y cada uno está dedicado a una temática en concreto. Sin embargo, en lo que se especializa Over The Wire es en la explotación de aplicaciones de sistema.
Con este propósito se nos presentan los sub-wargames
Cada uno de estos wargames es una evolución del anterior, de modo que el nivel de dificultad entre las pruebas se va incrementando a medida que vamos obteniendo los conocimientos para ir avanzando. Realmente es una manera ideal para ir aprendiendo.

Sin duda este wargame es de los más completos de la red, aún más después de haber añadido en su repertorio el wargame Natas, en el que tienes 23 niveles dedicados a seguridad web.

Además, por si fuera poco, también tienen otro wargame compuesto por 6 niveles llamado krypton enfocado en atacar diferentes vulnerabilidades relacionadas con criptografía.

Exploit Exercises

Dentro de la tipología de wargames en la que se nos proporciona una máquina virtual tenemos Exploit Exercises. Exploit Exercises nació hace más bien poco y también está enfocado a la explotación de vulnerabilidades a nivel de sistema. La gracia de Exploit Execises es que nos presenta tres máquinas virtuales, Nebula, Protostar y Fusion, que nos introducen en el mundo de la explotación de software y nos llevan hasta niveles bastante decentes en los que deberemos vulnerar diferentes medidas de seguridad implementadas para mitigar la explotación de software en los sistemas operativos de hoy en día.

Lo cierto es que desde que nació, Exploit Exercises ha madurado como el vino y puede que, actualmente, sea una de las opciones más didácticas para introducirse en el mundo del exploiting. A modo de ejemplo, si se accede a la web de Fusion, se puede ver todo un listado de niveles y en cada uno de estos niveles se nos explica qué medidas de seguridad están implementadas, tal y como se puede ver en la siguiente imagen.

Listado de niveles dónde se explica qué medidas de seguridad están implementadas en la web de Fusion

OWASP Broken Web Applications Project

Este wargame viene de la mano de OWASP (Open Web Application Security Project) y se enfoca en la seguridad, como no, de aplicaciones web.

Como ocurría con Exploit Exercises, para jugar este wargame nos tendremos que descargar una máquina virtual en la que tendremos diferentes aplicaciones vulnerables.

El wargame contiene diferentes tipologías de aplicaciones.
Por un lado, tenemos las aplicaciones de entrenamiento que no son más que aplicaciones implementadas para que un usuario pueda formarse de un modo amigable en lo que son las vulnerabilidades web. Entre ellas destacan las aplicaciones Damn Vulnerable Web Application y OWASP WebGoat.

Por otro lado tenemos otras aplicaciones que se han dejado vulnerables intencionadamente, pero que son un poco más realistas que las anteriores. De estas aplicaciones destaca el proyecto de Google llamado Gruyere, del que se puede encontrar mucha más información en http://google-gruyere.appspot.com. Como se puede ver en esa web, Gruyere trata muchísimos de los conceptos relacionados con la seguridad web como por ejemplo las diferentes tipologías de XSS, CSRF, XSSI, vulnerabilidades en Ajax y un largo etcétera.

Por último y siendo algo muy interesante, tenemos otro conjunto de aplicaciones web reales entre las que hay, por ejemplo, Wordpress o Joomla que son vulnerables debido a que son versiones antiguas con diferentes vulnerabilidades descubiertas.

Como conclusión, decir que el mundo de los wargames no termina aquí. Existen decenas y decenas de wargames con los que puedes especializarte en diferentes áreas. Existe una magnífica web que ha realizado un recojo de muchísimos wargames en una especie de mindmap que divide los wargames según su temática. Podéis encontrar este recurso en el siguiente enlace.


Autor: Albert López
Departamento de Auditoría

Ley de Habeas Data Colombia

Colombia como otros muchos países de su entorno (Argentina (Ley 25326/2008); Uruguay (Ley 18.331/2008); Perú (Ley 29733/2011); Costa Rica (Ley 8968/2011); Nicaragua (Ley 787/2012)) ha tenido una preocupación por la Protección de Datos de Carácter Personal trabajando duramente por homologar una normativa en esta materia siendo de gran importancia el impulso que la Red Iberoamericana de Protección de Datos ha prestado.

La protección de datos en Colombia surge del  artículo 15 de la Constitución Política, que establece:
Todas las personas tienen derecho a su intimidad personal y familiar y a su buen nombre, y el Estado debe respetarlos y hacerlos respetar. De igual modo, tienen derecho a conocer, actualizar y rectificar las informaciones que se hayan recogido sobre ellas en bancos de datos y en archivos de entidades públicas y privadas. En la recolección, tratamiento y circulación de datos se respetarán la libertad y demás garantías consagradas en la Constitución…
Y en base a ese artículo se han desarrollado diversas normativas para el reconocimiento de dicho derecho fundamental, en concreto a través de La ley 1266 de 2008 (Habeas Data Financiero) que regula la forma de ejercer los derechos frente al reporte de información en las centrales de riesgo y de la Ley 1581 de 2012 que instrumentó los mecanismos que permitirán a los colombianos hacer efectivo su derecho de acceso, actualización, rectificación y supresión de datos personales, ante cualquier entidad pública o privada que administre archivos o bases de datos.

Concluido el periodo de transición de seis meses establecido por la Ley 1581 de 2012, a partir del cual, todas las entidades públicas y privadas que manejan bases de datos con información personal, han debido adecuar sus procedimientos a los deberes que les impone el Nuevo Régimen de Protección de Datos.

La Superintendencia de Industria y Comercio (SIC)  ejercerá la función de vigilancia al uso de datos personales en Colombia, a través de su Delegatura para la Protección de Datos Personales, en concreto:
  • Ejerce facultades de autoridad de vigilancia.
  • Adelantar investigaciones por el incumplimiento de los deberes de los responsables y encargados del tratamiento.
  • Ordenar medidas correctivas para proteger el derecho de hábeas data de los ciudadanos.
  • Ordenar el bloqueo temporal de los datos.
  • Ordenar la eliminación o corrección de información en una base de datos
  • Administrar el Registro Nacional Público de Bases de Datos, (que se encuentra en proceso de reglamentación por parte del Gobierno Nacional).
En caso de comprobarse la comisión de una infracción a dichos deberes, la Delegatura para la Protección de Datos Personales, podrá imponer multas de hasta dos mil salarios mínimos legales mensuales vigentes (2.000 smlmv) , ordenar la suspensión de actividades u ordenar el cierre temporal o definitivo de las operaciones relacionadas con el tratamiento de datos personales.

La Superintendencia aclara que la Ley 1581 de 2012 no deroga la Ley 1266 de 2008, que se creó de manera exclusiva para la información financiera, por lo que las empresas deben plantear  un proceso de adecuación integral interno a los nuevos tiempos que se avecinan.


Autor: María del Carmen Areces
Departamento Comercial


50% de descuento en formación para personas en paro

En estos momentos de crisis, no hay que dejar de lado la formación. Por eso desde Internet Security Auditors queremos ayudar a todas esas personas que por desgracia están en paro, ofreciéndoles hasta el 50% de descuento en nuestros cursos más demandados. Por qué una buena formación es capaz de abrir muchas puertas.
50% de descuento en la inscripción normal a los cursos:

Certified Ethical Hacker (CEH)
Fechas disponibles:
8-12 de julio de 2013 en Barcelona
25-29 de noviembre de 2013 en Madrid

Inscripción normal: 1.950 € (IVA no incluido)  
50% descuento para parados: 975 € (IVA no incluido)


Computer Hacking Forensic Investigator (CHFI)
Fechas disponibles:
21-25 de octubre de 2013 en Madrid

Inscripción normal: 1.950 € (IVA no incluido)
50% descuento para parados: 975 € (IVA no incluido)


Certified Information Systems Security Professional (CISSP)
Fechas Disponibles:
14-18 de octubre de 2013 en Madrid

Inscripción normal: 2.595 € (IVA no incluido)
50% descuento para parados: 1297,5 € (IVA no incluido)

Guía sobre el uso de las cookies de la Agencia Española de Protección de Datos

La Agencia Española de Protección de Datos (AEPD) ha presentado la primera guía sobre el uso de las cookies en Europa, elaborada de manera conjunta por la autoridad de protección de datos y los representantes de la industria.

La Guía incluye un conjunto de directrices para conseguir mayor seguridad jurídica en el deber de información al usuario y en la obtención del consentimiento.

La primera duda que quizá pueda plantearse es, esta Guía ¿es derecho aplicable? La respuesta es no,  la propia guía reconoce que:
Dadas las múltiples complejidades que plantea el uso de las cookies, estas orientaciones no pretenden ofrecer una solución general y uniforme para el cumplimiento de la Ley sino que deben servir….. para que las entidades afectadas reflexionen y adopten decisiones sobre la solución más adecuada a sus intereses y  modelo de negocio.

La AEPD recomienda que Empresas y Responsables de páginas web que utilizan cookies realicen una revisión, bien internamente, bien con el asesoramiento de entidades especializadas, para validar qué cookies utilizan,  con qué finalidad, y descartar aquello que sea innecesario, lo que además supondrá una mejora del servicio que prestan a sus usuarios.

La segunda duda sería ¿aplica a todos los tipos de cookies? La respuesta también es negativa. El grupo de trabajo del Artículo 29 ha considerado que pueden excluirse del ámbito de aplicación del art. 22.2 de la LSSI:
  • Cookies de «entrada del usuario», que se utilizan para rastrear las acciones del usuario al rellenar los formularios, o cesta de la compra para hacer el seguimiento de los artículos que el usuario ha seleccionado etc.
  • Cookies de autenticación o identificación de usuario.
  • Cookies de seguridad del usuario, utilizadas para detectar intentos erróneos y reiterados de conexión a un sitio web.
  • Cookies de sesión de reproductor multimedia.
  • Cookies de sesión para equilibrar la carga.
  • Cookies de personalización de la interfaz de usuario.
  • Cookies de complemento (plug-in) para intercambiar contenidos sociales.
Veamos algunos de los puntos principales de la Guía:
En cuanto al deber de información, los usuarios deben recibir una información clara y completa sobre el uso de las cookies, es decir, el usuario no debe tener ninguna duda del uso que se va a hacer de la  información y cual será el destino de  la información captada.

Otro aspecto a tener en cuenta es quien es el usuario del servicio, se establece la necesidad de valorar los conocimientos técnicos para un usuario “tipo medio” que accede al servicio que prestamos, de esta forma será necesario establecer un deber de información adecuado a cada caso, es decir, información más sencilla y comprensible cuanto menos conocimiento se le suponga al usuario.

Además, la información que se facilite al usuario tiene que ser visible y accesible en la web, mediante  un posicionamiento y  tamaño adecuado y utilizando una denominación descriptiva e intuitiva para el enlace.

La obtención de la información obliga a utilizar una formula expresa, es decir que podamos demostrar la obtención de dicho consentimiento.

Por último, se deben explicar los métodos de desactivar y eliminar las cookies recogidas, además de proporcionar un método para revocar un consentimiento ya prestado anteriormente.

Si necesita apoyo en la interpretación o aplicación de estas medidas, puede contactar con el equipo de Internet Security Auditors a través de comercial@ isecauditors.com

Más información sobre la guía en:
http://www.agpd.es/


Autor: María del Carmen Areces
Departamento Comercial

Una visión general de los requerimientos de seguridad para la producción de tarjetas de pago

Como respuesta a una necesidad que se venía presentando desde hace bastante tiempo, el PCI SSC ha publicado el 9 de Mayo de 2013 dos nuevos documentos:
Estos nuevos requerimientos están dirigidos específicamente para empresas que se dedican a estampación de tarjetas de pago (plásticos),  personalización de tarjetas y grabación de datos tanto en banda magnética como en chip. Inicialmente, estos requerimientos eran gestionados independientemente por cada marca, siendo ahora centralizados y alineados con las políticas del PCI SSC.

¿Cuál es el objetivo de estos requerimientos?

Debido a que por efectos operativos las empresas involucradas en el proceso de estampación y grabación de datos en tarjetas de pago almacenan y procesan información de datos del titular de la tarjeta y datos confidenciales de autenticación, el potencial riesgo que presentan frente a un robo de información y uso fraudulento es muy alto. Cada una de las marcas había desarrollado su propio conjunto de requerimientos, pero el cumplimiento de PCI DSS de estas empresas no estaba del todo claro. El PCI SSC dentro de sus FAQ (https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Do-the-PCI-DSS-requirements-apply-to-card-manufacturers-embossers-card-personalizers-or-entities-that-prepare-data-for-card-manufacturing) publicó esta entrada (7/7/2009):
Do the PCI DSS requirements apply to card manufacturers, embossers, card personalizers, or entities that prepare data for card manufacturing?
FAQ Response: Organizations that participate in data preparation, manufacturing, personalizing, and/or and embossing for plastic cards are considered Service Providers for purposes of PCI DSS and should adhere to PCI DSS. However, some payment brands may already have programs in place that include PCI DSS for entities that prepare data, manufacture, personalize, or emboss plastic cards – we encourage you to check with each payment brand about their requirements for these entities. Please contact the payment brands directly.”
Por otro lado, el estándar PCI DSS v2 agregó una nota en el requerimiento 3.2 en la cual aclaran que bajo ciertas circunstancias especiales y justificadas, los emisores de tarjetas pueden almacenar datos confidenciales de autenticación, convirtiendo a estas entidades en una excepción que aún no estaba regularizada:
Requerimiento 3.2 de PCI DSS:… Nota: Es posible que los emisores de tarjetas y las empresas que respaldan los servicios de emisión almacenen datos confidenciales de autenticación si existe una justificación de negocio y los datos se almacenan de forma segura… "
Con estos nuevos documentos, tanto los requerimientos físicos como los lógicos dentro de todo este proceso serán centralizados en el PCI SSC, lo cual facilitará su integración con estándares relacionados y permitirá una adopción más homogénea en las empresas afectadas mejorando los niveles de seguridad relacionados. Adicionalmente, estos requerimientos entrarán dentro del mismo ciclo de vida de los estándares del PCI SSC con actualizaciones cada tres años.

Es importante aclarar que a pesar que son dos documentos diferentes (controles lógicos y físicos) no son excluyentes, son complementarios.

Payment Card Industry (PCI) Card Production Logical Security Requirements Version 1.0
Este documento está orientado hacia sistemas y procesos de negocio tales como personalización de tarjetas, generación de PIN, envío de PIN y distribución de plásticos, definiendo una serie de controles de seguridad lógica mínimos en el proceso de preparación, manufactura, transporte y personalización de tarjetas de pago y sus componentes.

El documento está dividido en las siguientes secciones:
Roles y responsabilidades
  • Personal de seguridad de la información
  • Asignación de responsabilidades de seguridad
Política de seguridad y procedimientos
  • Política de seguridad de la información
  • Procedimientos de seguridad
  • Planes de respuesta a incidentes y forenses
Seguridad de datos
  • Clasificación
  • Cifrado
  • Acceso a datos de titular de tarjeta
  • Transmisión de datos de tarjeta
  • Retención y eliminación de datos de tarjeta
  • Manipulación de medios de almacenamiento
  • Personalización de tarjetas contactless
Seguridad de red
  • Definición de una red típica
  • Requerimientos generales
  • Dispositivos de red
  • Cortafuegos
  • Programas antivirus
  • Acceso remoto
  • Redes inalámbricas
  • Pruebas de seguridad y monitorización
Seguridad de sistemas
  • Requerimientos generales
  • Gestión de cambios
  • Configuración y gestión de actualizaciones
  • Logs de auditoría
  • Diseño y desarrollo de software
  • Implementación de software
Gestión de usuarios y sistemas de control de acceso
  • Gestión de usuarios
  • Control de contraseñas
  • Bloqueo de sesiones
  • Bloqueo de cuentas
Gestión de claves: datos secretos
  • Principios generales
  • Claves simétricas
  • Claves asimétricas
  • Administración de seguridad en la gestión de claves
  • Generación de claves
  • Distribución de claves
  • Carga de claves
  • Almacenamiento de claves
  • Uso de claves
  • Copia de respaldo y recuperación de claves
  • Destrucción de claves
  • Registros de auditoría en la gestión de claves
  • Compromiso de claves
  • Hardware de seguridad para la gestión de claves (HSM)
Gestión de claves: datos confidenciales
  • Principios generales
Distribución de PIN mediante métodos electrónicos
  • Requerimientos generales
Payment Card Industry (PCI) Card Production Physical Security Requirements Version 1.0
Este documento define una serie de controles físicos mínimos para empresas que manufacturan, personalizan y graban datos de tarjeta en chip o en banda magnética antes, durante y después de los siguientes procesos:
  • Manufactura de tarjetas
  • Grabación de datos en banda magnética
  • Personalización de tarjetas
  • Inicialización de chip o pre-personalización
  • Grabación de datos en chip
  • Personalización de chip
  • Almacenamiento de tarjetas
  • Envío de tarjetas
El documento está dividido en las siguientes secciones: Personal
  • Empleados
  • Guardias
  • Visitantes
  • Proveedores de servicio externo
  • Agentes de vendedores/fabricantes
Edificios
  • Estructura externa
  • Seguridad externa
  • Estructura interna y procesos
  • Seguridad interna
  • Plan de contingencia del negocio de vendedores/fabricantes
Procedimientos de producción y registros de auditoría
  • Limitaciones en pedidos
  • Aprobación de diseños de tarjetas
  • Muestras
  • Materiales y planchas de impresión – Acceso e inventario
  • Tarjetas parcialmente finalizadas
  • Obtención de componentes propietarios
  • Controles de auditoría – manufactura
  • Equipamiento de producción y componentes de tarjetas
  • Tarjetas devueltas/Envío de PIN por correo
  • Procedimientos de destrucción y auditoría
  • Reportes de pérdida y robo
Requerimientos de embalaje y entrega
  • Preparación
  • Embalaje
  • Almacenamiento previo al envío
  • Distribución
  • Envío y recepción
  • Definición de responsabilidades por pérdida
Impresión de PIN y embalaje de tarjetas prepago no personalizadas
Al igual que todos los documentos del PCI SSC, estos requerimientos están publicados en la sección “Documents Library” de la página del Council: https://www.pcisecuritystandards.org/security_standards/documents.php.

REFERENCIAS

www.pcihispano.com


Autor: David Eduardo Acosta - CISSP, CISA, CISM, PCI QSA, CCNA Security, OPST, CHFI Instructor, BS25999 Lead
Departamento de Consultoría