Cada vez se suman más regulaciones de seguridad. El tiempo de prepararte es hoy
No es un misterio el por qué la seguridad de IT se ha vuelto una prioridad para las empresas en los últimos años. De acuerdo a un estudio realizado por nuestro partner de negocios Precisely, profesionales involucrados en empresas con los sistemas IBM i – AS/400 afirman que la seguridad ocupa uno de sus principales lugares en sus prioridades de tiempos y presupuestos.
Uno de los motivos de mayor peso, es la constante exigencia y surgimiento de nuevas regulaciones de seguridad con las que las empresas deben cumplir dependiendo la industria o giro de operación. Cumplir con ellas para estar dentro de la regla cada vez es más complicado. Uno de los ejemplos más recientes es la adición de la regulación GDPR, un estudio llevado a cabo por EY, encontró que las compañías que tenían que cumplir con esta regulación llegaron a invertir en promedio 1.3 millones de dólares. Y a pesar de las grandes inversiones, cerca del 40% de las compañías fueron incapaces de implementar las medidas incluso un año después de haber comenzado a trabajar en ellas. Cuando no se está preparado en lo absoluto para cerrar brechas de seguridad, las regulaciones resultan un auténtico dolor de cabeza que deriva en pérdidas financieras considerables para cualquier compañía sin importar su tamaño.
Por ejemplo, la protección y privacidad de datos se ha vuelto una de las mayores preocupaciones para los gobiernos, lo que potencializa la posibilidad del surgimiento de nuevas regulaciones durante los próximos años; o en su defecto, adición de exigencias a las regulaciones ya existentes. Es cierto que es imposible predecir y conocer con exactitud cuáles serán las exigencias de las nuevas regulaciones que puedan surgir en algún futuro. Sin embargo, es posible darnos una idea y tomar decisiones con base en las regulaciones existentes que han surgido en los últimos años aunque no apliquen para la industria o giro de nuestra compañía. Es importante mencionar que cumplir con las regulaciones tampoco garantiza un 100% de inmunidad ante brechas de seguridad, generalmente son reglas aplicables a cierto tipo de operaciones; nosotros somos los únicos expertos que conocemos nuestras particularidades y debemos ser capaces de ver más allá sobre lo que puede y no puede representar un riesgo antes de que se nos exija cumplir con cualquier regulación.
Como se mencionó anteriormente, es imposible predecir o adelantarse a nuevas exigencias de regulaciones. No obstante, echando un vistazo a los actuales puntos que afectan estas regulaciones nos pueden orientar para detectar en nuestra operación potenciales riesgos. Hablando particularmente del IBM i – AS/400 (pero no exclusivamente), algunos de estos puntos serían los siguientes:
Actualmente hay soluciones de terceros que facilitan considerablemente las tareas de los administradores del sistema IBM i – AS/400, puesto que muchas de las brechas surgen por errores manuales y se pueden cerrar automatizando procesos. Este es un tema que tocamos a profundidad en un video que realizamos hace unos meses. Estas soluciones pueden ser muy útiles para asegurarse que las configuraciones de su sistema se alineen con los requisitos de diversas normativas. En otras palabras, si un administrador de IBM i tuviera que revisar manualmente que las configuraciones cumplan con las políticas, sería un proceso que consumiría mucho tiempo, ya que a menudo hay cientos, si no miles, de objetos y opciones de configuración dentro de un sistema típico; donde además de tiempo, existe la posibilidad del error humano. Estas herramientas ofrecen plantillas personalizables para monitorear que todo esté en orden y para generar alertas que se dirigen a personas clave en caso de que se produzca una desviación de las políticas. Pero las plantillas son solo el comienzo. La supervisión y auditoría exhaustivas del journal de auditoría del sistema IBM i y otros registros y colas también es esencial para lograr una seguridad sólida y mantener el cumplimiento.
Las regulaciones de cumplimiento como PCI DSS, HIPAA, 23 NYCRR 500 y otras requieren evaluaciones periódicas de riesgos para buscar y abordar de manera proactiva las vulnerabilidades de seguridad. Los entornos de TI no son estáticos y tampoco lo son las amenazas. Sin realizar evaluaciones periódicas de riesgos de seguridad que examinen de cerca los sistemas, las redes y los periféricos, las probabilidades de una infracción dañina aumentan sustancialmente. Las regulaciones pueden requerir que las evaluaciones de riesgos también incluyan pruebas de penetración que intentan violar las defensas de su sistema.
Algunas regulaciones también requieren una “separación de funciones” cuando se realizan evaluaciones formales de riesgos. Esto significa que la parte que evalúa el sistema no puede ser la misma parte que es responsable de administrar el sistema. Por lo general, esto significa contratar a un experto en evaluación de riesgos externo a la empresa cuyo único objetivo es mantenerse actualizado sobre las vulnerabilidades de TI y la naturaleza evolutiva de las amenazas externas. Por supuesto, al evaluar los riesgos de seguridad de IBM i, es importante elegir una entidad externa que comprenda las características únicas de la plataforma.
Como se mencionó anteriormente, es prudente que cualquier programa de seguridad integral de IBM i incluya evaluaciones de riesgos, independientemente de las regulaciones. Para IBM i, existen herramientas de terceros que pueden brindarle una ventaja en sus evaluaciones, ya que generalmente están diseñadas para comparar las configuraciones de su sistema IBM i con las mejores prácticas de seguridad conocidas y producir informes que contienen información procesable.
Los requisitos de ciberseguridad de las regulaciones de cumplimiento están escritos en gran medida para obligar a las empresas a implementar tecnologías y procesos que mantengan a los usuarios no autorizados fuera de los sistemas mientras mantienen un control estricto sobre lo que los usuarios autorizados pueden hacer una vez que inician sesión. Dentro de los entornos IBM i, control de acceso integral requiere tres estrategias defensivas.
Las contraseñas débiles y los perfiles de usuario inactivos crean una vulnerabilidad de seguridad significativa que se puede resolver fácilmente mediante la implementación de políticas de contraseñas sólidas y la administración de perfiles. Para fortalecer aún más el acceso de inicio de sesión, un número creciente de empresas está implementando la autenticación multifactor (MFA). A su vez, un número creciente de regulaciones, como PCI DSS, 23 NYCRR 500, HIPAA y otras, están agregando requisitos de múltiples factores para roles o situaciones específicas. En esencia, MFA requiere que los usuarios proporcionen uno o más factores de identificación, más allá de su nombre de usuario y contraseña normales, antes de que se otorgue el acceso. Sin embargo, MFA no solo se utiliza para controlar el acceso de inicio de sesión a los sistemas. La tecnología también se puede utilizar para controlar el acceso a bases de datos específicas, comandos e incluso archivos individuales. Para obtener más información sobre MFA, lea el documento sobre autenticación multifactor para IBM i.
Una cosa es evitar que usuarios no autorizados accedan a los sistemas, pero otra es controlar lo que los usuarios autorizados pueden acceder y ejecutar una vez que inician sesión. Muchas regulaciones requieren controles estrictos sobre los usuarios para garantizar que solo tengan la capacidad de realizar tareas en el sistema que se alinean con la descripción de su trabajo. El uso generalizado de perfiles potentes genera rápidamente señales de alerta ante los auditores de cumplimiento. Desafortunadamente, en IBM i es muy común que los usuarios de base tengan perfiles que brinden un nivel de autoridad muy alto. Estos incluyen capacidades peligrosas como *ALLOBJ, *SECADM, *JOBCTL y otras. Ciertamente, hay ocasiones en las que un usuario necesita legítimamente un alto nivel de autoridad para completar las tareas necesarias, pero en lugar de dar acceso con carta blanca, el enfoque más seguro es otorgar la autoridad necesaria de forma temporal y dentro de parámetros estrictamente definidos. Las herramientas de administración de autoridad elevada de terceros simplifican la concesión y revocación de autoridades temporales al tiempo que hacen un seguimiento de las acciones de los usuarios en posesión de una autoridad elevada.
Hace años, la simple administración de la seguridad a nivel de objeto podría haber sido suficiente para controlar el acceso a objetos en IBM i, pero hoy, dadas las muchas formas en que un sistema típico está conectado a redes internas y externas, se requieren muchas más. Primero, están los muchos puntos de acceso al sistema a través de protocolos de red que deben protegerse, incluidos FTP, ODBC, JDBC, OLE DB, DDM, DRDA, NetServer, etc. Luego, están las muchas formas en que se puede acceder a las bases de datos utilizando código abierto. protocolos, como JSON, Node.js, Python, Ruby, etc. Además de esto, hay varias formas en las que se puede acceder a los comandos y archivos de datos que eluden la seguridad tradicional a nivel de objeto.
La solución para proteger todos estos puntos de acceso es implementar programas de salida completos basados en reglas que controlen estrictamente una amplia variedad de puntos de acceso, pero que lo hagan de manera matizada. Los programas de salida pueden requerir una gran cantidad de trabajo para implementar y administrar, pero afortunadamente, existen soluciones de terceros que agilizan las tareas de creación, implementación y administración de programas de salida, al mismo tiempo que brindan la capacidad de activar alertas en caso de que se detecte una actividad sospechosa.
Numerosas regulaciones requieren que la información de identificación personal (PII), la información de la tarjeta de pago (PCI) y la información de salud personal (PHI) estén encriptadas. Estos incluyen PCI DSS, HIPAA, GDPR, GLBA / FFIEC, numerosas leyes estatales de privacidad y otras. Las tecnologías de cifrado utilizan uno o más algoritmos disponibles públicamente con una clave de cifrado patentada para transformar datos legibles por humanos en texto cifrado no legible. Solo los usuarios autorizados que posean la clave de cifrado adecuada pueden acceder a los datos. Si se produce una infracción y los datos están correctamente cifrados, algunas normativas proporcionan protección de “puerto seguro” para no tener que revelar la infracción.
El cifrado se basa en una gestión cuidadosa de las claves de cifrado para garantizar que los datos se mantengan debidamente protegidos. Si las claves caen en las manos equivocadas, sus esfuerzos de cifrado son en vano, razón por la cual varias normativas como PCI DSS, HIPAA, GLBA / FFEIC y otras también estipulan cómo deben administrarse las claves de cifrado.
Para IBM i, hay varias soluciones de terceros disponibles para cifrar datos tanto “en reposo” como “en movimiento”. El cifrado en reposo se aplica a la protección de campos confidenciales de la base de datos (como números de tarjetas de crédito) en unidades de disco y en medios de respaldo. El cifrado en movimiento se aplica a la protección de datos confidenciales a medida que se envían a través de las redes, ya sea como un flujo de datos o como archivos completos. Al enviar archivos, a menudo se utilizan soluciones de transferencia de archivos seguras de terceros, ya que no solo proporcionan cifrado, sino que también incluyen numerosas funciones que agilizan y automatizan los procesos de transferencia de archivos.
Algunas empresas pueden evitar el cifrado de datos confidenciales y aun así demostrar el cumplimiento mediante una tecnología llamada tokenización. El enfoque reemplaza los datos confidenciales, digamos en un servidor de producción, con valores sustitutos no confidenciales llamados “tokens”. Esto elimina de manera efectiva el servidor de producción del alcance del cumplimiento porque la relación entre los datos confidenciales y su token de reemplazo se mantiene en una base de datos en un servidor separado. Las regulaciones PCI DSS, por ejemplo, permiten el uso de tokenización para proteger la información de la tarjeta de crédito.
Numerosas regulaciones, incluidas SOX, PCI DSS, HIPAA, GDPR y otras, requieren algún tipo de registro de actividad del sistema y, a medida que surgen nuevas regulaciones, es seguro que muchas de ellas también incluirán un requisito de registro. Como se mencionó anteriormente en esta publicación, el monitoreo regular de los registros de auditoría del sistema y la base de datos es una medida de seguridad fundamental y esencial.
Además de QHST y las colas de mensajes del sistema, IBM i proporciona las poderosas e inalterables capacidades de registro por journal del sistema operativo. La combinación de auditoría de seguridad y registro de objetos de datos hace posible registrar y rastrear una amplia gama de actividades, incluida la autenticación de usuarios, acceso al sistema, cambios de datos, cambios de configuración de objetos y más. La desventaja de llevar un journal es que su producción es voluminosa y críptica. Es por eso que muchas empresas con IBM i utilizan soluciones de terceros que simplifican los procesos de análisis de journal para identificar eventos específicos, activar alertas cuando se detecta actividad sospechosa, crear informes para auditores de cumplimiento y más. Tenga en cuenta que muchas regulaciones requieren guardar diarios y otros registros del sistema durante varios años en caso de que sean necesarios para una auditoría o investigación de algún evento de seguridad.
Aunque un journal puede registrar muchos tipos diferentes de actividades, algunas empresas tienen datos especialmente confidenciales que requieren que los oficiales de seguridad y los administradores sepan si un usuario no autorizado accedió y vio dichos datos, independientemente de si se modificaron o no. Aunque el registro en diario no puede proporcionar esta información, soluciones como Assure Security hacen posible registrar estas actividades de visualización de la base de datos, junto con “capturas” de los datos precisos que el usuario vio.
La cantidad de vulnerabilidades y puntos a tomar en cuenta al momento de reforzar nuestros sistemas puede ser abrumadora. En Timware contamos con amplia experiencia en seguridad respecto a operaciones con sistemas IBM i – AS/400. Ayudamos a nuestros clientes a cerrar esas brechas de forma fácil y efectiva por medio de la solución de seguridad Assure Security. Esta solución hace posible el cumplimiento de cualquier tipo de regulación o adelantarse a cualquier potencial exigencia ya que es posible cerrar al máximo las brechas de seguridad que más preocupan a las empresas.
Tenga control total sobre la seguridad del IBM i y mantenga ese control de la forma más eficiente y escalable. Estamos disponibles para hablar sobre las necesidades o inquietud que pueda tener respecto a la operación de su IBM i – AS/400.
