Sobre la humedad y el papel: análisis (crítico) de los artículos 15 y 18 del Esquema Nacional de Seguridad

Como se puede observar de los artículos de este blog, no soy precisamente un entusiasta del marco normativo que nos toca sufrir en temas TIC en la Administración Local. No es que no me parezcan bien ciertas Leyes o normas, muchas muy lógicas y loables, sino que centro mis reticencias en su aplicabilidad real en el entorno general actual. Quede claro que no voy a discutir temas legales, sino las cuestiones prácticas que se desprenden de la interpretación de las normas.
En esa ocasión, motivado por una conversación que tuve el otro día con una experta consultora en estos temas y algunos compañeros, al respecto del artículo 15, y sobretodo, del artículo 18 del Esquema Nacional de Seguridad. Parece lógico comenzar este análisis reproduciendo cómo quedan los artículos a los que aludiré tras la aprobación del Real Decreto 951/2015, de 23 de octubre, por el que se modificaba el RD 3/2010, de 8 de enero.

Artículo 15. Profesionalidad.

1. La seguridad de los sistemas estará atendida, revisada y auditada por personal cualificado, dedicado e instruido en todas las fases de su ciclo de vida: instalación, mantenimiento, gestión de incidencias y desmantelamiento.

2. El personal de las Administraciones públicas recibirá la formación específica necesaria para garantizar la seguridad de las tecnologías de la información aplicables a los sistemas y servicios de la Administración.

3. Las Administraciones públicas exigirán, de manera objetiva y no discriminatoria, que las organizaciones que les presten servicios de seguridad cuenten con profesionales cualificados y con unos niveles idóneos de gestión y madurez en los servicios prestados.
[...]
Artículo 18. Adquisición de productos de seguridad y contratación de servicios de seguridad.

1. En la adquisición de productos de seguridad de las tecnologías de la información y comunicaciones que vayan a ser empleados por las Administraciones públicas se utilizarán, de forma proporcionada a la categoría del sistema y nivel de seguridad determinados, aquellos que tengan certificada la funcionalidad de seguridad relacionada con el objeto de su adquisición, salvo en aquellos casos en que las exigencias de proporcionalidad en cuanto a los riesgos asumidos no lo justifiquen a juicio del responsable de Seguridad.

2. La certificación indicada en el apartado anterior deberá estar de acuerdo con las normas y estándares de mayor reconocimiento internacional, en el ámbito de la seguridad funcional.

3. El Organismo de Certificación del Esquema Nacional de Evaluación y Certificación de Seguridad de las Tecnologías de la Información, constituido al amparo de lo dispuesto en el artículo 2.2.c) del Real Decreto 421/2004, de 12 de marzo, y regulado por la orden PRE/2740/2007, de 19 de septiembre, dentro de sus competencias, determinará el criterio a cumplir en función del uso previsto del producto a que se refiera, en relación con el nivel de evaluación, otras certificaciones de seguridad adicionales que se requieran normativamente, así como, excepcionalmente, en los casos en que no existan productos certificados. El proceso indicado, se efectuará teniendo en cuenta los criterios y metodologías de evaluación, determinados por las normas internacionales que recoge la orden ministerial citada.

4. Para la contratación de servicios de seguridad se estará a lo dispuesto en los apartados anteriores y en el artículo 15.

Pues bien, comencemos la disección. Al artículo 15 le encuentro las siguientes 'debilidades':

1. Sobre la 'cualificación' del personal que debe atender a la seguridad de los sistemas: si bien es cierto que el CCN organiza desde hace años los cursos STIC para formar al personal de las AAPP en el despliegue y gestión de infraestructuras y programas de forma segura, así como en la propia gestión de la seguridad de la información. ésta es una formación a todas luces insuficiente, por dos motivos: su fase presencial se realiza sólo en Madrid, y el número de plazas anuales es muy reducido. Por tanto, esta formación llega a pocos afortunados. Existen otras opciones, como la cualificación en base a certificaciones 'privadas', tales como másteres en ciberseguridad o certificaciones internacionales como las de oganizaciones como ISACA, por ejemplo, pero cuyos costes son elevados para que una gran parte de las AALL consideren gastarse ese dinero en su personal TIC (si lo tienen). Y obviamente, aún es más complicado que sea el propio personal TIC quien asuma esos costes de formación y certificación. Por tanto, pese al voluntarismo, la cuestión de la cualificación profesional del personal al servicio de la mayoría de AAPP, sobretodo en las AALL, es PAPEL MOJADO.
2. Respecto de las organizaciones que prestan servicios de seguridad, ocurre algo radicalmente diferente: las empresas proveedoras de estos servicios sí exigen a sus empleados disponer de determinadas certificaciones o conocimientos con caracter previo a su contratación, o reciclan a personal preexistente para obtenerlas, de cara a poder presentar un elenco de profesionales adecuado para optar a los contratos que surjan de las AAPP o del sector empresarial. Pero el ENS se queda corto al no fijar cuáles de esas certificaciones o titulaciones son las que se consideran adecuadas para garantizar que un profesional es adecuado y que el servicio que se va a prestar tiene el nivel de madurez pertinente. Posiblemente se deja al libre albedrío de cada Administración el exigir determinadas certificaciones a las empresas licitantes (de las ISO series 14000 y 27000, por ejemplo) y/o a los profesionales que van a ejecutar de forma efectiva el servicio (ISACA CISA, CISM o CISS, por ejemplo). Pero ello exige que la AAPP conozca qué le aporta cada una de estas certificaciones, lo cual tampoco es demasiado habitual. Por tanto, esta cuestión del ENS es PAPEL CERCANO A MOJARSE.

