Con la tecnología avanzando a un ritmo cada vez mayor, los desarrolladores se enfrentan más que nunca al desafío de mantener el código seguro y mitigar las amenazas de ciberseguridad cada vez mayores. Pero el uso de ejemplos recopilados a lo largo de más de 20 años de trabajo en el campo muestra que siempre ha habido obstáculos que superar.
El mainframe de IBM
La codificación de mainframe de IBM consistía en escribir programas COBOL/PLI programados para ejecutarse como procesos por lotes durante la noche para leer/actualizar grandes bases de datos jerárquicas complejas. Resource Access Control Facility (RACF) administró el acceso de los usuarios a los recursos críticos, con un modelo de seguridad que se basó en el principio de privilegio mínimo. El uso de una cuenta con el nivel de acceso correcto era esencial para evitar que las ejecuciones de trabajos se detuvieran o fallaran debido a que la cuenta de usuario no tenía el acceso adecuado para leer o escribir en una rama de la base de datos.
Servidor de cliente
El siguiente paso fue el desarrollo front-end utilizando el lenguaje orientado a objetos Smalltalk-80 para generar órdenes de compra almacenadas en una base de datos IBM DB2. Sin seguridad incorporada, Smalltalk promovió la encapsulación: los objetos encapsularon el estado interno y la seguridad de los datos se protegió mediante el control del flujo de datos entre los objetos. El flujo de información utilizó un protocolo para desarrollar niveles de seguridad en los que residen los objetos; la información podría pasarse a un objeto en un nivel más seguro, pero no a uno en un nivel menos seguro.
SAP Dynpro
A esto le siguió el desarrollo de SAP Dynpro usando ABAP. Los códigos de transacción y los perfiles de autorización estaban a la orden del día, y se esperaba que los desarrolladores agregaran las comprobaciones adecuadas en el código para probar si una cuenta de usuario tenía el perfil de autorización correcto para acceder a la aplicación, leer/escribir en la base de datos, etc. erróneo vio al usuario final confrontado con indicaciones de “No autorizado” o se le dio demasiado acceso para que su actividad nunca fuera cuestionada.
2017 fue un momento decisivo para las empresas que utilizan SAP luego de un caso judicial de alto perfil que planteó el concepto de acceso indirecto a los sistemas SAP. Con frecuencia se usaba una única cuenta de servicio (a menudo con acceso SAP_ALL) para todas las llamadas de función remota/acceso remoto (RFC), y los desarrolladores conocían las contraseñas de estas cuentas. Las empresas volvieron rápidamente a cuentas individuales para cada aplicación.
desarrollo web
SAP Enterprise Portal (WebDynpro Java/Java Server Pages) y SAP Web Application Server (WebDynpro ABAP) abrieron las puertas para el desarrollo basado en navegador en el entorno SAP. Desarrollar e implementar código Java requería una plataforma de desarrollo instalada localmente (Eclipse), y los desarrolladores necesitaban asegurarse de que la base de código fuera segura, con repositorios de código almacenados en unidades de red seguras con acceso restringido.
El detrás de escena de una aplicación web es complejo y muchos usuarios habrán experimentado mensajes de error HTTP. La solución efectiva de problemas requería conocimiento de la arquitectura y a nivel de red: balanceadores de carga, DNS, mapeo de puertos, servidores proxy inversos, navegación de dominio, certificados, etc. El uso de HTTP se usaba a menudo como predeterminado para facilitar el desarrollo de una aplicación, pero la seguridad era comprometida.
Las mejores prácticas del desarrollador deben garantizar que siempre se use un puerto HTTPS para el desarrollo web, con certificados firmados externamente y un nivel de cifrado estándar de la industria.
Inicio de sesión único (SSO) y autenticación multifactor (MFA)
La autenticación básica (ID de usuario y contraseña) pasó los detalles de la cuenta y la contraseña como parámetros visibles en las URL para simular SSO, haciéndolo vulnerable a la explotación; Por lo tanto, la adopción de tokens y certificados de inicio de sesión para habilitar SSO en las aplicaciones fue un cambio de juego.
Los tokens de Kerberos que contienen la identidad de un usuario se pueden usar para SSO en un sistema SAP local, que pasa las credenciales del usuario como una cookie para generar un ticket de inicio de sesión de SAP para iniciar sesión en varios otros sistemas SAP. Sin embargo, debido a que las cookies son vulnerables a la explotación, se prefieren los tickets de aserción de SAP, ya que están restringidos solo al sistema de destino y se pasan como un encabezado HTTP en lugar de como una cookie.
SAML 2.0 se ha convertido en un estándar abierto para la autenticación y autorización basadas en la web. El proveedor de identidad solo emite un token de inicio de sesión una vez que se ha confirmado la identidad del usuario, y este token SAML 2.0 se reenvía a la aplicación de alojamiento del proveedor de servicios. El uso de SSL, encriptación, validez de token restringida, etc. mitiga el exploit.
Desarrollo móvil y API
El desarrollo de API implica la transferencia segura de paquetes de datos entre sistemas, ya sea a través de RFC de sistema a sistema o servicios web y, a menudo, a través de capas de mediación de servicios o middleware adicionales.
Requiere comprender el viaje completo de la API, a menudo con paquetes de datos que se transforman desde el sistema de origen a un formato diferente que puede recibir el destino, así como el intercambio de tokens de identidad como SAML 2.0 a OAuth 2.0.
Para el desarrollo REST (uno de los servicios web más comunes), OAuth 2.0 utiliza ámbitos para permitir que una aplicación acceda a recursos en otros sistemas a través de la API web. Un alcance limita el acceso de los usuarios a las aplicaciones, por lo que un buen diseño de alcances como parte del modelo de autorización es esencial para garantizar el nivel de acceso correcto.
Cumplimiento del navegador y multidispositivo
Los navegadores más recientes tienen protecciones de seguridad cada vez mayores para mitigar las amenazas de seguridad cibernética. Las empresas que confían en el modo de emulación de navegador (es decir, emular versiones heredadas como IE 5) descubren que las aplicaciones web que se han ejecutado durante años dejan de funcionar en navegadores modernos como Chromium o Edge Chromium, y se requiere un trabajo de desarrollo no planificado para proteger el código.
El desarrollo móvil agrega otro elemento con datos fuera de línea almacenados en el dispositivo, lo que permite que una aplicación continúe donde la dejó si se pierde una conexión de red. ‘OData sin conexión’ y técnicas similares para lograr esto requieren que los desarrolladores se aseguren de que solo se almacene la cantidad mínima de datos en el dispositivo (para mantener el proceso lo más seguro posible) y que administren el ‘punto de sincronización’ para que una vez que se establezca una conexión. los datos restaurados se pueden cargar/sincronizar de forma segura a su fuente.
Integración/entrega/implementación continuas
Las empresas se esfuerzan por lograr una entrega de “proyectos ágiles” que permita tiempos de ciclo de vida de desarrollo más rápidos sin comprometer la calidad o la seguridad. La automatización del ciclo de vida de DevOps (a través de canalizaciones continuas de integración, entrega e implementación para revisiones de código por pares, compilaciones, implementación, pruebas, aprobaciones, ciclos de vida de migración de desarrollo a producción) se activa en el momento en que el desarrollador verifica el código en un repositorio de código.
Las herramientas de escaneo de código como Onapsis y SonarQube se pueden integrar como parte de una canalización de DevSecOps para escanear el código en busca de mejores prácticas de codificación segura, señalando vulnerabilidades en diversas bases de código, desde ABAP hasta XML.
Sin embargo, hay trampas. A menudo, los escaneos de código se optimizan a la última versión del código y una línea de código heredado se puede marcar como un riesgo. Para evitar una gran cantidad de falsos positivos, los umbrales deben configurarse para ignorar o establecer una advertencia para el código que es seguro pero está escrito con una técnica obsoleta. Las alertas ayudarán a desarrollar mejores estándares de codificación en los equipos de desarrollo para minimizar las infracciones de DevSecOps.
Mas de lo mismo
Mantener la codificación segura siempre ha presentado desafíos. La mayoría de estos se han superado con una combinación de tecnología y experiencia humana, un modelo que debe continuar.