Solución simulacro   Primeros pasos para resolver el ejercicio    Es interesante dar un nombre al sistema.   Es conveniente identificar:  

● Punto de vista del negocio  ○ Cuál es el principal objetivo del sistema  ○ Quiénes son los “stakeholders”  ○ Cuáles son las principales dificultades  

● Punto de vista de la solución técnica  ○ Qué tipo de sistema nos están pidiendo  ○ Actores, interacciones y módulos del sistema  ○ Diagrama de contexto.  ○ Diagrama de módulos (opcional).  

  Se recomienda repartir el tiempo para resolver las cuestiones. En este caso 5 horas, dado que el examen en 2014 será de 4 horas máximo, se recomienda hacerlo en cuatro horas hasta la pregunta 12 inclusive, y una hora más para las cuestiones adicionales.  Propuesta de gestión del tiempo:  

● Una hora para interpretación del enunciado y primeros pasos.  ● Repartir aproximadamente el tiempo restante (unos 220 minutos) entre el total 

de preguntas (y 20 min para repaso).  ● 12 cuestiones y 4 adicionales (en principio menos tiempo en estas últimas)  ● Unos 10­15 min por cuestión y 10 para las adicionales, teniendo en cuenta 

que: Alguna llevará más tiempo (ej. planificación, arquitectura física, pregunta con varios apartados...).  

 Se puede reservar más tiempo para aquellas que se nos den mejor (sin descompensar el examen!).   No es necesario contestar todos los apartados ni condición necesaria para aprobar,  pero es deseable (por lo menos indicar la respuesta).   Si es recomendable tener presente el reloj y los tiempos para cada apartado a lo largo  del examen.   

1 

1.  Resumen ejecutivo del proyecto, que contemple los objetivos, resultados,                 características y la magnitud de su impacto económico. 

 El resumen ejecutivo, la nota al Ministro, etc… son preguntas que en los últimos                           

examenes han centrado gran parte de la atención del tribunal.  Si bien el enfoque que cada uno le de es muy personal, a continuación os indicamos                               

unas pautas a tener en cuenta que os serán de utilidad para afrontar este tipo de                               preguntas: 

 ● Lo primero es identificar el objetivo perseguido por el texto solicitado. En la                         

mayoría de los casos el objetivo será conocer el sistema, sus ventajas y el                           valor que aporta el mismo. 

○ Este primer paso condicional completamente el enfoque que se le de                     al texto. 

● A continuación se debe analizar el tipo de destinatarios finales del texto. En la                           mayoría de los casos, se tratará de un interlocutor no técnico. 

○ Esto exige orientar el texto hacia lo funcional y dejar fuera los detalles                         técnicos. 

● A continuación, una vez conocido el objetivo e identificados los interlocutores                     destinatarios del texto, es importante seleccionar los aspectos del sistema a                     incluir, es decir, los más importantes o que aportan más valor para el                         contexto y los interlocutores indicados por el enunciado. 

○ Resulta especialmente importante resaltar los puntos estratégicos del               proyecto, encuadrándolo si es posible en el contexto que se describa                     en el enunciado. 

● Por último, es importante tratar de contextualizar el texto que se redacte de                         forma que se resalten los aspectos del sistema seleccionados como                   relevantes. 

● Redacción: ○ El estilo y la redacción son fundamentales en este tipo de preguntas. ○ En la mayoría de los casos se trata de un texto “formal”, por lo que se                               

ha de enfocar el texto de una forma impersonal Ej: “se va a realizar” en                             lugar de “vamos a realizar”. 

● El tono empleado ha de ser neutro, resaltando las virtudes del sistema                       sin caer en la imparcialidad. 

● Por último resulta esencial que la extensión del texto sea razonable. 2.  Diseño de un diagrama de clases que muestre el dominio de la aplicación. 

  

 

2 

  

Es importante tener en cuenta que hay elementos que suelen repetirse en los casos                           de administración electrónica, como puede ser la clase expediente, la clase                     documento o la clase registro, si bien es cierto que pueden existir otras fórmulas.   Por otro lado, el hecho de poner de manifiesto clases que modelen la realidad del                             problema y que expresen que se ha comprendido el peso de los diferentes elementos                           del enunciado, implica demostrar que se ha comprendido mejor el ejercicio.  

3 

Es esencial ser proporcionado en la forma del diagrama. Un exceso de atributos (por                           ejemplo, los presentes en el anterior diagrama quizá son demasiados) en las clases                         puede aportar muy poco valor para el tiempo que se pierde. Por otro lado, si lo que                                 piden en el enunciado es establecer una gran cantidad de atributos, sí que habría que                             reflejarlo.  Conviene indicar las cardinalidades, siempre que sea posible. En UML, la cardinalidad                       de las relaciones indica el grado y nivel de dependencia. Se anotan en cada                           extremo de la relación y éstas pueden ser: o uno o muchos: 1..* (1..n) o 0 o                                 muchos: 0..* (0..n) o número fijo: m (m denota el número). Tener en cuenta que para                               las cardinalidades no siempre hay una solución única: a veces es muy claro que un                             operador puede consultar varios expedientes y que varios expedientes pueden ser                     consultados por varios operadores. Sin embargo, un expediente podría ser consultado                     sólo por un funcionario o no (se le da permiso a otros funcionarios a entrar), según                               cómo ideemos el sistema. 

  3.  Diseño de los principales casos de uso tomando en cuenta la descripción                       

ofrecida.  

Es importante poner de manifiesto que estos casos de uso son especialmente                       extensos y que ocuparían demasiado tiempo en un examen. Aún así, son un                         excelente ejercicio para practicar. Se puede hacer un diagrama de casos de uso en                           función de cada trámite, por sencillez del diagrama. O bien agrupar todos, para tardar                           menos, utilizando algunos casos de uso auxiliares que permitan evitar el cruce de                         líneas. Es importante insistir en que lo normal en un ejercicio es encontrar algo más acotado,                             bien por trámite o bien uno global pero algo más limitado. Aún así, podrían llegar a ser                                 complicados (de hecho en la convocatoria 2011 lo fue) por lo que no es bueno                             subestimar este diagrama y de ahí la importancia de realizarlo, para practicar al                         máximo. Los diagramas que se han adjuntado como imágenes fuera de este documento son                         un buen ensayo para llegar al diagrama grande que se sitúa justo a continuación. 

 PUNTO DE VISTA SOLICITANTE:  

4 

 

5 

PUNTO VISTA OPERADOR 

 PUNTO VISTA JPIT 

 Se debe tener en cuenta que faltaría el caso de uso relativo al instalador, que sólo                               puede remitir el protocolo y el boletín. Se trata de un caso de uso sencillo, un                               subconjunto de todo lo que podría hacer el proyectista, por lo que no se ha insistido en                                 su representación. 

 

6 

4.  Diseñe el diagrama de secuencia desde la entrega de boletín y protocolo hasta                         su posible descarga ya tramitados. 

  Diagrama de secuencia para la identificación:  

