Buenos días a todas y a todos.
Hoy vamos a dar a impartir el taller que originalmente estaba previsto
para el mes de noviembre y que tuvo que ser pospuesto.
El ponente es don Fidel Paniagua, que trabaja desde el año 2016
en el laboratorio de evaluación de la empresa Clover Technologies
y pasó a ser su responsable técnico en el año 2020.
La charla se titula El catálogo de productos del CCN.
¿Qué es?
¿Cómo acceder?
¿Y para qué sirve?
Muchas gracias, Fidel, por tu participación.
Y nada, todo tuyo.
Vale, muchas gracias, Agustín.
Hola, buenos días a todos.
Como os comenta Agustín, vamos a ver una charla
sobre el catálogo de productos del CCN, concretamente,
la guía CCNStick 105.
Antes que nada, agradecer a UNED, a Rafa y a Agustín
la confianza y, pues, un poco el traer un tema que es
un poco diferente quizás a otros que se hayan podido exponer,
pero que espero saber transmitiros a lo largo de la presentación.
Pues la importancia que tiene
que los productos que utilicemos en nuestros sistemas de información
sean productos que han sido certificados.
Hay un tercero que ha validado que la seguridad de ese producto
es la adecuada para el sistema de información
en el que se está utilizando.
Este es un poco el índice.
Empezaré contándoos un poco por qué estoy aquí,
aunque ya lo ha introducido Agustín,
pero para que entendáis de dónde viene un poco
esa parte de mi experiencia, porque contaros esto.
Y luego iremos desgranando un poco qué es el catálogo,
cómo se revisan esos productos que acceden al catálogo.
Y posteriormente veremos al final cómo es cómo es esos productos
que están en el catálogo pues tienen su relación
con el esquema nacional de seguridad que tuvisteis ya
una charla en la que sin duda os presentaron
pues todo lo que es el esquema lo que supone el esquema
y acabaremosos haré una pequeña pincelada
de cómo está evolucionando no al final es un área no.
Que está evolucionando mucho el tema de las certificaciones
de ciberseguridad.
Entonces, veremos el esquema europeo de certificación.
Os haré una pequeña introducción muy concreta, muy específica,
hacia dónde vamos.
Para empezar, un poco para que entendáis por qué estoy aquí,
¿qué es Clover Technologies?
Al final es una pyme de ciberseguridad.
Y tiene diferentes áreas.
Como veis, en esa segunda área, primera y segunda área,
es donde estaría más relacionado la actividad que desarrollamos
con la charla de hoy, que es la certificación,
al final la evaluación.
Nosotros participamos en la evaluación de productos
de seguridad a través de.
Pues común criteria y lince somos un laboratorio acreditado
por ccn y enac para realizar esas evaluaciones de seguridad
como veis aquí pues lo que os decía
no somos un laboratorio acreditado por el centro criptológico nacional
y por enac ya pasando a lo que es propiamente
la presentación que es el catálogo no al final el catálogo.
Que os podáis encontrar, no es más que un listado de productos,
pero en este caso son productos de seguridad,
productos orientados a la protección de los sistemas de información.
Y dentro de ese catálogo
vamos a tener tres categorías de productos.
Tenemos los productos cualificados, que son productos
orientados al esquema nacional de seguridad.
Dentro del esquema nacional de seguridad,
como os presentaban en la charla anterior.
Tenemos tres niveles, no el básico, el medio y el alto,
no?
Pues para esos niveles,
pues en función de las pruebas del nivel de aseguramiento
que se haya obtenido
durante la certificación del producto,
pues estará orientado a un nivel u otro.
Evidentemente no son los mismos requisitos para un nivel,
que para otro luego tenemos la categoría de productos
aprobados en este caso los productos aprobados lo que tenemos
es que pues habíamos visto el esquema nacional de seguridad los productos
aprobados están orientados a sistemas clasificados
donde los requisitos pues al final.
También son diferentes y también tenemos
diferentes niveles, ¿no?
Empezamos desde difusión limitada hasta llegar a secreto,
pasando al final por confidencial o reservado, ¿no?
Entonces, en función del nivel en el que estemos,
pues los requisitos van a ser unos u otros.
Entonces, no va a ser lo mismo los requisitos
para entrar con un producto cualificado a nivel de ese medio,
que para ser un producto aprobado, por ejemplo,
para esa categoría de difusión limitada.
Y luego tenemos,
independientemente un poco del sistema,
una categoría que engloba no tanto lo que son productos,
sino al final soluciones para la gobernanza de la seguridad,
que nos ayudan al final a gestionar los sistemas de información.
Pues ahí se vio que.
El CCN, el CPSTIC,
concretamente el departamento que gestiona el catálogo,
diseñó esta categoría
para dar respuesta un poco a productos que no ofrecen directamente
una funcionalidad de seguridad en el sistema de información,
pero sí que nos sirven para gestionar esa seguridad.
Y también es importante que esos productos,
antes de ser desplegados, de ser utilizados,
pues que hayan sido.
Revisado, se haya hecho al final,
pues al menos una evaluación de seguridad
sobre los mismos para ver que no tienen vulnerabilidades,
que ofrecen las funciones de seguridad mínimas
requeridas en función de la familia en la que estemos.
Y al final, pues pensaréis, ¿no?
Como pasa cuando abrimos cualquier catálogo, ¿no?
Tenemos.
Pues muchas secciones, ¿no?
Al final productos hay de muchos tipos, por ejemplo,
si vemos el catálogo de un supermercado, ¿no?
Pues vemos al final que tenemos como muchas secciones en función
de los tipos de productos, ¿no?
Pues lo mismo ocurre en el catálogo de productos
Stix, Stix, que la guía CCN Stix 105,
que luego la veremos rápidamente, está accesible en live.
Entonces, para categorizar eso,
el CCN ha definido una serie de taxonomías que serían categorías
más generales y luego dentro de esas categorías generales,
una serie de familias.
Al final, las familias lo que agrupan es productos
cuyos requisitos de seguridad.
Son los mismos entre ellos los requisitos de seguridad
que al final se establecen para ese tipo de productos.
Entonces, cada producto que está en el catálogo
sabemos que ha sido validada, ha sido certificada cierta funcionalidad
de seguridad, ¿no?
En base a esos requisitos fundamentales
de seguridad que se han definido para esa familia.
Por resumirnos un poco,
antes de entrar a detallar un poco todo este proceso,
que veamos un poquito paso a paso qué es ese concepto de familia,
desarrollar ese concepto de familia, ese concepto de requisito fundamental
de seguridad.
¿Cuáles son las entidades?
Por supuesto, hay una entidad pública,
como es el Centro Criptológico Nacional,
que se encarga a través del CCN PITEC,
del CPSTIC concretamente, de la gestión de ese catálogo,
de determinar cuáles son las reglas para atender a cada
una de las categorías que veíamos antes de los diferentes productos
y cuáles son esos requisitos de seguridad que deben de cumplir.
Para poder estar en el catálogo,
esos productos tienen que haber sido certificados,
tienen que haber sido.
Evaluados por un laboratorio y luego certificados.
Esa parte de certificación,
de validar el trabajo realizado por el laboratorio,
se hace también por otro departamento del CCN,
como es el organismo de certificación.
Luego, para lo que es más el trabajo técnico que nosotros desarrollamos,
que al final es esa evaluación del producto, es decir,
verificar que el producto cumple con esos requisitos de seguridad,
que no tiene vulnerabilidades,
pues lo desarrollan los laboratorios de evaluación,
como es Clover Technologies.
Por supuesto, está el fabricante,
que al final es el que desarrolla el producto
y al final el que tiene ese interés
de que ese producto esté en el catálogo
para poder trabajar con la administración.
Y también hay un cierto papel de consultor,
porque como vamos a ver, al final.
Todo lo que tiene que ver con esa certificación
del producto para poder estar en el catálogo tiene al final
una documentación, tiene un desarrollo,
una serie de requerimientos muy específicos del área.
¿Qué quiere decir eso?
Pues que al final esos requerimientos
no todas las empresas pueden tener al final una persona experta
que los desarrolle y a través de nosotros también.
Y otros laboratorios,
podemos dar ese apoyo en el que ayudemos a las empresas
a generar al final toda esa documentación necesaria
para poder abordar el proceso.
Y ahora ya vamos a ir a desarrollar un poco
cómo nosotros realizamos ese trabajo.
Lo realizamos basado en dos metodologías.
Una, sin duda, a nivel internacional,
como es común criterio, que es una metodología para el desarrollo,
para la certificación de productos de seguridad.
Esta metodología, común criterio,
lo que define al final son las acciones
que debe llevar a cabo el evaluador y cuáles son las evidencias que tiene
que entregar el evaluador.
El fabricante para poder desarrollar esa evaluación.
Entonces, nos establece qué elementos vamos a tener de entrada
para desarrollar la evaluación y define una serie de niveles
de aseguramiento que van desde el 1 hasta el 7,
evidentemente siendo el 1 más bajo, 7 el más alto,
en el que se van determinando cuáles son aquellos aspectos
de seguridad que debe cumplir el producto
y cómo el evaluador los debe de validar.
Y no solamente en la parte que sería más técnica, por así decirlo,
como puede ser la parte funcional o la parte de vulnerabilidades,
sino también, por ejemplo,
en el ciclo de desarrollo de vida del producto, ¿no?
Al final, cómo se ha llevado a cabo ese desarrollo,
cómo se controlan las versiones, ¿no?
Al final, una cuestión importante
cuando estamos certificando un producto es determinar, ¿no?
Qué producto hemos certificado, es decir,
si validamos, evaluamos un producto en una determinada versión
y luego el fabricante hace cambios,
potencialmente en esos cambios pueden haberse introducido
errores o que no se dé cumplimiento a los requisitos establecidos,
con lo cual habrá que validarlo.
Entonces, es más amplio,
la parte técnica evidentemente es muy importante,
pero.
Nos añade unas componentes en función del nivel en el que estemos,
en el que se valida todo lo que tiene que ver con el desarrollo
del producto, con cómo se presenta al final la documentación
o cómo se presentan las funcionalidades de seguridad
de ese producto.
Como os decía, tiene reconocimiento a nivel internacional.
El CCRA está formado por los países que veis ahí en la imagen.
Luego, a nivel europeo, para algunos dominios técnicos,
pues tenemos SOGIS,
pero como os decía, al final hablaremos un poquito de la evolución
de la certificación de productos de seguridad a nivel europeo
y cómo están surgiendo diferentes esquemas de certificación.
Y para la parte de certificación de productos, pues cómo esta entidad
SOGIS va evolucionando a ese esquema europeo de certificación.
Como veis, os he nombrado muchas cosas, ¿no?
Eso hace que al final
la certificación de un producto mediante común criterio,
pues sea un proceso largo, ¿no?
Al final un proceso que requiere de tiempo,
no solamente en el proceso de evaluación,
sino también en la aplicación, ¿no?
Para desarrollar ese proceso, ¿no?
Entonces, desde el CPN, ¿no?
Otros homólogos a nivel europeo, como Alemania o Francia,
pues desarrolló la metodología Junzenot a finales
de la década pasada, que es una metodología que está basada
en común criterio,
pero que se centra mucho en la parte técnica,
es decir, esa parte que os decía del ciclo de vida,
de desarrollo del producto, de análisis más documental.
Se reduce mucho y se añade el foco en la revisión técnica del producto.
Evidentemente, el nivel de garantía que vamos a ofrecer
si nosotros reducimos las actividades de evaluación,
pues es menor, pero como os decía, como vamos a verlo en función
del nivel al que vayamos del esquema nacional de seguridad,
pues nos podrá valer o no nos podrá valer
y eso es lo que determina esa guía CCNESCIC-106.
Que establece los requerimientos para entrar en el catálogo
en una familia u otra.
¿Cuál es el propósito del IRCE?
Pues productos para ese nivel,
hasta ese nivel medio del esquema nacional de seguridad.
Es verdad que hay algunas excepciones para algunas familias
en las que no se puede realizar a través de común criterio y bueno,
Ahí tampoco vamos a entrar al nivel de detalle concreto,
pero bueno, sí comentároslo para que lo sepáis.
Y lo que se establece para esta metodología
es que el tiempo de evaluación está determinado por la propia metodología
y se le dice al laboratorio las jornadas que tiene que dedicar
para cada una de las fases de la evaluación,
tanto para la revisión de documentación,
como para la parte funcional,
como para la parte de vulnerabilidades.
Como veis ahí, son 25 jornadas.
Y luego hay una serie de módulos adicionales
si hay que revisar cuestiones específicas
por las que se añaden 5 jornadas.
Tenemos 3 módulos a día de hoy, como es el del criptológico,
el de código fuente y el de biométrico,
para productos de biometría.
Entonces, pues si.
Al final, un producto requiere alguno de esos módulos,
pues se pueden extender en ese número de jornadas.
Pero como veis, a diferencia de como en Clindelia,
en donde no hay un tiempo determinado,
sino que en función del desarrollo de las actividades,
podrá requerirnos un poco más o menos, aquí está todo determinado.
Es fijo, ¿no?
Evidentemente, para poder cumplir esto,
este alcance concreto, tenemos que saber que las funciones
de seguridad que nos va a estar solicitando ese producto
se pueden evaluar dentro de este tiempo
y eso es algo que se analiza cuando un producto
va a entrar en el catálogo.
Y ahora sí que ya vamos a ir a ese proceso,
a ver un poco ese proceso de.
Entrada de un producto en el catálogo
y cuáles son las actividades que nosotros realizamos
bien a través de consultoría o bien a través de la evaluación
del producto a lo largo de todo el proceso
para que un producto que no ha sido certificado o bien,
como vamos a ver, que puede haber sido certificado,
pero que acabe entrando en el catálogo.
Al final, Es el proceso de entrada en el catálogo,
todo lo que vamos a ver aquí, estas diferentes fases,
se conoce como cualificación del producto.
Y dentro de esa cualificación tenemos la parte de certificación
del producto con la evaluación del mismo, que es el punto 3.
Entonces, primeramente, cuando un fabricante quiere
que su producto esté en el catálogo,
pues tiene que acometer la fase de solicitud, ¿no?
Que es esa fase en la que el fabricante le indica a Tepestí,
oye, tengo interés de que mi producto esté en el catálogo y de esta manera
cumplo los requisitos para la familia en la que quiero acceder.
Entonces, la primera pregunta para introducir un producto
en el catálogo es ¿en qué familia quiero introducirlo?
¿A qué familia?
¿De qué familia da respuesta mi producto?
¿A qué familia da respuesta las funcionalidades de mi producto?
Y en función de eso, desarrollar al final cómo mi producto da respuesta
a los requisitos de seguridad que están en esa familia.
Aquí tenemos.
Como esas diferentes categorías, ¿no?
Y luego cada una de estas categorías se dividen en familias.
Y sí que del inicio, ¿no?
De cuando empezó el catálogo a hoy en día,
pues se han ido añadiendo muchas categorías, ¿no?
Por ejemplo, la de servicios cloud que veis abajo,
la de seguridad OT.
La categoría que os decía, ¿no?
Bueno, categoría.
Esa parte de productos orientados hacia la gobernanza.
Al final, el catálogo, desde el personal de CPSIC,
es algo vivo, ¿no?
Es decir,
si viene un fabricante que tiene un producto que da respuesta
a una funcionalidad concreta que podemos categorizar,
pues se analiza y si hay que añadir una nueva familia.
Pues se añade.
Entonces, teniendo siempre esa perspectiva que tienen
que ser productos que o bien ofrezcan funciones de seguridad
o estén orientados a la parte de ciberseguridad,
pero al final es algo vivo,
algo que ha ido evolucionando con el tiempo,
no es algo estático de ahí estas familias con estas categorías
y estos requisitos,
sino que es algo que va evolucionando.
Y una parte importante de esa evolución
es los servicios cloud.
¿Por qué?
Porque, como os decía antes, tenemos dos metodologías, ¿no?
Pero esas metodologías, uno de los requerimientos
es que el producto se tiene que desplegar
en las instalaciones del laboratorio, ¿no?
Para poder ser evaluado.
Pues evidentemente cuando estamos ante un servicio cloud,
pues eso no es posible, ¿no?
Entonces, desde.
Catálogo y a través de la guía CCN-106,
pues ellos han ido evolucionando ese,
añadiendo ciertos procedimientos, ¿no?
, basados en las metodologías, pero con ciertas,
eliminando ciertas restricciones que permitan dar cabida,
pues, a estos nuevos tipos de servicios, ¿no?
, adaptándose, pues, a la casuística de cada uno de ellos.
Os he hablado de los requisitos de seguridad muchas veces,
pero ¿qué es un RFS?
¿Qué es lo que va a tener que cumplir el producto
y cómo se define eso?
Entonces, aquí os traigo un pequeño ejemplo
para un producto muy común, muy utilizado,
como puede ser un enrutador.
Y. Como veis, a nivel general, esto sería lo que tendríamos
en la familia de enrutadores.
El producto tiene que cumplir una serie de restricciones.
Y como veis ahí, se hace referencia a un documento concreto,
como es un Protection Profile, que ahora vamos a ver allí
que los requisitos ya están más a bajo nivel.
O al final.
El nivel de aseguramiento que tenemos que cumplir, que os decía, ¿no?
En función de la metodología con criterio,
pues tenemos diferentes niveles de aseguramiento, ¿no?
Pues aquí nos dice que el nivel tiene que ser el 2, ¿no?
Y que si las funciones criptográficas, ¿no?
Que del producto, los algoritmos que utilice.
Criptográficos, las longitudes de clave,
al final todo eso viene determinado por una guía
STI que veremos luego, que es la 807.
Entonces, como veis, son requisitos de alto nivel,
pero que si nosotros nos vamos a ese protection profile,
pues vamos a ver al final ya requisitos de bajo nivel,
vamos a ver determinadas las amenazas que pueden afectar a ese producto,
cuáles son nuestros objetivos de seguridad,
bajo qué asunciones se realiza al final esa descripción
de esos requisitos.
Y como veis ahí, pues tenemos un requisito,
se ha sacado uno de ellos muy concreto,
que es el requisito criptográfico.
Y como veis, nos dice, oye,
pues el producto para el algoritmo AES,
pues tiene que trabajar con estos modos,
Y al final con una determinación de unas normativas concretas.
Entonces aquí el fabricante está determinando a través de seleccionar
de esas partes cómo funciona su producto,
cómo trabaja con AES.
Y luego habrá otro requisito debajo, como os decía,
en el que se determinen las longitudes de clave.
Y aquí estamos en la parte cripto.
Lo mismo podríamos ir, ¿no?
, pues a otra diferente funcionalidad,
como pueden ser los requisitos de auditoría.
Cómo se gestionan esos requisitos de auditoría,
qué datos tienen, cómo garantizo la integridad,
la autenticación en el producto, etcétera, etcétera, ¿no?
Entonces, a través de las familias, el TTN,
pues establece un marco de requisitos que deben de cumplir los productos.
Y luego el fabricante,
a través de un documento que elabora para esta solicitud,
pues indica cómo dar respuesta a ello, ¿no?
Porque al final,
pues cada fabricante en función de su producto,
pues para dar respuesta a un requisito lo podrá hacer
de una manera o de otra.
Entonces, teniendo en cuenta que estos son los requisitos
que tengo que cumplir, luego vamos a cómo solicito, ¿no?
Esto es la fase en la que nosotros
ya empezamos a trabajar con el fabricante,
es decir, oye, yo quiero entrar en el catálogo,
¿cómo puedo acceder al catálogo, no?
Y al final el TTN,
pues, tiene una serie de formularios, ¿no?
, para cada una de esas categorías de productos que veíamos antes, ¿no?
Pues tiene un formulario en el CP5-04
para la parte de conformidad y gobernanza.
Y luego, en función
de si es un producto o es un servicio cloud,
pues tenemos el formulario 3 para productos
y el formulario 5 para servicios.
Y cuando nosotros rellenamos estos formularios, tenemos al final
que apuntar una serie de documentación.
Entre esa documentación está el documento,
un documento que se conoce como declaración de seguridad,
en el que nosotros describimos cómo damos respuesta a cada uno
de esos requisitos de seguridad que os comentaba anteriormente.
Entonces, Ya tenemos toda nuestra documentación,
podemos presentar esa solicitud y una cuestión importante
que se va a plantear es, oye, para que un producto
pueda estar dentro del catálogo,
pues tiene que haber sido certificado, ¿no?
Suponeros que hay fabricantes, ¿no?
, al final, como os enseñaba antes, ¿no?
, con común criterio
y hay muchos países involucrados, ¿no?
Que hubiese algún fabricante que ya tuviese su producto
certificado en otro país
o incluso aquí que lo hubiese certificado
y ahora quiere entrar en el catálogo.
Evidentemente,
pues no se le va a pedir rehacer todo ese trabajo, ¿no?
Pero ¿qué es lo que ocurre?
Que al final,
como os decía, ¿con esa certificación común criterial es suficiente?
Pues puede ser que no, ¿no?
¿Por qué?
Porque al final la certificación común criteria
es el fabricante que determina qué requisitos establece
en su declaración de seguridad.
Si te basas, es verdad,
en algún protection profile, pues vienen ahí determinados,
pero como os decía, el CPN ha definido una serie de familias
que establecen una serie de requisitos que tienen que cumplir
los productos que entran al catálogo en una determinada familia.
Entonces,
aunque tú tengas una certificación como criterio,
primero hay que analizar esa certificación como criterio
para determinar si con la misma ya es suficiente
o si al final necesitamos algún trabajo adicional.
Y aquí básicamente tenemos ese proceso.
Cuando un producto ya está certificado,
pues hacemos con el fabricante este análisis.
Lo primero que hay que analizar es, como os decía antes,
cuando abordamos una certificación de un producto,
lo hacemos para una versión muy concreta,
en un entorno concreto.
Entonces, lo primero es determinar por un lado del camino,
por el superior, Si la versión que vamos a introducir en el catálogo
es la certificada, es diferente.
Y si cubre todos los requisitos de seguridad marcados en la familia.
Por ejemplo, si al final
los requisitos que se establecieron cripto durante la certificación común
criteria fueron más laxos que los que establece el TPN,
pues habría que validar que al menos.
¿Alguna parte del producto,
algunos de esos requisitos?
Pues cumplan con lo que establece la guía CTN 807.
Si la respuesta a estas cuestiones es que sí,
pues el producto puede entrar en el catálogo
sin una evaluación adicional.
Pero como vemos ahí, si la respuesta es que no,
pues habrá que hacer al final un análisis
de cuáles son las cuestiones que no han sido revisadas.
O que se ven afectadas por esos cambios en el producto
y se hará una evaluación adicional de esos aspectos que han cambiado.
Pero también puede darse el caso, muchos fabricantes que nos vienen
que al final quieren entrar en el, su necesidad es entrar
en el catálogo.
No conocen al final la parte de certificación
o nunca se le ha dado esa necesidad
y entonces pues requieren certificarse, ¿no?
Entonces ahí que es lo que analizamos, ¿no?
Con el fabricante.
Pues un poco el objetivo, ¿no?
Que como os decía, aunque hay algunas excepciones,
pero normalmente para NS alto será un común criterio
con un nivel de aseguramiento EAL2 y para NS medio a través de INTE.
Aunque es verdad.
Intentando aportar esa flexibilidad a los fabricantes,
que con algún condicionante, pero podemos primeramente
haber determinado, oye, vamos a ir a un nivel medio,
lo hacemos a través del INCE, si luego quiero ir a ese alto,
todo el trabajo que hice para el INCE ya no me vale.
No, se puede hacer a través de un proceso
que viene determinado en el anexo de la CTN-STIC-106, que es,
pues si yo he hecho primero, he abordado una lince,
pero luego quiero ir a nivel alto,
pues nuevamente hay que cubrir ese gap.
Lo importante aquí es que cuando estamos en un determinado nivel,
aseguremos que todos esos requisitos de seguridad
que se nos están pidiendo para ese nivel,
pues han sido validados y revisados.
Entonces, si hemos hecho un medio, evidentemente,
los requisitos que cumplimos, que cumple nuestro producto,
pues van a ser más laxos y lo que tenemos que, van a ser,
no más laxos, perdón, van a ser,
no van a ser tan completos y lo que tendremos que hacer es,
pues para el nivel alto, hacer ese análisis CAP
y cubrir esa serie de requisitos.
Y una vez, pues si hemos determinado
que o bien no teníamos esa certificación
o la teníamos.
Pero hay un gap que tengamos que cubrir,
pues pasaríamos a esa fase de evaluación de nuestro producto.
La evaluación es una parte de todo ese proceso
de certificación.
La evaluación es lo que hace el laboratorio,
lo que nosotros desarrollamos, que es cogemos el producto
y analizamos que da cumplimiento a esas funciones de seguridad,
que no tiene vulnerabilidades.
Si estamos en común criterio, por ejemplo,
que todo es.
De la metodología, entonces hacemos toda esa fase, ¿no?
Pero eso es una de las fases del producto de certificación, ¿no?
Porque también existe una revisión, ¿no?
, de ese trabajo que nosotros hacemos,
como os decía, por parte del organismo de certificación.
Y aquí en la izquierda, un poco en el gráfico,
pues se determinan esas fases, como os.
Mostraba antes, ¿no?
, a nivel más general, las fases del proceso de cualificación, que es
para añadir un producto al catálogo.
Aquí tendríamos las fases del proceso de certificación,
que nuevamente, ¿no?
, se tiene que iniciar con una solicitud, ¿no?
Y aquí remarcaros, ¿no?
, que cuando queremos certificar un producto mediante el INCE,
tiene que ser, porque al final.
Lince está orientado, como os decía,
no es como Común Militeria que tiene ese alcance internacional.
Lince está orientado a nivel nacional.
Veremos con los esquemas de certificación
si pudiera tener principios a nivel nacional.
Y entonces tiene que haber ese interés,
tiene que haber sido validado
que se pueda desarrollar esa certificación por el TPSIC.
De que ese producto va a ir para el catálogo y entonces,
pues por eso tiene ese interés el desarrollar esa certificación
mediante el INCE.
Y dentro de este proceso,
que nuevamente es lo que veíamos más a nivel general,
pero que vamos a hacer aquí, pues estará esa parte de evaluación
que desarrolla el laboratorio, esa parte de validación
de la evaluación por parte del organismo de certificación
y luego ya la emisión de ese PERI.
Cuando nos enfrentamos, una cuestión que siempre nos hacemos fabricantes
cuando se acercan a nosotros para certificar su producto
es ¿y qué ocurre si durante la evaluación
surge algún problema que se detecta en el producto?
Pues evidentemente eso es algo que puede pasar,
que está ahí y que al final nosotros.
Realizamos una una validación en base a unos requisitos de seguridad
y a la descripción que el fabricante nos ha dado de cómo da cumplimiento
a esos requisitos de seguridad y entonces pues tenemos que ver
que realmente si dice por ejemplo que hay un tiempo de inactividad
un tiempo de inactividad por ejemplo se cierra la sesión
pues que tras ese tiempo de inactividad la sesión se cierre
por.
Un ejemplo muy, muy básico, ¿no?
Si durante la evaluación, ¿no?
, surgiese alguna cuestión que no estuviese bien resuelta
por el producto, que no diese la respuesta
adecuada al requisito de seguridad que se ha planteado,
pues nosotros al final informamos tanto al fabricante.
Al organismo de certificación,
pero sobre todo al fabricante de ese problema que se ha encontrado,
pues para que lo pueda analizar, lo pueda corregir
y se pueda seguir adelante con el proceso de certificación,
se pueda concluir.
Muchas veces los problemas que encontramos no son bloqueantes,
es decir, nosotros podemos continuar con nuestra evaluación,
pero el fabricante puede corrige esa parte y lo que os decía antes,
si antes os decía
no es lo mismo un producto en una versión que en otra,
pues si el fabricante ha introducido cambios,
pues que afectan a esos requisitos de seguridad,
evidentemente si nosotros le decimos que hay un problema que afecta
a un requisito de seguridad,
esos cambios afectan a los requisitos de seguridad,
por lo cual cuando recibimos esa nueva versión,
pues nosotros tenemos que realizar un análisis de regresión
que nos permita validar.
¿a qué afectan concretamente los cambios que se han introducido
entre las dos versiones?
Y si aparte de ese requisito, pues hubiese que validar otro, ¿no?
Por ejemplo,
imaginaros que se ha hecho ahí un análisis de vulnerabilidades,
pero para corregir ese problema se ha añadido,
pues, al final un nuevo formulario que habría que analizar,
pues, esa parte de auditoría web, ¿no?
Del producto, ¿no?
Pues.
Sería un ejemplo donde una parte del trabajo
habría que extenderlo para dar cabida a los cambios que ha introducido
el fabricante para corregir ese problema.
Y una vez ya hemos superado al final esa fase de evaluación,
pues ya evidentemente volvemos esa fase de certificación completa,
no solamente la fase de evaluación.
Volveríamos al proceso de cualificación.
Nuestro producto ya cumpliría con esos requerimientos establecidos
en la CCNSTIC 106 de entrada al catálogo
y en función de si es producto o servicio,
pues veríamos ahí.
Sello que se nos daría para nuestro producto
también en función del nivel.
Y una pregunta muy importante de todos los fabricantes es,
oye, yo ya estoy en el catálogo, esto es para sí.
Evidentemente, lo que os vengo comentando ya varias veces
a lo largo de la charla, los productos evolucionan
y a los productos le pueden surgir.
Nuevas vulnerabilidades que hay que dar respuesta entonces
una vez dentro del catálogo eso ya es algo para siempre
que no va a cambiar evidentemente la respuesta
es no cuando alcanza al final todos los productos que están
en el catálogo tienen una fecha de revisión
y ahí el personal dice.
Por ejemplo, la certificación a través de la cual entró
al catálogo, se realizó esa cualificación,
pues las certificaciones tienen un tiempo de validez,
por ejemplo, en común criterio son cinco años.
Pues si ya se hubiera caducado o por alguna cuestión
se hubiese revocado esa certificación de ese producto,
pues el producto,
si no se toma ninguna medida por parte del fabricante,
tendría que ser retirado del catálogo.
Al final.
Para estar en el catálogo es lo que os digo.
Sobre todo cuando hay familias nuevas
en las que quizás no haya productos que todavía estén en el catálogo,
pues el TTN tiene ahí unas cuestiones de excepcionalidad, por ejemplo,
para cubrir ese caso.
Si no hay productos en el catálogo, ¿cuál es el que mejor podría dar
ese servicio a la administración?
Pero si existe esa excepcionalidad que deja de darse,
porque por ejemplo ya se cualificase un producto en esa familia,
pues ese producto sería retirado.
Al final, lo que os decía también anteriormente,
los requisitos de seguridad en la parte TIC,
todos aquellos que desarrollen vuestra actividad en este área,
pues sabéis que está evolucionando constantemente
esos requisitos.
Pueden tener una evolución o bien por cuestiones de avance
de la tecnología o por cuestiones también,
como veis, de vulnerabilidades que puedan aparecer al producto,
pues evidentemente el fabricante debería de dar respuesta
a ello y en algunos casos puede ser necesario retomar ese proceso
que os decía anteriormente de.
Realizar ese análisis gap
y que se realice una validación específica donde están esos,
donde se han producido esos cambios.
Y un aspecto muy importante que yo considero
que al final es un aporte muy positivo,
todos los productos que están en el catálogo siempre,
que al final hay.
Y que a nivel de configuración
esté todo proporcionado por el fabricante.
Pero hay otros productos en los que la configuración de seguridad
y la operación del producto no es nada trivial.
Y el CCN ha establecido que para todo producto que está en el catálogo
tiene que tener asociado un procedimiento de empleo seguro.
Luego veremos un par de ejemplos en los que hemos trabajado.
Y este procedimiento de empleo seguro lo que nos determina es
cómo se debe configurar ese producto.
Y eso es para mí un aporte muy importante,
porque a la hora de entregar un producto,
los manuales que puede disponer el fabricante
pueden ser muy amplios, con muchas opciones,
y este procedimiento.
Indica concretamente cuáles son aquellas configuraciones
de seguridad que se deben de realizar en el producto para dar cumplimiento
a esos requisitos.
Por poneros un ejemplo de lo que veíamos anteriormente,
de ese requisito criptográfico.
Al final,
el producto puede permitirnos configurar de una manera más amplia,
por dar respuesta o compatibilidad hacia atrás.
Pero si lo vamos a emplear en un entorno, ¿no?
, donde el producto tenga que cumplir con los requisitos
de la evaluación, ¿no?
, pues la configuración tiene que permitir solamente
aquellas partes que han sido marcadas, ¿no?
Pues aquí se establece, ¿no?
,
donde hay esas posibilidades amplias de configuración del producto,
pues cuál es esa configuración segura, ¿no?
Por eso ese nombre de procedimiento de empleo seguro, ¿no?
Y luego esa operación, ¿no?
Cómo se debe de operar el producto.
Y por supuesto, si un producto deja de estar soportado, ¿no?
Pues quiere decir que pueden salir vulnerabilidades
al producto que no van a ser corregidas.
Entonces, pues estaríamos perdiendo, ¿no?
Ya esa parte que comentábamos en el punto anterior
de que haya vulnerabilidades que no estén corregidas, ¿no?
Entonces, cuando un producto deja de tener soporte,
pues ya no puede estar en.
Para desarrollar al final
o dar respuesta a las diferentes casuísticas
que se pueden dar en la evolución de un producto,
pues el CCN ha diseñado, CEPESTIG ha diseñado un procedimiento
de evaluación continua.
Como veis ahí tenemos tres ejes.
Pues bien puede ser que se cualificó un producto.
De que luego salen nuevas versiones hardware,
pero que en sí el firmware que tienen puede ser el mismo, ¿no?
Y cómo podemos hacer que esas nuevas versiones
del producto entren en el catálogo.
Pues está determinado cómo habría que hacer ese análisis
de cuáles son los cambios que tiene ese nuevo producto
respecto a la versión cualificada y si eso.
Requiere de una evaluación adicional por parte del laboratorio.
Lo que os comentaba antes, ¿no?
Si al final aparece un producto,
pues que hay que hacer una reevaluación del mismo
por alguna cuestión, algún cambio,
algún nuevo requisito que pueda aparecer,
o bien por evoluciones en el versionado, ¿no?
Al final, lo que os decía, cuando nosotros cualificamos
un producto es importante la versión sobre la que la hemos hecho.
Si el fabricante empieza a hacer cambios,
esos cambios pueden introducir vulnerabilidades
o pueden hacer que la funcionalidad no sea la correcta,
como se nos ha dado en algún caso recientemente.
Y, pues, Hay que validarlo, ¿no?
Entonces, pues para poder.
Evidentemente, los procesos de certificación
que veíamos antes son procesos.
Si lo hacemos con lince, pues es más ligero,
pero si no son procesos largos, ¿no?
Incluso con lince,
pues para el nivel de evolución de los productos hoy en día,
pues incluso hasta se podría considerar largo, ¿no?
Entonces, pues para poder dar respuesta,
ir añadiendo esas nuevas funciones.
Pues si, por ejemplo, los cambios que nosotros hemos hecho
no afectasen a las funcionalidades de seguridad,
pues podríamos añadir esa nueva versión.
Y al final todo eso hay que analizarlo,
hay que justificarlo.
Cuando realizamos una solicitud a catálogo en ese sentido,
pues siempre tendremos que justificar que esas nuevas funcionalidades
no afectan o de qué manera afectan para que a través de una evaluación
complementaria.
Pues se pueda cubrir ese gap.
Y una vez hemos cubierto lo que os decía, el catálogo,
y espero durante este tiempo haber sabido transmitiros
la importancia que tiene la certificación de un producto,
al igual que.
En muchas otras facetas, ¿no?
Otros ámbitos, ¿no?
Pues los productos que se nos ofrecen,
pues validamos que hayan sido revisados, ¿no?
Por ejemplo, aquí estamos en MED, ¿no?
En el ámbito de la educación, ¿no?
Y me comentaba antes Agustín, ¿no?
Pues como al final ellos,
pues también los títulos que ofrecen,
pues son revisados y ellos tienen que presentar unas memorias.
En ese sentido, a nivel de ciberseguridad,
de la seguridad que nos ofrecen nuestros productos,
también el hecho de que hayan sido validados es importante para evitar
que al final un atacante pueda utilizar una de esas vulnerabilidades
que puedan estar en nuestro producto.
O ese mala configuración, mal funcionamiento,
pues para al final comprometer nuestro sistema.
Y es verdad que eso muchas veces es, así como os lo comento, diríais,
evidentemente es una cuestión que queremos,
pero sin duda todo este proceso que os estoy comentando,
os he hablado de diferentes actores, pues tiene un proceso, un trabajo,
tiene un coste que hace que al final eso luego se repercuta
en esos productos.
Y no siempre es sencillo concienciar en la necesidad de la utilización
de productos que han sido certificados.
Y bueno,
pues para eso está la normativa, como en otros sectores,
como decía ahora, por ejemplo, en el de la educación,
en el que se establecen una serie de reglas, ¿no?
Y concretamente en el esquema nacional de seguridad,
pues al final un sistema que esté dentro del esquema nacional
de seguridad, pues tiene que cumplir una serie de requisitos
como veíais en la charla que os impartieron
sobre el esquema.
Y ya en esa charla pude ver que os hablaron
de estos dos requisitos, ¿no?
Que veis aquí que lo recupero, ¿no?
Que es que se.
Indica que al final cuando los productos de seguridad
que se desplieguen en un sistema de información
que va a estar bajo el paraguas del esquema nacional de seguridad,
tienen que ser productos
que están dentro del catálogo de productos de seguridad del CC.
Verdad que como os decía, no siempre para todas las.
Funcionalidades de seguridad que tenemos en nuestro sistema,
pues igual no hay producto que esté dentro del catálogo
y por eso se nombra ahí esa parte de excepciones.
Pero como norma general,
como os digo, se ha hecho un trabajo importante desde el PCN
para ir ampliando ese catálogo, para ir nutriéndolo,
para ir añadiendo nuevas categorías, nuevas familias.
Sin duda, un esfuerzo importante, ¿no?
Que han desarrollado estos requisitos,
lo que vienen es a establecer que al final tanto
las administraciones públicas como aquellos proveedores de servicio
a la administración pública que estén bajo el paraguas
del esquema nacional de seguridad,
pues tendrán que utilizar productos que están en el catálogo.
Y que, por tanto, han tenido ese proceso de cualificación,
a su vez, ese proceso de certificación.
Entonces, es importante el concienciar,
el entender el por qué, la necesidad y el riesgo al que nos exponemos
si esto no fuese así.
El uso de.
Ahora vamos a ver un poquito, vamos a pasar a una parte en la que,
pues aquí os voy a mostrar los documentos,
son todos documentos accesibles, documentos públicos.
El catálogo, ¿no?
Es la TGN Stick 105, hay una versión web en la web de TP Stick.
Pero hay una versión en PDF, esta es la última versión
del catálogo y tampoco es el objetivo extenderse mucho sobre el mismo,
pero un poco que podáis ver al final solamente a nivel de páginas,
372 páginas en las que se detallan productos que pueden ser utilizados
para que veáis.
Y al final hay un abanico amplio de productos.
Y aquí tenemos lo que os decía antes.
Para esa parte de productos cualificados,
cada una de esas categorías con sus familias.
Por ejemplo, tenemos aquí la de control de acceso a la red,
la de servidores de autenticación.
Por ejemplo, debajo de seguridad en la explotación,
los antivirus, los EDR, los SIEM.
Y si vamos a alguna de estas familias,
por ejemplo, la primera de ellas de control de acceso a red,
pues aquí ya veremos los productos concretos
que están cualificados, ¿no?
Y aquí cuestiones concretas que hemos ido comentando, ¿no?
La categoría para la cual está cualificado
para nivel alto, ¿no?
La fecha de inclusión y la fecha de validez que os decía.
¿Cuándo se va a revisar esa validez del producto?
Pues así.
Podemos ir avanzando a lo largo del producto.
A lo largo del catálogo y en función de la necesidad que nosotros tengamos
que cubrir en nuestro sistema de información,
pues ver cuáles son aquellos productos que tenemos.
Y lo que os decía anteriormente, cuando certificamos un producto,
si al final hay muchas variantes del mismo,
muchas series, lo que llamaríamos una serie de productos,
que por ejemplo, pues eso, comparten el mismo firmware,
pero son diferentes.
Pues como veis aquí en este ejemplo que tenemos,
pues hay como una variedad muy amplia de diferentes versiones
de ese producto que han sido cualificadas a la vez.
Lo que os comentaba antes, las guías STIG
de la serie 1000.
¿Qué son las guías STIG de la serie 1000?
Las guías STIG de la serie 1000
son esos procedimientos de empleo seguro que os indicaba.
En estos procedimientos de empleo seguro,
al final el fabricante describe cómo se debe configurar su producto
de una manera segura.
Ahí tenéis una pequeña descripción de las categorías a nivel general,
cómo se realiza esa configuración.
Obtención del producto, cuando lo obtenemos,
cómo podemos validar que el producto que nos han entregado
no haya sido comprometido,
que la integridad del mismo es la correcta.
Una vez tenemos ya nuestro producto, cómo debemos instalarlo.
Una vez hemos acabado esa instalación,
cómo debemos configurarlo.
Y una vez tenemos ya nuestro producto configurado y desplegado,
cómo debemos operarlo.
En ese sentido, os traigo dos ejemplos
en los que hemos trabajado desde Clover.
Uno es de un producto, otro es de un servicio.
Para que veáis esa diferencia que os decía antes
en cuanto al servicio, al producto, pues que evidentemente
si es un servicio ya el fabricante propiamente nos lo da.
Las opciones que nosotros podemos tener.
De para trabajar con ese producto pues con ese servicio
pues son menores no el nivel de capacidad que nosotros tenemos
sino que es el fabricante el que nos lo ofrece
y como veis aquí pues tenemos esas fases que os comentaba antes
pero en un procedimiento de empleo seguro
pues muy cortito no porque al final la capacidad que tenemos
pues es de definir en.
Por ejemplo, usuarios, de definir qué roles pueden tener.
Como os decía, este de Kimatio, un servicio que evaluamos,
utilizado para esa parte de concienciación.
Pero tenemos otros productos donde al final la configuración de seguridad
que se hace del.
Lo despliega en su sistema, pues es muy amplia.
Aquí os traigo un ejemplo de producto que es una tablet, ¿no?
Una tablet concreta, ¿no?
Y como veis, ¿no?
Aquí abajo, pues, el ejemplo en el índice, ¿no?
Solamente a nivel del índice, las actividades que tenemos
que desarrollar en la fase de configuración del producto,
pues son mucho más amplias, ¿no?
Y luego la operación del mismo,
pues la capacidad que nosotros tenemos de operar nuestro sistema,
pues también es mucho más fácil.
Entonces, pues en función del producto o servicio,
pues al final el documento será más o menos desarrollado,
teniendo en cuenta que al final este documento
muchas veces hace punteros no a la documentación propia
del fabricante.
Pero lo que os digo, la importancia,
lo que yo destacaría de todos estos procedimientos
es que dentro de todas esas configuraciones
que nosotros podemos realizar en un producto,
lo que nos da este procedimiento es que esa configuración
que estamos realizando del producto es segura.
No estamos al final como operadores que tampoco.
Producto para desplegarlo en nuestro sistema,
pues que esa configuración que estamos haciendo
es la correcta y que va a hacer que al final
el producto tal cual fue certificado y fue validado,
pues nosotros lo vamos a desplegar en nuestro sistema de información.
Y por último comentaros una parte,
quizás un.
Más detallada de unos aspectos importantes
cuando estamos en seguridad
pues la parte criptográfica que es transversal
y en todos los productos en todas las familias
que os comentaba anteriormente pues al final
hay una serie de categorías comunes a todas ellas
pues todos los productos van a tener una parte de autenticación,
de control de acceso.
De logs, muchos de ellos comunicaciones, ¿no?
Y al final, ¿cómo se protege toda esa información?
Pues a través de criptografía y para determinar, ¿no?
Al final la criptografía va evolucionando, ¿no?
Pues para determinar cuáles son aquellos algoritmos,
longitudes del clave que se consideran seguros,
pues el CCN tiene dos guías, ¿no?
La CCN STIG 807 y la CCN STIG 221.
Concretamente en las familias
se referencia a la CCN-STIC 807 y al final en la CCN-STIC
vamos a ir viendo para criptografía asimétrica
o en la 221 que ya se añade el concepto de quantum criptography.
¿Cuáles son los algoritmos, las configuraciones o el empleo
de esos algoritmos que se considera seguro?
Y tendremos dos tipos de clasificaciones.
Tendremos los recomendados y los heredados
o legacy.
Los legacy son configuraciones que están muy extendidas,
pero cuya resistencia a ataques ya está considerándose
que está llegando a su límite.
Y como veis ahí, pues se considera, ¿no?
De validez es hasta el 31 de diciembre de 2025,
¿no?
Entonces nosotros, por ejemplo, ¿no?
Como laboratorio, cuando evaluamos un producto, ¿no?
O sea, al final el fabricante, ¿no?
En su declaración de seguridad, pues dice cómo dar respuesta
a esos requisitos criptográficos y determinar que utiliza,
pues por ejemplo, aquí os ponía un protocolo de seguridad, ¿no?
Que.
Todos a diario, puede ser TBS,
cuando entramos a una página web a través de HTTPS, ¿no?
Pues una de las cuestiones es
cómo se protege ese canal de comunicación, ¿no?
Y a nivel cripto,
pues se determina, ¿no?
, a través del concepto de cifersuite,
pues qué algoritmos vamos a utilizar,
pues, por ejemplo, para la firma, para el cifrado,
para función resumen.
Como veis hay un poco en los nombres de las cifras suites viene eso, ¿no?
Pues esta guía nos dice
cuáles son aquellas que están recomendadas en este momento,
es decir, que se podría emplear o cuáles son legacy y ahí
pues en la guía se hace una especie de análisis de riesgos
para determinar si ese producto en función
de dónde va a ser empleado, con el nivel que va a ser empleado,
pues se puede utilizar o no.
Algoritmos legacy o no.
Y entonces nosotros lo primero que validamos es que el fabricante,
dentro de esa documentación que nos entrega y nos dice, oye,
yo utilizo estas Tifer suites, pues que cumplan.
Si se determina que solamente puede utilizar recomendados,
pues que solamente estén los del listado,
que de repente no aparezca otro.
Pero eso es.
A nivel documental, como os decía,
en esa declaración que nos presenta el fabricante de cómo dar respuesta
a esas funciones de seguridad.
Pero luego tenemos esa otra parte de.
Tenemos esta declaración, pero tenemos esos test funcionales.
Es decir, nosotros al final vamos a capturar ese tráfico
y vamos a ver que las opciones que se le dan.
Para establecer ese canal de comunicación,
por ejemplo, por seguir con este ejemplo de TLS,
pues utilizan las versiones del protocolo que están autorizadas
y las cifres suites que le corresponden, ¿no?
Y que todo, pues al final,
no solamente a nivel documental, sino también a nivel funcional,
pues está de acuerdo a la normativa, ¿no?
Y. Para aquellos que os guste la parte de criptografía,
enseñaros un poco la guía, tanto la 807,
porque antes de ir a lo que sería meramente
la descripción
o la tabla donde se determina qué se puede utilizar,
pues es verdad que hacen una descripción más teórica
de la parte de.
O de los modos,
al final de las diferentes longitudes de clave,
en esta, en la 807, pero también en la 221,
o sea, que tienen una parte muy importante, ¿no?
, una descripción a nivel teórico de cada uno de los elementos
que tratan, que es muy interesante, ¿no?
, para si alguien tiene interés,
pues, para conocerlo, de.
Que quiera desarrollarse al final en este área,
pues no solamente es una tablita como podría ser incluso,
porque al final es para determinar cuáles son las cuestiones,
sino que se desarrolla, se explica un poco
al final el por qué se llegan a esas conclusiones.
Y tienen evidentemente muchas referencias a descripción.
De algoritmos, de su funcionamiento, de problemáticas que puedan tener,
haber surgido, ¿no?
Con lo cual yo creo que es para aquellos
que os pueda interesar la parte de criptografía
o que queráis conocer un poco más,
pues yo creo que es una referencia interesante,
no muy pesada y que os puede dar una pequeña pincelada en.
En varias áreas.
Y ya para terminar lo que os decía, ¿no?
Entrar en detalle, sí que os quería traer, ¿no?
Pues que la normativa en ciberseguridad
está evolucionando mucho, ¿no?
Si alguno, pues sabéis,
tenéis un poco de interés por este área,
seguro que habéis oídolo de MIS-2,
la transposición a nivel nacional, ¿no?
El Cyber Resilient App, y para nosotros,
que estamos en la parte de certificación,
los esquemas europeos de certificación.
Concretamente, para nosotros, nuestro trabajo, nuestro desarrollo,
en este momento, que empieza el 27 del 2 de 2025,
pues ya entrarán, al final,
los productos que se certifiquen en Europa,
pongan que sea a través de este esquema europeo
de certificación de productos,
que al final describen nuevamente ese proceso que se tiene que hacer,
establece diferentes niveles
y matchean con la metodología que veíamos anteriormente
de común criterio cuáles son los niveles de aseguramiento
que se tienen que dar en cada nivel
y un poco de dónde se deben tomar esos requisitos de seguridad.
En base a esos perfiles de protección que veíamos, ¿no?
Pero aquí hablamos de productos, ¿no?
La idea es que ENISA, ¿no?
Que es la agencia a nivel europeo,
que desde la comisión le han dado este mandato, ¿no?
Pues que desarrolle esquemas de certificación que den respuesta
a las necesidades de ciberseguridad en ámbitos diferentes, ¿no?
Y como veis ahí,
pues ya se está desarrollando el de servicios cloud, ¿no?
El de 5G, irán desarrollándose
y ya se están proponiendo algunos nuevos esquemas,
están empezando los grupos de trabajo,
pues esquemas de certificación para ir dando respuesta
en los diferentes ámbitos que puedan ir surgiendo esas necesidades,
pues a cómo se debe de evaluar la seguridad de los productos.
Cada uno de ellos.
Con lo cual es importante al final este avance que vamos a tener,
donde al final,
lo que os decía, es importante que cuando empleamos un producto
en alguno de nuestros sistemas de información, donde sea,
que ese producto, la funcionalidad que nos está ofreciendo,
pues la haga de una manera segura y que al final nuestros sistemas
sean seguros y evitemos al final esas condiciones que a veces
llegan a la prensa de incidentes de seguridad que podemos tener,
sobre todo en aquellos casos que vienen asociados a la explotación
de alguna vulnerabilidad en alguno de los productos.
Y como os digo, para nosotros el UCC,
que ha sido el primer esquema que se ha desarrollado,
y que ya va a entrar en vigor, es importante porque regula,
de otra forma, un genio a ese nivel europeo,
cómo vamos a tener que desarrollar nuestro trabajo,
cómo va a ser ese proceso de certificación,
la relación con las diferentes instituciones,
Al final os decía antes el organismo de certificación del TPN,
pues cómo ellos al final van a tener que estructurarse y cuáles son
las funciones que tienen que hacer y nosotros como laboratorios,
cuáles son nuestras funciones.
Ya os digo, no es objetivo de la charla,
ni mucho menos entrar en detalle,
pero sí un poco que conozcáis esta evolución que se está dando
porque al final es importante, ¿no?
Los productos que empleamos, ¿no?
Y la normativa va en ese sentido, ¿no?
Lo que os decía, ¿no?
La normativa que se está desarrollando en que los productos
que se utilizan, que se emplean, ¿no?
En los sistemas de información, pues hayan sido revisados, ¿no?
Se haya validado con un nivel
u otro de aseguramiento en función de, evidentemente,
las necesidades de ese sistema.
En cuanto a seguridad,
pero sí que haya habido una validación que haga que alguien,
pues, si lleno, ¿no?
, un mínimo tutorial, ¿no?
, pues, permita explotar una vulnerabilidad muy básica
en un sistema, ¿no?
Eso es importante, ¿no?
Y eso es lo que espero haber os transmitido, ¿no?
, la importancia, ¿no?
, de que los productos.
En nuestros sistemas de información hayan sido revisados,
no hayan sido evaluados por un tercero,
que cumplan al final una serie de requisitos mínimos,
que eso es lo que nos aporta el catálogo,
y que al final su empleo en los diferentes sistemas
de información.
Como ya ocurre en España a través de este esquema nacional
de seguridad, cuando se vaya trayendo la normativa
que se está desarrollando a nivel europeo,
pues que se establezca esa obligatoriedad de la utilización
de los productos certificados, pues para tener al final esa garantía
de que nuestros sistemas de información.
Y nada más por mi parte, espero que os haya resultado
interesante la ponencia, el tema y ahora abierto
a si hubiese alguna pregunta.
Pues muchas gracias Fidel.
Bien.
Pues todos los asistentes que tenéis el enlace de la aplicación web,
si tenéis algún tipo de pregunta o cualquier comentario
o queréis decir cualquier cosa, pues por favor desbloqueéis el micro
y hacéis la consulta que consideréis de forma oral.
Así será lo más sencillo.
Voy a mirar también el chat, si alguien lo hubiera.
Bien.
¿Nadie hace ningún comentario?
Yo.
Me gusta hacer algún tipo de consulta y especialmente a personas
que no tienen que ver con la academia,
sino que están en empresas privadas, como es tu caso,
con el fin de tratar de ver algún tipo de previsión a medio plazo
de cómo va a evolucionar el área de conocimiento de esa institución.
Y lo más importante es de qué forma
nosotros como universidades podemos publicar esa demanda.
Entonces, imagínate que, bueno, tú eres responsable,
tienes un cargo importante dentro de la empresa, ¿vale?
Imagínate que estás dentro de cinco años, por ejemplo, o dentro de dos,
en un futuro a medio plazo, ¿vale?
Y tienes que, pues, tienes alguna necesidad,
bien formativa en tu caso de primera persona
o bien de, pues, una necesidad en tu empresa,
necesitas a alguien que sepa hacer algo.
La pregunta es, En ese contexto,
observas qué tendrían que hacer las universidades
para tratar de cubrir esa necesidad.
Observas que nuestra oferta actual realmente podría producir
a esas personas dentro de dos años, tres,
porque al fin y al cabo un grado son cuatro años,
un máster son mínimo uno o dos,
con lo cual tenemos que tener esa cancha
para empezar a trabajar la propuesta, desarrollarla
y que los estudiantes la completen.
Imaginemos un máster de un año, otro año van a prepararla.
O sea, imagínate dentro de dos años.
Sí.
¿Tus necesidades?
¿Qué tendríamos que hacer como universidad para dentro de dos años
que haya alguien que tenga esas necesidades que tú tienes?
Y ese alguien puede ser tú mismo, es decir, aprender algo, ¿vale?
Sí, sin duda muy interesante la cuestión.
Porque lo que os decía, ¿no?
En el esquema europeo de certificación,
una cuestión que se le está dando mucha importancia, ¿no?
Y de hecho está muy revelada,
es la capacidad que tienen que tener los evaluadores,
al final los trabajadores que validamos
esos productos para poder desarrollar esas actividades.
Es decir, cuando nosotros pasamos auditorías
que validan a través del centro criptológico
que vienen a revisarnos, pues validan nuestra competencia
para desarrollar esa actividad.
Y muchas, la competencia, tenemos dos partes, ¿no?
Como os decía, la parte más metodológica,
que no está cubierta en las universidades.
Muy pocos estudiantes que vienen de algún máster,
pues le han dado alguna charla, ¿no?
Respecto a lo que es Comuniteria o es Lince,
pero muy de alto nivel.
Entonces, pues nosotros eso lo cubrimos,
lo estamos cubriendo.
Para que los estudios
los candidatos al final que se desarrollan con nosotros
pues pueda al final realizar ese trabajo
pero entiendo no es un trabajo
o sea las metodologías son muy de nicho
y entonces entiendo que incluirlo en un plan formativo
pues es más complicado pero lo que sí que buscamos
no es que esa parte técnica.
Sí que esté cubierta.
¿Y dónde vería yo al final esos retos que nos van a llegar?
Ya nos están llegando peticiones, por ejemplo,
de productos que emplean criptografía poscuántica.
Entonces, la formación en esa parte que empezase a aparecer en los.
Programas formativos,
pues para nosotros sería interesante, ¿no?
Nosotros ahora cuando entrevistamos a un candidato, ¿no?
, pues nos centramos más en que tenga,
si ha realizado una formación especializada en ciberseguridad,
¿no?
, evidentemente, o ha tenido algunas asignaturas en su grado,
pues que haya visto,
pues, elementos más clásicos de criptografía simétrica
o asimétrica, pero sin duda,
tanto para mí, me comentabas, para nosotros,
que estamos en un área muy cambiante,
pues para mí sería un requisito de alguna manera el poder formarme
para afrontar ese reto que nos va a suponer la incorporación
de la criptografía postcuática a los productos
y cómo nosotros lo vamos a tener que validar
durante nuestras evaluaciones.
Cómo que los posibles candidatos, los estudiantes
que vayan saliendo de las instituciones educativas,
pues tengan ese conocimiento.
Y otra cuestión, es verdad que en una formación
más especializada, como puede ser un máster,
que se ven elementos, me lo comentabas antes,
de una manera práctica,
como pueda ser al final realizar un test
o al final el desarrollo, de alguna actividad,
pero sí, no sin ir directamente a la metodología,
pero con esa manera de pensar un poco más metodológica,
de que el hecho de que ellos luego lo vayan a tener que desarrollar,
uno de los gaps que yo creo que más encontramos es,
al final en la universidad se plantea un ejercicio práctico muy guiado,
y cuando llegas a desarrollar el.
La actividad con nosotros, pues no existe esta guía, ¿no?
Existe la metodología que te dice qué es lo que tienes que mirar
y tú eres un poco el que afrontas ese desarrollo de esa actividad.
Evidentemente, pues eso se va ganando con la experiencia,
pero sí que quizás que hubiese un enfoque más abierto
en las actividades que se desarrollan.
Pues creo que haría que esos candidatos que tienen
que ir luego de desarrollar la actividad profesional,
pues tuviesen ya como esa visión.
Vamos a ir viendo un poco las dos cuestiones
que yo destacaría.
Muy bien, pues muy interesante.
En relación con esto, en los últimos tiempos ha surgido
una propuesta formativa que se llaman microcredenciales, que son cursos
muy específicos, muy concretos, orientados a la empleabilidad,
es decir, nada de introducción a la ciberseguridad ni nada de eso,
sino algo muy, muy concreto,
como puede ser una metodología concreta
específicamente para las personas que van a hacer una labor concreta.
Es decir,
como lo que acabas de decir, cogemos un ingeniero de informática
que va a trabajar en una empresa de ciberseguridad,
le explicamos específicamente esa metodología
y eso le sirve a esa persona para esa empresa.
El mismo ingeniero
que vaya a trabajar en otro aspecto de la ingeniería informática,
a lo mejor esa metodología no es de utilidad,
con lo cual las microcredenciales son muy valiosas
para formar de forma quirúrgica.
Hace falta esto en estas condiciones.
Entonces, en la UNED estamos implementando esta oferta formativa,
disponemos de una serie de fondos europeos
para financiar esa formación.
Entonces, en primer lugar,
me gustaría informar a los asistentes de esa oferta,
que supone que.
Sin llegar a ser totalmente gratuita para los estudiantes,
la UNED sí que financiaría el 70% de la matrícula,
con lo cual se puede hacer un curso a un precio bastante asequible
para los estudiantes.
Y específicamente tienen que ser al nicho,
es decir, podríamos, si quieres luego lo hablamos con cierto detalle,
pues identificar alguna necesidad, metodologías, lo que sea,
y podríamos crear esa microcredencial.
Específicamente para formar ese tipo de personas.
Y puede parecer un poquito extraño,
estamos formando un empleado de Clover.
Bueno, nosotros ya tenemos en marcha microcredenciales, por ejemplo,
para formar las catatólicas de aceite de oliva.
Es decir,
empresas que se dedican a esto.
Porque las microcredenciales son para eso,
para formar a personas que van a hacer una tarea muy concreta,
muy específica.
No es un grado,
no es un máster que da una visión global,
sino algo quirúrgico.
Entonces, como digo, la oferta de las microcredenciales
va creciendo poco a poco aquí en la UNED
y en la página web del Vicerrectorado de Formación Permanente,
en el que yo soy vicerector adjunto, pues podéis encontrar información
y va a evolucionar.
Entonces, pues por mi parte, nada más.
Veo que no hay más consultas, si no me equivoco.
Con lo cual, pues muchas gracias, Fidel.
Y nada más,
muchas gracias a todos los asistentes y hasta la próxima sesión.
Muchas gracias a todos.
Muy bien.