PCI/DSS

En nuestra actualidad las tarjetas como medio de pago se han vuelto muy populares y a su vez fundamentales, es por eso que dos grandes compañías VISA y Mastercard crearon el estándar de protección de datos PCI/DSS con la intensión de minimizar el fraude en sus usos y a su vez apoyar a las organizaciones en la implementación de las buenas practicas de seguridad recogidas en esta norma. 

PCI/DSS es administrado actualmente por la empresa PCI Security Standards Council, que se basa en el mejoramiento de estándares de seguridad a través del desarrollo que ayude a la mejora de la protección de datos. 

Algunas características de este estándar son sus normas de seguridad de datos de la industria de tarjetas de pago (PCI DSS) que se desarrollaron para fomentar y mejorar la seguridad de los datos del titular de la tarjeta y facilitar la adopción de medidas de seguridad uniformes a nivel mundial. Las PCI DSS están diseñadas para proporcionar una referencia de requisitos técnicos y operativos desarrollados para proteger los datos de los titulares de tarjetas. Las PCI DSS se aplican a todas las entidades que participan en el procesamiento de tarjetas de pago, entre las que se incluyen comerciantes, procesadores, adquirientes, entidades emisoras y proveedores de servicios, como también todas las demás entidades que almacenan, procesan o transmiten CHD (datos del titular de la tarjeta) o SAD (datos de autenticación confidenciales).

Las PCI DSS constituyen un conjunto mínimo de requisitos para proteger los datos de titulares de tarjetas y se pueden mejorar por medio de controles y prácticas adicionales a fin de mitigar otros riesgos y de leyes y regulaciones locales, regionales y sectoriales. Además, la legislación o las regulaciones pueden requerir la protección específica de la información de identificación personal u otros elementos de datos (por ejemplo, el nombre del titular de la tarjeta). Las PCI DSS no sustituyen las leyes locales ni regionales, las regulaciones gubernamentales ni otros requisitos legales.

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.

Alcance de los requisitos de las PCI DSS. . .

Los requisitos de seguridad de las PCI DSS se aplican a todos los componentes del sistema incluidos en el entorno de datos del titular de la tarjeta o conectados a este. El CDE (entorno de datos del titular de la tarjeta) consta de personas, procesos y tecnologías que almacenan, procesan o transmiten datos de titulares de tarjetas o datos confidenciales de autenticación. El término “componentes del sistema” incluye dispositivos de red, servidores, dispositivos informáticos y aplicaciones. Los componentes del sistema incluyen, a modo de ejemplo:

• Sistemas que ofrecen servicios de seguridad (por ejemplo, servidores de autenticación), que facilitan la segmentación (por ejemplo, firewalls internos) o que pueden afectar la seguridad del CDE (por ejemplo, servidores de resolución de nombres o de redireccionamiento web).
• Componentes de virtualización, como máquinas virtuales, interruptores/routers virtuales, dispositivos virtuales, aplicaciones/escritorios virtuales e hipervisores. 
• Los componentes de red incluyen, a modo de ejemplo, firewalls, interruptores, routers, puntos de acceso inalámbricos, aplicaciones de red y otras aplicaciones de seguridad. 
• Los tipos de servidores incluyen, a modo de ejemplo: web, aplicación, bases de datos, autenticación, correo electrónico, proxy, NTP (protocolo de tiempo de red) y DNS (servidor de nombre de dominio). 
• Aplicaciones, que abarcan todas las aplicaciones compradas y personalizadas, incluso las aplicaciones internas y externas (por ejemplo, Internet). 
• Cualquier otro componente o dispositivo ubicado en el CDE o conectado a este. 

El primer paso de una evaluación de las PCI DSS es determinar con exactitud el alcance de la revisión. Por lo menos una vez al año y antes de la evaluación anual, la entidad evaluada debería confirmar la exactitud del alcance de las PCI DSS al identificar todas las ubicaciones y los flujos de datos de titulares de tarjetas y al asegurar que se incluyan en el alcance de las PCI DSS. Para confirmar la exactitud e idoneidad del alcance de las PCI DSS, realice lo siguiente: 

