Webinar Grabado

Lo nuevo en PCI DSS 3.2

Los cambios y requerimientos que llegan en 2018
Grabado:
14 septiembre 2017

 

El 1º de febrero de 2018 entra en vigencia la nueva versión de PCI DSS, el estándar de Seguridad de datos para la industria de tarjetas de pago. Si su compañía necesita cumplir con PCI, es fundamental que conozca los cambios que exige la normativa, y sepa cómo interpretarlos e implementarlos antes de esa fecha.

Vea la grabación de este webinar, donde explicaremos todo lo que necesita saber para estar preparado para PCI 3.2:

• Cambios en la versión 3.2 y los nuevos requerimientos
• Autenticación doble factor vs. multi-factor
• 12 claves para cumplir con la nueva regulación
• PCI como buena práctica para empresas en todas las industrias

Webinar dirigido a: CSOs, CISOs, responsables de Seguridad o IT, Auditores, y profesionales interesados en mejores prácticas de Seguridad. 

Lo nuevo en PCI DSS 3.2.

Amneris Teruel [00:00:04] La agenda que nos convoca: vamos inicialmente a hacer una breve introducción presentándonos como empresa. Luego empezaremos a hablar sobre PCI propiamente dicho con sus características, los 12 requerimientos fundamentales que forman parte de PCI y qué hay de nuevo en ellos, qué hay de nuevo fundamentalmente en esta versión 3.2. Por último, como nosotros lo podemos ayudar en este camino de cumplimiento. Al final, un resumen y como siempre, una sección de preguntas y respuestas donde ustedes van a poder hacernos las preguntas de interés y las compartiremos juntos. Mi nombre es Amneris Teruel. Formo parte de HelpSystems en la oficina de Buenos Aires. Estoy en el área de técnica, vinculada principalmente a la divulgación y a las actividades de pre-venta. Trabajo en el ámbito de la monitorización, de la Automatización y de la seguridad hce muchos años, casi 20 años, y como siempre, es un honor poder compartir con ustedes esta sesión.

Amneris Teruel [00:01:07] En HelpSystems la seguridad es un tópico muy importante. Realmente es una de las apuestas más fuertes que tenemos dentro de nuestro grupo. Tenemos un portfolio de herramientas de software para diferentes plataformas, muy amplio, que crece, que cada vez se va mejorando con el soporte de servicios profesionales muy fuerte. Tenemos el honor de tener en nuestro equipo de trabajo expertos muy calificados en todo el mundo de la seguridad y de PCI también como Robin Tatam, que probablemente hayan escuchado de ellos o hayan asistió a algunos seminarios que ellos también dictan del mismo modo que lo estamos haciendo hoy.También importante comentarles, es que HelpSystems integra el Council de PCI, con lo cual estamos con un compromiso muy fuerte en lo que respecta a esta regulación.

Amneris Teruel [00:02:04] Vamos a entrar ahora ya de lleno a nuestro tema y vamos a ver qué características son las que predominan en este mundo de PCI. Principalmente, PCI quiere decir Payment Card Industry Data Security Standard, son todas las siglas y esta es una regulación que ha sido desarrollada para fortalecer y mejorar la seguridad de los datos de los titulares de las tarjetas de pago. Ese es su objetivo, dar seguridad a esta forma de negocio tan divulgada y tan propagada en la comercialización de hoy. Realmente como regulación, es una regulación simple, sencilla desde un punto de vista de su formulación y ayuda rápidamente a que podamos adoptar un esquema seguro, consistente, homologado, globalizado. En su estructura tiene 12 requerimientos, hoy vamos a recorrer juntos. En estos requerimientos no solo se combinan condiciones de cómo debe establecer la seguridad, sino también cómo comprobarla, cómo hacer pruebas para tener la garantía de que estoy trabajando bien en el mundo de la seguridad. Y además, es una regulación que está enfocada mucho para que los diferentes evaluadores, los auditores, apliquen o verifiquen estas condiciones de trabajo en los distintos comerciantes, proveedores de servicios y todas las organizaciones que deban cumplir con la regulación.

Amneris Teruel [00:03:44] Si hacemos un poquitito de historia PCI es una organización que empezó siendo conformada estrictamente por algunas marcas de tarjetas de crédito, este fue el origen y esas marcas eran los principales interesados en que este negocio estuviera resguardado. De ahí viene la aparición de esta regulación. Pero sucesivamente, con el paso de los años, esta organización abrió sus puertas y hoy día muchas empresas privadas participan también de este interés general. De hecho HelpSystems forma parte de este Council. Este Council es una organización privada sin fines de lucro y que lo que busca es asegurar que toda la actividad basada en tarjetas de pago o tarjetas de crédito sea confiable y segura en el tiempo. Los invito particularmente a que entren a la página de PCI.

