Header Ads Widget

Ticker

6/recent/ticker-posts

API de la guerra mundial: ciberataques a escala internacional

 

Ciberataques-API-de-la-guerra-mundial-a-escala-internacional

El mundo esta cambiando. Lo que alguna vez se libró en los campos de batalla con armas físicas está cambiando rápidamente en línea , con grupos de individuos e incluso naciones enteras que utilizan Internet para perturbar a sus enemigos.

Al igual que con cualquier conflicto, habrá víctimas civiles, ya sea que se trate de infraestructura civil o de usuarios armados como drones de denegación de servicio distribuida, las consecuencias de los próximos conflictos virtuales serán malas.

Afortunadamente, los desarrolladores pueden hacer mucho para prevenir el impacto de dicha infiltración. Como hemos cubierto antes, los desarrolladores de API no solo tienen las herramientas para implementar la seguridad , sino que también tienen la responsabilidad ética y, a menudo, legal de garantizar que sus servicios se utilicen para el propósito previsto.

En este primero de dos artículos, examinaremos la amenaza de los ciberataques a escala internacional. En el seguimiento, veremos quién está lanzando exactamente estos ataques, junto con algunos métodos generales que los desarrolladores de API pueden implementar para negar el daño causado si se rompen las defensas.

Ejemplos del mundo real

En noviembre de 2014, el gobierno de Estados Unidos nombró a Corea del Norte como actor estatal en el hackeo de Sony Pictures . El ataque, que filtró información personal sobre empleados, dependientes de empleados y ganancias y cifras corporativas, fue citado por C-SPAN como el resultado de la liberación de “47,000 números únicos de Seguridad Social de la red informática de SPE” . El ataque le costó a Sony aproximadamente $ 35 millones de dólares .

En febrero de 2012, el grupo hacktivista Anonymous filtró aproximadamente 2.434.899 correos electrónicos de 680 dominios sirios, incluido el del presidente sirio Bashar Assad. El ataque dañó la posición internacional de Assad y cuestionó su manejo de la guerra civil siria en curso.

Amenazas como estas llevaron al presidente estadounidense Obama a emitir una Orden Ejecutiva el 1 de abril de 2015 contra los ataques cibernéticos. ¿Qué tienen todos estos eventos en común? Representan una tendencia creciente: la guerra cibernética representa el estado futuro de los conflictos internacionales . Si bien los días del terrorismo a pequeña escala y las escaramuzas fronterizas están lejos de terminar, cada vez más conflictos se están moviendo hacia el espacio digital.

Para mayor seguridad API Insights Visita nuestro Centro de Conocimiento de Seguridad

Por qué los atacantes se dirigen a las API

Desafortunadamente, las API son un producto candente para explotar. Si bien discutimos la naturaleza de los atacantes y sus objetivos en el complemento de este artículo , ayuda a nuestra discusión actual a comprender qué hace que las API sean tan atractivas para los piratas informáticos:

  • Las API son bufés virtuales para piratas informáticos. Miles y miles de usuarios, todos compartiendo información privada, utilizan API en su comercio electrónico diario , comunicaciones y entretenimiento. Esto hace que una API sea una gran cantidad de datos que los atacantes pueden utilizar para cometer fraude, robo e incluso chantaje.
  • Las API están necesariamente orientadas hacia adelante. Debido a que las API públicas están diseñadas para ser consumidas por desarrolladores externos, no tienen más remedio que estar orientadas hacia el futuro. Por tanto, quedan expuestos a la fuerza. A diferencia de los servidores privados, que deben ser pirateados físicamente o acceder a ellos a través de servidores no privados, los servidores y servicios públicos están más expuestos en todo momento.
  • Los desarrolladores de API a menudo utilizan recursos comunes (por ejemplo, dependencias, API de terceros y código fuente abierto). Si bien esto es bueno para el desarrollo, significa que todos los desarrolladores que usan un recurso específico pueden estar expuestos al error de ese recurso, ampliando la red de impacto. Este fue el caso del infame error Heartbleed .

Debido a estos hechos básicos, los desarrolladores de API deberían esperar más y más ataques por parte de actores estatales y no estatales a medida que los delitos de orientación política pasan de lo físico a lo digital. Esto también significa que los desarrolladores de API también deben esperar que, incluso si no están directamente relacionados con la causa, pueden ser "armados" o atrapados en el fuego cruzado .

Las tres defensas

