Blog WatchGuard

La normativa de ciberseguridad cambia. Tu arquitectura de seguridad no tiene por qué hacerlo

Las nuevas normativas se suceden, pero los principios básicos de la seguridad siguen siendo los mismos. Descubre cómo los MSP pueden vincular los controles de seguridad con los requisitos normativos y generar nuevas oportunidades de servicio.

Si eres un MSP o un MSSP, probablemente hayas mantenido alguna conversación como esta con un cliente: “Acabamos de enterarnos de que tenemos que cumplir con NIS2, DORA, HIPAA, PCI DSS… ¿Qué tenemos que comprar?” 

Es una pregunta lógica, aunque no suele ser el mejor punto de partida. Y saber responderla es precisamente lo que te permite aportar un valor real a tus clientes.

Porque, si trabajas en ciberseguridad o TI, a veces puedes tener la sensación de que a cada paso surge una nueva ley, normativa, marco de referencia o exigencia de cumplimiento en materia de ciberseguridad.

NIS2. El Reglamento de Ciberresiliencia. DORA. Los requisitos sectoriales. Las normativas regionales y nacionales. Y estos son solo algunos de los requisitos que tus clientes pueden necesitar conocer, según dónde operen y a qué se dediquen.

Mantenerse al día de todos ellos ya es difícil. Entender qué implican realmente para la tecnología que gestionas en nombre de tus clientes puede serlo aún más.

Pero hay una idea importante que puede perderse en el debate:

Los requisitos normativos pueden variar, pero muchas de las prácticas de seguridad necesarias para cumplirlos son muy similares.

Distintas normativas, preguntas de seguridad conocidas

Una normativa puede exigir que una organización demuestre que dispone de controles de acceso adecuados. Otra puede hacer hincapié en proteger las redes y los sistemas de información. Y otra puede exigir que las organizaciones gestionen los riesgos, detecten incidentes y respondan ante ellos, o protejan su cadena de suministro.

Leídos por separado, parecen requisitos distintos.

Sin embargo, desde la perspectiva de las TI o la ciberseguridad, suelen conducir a las mismas preguntas:

  • ¿Controlamos quién puede acceder a nuestros sistemas?
  • ¿Limitamos con qué recursos pueden comunicarse los usuarios y las aplicaciones?
  • ¿Protegemos nuestra red frente a amenazas conocidas y emergentes?
  • ¿Supervisamos lo que está ocurriendo?
  • ¿Podemos identificar actividades sospechosas?
  • ¿Disponemos de controles para reducir la probabilidad de sufrir un incidente y limitar su impacto?

No son preguntas nuevas. Los buenos equipos de ciberseguridad —y los buenos MSP— llevan años planteándoselas.

La evolución del panorama normativo hace aún más necesario responder a estas preguntas y demostrar a tus clientes que se están abordando.

Aquí es donde los puntos en común resultan útiles

Uno de los errores que pueden cometer las organizaciones -y del que conviene advertir a tus clientes- es abordar cada normativa como un proyecto de seguridad completamente independiente.

Este enfoque genera una larga lista de iniciativas de cumplimiento, cada una con sus propios controles, documentación y requisitos tecnológicos. Resulta caro, difícil de mantener y poco escalable.

Es más útil identificar las capacidades de seguridad comunes a esos requisitos.

Por ejemplo, los controles de seguridad de red pueden contribuir a varios objetivos de seguridad a la vez. La prevención de intrusiones puede ayudar a detectar y bloquear actividades maliciosas. Los controles de aplicaciones permiten restringir el uso de aplicaciones potencialmente peligrosas. El filtrado web y DNS puede reducir la exposición a destinos maliciosos o inapropiados. Y el antivirus y la protección avanzada frente al malware pueden aportar capas adicionales de defensa.

La tecnología no es “para NIS2” ni “para la normativa X”.

Es tecnología que aplica controles de seguridad para ayudar a una organización a cumplir los requisitos de distintas normativas y marcos de referencia. Precisamente el tipo de eficiencia que tus clientes esperan de ti.

El firewall puede formar parte de esa base

Al hablar de cumplimiento normativo y firewalls, es fácil centrarse en los servicios de seguridad disponibles mediante suscripción. Estos servicios aportan valor, pero son solo una parte.

Las funciones básicas de red de un firewall pueden ser igual de importantes.

Un Firebox, por ejemplo, permite utilizar zonas de seguridad y VLAN para segmentar las redes y controlar cómo se comunican los sistemas entre sí. En lugar de permitir que todos los dispositivos de una red se comuniquen libremente, puedes ayudar a tus clientes a establecer separaciones entre usuarios, servidores, redes de invitados, dispositivos IoT, sistemas de gestión y otros recursos.

Esta segmentación ayuda a aplicar un principio básico de seguridad: no todos los sistemas necesitan comunicarse con todos los demás.

El control de acceso es otro ejemplo. Las políticas del firewall determinan qué tráfico se permite entre redes y servicios, mientras que las protecciones integradas, como la prevención de ataques de fuerza bruta, ayudan a impedir los intentos de acceso no autorizado.

