Comentarios al anteproyecto de «Ley sobre la seguridad de las redes y sistemas de información»

El ministerio de Energía, Turismo y Agenda Digital ha publicado este anteproyecto para que las personas interesadas puedan hacer llegar sus comentarios, observaciones y alegaciones al mismo.
El texto completo del anteproyecto está disponible en la siguiente dirección: http://www.minetad.gob.es/telecomunicaciones/es-ES/Participacion/Paginas/anteproyecto-ley-seguridad-redes-sistemas-informacion.aspx. El plazo para enviar observaciones finaliza el próximo 8 de enero. El colegio de informáticos de Madrid (CPIICM) solicitó a los colegiados que enviaran sus comentarios para preparar una respuesta conjunta y así hice hace unos días. Recojo en esta entrada algunos comentarios y parte del análisis crítico que realizo sobre este borrador de ley.

Disclaimer: Estoy colegiado en el CPIICM (Colegio Profesional de Ingenieros en Informática de la Comunidad de Madrid), trabajo actualmente en la AEI de Ciberseguridad y soy miembro del comité de dirección del Observatorio Europeo en Ciberseguridad y Privacidad. Sin embargo, las opiniones y valoraciones recogidas en este análisis son propias y no representan la postura oficial de ninguna de estas organizaciones (o de ninguna otra).

Resumen ejecutivo

El anteproyecto de la “Ley sobre la seguridad de las redes y sistemas de información» es una transposición de la Directiva (UE) 2016/1148 (PDF) del 6 de julio de 2016 relativa a las medidas destinadas a garantizar un elevado nivel común de seguridad de las redes y sistemas de información en la Unión.

Entiendo que estos desarrollos normativos son pertinentes y oportunos, sobre todo por los siguientes tres puntos principales:

La homogeneización del marco regulatorio europeo relacionado con la seguridad de los sistemas de información (lo que, recientemente, ha comenzado a denominarse “ciberseguridad”).
La cooperación entre los sectores públicos y las organizaciones privadas para hacer frente a los riesgos y amenazas de esta naturaleza.
La comunicación o notificación de incidentes de una manera efectiva, pronta y formalizada como principal instrumento de respuesta ante los mismos.

Sin embargo, el análisis detallado del anteproyecto advierte, principalmente, de falta de concreción (casual o intencionada) en algunos aspectos importantes. Personalmente, me llama la atención la falta de concreción en los siguientes aspectos:

El papel de los centros de operación de seguridad (COS/SOC) externos al prestador del servicio. Estos centros operados por empresas ajenas a los prestadores de servicios deben disponer de procedimientos específicos de comunicación con los CSIRT además de una cobertura legal adecuada para actuar en nombre y representación de sus clientes (empresas a las que prestan el servicio de operación de seguridad). Estamos hablando de empresas externas que gestionan la seguridad informática de una organización. Estos «SOCs» pueden actuar en nombre de su cliente (por ejemplo, para notificar un incidente en plazo y forma) pero no pueden asumir su identidad ni descargar las responsabilidades del cliente. Hace falta contemplar esta figura en la ley y definir responsabilidades, requisitos para actuar como SOC, etc.
La naturaleza, normas y estándares relacionados con las auditorías de seguridad informática. Este aspecto no está suficientemente detallado en el anteproyecto y su desarrollo debería subrayar la importancia de las mismas, evitando que su indefinición devenga en un requisito ineficaz para el objetivo perseguido. Como ocurre tantas veces, obligar por ley a realizar auditorias pero no especificar las mismas (en su alcance, normativa a aplicar, requisitos de los auditores, etc.) acabará generando un mercado de «auditorías low cost» que permitan cubrir los requisitos de la ley sin cumplir los objetivos de la misma.
El concepto de normativa vigente. De alguna manera, la ley debe incluir claramente las normativas a considerar o, en su caso, una referencia a algún organismo nacional o internacional que establezca las normativas a considerar. Como en el caso de las auditorias, hay que especificar qué entiende el legislador por «normativa vigente». En puridad, no existe ninguna normativa sobre seguridad informática vigente. Al menos, habría que referenciar el trabajo en este sentido de organismos internacionales (ENISA o ECSO, por ejemplo).
La validación de las certificaciones de seguridad. El papel de las mismas se considera muy relevante, pero su utilidad depende de tres factores críticos: 1) su aceptación internacional, 2) la existencia de una organización independiente eficaz que establezca, regule y actualice la certificación, y 3) la disponibilidad de un registro que permita verificar la vigencia de la certificación otorgada a las organizaciones que ostenten la misma. Como en los dos puntos anteriores, dejar este tema sin concretar deja la puerta abierta a «certificaciones low cost» que no tengan mayor contenido que un papel timbrado.

Revisión detallada

[Página 2]
Exposición de motivos. II

