Las aplicaciones están bajo asedio. Los ataques se producen con una frecuencia alarmante —cada 39 segundos, según una investigación realizada por la Universidad de Maryland— y tienen una probabilidad de éxito inquietantemente alta.
Los desarrolladores, sobre quienes recae cada vez más la responsabilidad de proteger estas aplicaciones, son muy conscientes de la amenaza. Una encuesta realizada a finales de 2017 entre desarrolladores de node.js por NodeSource y Sqreen reveló que «más de un tercio de los encuestados (el 34 %) cree que existe una alta probabilidad de que su organización sea objeto de un ataque a gran escala en los próximos seis meses». Teniendo en cuenta nuestros propios hallazgos de que, en el 86 % de los ataques, el vector de ataque inicial es la propia aplicación o las identidades, esta percepción está más que justificada.
Por tanto, puede resultar inquietante descubrir que «el 35 % de los encuestados no sabía con certeza cómo identificar un ataque mientras se estaba produciendo». Esperan que ocurra uno, pero no saben con certeza cómo reconocerlo cuando sucede. Si no se sabe cómo identificar un ataque en curso, resulta sumamente difícil detenerlo.
Esto hace aún más preocupante que el 23 % de los desarrolladores de Node.js (el 23 por ciento) no utilice ningún tipo de protección en tiempo real contra los ataques.
La buena noticia es que, según nuestra propia investigación para el informe State of Application Delivery 2018, la mayoría de las organizaciones utilizan algún tipo de protección en tiempo real contra los ataques. Cuatro de cada cinco utilizan dos o más tecnologías, entre ellas un firewall de aplicaciones web (57 %), autoprotección de aplicaciones en tiempo de ejecución (11 %) y análisis del comportamiento de los usuarios (26 %).
La característica que comparten todas estas tecnologías es precisamente aquello de lo que suelen carecer los desarrolladores: visibilidad. La visibilidad es necesaria porque, para detectar (y, con suerte, identificar) un ataque, hay que ser capaz de reconocer comportamientos anómalos.
Las aplicaciones y sus servicios presentan patrones de uso bastante predecibles. Por ejemplo, las aplicaciones de inicio de sesión único (SSO) suelen registrar un uso intensivo los lunes por la mañana y un uso reducido los viernes por la tarde. Las aplicaciones financieras suelen utilizarse mucho justo antes de determinados eventos financieros, como los días de pago, el cierre de los periodos fiscales y el cierre del ejercicio fiscal.
Incluso las aplicaciones orientadas al consumidor presentan patrones de uso predecibles que pueden ayudar a detectar comportamientos inusuales (y potencialmente peligrosos). Por ejemplo, en abril de 2017 Malauzai Software publicó uno de sus informes mensuales sobre «pequeños datos» basado en datos de uso recopilados de más de «435 bancos y cooperativas de crédito, que abarcan 13,2 millones de inicios de sesión de 730.000 usuarios activos de banca por Internet y móvil». En él descubrimos que «El 100 % de los usuarios finales consulta sus saldos y revisa el historial de transacciones recientes. Esto se debe a que los saldos y el historial reciente aparecen en la página de inicio para que todos puedan verlos. Y por eso acceden. El 77 % de las veces. El 77 % de las veces, lo único que hace un usuario es consultar sus saldos y su historial. Solo el 23 % del total de las interacciones en la banca digital va más allá de los saldos y el historial para realizar alguna otra tarea».
Por tanto, se podría deducir que un interés repentino por otros tipos de transacciones podría ser indicativo de un ataque.
Por desgracia, estas estadísticas no siempre están disponibles fácilmente para todas las aplicaciones. Por eso es importante contar con visibilidad (supervisión), ya que permite establecer una referencia de base con respecto a la cual las anomalías resultan evidentes. Por supuesto, no todas las anomalías son indicativas de un ataque. Un aumento repentino a mitad de semana en el uso del servicio de SSO podría deberse a que se acerca la fecha límite para cambiar las contraseñas corporativas, o a que el lunes y el martes fueron festivos y no había nadie en la oficina. Aun así, disponer de una referencia de base supone una ventaja a la hora de identificar comportamientos que puedan indicar que hay un ataque en curso.
Asegúrate de investigar estos tres patrones de uso anómalos por si se tratara, en efecto, de un ataque. Porque, con bastante frecuencia, lo son.
1. Aumento drástico de las conexiones. Puede que acabes de hacerte viral, pero lo más probable es que esté ocurriendo algo más. Cuando detectes un aumento significativo en la tasa de conexiones, conviene comprobar de inmediato si se corresponde con un incremento del tráfico de red. De no ser así, debería activarse tu sentido arácnido, ya que podría tratarse de un ataque. Las inundaciones GET son los ataques DDoS basados en HTTP más fáciles de llevar a cabo, pues consisten simplemente en bombardear una aplicación con una cantidad ingente de solicitudes HTTP GET. A menudo ni siquiera intentan acceder a URL reales, ya que el único objetivo es consumir tantas conexiones como sea posible y provocar una situación de sobrecarga.
Si el aumento se dirige específicamente a URL o servicios que permiten iniciar sesión, podría estar siendo víctima de un ataque de fuerza bruta para obtener acceso.
Busca errores del servidor, una degradación progresiva del rendimiento y el agotamiento de recursos como indicios de un ataque en curso.
2. Tamaño de la respuesta saliente. Una respuesta saliente repentinamente grande puede indicar un ataque de exfiltración exitoso en el que el atacante ha obtenido acceso a datos a los que no debería tener acceso. Esta es una de las principales señales de alerta de un ataque de SQLi exitoso, ya que los atacantes suelen utilizar comodines para obtener acceso no autorizado a los datos. Cabría pensar que SQLi es un vector de ataque tan conocido que a estas alturas ya lo tendríamos controlado. Sin embargo, según diversos informes del sector, SQLi se encuentra sistemáticamente entre los ataques con más éxito cada año.
Básicamente, el ataque está diseñado para eludir las restricciones de acceso a los datos. Así, en lugar de recibir un único registro (o incluso solo unos pocos), el atacante podría recibir miles. Por tanto, un ataque exitoso se detectará porque la cantidad de datos devueltos será considerablemente mayor de lo habitual.
Cualquier diferencia significativa en el tamaño de la respuesta debería ser motivo suficiente para iniciar una investigación inmediata.
3. Bloqueos y fallos. Aunque estos pueden deberse a defectos o a datos de entrada «incorrectos» introducidos accidentalmente, también pueden ser indicio de intentos de desbordar los búferes de bibliotecas de terceros o plataformas de servidores web (o de su aplicación) con la esperanza de aprovechar una vulnerabilidad nueva (o antigua). Aunque hoy en día resulta práctico que los sistemas puedan simplemente «reiniciarse» solos, no conviene ignorar el motivo por el que fue necesario reiniciarlos.
Aunque pueda resultar tentador ignorar algún fallo ocasional, no lo haga.
No ignores los bloqueos ni los fallos y plantéate utilizar arquitecturas que te permitan aislar los sistemas defectuosos hasta que puedas revisarlos.
Obviamente, esta no es una lista exhaustiva, pero es un buen punto de partida para poder identificar cuándo una aplicación podría estar sufriendo un ataque y detenerlo en seco.
¡Mantente a salvo!
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.