Este diagrama se ha desglosado del diagrama que se pedía por motivos de claridad,                           si bien es cierto que es más lógico ponerlo juntos, en un sólo diagrama. En cualquier                               caso, se trata de algo importante a reflejar en el diagrama, puesto que sin este paso,                               no se podría realizar la segunda parte. 

  

Diagrama de secuencia desde la entrega de boletín y protocolo hasta su posible                         descarga ya tramitados. 

  

7 

  5.  Arquitectura lógica: 

a.       Diseñe un diagrama de arquitectura lógica b. Describa los diferentes módulos y las razones concretas de su                     

inclusión, así las posibilidades que existen de reutilización   

8 

   ● Capa de presentación: Interfaz web que permite el acceso a los usuarios de                         

la aplicación mostrando una interfaz distinta en función de la autenticación del                       mismo (autenticación como Proyectista/Promotor, como Operador o como               Funcionario). 

 ● Capa de lógica de negocio: Cuenta con los siguientes módulos: 

○ Tramitación de ICTs: ■ Módulo que alberga la lógica de negocio asociada a todos los                     

trámites relacionados con la presentación del proyecto de ICT                 realizados por parte del proyectista. 

 ○ Comunicación Colegios: 

■ Módulo encargado de la comunicación con los Colegios               Oficiales de Telecomunicación para llevar a cabo la validación y                   descarga de los proyectos presentados ante el Minetur,               

9 

basándose para ello en el código de verificación. Asimismo, se                   encarga del intercambio de documentación con los mismos en                 caso de que proceda.  

 ○ Consulta Operadores: 

■ Módulo encargado de la comunicación con los Operadores               para el intercambio de información en relación con la ubicación                   de la arqueta. Permitirá el intercambio de información necesaria                 para la identificación de la finca sobre la que se tramita la ICT                         así como la asociación al expediente correspondiente de la                 información que cada uno de los operadores proporcione. 

 ○ Gestión expedientes ICTS: 

■ Módulo encargado de la gestión del ciclo de vida del expediente                     en el “backoffice”, por parte del personal funcionario de las                   JPIT. Para cada uno de los trámites realizados por el                   proyectista/promotor u operador, se desencadenará una serie             de revisiones, notificación, generación y firma de oficios (por                 parte del responsable de la JPIT a través del portafirma                   corporativo, etc.). 

 ○ Administración: 

■ Módulo transversal encargado de tareas como por ejemplo la                 gestión de usuarios o la configuración de la aplicación, todo ello                     de acuerdo con las directrices de seguridad aplicables en el                   Ministerio.  

 ○ Tramitador administrativo: 

■ Módulo encargado de la tramitación asociada a todos los                 trámites del procedimiento administrativo que respalda           jurídicamente a la aplicación (procedimiento descrito en el               enunciado). 

 ○ Acceso a Datos: Permite el acceso a la capa de datos, tal y como se                             

describe en el siguiente punto.  

○ Acceso a Servicios: Permite el acceso a la capa de servicios, tal y                         como se describe en el siguiente punto. 

 ● Capa de acceso a datos: 

○ Datos: Tal y como se muestra en la arquitectura física, se trata de una                           capa protegida para evitar su acceso indebido. Dentro de esta capa se                       incluyen tanto la Base de Datos (con expedientes, documentos, etc…)                   

10 

como el gestor documental (repositorio común) para la gestión del                   ciclo de vida de los documentos involucrados. 

○ Servicios: Engloba tanto servicios comunes propios del Ministerio (por                 ejemplo el Registro Electrónico) como servicios horizontales a toda la                   administarción (en este caso, @Firma y la Plataforma de                 Intermediación) o servicios ofrecidos por otros organismos a través de                   Servicios Web, como es por ejemplo el caso de los servicios ofrecidos                       por el COIT. 

 En cuanto a la reutilización, cabe destacar que se ha apostado por el uso del                             máximo número de servicios horizontales, tanto dentro del Ministerio como en el                       ámbito de la AGE. En cuanto a los módulos, serían fácilmente reutilizables por                         otras áreas de desarrollo los módulos de administración y el módulo de                       tramitación de expedientes, debido a su carácter común en gran parte de                       proyectos de eadministración.   

 6.  Indique qué Normas Técnicas de Interoperabilidad deberían considerarse para                 

llevar a cabo la presente aplicación.   

● Norma Técnica de Interoperabilidad de Catálogo de estándares: ○ Justificación: La Norma Técnica de Interoperabilidad de Catálogo de                 

estándares tiene por objeto establecer un conjunto de estándares que                   satisfagan lo previsto en el artículo 11 del Real Decreto 4/2010, de 8 de                           enero, por el que se regula el Esquema Nacional de Interoperabilidad                     en el ámbito de la Administración Electrónica. 

○ Es como la base para definir los estándares que se han de usar en                           todo ello. 

■ Esencial para que el sistema sea interoperable y reutilizable. ○ En el caso propuesto, esta NTI es importante en cuanto a que se ha de                             

intercambiar información con otras entidades (JPIT, Colegios de               Ingenieros, AEAT…).  

● Norma Técnica de Interoperabilidad de Documento Electrónico: ○ La Norma Técnica de Interoperabilidad de Documento electrónico tiene                 

por objeto establecer los componentes del documento electrónico,               contenido, en su caso, firma electrónica y metadatos, así como la                     estructura y formato para su intercambio. 

○ Fundamental para estructurar todos los documentos electrónicos que               componen el expediente. 

11 

○ En el caso propuesto, existe gran cantidad de documentos                 participantes del procedimiento por lo que se hace importante                 homogenizar.  

● Norma Técnica de Interoperabilidad de Expediente Electrónico: ○ La Norma Técnica de Interoperabilidad de Expediente electrónico tiene                 

por objeto establecer la estructura y el formato del expediente                   electrónico, así como las especificaciones de los servicios de remisión                   y puesta a disposición.

○ Esencial para la definición del Expediente del sistema. ○ En el caso propuesto, la tramitación gira entorno a un expediente                     

administrativo que recoge la información correspondiente a esa ICT.                 También es vital de cara al intercambio con otros organismos. 

 ● Norma Técnica de Interoperabilidad de Política de Firma y de Certificados de                       

la Administración: ○ La Norma Técnica de Interoperabilidad de Política de firma electrónica                   

y de certificados de la Administración tiene por objeto establecer el                     conjunto de criterios comunes asumidos por la Administración pública                 en relación con la autenticación y el reconocimiento mutuo de firmas                     electrónicas basadas en certificados y que, como tales, serán                 desarrollados y consolidados a través de las políticas de firma                   electrónica basada en certificados. 

○ El objetivo final de esta NTI es facilitar el uso de firmas electrónicas                         seguras e interoperables entre las distintas organizaciones de la                 Administración pública. 

 ● Norma Técnica de Interoperabilidad de Política de Gestión de Documentos                   

