Header Ads Widget

Ticker

6/recent/ticker-posts

Principales amenazas de seguridad de API en 2020: Entrevista del panel de expertos

 


Cuando se trata de seguridad API, ninguna integración es 100% segura. Las infracciones se encuentran con las noticias día tras día. Las conexiones vulnerables continúan exponiendo datos privados, lo que cuesta a las empresas millones de dólares en reparaciones y resulta en relaciones públicas terribles.

Para responder a esta crisis, nuestra Cumbre de Plataformas 2019 reunirá a algunos de los principales expertos del mundo en seguridad API. Para iniciar la conversación antes del evento, hemos reunido un panel de oradores expertos en seguridad para cubrir los temas de seguridad más urgentes en el espacio API actual.

Para este artículo, hemos entrevistado a Jacob Ideskog , arquitecto de soluciones y especialista en identidad en Curity , Keith Casey , solucionador de problemas de API en Okta , David Stewart , director ejecutivo y cofundador de Critical Blue , y Michał Trojanowski , desarrollador de software sénior en Allegro.pl . Le hemos pedido a cada uno que describa las principales amenazas a las que se enfrentan las API y las mejores prácticas que los proveedores pueden utilizar para mitigarlas. También descubriremos algunos anti-patrones de seguridad y echaremos un vistazo a la evolución futura de la seguridad en 2020 y más allá.

Amenazas actuales de la API

Las API son puertas poderosas a los datos del usuario. Canalizan información que, de ser robada, podría tener ramificaciones drásticas. Con el panorama de vulnerabilidades en constante evolución, ¿cuáles se destacan como áreas principales para un mayor énfasis en la seguridad?

Privacidad del usuario

Con demasiada frecuencia, se filtran secretos privados, claves o contraseñas de almacenamiento en la nube a actores nefastos. Según Jacob Ideskog, "robar la identidad de un usuario es más que solo las credenciales". La privacidad del usuario es la principal preocupación de Ideskog.

“No solo es importante tener en cuenta las credenciales, sino también que la privacidad del usuario es importante”, dice Ideskog. En alusión a la reciente legislación GDPR, Ideskog señala una presión adicional para que las empresas basadas en API protejan la privacidad del usuario con vigilancia.

Ataques de sobrecarga masiva

Keith Casey cita el costo creciente asociado con los datos robados en las verticales. “Contamos con información médica, financiera, personal y una variedad de otros tipos de información que son dañinos para las personas y grupos si se los roban”, dice Casey.

Los ataques de denegación de servicio o los costos de transacción masivos para un objetivo son igualmente valiosos para que los hackers los exploten. Por lo tanto, para Casey, las API basadas en el consumo sin límites estrictos de tasas son las más vulnerables.

Brecha de conocimiento

David Stewart reconoce que las amenazas siempre están evolucionando y, como tales, requieren mucha inversión financiera para mantener la seguridad (una forma de superar a los atacantes). Con las plataformas integradas de hoy, un solo eslabón de la cadena puede tener un efecto en cascada en toda la plataforma.

“Como este es un momento de crecimiento explosivo, muchas de las amenazas provienen de una educación deficiente, una implementación deficiente, la ingenuidad en cuanto a qué tan rápido y profundo se pierde el control y los datos una vez que un hack tiene éxito”, dice Stewart.

Probando lo inesperado

Evitar los exploits requiere pruebas exhaustivas del "uso de API fuera de sus patrones de uso esperados", dice Stewart. Trojanowski se hace eco de este sentimiento, citando cómo la seguridad de las aplicaciones es un "proceso constante de tratar de encontrar soluciones a las amenazas en constante evolución".

Trojanowski se da cuenta de cómo las API están llegando al mercado vulnerables incluso a vectores conocidos como CSRF o XSS. Otras amenazas ofrecen poca o ninguna solución actual, como "situaciones en las que el atacante logra hacerse pasar por otro usuario o en las que un actor malintencionado obtiene acceso legítimo a una API pero abusa del acceso", señala Trojanowski.

Trojanowski señala cómo la utilización del aprendizaje automático para monitorear la actividad de la API para tal mal uso puede ser una evolución futura para la seguridad de la API.

Prácticas recomendadas de seguridad

Conociendo las amenazas que existen, ¿qué pueden hacer los proveedores de API para armarse mejor? En resumen, nuestro panel resumió las mejores prácticas de seguridad de API como tales:

  • No construyas tu propio sistema
  • Construya con seguridad desde el principio
  • Educar y compartir conocimientos continuamente entre equipos.
  • Leer y seguir los estándares

Analicemos los detalles de lo que implican estas mejores prácticas.

No construya su propio sistema

Según Ideskog, lo # 1 que debe recordar con la seguridad es que es extremadamente difícil construir su propio sistema de seguridad. De hecho, volver a construir la rueda iría en contra de la filosofía de la mayoría de SaaS, PaaS e IaaS basados ​​en API .