Es una página donde está toda la información disponible. Se pueden bajar en diferentes idiomas la regulación y vale la pena leerla. Si bien leer regulaciones realmente no es tan divertido, hay literatura mucho más linda para leer, pero dentro del mundo de las regulaciones, PCI es una regulación redactada de un modo amigable, comprensible, y muy práctica y no es extensa. Pierdan el miedo, vale la pena echarle un vistazo. ¿Quienes deben cumplir con PCI? Cada marca emisora tienen quizás algunas variantes o sutilezas respecto de quien deben cumplir y quienes no, pero si lo miramos así desde un pantallazo general, cualquier entidad que almacene, procese y transmita información de titulares de tarjetas de pago debe cumplir con PCI, así que almacenar, procesar o transmitir o cualquiera de las tres combinadas. Y las entidades generalmente no están limitadas, pero es todo lo que sea relativo a la comercialización, porque realmente las tarjetas de pago se usan en momentos de comercialización o a veces también proveedores de servicios.

Amneris Teruel [00:06:00] El tamaño de la empresa afectada no es menor, la regulación no tiene la misma rigurosidad para empresas pequeñas, que para empresas medianas o más grandes. Las empresas pequeñas que deban cumplir porque, o almacenan o procesan o transmiten, generalmente, en vez de ser auditadas con rigurosidad, se les envía un cuestionario de autoevaluación que después el Council evalúa y emite una una decisión al respecto. Y en las empresas más grandes si hay auditorías que deben ser llevadas a cabo por un asesor, digamos de seguridad habilitado y ahí sí, digamos el requerimiento, se vive con bastante más rigurosidad. ¿Qué es lo que busca proteger la regulación? ¿Qué dato hay que proteger? Y ustedes van a ver que es él el que se llama PAN,Primary Account Number, es decir, la información del titular de la tarjeta, básicamente, y ese es el dato a proteger.

No es necesario proteger información respecto de la compra, del monto, sino lo que rige, lo que gobierna toda esta regulación es el proteger el PAN. Entonces justamente si ese es el dato sensible, vale la pena preguntarse si es un dato que debo almacenar o no. Porque probablemente tenga que transmitirlo si estoy haciendo una operación comercial, tenga que llevar y traer información respecto del número del titular o los datos de titular. Sin embargo, almacenar esa información en muchos casos es algo que puedo decidir. No siempre es necesario almacenarlo, con lo cual justamente ¿almacenar o no almacenarlo?. Esa es la cuestión. Porque esto va a cambiar radicalmente el peso que pueda tener la regulación sobre la organización de ustedes.

Amneris Teruel [00:08:09] La regulación va va evolucionando a lo largo del tiempo. Estamos en su versión 3.2 ahora y generalmente tiene ciclos de vida de tres años. Cuando comenzó la regulación en el primer año, digamos, se publicó en noviembre. Todo el primer año se toma como período de divulgación. El segundo año y reciém hacia finales del tercero es cuando la regulación entra en vigencia con carácter de obligatorio, con lo cual también como regulación es, digamos, muy considerada con respecto a las organizaciones, de manera que cualquier cambio que la regulación exija, darnos tiempo a nosotros, como como integrantes del área de seguridad informática o de tecnología, para poder realmente cumplir con la regulación. En este sentido, las regulaciones es criteriosa en estos ciclos de aproximadamente tres años. Fíjense con la versión actual, la 3.2 se publica en mayo del 2016, ya hace bastante.

A partir de octubre del 2016, la versión anterior que era la 3.1 expira, entra en vigencia la 3.2, pero, entra en vigencia a modo de buena práctica. Y esto es como funciona siempre en el ciclo más o menos: se emite la versión, a los 6 meses expira la anterior entra en vigencia la actual, pero como buena práctica. ¿Qué quiere decir? Que desde este momento de octubre del 2016 hasta que entre en vigencia como obligación, este lapso de tiempo, si ustedes están sufriendo o están recibiendo una auditoría, si no cumplen con algunas de las condiciones que la 3.2 exige no es tan severo como si no lo cumplieron después del 2018. Estamos en este período ahora de que la regulación 3.2, con su versión 3.2, es una buena práctica. A partir de febrero de 2018, salvo algunas excepciones que vamos a ir viendo, empieza a ser obligatorio. Sí,Por por eso también la intención del webinar de hoy, para ajustar los detalles de acá a febrero. Algunos de los cambios que también tiene la regulación, más allá del contenido, que ahora vamos a ver, un poco también es en la forma. A la regulación la han mejorado mucho en lo que respecta a claridad, a guías,... Fíjense que conecta, digamos, los distintos requerimientos entre sí. Empieza ya a darnos algunos criterios diciendo, por ejemplo, hay que evaluar el riesgo entre medio, alto y bajo, osas que parecen quizás obvias, pero a veces las regulaciones no son tan detalladas como esta. Es un beneficio, porque cuanto más nos ayuda la regulación, más fácil será después la implementación. Y después incluso de procedimientos de testing, no de cómo llevarlo a cabo. Así que cada vez la regulación va ganando en claridad.

