Su intención es que se reduzcan los desabastecimientos provocados por la pandemia de covid-19.

Fuente: https://www.expansion.com/empresas/tecnologia/2020/03/12/5e6a0e07468aeb2a248b45aa.html

La entrada SAP libera el acceso a ARIBA tres meses por el coronavirus se publicó primero en The Whiteam.

LA SEGURIDAD, UN PROCESO CONTINUO.

La seguridad de sus sistemas de información no es una intervención puntual para solucionar incidencias eventuales, sino que debe considerarse como un proceso de gestión continuo, donde se verifique las novedades conocidas y las mejores prácticas de gestión de sus sistemas internos de SAP.
Whiteam ofrece a sus clientes el servicio WHITEAM SAP SECURITY SERVICE como ayuda para garantizar la mejor securización y máxima disponibilidad de sus sistemas de información, confíe en nuestros expertos para gestionar las amenazas y verificar la validez de sus instalaciones SAP en cualquiera de sus entornos de aplicación.

Nuestro servicio le permitirá disponer de un soporte especializado sin coste inicial, donde le ayudaremos a gestionar la verificación, el proceso de mejora, la planificación de cambios y la implantación de los mismos.
Colaboraremos con sus responsables técnicos y partners de negocio para ayudarles a garantizar del mejor modo posible la seguridad y funcionamiento de sus entornos de negocio.

SERVICIO SIN COSTE INICIAL

Whiteam ofrece el servicio sin coste inicial, su organización no tendrá que asumir coste si no hay amenazas que gestionar ni medidas correctivas que asumir.

Whiteam se responsabiliza de la revisión y análisis de sus infraestructuras SAP, control de las novedades comunicadas por SAP a sus clientes y determinará cuando existen riesgos o medidas correctoras que aplicar.

Whiteam aplicará el ciclo PDCA (Plan, Do, Check, Act) para gestionar la seguridad de sus sistemas de información SAP determinando cuando ocurren situaciones que representan un riesgo potencial a su seguridad, calibrando la urgencia del mismo y entregando el plan de medidas a ejecutar sobre sus sistemas.

SERVICIOS INCLUIDOS

Whiteam se responsabiliza de la revisión de los informes EWA de SAP, la verificación de las notas de seguridad y la validación de la configuración según la aplicación de las mejores prácticas de seguridad recomendadas por SAP a sus clientes.

Nuestro equipo de expertos revisará periódicamente la situación de sus sistemas notificando de cualquier incidencia y de los pasos que se deben dar para resolverla, así como el impacto en sus aplicaciones de negocio para validar con todos los equipos involucrados el impacto de los cambios y los riesgos incluidos en el mismo.

El servicio incluye la gestión de incidencias de seguridad relacionadas con la base de datos de sus sistemas SAP y los sistemas operativos de los servidores de aplicación y base de datos existentes.

COSTE LIGADO A LA INTERVENCIÓN SIN COMPROMISO (1)

Como cliente usted solo asume los costes de los trabajos para resolver las incidencias de seguridad, que serán notificadas previamente para la autorización de la intervención, podrá cancelar en cualquier momento el servicio de gestión sin compromiso de permanencia.
Nuestro servicio es compatible con la gestión continua de sus propios técnicos y de otros proveedores de servicios que su organización tenga contratados (outsourcing, hosting, etc).
Requisitos:

• Disponibilidad de acceso remoto a sus sistemas.
• Disponibilidad de SAP Solution Manager y conexión con SAPNET.
• Disponibilidad de contrato de soporte SAP Enterprise Support.
• Condicionado a validación previa de la instalación.

CONTACTE CON NOSOTROS

No espere más, mejore la seguridad de sus sistemas SAP con nuestra colaboración.

The Whiteam Consulting
SAPSECURITY@TWTSPAIN.COM
INFO@TWTSPAIN.COM

CONFÍE EN WHITEAM PARA EL SOPORTE DE SUS SISTEMAS SAP

(1) Este servicio se ofrece sin coste inicial con el objetivo de mejorar la seguridad de sus sistemas SAP y SAP HANA, contacte para conocer las condiciones económicas.
SAP y los productos SAP mencionados, así como los logos y marcas registradas son propiedad de SAP SE o de sus afiliadas.

La entrada WHITEAM SAP SECURITY SERVICE se publicó primero en The Whiteam.

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.

La entrada Seguridad en SAP en un mundo cloud (I) se publicó primero en The Whiteam.

El documento accesible desde la web de AUSAPE es un interesante resumen de los aspectos relevantes para el reto de liderar la migración a SAP S/4 HANA en las organizaciones.

SAP S4HANA Practical Guide

Si hay problemas con el enlace os sugerimos solicitar ayuda a info@twtspain.com

La entrada SAP S4HANA Practical Guide se publicó primero en The Whiteam.