SAFE. Guía para proteger tu vida digital y tu privacidad
Showing posts with label PCI. Show all posts
Showing posts with label PCI. Show all posts

Jun 27, 2022

Análisis de PCI DSS v4.0

Desarrollado por David Acosta en abril de 2022

El primer semestre del año 2022 ha sido bastante interesante para la comunidad de la ciberseguridad debido a la publicación del estándar ISO/IEC 27002:2022 – Information security, cybersecurity and privacy protection — Information security controls en febrero y la publicación de la versión 4.0 del estándar PCI DSS en marzo. En ambos casos, el objetivo fue actualizar los controles de seguridad existentes y agregar nuevos requisitos para adaptarlos a los cambios tecnológicos y a las amenazas de ciberseguridad actuales.

En el caso de PCI DSS v4.0, desde PCI Hispano han preparado una serie de artículos en donde se realizará un análisis detallado del proceso de desarrollo de esta versión del estándar, los cambios en los requisitos y el proceso de adaptación desde la versión 3.2.1 a la versión 4.0, entre otros temas.

En la primera parte de esta serie se analiza la historia detrás de la versión 4.0 del estándar, las variables que influyeron en su cambio y el proceso de revisión y publicación asociado. A continuación, en entregas subsiguientes, se realiza una revisión a los cambios en los requerimientos y en los documentos de reporte y finalmente se propondrá un plan de acción para el alineamiento de los controles de la versión 3.2.1 a la versión 4.0 para cumplir con los plazos establecidos por el PCI SSC y las marcas de pago.

Sep 20, 2021

Novedades de PCI DSS v4.0

