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

Protección de datos de tarjetas en pagos vía telefónica y grabación de llamadas en Call Centers

Dentro de los canales operativos por los cuales se reciben datos de tarjetas se encuentran los canales presenciales (aquellos en los cuales el usuario tiene que estar presente para verificar su identidad digitando su PIN) y los canales no presenciales (en los cuales se emplean otras  alternativas para la validación de la identidad del usuario, como por ejemplo el  código de verificación (CVV2, CVC2, CID o CAV2)). Dentro de este último canal podemos encontrar las transacciones MOTO (Mail Order/ Telephone Order) y transacciones realizadas por comercio electrónico. En este artículo se hablará acerca de las transacciones vía telefónica, el almacenamiento de datos de tarjetas de pago, el cumplimiento de PCI DSS y las alternativas técnicas para alinearse con el estándar.

Transacciones telefónicas y datos de tarjetas de pago

 

En una transacción típica vía telefónica, el usuario titular de tarjeta efectúa o recibe una llamada a un centro de servicio en la cual un agente le solicita sus datos de tarjeta de pago (PAN, nombre del titular, fecha de expiración y código de validación) y efectúa un cobro actuando en su nombre. A diferencia de otras transacciones no presenciales como las realizadas por comercio electrónico, los pagos vía telefónica han tenido una serie de inconvenientes que se desprenden de las necesidades propias de su modelo de operación:

  • Acceso a datos de tarjetas de pago por parte del agente telefónico: Dependiendo de cuál sea el método mediante el cual el usuario titular de tarjeta entrega sus datos al agente telefónico, éste último puede almacenarlos de forma no segura (escritos en un papel, almacenados en una hoja de cálculo o un documento de texto, por ejemplo) e inclusive extraerlos de la organización usando sistemas de mensajería (correo electrónico, mensajería instantánea, etc.), lo cual puede redundar en potenciales problemas de fraude e incumplimiento del estándar PCI DSS.  Igualmente, la terminal del agente telefónico que se emplea para ingresar los datos de tarjeta del usuario puede almacenar información sensible o permitir la visualización en texto claro. Al respecto, el PCI SSC hace una serie de aclaraciones relacionadas con la implementación de seguridad física en Centros de Llamadas en la FAQ “Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of the PCI DSS?” (10/2/2012).
  • Almacenamiento de datos de tarjetas de pago: Una práctica común para gestionar los niveles de calidad y servicio en la operativa telefónica consiste el grabar las llamadas telefónicas. Esta grabación puede ser realizada utilizando medios análogos o digitales, almacenando todo el contenido de la llamada e incluyendo la información proporcionada por el usuario al agente para la realización del pago, dentro de la cual se puede encontrar:
    • Primary Account Number: Este dato debe ser almacenado de forma segura según el requerimiento 3.4 de PCI DSS
    • Datos confidenciales de autenticación: Conforme con el requerimiento 3.2 de PCI DSS no se deben almacenar datos confidenciales de autenticación (datos de la banda magnética, CAV2/CVC2/CVV2/CID y/o PIN/PINBLOCK) posterior a la autorización.
    • Fecha de expiración
    • Datos del titular de tarjeta

El problema detrás de todos estos requerimientos está en la complejidad técnica que puede conllevar la aplicación de estos controles en el almacenamiento de las grabaciones de llamadas.  No todas las alternativas son válidas y en función del tipo de almacenamiento empleado, las cosas se pueden poner aún más difíciles. Al igual que con la seguridad física, el PCI SSC describió una serie de acciones a realizar para el cumplimiento y protección de datos de tarjetas en PCI DSS en la siguiente FAQ (10/3/2011):

“Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of PCI DSS?
This response is intended to provide clarification for call centers that record cardholder data in audio recordings, and applies only to the storage of card validation codes and values (referred to as CAV2, CVC2, CVV2 or CID codes by the payment brands).
It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.
It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.
Where technology exists to prevent recording of these data elements, such technology should be enabled.
If these recordings cannot be data mined, storage of CAV2, CVC2, CVV2 or CID codes after authorization may be permissible as long as appropriate validation has been performed. This includes the physical and logical protections defined in PCI DSS that must still be applied to these call recording formats.
This requirement does not supersede local or regional laws that may govern the retention of audio recordings.”
Con el fin de aclarar y facilitar la elección de una u otra solución para proteger los datos de tarjetas en transacciones telefónicas, el PCI SSC publicó en Marzo de 2011 el documento “Information Supplement: Protecting Telephone-based Payment Card Data” en donde se describen una serie de pautas y recomendaciones para la securización de la información de tarjetas con base en los criterios de PCI DSS.

Alternativas técnicas válidas para la protección de datos de tarjetas de pago en transacciones telefónicas

 

Como se comentó anteriormente, para el cumplimiento de PCI DSS se requiere almacenar de forma segura el PAN (en caso que sea necesario) y eliminar los datos confidenciales de autenticación posterior a la autorización. A continuación se analizarán diferentes alternativas para abordar estos requerimientos y se compararán sus pros y contras.


No grabar la llamada

 

En función de un análisis de riesgos y de un análisis coste/beneficio se puede implementar esta alternativa, en la cual la organización opta por eliminar el potencial riesgo de almacenamiento de datos de tarjetas de pago evitando la grabación de las llamadas.
  • Ventajas:
Costes de implementación: Al no existir necesidad de implementar ningún control debido a que no hay almacenamiento de datos por la ausencia de grabación, no se incurre en costes adicionales. Por otro lado, la infraestructura de grabación de llamadas no será necesaria, con lo cual la empresa no necesitará invertir en mantenimiento y soporte de dichos equipos.

Minimización del alcance de cumplimiento: Los equipos de grabación de llamadas ya no serán requeridos, minimizando el entorno de PCI DSS.

  • Desventajas:
Pérdida de valor agregado: En un entorno operativo real, optar por obviar la grabación de las llamadas implica que la organización no obtendrá las mejoras y ventajas provistas por esta herramienta, tales como gestión de calidad, monitorización del servicio, seguimiento de umbrales de niveles de servicio al cliente, información estadística, evidencias legales en caso de conflictos o investigaciones, formación al personal, etc.

El agente telefónico continuará teniendo acceso a los datos de tarjeta: A pesar que no existirá almacenamiento de datos de tarjeta provenientes de la grabación de llamadas, el agente telefónico que obtiene los datos del usuario seguirá teniendo acceso a esta información, con lo cual este potencial riesgo seguirá latente y deberá ser gestionado de acuerdo con los controles de PCI DSS.

Uso de Interactive Voice Response (IVR)


Un sistema de Respuesta de Voz Interactiva (Interactive Voice Response – IVR) es un sistema automatizado que permite que el usuario interactúe con una serie de opciones previamente configuradas (menús) para la obtención de información mediante el uso de:
  • DTMF (Dual Tone Multi Frequency) o marcación por tonos
  • Speech recognition (Reconocimiento del habla)  o conversores voz-texto entre otros.

Estos sistemas pueden ser usados de forma totalmente automatizada no hay agentes humanos) o en un formato híbrido, en el cual el agente puede llevar la llamada hasta el momento en el cual se requiera el ingreso de datos de tarjetas de pago, desviando la llamada hacia el sistema IVR.
  • Ventajas:

No hay interacción con agentes telefónicos humanos en el ingreso de datos de tarjetas de pago: Al no depender del ingreso manual de datos, el potencial riesgo proveniente del almacenamiento y extracción de datos de tarjetas por los agentes telefónicos es eliminado.

Se evita el almacenamiento de datos de tarjetas de pago provenientes de las llamadas telefónicas: En función del uso de una alternativa totalmente automatizada o híbrida, la interacción con el sistema IVR se puede desvincular de la grabación de las llamadas.
  • Desventajas:
