Seguridad de la Información
Auditando la seguridad web: Websecurify
Sep 9
El desarrollo de aplicaciones se transformó hace ya unas dos décadas con el auge de Internet y se acentuó aún más con la llegada de la denominada web 2.0. Redes sociales, wikis, blogs, servicios de alojamiento de videos, gestores de contenidos y un largo etcétera han contribuido a que hoy las posibilidades de negocio con Internet como medio conductor se multipliquen, y también sus riesgos.
Una de las asignaturas pendientes de nuestra “joven” profesión (Hablo de la de Ingeniero Informático) son los desarrollos de calidad y aunque iniciativas como Common Criteria, ISO 27001 u OWASP ponen su foco (o parte de él) sobre esta problemática, aún queda camino por recorrer. Hoy nos vamos a centrar en la detección de vulnerabilidades web.
Las pruebas del software son la piedra de toque para conseguir un software que responda a las especificaciones tanto en términos funcionales como de seguridad. WebSecurify es un entorno integrado para testing de seguridad web. que nos proporciona la posibilidad de realizar test tanto automatizados como manuales.
Entre las vulnerabilidades detectadas por el escaneo automático se encuentran:
- SQL Injection
- Local y Remote File Include
- Cross-site Scripting
- Cross-site Request Forgery
- Problemas de Revelación de Información
- Problemas de Seguridad en la Sesion
y muchas más, incluyendo las catalogadas como los 10 principales riesgos en seguridad web por OWASP top ten.
La interfaz es más sencilla imposible, comenzar un nuevo test y poner el objetivo. Al terminar nos muestra un informe con los resultados que ha obtenido para el dominio analizado.
PP (Post Post): He tenido bastantes problemas con la última versión (0.7) en sistemas operativos Windows Vista y Windows 7 porque DEP (Data Execution Prevention) mata XulRunner. Esto es un error conocido que además viene heredado de versiones anteriores con lo que no se soluciona instalando otra versión más antigua. Un workaround puede ser desactivar DEP momentáneamante para la ejecución de Websecurify volviendo a activarlo después.
Saludos.
Los caballos de troya de Spanair
Ago 25
El 20 de Agosto de 2008 el vuelo 5022 de la compañía Spanair que realizaba el trayecto Madrid – Gran Canaria sufría un terrible accidente en el que fallecieron 154 personas. El caso sigue sin sentencia y la instrucción judicial suma ya más de 11.000 folios.
Una de las últimas novedades que ha salido a la luz es la posible existencia de troyanos en la máquina encargada de reportar las incidencias. La noticia se ha extendido por Internet a la velocidad del rayo y cada cual ha hecho ya sus valoraciones. La alternativa que se baraja es que el ordenador encargado de dar las alarmas no operó correctamente debido a una carga elevada de malware que impidió el registro de la incidencia y la posterior alarma. Al parecer el sistema lanzaba una alarma cuando se acumulaban 3 incidencias del mismo tipo y ésta era la que hacía 3, pero no se pudo registrar, la alarma no se disparó y el avión despegó con las consecuencias ya conocidas. De cualquier forma, al parecer, el registro de la incidencia no se hubiera llevado a cabo a tiempo.
La fuente principal de esta noticia se encuentra en el pais. Cualquiera que lea esta noticia se da cuenta de que la información no es todo lo correcta que debería ser y hay que hacer algunas suposiciones. De esta noticia se ha hecho eco hasta el gurú de la seguridad informática Bruce Schneier con una edición posterior al primer post pidiendo cautela a la hora de valorar esta información.
La información de la investigación apunta como primer causa del accidenta al fallo humano en la verificación de uno de los puntos de la lista que deben ser examinados de forma previa al despegue. Este error habría sido provocado por la prisa tras el retraso del avion que llevó al piloto a una respuesta automática sin verificación de la posición de una pieza básica para el despegue.
Bien, pues en toda esta historia a mi me gustaría poner énfasis en otro aspecto diferente. La conferencia de prensa del dia después de los máximos dirigentes de spanair (Hacia el minuto 5:00) arrojaba datos sobre las auditorías por terceras partes de diferentes aspectos relacionados con la seguridad aérea afirmando que Spanair había obtenido la certificación IOSA y que ésta había sido renovada en su segundo año lo que implicaba una revisión extensa de todos los procesos y sistemas. El checklist de la norma IOSA de IATA está redactado estilo ISO 27002 como una guía pero que además incorpora tras cada control una evaluación al respecto del mismo. El cheklist es bastante extenso, supera las 300 páginas y para poder dar una opinión fundamentada habría que pasar largas horas delante del ordenador si no se controlan los conceptos (como es mi caso, aun asi, vease ORG.3.3.11, ORG 3.3.12, MNT 1.8.1). La cuestión es, ¿Se comprobó durante esa auditoría si los sistemas que soportaban los procesos de negocio estaban en las condiciones adecuadas?, y si era así, ¿De qué sirve un proceso de negocio que debe darme una alarma si algo va mal si no llega a tiempo?. ¿De que sirvió el sello IOSA?, y generalizando, ¿realmente acredita un sello aquello por lo que clama más allá de una buena gestión?.
Como todo accidente, es producto de un cúmulo de circunstancias adversas y en este confluyeron, al parecer, varias. ¿Cuanto influyó cada una?, ¿Podría el malware tener parte de culpa del accidente? (en caso de que la gestión de incidencias hubiera llegado a tiempo). Cada cual que saque sus conclusiones al respecto y si lo desea contribuya con un comentario ofreciendo su opinión. Yo ya tengo la mía.
Un saludo.
Software para Auditoría de Software
Ago 24
Los motivos por los que puede ser necesaria una auditoría de software en una empresa pueden ser de lo más variopinto, desde un simple control rutinario como parte del cumplimiento del control 15.1.2 sobre derechos de propiedad intelectual, pasando por una actividad programada como política de la organización o por un peritaje en busca de software pirata.
Cuando surge la necesidad de realizar la auditoría de este tipo, son varios los factores que se han de tener en cuenta de cara a la selección del producto más adecuado. Estos factores, entre otros, pueden ser:
- Parque de PCs: Número de PCs objeto de la auditoría
- Privilegios sobre los PCs a Auditar: Si el responsable de realizar la auditoría dispone de privilegios de Administración y en tal caso, si la instalación por defecto de cada PC dispone de un password de administración único por cada PC.
- Impacto en PC auditado: se ha de considerar si el impacto sobre el PC auditado debe ser mínimo.
Si trasladamos esto a nuestro caso, las respuestas a las cuestiones anteriores se traducen en:
- Parque de PCs: Desconocido. el auto no reflejaba el número de PCs a investigar. Recopilando información por internet traté de construirme una imagen mental de cómo sería y existía la posibilidad de verme desbordado por lo que recurrí a un compañero del Cuerpo Oficial de Peritos para que me acompañase lo que sin duda ha redundado en un trabajo de campo mucho más eficiente.
- Privilegios sobre los PCs a Auditar: Desconocido. La configuración de los PCs nos era desconocida también.
- Impacto en PC Auditado: Mínimo. Para el desarrollo de una pericia de este tipo se debe mantener el sistema impoluto, como no es posible, hay que ejecutar un programa que alterará los procesos, la memoria, creará un informe que se grabará en el disco duro, etc… hay que minimizarlo al máximo.
Ante esta definición de requisitos vamos a ver algunas de las posibilidades que nos ofrece el mercado para generar informes de las aplicaciones instaladas en los PCs de la organización.
- Network Inventory Expert: Esta aplicación nos va a permitir extraer el software de cualquier PC de la organización que disponga de una contraseña conocida por quien lo ejecuta. Precisa Instalación en el PC del administrador pero no en el resto de PCs de la organización. De pago.
- Total Network Inventory: Del corte del anterior, son programas diseñados para un seguimiento cómo del inventario ya que permiten extraer informes muy detallados de forma remota con la instalación del software en único PC. De pago.
- WinAudit: Inventario muy completo del PC, Incluido el Software, pero no los Product Keys. El problema que tiene es que hay que ejecutarlo PC por PC, pero por contra es Stand Alone. Freeware.
- Softkey Revealer: Esta herramienta no es como las demás, está diseñada expresamente para extraer los product key de una larga lista de productos comerciales por lo que es el complemento perfecto a Winaudit en caso de necesitar esta información. Freeware
- Everest: Herramienta de inventariado hardware y software muy profesional con posibilidad de instalación StandAlone. A pesar de ser comercial, su precio es bastante asequible.
- Microsoft Assessment and Planning Toolkit: Este software me ha sorprendido por su cantidad de opciones, con un proceso de instalación bastante largo precisa de un gestor de base de datos que se descarga durante la instalación donde almacena el inventario. Permite la recolección vía protocolos de red de windows y recolección por IPs, además es gratuito.
- Muchas más: GASP, Free PC Audit, y un larguísmo etcétera tanto de pago como freeware.
Finalmente nuestra opción fue Everest y como alternativa llevábamos la dupla Winaudit + softkey revealer que son herramientas no comerciales. Elegimos Everest ya que permite una instalación en modo stand-alone y además del software, incluida información sobre product keys, nos ofrecía información sobre el hardware de manera que teníamos una prueba más sobre los PCs examinados.
Pero esta búsqueda sin duda nos ha reportado algo más que el software que escogimos, nos ha dado una perspectiva de cómo se puede gestionar cómodamente el inventario de software en organizaciones con un parque de PCs elevado manteniendo una buena política de configuración de los PCs cuando éstos se ponen en uso (Incluyendo un usuario Administrador con contraseña robusta). Esto permite de forma sencilla la ejecución de una tarea de chequeo que nos dará desde el puesto de administración todos los informes de forma automática.
Un saludo.
Peritaje: En busca de SW Pirata, la Auditoría de SW
Ago 11
No hay ninguna duda de que Microsoft ha hecho mucho por nosotros, quien lo ponga en duda sólo tiene que pensar cual fue su primer S.O., qué editor de textos utiliza actualmente o qué emplea para hacer presentaciones profesionales cuando tiene que impartir alguna clase o realizar alguna ponencia, por poner algunos ejemplos. Sin embargo, todas estas ventajas se han conseguido a costa de un alto precio, la pérdida de la percepción de lo que realmente hacemos al instalar un software propietario pirata. Estamos robando, si señores, no se nos ocurriría ir a un supermercado y llenarnos los bolsillos de bolsas de pipas, pero es que instalar un software pirata resulta extremadamente sencillo y total… si nadie me va a buscar, ¿o si?.
El mes pasado, acompañado del secretario judicial, el procurador y un compañero de profesión nos dirigimos a la sede de una empresa con objeto de realizar una auditoría de software por una denuncia anterior de las empresas Autodesk, Microsoft, Adobe y Symantec. Aquí está mi experiencia.
Una vez nos encontramos en la empresa, el secretario judicial solicitó la presencia del gerente, quien rápidamente apareció por el hall y se prestó a todo lo que necesitábamos. Tras exposición de lo que había ocurrido al Gerente, nos dispusimos a realizar nuestro trabajo, que básicamente según rezaba el auto se reducía a una Auditoría de Software en la que se obtuvieran determinadas propiedades del software instalado, entre las que se encontraba, como no, el serial o product key del producto.
Solicitamos inspección visual de las instalaciones con objeto de hacer un conteo de los PCs y, por ende poder dar una estimación de la duración de la intervención. Una vez estimado el volumen de PCs y el tiempo se lo transmitimos al secretario judicial que debe estar presente durante toda la intervención como fedatario del procedimiento seguido por el perito.
Comenzamos pues la actuación y fuimos realizando las siguientes acciones:
- Extracción de listado de programas instalados en cada PC y su fecha de creación
- Extracción de listado de programas instalados en cada PC y su fecha de último acceso
- Ejecución de una herramienta automática Stand Alone que extraía todos los datos solicitados por los demandantes (Me reservo para un post posterior la exposición de las alternativas posibles para este objetivo)
- Fotografiar las posibles licencias que encontráramos en forma de pegatinas adheridas a cada uno de los PCs
- Fotografiar la pestaña General y Nombre de Equipo de cada PC
- Construir un mapa con la ubicación física de cada uno de los PCs examinados
Antes de nada pusimos al corriente al gerente de la empresa, ya que el responsable de sistemas estaba de vacaciones, de cuáles iban a ser nuestras actuaciones y qué íbamos exactamente a extraer de cada uno de los PCs corporativos.
Nada más comenzar la situación se volvió algo tensa dado que a nadie le gusta que le toquen sus… sistemas. Salimos bien de la situación por algo coyuntural, el gerente era conocido de uno de los allí presentes y esa confianza nos ahorró tener que lidiar con los abogados del demandado, pero es más probable que sean requeridos por el demandado que que no lo sean.
Así todo, fuimos ordenador por ordenador ejecutando los comandos y desde un CD la herramienta y grabando en local los informes que finalmente ubicamos en una carpeta de red para poder grabarlos desde una máquina que disponía de grabador de CD. El uso del CD como soporte para este tipo de actuaciones se hace indispensable. Plantearse utilizar un dispositivo tipo pendrive tanto para la ejecución de la herramienta stand-alone para la extracción de informes como para almacenar las evidencias obtenidas es poco menos que un suicidio por las altas probabilidades de infección de alguno de los sistemas.
Con todo eso, desde un PC portátil de nuestra propiedad, grabamos las fotografías a un CD y copiamos su contenido a la misma carpeta en la que disponíamos de los informes. Acto seguido ordenamos todo por nombre del PC de forma que disponíamos de todas las evidencias clasificadas. Finalmente todo este contenido fue grabado por triplicado dejando una copia a la empresa demandada, otra al secretario judicial y otra que nos quedamos nosotros para la elaboración del correspondiente dictámen.
Nos despedimos y fin del trabajo de campo, que se cuenta rápido pero llevó unas 5 horas para 23 sistemas.
En resumen una nueva experiencia que requiere más de aplomo y saber estar que de cualidades técnicas y que tiene varios puntos críticos:
- Selección de Software
- Elaboración de la Metodología más apropiada
- Cambios on the fly por restricciones de la infraestructura de sistemas de la empresa
- Y sobre todo, saber estar en los momentos de presión, no ponerse nervioso y ser consciente de que simplemente haces tu trabajo.
Salu2 y felices vacaciones para los que las estéis disfrutando actualmente!
La catástrofe del golfo de Mexico, la no seguridad y el SGSI
Jul 27
Accidente de la Plataforma de BP
El día 20 de Abril de este año, un desgraciado accidente que se llevó la vida de 11 trabajadores se pudo haber evitado. Esto que pensarás suena a tópico dejará de serlo si reconstruyes las circunstancias en las que el accidente se produjo.
Estando este fin de semana en casa, en uno de los pocos momentos que tengo para escuchar la televisión, escuché por casualidad la declaración de uno de los supervivientes al accidente. Mike Williams, ex empleado de la plataforma y técnico jefe de los sistemas electrónicos, declaró en una audiencia sita en Nueva Orleans que el sistema de detección encargado de monitorizar las acumulaciones de gas o la existencia de fuego no se activó. Preguntado por qué, Mike contestó que el sistema se encontraba apagado y que era una práctica habitual porque los responsables de la plataforma no querían despertar a nadie a las 3 de la mañana por una falsa alarma. A partir de aquí pueden haber dos líneas argumentales principales:
- El sistema de detección fue ineficaz porque estaba apagado pero… ¿Por qué estaba apagado?. Un sistema que emite muchas falsas alarmas resulta del todo inútil de forma que o se sustituye, o se perfecciona o se termina apagando. Si el sistema había demostrado no ser eficaz estando en funcionamiento, el responsable del sistema debía haber hecho notar esta circunstancia y haberlo corregido a tiempo dado que, por lo demostrado, se trataba de un sistema crítico.
- El sistema de detección funcionaba adecuadamente pero esporádicamente saltaba una falsa alarma que molestaba a alguien que no debía (o que si debía pero no le hacía mucha gracia levantarse a las 3 de la mañana).
Pues bien, el impacto, arriba descrito ha sido terrible, las consecuencias no sólo en términos de vidas humanas sino también de flora y fauna marinas, aves, plantas, contaminación atmosférica y un largo etcétera aún a día de hoy colean y el problema sigue sin cerrarse.
En infraestructuras y servicios críticos, la seguridad no es una opción, los impactos de la no seguridad no son admisibles bajo ningún punto de vista y es por eso que crece mi preocupación cuando veo empresas y servicios en los que aún no se les ha pasado por la cabeza pensar en la seguridad de sus activos, algunos de ellos teniendo como actividad principal la seguridad de los demás.
Enlazando todo esto con mi quehacer diario resulta algo curioso que cuando se finaliza la implantación de un SGSI, los controles que se han introducido para monitorizar determinados activos generan alarmas que a su vez se convierten en críticas, tan peligroso o más es no tener seguridad como pensar que se tiene y que ésta no funcione, sentirse seguro no es estar seguro. Esto nos lleva a la gran importancia de comprobar el buen funcionamiento de los controles implantados para aparte de sentirnos seguros tras la implantación del SGSI, estarlo, y a una pregunta más, ¿deben los activos de información generados por los controles implantados durante la construcción del SGSI formar parte del análisis de riesgos en futuras iteraciones?.
Espero vuestras opiniones.
Saludos a tod@s
Cursos Impartidos por Inteco
May 25
A través de INTECO, se están ofreciendo una serie de cursos introductorios a diversas materias incluida LOPD, seguridad a nivel básico, gestión de riesgos, gestión de proyectos y el que ya os dejé en la sección de cursos sobre SGSI, la oferta en este momento es extensa y una buena opción para acumular conocimientos en las diferentes áreas.
https://formacion-online.inteco.es/inscripcion/
No espereis cursos que profundicen en exceso pero aún así resultarán sin duda de utilidad para muchos.
Salu2!
Schneier sobre el futuro de la seguridad de la Información
Mar 11
Bruce Schenier es un reconocido experto en seguridad de la información a nivel mundial, en esta conferencia de casi una hora y media habla sobre el cloud computing, las preferencias en ocasiones irracionales que tenemos a la hora de asumir el riesgo y muchos más factores que influirán en el futuro de la seguridad informática.
Fuente: La comunidad DragonJAR
El Riesgo Residual en ISO 27001
Mar 8
Hola a tod@s
De entrada aviso que este post es puramente sobre ISO 27001 y 27005 por lo que aquellos que no se encuentren familiarizados con el tema les puede resultar algo denso.
Los debates sobre el riesgo residual suelen ser un tema recurrente entre consultores de seguridad de la información. Normalmente estos debates están enfocados en cómo es posible asignar un porcentaje de reducción a una determinada contramedida que permita calcular el riesgo remanente tras su aplicación, pero el propio concepto de riesgo residual en ocasiones genera otras controversias.
Este término no viene definido en ISO 27000 como cabría esperar puesto que ésta norma es de 2009 y el término ya quedó definido en ISO 27001 en el apartado 3, término 3.9 se describe como sigue:
Riesgo Residual: Riesgo remanente que existe después de que se hayan tomado las medidas de seguridad
Sin embargo, si acudimos a la norma 27005 ésta deja bien claro que este riesgo residual no se refiere al riesgo efectivo tras la aplicación de las medidas sino al teórico que se calcula durante el análisis de riesgos en la fase de Plan.
Esto empieza a dejarlo claro en la tabla 1 donde expone lo siguiente:
Tabla 1 – Alineación del SGSI y el Proceso de Gestión del Riesgo de Seguridad.
En esta tabla se puede observar que la aceptación del riesgo se encuentra en la fase de Plan del ciclo PDCA. Vamos a ver qué dice ISO 27005 en lo referente al riesgo residual.
La efectividad del trataminento de riesgo depende de los resultados de la evaluación de riesgo. Es posible que el tratamiento de riesgo no dé con un nivel aceptable de riesgo residual. Ante esta situación, si es necesario, podría requerirse otra iteración de la evaluación del riesgo con otros parámetros del contexto (por ejemplo valoración del riesgo, aceptación del riesgo o criterio de impacto), seguido a posteriori por otro tratamiento de riesgo (Vea la figura de abajo)
La actividad de aceptación del riesgo tiene que asegurar que los riesgos residuales son aceptados por los gerentes de la organización. Esto es especialmente importante en una situación donde la implmentación de controles se omite o pospone por motivos como los costes.
[...]
Una vez el plan de tratamiento de riesgo ha sido definido, es necesario determinar los riesgos residuales. Esto implica una actualiación o re-iteración de la evaluación de riesgos, teniendo en cuenta los efectos esperados de los tratamientos de riesgos propuestos. En caso de que los riesgos residuales no cumpliesen los criterios de aceptación de riesgo, una iteración más podría ser necesaria antes de proceder a la aceptación del riesgo.
Este último párrafo acaba de despejar las dudas, lo que se calcula es el riesgo resultante tras la aplicación de los tratamientos seleccionados teniendo en cuenta los efectos esperados. Es por esto también que en el punto 4.2.1.h de la norma 27001 habla de “Obtener la Aprobación de los Riesgos residuales propuestos“.
Tras leer todo esto parece quedar todo claro pero si tan sólo se ve la definición parece hablar del riesgo tras implantar las medidas de seguridad, lo que puede desviarnos de una buena interpretación.
Salu2!
Por favor, róbame
Feb 23
Curiosa iniciativa que ha llamado mucho la atención de bloggers (yo no soy una excepción) y especialistas en seguridad, la página web pleaserobme aglutina a aquellas personas que a través de twitter han dejado un mensaje notificando que abandonan su domicilio y donde se van a encontrar!!!. Claro, lo siguiente será, por favor, dense de alta todos en este servicio de moda de geolocalización en el que todo el mundo podrá saber dónde te encuentras, además podrás ponerlo también en twitter y no olvides dejar en facebook cuando te vas de vacaciones y el tiempo que vas a estar, aunque, no te preocupes, probablemente lo haga tu mujer o tu marido por tí.
No soy partidario de dominizar a las redes sociales puesto que tienen su utilidad. Yo mismo tengo un perfil en linkedin y probablemente algún día haga una cuenta en facebook, más que nada porque de poco sirve no tenerla, en facebook estás quieras o no, el que no lo crea que busque entre los perfiles de sus amigos y noooooooooooo!! ese soy yo!!. Sin embargo, todo debe tener sus límites y en una red social, los límites deben ponerlos los usuarios. Determinada información debe mantenerse en secreto y no ser revelada por simple sentido común y prudencia.
Publicada ISO 27003
Feb 23
Vía la lista de distribución de iso27001security primero y el blog de Javier Cao después veo que tenemos una nueva pieza que viene a completar un hueco importante dentro de la visión holística de la seguridad planteada por la familia 27000. Esta norma es la ISO 27003: Information technology — Security techniques — Information security management system implementation guidance que viene a mostrar los pasos necesarios para la implantación de un SGSI.
Más información aquí.