• La entidad evaluada identifica y documenta la existencia de todos los datos del titular de la tarjeta en su entorno, con la finalidad de verificar que no haya datos del titular de la tarjeta fuera del CDE actualmente definido.
• Una vez que se hayan identificado y documentado todas las ubicaciones de los datos de los titulares de tarjetas, la entidad utiliza los resultados para verificar que el alcance de las PCI DSS sea apropiado (por ejemplo, los resultados pueden ser un diagrama o un inventario de ubicaciones de datos de titulares de tarjetas).
• La entidad considera que todos los datos del titular de la tarjeta encontrados están dentro del alcance de la evaluación de las PCI DSS y forman parte del CDE. Si la entidad identifica los datos que no están actualmente en el CDE, se deberán eliminar de manera segura, migrar al CDE actualmente definido o al CDE redefinido para incluir estos datos. 
• La entidad retiene la documentación que muestra cómo se determinó el alcance de las PCI DSS. La documentación se conserva para la revisión por parte de los asesores o como referencia durante la siguiente actividad anual de confirmación del alcance de las PCI DSS.

Mejores prácticas para implementar las PCI DSS en los procesos habituales. . .

A fin de garantizar que los controles de seguridad se sigan implementando correctamente, las PCI DSS deberán implementarse en las actividades BAU (habituales) como parte de la estrategia general de seguridad. Esto permite que la entidad supervise constantemente la eficacia de los controles de seguridad y que mantenga el cumplimiento de las PCI DSS en el entorno entre las evaluaciones de las PCI DSS. Ejemplos de cómo incorporar las PCI DSS en las actividades BAU:

1. Monitorear los controles de seguridad, tales como firewalls, IDS/IPS (sistemas de intrusión-detección o de intrusión-prevención), FIM (monitorización de la integridad de archivos), antivirus, controles de acceso, etc., para asegurarse de que funcionan correctamente y según lo previsto
2. Garantizar la detección de todas las fallas en los controles de seguridad y solucionarlas oportunamente. Los procesos para responder en caso de fallas en el control de seguridad son los siguientes:
   - Restaurar el control de seguridad.
   - Identificar la causa de la falla.
   - Identificar y abordar cualquier problema de seguridad que surja durante la falla del control de seguridad.
   - Implementar la mitigación (como procesos o controles técnicos) para evitar que la causa reaparezca.
   - Reanudar la monitorización del control de seguridad, quizás con una monitorización mejorada durante un tiempo a fin de verificar que el control funcione correctamente.
3. Revisar los cambios implementados en el entorno (por ejemplo, incorporación de nuevos sistemas, cambios en las configuraciones del sistema o la red) antes de finalizar el cambio y realizar las siguientes actividades:
   - Determinar el posible impacto en el alcance de las PCI DSS (por ejemplo, una nueva regla para los firewalls que permita la conectividad entre un sistema del CDE y otro sistema puede incorporar sistemas o redes adicionales al alcance de las PCI DSS).
   - Identificar los requisitos de las PCI DSS correspondientes a los sistemas y las redes afectados por los cambios (por ejemplo, si un nuevo sistema está dentro del alcance de las PCI DSS, se deberá configurar de acuerdo con las normas de configuración de sistemas, entre otros, FIM (monitorización de la integridad de archivos), AV (antivirus), parches, registros de auditorías, etc., y se deberá incorporar al programa trimestral de análisis de vulnerabilidades).
   - Actualizar el alcance de las PCI DSS e implementar los controles de seguridad, según sea necesario.
4. Si se implementan cambios en la estructura organizativa (por ejemplo, la adquisición o fusión de una empresa), se debe realizar una revisión formal del impacto en el alcance y en los requisitos de las PCI DSS.
5. Se deben realizar revisiones y comunicados periódicos para confirmar que los requisitos de las PCI DSS se siguen implementando y que el personal cumple con los procesos de seguridad. Estas revisiones periódicas deben abarcar todas las instalaciones y ubicaciones, en las que se incluyen tiendas minoristas, centros de datos, etc., e incluir la revisión de los componentes del sistema (o muestras de los componentes del sistema) a fin de verificar que siguen implementados los requisitos de las PCI DSS, por ejemplo, normas de configuración implementadas, parches y AV (antivirus) actualizados, registros de auditorías revisados y así sucesivamente. La entidad debe determinar la frecuencia de las revisiones periódicas en función del tamaño y de la complejidad del entorno. Estas revisiones también se pueden usar para verificar que se mantiene la evidencia correspondiente, por ejemplo, registros de auditorías, informes de análisis de vulnerabilidades, revisiones de firewall, etc., para ayudar a la entidad a prepararse para la siguiente evaluación sobre cumplimiento.
6. Revisar las tecnologías de hardware y software, al menos, una vez al año para confirmar que el proveedor las sigue admitiendo y que pueden satisfacer los requisitos de seguridad de la entidad, incluso las PCI DSS. Si se detecta que el proveedor ya no puede admitir las tecnologías o que no pueden satisfacer las necesidades de seguridad de la entidad, la entidad debe preparar un plan de recuperación que incluya el reemplazo de la tecnología si fuera necesario. 