Los operadores de servicios esenciales y los proveedores de servicios digitales deberán adoptar medidas adecuadas para gestionar los riesgos que se planteen para la seguridad de las redes y sistemas de información que utilicen, aunque su gestión esté externalizada. Las obligaciones de seguridad que asuman deberán ser proporcionadas al nivel de riesgo que afronten y estar basadas en una evaluación previa de los mismos. Las normas de desarrollo de esta ley podrán concretar las obligaciones de seguridad exigibles a los operadores de servicios esenciales, incluyendo en su caso las inspecciones a realizar o la participación en actividades y ejercicios de gestión de crisis.

En el párrafo anterior, de la exposición de motivos, se menciona la situación habitual en la que los sistemas de información y, por tanto, su seguridad están gestionados por una organización externa al proveedor u operador del servicio. En este sentido, se debe hacer la observación de varias posibilidades diferentes:
• el servicio y la seguridad del mismo esté externalizada en un proveedor externo único.
• El servicio está externalizado en un proveedor de servicios y la seguridad del mismo está externalizada en un proveedor diferente (“proveedor externo de servicios de seguridad” conocido habitualmente como SOC -Security Operations Center- o COS -Centro de Operaciones de Seguridad-).
• El servicio no está externalizado, siendo operado de forma directa por el propio operador, pero sí lo está la gestión de seguridad del mismo (en un SOC o COS).
El anteproyecto analizado no regula la figura del proveedor de servicios de seguridad informática, cuya existencia es cada vez más común y de gran relevancia en la gestión de la seguridad informática de sus clientes.
Entendemos que la naturaleza de estos SOC/COS, su actuación en representación y delegación de sus clientes, sus propias responsabilidades y sus relaciones con otras organizaciones implicadas (por ejemplo, los CSIRT) debería merecer mayor atención dentro de la futura ley.

[Página 2]
Exposición de motivos. II
La notificación de incidentes forma parte de la cultura de gestión de riesgos que la Directiva y la ley fomentan. Por ello, la ley protege a la entidad notificante y a todo empleado que informe sobre incidentes ocurridos; se reserva la información confidencial de su divulgación al público o a otras autoridades distintas de la notificada y se permite la notificación de incidentes cuando no sea obligada su comunicación.

[Página 16]
Artículo 19. Protección del notificante.
1. Las notificaciones consideradas en este título no sujetarán a la entidad que las efectúe a una mayor responsabilidad.
2. Los empleados y el personal que, por cualquier tipo de relación laboral o mercantil, participe en la prestación de los servicios esenciales o digitales que informen sobre incidentes no podrán sufrir consecuencias adversas en su puesto de trabajo o con la empresa, salvo en los supuestos en que se acredite mala fe en su actuación.
Se entenderán nulas y sin efecto legal las decisiones del empleador tomadas en perjuicio o detrimento de los derechos laborales de los trabajadores que hayan actuado conforme a este apartado.

[Página 15]
Artículo 18. Obligación de notificar
[…]
3. Las autoridades competentes y los CSIRT de referencia utilizarán una plataforma común para facilitar y automatizar los procesos de notificación, comunicación e información sobre incidentes.

Tal y como recoge el anteproyecto, la protección del notificante es clave como parte integral de la gestión de incidentes. Sin embargo, se advierte de dos puntos que no están recogidos por el anteproyecto y que se antojan primordiales para lograr la máxima eficacia de las notificaciones:

1. Incluir en la protección del notificante no sólo a los empleados de la organización prestadora del servicio, sino también a todas aquellas personas que, teniendo por cualquier razón interés en el servicio prestado, notifiquen una incidencia de seguridad de forma y manera adecuadas. En esta lista de posibles notificantes se incluye (lista no exhaustiva): usuarios del servicio, clientes actuales o potenciales del servicio, expertos en seguridad informática, empleados de empresas de seguridad informática (aunque no presten servicio a la organización afectada), etc.

2. Incluir como requisito para la plataforma de notificación de incidentes de los CSIRT (Art. 18.3 del anteproyecto) la disponibilidad de un mecanismo para la notificación de incidentes de forma anónima. Esta función de notificación anónima, junto a la protección del informante indicada anteriormente, facilitaría a los expertos la notificación de incidentes de forma segura y con total garantía.

[Página 2]
 Exposición de motivos. II
 La ley recalca la necesidad de tener en cuenta los estándares europeos e internacionales así como las recomendaciones que emanen de los grupos de cooperación y de la red de CSIRT en el ámbito comunitario con vistas a aplicar las mejores prácticas aprendidas en estos foros y contribuir al impulso del mercado interior y a la participación de nuestras empresas en él.

[Página 7]
 Artículo 3. Definiciones
 […]
 k) Norma técnica: una norma en el sentido del artículo 2.1 del Reglamento (UE)nº 1025/2012 del Parlamento Europeo y del Consejo, de 25 de octubre de 2012, sobre la normalización europea.
 […]

