Proteger para habilitar: cómo integrar seguridad y negocio

A lo largo de mi carrera vi el mismo patrón repetirse una y otra vez: para muchas personas que toman decisiones de negocio u operativas, la seguridad aparece como un problema, un freno, algo que “complica”, “demora” o “encarece”. No como un habilitador, no como parte del diseño, sino como una capa molesta impuesta desde afuera. Y lo cierto es que, en muchos casos, no están del todo equivocados.

El error no está tanto en que el negocio perciba a la seguridad como un obstáculo, sino que está en asumir que eso es inevitable. Ahí nace el mito fundacional: la idea de que seguridad y negocio son fuerzas opuestas, condenadas a nunca entenderse. Como si mejorar una implicara necesariamente empeorar la otra.

Y ese es un relato cómodo. Para el negocio, porque le permite culpar a “los de seguridad” cuando algo no avanza. Para seguridad, porque justifica controles rígidos bajo el argumento de “yo solo cuido el riesgo” y las debilidades que puedan percibir en “el negocio no acompaña”. Todos quedan relativamente tranquilos… y el sistema sigue siendo malo.

Este enfoque choca de frente con una idea que Intel formalizó hace años bajo el lema “Protect to Enable”: la seguridad no existe para decir que no, sino para permitir que el negocio avance de forma segura. Respecto a lo que uno ve comunmente, supone un cambio completo de mentalidad. Proteger no es el objetivo final; el objetivo final es habilitar.

Sobre la implementación de esta idea en Intel, existe el libro «Managing Risk and Information Security: Protect to Enable» de Malcolm Harkins, ex-Vicepresidente de Seguridad y Gestión de Riesgos de Información en Intel.

Cuando esa filosofía se ignora, la seguridad se diseña en abstracto: como una colección de controles a imponer, desconectados de cómo trabaja la gente. Ahí aparecen las VPNs para todo, los bloqueos ante la duda, los accesos que tardan semanas, las excepciones manuales, los procesos opacos. No es seguridad sólida: es seguridad torpe, controles incapaces de convivir con la operación real.

El negocio por su parte, rara vez expresa esto en términos técnicos. No dice “este control no mitiga bien el riesgo” o “esto introduce más superficie de ataque indirecta”. Dice algo mucho más brutal y honesto desde su percepción: “así no puedo trabajar”. Y cuando trabajar se vuelve difícil, la gente no se detiene a debatir modelos de amenazas: busca atajos.

En este punto es donde la fricción se vuelve peligrosa. Cuando la seguridad frena al negocio el riesgo no desaparece. Solo se desplaza, llegando a volver invisible. Ahí aparece el «shadow IT», los accesos compartidos, los flujos paralelos, las soluciones “temporales” que duran años. El negocio sigue avanzando, pero fuera del radar de seguridad.

La filosofía de Protect to Enable apunta justamente a romper ese círculo vicioso: diseñar controles que acompañen el flujo del negocio en lugar de pelearse con él. Controles que logren que hacer lo correcto sea más fácil que evadirlos. Porque si la única forma de avanzar es esquivar la seguridad, el sistema ya falló, aunque todos los checks del marco normativo estén en verde. El problema no es “seguridad vs negocio”. El problema es seguridad diseñada sin entender el negocio. Es confundir rigor con rigidez. Y romper este mito es el primer paso para algo más honesto: aceptar que la seguridad no compite con el negocio, pero sí compite con la fricción innecesaria.

Cuando la seguridad se diseña desde el miedo

Buena parte de los controles de seguridad que vemos en organizaciones que sufren lo anterior, no nacen de un análisis serio de riesgo, sino de algo mucho más primitivo: el miedo. Miedo a un incidente reciente o futuro, a una auditoría que se acerca, —o peor todavía— a quedar expuesto frente a la jerarquía.

Los ejemplos son conocidos. Después de un ransomware, se bloquea todo “hasta nuevo aviso”. Tras un phishing exitoso, se agregan capas de fricción al acceso y más filtros en el correo electrónico y la navegación. Cuando llega una auditoría, aparecen controles de último momento que no se entienden muy bien. No hay rediseño, ni revisión sistémica: hay reacción.

