Prácticas recomendadas para cumplir la norma PCI DSS v4.0 sobre seguridad de API
Tener problemas para mantenerse al día con las regulaciones que cambian constantemente no es nada nuevo para los equipos de seguridad de TI. Piense en todas las organizaciones que definieron un enfoque para cumplir la Directiva sobre Seguridad de las Redes y los Sistemas Informáticos (NIS), para después conocer su continuación: NIS2. Y si se tiene en cuenta que más de 130 jurisdicciones de todo el mundo han promulgado leyes de privacidad de datos con mandatos que pueden cambiar, no es sorprendente que tan solo el 9 % de los ejecutivos sepa con seguridad que su empresa está preparada para cumplir todos los requisitos de divulgación.
Si se está preparando para cumplir la versión 4.0 de las Normas de Seguridad de Datos del Sector de las Tarjetas de Pago (PCI DSS v4.0), es posible que no se sienta del todo confiado.
La norma PCI DSS, creada por el Consejo de estándares de seguridad del sector de tarjetas de pago (PCI SSC), se ha convertido en un estándar global para la protección de los datos de pago. Si su empresa acepta las principales tarjetas de crédito y trata, almacena o transmite electrónicamente los datos de los titulares de tarjetas, debe cumplir esta normativa.
Los pilares de seguridad de PCI DSS
Los requisitos de la versión original abarcan los pilares fundamentales de seguridad que son tan importantes actualmente como lo eran cuando se publicaron por primera vez en 2006. Por ejemplo:
Supervisar y controlar el acceso a todas las cuentas administrativas de cualquier sistema de TI que procese o almacene datos de titulares de tarjetas
Asignar el acceso a los datos del sistema y del titular de la tarjeta según sea necesario y definir los requisitos de acceso por función
Las actualizaciones recientes siguen el ritmo de un panorama de amenazas que cambia constantemente
El problema es que el panorama de amenazas actual es más complejo que el de 2006.
Sí, las organizaciones todavía deben abordar la tendencia de los atacantes a dirigirse a áreas como cuentas con privilegios y usuarios con un número de permisos excesivo. No obstante, también necesitan adaptar sus programas de cumplimiento para tener en cuenta a los atacantes que tienen como objetivo los miles de API que incluyen las tecnologías de pago. Estos atacantes saben que las API son fáciles de explotar y ofrecen una forma eficaz de robar los datos de los titulares de tarjetas.
Por lo tanto, para cumplir con la norma PCI DSS v4.0, es necesario que su organización sepa comprender las amenazas dirigidas a las API y defenderse frente a ellas. En esta entrada del blog, compartiremos información sobre los riesgos, los requisitos y las diferentes formas de cumplir la normativa.
Los 4 objetivos clave de la norma PCI DSS v4.0
En general, la norma PCI DSS v4.0 se centra en cuatro objetivos clave:
seguir satisfaciendo las necesidades de seguridad del sector de pagos;
abogar por la seguridad como un proceso continuo;
ofrecer a las empresas flexibilidad (por ejemplo, nuevas herramientas o nuevos controles) para cumplir los requisitos; y
mejorar los métodos y procesos de validación.
Por qué la seguridad de las API es fundamental para proteger los datos de los titulares de tarjetas
La norma PCI DSS v4.0 considera explícitamente las API como un área clave que requiere visibilidad y protección. Entran en juego los cuatro objetivos. Sin embargo, el tercero (flexibilidad para utilizar nuevas herramientas y controles) es particularmente importante debido a los riesgos únicos que presentan las API. Por ejemplo:
Las API residen en el centro de todos los productos y servicios digitales que ofrece al cliente. La empresa media tiene entre 15 000 y 25 000 API, según su tamaño, diseñadas para facilitar el intercambio ininterrumpido de datos.
Estos datos incluyen información confidencial del cliente. En cada pago digital entra en juego una API que transmite datos entre aplicaciones, sistemas o terceros, entre otros.
Una sola API comprometida podría dar lugar al robo, la retención o la publicación de millones de registros para que todo el mundo pueda verlos. Y las API expuestas o mal configuradas prevalecen, son fáciles de vulnerar y, a menudo, no están protegidas, pasan desapercibidas o no se gestionan.
Por qué se preocupan los reguladores por las API de las tecnologías de pago
Los organismos reguladores son conscientes del riesgo de las API y su empresa debe demostrar que dispone de la visibilidad y los controles necesarios para evitar que los datos se vean comprometidos.
Los datos de las tarjetas de pago se ven afectados en más de un tercio (37 %) de las infracciones, según el Informe de 2023 de investigación sobre filtración de datos de Verizon. PCI DSS v4.0 incluye nuevos requisitos sobre la autenticación multifactorial y la longitud de la contraseña para proteger el elemento humano de la superficie de ataque del sector de los pagos.
No obstante, es importante recordar que las filtraciones de datos no siempre se deben a métodos de ataque bien conocidos y centrados en el ser humano, como el phishing para las contraseñas de los empleados.
Por ejemplo, el 18 % de los ataques a empresas de comercio electrónico implican el uso de código malicioso incrustado en las páginas web para el procesamiento de tarjetas. Los atacantes actuales son cada vez más sofisticados y se centran en los componentes automatizados no humanos del entorno de TI que no suelen estar bien protegidos, como las API.
El 78 % de las empresas ha sufrido un incidente de seguridad relacionado con las API, según nuestra investigación. A fin de reconocer la urgencia de las amenazas de API, PCI DSS v4.0 incluye nuevas reglas, directrices y prácticas recomendadas para la seguridad de las API. Para obtener más información, pasemos a describir el requisito 6.2.3.
Cumplimiento del requisito 6.2.3 de la norma PCI DSS v4.0
El requisito 6.2.3 se centra en la necesidad de que las organizaciones revisen el código de las aplicaciones hechas a medida (es decir, aplicaciones desarrolladas por un proveedor externo distintas a las aplicaciones comerciales estándar disponibles en el mercado) para garantizar que no se transmita ninguna vulnerabilidad a la fase de producción.
Este requisito ofrece orientación para confirmar que el software de una organización utiliza de forma segura las funciones de los componentes externos (bibliotecas, marcos de trabajo, API, etc.), lo que refleja el papel tan importante que desempeñan las API en la cadena de suministro de software y lo que se necesita para protegerlas.
Las API se han convertido en el método predeterminado de conectividad e intercambio de datos en los entornos de aplicaciones modernos. Teniendo esto en cuenta, proteger las API tanto con un enfoque de preproducción ("shift-left") como con un enfoque de posproducción ("shield-right") es esencial para que su empresa digital pueda resistir los ataques.
6 prácticas recomendadas de seguridad de API
A continuación se presentan seis prácticas recomendadas de seguridad de API que le ayudarán a cumplir el requisito 6.2.3.
Confirmar el uso de componentes basados en API y su postura de seguridad (por ejemplo, detectar cualquier error de configuración que provoque vulnerabilidades, incluido el uso de métodos de cifrado débiles, como se indica en el estándar)
Validar el comportamiento normal y esperado del uso de la API e implementar controles para bloquear a los agentes sospechosos de manera que no vulneren sus sistemas (por ejemplo, comprobar el comportamiento de la aplicación para detectar vulnerabilidades lógicas)
Detectar los marcos de trabajo utilizados por terceros para potenciar las API y determinar si alguno de ellos está obsoleto y es vulnerable
Crear un inventario completo de todas sus API, incluidas las diferentes versiones de API que está ejecutando, lo que le proporcionará información sobre posibles funciones no documentadas y puertas traseras que deba gestionar
Validar la seguridad de su código de API y evitar transmitir cualquier vulnerabilidad a la fase de producción
Implementar prácticas recomendadas de codificación segura para API, lo que le permitirá adoptar un enfoque programático para distribuir código de forma segura y continua
Requisitos adicionales para la seguridad de API en PCI DSS v4.0
PCI SSC también ha añadido otras dos secciones, que incluyen la seguridad de las API, a la norma PCI DSS v4.0. A continuación se ofrece un resumen de los dos requisitos adicionales que deberá cumplir.
Requisito 6.3.2 : se aplica al mantenimiento de un inventario de software personalizado y hecho a medida, así como de componentes de software de terceros que se han incorporado al software personalizado y hecho a medida, para facilitar la gestión de vulnerabilidades y parches.
Requisito 6.2.2 : se encarga de la formación del personal de desarrollo de software que trabaja en la creación de software personalizado y hecho a medida. Afirma que los desarrolladores deben recibir formación al menos una vez cada 12 meses sobre las medidas de seguridad relevantes para su puesto de trabajo, que incluye el diseño de software seguro y las técnicas de codificación seguras. Esta formación incluye herramientas de pruebas de seguridad y cómo utilizarlas para detectar vulnerabilidades en el software.
Cómo puede ayudarle Akamai API Security a cumplir los nuevos requisitos
Para cada requisito abordado en esta entrada, Akamai API Security (Noname Security) ofrece la protección de API que las empresas necesitan, no solo para cumplir con la norma PCI DSS v4.0, sino también para proteger continuamente los datos que le confían sus clientes.