Además de las prácticas anteriores, las organizaciones también deben considerar la opción de separar las tareas de las funciones de seguridad de modo que las funciones de seguridad y auditorías sean independientes de las funciones operativas. En entornos en los que una persona desempeña varias funciones (por ejemplo, operaciones de administración y seguridad), las tareas se deben asignar de manera tal que ninguna persona tenga control completo de un proceso sin un punto de verificación independiente. Por ejemplo, las tareas de configuración y de aprobación de cambios se pueden asignar a dos personas distintas.

GitHub

"Si no puedes con tu enemigo, únete a él". Una frase muy celebre del libro "El Arte de la Guerra" de Sun Tzu. Con mucha lógica por cierto, ya que en nuestros días se esta viendo muy seguido, sobre todo en la Corporación de Microsoft. Que ironía que hace unos años Steven Ballmer definieran a Linux como el cáncer de Microsoft y que en el transcurrir de nuestro año la compañía empiece amar a Linux con la genial idea de incorporarlo en un sistema llamado Azure, pero no solo les basto con esto, también tenían que adquirir una de las mayores empresas que nos brindaba gran parte de los repositorios que usamos los usuarios de Linux, afectando no solo a los programadores independientes sino que también poniendo en riesgo datos empresariales los cuales estaban basados en GIT.

Muchos de nosotros conocemos a GitHub desde los principios de nuestra carrera hasta la actualidad, sabiendo muy bien que funciona como una herramienta de seguridad, pentesting y hacking, que en el transcurrir de su vida ha llegado a ser una parte fundamental del Open Source. Pero no todo dura para siempre, y con el crecimiento exponencial de las nuevas herramientas de Microsoft desarrolladas con código abierto y tomando parte del kernel de Linux, no nos extrañemos de que en un tiempo se empiecen haber afectadas no solo una, sino que varias herramientas que usamos muchos de nosotros, los desarrolladores que no queremos depender de las políticas de una empresa que infligen nuestros derechos.

Muchos son los rumores del por qué de la nueva adquisición de Microsoft, algunos aseguran que GitHub estaba en quiebra, mientras que otros dicen que el mismo Linus Torvalds incentivo la idea de vender la empresa, lo cual no seria nada raro como muchos creerán, ya que en los inicios de la implementación de GNU con Linux, Linus Torvalds no estuvo de acuerdo dando como origen la idea del software privado. A su vez estimar la cantidad por la que se fue comprada también suele ser imprecisa ya que ambos lados suponen precios diferentes dejándonos con la intriga de cuanto dinero hubo de por medio. La noticia oficial asegura que GitHub fue comprada por 2 mil millones de Dolares, mientras que fuentes de Mircrosoft aseguran que fue comprada por mucho más, nada más que 7 mil quinientos millones de Dolares. El valor es incierto.
 
Esto significa que es verdad, ahora Microsoft no sera solo un sistema operativo como se cree, sino que a su vez empezara a implementar servicios de inteligencia artificial utilizando un software de Código Abierto, obviamente privatizado por ellos. El futuro de esta gran compañía asegura ser Azure. Pero mientras esto pasa, muchos de los usuarios que pertenecían a GitHub ahora se están trasladando a GitLab donde se cree encontrar la solución a los problemas de desarrollo de distintas empresas.

Estándar de Criptografía AES

Anteriormente habíamos mencionado las capaz de cifrado que utiliza la criptografía AES, pero no habíamos explorado a fondo sus principales características tanto de Cifrado como de Descifrado, por lo cual lo veremos en este articulo muy corto y sencillo a la vez.

CIFRADO. . .

SubBytes: La operación SubBytes consiste, según (NIS01), en una sustitución no lineal de bytes. Dicha sustitución se realiza aplicando la formula:

Existe una tabla de sustitución fija, llamada S-Box que aplica estas operaciones y permite realizar la operación SubBytes mediante un simple vistazo.

Entonces si necesitamos realizar la operación SubBytes al número {19}, no tenemos más que mirar la tabla, fijandonos en la fila 1x y la columna x9, obteniendo así que la transformación de {19} es {D4}. 

ShiftRows: La operación ShiftRows consiste, según (NIS01), en una rotación cíclica hacía la izquierda de las filas de la notación matricial del Estado, de manera que la primera fila permanece igual, la segunda fila se rota hacía la izquierda una posición, la tercer fila se rota hacía la izquierda dos posiciones y, por último, la cuarta fila se rota hacía la izquierda tres posiciones. 