Amneris Teruel [00:11:24] Y si hacemos un poquitito de historia, fíjense, PCI 2.X exigía sólo evaluar vulnerabilidades externas. Es decir, yo tenía que ver cómo protegía estos datos de los titulares de las tarjetas de crédito desde el punto de vista de los accesos que podía sufrir mi organización desde el exterior. Entonces exigían, scans trimestrales y este requerimiento era muy fácil lograrlo haciendo uso de algún servicio provisto por un proveedor. Entonces había un tercero al cual uno contrataba para que comprobase qué tan vulnerable o no es mi organización y así ajustar la configuración de la seguridad. Cuando saltamos a PCI 3, y por eso el cambio de número, cambia algo muy importante que ya no sólo vulnerabilidades externas, sino también internas, entonces también con scans trimestrales, pero acá aparece una complejidad: que para la vulnerabilidad interna contratar un tercero ya no es tan fácil, porque si lo contrato le tengo que dar acceso o lo tengo que hacer trabajar en mi oficina o tengo que poner una porción de software dentro de mi red y por el hecho de revisar la vulnerabilidad hasta puedo estar abriendo una vulnerabilidad en sí misma, abriendo el acceso a este proveedor.

Amneris Teruel [00:12:47] Y otra cosa que sugiere mucho PCI 3 en todas sus variantes es Security Business as usual. Así usual que la seguridad empieza a formar parte del negocio en su totalidad. Que deje de ser un requerimiento a cumplir formal, para que forme parte de las consideraciones de mi negocio. Ahora, en la medida que avancemos, vamos a ir ahondando un poquitito en esto. De dónde puedo saber qué controles estoy haciendo, si están activos o no, si los controles que estoy haciendo operan efectivamente. Detectar en tiempo real los problemas de seguridad que haya. Y todo esto tiene que formar parte de mi negocio. No es algo aparte. Revisar cualquier cambio del entorno antes de implementarlo, un nuevo hardware, un nuevo software. Si la gente del área de comercialización quiere incorporar un nuevo hardware que va a ser muy bueno para el área de ventas. Bueno, ahora, además de ver lo bueno que tiene desde el punto de vista de negocio puro, tenemos que evaluar los riesgos de seguridad que conlleva; o cambios organizacionales, compras, ventas de empresas, fusiones; bueno las fusiones ahora no sólo hay que tratarlas en todo su ámbito de todas las aristas que tiene, sino también desde el punto de vista de seguridad. Y obviamente, la revisión de PCI sea algo que sea frecuente, que forme parte de la planificación de la organización.

Amneris Teruel [00:14:21] Y ahora estamos en PCI 3.2, como les decía, se publicó en mayo del 2016, entra en vigencia en febrero de 2018, a pesar de que hay algunas excepciones, ahí vamos. Pero los puntos más importantes, la regulación cambió en varios artículos. De hecho, si ustedes entran a la página hay un documento que es un change log muy detallado, donde dice cada cambio que se hizo en la regulación y en cada uno de los artículos. Pero como resumen, hoy vamos a hablar de tres cosas importantes que se incluyeron en PCI 3.2: el tema de la Multifactor Authentication, cómo juega ahí con el acceso desde entornos que no sean la consola para usuarios administradores; el reemplazo de algunos protocolos que ya no son seguros SSL y TLS 1.0 no son más soportados por PCI, estamos invitados fuertemente a pasar a TLS 1.1 o mayores y este requerimiento se extendió a julio, si después vamos a hablar más en detalle. Y por primera vez PCI empezó a ingerir en el área de desarrollo de software. También vamos a hablar de esto.Entonces vayamos a PCI con sus 12 requerimientos.

Voy a hacer una recorrida por estos 12 requerimientos para que veamos que no son tantos, que tienen muchísimo sentido común y en cada uno de ellos si hay algo nuevo para destacar lo vamos a hacer. Este es un resumen de los 12 requerimientos, tal cual están escritos aquí en la versión en español que ustedes se pueden descargar. Fijense que son seis categorías, estos 12 requerimientos. Son realmente comprensibles fíjense. Requerimiento número 1: Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta. Muy comprensivo. Y acá algunas recomendaciones o consideraciones a tener en cuenta. Una herramienta muy útil para cumplir con este primer requerimiento, esto en lo que respecta a la segmentación de las redes.

Si ustedes tienen que cumplir con PCI, es probable que no todos los servidores deban cumplir con PCI, porque no todos operan con ese dato o operan con esta parte del negocio. Entonces, es importante distinguir los servidores que deben cumplimentar con los que no, y muchas veces, si es posible, segmentarlos en subredes diferentes, con lo cual vamos a poder tener en aquellassubredes críticas donde sí debemos cumplir PCI, criterios de seguridad muchísimo más severos, pero sí liberar otras áreas de la organización donde vamos a poder trabajar con más tranquilidad. Así que eso, tenerlo en cuenta. Y otra cosa a tener en cuenta también en el caso de la segmentación, tener la posibilidad de poner firewalls que protejan las distintas subredes a nivel red, pero no se olviden de los firewalls internos. Cada plataforma como última capa, en general, tiene un firewall, más eficiente, menos eficiente, algunos más configurables que otros, pero no olviden esta capa porque generalmente es muy confiable, es segura y puede ayudarlos para cumplir con este requerimiento.