Sin embargo, la desafortunada realidad de este cambio de la lucha física a la lucha digital es que la infraestructura civil se está convirtiendo en un objetivo cada vez mayor. Si bien la infraestructura empresarial gubernamental y corporativa son los objetivos principales, las amenazas a los servicios web están creciendo, ya que a menudo están menos protegidos y, por lo tanto, son más atractivos para los piratas informáticos.

En consecuencia, los desarrolladores de API tienen la responsabilidad ética, y en ocasiones legal, de prevenir el uso indebido y el abuso de sus API y servicios. Establecer y mantener la CIA ( confidencialidad, integridad y disponibilidad ) debería ser la actividad principal en la que se involucre un desarrollador de API. Afortunadamente, los desarrolladores pueden defenderse de una gran cantidad de estos ataques y asegurar su CIA al adherirse a un enfoque fundamental de tres niveles.

1: Prevención de daños

En primer lugar, los desarrolladores de API deben hacer todo lo posible para evitar que se produzcan daños. Esto es más fácil decirlo que hacerlo, por supuesto, pero hay algunos enfoques importantes que los desarrolladores pueden tomar para detener a los atacantes en seco.

Los piratas informáticos funcionan como una enfermedad. Cuando una enfermedad invade un cuerpo, a menudo utiliza insectos como garrapatas y mosquitos como ruta hacia el huésped. Por lo general, estas rutas son de oportunidad y azar en lugar de algo planeado específicamente (porque, seamos sinceros, la malaria no está sentada en una gran mesa verde planeando nuestra destrucción al estilo del Dr. Strangelove). Estos modos de transmisión se denominan vectores .

Los piratas informáticos son muy parecidos y, por lo general, utilizan vulnerabilidades y solicitudes sin parches como "vectores" de un sistema. Los desarrolladores de API necesitan parchear estos vectores y asegurarse de que los atacantes no puedan usarlos como rutas directas a los sistemas internos.

Encuentra señales usando el monitoreo de frecuencia

La limitación de la tasa geográfica y de comportamiento es quizás el enfoque más poderoso para prevenir daños. Los sistemas de limitación de frecuencia funcionan de diversas formas, pero la más común es un enfoque conductual. Al establecer una línea base de comportamiento razonable , por ejemplo, el número promedio de llamadas a un recurso determinado desde un área geográfica determinada durante un período de tiempo determinado, estos sistemas pueden analizar el tráfico que no se ajusta a la línea base y rechazar o limitar estas conexiones.

Al permitir que su sistema ahogue el tráfico malicioso o cuestionable, puede restringir de manera inteligente el acceso de los atacantes mientras mantiene la experiencia de la base de usuarios dinámica y efectiva.

Disminuir el número de rutas

Otro método para prevenir daños es asegurar la “fortaleza” API . Esencialmente, cuantas menos puertas o vías tenga, más seguro será un sistema. Lo que esto significa funcionalmente para los desarrolladores de API es que los puntos de entrada a la API deben estar restringidos y monitoreados. Reduzca la cantidad de llamadas y servicios externos que admiten esas llamadas. Cuando tal reducción no sea posible, intente combinar llamadas con funciones similares, o incluso coloque estas llamadas detrás de una puerta de enlace o llamada común con funcionalidad variable.

Containerización para aislamiento

Uno de los mejores métodos que pueden utilizar los desarrolladores de API es algo llamado "contenedorización". Los servicios como Docker combinan servicios, API y recursos en un solo "contenedor" , aislando la funcionalidad en los nodos. Al hacer esto, múltiples vectores se combinan en un vector singular, y el daño que se puede hacer al servicio se limita por completo a ese contenedor específico, evitando daños adicionales a los servicios exteriores.

Seguridad integral de la plataforma

Todas estas soluciones son excelentes para aplicaciones específicas, pero ¿qué pasa con la seguridad holística general? Ingrese a la gestión de acceso y al control de identidad . Estas dos soluciones utilizan credenciales emitidas desde un servidor central para identificar y otorgar acceso a un servicio en particular. Estas credenciales pueden ser de naturaleza limitada, con un alcance y un período de tiempo específicos aplicados para limitar el uso.

En Autenticación , un usuario proporciona sus credenciales para identificarse. En parte, la autorización controla los sistemas a los que el usuario puede acceder y cómo utilizan estos sistemas. La implementación de un sistema de control efectivo a este nivel puede limitar las operaciones no válidas entre los usuarios y ayudar a rastrear el comportamiento del usuario a lo largo del tiempo.

