Red Seguridad 099

46 red seguridad cuarto trimestre 2022 opinión que justifican la necesidad de evolucio- narlas y de buscar otro tipo de mecanis- mos. La primera es que se apoyan en organismos de normalización que de- finen los requisitos a evaluar. Esto, que parece una obviedad, tiene importantes implicaciones. En primer lugar, obliga a consensuar esos requisitos, lo que pue- de ser un proceso muy largo (pensemos, por ejemplo, en los 12 años entre versio- nes del Esquema Nacional de Seguridad o los más de cuatro que llevamos en Europa para consensuar el esquema de certificación de ciberseguridad para ser- vicios en la nube; vamos, que cuando lo publiquen estará ya obsoleto). Y en segundo término, el hecho de que cada caso de uso genere un referencial diferente provoca una segmentación del mercado por sector, país y, en general, por cada tipo de garantía que se quiera establecer. ¿No le parece al lector que existen demasiadas certificaciones? La segunda característica es que son absolutas. Las certificaciones dividen al mundo en dos: los que las tienen y los que no. Esto hace que no existan in- centivos para la excelencia en el cum- plimiento (sirve lo mismo una certifica- ción alcanzada por los pelos que otra lograda de manera sobresaliente), ni en la evaluación (son pocos los que prefie- ren a un examinador más exigente). De hecho, la mayoría de las certificadoras hacen un uso exhaustivo de profesiona- les liberales como auditores para evitar plantillas abundantes y reducir al máxi- mo los costes de personal, ya que las que se acaban haciendo con el mercado son las más económicas (a igualdad de condiciones, el precio es el factor deter- minante). La tercera es que evalúan una situa- ción estática en un momento en el tiem- po. Quizás este sea el factor que más choca con la realidad actual. Mientras que en el pasado las versiones de un producto o sistema podían durar años, con la aplicación de metodologías ági- les, en la actualidad, hay versiones de software con un periodo de vida de un par de semanas. Por lo tanto, ¿cómo po- demos saber que lo que estamos usan- do guarda cierta correlación con lo que fue evaluado y que la versión actual tie- ne, aproximadamente, el mismo grado de seguridad que la que fue evaluada? Y para empeorar la situación aún más, ¿cómo evaluar algo que tiene un ciclo de vida inferior a lo que se tarda en exa- minarlo? En el fondo, como decía Einstein, “locura es hacer la misma cosa una y otra vez esperando obtener diferentes resultados”. Pues bien, llevamos más de 20 años utilizando certificaciones y pensamos que vamos a solucionar los problemas que ellas mismas han crea- do, utilizando aún más certificaciones... En fin, una locura. Entender qué son Con esto no quiero decir que debamos huir de las certificaciones. Creo que debemos entender qué son, para qué sirven y utilizarlas de manera adecuada. Como he comentado hace unos pá- rrafos, las certificaciones sirven para de- mostrar el cumplimiento de unos requisi- tos estables, por lo que pueden ser muy útiles, por ejemplo, para asegurar que se cumplen los requisitos mínimos para ope- rar en un mercado o para comercializar un producto. En este sentido, no servirán como garantía absoluta de seguridad; pero sí para saber que, al menos, se al- canzan unos requisitos mínimos. Eso sí, al igual que los antivirus, de- ben evolucionar e incorporar otros ele- mentos: Agilidad en la definición de criterios. Capacidad de supervisión continuada en el tiempo. Niveles de cumplimiento (para fomen- tar la excelencia). Mecanismos orientados a la interope- rabilidad. En resumen, mucho han cambiado las cosas desde los primeros tiempos de la informática, y al igual que ahora las me- todologías agile se han impuesto como mejores para una realidad mucho más variable y cambiante, las certificaciones han de evolucionar en el mismo sentido reuniendo las características que hemos comentado. Así que espero que la próxima vez que me oigan decir que las “certificaciones no sirven”, entiendan a lo que me quiero referir.