En el panorama cibernético actual de malware y adversarios avanzados, centrarse solo en mecanismos o tecnologías específicos es una receta para el fracaso . Además, las organizaciones generan una falsa sensación de seguridad cuando el equipo de TI equipara la “seguridad” con las compras de los últimos sistemas de detección de intrusos o firewalls, pero carece de seguridad real al no diseñarla en sus sistemas, redes y personas.
La seguridad perimetral es una reliquia del pasado. Es necesario para mantener un nivel muy básico de seguridad (analogía: frontera e inmigración), pero hace poco para abordar muchos de los ataques avanzados (analogía: fuerzas especiales) que ahora se estudian o compran fácilmente en el mercado negro (por ejemplo, exploits de día cero).
Dicho esto, el diseño de seguridad en sus redes y sistemas debe seguir dos principios básicos:
1) Separación de deberes : tal como se aplica en los negocios y la contabilidad para minimizar el riesgo, los sistemas y dispositivos de red deben tener diferentes roles para evitar crear un solo punto de falla. Este principio fomenta la modularidad para permitir una recuperación ágil en el caso de que uno o más componentes se pierdan o se vean comprometidos. Especialmente útil en la gestión de recuperación ante desastres. Una aplicación práctica es la segmentación de red.
Wikipedia: separación de funciones
- Cómo resolver el error 'Host desconocido' en Burp Suite
- ¿Puedo crear mi propio administrador de contraseñas?
- ¿Qué habilidades debo desarrollar durante el programa de maestría para convertirme en especialista en redes y seguridad informática?
- Cómo desarrollar sitios web seguros más rápido
- ¿Es posible que el malware mueva su ubicación para evitar un escaneo AV?
2) Principio de menor privilegio : a los usuarios y aplicaciones solo se les debe permitir acceder a los sistemas y redes mínimos necesarios que necesitan para funcionar. Por lo tanto, si un adversario comprometió con éxito a un usuario / aplicación, ella solo tendría acceso a los servicios utilizados por ese usuario / aplicación específica. Un ejemplo simple es cómo un empleado de entrada de datos no debe tener privilegios de administrador para el servidor DBMS a pesar de que está alimentando la base de datos con entrada.
Wikipedia: Principio de menor privilegio
Hay muchos problemas de seguridad de los que hablar, por ejemplo, programación segura, administración de parches, pruebas de penetración, etc. Pero, en términos generales, estos dos principios pueden ayudarlo a comenzar a diseñar su red con la mentalidad de seguridad adecuada.
No promoveré la implementación de estos principios por una tecnología / marca específica porque:
a) No trabajo ni estoy certificado para dar recomendaciones de un proveedor en particular
b) no es prudente diseñar la seguridad en una red / sistema [soley] basado en productos específicos ofrecidos en el mercado
