La importancia del conocimiento técnico en auditorías de sistemas técnicas

Hola,

Aprovechando que el benchmark de AIX ha sido actualizado recientemente, traigo a portada un recordatorio acerca de una fuente de recursos bastante interesante auspiciada por el Center for Internet Security (CIS) que nos va a venir muy bien para insistir en un hecho que puede darse en el mundo de la auditoría TI.

Además de los benchmarks, el CIS tiene herramientas y métricas, aunque yo siempre me he centrado en lo primero. No quiero llamarlos checklists o pasos de auditoría porque en el fondo no lo son. La esencia de un benchmark de seguridad es proporcionar para un elemento determinado la configuración de seguridad recomendada, así como posibles consecuencias de la no observación de la misma. Obviamente, construir un programa de trabajo a partir de un benchmark no es tan complicado, pero requiere un conocimiento de la materia profundo, y este es un factor que podrían pasar por alto aquellos que se dedican a la auditoría de sistemas. Veamos un ejemplo.

Lo que dicen los checklists/benchmarks/etc

En el apartado 4.1 del benchmark de AIX que hemos comentado se recomienda desactivar los core dumps. Se ofrecen pautas de resolución y una somera explicación sobre el porqué.

Lo que debería conocer y aplicar el auditor

En esencia, un core dump es un volcado en el que queda registrado el estado de la memoria en una franja de tiempo determinada, usualmente cuando se produce un fallo catastrófico de uno o varios procesos. Lo primero es lo primero: saber de qué estamos hablando.

Los auditores deben siempre, de manera inexcusable, asociar sus recomendaciones al riesgo. Si no hay riesgo, es absurdo escribir recomendaciones de auditoría. Es por tanto que si analizamos un AIX, malos auditores seremos si enfocamos la recomendación de desactivación de los core dumps por el mero hecho de que lo dice el CIS o algún otro checklist. Hay que fundamentar la recomendación, estableciendo un nexo fundado entre las excepciones y los riesgos que derivan de las mismas. En este ejemplo que nos ocupa, habría que estudiar al menos:

• La probabilidad y el impacto EN EL NEGOCIO de que un core dump incluya datos sensibles que puedan provocar otras incidencias (acceso ilegítimo a información de negocio, obtención de contraseñas, etc.)
• La probabilidad y el impacto EN EL NEGOCIO de que el forzado malintencionado de volcados provoque DoS local y/o replicado en la red por agotamiento de almacenamiento y/o procesos I/O.

Cuando marcamos en negrita EN EL NEGOCIO queremos recordar que aunque hagamos una auditoría técnica, los impactos relevantes son los del negocio y no los puramente técnicos. Que el balanceador de carga de una VLAN sufra problemas de rendimiento por culpa de los core dumps NO ES un impacto en el negocio. Un impacto en el negocio es, por ejemplo, que por culpa de un mal rendimiento ocasionado por los core dumps tengamos un problema en la tesorería, no podamos operar los sistemas de asset management fluidamente y dejemos de colocar en el mercado 5 millones de euros en derivados. Nótese la diferencia.

Una vez fundamentada la recomendación conviene también prepararse para poder ayudar a la resolución y poder afrontar la discusión de las incidencias detectadas con garantías. El auditor, aunque no reflejará en el informe los pasos exactos para resolver el problema, ya que eso es dominio del auditado, si tendrá en la recámara argumentos para la discusión. Si alguien nos pregunta cómo desactivar los volcados, demostraremos conocimiento y solvencia indicando que lo más razonable es añadir una línea core_hard = 0 al fichero /etc/security/limits en la instancia correspondiente. Adicionalmente expondremos que sería conveniente añadir limitaciones a los perfiles de usuario desde las variables de entorno, como por ejemplo dejar el tamaño del corefile en cero (echo «ulimit -c 0» >> /etc/profile) y acometer cambios a nivel dispositivo, por ejemplo haciendo que los atributos para la permisividad de core dumps completos impidan los volcados (chdev -l sys0 -a fullcore=false)

La importancia de combinar el conocimiento técnico en nuestras recomendaciones técnicas

Ejemplos como el anterior deben hacernos reflexionar sobre la conveniencia de que las recomendaciones técnicas sólo dben hacerse cuando se tiene un conocimiento técnico profundo y suficiente. Por tres motivos, principalmente:

• En primer lugar por una cuestión de respeto y compañerismo. Auditar implica que la gente dedique tiempo valioso a atenderte, tiempo que necesitan para sus quehaceres. Si vamos a pedirles su tiempo, y probablemente a romper sus esquemas de trabajo, lo mínimo que podemos hacer es procurar no hacerles perder el tiempo por culpa de nuestra incompetencia o inexperiencia. Hay que ser profesionales, y si no estamos preparados para ofrecer solvencia, es momento de retirarse y documentarse.
• Por otro lado, si no sabes de lo que hablas, a duras penas estarás cualificado para opinar. La profesión de auditor exige producir como resultado, entre otras cosas, una opinión de auditoría. Si no puedes opinar o tu opinión no está basada en hechos contrastados por carecer de conocimiento, no eres un auditor. Eres otra cosa.
• Por otro lado si no conoces bien la naturaleza técnica del problema y sus soluciones, ¿cómo pretendes evaluar las respuestas del auditado, el trabajo de tus auditores o el seguimiento a la resolución de un problema? ¿Vas a basarte sólo en la confianza, la intuición y que te cuenten unos y otros? Este es un terreno peligroso, porque igual que te puedes fiar de un equipo de auditoría solvente y acertar de pleno, puedes acabar siendo víctima de los cantos de sirena de un auditado que te engatuse y te venda respuestas que acabarás comprando habida cuenta de tu ausencia de conocimiento. Repito, terreno especialmente farragoso, ya que por norma general los auditados pertenecen a centros de coste distintos al de auditoría, y por tanto son ellos los que pagan con sus chequeras las incidencias que encontremos (en otras palabras, siempre tratarán de minimizar el gasto derivado de una auditoría, rechazando recomendaciones no fundamentadas, proponiendo soluciones que quizás no mitiguen la totalidad de los riesgos, negando acciones que podrían ser perfectamente ejecutadas, etc).

Motivos como los expuestos hacen extremadamente importante conocer bien el origen técnico de los problemas cuando vamos a auditar aspectos técnicos en un negocio. Es especialmente relevante que la ausencia de conocimiento tiene colaterales tremendamente peligrosos, como la fatiga de auditoría, el daño a la reputación y a la imagen de la unidad de auditoría que provocan las incidencias mal gestionadas por ambas partes y como no podía ser de otro modo, conflictos internos de diversa índole que a la larga no benefician a nadie. Tratemos de evitarlos.

Los checklists no te van a contar qué es un core dump y tampoco te contarán cómo manipularlos. No te dirán cómo se opera un AIX en condiciones normales de producción ni nada parecido. Tampoco te recordarán que cuando se negocia la resolución de una incidencia cabe la posibilidad que te quieran meter un gol por la escuadra si ven que cojeas. Si eres un auditor de TI y vas a auditar aspectos técnicos, pon esfuerzo en aprender y comprender la naturaleza de los problemas técnicos, ya que en su ausencia acabarás produciendo trabajos con escasa calidad, no enfocados al riesgo y que no tendrán valor alguno para nadie.

Un saludo,