Electrónicos: ○ La Norma Técnica de Interoperabilidad de Política de gestión de                   

documentos electrónicos tiene por objeto establecer las directrices               para la definición de políticas de gestión de documentos electrónicos. 

○ Se asocia al archivado pero debería aplicar a todo el ciclo de gestión                         del documento también “en vida”. Habría que acogerse a lo que tiene la                         organización ya establecido  

● Norma Técnica de Interoperabilidad de Reutilización de recursos de la                   Información. 

○ La Norma técnica de interoperabilidad de reutilización de recursos de                   información tiene por objeto establecer el conjunto de pautas                 básicas para la reutilización de documentos y recursos de                 

12 

información elaborados o custodiados por el sector público a los                   que se refiere el artículo 3 de la Ley 37/2007. 

○ Dado que la selección de la información debe basarse en su                     importancia en relación con su fin social y económico, datos relativos a                       la implantación de ICTs, el tipo de vivienda en que se realizan, tamaños                         de empresas en este mercado o de implicación de operadores en el                       proceso son absolutamente prioritarios. Esto se debe a que el modelo                     de ICTs ha sido pionero en el mundo y está en proceso de exportación,                           por lo que aportar datos que beneficien a su expansión son muy                       positivos para potenciar la fuerza de las empresas españolas en el                     mercado internacional. 

○ El esquema de URI, los protocolos de seguridad y los formatos                     implicados, respetarán lo establecido en la NTI. 

 Aspectos interesantes 

¿Aplicación de Norma Técnica de Interoperabilidad de Protocolos de                 Intermediación de Datos a los Colegios?: No le aplica necesariamente, al ser corporaciones de Derecho público, pero                     que se rigen por Derecho privado, aunque en aquellas cosas en las que                         ejercen facultades de Derecho administrativo sobre sus miembros, también                 les aplica el administrativo. En este caso, su labor no es administrativa, sino                         de entidad de verificación, que bien podría ser una empresa privada, por lo que                           no aplicaría.     

 7.  Diseñe gráficamente un esquema XSD de expediente electrónico, que cumpla                   

con los requisitos de lo establecido en la NTI de expediente electrónico.                       Diseñe gráficamente el esquema XSD de los metadatos del mismo, indicando                     aquellos que se consideren más importantes. Indique qué tipos de firmas                     utilizaría para cada uno de los siguiente documentos, exponiendo los motivos: 

a.       Proyecto y modificaciones b.      Autorizaciones entre proyectista y promotor c. Boletines, proyectos, certificados de fin de obras, protocolos y                   

certificados de la jefatura provincial, todos ellos firmados por el                   jefe provincial. 

 Para empezar, conviene recordar qué es un expediente electrónico:  

13 

 

 A la hora de pensar en un expediente, conviene tener en cuenta algunos                         

elementos: ­ Los documentos van entrando a nuestro sistema desde que se inicia el                         

expediente hasta etapas posteriores.  ­ Cada documento cumple con la NTI de Documento electrónico y por                       

tanto se ve acompañado de sus metadatos y su firma.  ­ Cada documento queda guardado, de manera que dependiendo su                   

naturaleza, puede quedar guardado bajo un sistema u otro. Por                   ejemplo, un pdf de un proyecto podría quedar guardado en un gestor                       documental. 

 ­ El expediente no es más que una agrupación lógica de estos                       

documentos y sus metadatos. Para crear esa agrupación lógica, se                   crea un índice y se añaden unos metadatos al expediente                   (independientes de cada documento individual), y además se firma (el                   expediente). 

 ­ La gestión de los metadatos puede ser enfocada de diferentes maneras,                       

como por ejemplo, mediante el propio gestor documental.  

Para organizar esta agrupación, la NTI ofrece un sistema mediante el que establecer                         un índice y unos metadatos estandarizados, expresados en un esquema XSD                     genérico. Los metadatos identifican al expediente y asocian a diferentes elementos                     del mismo (autor, promotor, descripción, etc.). El índice electrónico “constituye un                     objeto digital que contiene la identificación sustancial de los documentos electrónicos                     que componen el expediente debidamente ordenada para reflejar la disposición de los                       documentos, así como otros datos con el fin de preservar la integridad y permitir la                             recuperación del mismo, en los términos del artículo 32.2 de la citada Ley 11/2007, de                             22 de junio” 

14 

Esos metadatos mínimos obligatorios y ese índice que identifica los documentos                     (guardados en el repositorio en cuestión, para su posterior recuperación e                     intercambio) son los que se organizan en el XSD. Gracias a ello, se identificará bien al                               expediente, se podrá intercambiar de una forma ordenada y se garantizará su                       integridad y su recuperación. Para el intercambio, se envía primero el índice.                       Posteriormente, se enviarán los documentos que lo componen, uno a uno, y                       siguiendo la distribución reflejada en el contenido del Índice. 

En cuanto a los esquemas que indica la NTI de expediente electrónico para su                           intercambio, se puede consultar en el anexo I de la guía de aplicación: 

 

http://www.mpt.gob.es/dms/es/publicaciones/centro_de_publicaciones_de_la_sgt/GUIAS_NTI/text_es_files/Guia_expediente­electronico­INTERNET.pdf  

 Se ve una serie de esquemas genéricos. Hay que tener en cuenta algunos hechos:  ­ Los metadatos mínimos obligatorios genéricos son siempre los mismos para todos                       los expedientes. ­ La visualización del Índice es opcional y sirve para dar una visualización alternativa                           de la información del expediente, como puede ser el índice o el contenido completo de                             los documentos que lo conforman.  Por ello, se centra el interés en dos puntos:  ­ Metadatos complementarios ­ Índice  Comenzamos con los primeros: 

   

15 

 Notar que el solicitante (interesado) es un metadato mínimo obligatorio, por lo que no                           figura aquí.  Por último, quedaría el índice. Se propone a continuación una solución, si bien existen                           múltiples soluciones alternativas a esto. En este caso se ha optado por mostrar                         únicamente dentro del índice documentos del caso práctico, pero pueden existir otros                       expedientes dentro del primero, así como otras carpetas, tal como indica la NTI. 

  

16 

   

b) En cuanto al FORMATO de firma para los DOCUMENTOS (no el índice                         electrónico, eso NOes lo que pide el enunciado), hay que tener en cuenta: 

● Muchos documentos ya se introducen en el sistema firmados con PAdES                     (admitido por la NTI). Pero para garantizar 100% de intervenciones firmadas,                     cada solicitud y el conjunto de sus datos adjuntos es firmada con XAdES                         (independientemente de la firma de los proyectos antes comentada). Téngase                   en cuenta que así, también se firma la solicitud y otros documentos que                         pudieran no estar firmados. 

● Se necesita garantía de firma por 15 años. ● No requiere altos requerimientos de seguridad (no nivel alto ENS). ● Se trabaja con @firma y las AC parecen relativamente estables. 

