Guía fundamental para evaluar el nivel de seguridad de su IBM i – AS/400

by | Feb 13, 2020 | Seguridad

Si bien es cierto que el Sistema IBM i – AS/400 es uno de los más seguros en el mercado, siguen existiendo brechas que representan vulnerabilidades de seguridad que podrían derivar en problemas delicados costando varios miles de dólares. Pérdidas que duelen más porque se pudieron haber evitado. Estas brechas se pueden encontrar en cualquier lado, tanto de fuentes externas (ej. ataques directos) como en fuentes internas (ej. mal uso de la información por parte de los empleados). Encontrar estas vulnerabilidades y blindar su Sistema de forma proactiva requiere de un amplio análisis por medio de assessments (o evaluaciones) de los controles de seguridad.

Dados los nuevos panoramas con las regulaciones, hacer una buena evaluación de controles de seguridad para su IBM i se ha vuelto una tarea muy compleja que requiere un profundo conocimiento en el tema. Estas evaluaciones no sólo deben ser el punto de partida para entender la situación del Sistema IBM i, sino que también deberían hacerse de manera periódica para asegurar que las configuraciones se mantengan en los estándares deseados.

Un error común que puede dejar brechas de seguridad en su Sistema IBM i es creer que solamente con cubrir aspectos físicos y de red son suficientes para mantener su ambiente seguro.  Sin duda son de suma importancia y cumplen parte del objetivo; sin embargo, las vulnerabilidades más comunes vienen de configuraciones de sistema inapropiadas. A continuación hablaremos sobre los principales puntos que deben ser analizados en estas evaluaciones de seguridad.

seguridad_ibmi_as400-1

Configuraciones de seguridad en el IBM i

Existen algunas cuantas decenas de configuraciones en su IBM i relacionadas con la seguridad en los valores de sistema y en los atributos de red que deben ser evaluados. Realizar las revisiones de estas configuraciones a un alto nivel son esenciales para el análisis:

  • Nivel de seguridad: El valor de sistema QSECURITY controla el nivel de seguridad del servidor, este valor de Sistema debe estar configurado entre 40 y 50 para garantizar un entorno de ejecución seguro.
  • Configuración de contraseñas: Existen de valores de Sistema que le permitirán establecer reglas como atributos especiales y tiempo de caducidad para las contraseñas. Las configuraciones de estos valores (QPWD*) contribuyen a cerrar brechas que puedan generar fugas de información desde fuentes externas.
  • Nivel de auditoría: El valor de sistema QAUD* debe ser revisado para verificar que las auditorías se está llevando a cabo correctamente en su IBM i capturando la información en su journal de auditoría (QAUDJRN)

seguridad_ibmi_as400-2

Seguridad en la red

  • Puertos abiertos: Los puertos abiertos permiten acceso remoto a su IBM i, de igual forma funcionan como portales para sistemas externos. El análisis de estos puertos es necesario para asegurar que no hay sistemas o aplicaciones no deseados con acceso al Sistema.
  • Exit points: Evaluar los exit points tanto de redes así como de aplicaciones para detectar y cerrar brechas que puedan generar fugas de información hacia fuentes externas.
  • Servidores y aplicaciones web: El Sistema IBM i es capaz de soportar numerosos servidores web para hospedar y ejecutar aplicaciones “cliente-servidor”. Las configuraciones de cada uno de estos servidores web debe ser analizadas rigurosamente. Algunas de estas configuraciones podrían ser el cifrado de información o la autenticación necesaria para garantizar el acceso al IBM i.

seguridad_ibmi_as400-3

Perfiles de usuario

  • Distribución de usuarios poderosos: Siempre es importante estar supervisando constantemente los usuarios poderosos (que cuentan con numerosos permisos). No llevar control sobre los usuarios con altos privilegios representan un riesgo importante al ser propensos a sufrir abusos de autoridad por empleados que no deberían tener tantos privilegios en el IBM i.
  • Clases de usuario: Muy similar al punto anterior, es necesario limitar la cantidad de usuarios que puedan pertenecer a las diferentes clases de usuarios. La evaluación debe garantizar que los usuarios están asignados correctamente a la clase con razones válidas para calificar como SECOFR, SECADM, SYSOPR o PGMR, por decir algunos ejemplos.
  • Capacidades limitadas: También es necesario restringir las capacidades de los usuarios para asegurar que ciertos perfiles solamente puedan trabajar desde la línea de comando, en ciertas librerías o programas dependiendo del rol del empleado.
  • Usuarios inactivos y deshabilitados: Este tipo de usuarios representan un riesgo ya que tienen la posibilidad de ser reactivados por error o por malas intensiones. Es necesario tener un control riguroso sobre los usuarios de empleados que dejan la compañía o de usuarios que se crean por motivos de pruebas. Establecer un periodo de tiempo máximo para que existan estos usuarios después de inhabilitarlos o de no tener actividad ayudará a reducir vulnerabilidades.

