Analytics

martes, 30 de junio de 2015

Suplemento de validación para entidades concretas

El día 5 de junio el PCI DSS publicó una guía para la realización de una validación adicional para ciertas entidades, siempre bajo la petición de su entidad adquiriente o una de las marcas de pago.

Destino del suplemento
Entre los motivos que podrían llevar a una de estas entidades a requerir está validación adicional estarían:

  • Entidades que almacenan, procesan o transmiten un gran volumen de datos de tarjeta.
  • Entidades que sirven como punto central de agregación de datos de tarjeta. 
  • Entidades que han sufrido una brecha significativa o repetidas brechas con datos de tarjeta involucrados.

Motivación de la publicación del suplemento
Es importante dejar claro que no se trata de nuevos requerimientos de la norma PCI DSS, sino de formas más detalladas para validación de ciertos requisitos ya existentes. Su motivación principal es demostrar que los controles de la norma son mantenidos de forma efectiva durante todo el año, a través de la validación de los controles BAU (Business As Usual) y mayor control sobre la definición del ámbito PCI DSS.

Uno de los principales objetivos del PCI SSC tanto en la evolución de la norma como con este tipo de suplementos de ayuda, es conseguir que ésta no sea percibida como una validación anual en forma de auditoría sino que haya que demostrar la labor realizada durante todo del año. Por este motivo, en la versión 3 de la norma se introdujo el concepto de procesos BAU.

Estructura del suplemento
En lo que respecta propiamente al contenido del suplemento publicado, está dividido en 5 áreas de control, 20 requerimientos y 37 procedimientos de validación. En relación con las áreas de control, podemos distinguir las siguientes:

DE.1: Implementar un programa de cumplimiento PCI DSS
Principalmente basada en el requerimiento 12, hace énfasis en el establecimiento de la responsabilidad en la realización de los procesos requeridos para el cumplimiento la norma PCI DSS así como la definición formal de las actividades que deben ser realizadas (incluyendo en que franjas temporales) para asegurar dicho cumplimiento. Adicionalmente, se debe demostrar formación realizada en relación con la norma PCI DSS a personal con responsabilidades en su cumplimiento.

DE.2: Documentar y validar el ámbito PCI DSS
Requerimientos referentes a una validación estricta del ámbito PCI DSS definido, así como su evolución durante el proceso de cumplimiento de la norma haciendo especial énfasis en los cambios realizados en el entorno (cambios de configuración, administrativos u organizativos). Cabe destacar la necesidad de un método formal de búsqueda de números de tarjeta y procedimientos de respuesta en caso de detección de los mismos. 

DE.3: Validar que PCI DSS está incorporado dentro de la actividades habituales del negocio (BAU)
Formalización y documentación de los procedimientos de realización de las tareas recurrentes incluidas en la norma PCI DSS y análisis detallado de situaciones anómalas.

DE.4: Controlar y gestionar el acceso lógico al entorno de datos de tarjeta
Revisión recurrente (cada 6 meses) de las cuentas de usuarios y los privilegios de acceso en función de la necesidad de conocer, para todos los sistemas incluidos dentro del ámbito PCI DSS.

DE.5: Identificar y responder a eventos sospechosos
Definición de una metodología de detección y respuesta ante la ocurrencia de anomalías.

Reporte de cumplimiento
Aunque los requisitos de reporte no han sido definidos, dadas las circunstancias en las que se requiere este tipo de validación (orientado a entidades de nivel 1) parece bastante evidente que deberá ser un auditor el que certifique el cumplimiento de los requisitos incluidos en este suplemento.


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

martes, 23 de junio de 2015

El PCI SSC publica el documento: PCI DSS Designated Entities Supplemental Validation

El PCI SSC ha publicado este mes de Junio el documento "PCI DSS Designated Entities Suplemental Validation". Este documento lo podemos ver como una "meta-norma" que tiene como objetivo aumentar las garantías de mantenimiento en el cumplimiento con PCI DSS v3.1. Se amplía el conjunto de requisitos a cumplir para aquellas empresas que suponen un alto riesgo para la seguridad de los datos de tarjeta de pago. El documento establece que será obligatorio su cumplimiento para aquellas empresas designadas por las marcas de pago o las entidades adquirientes (estas serán quienes comuniquen a los afectados), dando algunos ejemplos (empresas que tratan grandes volúmenes de datos de tarjeta de pago o aquellas que hayan sufrido compromisos importantes y/o reiterados), pero sin limitarlos, de manera que finalmente dependerá del criterio de las marcas y los adquirientes.

El documento define requisitos enfocados a definir formalmente un programa de cumplimiento, validar y actualizar correctamente el alcance de cumplimiento, validar que las tareas periódicas que solicita PCI DSS se están ejecutando correctamente y corregir desviaciones, reforzar la revisión en los controles de acceso implementados y finalmente reforzar la identificación y respuesta ante incidentes.

Gran parte de estos requisitos vienen a constatar la necesidad de controles que las empresas ya implementan para poder mantener el cumplimiento de una norma tan precisa y compleja como es PCI DSS.  Recordemos que PCI DSS es un proceso continuo, y esto es lo que se intenta remarcar a lo largo de los requisitos recogidos en este nuevo documento.

Junto a este documento se han emitido plantillas para poder documentar un RoC y un AOC específico en estos casos (aunque en compañía de los documentos de RoC y AOC para PCI DSS v3.1).