Este tipo de decisiones tiene una lógica emocional muy clara. El cerebro humano está mal cableado para manejar riesgos abstractos y de baja frecuencia. La « Heurística de disponibilidad   » explica que las personas estiman la probabilidad de un evento según la facilidad con la que pueden recordar ejemplos similares. Entonces, un incidente concreto, visible y reciente, pesa más que cien amenazas bien modeladas. Es el sesgo de disponibilidad en acción: lo que acaba de pasar se siente más probable, más peligroso y/o más urgente, aunque estadísticamente no lo sea.

A eso se suma otro factor clave: la aversión a la culpa. En muchas organizaciones la seguridad no se mide por su efectividad, sino por su capacidad de demostrar que “se hizo algo”. Agregar un control visible reduce la ansiedad interna: si algo vuelve a pasar, al menos se puede decir que se endureció la postura. En este contexto el control no tiene que ser bueno, tiene que ser defendible.

Así aparecen decisiones como forzar cambios masivos de contraseñas, bloquear accesos legítimos, imponer procesos manuales interminables o exigir aprobaciones absurdas. Son controles que tranquilizan a quien los firma, pero no a quien los usa.

El problema es que la seguridad diseñada desde el miedo tiende a ser acumulativa y asimétrica. Cada incidente agrega una capa, pero casi nunca se revisan las anteriores. El sistema se vuelve más pesado, más frágil y más difícil de operar. Nadie se pregunta qué controles siguen siendo relevantes, solo se va sumando uno más “por las dudas”.

Desde el punto de vista psicológico, esto es entendible: el miedo empuja a maximizar la sensación de control inmediato, incluso si eso empeora el resultado a largo plazo. Pero ese reflejo genera fricción, errores humanos y, paradójicamente, más riesgo operativo.

El negocio por su parte reacciona como puede, se adapta. Aparecen los atajos, las excepciones informales, las credenciales compartidas, los procesos paralelos, las herramientas no aprobadas. La seguridad entonces, al volverse impracticable, deja de ser parte del sistema real y pasa a ser algo casi decorativo.

Diseñar seguridad desde el miedo no es un error intelectual, es un fallo humano. Y reconocerlo es clave, porque mientras las decisiones se tomen para calmar ansiedades en lugar de reducir riesgo real, la brecha entre seguridad y operación solo va a crecer.

Fricción operativa: el costo invisible

La fricción operativa es un efecto secundario subestimado de la seguridad mal diseñada. No aparece en los reportes de auditoría, no suele tener KPI propio y es difícil de asumir, pero está ahí robando tiempo, atención y energía todos los días. Cada paso extra para acceder a un sistema, cada aprobación manual, cada workaround improvisado es tiempo de trabajo perdido. Tiempo que se pierde por goteo y en ocasiones es difícil de percibir, porque la organización no se detiene, pero sí se vuelve más lenta y más propensa al error.

Un ejemplo que he visto por mí mismo: accesos a sistemas que requieren el uso VPN incluso cuando el servicio ya está en la nube, con posibilidad de implementar autenticación fuerte y controles de identidad adecuados. El resultado de esto no es más seguridad, sino sesiones inestables, caídas y reconexiones, el costo de mantener un servidor VPN, y usuarios que terminan dejando la VPN abierta todo el día “por las dudas”. El control existe, pero su uso real degrada el sistema.

Otro caso frecuente: procesos de alta o cambio de permisos que tardan días. Desde el punto de vista de seguridad es “control de accesos”. Desde el punto de vista operativo es bloqueo. En estos casos el negocio no espera: comparte credenciales, reutiliza cuentas o pide favores. La fricción no elimina el acceso indebido sino que lo empuja a la informalidad.

Toda esta fricción además tiene un efecto psicológico importante y contraproducente: si interactuar con la seguridad es constantemente frustrante las personas dejan de verla como parte del sistema y la perciben como un obstáculo externo. El usuario no piensa “esto me protege”, piensa “esto me hace perder tiempo”. A partir de ahí cualquier control se vive como algo a esquivar.

Paradójicamente, muchos de estos controles que fueron pensados para reducir el error humano terminan aumentando la probabilidad de error, porque fuerzan a trabajar bajo estrés, con atajos y sin claridad. La seguridad entonces termina creando las condiciones ideales para los mismos incidentes que pretende evitar.

Hay también un costo menos visible pero más profundo: el desgaste. Equipos cansados de pelear con herramientas, procesos que nadie entiende y excepciones que se vuelven regla.