“El diablo está en los detalles cuando se trata de seguridad, lo que significa que es un problema de“ eslabón débil ””, dice Ideskog. "Algunos pequeños errores en diferentes partes del sistema pueden generar una gran vulnerabilidad".

La seguridad no puede ser una ocurrencia tardía y tomar atajos puede ser perjudicial. Para Ideskog, esto equivale a revisar los estándares religiosamente y no a construir su propio sistema de seguridad.

Casey también cree que construir su propio sistema no es la estrategia correcta. "Cíñete a los estándares", dice Casey. "No cree su propio cifrado, protocolos o esquemas de codificación cuando existen numerosas opciones probadas disponibles".

La seguridad es lo primero

Una vez visto solo como una "herramienta para un puñado de" usuarios "internos de confianza, Casey describe cuántas API se crearon por primera vez en entornos internos seguros. Posteriormente, el mismo software se externalizó a otros equipos, socios, clientes y usuarios públicos,

Aunque los casos de uso empresarial pueden haber cambiado, el problema es que el desarrollador procesado se ha mantenido estático. Como describe Casey, existe una renuencia a cambiar los esquemas de autenticación, ya que puede romper los sistemas, o los equipos simplemente no están pensando en eso.

Casey enfatiza que debemos “reevaluar nuestras suposiciones de seguridad iniciales” para colocar la seguridad mucho más adelante en el ciclo de vida del desarrollo. Para Casey, esta reevaluación implica:

  • Dándose cuenta de que "la oscuridad nunca es seguridad". Los sombreros negros siempre encontrarán tu API.
  • "Reconozca que sus herramientas y tácticas son diferentes y considere cómo sus marcos, puertas de enlace de API e infraestructura pueden protegerlo de manera inherente".
  • "Tenga en cuenta que incluso con API" ilimitadas ", requerir autenticación y autorización le brinda control y una forma de comunicarse con sus usuarios".
Hemos compilado una lista de más de 20 recursos para definir conceptos de seguridad de API estrictos

Antipatrones comunes

¿Qué suelen hacer mal las empresas cuando se trata de seguridad API? Quizás el error más común de nuestros testigos del panel es no seguir los estándares.

“Hay muchos recursos disponibles: recursos compartidos por OWASP, RFC que describen estándares, RFC que describen las mejores prácticas de seguridad, por nombrar algunos”, dice Tojanawski. "Aún así, creo que muchas empresas no les prestan mucha atención, especialmente los equipos que se centran en ofrecer las API".

Tojanawski y Stewart se apresuran a mencionar la lista de las 10 principales de OWASP, que identifica las 10 vulnerabilidades de aplicaciones más vistas como tales:

  1. Inyección
  2. Autenticación rota
  3. Exposición de datos sensibles
  4. Entidades externas XML (XXE)
  5. Control de acceso roto
  6. Configuraciones incorrectas de seguridad
  7. Secuencias de comandos entre sitios (XSS)
  8. Deserialización insegura
  9. Usar componentes con vulnerabilidades conocidas
  10. Registro y monitoreo insuficientes

Stewart identifica otros anti-patrones que son demasiado comunes en todos los proveedores de API:

  1. Secretos expuestos públicamente. “A menudo son fáciles de encontrar en el código, se almacenan en repositorios de git, se registran como parte de los registros de llamadas de API”, dice Stewart.
  2. Autenticación de usuario sólida sin autorización sólida
  3. No identificar la fuente de la llamada a la API
  4. Falta o floja controles de seguridad
  5. Incompatibilidad o falta de supervisión al usar múltiples herramientas de seguridad
  6. Mal aseguramiento de los canales de comunicación

En términos de las mejores prácticas, Stewart enfatiza "la educación continua y una auditoría de seguridad multifuncional con un fuerte incentivo para hacer la seguridad correctamente, desde el principio". Ideskog recomienda de manera similar educación continua: "lea sobre los estándares de seguridad OAuth y OpenID Connect".

La educación es el primer paso. Compartir el conocimiento de seguridad de API entre equipos es el segundo. Los desarrolladores de API especialmente deben ser conscientes de que tienen nuevas cargas de responsabilidad de seguridad.

“Por supuesto que es útil, especialmente en una organización más grande, tener una persona o un equipo dedicado a los temas de seguridad, pero el conocimiento de la seguridad de API debe difundirse entre sus equipos de desarrolladores”, dice Trojanowski.

Relacionado: 5 vulnerabilidades comunes de API (y cómo solucionarlas)

Evolución futura: seguridad de API en 2020

¿Cómo cambian y evolucionan las vulnerabilidades de seguridad? ¿Cómo cambiará el diseño para hacer frente a estos nuevos obstáculos? Todos los encuestados de nuestro panel están de acuerdo en una cosa; Los ataques se volverán más sofisticados a medida que pase el tiempo.