○ Se puede añadir referencias a datos de verificación ○ No hace falta, en principio, por estas razones incluir los datos de                       

verificación de la firma (puede realizarse a través de respuestas OCSP                     o CRL). Esto es algo que hay que tener en cuenta ya que la NTI de                               política de firma hace énfasis en ser proporcionados (ver epígrafe                   7.3.128 de la guía de aplicación de la NTI de política de firma). 

● Esto coincide con XAdES­C  

17 

 Este tipo de firma coincide con XAdES­C y daría cobertura a las medidas de firma                             electrónica para nivel medio del ENS (en lo relativo a Integridad y Autenticidad), lo que                             está por encima de las necesidades de este sistema. Esto, por otra parte, exigiría el                             sellado de tiempo sobre la firma, lo cual habría que detallar.  http://zonatic.usatudni.es/es/aprendizaje/aprende­sobre­el­dnie/57­aspectos­tecnicos/208­sistemas­actuales­de­autenticacion­y­firma.html  Pag 43 http://www.boe.es/boe/dias/2010/01/29/pdfs/BOE­A­2010­1330.pdf (ENS)  En cuanto al TIPO de firma, la NTI admite para XAdES, dos maneras: 

  Cualquiera puede llegar a ser válida, si se justifica la razón para su elección, si bien                               XAdES internally detached es aconsejable por ser fácil de extraer del conjunto de los                           documentos en un expediente. Es importante insistir en no confundir con el campo firmas del expediente electrónico:                         el enunciado pide qué firmas se aplicarían a una serie de documentos, (a todos la                             misma), pero no la firma del índice del expediente. 

  8.  Explique el mecanismo y tecnología que utilizaría el sistema para realizar el                       

posible trámite de verificación con el Colegio Oficial de Ingenieros de                     Telecomunicación, teniendo presente los datos adicionales proporcionados en               el enunciado. 

 El proceso que siguen ahora es:  

1­ En el momento de adjuntar el proyecto, la aplicación utiliza el código de                           verificación para consultar si pertenece a un proyecto real, a través de un servicio                           web publicado en el colegio. Esta respuesta es síncrona y se realiza en el mismo                             momento del trámite: el colegio recibe un código de verificación y consulta si                         disponen de un proyecto registrado para el mismo. 

 2a­ En caso de resultado negativo en la etapa 1, el sistema rechaza el trámite y el                                 solicitante no puede solicitar la ICT.  

18 

 2b ­ En caso de resultado positivo en la etapa 1, el sistema crea una cola con los                                   proyectos que es necesario comprobar, procedentes de diversos expedientes, y                   automáticamente se lanza un proceso nocturno que realiza las descargas pendientes                     y almacena cada proyecto en su correspondiente expediente. Dichos proceso sigue                     los siguientes pasos:  

1. Consulta otros dos métodos del servicio web del Colegio, para cada uno de                         los proyectos “en cola”: 

a. El primero verifica que dicho código realmente es válido, a modo de                       confirmación. 

b. El segundo obtiene la ruta donde se encuentra el fichero en el servidor                         FTP de cada colegio. 

 2. Una vez que se tiene el dato anterior, el MINETUR conecta con los servidores                           

FTP de cada Colegio (a través de un usuario con permisos) y directamente                         descarga los ficheros cuya ruta obtuvo en el paso anterior.  

3. En caso de que exista algún problema, por ejemplo que la memoria realmente                         no exista (aunque el resultado del paso 2 fuese positivo) o que se produzca un                             problema en la descarga, se genera un log de errores y al final del proceso se                               remite un correo al colegio correspondiente para que solvente la incidencia                     detectada. El proyecto en cuestión se mantiene en la cola y al día siguiente se                             vuelve a intentar descargar. 

 

  

 

19 

9.  Describa cómo implementaría la funcionalidad de consulta sobre la ubicación                   de la arqueta descrita en la Etapa 2. Esta consulta, iniciada por el proyectista e                             intermediada por MINETUR, deberá ser trasladada a todos los operadores que                     den servicio en la zona, quienes deberán dar respuesta en el plazo de un mes. 

 Alguna indicación sobre la solución real:  

1. En el momento en que el proyectista registra la localización de la arqueta en el                             expediente, a través de una solicitud, se inicia el procedimiento de consulta. 

 2. Para localizar a los operadores a los que remitir la consulta (los que operan en                             

la zona), se utilizará una funcionalidad de localización geográfica, a partir de                       las coordenadas que introduce el proyectista (o directamente del municipio).                   Cada operador está obligado a indicar y mantener actualizados los municipios                     en los que opera.  

3. En el sistema real, han aprovechado la funcionalidad de una aplicación                     existente (el propio Registro electrónico) para el intercambio de información                   entre el proyectista y los operadores. “El Registro Electrónico es un sistema                       externo al desarrollo encargado de crear expedientes y de realizar entradas y                       salidas del Registro Electrónico sobre ellos, accesible mediante servicio web”.  

4. Así, el envío del proyectista desencadena la creación de un expediente en el                         Registro con una entrada (que es precisamente la ubicación de la arqueta) y N                           salidas iguales a dicha entrada, una para cada operador, que constituye la                       consulta en sí. 

 5. Los operadores disponen de un plazo de 30 días para contestar, y para ello                           

accederían a su interfaz (ver casos de uso) y allí podrían responder a la                           consulta realizada indicando la conformidad o nueva ubicación, las tecnologías                   con las que llegan, etc.  

 6. Una vez finaliza el plazo (o bien cuando hayan respondido todos los                       

operadores), se crean M entradas en el expediente descrito en el punto 4, una                           para cada operador, y una salida que agrupa estas respuestas hacia el                       proyectista, que recibe por tanto las distintas ubicaciones de la arqueta                     aconsejadas por los operadores (también por email). 

 El siguiente diagrama refleja los principales elementos descritos: 

20 

   

 Como se puede apreciar, el operador también puede gestionar los usuarios y las                         

provincias/municipios (localizaciones) en las que está presente.    

10. Indique cómo aplica el Esquema Nacional de Seguridad realizando el                     proceso de categorización del sistema y seleccionando, al menos, tres                   medidas de seguridad de las previstas en el ANEXO II del ENS. 

Siguiendo el procedimiento de categorización del ANEXO I, se obtiene la siguiente                       categorización: 

 

* Se categoriza la disponibilidad como MEDIA para que el ejemplo sea más ilustrativo.                           Debería ser B, ya que en el enunciado no se indica que la tramitación tenga que ser                                 exclusivamente por medios electrónicos. Además, tampoco se indican plazos de                   finalización de presentación de documentación que puedan hacer más crítico el                     sistema a nivel de disponibilidad. 

21 

Para la selección de medidas es conveniente memorizar varias medidas del Anexo II                         del ENS que sean granulares según el nivel. Des esta forma la solución será más                             particularizada a los niveles definidos en el proceso de categorización. 

