Durante un proyecto que dirigí en México, hace unos años, en la implantación del sistema informático para la expedición de los pasaportes mexicanos, un alto cargo me preguntó si el sistema era totalmente seguro. Yo le respondí que el sistema era uno de los más seguros del momento, pero que independientemente de si el sistema fuera seguro o no, estaba de por medio, el factor humano. Le puse un ejemplo, si al realizar un nuevo pasaporte, no se exigen los documentos necesarios (se aporta documentación apócrifa con el conocimiento del operario) o que en la aduana, no se le revise la autenticidad del documento (por descuido, por cohecho, o por cualquier otra circunstancia), el proceso no evita el fraude por la tecnología, falla por el factor humano y hasta que no se automatizara el proceso quitando el factor humano (prácticamente inviable), existía un riesgo que había que mitigarlo con otro tipo de acciones (validaciones, autorizaciones, auditorías, metodología, rotaciones, etc).

En definitiva, puede tener la mejor tecnología de seguridad, Firewalls, seguridad perimetral, sistemas de detección de intrusos, detección del malware, etc., pero lo único que se necesita es un empleado descontento o malicioso, también llamado Insiders. Tienen todo en sus manos y a diferencia del atacante externo, los empleados de una empresa poseen el suficiente conocimiento para explotar vulnerabilidades y actuar de forma maliciosa.

"El 70% de las instituciones financieras de las que sufrieron fraudes internos, fueron causados por empleados en el 2010” (Darksecurity). Lo que suele ocurrir es que muy pocas noticias salen a la luz pública, aunque alguna que otra, se conoce: Hubo un caso en España, que un empleado incrementaba su nómina un día antes de emitirse (accediendo a la base de datos), y una vez emitida, restablecía el importe para que pasara inadvertido. Pasó mucho tiempo para que fuera descubierto.A pesar de que el número de ataques externos e internos son semejantes en número, el coste asociado a cada tipo de incidente de seguridad es significativamente diferente (57.000 dólares externos contra los 2.7 millones de dólares de daños por atacantes internos).

Otro ejemplo de Insiders (historia basada en hechos reales):
"Algo no iba bien en una empresa cuando detectaron mucho tráfico web proveniente de un país asiático (90%). Pero por todos era sabido que dicho comportamiento era anómalo, ya que la tendencia de visitas hacia dicha sección de la página web, debería estar monopolizada por las visitas desde Latinoamérica, donde se encontraban los principales clientes VIP.

Tras las primeras investigaciones acerca del suceso, se confirmó la gravedad del mismo. Los datos de los clientes, estaban disponibles a través de una simple búsqueda en Google. En las conclusiones del informe, los técnicos descartaron filtraciones externas ya que el problema estaba en el código fuente de la aplicación. Comparando el código desplegado en producción y la última versión del mismo disponible, había diferencias y es que aparecía una línea de código extra que volcaba el contenido de las variables correspondientes, con el nombre de usuario y el password cuando la sesión era validada con éxito, en un fichero, y con el tiempo, este fichero fue indexado por las arañas de Google y la información se hizo pública para cualquiera.”

DEFICIENCIAS DETECTADAS:

• La detección de la anomalía, fue muy a posteriori.
• Una vez detectado, la recopilación de los datos e información para el estudio de la misma, no fue de forma ágil y precisa, tardando mucho tiempo en obtenerla implicando a muchos recursos.
• No disponían de controles (en tiempo real) que alerten ante cualquier modificación del código desplegado en producción.
• Las auditorías black box que la compañía contrataba cada tres meses, no detectaron ningún problema de inyección en las variables de las credenciales, ya que no tenían visibilidad completa acerca de la actuación del aplicativo. El formulario de login fue analizado en múltiples ocasiones, y siempre mostró un comportamiento seguro.
• La compañía tenía implementado un sistema de revisión manual del código a lo largo del ciclo de vida del desarrollo seguro, pero éste no comprobaba si el código subido a producción, se corresponde con el previamente revisado en los repositorios de código.
• La periodicidad de las revisiones manuales no era suficiente como para detectar el problema de seguridad de manera proactiva.
• Primaron mas las necesidades y las presiones por poner en producción el site que la seguridad, sobre todo porque una revisión o auditoría tardaban semanas y retrasaban en lanzamiento.

RECOMENDACIONES

• Lo ideal sería automatizar en alto grado, los procesos de controlar y auditar los códigos fuentes y los binarios, antes de la puesta en producción verificando la integridad del código en base a las fuentes almacenadas en los repositorios.
• Las revisiones de seguridad deben ser rápidas y fiables para reducir el "time to market"
• Complementar este análisis de código con auditorías BlackBox y WhiteBox, siendo recomendable revisiones periódicas (lo que hoy no es vulnerable, puede serlo mañana)
• Usar soluciones o herramientas que permitan alertar y visualizar la alerta en tiempo real e incluso, se integren con con herramientas SIEM.

La solución de Indra I-SCode, detecta automáticamente cuándo lanzar auditorías de código fuente, y qué hacer en caso de alertas o falsas alarmas. En el caso que nos ocupa, I-SCode habría detectado una vulnerabilidad de log injection, en base a que las credenciales de acceso, eran redirigidas al fichero de texto sin validar y no hubiera permitido el paso a producción del código vulnerable, enviado alertas al visor y a las herramientas SIEM.

I-SCode permitiría haber evitado de forma automática, este incidente de fuga de datos, debido a los siguientes factores:

• Dispone de una serie de sensores-agentes distribuidos, que alertan ante cualquier modificación del código desplegado en los entornos del ciclo de vida del desarrollo, verificando la integridad del código entre entornos.
• Las alertas son mostradas en la consola web de I-SCode, y a su vez se envían al SIEM para que esta información pueda ser correlacionada con otros eventos de seguridad.
• Sin embargo I-SCode, no solo se limita a alertar de cambios en el código, sino que proactivamente, y de forma automática, lleva a cabo un análisis de seguridad del código afectado, de tal forma que junto a la alerta, llegará el informe del análisis de vulnerabilidad, para que se tenga toda la documentación y datos necesarios, para que la toma de decisiones sea ágil.

“Las organizaciones gastan millones de dólares en firewalls y dispositivos de seguridad, pero tiran el dinero porque ninguna de estas medidas cubre el eslabón más débil de la cadena de seguridad: la gente que usa y administra los ordenadores”. Kevin Mitnick, uno de los más famosos hackers de toda la historia, también apodado como el "fantasma de los cables".