Nada de esto exige que el cliente contrate una suscripción independiente para cada objetivo de seguridad. Son controles básicos que pueden incorporarse al diseño de la red desde el primer día.

A ello se suman los servicios de seguridad, que añaden nuevas capas de protección. Según el modelo de Firebox y las licencias contratadas, funciones como Intrusion Prevention Service, Gateway AntiVirus, APT Blocker, Application Control, WebBlocker, DNSWatch, Botnet Detection, Geolocation y Data Loss Prevention ofrecen protección adicional frente a amenazas y técnicas de ataque específicas.

Lo importante es que estas capacidades actúan de forma conjunta. Una red segura se construye mediante varias capas de controles que se complementan para reducir el riesgo.

Por eso, ante una nueva normativa, no empezaría preguntando: “¿Qué producto de seguridad necesito para cumplirla?” 

Yo empezaría preguntando: “¿Qué controles de seguridad exige este requisito, qué riesgos pretenden abordar y de qué capacidades disponemos ya?”. 

Este cambio de perspectiva facilita considerablemente la adaptación a nuevas normativas. Y tú estás en una buena posición para guiar esa conversación. Activar un servicio de seguridad no equivale a utilizarlo bien: hay que configurarlo de acuerdo con el perfil de riesgo y las necesidades de seguridad de cada cliente.

DNSWatch, por ejemplo, puede ayudar a proteger a los usuarios frente a dominios maliciosos, mientras que WebBlocker ofrece un filtrado de contenido web más detallado. Intrusion Prevention y Application Control aportan capacidades adicionales de inspección y control del tráfico de red y del comportamiento de las aplicaciones.

Estas capacidades constituyen la base de una estrategia de seguridad más amplia, que puedes adaptar a cada cliente en lugar de revender el mismo paquete a todos. 

El cumplimiento normativo no consiste en marcar casillas

Hay otra diferencia que conviene dejar clara a tus clientes: tener una función de seguridad activada no significa que una organización cumpla automáticamente con la normativa.

El cumplimiento depende de la normativa aplicable, las circunstancias de la organización, cómo se implantan los controles y las evidencias disponibles para demostrar que funcionan de forma eficaz.

Un firewall con todos los servicios de seguridad activados no garantiza un mayor cumplimiento que uno configurado específicamente para abordar los riesgos reales de la organización. De hecho, a veces puede ocurrir lo contrario: el ruido y los errores de configuración pueden restar eficacia a los propios controles que la normativa exige que funcionen correctamente.

Tus clientes necesitan entender por qué existe cada control, qué riesgo aborda, cómo está configurado y cómo se supervisa su eficacia. Ahí es donde tu papel como MSP o MSSP aporta un valor especial. 

Convertir la normativa en una oportunidad para ofrecer servicios

Para los proveedores de servicios, la proliferación de normativas supone tanto un reto como una oportunidad.

Puede que tus clientes acudan a ti con esta pregunta: “¿Podéis conseguir que cumplamos con la normativa?” 

Lo más útil suele ser plantear la conversación en estos términos:

“Veamos qué requisitos debéis cumplir, identifiquemos los riesgos y los controles aplicables y determinemos cómo puede abordarlos vuestra arquitectura de seguridad actual”. 

Este enfoque suele revelar que el cliente ya dispone de muchas de las capacidades necesarias. Quizá deba configurarlas de otra manera, subsanar carencias, mejorar la supervisión, documentar los controles o establecer mejores procesos operativos. Todo ello son servicios que puedes estructurar en paquetes y facturar.

Para ti y tus equipos técnicos, esto significa que la capacidad de traducir la normativa en controles técnicos concretos tiene cada vez más valor. No es necesario memorizar cada párrafo de cada norma. Sí es fundamental entender los objetivos de seguridad que persiguen esos requisitos y saber relacionarlos con las capacidades que ya existen en la red de tu cliente.

La normativa seguirá cambiando

No creo que el panorama normativo vaya a simplificarse a corto plazo. Surgirán nuevas leyes. Se modificarán las normas existentes. Distintas jurisdicciones introducirán requisitos diferentes. Y tus clientes seguirán preguntándote qué implica todo esto para ellos.

Puede resultar abrumador.

Pero la mejor forma de abordarlo es empezar por los principios básicos de la seguridad.

Protege los accesos. Segmenta las redes. Controla las aplicaciones. Prevén y detecta amenazas. Protege a los usuarios frente a destinos maliciosos. Supervisa la actividad. Prepárate para los incidentes. Gestiona el riesgo. Documenta qué haces y por qué.

Después, relaciona esas capacidades con los requisitos aplicables a cada cliente.

Las normativas concretas pueden cambiar, pero estas prácticas básicas de seguridad seguirán siendo necesarias. Y cuando una plataforma como Firebox reúne múltiples capacidades en un único sistema, se convierte en una base sólida para implantar y mantener esos controles en un entorno normativo en constante evolución, para cada cliente y ante cada nueva regulación.

El objetivo no debería ser diseñar una arquitectura de seguridad distinta para cada nueva normativa, sino construir una arquitectura sólida que pueda adaptarse a los cambios normativos.