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,

Fuente: Sergio Hernando

www.segu-info.com.ar

Here is the original post:
La importancia del conocimiento técnico en auditorías de sistemas técnicas |