He recibido un correo en el que se me sondeaba sobre la posibilidad de colaborar profesionalmente con un peticionario, al que obviamente he pedido permiso para poder hablar de ésto, vaya que se sintiera ofendido. Tal y como me ha pedido, no revelaré su identidad ni hablaré tampoco de la empresa para la que trabaja, que todo sea dicho, es conocida en el mundillo.
El caso es que este correo me hace reabrir un discurso que llevo años pronunciando. Hoy quiero haceros a todos partícipes de este pequeño debate, y en caso de que haya alguien que se sienta identificado, nos cuente lo que opina al respecto.
Este señor me pedía información para realizar una auditoría. Yo he declinado, por muchas razones, la principal es que en caso de aceptación existiría un conflicto de interés con mi empleador, al que le debo lealtad y respeto, así como cumplimiento de la legislación vigente :) Aún así, es posible que existan vías de colaboración para otros menesteres en los que no exista tal conflicto, algo de lo que yo particularmente me alegro.
Este señor me solicitada información sobre lo que podría costar una auditoría de un TRU64. Lo que ocurre es que lo que este señor quería contratar, leyendo sus peticiones, no era una auditoría, era un test de intrusión. Para él la auditoría equivalía a un test de penetración, confusión frecuente sobre todo en personas que están en departamentos que orbitan alrededor de TI, y en los que no se puede presuponer que se conozcan este tipo de distinciones.
El auditor no es mas guay ni es mejor que el pen-tester. Tampoco sucede en el otro sentido. Son perfiles distintos, que hacen trabajos distintos, y no por ello uno es más valioso que el otro. Por eso mismo aclaremos que una auditoría NO es un un test de penetración, aunque obivamente, son conceptos que tienen relación.
El test de penetración es una prueba técnica que se ejecuta en un contexto delimitado (una IP pública, un equipo de la red local, lo que sea), en el que se intenta lograr la intrusión explotando vulnerabilidades, problemas técnicos y deficiencias de la configuración, con la finalidad de evaluar si un sistema es o no es seguro ante un ataque externo. Muchas veces se habla de hacking ético, queriendo significar esto que se trata de ponernos en la piel de un atacante externo que, explotando problemas, desea acceder a nuestros recursos protegidos. El adjetivo ético hace referencia a que lo hacemos bajo demanda del peticionario, y sin oscuras intenciones. Por eso mismo creo que sería más prudente llamarlo cracking ético, porque según la filosofía underground, el hacker entra sin causar daños ni pretenderlos. Una larga disquisición cracker vs hacker, que tampoco es menester desarrollar ahora :)
La mejor manera de entender qué es un pen-test (penetration test, test de penetración) es resumiendo esquemáticamente las fases habituales de un análisis de este tipo:
- Definimos nuestro objetivo. En este caso, el ejemplo de análisis es la IP a la que nos lleva OpenBSD.org. Ni qué decir que esto que os cuento es un mero ejemplo, y que obviamente, un test completo acarrea bastante más trabajo. No quiero que ningún pen-tester se sienta ofendido ante la imagen de simplicidad de este ejemplo :)
- Listado de servicios en exposición (habitualmente, un escaneo de puertos). Entre otros, resulta que «Interesting ports on openbsd.sunsite.ualberta.ca (129.128.5.191): 80/tcp open http». Descubrimos que en OpenBSD.org tienen el puerto 80 abierto (menudo descubrimiento :P)
- Identificación completa de servicios y versiones. Identificamos qué servidor Web y que versión están a la escucha de ese puerto 80. Nmap nos vale también, aplicando la opción de TCP/IP fingerprinting. Ejecutamos un nmap -T4 -A www.openbsd.org -p 80 y descubrimos que «80/tcp open http Apache httpd 1.3.34 ((Unix) PHP/4.4.2 mod_perl/1.27) Running: Sun Solaris 2.X|7|8. OS details: Sun Solaris 2.6 – 8 (SPARC)». Información suficiente para progresar.
- Análisis automatizado de vulnerabilidades y deficiencias. Antes de proceder al análisis manual, aprovechemos las herramientas que separan trigo y paja. Ya recogeremos el grano después. Pasamos un escáner de vulnerabilidades para ver si ese Apache descubierto es vulnerable o no. El escáner automático dice que no hay nada anormal. Vía muerta de investigación.
- Análisis manual de vulnerabilidades y deficiencias. Repasamos el histórico de vulnerabilidades y tratamos de explotar las deficiencias manualmente. Queremos ver si ese Apache 1.3.34 está actualizado en lo que parches de seguridad concierne (no lo está, pero los fallos entre la 34 y la 37, última disponible, no son explotables). Tampoco hay deficiencias de configuración reseñables. Vía muerta.
- Ejecución de la intrusión, si es posible (si por el Apache no podemos, tratamos por el sistema Solaris, o vía módulos de Apache detectados, como PHP/4.4.2 mod_perl/1.27. Cualquier puerta de entrada es válida. Por desgracia, no la encontramos. No esperaba menos de OpenBSD :)
- Recolección de evidencias (capturas de pantalla, logs, etc) en el caso de que encontremos vías de acceso. Hay que guardar todas las pruebas para demostrar después los logros del trabajo. Eso sí, hay que ser profesional obteniendo y conservando pruebas.
- Informe del test, documentado todo lo que hemos hecho y qué hemos logrado, y lo más importante: consignamos las recomendaciones para subsanar el problema con la mejor optimización. Un trabajo técnico que no proporciona soluciones óptimas no sirve DE NADA.
Eso es un test de intrusión en esencia, resumido esquemáticamente. Una auditoría es un concepto mucho más general, en el que no necesariamente evaluamos la seguridad de un ítem. Podemos evaluar la eficacia, la eficiencia, el rendimiento, la escalabilidad, la compatibilidad, los tiempos de recuperación … La auditoría es un trabajo en el que se evalúan habitualmente una o varias características de un sistema determinado así como su interrelación. Estas características ni tan siquiera tienen por que ser técnicas. Es posible auditar aspectos financieros u operacionales.
Bajo mi punto de vista, una auditoría, salvo que el alcance no lo requiera, puede perfectamente incorporar un test de penetración como una prueba más. El auditor puede conducir la prueba si tiene habilidades para ello, si bien es deseable, por plazos, por objetividad y porque cuatro ojos ven más que dos, que esta prueba, mucho más económica que una auditoría de sistemas, la haga un tercero, interno o externo a la compañía, y que el auditor evalúe los resultados de dicha prueba. Es el escenario de la auditoría de seguridad más usual, en el que además de los test de intrusión, se evalúan otros aspectos como la calidad de la criptografía, la explotación del sistema, las comunicaciones, la seguridad física, la seguridad lógica, el retorno de la inversión, … todo lo que queramos definir en nuestro alcance.
Insisto: son trabajos distintos. No podemos confundirlos. Llamemos a cada cosa por su nombre, por favor :)
¿Has llegado al final del artículo? ¿Lo leíste entero? Te mereces un premio, no me cabe duda. Aquí os dejo dos enlaces para seguir investigando:
- Las 10 mejores distribuciones Linux para pen testing y análisis forense
- Arudius. Una distribución Linux para pen testing. Realmente buena, y con muy buenas herramientas gratuítas.
Saludos :)
Sergio, totalmente de acuerdo con la diferenciación y con la necesidad de que las empresas se dirigan al mercado con el discurso correcto y utilizando las palabras correctamente (ver artículo del IT Skeptic poniendo verdes a los que no usan el vocabulario adecuado en http://www.itskeptic.org/node/45 ).
Solo añadiría una puntualización: para mi el auditor comprueba y evidencia el cumplimiento de normativas, politicas, procedimientos, procesos, etc… es decir, su trabajo es comprobar y demostrar que se hace lo que se dice que se hace, además de comprobar que los controles establecidos son adecuados y suficientes y, desde una perspectiva colaborativa y proactiva, proponer mejoras en función de los descubrimientos que realice y las conclusiones a las que llegue.
Apa, eso es todo, buenas noches!!
Antonio Valle
Yo también coincido con la diferenciación de ambos perfiles y sus objetivos de comprobación. Además las empresas quizás no valoran la importancia que la auditoría de sistemas de información puede tener para su negocio. Ya no se trata de probar que los sistemas no son vulnerables sino evidenciar que cumplen los objetivos por los que son adquiridos e implantados.
Semejante problemática se plantea entorno a la auditoría bienal que aparece en el nivel medio del R.D. 994/1999 de la LOPD. Una auditoría debe probar con evidencias el cumplimiento o no cumplimiento de los controles.
¡ No es pasar un cuestionario!
Evidentemente los controles no técnicos de la ley habrá que evaluarlos de diferentes maneras pero saber si los procedimientos se están ejecutando obliga a mirar los registros que dichos procedimientos deben generar. La idea con la que creo fue elaborado el R.D. 994/1999 es forzar a las empresas a que exista una documentación mínima sobre los sistemas de información donde se realiza el tratamiento, sus «activos de información» y una serie de procedimientos a cumplir. De esa manera, es muy facil auditar para un tercero (el inspector de la Agencia de turno) si se CUMPLE lo que el documento de seguridad pone. El control no es en sí mismo la tenencia del documento sino el cumplimiento del contenido.
Desgraciadamente muchas empresas de asesoramiento LOPD venden que el problema es la tenencia del documento, olvidando así el verdadero objetivo de dicho documento.
Imagino que el tiempo irá poniendo a la auditoría de sistemas de información en su sitio, como ya ocurre con la auditoría contable. El otro tema sin resolver es ¿quién es el perfil adecuado para ser auditor de sistemas de información? ¿Qué requisitos debe satisfacer?
Buena reflexión y a pesar de todo me sorprende como se pueden llegar a confundir ambos roles. Aunque personalmente considero que un test de intrusión debe ser considerado como el intento de acceso a un sistema a toda costa (siempre utilizando procedimientos legales, lícitos y éticos claro ;-)) Por tanto, además de explotar las vulnerabilidades a nivel técnico no hay que olvidar otros mecanismos para conseguir el objetivo final, por ejemplo técnicas de ingeniería social (según la finalidad no son demasiado éticos pero dado que en el mundo real existen pues hay que considerarlos no ???). Aplicando el dicho aquel de que la fortaleza de una cadena reside en el eslabon más débil, es obvio, que todo «ente» que tenga algo que ver con el objetivo es un candidato más a ser «penetrado» :-) ;-)
PD. Por supuesto, en el alcance del test debe quedar todo ello bien delimitado.
Muy buen articulo, me ha gustado.
Me ha gustado el artículo, (por cierto muy de acuerdo con Antonio valle) jjejeje, preciso — conciso en el detalle. :)
Lo único que sopesa también en este mundillo es el alcance en función del auditor de sistemas vs un oficial de seguridad (OSI).
Que sería entonces el audito con respecto a éste último, hace tiempo leía que era una función incluida en Sarbanes Oxley , dado los asuntos de seguridad ante todo.
Excelente el artículo, muy bueno
Gracias Sergio, enhorabuena.
Hola!
Solo un par de cosillas mas: a lo que dice Javier Cao sobre la LOPD, ojo, que esta en la cocina Basel II que igual acaba siendo «la SOX europea» y ya veremos como cambian las cosas!!
A lo que dice EAM sobre la ingenieria social , nosotros la incluimos en los servicios de test de intrusion como una de las vias de ataque mas.. y no veas como disfruta el que lo hace y como flipa el cliente cuando le muestras lo que has encontrado…
Antonio
Buenas,
He leido algo sobre Basel II y creo que solo aplica a entidades financieras. Desde luego que va a cambiar las cosas pero más en tema de continuidad de negocio para la gestión del riesgo de operación. Por desgracia como ya he comentado solo aplica a entidades financieras.
Ojalá en ciertos organismos e instituciones fuera obligatorio al menos un SGSI.
Basel II, entidades financieras … pues eso, casi la nueva Sarbanes-Oxley. Buen artículo Sergio. Voy a plagiártelo en mi blog para poder meter algo de entrada (naturalmente citando fuentes, etc.). Al 500% entre el Proyecto Camersec y otros que han surgido de la nada ante ciertas peticiones.
Respecto de la Auditoría de LOPD lo del cuestionario es bastante más habitual de lo que pudiera parecer, desgraciadamente (como indicaba Javier Cao).
Yo particularmente, cuando hacemos alguna, me la tomo como una auditoría de un ‘mini-SGSI’ para entendernos. Quizás por el background en auditorías de todo tipo, tiendo a aplicar ISO 19011 en lo que al procedimiento de auditoría en sí respecta. Como guía de actuación está bastante bien. Cuando el cliente recibe el informe de auditoría lo primero que espeta es un ‘joder, ni que fuésemos la ONU’, pero debe ser así sin ningún género de dudas.
Respecto al Sr. Valle, al cual creo que tengo posibilidades de ver en el congreso de itSMF, al cual asistiré, pues lleva razón en la puntualización. Básicamente es eso: comprobar prácticas, procedimientos, … En definitiva, auditar que el sistema establecido cumple con los requisitos previamente definidos.
Tiene pinta de estar bien el congreso itSMF. Por lo menos las ponencias parecen muy interesantes para captar más información si cabe sobre ITIL e ISO 20000.
Antonio,
Solo añadiría una puntualización: para mi el auditor comprueba y evidencia el cumplimiento de normativas, politicas, procedimientos, procesos, etc… es decir, su trabajo es comprobar y demostrar que se hace lo que se dice que se hace, además de comprobar que los controles establecidos son adecuados y suficientes y, desde una perspectiva colaborativa y proactiva, proponer mejoras en función de los descubrimientos que realice y las conclusiones a las que llegue.
Sí, efectivamente. La verificación del cumplimiento de las obligaciones que establecen los reguladores es una misión claramente imputable al auditor. Es, para los distintos ámbitos existentes, un fedatario que además, como bien dices, en algunas ocasiones también debe proponer mejoras :)
Javier,
¡ No es pasar un cuestionario!
Cómo se nota que estás en la brega diaria del que quiere hacer las cosas bien y vé como otros se limitan a eso, a pasar checklists que de nada sirven. Vender tener el documento, documento que pasa después a lo alto de un estante a coger polvo.
No sabes en cuántas pseudoconformidades de esas me he visto envuelto :)
El otro tema sin resolver es ¿quién es el perfil adecuado para ser auditor de sistemas de información? ¿Qué requisitos debe satisfacer?
Para mí son dos requisitos: por un lado estar formado en «las artes de la auditoría», es decir, conocer las prácticas, las metodologías y los modos de actuar con el cliente. Por otro, debe tener especialidad en el tipo de sistemas que está auditando. Si no has tocado un CRM, a duras penas podrás auditarlo. Ya no te digo nada si te cae una Sybase, o un TRU64.
Requisitos generales y requisitos específicos. Algo como los códigos tipo que se idearon para los IRCA de Calidad (sí, esos que al final se han pasado por la piedra, ya que calidad audita hasta un mono con libreta últimamente)
EAM,
Por supuesto. La ingeniería social es otro método de extracción de información. Las contemplo dentro de las deficiencias, pero si no ha quedado claro te lo confirmo: es una fuente de información válida :)
B.sword!?,
A mandar :)
Hildebrando,
La mejor manera de entender la diferencia entre un oficial de seguridad y un auditor, es entender qué es un auditor certificado y qué es un gestor certificado. El oficial debería ser CISM, y el auditor, CISA. Por supuesto, valen las certificaciones equivalentes :)
Sobre SOX puedo contarte, y algo de experiencia me avala, que más que un auditor, es preciso un equipo de auditoría. Sólo hay tres fracciones que un auditor de sistemas puede hacer en SOX: infraestructura, ciclo de vida de aplicaciones y explotación. Para la parte de operativa crítica que no esté comprendida en estos tres dominios, y para el resto que no es operativa crítica, ha de contarse con auditoría financiera INEXORABLEMENTE :)
Jose Manuel,
Quizás por el background en auditorías de todo tipo, tiendo a aplicar ISO 19011 en lo que al procedimiento de auditoría en sí respecta
Excelente marco. Hacía falta que Q y MA se unieran en cuanto a auditoría se refiere. Sin embargo, la veo algo coja para afrontar otro tipo de auditorías que no están regladas claramente por normativa y metodología. De todos modos es un texto muy sensato.
Si has hablado de itSMF pásanos el enlace, que me ponga al día :P
Sobre Basilea II,
He leido algo sobre Basel II y creo que solo aplica a entidades financieras.
Has leído bien, puedo dar fé de ello :P
Gracias a todos por los comentarios :)
Pues hace unos días se abrió las inscripción formal del congreso. Me enviaron un eMail directo pues dejé mis datos en verano, cuando se estaba suministrando información sobre el evento y se realizaban preinscripciones, declaraciones de intenciones de asistencia o como se llame eso. No se si existirán plazas libres, pero os animo a ir.
Sergio, tríncate una plaza y nos vemos por allí. Cuesta pasta. Alrededor de unos 300 Euros más o menos.
El post donde dije lo del itSMF es del día 25 de julio y también lo vi, al margen de http://www.itsmf.es, es el blog del amigo Antonio Valle por aquellos días conforme digo en el post.
Enlace a la noticia en blog Jose Manuel
Enlace al site de itSMF España
Buena entrada Sergio. Me la he leído enterita y de un tirón. Yo creo que ambos perfiles son diferentes, aunque el de auditor pueda incluir el de pen-tester no tiene porqué. De un modo informal siempre tuve en mente que el pen-tester es más práctico y menos burocrático y el auditor más de papeleo, normativas de seguridad, y esas cosas.
No obstante el punto #8 que mencionas es fundamental. Sin eso, el trabajo de un pen-tester se queda en nada. O bueno, en nada bueno… jeje :-)
Mencionas de refilón el concepto de hacking ético, quizás ahí si entre mejor el pen-tester, aunque es mucho más amplio que eso. No tengo claro si sería cracking porque analizar cómo entrar no tiene porque comportar romper nada.
Saludos. :)