Elegimos una que aplica por la dimensión ­ DISPONIBILIDAD (D) = M. 

5.3.4 Medios alternativos [mp.eq.9]. 

 

Se garantizará la existencia y disponibilidad de medios alternativos de tratamiento de                       la información para el caso de que fallen los medios habituales. Estos medios                         alternativos estarán sujetos a las mismas garantías de protección. 

Igualmente, se establecerá un tiempo máximo para que los equipos alternativos                     entren en funcionamiento. 

Elegimos una que aplica por la categoría ­ MEDIA 

4.1.1 Análisis de riesgos [op.pl.1]. 

 

Categoría MEDIA ­ Se deberá realizar un análisis semi­formal, usando un lenguaje                       específico, con un catálogo básico de amenazas y una semántica definida. Es decir,                         una presentación con tablas que describa los siguientes aspectos: 

a) Identifique y valore cualitativamente los activos más valiosos del sistema. 

b) Identifique y cuantifique las amenazas más probables. 

c) Identifique y valore las salvaguardas que protegen de dichas amenazas. 

d) Identifique y valore el riesgo residual. 

Elegimos una que aplica por dimensión ­ I C A T = B. 

4.2.5 Mecanismo de autenticación [op.acc.5]. 

22 

 

Nivel BAJO 

a) Se admitirá el uso de cualquier mecanismo de autenticación: claves concertadas,                       o dispositivos físicos (en expresión inglesa »tokens») o componentes lógicos tales                     como certificados software u otros equivalentes o mecanismos biométricos. 

b) En el caso de usar contraseñas se aplicarán reglas básicas de calidad de las                             mismas. 

c) Se atenderá a la seguridad de los autenticadores de forma que: 

1.º Los autenticadores se activarán una vez estén bajo el control efectivo del usuario. 

2.º Los autenticadores estarán bajo el control exclusivo del usuario. 

3.º El usuario reconocerá que los ha recibido y que conoce y acepta las obligaciones                             que implica su tenencia, en particular el deber de custodia diligente, protección de su                           confidencialidad e información inmediata en caso de pérdida. 

4.º Los autenticadores se cambiarán con una periodicidad marcada por la política de                         la organización, atendiendo a la categoría del sistema al que se accede. 

5.º Los autenticadores se retirarán y serán deshabilitados cuando la entidad (persona,                       equipo o proceso) que autentican termina su relación con el sistema. 

 

Independientemente de la categorización de los sistemas, la mayoría de los                     Ministerios y algunos organismos autónomos disponen de un sistema de detección                     de intrusión (4.6.1 Detección de intrusión [op.mon.1]) que se corresponde con la                       sonda del CERT del Centro Criptológico Nacional (Se muestra en el diagrama del                         siguiente apartado). 

Además de las medidas seleccionadas y, teniendo en cuenta la debilidad del                       

23 

protocolo FTP ante ataques de fuerza bruta, es conveniente reforzar el sistema con                         medidas de seguridad adicionales. Se propone: 

● Acceso por FTP seguro SFTP mediante certificados de cliente desplegados                   en MINETUR para conectar a cada uno de los colegios. Esta medida garantiza                         la confidencialidad gracias al cifrado y evita que se puedan conseguir usuarios                       y contraseñas. 

● Conectividad VPN site to site con los colegios que dispongan de                     infraestructura con capacidad de establecer el túnel entre los cortafuegos. En                     este caso el servidor de FTP no estaría accesible para cualquier usuario                       desde Internet. 

   

    

24 

11.   Infraestructura física: a. Diseñe un diagrama de infraestructura física que de soporte al sistema                       que se pretende implementar.  

  

● Se identifican los agentes que acceden al sistema. ● Se separan los entornos por tipo de arquitectura y perímetro de interconexión, 

teniendo en cuenta las redes privadas o públicas por las que va el tráfico. 

25 

● La alta disponibilidad se puede garantizar por diversos mecanismos, como balanceadores, virtualización o clúster (en los servidores de bases de datos o de ficheros). 

 Integración con infraestructura existente Si el enunciado no indica que es un Ministerio/Organismo de nueva creación y, en caso de pedir presupuesto, sería conveniente suponer que se dispone de infraestructura básica de red y comunicaciones (líneas, routers, switches, seguridad perimetral, etc). Se puede presuponer la existencia de un Gestor de Bases de Datos, presupuestando así sólo la parte de servidores de aplicaciones/Web adicionales.  Si fuera un organismo nuevo y los plazos de implantación son cortos, se pueden plantear modalidades de infraestructura como servicio, o plataforma como servicio. 

  

b. Con ayuda de las tablas de los anexos, dimensione las líneas de                         comunicación para la comunicación con los Colegios de Ingenieros de                   Telecomunicación, teniendo en cuenta que se prevé que un 70% de los                       expedientes  vean adjuntado el proyecto por este medio:  Tomando la gráfica 1, se puede observar que de 2014 hacia adelante, el número de                             expedientes anuales queda estabilizado en 2000 unidades, aproximadamente. De                 estos, 70% se entrega por la vía de Colegio Oficial, lo que significa un total de 1400                                 expedientes anuales.  1400/12≈120 expedientes mensuales.  Del extracto al subdirector, se deduce que Junio es el mes peor, ya que necesitan                             contratar a más gente para tramitarlos (no confundir con contratación de personal                       para desarrollar el sistema), con un número de expedientes que puede triplicar a lo                           que sería la media, es decir, 360 expedientes. Se divide por el número de días.                             Podrían ser 30 días al mes, pues se trata de administración electrónica 24x7, pero es                             cierto que el grueso de los expedientes suelen entrar en días laborables, lo que añade                             asimismo un cierto margen de seguridad al cálculo.  360 expedientes/20 días laborables = 18 expedientes diarios.  El caso peor es de unos 100 MB (a la vista de las capturas de pantalla del anexo) y                                     esto ya supone un margen de seguridad más que suficiente en caso de picos diarios                             en los que haya más expedientes que la media, pues no todos los expedientes van a                               ser de 100 MB. Se toman 10 horas diarias para transferencia de archivos.  

26 

  ,  Mbps10 horas∙3600 segundos18 expedienets∙100MB∙8bit/Byte = 0 4  

 Con un ancho de banda 512 kbps existe una capacidad más que suficiente para                           ofrecer estos servicios.  Las líneas de comunicaciones englobadas dentro de un Plan Director de                     Comunicaciones licitado por Procedimiento Abierto (concurso). En las               comunicaciones internas de los organismos se suele utilizar tecnología MPLS del                     operador, mientras que en la salida a Internet nos podríamos encontrar líneas                       dedicadas de fibra hasta el operador (100 Mbps, 1 Gbps), dependiendo del ancho de                           banda requerido. Es razonable tener dos y, si es posible, de operadores distintos.  c. Teniendo en cuenta el tipo de documentos y el volumen de información                         que maneja el sistema, describa el tipo de sistema de almacenamiento que se                         debería utilizar:  Volumen de la información dimensionado a partir de la gráfica 1 del Anexo:  