Debido a la ampliación en el periodo de recepción de comentarios y sugerencias para los documentos de validación de PCI DSS (plantillas del Report on Compliance (ROC), Self-Assessment Questionnaires (SAQs) y Attestation of Compliance (AOC), el PCI Security Standards Council (PCI SSC) ha anunciado formalmente que la publicación de la versión 4.0 del estándar PCI DSS será pospuesta hasta finales del año 2021 principios del año 2022 (primer trimestre), aunque las fechas oficiales serán informadas en los próximos meses.

Por lo que se sabe, el PCI SSC continuará por la misma línea de publicar sus estándares fuera de los ciclos de 3 años establecidos originalmente, con lo cual su programa del ciclo de vida para la publicación de PCI DSS y PA DSS se convertirá oficialmente en obsoleto. Se ha anunciado la publicación de la versión 4.0 de PCI DSS durante el primer trimestre de 2022. Esta es una fecha estimada, ya que todo depende del trabajo de análisis de los comentarios recibidos en 2021 por parte de los grupos de trabajo.

El cambio en esta fecha afectará también a los periodos de transición de PCI DSS v3.2.1 a PCI DSS v4.0 y a las fechas de cumplimiento de varios requerimientos (future-dated requirements).

Por ahora (si no se presentan más cambios), las fechas de desarrollo y publicación del estándar PCI DSS v4.0 serán las siguientes:

Por otro lado, las fechas de transición entre la versión 3.2.1 y la versión 4.0, así como las fechas de los requerimientos que se deben cumplir en el futuro serán las siguientes:

¿Qué novedades traerá la versión 4.0 de PCI DSS?

  • Dentro de las novedades que se incorporarán en esta nueva versión se encuentran las siguientes:
  • Alineación de los controles de autenticación con las guías de contraseñas y autenticación multifactor (MFA) del NIST (Special Publication 800-63), incluyendo la protección de cuentas críticas, restricción del uso de contraseñas de un solo uso ("One Time Password" – OTP) basadas en SMS y correo electrónico y recomendaciones generales para la selección de contraseñas y su complejidad.
  • Uso de encriptación en el tráfico dentro de redes confiables.
  • Incorporación de varios controles del Anexo 3 de PCI DSS (Validación suplementaria de entidades designadas) como controles regulares de PCI DSS.
  • Adición de soporte de metodologías adicionales para la gestión de seguridad del entorno.
  • Optimización de los métodos y procedimientos de validación.
  • Mejora de controles existentes relacionados con monitorización para incorporar los cambios tecnológicos actuales.

Fuente: PCI Hispano

Aug 12, 2020

APIs con certificación PCI DSS, RGPD y Open Banking

¿Qué es la certificación PCI DSS?

PCI DSS (PaymentCardIndustry – Data Security Standard) es un estándar de seguridad de alto nivel, indicado para todo el ecosistema de empresas que graban o procesan datos de tarjetas de crédito y débito – cubriendo desde dispositivos electrónicos, hasta aplicaciones e infraestructuras.

Este estándar fue establecido por PCI Security Standards Council (PCI SSC), formado por las grandes compañías de tarjetas, para tornar el ecosistema de pagos electrónicos más seguro y garantizar la adhesión y confianza de los clientes.

¿Las APIs necesitan ser PCI Compliant?

Cualquier empresa que acepta pagos con tarjeta de crédito/débito, procesando o almacenando datos de estas tarjetas, es indicada para tener la certificación PCI DSS. Este escenario es cada vez más común, principalmente para empresas involucradas en sectores como Mercado Minorista, Servicios Financieros y proveedores de tecnología.

En el caso que sus APIs trafiquen alguna información relacionada a tarjetas de pagos, entonces es muy importante que usted y los colaboradores técnicos involucrados en la sustentación de estas APIs cumplan los requerimientos y posean la certificación PCI.

¿Por qué la certificación PCI es importante?

Las personas cada vez más utilizan tarjetas de crédito y débito (físicas o virtuales), en lugar de dinero, para realizar pagos. Estos medios electrónicos promueven facilidades no solamente para los consumidores, sino también para los criminales.

Usando exploit kits de uso simple, hackers de diversas partes del mundo explotan vulnerabilidades en sistemas y realizan crímenes en escala, causando enormes perjuicios y convirtiéndose en un gran riesgo para las empresas. Este riesgo no involucra solamente vulnerabilidades externas, sino también amenazas de origen interno.

En el caso que ocurra fuga de datos, esto puede traer consecuencias graves como: penalidades, multas, pérdida de la confianza de los clientes y de ventas futuras, costos adicionales de adecuación a las normas, prohibición de procesamiento de pagos can los tarjetas, e incluso la quiebra.

Según el Report 2019 CostOf A Data Breach, las fugas de datos ocurridos en el 2019 generaron un costo promedio de US$ 3,92 millones cada uno para las empresas.

Sin la certificación PCI, las empresas no lograr firmar acuerdos con muchas empresas del ecosistema de pagos. Obtener una certificación PCI significa que están siendo aplicadas prácticas fundamentales en seguridad de datos.

Siendo así, poseer el certificado PCI y colaboradores PCI compliant puede traer beneficios como:
  • Más alto nivel de seguridad de datos
  • Diferenciación de los competidores
  • Reducción de riesgos
  • Aumento en la confianza de los consumidores
  • Facilidad en firmar acuerdos para ser proveedores de las grandes empresas que trafican pagos de tarjeta.
  • Salir adelante y acortar la preparación para las regulaciones de privacidad como GDPR, LGPD e incluso, Open Banking.

¿Qué exige la certificación PCI?

Las recomendaciones del PCI son buenas prácticas de seguridad de la información y suministra una metodología clara de lo que debe ser alcanzado.

La certificación PCI intenta alcanzar 6 objetivos, para esto, fueron definidos 12 requerimientos, que son verificados por una serie de procedimientos de prueba y conformidad, siendo confirmados por una entidad autorizada para realizar la certificación:

Objetivo 1 – Construir y mantener la seguridad de red y sistemas

  1. Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta
  2. No usar estándares dispuestos por el proveedor para contraseñas del sistema y otros parámetros de seguridad

Objetivo 2 – Proteger los datos del titular de la tarjeta

  1. Proteger los datos almacenados del titular de la tarjeta
  1. Cifrar la transmisión de los datos del titular de la tarjeta en redes abiertas y públicas

Objetivo 3 – Mantener un programa de gestión de vulnerabilidades

  1. Proteger todos los sistemas contra malware y actualizar regularmente programas o software antivirus
  2. Desarrollar y mantener sistemas y aplicaciones seguros

Objetivo 4 – Implementar medidas rigurosas de control de acceso

  1. Restringir el acceso a los datos del titular de la tarjeta de acuerdo con la necesidad de conocimiento para el negocio
  2. Identificar y autenticar el acceso a los componentes del sistema
  3. Restringir el acceso físico a los datos del titular de la tarjeta

Objetivo 5 – Monitorear y probar las redes regularmente

  1. Supervisar y monitorear todos los accesos con relación a los recursos de la red y a los datos del titular de la tarjeta
  2. Probar regularmente los sistemas y procesos de seguridad

Objetivo 6 – Mantener una política de seguridad de informaciones

  1. Mantener una política que aborde la seguridad de la información para todas los equipos
Estos procedimientos de prueba están relacionados con 4 niveles de seguridad (el nivel 1 es el más alto) de acuerdo principalmente con el volumen de transacciones:

¿Qué tiene que ver la certificación PCI con GDPR y con LGPD? ¿Puede ayudar?

GDPR (General Data ProtectionRegulation) entró en vigor en la Unión Europea en el 2018 y se aplica a todas las empresas que guardan o procesan datos que identifiquen a ciudadanos europeos, proveyendo una serie de derechos para garantizar la propiedad, la finalidad, el consentimiento, la transparencia y la privacidad a los individuos sobre los datos relacionados a ellos.

Regulaciones similares están siendo desarrolladas por diversos países. En Brasil, el congreso nacional está definiendo la aplicación de una regulación similar al GDPR (LGPD – Ley General de Protección de Datos) en Agosto/2020.

Están sujetas a las multas, en el caso de GDPR, todas las empresas que operan en el Espacio Económico Europeo, independientemente de su país de origen, de hasta 4% de la facturación global o 20 millones de euros – lo que sea mayor, y hasta la suspensión de las actividades con la UE.

El cumplimiento de estas regulaciones colocadesafíos técnicos y de negocio para las empresas, que necesitan protegerse de las amenazas y aprovechar las oportunidades que se abren. No obstante, aunque dejen explícito los derechos de los ciudadanos, estas regulaciones no suministran una guía clara de cómo estar en conformidad.

A pesar de que el alcance de protección de datos del PCI sea menor (datos de tarjetas de pagos), está contenido en el alcance de datos personales de LGPD y de GDPR. Además de esto, el proceso de certificación PCI provee una metodología definida para que su empresa gane capacidad de mapear y proteger datos sensibles durante el procesamiento, transmisión y almacenamiento.

Estar PCI compliant indica que su empresa está atenta a las prácticas más maduras de protección de datos, y está al frente de la competencia en la adecuación a GDPR y a LGPD.

Open Banking

Los bancos centrales de varios países están desarrollando regulaciones similares a PSD2 de la Unión Europea, exigiendo de los bancos la apertura de datos bancarios y servicios de pagos a través de APIs, para ser consumidas por empresas terceras que posean el consentimiento de los usuarios.

El BC de Brasil está planificando aplicar una regulación similar a PSD2 para Open Banking antes del inicio del 2º semestre/2020.

Esta regulación tiene como objetivo aumentar la competencia en el sector y da oportunidades para que las empresas terceras se integren a los bancos vía APIs, y utilizando estos datos, suministren ofertas y mejores experiencias para los consumidores.

Estas oportunidades no están restringidas a las empresas del sector financiero, también están siendo evaluadas por grandes empresas minoristas, telecom, utilities – que comienzan a ofrecer servicios financieros propios.

Para aprovechar las posibilidades de esta regulación, en lo que se refiere a los pagos con tarjetas, la certificación PCI es un paso esencial. Además de esto, se discute la necesidad de una certificación similar al PCI DSS para la protección de los datos bancarios. Estar familiarizado con las prácticas exigidas en el PCI DSS acelera mucho la preparación para desarrollar negocios basados en Open Banking.

Fuente: Sensedia

Mar 27, 2020

Controles técnicos de PCI DSS: WAF (Web Application Firewall)

Aquí se describirán de forma detallada los controles de seguridad lógica exigidos por el estándar PCI DSS entre los cuales se encuentran los IDS/IPS, los antivirus, los cortafuegos, los analizadores de código estático, el FIM (File Integrity Monitoring), entre otros.

Todos los artículos de la serie "Controles técnicos de PCI DSS":
En esta primera parte  analizaremos el WAF (Web Application Firewall), un elemento crítico para la protección de aplicaciones web.

¿Qué es un WAF (Web Application Firewall)?

Un WAF (Web Application Firewall) es una solución de seguridad para el análisis específico de tráfico HTTP en busca de potenciales contenidos maliciosos como XSS (Cross Site Scripting) y SQL Injection. Va más allá de los controles provistos por un IDS/IPS (Intrusión Detection System / Intrusion Prevention System) y de un cortafuegos (firewall), debido a que funciona exclusivamente en la capa de aplicación (que es la capa superior de los modelos OSI y TCP/IP), lo que le permite realizar análisis mucho más detallados y particulares del tráfico HTTP, entrando a complementar y reforzar la seguridad provista por estos otros dos controles. Esta solución puede ser implementada como un dispositivo auto-contenido dedicado (appliance), como un módulo de software en el mismo servidor donde se encuentra el servicio web o como una funcionalidad adicional en un equipo independiente, como en un firewall UTM (Unified Threat Management – Gestión Unificada de Amenazas), por ejemplo.

Para que el WAF tenga completa visibilidad del tráfico HTTP se debe tener en cuenta:
  • Debe ser desplegado delante del servidor web (en el caso de appliances) o antes de la llegada del tráfico HTTP al servicio web (en el caso de un módulo de software) con el fin de monitorizar cualquier tráfico entrante y saliente. Su funcionalidad se asimila a la de un proxy, que actúa como intermediario y como punto de convergencia del tráfico de un servicio. De esta manera no existirán caminos alternos inseguros que puedan dejar la aplicación sin protección.
  • Si se emplea cifrado en HTTP (es decir, HTTPS empleando SSL/TLS) es importante tener presente que el WAF debe poder analizar el contenido descifrado, de lo contrario no podría detectar ataques dado que la información estaría cifrada. Por ello, se debe ubicar el WAF después de la finalización del túnel HTTPS.
En términos de seguridad, un WAF funciona de una manera similar a como lo hace una solución antivirus: puede trabajar con base en patrones de firmas de ataques y realizar análisis heurísticos (de comportamiento y de lógica) del tráfico HTTP para prevenir potenciales ataques no conocidos. Adicionalmente, es lo bastante configurable para permitir que el administrador defina sus propias reglas y las pueda adaptar a su entorno particular. Por otro lado, puede ser configurado para trabajar en modo detección (identifica el ataque y lo registra en un log) o detección/prevención (aparte de identificar y registrar el ataque, realiza una acción preventiva para evitar que el ataque llegue al servicio web).

¿Qué requerimientos de PCI DSS están relacionados con el WAF?

Un WAF es el complemento ideal en la fase de despliegue y puesta en marcha de un desarrollo web que sigue un Secure SDLC (Software Development Life Cycle), ya que protege la aplicación en casos excepcionales en los cuales exista una vulnerabilidad no detectada durante el proceso de desarrollo. Por ello, hace parte opcional (*) del requisito 6 "Desarrolle y mantenga sistemas y aplicaciones seguras":
6.6 En el caso de aplicaciones web públicas, trate las nuevas amenazas y vulnerabilidades continuamente y asegúrese de que estas aplicaciones se protejan contra ataques conocidos con alguno de los siguientes métodos:
– Instalación de una solución técnica automática que detecte y prevenga ataques web (por ejemplo, firewall de aplicación web) delante de aplicaciones web públicas a fin de controlar el tráfico continuamente.

(*) Es opcional, ya que la otra opción consiste en la realización de un análisis de vulnerabilidades web, tema del que hablaremos en un próximo artículo de esta serie.

Si se opta por la implementación de un WAF, las condiciones requeridas para que esta solución cumpla con PCI DSS son las siguientes:

Revise los parámetros de la configuración del sistema y entreviste al personal responsable para verificar que se haya implementado una solución técnica automática que detecte y prevenga ataques web (por ejemplo, un firewall de aplicación web) de la siguiente manera:
  • Se encuentre delante de las aplicaciones web públicas para detectar y prevenir ataques web.
  • Funcione activamente y esté actualizada, según corresponda.
  • Genere registros de auditoría.
  • Esté configurada para bloquear ataques web o para generar una alerta.

Criterios para la elección de una solución WAF para PCI DSS

A continuación, algunos consejos a tener en cuenta en el momento de la elección de un WAF para un entorno de cumplimiento PCI DSS:
  • Tener claro que un cortafuegos (firewall) y/o un IDS/IPS no son un WAF. Son soluciones distintas, que trabajan de forma conjunta y de ninguna forma son excluyentes. Un cortafuegos o un IDS/IPS no pueden remplazar a un WAF y viceversa.
  • Como mínimo, debe poder detectar las vulnerabilidades listadas en el OWASP Top Ten
  • Debe permitir una adaptación y personalización al entorno analizado, facilitando la edición y adición de nuevas reglas e inclusive "aprender" del entorno analizado y crear reglas de forma dinámica
  • Debe contar con características que le permitan interactuar y analizar diferentes tecnologías relacionadas con aplicaciones web, tales como XML, SOAP, WSDL, XML-RPC, UDDI, JSON, etc.
  • Debe contar con actualizaciones constantes, tanto de componentes como de firmas (si emplea dicha funcionalidad)
  • Para garantizar un comportamiento adecuado, debe manejar una tasa muy baja de falsos positivos con el fin de no bloquear peticiones legítimas y afectar el negocio. Para ello, una fase previa de adecuación al entorno es recomendable.
  • Tener presente que el WAF se convierte en un elemento más dentro del flujo HTTP e inclusive puede convertirse en un cuello de botella, penalizando el desempeño del aplicativo, por lo que es necesario realizar pruebas de comportamiento y definir acciones en caso de problemas con esta solución.
Adicionalmente, se pueden emplear como referencia los documentos «OWASP Best Practices: Use of Web Application Firewalls» y los criterios de evaluación de WAF del Web Application Security Consortium. En todo caso, el concepto objetivo de un QSA durante el proceso de elección e implementación de una solución de WAF es altamente recomendable.

Soluciones comerciales de WAF

En el mercado existen múltiples soluciones de WAF comerciales (licenciadas). Un buen punto de inicio es el cuadrado mágico de Gartner (aquí el cuadrado mágico de WAF de Junio de 2014), que analiza diferentes soluciones y las sitúa en un «cuadrado» con base una serie de variables definidas. Las soluciones más destacadas son:
Por otro lado, muchas de estas soluciones están migrando hacia aplicaciones SaaS (Software as a Service) basados en la nube (Cloud Computing), que por lo general requieren una redirección de tráfico realizando cambios en los registros de los DNS o instalación de agentes en el servidor web. Entre ellas se pueden enumerar:

Soluciones OpenSource de WAF

Algunas de las soluciones de WAF basadas en OpenSource son:
Fuente: PCIHispano

    Nov 11, 2019

    PCI DSS v.3.2.1 y la implementación de NIST CSF

    El marco de trabajo de ciberseguridad del NIST (NIST Cybersecurity Framework – NIST CSF) se ha convertido en uno de los documentos de referencia más reconocidos y completos para gestionar el establecimiento y monitorización de una estrategia de ciberseguridad. Desde su primera publicación en el año 2014 entró a complementar a otros marcos de trabajo y estándares más maduros (como CIS CSC, COBIT o ISO/IEC 27001:2013), logrando bastante aceptación por su facilidad de implementación, documentación disponible (incluyendo una traducción al español), herramientas para facilitar su implementación y arquitectura. Ha sido desarrollado por el Gobierno de EE.UU. a través del Instituto Nacional de Estándares y Tecnología (National Institute of Standards and Technology – NIST) como guía de implementación voluntaria para responsables y operadores de infraestructuras críticas para prevenir, detectar y responder ante ataques cibernéticos a través de una taxonomía de alto nivel y una metodología asociada para evaluar y gestionar sus resultados, permitiendo a las organizaciones realizar las siguientes tareas:
    1. Describir su postura actual de seguridad cibernética.
    2. Describir su objetivo deseado para seguridad cibernética.
    3. Identificar y priorizar oportunidades de mejora dentro del contexto de un proceso continuo y repetible.
    4. Evaluar el progreso hacia el objetivo deseado.
    5. Comunicarse entre las partes interesadas internas y externas sobre el riesgo de seguridad cibernética.

    Figura 1. Línea del tiempo del desarrollo del NSF

    Este marco de trabajo está dividido en tres partes principales:

    • Núcleo (Core): Es un conjunto de actividades de seguridad cibernética, resultados deseados y referencias aplicables que son comunes en todos los sectores de infraestructura crítica. El Núcleo presenta estándares, directrices y prácticas de la industria de una manera que permite la comunicación de las actividades y los resultados de seguridad cibernética en toda la organización, desde el nivel ejecutivo hasta el nivel de implementación u operaciones. El Núcleo del Marco consta de cinco funciones simultáneas y continuas: Identificar, Proteger, Detectar, Responder y Recuperar.
    • Los Niveles de Implementación del Marco (Levels) proporcionan un contexto sobre cómo una organización considera el riesgo de seguridad cibernética y los procesos establecidos para gestionar dicho riesgo. Los Niveles caracterizan las prácticas de una organización en un rango, desde Parcial (Nivel 1) hasta Adaptable (Nivel 4). Estos Niveles reflejan una progresión desderespuestas informales y reactivas a enfoques que son ágiles einformados sobre los riesgos.
    • Perfil del Marco (Profile), que representa los resultados que se basan en las necesidades empresariales que una organización ha seleccionado de las categorías y subcategorías del Marco. El Perfil se puede caracterizar como la alineación de estándares, directrices y prácticas con el Núcleo del Marco en un escenario de implementación particular. Los Perfiles se pueden utilizar para identificar oportunidades para mejorar la postura de seguridad cibernética comparando un Perfil «actual» (el estado «tal como está«) con un Perfil "objetivo" (el estado "por ser").

    Figura 2. Arquitectura del marco de trabajo de ciberseguridad del NIST (NIST CSF)

    Se puede encontrar información adicional del marco de trabajo del NIST en el documento "MARCO NIST CIBERSEGURIDAD: Un abordaje integral de la Ciberseguridad" de la Organización de Estados Americanos (OEA) y Amazon Web Services (AWS).

    PCI DSS + NIST CSF: llevando el cumplimiento normativo a otro nivel

    El PCI SSC (Payment Card Industry Security Standards Council) publicó en julio de 2019 el documento «Mapping PCI DSS v. 3.2.1 to the NIST Cybersecurity Framework v. 1.1» en el cual integra los requerimientos de seguridad del estándar PCI DSS v3.2.1 con el NIST Cybersecurity Framework v1.1. De esta forma, aquellas entidades que usen el NIST CSF como marco referencial para su estrategia de seguridad corporativa podrán integrar los requerimientos para la protección de los datos de tarjetas de pago dentro de un mismo marco global de trabajo.

    Figura 3. Integración entre NIST CSF y PCI DSS

    En este caso, es importante tener en cuenta que PCI DSS provee requerimientos de seguridad específicos para la protección de los datos de tarjetas de pago, mientras que el marco de trabajo de ciberseguridad del NIST (NIST CSF) proporciona objetivos más amplios en términos de seguridad y gestión de riesgos, sin limitarse solamente a los datos de tarjetas de pago. En este sentido, ambos documentos son complementarios pero no son excluyentes ni intercambiables.

    Previamente, el NIST CSF ya incluía un mapeo con otros estándares y marcos de trabajo. El PCI SSC ha complementado dicho mapeo incluyendo PCI DSS v3.2.1:

    Figura 4. Mapeo de requerimientos de PCI DSS dentro de NSC

    De esta manera, se facilita la identificación de elementos comunes entre los objetivos de seguridad corporativos, permitiendo que la organización pueda realizar ejercicios de auto-evaluación para determinar la efectividad y madurez de los controles implementados y prepararse ante una evaluación de PCI DSS, de NIST CSF o de ambos.

    Fuente: PCI Hispano

    Jul 24, 2019

    Fin del soporte de Windows 7 y Windows Server 2008 (WS2K8) y su impacto en PCI DSS

    Al igual que sucedió con Windows XP y con Windows 2003, Microsoft ya ha anunciado el fin del ciclo de vida ("End of Life" – EOL) para dos versiones de su sistema operativo Windows: Windows 7 (todas las versiones incluyendo el Service Pack 1) y Windows Server 2008 (todas las versiones incluyendo R2). Para ambos sistemas operativos, el EOL está programado para el día 14 de enero de 2020.

    A partir de ese día, estos sistemas operativos:
    • No recibirán más actualizaciones de seguridad,
    • No recibirán más actualizaciones vinculadas con mejoras o con correcciones funcionales,
    • No tendrán soporte técnico por parte del fabricante (Microsoft), y
    • Todo el contenido de los portales de soporte no será actualizado.
    Esto no solamente afectará a estos sistemas operativos sino también a otras aplicaciones como Microsoft SQL 2008, Microsoft Hyper-V Server 2008, Windows HPC Server 2008 R2, Windows Server Update Services 3.0 SP2 y Windows Storage Server 2008.

    A la par con esta fecha de obsolescencia, otros fabricantes y desarrolladores de aplicaciones para estas plataformas operativas (como antivirus, firewalls, monitorización, etc.) también empezarán a limitar o finalizar su soporte.

    ¿Qué implicaciones tiene esta noticia en el cumplimiento de PCI DSS?

    El requerimiento 6.2 de PCI DSS v3.2.1 establece lo siguiente:
    6.2 Asegúrese de que todo el software y componentes del sistema tengan instalados parches de seguridad proporcionados por los proveedores que ofrecen protección contra vulnerabilidades conocidas. Instale los parches importantes de seguridad dentro de un plazo de un mes de su lanzamiento. Debido a ello, tener dentro del alcance de cumplimiento un equipo con un sistema operativo sin soporte por parte del fabricante puede implicar un incumplimiento del estándar, aparte de los potenciales problemas derivados de las vulnerabilidades de seguridad no corregidas y la consecuente exposición a riesgos por parte del negocio.

    ¿Qué alternativas se tienen para gestionar el riesgo frente a esta plataforma no soportada?

    Con el fin de servir de guia a comercios y proveedores de servicio que deben cumplir con PCI DSS y se encuentran frente al inconveniente de contar dentro de su entorno con una plataforma operativa no soportada, la posición del PCI SSC fue descrita en la siguiente FAQ:
    Are operating systems that are no longer supported by the vendor non-compliant with the PCI DSS?
    PCI DSS Requirements 6.1 and 6.2 address the need to keep systems up to date with vendor-supplied security patches in order to protect systems from known vulnerabilities. Where operating systems are no longer supported by the vendor, OEM or developer, security patches might not be available to protect the systems from known exploits, and these requirements would not be able to be met.
    However, it may be possible to implement compensating controls to address risks posed by using unsupported operating systems in order to meet the intent of the requirements. To be effective, the compensating controls must protect the system from vulnerabilities that may lead to exploit of the unsupported code. For example, exhaustive reviews may need to be regularly performed to ensure that all known exploits for that operating system are continually identified and that system configurations, anti-virus, IDS/IPS, and firewall rules are continually updated to address those exploits. Examples of controls that may be combined to contribute to an overall compensating control include active monitoring of system logs and network traffic, properly-configured application whitelisting that only permits authenticated system files to execute, and isolating the unsupported systems from other systems and networks. Note that these examples may complement an overall compensating control, but these examples alone would not provide sufficient mitigation.
    Additionally, if an unsupported operating system is Internet-facing, it will be detected and reported as an automatic failure by an ASV scan. Detection of unsupported operating systems in an ASV scan will need to be addressed according to Addressing Vulnerabilities with Compensating Controls section of the ASV Program Guide.
    The use of compensating controls should be considered a temporary solution only, as the eventual solution is to upgrade to a supported operating system, and the entity should have an active migration plan for doing so. For assistance with compensating controls, and for questions about whether a specific implementation meets PCI DSS requirements, please contact a Qualified Security Assessor.
    Bajo este criterio, a continuación se enumeran las alternativas para la gestión de este inconveniente y que se pueden implementar para cumplir con PCI DSS:

    Migración/actualización a Windows 10 (para Windows 7) o a Microsoft Windows Server 2019 (para Windows 2008)

    Esta es la opción recomendada por Microsoft como camino directo frente a la notificación de finalización de soporte. Para ello, se ha creado una herramienta web que ofrece las siguientes alternativas:
    • Migrar a servidores en la nube (cloud) provistos por Microsoft Azure o cualquier otro proveedor (*)(**)
    • Migrar a servidores en la nube (cloud) provistos por cualquiera de los miembros del Cloud OS Network (*)
    • Migrar a servidores virtualizados
    • Instalar el nuevo sistema operativo en un hardware independiente
    (*) Tener presente que para servidores dentro del ámbito de cumplimiento de PCI DSS, la gestión de servicios de cloud en formato IaaS está cubierta por el requerimiento 12.8

    (**) Para Windows 2008, si estos sistemas operativos son migrados a Microsoft Azure podrán recibir 3 años adicionales de actualizaciones críticas e importantes.

    Así mismo, para Windows 2008 Microsoft ha creado un infográfico denominado "Windows Server 2008 and 2008 R2 EOS brochure" en el cual analiza los procesos de migración en función del rol del servidor en la red (Directorio Activo, servidor web, servidor de archivos, servidor de base de datos, etc.).

    Migración a una nueva plataforma operativa

    Otra alternativa es la migración a una nueva plataforma operativa. En función de las necesidades, la plataforma completa se puede migrar o se puede delegar determinados servicios en otros sistemas operativos, como GNU/Linux, HP-UX, AIX, etc.

    Uso de controles compensatorios

    Si se requiere de un plan temporal mientras que se procede con una migración definitiva, el uso de controles compensatorios puede ser una opción. Estos controles alternativos deben ser consultados con un QSA previo a su implementación para validar que efectivamente el riesgo es gestionado conforme con los criterios de PCI DSS.

    Algunos controles compensatorios que se pueden analizar son:
    • Uso de listas blancas de aplicación (application whitelisting)
    • Uso de controles complementarios para el aislamiento del servidor (usando firewalls personales, por ejemplo)
    • Empleando soluciones de HIDS/HIPS (Host IDS/IPS)
    Invitamos a adelantarse a este evento y a planificar y desplegar de forma inmediata los controles necesarios para la gestión de los potenciales riesgos asociados con un sistema operativo no soportado por el fabricante. Microsoft estima en 150 días (mínimo) el tiempo necesario para la migración de un sistema operativo a una nueva versión, por lo que es hora de ponerse manos a la obra.

    Fuente: PCIHispano

    Sep 27, 2018

    Publicada la versión 3.0 del estándar "PCI PIN – Security Requirements and Testing Procedures"

    En Agosto de 2018 el PCI SSC publicó la versión 3.0 del estándar PIN Security Requirements and Testing Procedures. Este documento hace parte de la familia de estándares PCI PIN Transaction Security (PTS) en donde también se encuentran PCI HSM (Hardware Security Module) y PCI POI (Point of Interaction), orientados a la protección del PIN (Personal Identification Number) en transacciones presenciales ("card present") en cajeros electrónicos y terminales de punto de venta (TPV) atendidas y desatendidas.

    La primera versión de PCI PIN (1.0) fue publicada en el año 2011 y la versión 2.0 fue publicada en 2014, con lo este estándar ya acumula 7 años de implementaciones a nivel mundial (para más información, ver el artículo La línea de tiempo del comité de estándares PCI SSC).

    Los objetivos de este estándar son:
    • Identificar los requerimientos mínimos de seguridad para transacciones de intercambio basadas en PIN.
    • Describir los requisitos mínimos aceptables para asegurar el dato del PIN y las claves de encriptación.
    • Asistir a todos los participantes del sistema de pago minorista en el establecimiento de garantías de que los datos del PIN de los titulares de tarjetas no se vean comprometidos.
    El estándar PCI PIN es de obligatorio cumplimiento para todas las instituciones adquirientes y agentes responsables del procesamiento de transacciones con PIN de las tarjetas de las marcas del PCI SSC (VISA, MasterCard, AMEX, Discover y JCB) incluyendo servicios de inyección de claves y gestión de certificados y debe ser usado en conjunción con otros estándares aplicables de la industria (PCI DSS, PCI P2PE, etc.).

    Novedades en la versión 3.0 de PCI PIN

    Para esta nueva versión (3.0), el PCI SSC ha optado por combinar los requerimientos de seguridad ("PIN Security Requirements") y los procedimientos de prueba ("Test Procedures") en un único documento, ya que en versiones anteriores se habían mantenido documentos separados.

    Respecto a esta nueva versión, uno de los cambios más representativos está en la reorganización de los requerimientos en tres grandes grupos, cada uno subdividido a su vez en "objetivos de control" ("Control Objectives"):
    1. Transaction Processing Operations: Anteriormente denominados "PIN Security Requirements", este grupo de controles aplican a cualquier entidad relacionada con procesos de adquiriencia y/o procesamiento de transacciones basadas en PIN.
    2. Normative Annex A – Symmetric Key Distribution using Asymmetric Keys: Requerimientos específicos para entidades adquirientes involucradas en la implementación de procesos de distribución de claves simétricas usando claves asimétricas (distribución remota de claves) o para aquellas entidades que ofrecen servicios de operación de autoridades de certificación (Certification Authorities – CA) empleadas para dichos propósitos. Su aplicación depende de las tareas realizadas por la entidad afectada:
      • Si se trata de una entidad adquiriente que también realiza funciones de distribución remota de claves, le aplicarán los controles del grupo "Transaction Processing Operations" y los controles del anexo A.
      • Si se trata de proveedores de servicio o de fabricantes de dispositivos de punto de interacción (POI) o de HSM que operen sistemas de distribución de claves actuando en nombre de una entidad adquiriente, deben cumplir la totalidad de los controles del anex.
    3. Normative Annex B – Key-Injection Facilities: Requerimientos para entidades que operan servicios de inyección de claves de adquiriente en dispositivos empleados para la captura del dato de PIN.

    En este punto, hay que resaltar que el estándar PCI PIN especifica los controles sobre las claves vinculadas a procesos que específicamente afecten al PIN. Cualquier clave empleada para la protección de otros datos de la tarjeta (PAN, por ejemplo) o que se use para funcionalidades de MAC está fuera del ámbito del documento.

    Por otro lado, dependiendo de las tareas realizadas, cada entidad puede estar sujeta a la aplicabilidad de requerimientos de diferentes secciones o al estándar completo. El apéndice A del estándar incluye una nueva matriz en la cual se indica la aplicabilidad de cada requerimiento en función de las labores desarrolladas.

    El listado de cambios entre la versión 2.0 y 3.0 se puede encontrar en el documento "PIN Security Requirements Modifications and Testing Procedures: Summary of Changes".

    Fechas límite para la retirada de claves 3DES (TDES) fijas para la encriptación de PIN y soporte al formato 4 de bloque de PIN

    En esta versión del estándar se han estipulado los siguientes plazos para el uso de claves fijas de 3DES (TDES) empleadas para la encriptación de PIN y el uso del formato 4 de bloque de PIN ( ISO PIN block format 4):
    • A partir del 1 de enero de 2023 todas las claves fijas de 3DES (TDES) empleadas para la encriptación de PIN en puntos de interacción (POI) y conexiones host-to-host no serán permitidas.
    • A partir del 1 de enero de 2023 todos los hosts deben soportar la desencriptación del formato 4 de bloque de PIN.
    • A partir del 1 de enero de 2025 todos los hosts deben soportar la encriptación del formato 4 de bloque de PIN.

    Fechas límite para la implementación de "key blocks" para claves de cifrado simétricas

    De la misma manera, se han definido las siguientes fechas para que las claves de encriptación simétricas sean manejadas en estructuras de key blocks (controles adicionales para proteger la integridad de las claves de encriptación).
    • Fase I: Se debe implementar la funcionalidad de "key blocks" para todas las conexiones internas y almacenamiento de claves dentro de los entornos de proveedores de servicios (esto puede incluir todas las aplicaciones y bases de datos conectadas a HSM). Fecha de entrada en vigencia: 1 de junio de 2019.
    • Fase II: Se debe implementar la funcionalidad de "key blocks" para todas las conexiones externas a asociaciones y redes. Fecha de entrada en vigencia: 1 de junio de 2021.
    • Fase III: Se debe extender la funcionalidad de "key blocks" a todos los hosts de comercios, terminales de punto de venta (TPV/POS) y cajeros electrónicos (ATM). Fecha de entrada en vigencia: 1 de junio de 2023.

    Otras consideraciones adicionales

    Finalmente, se han establecido los siguientes criterios adicionales:
    • Todas las entidades afectadas por el estándar deben mantener un inventario de todas las claves criptográficas empleadas en el entorno, incluyendo su nombre, su uso, el algoritmo usado y su longitud. De igual forma, se debe mantener un diagrama de flujo red esquemático que facilite la revisión de los requerimientos de seguridad.
    • El uso de ordenadores personales para la carga de claves, en donde los secretos en texto claro y/o las claves privadas y/o sus componentes puedan existir en memoria no protegida fuera del perímetro de seguridad del dispositivo SCD está planificado para ser retirado en fechas futuras.
    • El uso de inyección de secretos en texto claro o de material de claves privadas en un SCD está siendo planificado para ser retirado en fechas futuras. Solamente se permitirá la inyección de claves encriptadas.
    • En relación con el uso de determinados modelos o actualizaciones de dispositivos POI, serán las propias marcas de pago las que definan los criterios de despliegue y periodos de expiración y remplazo de estos equipos en campo de acuerdo con el estándar PCI PTS.
    • Es importante aclarar que son las marcas (y no el PCI SSC) las responsables de la definición y la gestión de los programas de cumplimiento asociados a este estándar, por lo que cada marca estipulará las fechas de cumplimiento, multas y forma mediante la cual se realizará el reporte de cumplimiento, así como los listados de empresas que pueden auditar.
    Fuente: PCIHispano

    Sep 11, 2018

    Guía práctica para alinear AWS con PCI DSS

    Cuando por consideraciones técnicas o administrativas se opta por delegar la gestión de ciertos componentes o de la totalidad de la infraestructura informática de la organización a un tercero, es imprescindible garantizar que los niveles de seguridad que dicho tercero aplicará serán iguales o mejores a los que la propia organización mantiene. Adicionalmente, si el entorno delegado debe cumplir con requerimientos legales o estándares de la industria, la responsabilidad de parte y parte debe quedar claramente estipulada en términos contractuales. Este es el caso de los servicios de Amazon en la nube (Amazon AWS) y el cumplimiento de PCI DSS.

    A pesar que el proveedor (CSP) ofrece una gran cantidad de servicios para configurar la infraestructura de forma segura, es finalmente el cliente el responsable de la seguridad de los datos y de la configuración de los servicios que se ejecutan sobre la capa provista por Amazon.

    Por otro lado, la complejidad en el despliegue de una solución de estas características implica un alto conocimiento tanto de la plataforma del CSP como de la aplicación de los controles de PCI DSS.

    En el artículo de David E. Acosta "Amazon y PCI DSS: guía práctica para alinear AWS en un entorno de datos de tarjeta de pago" [PDF] se ha plasmado el despliegue técnico de controles empleando las funcionalidades provistas por un CSP como Amazon.

    Con base en estas responsabilidades, se describe cómo se pueden utilizar los servicios provistos y certificados por Amazon para lograr el cumplimiento del entorno del cliente por cada uno de los requisitos de PCI DSS.
    • Requisito 1: Instale y mantenga una configuración de firewalls para proteger los datos de los titulares de las tarjetas
    • Requisito 2: No utilizar contraseñas de sistemas y otros parámetros de seguridad provistos por los proveedores
    • Requisito 3: Proteja los datos del titular de la tarjeta que fueron almacenados
    • Requisito 4: Cifrar la transmisión de los datos del titular de la tarjeta en las redes públicas abiertas
    • Requisito 5: Proteger todos los sistemas contra malware y actualizar los programas o software antivirus regularmente
    • Requisito 6: Desarrolle y mantenga sistemas y aplicaciones seguras
    • Requisito 7: Restrinja el acceso a los datos del titular de la tarjeta según la necesidad de saber que tenga la empresa
    • Requisito 8: Identificar y autenticar el acceso a los componentes del sistema
    • Requisito 9: Restringir el acceso físico a los datos del titular de la tarjeta
    • Requisito 10: Rastree y supervise todos los accesos a los recursos de red y a los datos de los titulares de las tarjetas
    • Requisito 11: Pruebe con regularidad los sistemas y procesos de seguridad
    • Requisito 12: Mantener una política que aborde la seguridad de la información de todo el personal
    Fuente: PCI Hispano

    Feb 1, 2018

    Requisitos de PCI DSS v3.2 que entran en vigencia en el 2018

    El 30 de abril de 2016 se publicó la versión 3.2 del estándar PCI DSS. Esta versión y sus revisiones posteriores incluían una serie de requisitos identificados temporalmente como “buenas prácticas” y se estipularon unas fechas límite a lo largo del año 2018 para su entrada en vigencia como requisitos obligatorios. Esto implica que a partir del día siguiente a la fecha límite, el requisito deberá contar con evidencia verificable de su ejecución.

    A continuación se encuentran identificados todos los controles que se convertirán en obligatorios durante el año 2018:
    Fecha de entrada en vigenciaRequisito de PCI DSS v3.2Aplicable a
    01 de febrero de 2018 3.5.1. Mantenga una descripción documentada de la arquitectura criptográfica que incluye:
    - Detalles de todos los algoritmos, protocolos y claves utilizados para la protección de los datos del titular de la tarjeta, incluidas la complejidad de la clave y la fecha de caducidad
    - Descripción del uso de la clave para cada tecla
    - Inventario de un HSM SMS y otros SCD utilizados para la gestión de claves
    Proveedores de servicios
    01 de febrero de 2018 6.4.6. Al término de un cambio significativo, deben implementarse todos los requisitos pertinentes de la PCI DSS en todos los sistemas y redes nuevos o modificados, y la documentación actualizada según sea el caso. Comercios y proveedores de servicios
    01 de febrero de 2018 8.3.1. Incorporar la autenticación de múltiples factores para todo acceso que no sea de consola en el CDE para el personal con acceso administrativo. Comercios y proveedores de servicios
    01 de febrero de 2018 10.8. Implementar un proceso para la detección oportuna y la presentación de informes de fallas de los sistemas críticos de control de seguridad, incluido pero no limitado a la falla de:
    - Firewalls
    - IDS/IPS
    - FIM
    - Antivirus
    - Controles de acceso físicos
    - Controles de acceso lógico
    - Mecanismos de registro de auditoría
    - Controles de segmentación (si se utilizan)
    Proveedores de servicios
    01 de febrero de 2018 10.8.1. Responder a las fallas de los controles de seguridad críticos en el momento oportuno. Los procesos para responder en caso de fallas en el control de seguridad son los siguientes:
    - Restaurar las funciones de seguridad
    - Identificar y documentar la duración (fecha y hora de inicio a fin) de la falla de seguridad
    - Identificar y documentar las causas de la falla, incluida la causa raíz, y documentar la remediación requerida para abordar la causa raíz
    - Identificar y abordar cualquier problema de seguridad que surja durante la falla del control de seguridad.
    - Realizar una evaluación de riesgos para determinar si se requieren más acciones como resultado de la falla de seguridad
    - Implementar controles para prevenir que se vuelva a producir la causa de la falla
    - Reanudar la supervisión de los controles de seguridad
    Proveedores de servicios
    01 de febrero de 2018 11.3.4.1. Si se utiliza la segmentación, confirme el alcance de la PCI DSS al realizar pruebas de penetración en los controles de segmentación al menos cada seis meses, y después de cualquier cambio a los controles/métodos de segmentación. Proveedores de servicios
    01 de febrero de 2018 12.4.1. La gerencia ejecutiva deberá establecer la responsabilidad de la protección de los datos del titular de la tarjeta y un programa de cumplimiento de la PCI DSS para incluir:
    - Responsabilidad general de mantener el cumplimiento de la PCI DSS
    - Definir un estatuto para el programa de cumplimiento de la PCI DSS y la comunicación a la gerencia ejecutiva
    Proveedores de servicios
    01 de febrero de 2018 12.11. Realizar revisiones al menos trimestralmente para confirmar que el personal sigue las políticas de seguridad y los procedimientos operativos. Las revisiones deben cubrir los siguientes procesos:
    - Revisiones del registro diario
    - Revisiones del conjunto de reglas de firewall
    - La aplicación de las normas de configuración a los nuevos sistemas
    - Respuesta a las alertas de seguridad
    - Procesos de gestión del cambio
    Proveedores de servicios
    01 de febrero de 2018 12.11.1. Mantener la documentación del proceso de revisión trimestral para incluir:
    - Documentar los resultados de las revisiones
    - Revisión y cierre de los resultados por el personal asignado a la responsabilidad del programa de cumplimiento de la PCI DSS
    Proveedores de servicios
    01 de julio de 2018 Todas las entidades deberán haber dejado de usar la SSL/TLS temprana como un control de seguridad, y usar solo las versiones seguras del protocolo. Comercios y proveedores de servicios

    Si tienes preguntas, no olvides dejar tu comentario o ingresar al foro de PCI Hispano.

    OWASP Top Ten y PCI DSS

    Desde sus primeras versiones, PCI DSS siempre citado a la OWASP como referente para la definición de directrices de codificación segura. Por ello, en el requisito 6.5 "Aborde las vulnerabilidades de codificación comunes en los procesos de desarrollo de software" se citan las guías de la OWASP como mejores prácticas de la industria a ser empleadas para estas acciones, en conjunción con las guías del CERT (https://www.cert.org/secure-coding/publications/index.cfm) y del SANS CWE Top 25 (http://cwe.mitre.org/top25/).

    Teniendo en cuenta la dinámica en términos de riesgos en las aplicaciones web, el PCI SSC fue bastante precavido y por ello dejó en claro que, en el caso de actualización de las mejores prácticas de la industria para la gestión de las vulnerabilidades, éstas deberían primar sobre las identificadas por el propio estándar.
    Figura 3. Requisito 6.5 de PCI DSS

    Por otro lado, también se deja en claro lo siguiente:
    "A medida que cambian las prácticas de codificación segura aceptadas por la industria, las prácticas de codificación de las organizaciones y la capacitación de los desarrolladores se deben actualizar para abordar nuevas amenazas, por ejemplo, ataques para extraer la memoria." 

    "Las vulnerabilidades identificadas en los Requisitos 6.5.1 al 6.5.10 proporcionan un punto de partida mínimo."

    "Es responsabilidad de la organización informarse sobre las últimas tendencias en vulnerabilidades e incorporar las medidas apropiadas en cuanto a las prácticas de codificación segura"

    Las vulnerabilidades descritas en los requisitos 6.5.1 al 6.5.10 de PCI DSS hacen referencia a los controles mínimos que se deben implementar y que las organizaciones deben incorporar dentro de sus prácticas de codificación segura correspondientes a la tecnología particular de su entorno.
    A continuación, se relacionan dichos requisitos de PCI DSS y su correspondencia con los Top Ten de la OWASP de los años 2013 y 2017:
    Req.
    Descripción
    Referencia en OWASP Top Ten 2013
    Referencia en OWASP Top Ten 2017
    6.5.1
    Errores de inyección, en especial, errores de inyección SQL. También considere los errores de inyección de comandos de OS, LDAP y Xpath, así como otros errores de inyección.
    A1:2013
    A1:2017
    6.5.2
    Desbordamiento de buffer
    -        
    -        
    6.5.3
    Almacenamiento cifrado inseguro
    A6:2013
    A3:2017
    6.5.4
    Comunicaciones inseguras
    A6:2013
    A3:2017
    6.5.5
    Manejo inadecuado de errores
    A5:2013
    A6:2013
    A3:2017
    A6:2017
    6.5.6
    Todas las vulnerabilidades de "alto riesgo" detectadas en el proceso de identificación de vulnerabilidades
    A9:2013
    A9:2017
    6.5.7
    Lenguaje de comandos entre distintos sitios (XSS)
    A3:2013
    A7:2017
    6.5.8
    Control de acceso inapropiado
    A4:2013
    A7:2013
    A10:2013
    A5:2017
    6.5.9
    Falsificación de solicitudes entre distintos sitios (CSRF)
    A8:2013
    -        
    6.5.10
    Autenticación y administración de sesión interrumpidas
    A2:2013
    A2:2017

    Como se puede observar, ninguno de los nuevos riesgos incluidos en la versión 2017 del Top Ten de la OWASP es contemplado por PCI DSS v3.2:
    • A4:2017 – XML External Entities (XXE)
    • A8:2017 – Insecure Deserialization
    • A10:2017 – Insufficient Logging & Monitoring

    ¿Qué implican estos cambios en el cumplimiento de PCI DSS y cómo se debe proceder?

    La priorización de nuevos riesgos a nivel de aplicación previamente no cubiertos por PCI DSS, pero identificados actualmente en la última versión del Top Ten de la OWASP, implica que todas las organizaciones que desarrollen aplicaciones de pago para entornos PCI DSS deben proceder de la siguiente manera:
    • Actualizar la documentación vinculada con el SSDLC (Secure Software Development Life Cycle) para que contemplen la totalidad de los riesgos del Top Ten de la OWASP 2017 – Req. 6.3
    • Actualizar los criterios empleados en la revisión de código (ya sea si se realiza manualmente o empleando herramientas automatizadas) antes de enviarlo a Producción para que cubran estos nuevos riesgos – Req. 6.3.2
    • Actualizar el material de formación en desarrollo seguro incluyendo estos nuevos riesgos y describir sus contramedidas – Req. 6.5
    • Proceder a capacitar a los desarrolladores dentro de los ciclos formativos anuales – Req. 6.5
    • Si se cuenta con aplicaciones web públicas y dependiendo de la opción empleada para protegerlas contra ataques conocidos, actualizar dichos métodos para que contemplen los riesgos de la OWASP Top Ten 2017:
      • Si se emplean herramientas o métodos de evaluación de vulnerabilidades de aplicación  automáticos o manuales, éstos deben permitir la identificación de los nuevos riesgos.
      • Si se emplea un WAF (Web Application Firewall), esta solución debe ser configurada para que detecte y/o bloquee aquellos ataques vinculados con estos nuevos riesgos. 
    Fuente: IsecAuditors

    Dec 20, 2017

    Controles de PCI DSS v3.2 en Excel

    PCI Hispano es un proyecto cooperativo en idioma español entre profesionales de América y Europa para compartir conocimiento y experiencias en el proceso de implementación de estándares del PCI DSS.

    Este grupo ha organizardo todos los controles de PCI DSS v3.2 en una hoja de cálculo de Excel, tanto para el estándar en idioma español como en idioma inglés.

    Otros artículos de esta serie:

    Apr 2, 2015

    Guía de Penetration Testing para PCI 3.0

    El objetivo de esta nueva guía "Guía de Penetration Testing para PCI 3.0" [PDF] publicada por PCI Security Standards Council es actualizar y reemplazar los métodos de la guía "Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 Penetration Testing" publicada en 2008.
    Todas las referencias hechas en el documento son PCI DSS versión 3.0, pero los principios generales y las prácticas que se ofrecen pueden aplicarse a cualquier versión de PCI DSS y otros estándares.

    La guía presenta directrices que se pretenden extender a las futuras versiones de del documento. La guía se centra en los siguientes puntos:
    • Componentes de las pruebas: comprensión de los diferentes componentes que conforman un Penetration Test y cómo esto difiere de la búsqueda vulnerabilidad incluyendo alcance, verificación y pruebas de ingeniería social.
    • Las cualificaciones del tester: determinar si las calificaciones de un tester, interno o externo, a través de su experiencia y certificaciones.
    • Metodologías: información relacionada con las tres partes principales de una prueba, el compromiso antes de la contratación, durante y después de la contratación.
    • Reportes: guía para el desarrollo de una prueba completa y la información a documentar durante el reporte, así como una lista para verificar si el contenido necesario está incluido.
    La información contenida en este documento está concebida como guía complementaria y no sustituye, reemplaza o extienden los requerimientos de PCI DSS.

    Cristian de la Redacción de Segu-Info

    Oct 22, 2014

    Webcast sobre PCI DSS v3.0 (22/10)

    Este evento ha finalizado y ya se puede ver Webcast sobre PCI DSS v3.0.

    A partir del próximo enero 2015 empieza a utilizarse PCI DSS v3.0 estándar aunque algunos de los cambios serán solo buenas prácticas hasta junio de 2015 donde pasaran a ser requerimientos de PCI.

    Esta presentación incluye una introducción a PCI DSS y remarca los principales cambios que nos trae la v3.0.

    El webcast estara a cargo de Mateo Martinez quien es Especialista en Seguridad de la Información y Desarrollo de Software además de Asesor de Emprendimientos tecnológicos. Posee las certificaciones CISSP, ITIL, ISO 27001 Lead Implementer y es Auditor PCI QSA, con amplia experiencia en consultoría de sistemas y seguridad.

    Ya se encuentra el video en línea: http://segu.info/ypci

    Cristian de la Redacción de Segu-Info

    Mar 28, 2014

    Cumplimiento de Estándar PCI DSS v3 con EnCase

    Hemos producido previamente una serie de tres publicaciones en el blog en el que hemos descrito cómo EnCase® puede reducir los costos y las necesidades de recursos de cumplimiento interno PCI-DSS V2 (http://recorriendo-los-caminos-de-encase.blogspot.com/2013/09/ahora-que-entendiendo-el-cumplimiento.html). A finales de 2013, el cuerpo de las normas PCI publicó la versión 3 de las normas de PCI, que es una actualización de las normas PCI V2.

    Las nuevas normas tienen un montón de atención en las áreas que EnCase® tiene capacidades muy fuertes. Entre otras, estas normas actualizadas requieren que las organizaciones llevan a cabo auditorías para las conexiones remotas, los permisos de archivos y servicios. Esperamos que usted considere EnCase® para asegurar el cumplimiento de las normas PCI actualizados para auditar a las normas, así como datos confidenciales de los usuarios que han sido almacenados en los registros, correos electrónicos, SharePoint o la nube.

    El número de cuenta primaria es el elemento clave del estándar. Aquí explicamos cómo el número de cuenta se interrelaciona con el estándar PCI:
    El número de cuenta principal es el factor que define los datos del titular de la tarjeta. Si el nombre del titular de la tarjeta, el código de servicio o la fecha de vencimiento se almacenan, procesan o transmiten con el PAN (número de cuenta principal) o se encuentran presentes de algún otro modo en el entorno de datos del titular de la tarjeta, se deben proteger de conformidad con los requisitos de las PCI DSS.
    Los requisitos de las PCI DSS se aplican a las organizaciones y entornos en los que se almacenan, procesan o transmiten datos de cuenta (datos del titular de la tarjeta y datos de autenticación confidenciales). Algunos requisitos de las PCI DSS también se aplican a organizaciones que han tercerizado las operaciones de pago o la gestión del CDE (entorno de los datos del titular de la tarjeta) Además, las organizaciones que tercerizan el CDE (entorno de los datos del titular de la tarjeta) o las operaciones de pagos a terceros deben asegurarse de que estos protejan los datos de cuenta de acuerdo con todos los requisitos correspondientes de las PCI DSS.

    http://es.pcisecuritystandards.org/_onelink_/pcisecurity/en2es/minisite/en/docs/PCI_DSS_v3.pdf
    En nuestro próximo artículo de la serie, vamos a seguir buscando en la próxima serie de requisitos de cumplimiento de PCI DSS v3. La intención es ayudar a las organizaciones a entender cómo EnCase® puede reducir la complejidad del cumplimiento de PCI y ayudar con la práctica en la ejecución de los requisitos.
    Fuente: Recorriendo los caminos de EnCase I y II, III

    Feb 7, 2014

    Guía esencial para el cumplimiento de PCI

    El Estándar de Datos de Seguridad de la Industria de las Tarjetas de Pago (PCI DSS) se actualizó a la versión 3.0 por última vez en noviembre de 2013. Desde entonces hemos visto algunos cambios, incluyendo la política de cumplimiento por parte de VISA hasta la fuerte adopción de nuevas tecnologías como los pagos móviles.

    En esta guía esencial de PCI [PCI] usted puede entender desde lo más básico de PCI hasta los detalles, nuevas tecnologías  y consejos para usar las mejores prácticas en la implementación de PCI 3.0.

    Fuente: TechTarget