Amneris Teruel [00:17:57] Requerimiento número 2: este parece increíblemente obvio: no usar valores predeterminados suministrados por el proveedor para las contraseñas de sistema y otros parámetros de seguridad. Cuántas veces hemos instalado software o paquetes que contratamos, que en general, conllevan usuarios, propietarios o administradores con alguna contraseña que es pública, que está documentada en algún manual.

Amneris Teruel [00:18:27] Importantísimo: no olvidar cambiar las contraseñas.A veces hasta uno descuida al momento de hacer instalación de software, en verificar cuáles son esos eventuales nuevos usuarios que se pueden haber generado y son puertas que quedan abiertas y prácticamente de manera inconsciente. Súper simple este requerimiento, pero a no olvidarlo, porque es un requerimiento fácil de cumplir.

Amneris Teruel [00:18:53] Requerimiento 3. Y acá ya nos empezamos a meter más de lleno: proteger los datos almacenados del titular de la tarjeta. Y acá me atrevía a enumerar los subartículos y dice: almacene la menor cantidad posible de datos del titular de la tarjeta. No almacenar datos confidenciales de autenticación después de recibir la autorización. Y acá entra en juego algo importante. Hay que evaluar seriamente si necesito guardar el dato de la tarjeta de titular. Normalmente, cuando estoy haciendo una compra lo que vale es, para quien está en la transacción comercial, es el código de autorización. En general, no es necesario guardar los datos del titular de la tarjeta. Y acá entran en juego, a veces, las áreas de desarrollo. Quienes están en el mundo del desarrollo de software están alejados de estos detalles de la seguridad, dado que el dato del titular de la tarjeta lo disponen porque al momento de hacer la compra es un dato que va a circular por el software, está la clarísima tentación de guardar esa información si es información que poseo, sí, la guardo, me puede servir para más adelante.

Fíjense cómo quizás una buena intención o una mirada excesivamente técnica de alguien que desarrolla el software puede hacer que los vea obligados a ustedes a cumplir con PCI, por el simple almacenamiento, cuando en realidad no era algo necesario. Así que tenerlo en cuenta. El artículo 3.3: enmascare el Private Account Number. Lo que te permite la regulación es que, a lo sumo, muestres los seis primeros dígitos y los últimos cuatro en los casos en que lo tengas que hacer visible y que, claramente, quienes tengan acceso o que necesiten ver o disponer de la información completa, sean personas restringidas y que esté absolutamente documentado. Convierta el PAN en ilegible, o sea, hay que encriptarlo en cualquier lugar donde se almacene. Obligatorio.

Amneris Teruel [00:21:08] Documente los procedimientos que protejan las claves de encriptación, también aparece un tema adicional si guardo el dato, lo tengo que encriptar. Si lo tengo que encriptar, tengo que gestionar todo lo que respecta a la llave. Y bueno, documente todos los procesos. Entonces, si a esto le agregamos este criterio de si puedo no almacenarlo, mejor no lo almacene. Ahora bien, algunos trucos o métodos para no almacenarlo, cuando a veces da la sensación de que si debo hacerlo. Una herramienta es el hash unidireccional. ¿Qué es esto? Es una transformación que yo le puede aplicar al número de la tarjeta,de una única dirección y que me dé un valor único, irreversible, pero que sea suficiente para validar.

¿Cuánto lo usaría?Por ejemplo, esta descripción que hice acá: transacción de tarjeta no presente con verificación de tarjeta en el momento de recogida. Traducción: compra de entradas para ir al cine, las compré en mi casa vía web y cargo el número de tarjeta ahí y tengo las entradas compradas. Cuando llego a la puerta del cine, hay probablemente algún dispositivo que me pide que ingrese la tarjeta de crédito con la cual hice la compra para que me dé los comprobantes de entrada. La empresa que se encarga de la comercialización de las entradas debe validar que la tarjeta con la que compré es la misma con la que estoy retirando los tickets de entrada y uno diría, sí tengo que comparar el número de tarjeta. El hash es un método para que lo que compares sean hash, no sean los números de la tarjeta. Entonces, cuando hago la compra, se almacena en la base de datos el hash, esa conversión unívoca de mi número de tarjeta y cuando hago el retiro de las entradas, lo mismo. Y lo que debe hacer el que me vende las entradas, es simplemente comparar los hash. Si coinciden, tengo la certeza de que ambas tarjetas son la misma y no guardé el dato del titular.

Guardando un hash no debo tener en cuenta todas las condiciones que PCI exige para el titular. Y también se usa mucho con transacciones de pago recurrentes, cuando cuando quizás tenés que guardar alguna información donde sucesivamente estás haciendo compras con la misma tarjeta. Bueno, son algunos recursos para no almacenarlos. En el caso de que lo tenga que almacenar y que lo tenga que enmascarar, la idea es en algún momento vas a tener que informar el número entero de tu tarjeta, pero sin embargo, en tu base de datos va a quedar guardado de manera enmascarada, encriptada y algunos usuarios van a desencriptar en base a una máscara donde van a ver los primeros dígitos y los últimos probablemente y algunos otros usuarios muy pocos, detallados, restringidos, son los que van a tener acceso a la información completa del dato del titular.