Re-definición del modelo de atención al usuario: Debido a que se ingresa un nuevo elemento al flujo de la llamada, es necesario reajustar la operación para que la llamada sea interrumpida cuando se van a ingresar datos de tarjetas de pago, lo cual implica formación a los agentes telefónicos y notificaciones e instrucciones a los clientes y usuarios del servicio.

Re-definición de la infraestructura tecnológica del servicio: Ingresar un nuevo elemento dentro de la infraestructura del servicio de atención telefónica puede ser traumático en función de la complejidad de la organización. Así mismo, se requiere integrar el servicio de IVR al software de procesamiento de pagos para que el ingreso de datos sea automatizado.

Abandono de llamada: El uso de un sistema automatizado puede hacer que un usuario “dudoso” abandone la llamada por ejemplo en el caso de una venta difícil o de pagos de créditos o cuotas), minimizando la efectividad del servicio telefónico.

Tiempos muertos: El tiempo mientras que el usuario está interactuando con el sistema IVR es tiempo “muerto” del agente telefónico, lo cual puede implicar costes al servicio. Igualmente, los tiempos de llamadas se extenderán, incrementando los costes de facturación telefónica.

Envío de transacciones erróneas al centro autorizador: Debido a que no hay un punto de validación (double-check) en el ingreso de datos de tarjeta vía IVR por parte del usuario, se pueden presentar errores en los datos enviados al centro autorizador, incrementando los costes del servicio (si se paga por transacción procesada).

Soporte a usuarios: Finalmente, algunos usuarios requerirán de soporte para el uso del sistema, con lo cual se debe formar a los agentes telefónicos para que puedar dar las instrucciones necesarias en el uso del sistema IVR, alargando los tiempos medios de llamadas.

Pausar automáticamente la grabación


Mediante esta opción, la grabación es detenida de forma automática en el momento del ingreso de datos de tarjetas de pago con base en una serie de “activadores” en la pantalla del agente telefónico o del formulario de pago empleado.
  • Ventajas:
No requiere cambios en la operación de la llamada: Debido a que la desactivación de la grabación debe ser automática y vinculada a eventos específicos, no se requiere ningún cambio en la atención de la llamada por parte del agente telefónico o cambios en la interacción del usuario.

Se evita el almacenamiento de datos de tarjetas de pago provenientes de las llamadas telefónicas: Debido a que la grabación de la llamada es detenida en el momento de ingreso de datos de tarjeta, no existirá almacenamiento de este tipo de datos.
  • Desventajas:
Interacción con el software de procesamiento de pagos: Debido a que la premisa de esta alternativa es la automatización en la desactivación de la llamada,  se requiere un tiempo prudencial en el proceso de desarrollo e integración entre el software de procesamiento de pagos y el sistema de grabación de llamadas.

Impacto de cambios en el software de procesamiento de pagos: Cualquier cambio que sea realizado en el software de procesamiento de pagos implicará nuevos desarrollos, integración y pruebas con los “activadores” definidos para detener la grabación.

El agente telefónico continuará teniendo acceso a los datos de tarjeta: A pesar que no existirá almacenamiento de datos de tarjeta provenientes de la grabación de llamadas, el agente telefónico que obtiene los datos del usuario seguirá teniendo acceso a esta información, con lo cual este potencial riesgo seguirá latente y deberá ser gestionado de acuerdo con los controles de PCI DSS.

Ocultar o enmascarar automáticamente la voz


Esta opción es una variación de la opción anterior de “Pausar la grabación”. La diferencia radica en que en vez de detener la grabación en el momento en el que el usuario dicta los datos de tarjeta, se “oculta” o “enmascara” la voz (empleando un pitido, silencio o ruído) para que no quede en la grabación. Esta opción también debe contar con un automatismo especial que permita que el “ocultamiento” de la voz sea activado en determinados eventos.

Las ventajas y desventajas son las mismas que en la opción de “Pausar la grabación”.

Uso de Dual-Tone Multi-Frequency signaling (DTMF)

 