De cara al futuro, Ideskog prevé una mayor complejidad en los vectores de ataque y tácticas más intrigantes, que aumentarán el tiempo de detección. Esto está obligando a sistemas más resistentes con patrones de diseño impecables.

“Los ataques se están volviendo más sofisticados, así que creo que será cada vez más difícil detectar que un ataque está en curso”, dice Ideskog. "Poner un firewall o una puerta de enlace delante de las API no será suficiente".

Casey está de acuerdo en que los ataques sofisticados requieren nuevos movimientos de diseño y reposicionamiento arquitectónico. La economía de las API ha madurado bastante. Ahora, también debe hacerlo la seguridad a lo largo del proceso de desarrollo.

"Creo que las vulnerabilidades de API solo empeorarán antes de mejorar", dice Casey. “Pasamos 10 años construyendo API asombrosas que impulsan aplicaciones móviles, microservicios e integraciones profundas con socios, pero las construimos en un momento en que las API no estaban dirigidas. Ahora lo son ”.

Las API son ahora objetivos importantes y valiosos. Case señala que los delincuentes pueden usar elementos como hipermedia , documentación pública y entornos sandbox en vivo para determinar un conocimiento profundo de la API. Si bien esas herramientas son cruciales para mejorar la experiencia de los desarrolladores, los proveedores de API deben equilibrar tanto la información externa como el control de acceso con más cuidado que nunca.

Además de una mayor "sofisticación y velocidad de descubrimiento de vulnerabilidades por parte de los atacantes", Stewart predice un cambio potencial de objetivos de alto valor a más "objetivos de menor valor por ataque". Esto podría deberse al aumento de costosos armamentos de seguridad que disuaden a los atacantes de objetivos de alto valor.

Por último, Trojanowski espera más de lo mismo: una gran cantidad de vulnerabilidades y malos actores omnipresentes. Quizás eso se deba a las tendencias arquitectónicas que desplazan a los equipos:

"En un entorno distribuido, donde tiene una API que consta de diferentes microservicios creados por diferentes equipos, me temo que las vulnerabilidades se repetirán", dice Trojanowski.

Lea también: Beneficios del enfoque DevSecOps

Platform Summit y más allá

Es difícil predecir el futuro, pero por lo que nuestros panelistas pueden recopilar, los atacantes continuarán encontrando métodos matizados para penetrar sistemas. Las API de ninguna manera están fuera de la línea de fuego.

Afortunadamente, en la Cumbre de la Plataforma de este año , todos nuestros panelistas compartirán sus ideas sobre cómo defender adecuadamente. Para obtener un adelanto de sus charlas, le preguntamos a cada panelista cómo abordarán sus sesiones las principales amenazas de seguridad de la API:

Asista al taller previo a la conferencia de Jacob Ideskog sobre OAuth y OpenID Connect en la práctica . Hablaré
sobre cómo los datos de identidad críticos pueden extraerse de la API y hacerse más seguros. Cómo identificar estos datos y por qué es importante quién los proporciona.

Asista a la sesión de Keith Casey Cómo construir una estrategia de seguridad de API eficaz
En mi sesión, analizo la mentalidad sobre cómo llegamos aquí, las implicaciones de nuestros errores colectivos y trazo algunos pasos concretos para mejorar la seguridad de API. No podemos prevenir todos los ataques, pero podemos mitigar los daños y las consecuencias para nosotros, nuestras organizaciones y nuestras carreras.

Asista a la sesión de David Stewart Abuso de API: la anatomía de un ataque
Mi presentación describirá cómo se ve y se siente un ataque contra una API. La gente a menudo espera que sea un enfoque de excavadora donde grandes cantidades de tráfico golpean la puerta de entrada. Eso puede suceder, pero es mucho más probable que el ataque sea sutil y de baja frecuencia ... Para vencer al enemigo, primero debes comprenderlo. Este es el tema de mi charla.

Asista a la charla de Michał Trojanowski Cuando el OAuth básico no es suficiente :
Me gustaría que la gente notara los diferentes RFC que se están creando para el marco de OAuth que ayudan a hacerlo aún más seguro y a ampliar las funcionalidades que proporcionó originalmente. Yo mismo he aprendido mucho sobre los problemas de seguridad de OAuth leyendo las diferentes extensiones de RFC OAuth. También me gustaría dar a conocer las funciones de OAuth que usan las personas y si se usan de la mejor manera posible. De esta manera, espero que las API sean menos vulnerables a los vectores de ataque dirigidos a las funciones de OAuth.

Los beneficios de las conferencias no pueden subestimarse. Pero no me lo quites. Según Trojanowski, "estar físicamente en una conferencia también le brinda la capacidad de establecer contactos y obtener conocimientos cruciales directamente de las personas que conoce".

Las entradas para el Platform Summit 2019 se pueden comprar aquí .

Publicar un comentario

0 Comentarios