¡DEBE SER Y PARECER!! TENER UN HTTPS NO ES SUFICIENTE

Lamentablemente aun nuestra entidades toman de mala manera cuando se publican verdades facticas.

Este reporte llega a ALGUNAS entidades con datos completos, pero para fines de difusion publica se ha enmascarado cierta informacion.

Aun tenemos generacion X reaccionado al Rojo Vivo y generando un espiritu de limitacion a la libertad de expresion. Pero a buen entendor pocas palabras!!!

Por muchos años contar con un protocolo HTTPS y su correspondiente certificado digital en los servidores web, que soportan sistemas de entidades xxx–xxx ha sido sinónimo inobjetable de SEGURIDAD.

Sin embargo, los certificados Digitales con el tiempo han enfrentado el descubrimiento de vulnerabilidades en los algoritmos criptográficos, los protocolos de seguridad, la compatibilidad y seguridad de navegadores, así como la configuración de los servidores. Entonces para mantener el estado SEGURO de los sitios HTTPS se deben contemplar diferentes variables. El solo hecho de contar con un candado visual y un protocolo HTTPS ya no es suficiente.

Figura 1: Relación de seguridad con HTTPS

En términos simples podemos decir que existen Niveles de seguridad entre los sitios que tienen configurado un protocolo HTTPS.

OBJETIVO:

Yanapti SRL con el afán de apoyar en la seguridad de xxx–xxx ha realizado un trabajo de investigación técnica mediante una evaluación externa, COMPLETAMENTE PUBLICA, PASIVA Y NO INTRUSIVA en los sitios web de 23 entidades xxx–xxx!!!!

El Objetivo es apoyar para que TODOS los sitios tengan un nivel ALTO en términos de seguridad de acuerdo con los métodos y criterios utilizados a la fecha.

Las vulnerabilidades institucionales afectan la MARCA PAIS en cuanto a nivel y percepción de la seguridad de la información devaluando las capacidades tanto como nación, así como profesionales. Los resultados pueden y han sido enviados unicamente con datos de entidades comprendidas en la muestra.

RESULTADO GENERAL:

El resultado de la evaluación es el siguiente:

Figura 2: Niveles de RIESGO detectados – agosto 2017

Se volvio a realizar las evaluaciones al 15 de diciembre 2017

Figura 3: Niveles de RIESGO detectados – diciembre 2017

Esta figura refleja los porcentajes por grupos donde se puede apreciar los extremos

Para determinar los niveles se ha tomado la relación entre la calificación más baja y la más alta.

Al mes de agosto se tuvieron los siguientes resultados

NIVEL DE RIESGO MUY BAJO. 13% significa un grupo donde la conjugación de variables ha cubierto las diferentes vulnerabilidades conocidas hasta hoy. Se puede decir que tienen un nivel de seguridad MUY ALTO
NIVEL DE RIESGO MUY ALTO. 18% – Representa un grupo de entidades que, si bien tienen un certificado digital, la conjugación de variables no es óptima según los criterios de seguridad. Requieren de forma inmediata la reconfiguración de sus sitios. Se puede decir que tienen un NIVEL DE SEGURIDAD MUY BAJO.

Si consideramos que a Menor nivel de seguridad se puede entender MAYOR riesgo tenemos los siguientes resultados:

Figura 4: Relación Cantidad y Porcentaje – agosto 2017

Para el mes de diciembre 2017 la situacion ha cambiado un poco. se han invertido los resultados en promedio. El nivel de riesgo alto es de 13% y el nivel muy bajo subio hasta 17%

Figura 5: Relación Cantidad y Porcentaje – diciembre 2017

Los cuadros permiten aprecias la cantidad y la relación porcentual.

Se resalta como PROMEDIO DEL SECTOR el NIVEL ALTO de RIESGO, por cuanto sería el resultado de todo el grupo que exactamente da 27.83 en el mes de agosto y de 24.13 para el mes de diciembre. Se observa una mejora muy leve.

RESULTADO ESPECIFICO

De acuerdo con las evaluaciones realizadas las 23 entidades están distribuidas de diferente manera. Se identifican 5 grupos por el grado de riesgo que presentan.

Los nombres de las entidades no son presentados por motivos de confidencialidad y reserva de información.

Figura 6: Resultados de la evaluación – agosto 2017

Para diciembre hubieron mejoras en varias entidades, solo algunas mantuvieron el nivel al mes de agosto. En realidad solo una entidad bajo de nivel hasta lograr una F, el nivel mas bajo de seguridad.

Figura 7: Resultados de la evaluación – diciembre 2017

Por confidencialidad no se despliegan las entidades.

Se observa que algunas, aunque pocas entidades han mejorado su resultado, lamentablemente otras se mantienen y una ha empeorado.

VULNERABILIDADES ENCONTRADAS

Se muestra las principales vulnerabilidades encontradas:

FREAK attack
POODLE TLS attack.
MITM attacks
The server uses SSL 3, which is obsolete and insecure.
Intermediate certificate has an insecure signature.
The server supports only older protocols, but not the current best TLS 1.2.
This server accepts RC4 cipher, but only with older
There is no support for secure renegotiation
The server does not support Forward Secrecy with the reference browsers.

El grado de gravedad de estas vulnerabilidades hace que el sitio aparentemente protegido reciba calificaciones menores. Muchas de estas vulnerabilidades están ampliamente descritas en foros y sitios especializados. Tanto de manera teórica, como facilidades para explotarlas.

RECOMENDACIONES:

Es importante que cada entidad analice la exposición presentada bajo la premisa “DEBE SER SEGURO Y DEBE PARECER SEGURO”. La evaluación se ha realizado tomando las mismas variables y métodos para las 23 Entidades.

Consideramos que para mantener la confianza en el concepto HTTPS, TODAS las entidades del Sistema xxx–xxx deberían estar mínimamente con calificación A, siendo que aún existe la calificación A+.

Las recomendaciones técnicas van en diferentes niveles:

Se supone que muchas hacen evaluaciones de hacking regularmente. Recomendamos validar si este informe comprende vulnerabilidades en el certificado digital.
Del lado de los servidores WEB. Sin duda el lado más importante y que le toca bajo responsabilidad total a las entidades reguladas. Las vulnerabilidades están desnudando la limitacion de seguir a buen ritmo la detección y publicación de vulnerabilidades por cuanto varias tienen más de 12 meses. Esta recomendación está en manos de cada entidad y puede ser rápidamente subsanada.
Del lado de los clientes. Sin duda aun la brecha digital entre usuarios comunes y usuarios seguros es muy grande. Los primeros pueden dejar las vulnerabilidades de sus navegadores expuestas. Esta recomendación es mucho más difícil de asegurar.
Del lado de los desarrolladores que sin duda recae en las pruebas de pase a producción, donde deberían saltar estas vulnerabilidades. Esta recomendación está en manos de cada entidad y puede ser subsanada en un plazo de semanas.
La tarea de los diferentes niveles debe ser más estricta en términos de pruebas y acreditaciones antes de que algo sea publicado al Internet. Las Re acreditaciones de seguridad permiten protegerse contra la dinámica de la relatividad en seguridad. Algo que ayer fue seguro, hoy ya no lo es.

Finalmente, se debería exigir que todas las entidades consideren de manera más integral el análisis de vulnerabilidades y seguimientos a este tipo de riesgos. Muchos de los certificados tienen más de 12 meses de estar implementados, por tanto, se infiere que las vulnerabilidades tienen más de ese tiempo sin haber sido corregidas.