1.
Modelado de amenazas en el contexto de la
indexación de páginas y propuesta de inclusión en
el ENS
Chema Alonso Cebrián
ESCET
Universidad Rey Juan Carlos
Email: chema@informatica64.com
Antonio Guzmán Sacristán
DATCCCIA
Universidad Rey Juan Carlos
Email: antonio.guzman@urjc.es
Gonzalo Álvarez Marañón
Instituto de Física Aplicada
Consejo Superior de Investigaciones Científicas
Email: gonzalo@iec.csic.es
Enrique Rando González
Departamento de Informática
Delegación de empleo de la Junta de Andalucía
Email: enrique.rando@juntadeandalucia.es
Resumen—Este trabajo analiza las amenazas derivadas de las
malas prácticas en la gestión de técnicas SEO para indexación
de páginas web, así como las vulnerabilidades y ataques que se
pueden derivar de ellas. A partir de este análisis se ha propuesto
un conjunto de cinco normas que deben resultar básicas para
el desarrollo seguro de la gestión de indexación. Además, se ha
propuesto la adaptación de estas normas al Esquema Nacional
de Seguridad.
I. INTRODUCCIÓN
La correcta indexación de un sitio web por los motores de
búsqueda reviste una importancia capital para contar con una
presencia sólida en Internet. Con el fin de mejorar el posi-cionamiento
de un sitio web en la página de resultados de un
buscador se utilizan las denominadas técnicas de optimización
para motores de búsqueda (Search Engine Optimization, SEO).
Entre la gran variedad de técnicas SEO, se incluyen la correcta
configuración de los archivos robots.txt [1] y sitemap.xml [2]
para indicar a los buscadores qué indexar y qué no dentro
de un sitio web. La incorrecta configuración de estos archivos
puede acarrear consecuencias negativas desde el punto de vista
de la seguridad y del rendimiento de un sitio web.
El viernes 29 de enero de 2010 se publicó en el BOE el
Real Decreto 3/2010, de 8 de enero, por el que se regula el
Esquema Nacional de Seguridad (ESN) en el ámbito de la
Administración Electrónica [3]. El ESN nace con el objetivo
de crear las condiciones necesarias de confianza en el uso de
los medios electrónicos en las relaciones de los ciudadanos
con las Administraciones públicas. Se limita a establecer los
principios básicos y requisitos mínimos que permiten una
protección adecuada de la información y los servicios, en
respuesta al Art. 42.2 de la Ley 11/2007, de 22 de junio, de
acceso electrónico de los ciudadanos a los servicios públicos
[4]. Con ello, se logra un común denominador normativo,
constituido por los principios básicos y requisitos mínimos
para una protección adecuada de la información [5].
En el extenso Anexo II, el ENS proporciona medidas de
seguridad concretas estructuradas en tres grandes grupos (or-ganizativas,
operacionales, de protección), los cuales pueden
estar a su vez divididos en más subgrupos. Aunque existe una
categoría destinada a la protección de servicios y aplicaciones
web, no se tratan específicamente los posibles problemas de
seguridad derivados de una deficiente configuración de los
archivos robots.txt y sitemaps.
El objetivo de este trabajo es exponer estos problemas y pro-poner
unas guías de buenas prácticas de cara a combatirlos, las
cuales podrían añadirse o complementar las recomendaciones
del ENS.
El trabajo está estructurado de la siguiente forma: en la
Sec. II se realiza un modelado de amenazas sobre los riesgos
derivados de la incorrecta indexación de páginas web; en
la Sec. III se ofrecen una serie de recomendaciones para
protegerse frente a los riesgos identificados; en la Sec. IV se
adaptan estas recomendaciones al formato del ENS; la Sec. V
concluye el trabajo.
II. MODELADO DE AMENAZAS EN EL CONTEXTO DE LA
INDEXACIÓN DE PÁGINAS
El modelado de amenazas ayuda a identificar amenazas,
ataques, vulnerabilidades y contramedidas con el fin de mejo-rar
la gestión de la seguridad de los sistemas de información.
En las siguientes secciones se explican cuáles son las ame-nazas,
vulnerabilidades y ataques a los que está expuesto un
sitio web con una incorrecta configuración de los archivos
robots.txt y sitemap.xml.
II-A. Amenazas derivadas de malas prácticas en la gestión
de indexación
Se entiende por amenaza el potencial de que un incidente,
deliberado o no, comprometa los objetivos de seguridad de
la organización [6]. Entre los objetivos de toda organización
suelen figurar el salvaguardar la privacidad de la información
sensible, así como asegurar un servicio rápido y de calidad.