[00:24:22] Requerimiento 4: Cifrar la transmisión de los datos. Acá es donde aparece el primer cambio fuerte con respecto a la versión 3.2. No se puede usar más SSL o TLS 1.0. Son protocolos que ya se han descubierto que son vulnerables, así que hay que usar 1.1 o superior. Y, si están desarrollando nuevas aplicaciones, deben usar 1.1 o superior. Digamos que la contemplación de no usar el protocolo actualizado, es sólo para el software preexistente. ¿Por qué esta prórroga hasta julio? Porque realmente cambiar el protocolo requiere de planificación, porque en una comunicación siempre hay dos involucrados. Ustedes en su organización pueden hacer todos los cambios que quieran para cambiar el protocolo, pero si la organización o el socio negocio que conversa con ustedes no cambia o no se ajusta a los protocolos, puede ocurrir que no lo puedan llevar adelante. Entonces planifiquen, hablen con todos sus socios de negocio, con los cuales intercambian información de tarjetas de pago y ajusten todo lo que sea necesario para pasar a TLS 1.1 o más.

Algunas consideraciones, incluso justificaciones, de por qué PCI estiró los plazos. Porque hay como una cadena de dependencias. No sólo tengo que hablar con mis socios de negocio y ponerme de acuerdo, sino también tengo que ver en mi infraestructura una serie de compatibilidades. Esta imagen la tomé de la web. Simplemente entré a Microsoft y dije ¿qué sistemas operativos, qué versiones de sistemas operativos soportan cada uno de las versiones? Entonces, por ejemplo, Vista no soporta TLS1.1. Si tengo algún servidor que está en esta situación, sé que lo voy a tener que cambiar para luego poder implementar el protocolo. Así que una invitación a que revisen las compatibilidades de sus plataformas de base. Lo mismo con el IBM i, esta es información sacada de Internet, donde hay sistemas operativos donde está ya disponible TLS 1.1 de manera nativa, en la versión 7.1 es algo que hay que activar, digamos está disponible, pero no por defecto, y en versiones anteriores no está disponible, así que hay que hacer cambios de software de base. Voy a aprovechar y lanzar una encuesta, preguntándoles si su compañía ya comenzó alguna iniciativa para cumplir con PCI antes de febrero de 2018. Les va a aparecer ahí en su panel sobre la derecha. Los invitamos a responder y después yo voy compartiendo con ustedes lo que van respondiendo. Así sabemos un poco en qué estamos todos. En qué estado de situación estamos con respecto a trabajar para el cumplimiento de esta regulación.

Amneris Teruel [00:27:52] Requerimientos 5. Utilizar y actualizar con regularidad los programas de soporte antivirus. Importante: tener actualización de la firmas, no retrasarse,... Con Wannacry tuvimos un ejemplo clarísimo de que este requerimiento no es menor, aunque parece también bastante trivial.Y asegúrense también, otra cosa que parece obvia, pero no es menor, asegurense que los mecanismos de antivirus no puedan ser deshabilitados por los usuarios. ¿Cuantas veces uno pide una excepción que le deshabilitne el antivirus para hacer tal o cual actividad? Y después queda en el olvido y el antivirus queda desactivado en alguna de las plataformas. Así que a ponerse duro con el tema de los antivirus.

Amneris Teruel [00:28:49] Requerimiento 6: desarrollo y mantenimiento de aplicaciones. Otro cambio fuerte que pone PCI 3.2. Dice, así como un resumen no es textual, como dice la regulación, pero dice, ante un cambio grande en las aplicaciones, verificar que cumplen con PCI antes de pasar a producción, ustedes van a tener que dar evidencia a los auditores de qué proceso tienen antes de hacer un pasaje a producción, de verificar que una aplicación cumple con los requerimientos. Y esto refiere a estilos de programación. Hay estilos de programación que son mucho más vulnerables que otros. Trabajar con las áreas de desarrollo, verificar las formas de validación de la identidad que el software haga, divisiones claras entre los ambientes de desarrollo, los ambientes de producción. Evitar que datos productivos se utilizan para pruebas, que es algo súper frecuente. La necesidad de tener un lote de pruebas consistente, muchas veces parece que el único camino es hacer una restauración de un entorno productivo. Y trabajar fuertemente en la capacitación a desarrolladores. Darles directivas de cómo la organización quiere que ellos desarrollen para tener un ambiente seguro.

Amneris Teruel [00:30:04] Bueno, les cuento el resultado de la encuesta: Por ejemplo, tenemos un 24 por ciento de la audiencia que dice: sí estamos trabajando activamente en el cumplimiento de PCI, un 23 que nos dice moderadamente y un 19 que nos dice que aún no están trabajando. Es interesante saber cómo se reparte la actividad, hay prácticamente un 50 por ciento que ya está en tema, bien, hay mucho por hacer. Estamos a tiempo, en febrero esto entra en vigencia y tenemos también hasta julio para para todo lo que es la parte de comunicaciones.