Esta opción combina funcionalidades de la opción “Uso de Interactive Voice Response (IVR)” y “Ocultar o enmascarar la voz”. En esta alternativa, el agente telefónico mantiene la llamada normalmente y con base en determinados eventos (o “activadores”) se le pide al usuario que ingrese sus datos de tarjeta de pago empleando las teclas de su teléfono. Estos datos son procesados internamente por un filtro DTMF (sin necesidad de que la llamada sea re-enrutada) y convertidos de tonos a texto, ingresando la información en los campos correspondientes del software de procesamiento de pago.
  • Ventajas:
No hay “cortes” en la llamada: La interacción entre usuario y agente fluye normalmente hasta el momento en el cual se ingresan los datos de tarjeta de pago. En este momento, el usuario usa las teclas de su teléfono para proporcionar la información pero la llamada no es “detenida” ni la grabación es cortada. El agente telefónico continuará con el control de la llamada.

No hay interacción con agentes telefónicos humanos en el ingreso de datos de tarjetas de pago: Al no depender del ingreso manual de datos, el potencial riesgo proveniente del almacenamiento y extracción de datos de tarjetas por los agentes telefónicos es eliminado.

Se evita el almacenamiento de datos de tarjetas de pago provenientes de las llamadas telefónicas: La interacción con DTFM evita que exista almacenamiento de datos de tarjetas de pago en las grabaciones de llamadas.
  • Desventajas:
Integración de un filtro en el sistema de telefonía: Para que esta alternativa sea funcional se requiere la integración de un filtro especial en el sistema de telefonía que sea capaz de detectar los tonos DTMF y convertirlos a texto. Este filtro requiere ser capaz de identificar cuándo los tonos pertenecen a datos de tarjetas y cuándo corresponden a acciones propias de una terminal IVR que pueda estar en la infraestructura telefónica, para no incurrir en solapamientos.

Interacción con el software de procesamiento de pagos: Se requiere la implementación de una serie de controles adicionales en el software de procesamiento de pagos para que sea capaz de integrarse con el filtro DTMF.

Impacto de cambios en el software de procesamiento de pagos: Cualquier cambio que sea realizado en el software de procesamiento de pagos implicará nuevos desarrollos, integración y pruebas con el filtro DTMF.

Alternativas técnicas NO VÁLIDAS para el cumplimiento de PCI DSS


En el mercado – y probablemente diseñadas para cubrir otro tipo de requerimientos operativos – existen una serie de alternativas que no son válidas para el cumplimiento de PCI DSS. Estas alternativas deben ser analizadas con mucho cuidado, con el fin de no incurrir en una inversión que al corto plazo no cubra con las necesidades técnicas descritas en los controles de PCI DSS.

Pausar manualmente la grabación

Conforme con el “Information Supplement: Protecting Telephone-based Payment Card Data”, los datos de tarjeta de pago deben ser removidos de la grabación de forma automática (esto es: sin intervención del agente).  La justificación asociada es la siguiente:

  • Si la pausa se realiza manualmente, el agente puede olvidar realizar esta acción, con lo cual se puede presentar un almacenamiento involuntario de datos de tarjeas de pago en la grabación, dando un falso sentido de seguridad y exponiendo a la organización a un potencial riesgo.
  • Por otro lado, si el agente es el encargado de la pausa de la llamada, puede detener de forma premeditada partes de la conversación que no quiere que sean trazadas, perdiendo sentido las acciones posteriores de revisión de calidad y servicio.

Uso de cifrado exclusivamente

El uso de cifrado de los datos almacenados como resultado de la grabación de llamadas no es suficiente para proporcionar el nivel de seguridad exigido por PCI DSS:
  • El requerimiento 3.2 de PCI DSS establece “No almacene datos confidenciales de autenticación después de recibir la autorización (aun cuando estén cifrados)”. De acuerdo con esto, inclusive si los medios donde se encuentra la grabación están cifrados, estarían incumpliendo con el estándar.
  • Si existe un proceso de cifrado, existirá su contrapartida: el descifrado. En algún momento, los responsables del Centro de Llamadas necesitarán acceder a la información guardada para realizar sus labores de calidad y monitorización. Estos roles tendrán acceso a los datos de tarjetas almacenados, incumpliendo la normativa y exponiendo esta información al mismo riesgo que se está tratando de controlar.