2.
En las siguientes secciones se describe cómo estos objetivos
pueden verse amenazados.
II-A1. Revelación de información sensible sobre la organi-zación:
Toda organización posee información sensible: datos
de personas físicas y jurídicas, ya sean empleados, clientes
o proveedores; datos de sistemas y servicios, como archivos
de configuración, registros de actividad y código fuente; etc.
Esta información sensible puede revelarse de varias maneras
indeseadas y a veces insospechadas.
II-A1a. Metadatos en documentos públicos: La mayoría
de software utilizado cotidianamente para generar documentos
digitales de todo tipo realiza la adición automática de datos
sobre los datos creados (metadatos), los cuales se adjuntan
de forma más o menos visible a los propios documentos.
Estos metadatos pueden revelar información como nombres
de personas, organizaciones, fechas de creación, histórico de
alteraciones en el documento, rutas de acceso de archivos,
dispositivos utilizados en su creación, coordenadas GPS, y un
sinfín de datos adicionales.
II-A1b. Errores de sistemas: Todo software está sujeto
a errores o condiciones excepcionales que pueden provocar
el funcionamiento anormal de una aplicación. Cuando estas
excepciones no se gestionan adecuadamente, pueden revelar
información sobre el sistema: código fuente, rutas de acceso
de archivos, tipo de servidores, versión de software instalado,
nombres de usuario, cadenas de conexión a bases de datos,
consultas SQL que revelan a su vez estructuras internas de
tablas, etc.
II-A1c. Rutas de acceso: Aunque los archivos robots.txt
y sitemap.xml están destinados a los robots de búsqueda, son
públicos y cualquiera puede descargarlos. Pueden contener
información sobre rutas de acceso, las cuales a su vez rev-elan
qué tipo de software existe instalado y qué contenidos
sensibles se desean ocultar.
II-A1d. Contenido de ficheros de configuración: El
funcionamiento de algunos servidores se configura mediante
archivos de texto, los cuales pueden contener información
sensible como nombres de usuario y contraseñas, cadenas de
conexión a bases de datos, rutas de acceso de archivos, etc.
II-A1e. Contenido de ficheros de registro de actividad:
Registrar en archivos de texto la actividad de un servidor
permite estudiar de qué manera es usado y también reconstruir
incidencias. Estos registros o logs pueden contener informa-ción
sensible de los visitantes, como por ejemplo los datos
introducidos en formularios.
II-A2. Deterioro del rendimiento: Un objetivo fundamen-tal
de todo servicio web es asegurar un buen rendimiento,
percibido por los usuarios como la cantidad de tiempo nece-saria
para cargar la página solicitada. Los motores de búsqueda
legítimos por lo general obedecen el protocolo de exclusión
de robots que indica qué porciones del sitio web deben
agregarse a los resultados de búsqueda. Archivos robots.txt y
sitemap.xml mal configurados pueden originar una sobrecarga
de peticiones por parte de estos robots, causando una pérdida
de rendimiento.
II-A3. Deterioro de la calidad de servicio: A medida que
se incrementa la complejidad de un sitio web y crece su
número de páginas, resulta más difícil navegar por ellas y
encontrar la información deseada. Un sitio web que carezca
de una buena gestión de SEO perderá visibilidad, ya que
no aparecerá entre los 10 primeros puestos en las páginas
de resultados de los buscadores, y también calidad, porque
aunque aparezca listado, no aparecerán en primer lugar las
páginas más relevantes dentro del propio sitio.
II-A4. Secuestro de resultados de búsqueda: Para asegurar
la visibilidad en Internet, es muy importante que la búsqueda
de palabras relevantes para el servicio prestado por una orga-nización
conduzca al sitio web de esta organización. Existen
técnicas conocidas como Black Hat SEO [7] que pueden
alterar artificialmente estos resultados.
II-B. Vulnerabilidades en la gestión de indexación: Mala
configuración de robots.txt y sitemap.xml
Se entiende por vulnerabilidad toda debilidad en un sistema
que podría permitir o facilitar la materialización de una
amenaza contra un activo [6]. La forma de disminuir el riesgo
a que se ven expuestos los activos de la organización pasa
por mitigar o eliminar las vulnerabilidades. En las siguientes
secciones se describen cuáles son las vulnerabilidades más
importantes en la gestión de una política de SEO asociadas a
los archivos robots.txt y sitemap.xml.
II-B1. Inexistencia de archivos: Los robots de búsqueda
indexarán absolutamente todo el contenido al que se tenga
acceso públicamente navegando desde la página principal.
II-B2. Archivos excesivamente explícitos: Algunos sitios
web se sirven del archivo robots.txt para especificar los
directorios o archivos con información sensible para evitar
que sean indexados por los robots de búsqueda. Este archivo
puede por tanto llegar a contener información sobre directorios
y archivos confidenciales.
II-B3. Archivos con errores: Un archivo robots.txt mal
configurado puede suponer una sobrecarga para el servidor
al obligar a los motores de búsqueda a realizar peticiones
innecesarias y entrar en bucles.
II-B4. Archivos robots.txt y sitemap.xml mal configurados:
Como parte de una estrategia de SEO global, deben configu-rarse
adecuadamente estos archivos para garantizar una buena
visibilidad en la página de resultados y una buena calidad en
los enlaces mostrados en primer lugar.
II-B5. Archivos muy permisivos: Permiten que Google in-dexe
todo tipo de páginas de configuración, manuales, ayudas
y mensajes de error, los cuales son expuestos a través de
búsquedas conocidas como “google dorks” [8].
II-C. Ataques
Se entiende por ataque todo intento, exitoso o no, de atentar
contra el buen funcionamiento del sistema con el consiguiente
incumplimiento de los objetivos de la organización [6]. En las
siguientes secciones se describen sin ánimo de exhaustividad
algunos de los ataques más populares dirigidos contra sitios
web con una pobre gestión de SEO, capaces de materializar
las amenazas descritas en la Sec. II-A.