Referencias:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_DESV.pdf
https://www.pcisecuritystandards.org/documents/FAQs_for_DESV.pdf
https://www.pcisecuritystandards.org/documents/PCI_DSSv3_DESV_S-ROC_Reporting_Template.pdf
https://www.pcisecuritystandards.org/documents/PCI_DSSv3_DESV_S_AOC.docx
 

Autor: Miguel Ángel Domínguez - CGEIT, CISA, CISSP, ISO27001 L.A. BS25999 L.A., PCI QSA, PCI PA-QSA, AMBCI, OPST
Departamento de Consultoría

viernes, 19 de junio de 2015

Crónica IX OWASP Spain Chapter 2015

Un año más, se celebró el OWASP Spain Chapter, y ya van 9! Este año las jornadas se han centrado en la seguridad en el ciclo de vida del software. Se ha hecho hincapié en concienciar al público de que es insuficiente realizar una auditoría de seguridad antes de sacar el producto al mercado y que la metodología y automatización de las pruebas de seguridad en cada uno de los ciclos del desarrollo del software debe ser un requisito imprescindible.

También remarcó en esta edición el gran número de vulnerabilidades detectadas en el periodo 2014-2015. Estas vulnerabilidades han afectado a todo tipo de software de diferentes áreas. Esta cantidad de problemas detectados ha puesto en relieve lo expuestos que podemos estar sino estamos al día de las vulnerabilidades publicadas y de las mitigaciones que debemos aplicar periódicamente.

A continuación se detallan las distintas ponencias de esta última OWASP.

Presentación de las jornadas

Aunque lamentablemente este año Vicente Aguilera, líder del Capítulo español, no pudo acudir a las jornadas Joan Figueres y Jaume Abella tomaron el relevo y se encargaron de hacer la introducción a las ponencias y a los ponentes.

Cat-and-Mouse Game with Sucuri's Web Application Firewall

En esta conferencia Ashar Javed explica las investigaciones que ha realizado sobre dos firewalls de aplicación. Se ha centrado principalmente en evaluar el filtrado de ataques de tipo XSS (cross-site scripting) complejos. Utilizó varias técnicas de ofuscación como codificar en utf8 o utilizar tags HTML5, así consigue evadir los firewalls de aplicación, ya que estos se basan en expresiones regulares muy simples.

Ashar nos sorprendió con sus métodos de inyección de cross-site, esperamos poder descargar su presentación en breve y poder replicar sus experiencias.

Estableciendo las tres líneas de defensa en proyectos web

Marc Muntañá muestra los problemas que surgen en una compañía en el momento de evaluar su plan de seguridad, los roles de los departamentos, como también el de los jefes, donde presenta un modelo en 3 capas.

En su presentación explicaba el origen de un nuevo perfil de profesional, un profesional que debe conocer tanto de calidad como de seguridad. La idea de que la seguridad forme parte dentro del ciclo de vida del desarrollo no es un concepto nuevo, sin embargo la seguridad debe ganar su espacio dentro del ciclo de vida como lo ganó la calidad hace 10 años.

También se habló del uso de herramientas para poder llevar a cabo las auditorias, GAUNTLET, Owasp ZAPjenkis plugins, Zap Junit.

Desarrollo Rápido y Seguro de Aplicaciones. ¿Es posible tener las dos cosas?

Fabio Cerullo explica cómo implementar seguridad en las nuevas metodologías de desarrollo de software como AGILE, que están actualmente tan de moda, y como añadir pruebas de seguridad en los Sprints del desarrollo. Para finalizar explicó las herramientas para automatizar la pruebas de seguridad en cada etapa del desarrollo.

También comentó que los nuevos fronts para los compiladores, los cuales añadirán la característica de validar los campos de entradas y si estos no están validados no dejaran compilar el código.

Pruebas de seguridad continuas para DevOps

Stephen De Vries en su ponencia describe que el proceso de seguridad no debe ir a parte del desarrollo del software y que los DevOps han de formarse para ser SecDevOps y así integrar la seguridad en los diferentes ciclos tanto de la parte de sistemas  como del desarrollo del software. Posteriormente se explican diversas herramientas para automatizar estas tareas, tales como Sonar Qube, Jenkis y el OWASP Dependency Test.

Abuse Cases -  From Scratch to the hack

Miguel Ángel Hernández muestra varios errores en aplicaciones debidos las validaciones que se hacen a nivel de javascript en el cliente y posteriormente el servidor no tiene métodos para validar estos datos, por lo que un atacante puede modificar las peticiones. Al final se hace una demostración en la página web de una conocida empresa de ropa, donde se cambia el precio de los productos del carro de la compra y estos son enviados a la pasarela de pago con el precio total modificado.

APT, Ataque y defensa en entorno hostil

Marc Rivero resume los  últimos ataques APT publicados por Kaspersky (Duqu 2.0 infección de firmware del disco duro). Desde un punto de vista de ataque y de cómo deberíamos proteger  una empresa para prevenir futuros ataques.

Mesa redonda (ponente e invitada)

Para empezar la mesa redonda se hizo un resumen de la jornada y se continuó tratando temas variados, se habló de la moda de añadir la palabra “ciber” a cualquier cosa relacionada con la seguridad informática. También se comentó las últimas vulnerabilidades del año y la publicación de información confidencial de la NSA por parte de Edward Snowden.
A día de hoy no están publicadas las presentaciones de las ponencias, este material se publicará en breve en el capítulo Español de la web de la OWASP.

https://www.owasp.org/index.php/Spain/Chapter_Meeting


Autores: Tomás Velázquez - CEH. Luis E. Benítez  
Departamento de Auditoría.