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.