3.
User-agent: *
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /editor/
Disallow: /includes/
Disallow: /mambots/
Disallow: /modules/
Disallow: /templates/
Disallow: /installation/
Figura 1. Ejemplo de archivo robots.txt con exceso de información.
User-Agent: *
Disallow: /etc
Disallow: /bin
Disallow: /tmp
Disallow: /log
Allow: /
Figura 2. Ejemplo de archivo robots.txt con exceso de información.
II-C1. Rutas de acceso: El archivo robots.txt de la Fig. 1
contiene un exceso de información al revelar la zona de
administración y el tipo de software usado, ya que la carpeta
mambots, sumada al resto de carpetas, ofrece el panorama
típico de Mambo [9]. Permitió descubrir el software y la ruta
de administración para el ataque posterior.
En la Fig. 2 se ofrece otro ejemplo de archivo robots.txt
que revela directorios del servidor.
II-C2. Metadatos: Debido a la mala manipulación de los
archivos y a la indexación de Google es posible encontrar
usuarios con sencillas búsquedas como la siguiente:
http://www.google.com/#hl=es&q=
intitle:"Documents and Settings"site:es
ministerio &lr=&aq=f&oq=
intitle:"Documents and Settings"site:es
ministerio
Posteriormente, utilizando herramientas como FOCA [10],
puede extraerse información adicional sobre los usuarios y la
organización a partir de los documentos encontrados.
II-C3. Ficheros de configuración: El archivo robots.txt
de la Fig. 3 contiene numerosas líneas como la mostrada,
en la que se revelan los nombres y rutas de archivos de
configuración. En este caso, los archivos ocultados a los
buscadores contienen las respuestas al juego propuesto por
el sitio web.
II-C4. Revelación interna de datos: En teoría, un buscador
sólo indexa documentos accesibles mediante un hiperenlace
a partir del nombre de dominio en el DNS. Si existe un
fichero sitemap.xml, sigue también todos los hiperenlaces en
él dados de alta. Si el documento A no está enlazada desde
Disallow: /educational_games/medicine/
dna_double_helix/xmldata.xml
Figura 3. Fragmento de archivo robots.txt.
ningún otro del sitio web, no será indexado por los buscadores.
No obstante, si no existe un fichero robots.txt que prohíba
la indexación de la ubicación del documento A, un atacante
interno podría desvelar este fichero realizando una petición
expresa de indexación al buscador con la ubicación exacta del
documento A.
III. BUENAS PRÁCTICAS EN LA GESTIÓN DE INDEXACIÓN
El siguiente apartado recoge algunas de las buenas prácticas
que deben ser aplicadas a la hora de exponer un sitio web a
las arañas de los buscadores de Internet, con el fin de que la
información que los buscadores obtengan de la organización
sea única y exclusivamente aquella que la organización desea,
y que su obtención sea efectiva.
III-A. Por omisión: disallow:* para todos los robots
La presencia o no de un sitio web en los buscadores de
Internet debe ser una decisión de la organización a tomar en
consideración con madurez. ¿Tiene sentido que estén indexa-dos
los datos de una aplicación que utilizan sólo los empleados
internos de una organización? ¿Tiene sentido que se indexen
ficheros y datos privados de aplicaciones en la Intranet? En
el caso que desee la organización tener presencia en los
buscadores, ¿cómo quiere aparecer en ellos? Éstas y muchas
preguntas deben ser contestadas con anterioridad a poner un
sitio a disposición de las arañas de los buscadores. Si el sitio
ha sido puesto en producción sin haber realizado la reflexión
necesaria para conocer la presencia que se desea tener en
ellos, debe configurarse un fichero robots.txt que bloquee la
indexación de todos los contenidos de la organización.
Debido al gran número de arañas de buscadores, es nece-sario
realizar este bloque para todos los agentes:
User-agent: *
Disallow: /
Este fichero indica a las arañas que no se desea ser in-dexado
y no volverán a intentar indexar el sitio hasta que,
manualmente, se pida su indexación. Si no se realiza esta
configuración antes de poner el sitio en producción, los datos
de la organización pueden estar copiados durante una cantidad
incierta de tiempo en una gran cantidad de buscadores y será
necesario realizar un borrado manual en todos ellos.
III-B. Auto-catalogación Sí/No
El siguiente paso consiste en realizar la clasificación que
clarifique qué contenido debe o no ser indexado por los bus-cadores.
Hay que tener en cuenta que debe ser indexado aquel
contenido que sea estrictamente de índole público. En adelante
se entiende por ruta pública la ubicación con contenidos que se
desean indexar y por ruta privada la ubicación con contenidos
que no se desea que sean copiados a los buscadores.
Para realizar esta catalogación de una forma correcta se
recomiendan las siguientes pautas:
Evitar rutas con contenido mixto (público/privado), ya
que provocaría o fugas de información o mala presencia
en Internet a la hora de decidir si una ruta es pública o
privada.