A. A futuro: 15 años x 1400 ICTs/año x 100MB/ICT = 2,1 TB B. ¿A pasado? 83100 ICTs x 100MB/ICT = 8,3 TB. Se dimensiona el volumen de                           

la información pasada por si fuera necesario digitalizarla. Se toman los                     mismos datos de 100 MB/ICT, suponiendo que el proceso de digitalización                     genera ese volumen. 

 En el sistema se almacena información documental (los proyectos) y relacional en                       bases de datos. La información documental de los proyectos presentados tiene una                       tasa de accesos muy baja y no se modifica después de su recepción, mientras que la                               información relacional de la base de datos necesita ser almacenada en un sistema de                           almacenamiento con mayor capacidad de entrada/salida. Esta clasificación de                 información es típica en proyectos de Administración Electrónica en los que se                       presenta una documentación que debe permanecer inalterable con el paso del                     tiempo.  Dentro de las clasificaciones teóricas de los sistemas de almacenamiento (la mayoría                       de los sistemas de almacenamiento empresarial actuales ofrecen capacidades de                   ambos mundos) tenemos:  

● SAN ­ Almacenamiento en bloque de alto rendimiento, alta tasa de                     entrada/salida (IOPs) y posibilidad de conexión de muchos servidores. 

● NAS ­ Almacenamiento en red en modo sistema de ficheros, menor capacidad                       de entrada/salida 

 

27 

Es razonable pensar que el Ministerio responsable de las ICTs dispone de un sistema                           de almacenamiento SAN/NAS y para el presente proyecto se requiere una ampliación                       de 10 TB de espacio neto (los algoritmos de redundancia RAID y otra información                           añaden un porcentaje de espacio en bruto).  Se recomienda buscar información para aplicarla a los supuestos sobre:  

● Conceptos de almacenamiento jerárquico (tiering), deduplicación, archivado             (archiving).  

● Del mismo modo, las tecnologías específicas de almacenamiento según el                   tipo de dispositivo, como array de memoria, Flash/SSD, Fibrechannel (FC) o                     SATA.  

● Los fabricantes líderes en el mercado según informes de Gartner son EMC,                       NetApp e Hitachi. 

    

12. Dimensione los recursos del proyecto y realice un diagrama de Gantt en el                           que se distingan las diferentes fases del proyecto y los hitos principales.  Indicaciones:  

● La duración estimada del proyecto, tras la contratación, es de 12 meses                       aproximadamente. No obstante, se ha paralelizado el desarrollo de módulos                   relacionados durante la fase CSI, por lo que este tiempo podría ser superior si                           se realizasen de forma secuencial (y en cualquier caso es una estimación a                         partir de la complejidad estimada de los módulos). 

 ● La contratación se estima en tres meses, si bien en el último mes se                           

comienza con las tareas de análisis, llevadas a cabo por personal funcionario.   

● Dicha contratación se realizará mediante un contrato de servicios, siguiendo el                     procedimiento de contratación centralizada a través del Catálogo de la D.G. de                       Patrimonio del Estado, ya que se trata del desarrollo de una aplicación                       relacionada con la implantación de la Administración electrónica y la cuantía                     del contrato es inferior al límite establecido. 

  Planificación general (con EVS y contratación) y por fases:    

28 

   

  Resumen del Gantt  

29 

  Estimación del coste Atendiendo únicamente a los recursos subcontratados, los costes del proyecto                   presentado son 148.106 euros, con los siguientes costes por hora.  

  (Nota: hay una pequeña errata porque en los gastos del analista también se ha                           considerado el mes en que se solapa con la fase de contratación, y esta tarea tendría                               que realizarla personal funcionario, y por tanto sin coste externo).   PREGUNTAS ADICIONALES  

a. Se ha detectado fraude en los Ayuntamientos, dado que algunos                     promotores han entregado el resguardo de entrega de boletín,                 protocolo y certificado de fin de obra como si fuera esto el certificado                         del MINETUR que avala la entrega y firma de estos documentos por                       

30 

parte del Jefe Provincial. Describa el formato de resguardo que puede                     darse como respuesta del Registro Electrónico ante la entrega de los                     citados documentos, en pleno cumplimiento de la Ley 11/2007. 

 Para dar pleno cumplimiento a la ley 11/2007 y su desarrollo, es preciso remitirse                           

al artículo 30.3:   

El registro electrónico emitirá automáticamente por el mismo medio un recibo firmado electrónicamente, mediante alguno de los sistemas de firma del artículo 18 de la Ley 11/2007, de 22 de junio, con el siguiente contenido: a) Copia del escrito, comunicación o solicitud presentada, siendo admisible a estos efectos la reproducción literal de los datos introducidos en el formulario de presentación. b) Fecha y hora de presentación y número de entrada de registro. c) En su caso, enumeración y denominación de los documentos adjuntos al formulario de presentación o documento presentado, seguida de la huella electrónica de cada uno de ellos. d) Información del plazo máximo establecido normativamente para la resolución y notificación del procedimiento, así como de los efectos que pueda producir el silencio administrativo, cuando sea automáticamente determinable.

 Según este artículo, los más normal en la aplicación sería que devolviese el                         

resguardo que genera el registro y que tendría un aspecto de este tipo, junto a                             la copia del escrito: 

  

31 

 

32 

  

Este recibo de registro, se ofrece en todas las etapas de la aplicación, salvo en la                               relativa a la de boletín y protocolo, puesto que junto a la copia del escrito que se da,                                   eran entregadas en ayuntamientos como si ya fuese el boletín y el protocolo firmados                           por el JPIT. Por eso, para el caso de boletín y protocolo, la aplicación sólo devuelve un                                 

33 

mensaje de “entrega correcta” y no le da el resguardo. Esto podría parecer ilegal, pero                             no lo es, puesto que un particular podría obtener el resguardo dirigiéndose al registro                           electrónico del MINETUR directamente y descargando su resguardo. Sin embargo, al                     no entregarlo por la aplicación directamente, se ha conseguido, de manera real,                       disminuir el número de casos de fraude. Junto al certificado que expiden los Jefes                           Provinciales y que piden ya muchos ayuntamientos, este tipo de fraude está mucho                         más acotado. Por eso, la aplicación sólo devuelve lo siguiente: 

    b. En línea con la estrategia de lucha contra el fraude emprendida por el                           

Gobierno, desde la AEAT se emprende un proyecto de cruce de datos                       de facturación de autónomos. Para ello, se hace necesario que el                     MINETUR traslade los datos de las empresas/autónomos que realizan                 las ICTs para su contraste con las declaraciones trimestrales realizadas                   por las mismas. 

