El pasado 18 de Febrero se celebró el evento Ciberseguridad 2020 de IDG (https://eventos.idg.es/ES/Ciberseguridad)  donde The Whiteam asistió para acompañar a sus partners.

El evento puso de manifiesto tanto la complejidad de la gestión actual para un CIO/CISO del mundo de la seguridad informática como la creciente “mejora tecnológica” de nuestros nuevos socios de negocio, los hackers que atacan nuestros sistemas de información.

Nuevos medios de ataque a sus sistemas

El mundo era un lugar seguro, en los años 90 nuestros sistemas ERP estaban sólidamente protegidos en un CPD blindado, dentro de una red corporativa, varios muros de seguridad (incluso físicos) protegían nuestros vitales sistemas de información.

Un sistema SAP en los años 90 estaba perfectamente aislado del exterior, nuestra contabilidad, nuestros datos, nuestros procesos estaban protegidos de todo el peligroso mundo exterior, que no podía dañarnos.

Poco a poco nuestros sistemas dejaron de ser seguros, visto de un modo crítico, cada paso que hemos dado ha empeorado la situación:

1. Primero eliminamos el problema del acceso físico, concedimos acceso a nuestras redes a equipos ajenos a nuestra red.
2. Más tarde interconectamos “online” nuestros sistemas SAP con sistemas externos, dejamos expuestos nuestros servidores al exterior, si bien intentamos que las puertas estuvieran vigiladas (mediante por ejemplo el uso de firewall).
3. Para facilitar el trabajo a un ataque exterior automatizamos el mayor número posible de procesos, eliminamos el control humano en nombre de la eficacia y la velocidad de respuesta.
4. No contentos con todo ello, llevamos nuestros sistemas a una “nube virtual” donde ni siquiera sabemos dónde están con exactitud, delegamos el control del acceso (físico y lógico) en terceros.
5. Luego “destruimos” nuestras aplicaciones, en lugar de tener un solo sistema informático (por ejemplo, nuestro añorado SAP R/3) hemos construido “ecosistemas” de aplicaciones (SAP S/4, SAP C/4, Ariba, Success Factors, SAP Cloud, Salesforce, Qlik, SAS, Power BI, etc) de un modo que en ocasiones una ejecución de un proceso no pasa por un solo sistema, sino por una multitud de ellos multiplicando el número de puntos a proteger, haciendo una analogía es como si un señor feudal hubiera decidido que el mejor modo de proteger los habitantes de su castillo era enviarlos solos a puntos muy alejados entre sí, aniquilando los muros.
6. No contentos con exponer nuestros sistemas de producción, abrimos los entornos de desarrollo y el propio código fuente de nuestras aplicaciones, creando un modelo de modificación de aplicaciones donde equipos multidisciplinares modifican código en diversos sistemas de modo acelerado y continuo, dificultando la revisión del mismo.

Nosotros mismos hemos destruido las débiles defensas que nos protegían de un mundo exterior cada vez más agresivo y con mejores capacidades de ataque.

¿Es posible proteger el mundo actual de IT?

Por supuesto, igual que es posible atacar cualquier muralla es posible proteger cualquier entorno.

Empresa y hackers conviven en un mundo común donde ambos estudian las vulnerabilidades y las medidas de contención, buscando ambos donde están las brechas de seguridad posibles para aprovecharlas (los predadores) y para protegerse (las presas).

Los puntos (1 – Acceso), (2 – Interconexión) y (4 – Seguridad Cloud) anteriores son aspectos habitualmente conocidos por las organizaciones IT, para los que aplicamos soluciones de seguridad “de comunicaciones” y “ de infraestructura”. Son también los puntos más vulnerables y los ataques más comunes (Malware, ramsonware, virus, etc).

El punto (5 – Combinar aplicaciones) es una “maldición” impuesta por el mercado tecnológico. Todo director de TI querría volver a un sistema monolítico pero la realidad del mercado conduce a una situación donde no podemos impedir que un área de negocio exija conectar nuestro ERP con Power BI y Salesforce porque puede que dicha decisión sea fundamental para el negocio a pesar de los riesgos de seguridad, que por otro lado solo consisten en incrementar el perímetro de activos a proteger.

En esta serie de artículos vamos a comentar diferentes aspectos de la seguridad de sistemas SAP, comenzando por dos ejemplos basados en validación de procesos críticos y en la seguridad de los entornos de desarrollo distribuidos.

Validación humana de cambios relevantes.

Uno de los ataques más comunes es un simple phishing, solo con saber:

• El nombre de la persona de la organización responsable de los cambios de cuenta bancaria de proveedores.
• El nombre de un proveedor relevante
• Los datos de una persona con poder en la compañía
• Un ejemplo de plantilla de nuestros correos internos

Con esa simple información que pueden obtener de Linkedin en gran parte (obtener un correo de ejemplo es tan sencillo como pedir cualquier información por email a marketing) pueden enviar la orden de que los siguientes pagos se realicen a una cuenta bancaria comprometida desde donde el atacante pueda transferir el dinero a una cuenta en el extranjero.

Este ataque es muy común, y depende exclusivamente de la fortuna y dedicación de nuestro enemigo, y de la perspicacia (y tiempo para ejercerla) de nuestros empleados. En el correo no hay enlaces web, no hay ficheros ocultos, ningún antivirus o antispam nos defenderá. Si el atacante tiene la habilidad de elegir unos días de vacaciones del manager dejaremos al empleado sin la opción de verificar una orden muy concreta y potencialmente importante (si fuera real pagar correctamente a un proveedor crítico es crucial para el negocio).

Una solución para estos ataques (además de confiar en la habilidad humana o aislar de comunicaciones externas a los responsables de cambiar cuentas bancarias en este ejemplo) es establecer procesos de verificación automáticos sobre este tipo de información crítica, donde podamos involucrar a manager y empleado (idealmente un sistema de workflow) e incluso donde podríamos involucrar a nuestros proveedores (con un email de confirmación del cambio similar a los cambios de clave de Facebook o Google).

Proteger los entornos de desarrollo.

Hay dos causas que han convertido a nuestros entornos de desarrollo en vulnerables, la primera es endógena (hemos decidido externalizar tanto personal como sistemas de desarrollo por ahorros) y la segunda es exógena y tiene que ver con el punto (5) Combinación de aplicaciones, ya que, por ejemplo, en una infraestructura SAP actual desarrollamos código en diversos lugares (código HANA, código ABAP, código Java, código en SAP Cloud, etc) y en todos ellos los equipos de programación son diversos, distribuidos y heterogéneos.

Hay dos puntos de vulnerabilidad en los entornos de desarrollo:

• El primero es la dependencia de la seguridad del puesto de trabajo de cada uno de los desarrolladores, no necesitamos que el atacante sea una persona que trabaja para nuestra organización, solo necesitamos que los atacantes consigan vulnerar el equipo de trabajo de una de las personas del equipo de desarrollo, cuya lista hemos puesto a su disposición (de nuevo) en redes como Linkedin.
• El segundo punto de vulnerabilidad a superar, ya que el equipo de trabajo de nuestros desarrolladores no tiene en si mismo activos de nuestra compañía, es el propio código, el atacante necesita poder alterar el código de los programas que estamos cambiando para introducir su propio programa agresor, que ejecutaremos en nuestros propios sistemas sin que ellos tengan que tener en realidad acceso a los mismos.

Volviendo al ejemplo del cambio de cuenta bancaria, es técnicamente sencillo si podemos ejecutar código con suficientes privilegios programar una rutina (incluso de un solo uso) que esté diseñada para ejecutarse únicamente en el sistema de producción, localice nuestras partidas de proveedor pendientes de pago y actualice los datos bancarios de dichos proveedores.

En entornos de desarrollo estables, con poco volumen de cambios, equipos de desarrollo compactos y revisiones del código y cambios por parte de los propios desarrolladores es complicado que algo así pase inadvertido (no es imposible) pero en entornos de desarrollo con cambios continuos, volumen de cambios elevado y equipos de gran tamaño por el contrario no es extraño que cambios de código pasen sin revisión posterior.

El modo de protegernos de este tipo de agresiones es establecer protocolos de control de cambios, verificación de código y también sistemas de alerta con inteligencia para determinar posible código extraño por los datos que realiza cambios.