4.
User-agent: *
Disallow: /cgi-bin/
Disallow: /images/
Disallow: /aplicaciones/
Figura 4. Ejemplo de un robots.txt para un sitio web.
Evitar contenido no enlazado en rutas públicas, pues
alguien que lo descubra o conozca podrá solicitar su
indexación manualmente.
Evitar rutas privadas conocidas, ya que ubicaciones
privadas del tipo /etc o /home pueden identificar la
existencia de archivos conocidos, sensibles a la seguridad
de la información.
Evitar rutas privadas explícitas: Una catalogación como
privada de una ruta como /administrator o /admin puede
ayudar a un atacante a descubrir la existencia de un
fichero login.hml o login.jsp dentro de esas ubicaciones,
debido a lo común de estas arquitecturas en aplicaciones
web.
Evitar configuraciones privadas automáticas: ciertas apli-caciones
web, como gestores documentales o gestores de
contenido, utilizan ficheros robots.txt estándar que son
fácilmente reconocidos.
Evitar el uso de rutas privadas a fichero: El pedir la no
indexación de un fichero mediante el fichero robots.txt
es hacer pública su ubicación, lo que es igual o más
peligroso. Para restringir la indexación de una página
única en rutas mixtas existen soluciones tecnológicas
creadas para ello como es la meta etiqueta robots:
<meta name=“robots” content=“noindex”>
Aplicar la misma configuración para todas las arañas de
todos los buscadores de Internet.
Proteger las rutas privadas con listas de control de acceso
si es posible para evitar cualquier indexación por parte
de los buscadores.
III-C. Optimización rendimiento y SEO con sitemap.xml
Para optimizar tanto el consumo de recursos que realizan
los robots dentro del sitio como la forma en la que un sitio
aparece en ellos se recomienda hacer un correcto uso del
archivo sitemap.xml.
Este fichero, aunque es una modificación al estándar original
del formato de robots.txt, es de aplicación extendida e indica
a los robots de los buscadores tanto la importancia de los
ficheros públicos, como su frecuencia de actualización. En
sitios en los que se está indexando información estática con
pocos cambios se puede configurar un largo periodo de actu-alización
haciendo que el robot no intente indexar nuevamente
los elementos. Además, en sitemap.xml se marca también la
fecha de la última actualización y si ésta es anterior a la fecha
de indexación que tiene el buscador, no se volverán a realizar
todas las peticiones de documentos.
Usar un sitemap.xml correctamente ayuda a:
1. Mejorar el rendimiento aligerando la carga de los bots
en el servidor web.
2. Mejorar la presencia del sitio en Internet eligiendo cómo
los usuarios deben encontrar y entrar en el sitio.
3. Evitar los ataques de hijacking-SEO [7].
III-D. Auditoría
Una vez terminado de catalogarse correctamente el con-tenido
entre público y privado, y tras optimizarse con
sitemap.xml la carga de los robots y la relevancia del con-tenido,
se podría plantearse añadir el sitio a los buscadores
mediante la sustitución del archivo robots.txt inicial, que
bloqueaba la indexación, por el nuevo archivo generado. Sin
embargo, este proceso no debe realizarse hasta que el sitio web
haya recibido una auditoría de seguridad, con el fin de que
no se indexen posibles páginas de error como consecuencia
de vulnerabilidades de Inyección de SQL o de Cross-Site
Scripting (XSS).
Además de la auditoría de seguridad, es altamente re-comendable
realizar un análisis tanto del fichero robots.txt
como de sitemap.xml para comprobar que su funcionamiento
va a ser el esperado.
Una vez que se haya validado tanto la seguridad del sitio
como el formato y la estructura de robots.txt y sitemap.xml,
podrá ponerse en producción.
III-E. Auditoría constante
Debido a la estructura viva de muchos sitios web de Internet,
es necesario incluir dentro de los procedimientos de auditoría
la revisión de la presencia del sitio en Internet, mediante la
reevaluación de robots.txt y sitemap.xml, como mediante la
presencia de posibles fugas de datos en buscadores de Internet
para, en caso de haberse producido, solicitar el borrado de la
URL de los índices de los buscadores.
IV. RECOMENDACIONES PARA ENS
Es preciso determinar la forma en que un sistema establece
un equilibrio entre la importancia de la información que
maneja, los servicios que presta y el esfuerzo de seguridad
requerido. Esto supone categorizar el sistema basándose en
la valoración del impacto que tendría sobre la organización
un incidente que afectara a la seguridad de la información
o de los sistemas con repercusión en las funciones de dicha
organización.
Para poder mesurar el impacto de un incidente en la
ENS se proponen dimensiones de seguridad sobre las que
posteriormente se podrán definir métricas de seguridad. Las
dimensiones propuestas son:
a) Disponibilidad (D)
b) Autenticidad (A)
c) Integridad (I)
d) Confidencialidad (C)
e) Trazabilidad (T)
Cada uno de estos aspectos podrá evaluarse con tres posibles
valores: BAJO, MEDIO y ALTO, según las definiciones del
ENS [3].
Cuando un sistema maneja diferentes informaciones y presta
diferentes servicios, el nivel del sistema en cada dimensión