Uso de técnicas de reconocimiento de voz para eliminación de datos almacenados


En esta opción, se emplean técnicas de reconocimiento de voz en las grabaciones de llamadas realizadas, tratando de identificar aquellos apartados en los cuales se dictan datos de tarjetas de pago para proceder con su borrado. Lamentablemente, esta técnica no ofrece resultados totalmente confiables en la detección, pudiendo dejar datos de tarjetas remanentes y exponiendo a la organización a potenciales riesgos derivados de este almacenamiento no controlado.

Soluciones comerciales en el mercado que permiten el cumplimiento de PCI DSS en la grabación de llamadas telefónicas


A continuación se presentan como referencia algunas soluciones comerciales que permiten la implementación de los controles de PCI DSS implementando alguna de las alternativas descritas anteriormente:
  • Veritape CallGuard: Esta solución implementa filtros Dual-Tone Multi-Frequency signaling (DTMF) para la protección de datos de tarjetas de pago en llamadas. Ofrece adicionalmente enmascaramiento de datos en la visualización.
  • Nice: Esta solución utiliza pausado automático de la llamada cuando se ingresan datos de tarjetas de pago.
  • Red Box Recorders: Esta solución utiliza enmascaramiento de la voz mediante la aplicación de silencios en el ingreso de datos de tarjetas de pago.
  • Verint: Esta solución se basa en el uso de pausas automáticas en la grabación cuando se proporcionan los datos de tarjetas. Así mismo, ofrece cifrado en el almacenamiento y enmascaramiento de datos en la visualización.
  • Calabrio: Esta solución se basa en el uso de pausas automáticas en la grabación cuando se proporcionan los datos de tarjetas.
  • CallCopy:  Esta solución se basa en el uso de pausas automáticas en la grabación cuando se proporcionan los datos de tarjetas.

REFERENCIAS

http://www.pcihispano.com


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

Sersecure alcanza la segunda fase en el BBVA Open Talent

El BBVA Open Talent es una competición de start-ups organizada por el Centro de Innovación del BBVA en la que se apoya la creación y desarrollo de proyectos innovadores de base tecnológica con ayudas de hasta 100.000 euros para los ganadores. Se trata de una plataforma abierta que quiere ofrecer la oportunidad de desarrollar y dar visibilidad al mayor número de proyectos relacionados con el emprendimiento, nuevos modelos de negocio en banca, la tecnología, Internet y los negocios. Este año 2013 la competición se ha divido en dos áreas: Nueva Banca e Innovación y tecnología. Desde Internet Security Auditors hemos presentado nuestro proyecto Sersecure dentro de la categoría de Innovación y Tecnología y se ha alcanzado la segunda fase de la stat-up competition.

Sersecure es una spin-off que comercializa servicios de Seguridad TIC desde la nube, aprovechando todo el conocimiento y la experiencia que desde Internet Security Auditors se ha venido realizando desde hace más de 10 años. Sersecure se lanza con el servicio Sersecure AntiMalware Service, que es una herramienta de vigilancia AntiMalware enfocada a todo tipo de organizaciones que necesitan monitorizar su dominios web en Internet. El servicio proporciona el escaneo, análisis y soporte especializado frente a web Malware de tal forma que las organizaciones puedan conocer con la máxima prontitud si su webs han sido vulneradas y se encuentran sirviendo Malware a sus usuarios y clientes, así como disponer de información relevante de las actividades llevadas a cabo por el Malware.