[Página 14]
 Artículo 16. Normas técnicas.
 Las autoridades competentes promoverán la utilización de regulaciones, normas o especificaciones técnicas en materia de seguridad de las redes y sistemas de información elaboradas en el marco del Reglamento (UE) 1025/2012 del Parlamento Europeo y del Consejo de 25 de octubre de 2012 sobre la normalización europea.
 En ausencia de dichas normas o especificaciones, promoverán la aplicación de las normas o recomendaciones internacionales aprobadas por los organismos internacionales de normalización, y, en su caso, de normas y especificaciones técnicas aceptadas a nivel europeo o internacional que sean pertinentes en esta materia.

Ante la atomización de los estándares en ciberseguridad y de los propios organizaciones que desarrollan los estándares (en inglés, SDO -Standards Developing Organizations-), se propone utilizar como “organismo de normalización reconocido”, en el sentido del artículo del reglamento mencionado en el anteproyecto (1025/2012), la organización europea de ciberseguridad ECSO (European Cyber Security Organisation) cuyo grupo de trabajo 1 (WG1) tiene, precisamente, como objetivo proponer a la Comisión Europea un marco común de normativas en ciberseguridad basado en los estándares existentes para su aplicación en el mercado único digital europeo.

Nota bene: el autor de este análisis, teniendo acceso a la documentación interna del mencionado grupo de trabajo, ECSO WG1, debe hacer constar que en el momento de la redacción no existe aún un resultado final que recoja esta normativa común europea. Por ello, la propuesta concreta sería referenciar en la ley “el estándar (o los estándares) europeo de ciberseguridad elaborados por ECSO y aprobados por la comisión europea”.

[Página 15]
Artículo 17. Sectores con normativa específica equivalente.
Cuando una normativa nacional o comunitaria establezca para un sector obligaciones de seguridad de las redes y sistemas de información o de notificación de incidentes que tengan efectos, al menos, equivalentes a los de las obligaciones previstas en esta ley, prevalecerán aquellos requisitos y los mecanismos de supervisión correspondientes.
Ello no afectará al deber de cooperación entre autoridades competentes, a la coordinación ejercida por el Consejo de Seguridad Nacional ni, en la medida en que no sea incompatible con la legislación sectorial, a la aplicación del título V sobre notificación de incidentes.

En el artículo indicado sobre normativa específica (Art 17) se advierte la ausencia de una mención específica al Esquema Nacional de Seguridad (ENS, RD 3/2010 y posterior RD 951/2015) de obligado cumplimiento en la administración pública y de aplicación extensible a, prácticamente, cualquier proveedor de servicios digitales.

[Página 13]
 Artículo 12. Requisitos y funciones de los CSIRT de referencia.
 […]
 3. Los CSIRT establecerán relaciones de cooperación con el sector privado. A fin de facilitar la cooperación, los CSIRT fomentarán la adopción y utilización de prácticas comunes o normalizadas de:
 a) Procedimientos de gestión de incidentes y riesgos.
 b) Sistemas de clasificación de incidentes, riesgos e información.

[Página 13]
 Artículo 14. Cooperación con otras autoridades con competencias en seguridad de la información, y con las autoridades sectoriales.
 1. Las autoridades competentes, los CSIRT de referencia y el punto de contacto único consultarán, cuando proceda, con los órganos con competencias en materia de seguridad nacional, seguridad pública, seguridad ciudadana y protección de datos de carácter personal y colaborarán con ellas en el ejercicio de sus respectivas funciones.
 2. Consultarán asimismo, cuando proceda, con los órganos con competencias por razón de la materia en cada uno de los sectores incluidos en el ámbito de aplicación de esta ley, y colaborarán con ellos en el ejercicio de sus funciones.
 3. Cuando los incidentes notificados presenten caracteres de delito, las autoridades competentes y los CSIRT de referencia darán cuenta de ello, a través de la Oficina de Coordinación Cibernética del Ministerio del Interior, al Ministerio Fiscal a los efectos oportunos, trasladándole, al tiempo, cuanta información posean en relación a ello.

La inevitable, y bienvenida, propuesta de intercomunicación de los CSIRT con el sector privado (empresas proveedoras de servicios y centros de servicios de seguridad -SOC-) carece de una definición concreta: cómo serán estos puntos de contacto y colaboración entre CSIRT e industria, cómo se registrarán, documentarán y comunicarán estos incidentes, cómo se establecerán mecanismos automáticos de notificación, etc.
Todos estos detalles son relevantes en el caso de cualquier incidencia, pero revisten una importan crucial cuando los mismos deban formar parte de un procedimiento judicial. El modo en que se registren y envíen estas evidencias deberá ser establecido previamente para garantizar la seguridad jurídica de su incorporación a posibles procesos judiciales.