Describa la arquitectura necesaria para el intercambio de datos                 entre la AEAT y el MINETUR.  Indique la aplicación de la LOPD para este caso concreto. 

 Se trata de una pregunta compleja y al encontrarse en las preguntas adicionales cabe señalar que el objetivo no debe ser entrar detalle, para no restar tiempo al resto de preguntas, sino aportar un conjunto de ideas o claves sobre el problema planteado. 

34 

(De hecho, en este caso realizar la descripción detallada de la arquitectura por sus características organizativas, de seguridad, etc. sería muy complejo). 

Aspectos a tener en cuenta en la solución:  

● Siempre que se incluya un servicio con otro organismo, es positivo revisar si éste está contemplado en la plataforma de intermediación. En este caso, al tratarse de un servicio no incluido, sería necesario utilizar los disponibles en la Agencia para este caso concreto.  

● De cara a la arquitectura de comunicación, es importante tener presente la Red SARA como red comunicación entre organismos. Las características básicas a tener en cuenta de cara a un diseño basado en Red SARA: 

○ Red entre organismos de la AGE en modalidad “todos con todos” sin existencia de un nodo central. 

○ Basado en tecnología VPLS (conexiones de nivel 2 sobre un MPLS) que permite ofrecer Calidad de Servicio. 

○ Soporte 24x7 y acuerdos con SLAs definidos. ○ El tráfico circula cifrado. ○ Velocidades: 

■ 1Gbps entre Ministerios y CPDs. ■ 100Mbps con CCAA. 

 ● Respecto al proceso de intercambio en sí, existen varias posibilidades. Una de 

las más probables es un Servicio Web publicado en la AEAT que se invoque periódicamente desde MINETUR (no nos indican si es síncrono, podemos asumir que no es así). También existirían otras vías posibles, como la transferencia de ficheros, FTP, etc.   

● En este punto, siempre que nos indiquen que tenemos que enviar datos a otro organismo que tiene la misión de procesarlo e integrarlo en su sistema es interesante indicar que se  partirá de los servicios existentes para minimizar el impacto organizativo (asumir que la AEAT recogerá datos de autónomos a más organismos y el servicio ya estará desplegado).  

 Respecto a las implicaciones de la LOPD:  

● ¿Aplica? Dependerá de los datos a ceder a la AEAT. La LOPD no se aplica a los datos de personas jurídicas pero sí a los datos de los empresarios individuales ­ personas físicas (por ejemplo, autónomos) y a los ficheros de empresas que tengan una relación de personas físicas de contacto, esto es, los datos del representante legal de la empresa.  

35 

● ¿Con qué nivel? En función del tipo de dato que fuese requerido al MINETUR aplicaría un nivel u otro de la LOPD. (si no se explica podemos hacer suposiciones). Un resumen: 

  

● ¿Es necesario recoger el consentimiento expreso de la empresa o autónomo? Esta pregunta puede ser confusa si se asocia este trámite a otros como por ejemplo la consulta a la AEAT de si la empresa está al corriente de pagos, el cual debe autorizar expresamente para que lo intermedie el MINETUR. En este caso, dado que se trata de una investigación contra el fraude que realiza la AEAT en el ejercicio de sus competencias no parece necesario informar al ciudadano. Lo que sí se debería es cumplir la LOPD en lo relativo a cesión de datos.  

● ¿Existe una cesión de datos? Según Artículo 11 de la LOPD, no se pueden comunicar datos a otras AAPP para competencias diferentes salvo que: Lo permita una Ley, Que el interesado lo consienta u otras excepciones (fines históricos o estadísticos, deatos de salud por motivos de urgencia...). En este caso se entiende que entra dentro del ejercicio de las competencias de la AEAT, recogidas en la ley. 

 

36 

    

 c. En relación con el trámite descrito en la Etapa 1, de presentación del                           

proyecto inicial, en el supuesto de que no se realice a través del                         Colegio Oficial de Ingenieros de Telecomunicación, la persona que                 firme el proyecto deberá cumplir con la condición de ser “Técnico                     competente”. Esto se traduce en que debe estar en posesión de un                       título universitario válido (no inhabilitado), comprendido en un conjunto                 de posibles titulaciones. 

∙ Describa de forma cualitativa cómo realizaría este trámite,                 asumiendo que el MINETUR debe realizar dicha comprobación               en el momento de aceptar el proyecto. 

   

La clave de esta cuestión es tener presente qué servicios se prestan en la                           plataforma de intermediación (o servicio de verificación y consulta de datos)                     del MINHAP:  http://administracionelectronica.gob.es/ctt/verPestanaGeneral.htm?idIniciativa=svd#.Uz3IG_l_sdU  El catálogo de servicios completo se encuentra en               http://administracionelectronica.gob.es/ctt/resources/e9f8d35f­f21f­41bd­b032­93550ae400b9?idIniciativa=223&idElemento=361   En este caso, el servicio que se debe utilizar es el Servicio de Verificación                           de Datos de Títulos Oficiales (SVDT), ofrecido por el Ministerio de                     Educación y que consta de dos servicios:  

● El Servicio de Verificación de Títulos Universitarios ● El Servicio de Verificación de Títulos No Universitarios. 

 Estos servicios recogen los títulos oficiales registrados para un ciudadano. En                     el caso de los títulos universitarios, es necesario haber pagado la Tasa de                         Expedición para que el servicio muestre la información relativa al título.  Así, dado que MINETUR ya utiliza la plataforma de intermediación en múltiples                       aplicaciones, tan solo es necesario utilizar la infraestructura desplegada dando                   de alta esta aplicación y procedimiento. El sistema de intercambio podría                     realizarse a través de Servicios Web, si bien en este caso es necesario                         

37 

