Source: https://elderecho.com/real-decreto-ley-12-2018-7-septiembre-seguridad-las-redes-sistemas-informacion-1a-parte
Timestamp: 2019-08-18 20:03:39+00:00

Document:
Sobre el Real Decreto ley 12/2018, de 7 de septiembre, de Seguridad de las Redes y Sistemas de Información (1ª parte) - El Derecho - Derecho Tic, Penal
Sobre el Real Decreto ley 12/2018, de 7 de septiembre, de Seguridad de las Redes y Sistemas de Información (1ª parte)
Conectarse a Internet sin ningún tipo de protección, provoca que la máquina quede comprometida con algún tipo de gusano, troyano u otra clase de malware.
Tribuna 18-09-2018 Madrid
A ningún lector, por poco ducho que esté en las Tecnologías de la Información y Comunicación (TIC), se le escapa que vivimos en un permanente estado de alerta por los continuos ataques a sistemas informáticos y las fugas masivas de datos de dichos sistemas. No obstante, desde su misma concepción, Internet se diseñó como una red de redes que no sólo no respetaba fronteras establecidas por el hombre, sino que estaba específicamente concebida para ignorarlas. Debemos, obligadamente, traer a colación el manifiesto conocido como “Declaración de independencia del ciberespacio”, presentada en Davos (Suiza) por John Perry Barlow, fundador de la Electronic Frontier Foundation (Fundación Fronteras Electrónicas), el 8 de febrero de 2016.
Tras ello, recuperemos del baúl de los pensadores desterrados por la moderna filosofía la obra “Leviatán, o La materia, forma y poder de una república eclesiástica y civil”, publicada por Thomas Hobbes en 1651. Al analizar las 19 Leyes de la Naturaleza, que prevalecen en caso de ausencia de ese Leviatán que contenga a los hombres, la primera debe ponernos claramente sobre aviso: “Cada hombre debe procurar la paz hasta donde tenga esperanza de lograrla, y, cuando no puede conseguirla, entonces puede buscar y usar todas las ventajas y ayudas de la guerra.”
Si la política internacional es la muestra palpable de esta norma, ante la ausencia de un Estado mundial al que todos acaten obediencia, la Internet que conocemos hoy es su forma más pura de cristalización: Bellum omnium contra omnes.
Esta institucionalización de la guerra de todos contra todos, como forma habitual de dirimir discordias en el ciberespacio se plasma en su consideración como “quinto escenario” por parte de la mayoría de los estudiosos de la estrategia militar y la geopolítica. Los tres primeros eran los tradicionales Tierra, Mar y Aire. El cuarto pasó a ser el Espacio Exterior. El quinto es Internet . De una forma mucho más doméstica, el lector puede comprobarlo accediendo a la configuración interna del router que le proporcione su compañía telefónica para acceder a la Red: en el apartado relativo a “Port Forwarding” (Apertura de Puertos, una técnica específica para mejorar el funcionamiento de aplicaciones como las redes de intercambio de archivos P2P), solemos encontrar un apartado llamado DMZ. ¿Que esconden esas siglas? Ni más ni menos que el acrónimo de Demilitarized Zone (Zona Desmilitarizada) . Es decir, estamos hablando de usar terminología bélica en el contexto de un electrodoméstico. Pero el término no es exagerado. Basta conectarse a Internet unos segundos desde un ordenador sin ningún tipo de protección, como antivirus, firewall u otros programas de seguridad, para que la máquina quede comprometida con algún tipo de gusano, troyano u otra clase de malware. Un ejemplo canónico fue el conocido como gusano “Sasser” (W32/Sasser-A, W32/Sasser.worm, Win32/Sasser.A, WORM_SASSER.A), difundido circa 2004, que reiniciaba un ordenador con Windows XP al poco de conectarse a Internet, a menos que el usuario activase el cortafuegos.
Habida cuenta de este entorno tan hostil que es la Internet abierta, se ha reaccionado en diversos foros y organizaciones internacionales, como es la Unión Europea, a través de su DIRECTIVA (UE) 2016/1148 DEL PARLAMENTO EUROPEO Y DEL CONSEJO de 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 (en adelante, Directiva NIS). Dicha directiva establecía un plazo de transposición de algo menos de dos años, debiendo estar las primeras obligaciones normativas cumplidas para el 9 de mayo.
Nuestro legislador, como desgraciadamente estamos acostumbrados a ver en materia de Derecho TIC, no hizo sus deberes, y no fue hasta el 7 de septiembre de 2018, con varios meses de retraso sobre el plazo máximo, que se publicó el Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información, que ahora nos ocupa (en adelante, RDL 12/2018).
Y la militarización de las TIC se hace todavía más presente al repasar su articulado. Simplemente, con lanzar una búsqueda sobre el texto, nos encontramos los siguientes resultados de coincidencias de palabras: “Justicia”, 0; “Fiscalía”, 0; “Juez”, 0; “Tribunales”, 0, y finalmente, “Ministerio Fiscal”, 1 único y solitario resultado, en el artículo 14, apartado 3º, junto con otra mención al artículo 259 de la LECrim, en el artículo 19, apartado 6º, a los que próximamente nos referiremos.
En cambio, las atribuciones de competencias que este Real Decreto realiza a organismos directamente vinculados a la jerarquía militar o policial son constantes. Concretamente, en el artículo 11, en el que se regulan los CSIRT (Computer Security Incidence Response Team, o Equipos de Respuesta a Incidentes de Seguridad Informática). Así, en materia de servicios esenciales relacionados con el sector público, el organismo encargado es el Centro Criptológico Nacional, CCN-CERT (Computer Emergency Response Team, Equipos de Respuesta a Emergencias Informáticas, una terminología más antigua y menos específica que la manejada ahora con el acrónimo CSIRT), que no es otra cosa que la rama informática del Centro Nacional de Inteligencia, dependiente del Ministerio de Defensa.
Cuando hablamos de operadores que tengan incidencia en la Defensa Nacional, el regulador ha sido bastante más directo, pues apela al ESPDEF-CERT, el equipo de emergencias informáticas del Ministerio de Defensa.
Si se trata de operadores críticos, el equipo de respuesta es el CNPIC (Centro Nacional de Protección de Infraestructuras y Ciberseguridad), dependiente de la Secretaría de Estado de Seguridad del Ministerio del Interior.
Al fin y al cabo, estamos hablando de colectivos altamente especializados en seguridad informática, con un equipamiento a la altura y formación constante. Algo que, en principio, no parece asunto de juristas.
Pero si nos fijamos en lo que la Directiva NIS denominaba “autoridades competentes” para recibir notificaciones de incidentes de seguridad de la información, el panorama se vuelve más turbio. Porque aquí ya estamos hablando de realizar una indiciaria calificación jurídica, en base a los criterios que contempla el RDL 12/2018: en cuanto a su ámbito de aplicación, en el artículo 2; en cuanto a las definiciones que contiene, en el artículo 3; en cuanto a la identificación de servicios esenciales y de operadores de servicios esenciales, en el artículo 6.
Este último apartado merece mención aparte. Si la Directiva NIS introducía una dicotomía entre servicios esenciales y servicios digitales sin más, aquí el Real Decreto-Ley riza el rizo para complicar las cosas hasta extremos absurdos. Por un lado, dentro de los servicios esenciales, tenemos que distinguir entre los que son esenciales, sin más (lo que parece un oxímoron), y los que además de ser esenciales, son operadores críticos. Es decir, vamos en una escalada de conceptos jurídicos indeterminados sólo comparable a la redacción del artículo 264 del Código Penal, que llega a utilizar seis veces la expresión “grave” en un mismo precepto, para diferenciar distintas variantes de una conducta, que pueden llegar a tener respuestas penales de diferente calado.
Esto parece una obligación impuesta para dar coherencia interna a un sistema jurídico que se completa con la Ley 8/2011, de 28 de abril, de Protección de Infraestructuras Críticas, pero no hace más que complicar la respuesta a una situación que exige decisiones inmediatas.
Pero la complicación no termina ahí, pues a efectos de autoridades competentes, tenemos que distinguir entre los operadores que están bajo el paraguas de la Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público, y todos los demás, o sea, la empresa privada. Para los primeros, la autoridad competente puede ser el CNPIC, si son operadores críticos, o la autoridad sectorial que se determine reglamentariamente, si no lo son (es decir, que podemos llegar a encontrarnos con una autoridad competente por Ministerio, si seguimos el esquema del Anexo I de la Ley 8/11).
Así lo afirma el apartado 1. letra a), inciso 1º del artículo 9 del RDL 12/2018. No obstante, la letra c) del mismo precepto parece contradecirse, pues para los operadores de servicios esenciales y proveedores de servicios digitales que no sean críticos (todavía no he llegado a entender cómo podría un proveedor de servicios ser crítico sin ser esencial), no espera al reglamento, sino que directamente designa como autoridad competente al CCN-CERT. Es decir, el mismo organismo subsidiario del CNI va a ser autoridad competente y equipo de respuesta. Yo me lo guiso, yo me lo como. El principio de autotutela administrativa ejecutiva llevado al paroxismo.
Si, siendo juristas, han tenido ustedes algún problema en digerir esta última página y media, imagínense en la situación de un administrador de sistemas informáticos (sea ingeniero informático, o de cualquier otra titulación técnica) que encuentra un problema potencialmente grave y debe reportarlo inmediatamente. Va a tardar considerablemente más tiempo en acudir a sus superiores, consultar con los servicios jurídicos de la empresa, si los tiene, o llamar al abogado, si no es así, y tomar la decisión correspondiente, que en solucionar el incidente.
Por poner un ejemplo de actualidad. Pongamos que, durante la construcción de las famosas corbetas (en realidad, BAM, o Buques de Acción Maritima) que Navantia debe entregar a Arabia Saudí, aparece un incidente de ciberseguridad en la conexión de los sistemas informáticos de las citadas embarcaciones. Navantia es una empresa, NAVANTIA, S.A., entidad inscrita en el Registro Mercantil de Madrid, al Tomo 20.348, folio 40, sección 8ª, hoja M-359.813, inscripción 1ª., por lo que debería considerarse comprendida en el sector privado, pero a pesar de que gira en el tráfico mercantil con tal denominación, en realidad es una empresa pública. Esta denominación no aclara mucho. ¿Es una sociedad mercantil estatal de las previstas en el artículo 111 de la Ley 40/2015?
Bien, aceptemos que se trata de una entidad comprendida en el Sector Público. ¿Es un servicio esencial? Si preguntamos a los ciudadanos de Cádiz, donde se encuentran sus astilleros, nos contestarán que sin duda es una empresa necesaria para el mantenimiento de las funciones sociales básicas, la salud, la seguridad, el bienestar social y económico de los ciudadanos, como dice el artículo 3, apartado c). ¿Pero es un operador crítico? En fin, una empresa cuyo producto es un mastodonte de acero de 94 metros de eslora y 2500 toneladas, equipado con un cañón OTO Melara de 76mm/62, dos cañones M242 Bushmaster de 25 mm y dos ametralladoras FN-Herstal del calibre 50 (12’5 mm), todo ello dirigido por un sistema de tiro computerizado… Llámenme exagerado, pero me parece BASTANTE crítico. ¿Afecta a la Defensa Nacional? Podríamos decir que sobran los comentarios, pero, en realidad, esos barcos van a ser vendidos a un país extranjero.
Así pues, detectado el riesgo para la seguridad de sus sistemas informáticos conectados en red, ¿a qué autoridad competente debe reportar el Administrador de Sistemas de Navantia? Dejemos esa cuestión en el aire. O mejor, en el mar, valga el juego de palabras.
Como hemos visto, los operadores de servicios digitales, esenciales o no, críticos o no, van a tener que contemplar la figura del abogado de guardia, integrando sus equipos de ciberseguridad.
Pero no es sólo este batiburrillo incomprensible, aderezado con un pastiche de normas anteriores, el que me preocupa. Hemos hablado de militarización y autotutela administrativa. Y es que, la autoridad competente para el reporte de riesgos e incidentes de seguridad de la información, en caso de entes privados que no sean operadores esenciales ni críticos, es la Secretaría de Estado para el Avance Digital, del Ministerio de Economía y Empresa. Parece que todos los organismos de la Administración están invitados a este festival regulatorio, salvo la Administración de Justicia, en su vertiente Penal.
¿Y qué relevancia tiene esto? Muy sencillo y muy contundente. En cuanto a los riesgos para un sistema informático, vamos a considerarlos una mera oportunidad para el criminal. Pero volviendo a las definiciones del artículo 3, apartado b): “Seguridad de las redes y sistemas de información: la capacidad de las redes y sistemas de información de resistir, con un nivel determinado de fiabilidad, toda acción que comprometa la disponibilidad, autenticidad, integridad o confidencialidad de los datos almacenados, transmitidos o tratados, o los servicios correspondientes ofrecidos por tales redes y sistemas de información o accesibles a través de ellos.”
Salvo en tiempos de guerra, esa definición estaba prevista mucho antes de la Ley 40/2015, y del Real Decreto-Ley 12/2018. Estaba en el Convenio para Prevención del Cibercrimen dado en Budapest el 23 de noviembre de 2001. Hace 17 años. Y tras la ratificación por el Reino de España, dio lugar a la modificación del Código Penal introducida por Ley Orgánica 1/2015, de 30 de abril. Esa reforma introdujo los actuales artículos 197 bis a quinquies, así como 264 y siguientes hasta el quater, que castigan los delitos de acceso ilícito y daños contra sistemas informáticos.
Delitos informáticos de los que debería conocer inmediatamente la Fiscalía de Sala de Criminalidad Informática, a fin de impetrar las acciones judiciales oportunas. Pero, como ya hemos dicho, la Justicia no está invitada a la fiesta. Eso sí, sanciones administrativas no faltan para el caso de incumplimiento del deber de reportar las vulnerabilidades detectadas, prevista en el Título V del RDL 12/2018, artículos 19 a 31. Multas por valor de hasta un millón de euros, aunque son ridículas frente a las que contempla la posibilidad de infracción del Reglamento General de Protección de Datos, que son de hasta 4 millones de euros, o el 4% de la facturación anual de la empresa, tratándose siempre de la cantidad más elevada.
Bueno, pues el artículo 19, el arco de bóveda de todo el título, habla de los incidentes que pudieran comportar un riesgo. Y es que, habitualmente, no estamos en presencia de un ataque directo que comporte la vulneración de medidas de seguridad, como exige el artículo 197 bis. Simplemente, nos encontramos con errores en el código informático, producto de la fragmentación de su proceso de programación, de fechas de entrega, prisas y la imposibilidad de prever todo error posible. Así pues, muchos de los denominados “incidentes” no son más que boquetes de seguridad del tamaño de un edificio de diez plantas, que cualquiera puede aprovechar para obtener un acceso al sistema informático sin necesidad de vulnerar medidas de seguridad. ¿Nos encontramos, en este caso, ante un delito? Si alguien hace uso de esta vulnerabilidad para acceder a un sistema informático que contiene datos personales, estaríamos en presencia de un delito del artículo 197, que lleva en vigor desde 1995, aunque lo cierto es que la Jurisprudencia de la Sala 2ª del Tribunal Supremo que ha depurado el concepto de datos personales ha sido bastante más tardía.
No obstante, si alguien percibe esta vulnerabilidad, pero no hace uso de ella para acceder al sistema informático, o si lo hace para comprobar su viabilidad, y no se lleva ningún tipo de datos personales, en principio no concurrirían los requisitos del tipo. No se darían los del 197 CP al no haber apoderamiento de datos, ni los del 197 bis CP, al no vulnerarse medida de seguridad, pues el sistema no tiene la capacidad de resistir una acción que comprometa la disponibilidad, autenticidad, integridad o confidencialidad de los datos almacenados, transmitidos o tratados, o los servicios correspondientes ofrecidos por tales redes y sistemas de información o accesibles a través de ellos, por usar la terminología del propio RDL.
Expliquémoslo con un ejemplo bien reciente: la vulnerabilidad reportada por FACUA, la asociación de consumidores, en la página web de Movistar - Telefónica (http://www.europapress.es/economia/noticia-telefonica-corrige-vulnerabilidad-permitia-acceso-factura-clientes-movistar-aleatorios-20180716121712.html). El problema, según se supo después, era muy similar al sufrido en su día por el sistema de comunicaciones judiciales LexNET: una actualización de la página web había eliminado la barrera de contención que solicita nueva autenticación cuando un usuario registrado intenta cambiar el identificador de usuario de la URL (Uniform Resource Locator - Localizador Uniforme de Recursos, acrónimo de las direcciones de las páginas web que todos conocemos). Así pues, cualquier usuario legítimo previamente autenticado en el sistema podría, mediante un simple “corta y pega” de identificador, cuchichear en los datos confidenciales de cualquier otro usuario, fuera Agamenón o su porquero.
Evidentemente, sería un activo sumamente interesante para la ciberseguridad, tanto del sector público como del privado, que estas vulnerabilidades descubiertas por expertos freelance del mundo de la investigación en seguridad de la información fueran reportadas a los titulares de los sistemas concernidos.
Por desgracia, y a diferencia de países más concienciados, donde las empresas privadas tienen programas de bug bounties (literalmente, “botín por el bicho”, siendo bicho el término de jerga con la que se denomina al fallo de un sistema informático) con los que se recompensan estos reportes, o donde las propias instituciones (como el Departamento de Defensa de los EE.UU.) fomentan esta conducta altruista, no estamos en el mismo escenario. En España, por miedo a perjuicios reputacionales que afecten a la empresa, o que comprometan la imagen del político responsable de turno, la solución patria pasa por “matar al mensajero”.
Como ya hemos dicho, en teoría no cabría la aplicación de ninguno de los tipos penales involucrados, si el hacker ha respetado la ética del movimiento, que suele plasmarse en realizar un responsable disclosure (revelación responsable, advertencia en privado al afectado, para que tenga tiempo de corregir el problema). No obstante, el Derecho Penal es algo voluble, y depende la interpretación de gentes que, muchas veces, no terminan de comprender la realidad subyacente a las metáforas visuales que ellos ven en pantalla. Así pues, el riesgo del ejercicio de acciones penales contra el hacker ético sobrevuela siempre, cual espada de Damocles, sobre la cabeza de quien pretenda llevar a cabo esta altruista e indispensable labor.
3 Para ampliar información, se recomienda la lectura de “En el principio, fue la línea de comandos”, ensayo de Neal Stephenson, Editorial: TRAFICANTES DE SUEÑOS, ISBN: 9788493298227, Editado en Madrid en 2003, con traducción de ASUNCION ALVAREZ

References: Real Decreto 
 Real Decreto 
 artículo 14
 artículo 259
 artículo 19
 Real Decreto 
 artículo 11
 artículo 2
 artículo 3
 artículo 6
 artículo 264
 artículo 9
 artículo 111
 artículo 3
 artículo 3
 artículo 19
 artículo 197
 artículo 197