Y lo más irónico: desde afuera, todo parece funcionar. Los controles están, las políticas existen, los accesos están “gestionados”. He visto organizaciones pasar auditorías así. Pero el sistema real, el que la gente usa para trabajar, ese opera en paralelo. Cuando se llega a este punto ya no importa cuántos controles haya. El costo operativo supera cualquier beneficio teórico, y el riesgo real aumenta, ya no por falta de controles sino por exceso de fricción.

Shadow IT: el síntoma visible

Debido a la fricción operativa suele aparecer el «Shadow IT». Con este término describimos el conjunto de herramientas, servicios y procesos que el negocio adopta por fuera de los canales formales de TI y seguridad.

Shadow IT no aparece porque la gente sea irresponsable o “no entienda de seguridad”. Aparece cuando los caminos oficiales resultan lentos, rígidos o directamente impracticables. Es una respuesta adaptativa, el negocio no se propone violar políticas sino cumplir objetivos. Cuando acceder a una herramienta demora semanas o meses, cuando compartir información de forma segura es más difícil que mandarla por cualquier SaaS gratuito, cuando pedir un permiso implica frenar un proyecto, el camino informal se vuelve el más lógico. En general podría decir que no es una decisión reflexiva sino pura eficiencia humana.

La seguridad tradicionalmente interpreta Shadow IT como un problema de disciplina. Entonces la respuesta típica es endurecer controles, bloquear servicios, emitir políticas más estrictas. Dicho de otra forma: atacar el síntoma con más fricción, justo el mecanismo que generó el problema en primer lugar. Pero si lo vemos desde el punto de vista de la psicología, Shadow IT es coherente. Las personas optimizan para cumplir su trabajo con el menor costo cognitivo posible. Si el camino “seguro” es largo o frustrante el cerebro va a elegir el atajo. En esto como en tantas otras cosas, es importante tener en cuenta el comportamiento humano para diseñar sistemas considerándolo, y no contra él.

Lo interesante en todo esto es que la existencia de Shadow IT no elimina la necesidad de seguridad sino que la desplaza fuera del radar. Las herramientas no aprobadas igual manejan datos sensibles, las cuentas compartidas igual existen y los flujos paralelos igual operan. Pero ahora nadie los ve, nadie los monitorea y nadie los mejora.

En organizaciones maduras Shadow IT se trata como una señal. Una alerta de que los controles no están alineados con la realidad operativa. No se pregunta “¿por qué la gente incumple?”, sino “¿qué les estamos impidiendo hacer de forma segura?”. Ahí aparece una oportunidad clave: muchas veces el Shadow IT revela necesidades reales del negocio antes que los procesos formales. Ignorarlo o simplemente prohibirlo es desperdiciar información valiosa.

Volviendo a la filosofía de Protect to Enable: si diseñás controles que habilitan el trabajo, el Shadow IT pierde sentido. No porque se prohiba específicamente, sino porque deja de ser necesario. El camino oficial se vuelve más corto, más confiable y más seguro que el atajo.

Incluso cuando la seguridad funciona bien, es esperable que Shadow IT no desaparezca del todo, pero sí que se reduzca a casos puntuales, e importante, visibles. Cuando la seguridad funciona mal, el Shadow IT se convierte en la infraestructura real de la organización, y la “oficial” en una fachada vacía. Observar esto es un indicador muy valioso: si tenés mucho Shadow IT, no tenés un problema de usuarios, tenés un problema de diseño.

El modelo de amenazas

Después de ver cómo la fricción operativa y el Shadow IT aparecen cuando la seguridad se diseña sin contexto, surge una pregunta inevitable: ¿cómo se modela la seguridad para que eso no ocurra? La respuesta no está en más controles, sino en mejores decisiones. Ahí es donde entra el modelo de amenazas bien hecho. Un modelo de amenazas no debe ser un documento para cumplir ni una planilla para auditoría. Es una herramienta para pensar antes de controlar. Para decidir qué proteger, de quién, cómo y con qué costo. Y también, qué no proteger de la misma forma.

El primer cambio mental es aceptar que no todo tiene el mismo valor ni el mismo riesgo. Suena obvio, pero muchísimas arquitecturas de seguridad se diseñan como si todos los sistemas fueran igual de críticos y todos los accesos igual de peligrosos. Eso lleva directamente a controles uniformes, rígidos, y en muchas ocasiones, caros.

