Header Ads Widget

Ticker

6/recent/ticker-posts

Por qué la seguridad de las API es más importante que nunca


 

Seguridad API: en pos de MASH

Entre el incidente de Cambridge Analytica en Facebook y el Reglamento general de protección de datos ( GDPR ) que entró en vigor en toda Europa a partir del 25 de mayo, es seguro decir que la seguridad en línea ocupará un lugar central como nunca antes. Una repercusión de todo esto para los desarrolladores de API es un enfoque renovado en descubrir y analizar exactamente cómo los consumidores están interactuando con su API .

Desde Nissan hasta Tinder, muchas de las vulnerabilidades en línea de alto perfil que aparecen en los titulares últimamente se reducen a problemas con las API. Como resultado, existe una posibilidad muy real de que, especialmente para las grandes organizaciones, 2018 sea el año de la reunión con un especialista en seguridad de API.

Las API inseguras están provocando infracciones públicas y prensa negativa en muchas organizaciones.

Akshay Aggarwal , uno de esos especialistas en seguridad, es ex director de Microsoft y actual director ejecutivo de PeachTech . Apareció en nuestra Cumbre de Plataformas el año pasado y soltó algunas ideas sobre seguridad que, ahora más que nunca, constituyen una lectura esencial para todos los desarrolladores de API.

Vea a Akshay Aggarwal de Peach Tech presente en la Platform Summit:

Complejidad

Empecemos destacando el hecho de que la seguridad de la API es complicada . Eso no quiere decir que la seguridad web tradicional sea fácil, pero, como dice Akshay, “tan pronto como ingresas al mundo de la arquitectura de microservicios [a diferencia de una aplicación tradicional], la complejidad de este problema explota en un orden de magnitud o más. "

Como suele ser el caso, ese mayor nivel de complejidad está asociado con un costo adicional. Es una evidencia anecdótica, pero Akshay sugiere que, en su experiencia, corregir un error en una API frente a un error comparable en un sitio web estándar puede costar entre 1,5 y 2 veces más.

Si bien existen subprocesos de diseño comunes en muchas API, cada infraestructura de API funciona de manera diferente. En otras palabras, no existe un enfoque de "talla única" a la par con, digamos, agregar un firewall a una red. Como dice Akshay:

"Asegurar las API web es lento, manual y depende de la habilidad del evaluador".

Pero ahí no termina el problema.

Comprender y hacer pruebas futuras de las vulnerabilidades conocidas en su código está muy bien, pero Akshay anima a los desarrolladores a preguntarse "¿cuál es su plan para encontrar las vulnerabilidades desconocidas en su API?"

Un estudio realizado por HP encontró que el dispositivo de IoT (Internet de las cosas) promedio puede tener hasta 25 vulnerabilidades , incluido un cifrado insuficiente e interfaces de usuario inseguras. ; Es prácticamente seguro que algunas de estas fallas de seguridad estarán relacionadas con las API que se utilizan para dar datos y funcionalidad a dichos dispositivos cliente.

Es casi suficiente para hacer que quieras buscar algunos hackers de sombrero blanco para poner a prueba tu API ... o al menos revisar algunos cursos centrados en la seguridad de alguien como Troy Hunt , director regional de Microsoft y creador de herramientas como Have I Been Pwned .

Lea también: OAuth 2.0: por qué es vital para la seguridad de IoT

Responsabilidad

¿Quién es responsable de la seguridad de la API? Akshay presenta un resumen de un estudio reciente de Ovum que encontró que el 53% de los encuestados cree que el departamento de TI es responsable de proteger las API, mientras que el 47% dijo que el equipo de desarrollo de API en cuestión es responsable. Cuando existe este tipo de disparidad entre las respuestas de las personas, se vuelve demasiado fácil para la seguridad de la API pasar por alto.

Una de las diapositivas de Akshay señala que "la seguridad de la API ahora también depende del consumidor desarrollador". Para decirlo de otra manera, la responsabilidad no comienza y termina con los desarrolladores de API y / o el departamento de TI. Desafortunadamente, como señala, a menudo se asume que el desarrollador de la API se ha encargado de todo en el lado de la seguridad de la API.

Si bien se pueden argumentar que todos, desde los consumidores de API hasta los usuarios finales de las aplicaciones, tienen un papel que desempeñar en lo que respecta a la seguridad, probablemente sea más prudente que los desarrolladores de API asuman que la responsabilidad termina con ellos. Los procesos inseguros siempre volverán para atormentar al equipo de desarrolladores detrás de una API y, con el precedente establecido por las enormes multas potenciales que estamos viendo asociadas con el incumplimiento de GDPR , también pueden tener un impacto financiero significativo.

Relacionado: API de la guerra mundial: ciberataques a escala internacional

3 pasos para escalar la seguridad

Como ya mencionamos anteriormente, es difícil prescribir una "solución milagrosa" que funcione para todas las API. Sin embargo, lo que sí sugiere Akshay es un conjunto de tres puntos de control que pueden considerarse una base sólida para una buena seguridad de API.

1. Integrar con CI System

Akshay sugiere combinar sus medidas de seguridad con pruebas unitarias , con el objetivo final de integrarlas en sus herramientas y procesos existentes.

"Haga que las pruebas de seguridad sean solo un paso más en su proceso de compilación"

2. Pruebe la seguridad de cada compilación

Depender de las pruebas manuales es problemático por un par de razones. Además de consumir mucho tiempo, también depende de que la persona relevante se asegure de que lo agregue a su flujo de trabajo de forma regular. Todos sabemos que la vida a veces se interpone y, antes de que te des cuenta, has implementado una tonelada de código sin que se hayan realizado controles de seguridad.

3. Devolver resultados procesables

Para obtener algo de las pruebas automáticas, debe actuar sobre la información de las pruebas.
En realidad, se trata de dos partes, porque ambos deben tomar las medidas adecuadas en función del resultado y asignar el esfuerzo de remediación a un miembro del equipo. Pueden ser los propios desarrolladores de API, un equipo de control de calidad, un especialista en seguridad de TI o alguien de todas las áreas anteriores.

Lo interesante es que todos los puntos anteriores se reducen a una instrucción clave, y es una con un pequeño acrónimo para arrancar: MASH ( Make API Security Habitual ).

Más sobre seguridad API: proteja su plataforma API

Pensamientos finales

Quizás el mayor problema con la seguridad de API y microservicios en este momento es que a menudo se ve como una ocurrencia tardía, más que como una parte clave del proceso de desarrollo. Rik Turner, analista senior de Ovum, dice que "este estudio [mencionado anteriormente] destaca una alarmante falta de coherencia y propiedad en cómo se aborda la seguridad de API".

Eso se refleja en el pensamiento que nos deja Akshay, diciendo que, en última instancia, “[cualquier solución de su implemento] tiene que coincidir con las pruebas que ya está haciendo. Piense en la seguridad no como un caso único de prueba, sino como algo que se ajusta a su marco de prueba existente ".

Hemos visto anteriormente que hay muchas formas de hacer esto, que van desde repasar las mejores prácticas de seguridad de API e intentar piratear su propia API; Akshay bromea al comienzo de su charla diciendo que no crea API, sino que toma separarlos, hasta el uso de una herramienta externa para hacer el trabajo. Cualquiera que sea la ruta que tome, quizás lo más importante de todo sea asegurarse de que las personas a cargo de la seguridad de API en su organización estén protegiendo, probando y ajustando activamente las conexiones de API.

Publicar un comentario

0 Comentarios