En la segunda fase del BBVA Open Talent se votan de forma pública todos los proyectos que han resultado seleccionados y las 20 start-ups más votadas pasarán a la tercera fase de presentación ante el jurado.  La votación acaba el lunes 27 así que ¡ayúdanos y vota por nuestro proyecto! Sólo tienes que acceder al siguiente enlace y realizar un pequeño registro:
https://www.centrodeinnovacionbbva.com/opentalent/votaciones/1305-sersecure

¡Muchas gracias por tu participación!

¿Qué es y qué podemos esperar del cloud computing? (I)

Cloud computingA día de hoy, ¿quién no ha oído hablar del cloud computing? Pero, ¿Qué es? ¿Qué podemos esperar? ¿Cómo nos puede ayudar? A continuación os vamos a explicar a modo un poco de resumen todas estas preguntas que nos rondan por la mente y que probablemente nos ayuden a la hora de elegir.
La computación en la nube, es un concepto conocido también bajo los términos “servicios en la nube”,  y proviene del inglés cloud computing. Es un prototipo que permite ofrecer servicios de computación a través de Internet. Con Cloud Computing, todo lo que se encuentra en el Datacenter de una compañía es ofrecido como un servicio.

Permite a los usuarios acceder a un catálogo estándar de servicios, respondiendo a las necesidades del negocio de forma flexible y permitiendo adaptarse a las demandas de los usuarios que podrán disponer siempre de los diferentes servicios ofrecidos independientemente de dónde se encuentren.

Algunas de las características principales que nos ofrece el cloud computing son:
  • Servicio a demanda
  • Pool de recursos independientes de la ubicación
  • Elasticidad y flexibilidad
  • Servicio medible

TIPOS DE CLOUD

Podemos distinguir entre tres tipos de cloud computing.
  • Cloud Privada: Infraestructura on-demand implementada y administrada exclusivamente por la organización, que controla que servicios ofrecer.  Es la mejor opción para las compañías que necesitan una alta protección de datos y asegurar el acceso continuo a los servicios sin la dependencia del acceso a Internet.
  • Cloud Pública: Infraestructura on-demand  implementada de manera que puede ser accedida de manera pública y desde internet. Generalmente la ofrecen empresas de comunicación y datacenters y se accede de forma estándar desde internet.
  • Cloud Hibrida: Se combinan los modelos de nubes públicas y privadas, donde el cliente es propietario de una parte de la infraestructura, mientras comparte otra. 

¿QUÉ NOS APORTA EL CLOUD COMPUTING?

  • Se integra de forma fácil y rápida con los demás servicios de red utilizados en la empresa.
  • Sus infraestructuras tienen mayor capacidad de adaptación y recuperación completa, en caso de pérdida de datos, y reduce al mínimo los tiempos de inactividad.
  • Podemos prescindir de instalar cualquier tipo de hardware, ya que éste es el proveedor de la infraestructura o plataforma el que lo proporciona.
  • Implementación más rápida y con menos riesgos, ya que se comienza a trabajar más rápido y no es necesaria una gran inversión.
  • Actualizaciones automáticas que no afectan negativamente a los recursos de TI.

DESDE EL PUNTO DE VISTA TÉCNICO

  • Automatización. Permite automatizar la gestión de la infraestructura mediante scripts u otras soluciones, permitiendo desplegar nuevas aplicaciones, o gestionar recursos de manera automática.
  • Escalabilidad. Ya sea en forma automática o en forma manual, es posible escalar los recursos que una aplicación necesita en forma dinámica y on-demand. 
  • Movilidad. Existe una independencia del dispositivo y la ubicación, lo que permite que los usuarios puedan acceder a los sistemas usando un navegador de Internet independiente de su ubicación geográfica y del sistema operativo o computador.
  • Disponibilidad. La infraestructura y arquitectura de un Data Center diseñado como una Cloud, está especialmente diseñada con alta redundancia para asegurar la Continuidad Operacional y la Continuidad del Negocio.

¿PARA QUÉ SE UTILIZA EL CLOUD COMPUTING?

