Tres preguntas que un CISO debe hacerse antes de escoger una solución de ciberseguridad o un dispositivo de red

A estas alturas, todo el mundo da por hecho que cualquier producto que llega al consumidor ha pasado previamente los controles necesarios para garantizar que cumple con las normas de calidad y seguridad exigibles. La actual pandemia incluso nos ha acostumbrado a oír hablar de sellos y certificaciones, por ejemplo, a la hora de adquirir unas mascarillas.

En el mundo de la ciberseguridad, los fabricantes de soluciones y expertos en este ámbito se deshacen en esfuerzos a la hora de pedir que las organizaciones aumenten sus presupuestos e inversiones en ciberseguridad, y revisen y optimicen sus arquitecturas para protegerlas mejor. Y es normal, diariamente seguimos viendo infraestructuras de organizaciones que son comprometidas y secuestradas por cibercriminales, principalmente por no disponer de medidas de ciberseguridad suficientes y adecuadas.

Lo que es curioso es que cuando un CISO (Chief Information Security Officer) va a contratar servicios de ciberseguridad, seguramente exigirá que los profesionales dedicados muestren su conocimiento y certificaciones, formación universitaria y especifica del servicio que van a prestar. Pero, ¿qué pasa con las soluciones o productos que vamos a desplegar en nuestras infraestructuras?

¿Qué garantías se deben exigir a una solución de seguridad o un dispositivo de red?

Lo normal y aconsejable es que antes de seleccionar una solución para mejorar la accesibilidad y/o proteger activos e infraestructuras, se lleve a cabo un buen análisis de las diferentes soluciones disponibles en el mercado. Que se consulten los cuadrantes y expertos. E incluso que se realicen pilotos para comprobar qué solución cumple mejor con las necesidades de mi organización.

Pero lo que es menos habitual, es poner en duda la propia integridad de la solución. ¡Es una solución de seguridad!, tiene que ser segura, ¿no?

Es posible que hayamos seleccionado un producto porque sus funcionalidades permiten alcanzar el nivel de seguridad marcado, pero ¿tenemos certeza de que no vamos a introducir en nuestra arquitectura un dispositivo o solución que puede tener fallos de desarrollo o vulnerabilidades ante ataques específicos? ¿Una tercera parte independiente ha evaluado esta solución?

Puede que en lugar de mejorar la seguridad como pretendíamos, lo que hemos introducido es un nuevo agujero de seguridad en nuestra arquitectura, del que además no tenemos constancia y que encima nos ha supuesto un coste, en muchos casos, considerable ¿podemos imaginar al CISO de esa compañía, explicando un incidente de seguridad sufrido por esta situación?

Entonces, estamos de acuerdo en la necesidad de garantizar, de algún modo, que la integridad y seguridad de las soluciones que ofrecen los diferentes desarrolladores, ha sido revisada por un tercero que nos proporciones evidencias suficientes. Pero ¿qué sello, evaluación o certificación es la más adecuada o reconocida?, ¿cómo conocer el alcance de una certificación de seguridad?, ¿dos productos con la misma certificación de seguridad ofrecen las mismas garantías?

¿Qué certificación o certificaciones hay y cuál exigir?

Hay diferentes alternativas en el mercado, desde la autoevaluación, o las certificaciones privadas, hasta las certificaciones bajo un estándar internacional y un esquema de certificación público-privado. De estas últimas, quizás la más popular y reconocida internacionalmente es la Common Criteria. Existen otras locales, como la certificación LINCE, válida para entrar en el catálogo de productos IT para la administración pública, el CPSTIC español. Podemos encontrar información más detallada de ambas certificaciones en nuestra página web.

Pero, si estamos analizando dos soluciones de seguridad similares en cuanto a funcionalidades y las dos tienen una certificación Common Criteria ¿significa que ambas garantizan haber superado los mismos controles de seguridad? La respuesta es: depende.

La certificación Common Criteria es muy flexible, eso permite a los desarrolladores decidir que funcionalidades quieren evaluar y certificar. Por esta razón es muy importante no suponer que, porque un desarrollador tenga un sello Common Criteria, eso sea automáticamente una garantía de que cumple nuestros requisitos de seguridad o que cumple con los mismos requisitos de seguridad de un producto competidor con funcionalidades similares.

Es necesario revisar toda la información del alcance de la certificación, producto, versión, funcionalidades evaluadas, validez del certificado, etc. Esta información es pública y accesible para cualquier interesado, se puede encontrar en la página web de Common Criteria y en las diferentes páginas de los organismos de certificación de cada país, en el caso de España, en la página de OC-CCN.

Es posible que para alguien que no esté acostumbrado a analizar este tipo de información, pueda resultar una tarea un poco complicada o tediosa, pero está en juego la seguridad de nuestras infraestructuras y activos digitales, es necesario.

¿Cómo comparar dos productos certificados Common Criteria: PP vs EAL?

El estándar Common Criteria tiene diferentes aproximaciones, una de las más conocidas son los EAL (Evaluation Assurance Level). Siete niveles acumulativos, cada uno representando un mayor esfuerzo de evaluación y de garantía. Con este enfoque, el desarrollador es quien define los objetivos y el alcance de la evaluación (TOE). Por ello, es posible encontrarse con evaluaciones de alto nivel, pero con un alcance muy reducido y viceversa. Lo que hace difícil comparar dos certificados EAL sin entrar en los detalles más técnicos de la evaluación realizada.  

Para, entre otras cosas, facilitar el reconocimiento de una certificación Common Criteria de un tipo de solución específica, se crean lo que se conoce como Perfiles de Protección. Estos documentos reúnen una serie de requisitos mínimos a evaluar de cara a una certificación para una familia de productos concreta, haciendo posible la comparación de productos con certificados del mismo nivel de garantía (EAL) con el mismo alcance evaluado.

Los Perfiles de Protección son generados por grupos técnicos de trabajo internacionales, que pueden estar compuestos por fabricantes, laboratorios de evaluación, organismos públicos, etc. Posteriormente son revisados y certificados por algún Organismo de Certificación reconocido Common Criteria, que los publica en su página web.

De esta manera, cuando nos encontramos que dos productos han obtenido el certificado Common Criteria, cumpliendo los requisitos de un perfil de protección concreto, tenemos la garantía de que ambos productos han superado las mismas pruebas de seguridad y no necesitamos dedicar mucho más tiempo en analizar en profundidad los documentos de la certificación.

Uno de los perfiles de protección más utilizados es el correspondiente a la familia de Network Devices, que aplica a la mayoría de las soluciones conectadas en red del mercado. También es posible que una solución se haya certificado en base a varios perfiles de protección concurrentemente, como puede ser el caso de una solución de Firewall, que podría completar la certificación con un perfil de protección más específico. Podemos encontrar toda la información relativa a los perfiles de protección en la página de Common Criteria.

En resumen, para poder tomar decisiones informadas a la hora de decidirse por una solución de ciberseguridad o un dispositivo de red, es clave asegurarse que la solución ha sido evaluada por una tercera parte independiente. Y, además, debemos entender el nivel de exigencia y el alcance de dicha evaluación para poder comparar dos productos similares. Si no, estaremos escogiendo la solución en base a la confianza que nos inspire el fabricante.