La mayoría de las políticas comienzan limpias y simples pero se deterioran
Por lo tanto, la verdadera pregunta probablemente no sea tanto sobre la creación de la política, sino más bien sobre el mantenimiento de una política saludable a lo largo del tiempo.
Una política saludable debe ser:
Fácil de adaptar a las necesidades cambiantes del negocio.
Las necesidades empresariales dinámicas requieren cambios continuos en la conectividad.
Realizar estos cambios es responsabilidad de los administradores del firewall.
- ¿Por qué se necesitan huellas digitales y un escaneo retiniano para una tarjeta Aadhar?
- Con la última tecnología de pruebas de seguridad y penetración, ¿cuál es la compañía líder en pruebas de control de calidad?
- ¿Cuál es la diferencia entre cifrado y codificación?
- ¿Qué tan útil es IDS como parte de una arquitectura de seguridad SCADA en un centro de control?
- ¿Puedes forzar bruta una contraseña de administrador de Linux?
Su objetivo como arquitecto de la política de seguridad es facilitar que los administradores encuentren la regla relevante o agreguen nuevas cuando sea necesario para que puedan proporcionar un servicio rápido y preciso al resto de la organización.
Puede lograr esto manteniendo una documentación clara por regla y objeto de red para que sepa cuál es el propósito de cada uno.
Evite usar las mismas reglas y objetos de red para múltiples propósitos. Cree otra regla u objeto si es necesario; de lo contrario, terminará con reglas y objetos que harán todo: serán inseguros e imposibles de mantener.
Puede agrupar reglas por necesidad comercial y documentarlas con un título de sección que admitan algunos proveedores.
Fácil de solucionar problemas de conectividad
Cuando algo sale mal, el firewall es uno de los primeros en culpar. Asegúrese de poder determinar fácilmente si el firewall es la fuente del problema o no y poder probárselo a la otra parte.
Al aceptar un ticket de problema, debe tener información precisa sobre el problema, por ejemplo, la PC de Joe no puede acceder al CRM a través de HTTP. Debe poder detectar rápidamente los firewalls y reglas relevantes que permiten o bloquean este tráfico. Esto se puede hacer mediante análisis de registro o análisis de políticas.
Fácil de revertir cuando sea necesario
Cuando la política causa una interrupción o bloquea la conectividad necesaria, debe poder determinar rápidamente cuándo, por qué y cómo se rompió la política y revertir los cambios relevantes. Mantenga una pista de auditoría fácil de leer de todos los cambios de política con total responsabilidad.
Auto documentado y no depende del conocimiento privado de nadie
La política debe contener toda la información necesaria para administrarla. No permita que nadie introduzca cambios no documentados, ni siquiera temporalmente. Puede desafiar a los administradores del firewall (oa usted mismo) periódicamente preguntando “¿qué hace esta regla?” O “muéstrame las reglas de CRM”.
Fácil de aprender y entender.
Cuando se incorpora un nuevo administrador, debe poder enseñarle la política rápidamente. Debe poder decir “esta es nuestra estructura de políticas” y “este es nuestro proceso para cambiar las políticas”, no “esta regla hace eso y esta regla hace eso …”.
Consistente a través de firewalls, incluso de diferentes proveedores.
El diseño de su política debe ser coherente en todo el entorno. Tenga en cuenta que incluso si tiene una política única hoy, puede tener muchas más en el futuro.
Los firewalls de otros proveedores pueden aparecer debido a requisitos comerciales como fusiones y adquisiciones, reducciones de costos que dictan un cambio de proveedor o tecnologías emergentes (por ejemplo, firewalls de próxima generación).
Bien documentado
Toda regla y objeto importante debe documentarse.
Mantenga secciones de políticas con nombres claros siempre que sea posible.
Para cada cambio de política, coloque el ID de ticket relevante en el campo de comentarios y use una convención estándar.
A algunas personas les gusta mantener una convención de nomenclatura de objetos, por ejemplo: host-10.0.1.30 o net-10.0.1.0.
Justificado por negocio
Cada regla permisiva debe estar allí por una razón, de lo contrario, está comprometiendo la seguridad.
No permita reglas excesivamente permisivas, incluso temporalmente (a menos que tenga un procedimiento bien definido para corregirlas más adelante).
Establezca restricciones de tiempo en los flujos de acceso temporal (diferentes proveedores tienen diferentes mecanismos para esto, como Time Objects en Check Point o Rule Expiration en Cisco).
Periódicamente elimine reglas y objetos obsoletos. Necesitará algún mecanismo para identificarlos, y también una documentación de los dueños de negocios para que pueda contactarlos y verificar que el acceso ya no sea necesario antes de eliminarlo.
Una manifestación de la política de seguridad de alto nivel.
Por último, pero no menos importante, su “política” de firewall no es la política de seguridad, es solo una manifestación de una parte de ella (otras partes pueden estar relacionadas con la seguridad del punto final,
seguridad física etc.). Asegúrese de que sus políticas de firewall sigan una política de seguridad bien definida, como, por ejemplo, una política de lista blanca basada en zonas. Esté preparado para demostrar el cumplimiento en todo momento.
Además, recomiendo mantener un documento escrito de Pautas y Procedimientos que explique la estructura de la política, los estándares de documentación, las convenciones y procedimientos de nomenclatura.
para políticas de cambios.
Estos son algunos de los principios que aprendí a lo largo de los años.
como CTO de Tufin Technologies que construye soluciones de gestión de operaciones de firewall.
Reuven
