Integre la seguridad de las API en el cumplimiento de normativas: Seis ejemplos a tener en cuenta
P: ¿Por qué se imponen sanciones a las empresas por incidentes relacionados con la seguridad de las API?
R: Porque los reguladores están empezando a comprender lo que los atacantes ya saben: las API expuestas o mal configuradas prevalecen, son fáciles de vulnerar y, a menudo, no están protegidas.
Todo lo que se necesita es una API vulnerable
Cada vez que un cliente, partner o proveedor interactúa digitalmente con su empresa, existe una API entre bastidores que facilita un intercambio rápido de datos, que a menudo son confidenciales. Los atacantes de hoy en día saben que no siempre necesitan utilizar complejos métodos de varios pasos para robar sus datos. En lugar de eso, pueden eludir los elementos intermedios (por ejemplo, sus aplicaciones) y dirigirse directamente a sus API.
¿Importa si un documento normativo de 200 páginas menciona explícitamente, implica sutilmente o indica vagamente que proteger las API es importante? En realidad no. Porque una filtración de datos es exactamente eso, una filtración de datos, independientemente de cómo o dónde se ejecutó. Lo único que se necesita es una API vulnerable para que sus datos acaben vulnerados, robados o publicados para que los vea todo el mundo.
Las filtraciones de datos se están produciendo mientras usted espera
¿Puede esperar la seguridad de las API mientras da prioridad a las amenazas que sus reguladores resaltan, como el ransomware? Lamentablemente no. Las API se multiplican en número y en riesgo a medida que las empresas implementan nuevos productos y servicios digitales.
El 66 % de las organizaciones encuestadas ha sufrido un incidente de seguridad relacionado con las API y la mayoría no cuenta con los controles o las herramientas necesarios para detenerlo. Mientras tanto, el coste medio de una filtración de datos. aumenta en un 12,6 % (hasta 5,05 millones de dólares) cuando una organización no cumple con las normativas.
Si adopta un enfoque proactivo para detectar todas las API, evaluar el riesgo de cada una y protegerlas de las filtraciones, protegerá sus datos de los resultados exactos que los reguladores están tratando de evitar".
¿Cómo afecta esto a su programa de cumplimiento?
Si adopta un enfoque proactivo para detectar todas las API, evaluar el riesgo de cada una y protegerlas de las filtraciones, protegerá sus datos de los resultados exactos que los reguladores están tratando de evitar.
En esta entrada del blog, presentamos una revisión de alto nivel de las seis normativas y directrices que indican la necesidad de protección de las API, y resaltaremos ejemplos clave de formas de cumplirlas.
6 normativas y marcos clave
1. Normas de Seguridad de Datos del Sector de las Tarjetas de Pago (PCI DSS) versión 4.0
PCI DSS se ha convertido en una norma global para proteger 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, está en el punto de mira para el cumplimiento de las normas.
El requisito 6.2.3 de PCI DSS 4.0 se centra en la necesidad de que las organizaciones revisen el código de su aplicación personalizado a medida para garantizar que no se transmita ninguna vulnerabilidad a la fase de producción. Este requisito, específico de las API, ofrece orientación para confirmar que el software de una organización utiliza de forma segura las funciones de los componentes externos (bibliotecas, marcos, API, etc.).
Una de las varias formas de cumplirlo es validando 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).
2. Reglamento General de Protección de Datos (RGPD)
RGPD es una legislación de la Unión Europea cuyo objetivo es reforzar y unificar la protección de datos de las personas dentro de la Unión Europea. Sin embargo, el RGPD no se limita a las empresas con sede en la UE; cualquier organización que ofrezca bienes o servicios de consumo en la Unión Europea debe cumplirlo.
El artículo 25 del RGPD tiene sus raíces en los mínimos privilegios, lo que exige a las empresas que implementen "medidas técnicas y organizativas apropiadas con miras a garantizar que, por defecto, solo sean objeto de tratamiento los datos personales que sean necesarios para cada uno de los fines específicos del tratamiento". A su vez, los desarrolladores de API deben implementar controles de autenticación y autorización de usuarios para proteger los datos confidenciales que fluyen a través de sus API.
Este es un gran ejemplo de cómo la seguridad de las API se integra en los programas generales de cumplimiento y seguridad de su empresa. Conceptos como el de mínimos privilegios no solo son relevantes para nosotros, los humanos; las API también deberían tener la cantidad justa de acceso para hacer su trabajo.
3. Ley de Resiliencia Operativa Digital (DORA)
En total, más de 22 000 instituciones financieras y proveedores de servicios de TI de la Unión Europea se ven afectados por los requisitos de DORA, que están destinados a ayudar a las organizaciones a resistir ante los ciberataques y recuperarse de ellos.
¿Cómo encaja la seguridad de las API en DORA? Analicemos la naturaleza del artículo 3 de DORA , que obliga a las organizaciones a utilizar soluciones y procesos basados en TIC que:
minimizan los riesgos relacionados con los datos, el acceso no autorizado y los defectos técnicos;
previenen la falta de disponibilidad de los datos, la pérdida de los datos y las infracciones de integridad y confidencialidad; y
garantizan la seguridad de la transferencia de datos.
Dado que el propósito principal de las API es transferir datos, es esencial probar regularmente sus API para detectar vulnerabilidades, incluida la falta de controles de autenticación y la exposición accidental a la red pública de Internet. Mediante la aplicación de un enfoque "shift-left" para probar las API, puede evitar que las vulnerabilidades lleguen a la fase de producción.
4. Ley de transferibilidad y responsabilidad de seguros médicos (HIPAA)
La HIPAA se centra en las normas de privacidad y seguridad de los datos para proteger la información sanitaria protegida (PHI) en los registros sanitarios electrónicos y los sistemas de TI de atención sanitaria. Cualquier proveedor de atención sanitaria, administrador de seguros o centro de compensación de EE. UU. que almacene o transmita electrónicamente la PHI debe cumplir con la HIPAA.
La norma de privacidad de la HIPAA especifica que las entidades cubiertas "deben desarrollar e implementar políticas y procedimientos que restrinjan el acceso y los usos de la información sanitaria protegida según las funciones específicas de los miembros de su plantilla".
Por lo tanto, los desarrolladores de API de una organización deben integrar medidas de seguridad técnicas como la autenticación, los ID de usuario únicos y los controles de acceso basados en funciones para garantizar que se aplican los mínimos privilegios.
5. Directiva de seguridad de sistemas de redes y de información (NIS2)
La Unión Europea adoptó la versión 2.0 de la Directiva NIS en enero de 2023, que se basa en las directrices de la versión original para proteger la infraestructura de TI y notificar incidentes.
Cabe destacar que la NIS2 incluye un nuevo énfasis en proteger las cadenas de suministro: ahora, las empresas deben evaluar el riesgo y proteger sus cadenas de suministro de TI y sus relaciones con proveedores externos.
Dado que las API se utilizan a menudo para integrar servicios externos (desde proveedores de software hasta proveedores de servicios en la nube), garantizar su seguridad es clave para mostrar a los reguladores que su organización está protegiendo los datos de sus clientes y la cadena de suministro en general de los ataques.
6. Consejo Federal de Certificación de Instituciones Financieras (FFIEC)
La FFIEC crea las directrices y normas para que los reguladores federales supervisen el sector financiero de EE. UU. Esto incluye la Reserva Federal y la FDIC. La misión del consejo es proteger a los consumidores e inversores del fraude, el abuso y el uso indebido.
Al revisar las directrices de la FFIEC, queda claro cómo la protección de las API puede ayudar a las organizaciones a proteger a los consumidores del fraude y el robo de identidad. Por ejemplo, la FFIEC recomienda que las empresas creen un inventario de todos los sistemas de información, incluidas las API, que requieren autenticación y controles de acceso.
La autorización también es fundamental: la FFIEC recomienda implementar seguridad por capas; por ejemplo, actividades de supervisión, registro y notificación para identificar y hacer un seguimiento del acceso no autorizado a las API.
Proteger las API también significa proteger la confianza
Las seis normativas y directrices que se describen en esta entrada del blog tienen una cosa en común: proteger los datos que otras personas le han confiado.
Como sabe, lo que está en juego en una filtración de datos de API es algo más que las sanciones. La confianza y la reputación están en juego, entre sus clientes, empleados y los reguladores que cubren su sector. Los reguladores necesitan ver que está aplicando la combinación adecuada de personas, procesos y herramientas para evitar que se produzcan ataques como estos.
Más información
¿Le gustaría obtener más información sobre los requisitos relacionados con las API de las seis normativas que hemos visto en esta publicación?