Por qué los hoteles son objetivos fáciles, y no daños colaterales
Un hotel es un objetivo inusualmente atractivo, y a la mayoría de los operadores nunca se les ha explicado por qué. Almacenas una gran cantidad de datos personales de miles de desconocidos: nombres, direcciones particulares, copias escaneadas de pasaportes y documentos de identidad, fechas de viaje, datos de pago y, en ocasiones, notas sobre salud y alimentación. Gestionas un edificio repleto de dispositivos de los huéspedes conectados a tu red. Operas las 24 horas del día con una recepción atendida por personal formado para ayudar a desconocidos, que es precisamente el instinto que aprovecha un ingeniero social. Además, dependes de un conjunto de sistemas siempre activos, el sistema de gestión hotelera que gestiona la cuenta y almacena los datos de los huéspedes, el gestor de canales, las cerraduras de las puertas, el punto de venta, que no pueden permitirse ningún tiempo de inactividad sin que el negocio se paralice. Los atacantes saben todo esto. No se topan con los hoteles por casualidad; los eligen. Los sistemas que contienen los datos de sus huéspedes, empezando por el sistema de gestión hotelera, son las joyas de la corona que realmente busca un atacante.
Durante años, la ciberseguridad se consideró un problema del departamento de TI o, en un hotel independiente sin departamento de TI, un problema de nadie hasta que algo fallaba. Esa postura ya no es sostenible en 2026 por dos razones que convergen. La primera es el ransomware, que se ha industrializado hasta convertirse en un negocio de servicios que afecta de manera desproporcionada a los operadores de tamaño medio con datos valiosos y defensas débiles, exactamente el perfil de un hotel independiente. La segunda es la NIS2, la directiva de la UE sobre seguridad de las redes y la información, que ha convertido la ciberseguridad de un gasto discrecional en TI en una obligación legal con responsabilidad personal para la dirección. Incluso su flujo de pagos forma parte del panorama: la forma en que gestiona los datos de las tarjetas a través de su sistema de pago determina la cantidad de datos utilizables que un atacante puede robar realmente cuando, no «si», sino «cuando», consiga acceder al sistema.
Escribo para Prostay, y nuestro equipo dedica mucho tiempo a la intersección entre los sistemas hoteleros que desarrollamos y las obligaciones de seguridad que ahora asumen nuestros clientes; por ello, los patrones de amenazas, los plazos normativos y las prioridades de control que se exponen a continuación proceden del marco publicado de la NIS2, de los datos sobre incidentes que las empresas de seguridad informan en el sector hotelero y de la realidad práctica de ayudar a los establecimientos a recuperarse cuando algo sale mal. Este artículo está dirigido al director general y al propietario, no al ingeniero de seguridad. Explica si la NIS2 se aplica a su caso, cómo se produce realmente una violación de seguridad en un hotel, los plazos de notificación que debe cumplir, las pocas medidas de control que reducen realmente el riesgo y un plan de 30 días para pasar de estar expuesto a estar protegido. Nada de esto requiere una titulación en informática. Lo que sí se necesita, en su mayor parte, es decidir que esta es ahora tu responsabilidad, porque, tanto desde el punto de vista legal como práctico, lo es.
Qué es realmente la NIS2 y si afecta a su hotel
La NIS2 es la segunda versión de la Directiva de la UE sobre seguridad de las redes y la información. La primera Directiva NIS (2016) abarcaba un conjunto reducido de operadores críticos: energía, agua y grandes infraestructuras digitales. La NIS2, que los Estados miembros debían transponer a la legislación nacional antes del 17 de octubre de 2024, amplía drásticamente el ámbito de aplicación, eleva el nivel mínimo de las medidas de seguridad exigidas, endurece los requisitos de notificación de incidentes y, lo que es más importante, establece sanciones reales y la responsabilidad personal de los directivos. No se trata de una ley específica para el sector hotelero, y precisamente por eso muchos hoteleros no se han dado cuenta de que podría aplicárseles.
Su aplicación depende de tres factores: el sector, el tamaño y la transposición de la normativa en su país. Los hoteles no figuran en la lista principal de sectores «esenciales» como sí lo hacen la energía y la sanidad, por lo que un hotel independiente no es automáticamente una entidad regulada en la mayoría de los países. Sin embargo, los límites son más difusos de lo que sugiere ese resumen: los umbrales de tamaño afectan directamente a los grandes establecimientos y grupos, y las disposiciones relativas a la cadena de suministro tienen un alcance mucho más amplio que el ámbito de aplicación formal. El resultado es un panorama en el que algunos hoteles entran directamente en el ámbito de aplicación, muchos más están vinculados indirectamente a través de socios y casi ninguno está realmente exento de la expectativa subyacente de gestionar el riesgo cibernético.
Entidades esenciales frente a importantes, y el criterio de tamaño
La NIS2 divide a las organizaciones reguladas en dos niveles. Las entidades esenciales son los operadores de mayor criticidad y se enfrentan a la supervisión más estricta. Las entidades importantes constituyen un grupo más amplio que, aunque debe cumplir con las obligaciones de seguridad y notificación, está sujeto a una supervisión más ligera, normalmente tras un incidente y no de forma proactiva. Esta distinción es relevante principalmente por el grado de presión que ejerce el regulador y por la cuantía de las multas máximas.
A esto se suma un filtro de tamaño. Las obligaciones de la directiva están pensadas para organizaciones medianas y grandes, en términos generales aquellas con 50 o más empleados, o con una facturación anual y un balance superior a 10 millones de euros, que operen en los sectores cubiertos. Un pequeño hotel costero con 18 empleados suele quedar por debajo de ese umbral y no está directamente incluido en el ámbito de aplicación. Un hotel de conferencias urbano de 250 habitaciones, o una empresa gestora que administre una docena de inmuebles, puede superar fácilmente ese umbral y entrar directamente en el ámbito de aplicación. El punto clave a tener en cuenta a la hora de planificar es que el tamaño se evalúa a nivel de la entidad jurídica y, en ocasiones, del grupo en su conjunto, por lo que un pequeño establecimiento propiedad de un operador más grande puede heredar obligaciones que no tendría por sí solo. Confirme su situación concreta con un asesor local, ya que los detalles de la transposición y la correspondencia exacta con los sectores varían según el Estado miembro.
La cláusula de la cadena de suministro que afecta a los pequeños hoteles
Esta es la parte que pilla desprevenidos a los independientes. La NIS2 convierte la seguridad de la cadena de suministro y de los proveedores en una obligación explícita de las entidades que entran en el ámbito de aplicación. Un grupo hotelero regulado, una plataforma de viajes, un comprador de viajes corporativos o una empresa gestora debe gestionar la seguridad de sus proveedores y socios, y la forma más clara de cumplir con esa obligación es trasladar los requisitos a sus proveedores mediante contrato. Así pues, a un hotel independiente de 40 habitaciones que reciba reservas corporativas de una empresa regulada, opere bajo una marca de franquicia o se conecte a una plataforma regulada se le exigirá cada vez más un anexo de seguridad: aplicar la autenticación multifactorial (MFA), mantener copias de seguridad comprobadas, notificarnos los incidentes en un plazo de X horas y permitirnos realizar auditorías. Se cumplen los controles exigidos por la NIS2 no porque haya llamado a la puerta un regulador, sino porque perder el contrato no es una opción.
Por eso, pensar que «somos demasiado pequeños para la NIS2» es una forma errónea de plantearse el año 2026. La pregunta realista no es si la directiva menciona a tu empresa, sino cuándo te afectarán los controles, ya sea por designación directa, a través de tu grupo o por el contrato de un socio, y si prefieres implementarlos con calma ahora o tener que apresurarte ante un plazo impuesto por otra persona. El resto de este artículo da por hecho que los necesitarás, porque la gran mayoría de los operadores con alguna actividad comercial los necesitarán.
La superficie de ataque de un hotel, representada en un mapa
Para defender un hotel hay que verlo como lo ve un atacante: como un conjunto de puertas, la mayoría de las cuales has olvidado dejar abiertas. La superficie de ataque es más amplia que el ordenador de la recepción, y identificar cada parte es el primer paso para cerrarla.
La recepción humana. El personal de recepción está formado para confiar y ayudar. A menudo basta con una llamada telefónica convincente («somos el departamento de TI de la sede central, necesitamos que instales una actualización rápida») o una factura por correo electrónico bien elaborada. El phishing y la ingeniería social son el punto de entrada inicial más común en todos los sectores, y la cultura de amabilidad del sector hotelero lo agrava aún más.
Acceso remoto. Alguien tiene que acceder al PMS desde fuera de las instalaciones: un propietario, un responsable de noche, un proveedor de software que presta asistencia técnica. Con demasiada frecuencia, ese acceso es un servicio de Escritorio Remoto sin protección, expuesto directamente a Internet y protegido por una sola contraseña reutilizada. Es, sin lugar a dudas, la vulnerabilidad que se explota con mayor fiabilidad en los ataques de ransomware a pequeñas empresas.
Conexiones de terceros. Tu gestor de canales, motor de reservas, pasarela de pago, sistema de cerraduras y contratistas de mantenimiento se conectan a tu entorno. Cada uno de ellos es una vía de acceso potencial, y una brecha de seguridad en un proveedor puede convertirse en una brecha en tu propio sistema. Este es el riesgo de la cadena de suministro por el que se obsesiona la NIS2, visto desde tu perspectiva.
Redes de huéspedes y operativas. Si la red Wi-Fi para huéspedes, los sistemas de reservas, los terminales de pago y los equipos de la trastienda comparten una misma red plana, entonces el portátil comprometido de un huésped o un dispositivo infectado con malware en el vestíbulo puede acceder al PMS. Las redes planas convierten una pequeña intrusión en una intrusión total.
Dispositivos sin parches y olvidados. El controlador de la cerradura de la puerta que funciona con un firmware de hace diez años, el terminal de punto de venta que nadie actualiza, el viejo ordenador de la trastienda que sigue con un sistema operativo que ya no recibe parches de seguridad. Los atacantes buscan precisamente estos dispositivos y los utilizan para colarse. La superficie de ataque de un hotel no es un gran muro que defender, sino docenas de pequeños muros, y al atacante solo le basta con que uno de ellos sea vulnerable.
Cómo se desarrolla realmente una brecha de seguridad en un hotel
El ransomware no se activa en el instante en que alguien hace clic en un enlace malicioso. Se desarrolla por etapas a lo largo de horas o días, y comprender la secuencia te indica en qué momento aún tienes la oportunidad de detenerlo.
Suele comenzar con un acceso inicial: unas credenciales obtenidas mediante phishing, un inicio de sesión RDP expuesto al que se accede probando contraseñas comunes, o un punto de apoyo heredado de un proveedor comprometido. El atacante ya está dentro como un usuario más, a menudo sin que nadie se dé cuenta. A continuación viene la escalada de privilegios y el movimiento lateral: buscan una cuenta de administrador, se desplazan desde el ordenador de recepción hacia los servidores y mapean lo que tienes. Esta es la fase silenciosa, que a veces dura días, y es donde una buena supervisión y la segmentación de la red aún pueden detectarlos y contenerlos.
A continuación, la exfiltración: los grupos modernos de ransomware roban una copia de los datos de tus huéspedes antes de cifrar nada, porque los datos robados son una baza incluso si tus copias de seguridad son perfectas. Este es el paso a la denominada «doble extorsión». Solo al final llegan el cifrado y la nota de rescate: archivos bloqueados, el PMS inutilizable, una exigencia en pantalla y una recepción que, de repente, no puede registrar la entrada ni la salida de nadie. La razón por la que esta secuencia es importante es que la parte ruidosa y obvia (la pantalla bloqueada) es el último acto, no el primero. Para cuando la ves, el atacante suele llevar ya un tiempo en tu entorno y se ha llevado lo que quería. Las defensas que solo reaccionan ante el cifrado lo hacen demasiado tarde; las victorias se consiguen antes, en el acceso y el movimiento lateral.
La economía de un ataque de ransomware a un hotel
Los operadores se fijan en la cuantía del rescate, pero este rara vez es el mayor coste. Si sumas todo lo que un incidente grave supone realmente para un hotel, la cifra que importa es la interrupción total de la actividad, no la demanda que aparece en pantalla.
Empecemos por el tiempo de inactividad. Si el PMS está cifrado, la recepción vuelve a utilizar lápiz y papel si puede, el gestor de canales deja de sincronizarse, las OTA siguen vendiendo habitaciones que no puedes ver, y en cuestión de horas te encuentras con reservas duplicadas y tienes que rechazar a huéspedes. Una interrupción del servicio de varios días durante un periodo de mucha actividad puede suponer más pérdidas por reservas perdidas o gestionadas incorrectamente que cualquier rescate. A esto hay que añadir el coste de la recuperación: especialistas en respuesta a incidentes, investigación forense, reconstrucción de los sistemas a partir de copias de seguridad limpias y las horas extras del personal para gestionar las operaciones manualmente mientras tanto. Luego está el aspecto normativo y legal: las sanciones de la NIS2 para las entidades afectadas son elevadas (para las entidades esenciales, las multas pueden alcanzar los 10 millones de euros o el 2 % de la facturación anual global, lo que sea mayor), la exposición al RGPD si se han filtrado los datos de los huéspedes y el coste de notificar y atender a los huéspedes afectados.
Y, por último, el coste que ninguna hoja de cálculo refleja con claridad: la reputación. «Este hotel filtró los datos de mi pasaporte y de mi tarjeta» es el tipo de historia que persigue a un establecimiento en las reseñas y en la prensa durante años. Pagar el rescate tampoco soluciona nada de esto de forma fiable; las herramientas de descifrado proporcionadas por los delincuentes suelen ser lentas o incompletas, el pago te marca como un objetivo fácil para el siguiente grupo de atacantes y no resuelve en absoluto el problema de los datos ya robados. Los argumentos económicos a favor de la prevención son abrumadores precisamente porque las consecuencias negativas son mucho mayores y más complicadas de lo que sugiere la cifra del rescate que aparece en los titulares. Gastar unos pocos miles en autenticación multifactorial (MFA), copias de seguridad y segmentación es un seguro barato frente a un mal mes que puede costar seis o siete cifras.
El plazo de notificación: 24 horas, 72 horas, un mes
Para las entidades afectadas, la NIS2 no solo te exige que estés protegido; te impone la rapidez con la que debes informar a las autoridades cuando no lo estás. El plazo es más ajustado de lo que la mayoría de los operadores supone, y comienza en el momento en que alguien en las instalaciones se da cuenta de que se está produciendo un incidente significativo.
En un plazo de 24 horas: la alerta temprana. Una vez que se tiene conocimiento de un incidente significativo, se debe enviar a la autoridad nacional o al CSIRT una alerta temprana rápida, incluso antes de comprender plenamente lo que ha ocurrido. Lo importante es la rapidez, no la exhaustividad; el regulador quiere saber cuanto antes que se está produciendo algo grave.
En un plazo de 72 horas: la notificación del incidente. A continuación se presenta un informe más completo, con una evaluación inicial de la gravedad, el impacto y cualquier indicador de compromiso. Para entonces, ya deberías haber activado tu equipo de respuesta a incidentes y tener una idea clara del alcance del mismo.
En el plazo de un mes: el informe final. Un relato detallado del incidente, la causa raíz, las medidas adoptadas y el impacto. Esto cierra el ciclo con el regulador. Paralelamente, si se han expuesto datos personales (y en una filtración en un hotel casi siempre es así), también se aplica el plazo de 72 horas del RGPD para notificar a la autoridad de protección de datos, y es posible que tengas que informar directamente a los huéspedes afectados. Se trata de obligaciones distintas ante autoridades distintas, y se solapan en el tiempo, lo que explica precisamente por qué no se puede determinar quién llama a quién durante el propio incidente.
La lección operativa es clara: las decisiones sobre la notificación deben estar tomadas de antemano. Quién declara un incidente, quién se pone en contacto con la autoridad, qué autoridad, con qué información, a qué número… Todo ello debe figurar en un plan escrito que puedas ejecutar a las 3 de la madrugada sin tener que llamar a un abogado. Un establecimiento que nunca haya pensado en esto agotará el plazo de 24 horas simplemente porque nadie sabía que era su responsabilidad realizar la llamada.
La responsabilidad de la dirección y por qué el director general no puede delegar esto
El cambio en la NIS2 que más debería preocupar a los propietarios y directores generales no es en absoluto técnico. Se trata de que la directiva atribuye la responsabilidad de la gobernanza de la ciberseguridad directamente al órgano de dirección y hace que esa responsabilidad sea personal. La dirección debe aprobar las medidas de gestión de riesgos cibernéticos de la organización, supervisar su implementación y puede ser considerada responsable en caso de incumplimiento. La directiva también exige que los directivos reciban formación en ciberseguridad para que puedan comprender realmente los riesgos que están autorizando.
En términos sencillos: un director general ya no puede limitarse a decir «eso es tarea del departamento de TI» y dar el asunto por zanjado. Puedes delegar el trabajo a un equipo interno o a un proveedor externo, pero la responsabilidad de garantizar que se lleve a cabo, y las consecuencias si no es así, recae sobre ti. Las transposiciones nacionales respaldan esto con la amenaza de multas significativas y, en algunos casos, la posibilidad de inhabilitar temporalmente a las personas para ocupar puestos directivos en caso de fallos graves. Se trata de una decisión deliberada de la UE: la experiencia demostró que la seguridad carecía de recursos suficientes mientras se situaba dos niveles por debajo de quienes controlaban el presupuesto, por lo que la Directiva NIS II la elevó a la cima del organigrama.
Para un hotel independiente, no se trata tanto de miedo como de asunción de responsabilidad. Alguien con autoridad debe asumir la responsabilidad del riesgo cibernético del mismo modo que asume la de la seguridad contra incendios o la higiene alimentaria: como una responsabilidad específica con un presupuesto, un plan y una revisión periódica, y no como una cuestión secundaria que solo sale a la luz cuando algo falla. La buena noticia es que los controles que cumplen con esta obligación son, en su mayoría, sencillos y asequibles, y de eso trata el resto de este artículo. La obligación es seria; cumplirla no es nada del otro mundo.
Los controles que realmente marcan la diferencia
El marketing de la ciberseguridad quiere venderte un sinfín de siglas. La verdad es que un pequeño número de controles poco llamativos detienen la gran mayoría de los ataques reales contra los hoteles, y son mucho más importantes que cualquier producto concreto. Estos son los que merecen tu atención y tu presupuesto en primer lugar.
Identidad, autenticación multifactorial (MFA) y el problema del RDP
La mayoría de las brechas de seguridad en los hoteles no son ingeniosas; se trata de una contraseña válida utilizada en un lugar donde no debería haber funcionado. Dos medidas neutralizan la mayor parte de esos casos. En primer lugar, aplica la autenticación multifactorial en todas las cuentas importantes: inicios de sesión en el PMS, correo electrónico, acceso remoto, cuentas de administrador, etc. Con la MFA, una contraseña robada por sí sola es inútil. En segundo lugar, retira el Escritorio Remoto de la red pública. Si el personal o los proveedores necesitan acceso remoto, hazlo a través de una VPN o una pasarela de confianza cero con autenticación multifactorial, y nunca expongas el RDP directamente. Combina esto con unas prácticas básicas de seguridad en las contraseñas (no compartir credenciales, nada de «Welcome2024» en la cuenta de administrador, un gestor de contraseñas para que los usuarios puedan tener contraseñas seguras y únicas) y habrás cerrado la puerta por la que se cuelan los ataques más comunes. Esta es la medida de seguridad más rentable que puede adoptar un hotel, y cuesta muy poco.
Copias de seguridad de las que realmente se puede restaurar
Las copias de seguridad son las que determinan si un ataque de ransomware supone una mala semana o el fin del negocio. Pero el detalle que suele pasar desapercibido es que la copia de seguridad debe estar tanto fuera de línea o ser inmutable como haber sido probada. Los atacantes buscan específicamente y cifran las copias de seguridad conectadas antes de activar el ransomware, por lo que una unidad de copia de seguridad conectada permanentemente al servidor no ofrece protección alguna. Lo que necesitas son copias a las que el atacante no pueda acceder: fuera de línea o en un almacenamiento en la nube inmutable que no pueda modificarse ni eliminarse dentro de un plazo de retención. Y tienes que probar la restauración de forma periódica, porque el peor momento para descubrir que tus copias de seguridad están dañadas o incompletas es la mañana en que realmente las necesitas. Una copia de seguridad de la que nunca has restaurado datos es una esperanza, no un plan.
Segmentación del PMS, el TPV y la red Wi-Fi para huéspedes
La segmentación de la red es el control que limita hasta dónde puede extenderse una intrusión. El principio es sencillo: los elementos que no necesitan comunicarse entre sí no deben estar en la misma red. La red Wi-Fi para huéspedes debe estar aislada de todo lo operativo, de modo que el portátil infectado de un huésped no pueda acceder al PMS. Las terminales de pago deben estar en su propio segmento. Los sistemas de back-office y el PMS deben estar separados de la navegación general del personal. Cuando el ordenador de recepción se ve comprometido, la segmentación es lo que impide que el atacante llegue a los servidores y a los sistemas de pago de un solo salto. Convierte una posible brecha total en una contenida, y se trata principalmente de configurar correctamente el equipo que ya tienes, en lugar de comprar nada nuevo.
Datos de pago, tokenización y reducción del alcance de la brecha
Los datos más peligrosos que se pueden almacenar son aquellos que no es necesario conservar. Los números de tarjeta sin cifrar son el ejemplo más claro. Si tus sistemas almacenan o incluso gestionan, aunque sea brevemente, los datos completos de las tarjetas, una filtración los deja al descubierto y tu responsabilidad es grave. La solución es la tokenización: tu procesador de pagos guarda los datos reales de la tarjeta en su almacén seguro y entrega a tu PMS un token sin significado que representa la tarjeta, pero que no se puede utilizar en caso de robo. Si se hace correctamente, el número confidencial de la tarjeta nunca llega a estar presente en tu red.
Esta es la lógica de seguridad que subyace a la norma PCI DSS, y es la razón por la que una configuración de pago moderna y tokenizada constituye tanto un control de seguridad como una comodidad a la hora de realizar pagos. Cuando un atacante irrumpe en el sistema y busca datos de tarjetas para robarlos, no hay nada útil que pueda llevarse. Esa única decisión arquitectónica elimina por completo de tu riesgo la categoría de datos más atractiva y más estrictamente regulada. Esto no le hace invencible, ya que el resto del expediente del huésped (pasaportes, direcciones, historial de estancias) sigue siendo valioso y debe protegerse, pero elimina el «tesoro más preciado» de la ecuación. Cualquier hotel que siga permitiendo que los números completos de las tarjetas de crédito entren en contacto con su PMS o se almacenen en una hoja de cálculo debería considerar la solución de este problema como una emergencia, no como un punto más de su plan de acción.
Proveedores, el gestor de canales y el riesgo de terceros
Tu seguridad es tan sólida como el proveedor más débil que tenga conexión con tus sistemas, y un hotel tiene muchos. El gestor de canales, el motor de reservas, la pasarela de pago, la plataforma de cerraduras, las herramientas de marketing, la empresa de soporte informático: cada uno de ellos tiene acceso o datos, y una brecha de seguridad en cualquiera de ellos puede convertirse en una brecha en tu propio sistema. La NIS2 formaliza esto como una obligación de gestionar el riesgo de los proveedores, pero es simplemente una cuestión de sentido común, independientemente de si la directiva menciona específicamente a tu establecimiento.
Gestionar este riesgo no requiere un departamento de compras. Lo que se necesita es plantear a tus proveedores clave una serie de preguntas breves y concisas, y actuar en función de las respuestas. ¿Dónde se almacenan nuestros datos y están cifrados? ¿Aplicáis la autenticación multifactorial (MFA) para acceder a nuestro entorno? ¿Habéis sufrido alguna brecha de seguridad y cómo la gestionasteis? ¿Qué certificaciones o evaluaciones de seguridad independientes podéis mostrarme? ¿Con qué rapidez nos avisarían si se viera comprometida su seguridad? Un proveedor serio responde a estas preguntas sin dudar y puede ofrecer de su propia iniciativa un resumen de su seguridad o una certificación reconocida. Un proveedor que se pone a la defensiva o se muestra evasivo le está diciendo algo importante. Dé preferencia a los socios que tratan la seguridad como una característica de la que se enorgullecen, en lugar de como una cuestión que les molesta, porque en una infraestructura interconectada su falta de higiene se convierte en su riesgo.
Redactar un plan de respuesta a incidentes que pueda ejecutar un auditor nocturno
El único documento que distingue un incidente controlado de uno caótico es un plan de respuesta por escrito que un miembro del personal sin conocimientos técnicos pueda seguir en el peor momento posible. Los ataques no respetan el horario laboral; a menudo se producen por la noche y en días festivos precisamente porque el equipo reducido está menos preparado. Por lo tanto, el plan debe poder ser utilizado por quienquiera que esté de turno, no solo por el contratista de TI que está durmiendo.
Que sea concreto. El plan debe indicar los tres primeros pasos que cualquiera puede dar: desconectar de la red los equipos afectados (desenchufar el cable, desactivar el wifi) para detener la propagación sin apagarlos, lo que podría destruir pruebas forenses; llamar a la persona de contacto designada para incidentes; y comenzar un sencillo registro escrito de lo que se ha observado y cuándo. Debe incluir una lista de a quién llamar, con nombres reales y números de teléfono: el responsable interno, el proveedor de TI o el servicio de respuesta a incidentes contratado, la línea de atención de la aseguradora cibernética y la autoridad competente para la denuncia policial. Debe recordar al personal lo que no debe hacer: no pagar nada, no negociar, no borrar los datos de los equipos, no hablar con la prensa. Y debe abordar la continuidad operativa: cómo gestionar manualmente el registro de entrada y salida de los huéspedes, cómo cobrar si el sistema está fuera de servicio, cómo impedir que las OTA vendan en exceso habitaciones que ya no están disponibles.
A continuación, haz lo que casi nadie hace: ensaya el plan. Un ejercicio de simulación de 30 minutos en el que guíes al equipo de recepción a través de la situación «el PMS está bloqueado y hay una nota de rescate, ¿y ahora qué?» saca a la luz las carencias mientras aún son fáciles de solucionar. Un plan que nunca se ha leído en voz alta es un plan que se encontrará, sin haber sido leído, durante el único incidente para el que se redactó. Imprímelo. Deja una copia en recepción. Asegúrate de que el personal del turno de noche sepa que existe y dónde está.
Un plan de preparación cibernética de 30 días
Un mes es suficiente para que un hotel independiente típico pase de estar expuesto a estar realmente protegido, sin necesidad de un consultor ni de un gran presupuesto. Un responsable con autoridad puede liderarlo, recurriendo al proveedor de TI para los pasos técnicos.
Días 1 a 5: analiza lo que tienes. Haz una lista de todos los sistemas que contengan datos de huéspedes o estén relacionados con pagos, todas las cuentas con acceso remoto o de administrador, y todos los proveedores con conexión al sistema. No puedes proteger lo que no has inventariado, y esta lista es también la base de la evaluación de riesgos que exige la NIS2. Anota qué equipos ejecutan software que ya no recibe actualizaciones de seguridad.
Días 6 a 12: cierra las puertas más vulnerables. Activa la autenticación multifactorial (MFA) en todos los lugares donde esté disponible, empezando por el correo electrónico, el acceso remoto y el PMS. Retira el RDP de la red pública de Internet. Elimina los inicios de sesión compartidos y restablece las contraseñas de administrador débiles. Solo con esta semana se eliminan las vulnerabilidades más explotadas, y se trata principalmente de configuración, no de adquisición de equipos.
Días 13 a 18: soluciona los problemas con las copias de seguridad. Confirma que dispones de copias de seguridad del PMS y de los sistemas críticos que estén desconectados o sean inmutables, y luego comprueba realmente que la restauración funciona. Si la única copia de seguridad es una unidad conectada al servidor, soluciona eso primero. Documenta los pasos de restauración para que puedan seguirse en situaciones de presión.
Días 19 a 23: segmenta y aplica parches. Separa la red Wi-Fi para invitados de los sistemas operativos, coloca los pagos en su propio segmento y aplica las actualizaciones de seguridad pendientes a los sistemas que puedan recibirlas. Planifica la sustitución de cualquier sistema que utilice software al final de su ciclo de vida y que no pueda parchearse.
Días 24 a 28: redactar el plan de incidentes y revisar a los proveedores. Elabora un borrador del plan de respuesta de una página con nombres y números reales, y envía a tus proveedores clave el breve cuestionario de seguridad. Decide si un seguro cibernético tiene sentido para el tamaño y el riesgo de tu empresa.
Días 29 a 30: asigna responsabilidades y realiza simulacros. Nombra a la persona responsable del riesgo cibernético, programa una revisión trimestral en el calendario y lleva a cabo un ejercicio de simulación de 30 minutos con el equipo de recepción. Al final del mes no serás invulnerable, nadie lo es, , pero habrás cerrado las puertas por las que se cuelan los ataques reales y tendrás un plan para el día en que alguno se cuele. Esa es la definición realista de «listo».
El papel de Prostay, de forma breve y sincera
Escribo para Prostay, así que aquí va la versión sin rodeos. Un sistema de gestión hotelera ocupa el centro de este panorama porque alberga los datos de los huéspedes que buscan los atacantes y es el sistema cuyo tiempo de inactividad paraliza el negocio. Por lo tanto, la postura de seguridad de tu proveedor de PMS forma parte de tu riesgo, lo consideres así o no. Prostay funciona como una plataforma en la nube con los controles que cabría esperar de un proveedor serio: cifrado de datos en tránsito y en reposo, autenticación multifactorial (MFA) en el acceso, pagos tokenizados para que los datos brutos de las tarjetas nunca lleguen al entorno del establecimiento, infraestructura auditada y copias de seguridad gestionadas, de modo que gran parte de la carga mencionada anteriormente la asume la plataforma en lugar de recaer en la recepción. Nada de esto es exclusivo de Prostay; proveedores de PMS en la nube de renombre, como Mews y Cloudbeds, asumen compromisos similares, y deberías plantearles a todos ellos las mismas preguntas difíciles que figuran en la sección anterior dedicada a los proveedores.
El argumento más sólido a favor de una plataforma moderna en la nube frente a un servidor local heredado en la trastienda es que traslada gran parte del trabajo de seguridad más complejo (aplicación de parches, refuerzo de la infraestructura, copias de seguridad y gestión de datos de pago) a un proveedor que se dedica a ello a tiempo completo, que es precisamente lo que un hotel de 40 habitaciones sin departamento de TI no puede hacer bien por sí solo. Esto no te exime de tus obligaciones; sigues siendo responsable de la autenticación multifactorial (MFA) de tus cuentas, de tu plan de gestión de incidentes, de la formación de tu personal y de la gestión de tus proveedores. Pero reduce el ámbito que tienes que defender personalmente. Si quieres ver cómo gestiona el PMS de Prostay los datos de los huéspedes y los pagos, ahí tienes la información detallada del producto; y si prefieres que nuestro equipo revise tu infraestructura actual comparándola con la lista de verificación de preparación anterior, reserva una demostración y abordaremos las cuestiones reales en lugar de venderte una actualización basada en el miedo.
Preguntas frecuentes
Respuestas a las cinco preguntas más frecuentes de los hoteleros independientes sobre ciberseguridad y la Directiva NIS2, basadas en la propia directiva y en cómo se desarrollan realmente los ataques, en lugar de en el discurso alarmista de los proveedores.