Amneris Teruel [00:30:49] Voy a aprovechar también para abrir otra encuesta preguntándoles sobre esto de pasar TLS 1.1. ¿Qué grado de dificultad creen ustedes, o si ya lo han evaluado o lo están considerando ahora, el grado de dificultad que conlleva para ustedes este cambio?

Amneris Teruel [00:31:20] El requerimiento 7 nos habla de restringir los accesos:habilitar los accesos a la información basados en la necesidad de saber. Por defecto, trabajar en que nadie puede tener acceso a la información de los datos de titulares de tarjeta, por defecto deny, por defecto, No. Aquellos que estén aprobados sí lo tendrán, pero debería ser acceso de mínima.

Amneris Teruel [00:31:52] Requerimiento 8: y acá también otro cambio de 3.2 fuerte. Asignar una ID exclusiva a cada persona que tenga acceso por computadora. Esto es lo que quiere decir, el gran rubro de este requerimiento, es que cada usuario debe tener su usuario si con su password y su ID único para conectarse a los sistemas. Ahora bien, esto es algo que existió desde siempre, donde cada uno tiene que ser autenticado al momento de conectarse a toda la plataforma tecnológica. Ahora bien, ¿en qué nos está invitando PCI a trabajar más fuerte en la versión 3.2? Miren el requerimiento 8.3: asegure todo el acceso administrativo individual, que no sea de consola, y todo acceso remoto, mediante la autenticación de múltiples factores.

¿Qué nos está diciendo? Si tenemos usuarios considerados administradores o de acceso administrativo, es decir, usuarios poderosos, privilegiados, que se conectan a cualquier dispositivo o servidor de un modo que no sea consola; es decir, entendiendo como consola la conectividad física sobre el dispositivo, entonces un escritorio remoto no sería consola o conexiones SSH no sería consola o telnetno sería consola, en los cuales se identifica un usuario con acceso administrativo debe tener múltiple autenticación. La autenticación de múltiples factores requiere que se utilicen dos de los tres métodos de autenticación, o sea, hpy PCI, si bien habla de múltiples factores, como mínimo nos piden dos de los tres conocidos y el uso de un mismo factor dos veces, es decir, si a un usuario le hago poner dos IDs con dos contraseñas no sirve, tienen que ser diferentes.

Los diferentes factores de autenticación de diferentes tipos que hay son básicamente tres: la autenticación en base a conocimientos, es decir algo, que el usuario sabe, la contraseña, es algo que yo sé. este es un factor de autenticación; un segundo factor de autenticación puede ser el de posesión, algo que yo tengo, una UBKey, alguna contraseña on-time que ahora hay muchos en los celulares donde me va dando contraseñas dinámicas cada X cantidad de tiempo, pero es algo que yo tengo; y el tercer factor, que es el de inherencia, es algo que yo soy, mi huella digital, el análisis de mi retina, reconocimiento de voz, reconocimiento de la cara. Entonces, cuando estamos hablando de múltiple factor, puede ser una combinación de cualquiera de estas. La diferencia entre múltiple y doble; múltiple solo significa cualquier número de factores mayores que uno. Y elijo la combinación que quiero. Normalmente es la del conocimiento, que es el usuario y contraseña que ya todos tenemos, más alguna de las otras dos o posesión o inherencia.

Amneris Teruel [00:35:20] Y antes de pasar al siguiente requerimiento les comparto los resultados de la encuesta que hablábamos sobre esto de pasarse de protocolo, no de pasarse a TLS 1.1, y hay un 10 por ciento que nos dice que el grado de dificultad es bajo, un treinta y siete que dice medio y un 18 que nos dice que es alto. Fíjense que también tenemos un 50 por ciento que está considerando esto entre medio y alto. Qué bueno que PCI ha considerado este tema para prorrogarlo hastamediados del año que viene. Y con respecto a la doble autenticación, que es el tema que acabo de comentarles, también abrimos una encuesta y les pregunto si tienen alguna solución implementada. La respuesta es fácil sí o no.

Amneris Teruel [00:36:14] Mientras van contestando, también vamos hablando del requerimiento 9 que es restringir el acceso físico. Esto es frecuente, registrar los ingresos a los datacenters, log de accesos,... Y acá hay algo importante no se olviden de los backups. Muchas veces en lo que es restricción física de acceso, uno cuida los computadores, los discos,...pero los resguardos son tan críticos como los datos productivos del momento. Es más, les diría que son muchísimo más vulnerables porque sobre los datos productivos tenemos toda la arquitectura de defensa,s lo backups, muchas veces son discos o dispositivos de almacenamiento masivo que quedan en algún armario, en alguna sala que quizás no está lo suficientemente protegida.

