¿Son los desarrolladores SAP jefes de defensa?

Los desarrolladores de SAP trabajan en entornos empresariales críticos integrados y crean software que procesa datos con características de seguridad y requisitos normativos específicos.

Papel clave de los promotores

Los desarrolladores SAP desempeñan un papel clave en la configuración del panorama de seguridad de los entornos SAP. El desarrollo de código para modificar funciones SAP existentes o nuevas aplicaciones e interfaces puede ser un proyecto de desarrollo informático de cualquier complejidad. Estas personalizaciones son a menudo necesarias, pero pueden contener vulnerabilidades y reducir el nivel de seguridad del sistema global.

Muchas vulnerabilidades de seguridad en el entorno SAP se deben a la falta de requisitos, a decisiones incorrectas en el diseño del software y la selección de herramientas y a la falta de conocimientos sobre prácticas de programación seguras con los lenguajes y marcos de programación utilizados. Los desarrolladores crean, sin saberlo, múltiples vulnerabilidades, como el cruce de directorios, las vulnerabilidades de secuencias de comandos en sitios cruzados o los errores de control de acceso. Una sola vulnerabilidad puede exponer datos empresariales confidenciales o permitir que el sistema se vea comprometido por un atacante. En la situación actual, los desarrolladores crean nuevos riesgos de seguridad además de los beneficios de su trabajo. Los desarrolladores tienen amplias autorizaciones. Con amplios derechos de acceso, los desarrolladores pueden introducir inadvertida o maliciosamente puertas traseras, manipular datos críticos o eludir los controles de seguridad. A día de hoy, las listas de comprobación de las autorizaciones de transporte no suelen incluir una comprobación de defectos de seguridad o malware.

Si no se aplica la segregación de funciones y los desarrolladores tienen acceso sin restricciones a los entornos de desarrollo, prueba y producción, resulta especialmente interesante para los atacantes explotar estos accesos. Fuera del mundo SAP, el perfil de un desarrollador SAP se describiría como un desarrollador full-stack. En contraste con front-end y back-end, esto se refiere a los programadores que realizan una aplicación de forma independiente con la pila tecnológica disponible, desde la interfaz de usuario y las integraciones hasta la lógica empresarial.

En combinación con su conocimiento de los procesos, los desarrolladores de SAP utilizan la caja de herramientas de SAP para ofrecer miles de mejoras y personalizaciones cada día, proporcionando a los clientes de SAP un enorme potencial de innovación y ventajas competitivas. La caja de herramientas de SAP está creciendo y a menudo se espera que los desarrolladores de SAP dominen toda la gama, desde el mantenimiento de una aplicación SAP GUI heredada hasta el uso de elementos de Fiori y todo lo que hay entre medias. Cada uno de estos teclados tiene características de seguridad individuales que los desarrolladores de SAP deben tener en cuenta al utilizarlos para evitar vulnerabilidades e implementar correctamente los requisitos de seguridad.

Aprendizaje fatal

Rara vez se puede dedicar tiempo y recursos a esto: suele prevalecer una mentalidad de "aprender haciendo", con las consecuencias que ello conlleva. "Nunca habría pensado en un formato de entrega de software al oír el término 'transporte'", afirma el arquitecto de seguridad de software de un banco. A menudo, el resto de operaciones de TI y seguridad de la información desconocen por completo la frecuencia y el alcance del desarrollo de software que utiliza tecnologías SAP como plataforma de aplicación. Un arquitecto de software de un cliente lo describió una vez como el "elefante oculto" de su práctica de desarrollo de software.

Sin embargo, también ocurre que las iniciativas para controlar los procesos de desarrollo de software o mejorar la calidad y la seguridad no incluyen el desarrollo SAP y que los procesos y herramientas definidos a tal efecto no son aplicables al desarrollo SAP o lo son sólo parcialmente. Los errores en los desarrollos a medida y los complementos pueden causar problemas de seguridad considerables. Como todo lenguaje de programación, Abap y compañía también tienen características específicas que los desarrolladores deben tener en cuenta.

Patrón de error Abap

De las docenas de revisiones de código que he realizado en los últimos diez años, destacan especialmente los siguientes patrones de error:

• Insuficiente validación de entradas que conducen a vulnerabilidades de cruce de directorios, inyección SQL o inyección de código. Esto da lugar directa o indirectamente a la posibilidad de comprometer por completo un sistema SAP. Esto se debe a menudo a la falta de conocimiento sobre las características de seguridad del marco o API utilizado.

