Consultor de Seguridad, Perito Informático
Archivo de septiembre, 2010
e-Confianza: Consultando a Confianza Online (II)
2hace 2 años
Fui perfectamente atendido y tal como ayer os comenté, aquí está su respuesta que ellos mismos me han autorizado a publicar, sin modificación alguna:
Estimado Miguel Ángel:
Le escribo en referencia a su consulta sobre nuestro ámbito de actuación y la aportación que se realiza desde Confianza Online a la confianza y seguridad en Internet.
El ámbito de actividad de Confianza Online se centra en la autorregulación, la responsabilidad social corporativa y las buenas prácticas en Internet.
Dentro de esta amplia finalidad se encuentran recogidos en nuestro Código Ético los aspectos legales y éticos de las actividades diferentes que las empresas y entidades públicas pueden realizar en Internet. Así, el Código se amplía a los aspectos legales de la publicidad, comercio electrónico, protección de datos, accesibilidad y usabilidad, así como protección de menores. Cabe destacar que el mencionado Código ha sido sometido a consulta a la Agencia Española de Protección de Datos, a la Dirección General de la Sociedad de la Información, y al Instituto Nacional de Consumo con anterioridad a su aprobación. Asimismo, el Código se encuentra inscrito en el Registro General de Protección de Datos, con el nº CT/0004/2002.
Estos ámbitos son comprobados previamente a la adhesión de una entidad a Confianza Online a través de una verificación online de los aspectos legales. Adjunto encontrará una copia del citado Código para su consulta.
Por otro lado, en cuanto a los aspectos técnicos, cabe destacar que a través de la verificación se valoran por ejemplo la existencia de un protocolo seguro mediante la inclusión de SSL, la presencia de información sobre cookies ya que, como le explicábamos, el chequeo que se realiza se centra principalmente en la transparencia y fiabilidad de la página web desde el punto de vista legal y deontológico.
A tenor de lo expuesto anteriormente, lo que contribuye a acrecentar la confianza de los usuarios de la Red, será desde la óptica jurídica todo lo que hay detrás del Sello de Confianza Online:
- De forma previa a la eventual contratación, nos encontramos con una página web verificada en todos sus aspectos legales que, de este modo, ofrece información clara, verídica y segura;
- De forma posterior a la eventual contratación, la mencionada página web ofrecerás las garantías y el ejercicio de los derechos que prevé la normativa en vigor;
- Asimismo, en caso de conflictos surgidos con usuarios de la Red, las empresas adheridas ofrecen gracias al Sello, un sistema de resolución extrajudicial de controversias a través de la actuación de dos organismos encargados de resolver las reclamaciones presentadas por presuntas infracciones del Código Ético. De una lado, el Jurado de la Publicidad de AUTOCONTROL (Asociación para la Autorregulación de la Comunicación Comercial), para todas aquellas reclamaciones sobre publicidad interactiva, y de otro la Junta Nacional Arbitral de Consumo –previo intento de mediación de “adigital” (Asociación Española de la Economía Digital, fruto de la reconversión de FECEMD, (antigua Federación de Comercio Electrónico y Marketing Directo) y de sus asociaciones integrantes, entre las cuales la AECEM (Asociación Española de Comercio Electrónico y Marketing Relacional, patronal de las empresas de comercio electrónico) para las controversias sobre contratación electrónica con consumidores. Ambos organismos han sido reconocidos por la Comisión Europea como cumplidores de los requisitos de la Recomendación 98/257/CE sobre Organismos de Resolución Extrajudicial de Controversias, habiendo sido incluidos desde el año 2000 en la Red EJE de la Comisión.
Espero haber podido contestar su consulta y que la información facilitada le sea de utilidad. En caso de que tenga alguna otra pregunta, no dude en ponerse en contacto con nosotros.
Reciba un cordial saludo,
Y tras esto, id alineando Preguntas con respuestas y tendréis lo que se ofrece desde Confianza Online. Espero vuestros comentarios al respecto con mucho interés.
Salu2!
e-Confianza: Consultando a Confianza Online (I)
3hace 2 años
Mientras termino la serie de post sobre VSS y análisis de riesgos en ISO 27001, os voy a dejar un par de posts, uno con las cuestiones que planteé a Confianza Online, una asociación que ofrece un sello a sus entidades adheridas, con el objetivo de que me aclarasen qué significaba ese sello, y otro que os ofreceré mañana con la respuesta por su parte.
Este es mi mail:
Hola,
He escuchado vuestra publicidad por la radio y me han asaltado dudas, dudas sobre si, realmente, esta es la manera más adecuada de afrontar el problema de la e-confianza.
Leo en su web:
“CONFIANZA ONLINE pone a disposición de los usuarios de los nuevos medios y de las empresas un Código de Conducta específico, el Código Ético de Confianza Online, así como un Sello de Confianza que las empresas adheridas podrán insertar en sus páginas web para mostrar su compromiso de responsabilidad en sus comunicaciones comerciales y en sus transacciones contractuales con los consumidores, ofreciendo, de este modo, mayores garantías a los usuarios de la Red, lo que contribuirá al aumento de su confianza en los nuevos medios.”
Ciertamente voy a hacer aquí un ejercicio de opinión que, desde que escuché de su existencia, no me deja tranquilo, y es que para que exista la e-confianza debe existir la e-seguridad. Actualmente la seguridad en los nuevos medios de información se ha creado entorno a un eje tecnológico y uno legal que han tratado de dotar a la información y las transacciones electrónicas de una mayor seguridad, han surgido legislaciones como la LSSI, LSSI-CE, LOPD y el RD 1720/2007, Ley 11/2007, los recientemente publicados Esquema Nacional de Seguridad y Esquema Nacional de Interoperabilidad y un largo etcétera, que usan a modo de escudo las posibilidades tecnológicas y organizativas como herramienta de defensa dentro de sus textos. Es por esto que me preocupa ver iniciativas en las que se clama por la inclusión de un “Sello de Confianza que las empresas adheridas podrán insertar en sus páginas web para mostrar su compromiso de responsabilidad en sus comunicaciones comerciales y en sus transacciones contractuales con los consumidores, ofreciendo, de este modo, mayores garantías a los usuarios de la Red, lo que contribuirá al aumento de su confianza en los nuevos medios.” en lugar de hacer llegar al ciudadano los conocimientos sobre una navegación responsable, cuándo una conexión está o no cifrada y que los fraudes ya no son sólo el timo de la estampita.
Por otro lado, aún me quedan dudas sobre qué asegura su sello exactamente porque los términos desde lo técnico resultan algo inconcretos. Al hilo del comienzo del párrafo anterior, abordando este problema desde el punto de vista de la e-seguridad, ¿Realizan ustedes una auditoría web mediante alguna metodología reconocida que reduzca el riesgo de existencia de bugs?, ¿Qué comprobaciones hacen ustedes exactamente antes de otorgar el sello a una entidad adherida?, ¿Comprueban las medidas que la empresa dispone para todas las dimensiones de la seguridad de la información, Confidencialidad, Integridad y Disponibilidad?. Desde el punto de vista de alguien que sabe qué es ssl, https, un certificado digital y hace una navegación responsable, ¿qué plus aportan ustedes?.
Gracias de antemano por la resolución de mi consulta
Un cordial saludo.
La respuesta … Mañana 
CVSS + ISO 27001 (IV)
0hace 2 años
Métricas del Entorno
Las vulnerabilidades pueden suponer un problema de muy diferente grado dependiendo del entorno en el que se presente. El grupo de métricas del entorno capturan las características de una vulnerabilidad que están asociadas con el entorno TI del usuario.
Potencial de Daño Colateral (Collateral Damage Potencial /CPD)
Esta métrica refleja el potencial de pérdidas humanas o de activos físicos a causa de daño o robo de propiedades o equipamientos. Esta métrica puede también medir la pérdida de productividad o ingresos.
Ilustración 12: Potencial de Daño Colateral
Como es lógico, cuanto mayor es el daño colateral provocado, mayor será el valor de la vulnerabilidad. Esta métrica incorpora al igual que en el caso de las métricas temporales y el resto de este grupo el valor “No Definido (ND)” que mantendrá inalterado el cálculo final.
Distribución del Objetivo (Target Distribution / TD)
Proporción de sistemas vulnerables en la organización. Esta métrica añade información sobre el porcentaje aproximado de sistemas que se encuentran afectados en la organización con respecto al total.
Ilustración 13: Distribución del Objetivo
Cuanto mayor sea la proporción de sistemas vulnerables mayor será el valor de la vulnerabilidad.
Requisitos de Seguridad (Security Requirements / CR, IR, AR)
Estas métricas permiten a un analista de seguridad instanciar el valor que CVSS otorga a una determinada vulnerabilidad en función de la importancia de los activos afectados por las dimensiones de Integridad, Confidencialidad y Disponibilidad. Cada requisito de seguridad tiene tres posibles valores: bajo, medio o alto.
El efecto completo sobre el valor del entorno viene determinado por las correspondientes métricas base de impacto (las métricas del cálculo base sobre confidencialidad, integridad y disponibilidad no cambian por sí mismas). Esto es, estas métricas lo que hacen es introducir un modificador a las métricas base de impacto sobre confidencialidad, integridad y disponibilidad. Por ejemplo, la métrica de impacto en la confidencialidad se ve incrementada si el valor del requisito de confidencialidad es alto. O al contrario, la métrica de impacto en la confidencialidad se ve decrementada si el requisito de confidencialidad es bajo. En caso de que el valor del requisito de confidencialidad sea medio, el cálculo para la métrica de impacto en la confidencialidad no se verá afectada. La misma lógica se aplica a las dimensiones de integridad y disponibilidad.
Los posibles valores para cualquiera de estas métricas se muestran en la siguiente imagen:
Ilustración 14: Evaluación de Requisitos de Seguridad
Además de los mostrados, estas métricas incluyen el valor “No Definido (ND)” para los casos en los que se desea que no apliquen estas métricas. Conforme mayor es el requisito de seguridad, mayor es el valor final de la vulnerabilidad. El valor con respecto a la métrica base puede verse alterado a lo sumo en +-2,5 mediante estas métricas.
Vector de Entorno
Como sucedía para el Vector Base y para el Vector Temporal, el Vector de Entorno se define de la siguiente forma:
CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/IR:[L,M,H,ND]/
AR:[L,M,H,ND]
Un posible ejemplo sería como sigue:
- Collateral Damage Potential: High (H)
- Target Distribution: Medium (M)
- Confidentiality Requirement: High (H)
- Integrity Requirement: (L)
- Availability Requirement: (H)
Quedando entonces el vector de entorno de la siguiente forma:
CDP:H/TD:M/CR:H/IR:L/AR:H
Ecuación de Entorno
Quizá esta fórmula sea la de cálculo más enrevesado pero si tenemos en cuenta lo que se ha expuesto con anterioridad, no resulta difícil interpretar el cálculo. Lo primero es recalcular el Impacto teniendo en cuenta las nuevas métricas Integrity, Confidenciality y Availability Requirement para posteriormente recalcular también la Ecuación Temporal que dependía de la Ecuación Base y combinar estos valores con los de Distribución del Objetivo y Potencial de Daño Colateral.
El resultado se calcula de forma que el valor obtenido por la Ecuación de Entorno altera en un máximo de 2,5 puntos de valor añadido o disminuido al valor de la Ecuación Base.
En este enlace podéis encontrar ejemplos de cálculo para 3 vulnerabilidades, sin embargo aquí no los incluiré porque la idea tras este artículo no es que se conozcan los valores que se han asignado a cada literal sino cómo éstos contribuyen a un cálculo final, qué factores se tienen en cuenta y qué relaciones mantienen las diferentes métricas y grupos de métricas.
Y aquellos que piensen que esto se ha terminado, de eso nada, espero que esta introducción os esté sirviendo como un acercamiento a CVSS y aquellos que la hayan seguido a buen seguro que se les están empezando a encender luces en relación a la ISO 27001 y a eso vamos la semana que viene, a relacionar todo esto con ISO 27001.
Como no…
Continuará…
CVSS + ISO 27001 (III)
1hace 2 años
Métricas Temporales
El grado de peligro que supone una vulnerabilidad puede cambiar con el tiempo. Tres de los factores que incluye CVSS como componentes que influyen en la variación del grado de peligro son:
- El grado de confirmación de los detalles técnicos sobre la vulnerabilidad
- Cuáles son las soluciones planteadas, si éstas existen
- La existencia de códigos o técnicas que permitan aprovechar la vulnerabilidad
Estas métricas son opcionales por lo que incluyen un valor que no altera el cálculo total.
Aprovechamiento (Exploitability / E)
Esta métrica mide el estado actual en cuanto a la disponibilidad de código o técnicas que permitan aprovechar la vulnerabilidad existente. El número potencial de atacantes aumenta conforme las técnicas o códigos para aprovechar la vulnerabilidad se hacen más sencillos y accesibles para los menos experimentados.
Ilustración 9: Aprovechamiento
Además de los valores reflejados en la Ilustración 9, esta métrica dado que es opcional puede tomar el valor “No definido (ND)”. Cuanto más fácil pueda aprovecharse la vulnerabilidad, mayor será el valor asignado a la misma.
Nivel de Reparación (Remediation Level /RL)
Como su propio nombre indica, esta métrica trata de otorgar un valor conforme al tipo de solución existente para la vulnerabilidad, que puede ser en forma de workaround, parche del fabricante, o e primera instancia no disponer de ninguna solución. Conforme menos oficial es una solución, mayor será el valor de la vulnerabilidad.
Ilustración 10: Nivel de Solución
Al igual que en la métrica anterior, aparte de los valores expresados en la Ilustración 10, esta métrica opcional incluye el valor “No Definido (ND)” que no altera el resultado final de la vulnerabilidad.
Confianza en la Fuente (Report Confidence / RC)
Dependiendo de quién informe sobre la vulnerabilidad, ésta es más o menos creíble de forma que se puede definir una escala según lo oficial de la fuente que comunica o reconoce la vulnerabilidad. La urgencia para el parcheo de una vulnerabilidad será mayor cuanto más oficial sea la fuente que la confirme.
Ilustración 11: Confianza en la Fuente
El valor de la vulnerabilidad crecerá conforme esté confirmada por fuentes más acreditadas. Esta métrica incluye el valor “No Definido (ND)” que no alterará el cálculo final.
Vector Temporal
Con la misma filosofía en cuanto a codificación que en el Vector Base, se obtiene la siguiente representación abreviada para el vector temporal.
E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]
Un ejemplo de posible valoración para estas métricas sería el siguiente:
- Exploitability: Functional
- Remediation Level: Temporary Fix
- Report Confidence: Confirmed
Lo que dejaría el siguiente vector temporal:
E:F/RL:TF/RC:C
Ecuación Temporal
Al igual que sucede en el caso de la Ecuación Base, para la Ecuación Temporal se crea una equivalencia entre los literales que puede tomar como valor cada métrica y un valor numérico que permita cuantificar la repercusión del aspecto temporal en la vulnerabilidad. Las Asignaciones de valores se hacen de forma que las métricas temporales en caso de que no se tengan en cuenta nunca disminuyan el valor del cálculo base. Si se establecieran los valores máximos para cada una de las métricas, esta ecuación dejaría intacta la ecuación base mientras que cualquier valor intermedio rebajaría su resultado total. En este enlace puede ampliar información sobre cómo se calcula esta Ecuación Temporal.
Continuará…
CVSS + ISO 27001 (II)
0hace 2 años
Grupos de Métricas
Métricas base
El grupo de métricas base acoge las características de la vulnerabilidad que no son alterables en el tiempo ni dependientes del entorno. Este grupo contiene tres métricas denominadas Vector de Acceso (Access Vector o AV), Complejidad de Acceso (Access Complexity o AC) y Autenticación (Authentication o Au). Y otras tres más para recoger el impacto en cada uno de las dimensiones de la Información; Confidencialidad, Integridad y Disponibilidad. De esta forma se recoge la posibilidad de que una vulnerabilidad pueda afectar a algunas de las dimensiones más que a otras.
Para cada uno de los valores que puede tomar una métrica, se exponen sus iniciales provenientes del inglés. Para más detalles sobre qué hechos son determinantes a la hora de asignar un valor a una métrica visite este enlace.
Vector de Acceso (Access Vector / AV)
Esta métrica refleja cómo se puede sacar partido de la vulnerabilidad en términos de lejanía. Los valores que puede tomar esta métrica quedan reflejados en la Ilustración 3 .
Ilustración 3: Vector de Acceso
Conforme es más sencillo el acceso para sacar partido de la vulnerabilidad, mayor es la valoración de la vulnerabilidad.
Complejidad de Acceso (Access Complexity / AC)
Lo que se pretende medir mediante esta métrica es cómo de complejo resulta aprovechar la vulnerabilidad en términos de las condiciones que se deben presentar. Algunas vulnerabilidades, por ejemplo, requieren interacción del usuario para obtener un resultado por parte del atacante o requieren condiciones de acceso de Administrador.
Ilustración 4: Complejidad de Acceso
Donde los valores representan:
- Bajo: No se requieren condiciones especiales de acceso
- Medio: Las condiciones de acceso son algo específicas
- Alto: Existen condiciones de acceso especiales
Cuanto menores son las condiciones de acceso, mayor es el valor de la vulnerabilidad.
Autenticación (Authentication / Au)
Esta métrica mide el número de veces que un atacante debe autenticarse antes de tener acceso para aprovechar la vulnerabilidad.
Ilustración 5: Autenticación
Cuanto menores condiciones de autenticación son necesarias para el atacante, mayor es el valor de la vulnerabilidad.
Impacto en la Confidencialidad (Confidentiality / C)
Mediante este valor se mide el impacto sobre la confidencialidad de un ataque satisfactorio.
Ilustración 6: Impacto en la Confidencialidad
Un incremento de impacto en la confidencialidad, incrementa también el valor de la vulnerabilidad.
Impacto en la Integridad (Integrity / I)
Al igual que el anterior pero en esta ocasión para la dimensión de la disponibilidad, esta métrica viene a medir el impacto sobre la integridad de la información de un ataque satisfactorio.
Ilustración 7: Impacto en la Integridad
Un incremento en el impacto a la integridad se traduce en un incremento en el valor de la vulnerabilidad.
Impacto en la Disponibilidad (Availability / A)
Impacto por la dimensión de disponibilidad de la información, en caso de que se produzca un ataque exitoso.
Ilustración 8: Impacto en la Disponibilidad
Cuanto mayor es el impacto, mayor es el valor de la vulnerabilidad.
Vector Base
Cada métrica dentro del vector consta de el nombre abreviado de la métrica seguida del símbolo “:”, a continuación el valor abreviado de la métrica, usando el carácter “/” para separar las métricas. El vector Base tiene la forma general:
AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]
Dónde AV, AC, Au… se corresponden con Access Vector, Access Complexity, Authentication… vistos en las secciones anteriores y los valores entre corchetes son las abreviaturas de los posibles valores para cada métrica (en Inglés).
Un ejemplo de posible valoración de las métricas sería:
- Access Vector: Low
- Access Complexity: Medium
- Authentication: None
- Confidentiality Impact: None
- Integrity Impact: Partial
- Availability Impact: Complete
Lo que dejaría el siguiente vector base:
AV:L/AC:M/Au:N/C:N/I:P/A:C
Ecuación Base
La versión 2.10 de la fórmula para el cálculo mediante la ecuación base combina Impacto y Aprovechamiento (Exploitability) con ciertos modificadores en forma de pesos numéricos. Asignando valores numéricos a los literales definidos como valores posibles para cada métrica se obtiene un resultado numérico entre 0 y 10. La asignación concreta de valores podéis verla en este enlace.
Continuará…
CVSS + ISO 27001 (I)
2hace 2 años
A principios de esta semana pensé en hacer una referencia en un post a un par de páginas que hacen una valoración de las vulnerabilidades pero claro… ¿cómo os voy a dejar esas referencias sin explicar qué parámetros se tienen en cuenta? y claro todo esto además se queda cojo si no lo vinculamos con nuestra norma de seguridad de la información ISO 27001… total que al final intuyo que lo que iba a ser un post se va a convertir en unos cuantos y vamos a comenzar hoy con los primeros conceptos acerca del Common Vulnerability Scoring System (CVSS) que más adelante enlazaremos con diversos aspectos de la ISO 27001 como son el análisis de riesgos y la gestión de la vulnerabilidad técnica. Esta primera parte está sacada íntegramente de la guía CVSS v2 (donde podéis dirigios en cualquier momento a ampliar información) aunque la he reestructurado, traducido, sintetizado, añadido diagramas y personalizado a mi gusto tratando de mantener la máxima fidelidad en su contenido. Espero que os guste y os resulte de utilidad…
Introducción
El sistema de puntuación de vulnerabilidades comunes (Common Vulnerability Scoring System, en adelante CVSS) viene a solucionar la problemática de priorizar las actuaciones entorno a las vulnerabilidades técnicas localizadas dentro de la organización en el proceso de gestión de la vulnerabilidad técnica, unificando la forma en la que las vulnerabilidades son evaluadas.
CVSS constituye un marco de trabajo en el cual se definen una serie de parámetros que permiten asignar un valor de riesgo a una determinada vulnerabilidad basándose en tres diferentes grupos de métricas:
- Métricas Base: recogen las características intrínsecas y fundamentales de la vulnerabilidad que son independientes del tiempo y del entorno en el que ésta se pueda presentar.
- Métricas Temporales: refleja aquellas cualidades que pueden variar en el tiempo.
- Métricas del Entrono: involucran aquellas variables que dependen del entorno en el que se encuentra la vulnerabilidad.
¿Cómo funciona CVSS?
La idea para el cálculo del valor de la vulnerabilidad pasa por hacer obligatorio el cálculo de las métricas base y opcional los cálculos de las métricas temporal y de entorno siendo estas últimas modificadores de la base.
De esta forma, una vez fijados los valores que componen la fórmula de cálculo base se obtiene un valor entre 0 y 10 que posteriormente puede ser refinado por características temporales o del entorno. Este valor irá acompañado de lo que se denomina Vector que no es otra cosa que una cadena de texto donde se refleja cómo se ha llevado a cabo el cálculo. La Ilustración 1 muestra la filosofía detrás de esta forma de cálculo:
Ilustración 1: Métricas y Funciones
¿Quién calcula los valores?
Generalmente, quien tiene mejor conocimiento de las diferentes métricas. Las métricas base y temporal son calculadas por los emisores de boletines de vulnerabilidades, vendedores de productos de seguridad o aplicaciones, mientras que la del entorno es fijada por los usuarios, que son los que mejor conocen las circunstancias y distribución de las Tecnologías de la Información en su organización.
¿A quién pertenece CVSS?
CVSS está bajo la custodia y cuidado del Foro de Respuesta a Incidentes y Equipos de Seguridad (Forum of Incident Response and Security Teams, en adelante FIRST). No obstante nadie es propietario de CVSS y no se requiere ser miembro de FIRST para poder usarlo o implementarlo.
¿Quién lo usa?
Diferentes colectivos se benefician de diferente forma de CVSS entre los que destacan los mostrados en la Ilustración 2.
Ilustración 2: Colectivos que se benefician de CVSS
Definiciones
Dentro de CVSS los términos Vulnerabilidad, Amenaza y Riesgo se definen como sigue:
- Vulnerabilidad: un problema, debilidad o exposición de una aplicación, dispositivo, sistema o servicio que puede llegar a causar un problema de confidencialidad, integridad o disponibilidad.
- Amenaza: probabilidad o frecuencia de que ocurra un evento no deseado.
- Riesgo: el impacto relativo que una vulnerabilidad aprovechada pudiera tener en un entorno usuario.
Continuará…
Auditando la seguridad web: Websecurify
0hace 2 años
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.
LOPD: La Instrucción 1 / 2006:
1hace 2 años
Hace algunos días que leía en el blog de Joseba Enjuto una cuestión que me llevó hasta la relectura de algunas partes del texto de la LOPD y el RD en vigor 1720/2007. En este post, Joseba planteaba una interesante cuestión.
Imaginemos el siguiente escenario:
Tenemos un establecimiento público, un bar, por ejemplo. En ese bar disponemos de una cámara que no está grabando, la utilizamos, pongamos una vez al trimestre para ver qué ocurre o por si salta la alarma y nos avisan poder ver qué esta pasando en nuestro local. ¿Nos aplica la LOPD?.
Pues si nos vamos a la LOPD o al RD 1720 / 2007 en su artículo 2 podemos encontrar la siguiente descripción dentro del ámbito de aplicación:
Art 2. Ámbito Objetivo de Aplicación
El presente reglamento será de aplicación a los datos de carácter personal registrados en soporte físico que los haga susceptibles de tratamiento, y a toda modalidad de uso posterior de estos datos por los sectores público y privado.
Nuestra cámara no está registrando nada en un soporte físico por lo que la cosa está clara, no nos aplica la ley, si no está dentro del ámbito de aplicación y además no hay fichero no nos aplica.
Pero si seguimos leyendo (aun con la idea en mente de que no registramos nada y no tenemos fichero), encontramos la definición de Datos de Carácter Personal que todos conocemos ya sobradamente:
Cualquier información numérica, alfabética, gráfica, fotográfica, acústica o de cualquier otro tipo concerniente a personas físicas identificadas o identificables
Y… la de Tratamiento de Datos:
Cualquier operación o procedimiento técnico, sea o no automatizado, que permita la recogida, grabación, conservación, elaboración, modificación, consulta, utilización, modificación, cancelación, bloqueo o supresión, así como las cesiones de datos que resulten de comunicaciones, consultas, interconexiones y transferencias.
La cosa ya no es lo que parecía porque se está haciendo un tratamiento de datos personales pero… es que el ámbito de aplicación es el que es. Pues aquí entra en juego la instrucción 1/2006 de 8 de noviembre, de la Agencia Española de Protección de Datos, sobre el tratamiento de datos personales con fines de vigilancia a través de sistemas de cámaras o videocámaras.
Esta instrucción clarifica qué se debe hacer en el caso del bar de nuestro amigo:
- Información.
- Colocar, en las zonas videovigiladas, al menos un distintivo informativo ubicado en lugar suficientemente visible, tanto en espacios abiertos como cerrados y
- Tener a disposición de los/las interesados/as impresos en los que se detalle la información prevista en el artículo 5.1 de la Ley Orgánica 15/1999.
El distintivo informativo deberá de incluir una referencia a la LEY ORGÁNICA 15/1999, DE PROTECCIÓN DE DATOS, incluirá una mención a la finalidad para la que se tratan los datos (ZONA VIDEOVIGILADA), y una mención expresa a la identificación del responsable ante quien puedan ejercitarse los derechos a los que se refieren los artículos 15 y siguientes de la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal. El contenido y el diseño del distintivo informativo se ajustará a lo previsto en el Anexo de esta Instrucción.
- Seguridad y Secreto.
El responsable deberá adoptar las medidas de índole técnica y organizativa necesarias que garanticen la seguridad de los datos y eviten su alteración, pérdida, tratamiento o acceso no autorizado.
Asimismo cualquier persona que por razón del ejercicio de sus funciones tenga acceso a los datos deberá de observar la debida reserva, confidencialidad y sigilo en relación con las mismas.
El responsable deberá informar a las personas con acceso a los datos del deber de secreto a que se refiere el apartado anterior.
Dilema resuelto.
Un saludo.