Amneris Teruel [00:37:13] Vamos a pasar al siguiente requerimiento que ya estamos cerca del final. Si el requerimiento 10 es rastre y supervise los accesos; es decir, tenemos que activar todas las auditorías que tengamos nativas de las diferentes plataformas. Revisémoslas, asegurémonos de que los logs son inalterables, y un tema que en la auditoría se mira mucho y no es menor, que es que los relojes estén sincronizados. Es importante a nivel de auditoría tener un criterio con respecto a los horarios de los distintos servidores, porque si no en un eventual análisis forense, si los relojes no están sincronizados el análisis forense carece de toda fortaleza.

Amneris Teruel [00:38:00] Miren qué interesante la respuesta a aquellos que tienen implementada alguna solución de multifactor, el 36 por ciento contesta que sí, bien qué bueno, quizás lo que haya que hacer con la nueva normativa es extenderlo a más usuarios o no, pero si ya tienen alguna solución es un gran paso ganado. Hay un 24 por ciento que no lo tiene y un 40 por ciento que no contestó. Bueno, aquellos que no lo tengan y que deban cumplir PCI, tengan en cuenta que no solo implica esto un cambio de hardware o de software, sino también un cambio cultural que hay que trabajar con tiempo.

Amneris Teruel [00:38:44] Pasemos, ahora sí, al requerimiento 11 que dice pruebe con regularidad los sistemas y procesos de seguridad. Hacer los tests de penetración anuales que que se exigen, verificación de la integridad de los datos y del software. Hay diferentes plataformas que les van a permitir a ustedes ejecutar procesos que verifican la integridad de que, por ejemplo, el sistema operativo no tenga componentes adulterados o que algún software de algún proveedor de terceros tenga todos sus elementos integros que estén firmados y que no hayan sido adulterado después de haber sido firmados. Muchas veces estos procesos de integridad consumen recursos porque son procesos pesados, bueno, habrá que planificarlo y hacerlo en un momento de poca actividad.

Amneris Teruel [00:39:33] Y por último, el requerimiento 12, que quizás es el más social, que dice mantener una política que aborde la seguridad de la información para todo el personal. Generar conciencia, establecer procedimientos, realizar evaluaciones, mantenerse actualizado,... Pero es todo generar conciencia. Ustedes pueden tener el esquema más seguro, sin embargo, si hay alguien dentro de la organización que presta su usuario y contraseña al vecino, es un punto de entrada increíble y que tira abajo o destruye con muchísima facilidad toda la arquitectura de seguridad que ustedes hayan podido montar. Así que no perder de vista este factor humano, que integra fuertemente el mundo de la seguridad.

Amneris Teruel [00:40:24] Y bueno, ya habiendo recorrido los 12 requerimientos desde HelpSystems, los podemos ayudar, y mucho.Nosotros en HelpSystems tenemos cuatro grandes áreas de diferentes productos. La seguridad es una de las áreas más fuertes en las que trabajamos muchísimo y tenemos muchas soluciones que nos pueden ayudar, con productos confiables, multiplataforma, que evolucionan permanentemente. Les cuento que yo que estoy del lado de adentro de HelpSystems, me cuesta mucho mantenerme al día con todas las nuevas versiones y funcionalidades que se le agregan a los diferentes productos. De los 12 requerimientos lo podemos ayudar, les diría en casi todos. Me atrevo a decir que en el último, que es el más social y cultural, es donde menos podemos ayudar. Pero en todos los demás tenemos soluciones que pueden colaborar en que ustedes cumplan con ellos.

Amneris Teruel [00:41:21] Por ejemplo, tenemos un producto denominado GoAnywhere para todo lo que es transferencia segura de archivos. Cuando tengo que mover información sensible, quizás con datos de titulares de tarjetas de crédito y quiero que viaje en forma encriptada con toda la gestión de la transferencia segura. Tenemos Vityl como herramienta SIEM para todo lo que es la gestión en tiempo real de las auditorías y de la actividad y la seguridad de los equipos. Interact como herramienta para quienes sean usuarios de IBM i y necesitan sacar la información de auditoría del IBM i hacia afuera para, por ejemplo, integrarlo con una herramienta SIEM. Network Security, un firewall de última capa para la plataforma IBM i. Crypto Complete, una herramienta para encriptado de información sensible, StanGuard Antivirus, antivirus para IBM i, Linux sobre Power, AIX, los podemos ayudar mucho con esto, esta es una herramienta que está con mucha, mucha fuerza. Y después Compliance Monitor, Authority, Brooker y Data Thread son herramientas para la plataforma IBM i, para todo lo que es auditoría, gestión de usuarios privilegiados y detección de cambios a bases de datos. Tenemos una gama importante, así que cuenten con nosotros desde desde el lado de la ayuda que les podemos dar.

[00:42:46] Así que bueno, resumiendo todo lo recorrido en estos minutos, PCI aplica a quienes almacenan, procesan o transmiten información de los titulares. Es una muy buena práctica más allá de que hay que cumplirla. Tiene ciclos de aproximadamente 3 años, tiene 12 puntos genéricos que lo recorrimos hoy. Hoy está vigente como mejor práctica la versión 3.2, pero a partir de febrero entra en vigencia como obligatoria, excepto este cambio a TLS 1.1 o superior. Recuerden que lo nuevo que destacamos fue para el requerimiento 4, 6 y 8; TLS 1.1 superior, Multifactor Authenticator para todos los administradores que se conectan desde fuera de la consola y ajustar los procesos de desarrollo. Tengan en cuenta que los podemos ayudar.