A continuación mostraremos con claridad la función de esta operación.

MixColumns: En la operación MixColumns, los cuatro bytes de cada columna de la notación matricial del Estado se combina utilizando una transformación lineal invertible, como lo establece (NIS01). 

Cada columna se trata como un Polinomio y luego se multiplica el módulo x^4+1 con un polinomio fijo a(x)={03}x^3+{01}x^2+{01}x+{02}. Es más sencillo verlo como una multiplicación matricial, donde el Estado siempre se multiplica a la derecha de la misma matriz.

Multiplicando de esta manera, siempre teniendo en cuenta los aspectos matemáticos que hemos comentado, obtendremos el resultado de la operación MixColumns. Dentro de AES este es, sin duda, uno de los procesos más costosos en cuanto a cantidad de operaciones realizadas. 

AddRoundKey: La operación AddRoundKey consiste, según (NIS01), en la combinación de subclaves de ronda correspondiente con el Estado. Esta combinación se realiza a través de XOR.

En la imagen que corresponde al proceso de cifrado se observa que en la ronda inicial (Ronda 0) se realiza esta operación. En el caso que estamos estudiando, longitud de clave de 128 bits, la subclave de ronda 0 es la propia clave de cifrado. Es importante mencionar que, en el caso de tener claves de 192 y 256 bits, su correspondiente subclave de ronda 0 no es, lógicamente, la clave original, sino que sera un fragmento de 128 bits de está, en concreto sus 128 bits más significativos. 

DESCIFRADO. . .

InvSubBytes: Según (NIS01), la operación InvSubBytes es, al igual que la operación SubBytes, una sustitución no lineal de bytes. Dicha sustitución se realiza utilizando la formula:

De nuevo, existe una tabla de sustitución fija a la que hemos llamado InvS-box, la cual permite realizar la operación InvSubBytes de manera análoga a la operación SubBytes.

Esta tabla es inversa a la anterior que presentamos como S-box. Recordemos el ejercicio que se propuso anteriormente, en el que el byte {19}, a través de la operación SubBytes se transformo en el byte {D4}. Si ahora queremos aplicar la operación InvSubBytes al byte {D4}, miramos en la tabla la fila Dx y la columna x4, obteniendo así el byte {19}.

InvShiftRows: La operación InvShiftRows consiste, según (NIS01), es una rotación cíclica hacía la derecha de las filas de la notación matricial del Estado, de manera que la primera fila permanece igual, la segunda fila se rota hacía la derecha una posición, la tercera fila se rota hacía la derecha dos posiciones y, por último, la cuarta fila se rota hacía la derecha tres posiciones.

Consiste por tanto, en una rotación en dirección opuesta a la que se propuso en la operación ShiftRows. 

InvMixColumns: Según (NIS01), es la operación inversa a MixColumns. En ella cada columna se trata como un polinomio y luego se multiplica el módulo x^4 con un polinomio fijo a^-1(x)={0B}x^3+{0D}x^2+{09}x+{0E}. De nuevo es más intuitivo verlo como una multiplicación del Estado de la derecha de una matriz fija.

 AddRoundKey: en la operación AddRoundKey, se utilizan diferentes subclaves, todas derivadas de la clave original. 

La clave expandida, una sucesión de todas las subclaves, puede verse como una matriz de 4 filas por [4 × (Nr + 1)] columnas. Es decir, que la longitud de la clave expandida var´ıa dependiendo de Nr, que a su vez varía dependiendo de la longitud de clave. Por ejemplo, la clave expandida para una longitud de clave de 128 bits se representa como una matriz de 4 filas por (4 × 11), es decir, 44 columnas. Análogamente, para una longitud de clave de 192 bits (la cual se representa en la clave expandida como una matriz de 4 × 6), la clave expandida es una matriz de 4 filas por (4 × 13), o lo que es lo mismo, 52 columnas. Todas las subclaves utilizadas, para cualquier longitud de clave, son de 128 bits, o lo que es lo mismo, 4 columnas. Esa es la razón por la que a más longitud de clave, más número de rondas. Es importante señalar que el cálculo de subclaves es idéntico para longitudes de clave de 128 y 192 bits, mientras que para 256 bits varía en ciertos detalles. Un dato del AES, necesario para el cálculo de subclaves para claves de cualquier longitud, es la matriz Rcon. Dicha matriz, según [NIS01] es de la siguiente forma:

Las columnas de la matriz de clave ampliada se calculan en diez grupo (uno por cada columna de la matriz Rcon) de Nk columnas cada uno.