5.
será el mayor de los establecidos. De esta forma es posible
categorizar un sistema de información en tres categorías:
BASICA, MEDIA y ALTA en función de que alguna de
sus dimensiones esté evaluada en BAJO, MEDIO y ALTO,
respectivamente.
Una vez que se han definido las dimensiones de seguridad
relevantes y la categoría del sistema a proteger, es posible
elegir qué medidas de seguridad deben implementarse. La se-lección
de las medidas de seguridad implicará la identificación
de los tipos de activos presentes y la determinación de las
dimensiones relevantes así como de su nivel correspondiente.
Estas medidas pueden clasificarse en tres marcos diferencia-dos:
el marco organizativo, el marco operacional y el marco de
protección. Este último se centra en la protección de activos
concretos, según su naturaleza y la calidad de servicio exigida.
En el Esquema Nacional de Seguridad, a través del anexo II,
se propone un sistema tabulado para incluir todos los aspectos
que pueden ser estimados como medidas de seguridad. Según
se ha visto en las secciones anteriores, surge la necesidad
de ampliar la propuesta de medidas de seguridad dentro del
marco de protección con un bloque centrado en la protección
de las técnicas SEO, en línea con el artículo 42 del ENS, en
el que se indica que el esquema se debe mantener actualizado
de manera permanente. Se desarrollará y perfeccionará a lo
largo del tiempo, en paralelo al progreso de los servicios
de Administración electrónica, de la evolución tecnológica y
nuevos estándares internacionales de seguridad y auditoría.
En la tabla IV se utilizan las siguientes convenciones:
a) Para indicar que una determinada medida de seguridad
se debe aplicar a una o varias dimensiones de seguridad
en algún nivel determinado se utiliza “aplica”.
b) « n.a. » significa “no aplica”.
c) Para indicar que las exigencias de un nivel son iguales
a las de un nivel anterior se utiliza el signo « = ».
d) Para indicar el incremento de exigencias graduado en
función del nivel de la dimensión de seguridad, se
utilizan los signos « + » y « ++ ».
e) Para indicar que una medida protege específicamente
una cierta dimensión de seguridad, ésta se explicita
mediante su inicial.
IV-A. Valor por omisión de disallow para todos los robots
Debido al gran número de arañas de buscadores, es nece-sario
realizar este bloque para todos los agentes:
User-agent: *
Disallow: /
Este fichero indica a las arañas que no se desea ser in-dexado
y no volverán a intentar indexar el sitio hasta que,
manualmente, se pida su indexación. Si no se realiza esta
configuración antes de poner el sitio en producción, los datos
de la organización pueden estar copiados durante una cantidad
incierta de tiempo en una gran cantidad de buscadores y será
necesario realizar un borrado manual en todos ellos.
IV-B. Autocatalogación: SI/NO
Los sistemas deben decidir qué contenidos son privados y
cuales son públicos. A partir de esta clasificación es preciso
determinar si las diferentes ubicaciones del servidor correspon-den
a una ruta pública o a una ruta privada.
IV-C. Optimización rendimiento y SEO con sitemap.xml
Para asegurar un rendimiento óptimo del consumo de re-cursos
por parte de los robots en un sitio se recomienda
una configuración adecuada del archivo sitemap.xml. Como
resultado se consigue mejorar el rendimiento del sistema,
mejorar la calidad de servicio y evitar los ataques de hijacking
SEO.
IV-D. Auditoría
Además de las auditorías a las que deberían estar sujetas
las aplicaciones informáticas ofertadas por el sitio es preciso
realizar un análisis exhaustivo del fichero robots.txt así como
de los ficheros sitemap.xml para validar el comportamiento
del sistema y la estructura de estos archivos.
Categoría Básica
Antes de pasar a producción se comprobará el correcto
funcionamiento del sistema.
a) Se comprobará que se cumplen los criterios de seguridad
b) Se harán pruebas en un entorno aislado
c) Las pruebas no se harán con datos reales.
d) Se diseñará un sistema de auditoría constante que con-temple
la naturaleza viva de muchos sitios web de
Internet y que se traduzca en una reevaluación de las
configuraciones de robots y sitemap.xml. Para ello se
deben revisar:
a) Posibles fugas de datos en buscadores de Internet.
b) Solicitar el borrado de la URL de los índices de
los buscadores en caso de fugas.
Categoría Media
Se realizarán las siguientes inspecciones previas a la entrada
en producción:
a) Análisis de vulnerabilidades.
b) Pruebas de intrusión derivadas del uso del sistema de
indexación.
Categoría Alta
Se debe contemplar la siguiente línea de actuaciones:
a) Análisis de cumplimiento con la calidad de servicio.
b) Análisis de rendimiento del sistema.
V. CONCLUSIONES
A partir del modelado de las amenazas asociadas a una
incorrecta configuración de las técnicas de optimización para
el indexado de páginas web se ha propuesto una línea de
actuación orientada a proporcionar una gestión eficaz de dichas
técnicas SEO. Para ello se ha propuesto un conjunto de buenas
prácticas y se ha adecuado su redacción al Esquema Nacional
de Seguridad. En esta redacción se ha optado por un enfoque
más conciso de lo que es habitual en la propuesta inicial del
ENS buscando una mejor aplicabilidad del mismo.

