Analytics

miércoles, 27 de noviembre de 2013

Descuento en la inscripción al curso CCFP

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

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

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

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

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

martes, 26 de noviembre de 2013

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

jueves, 7 de noviembre de 2013

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

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

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

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

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


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

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

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

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

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


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

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


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