Consultorías

PCIDSS40

Cumplimiento PCI – Reglas del Firewall

Si bien en nuestro país "parece" que el tema de cumplimiento PCI se ha relajado, no olvidemos que nuestros dos principales Administradores de Tarjetas debito/credito han entrado no hace mucho bajo la regulación y control de ASFI. Una ya ha certificado el pasado año su cumplimiento PCI y la otra este año. Ahora si, con los principales actores Certificados, el escenario cambia.

Esperamos que ahora se pase a la fas de hacer cumplir a los Entidades Financieras que ofrecen estos servicios.

No era muy razonable que se obligue a las Entidades Financieras cuando las Administradoras de tarjetas ni siquiera eran reguladas por ASFI. Creo que ahí se les fue un poco la lógica, dado que la principal fuente de Contaminación PCI no estaba cubierta.

Entonces la lectura hacia adelante es que se retome este control por parte del los reguladores. Aun si me equivocara, hacerlo no perjudica al negocio.

PCI tiene un enfoque de seguridad de tinte Minimalista!!. Mientras mas pequeño sea el ámbito PCI, el control es mejor. Mientras menos perjudiquen, la seguridad es mas administrable.

Uno de los puntos a controlar se refiere a las reglas del Firewall

Adjuntamos dos ejemplos, el primero un estado de no cumplimiento PCI

El segundo cuando las reglas han sido definidas. Por supuesto que a esta validación se debe acompañas las correspondientes políticas, normas y procedimientos.

Desde Yanapti recomendamos retomar o mantener los proyectos PCI. Al final la lógica binaria de cumplimiento ayuda mucho y despeja las eternas discusiones a las que llevan estándares como ISO 27001 o metodologías como COBIT cuando el Riesgo determina la dirección.

Con PCI el estado es Binario. Se tiene o no, independiente del riesgo. Este ayuda después de cumplir y no se usa como instrumento de escape.

HTTPS – No todos los sitios tienen la misma seguridad

Por muchos años contar con un protocolo HTTPS y su correspondiente certificado digital en los servidores web, que soportan sistemas de entidades 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:

Nuestra empresa con el afán de apoyar en la seguridad del sistema nacional 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, que por la naturaleza de sus actividades, deben tener certificados digitales. 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.

IMPORTANTE: El relevamiento corresponde en fecha a mediados del mes de agosto 2017. Se ha notificado a varias de las entidades afectadas habiendo notado que ALGUNAS han tomado recaudo correspondiente y otras ninguna acción.

No se publican datos específicos del Sector o las entidades por cuanto AUN prevalece la posición de NEGACIÓN en muchos Directorios. Cuando la reacción debería ser actuar rápidamente frente a una observación dada a conocer formalmente, la respuesta es un ataque a la fuente de la misma. Tenemos 16 años contribuyendo a mejorar la seguridad y hemos vivido muchos escenarios de confrontación inicial, aceptación posterior y agradecimiento como conclusión, pero después de varios meses. Por tanto consideramos correcto el camino. pero tomamos precauciones. Hemos comprobado que el personal técnico al final, acepta el efecto positivo de estas publicaciones.

RESULTADO GENERAL:

El resultado de la evaluación es el siguiente:

Figura 2: Niveles de Seguridad detectados

 

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.

  • NIVEL MUY ALTO. 17% 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 y correspondientemente un nivel de riesgo MUY BAJO
  • NIVEL MUY BAJO. 13% - 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 y correspondientemente un NIVEL DE RIESGO MUY ALTO

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

 

Figura 3: Relación Cantidad y Porcentaje

 

Los cuadros permiten apreciar 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.

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 4: Resultados de la evaluación

Por confidencialidad no se despliegan las entidades.

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 debería estar mínimamente con calificación A, siendo que aún existe la calificación A+.

Las recomendaciones técnicas van en diferentes niveles:

  • Del lado de los servidores WEB. Sin duda el lado más importante y que le toca bajo responsabilidad total a las entidades. Las vulnerabilidades están desnudando la incapacidad 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.

Ethical Hacking

¿Qué es Ethical Hacking y para qué se utiliza?

Ethical Hacking es un procedimiento en el cual una organización ataca su propia tecnología sin fines destructivos y dentro del marco legal vigente, esto con el fin de tomar medidas preventivas contra posibles ataques maliciosos.

Para esta finalidad se utilizan metodologías y técnicas usualmente propias de un hacker con el propósito principal de la búsqueda de vulnerabilidades y brechas de seguridad que pudieran permitir la intrusión a la red y el consiguiente robo, alteración y/o cualquier otro delito que pudiera aplicarse sobre la información confidencial de la empresa.

YanapTI Corporation brinda el servicio de Ethical Hacking el cual consta de evaluaciones de Seguridad Interna y Externa, con objetivos especificos y bajo estandares internacionales.