Robusteciendo y auditando DB2

Hola,

En el mundo de la seguridad suelen darse situaciones en las que tratar de mejorar puede conducir, caso de errar, a obtener efectos adversos y perniciosos. Es el caso de aquellas infraestructuras críticas que requieren un férreo control de la seguridad, pero que a su vez, según crece el nivel de seguridad, sufren descensos del rendimiento que pueden hacer incurrir a los negocios en lucro cesante y en la necesidad de adoptar inversiones que pueden superar el coste de los impactos que se prevean, caso que materialicen los riesgos que se esté considerando mitigar.

Un ejemplo de estas situaciones de difícil balance lo protagoniza habitualmente DB2. La vara para medir el grado de seguridad deseado versus los impactos en los negocios y los costes de mitigación tiene que estar muy especialmente afinada, especialmente cuando corre dando soporte a core de negocio en un mainframe. En estos entornos, equivocarse puede costar millones de euros y daños irreversibles a la imagen y la reputación de los negocios que los utilizan, con lo que no son admisibles los errores.

La dificultad de sugerir medidas de seguridad y auditoría en DB2 estriba en la propia complejidad del producto y sobre todo, de las instalaciones donde habita. Instituciones financieras, compañías de seguros, instalaciones centrales de administraciones y gobiernos, control industrial de largo alcance … entornos lo suficientemente críticos como para que antes de determinar qué medidas se proponen se hayan considerado muy seriamente los impactos. No son entornos donde uno pueda llegar alegremente solicitando que se cifre la información de la base de datos, o sugiriendo que se activen a todo trapo los mecanismos de auditoría de lectura y modificación de datos. Recomendaciones drásticas e incompletas de este tipo tardan poco en caerse:

Consultor/auditor: Verá, es que sus datos no están cifrados. Solución: a cifrarlo todo, así nos aseguramos de que cualquier hacker bielorruso que entre en el perímetro de seguridad no pueda llevarse dato alguno.

Negocio/dueño del proceso: ¿Cuánto me cuesta la gracia? ¿en cuánto tiempo recupero la inversión? ¿cuántos euros dejo de ganar si no hago esto que Usted me dice?

Consultor/auditor: Esto, mmmm, aha …

—-

Consultor/auditor: Hay que activar para toda la base de datos los mecanismos de auditoría de lectura y modificación de datos, o de lo contrario, no sabrá quién ha leído un dato o lo que es peor: quién lo ha modificado.

Negocio/dueño del proceso:¿Y quién va a revisar los logs que Usted me dice que hay que generar? ¿Usted sabe que en un online genero 300 gigas de datos, y en un batch tera y medio? ¿cuántas personas tengo que meter en nómina para abordar el análisis? ¿Podría ver su estimación de perjucios económicos en caso de que, por no tener las auditorías activadas, alguien cambie una fecha de vencimientos de mis pólizas de seguros?

Consultor/auditor: Esto, mmmm, aha … (2)

Al hilo de la seguridad y auditoría en DB2, podéis echar un ojo al libro Securing and Auditing Data on DB2 for z/OS, en el que se exponen distintas maneras de abordar el problema no sólo con los mecanismos propios de DB2, sino también con la propia arquitectura de seguridad z/OS. Que nadie piense que el texto resuelve el eterno de problema de qué recomendar cuando auditemos un DB2 o cualquier otra base de datos de alta transaccionalidad, porque eso sólo puede determinarse con un estudio riguroso que enfrente riesgos, sus probabilidades de ocurrencia y la relación impacto-coste que entraña cada uno de los focos de exposición.

Un saludo,

3 comentarios sobre “Robusteciendo y auditando DB2

  1. Entiendo y comparto tus argumentos, pero los dos ejemplos son peligrosos pues si hablamos de bases de datos de carácter personal, coinciden con requisitos legales y las leyes en este caso, están para cumplirlas. Imagino que serán dos de las recomendaciones machaconas que debes ver pero su justificación viene dada por el R.D. 1720/2007.

    El auditor no puede relajar en sus observaciones aquellos hechos que suponen un incumplimiento legal. El Negocio/Dueño del proceso evidentemente deberá con el menor impacto económico y esfuerzo intentar buscar mecanismos de protección o de compensación, pero en cualquier caso, debe lograr que se cumpla lo que la legislación regula.

    Ahora, también tienes razón en que los consultores/auditores deben entender que el Negocio/Dueño de proceso quiera ir como estrategia a un cumplimiento de mínimos y solo hacer aquello que sea necesario para salvar todas las regulaciones que le afecten. Es cierto que muchos negocios empiezan a verse desbordados por las diferentes normativas regulatorias que están apareciendo: LOPD, PCI-DSS, Basilea II,Sarbanes-Oxley, etc.

  2. Muy buen post, es la primera vez que paso por aquí después de verte referenciado en SbD. La verdad es que tienes toda la razón del mundo. DB2, tanto en mainframe como en sistemas abiertos siempre es una espinita clavada para los que nos dedicamos a la seguridad.
    El redbook ya lo tenía pero parece que IBM ya no lo tiene online. Ningún enlace funciona en este momento, no sólo el tuyo.

    Saludos,
    Juanma

Comentarios cerrados.