Los primeros días de abril estuvieron muy ocupados por infracciones. Primero, Krebs on Security reveló que, durante un período de ocho meses, Panera Bread ignoró la filtración de más de 37 millones de datos de clientes. Luego, se divulgó la noticia de una violación en septiembre pasado en el proveedor de la interfaz de cliente [24] 7.ai.

Aún se desconoce su alcance total, pero al momento de escribir esto, el cliente de [24] 7, Delta Airlines, dijo que “varios cientos de miles de clientes pueden haber estado expuestos”, y su compañero cliente, Sears Holdings, señaló que se accedió a menos de 100 mil números de tarjetas de crédito de los clientes.

En una declaración oficial, Delta explicó que la fuga [24] 7.ai provino de un malware en el programa; pero en Panera, un punto final no autenticado de la API fue el culpable. Panera supo sobre la violación el 2 de agosto del 2017, pero la compañía parece haberla ignorado.

Para aquellos que buscan priorizar la seguridad de la API, u obtener más información al respecto, nos gustaría compartir esta lista de los cinco principales mitos de seguridad de la API.

Mito # 1: La seguridad de la API es una característica, no una tecnología.

Según Jason Macy, director de tecnología del proveedor de gestión de seguridad API Forum Systems, “muchos proveedores en el panorama de productos API hablan de tener características de seguridad de la API”. En realidad, señaló, “afirmar que tienen características que proporcionan aspectos de seguridad AP, es como afirmar tener características que proporcionan seguridad de firewall o antivirus”.

La protección proviene de los productos, no de las características, afirmó: “Del mismo modo que no confiaría en que sus aplicaciones ofrecen protección real de firewall o malware, no debería esperar que sus plataformas de administración de APIs proporcionen una protección de seguridad real de la API”.

Keith Casey, coautor de A Practical Approach to API Design(Leanpub, 2016), dijo que la seguridad API es una mentalidad de proceso. Casey trabaja como solucionador de problemas de API en el proveedor de autenticación Okta, sí, ese es su verdadero nombre, y apunta a los cinco pilares de la administración de la API: ciclo de vida, interfaz, acceso, consumo y negocios.

Los cinco pilares, explicó, son la forma “en que miramos el mundo”. Cualquier buena plataforma de administración de la API cubrirá los cinco aspectos (y probablemente otros). “El software de seguridad” solo cubrirá ese pilar central: Acceso.

Si bien Casey señaló que una herramienta específica de seguridad como la de Forum Systems puede ser “complementaria a todo lo demás”, eso no significa que la protección no pueda provenir de herramientas que aborden la gestión completa del ciclo de vida.

Mito # 2: Las soluciones de seguridad de la API basadas en software son seguras

Si cree que esto no es un mito, Macy preguntó: “¿Cuántas vulnerabilidades se necesitan para convencerlo de lo contrario?” De acuerdo, todavía estamos aprendiendo más acerca de lo que sucedió en Panera, pero para más ejemplos probados, Macy apuntó a Spectre, Meltdown, ShellShock y Heartbleed. Specter y Meltdown, explicó, “permite que código de terceros que se ejecutan en su sistema de seguridad comprometan el sistema. Sin embargo, las soluciones de seguridad API basadas en productos de seguridad tienen sistemas operativos bloqueados, que no permiten código de terceros, y por lo tanto no son, y nunca han sido, susceptibles a las vulnerabilidades”.

Mito # 3: La seguridad de la API es simple
El concepto de API en sí mismo es simple: en realidad, una interfaz de programa de aplicación solo conecta dos programas. Eso no significa que los asegure. “Las API representan una evolución de las tecnologías que han liderado el camino hacia las tecnologías móviles y en la nube, y una complejidad cada vez mayor en los sistemas interconectados”, anotó Macy. Pero “la simplicidad de la conexión”, afirmó, es lo que crea complejidad. Él dice que la información que se encuentra está “donde emergen los vectores de amenaza reales”. Cuanto más simple sea su enfoque de solución de seguridad API, menos seguro será”.

Casey añadió que Macy tiene razón, en parte, pero no está de acuerdo en el por qué: “El problema no es solo la creciente complejidad, sino el hecho de que los límites se han movido”. En los viejos tiempos de la seguridad, explicó, los usuarios “tenían que estar físicamente en la red, o dentro del firewall. “De manera predeterminada, los datos estaban restringidos a los que estaban dentro.

“Lo que las APIs han hecho es crear estos lugares en los que queremos permitir que las personas utilicen nuestros sistemas, datos o funciones internas de la manera que describimos”, continuó Casey. El matrimonio de compartir datos mientras se protege es difícil por defecto. Además de eso, agregó, “dado que la mayoría de la gente no ha pensado ‘esto está fuera de mi firewall, ¿y ahora qué?’, tenemos nuevas vulnerabilidades y ataques que nos golpean”.

Mito # 4: una puerta de enlace API proporciona la misma protección que una puerta de enlace de seguridad API

Mike Cook es un especialista en gobernabilidad, riesgo y cumplimiento (GRC) para ciberseguridad sin fines de lucro (ISC, por sus siglas en inglés)². Él dijo que los gateways de seguridad API “deberían usarse más… Las APIs entran y pueden leer todos sus datos o leen los datos de otra aplicación que tiene”. Sin una, pregunta: “¿Puedes asegurarse? que esa API, esa otra parte, la información que sale, es solo la información que necesitan y que se les permite tener? O eso … la compañía del otro lado de la API ¿es realmente esa compañía?

Entonces, ¿por qué no obtener esa seguridad de una puerta de enlace API básica? Macy señaló: “Si el producto de la puerta de enlace API en sí mismo puede verse comprometido, no importa qué característica de seguridad API ofrezca. Los gateways API no se basan en tecnología de ciberseguridad; están basadas en plataformas de integración que se ejecutan como aplicaciones de software en sistemas operativos inseguros. “Debido a que las pasarelas de seguridad están diseñadas expresamente para protegerlo, utilizan almacenamiento seguro de políticas y garantías de integridad, anotó Macy”, para evitar que los productos mismos puedan ser comprometidos”.

Mito # 5: La identidad de la API está separada de la seguridad de la API
Macy señaló que este mito proviene de “años de práctica industrial divergente que resulta de la identidad y el control de acceso como una práctica separada de la ciberseguridad”. Los productos de seguridad cibernética no están diseñados para admitir la identidad, y los productos de identidad API no están diseñados para imponer la seguridad. “La mejor API de seguridad requiere que el acceso a la identidad y la ciberseguridad funcionen juntos. “La seguridad de la API es dinámica y se basa en muchos criterios”, explicó, “El usuario y el comportamiento del usuario son aspectos críticos de la decisión y el cumplimiento”.

-Terena Bell, CSO (EE.UU.)