6.
Dimensiones Medidas de seguridad
Afectadas BAJO MEDIO ALTO mp Medidas de protección
mp.seo Protección de sitios web
C aplica = = mp.seo.1 Valor por omisión:Disallow para todos los robots
C,D aplica = = mp.seo.2 Auto-catalogación si/no
D n.a aplica = mp.seo.3 Optimización del rendimiento y SEO con sitemap.xml
Categoría aplica + ++ mp.seo.4 Auditoría
Cuadro I
CORRESPONDENCIA ENTRE LOS NIVELES DE SEGURIDAD EXIGIDOS EN CADA DIMENSIÓN Y LAS MEDIDAS DE SEGURIDAD
REFERENCIAS
[1] M. Carl Drott, “Indexing aids at corporate websites: the use of robots.txt
and META tags”, Information Processing & Management 38(2), 209–
219, 2002.
[2] http://www.sitemaps.org/es/
[3] Ministerio de la Presidencia, “Real Decreto 3/2010, de 8 de enero, por
el que se regula el Esquema Nacional de Seguridad en el ámbito de la
Administración Electrónica”, BOE 25(I), 8089–8138, 2010.
[4] Jefatura del Estado, “Ley 11/2007, de 22 de junio, de acceso electrónico
de los ciudadanos a los Servicios Públicos”, BOE 150, 27150–27166,
2007.
[5] Antonio Martínez, “Esquema Nacional de Seguridad: Seguridad Obliga-toria
en las AAPP”, red seguridad 44, 74–76, 2010.
[6] Urs E. Gattiker, The information security dictionary, Kluwer Academic
Publishers, Boston 2004.
[7] Ross A. Malaga, “Search Engine Optimization–Black and White Hat
Approaches”, In: Marvin V. Zelkowitz, Editor(s), Advances in Computers:
Improving the Web, 78, 1–39, Elsevier, 2010.
[8] Johnny Long, Google Hacking, Syngress, 2007.
[9] http://www.mamboserver.com
[10] http://www.informatica64.com/foca/