seguridad_ibmi_as400-4

Seguridad de la información

Mientras que los puntos anteriores se pueden atacar por medio de configuraciones en el Sistema, este punto requiere ser solucionado por otros medios. Además de ser uno de los puntos más fuertes e importantes que deben ser priorizados para blindar su IBM i.

Información en sitio (at rest)

  • Object authority Se debe hacer una evaluación exhaustiva para asegurar que solamente los usuarios apropiados tienen acceso a determinada información y que las configuraciones de los archivos estén establecidos con parámetros *EXCLUDE
    • Configuraciones de autoridad pública para información sensible: Las configuraciones ideales para cualquier archivo con información sensible deben de estar establecidas AUT(*EXCLUDE).  Esto evitará por defecto que los usuarios no cuenten con permisos de *ALLOBJ tengan acceso a estos archivos.
    • Listas de autorización: Es necesario revisar la lista de usuarios autorizados para tener acceso a información sensible.  Los comandos Display Object Authority (DSPOBJAUT) y Display Authority (DSPAUT) mostrarán a todos los usuarios que tengan estos accesos.
    • Grupos de perfiles de usuarios: No hay que perder de vista que los grupos de usuarios comparten los mismos permisos de acceso. Para poder revisar esta información es posible utilizar el comando Display User Profile (DSPUSRPRF) y el parámetro TYPE(*GRPMBR).
  • Cifrado y tokenización: En IBM i a menudo se cifra la información transformando el texto normal en cadenas de texto ilegibles como medida de seguridad. También es posible sustituir de forma temporal ciertos valores con tokens para enmascarar la información. Para cualquiera de los dos métodos, es indispensable tener un control riguroso de la administración de las llaves para descifrar la información.

Información en movimiento (in motion)

Muchas aplicaciones intercambian información de su IBM i en diferentes redes por cuestiones de proceso o almacenamiento. Cuando la información sensible es enviada por medio de una red, es fundamental que viaje cifrada para que no sea interceptada por intrusos mientras se transfiere. En la evaluación se deben analizar todas las aplicaciones que transfieran información tanto en redes internas como externas, de igual forma se debe validar que se utilicen protocolos con altos estándares de seguridad (TLS 1.2 o superiores) así como el uso de algoritmos de cifrado de alta calidad; una buena referencia es que cumplan con los estándares de el NIST (National Institute of Standards of USA).

Determinar qué tipo de protocolos de red y qué algoritmos de cifrado utilizar no es una tarea sencilla y probablemente serán necesarios servicios externos para evaluar las aplicaciones. Existen algunas aplicaciones como WireShark que pueden facilitar la evaluación de configuraciones de seguridad de red.

seguridad_ibmi_as400-5

Seguridad de las aplicaciones

Determinar que sus aplicaciones son seguras implica un reto desafiante al momento de hacer la evaluación. Algunos de los puntos que se deben responder al momento de analizar son:

  • ¿Qué nivel de autoridad tienen las aplicaciones sobre los objetos que manipula?
  • ¿El programa adopta la misma autoridad del dueño del programa?
  • ¿La información de la aplicación debe estar cifrada o protegida de alguna forma?

Para entender completamente el nivel de seguridad de una aplicación se recomienda hacer pruebas de penetración para intentar “burlar o romper” la seguridad de la misma. Este tipo de pruebas deberían ser realizadas por proveedores externos para evitar sesgos en los resultados.

¿Cómo puede ayudar Timware?

Realizar un análisis detallado de seguridad de su IBM i – AS/400 es una tarea complicada que puede representar para su empresa una inversión significativa de tiempo y de recursos humanos. Sin embargo, en Timware contamos con Assure Security, una solución sumamente robusta capaz de realizar esta evaluación y cuenta con módulos especializados para atacar cada uno de los puntos mencionados en esta guía.

Gracias al módulo de Security Risk Assessment es posible tener visibilidad de todas las fortalezas y debilidades de su IBM i en cuanto seguridad se refiere. El análisis que obtendría de su sistema sería como se muestra en este ejemplo. Con base en este análisis, que se puede llevar a cabo totalmente sin costo (por primera vez), será posible determinar si alguno de los siguientes módulos pudiese ayudar a cerrar brechas de vulnerabilidad en su Sistema:

Contáctanos y hablemos más sobre lo que necesita tu compañía: