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,

Métricas de seguridad del Center for Internet Security

Hola,

The Center for Internet Security (CIS) tiene diversos proyectos en marcha. Uno de ellos es la definición de unas métricas de seguridad reutilizables por organizaciones y particulares, ya que la obtención del documento Consensus Metric Definitions, que recoge la definición de las mismas, es gratuita.

Un poco de teoría sobre métricas de seguridad …

Que nadie se asuste con las métricas, ya que son de lo más sencillas de comprender. La dificultad cuando se emplean métricas de seguridad estriba en saber qué vamos a medir, cómo y para qué lo queremos someter a medición. Las métricas, en su amplia mayoría, son muy simples, pero que nadie se frote las manos: son herramientas que requieren, además de su definición inicial, la objetivación necesaria para poder extraer de ellas las pautas de actuación precisas y adecuadas.

Un ejemplo clásico dentro de la seguridad aplicativa, presente en el Consensus Metric Definitions, es el porcentaje de aplicaciones críticas (PAC), y es tan simple de obtener como calcular el porcentaje que representan, dentro del total de aplicaciones, aquellas que se consideran críticas para el negocio.

PAC = (Número de aplicaciones críticas / Total aplicaciones ) * 100

Muchos dirán que vaya simpleza. Nada más lejos de la realidad:

  • ¿Qué convierte a una aplicación en crítica?
  • ¿Qué objetivación asociaremos a los distintos porcentajes obtenidos?
  • ¿Qué decisiones deben emanar de los porcentajes?
  • ¿Qué programas específicos de seguridad serán de aplicación en cada banda porcentual?

Métricas: representaciones sencillas de estrategias complejas

Al final, como podéis imaginar, esta es una métrica sobre la que no hay datos experimentales suficientes como para obtener un consenso pleno sobre los objetivos que deben derivar del porcentaje de aplicaciones críticas. Preguntas como las anteriores pueden surgir cientos, y finalmente, lo más aconsejable es que se actúe en función a la estrategia de TI de la empresa. Lo que inicialmente parece muy simple (un porcentaje) finalmente tendrá una traducción estratégica con un componente de dificultad notorio, ya que lo que es crítico o no para el negocio, y cómo se espera se actúe en estos casos, es algo muy subjetivo y variable.

Ejemplos de lo anterior se nos pueden ocurrir muchos. Para una notaría, una aplicación en línea de gestión documental puede ser crítica, ya que su negocio depende directamente de la documentación recibida y generada, que además está sujeta a una estricta legislación, mientras que, por ejemplo, la gestión documental que los usuarios de Terra Giga puedan realizar no parece ser el alma mater de Terra, y aunque es importante y relevante custodiar adecuadamente los documentos de los usuarios, esta aplicación, probablemente, no será crítica a la hora de sustentar las operaciones del citado proveedor.

Center for Internet Security Consensus Metric Definitions

En el documento Consensus Metric Definitions encontraréis métricas para los siguientes ámbitos:

  • Seguridad aplicativa
  • Gestión del cambio y de la configuración
  • Correlación financiera de partidas de TI
  • Gestión de incidentes
  • Gestión de parches (no tipificada como gestión del cambio)
  • Gestión de vulnerabilidades (podría ser parte de la gestión del cambio, si bien está considerada aparte)

Consensus Metric Definitions (PDF 83 páginas, 1,31 MB) se puede descargar, previo registro y sin coste alguno para el interesado, a través de la dirección https://community.cisecurity.org/download/.

Un saludo,