Ahora que en el Reino Unido se ha realizado el mayor programa piloto de la historia para probar la viabilidad de una semana laboral de cuatro días, cabe preguntarse qué implicaciones podría tener para la seguridad de las TIC la adopción generalizada de este sistema.
Casi cuatro mil empleados de 61 empresas británicas participaron en la prueba, y el 92% optó por seguir con una semana laboral de 32 horas, al menos de momento. Sus defensores afirman que el cambio contribuyó a elevar la motivación y la productividad de los empleados. Bélgica, Islandia y Nueva Zelanda también han realizado pruebas con resultados similares. Y más recientemente, hemos conocido que el Ayuntamiento de Valencia ha empezado con un test para probar en la ciudad el impacto de su aplicación.
La ONG neozelandesa 4 Day Week Global está detrás de muchos de los pilotos y sostiene que, si se les da la opción, los empleados mantendrán una productividad igual o superior y un mayor grado de satisfacción cuando se les ofrezca la posibilidad de trabajar 32 horas semanales por el mismo salario.
Aún es demasiado pronto para saber si la semana laboral de cuatro días ganará terreno, e incluso sus defensores admiten que no se adapta bien a todos los sectores. Pero si vamos a asistir a nuestro segundo cambio tectónico en la forma en que trabajamos en tan sólo los últimos cinco años, no estará de más considerar las implicaciones para la seguridad de las TIC de una semana laboral de cuatro días mucho antes de su adopción.
¿Acceso sin contexto?
Muchas empresas acogidas al programa piloto del Reino Unido optaron por escalonar los horarios de los trabajadores durante la prueba, para así garantizar al menos cinco días de cobertura de las necesidades de la empresa. Otras funcionaban con lo que los encargados del estudio denominaron horarios «descentralizados», en los que los departamentos e incluso los individuos podían elegir su día libre. Algunos optaron por imponer una semana laboral de 32 horas y dejar a discreción de los empleados cuándo cumplir con sus responsabilidades. Otras variaban la jornada laboral de una semana a otra.
Aunque esto favorece la flexibilidad de los empleados, puede también causar problemas en los equipos de seguridad, que se basan en patrones de comportamiento predecibles para tomar decisiones de seguridad. El contexto del acceso es un elemento clave para decidir si se debe permitir o denegar dicho permiso.
Pensemos, por ejemplo, en un empleado que suele estar activo en el entorno de trabajo los lunes, pero no los viernes. Cuando ese empleado aproveche su recién lograda flexibilidad para cambiar los días de la semana en los que trabaja, los analistas del SOC ya no podrán señalarlo como inusual, eliminando lo que antes era una útil fuente de contexto. Para un empleado, se trata de un desafortunado punto ciego, pero para muchas empresas, es un problema de seguridad.
La ubicación de los dispositivos es otro elemento crítico de contexto que corre el riesgo de verse alterado por la semana laboral de cuatro días. En el estudio realizado en el Reino Unido, el 52% de los empleados declararon haber aumentado sus viajes de ocio durante los periodos de prueba. Podríamos encontrarnos ante un estado casi permanente de solicitudes de acceso a recursos desde destinos vacacionales, ya que los empleados aprovecharían el trabajo híbrido y los «puentes» para viajar.
La detección de un problema de seguridad depende en gran medida de una conducta de referencia previamente identificada. Las desviaciones de esta base desencadenan una investigación más profunda. Pero, ¿cómo pueden los profesionales de la seguridad determinar un comportamiento de referencia cuando todo es anormal?
Dificultades en la gestión de dispositivos
Otra consecuencia imprevista para los equipos de TIC en las organizaciones que pasan a tener una semana laboral de cuatro días, tiene que ver con la gestión de la seguridad de los dispositivos. Cuando los dispositivos están fuera de la red durante largos periodos de tiempo, los equipos de TIC se enfrentan a largos periodos de tiempo entre actualizaciones y parches. Se puede seguir actualizando la infraestructura principal con regularidad, pero muchas actualizaciones siguen requiriendo que los dispositivos estén en la red corporativa. Cuando se detecte el próximo caso grave de «zero day», es posible que pasen varios días antes de que todos los terminales dispongan de las actualizaciones necesarias para protegerlos, y proteger a la empresa.
No cabe duda de que los equipos de TIC establecerán nuevos calendarios de aplicación de parches y actualizaciones para adaptarse a los nuevos horarios de trabajo. Pero no será un proceso de un día para otro y dará lugar a una curva de aprendizaje. Las empresas que decidan pasar a una semana laboral de cuatro días deben tener en cuenta este efecto secundario antes de implantar el cambio.
Prevenir es lo mejor
La semana laboral de cuatro días puede convertirse en algo que nuestros hijos asuman como natural dentro de un tiempo. Muchos dicen que la semana laboral de cinco días se debe a Henry Ford, que la redujo de seis días con la corazonada de que trabajar menos horas haría a los empleados más productivos. Las organizaciones que participaron en el estudio del Reino Unido notaron efectivamente niveles más bajos de estrés, mayor productividad y menor rotación de personal.
Pero es poco probable que las empresas realicen esta transición en poco tiempo. Aunque el ritmo va subiendo, las grandes organizaciones han de tener en cuenta factores como los planes de aplicación de parches y el contexto de las solicitudes de acceso antes de cambiar. De hecho, pueden aparecer muchos obstáculos imprevistos relacionados con las TIC como resultado de un cambio tan significativo.
Ya hemos vivido estos cambios antes, y sabemos que aquellos que fueron capaces de conectar de forma segura a los usuarios con las aplicaciones, independientemente de la red, la ubicación o el tipo de dispositivo, fueron los más resilientes a las incidencias.
Una arquitectura de red basada en la confianza cero, complementada con los siguientes elementos, es la respuesta más sólida a las nuevas necesidades de los usuarios:
- Pasar a negro – Establecer reglas precisas para impedir que los actores de amenazas busquen activos expuestos a través de DNS y pings de IP.
- Evitar los desplazamientos laterales – Conectar a los usuarios a las aplicaciones, no a las redes.
- Crear un contexto propio – Aprovechar el contexto adicional mediante una estrecha integración de las soluciones de seguridad de terminales y de protección/verificación de identidades. Registrar cada transacción en el SOC para ayudar a crear nuevas referencias.
- Detener el transporte de retorno – Aprovechar la proximidad de los usuarios finales a los centros de datos regionales, garantizando el rendimiento en todo el mundo mediante la presencia localizada en la nube.
En un mundo en constante cambio, la única forma de avanzar es no confiar en nada ni en nadie.
Martyn Ditchburn, Director de Transformación Estratégica, Zscaler