Analicemos ahora el artículo 18, que se presenta mucho más chispeante al meterse de lleno en el tema de la certificación de sistemas, ya que para los servicios se remite al artículo 15:

1. Este artículo es claramente un brindis al Sol. Con buenas intenciones, con referencias a estándares o normas internacionales reconocidas (como los Common Criteria), pero que no puede ser aplicado. En un entorno estático se puede pensar en certificar sistemas, porque van a durar muchos años. Por ejemplo, en entornos industriales o críticos conviene que los sistemas se certifiquen. Se pueden certificar servicios de emisión de certificados digitales, o software embebido en sistemas militares. Pero, ¿qué ocurre realmente en el mercado tecnológico habitual, al que no son ajenas las AAPP? Pues que va a toda velocidad. No me voy a referir al software. Pero ¿el hardware no se actualiza? Si. Pero la certificación se habrá obtenido por un hardware para una versión de firmware (o se sistema operativo) concreta, por lo que tras cada revisión de éste habría que recertificar. ¿Y eso quien lo asume? Nadie. Por tanto, la certificación de sistemas, por este motivo es PAPEL MOJADO. Puede consultarse una lista actualizada de productos certificados según los Common Criteria en este enlace.
2. Suponiendo que no hubiera que recertificar tras cada actualización (lo cual no tendría sentido), la lista oficial de sistemas certificados llevaría un retraso considerable respecto al mercado, por lo que las AAPP estarían adquiriendo productos prácticamente obsoletos, ya que al retraso por la certificación habría que añadirle el retraso por el proceso de contratación pública. Por este motivo, también es PAPEL MOJADO.
3. La obligatoriedad de adquirir sistemas certificados queda supeditada a la "proporcionalidad en cuanto a los riesgos asumidos", a juicio del Responsable de Seguridad. Obviamente, había que dejar una escapatoria a las AAPP para poder funcionar. Ello simplemente resulta en que hay que justificar que, o bien no hay equipos certificados que tengan las funcionalidades que se requieren en la AAPP concreta, o bien el Responsable de Seguridad informa de que no hace falta que lo estén. Ya sabemos que el papel es muy sufrido. Y en este caso, además, es PAPEL MOJADO.
4. La certificación de productos sólo pueden realizarla empresas de tamaño considerable, por motivos económicos. Ello deja fuera de esa posibilidad, por ejemplo, a proyectos de software libre, en general, algunos tan importantes como OSSIM en temas de seguridad informática. ¿Restricción de la competencia? ESTE PAPEL LO MOJO YO.

En resumen, nos encontramos ante dos artículos de un Real Decreto que son (casi) imposibles de aplicar, y que el legislador podría directamente habérselos ahorrado. Abundaré en la percepción general de que este RD se creó pensando en la AGE y en las CCAA, no en las AALL que son la mayoría.
En mi modesta opinión, lo único aprovechable de ambos son los puntos 1 y 2 del artículo 15, si no fuera porque con el apartado 3 tiene un tufillo privatizador importante, ya que continuamos sin poder contratar personal ampliando plantilla en las AALL.
Es obvio que hace falta un PLAN MASIVO DE FORMACIÓN en temas de seguridad para el personal TIC de las AAPP españolas. Por ejemplo, con ediciones de los cursos STIC en todas las provincias, con varias ediciones anuales proporcionalmente al número de empleados públicos TIC de cada una de ellas. O con subvenciones para que las AALL formen a esos empleados en la materia a través de centros de formación previamente certificados para ello.
Porque si no, el ENS responde al conocido dicho de 'Mucho ruido y pocas nueces', y los derechos de los ciudadanos y las actuaciones de las AAPP corren peligro si la seguridad de la información en el ámbito de la Administración (Electrónica, hubiéramos dicho antes de las Leyes 39/2015 y 40/2015) no tiene el nivel adecuado.
Lo dicho: PAPEL MOJADO.