Un buen modelo de amenazas empieza por entender el negocio, no por la tecnología. ¿Qué procesos generan valor? ¿Qué datos, si se ven comprometidos, realmente duelen? ¿Qué caídas son tolerables y cuáles no? Sin esas respuestas, cualquier control es un tiro al aire. Lo ideal es tener un buen inventario de activos de información como base para modelar amenazas.

El segundo paso es identificar amenazas realistas, no imaginarias. No se trata de pensar en atacantes omnipotentes, sino priorizar el pensar en adversarios plausibles dadas la industria, el contexto y la exposición real. Cuando el modelo de amenazas exagera al adversario, los controles sobrerreaccionan. Y la sobrerreacción casi siempre resulta en fricción operativa. Es fundamental evaluar probabilidad e impacto sin dramatismo. No todo acceso externo es una catástrofe. No todo error humano termina en desastre. La seguridad madura acepta la incertidumbre y trabaja con ella, en lugar de intentar eliminarla a fuerza de fricción.

Un tercer punto clave es entender dónde conviene poner el control. El modelo de amenazas permite elegir puntos de control que reduzcan riesgo sin interferir —o con interferencia mínima— en la operación. Hablo de decisiones como proteger la identidad en lugar de la red, usar automatización en vez de aprobaciones manuales, o priorizar visibilidad y alertas accionables antes que restricciones rígidas. Por ejemplo: si la amenaza principal es el robo de credenciales, imponer VPNs y restricciones de red puede ser menos efectivo que fortalecer identidad , implementar MFA resistente a phishing y detección de comportamiento anómalo. El control correcto en el lugar correcto es menos intrusivo y más eficaz.

Otro punto importante: un modelo de amenazas honesto reconoce que hay riesgos que no vale la pena mitigar del todo, lo que llamamos riesgo aceptado. No porque no se puedan, sino porque el costo —operativo, económico o humano— supera el beneficio. Bien analizados y gestionados estos riesgos no suponen negligencia sino diseño consciente.

Por último, un modelo de amenazas bien hecho es algo vivo, no se hace una vez y se archiva. Cambia con el negocio, con la tecnología y con el contexto. Pero cada iteración tiende a reducir fricción, no a aumentarla, porque aprende de la operación real.

En contraste, la seguridad diseñada desde el miedo acumula controles, mientras que la seguridad diseñada desde un modelo de amenazas elige controles.

Métricas que importan

Las métricas son importantes para evaluar la efectividad de un sistema, pero es importante saber qué medir, porque si medís mal empujás a decisiones malas, aunque la intención sea buena. En seguridad, esto pasa bastante: se celebran números que no dicen nada sobre riesgo real ni sobre impacto en el negocio.

En la práctica he visto muchas organizaciones que siguen midiendo la seguridad por actividad visible: cantidad de controles implementados, volumen de bloqueos, número de alertas generadas o porcentaje de cumplimiento. Son métricas cómodas porque son fáciles de contar y fáciles de reportar, pero peligrosas porque premian la fricción en lugar de la efectividad. Cuando el éxito se define como “bloquear más” lo único que puede ocurrir es eso: más bloqueos, más fricción. Por otro lado, organizaciones que ni siquiera tienen claro qué deberían medir y terminan usando cualquier número disponible como indicador de “buena seguridad”, esto, por supuesto, tampoco es útil para evaluar la seguridad.

Una métrica útil no mide la existencia del control, sino su efecto. Debería permitir responder una pregunta simple: ¿este control reduce riesgo sin dañar la operación?. Si la métrica no ayuda a ver eso, posiblemente no sirve.

Algunos ejemplos de métricas que sí dicen algo:

Tiempo medio para habilitar un acceso legítimo. No cuánto tarda el ticket en cerrarse, sino cuánto tiempo pasa hasta que una persona puede trabajar. Si este número crece, la seguridad está introduciendo fricción.

Cantidad y tipo de excepciones activas. Las excepciones no son un fallo puntual; son una señal estructural. Muchas excepciones indican que el control no encaja con la realidad.

Uso real de los controles (no solo existencia). Un control que existe pero se evita sistemáticamente no protege nada. Medir adopción efectiva —por ejemplo, accesos directos vs accesos por atajo— es mucho más valioso que contar reglas configuradas.