[Página 14]
Artículo 15. Obligaciones de seguridad de los operadores de servicios esenciales y de los proveedores de servicios digitales.
[…]
4. Los proveedores de servicios digitales determinarán las medidas de seguridad que aplicarán, teniendo en cuenta, como mínimo, los avances técnicos y los siguientes aspectos:
a) la seguridad de los sistemas e instalaciones;
b) la gestión de incidentes;
c) la gestión de la continuidad de las actividades;
d) la supervisión, auditorías y pruebas;
e) el cumplimiento de las normas internacionales.
Los proveedores de servicios digitales atenderán igualmente a los actos de ejecución por los que la Comisión europea detalle los elementos citados.

[Página 20]
Artículo 32. Supervisión de los operadores de servicios esenciales.
1. Las autoridades competentes podrán requerir a los operadores de servicios esenciales para que les proporcionen toda la información necesaria para evaluar la seguridad de las redes y sistemas de información, incluida la documentación sobre políticas de seguridad.
Podrán requerirles información sobre la aplicación efectiva de su política de seguridad, así como auditar o exigir al operador que someta la seguridad de sus redes y sistemas de información a una auditoría por una entidad externa, solvente e independiente.
1. A la vista de la información recabada, la autoridad competente podrá ordenar al operador que subsane los incumplimientos detectados e indicarle cómo debe hacerlo.

[Página 23]
Artículo 36. Infracciones
[…]
4. Son infracciones leves:
[…]
d) No someterse a una auditoría de seguridad o poner obstáculos a la realizada por la Administración, según lo ordenado por la autoridad competente.

En relación a las auditorias de seguridad informática, se advierte que el anteproyecto analizado no define con precisión el alcance, naturaleza y características de “auditoría de seguridad informática”, asimismo tampoco define los estándares bajo los cuales se deben realizar las mencionadas auditorias ni las cualificaciones de los auditores.
Este aspecto tan importante para la seguridad (las auditorías) queda, por tanto, sin una definición clara y a merced de interpretaciones laxas, intrusismo profesional y, en definitiva, prácticas contrarias al espíritu del anteproyecto.

[Página 22]
 Artículo 36. Infracciones.
 […]
 2. Son infracciones muy graves:
 […]
 3. Son infracciones graves:
 […]
 e) Proporcionar información falsa o engañosa al público sobre los estándares que cumple o las certificaciones de seguridad que mantiene en vigor.

Como ya se ha comentado, los estándares y certificaciones de seguridad adolecen de una gran dispersión y atomización. Además de la referencia al trabajo, ya comentado, del grupo de trabajo WG1 de la organización ECSO, se consideraría deseable que la futura ley recogiese las características básicas que los certificados de seguridad de los proveedores de servicio deben cumplir.
Sin ánimo excluyente, se propone que los certificados de seguridad a considerar cumplan al menos con las siguientes condiciones:
1. Disponer de una certificación expedida por una entidad acreditada independiente (como ocurre, por ejemplo, con el esquema nacional de seguridad -ENS-).
2. Disponer de un registro público de organizaciones certificadas donde se recoja el tipo de certificación otorgado, el nivel de la misma (si la correspondiente certificación se organiza por niveles) y la vigencia del certificado. Este registro debería ser mantenido por la entidad certificadora y ser accesible públicamente.

[Página 9 y siguiente]
 Artículo 9. Autoridades competentes.
 1. Son autoridades competentes en materia de seguridad de las redes y sistemas de información las siguientes:
 a) Para los operadores de servicios esenciales:
 1º) En el caso de que éstos sean, además, operadores críticos designados conforme a la Ley 8/2011, de 28 de abril, y su normativa de desarrollo: la Secretaría de Estado de Seguridad, del Ministerio del Interior, a través del Centro Nacional de Protección de Infraestructuras y Ciberseguridad (CNPIC).
 2º) En el caso de que no sean operadores críticos: la autoridad sectorial correspondiente por razón de la materia, según se determine reglamentariamente.

Artículo 41. Competencia sancionadora.
 1. La imposición de sanciones corresponderá, en el caso de infracciones muy graves, al Ministro competente en virtud de lo dispuesto en el artículo 9, y en el caso de infracciones graves y leves al órgano de la autoridad competente que se determine mediante el reglamento de desarrollo de esta ley.

En los artículos referidos, art 9 y art 41, se observa la ausencia de definición de autoridad competente sancionadora en el caso de los operadores de servicios esenciales no críticos. Según la redacción de ambos artículos, las autoridades competentes en estos casos serían “autoridades sectoriales” no explicitadas en el anteproyecto.
Se considera pertinente que tanto los operadores críticos como los operadores de servicios esenciales “no críticos” dispongan de una autoridad competente inequívoca claramente definida.