[00:43:46] Bien, llegó el momento de poder dar respuesta a las inquietudes que se hayan generado, así que pueden entrar al área de preguntas y respuestas y lo vamos viendo juntos y escriban ahí sus inquietudes. Mientras van escribiendo las preguntas, les cuento que cuando termine este webinar les vamos a mandar la grabación del webinar en su totalidad, por si quieren compartir con alguien de su organización, les vamos a mandar material de interés sobre PCI y también les vamos a mandar una invitación al próximo webinar que es el miércoles 27 de septiembre, donde vamos a hablar sobre PCI 3.2, pero con un enfoque especial para la plataforma IBM i.

Amneris Teruel [00:44:42] Y también los invitamos a que nos pidan ayuda, nos llamen, nos digan que quieren una llamada con alguno de los expertos de seguridad de HelpSystems. Mantenemos una charla, nos cuentan sus inquietudes y bueno, y compartimos algunas ideas o como atacar mejor este cumplimiento.

Amneris Teruel [00:45:07] A ver, estoy leyendo algunas preguntas. Miren, por acá tenemos a Pablo, dice: tengo más de 100 usuarios con privilegios elevados, ¿todos deben usar MFA, Multifactor?. Si vamos a la teoría, sí. Y de esto habla la teoría: si hay 100 usuarios que tienen privilegios especiales, si vamos a la base de la normativa, los 100 deberían cumplir con esta condición. Quizás lo que te invitaría Pablo frente a esto es tratar de bajar el número de 100, tratar de evitar el problema. Buscando algunos recursos y quizás darle a esos usuarios privilegios especiales solo y estrictamente en los momentos que lo requieran y que sea de una manera transparente para ellos. Bueno, gestionar un poco este número 100 y tratar de bajarlo. Pero la teoría diría que si.

Amneris Teruel [00:46:29] Enrique me dice. La regulación habla de plataformas susceptibles a virus. ¿Cuáles son? En todo lo que solicita la regulación respecto antivirus habla de aquellas plataformas susceptibles. Usa exactamente ese adjetivo, donde uno diría bueno, ¿pero cuáles no? Es difícil dar una lista. Sabemos que hay plataformas muy vulnerables. La plataforma de Windows, que sabemos que tiene muchas vulnerabilidades, o no solo que las tiene, sino que son explotadas porque en realidad todas las plataformas tienen vulnerabilidades. Lo que pasa es que hay veces que son destinatarias de más ataques o no. También recientemente, en otro webinar habíamos comentado, justamente habíamos hablado de esto, de los diferentes tipos de ataques y que está habiendo muchos más ataques sobre Linux, que son principalmente los que hostean páginas web. Entonces, ¿son susceptibles? Sí, porque se están entre comillas, poniendo de moda, entonces: implementación de antivirus en el mundo Linux. Para todos los que son de la plataforma IBM i, sabemos que el IBM i tiene una reputación de poco susceptible a los virus, pero poco no quiere decir que no lo es. En realidad hay que hacer una evaluación de cada una de las plataformas que ustedes tengan, comenzando desde las más vulnerables, que de mercado se sabe que lo son. Pero no hay una lista que diga que tal o cual no lo es, porque realmente no existe un sistema no vulnerable. Todos tienen algún grado de vulnerabilidad.

Amneris Teruel [00:48:07] Vamos con la última pregunta porque ya estamos sobre el tiempo. Dice Mari, de las herramientas que presentaste ¿son compatibles a distintas plataformas, por ejemplo para Windows, Linux, Unix, AIX, Solaris, etc.? La lista de herramientas que nombré tiene un surtido. Hay algunas que son multiplataforma, algunas otras que nombré son exclusivas de algunas plataformas. Pase muy rápido por la pantalla. Te invito, Mari, a que te pongas en contacto con nosotros y nos digas qué estás buscando y te decimos cuál de ellas puede ajustarse a la plataforma que tenga.

Amneris Teruel [00:49:02] Y bueno, ya cumplimos, un poquito excedidos nuestros 45 minutos que nos habíamos propuesto. Antes que nada agradecerles que hayan estado presentes en este webinar. Las preguntas que hayan quedado sin contestar trataremos de contestarlas offline, por email o por algún contacto que ya tengamos y los esperamos en nuestro próximo webinar. Espero que les haya sido de utilidad. Hasta pronto.

Contacte a un experto en Seguridad

¿Está preparado para su auditoría PCI DSS? Solicite en forma gratuita y sin compromiso una llamada con los expertos en Seguridad Informática de HelpSystems para que lo guíen en cómo nuestras soluciones pueden ayudarlo a cumplir con los requisitos de PCI DSS 3.2.