Incidentes por fricción operativa. Errores causados por complejidad: credenciales compartidas, accesos mal configurados, bypass “temporal”.

Tiempo de recuperación ante accesos bloqueados incorrectamente. Los falsos positivos importan. Un sistema que bloquea mucho pero tarda en corregirse castiga al negocio.

Proporción de controles preventivos vs reactivos. Más prevención bien ubicada suele significar menos interrupciones.

Feedback del usuario como dato operativo. No hablo de encuestas de satisfacción, sino señales concretas: cuántos tickets se abren por fricción, cuántos pasos requiere una acción segura, cuántas veces se pide ayuda para lo mismo.

Estas métricas tienen algo en común: obligan a mirar el sistema completo y no solo la postura de seguridad aislada. Hacen visible el costo operativo del control y permiten compararlo con el riesgo que mitiga. Desde la lógica de Protect to Enable, un control que bloquea el trabajo no está protegiendo nada relevante. Medir seguridad en términos de impacto real es lo único que permite distinguir entre controles que habilitan al negocio y controles que lo frenan.

El rol del arquitecto de seguridad

Considerando todo lo anterior, el rol del arquitecto de seguridad es diseñar sistemas que gestionen el riesgo de forma deliberada y permitan operar sin fricción innecesaria, o dicho de otra forma: diseñar sistemas seguros que la gente pueda usar sin pensar en seguridad

Cuando la seguridad falla, rara vez es por falta de controles. Es por falta de diseño. Y diseñar implica entender cómo trabaja el negocio, cómo se equivocan las personas, qué duele cuando algo se rompe y qué no. Implica aceptar que la perfección no existe y que el riesgo no se elimina: se gestiona.

Un arquitecto de seguridad no debería empezar preguntando “¿qué control aplicamos?”, sino “¿qué estamos intentando habilitar?”. La diferencia es sutil pero cambia todo. En lugar de imponer barreras, se diseñan caminos. En lugar de reglas rígidas, se definen principios que se sostienen cuando el contexto cambia.

También es quien traduce. Traduce riesgo técnico a impacto de negocio, y urgencias de negocio a decisiones técnicas conscientes. No simplifica de más, pero tampoco agrega complejidad innecesaria. Hace explícitos los trade-offs, incluso cuando eso incomoda.

Otra función clave es resistir la tentación del miedo que mencionaba antes. Después de un incidente, es común que todo empuje a endurecer. El arquitecto de seguridad es quien tiene que frenar, mirar el sistema completo y preguntar si el nuevo control realmente reduce riesgo o solo calma ansiedades.

Con todo esto, Protect to Enable se vuelve un criterio de diseño. Si un control no habilita el trabajo seguro o no escala, se revisa, y se rediseña o se reemplaza.

Cuando la seguridad frena al negocio, el problema no es el negocio

A lo largo de los años he visto muchísimos casos donde seguridad y negocio están en constante tensión. Casi como si fuera algo inevitable. Pero en mi experiencia —y lo que he leído— que esto ocurra no se trata de un choque de objetivos o una verdadera incompatibilidad, sino de un problema de diseño.

No es necesario aclarar que este artículo no trata de relajar controles ni de elegir velocidad por encima de seguridad. Trata más bien de cómo el miedo, la fricción mal ubicada y las métricas equivocadas empujan a construir sistemas que obligan al negocio a esquivar la seguridad para poder avanzar.

Proteger para habilitar no es una consigna optimista: es una disciplina de diseño. Implica partir de lo que se quiere hacer posible, modelar amenazas reales, aceptar trade-offs explícitos y construir controles que reduzcan riesgo sin trasladar el costo a la operación. Diseñar controles que funcionen en la práctica, no solo en auditorías.

La seguridad bien diseñada no compite con el negocio: lo acompaña. Cuando eso no ocurre, el problema no es que el negocio quiera ir rápido, es que la seguridad está pensada como un obstáculo, y en esos casos hay que rediseñarla

Para cerrar, para quien quiera profundizar en esta forma de pensar, Protect to Enable es una muy buena lectura —aprendí bastante leyendo ese libro—, junto con cualquier otra que ponga el acento en diseño, contexto y efectos reales antes que en checklists y prohibiciones. También, si querés conversar sobre esto, me interesa leer comentarios, críticas y experiencias propias. Encontrarás mis métodos de contacto en el pie de este blog.