Luego vienen los conceptos para una gestión de identidad más amplia. Con Federation , se utiliza una única cuenta o credencial de usuario en varios servicios. Si bien esto es excelente para la experiencia del usuario, necesariamente disminuye la seguridad al proporcionar una clave relativamente "única para todos" para el usuario. La delegación , por otro lado, es mucho más limitante; de ​​hecho, permite a un usuario funcionar dentro de los derechos de otro perfil de usuario, limitando así sus acciones incluso por debajo de las de un usuario completo.

La implementación de la solución correcta de administración de acceso y control de identidad dependerá en gran medida de la potencia que desee que tengan sus usuarios, pero lograr el punto óptimo significa una seguridad drásticamente aumentada.

Lea Las 4 defensas de API Stronghold para obtener más información sobre autenticación, autorización, delegación y federación

2: daño anticipado

Los desarrolladores deben prevenir el daño a sus servicios pensando como un atacante. ¿Por qué, exactamente, una API es un objetivo para los piratas informáticos? ¿Qué hace que los recursos de una API sean atractivos? ¿Qué se puede hacer para negar esto?

Un problema importante en el desarrollo de API es la tendencia de codificar "lo suficiente". Cuando los desarrolladores codifican solo para la funcionalidad, en lugar de para la seguridad a largo plazo y la cohesión del ecosistema, crean una situación en la que tienen un servicio potente y extensible que no considera la plataforma en la que se basa.

Esto crea muchos vectores adicionales. Por ejemplo, sin comprender las debilidades y fortalezas de la plataforma subyacente, cosas como la inyección de SQL se convierten en una realidad abrumadora. La inyección de código en un servicio niega casi todas las características de seguridad que puede adoptar una API, ya que las partes internas quedan expuestas de manera completa e irreparable.

Afortunadamente, gran parte del proceso de apropiación de datos se refiere a la cultura y los procesos del desarrollador de API y, por lo tanto, se puede implementar fácilmente:

  • Adoptar una cultura interna de seguridad adecuada puede prevenir muchos ataques internos utilizando contraseñas de phishing obtenidas a través de la ingeniería social.
  • La segregación del control de versiones y el desarrollo puede ayudar a detener la amenaza constante de las vulnerabilidades del día cero y los ataques de control de versiones .
  • Sepa dónde se encuentran sus vulnerabilidades y asuma el papel de un pirata informático de sombrero blanco para probar estos riesgos.
  • Incluso un enfoque adecuado de la documentación de GitHub segregado entre la funcionalidad del desarrollador y del usuario puede ser de gran ayuda para ofuscar y, por lo tanto, proteger una gran parte de su funcionalidad.

Asegurando-la-fortaleza-API-blog-post-CTA-01

3: Recuperarse del daño

Desafortunadamente, no todos los daños se pueden prevenir o anticipar. Se producirán daños y los desarrolladores deben tener un plan para hacer frente a esto. Gran parte de esta recuperación se puede realizar en el nivel básico. La implementación de clústeres de servidores redundantes y copias de seguridad fuera del sitio puede crear un punto de restauración de la base de datos, lo que garantiza que los datos perdidos sean de un período de tiempo relativamente pequeño.

La creación e implementación de un plan de recuperación ante desastres de TI que tenga en cuenta la piratería y el espionaje puede crear una vía por la cual una empresa puede recuperarse después de daños drásticos. De manera indirecta, adherirse a las preocupaciones legales y éticas de los proveedores de TI también puede ayudar, ya que mantener registros adecuados, proteger estos registros y mantener estos registros hace que la pérdida total no sea un problema.

Últimos pensamientos

La amenaza de la guerra cibernética internacional no es una discusión hipotética, está ocurriendo mientras hablamos. Las entidades estatales y no estatales están utilizando el espacio web para distribuir el terrorismo y los actos de guerra directos, y esto solo aumentará. Los desarrolladores de API tienen la responsabilidad de comprender y combatir la piratería que se deriva de estos conflictos y de proteger a sus usuarios de la exposición.

Si los proveedores de API no pueden armar sus plataformas, la industria morirá. Los desarrolladores integran las API no por necesidad, sino por confianza. Si esa confianza se rompe, entonces la API de la Guerra Mundial la ganarán, pero no los desarrolladores de API, sino el enemigo.

Publicar un comentario

0 Comentarios