¿Por qué la protección insuficiente contra ataques es una amenaza / riesgo definitivo para una organización?

Navega tus respuestas
3

Recientemente, OWASP introdujo dos nuevas series de categorías a partir de 2017, en abril: a OWASP Top 10 :

  1. Protección de ataque insuficiente
  2. API no protegidas

Entiendo, las API no protegidas tienen un riesgo inmediato que implica probar una gran superficie de ataque junto con la posibilidad de fugas de datos, sin embargo, no entiendo cómo Insufficient Attack Protection es una amenaza o un riesgo. para una categoría?

Mejorando mi enfoque, resumiría las citas de scamdemy :

  

La protección insuficiente contra ataques se refiere a la incapacidad de detectar, prevenir y responder a varios tipos de ataques contra la aplicación en su conjunto. Esto, debido a la gran cantidad de componentes de terceros no auditados que pueden contener vulnerabilidades críticas, requiere el uso de herramientas de seguridad genéricas como los sistemas de detección de intrusos (IDS) y los firewalls de aplicaciones web (WAF) que pueden identificar un ataque en curso como Inyección SQL. Se enfoca en las consecuencias en lugar de en las causas de las debilidades.

¿Esto implica que la configuración de WAF en conexión directa tenga una gran área de superficie de ataque sin la presencia de Firewalls? Si la ausencia de un componente es una necesidad de categorización inmediata en OWASP Top 10. ¿No está seguro, cómo otros no se ven afectados por el mismo?

por ejemplo Al no tener WAF, ciertos niveles de Inyección (s) serán evidentes dado que hay una falla en el código de la aplicación.

Supongo que este es un movimiento para que el equipo de auditoría de seguridad comercialice sus productos de Firewall manteniendo el Top 10 de OWASP como referencia. ¿O era realmente necesario técnicamente?

    
pregunta Shritam Bhowmick 12.04.2017 - 07:43
fuente

2 respuestas

4

"Protección de ataque insuficiente" es una elección horrible de palabras, pero no tengo una sugerencia sobre cómo mejorarla.

He supervisado las aplicaciones en las que faltaban habilidades de detección realmente básicas y es frustrante tratar de comunicar la urgencia de algún tipo de respuesta al equipo de aplicaciones.

Imagina una aplicación con:

  • no hay protección contra ataques de contraseña de fuerza bruta,
  • sin registro de intentos de inicio de sesión,
  • no se registra el inicio o finalización de la sesión,
  • no se registran intentos de manipular sesiones caducadas, etc.

Me encontré escribiendo firmas Snort frágiles e incómodas para extraer datos de registro básicos y ajustar los firewalls de las aplicaciones para intentar compensar los comportamientos faltantes, mientras que los equipos de aplicaciones simplemente dijeron "meh, es el problema de Infosec".

Las firmas IPS no pueden saber "¿es este un usuario válido?" o "esta sesión esta activa?" o "¿cuántos datos ha utilizado esta persona hoy?", pero la lógica de la aplicación puede tener acceso a esta información, o tal vez el hecho de tener las sesiones registradas significaría que el SIEM podría realizar la lógica.

Con respecto al artículo de scamdemy, creo que está equivocado. Esto no tiene nada que ver con componentes de terceros. Muchos de los artículos de seguridad que se publican en el A7 2017 propuesto parecen ser reacciones instintivas a una respuesta al nuevo Top-10 de OWASP, supongo que recibe atención, pero no creo que los autores hayan respondido con cuidado. pensamiento.

Los enlaces externos dentro de la hoja de trucos A7 son mucho más descriptivos:

En mi humilde opinión, A7 necesita algunos ajustes, creo que las referencias de "parches" deberían eliminarse. Infosec puede hacer parches virtuales o los procesos de desarrollo pueden parchearlos, pero las referencias aquí en detrimento de lo que creo que es su mensaje principal.

    
respondido por el mgjk 12.04.2017 - 10:46
fuente
0

Según la breve descripción de OWASP ( documento completo aquí ):

  

La mayoría de las aplicaciones y API carecen de la capacidad básica para detectar, prevenir y responder a ataques tanto manuales como automáticos. La protección contra ataques va mucho más allá de la validación de entrada básica e implica la detección, el registro, la respuesta e incluso el bloqueo automático de los intentos de explotación. Los propietarios de aplicaciones también deben poder implementar parches rápidamente para protegerse contra ataques.

Tu pregunta:

  

Entiendo, las API no protegidas tienen un riesgo inmediato que implica probar una gran superficie de ataque junto con la posibilidad de fugas de datos, sin embargo, no entiendo cómo la protección insuficiente contra ataques es una amenaza o un riesgo para una categoría.

Además de mantener todo actualizado y de haber desarrollado una API bastante segura, una organización o empresa con una red enorme (y mabye sus propios servidores de alojamiento web), necesita tener más de los típicos. Los firewalls y los IDS necesitan que las personas los vigilen y sepan cómo reaccionar en caso de una intrusión o un intento de explotación. Eso incluye políticas de respuesta activa (bloqueo de ip's, denegación de servicios en clientes específicos (maliciosos, etc.). Ahora, si los atacantes logran superar con éxito los firewalls, IDS y causar daños, debe haber procedimientos para especificar las acciones necesarias para la recuperación del sistema / red y la aplicación de parches adicionales. La falta de personal para hacer esas cosas y la falta de políticas específicas (es decir, iso 27001), la protección insuficiente contra ataques es AMBAS amenazas y un riesgo. Solo tome un momento y piense que muchas empresas (pequeñas / grandes / no importan) ni siquiera mantienen copias de seguridad de sus bases de datos.

    
respondido por el Chris Tsiakoulas 12.04.2017 - 11:17
fuente

Lea otras preguntas en las etiquetas

Uso de cifrados antiguos en la seguridad del correo electrónico ¿Se puede encontrar un beneficio de seguridad al usar una máquina virtual si el host está infectado?