¿se lograría la defensa en profundidad a pesar de que los tres controles de seguridad tienen al menos una superficie de ataque común?
No, puede verlo muy bien con el software antivirus, por ejemplo: parece una defensa en profundidad al poner los sistemas de protección en varias capas (firewall de red, complemento de navegador, monitoreo de procesos, análisis de archivos, etc.), Sin embargo, un atacante solo tiene que derrotar una sola cosa, el software antivirus en sí, para hacer que todo el sistema de protección colapse.
Como se observa correctamente, el kernel de Linux no implementa sus verificaciones de autorización de manera monolítica, en su lugar, utiliza una forma modular en donde los módulos de seguridad (llamados LSM, consulte here y allí para más información pueden provenir de diferentes proveedores y completarse entre sí (por lo tanto, el sistema DAC del kernel se puede completar con capacidades y un sistema MAC que viene como módulos).
Esto ofrece varias ventajas, tanto en términos de libertad, que es el núcleo de la filosofía y seguridad de GNU / Linux:
-
Más libertad porque un módulo de seguridad no está estrechamente integrado al kernel, esto permite que un usuario (o más probablemente un mantenedor de distribución) seleccione el LSM que mejor se adapte a sus necesidades (lo que, al final, brinda más seguridad al final -usuario). Por ejemplo, algunos prefieren el modelo de seguridad de AppArmor, otros prefieren el modelo de SELinux, etc.: la elección no es impuesta por el equipo de desarrollo del kernel de Linux. Esto se establece explícitamente en la página de Wikipedia previamente vinculada :
Linus Torvalds rechazó a SELinux en ese momento, porque observó que hay muchos proyectos de seguridad diferentes en desarrollo, y como todos difieren, la comunidad de seguridad aún no ha logrado un consenso sobre el modelo de seguridad definitivo. En su lugar, Linus cargó a la comunidad de seguridad para "convertirlo en un módulo".
-
Seguridad por dos razones, que ambas terminan siendo beneficiosas del aislamiento del código:
-
Una corrección hecha en una característica de seguridad no debería causar ningún problema en otra. Una actualización en SELinux, por ejemplo, no debería afectar a los sistemas de autorización de DAC o capacidades, ya que cada uno utiliza un código y estructuras de datos distintos. Este no sería el caso si todo esto se implementara como una única pieza de software monolítica.
-
Una vulnerabilidad que afecta a una característica de seguridad no debe poner en peligro las otras. En caso de que la vulnerabilidad afecte a SELinux, por ejemplo, dicha vulnerabilidad no anulará los sistemas de seguridad de DAC y capacidades como en el ejemplo de antivirus que se muestra arriba, donde una vulnerabilidad en el software antivirus probablemente cancelará todos sus beneficios de seguridad.
La defensa en profundidad no debe concebirse como simplemente con varias capas de controles de seguridad, en lugar de eso, debe considerarse simplemente como tener varias capas de sistemas de seguridad . De hecho, es el aislamiento entre cada sistema lo que le brindará una buena garantía de que un atacante tardará en vencer su infraestructura de seguridad.