Desde finales de 2012 las empresas utilizan el cloud computing para su cliente externo de aplicaciones. Gracias a ello, no se ven obligadas a disponer de un determinado ancho de banda, pudiendo escalar fácilmente sus aplicaciones externas sin necesidad de comprar nuevo hardware o software.

A corto plazo, las empresas podrían utilizar el cloud computing para el almacenamiento de gran cantidad de datos, (Big Data) que se está convirtiendo en una de las utilidades más usadas del cloud computing gracias a la escalabilidad de la nube y lo fácil que resulta instalar sistemas con herramientas.


Autor: Lidia Buendia
Departamento de Marketing

La gira europea de OWASP llega a Barcelona

¡Reserve en su agenda los días 13 y 14 de junio!

OWASP Europe Tour 2013Barcelona se incluye en la gira que OWASP (Open Web Application Security Project) realiza este año en 12 ciudades europeas.

El objetivo del OWASP Europe Tour 2013 es crear conciencia sobre la seguridad del software en la región europea, de forma que las personas y las organizaciones puedan tomar decisiones informadas sobre los verdaderos riesgos de la seguridad en las aplicaciones.

El capítulo OWASP Spain, liderado por Vicente Aguilera Díaz (socio y director del departamento de Auditoría en Internet Security Auditors), organiza el evento de Barcelona en el que participarán reconocidos expertos de la comunidad internacional.
 
El evento se celebrará los días 13 y 14 de junio en La Salle:
  • Jueves 13 de junio: sesiones de formación
  • Viernes 14 de junio: conferencias abiertas y gratuitas
Consulte la agenda e inscríbase ahora de forma gratuita a las conferencias:
https://www.owasp.org/index.php/EUTour2013#Barcelona

¡Le esperamos!

Participamos en los talleres de seguridad del I Encuentro de madres Blogueras

El sábado 8 de junio se celebra en la Casa del Lector del Centro Cultural Matadero en Madrid, el I Encuentro de Madres Blogueras organizado por Madresfera, El Mundo y YoDona.

El objetivo del evento es servir de foro de encuentro “desvirtualizador” a todas las madres blogueras y poner en contacto directo a marcas y madres. Se han organizado diversos Talleres y Mesas Redondas durante todo el día con la colaboración de marcas, expertos y bloggers.

Sara Blanco, del departamento de Consultoría, aportará su granito de arena ayudando a estas madres a protegerse contra las amenazas que corren por Internet, participando en uno de los talleres que se realizan:

Taller 2 (16:15): Peligros en la Red: Estoy Protegido o Soy Vulnerable
  • Como proteger tus Accesos (tu blog, tu correo, tus redes sociales, etc.)
  • Como proteger tu identidad y la de tu familia (Fotos, revelación de información en la red, etc.)
  • El Bueno, el Feo y el malo: hackers, trolls y ladrones de información.
  • Identidades falsas: ¿hasta dónde es legal?
Primer encuentro de madres blogueras


Tengo una cuenta en Internet, ¿he dicho cuenta? o ¿era un “cuento”?

Como casi todo el mundo, tengo una cuenta en varias redes sociales, y también un correo electrónico que uso habitualmente para que me manden información de temas que me pueden  interesar: mi nombre es pericoeldelospalotes y mi cuenta de correo electrónico es "pericoeldelospalotes@porqueyolovalgo.com"

A parte de la anécdota en la que muchos nos podemos sentir identificados, es habitual encontrarnos cuentas o usuarios con nombres extravagantes, usuarios que son un puro número o personajes de película.

Esto nos lleva a reflexionar sobre la legalidad de no utilizar nuestro nombre en Internet, evidentemente no hablamos de suplantación de identidades, sino de saber si un  usuario debe o no identificarse en su actividad en la Red.

El debate está servido, ¿puedes negarte a revelar tu verdadera identidad?, ¿miran para otro lado los prestadores de servicios en Internet, con tal de ganar cuota de mercado en sus servicios?
A favor, los que opinan que es recomendable el anonimato. Argumentan que este facilita la libertad de expresión, evita el ciberacoso y otros males del mundo Internet.