• Errores en el diseño y la aplicación de los controles de acceso, como la falta de comprobaciones de autorización o comprobaciones lógicamente incorrectas y una insuficiente separación de funciones en el diseño del almacenamiento o el tratamiento y la visualización de los datos. Esto puede dar lugar a una fuga de información confidencial o a que ésta se vea comprometida a nivel de transacción.
• Diseños de integración inseguros que, en última instancia, dan lugar a oportunidades de comprometer sistemas SAP productivos desde, por ejemplo, entornos de prueba y desarrollo o permiten otras formas de ataques de falsificación de solicitudes del lado del servidor.
• No se limpian las herramientas obsoletas y, por lo general, ya no pertinentes, ni las copias de aplicaciones SAP estándar en las que se han eliminado las funciones de seguridad o nunca se han aplicado las correcciones de vulnerabilidades de SAP.

Utilice "transacción de llamada" sólo con la opción "con comprobación de autoridad" (extracto de una directriz de desarrollo típicamente mala).

Paradigma del núcleo limpio

Incluso en el mundo SAP, la seguridad del software necesita directrices claras en combinación con un apoyo adecuado a los desarrolladores para poder cumplirlas. Las iniciativas de calidad y seguridad del código suelen fracasar por esto último. Ni la introducción de análisis de código fuente mejorados en comparación con las herramientas estándar ni las prohibiciones en las directrices de desarrollo harán que los desarrolladores de SAP tomen conciencia de la seguridad y de la experiencia necesaria en soluciones.

Una formación adecuada y unos folletos sensatos en forma de instrucciones son la base del cambio cultural necesario para que otras medidas y herramientas también surtan efecto. Pero, ¿puede un desarrollador SAP que utilice el paradigma "Clean Core" y herramientas como SAP Build y Joule seguir causando graves problemas de seguridad en el futuro? "Clean Core" propaga la separación de las extensiones y la funcionalidad central. Además del objetivo egoísta de poder migrar mejor a los clientes existentes a los servicios en la nube de SAP y familiarizarlos con ellos, los riesgos operativos durante las actualizaciones y migraciones se reducen significativamente cuando se utilizan correctamente.

Cerrar los defectos de seguridad

El uso de SAP Business Technology Platform (BTP) tiene como resultado una separación más estricta de la extensión propia del cliente del estándar SAP. Si se implementa bien, los posibles efectos de las vulnerabilidades típicas mencionadas anteriormente pueden reducirse o contenerse en gran medida, o pueden excluirse determinados defectos de seguridad, como las vulnerabilidades de traspaso de directorios. Las exigencias sobre la capacidad del desarrollador para implementar correctamente la seguridad y convertir los diseños originalmente orientados a las transacciones en una arquitectura de microservicios son considerables. Los desarrolladores de SAP son ahora también responsables de otras tareas de seguridad, como la creación de roles, la aplicación de nuevos conceptos para el registro de aplicaciones y la comprobación de componentes de software y bibliotecas dependientes en busca de malware y vulnerabilidades.

La verdad está en el código

En el modelo operativo clásico de SAP, estas son las tareas del administrador básico y de autorización. Con la programación nativa de la nube, también hay nuevos escenarios de amenazas a los que el desarrollador de SAP tiene que hacer frente. Por ejemplo, una denegación de servicio económica (EDoS), en la que se hace un uso indebido de la aplicación para utilizar los servicios y recursos de la nube hasta tal punto que no se pueden asumir los costes o se desactivan los servicios al alcanzar los valores máximos de consumo.

Deben comprender la caja de herramientas SAP disponible con sus funciones de seguridad y deben ser capaces de dominar conceptos para el análisis de seguridad de aplicaciones de software, así como crear modelos de amenazas e implementar contramedidas. Esto convierte al desarrollador SAP en un actor central y controlador de la seguridad informática de su entorno SAP.

En resumen, puede decirse que tanto las aplicaciones SAP nativas en la nube como las clásicas, ya sean desarrolladas por el cliente o por terceros, deben ser cuidadosamente comprobadas en cuanto a vulnerabilidades y cumplimiento de las normas de seguridad. El papel del desarrollador SAP está cambiando cada vez más, de implementador de requisitos funcionales a consultor que encuentra soluciones innovadoras, tiene en cuenta la seguridad y la protección de los datos, así como los requisitos de seguridad para el funcionamiento y la prestación de su aplicación desde el principio y examina su adecuada implementación.

Comprender la caja de herramientas SAP

Deben comprender la caja de herramientas SAP disponible con sus funciones de seguridad y deben ser capaces de dominar conceptos para el análisis de seguridad de aplicaciones de software, así como crear modelos de amenazas e implementar contramedidas. Esto convierte al desarrollador SAP en un actor central y controlador de la seguridad informática de su entorno SAP.