Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Al establecer la materia de arquitectura de seguridad, en este artículo se proporcionan instrucciones sobre cómo aplicar 10 leyes inmutables de riesgo de seguridad como sugerencias prácticas a medida que se establece y moderniza la materia de arquitectura de seguridad.
Revisar las leyes inmutables de seguridad
La arquitectura existe para identificar requisitos desafiantes y traducirlos en instrucciones accionables para reducir el riesgo de seguridad, limitar los daños y mantener los sistemas disponibles a lo largo del tiempo. En la base de esta obra se encuentran las leyes inmutables de seguridad.
Estas leyes describen verdades incómodos sobre la seguridad que le ayudan a planear un control eficaz, evitar conceptos erróneos comunes que minan la arquitectura de seguridad y crean riesgos organizativos.
| Ley inmutable | Impacto en la arquitectura |
|---|---|
| 1. Si un ciberdelincuente puede convencerle de que ejecute su programa, no es su ordenador | La ejecución de código no autorizado provoca la pérdida de control. La prevención por sí sola no es suficiente. |
| 2. Si un actor malicioso puede modificar el sistema operativo, no es tu equipo | El riesgo del plano de control es un riesgo sistémico. Esto se aplica si el plano de control es un sistema operativo local, un sistema de administración de identidades, una herramienta de seguridad o cualquier otra cosa con acceso de nivel de sistema o raíz. |
| 3. Si un ciberdelincuente tiene acceso físico sin restricciones, no es su ordenador | Se debe asumir la exposición física, no tratada como una excepción. |
| 4. Si un ciberdelincuente puede ejecutar contenido activo en su sitio web, no es su sitio web | Los límites de ejecución definen límites de confianza. |
| 5. Las contraseñas débiles socavan una seguridad sólida | Los errores de identidad derrotan los controles en capas. |
| 6. Un equipo solo es tan seguro como su administrador | El acceso con privilegios es una prioridad de seguridad críticamente importante. |
| 7. Los datos cifrados solo son tan seguros como su clave de descifrado | La criptografía sin gobernanza es frágil. |
| 8. Un escáner antimalware obsoleto es marginalmente mejor que ninguno | Las defensas estáticas se desintegran. |
| 9. El anonimato absoluto no es factible | La visibilidad es inevitable. |
| 10. La tecnología no es una panacea | Se deben asumir los errores de personas y procesos. |
Aplicar las diez leyes de riesgo de ciberseguridad
Incluso después de comprender cómo se pierde el control de seguridad y el impacto en la arquitectura de seguridad, esta no es suficiente información para diseñar un sistema. Los arquitectos de seguridad también deben comprender lo siguiente:
- ¿Para qué optimizamos? - ¿Dónde concentramos los esfuerzos? - ¿Qué inconvenientes son aceptables?
Para averiguar estas preguntas, podemos aplicar 10 leyes comunes de riesgo de ciberseguridad. Cada conjunto de leyes se ocupa de diferentes aspectos de la ciberseguridad.
| Ley | Implicación de la arquitectura | Guía de modernización |
|---|---|---|
| 1. El éxito de la seguridad está arruinando el ROI del atacante | Diseñe arquitecturas que aumenten el costo del atacante y reduzcan el pago, especialmente para los recursos de alto valor. | - Concentrar controles en torno a la identidad, el acceso con privilegios y los datos confidenciales. - Reduzca las zonas de confianza planas; segmente los sistemas para que una intrusión no se propague. - Priorizar las protecciones que interrumpen las cadenas comunes de atacantes, no casos especiales. |
| 2. No mantenerse al día es quedarse atrás | Se produce un error en las arquitecturas estáticas. La arquitectura debe asumir la evolución continua. | - La arquitectura de seguridad nunca se termina. Debe ser operativamente sostenible y mejorar continuamente. - Diseño para la actualización continua (aplicación de parches, configuración, políticas). - Prefiere los servicios nativos y administrados en la nube que evolucionan más rápido que los sistemas locales o a medida. - Asegúrese de que la visibilidad y el inventario sean requisitos arquitectónicos, no ocurrencias de última hora. |
| 3. La seguridad es un habilitador empresarial (la productividad siempre gana) | Si la arquitectura crea fricción, se omite. | - Una buena arquitectura de seguridad permite la productividad de forma predeterminada. - Favorezca el acceso basado en la identidad en lugar de la complejidad de red. - Integrar controles de seguridad en flujos de trabajo estándar de usuario y desarrollador. - Hacer que las rutas de acceso seguras sean las más fáciles. |
| 4. A los atacantes no les importa | Los atacantes usan cualquier ruta de acceso disponible en el entorno. La arquitectura debe eliminar las rutas más baratas, no defender solo las obvias. | - La arquitectura debe reflejar el comportamiento real de los atacantes, no las creencias idealizadas en los controles individuales. - Asuma que ha sido comprometido por phishing, errores de configuración o protocolos heredados. - Eliminar los puntos únicos de fallo catastrófico en la arquitectura. - Proteja frente al ciclo de vida completo del ataque (movimiento lateral, cumplimiento de objetivos), no solo frente al acceso inicial. |
| 5. La priorización despiadada es una habilidad de supervivencia | No puedes proteger todo. | - La arquitectura consiste en elegir qué no hacer. - Identificar activos de joyas de corona y diseñar "defensa en profundidad" allí. - Acepte una garantía inferior en la que el impacto empresarial sea menor. - Usar escenarios empresariales para guiar la inversión arquitectónica. |
| 6. Ciberseguridad es un deporte de equipo | La arquitectura debe integrar el trabajo entre disciplinas y equipos. | - Arquitectos diseñan coordinación, no solo controles. - Alinear la arquitectura con equipos de plataforma, desarrolladores y operaciones. - Delegar controles en plataformas que pueden hacerlos mejor (proveedores de nube, sistemas de identidad). - Evite soluciones personalizadas en las que los servicios compartidos sean suficientes. |
| 7. La red no es tan confiable como cree que es | La confianza en la red nunca debe ser el plano de control principal ni el único. | - Esta ley sustenta el abandono del enfoque centrado en el perímetro. - Cambiar las decisiones de confianza a la identidad, el dispositivo y el contexto de la aplicación. - Diseño de arquitecturas que asumen que la red es observable y hostil. - Conservar controles efectivos, como firewalls o firewalls de aplicaciones web (WAF), pero no se basan en ellos para detectar o bloquear todo. - Utilice modelos de acceso Confianza cero de manera coherente en todos los entornos. |
| 8. Las redes aisladas no son seguras automáticamente | El aislamiento solo es efectivo cuando se diseña y mantiene rigurosamente. | - Conservar el aislamiento de red que funciona bien. Asegúrese de seguir manteniéndola y de que los atacantes no puedan eludirla fácilmente. - La arquitectura debe tener en cuenta las personas y el proceso, no solo la topología. - Tratar el aislamiento como un sistema, no una regla de filtrado de red. - Asegure todos los puntos de interconexión (medios, acceso de proveedores, administradores). - Dé por hecho que está en peligro y aplique controles sólidos de identidad y operativos, incluso en diseños aislados. |
| 9. El cifrado por sí solo no es una solución de protección de datos | La criptografía solo es tan segura como las claves que lo desbloquean. | - El cifrado es importante, pero es ineficaz sin una implementación y operación seguras. - Diseñar la administración centralizada de claves y la gobernanza del acceso. - Proteja las vías de descifrado con la misma contundencia que el almacenamiento cifrado. - Combinar el cifrado con la identidad, la supervisión y la aplicación de directivas. |
| 10. La tecnología no resuelve los problemas de las personas ni de los procesos | La arquitectura debe asumir procesos y humanos imperfectos. | - Modernizar la arquitectura de seguridad para reducir el radio de explosión del error humano. No permita que un solo clic en un correo electrónico de phishing haga fracasar su postura de seguridad. - Diseñar sistemas resistentes al error. - Automatice las salvaguardas siempre que sea posible. - Evite arquitecturas que dependan del funcionamiento manual impecable. |
Creación de una arquitectura
Como arquitecto de seguridad, puede usar estas dos tablas como lentes complementarias. Uno para validar la solidez técnica y el otro para impulsar la priorización basada en riesgos. Cuando se combinan, forman un marco de decisión práctico para el diseño y la modernización de la arquitectura.
| Leyes | Objetivo | Uso arquitectónico | Preguntas respondidas |
|---|---|---|---|
| Leyes inmutables de seguridad | Capturar las verdades técnicas que siempre se cumplen. | Asegúrese de que las arquitecturas no infringen la realidad técnica. Suposiciones de prueba Valide los límites de confianza. Evite la confianza falsa. |
¿La arquitectura es fundamentalmente sólida? ¿El diseño se basa en algo que se puede omitir fácilmente? ¿Suponemos que la tecnología puede compensar a administradores que no son de confianza, contraseñas débiles o métodos de acceso físico? ¿Estamos confundiendo el cifrado, el aislamiento o las herramientas con un control real? |
| Leyes de riesgo de ciberseguridad | Decida lo que más importa. | Identifique dónde invertir el esfuerzo de arquitectura. Defina hojas de ruta de modernización. Justifica los inconvenientes con los líderes empresariales. |
¿Dónde obtienen los atacantes el mayor pago por el menor esfuerzo? ¿Qué controles cambian realmente el comportamiento del atacante? ¿Qué trabajo ya no vale la pena hacer? |
Example
Entonces, si tomamos un ejemplo en el que se aplican ambas tablas a la vez.
| Decisión de diseño | Lente de las leyes inmutables | La lente de las diez leyes |
|---|---|---|
| Reducir la dependencia de las ACL de red en favor del acceso basado en identidad | Las redes no son de confianza, la identidad es importante. | Aumenta el costo del atacante y se alinea con los principios de Confianza cero. |
| Priorice la MFA para los administradores antes de reforzar los cortafuegos perimetrales. | Las contraseñas débiles echan por tierra una seguridad robusta. | Forma más barata de romper las cadenas de ataque comunes. |
| Segmentar las cargas de trabajo en lugar de depender de "espacios aislados" | El aislamiento no es seguro automáticamente. | Reduce el alcance del daño cuando los atacantes logran entrar. |
| Automatice la aplicación de parches y la detección de desviaciones en la configuración | Las protecciones obsoletas fallan. | No mantenerse al día es quedarse atrás |
El uso de ambas tablas conjuntamente conduce a arquitecturas de seguridad que:
- Asumir el riesgo, centrarse en la reducción de riesgos y la limitación de daños, en lugar de en la promesa de la prevención absoluta.
- Céntrese en la identidad, los privilegios y el movimiento lateral, no solo en la defensa perimetral.
- Supongamos el cambio continuo y la evolución, y no diagramas estáticos.
- Equilibre la productividad empresarial con la reducción de riesgos. Alinee los controles de seguridad con el valor empresarial.
- Integre personas, procesos y tecnología.
- Reduzca el ROI del atacante en lugar de perseguir la seguridad perfecta.
- Aplique los principios de Confianza cero de extremo a extremo.
Pasos siguientes
Asegúrese de revisar las demás disciplinas de seguridad.