En contra, los que aducen que supone un problema cuando la actividad es con fines delictivos ya que complica las investigaciones.

Pero, ¿nos hemos parado a pensar que estamos haciendo cuando accedemos a un servicio en Internet?
La respuesta es sencilla, para perfeccionar un contrato entre dos partes y fijar los primeros límites nos vamos al  Código Civil, hagamos un pequeño repaso:

Artículo 1254: El contrato existe desde que una o varias personas consienten en obligarse, respecto de otra u otras, a dar alguna cosa o prestar algún servicio. Artículo 1255: Los contratantes pueden establecer los pactos, cláusulas y condiciones que tengan por conveniente, siempre que no sean contrarios a las leyes, a la moral, ni al orden público.
Hasta aquí parece que si el operador no me “impone” dar un nombre real, podría utilizar datos que no se corresponda con mi identidad.

El problema puede surgir en aquellas situaciones en las que la ley exige a los operadores que identifiquen específicamente, quien es el usuario Por ejemplo, la Ley Orgánica de Protección de Datos obliga comprobar si estamos ante datos de un menor o, en el caso de acceso a páginas de adultos, donde se impone por protección, tener una edad mínima para el acceso los servicios.

Por eso, y a través de la aceptación de las condiciones de uso, que se nos muestran cuando creamos nuestros perfiles, es donde afirmamos (generalmente sin leer) que entendemos y aceptamos que debemos facilitar información veraz sobre  nuestra identidad.

No diríamos  que ocurra siempre, pero como lo importante para el prestador del servicio suele ser subir su cuota de mercado, su cantidad de usuarios o su ranking con relación a la competencia, en muchas ocasiones, no se suele comprobar, y por tanto no se deja/ impide el suministro de  un servicio, si se da de alta el usuario con nombre “pericoeldelospalotes”.

Además, la cobertura legal se la proporcionamos nosotros mismos al operador, como usuarios, al suscribir “voluntariamente” las condiciones de uso del servicio.

En resumen, podemos decir que la legislación actual no regula el anonimato en Internet ya que se busca que la actividad que se genera sea mediante un registro con datos veraces. Pero los proveedores de servicio dejan en manos del usuario el cumplimiento de la obligación.


Autor: María del Carmen Areces
Departamento Comercial


Participamos en el CyberSecurity Government Perú 2013

El pasado 10 de abril tuvo lugar en la ciudad de Lima (Perú) el segundo congreso de seguridad informática y seguridad de la información de los gobiernos más importante del país, el CyberSecurity Government 2013, organizado por el capítulo de ISSA Perú y en el que Internet Security Auditors participó como sponsor.

En el evento se trataron temas diversos como la seguridad en las aplicaciones, la protección de datos de carácter personal y las responsabilidades e implicaciones de las organizaciones en la seguridad de la información. Como sponsor tuvimos la posibilidad de participar junto con las autoridades y organización en la mesa de apertura y cierre del evento, haciendo un resumen de valoración y comentarios sobre la importancia de la seguridad de la información en la administración pública.

También hubo bastantes presentaciones centradas en tecnología y productos de diferentes fabricantes del sector así como algunos talleres prácticos sobre revisión de seguridad en aplicaciones, sin duda uno de los puntos relevantes junto con los aspectos de la reciente legislación y regulación peruana relativa a la persecución del fraude.

Fue una gran oportunidad para nosotros poder participar y conocer de primera mano las inquietudes de la administración pública en Perú en cuanto a la seguridad se refiere en el que, sin duda, es un evento referente en el país andino en cuanto a Seguridad TIC se refiere.

CyberSecurity Government 2013 - Lima (Perú) CyberSecurity Government 2013 - Lima (Perú)
CyberSecurity Government 2013 - Lima (Perú) CyberSecurity Government 2013 - Lima (Perú)