En el art铆culo anterior contamos mucho sobre la seguridad de los sistemas ERP. Ahora queremos hablar sobre formas de protegerlos.
La protecci贸n de los sistemas ERP es un desaf铆o. Un buen proyecto integral puede tardar a帽os en completarse, especialmente cuando se trata de grandes paisajes. Sin embargo, vale la pena las inversiones. Estos son algunos pasos b谩sicos que lo ayudar谩n a dise帽ar de manera segura su implementaci贸n de SAP cuando se encuentre en la etapa de planificaci贸n. Tambi茅n puede aplicar esta metodolog铆a para proteger sus sistemas de los ataques m谩s comunes.
1. Proteger de ataques externos, deshabilitar servicios inseguros
Cualquier aplicaci贸n m谩s o menos compleja tiene una gran funcionalidad que se necesita en general, pero innecesaria en casos particulares. Casi toda esta funcionalidad en un sistema ERP t铆pico est谩 habilitada de manera predeterminada.
Como de costumbre, la instalaci贸n de SAP incluye aproximadamente 1500 diversos servicios web, que est谩n disponibles de forma remota en nombre de cualquier usuario registrado, si el servicio est谩 habilitado de forma predeterminada. Adem谩s, alrededor de 40 servicios son accesibles incluso para usuarios an贸nimos. Algunos trabajos de investigaci贸n se帽alaron 13 servicios cr铆ticos. Como se mencion贸 anteriormente, estos son solo servicios b谩sicos.
Recomendamos que aplique las recomendaciones de la gu铆a mencionada anteriormente lo antes posible: deshabilite todos los servicios accesibles para usuarios an贸nimos, analice cu谩les de los servicios instalados son necesarios y, adem谩s, restrinja el acceso mediante la implementaci贸n de verificaciones de autorizaci贸n.
La arquitectura del sistema SAP debe incluir un proxy basado en la web (SAP Web Dispatcher) que restringir谩 el acceso a todos los servicios innecesarios desde el exterior y permitir谩 el acceso solo a los necesarios.
El despachador web de SAP se encuentra entre Internet y su sistema SAP. Es el punto de entrada para las solicitudes HTTP (s) en su sistema, que consiste en uno o m谩s servidores de aplicaciones SAP NetWeaver. El Web Dispatcher de SAP, por lo tanto, contribuye a la seguridad y equilibra la carga en su sistema SAP.
Puede encontrar informaci贸n adicional sobre SAP Web Dispatcher aqu铆 .
2. Aplicar los principios de SoD
Las soluciones de SAP tienen varias oportunidades funcionales, que se implementan a trav茅s de programas, transacciones e informes. El acceso a estos objetos debe estar estrictamente regulado en funci贸n de los valores de autorizaci贸n que definen usuarios, m茅todos y objetos, permitidos para el acceso. El acceso a acciones cr铆ticas (por ejemplo, derechos de acceso para modificar transacciones o leer cualquier tabla) permite a los usuarios realizar ataques en los sistemas SAP, escalar sus privilegios o robar datos cr铆ticos.
La segregaci贸n de deberes (SoD) es un m茅todo de seguridad para evitar conflictos de intereses, es decir, para evitar dos o m谩s derechos de acceso que, otorgados en conjunto, pueden dar lugar a un riesgo de acciones fraudulentas (por ejemplo, un derecho a crear y aprobar una orden de pago).
El primer paso es minimizar el n煤mero de usuarios con perfil SAP_ALL o aquellos que tienen acceso a transacciones cr铆ticas como SE16, SM59 y SE38. Como siguiente paso, aplique controles SoD, al menos los mencionados en las pautas de ISACA .
3. Separe el desarrollo de la prueba y verifique las vulnerabilidades
Para protegerse de los desarrolladores maliciosos, primero, dise帽e la separaci贸n entre el desarrollo de prueba y la infraestructura de producci贸n y luego controle todas las solicitudes de transporte desde el desarrollo hasta la producci贸n. Parece f谩cil; Sin embargo, la cuesti贸n es qu茅 debe controlarse exactamente. Para separar de forma segura el arquitecto entre los sistemas de desarrollo y producci贸n de prueba, debe asegurarse de que no haya conexiones con credenciales almacenadas de sistemas con alta prioridad (sistemas de producci贸n) a los sistemas con baja prioridad (sistemas de desarrollo). Estas conexiones solo pueden almacenar la configuraci贸n de conectividad t茅cnica y autenticar al usuario para cada acceso.
Como ya sabr谩, OWASP (Proyecto de seguridad de aplicaciones web abiertas, enfocado en mejorar la conciencia en la seguridad de aplicaciones web) proporciona su lista de las 10 vulnerabilidades m谩s peligrosas que afectan a las aplicaciones web. Cuando tratamos con aplicaciones empresariales, no es una tarea tan trivial comprender qu茅 problemas debemos verificar. Afortunadamente, existe EAS-SEC (eas-sec.org), una organizaci贸n sin fines de lucro destinada a aumentar la conciencia en el espacio de seguridad de aplicaciones empresariales. EAS-SEC consta de proyectos separados y uno de ellos cubre la seguridad del c贸digo. Se llama Gu铆a de desarrollo de aplicaciones de sistemas de aplicaciones empresariales, o EASAD. Esta gu铆a describe 9 categor铆as generales de problemas de c贸digo fuente para idiomas de negocios.
Categor铆as:
- Inyecciones (C贸digo, SQL, OS)
- Llamadas cr铆ticas (a DB, a OS)
- Comprobaciones de control de acceso faltantes o incorrectas (autenticaci贸n faltante, errores)
- Recorrido del directorio (escritura, lectura, SMBRelay)
- Modificaci贸n del contenido visualizado (XSS, CSRF)
- Puertas traseras (credenciales codificadas)
- Canales encubiertos (sockets abiertos, llamadas HTTP, SSRF)
- Divulgaci贸n de informaci贸n (usuarios codificados, contrase帽as)
- Declaraciones obsoletas (READ TABLE, m茅todos del n煤cleo)
Estas categor铆as son universales y las mismas para la mayor铆a de las aplicaciones comerciales como SAP, Oracle, Microsoft Dynamics e Infor y sus lenguajes personalizados.
Un proceso de desarrollo seguro debe incluir al menos la comprobaci贸n de vulnerabilidades de c贸digo de estas nueve categor铆as.
4. Conexiones seguras
A medida que cada sistema est谩 conectado con otros, es esencial comprender qu茅 sistema puede ser atacado, c贸mo SAP est谩 conectado con otras aplicaciones empresariales, c贸mo un atacante puede escalar privilegios y qu茅 activo debe proteger al principio. Deber铆amos analizar qu茅 sistema es el m谩s importante y comenzar a resolver problemas en ese sistema en particular.
En primer lugar, debemos asignar gravedad a cada activo. Luego, analice las conexiones entre los activos, sean o no seguros, y finalmente priorice los activos por su impacto general en la seguridad del paisaje en general. Por ejemplo, tiene un activo de bajo riesgo, por ejemplo, un sistema de prueba sin datos cr铆ticos. Este sistema tiene una conexi贸n con el sistema de producci贸n, y este sistema de producci贸n, a su vez, tiene una conexi贸n con la infraestructura de ICS. Teniendo en cuenta todas las conexiones, este sistema de prueba puede tener un alto impacto en todo el paisaje y deber铆amos preocuparnos por su seguridad.
Adem谩s de los mecanismos de un servidor de aplicaciones, los servidores a menudo pueden conectarse con otros mecanismos. Por ejemplo, las soluciones SAP pueden instalarse en servidores Windows, que son parte de un solo dominio y se ejecutan con privilegios de una cuenta com煤n. En este caso, obtener acceso a un servidor casi siempre significa acceso a todos los dem谩s servidores, sin importar cu谩n adecuadamente est茅n protegidos a nivel de aplicaci贸n. Tambi茅n es posible cuando se implementan enlaces o conexiones confiables a trav茅s de DBMS . DBMS a menudo almacena referencias a otras bases de datos con datos de autenticaci贸n predefinidos, lo que hace que otros DBMS sean accesibles. Adem谩s, el alcance de tales mecanismos incluye cualquier otro m茅todo posible para penetrar en el sistema vecino, que los auditores suelen usar en las pruebas de penetraci贸n, es decir, un intento de iniciar sesi贸n en un sistema vecino con las mismas contrase帽as o similares, tanto en el sistema operativo, DBMS y niveles de aplicaci贸n , as铆 como todo tipo de b煤squeda de contrase帽as en texto plano en el sistema de archivos; actualizaci贸n, integraci贸n, scripts de respaldo, etc. Todas estas opciones deben verificarse para eliminar cualquier riesgo de penetraci贸n con un enlace d茅bil a todos los sistemas.
Otro riesgo de conexiones inseguras es la fuga de datos. SAP Systems debe cifrar los datos mientras los transfiere. Est谩 claro que el tr谩fico HTTP debe estar protegido por SSL, pero la mayor parte del tr谩fico se transfiere utilizando los protocolos patentados de SAP que son inseguros por defecto, como RFC (Protocolo para conectar sistemas SAP), DIAG (Protocolo para conectar el cliente SAP con el Servidor SAP) y el protocolo del servidor de mensajes. Desafortunadamente, no hay forma de asegurar el tr谩fico del servidor de mensajes; por lo tanto, simplemente poner este servicio bajo el firewall ser谩 la 煤nica opci贸n. En cuanto a los protocolos DIAG y RFC, el cifrado se puede implementar a trav茅s de SNC.
El SNC sin capacidad de inicio de sesi贸n 煤nico est谩 disponible para todos los clientes de SAP NetWeaver para la GUI de SAP utilizando el cifrado del cliente SNC y para todas las comunicaciones de RFC entre servidores SAP. Las capacidades b谩sicas de inicio de sesi贸n 煤nico est谩n disponibles en entornos donde los servidores SAP y los clientes de la GUI de SAP ejecutan Microsoft.
Resumen
La seguridad ERP es una tarea compleja. Sin embargo, solo tomar estos 4 pasos de alto nivel puede mejorar significativamente el nivel de seguridad de su sistema ERP. Solo despu茅s de implementar la arquitectura de forma segura, tiene sentido tomar medidas adicionales, como la gesti贸n de vulnerabilidades y la respuesta a incidentes.