realizar una comprobación manual por parte del gestor a posteriori, ya que las                         titulaciones aceptadas no están identificadas unívocamente y se debe analizar                   cada una por separado.  También es muy importante señalar que será necesario recabar el                   consentimiento expreso del proyectista, de forma que autorice a que sea el                       MINETUR quien realice el trámite en su nombre (informe interesante, sobre la                       cesión de datos y el consentimiento del interesado               http://administracionelectronica.gob.es/ctt/resources/96bb1e2c­fcfa­4f3d­8abc­ef6d74174f93?idIniciativa=223&idElemento=826 ) 

  

d. En futuras fases del proyecto se valorará la incorporación de un                       cuadro de mando para el personal del MINETUR encargado de la                     gestión de las ICTs. Realice una propuesta del mismo, destacando los                     principales indicadores e información a incluir.  

 Con respecto a este apartado, cuando se pide un cuadro de mando, lo normal es                             tratar de de hacer una recopilación de datos que pueden ser de interés para la                             persona afectada, como puede ser en este caso el encargado de la gestión de las                             ICTs. Para él, lo más importante serán los plazos y algo que refleje que el servicio que                               atiende es utilizado y de una cierta importancia. Por ello los plazos y los datos de                               

38 

ICTs que se instalan (que necesariamente reflejan que se usa su servicio) son                         importantes. Otros datos en este sentido podrían ser algunos relativos a incidencias                       de la aplicación, que no figura en el cuadro de mando, entre otras cosas porque un                               servicio de CAU podría estar dando respaldo a esto. Pero además, hay datos que indirectamente importan al gestor:  

● Los costes de la ICT, pues si el coste por vivienda es bajo, significa que no es                                 una carga al ciudadano y que le aporta beneficios relativos a la conexión a                           redes de operadores. Esto hace que la iniciativa sea “vendible” a la dirección y                           que siga apostando por la misma. 

● Las ICTs son algo de lo que se habla internacionalmente y España es ejemplo                           de ella. Dar datos de los costes de los proyectos y del número de ICTs                             instaladas en España dan idea de la fuerza del sector, que al ser pionero                           mundial puede exportar su conocimiento a otros países que estén planeando                     explotar un modelo similar. 

● El número de ICTs, los operadores que llegan a las casas y sus coberturas en                             lo relativo a diferentes tecnologías alimentan datos importantes para informes                   de Sociedad de la Información, lo que justifica al mismo tiempo que esta                         información pueda ser reutilizable. 

 Por último destacar que sólo se pide el cuadro de mando. Si se pidiese la tecnología                               que subyace al mismo, se trataría de ser proporcionado al fin. Un cuadro de mando                             sencillo puede generarse con herramientas sencillas de generación de reportes                   integradas en la aplicación. Si quisiese usarse una herramienta de Business                     Intelligence, el sistema NO justificaría la compra de una. Debería hacerse uso de                         tecnologías ya existentes en el Ministerio y que la aplicación sea fuente de datos de                             las mismas. Estas tecnologías requieren de un cierto estudio para hablar de ellas con                           propiedad.    

39 

 

Anexos Anexo I - Proceso de categorización de los sistemas El proceso de categorización de los sistemas que se describe a continuación es el propuesto

en el ANEXO I del Esquema Nacional de Seguridad.

1. Fundamentos para la determinación de la categoría de un sistema.

La determinación de la categoría de un sistema se basa 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 la capacidad organizativa para:

a) Alcanzar sus objetivos.

b) Proteger los activos a su cargo.

c) Cumplir sus obligaciones diarias de servicio.

d) Respetar la legalidad vigente.

e) Respetar los derechos de las personas.

La determinación de la categoría de un sistema se realizará de acuerdo con lo establecido en

el presente real decreto, y será de aplicación a todos los sistemas empleados para la

prestación de los servicios de la Administración electrónica y soporte del procedimiento

administrativo general.

2. Dimensiones de la seguridad.

A fin de poder determinar el impacto que tendría sobre la organización un incidente que

afectara a la seguridad de la información o de los sistemas, y de poder establecer la

categoría del sistema, se tendrán en cuenta las siguientes dimensiones de la seguridad, que

serán identificadas por sus correspondientes iniciales en mayúsculas:

a) Disponibilidad [D].

b) Autenticidad [A].

c) Integridad [I].

d) Confidencialidad [C].

e) Trazabilidad [T].

3. Determinación del nivel requerido en una dimensión de seguridad.

40 

Una información o un servicio pueden verse afectados en una o más de sus dimensiones de

seguridad. Cada dimensión de seguridad afectada se adscribirá a uno de los siguientes

niveles:

BAJO, MEDIO o ALTO. Si una dimensión de seguridad no se ve afectada, no se adscribirá a

ningún nivel.

a) Nivel BAJO. Se utilizará cuando las consecuencias de un incidente de seguridad que

afecte a alguna de las dimensiones de seguridad supongan un perjuicio limitado

sobre las funciones de la organización, sobre sus activos o sobre los individuos

afectados.

Se entenderá por perjuicio limitado:

1º La reducción de forma apreciable de la capacidad de la organización para

atender eficazmente con sus obligaciones corrientes, aunque estas sigan

desempeñándose.

2º El sufrimiento de un daño menor por los activos de la organización.

3º El incumplimiento formal de alguna ley o regulación, que tenga carácter de

subsanable.

4º Causar un perjuicio menor a algún individuo, que aún siendo molesto pueda

ser fácilmente reparable.

5º Otros de naturaleza análoga.

b) Nivel MEDIO. Se utilizará cuando las consecuencias de un incidente de seguridad que

afecte a alguna de las dimensiones de seguridad supongan un perjuicio grave sobre

las funciones de la organización, sobre sus activos o sobre los individuos afectados.

Se entenderá por perjuicio grave:

1º La reducción significativa la capacidad de la organización para atender

eficazmente a sus obligaciones fundamentales, aunque estas sigan

desempeñándose.

2º El sufrimiento de un daño significativo por los activos de la organización.

3º El incumplimiento material de alguna ley o regulación, o el incumplimiento

formal que no tenga carácter de subsanable.

4º Causar un perjuicio significativo a algún individuo, de difícil reparación.

5º Otros de naturaleza análoga.

c) Nivel ALTO. Se utilizará cuando las consecuencias de un incidente de seguridad que

afecte a alguna de las dimensiones de seguridad supongan un perjuicio muy grave

sobre las funciones de la organización, sobre sus activos o sobre los individuos

afectados.

Se entenderá por perjuicio muy grave:

41 

1º La anulación de la capacidad de la organización para atender a alguna de sus

obligaciones fundamentales y que éstas sigan desempeñándose.

2º El sufrimiento de un daño muy grave, e incluso irreparable, por los activos de

la organización.

3º El incumplimiento grave de alguna ley o regulación.

4º Causar un perjuicio grave a algún individuo, de difícil o imposible reparación.

5º Otros de naturaleza análoga.

Cuando un sistema maneje diferentes informaciones y preste diferentes servicios, el nivel del

sistema en cada dimensión será el mayor de los establecidos para cada información y cada

servicio.

4. Determinación de la categoría de un sistema de información.

1. Se definen tres categorías: BÁSICA, MEDIA y ALTA.

a) Un sistema de información será de categoría ALTA si alguna de sus dimensiones

de seguridad alcanza el nivel ALTO.

b) Un sistema de información será de categoría MEDIA si alguna de sus dimensiones

de seguridad alcanza el nivel MEDIO, y ninguna alcanza un nivel superior.

c) Un sistema de información será de categoría BÁSICA si alguna de sus dimensiones

de seguridad alcanza el nivel BAJO, y ninguna alcanza un nivel superior.

2. La determinación de la categoría de un sistema sobre la base de lo indicado en el

apartado anterior no implicará que se altere, por este hecho, el nivel de las

dimensiones de seguridad que no han influido en la determinación de la categoría del

mismo.

42 

Anexo II - Información del enunciado

Gráfico 1

 

Extracto de carta al subdirector  

 

43 

Capturas de pantallas de archivos en CD’s de expedientes de ICTs previos a la implementación de la aplicación

 

44 

   

45