SECRETARIA NACIONAL DE PLANIFICACION Y...

SECRETARIA NACIONAL DE PLANIFICACION Y DESARROLLO SUBSECRETARIA DEINFORMACION

Producto 2: Normas para el levantamientode requerimientos para sistemas deinformaciónE – Open Solutions Cía. Ltda.

16/07/2013

El presente documento contiene los aspectos de índole normativo que deberán serconsiderados en la construcción de sistemas de información en lo referente al levantamientode requerimientos.

Normas para Mejorar laImplementación deSistemas Integrales deInformaciónPROPUESTA

Normas para el levantamiento de requerimientos para sistemas de información

EOpenSolutions Página 1 de 19

Contenido

1. Antecedentes .............................................................................................. 22. Alcance ....................................................................................................... 43. Referencias Normativas .............................................................................. 54. Marco de Referencia ..................................................................................... 65. Normas para el Levantamiento de Requerimientos .................................... 8

5.1. Identificación de las partes interesadas. ............................................... 85.2. Levantamiento de los requerimientos.................................................... 85.3. Evaluación de los requerimientos levantados. .................................... 115.4. Apoyo al levantamiento de los requerimientos. ................................... 11

6. Referencias ............................................................................................... 127. Anexos ...................................................................................................... 13

PROPUESTA



1. Antecedentes

Según los pliegos de Contratación de la presente consultoría, el EstatutoOrgánico por Procesos de la SENPLADES describe, entre lasresponsabilidades de la Subsecretaría de Información, coordinar con lasentidades del Gobierno Central generadoras de información estadística ygeográfica, los procesos de generación, validación, estandarización y difusiónde los indicadores integrados al Sistema Nacional de Información; y, ademáscoordinar e impulsar el mejoramiento de los procesos de producción y el uso dela información que permitan cumplir con el planteamiento de los lineamientosmetodológicos para la construcción del Plan Nacional de Desarrollo.

El Código Orgánico de Planificación y Finanzas Públicas, establece que el PlanNacional de Desarrollo es la máxima directriz política y administrativa para eldiseño y aplicación de la política pública y todos los instrumentos deplanificación, así como señala que la Secretaría Nacional de Planificación yDesarrollo establecerá los mecanismos, metodologías y procedimientosaplicables a la generación y administración de la información para laplanificación, así como sus estándares de calidad y pertinencia.

El mismo Código señala que el Sistema Nacional de Información constituye elconjunto organizado de elementos que permiten la interacción de actores conel objeto de acceder, recoger, almacenar y transformar datos en informaciónrelevante para la planificación del desarrollo y las finanzas públicas.

La Subsecretaría de Información, perteneciente a la SENPLADES en suresponsabilidad de proveer datos e información relevantes en los procesos deplanificación de los distintos niveles de gobierno, ha coordinado la generación ydefinición de lineamientos metodológicos para la definición de metas del PlanNacional de Desarrollo, que permitirá la interacción de diferentes actores einstituciones para organizar y coordinar la planificación del desarrollo delEstado.

Bajo este preámbulo el proyecto emblemático Sistema Nacional de Informaciónel cual se encuentra dentro de la Subsecretaría de Información - SENPLADES,comprende entre sus objetivos elaborar normas, políticas y estándares, queayuden al mejoramiento y tratamiento de los sistemas de informaciónestadística y geográfica de las instituciones del Gobierno Central que debeninteractuar con el Sistema Nacional de Información.

Además, el proyecto emblemático Sistema Nacional de Información estáempeñado en establecer y difundir estándares y metodologías para lageneración, validación y publicación de información geográfica y estadística enlas instituciones del sector público.

PROPUESTA



Por lo mencionado, resulta indispensable contar con las normativas técnicasque ayuden a generar información estandarizada para la planificación,necesaria para el seguimiento y evaluación al Plan Nacional de Desarrollopropuesto por la SENPLADES

En cuanto a los antecedentes del presente producto, cuando arranca unproyecto, su administrador debe contactar a todas las partes interesadas paradeterminar sus intereses y así captar de la mejor manera los requerimientosque se necesitan para cumplir las metas del proyecto. Pero frecuentemente nohay una definición clara de los requerimientos debido a falta de entendimiento odetalles en la comunicación entre el cliente, los grupos de interés y eladministrador del proyecto. Inclusive según estadísticas, un levantamiento derequerimientos incompleto o alejado de la realidad, disminuye dramáticamentelas probabilidades de éxito del proyecto.

De allí la importancia de poner en práctica un perfecto levantamiento derequerimientos, asegurando así el cumplimiento de los objetivos trazados en elproyecto, así como la satisfacción total del cliente, la cual no es más que lapercepción de sentir que las necesidades o expectativas que se tenían haciaalgo fueron cubiertas.

Hay que reconocer que no siempre es fácil la comunicación entre eladministrador del proyecto y las partes interesadas, debido a que suelen hablarlenguajes distintos, pues uno está enfocado hacia lo técnico y el otro hacia losservicios. Por lo que es necesario que el administrador del proyecto halle esazona o punto de encuentro en donde la comunicación es efectiva a través deun verdadero proceso de retroalimentación que refleje entendimiento.

Vale resaltar que los instrumentos de recolección de requerimientos nogarantizan por sí solos una recopilación de necesidades claras y coherentes,pues en todo momento el administrador del proyecto debe estar al pendienterespecto a qué realmente es lo que necesita el cliente.

Esto lo conseguirá entendiendo el “para qué” de un requerimiento, es decir,debe comprender el beneficio que se generará con el producto del proyecto,gracias a que esto determinará el valor agregado que pudiera imprimirle siconociera con exactitud “para qué” se empleará lo que resulte del proyecto.PROPUESTA



2. Alcance

De las tres fuentes clásicas de datos estadísticos, las encuestas, los censos, ylos registros administrativos, son éstos últimos los de mayor repunte en laépoca actual debido a que poseen propiedades que les permiten convertirse endatos estadísticos de muy buena calidad y a un costo más bajo que lasencuestas y los censos.

Sin embargo de lo citado en el párrafo anterior, la generación de datosestadísticos a partir de registros administrativos depende de una serie defactores, algunos de los cuales están fuera del control de las áreas estadísticasde las organizaciones ya que son aspectos inherentes a los sistemas deinformación que son usados como herramientas tecnológicas para la creacióny/o captura de los registros administrativos como tal.

Los aspectos de los sistemas de información que se deben considerar en lageneración de registros administrativos son los siguientes:

El Levantamiento de los requerimientos de los sistemas de información. La captura de los datos en los sistemas de información. La calidad de los datos procesados y obtenidos a partir de los sistemas

de información La seguridad de los datos en los sistemas de información, la cual tiene

que ver a su vez con:o Verificación de la identidado Control de Accesoo Confidencialidado Integridado Trazabilidad (auditoría)

La disponibilidad de los sistemas de información como fuente de losdatos requeridos

En función de lo expuesto, y en relación al alcance del presente documento, elmismo tiene la finalidad de dejar constancia escrita de las normas para ellevantamiento de requerimientos que un sistema de información deberíacumplir con miras a soportar la obtención posterior de registros administrativos.

En lo referente al levantamiento de requerimientos, las normas propuestasaportarán para que los reportes que se puedan generar en base a los registrosadministrativos, faciliten la toma de decisiones encaminadas al cumplimiento delas metas del Plan Nacional para el Buen Vivir.

En este producto se analizará normativa referente a la gestión de proyectos, deriesgos, de control de cambios, de costos, de partes interesadas y dedocumentación.

PROPUESTA



3. Referencias Normativas

Las referencias a partir de las cuales se desprenden las normas incluidas en elpresente documento, son las siguientes:

PMI – PmBok 4ta edición, 2008 ISO/IEEE 1220, 2005, Ingeniería de Sistemas – Parte 6: Ciclo de Vida

del Sistema. ISACA/ITGI – COBIT 5, 2012

El PmBok (Project Management Body of Knowledge) desarrollado por el PMI(Project Management Institute) es el mayor referente a nivel mundial en cuantoa dirección de proyectos. Más que una metodología, la enseñanza de lasbuenas prácticas propuestas por este Instituto garantizan actualidad, así comoel aporte de centenas de profesionales en Administración de Proyectos, quecon su experiencia han propuesto herramientas y metodologías aptas paraenfrentar el entorno cambiante de los proyectos y sus requerimientosparticulares, sean del campo que sean.

La Organización Internacional para la Estandarización con sede en Ginebra,Suiza y sus normativas ISO son el mayor referente a nivel mundial en cuanto acalidad en procesos de producción y control tanto de bienes como de servicios,dentro de las que se incluyen el ciclo de vida del software y sistemas de gestiónde seguridad de la información .

COBIT (Control Objectives for Information and related Technology) (Objetivosde Control para Información y Tecnologías Relacionadas) es una guía demejores prácticas dirigida a la gestión de tecnología de la información (TI)mantenida por ISACA (Information Systems Audit and Control Association) y elITGI (IT Governance Institute).

Es importante mencionar que para las referencias con fecha sólo se aplica a laedición citada, mientras que para las referencias sin fecha se aplica a la últimaedición o versión del documento referenciado.PROPUESTA



4. Marco de Referencia

Los registros administrativos se pueden definir como la información que unaorganización recolecta y mantiene sobre una entidad individual, y que ha sidodiseñada con el fin de controlar o tomar decisiones sobre tal entidad.

Actualmente las tecnologías de información o TI, y específicamente lossistemas de información son medios o herramientas para la recolección ymantenimiento de registros administrativos, a partir de la información que seprocesa y/o se obtiene en dichos sistemas de información.

Si consideramos el hecho de que los sistemas de información existen como unmedio para cubrir los objetivos de negocio, y que la información procesada yobtenida por los sistemas de información puede dar origen a registrosadministrativos, se puede concluir que los registros administrativos a la largaestán orientados a satisfacer los objetivos de negocio, por lo cual deben estaren conformidad con ciertos criterios de control.

Según el marco de COBIT, los criterios de control que la información (registroadministrativo) debería acatar se expresan a través del cumplimiento de lossiguientes requerimientos:

Efectividad, que quiere decir que la información (registro administrativo)debe ser relevante y pertinente al negocio y que debe ser entregada deforma oportuna, correcta y consistente.

Eficiencia, que quiere decir que la información (registro administrativo)debe ser obtenida de una forma económica y productiva con un usoóptimo de recursos.

Fiabilidad, que quiere decir que la información (registro administrativo)sea apropiada y conforme a la necesidad del usuario.

Cumplimiento, que quiere decir que la información (registroadministrativo) debe estar acorde con las leyes, regulaciones uobligaciones.

Integridad, que quiere decir que la información (registro administrativo)sea válida, exacta y completa (completitud).

Disponibilidad, que quiere decir que la información (registroadministrativo) sea accesible cuando el proceso o el usuario losrequieran.

Confidencialidad, que quiere decir que la información (registroadministrativo) es asegurada para que sea utilizada por quien debautilizarla.

Para satisfacer cada uno de los requerimientos anteriormente detallados, esnecesario establecer un sistema de control, con actividades que permitenimplementar dos tipos de controles:

PROPUESTA



Controles de Aplicación, empleados al interior de los procesos deservicio y los sistemas de información.

Controles Generales de TI, empleados al interior de los procesos yservicios de TI que gestionan el ambiente dentro del cual operan lossistemas de información.

En lo referente al levantamiento de requerimientos para sistemas deinformación los aspectos que serán motivo de las normas se pueden agruparen los siguientes puntos:

Identificación de las partes interesadas. Levantamiento de los requerimientos. Evaluación de los requerimientos levantados. Gestión de los requerimientos.

Las partes interesadas o stakeholders son las personas y organizaciones queestán activamente involucrados en el proyecto o cuyos intereses pueden verseafectados de manera positiva o negativa por la ejecución o terminación delproyecto.

Cuando se habla de proyecto se establece que se puede desagregar el sistemade información en sistemas en general, subsistemas, productos ocomponentes.

La normativa se puede aplicar iterativamente tanto para los sistemas deinformación enfocados en registros administrativos, como para sussubsistemas, componentes, productos y demás desagregados.

PROPUESTA



5. Normas para el Levantamiento de Requerimientos

El levantamiento de requerimientos debe llegar a determinar todo (yúnicamente todo) el trabajo requerido para completar el sistema con éxito. Elobjetivo principal es definir qué se incluye y qué no se incluye en el sistema.

5.1. Identificación de las partes interesadas.

1. Para identificar las partes interesadas, se debe:

a. Definir los interesados dentro y fuera de la institución.

b. Definir los roles, niveles de conocimiento, responsabilidades, nivelesde participación, autoridad, influencia, intereses y expectativas decada interesado.

c. Clasificar a los interesados.

5.2. Levantamiento de los requerimientos.

1. Definir las expectativas de las partes interesadas (Stakeholders) con elfin de establecer lo que el proyecto debe ser capaz de realizar en funciónde términos cuantitativos y medibles, considerando:

a. Definir las expectativas funcionales de las partes interesadas enrelación al sistema, ciclo de vida del proyecto y factores de calidad.

b. Definir expectativas de desempeño (performance) y la medida enque se cumplimentará cada función del sistema.

c. Definir el entorno en el cual el sistema de información operará o seráimplementado.

d. Identificar restricciones no funcionales entre las que se debe incluir:económicas, de costos, de temporalidad, tecnológicas, norelacionadas con el desarrollo, características del diseño, horarios deoperación, secuencias, interfaces externas, equipamiento, procesosy locaciones, requeridas durante el ciclo de vida del sistema.

2. Identificar las restricciones organizacionales y del proyecto con el fin deconocer las restricciones que generan un impacto en el diseño desistemas de información considerando:

a. Definir las restricciones del proyecto incluyendo:

i. Especificaciones y líneas de base desarrolladas en proyectosanteriores de sistemas de información.

ii. Planes de ingeniería y tecnológicos.iii. Estructura organizacional y asignación de personal.iv. Herramientas CASE (Computer Aided Software Engineering,

Ingeniería de Software Asistida por Computadora) y de

PROPUESTA



automatización, aprobación de su uso.v. Mecanismos de Control.vi. Métricas para medir el proceso técnico de desarrollo.vii. Reutilización y software existente en el mercado.

b. Definir las restricciones organizacionales incluyendo:

i. Decisiones administrativas de revisiones técnicas previas.ii. Estándares, guías y especificaciones generales

organizacionales.iii. Políticas y Procedimientos.iv. Tecnologías existentes.v. Capacidades establecidas para el ciclo de vida de proyectos.vi. Asignaciones al esfuerzo técnico tanto de personal, financieras

y de recursos humanos.

3. Identificar y definir las restricciones externas que generan un impacto enel diseño de sistemas de información considerando:

a. Leyes y regulaciones.b. Base tecnológica.c. Estándares internacionales relacionados a la organización,

especificaciones generales.d. Especificaciones y estándares relacionados al recurso humano.e. Disponibilidad, contratación y selección de recursos humanos.f. Capacidades de productos similares.

4. Definir escenarios operativos que identifiquen usos anticipados deproductos del sistema, para cada escenario, se debe identificar lasinteracciones con el entorno y otros sistemas, tareas humanas ysecuencias de tareas; conexiones con interfaces, plataformas yproductos.

5. Identificar los límites del proyecto considerando:

a. Definir qué elementos están bajo control del proyecto y cuales estánfuera del control del proyecto.

b. Definir las interacciones entre elementos bajo control del proyecto ysistemas externos de alto nivel y otros sistemas fuera de los límitesdel sistema de información.

6. Identificar interfaces funcionales y de diseño a otros sistemas,plataformas, usuarios, y/o productos en términos cuantitativos.

7. Se debe definir el entorno de uso para cada escenario operativo, todoslos factores del entorno que pueden afectar el desempeño del sistemadeben estar identificados y definidos, principalmente factores quepongan en riesgo la operatividad del sistema definidos por locación y

PROPUESTA



condiciones en las que el sistema será operado.

8. Al definir los requerimientos del ciclo de vida del sistema , se debeanalizar las expectativas de las partes interesadas, organizacionales,externas, operativas, limitaciones, interfaces, con el fin de definirrequerimientos al ciclo de vida del proceso, necesarios para desarrollar,producir, probar, operar , mantener, entrenar y desechar los productosdel sistema en desarrollo, se debe:

a. Identificar y definir las tareas y carga de trabajo asociados paradeterminar el número y cantidad de personas que darán soporte alciclo de vida del sistema.

b. Identificar y definir la experiencia, aptitudes, conocimientos,habilidades requeridas para desarrollar las tareas asociadas alpersonal que soportará el ciclo de vida del sistema.

c. Identificar y definir las tareas necesarias para socializar, educar,entrenar al personal necesario identificado para soportar el ciclo devida del sistema.

d. Identificar y definir características cognitivas, físicas y sensoriales delos seres humanos que soportarán el ciclo de vida del sistema, quedirectamente contribuyen o restringen el desempeño del sistema.

e. Identificar y definir características de seguridad que puedan causarriesgos a la salud, enfermedades crónicas, discapacidades, reducir eldesempeño del personal que operará, mantendrá y soportará elsistema de información.

9. Identificar y definir restricciones en base a características de diseño paraproductos del sistema.

10. Identificar y definir restricciones en base a ingeniería de factoreshumanos (límites de espacio de diseño, limites climáticos, movimientode visión, alcance, ergonomía, limites cognitivos, usabilidad) que puedenafectar la operación del sistema en la etapa de desarrollo.

11.La especificación de los requerimientos del sistema deberá describirfunciones y capacidades del sistema; requerimientos de las partesinteresadas, requerimientos de negocio, organizativas y de usuario;requerimientos externos; requerimientos de seguridad física y de acceso;escenarios operativos; limitaciones; requerimientos de ingeniería defactores humanos, interfaces y requerimientos del ciclo de vida delsistema; limitaciones de diseño. Se deberá documentar la especificaciónde los requerimientos del sistema en base al plan de documentación.

PROPUESTA



5.3. Evaluación de los requerimientos levantados.

1. Con la finalidad de cumplir con los objetivos de efectividad y eficiencia,los requerimientos levantados deberán ser evaluados, tomando encuenta que deben ser claros (medibles y comprobables), rastreables,completos, coherentes y aceptables. Complementariamente, se deberádocumentar los resultados de las evaluaciones en base al plan dedocumentación.

5.4. Apoyo al levantamiento de los requerimientos.

1. Elaborar un plan de gestión de requerimientos, en el cual se analizarán,priorizarán, documentarán, planificarán y gestionarán los requisitos a lolargo del proyecto.

2. Vincular los requerimientos con su origen y monitorearlos a lo largo delciclo de vida del proyecto. Se debe rastrear los requisitos:

a. Con respecto a las necesidades, oportunidades, metas y objetivos dela institución.

b. Con respecto a los objetivos del proyecto.

c. Con respecto al alcance del proyecto/a los entregables

d. Con respecto al diseño del producto.

e. Con respecto al desarrollo del producto.

f. Con respecto a la estrategia y los escenarios de prueba

g. De alto nivel con respecto a los requisitos más detallados.

3. Definir el alcance del proyecto, describiendo el alcance, requerimientos ylos criterios de aceptación del sistema, los entregables, las exclusiones,las restricciones y los supuestos del proyecto.

4. Identificar los riesgos, analizarlos cualitativa y cuantitativamente yplanificar respuestas.

5. Elaborar un plan de control de cambios, desarrollando procedimientosque indiquen formatos, vías y destinatarios, definir los niveles deautoridad necesarios y gestionar los cambios aprobados con todas lasáreas involucradas.

PROPUESTA



6. Elaborar un presupuesto, para lo cual se debe:

a. Estimar los costos tomando en cuenta que la estimación no puedeser exacta, generalmente tendrá un rango de variación de +/- 30% enla fase inicial e irá disminuyendo hasta llegar a un +/- 10%.

b. Presentar no menos de tres escenarios: optimista, intermedio ypesimista.

c. Incluir todos los recursos que se asignarán al proyecto, incluyendoequipos, licencias, recurso humano, riesgos.

7. Elaborar un plan de documentación, para lo cual se debe:

a. Establecer un repositorio de información y los responsables de suactualización.

b. Identificar los documentos que se van a producir y considerar losiguiente para cada uno: título o nombre, propósito, audiencia a laque se dirige, versión, procedimientos, responsabilidades y plazos.

c. Diseñar los documentos de acuerdo con las normas dedocumentación aplicables para el formato, descripción del contenido,numeración de páginas, situación de las figuras y tablas, marcas depropiedad y seguridad, empaquetado y otros elementos depresentación.

d. Definir la producción, puesta a disposición y almacenamiento de losdocumentos en el repositorio de información considerando unaversión del documento.

e. Actualizar los cambios cuando estos se produzcan.

6. Referencias

PMI (2008) PMBOK (Project Manajement Body of Knowledge) 4ta edición,Pennsylvania, EEUU: PMI

ISO (2005) ISO/IEC 26702 IEEE STD 1220-2005 , Ginebra, Suiza: ISO.

ISACA/ITGI (2012) COBIT 5, Illinois, EEUU: ISACA

PROPUESTA



7. Anexos

En el siguiente anexo se indica un caso de ejemplo de documento delevantamiento de requerimientos. Se hace referencia a que el documentopuede o no contener elementos relacionados a la normativa, sin embargo es unbuen inicio para redactar requerimientos; cada organización podrá evaluarlo ,modificarlo y aplicarlo con el fin de cumplir con la norma propuesta.

REQUERIMIENTOS SOFTWARE[NOMBRE DEL PROYECTO]

PREFACIO

Este documento describe los requerimientos de software del[nombre del proyecto], cuyo objetivo principal es [describa elobjetivo principal del proyecto]

Alcance Este documento de requerimientos de software es la base deldesarrollo de software del proyecto. Describe los siguientestópicos: [especifique la lista de tópicos]. Este documento nodescribe [especifique lo que no se describe en estedocumento].

HISTORIA DEL DOCUMENTO

Fecha Versión Comentarios Autor30 Julio 2013 0.1 Versión inicial nn

27 Agosto2013 1.0 Revisada por el equipo nn

PROPUESTA



TABLA DE CONTENIDOS

5.1. Identificación de las partes interesadas. ............................................... 85.2. Levantamiento de los requerimientos.................................................... 85.3. Evaluación de los requerimientos levantados. .................................... 115.4. Apoyo al levantamiento de los requerimientos. ................................... 111.1. Entorno................................................................................................ 151.2. Estándares .......................................................................................... 151.3. Documentación ................................................................................... 152.1. Requerimientos Funcionales............................................................... 152.2. Requerimientos de Testing ................................................................. 152.3. Matriz Requerimientos Funcionales vs. Requerimientos de Testing ... 164.1. Requerimientos de Ambiente de Desarrollo........................................ 16

4.1.1. Hardware de Desarrollo ................................................................ 164.1.2. Desarrollo de Software ................................................................. 17

4.2. Requerimientos de Ambiente de Testing ............................................ 174.2.1. Hardware de Testing .................................................................... 174.2.2. Software de Testing...................................................................... 17

5.1. Restricciones Hardware ...................................................................... 175.2. Restricciones Software........................................................................ 175.3. Restricciones de Interfaz..................................................................... 176.1. Modelo Arquitectónico......................................................................... 176.2. Matriz Requerimientos Funcionales vs. Componentes de laArquitectura .................................................................................................. 187.1. Requerimientos Participación Cliente.................................................. 187.2. Requerimientos de Comunicación ...................................................... 187.3. Requerimientos de Infraestructura ...................................................... 188.1. Requerimientos de Entrenamiento ...................................................... 188.2. Requerimientos de Mantenimiento...................................................... 18

0

PROPUESTA



1. INTRODUCCION

1.1.Entorno[Esta sección debe contener cualquier información de entorno que el lectordeba conocer. Esto incluye típicamente existencia de productos similares,datos históricos de otros proyectos similares, etc.]

1.2.Estándares[En esta sección se especifican los estándares que serán utilizados durante eldesarrollo, por ejemplo estándares de codificación]

1.3.Documentación[Esta sección debe identificar los documentos relacionados con el proyecto queya existen, y aquellos que serán generados o modificados como parte deldesarrollo.]

2. Requerimientos Software

[Esta sección entrega un resumen de todos los requerimientos de alto nivel delsoftware del sistema. Los requerimientos de testing, de interfaz y otros sonigualmente definidos.]

2.1.Requerimientos FuncionalesEsta sección lista los requerimientos funcionales de alto nivel. Cadarequerimiento debe tener un identificador único, el que será parte de la matrizde trasabilidad y el que será utilizado como referencia. Los siguientes puntosdeben ser tomados en cuenta al definir los requerimientos.¿Está claramente definido el requerimiento? (si hay más de una interpretación,el requerimiento es ambiguo).¿Es testable el requerimiento? ¿Se puede demostrar con uno o varios casos deprueba que el requerimiento se cumple?]

FSR1 [Requerimiento funcional 1]



FSR4 [Requerimiento funcional 4

2.2.Requerimientos de Testing[Esta sección debe identificar los requerimientos de testing para cada uno delos requerimientos funcionales definidos en la sección anterior. Puede habermás de un test para validar un requerimiento funcional. Los requerimientos de

PROPUESTA



testing deben ser definidos a alto nivel pero deben validar claramente losrequerimientos del software. Al igual que los requerimientos funcionales, losrequerimientos de testing deben tener un identificador único.]

ST1 [Requerimiento de testing 1]




2.3.Matriz Requerimientos Funcionales vs. Requerimientos de Testing[En esta sección se debe especificar la matriz que mapea los requerimientosfuncionales con los requerimientos de testing.]

Requerimientos de test

Requerimientofuncional

ST1 ST2 ST3 ST4 ST5 ST6

FSR1 X X X

FSR2 X X

FSR3 X X X X

FSR4 X X X

FSR5 X X X

3. Requerimientos de Calidad

[Esta sección identifica todos los requerimientos de calidad que han sidoespecificados por el cliente. Para cada requerimiento de calidad se debeespecificar lo siguiente:

Escala dimensión de la mediciónPrueba como se realizará la mediciónPeor Caso El peor valor aceptable (bajo este valor se considera falla)Plan valor planificadoAutoridad quien valida el requerimiento]

4. Requerimientos de Ambiente

4.1.Requerimientos de Ambiente de Desarrollo4.1.1. Hardware de Desarrollo

PROPUESTA



[En esta sección se especifican los requerimientos de hardware de desarrollo.Por ejemplo, el proyecto se desarrollará en plataformas PC con 128 Mbyte deRAM]

4.1.2. Desarrollo de Software[Especifique los requerimientos de desarrollo de software, por ejemplo lenguajede programación]

4.2.Requerimientos de Ambiente de Testing

4.2.1. Hardware de Testing[Especifique aquí los equipos o elementos de hardware que se usarán paraprobar el software]

4.2.2. Software de Testing[Especifique aquí los software que se utilizarán para probar el software delsistema]

5. Restricciones

5.1.Restricciones Hardware[Esta sección debe identificar todas las restricciones hardware que puedantener un impacto en la funcionalidad, tamaño o rendimiento del software]

5.2.Restricciones Software[Esta sección debe identificar todas las restricciones software que puedan tenerun impacto en la funcionalidad, tamaño o rendimiento del software.]

5.3.Restricciones de Interfaz[Esta sección debe incluir todas las consideraciones de interfaz, tales comointerfaz con otros productos, interfaz usuario, etc.]

6. Arquitectura del Software

6.1.Modelo Arquitectónico[En esta sección se debe presentar la arquitectura del software en la forma deun diagrama de bloques. Se pueden hacer múltiples diagramas si es necesario.Si se considera que el producto será mejorado a futuro, las mejoras debenaparecer en la arquitectura desde el principio.]

C1 [Descripción del componente 1]



PROPUESTA



6.2.Matriz Requerimientos Funcionales vs. Componentes de laArquitectura

Componente de la arquitectura

Requerimientofuncional

C1 C2 C3 C4 C5 C6

SFR1 X

SFR2 X

SFR3 X X

SFR4 X

SFR5 X X

7. Requerimientos de Desarrollo

7.1.Requerimientos Participación Cliente[En esta sección se deben identificar todas las ocasiones en que el cliente seráparte del proceso de desarrollo. Esto incluye participación en test deaceptación, revisiones periódicas, etc.]

7.2.Requerimientos de Comunicación[En el caso de desarrollos conjuntos con el cliente y en otros casos, lascomunicaciones periódicas pueden ser esenciales para el éxito del desarrollo.Esta sección identifica los requerimientos de comunicación incluyendo lasconferencias telefónicas periódicas, bases de datos distribuidas, transferenciade documentos para revisión, tiempos de respuesta, etc.]

7.3.Requerimientos de Infraestructura[Esta sección identifica todos los requerimientos de infraestructura que seránnecesarios para el éxito del proyecto, como por ejemplo conexión satelital oconexión de alta velocidad]

8. Requerimientos Post Desarrollo

8.1.Requerimientos de Entrenamiento[Esta sección describe los requerimientos de entrenamiento del clienteincluyendo detalles como audiencia requerida, lugar del entrenamiento,material, etc.]

8.2.Requerimientos de Mantenimiento[Esta sección describe los requerimientos de mantenimiento del software talescomo el modo de reportar los problemas, persona de contacto, etc.]

PROPUESTA

SECRETARIA NACIONAL DE PLANIFICACION Y DESARROLLOSUBSECRETARIA DE INFORMACION

Normas para Mejorar laImplementación deSistemas Integrales deInformaciónProducto 3: Normas para la validación de lainformaciónE – Open Solutions Cía. Ltda.

12/08/2013

El presente documento contiene los aspectos de índole normativos que deberán serconsiderados en la construcción de sistemas de información en lo referente a la captura y a lacalidad de la información.

PROPUESTA

Normas para la validación en la captura y la calidad de los datos para sistemas de información


Contenido

1. Antecedentes .............................................................................................. 22. Alcance ....................................................................................................... 43. Referencias Normativas .............................................................................. 64. Términos y Definiciones .............................................................................. 75. Marco de Referencia ................................................................................... 96. Normas para la Captura de Información ................................................... 11

6.1. Preparación de datos fuente ............................................................... 116.2. Recolección e ingreso de datos .......................................................... 126.3. Actualización de datos ........................................................................ 14

7. Normas para la Calidad de la Información ................................................ 157.1. Procesamiento de datos...................................................................... 157.2. Manejo de errores ............................................................................... 167.3. Evaluación de resultados .................................................................... 17


9.1. Ejemplo de Aplicación de las Normas para la Captura de Datos ........ 20

PROPUESTA



1. Antecedentes






Además, el proyecto emblemático Sistema Nacional de Información estáempeñado en establecer y difundir estándares y metodologías para lageneración, validación y publicación de información geográfica y estadística enlas instituciones del sector público en coordinación con las mismas.

PROPUESTA



Por lo mencionado, resulta indispensable contar con las normativas técnicasque ayuden a generar información estandarizada para la planificación,necesaria para el seguimiento y evaluación al Plan Nacional de Desarrollopropuesto por la SENPLADES.

PROPUESTA



2. Alcance

De las tres fuentes clásicas de datos estadísticos, las encuestas, los censos, ylos registros administrativos, son éstos últimos los de mayor despunte en laépoca actual debido a que poseen propiedades que les permiten convertirse endatos estadísticos de muy buena calidad y a un costo más bajo que lasencuestas y los censos.


Los aspectos de los sistemas de información que se deben considerar son lossiguientes:





En función de lo expuesto, y en relación al alcance del presente documento, elmismo tiene la finalidad de dejar constancia escrita de las normas de capturade datos y de calidad de datos que un sistema de información debería cumplircon miras a soportar la posterior obtención de registros administrativos.

En lo referente a la captura de los datos, las normas propuestas aportarán a laintegridad (completitud) y fiabilidad de los registros administrativos que sepudieran obtener posteriormente.

En lo referente a la calidad de los datos, las normas propuestas aportarán parala fiabilidad de los registros administrativos que se pudieran obtenerposteriormente.

Finalmente es importante recalcar que al normar la entrada de datos (captura)en un sistema de información, así como la calidad de dichos datos en cuanto asu procesamiento y a los resultados obtenidos, se está generando el sustento

PROPUESTA



necesario sobre el cual la institución podrá implementar mecanismos deseguimiento o trazabilidad de los datos proporcionados por un sistema deinformación, hacia uno o varios procesos de la organización.

PROPUESTA




El marco de referencia a partir del cual se desprenden las normas incluidas enel presente documento, ha sido desarrollado en función del contenido de lossiguientes estándares y normas:

ISO/TS 8000-1:2011, Calidad de Datos – Parte 1: Generalidades

Este estándar contiene los principios y las buenas prácticas de calidadde datos, siendo por lo tanto una importante referencia a considerar enla construcción de sistemas de información.

COBIT 4.1:2009, Marco de Gobernabilidad

Este marco de gobierno establece procesos y controles para minimizarel riesgo y maximizar los beneficios de la aplicación de la tecnología enuna organización. En relación a la captura y calidad de los datos, estemarco establece una serie de controles de aplicación que deben serconsiderados en la construcción de sistemas de información.

Es importante mencionar que para criterio del autor, las referencias normativasaquí citadas son las más apropiadas para la generación de normas para lacaptura y calidad de datos en sistemas de información.

Finalmente es necesario indicar que las versiones de las referenciasnormativas aquí citadas, son las vigentes en relación a la generación denormas para la captura y calidad de datos en sistemas de información, almomento de la entrega del presente documento.

PROPUESTA



4. Términos y Definiciones

Para el propósito de este documento, son aplicables los siguientes términos ydefiniciones:

ArquitecturaOrientada a Servicios

Modelo arquitectónico para ampliar la eficiencia, la agilidady la productividad de una organización a través del uso deservicios de negocio que implementan la lógica de lasolución.

COBIT Marco de gobernabilidad que establece procesos ycontroles para minimizar el riesgo y maximizar losbeneficios de la aplicación de la tecnología en unaorganización.

Desacoplamiento Separación de los módulos de un sistema de informaciónde tal forma de minimizar la dependencia entre ellos. Eldesacoplamiento es la base de la integración de sistemasde información bajo una arquitectura orientada a servicios.

Estructura deAplicación

Estructura de datos creada con fines exclusivos deprogramación, la cual es utilizada al interior de un sistemade información. Su significado tiene mayor sentido para losdesarrolladores o programadores.

Gobernabilidad Liderazgo, estructura organizacional, y procesos queapalancan y maximizan la estrategia y los objetivos de unaorganización.

Log o Bitácora Registro de eventos que se capturan y almacenan duranteun rango de tiempo determinado, con un fin en particular.

Norma Documento de ámbito púbico cuyo contenido está fundadosobre los resultados conjugados de la ciencia, tecnología yexperiencia, y cuya observancia no es obligatoria.

Objeto de Negocio Estructura de datos que representa una entidad utilizada oreferenciada en los procesos de una organización. Susignificado tiene mayor sentido para los usuarios denegocio.

Reglamento Documento de carácter obligatorio que contienedisposiciones legislativas, reglamentarias oadministrativas.

RequerimientoFuncional

Funcionalidad que debe ser cubierta por un sistema deinformación, por ejemplo: cálculos, detalles técnicos,manipulación de datos y otras funcionalidades específicas.

Requerimiento NoFuncional

Es un atributo de calidad que establece un criterio parajuzgar la operación de un sistema de información, porejemplo: rendimiento, disponibilidad, seguridad y

PROPUESTA



accesibilidad.

Trazabilidad Conjunto de procedimientos que permiten conocer elhistórico, la ubicación y la trayectoria de un elemento a lolargo de una serie de fases y procesos.

URL Secuencia de caracteres, de acuerdo a un modelo yformato estándar, que se usa para nombrar recursos enInternet con fines de localización o identificación.

Usuario de Negocio Persona que pertenece a una organización y hace uso deun sistema de información para cumplir con sus funciones.

PROPUESTA






Si consideramos el hecho de que los sistemas de información existen como unmedio para cubrir los objetivos de la organización, y que la informaciónprocesada y obtenida por los sistemas de información pueden dar origen aregistros administrativos, se puede concluir que los registros administrativos ala larga están orientados a satisfacer los objetivos de la organización, por locual deben estar en conformidad con ciertos criterios de control.

Según el marco de COBIT, los criterios de control que la información deberíaacatar se expresan a través del cumplimiento de los siguientes requerimientos:








PROPUESTA




Controles de Aplicación, empleados al interior de los procesos de laorganización y los sistemas de información.


En relación con el alcance de la presente consultoría, las normas que seproponen tienen que ver con sistemas de información y por ende con controlesde aplicación.

En lo referente a la captura de los datos en los sistemas de información losaspectos que serán motivo de las presentes normas se pueden agrupar en lossiguientes objetivos:

Preparación de datos fuente Recolección e ingreso de datos Actualización de datos

Por otro lado, en lo referente a la calidad de los datos en los sistemas deinformación los aspectos que serán motivo de las presentes normas se puedenagrupar en los siguientes objetivos:

Procesamiento de datos Manejo de errores Evaluación de resultados

Con esto se pretende que los registros administrativos que se puedan obtenerde los sistemas de información cumplan con el requerimiento de efectividad enrelación a su entrega oportuna, correcta y consistente.PROPUESTA



6. Normas para la Captura de Información

6.1. Preparación de datos fuente

1. Si los datos que van a ser ingresados a un sistema de información se losrecopila previamente a su registro mediante formularios pre-impresos.Dichos formularios deben:

a. Incluir encabezados, títulos, notas e instrucciones estándar.

b. Poseer una estructura legible y fácil de uso.

c. Agrupar campos similares para facilitar la captura de los datos.

d. Tener una codificación pre-determinada para aquellos camposque ofrecen varias alternativas de llenado.

e. Poseer, cuando apliquen, valores por defecto para acelerar larecopilación de la información.

f. Contener números de referencia o correlación para facilitar larevisión y la trazabilidad.

g. Usar preferiblemente casilleros para facilitar la prevención deerrores de tamaño de campo en el registro en el sistema deinformación.

h. Incluir un área apropiada y estandarizada para registrarautorizaciones.

2. Se debe, definir, implementar y monitorear, el procedimiento de gestiónpara:

a. La captura de información mediante formularios pre-impresos.

b. El registro de la información recopilada en los sistemas deinformación.

c. El archivo o destrucción de los formularios pre-impresos.

3. Si los datos que van a ser cargados a un sistema de información se losobtiene a partir de una integración con otro sistema de información(interoperabilidad), se debe:

a. Definir los formatos de intercambio de información comorepresentaciones de objetos de negocio en lugar de estructurasde aplicaciones.

PROPUESTA



b. Estandarizar los formatos para el intercambio de información conel fin de minimizar el número de transformaciones a ser creadas ymantenidas.

c. Evitar realizar integraciones punto a punto, ya que esto es unapráctica que atenta contra el mantenimiento y la gestión de lasintegraciones.

d. Preferir la integración mediante una arquitectura orientada aservicios.

e. Definir los requerimientos funcionales y no-funcionales de laintegración.

f. Evitar realizar modificaciones intrusivas y extensivas en lossistemas de información a integrar.

g. Asegurar que la integración no tenga dependencias directas conlos sistemas de información a integrar. Aplicar el concepto dedesacoplamiento.

h. Asegurar que la integración será flexible y de fácil mantenimiento.

i. Generar la documentación necesaria sobre la integración parafacilitar su uso y su mantenimiento.

6.2. Recolección e ingreso de datos

1. Si los datos que van a ser ingresados a un sistema de información se losobtiene por la interacción directa del usuario con el sistema deinformación. El formulario digital utilizado para el efecto debe garantizarla calidad de la recolección y del ingreso de datos. El mencionadoformulario deberá:

a. Tener posicionados las etiquetas y los campos de una manera talque sea propensa a reducir el tiempo de recolección de los datos.

b. Indicar claramente la obligatoriedad u opcionalidad de loscampos.

c. Tener campos con una longitud adecuada en relación a sucontenido.

d. Agrupar adecuadamente los campos que se relacionen entre sí.

e. Proveer, en función de la importancia, la representación visualadecuada para las acciones que un usuario pueda realizar.

PROPUESTA



f. Contener la cantidad estrictamente necesaria de elementosvisuales de ayuda y consejos (tips), de tal forma de no abrumar alusuario.

g. Resaltar visualmente un camino claro para la recolección de losdatos.

h. Considerar el uso de tabs cuando sea apropiado, sin caer en eluso excesivo y abrumador de los mismos.

i. Revelar progresiva y adecuadamente las opciones a las quepueda tener acceso el usuario en función de los datos que éstevaya registrando.

j. Mantener una clara y lógica relación con las opcionesseleccionadas previamente por el usuario, evitando los saltosdisociativos.

k. Proveer una retroalimentación al usuario, conforme éste avanzaen el ingreso de los datos.

i. Mostrando entradas sugeridas para eliminarambigüedades.

ii. Indicando las restricciones o los límites de los campos.

l. Comunicar los errores que se presenten mediante un contrastevisual adecuado.

i. Proveyendo, de ser factible, las instrucciones y opcionespara ejecutar las acciones correctivas.

ii. Indicando el o los campos relacionados con el error.

m. Indicar claramente el progreso de las tareas en curso

n. Indicar claramente la ejecución exitosa de una acción, y si aplica,la correspondiente retroalimentación para el usuario.

2. La correcta utilización por parte de los usuarios, de los formulariosdigitales para la recolección e ingreso de datos, deberá ser formalmentereglamentada a fin de asegurar que los esfuerzos dedicados a su diseñoy construcción sean aprovechados de manera efectiva por parte de losusuarios.

PROPUESTA



6.3. Actualización de datos

1. La actualización de datos a través de los sistemas de informacióndeberá implementarse sin que se atente o transgreda las normasaplicadas para la captura e ingreso de datos. Es decir se debe evitar quelos datos que fueron debidamente validados en su captura e ingreso,pierdan su validez y calidad tras su actualización.

PROPUESTA



7. Normas para la Calidad de la Información

7.1. Procesamiento de datos

1. Para garantizar la confiabilidad del procesamiento de datos a través desistemas de información, se deberá:

a. Validar los datos que se suministran para el procesamiento, tancerca de su punto de captura o ingreso como sea posible, de estamanera se asegurará la integridad, la exactitud y la validez de losinsumos para el procesamiento de datos.

b. Asegurar que todos los datos recibidos como insumos seránaprovechados y procesados.

c. Implementar como parte de los sistemas de información, lospatrones y las buenas prácticas que son recomendados deacuerdo al contexto de uso de los sistemas de información.

d. Garantizar que el procesamiento de los datos no transgreda lasreglas de integridad y/o las reglas de negocio definidas a nivel dela capa de la lógica de negocio y/o a nivel de la capa de base dedatos.

e. Asegurar que los resultados esperados sean entregados a losinteresados (stakehoders) de una manera oportuna y en lasmejores condiciones.

f. Coordinar con el área responsable, el correcto mantenimiento delas plataformas de hardware, de software y de comunicaciones,con el fin de evitar que alguno de estos factores atenten contra laconfiabilidad del procesamiento de datos a través de sistemas deinformación.

g. Generar las pistas de auditoría que sean necesarias para cumplirlas políticas y/o las regulaciones internas y/o externas.

h. Definir y controlar la aplicación del modelo de gobernabilidad parael procesamiento de datos a través de sistemas de información.

i. Asegurar la correcta y efectiva aplicación de las políticas y losprocedimientos de seguridad relacionados con el procesamientode datos.

j. Para casos de procesamiento fuera de línea de grandesvolúmenes de información, asegurar que la ejecución de unproceso no afecte o se vea afectado por la ejecución de otros.

PROPUESTA



7.2. Manejo de errores

1. Con el fin de implementar una gestión efectiva de errores en elprocesamiento de datos, un sistema de información deberá:

a. Generar mensajes de error tan cerca de su punto de origen comosea posible.

b. Proveer mensajes de error que sean entendibles e inmediatos, detal forma que se favorezca a una resolución eficiente de lanovedad presentada.

c. Impedir que una transacción sea procesada a menos que loserrores presentados sean corregidos, o los efectos de éstos sehayan anulado.

d. Para el caso del procesamiento de transacciones en volumen, loserrores que no puedan corregirse automática e inmediatamentedeberán ser registrados en un log o bitácora de pendientes deprocesamiento, de tal forma que las transacciones válidas puedancontinuar con su procesamiento.

2. Los procedimientos para la gestión y corrección de errores deben serdefinidos y formalizados, considerando:

a. Las descripciones de los mensajes de error.

b. Los mecanismos de anulación.

c. La definición y cumplimiento de los acuerdos de nivel de serviciorelacionados a la atención y solución de errores.

d. La revisión y atención de errores por parte del personal con losroles y las habilidades adecuados.

e. Los niveles de escalamiento que sean necesarios.

f. La generación oportuna de reportes de transacciones fallidas, yde errores producidos, de tal forma que no se afecte alprocesamiento de las transacciones libres de errores.

g. El seguimiento apropiado de los errores desde su generaciónhasta su remediación.

h. La permanencia y el aprovechamiento de la informaciónrecopilada sobre los errores con fines de mejoras alprocesamiento de datos y a los controles automáticos.

PROPUESTA



7.3. Evaluación de resultados

1. Los resultados generados por un sistema de información deberán:

a. Ser completos y exactos, en función de los requerimientosespecificados por parte de los usuarios.

b. Ser presentados, formateados y entregados de una formaefectiva, consistente y segura.

c. Siempre que se trate de información sensible y crítica, serregistrados y asegurados adecuadamente para proveersalvaguardas adecuadas contra su robo o daño.

d. Para el caso de reportes físicos:

i. Ser distribuidos de acuerdo a los parámetros dedistribución autorizada.

ii. Ser registrados antes de su distribución.

iii. Ser tratados con sumo cuidado cuando sean impresospara evitar pérdida y/o exposición de información sensibley crítica.

iv. Tener políticas y procedimientos de desuso y destrucciónpara evitar pérdida y/o exposición de información sensibley crítica.

2. Los procedimientos para la evaluación de los resultados generados porun sistema de información deberán:

a. Definirse en base a estándares y/o buenas prácticas de laindustria.

b. Siempre que sea posible, no interrumpir la validación deresultados apenas se encuentre el primer error, sino presentar loshallazgos de la validación de manera consolidada.

c. Implementar mecanismos para el aseguramiento de lacompletitud y exactitud de los resultados generados por unsistema de información, considerando la notificación denovedades para cuando sea necesario.

d. Asegurar que la completitud y exactitud de los resultadosgenerados por un sistema de información, sean adecuadamenteverificados antes que los mismos sirvan de insumos para otrasoperaciones o procesos.

PROPUESTA



e. Contar con la participación de los usuarios de negocio que fungencomo propietarios de los resultados generados por un sistema deinformación.

f. Registrar las novedades encontradas en una bitácora o log deevaluación de resultados, con fines de mejoras al procesamientode datos y/o a los procedimientos de evaluación de los resultadosgenerados por un sistema de información.

g. Asegurar el manejo y la retención de los resultados generadospor un sistema de información, considerando los niveles deprivacidad y de seguridad, así como los procedimientos dedistribución que se hayan definido y/o acordado.

PROPUESTA



8. Referencias

Casanova, H. D. (2009). Los Registros Administrativos: Sus Ventajas ydesventajas. Sus diferencias frente a las encuestas y los censos.COBATAB, Villahermosa, México.

ISACA. (2009). COBIT and Application Controls; A Management Guide. RollingMeadows, Illinois, Estados Unidos: ISACA.

ISACA. (2011). Manual de Preparación al Examen CISA 2012. RollingMeadows, Illinois, Estados Unidos: ISACA.

ISO. (2011). ISO/TS 8000-1:2011, Data quality -- Part 1: Overview. Geneva,Suiza: ISO.

Wroblewski, L. (2008). Web Form Design: Filling in the Blanks. Brooklyn, NewYork, Estados Unidos: Rosenfeld Media.

PROPUESTA



9. Anexos

9.1. Ejemplo de Aplicación de las Normas para la Captura deDatos

Tal cual como se lo menciona en su definición, una norma establece lo que sedebe hacer, sin llegar a especificar el cómo se lo debe realizar.

Sin embargo con el fin de brindar información adicional sobre la aplicación dealgunas de las normas mencionadas en el presente documento, se indica acontinuación una dirección web en la cual se podrá encontrar materialrelacionado con la aplicación de la mayoría de las normas de validación en lacaptura de datos.

La URL en mención es: http://www.lukew.com/presos/preso.asp?19

En este sitio web el lector podrá acceder a un documento en formato PDF conejemplos de las mejores prácticas para el diseño de formularios web, los cualesconstituyen un ejemplo de los formularios digitales mencionados en el presentedocumento.

PROPUESTA

SECRETARIA NACIONAL DE PLANIFICACION Y DESARROLLO SUBSECRETARIA DEINFORMACION

Normas para Mejorar laImplementación deSistemas Integrales deInformaciónProducto 4: Normas para la verificación deidentidad y control de acceso de lainformaciónE – Open Solutions Cía. Ltda.

10/09/2013

El presente documento contiene los aspectos de índole normativos que deberán serconsiderados en la construcción de sistemas de información en lo referente a la verificación deidentidad y control de acceso de la información.

PROPUESTA

Normas para la verificación de identidad y control de acceso de la información


Contenido

1. Antecedentes............................................................................................... 22. Alcance........................................................................................................ 43. Referencias Normativas............................................................................... 54. Términos y Definiciones............................................................................... 75. Marco de Referencia.................................................................................... 96. Normas Comunes para la Verificación de Identidad y Control de Acceso dela Información................................................................................................... 117. Normas para la Verificación de Identidad .................................................. 178. Normas para el Control de Acceso de la Información................................ 249. Referencias................................................................................................ 2810. Anexos ...................................................................................................... 29

PROPUESTA



1. Antecedentes







PROPUESTA




PROPUESTA



2. Alcance








En función de lo expuesto, y en relación al alcance del presente documento, elmismo tiene la finalidad de dejar constancia escrita de las normas verificaciónde identidad y control de acceso de la información que un sistema deinformación debería cumplir con miras a soportar la posterior obtención deregistros administrativos.

En lo referente a la verificación de identidad y control de acceso, las normaspropuestas aportarán en el contexto de la seguridad para la integridad,disponibilidad y a la confiabilidad de los registros administrativos que sepudieran obtener posteriormente.

Finalmente es importante recalcar que al normar la verificación de identidad ycontrol de acceso en un sistema de información, desde el punto de vista de laseguridad de la información, se está generando el sustento necesario sobre elcual la institución podrá implementar mecanismos de auditoría sobre loshechos, con los datos que son proporcionados por un sistema de información.

PROPUESTA





ISO/IEC 27001:2005, Tecnología de Información – Técnicas deSeguridad – Sistemas de Gestión de la Seguridad de la Información -Requerimientos

Este estándar especifica los requisitos para establecer, implementar,operar, supervisar, revisar, mantener y mejorar un Sistema de Gestiónde Seguridad de la Información debidamente documentado. Del cualresaltan para el presente trabajo las recomendaciones para verificaciónde identidad y control de acceso de la información.

Es importante mencionar que éste estándar internacional tiene sucorrespondiente norma nacional NTE INEN ISO/IEC 27001 Tecnologíasde la Información. Técnicas de Seguridad. Sistemas de Gestión de laSeguridad de la Información. Requisitos (2010).

ISO/IEC 27002:2005, Tecnología de Información – Técnicas deSeguridad – Código de Práctica para la Gestión de la Seguridad de laInformación

Este estándar establece directrices y principios generales para iniciar,implementar, mantener y mejorar la gestión de seguridad de lainformación en una organización. Del cual resaltan para el presentetrabajo las recomendaciones para verificación de identidad y control deacceso.

Es importante mencionar que éste estándar internacional tiene sucorrespondiente norma nacional NTE INEN ISO/IEC 27002 Tecnologíasde la Información. Técnica de Seguridad. Código de Práctica para laGestión de la Seguridad de la Información (2009).


Este marco de gobierno establece procesos y controles para minimizarel riesgo y maximizar los beneficios de la aplicación de la tecnología enuna organización. En relación a la verificación de identidad y control deacceso de la información, este marco establece una serie de controlesde aplicación que deben ser considerados en la construcción desistemas de información.

PROPUESTA



Es importante mencionar que para criterio del autor, las referencias normativasaquí citadas son las más apropiadas para la generación de normas para laverificación de identidad y control de acceso de la información.

Finalmente es necesario indicar que las versiones de las referenciasnormativas aquí citadas, son las vigentes en relación a la generación denormas para verificación de identidad y control de acceso de la información almomento de la entrega del presente documento.

PROPUESTA





Amenaza Causa de un potencial incidente no-deseado, el cualpuede resultar en daño a un sistema u organización.

COBIT

Control de Acceso

Marco de gobernabilidad que establece procesos ycontroles para minimizar el riesgo y maximizar losbeneficios de la aplicación de la tecnología en unaorganización.

Proveer niveles apropiados de acceso a los sistemas oinformación a un usuario identificado.

Criticidad Grado de importancia que tiene un recurso para laorganización.


Impacto

Identidad Digital

Los resultados y consecuencias de que un potencialsuceso se materialice.

Conjunto de características, certificado o documento enlínea que representa en el mundo digital y certifica queuna Persona existe en el mundo real.


Norma Documento de ámbito público cuyo contenido estáfundado sobre los resultados conjugados de la ciencia,tecnología y experiencia, y cuya observancia no esobligatoria.

Objeto de Negocio

Perfiles

Privilegios

Estructura de datos que representa una entidad utilizada oreferenciada en los procesos de una organización. Susignificado tiene mayor sentido para los usuarios denegocio.

Definen limitaciones a recursos del sistema deinformación.

Permiso dado a un usuario para que realice ciertaoperación sobre un sistema de información.

Reglamento Documento de carácter obligatorio que contienedisposiciones legislativas, reglamentarias o

PROPUESTA



administrativas.

Riesgo

Roles

Es la probabilidad de explotar una vulnerabilidad quepuede generar impactos negativos para la operación de laorganización.

Conjuntos de Privilegios, un rol puede tener garantizadouna serie de privilegios tanto del sistema comosubsistemas, y componentes, a la vez puede tenergarantizados otros roles.

Sensibilidad

Single Sign On

Es el grado de impacto en la organización si se da unadivulgación no autorizada.

Procedimiento de autenticación que habilita al usuariopara acceder a varios sistemas con una sola instancia deidentificación.

Trazabilidad Conjunto de procedimientos que permiten conocer elhistórico, la ubicación y la trayectoria de un elemento a lolargo de una serie de fases y procesos. La auditoría es uncaso particular de la trazabilidad.

Usuario de Negocio /Usuario

Persona que pertenece a una organización y hace uso deun sistema de información para cumplir con sus funciones.

Verificación deIdentidad

Vulnerabilidad

Comprobar en el mundo digital que un usuario es quiendice ser.

Es la debilidad de un sistema de información que puedeser explotada por una o más amenazas.

PROPUESTA













Disponibilidad, que quiere decir que la información (registroadministrativo) sea accesible cuando el proceso o el usuario larequieran.


PROPUESTA






En relación con el alcance de la presente consultoría, las normas que seproponen tienen que ver con controles generales de TI y con sistemas deinformación por ende con controles de aplicación.

En lo referente a las normas incluidas en el presente documento, las mismasserán presentadas de la siguiente forma:

Considerando que tanto la verificación de identidad y control de accesode la información, son dos elementos de la triada de seguridad AAA1 ensistemas de información, en primer lugar se enunciarán normas que sonde consideración y aplicación común tanto para la verificación deidentidad, como para el control de acceso.

Posteriormente se enunciarán las normas que deben considerarse yaplicarse para asegurar exclusivamente la verificación de identidad enlos sistemas de información.

Y finalmente se enunciarán las normas que deben considerarse yaplicarse para asegurar exclusivamente el control de acceso en lossistemas de información.

Con todo esto se pretende que los registros administrativos que se puedanobtener de los sistemas de información cumplan con los requerimientos deverificación de identidad y control de acceso con miras a proveer el marco deseguridad enfocado a confidencialidad , integridad y disponibilidad de losdatos.

1 La triada de seguridad AAA es una buena práctica que establece que todo sistema deinformación que se considere seguro debe establecer controles sobre Autenticación(Verificación de Identidad), Autorización (Control de Acceso) y Auditoría.

PROPUESTA



6. Normas Comunes para la Verificación de Identidad yControl de Acceso de la Información

1. Por principio y buena práctica la verificación de identidad y control deacceso de la información deben ser aseguradas en todo momento de suexistencia. Esto es, desde su creación hasta su destrucción, y en todoslos estados intermedios productos de su transmisión sobre una red, suestadía temporal en memoria, su almacenamiento permanente otemporal en bases de datos, archivos, respaldos, dispositivos móviles, osu persistencia en medios impresos.

2. Por principio y buena práctica la organización debe realizar un análisisde riesgos para detectar las vulnerabilidades que podrían impactar a laverificación de identidad y control de acceso de la información ysistemas de información.

3. Por principio y buena práctica verificación de identidad y control deacceso de la información deben ser aseguradas a lo largo de todo elentorno informático. Esto es, desde los puntos en los que se originan lasinteracciones con los sistemas de información, a través de todos lospuntos de integración, procesamiento y persistencia de datos.

4. La verificación de identidad y control de acceso de la información debenser aseguradas en todo momento mediante la aplicación de lassiguientes prácticas:

a. La implementación de una combinación de varios mecanismos,procedimientos y políticas, establecidos en diferentes capas delos sistemas de información que resulten más difíciles de vulnerarque un solo o un reducido número de mecanismos de seguridad.

b. Los usuarios de los sistemas de información deben operarutilizando los privilegios que sean exclusivamente necesarios enfunción de las tareas, temporalidad y responsabilidades que lescompeten.

c. La información sobre usuarios, credenciales, grupos, roles yatributos, acceso a la información con categorización desusceptible, debe ser almacenada y gestionada en formacentralizada, con un enfoque holístico, y de una manera segura yauditable.

5. Con el fin de implementar una gestión efectiva de la verificación deidentidad y control de acceso de la información se debe:

a. Establecer la política de seguridad de la información al interior dela organización y en concordancia con sus objetivos de negocio.

PROPUESTA



b. Conseguir y formalizar el apoyo y el compromiso de la direcciónde la organización para con la política de seguridad de lainformación previamente definida.

c. Documentar y socializar al interior de la organización, la políticade seguridad de la información previamente definida.

d. Definir y asignar claramente las responsabilidades, y la rendiciónde cuentas, sobre la verificación de identidad y control de accesode la información, acorde a la política de seguridad de lainformación previamente definida.

6. Si se tiene que interactuar con entidades externas las cuales poseenacceso y/o procesan la información de la organización, se debe:

a. Identificar los riesgos sobre verificación de identidad y acceso a lainformación ,y los medios de acceso y procesamiento de lainformación.

b. Definir e implementar los controles relacionados a los riesgosidentificados, antes de otorgar la identidad y acceso a la entidadexterna.

7. Se debe asegurar que empleados, proveedores, y terceros, entiendan yasuman sus responsabilidades en relación a la política de seguridad dela organización:

a. Antes,

b. Durante y

c. Después de su interacción con la organización.

8. Si la organización brinda o utiliza servicios de comercio electrónico, sedebe:

a. Identificar las implicaciones y los riesgos para la verificación deidentidad y control de acceso de la información.

b. Establecer los requerimientos de controles con el fin de asegurarla verificación de identidad y control de acceso de la información.

c. Proteger la identidad y el acceso a la información involucrada enel comercio electrónico que se transmite a través de redespúblicas de eventos tales como:

i. Fraudes

PROPUESTA



ii. Disputas contractuales

iii. Divulgación no autorizada

iv. Modificación no autorizada

d. Proteger la identidad y el acceso a la información involucrada entransacciones en línea para evitar:

i. Transmisión incompleta

ii. Enrutamiento equivocado

iii. Alteración no autorizada

iv. Divulgación no autorizada

v. Duplicación no autorizada

vi. Re-envío no autorizado

PROPUESTA



9. Para el desarrollo, el mantenimiento y la adquisición de sistemas deinformación, se debe asegurar el apego y el cumplimiento de loslineamientos de verificación de identidad y control de acceso de lainformación, incluidos en la política de seguridad de la informaciónpreviamente definida.

10.En las etapas de prueba o de certificación de nuevos sistemas deinformación, se debe verificar el cumplimiento y el apego a loslineamientos de verificación de identidad y control de acceso de lainformación, incluidos en la política de seguridad de la informaciónpreviamente definida.

11.Para el caso de software base como: sistemas operativos, sistemas degestión de bases de datos, servidores de aplicaciones y otros, que sonadquiridos a terceros. Se debe definir, implementar y controlar unprocedimiento para obtener y gestionar oportunamente la informaciónsobre las vulnerabilidades técnicas que puede tener este software y quepodrían atentar contra la verificación de identidad y control de acceso dela información.

12.La gestión de incidentes relacionados a verificación de identidad ycontrol de acceso de la información en los sistemas de informacióndebe:

a. Asegurar que la información de tales incidentes sea comunicadade manera oportuna de tal forma que se pueda tomar la accióncorrectiva más apropiada.

b. Asegurar una respuesta rápida, efectiva y ordenada a losincidentes reportados.

c. Permitir obtener métricas sobre la efectividad de la gestión de losincidentes reportados.

d. Incluir la recolección, mantenimiento y presentación de losregistros de incidentes con miras a ser utilizados como evidenciasen eventuales acciones legales en contra de personas uorganizaciones.

13.En relación al cumplimiento de leyes y/o regulaciones sobre laverificación de identidad y control de acceso de la información en lossistemas de información utilizados por la organización, se debe:

a. Formalmente, definir, documentar y actualizar los requerimientosde verificación de identidad y control de acceso de la informaciónque deben cumplir todos los sistemas de información utilizados enla organización.

PROPUESTA



b. Definir, implementar y monitorear los procedimientos apropiadospara asegurar el cumplimiento de las leyes y/o regulaciones sobrela verificación de identidad y control de acceso de la informaciónen los sistemas de información.

14.El valor de la inversión para asegurar la verificación de identidad ycontrol de acceso de la información, deberá ser proporcional al valor quepara la organización representa la información a ser protegida con talinversión.

15.En relación al cumplimiento de las políticas y normas relacionadas con laverificación de identidad y control de acceso de la información, se debedefinir, implementar y socializar al interior de la organización, losprocedimientos adecuados para verificar y evaluar el cumplimiento y laefectividad de dichas políticas y normas.

16.Los requerimientos de verificación de identidad y control de acceso a lainformación deben ser considerados en los planes de contingencia y/orecuperación ante desastres, desarrollados al interior de la organización.

17.Debe definirse e implementarse formal y periódicamente al interior de laorganización ciclos de concientización y capacitación sobre los riesgos ypeligros que trae la no observancia o incumplimiento de las normas ypolíticas de verificación de identidad y control de acceso de lainformación.

18.Se debe establecer políticas, procedimientos y controles para proteger lainformación sobre verificación de identidad y control de acceso durantesu intercambio, utilizando todos los tipos de medios de comunicación,tanto al interior como al exterior de la organización.

19.De manera complementaria a la norma anterior, se debe estableceracuerdos de intercambio de información relacionada a la Verificación deIdentidad y Control de Acceso con quien sea apropiado, considerandolos siguientes elementos:

a. La gestión de las responsabilidades para el control y notificaciónde la transmisión, despacho y recepción.

b. Los procedimientos para notificar al remitente de la transmisión,despacho y recepción.

c. Los procedimientos para asegurar el rastreo y la autenticacióncomo genuino.

d. Los estándares técnicos mínimos para la transmisión.

e. Los estándares de identificación del mensajero.

PROPUESTA



f. Las responsabilidades y obligaciones en el caso de incidentesque atenten contra la verificación de identidad y control de accesode la información.

g. El uso de un sistema de etiquetación de la información paraidentificar claramente los niveles de verificación de identidad ycontrol de acceso de la misma.

h. La propiedad y responsabilidades de la protección de lainformación, los derechos de autor, las licencias de software yotras consideraciones similares.

i. Los estándares técnicos para grabar y leer la información o elsoftware.

j. Cualquier control adicional que se requiera por la naturaleza de laverificación de identidad y control de acceso, por ejemplo clavescriptográficas o códigos de verificación.

20.En el caso de que el personal de la organización utilice dispositivosmóviles o acceso remoto para acceder y/o manejar información de laorganización. Se debe definir, implementar y formalizar la aplicación delos procedimientos necesarios para asegurar el buen uso de lainformación en relación a la verificación de identidad y control de accesoa la información se mantendrán intactas inclusive en caso de daño,pérdida o robo de los dispositivos.

PROPUESTA



7. Normas para la Verificación de Identidad

1. Se debe definir, implementar y dar a conocer de manera formal unapolítica de Verificación de identidad en base a la política de seguridaddefinida en la organización.

2. La Verificación de la Identidad debe aplicarse tanto al personal de laorganización como al externo, y debe cumplir con lo establecido por laspolíticas de seguridad de la organización y/o las regulaciones aplicables.

3. La Verificación de la identidad debe considerar la protección de lainformación propia de la organización, su operación y sus empleados;así como también de la información suministrada por clientes, usuarios uotras organizaciones.

4. Se debe implementar una plataforma tecnológica para gestión yverificación de identidad utilizada por la organización, la misma deberáimplementar los mecanismos necesarios para garantizar el cumplimientode las políticas de Verificación de identidad, control de acceso y deseguridad de la organización, dicha plataforma deberá:

a. Administrar identidades individuales en el contexto de sistemas,como organizaciones, sistemas, redes, países, entre otros.

b. Administrar roles y privilegios de usuarios.

c. Proveer a los Gestores de TI de herramientas y tecnología paraproteger y controlar la identidad y por ende el acceso ainformación crítica y sensible de la organización.

d. Manejar un único identificador por usuario.

e. Mantener, modificar y monitorear la identidad y acceso a travésde ciclo de vida de los sistemas de información.

f. Proveer a los Gestores de IT de herramientas y tecnología paramodificar los roles y privilegios de usuario, controlar y auditar lasactividades de usuario y aplicar políticas sobre la marcha.

g. Proveer de administración de acceso de usuario a todos losrecursos informáticos de la organización,

h. Asegurar el cumplimiento de las regulaciones nacionales einternacionales relacionadas a la verificación de identidad ycontrol de acceso de la información.

5. La plataforma mencionada en el punto anterior deberá ser provista comoun único repositorio o servicio de Identidad para la Organización, al cual

PROPUESTA



podrán acceder los sistemas, equipos, redes y demás componentes dela plataforma tecnológica, dicha plataforma deberá ser administrada porel departamento de TI y se deberá establecer los controlescorrespondientes para cumplir con la política de seguridad de laorganización.

6. La plataforma de Gestión y Verificación de identidad deberá interactuarsin limitación con los sistemas y subsistemas organizacionales así comopermitir la identificación y control de los roles, perfiles y privilegiosasociados a los usuarios.

7. Por principio y buena práctica se debe implementar un proceso formalpara identificar, documentar y controlar los roles y funciones que cumplecada miembro de la organización , los mismos representarán losderechos de acceso a sistemas o porciones de sistemas de informaciónen los denominados perfiles de usuario, para esto se debe considerar:

a. Que los usuarios deben ser asociados a uno o varios perfiles enbase a los servicios para los cuales han sido específicamenteautorizados en función de su rol y funciones.

b. Se debe identificar y controlar la temporalidad de las tareas encaso de que un mismo funcionario tenga diferentes perfiles, esdecir realizar una separación de funciones y controlarla en loscasos que aplique.

c. Los privilegios se deben asignar a los usuarios sobre la base de“solo lo que necesitan saber” y sobre una base de evento-por-evento en línea con la política de control de acceso. Es decir losprivilegios mínimos para su rol funcional.

8. Como principio y buena practica se debe realizar una gestión formal declaves asignadas a cada usuario para esto se debe incluir las siguientesconsideraciones:

a. Requerir que los usuarios firmen un enunciado para mantenerconfidenciales las claves secretas y claves grupales solo dentrodel grupo; esto se puede incluir en las condiciones de empleo.

b. Se deberá proporcional inicialmente una clave secreta , la cual sedeberá modificar inmediatamente al ser recibida.

c. Establecer procedimientos para verificar la identidad de unusuario antes de proporcionar una clave secreta nueva, sustitutivao temporal.

PROPUESTA



d. Las claves temporales, deberán ser proporcionadas de manerasegura, evitando mensajes de correo electrónico de terceros o noprotegidos (texto plano).

e. Las claves deberán ser únicas para la persona y no deberán serfáciles de adivinar.

f. Los usuarios deberán reconocer por un medio formal la recepciónde las claves.

g. La claves secretas nunca deberán ser almacenadas en lossistemas de computo de forma desprotegida.

h. Las claves predeterminadas por el vendedor deberán sercambiadas inmediatamente luego de la instalación de sistemas, osoftware.

9. Como buena práctica y principio se debe asegurar que el usuario tengaclaro criterios para la selección y uso de contraseñas, para eso se debesocializar y controlar las responsabilidades como:

a. Mantener confidenciales las claves secretas.

b. Evitar mantener un registro en papel, archivo o dispositivo deforma insegura.

c. Modificar la clave cuando existan indicios de posible peligro en elsistema o la clave secreta.

d. Seleccionar claves de calidad en base a la política definida,considerando que no sean fáciles de recordar, que no seanfáciles de adivinar mediante ingeniería social, que no sean dediccionario y que no posean caracteres idénticos consecutivos.

e. Modificar regularmente la contraseña en intervalos irregulares oen base a un numero de accesos, evitando el reciclaje o re-usode claves antiguas.

f. No incluir claves en ningún proceso automatizado, o deprogramación.

g. No compartir claves secretas.

10.En caso de ser necesario se puede considerar otras tecnologíasadicionales a la de clave segura para la identificación y autenticación delusuario, como las biométricas, firmas digitales y uso de dispositivos dehardware como tarjetas inteligentes, tokens u otros dispositivos que

PROPUESTA



soporten autenticación multi-factor, siempre y cuando estén asociadas ala plataforma de gestión de identidad y aprobados por la política deseguridad de la organización.

11.La organización debe asegurar que todos sus empleados observen losmás altos estándares de conducta y ética profesional relacionados conel respeto y apego a las políticas establecidas de Verificación deidentidad de la organización.

12.Para el caso de la información contenida en documentos de papel, sedebe asegurar que la misma sea identificada de manera física según lapolítica de gestión de identidad, con el fin de evitar pérdidas, robos oexposición no adecuada.

13.La organización debe definir, implementar y socializar a su interior, lasacciones disciplinarias o legales en las que podría incurrir por ladivulgación no adecuada, robo o pérdida de información relacionada asuplantación o entrega deliberada de la identidad.

14. La organización debe definir y firmar con quien aplique los acuerdos deconfidencialidad o acuerdos de no-divulgación para proteger lainformación relacionada con gestión/verificación de la identidad y accesoa la información, considerando los siguientes elementos:

a. La definición de la información a proteger.

b. La duración esperada del acuerdo.

c. Las acciones requeridas cuando se termine el acuerdo.

d. Las responsabilidades y acciones de los firmantes.

e. La propiedad de la información motivo del acuerdo.

f. El uso permitido de la información a proteger.

g. El proceso de notificación y reporte de divulgación no autorizadao incumplimiento del acuerdo.

h. Las condiciones para el retorno o destrucción de la informacióntras el término del acuerdo.

i. Las acciones a realizarse tras el incumplimiento del acuerdo.

15.La organización debe revisar periódicamente los acuerdos de gestión deidentidad o acuerdos de no-divulgación de identidad, para asegurar que

PROPUESTA



los mismos reflejan las necesidades actuales de la organización paraproteger la confidencialidad de la información.

16.La Verificación de Identidad involucrada en mensajes electrónicos debeser asegurada considerando los siguiente aspectos:

a. Evitar el acceso no autorizado, la modificación o la negación delservicio de mensajería.

b. Asegurar la correcta dirección y transporte del mensaje.

c. Los requerimientos de aspecto legal.

d. Los niveles de seguridad de las redes o servicios públicos quesean utilizados para la transmisión de mensajes electrónicos.

e. La utilización de métodos de verificación de identidad aprobadosen la legislación como firma electrónica.

17.Se debe generar una política sobre el uso de la encriptación como unaherramienta para proteger la Verificación de Identidad. Dicha políticadebe considerar:

a. La protección de la información de identidad almacenada endispositivos y en tránsito a través de una red.

b. El ámbito de acción de la encriptación en función de lasdirectrices corporativas de la organización.

c. El tipo, la fuerza y la calidad de los algoritmos de encriptaciónutilizados.

d. La gestión que se le deberá dar a las claves de encriptación.

e. Los roles y responsabilidades asociados con el uso de laencriptación.

f. La plataforma tecnológica que soportará el uso de la encriptación.

g. El impacto de la utilización de la encriptación en los sistemasinformáticos que se usan en la organización.

h. Las leyes y regulaciones nacionales e internacionales relativas ala aplicación de la encriptación.

i. La maximización de los beneficios del uso de la encriptación.

j. La minimización de los riesgos y el mal uso de la encriptación.

PROPUESTA



18.Si la organización en miras a cumplir la política de Verificación deIdentidad se decide por el uso de la encriptación, se debe establecer unsistema para la gestión adecuada de la contraseña asociada a laIdentidad. Dicho sistema debe basarse en estándares, procedimientos ymétodos seguros y acordados para:

a. Generar las claves para los varios sistemas de información queusan encriptación.

b. Generar y obtener certificados de claves públicas.

c. Distribuir las claves a los usuarios autorizados y su respectivaactivación.

d. Almacenar la claves y como los usuarios autorizados acceden alas mismas.

e. Cambiar o actualizar las claves, incluyendo la periodicidadobligatoria y el procedimiento de ejecución.

f. Proceder con las claves que han sido comprometidas.

g. Revocar y/o desactivar las claves.

h. Recuperar las claves, cuando estas han sido olvidadas, perdidaso corrompidas.

i. Archivar las claves.

j. Destruir las claves.

k. Registrar y auditar las acciones relacionadas a la gestión declaves.

19.La red de datos de la organización deberá ser asegurada para evitar eluso y la explotación de canales encubiertos por parte de códigosmaliciosos, como por ejemplo programas troyanos, lo cual puededesencadenar en una filtración de información de identidad consideradacomo altamente confidencial.

20.El desarrollo de software al interior y exterior de la organización debe sersupervisado y monitoreado para asegurar que las políticas definidassobre la verificación de identidad de acceso a la información, seanaplicadas adecuadamente.

21.Los diseños de los sistemas de información deben desarrollarsepreferentemente en base a un esquema de propagación de la identidad

PROPUESTA



del usuario desde la capa de presentación del aplicativo hasta la capade la base de datos.

PROPUESTA



8. Normas para el Control de Acceso de la Información.

1. Se debe definir, implementar y socializar una política de control deacceso en base a la política de seguridad definida en la organización.

2. Por principio y buena práctica se debe garantizar y asegurar el accesodel usuario autorizado y evitar acceso no-autorizado a la información ysistemas de la información, para esto se debe:

a. Definir un procedimiento formal para inscripción y re-inscripciónpara otorgar acceso a los sistemas y servicios de información.

b. Controlar y restringir la asignación y uso de los privilegios.

c. Se debe controlar la asignación de claves a través de un procesoformal de gestión.

d. Revisar regularmente los derechos de acceso de los usuariosutilizando un proceso formal.

3. Como buena práctica y principio se debe identificar, documentar ysocializar las responsabilidades del usuario, con el fin de evitar accesosno autorizados y riesgos inherentes a la información, para esto se debe:

a. Requerir que los usuarios se aseguren de dar la protecciónapropiada al equipo desatendido.

b. Adoptar una política de escritorio limpio para los documentos ymedios de almacenaje removibles y una política de pantalla limpiapara los medios de procesamiento de información.

4. Por principio y buena práctica se debe evitar el acceso no autorizado alos servicios e información de los sistemas de información, para esto sedebe considerar:

a. Que los usuarios solo deben tener acceso a los servicios para loscuales han sido específicamente autorizados en base a su rol yfunciones, adicionalmente se debe identificar y controlar latemporalidad de las tareas es decir días, horas en las que tendráacceso, adicionalmente considerar que un usuario podrá tenervarios roles, y que deberán separarse y controlarse los mismosen el control de acceso.

b. Se debe utilizar métodos de autenticación y control de accesofuertes para controlar el acceso de usuarios remotos.

PROPUESTA



c. Se debe considerar la identificación automática del equipo comoun medio para autentificar las conexiones desde equipos yubicaciones específicas.

d. Se debe controlar el acceso físico y lógico a los puertos dediagnostico y configuración en los que residan sistemas deinformación.

e. Los servicios de información, usuarios y sistemas de informaciónse deben separar, asegurar y auditar en las redes.

f. Se debe restringir la capacidad de conexión de los usuarios en lasredes compartidas, especialmente aquellas que se extienden através de los límites organizacionales, en concordancia con lapolítica de control de acceso y los requerimientos del giro delnegocio.

g. Se debe implementar controles de ruteo para las redes y asegurarque las conexiones y flujos de información no infrinjan la políticade control de acceso a los sistemas de información.

5. Por principio y buena práctica se debe evitar el acceso no autorizado alos sistemas operativos donde residan sistemas de información oporciones de este, para esto se debe:

a. Controlar el acceso a los servicios mediante un procedimiento deregistro seguro, procedimiento que habilite acceder a variossistemas de información con una sola instancia de identificación(Single Sign On).

b. Definir que todos los usuarios deben tener un identificador únicopara su uso personal y exclusivo, se debe elegir una técnica deautenticación adecuada para verificar la identidad de usuario,incluyendo sistemas de validación en base a autenticación multi-factor.

c. Controlar que los sistemas de manejo de Verificación de Identidaddeben ser interactivos y asegurar la calidad de las claves deacceso.

d. Restringir y controlar estrictamente el uso de los programasutilitarios y acceso por parte de usuarios privilegiados, quepodrían superar al sistema y controles de aplicación, yproporcionar acceso indiscriminado a la información o datos delos sistemas de información.

PROPUESTA



e. Se debe garantizar el cierre de aplicaciones luego de un periodode inactividad definido.

f. Debe utilizarse restricciones en base a los perfiles, roles,funciones, la temporalidad de las funciones y tareas paraproporcionar seguridad adicional a las porciones de informaciónde alto riesgo.

6. Por principio y buena práctica se debe evitar el acceso no autorizado alsistema de información e información ,para esto se debe:

a. Controlar y restringir el acceso de los usuarios y personal desoporte o que disponga de privilegios elevados al sistema deinformación, subsistemas, base de datos, datos, funciones deaplicación hasta un nivel granular adecuado y servidores deaplicación en concordancia con la política de control de accesodefinida.

b. Definir que los sistemas sensibles deben tener un ambientededicado y aislado.

7. Por principio y buena practica se debe asegurar el acceso a lainformación cuando se utilicen dispositivos móviles y acceso remoto,para esto se debe establecer:

a. Una política formal para la utilización de dispositivos móviles tantoorganizacionales como en modalidad BYOD y acceso remoto, yadoptar las medidas de seguridad pertinentes.

b. Se debe desarrollar e implementar políticas, planes operacionalesy procedimientos para actividades de acceso remoto.

8. Por principio y buena práctica se debe definir requerimientos y políticasde seguridad y políticas de control de acceso , mismos que deben serparte integral y estar definidos como requerimientos para la adquisición,desarrollo y mantenimiento de los sistemas de información.

9. Se debe definir, implementar y dar a conocer de manera formal, losprocedimientos necesarios para asegurar que la política de control deacceso que se utilice al interior de la organización siempre estéactualizada, esto es se utilice siempre su última versión.

10.Todo sistema de información en fases de desarrollo o mantenimiento,deberá ser analizado y diseñado con la participación conjunta de losgestores de IT/Seguridad, analistas de sistemas y de los usuarios denegocio relacionados con la funcionalidad del sistema de información. Elobjetivo es que el gestor de seguridad identifique y especifique todos los

PROPUESTA



requerimientos sobre seguridad y el control de acceso de la información,y que se asegure que éstos sean considerados en la etapa de diseño.

11.Todo mantenimiento realizado a sistemas de información en relación a laseguridad y el control de acceso deberá ser documentado en losmanuales y ayudas en línea correspondientes, siendo este un requisitopara habilitar la puesta en producción del mantenimiento en mención.

12.El control de acceso en los sistemas de información deberá serpreferentemente establecido utilizando una única solución de gestión yVerificación de Identidades, misma que deberá ser definida, gestionaday asegurada por la política de gestión/verificación de identidad.

13.Para controlar de mejor manera el control de acceso de la informaciónen los procesos de la organización, se deberá definir tantos puntos decontrol o chequeo como necesidades de seguridad se requieran.

14.En las etapas de prueba o certificación de los sistemas de información,se debe preparar casos de prueba y escenarios de prueba quecontemplen todas, o de no ser posible la totalidad la mayoría de lasvalidaciones de control de acceso que se pudieran dar con el fin deverificar si los resultados producidos por el sistema de información sonlos esperados.

15.Las pruebas de control de acceso en un sistema de información debenejecutarse en primer lugar con una cantidad ligeramente moderada dedatos, y finalmente con un volumen de datos semejante al real.

16.Se debe llevar un registro adecuado de las versiones del software y delos sistemas de información utilizados en la organización, con el fin deasegurar que las actualizaciones de versiones no atenten a loslineamientos de control de acceso de la información.

17.Los usuarios de negocio deberán ser provistos de manera oportuna deuna adecuada capacitación así como de la respectiva documentacióncon el fin de que pueda hacer un buen uso de los sistemas deinformación como un apoyo a las funciones que desempeñan en base ala política de control de acceso.

18.Con el fin de evitar los riesgos de accesos no autorizados y la alteracióno destrucción total de la información, lo cual atenta contra el control deacceso. Cuando aplique, se debe contar con ambientes separados eindependientes para desarrollo, pruebas (test), pre-producción, yproducción.

19.La organización debe asegurar que el control de acceso de lainformación no se vea afectada por la intromisión y ejecución de códigosmaliciosos o virus.

PROPUESTA



9. Referencias




ISO/IEC. (2005). ISO/IEC 27001:2005(E) Information technology - Securitytechniques - Information security management systems - Requirements.Geneva, Suiza: ISO/IEC.

ISO/IEC. (2005). ISO/IEC 27002:2005(E) Information technology - Securitytechniques - Code of practice for information security management.Geneva, Suiza: ISO/IEC.

PROPUESTA



10. Anexos

En los siguientes url´s se tiene casos de ejemplo de políticas de seguridad,verificación de identidad y control de acceso.

Se hace referencia a que los documentos puede o no contener elementosrelacionados a la normativa expuesta, sin embargo es un buen punto de partidapara considerar al redactar políticas de seguridad , verificación de identidad ycontrol de acceso, cada organización podrá evaluarlo, modificarlo y aplicarlocon el fin de cumplir con la norma propuesta.

http://www.utpl.edu.ec/csirt-utpl/images/stories/manual.pdf

http://www.utn.edu.ar/download.aspx?idFile=14736

PROPUESTA


Normas para Mejorar laImplementación deSistemas Integrales deInformaciónProducto 5: Normas para la confidencialidade integridad de la informaciónE – Open Solutions Cía. Ltda.

11/10/2013

El presente documento contiene los aspectos de índole normativos que deberán serconsiderados en la construcción de sistemas de información en lo referente a laconfidencialidad e integridad de la información.

PROPUESTA

Normas para la confidencialidad e integridad de la información


Contenido

1. Antecedentes .............................................................................................. 22. Alcance ....................................................................................................... 43. Referencias Normativas .............................................................................. 64. Términos y Definiciones .............................................................................. 85. Marco de Referencia ................................................................................. 106. Normas Comunes para la Confidencialidad y la Integridad de laInformación....................................................................................................... 127. Normas para la Confidencialidad de Información...................................... 188. Normas para la Integridad de la Información ............................................ 229. Referencias ............................................................................................... 26

9.1. Ejemplo de Aplicación del Estándar 27001 ......................................... 289.2. Ejemplo de Aplicación del Marco COBIT ............................................ 29

PROPUESTA



1. Antecedentes







PROPUESTA




PROPUESTA



2. Alcance








En función de lo expuesto, y en relación al alcance del presente documento, elmismo tiene la finalidad de dejar constancia escrita de las normas deconfidencialidad e integridad de datos que un sistema de información deberíacumplir con miras a soportar la posterior obtención de registros administrativos.

En lo referente a la confidencialidad de los datos, las normas propuestasaportarán a la seguridad, y a la fiabilidad de los registros administrativos que sepudieran obtener posteriormente.

En lo referente a la integridad de los datos, las normas propuestas aportarán ala validez, a la exactitud, y a la completitud de los registros administrativos quese pudieran obtener posteriormente.

Finalmente es importante recalcar que al normar la confidencialidad y laintegridad de los datos en un sistema de información, desde el punto de vistade la seguridad de la información, se está generando el sustento necesario

PROPUESTA



sobre el cual la institución podrá implementar mecanismos de auditoría sobrelos hecho con los datos que son proporcionados por un sistema de información.

PROPUESTA






Este estándar especifica los requisitos para establecer, implementar,operar, supervisar, revisar, mantener y mejorar un Sistema de Gestiónde Seguridad de la Información debidamente documentado. Del cualresaltan para el presente trabajo las recomendaciones paraconfidencialidad e integridad de la información.



Este estándar establece directrices y principios generales para iniciar,implementar, mantener y mejorar la gestión de seguridad de lainformación en una organización. Del cual resaltan para el presentetrabajo las recomendaciones para confidencialidad e integridad de lainformación.



Este marco de gobierno establece procesos y controles para minimizarel riesgo y maximizar los beneficios de la aplicación de la tecnología enuna organización. En relación a la confidencialidad y la integridad de losdatos, este marco establece una serie de controles de aplicación quedeben ser considerados en la construcción de sistemas de información.

PROPUESTA



Es importante mencionar que para criterio del autor, las referencias normativasaquí citadas son las más apropiadas para la generación de normas para laconfidencialidad e integridad de datos en sistemas de información.

Finalmente es necesario indicar que las versiones de las referenciasnormativas aquí citadas, son las vigentes en relación a la generación denormas para la confidencialidad y la integridad de datos en sistemas deinformación, al momento de la entrega del presente documento.

PROPUESTA





Amenaza Una causa potencial de un incidente no-deseado, el cualpuede resultar en daño a un sistema u organización.


Criticidad El grado de importancia que tiene un recurso para laorganización.


Impacto Los resultados y consecuencias de que un riesgo sematerialice.



Objeto de Negocio Estructura de datos que representa una entidad utilizada oreferenciada en los procesos de una organización. Susignificado tiene mayor sentido para los usuarios denegocio.


Riesgo Es la probabilidad de explotar una vulnerabilidad quepuede generar impactos negativos para la operación de laorganización.

Sensibilidad Es el grado de impacto en la organización si se da unadivulgación no autorizada.

Trazabilidad Conjunto de procedimientos que permiten conocer elhistórico, la ubicación y la trayectoria de un elemento a lolargo de una serie de fases y procesos. La auditoría es uncaso particular de la trazabilidad.

PROPUESTA




Vulnerabilidad Es la debilidad de un sistema de información que puedeser explotada por una o más amenazas.

PROPUESTA















PROPUESTA







En lo referente a las normas incluidas en el presente documento, las mismasserán presentadas de la siguiente forma:

Considerando que tanto la confidencialidad como la integridad, son doselementos de la triada de seguridad1 en sistemas de información, Enprimer lugar se enunciarán normas que son de consideración yaplicación común tanto para la confidencialidad, como para la integridad.

Posteriormente se enunciarán las normas que deben considerarse yaplicarse para asegurar exclusivamente la confidencialidad de los datosen los sistemas de información.

Y finalmente se enunciarán las normas que deben considerarse yaplicarse para asegurar exclusivamente la integridad de los datos en lossistemas de información.

Con todo esto se pretende que los registros administrativos que se puedanobtener de los sistemas de información cumplan con los requerimientos deconfidencialidad y de integridad.

1 La triada de seguridad es una buena práctica que establece que todo sistema de informaciónque se considere seguro debe establecer controles sobre confidencialidad, integridad ydisponibilidad.

PROPUESTA



6. Normas Comunes para la Confidencialidad y laIntegridad de la Información

1. Por principio y buena práctica la confidencialidad y la integridad de lainformación deben ser aseguradas en todo momento de su existencia.Esto es, desde su creación hasta su destrucción, y en todos los estadosintermedios productos de su transmisión sobre una red, su estadíatemporal en memoria, su almacenamiento permanente o temporal enbases de datos, archivos, respaldos, dispositivos móviles, o supersistencia en medios impresos.

2. Por principio y buena práctica la información debe ser clasificada con elfin de determinar sus requerimientos de confidencialidad y de integridad,y con el fin de identificar sus niveles de sensibilidad y criticidad. Laclasificación de la información debe definir:

a. Quién es el propietario de la información

b. Cuáles son sus niveles de sensibilidad

c. Cuáles son sus niveles de criticidad

d. Quién tiene derechos de acceso

e. Cuáles son los niveles de acceso

f. Quién es el responsable por determinar y aprobar los derechos ylos niveles de acceso

g. Cuáles son el grado y la profundidad de los controles deseguridad que se deben aplicar

3. La organización debe revisar periódicamente las clasificaciones de lainformación, para asegurar que las mismas reflejan las necesidadesactuales sobre confidencialidad e integridad de la información que estásiendo manejada por la organización.

4. En base a las clasificaciones de la información, la organización deberealizar un análisis de riesgos para detectar las vulnerabilidades quepodrían impactar a la confidencialidad y a la integridad de la informaciónmanejada en la organización.

5. Por principio y buena práctica la confidencialidad y la integridad de lainformación deben ser aseguradas a lo largo de todo el entornoinformático. Esto es, desde los puntos en los que se originan lasinteracciones con los sistemas de información, a través de todos lospuntos de integración, procesamiento y persistencia de datos.

PROPUESTA



6. La confidencialidad y la integridad de la información deben seraseguradas en todo momento mediante la aplicación de las siguientesprácticas:

a. La implementación de una combinación de varios mecanismos,procedimientos y políticas, establecidos en diferentes capas delos sistemas de información que resulten más difíciles de vulnerarque un solo o un reducido número de mecanismos de seguridad.

b. Los usuarios de los sistemas de información deben operarutilizando los privilegios que sean exclusivamente necesarios enfunción de las tareas y responsabilidades que les competen.

c. La información sobre usuarios, credenciales, grupos, roles yatributos, debe ser almacenada y gestionada en formacentralizada, con un enfoque holístico, y de una manera segura yauditable.

7. Con el fin de implementar una gestión efectiva de la confidencialidad yde la integridad de la información se debe:

a. Establecer la política de seguridad de la información al interior dela organización y en concordancia con sus objetivos de negocio.

b. Conseguir y formalizar el apoyo y el compromiso de la direcciónde la organización para con la política de seguridad de lainformación previamente definida.

c. Documentar y comunicar formalmente, al interior de laorganización, la política de seguridad de la informaciónpreviamente definida.

d. Definir y asignar claramente las responsabilidades, y la rendiciónde cuentas, sobre la confidencialidad y la integridad de lainformación, acorde a la política de seguridad de la informaciónpreviamente definida.

8. Si se tiene que interactuar con entidades externas las cuales poseenacceso y/o procesan la información de la organización, se debe:

a. Identificar los riesgos sobre la información y los medios deprocesamiento de la información.

b. Definir e implementar los controles relacionados a los riesgosidentificados, antes de otorgar el acceso a la entidad externa.

PROPUESTA



9. Se debe asegurar que empleados, proveedores, y terceros, entiendan yasuman sus responsabilidades en relación a la política de seguridad dela organización:

a. Antes de su interacción con la organización;

b. Durante su interacción con la organización; y

c. Después de su interacción con la organización.

10.Si la organización brinda o utiliza servicios de comercio electrónico, sedebe:

a. Identificar las implicaciones y los riesgos para la confiabilidad y laintegridad de la información.

b. Establecer los requerimientos de controles con el fin de asegurarla confiabilidad y la integridad de la información.

c. Proteger la información involucrada en el comercio electrónicoque se transmite a través de redes públicas de eventos talescomo:

i. Fraudes

ii. Disputas contractuales

iii. Divulgación no autorizada

iv. Modificación no autorizada

d. Proteger la información involucrada en transacciones en líneapara evitar:

i. Transmisión incompleta

ii. Enrutamiento equivocado

iii. Alteración no autorizada

iv. Divulgación no autorizada

v. Duplicación no autorizada

vi. Re-envío no autorizado

PROPUESTA



11.Para el desarrollo, el mantenimiento y la adquisición de sistemas deinformación, se debe asegurar el apego y el cumplimiento de loslineamientos de confidencialidad y de integridad de la información,incluidos en la política de seguridad de la información previamentedefinida.

12.En las etapas de prueba o de certificación de nuevos sistemas deinformación, se debe verificar el cumplimiento y el apego a loslineamientos de confidencialidad y de integridad de la información,incluidos en la política de seguridad de la información previamentedefinida.

13.Para el caso de software base como: sistemas operativos, sistemas degestión de bases de datos, servidores de aplicaciones y otros, que sonadquiridos a terceros. Se debe definir, implementar y controlar unprocedimiento para obtener y gestionar oportunamente la informaciónsobre las vulnerabilidades técnicas que puede tener este software y quepodrían atentar contra la confidencialidad y/o la integridad de lainformación.

14.La gestión de incidentes relacionados a la confiabilidad y a la integridadde los datos en sistemas de información debe:

a. Asegurar que la información de tales incidentes sea comunicadade manera oportuna de tal forma que se pueda tomar la accióncorrectiva más apropiada.

b. Asegurar una respuesta rápida, efectiva y ordenada a losincidentes reportados.

c. Permitir obtener métricas sobre la efectividad de la gestión de losincidentes reportados.

d. Incluir la recolección, mantenimiento y presentación de losregistros de incidentes con miras a ser utilizados como evidenciasen eventuales acciones legales en contra de personas uorganizaciones.

15.En relación al cumplimiento de leyes y/o regulaciones sobre laconfiabilidad y la integridad de los datos en los sistemas de informaciónutilizados por la organización, se debe:

a. Formalmente, definir, documentar y actualizar los requerimientosde confiabilidad e integridad que deben cumplir todos y cada unode los sistemas de información utilizados en la organización.

PROPUESTA



b. Definir, implementar y monitorear los procedimientos apropiadospara asegurar el cumplimiento de las leyes y/o regulaciones sobrela confiabilidad y la integridad de los datos en los sistemas deinformación.

16.El valor de la inversión para asegurar la confidencialidad y la integridadde la información, deberá ser proporcional al valor que para laorganización representa la información a ser protegida con tal inversión.

17.En relación al cumplimiento de las políticas y normas relacionadas con laconfidencialidad y la integridad de la información, se debe definir,implementar y comunicar formalmente, al interior de la organización, losprocedimientos adecuados para verificar y evaluar el cumplimiento y laefectividad de dichas políticas y normas.

18.Los requerimientos de confidencialidad e integridad de la informacióndeben ser considerados en los planes contingencia y/o recuperaciónante desastres, desarrollados la interior de la organización.

19.Debe definirse e implementarse formal y periódicamente al interior de laorganización ciclos de concientización y capacitación sobre los riesgos ypeligros que trae la no observancia o incumplimiento de las normas ypolíticas de confidencialidad e integridad de la información.

20.Se deben establecer políticas, procedimientos y controles para protegerla confidencialidad y la integridad durante el intercambio de informaciónutilizando todos los tipos de medios de comunicación, tanto al interiorcomo al exterior de la organización.

21.De manera complementaria a la norma anterior, se debe estableceracuerdos de intercambio de información con quien sea apropiado,considerando los siguientes elementos:

a. La gestión de las responsabilidades para el control y notificaciónde la transmisión, despacho y recepción.

b. Los procedimientos para notificar al remitente de la transmisión,despacho y recepción.

c. Los procedimientos para asegurar el rastreo y no-repudio.

d. Los estándares técnicos mínimos para la transmisión.

e. Los estándares de identificación del mensajero.

f. Las responsabilidades y obligaciones en el caso de incidentesque atenten contra la confidencialidad y/o la integridad de lainformación.

PROPUESTA



g. El uso de un sistema de etiquetación de la información paraidentificar claramente los niveles de confidencialidad o integridadde la misma.

h. La propiedad y responsabilidades de la protección de lainformación, los derechos de autor, las licencias de software yotras consideraciones similares.

i. Los estándares técnicos para grabar y leer la información o elsoftware.

j. Cualquier control adicional que se requiera por la naturaleza de lainformación, por ejemplo claves criptográficas o códigos deverificación.

22.En el caso de que el personal de la organización utilice dispositivosmóviles para acceder y/o manejar información de la organización. Sedebe definir, implementar y formalizar la aplicación de losprocedimientos necesarios para asegurar el buen uso de la informaciónen relación a que su confidencialidad y su integridad se mantendránintactas inclusive en caso de daño, pérdida o robo de los dispositivos.

PROPUESTA



7. Normas para la Confidencialidad de Información

1. La confidencialidad de la información debe aplicarse tanto para lainformación electrónica contenida en cualquier medio como para losdocumentos en papel, y debe cumplir con lo establecido por las políticasde la organización y/o las regulaciones aplicables.

2. La confidencialidad de la información debe abarcar la protección de lainformación propia de la organización, su operación y sus empleados;así como también de la información suministrada por clientes, usuarios uotras organizaciones.

3. La plataforma tecnológica utilizada por la organización deberáimplementar los mecanismos necesarios para garantizar el cumplimientode las políticas de confidencialidad de la organización.

4. La organización debe asegurar que todos sus empleados observen losmás altos estándares de conducta y ética profesional relacionados conel respeto y apego a las políticas establecidas de confidencialidad de laorganización.

5. La organización debe garantizar la confidencialidad de la información desus empleados, cuando haga uso de su derecho de inspeccionar el usoque sus empleados le están dando a los recursos tecnológicos, porsospechas fundadas de violaciones a normas y regulaciones, o por unasituación emergente.

6. En relación a la clasificación de la información para definir sus niveles desensibilidad y criticidad, se deberá asegurar la identificación y elposterior cumplimiento de los requerimientos de confidencialidad de lainformación.

7. La organización debe asegurar que interna y externamente se conozcaclaramente los responsables y el alcance de la divulgación y/o entregade la información generada o manejada por la organización.

8. Para el caso de la información contenida en documentos de papel, sedebe asegurar que la misma sea identificada de manera física según sunivel de confidencialidad, con el fin de evitar pérdidas, robos oexposición no adecuada.

9. La organización debe definir, implementar y comunicar formalmente a suinterior, las acciones disciplinarias o legales en las que podría incurrirpor la divulgación no adecuada, robo o pérdida de información según sunivel de confidencialidad.

PROPUESTA



10. La organización debe definir y firmar con quien aplique los acuerdos deconfidencialidad o acuerdos de no-divulgación para proteger laconfidencialidad de la información que maneja, considerando lossiguientes elementos:

a. La definición de la información a proteger.

b. La duración esperada del acuerdo.

c. Las acciones requeridas cuando se termine el acuerdo.

d. Las responsabilidades y acciones de los firmantes.

e. La propiedad de la información motivo del acuerdo.

f. El uso permitido de la información a proteger.

g. El proceso de notificación y reporte de divulgación no autorizadao incumplimiento del acuerdo.

h. Las condiciones para el retorno o destrucción de la informacióntras el término del acuerdo.

i. Las acciones a realizarse tras el incumplimiento del acuerdo.

11.La organización debe revisar periódicamente los acuerdos deconfidencialidad o acuerdos de no-divulgación, para asegurar que losmismos reflejan las necesidades actuales de la organización paraproteger la confidencialidad de la información.

12.La organización debe asegurar que su infraestructura de red estédebidamente protegida para evitar intercepciones no autorizadas de lainformación durante su transmisión.

13.Se debe definir, implementar y dar a conocer formalmente, losprocedimientos de operación necesarios para establecer una gestión demedios de almacenamiento, que evite la divulgación no autorizada,modificación, eliminación o destrucción de la información.

14.La documentación de los sistemas de información es un activo de laorganización ya que puede contener información confidencial, por lo quedebe protegerse para evitar el acceso y el uso no autorizados.

15.La confidencialidad de la información involucrada en mensajeselectrónicos debe ser asegurada considerando los siguiente aspectos:

a. Evitar el acceso no autorizado, la modificación o la negación delservicio de mensajería.

PROPUESTA



b. Asegurar la correcta dirección y transporte del mensaje.

c. Los requerimientos de aspecto legal.

d. Los niveles de seguridad de las redes o servicios públicos quesean utilizados para la transmisión de mensajes electrónicos.

16.Se debe generar una política sobre el uso de la encriptación como unaherramienta para proteger la confidencialidad de la información. Dichapolítica debe considerar:

a. La protección de la información almacenada en dispositivos y entránsito a través de una red.

b. El ámbito de acción de la encriptación en función de lasdirectrices corporativas de la organización.

c. El tipo, la fuerza y la calidad de los algoritmos de encriptaciónutilizados.

d. La gestión que se le deberá dar a las claves de encriptación.

e. Los roles y responsabilidades asociados con el uso de laencriptación.

f. La plataforma tecnológica que soportará el uso de la encriptación.

g. El impacto de la utilización de la encriptación en los sistemasinformáticos que se usan en la organización.

h. Las leyes y regulaciones nacionales e internacionales relativas ala aplicación de la encriptación.

i. La maximización de los beneficios del uso de la encriptación.

j. La minimización de los riesgos y el mal uso de la encriptación.

17.Si la organización se decide por el uso de la encriptación, se debeestablecer un sistema para la gestión adecuada de las claves deencriptación. Dicho sistema debe basarse en estándares,procedimientos y métodos seguros y acordados para:

a. Generar las claves para los varios sistemas de información queusan encriptación.

b. Generar y obtener certificados de claves públicas.

PROPUESTA



c. Distribuir las claves a los usuarios autorizados y su respectivaactivación.

d. Almacenar la claves y como los usuarios autorizados acceden alas mismas.

e. Cambiar o actualizar las claves, incluyendo la periodicidadobligatoria y el procedimiento de ejecución.

f. Proceder con las claves que han sido comprometidas.

g. Revocar y/o desactivar las claves.

h. Recuperar las claves, cuando estas han sido olvidadas, perdidaso corrompidas.

i. Archivar las claves.

j. Destruir las claves.

k. Registrar y auditar las acciones relacionadas a la gestión declaves.

18.La información almacenada en ambientes de producción de sistemas deinformación, que sean replicadas a ambientes de desarrollo, prueba opre-producción, debe ser enmascarada mediante un proceso irreversibleque garantice la confidencialidad de la información original de losambientes de producción.

19.La red de datos de la organización deberá ser asegurada para evitar eluso y la explotación de canales encubiertos por parte de códigosmaliciosos, como por ejemplo programas troyanos, lo cual puededesencadenar en una filtración de información altamente confidencial.

20. El desarrollo de software al exterior de la organización debe sersupervisado y monitoreado para asegurar que las políticas definidassobre la confiabilidad de la información, sean aplicadas adecuadamente.PROPUESTA



8. Normas para la Integridad de la Información

1. Por principio y buena práctica se debe garantizar que la informaciónpermanezca sin alteración alguna a menos que sea modificada por losusuarios autorizados. Dicha alteración deberá ser registrada paraasegurar su precisión y su confidencialidad.

2. Por principio y buena práctica se debe garantizar que la informacióncontenida en mensajes, sistemas informáticos, documentos y en otrasformas de contenido, no sea modificada ni en tránsito ni en reposo.

3. Por principio y buena práctica se deben implementar mecanismos quepermitan verificar la autenticidad de quien accede a la información, conel fin de preservar la integridad de la misma.

4. Los sistemas de información que manejan información cuya integridaddeba protegerse, deben implementar técnicas de aseguramiento de laintegridad de la información tales como:

a. Firmas digitales.

b. Códigos de verificación (Checksums).

c. Infraestructura de Clave Pública (Public Key Infraestructure)

5. Se debe definir, implementar y dar a conocer de manera formal, losprocedimientos necesarios para asegurar que la información que seutilice al interior de la organización siempre esté actualizada, esto es seutilice siempre su última versión.

6. Todo sistema de información en fases de desarrollo o mantenimiento,deberá ser analizado y diseñado con la participación conjunta de losanalistas de sistemas y de los usuarios de negocio relacionados con lafuncionalidad del sistema de información. El objetivo es que el analistaidentifique y especifique todos los requerimientos sobre la integridad dela información, y que se asegure que éstos sean considerados en laetapa de diseño.

7. Los programas fuentes de los sistemas de información deberán estardebidamente documentados y deberán denominarse de maneraestándar.

8. Todo mantenimiento realizado a sistemas de información deberá serdocumentado en los manuales y ayudas en línea correspondientes,siendo este un requisito para habilitar la puesta en producción delmantenimiento en mención.

PROPUESTA



9. Los diseños de bases de datos deben desarrollarse hasta cumplir por lomenos con la tercera forma normal, la cual garantiza la presencia dereglas de integridad entre los datos almacenados. Esto permitiráasegurar la calidad de la información almacenada en las bases de datos.

10.Para controlar de mejor manera la integridad de la información en losprocesos de la organización, se deberá definir tantos puntos de control ochequeo como necesidades de integridad se requieran.

11.Si existe la necesidad de que más de un usuario a la vez modifique lamisma información, se debe aplicar controles de concurrencia, para quela integridad de la información sea asegurada.

12.En las etapas de prueba o certificación de los sistemas de información,se debe preparar casos de prueba y conjuntos de datos de prueba quecontemplen todas, o de no ser posible la totalidad la mayoría de lasentradas correctas e incorrectas que se pudieran dar con el fin deverificar si los resultados producidos por el sistema de información sonlos esperados.

13.Las pruebas de integridad de los resultados esperados de un sistema deinformación deben ejecutarse en primer lugar con una cantidadligeramente moderada de datos, y finalmente con un volumen de datossemejante al real.

14.Para asegurar la integridad de los sistemas de información esindispensable que el ciclo de pruebas incluyan los siguientes tipos depruebas:

a. Pruebas de verificación y validación.

b. Pruebas de almacenamiento.

c. Pruebas de carga máxima.

d. Pruebas de recuperación.

e. Pruebas de tiempo de ejecución.

f. Pruebas de procedimientos.

g. Pruebas de factores humanos.

15.Los sistemas de gestión de base de datos utilizados en la organizacióndeberán tener las características técnicas necesarias para asegurar laintegridad de la información en ellos almacenada, tanto en la operaciónnormal como durante la recuperación ante un fallo sucedido.

PROPUESTA



16.El área de TI de la organización deberá definir una estrategia derespaldos y recuperación de la información, que garantice la integridadde la información cuando esta se respalda y cuando se recupera si fueranecesario.

17.Se debe llevar un registro adecuado de las versiones del software y delos sistemas de información utilizados en la organización, con el fin deasegurar que las actualizaciones de versiones no atenten contra laintegridad de la información.

18.Los usuarios de negocio deberán ser provistos de manera oportuna deuna adecuada capacitación así como de la respectiva documentacióncon el fin de que pueda hacer un buen uso de los sistemas deinformación como un apoyo a las funciones que desempeñan.

19.El hardware de servidores, de computadores, de comunicaciones (red),y otros dispositivos, que sean utilizados para la operación de laorganización debe ser sometido a mantenimientos periódicos con el finde asegurar su continuidad, así como la integridad física y de lainformación que manejan. Los mantenimientos en mención debenconsiderar los siguientes lineamientos:

a. Los intervalos de mantenimiento deben ser concordantes con lasrecomendaciones del proveedor.

b. Los mantenimientos deben ser realizados solo por personalcalificado.

c. Se deben mantener de manera formal y segura registros de:

i. Fallas sospechadas.

ii. Fallas reales.

iii. Mantenimientos preventivos.

iv. Mantenimientos correctivos.

d. El personal que realiza el mantenimiento no debe ser dejado soloen ningún momento.

20.Con el fin de evitar los riesgos de accesos no autorizados y la alteracióno destrucción total de la información, lo cual atenta contra la integridadde la misma. Cuando aplique, se debe contar con ambientes separadose independientes para desarrollo, pruebas (test), pre-producción, yproducción.

PROPUESTA



21.La organización debe asegurar que la integridad de la información no sevea afectada por la intromisión y ejecución de códigos maliciosos ovirus.

PROPUESTA



9. Referencias






Oracle Corporation. (2010). Oracle Reference Architecture - Security Release3.1. Estados Unidos: Oracle Corporation.

PROPUESTA



AnexosTal cual como se lo menciona en su definición, una norma establece lo que sedebe hacer, sin llegar a especificar el cómo se lo debe realizar.

Sin embargo con el fin de brindar información adicional sobre la aplicación delas normas aquí definidas, se presentan a continuación dos ejemplos de guíasde implementación de las principales referencias normativas utilizadas en elpresente documento.

El conocer cómo se puede implementar la ISO 27001 y COBIT, le dará al lectorun mayor entendimiento sobre lo que se debería hacer para implementar lasnormas de confidencialidad e integridad de datos incluidas en el presentedocumento, ya que éstas han sido establecidas a partir de dichas normativas.

PROPUESTA



9.1. Ejemplo de Aplicación del Estándar 27001

A continuación se indica una dirección web en la cual se podrá encontrar unartículo técnico sobre la ISO 27001 y su aplicación en las organizaciones.

La URL en mención es: http://www.redalyc.org/articulo.oa?id=84921327061

En este sitio web el lector podrá acceder a un documento en formato PDF queexpone una estrategia de implementación de la ISO 27001 en organizacionesen donde la confidencialidad e integridad de los datos podrían ser una de susprincipales preocupaciones.

PROPUESTA



9.2. Ejemplo de Aplicación del Marco COBIT

A continuación se expone una serie de diapositivas relacionadas con laimplementación de COBIT 5, sus beneficios generales, y su nuevo componentedireccionado a controlar la seguridad de la información.

Es importante mencionar que las diapositivas en mención son parte de unapresentación que se realizó en el XIX Congreso y Feria Interamericana deSeguridad de la Información el 13 de marzo del 2012 en Buenos AiresArgentina, y que estuvo a cargo de Patricia Prandini y Rodolfo Szuster, ambosprofesionales certificados como auditores en seguridad de la información.

PROPUESTA



PROPUESTA



Finalmente se indica la dirección web de la página oficial del componente deCOBIT relacionado con el Modelo de Negocio para la Seguridad de laInformación o BMIS por sus siglas en inglés.

La URL en mención es:http://www.isaca.org/Knowledge-Center/BMIS/Pages/Business-Model-for-Information-Security.aspx

En este sitio web el lector podrá acceder a información gratuita y tambiénpagada, en formatos HTML y PDF, sobre el modelo de negocio orientado a laseguridad de la información que puede ser implementado en organizaciones endonde la confidencialidad e integridad de los datos podrían ser una de susprincipales preocupaciones.PROPUESTA


Normas para Mejorar laImplementación deSistemas Integrales deInformaciónProducto 6: Normas para la Trazabilidad dela InformaciónE – Open Solutions Cía. Ltda.

04/11/2013

El presente documento contiene los aspectos de índole normativos que deberán serconsiderados en la construcción de sistemas de información en lo referente a la trazabilidad.

PROPUESTA

Normas para la trazabilidad de la información


Contenido

1. Antecedentes .............................................................................................. 22. Alcance ....................................................................................................... 43. Referencias Normativas .............................................................................. 54. Términos y Definiciones .............................................................................. 75. Marco de Referencia ................................................................................... 96. La Trazabilidad en los Sistemas de Información....................................... 117. Normas para la Trazabilidad en Sistemas de Información ........................ 12

7.1. Según la perspectiva de Seguridad..................................................... 127.2. Según la perspectiva del Ciclo de Vida ............................................... 19


9.1. Referencias para la Aplicación de la Auditoría a Nivel de Bases deDatos22

PROPUESTA



1. Antecedentes







PROPUESTA




PROPUESTA



2. Alcance





de información. La seguridad de los datos en los sistemas de información, la cual tiene


La disponibilidad de los sistemas de información como fuente de losdatos requeridos.

En función de lo expuesto, y en relación al alcance del presente documento, elmismo tiene la finalidad de dejar constancia escrita de las normas detrazabilidad (auditoría) que un sistema de información debería cumplir conmiras a soportar la posterior obtención de registros administrativos.

En lo referente a la trazabilidad de los datos, las normas propuestas aportarána la seguridad, al cumplimiento, y a la fiabilidad de los registros administrativosque se pudieran obtener posteriormente.

Finalmente es importante recalcar que al normar la trazabilidad en un sistemade información, desde el punto de vista de la seguridad de la información, seestá generando el sustento necesario sobre el cual la institución podráimplementar mecanismos de auditoría sobre los hecho con los datos que sonproporcionados por un sistema de información.

PROPUESTA






Este estándar especifica los requisitos para establecer, implementar,operar, supervisar, revisar, mantener y mejorar un Sistema de Gestiónde Seguridad de la Información debidamente documentado. Del cualresaltan para el presente trabajo las recomendaciones para trazabilidaden sistemas de información.



Este estándar establece directrices y principios generales para iniciar,implementar, mantener y mejorar la gestión de seguridad de lainformación en una organización. Del cual resaltan para el presentetrabajo las recomendaciones para trazabilidad en sistemas deinformación.



Este marco de gobierno establece procesos y controles para minimizarel riesgo y maximizar los beneficios de la aplicación de la tecnología enuna organización. En relación a la trazabilidad, este marco estableceuna serie de controles de aplicación que deben ser considerados en laconstrucción de sistemas de información.

PROPUESTA



ISO/IEC 15489-1:2001, Información y documentación – Gestión dedocumentos

Este estándar establece directrices y principios generales para la gestiónde documentos en una organización, de tal forma que la evidencia y lainformación que contienen puedan ser recuperadas más eficiente yeficazmente usando prácticas y procedimientos normalizados. Del cualresaltan para el presente trabajo las recomendaciones para la gestión dela información que se obtenga de aplicar las normas de trazabilidad.

Es importante mencionar que para criterio del autor, las referencias normativasaquí citadas son las más apropiadas para la generación de normas para latrazabilidad en sistemas de información.

Finalmente es necesario indicar que las versiones de las referenciasnormativas aquí citadas, son las vigentes en relación a la generación denormas para la trazabilidad en sistemas de información, al momento de laentrega del presente documento.

PROPUESTA





Activo Tecnológico Elementos de información, hardware y software que sonpropiedad de una organización y que son utilizados pararealizar las actividades de negocio.

Audit Log Registro o bitácora de auditoría, el cual se obtiene comoimplementación del concepto de trazabilidad en lossistemas de información.

Amenaza Una causa potencial de un incidente no-deseado, el cualpuede resultar en daño a un sistema u organización.


Criticidad El grado de importancia que tiene un recurso para laorganización.


Hacking Búsqueda y explotación de vulnerabilidades en un sistemade información.

Impacto Los resultados y consecuencias de que un riesgo sematerialice.

Insider Persona que pertenece o labora en una organización yque tiene conocimiento de información importante paradicha organización.



Objeto de Base deDatos

Estructura de datos que permite manejar la información alinterior de una base de datos, como por ejemplo tablas,vistas, índices, etc.

Objeto de Negocio Estructura de datos que representa una entidad utilizada oreferenciada en los procesos de una organización. Su

PROPUESTA



significado tiene mayor sentido para los usuarios denegocio.

Pistas de Auditoría Conjunto de transacciones que reflejan los cambioshechos a una base de datos.


Riesgo Es la probabilidad de explotar una vulnerabilidad quepuede generar impactos negativos para la operación de laorganización.

Sensibilidad Es el grado de impacto en la organización si se da unadivulgación no autorizada.

Trazabilidad Conjunto de procedimientos que permiten conocer elhistórico, la ubicación y la trayectoria de un elemento a lolargo de una serie de fases y procesos.


Vulnerabilidad Es la debilidad de un sistema de información que puedeser explotada por una o más amenazas.

PROPUESTA















PROPUESTA







En lo referente a las normas incluidas en el presente documento, las mismasserán presentadas en base a algunas de las perspectivas de aplicación delconcepto de trazabilidad en relación a los sistemas de información.

Con todo esto se pretende que los registros administrativos que se puedanobtener de los sistemas de información cumplan con los requerimientos detrazabilidad.

PROPUESTA



6. La Trazabilidad en los Sistemas de Información

Tal cual como se indica en la sección 4 del presente documento, la trazabilidadse define como el conjunto de procedimientos que permiten conocer elhistórico, la ubicación y la trayectoria de un elemento a lo largo de una serie defases y procesos.

La aplicación de este concepto en sistemas de información puede ser vistadesde las siguientes perspectivas:

La perspectiva de la seguridad, en donde la trazabilidad se la plasma através del concepto de auditoría, implementando un registro deactividades o transacciones que han ocurrido en un sistema deinformación.

Esta perspectiva es la de mayor difusión y uso, y es la razón de ser delpresente documento.

La perspectiva del ciclo de vida, en donde la trazabilidad implica hacerun seguimiento del ciclo de vida de la información en los activostecnológicos que la contienen y la procesan.

Esta perspectiva es relativamente nueva, pero por ser consideradaimportante, a criterio del autor, y como valor agregado de la consultoría,será también tratada de manera breve en el presente documento.

La perspectiva del análisis de la información, en donde la trazabilidadtiene que ver con el seguimiento en la procedencia y en elprocesamiento de la información que es recolectada y almacenada confines de soportar las soluciones de inteligencia de negocio.

Esta perspectiva no será considerada en el presente documento ya quesu cubrimiento demanda un alcance diferente al de la presenteconsultoría.

La perspectiva de procesos, en donde la trazabilidad consiste en realizarun seguimiento de como la información es gestionada a lo largo de lasactividades y tareas que comprenden los procesos de una organización.

Esta perspectiva no será considerada en el presente documento ya quesu cubrimiento demanda un alcance diferente al de la presenteconsultoría.

PROPUESTA



7. Normas para la Trazabilidad en Sistemas deInformación

7.1. Según la perspectiva de Seguridad

1. Desde la perspectiva de seguridad la trazabilidad en sistemas deinformación deberá proveer un registro de auditoría (audit log) con lasactividades o transacciones que han ocurrido al interior del sistema.Dicho registro debería ser utilizado para:

a. Entender los pasos involucrados en una transacción.

b. Cuantificar las actividades que se están dando en un sistema deinformación.

c. Identificar patrones de actividad.

d. Identificar comportamientos sospechosos o erróneos.

e. Intentar determinar si una acción específica ocurrió o no.

f. Implementar una trazabilidad de los elementos y recursosinvolucrados en la operación de un sistema de información.

g. Generar tableros de control con gráficas sobre el uso o laactividad en el tiempo de un sistema de información y/o suscomponentes.

2. Por principio y buena práctica, todo sistema de información deberácontar con opciones de auditoría las cuales deberán poder ser activadasy configuradas en función de las necesidades de aseguramiento de lainformación.

3. Previa a la activación de las opciones de auditoría en un sistema deinformación, se deberá realizar un análisis de cómo esta activaciónafectará al actual rendimiento del sistema de información.

4. Los registros de auditoría que se generen deberán incluir actividades,excepciones y eventos relacionados con la seguridad de la información,y podrán durante un periodo acordado servir de apoyo a investigacionesy a un monitoreo del control de acceso.

5. Los mecanismos de auditoría que se implementen en un sistema deinformación deberían contar con la opción de detectar ataques deseguridad como por ejemplo:

PROPUESTA



a. Ataques de fuerza bruta.

b. Hacking de contraseñas.

c. Actividades inapropiadas perpetradas por insiders.

6. Los mecanismos de auditoría que se destinen a una trazabilidad de lasactividades realizadas por los usuarios de un sistema de información,deberían capturar, cuando aplique, datos tales como:

a. La identidad del usuario;

b. La ubicación del usuario (de ser posible);

c. El tipo de actividad realizada;

d. La fecha y hora de la actividad realizada;

e. Información de eventos principales como por ejemplo ingresos ysalidas;

f. Los recursos o elementos afectados por la actividad realizada;

g. Los parámetros claves o principales de la actividad realizada;

h. Cambios en las configuraciones de sistemas;

i. El uso de privilegios concedidos;

j. El uso de utilidades y aplicaciones del sistema;

k. Registros de intentos de acceso fallidos y rechazados al sistema;

l. Registros de intentos de acceso fallidos y rechazados a lainformación y/o a otros recursos;

m. Los repositorios, como por ejemplo archivos, a los cuales se tuvoacceso y los tipos de acceso;

n. Las direcciones y los protocoles de red utilizados;

o. Las alarmas activadas por el sistema de control de acceso;

p. La activación y desactivación de los sistemas de protección, comoantivirus, IDS’s1, o IPS’s2.

1 IDSSistema de Detección de Intrusiones2 IPS Sistema de Prevención de Intrusiones

PROPUESTA



7. La información generada con fines de auditoría o trazabilidad seconsidera altamente sensible por lo que debe protegerse de accesos noautorizados o de una eventual alteración o destrucción. Para este fin sepueden utilizar mecanismos tales como encriptación, firmas digitales, oenforzamiento de la transmisión, entre otros.

8. Se debe definir, implementar y comunicar formalmente, losprocedimientos necesarios para el monitoreo del uso y de lasactividades realizadas en los sistemas de información.

9. Se debe definir, implementar y comunicar formalmente, losprocedimientos necesarios para la revisión y el procesamiento,periódicos, de la información contenida en los registros de auditoría. Losaspectos a considerar son los siguientes:

a. El grado crítico de los procesos de aplicación;

b. El valor, la sensibilidad y la criticidad de la informacióninvolucrada;

c. Los antecedentes de infiltración y mal uso del sistema, y lafrecuencia con la que se explotan las vulnerabilidades;

d. La extensión de la interconexión del sistema (sobre todo las redespúblicas);

e. La desactivación del medio de registro.

10.Los relojes de todos los sistemas de información que contienenmecanismos de auditoría deben estar sincronizados con una fuente detiempo que proporcione la hora exacta acordada.

11.Se debe definir, implementar y comunicar formalmente, losprocedimientos necesarios para el mantenimiento de la informacióncontenida en los registros de auditoría.

12.Con el fin de establecer el nivel requerido de auditoría o monitoreo paralos sistemas de información y/o sus componentes, se debe realizar:

a. Una evaluación de riesgos;

b. La identificación de las disposiciones regulatorias que se debencumplir.

PROPUESTA



13.Para sistemas de información en los que se maneja información sensibley un elevado número de transacciones, debe ser factible correlacionarmúltiples transacciones de tal forma de poder realizar análisis de todaslas transacciones generadas por un mismo usuario o por unrequerimiento original.

14.La auditoría de un sistema de información debe incluir las accionesrealizadas por usuarios privilegiados, tales como administradores,analistas, desarrolladores y arquitectos, a lo largo de todas las capas yde todos los componentes del sistema de información.

15.Si es necesario monitorear de manera reactiva la actividad de unsistema de información, con el fin de detectar actividades sospechosasque eventualmente podrían convertirse en un problema de seguridad, sedebe implementar un sistema de detección de intrusiones o IDS por sussiglas en inglés, con el cual se podrá detectar:

a. Ataques desde la red a servicios vulnerables.

b. Ataques por explotación de vulnerabilidades de las aplicaciones.

c. Escalamiento de privilegios, a través de la explotación devulnerabilidades a nivel del sistema operativo.

d. Accesos o intentos de acceso no autorizados a sistemas deinformación.

e. Accesos o intentos de acceso a repositorios de informaciónconfidencial.

16.Si es necesario monitorear de manera proactiva la actividad de unsistema de información, con el fin de evitar problemas de seguridad, sedebe implementar un sistema de prevención de intrusiones o IPS porsus siglas en inglés.

17.Por ser considerados componentes de los sistemas de información,cuando aplique y sea necesario, se deberá activar y configurar lageneración de logs a nivel de bases de datos, servidores deaplicaciones, componentes de capa media, y sistema operativo de losservidores en donde residan los elementos anteriormente mencionados.

18.Se deberá activar la generación de registros de auditoría para lasactividades de los administradores y operadores de bases de datos.

19.Según la criticidad y la sensibilidad de la información almacenada enuna base de datos, se deberá configurar la generación de bitácoras ologs que permitan tener pistas sobre las acciones realizadas sobre losobjetos de la base de datos.

PROPUESTA



20.Se debe configurar la generación de logs de auditoria para que sealmacene solo la información relevante y la que realmente será motivode una revisión periódica.

21.A nivel de bases de datos, la trazabilidad configurada mediante laactivación de opciones de auditoría debe permitir determinar:

a. Quién accedió a los datos.

b. Cuándo se accedió a los datos.

c. Desde qué tipo de dispositivo/aplicación.

d. Desde que ubicación en la red.

e. Cuál fue la sentencia SQL ejecutada.

f. Cuál fue el efecto del acceso a la base de datos

g. Las conexiones a la base de datos.

h. Las modificaciones al diseño de los datos.

i. Las modificaciones a los datos como tal.

22.Los mecanismos de trazabilidad deberán complementarse con lageneración de alertas que permitan:

a. Mitigar los riesgos asociados con el manejo inadecuado de losdatos.

b. Apoyar el cumplimiento regulatorio.

c. Satisfacer los requerimientos de los auditores.

d. Evitar acciones criminales.

e. Evitar multas por incumplimiento.

23.Del análisis periódico de la información recolectada por los mecanismosde auditoria o trazabilidad, se deberán definir planes de acción, siaplicase, para cubrir temas tales como:

a. El control de acceso a toda la información de índole financiero dela organización residente en bases de datos.

b. Demostrar la integridad de la información almacenada en lasbases de datos.

PROPUESTA



c. La mitigación de los riesgos asociados a la pérdida de datos y a lafuga de información.

d. La responsabilidad que la organización adquiere al manejarinformación confidencial de sus clientes.

e. Los datos que son convertidos en información a través deprocesos de bases de datos y/o procesos de negocio.

f. La extensión de las medidas de seguridad por parte de laorganización, para que consideren aspectos complementarios alsolo aseguramiento de los datos.

g. La disponibilidad de la información de modo rápido y seguro.

h. El posicionamiento de la compañía frente a los entes regulatoriosy a la competencia.

i. Un mayor nivel de satisfacción y confianza de parte de clientes,proveedores y socios de negocio.

24.El diseño e implementación de mecanismos de auditoria y/o trazabilidaddeberá considerar:

a. La definición de las estructuras físicas y lógicas de las bases dedatos.

b. El control de la carga y el mantenimiento de las bases de datos.

c. La integridad de los datos y la protección de los accesos a losmismos.

d. Los niveles definidos de sensibilidad y de criticidad de los datos.

e. Los estándares para análisis y programación en el uso de basesde datos.

f. Los procedimientos de respaldo y de recuperación de datosdefinidos.

25.Para el caso de sistemas de información que manejen datos con nivelesextremos de sensibilidad y criticidad, se debe analizar la posibilidad deimplementar el concepto de eliminaciones lógicas, el mismo queconsiste en que nunca se eliminen registros físicos de la base de datos,sino que únicamente se les cambie el estado, de tal forma que para elusuario de negocio estos registros ya no existan pero físicamenteseguirán en la base de datos.

PROPUESTA



26.Por principio y buena práctica, la activación de las opciones de auditoríao trazabilidad en un sistema de información no puede afectar eldesempeño o disponibilidad del sistema de información.

PROPUESTA



7.2. Según la perspectiva del Ciclo de Vida

1. Por principio y buena práctica, el manejo de información a través demedios tecnológicos debe asegurar, que de ser requerido, se contarácon los mecanismos necesarios para realizar un seguimiento y posterioranálisis de cómo los datos han sido gestionados, es decir, desde sucaptura o generación, durante su procesamiento, y hasta sualmacenamiento o su posible destrucción.

2. Se deben definir, implementar y comunicar formalmente losprocedimientos necesarios, sobre el movimiento de los activos detecnología con los que se gestiona la información relacionada con laorganización. Dichos procedimientos deben permitir:

a. Realizar un análisis de los riesgos que implican tales movimientosde activos.

b. Garantizar que los activos podrán localizarse siempre que seanecesario.

3. El análisis de riesgos que debe ser ejecutado antes del movimiento delos activos de tecnología debe considerar:

a. El impacto del movimiento a las aplicaciones y a los procesos dela organización.

b. La seguridad de la información relacionada.

c. La seguridad del activo o de los activos involucrados.

d. Los aspectos logísticos de los traslados.

4. Se deben definir, implementar y comunicar formalmente los mecanismosde seguimiento para registrar:

a. Los códigos de identificación de los activos de tecnología.

b. La ubicación de los activos de tecnología.

c. El funcionario o área responsable por los activos de tecnología.

d. La justificación de su traslado por cambio de ubicación y/o porcambio de responsable.

PROPUESTA



5. Los incidentes que se dieran durante el ciclo de vida de la informaciónque es manejada a través de activos de tecnología, deben gestionarseconsiderando los mecanismos necesarios para garantizar el seguimientode tal gestión con miras a la ejecución de posteriores análisis sobrecantidad, eficiencia, y criticidad, entre otros.

PROPUESTA



8. Referencias




ISO. (2001). ISO 15489-1:2001(E) Information and documentation - Recordsmanagement - Part1:General. Geneva, Suiza: ISO.



Oracle Corporation. (2010). Oracle Reference Architecture - Security Release3.1. Estados Unidos: Oracle Corporation.

PROPUESTA



9. Anexos

9.1. Referencias para la Aplicación de la Auditoría a Nivel deBases de Datos

A continuación se indica una dirección web a través de la cual se podráacceder al capítulo de introducción a la auditoría de bases de datos, de la guíade seguridad de la base de datos Oracle.

La URL en mención es:

http://docs.oracle.com/cd/E16655_01/network.121/e17607/auditing.htm#BCGIDBFI

En este sitio el lector podrá encontrar aspectos conceptuales, buenas prácticas,beneficios y recomendaciones, de uno de los principales proveedores de basesde datos a nivel mundial, lo cual podría ser tomado como una referencia válidaal momento de aplicar la auditoría a nivel de bases de datos.

PROPUESTA



Finalmente, se indica una dirección web a través de la cual se podrá acceder auna valoración sobre el nivel de seguridad que se tiene al interior de unaorganización, en relación a la información.


http://www.oracle.com/us/media/survey/index-191234.html

En este sitio el lector podrá responder una serie de preguntas que al final lepermitirá conocer el grado de validez de las estrategias de seguridad de lainformación que actualmente existen en la organización, según las buenasprácticas y estándares internacionales.PROPUESTA

El presente documento contiene los aspectos de índole normativos que deberán serconsiderados en la construcción de sistemas de información en lo referente a sudisponibilidad.


Normas para Mejorar laImplementación deSistemas Integrales deInformaciónProducto 7: Normas para la Disponibilidadde Sistemas de InformaciónE – Open Solutions Cía. Ltda.

29/11/2013PROPUESTA

Normas para la disponibilidad de sistemas de información


Contenido

1. Antecedentes .............................................................................................. 22. Alcance ....................................................................................................... 43. Referencias Normativas .............................................................................. 54. Términos y Definiciones .............................................................................. 65. Marco de Referencia ................................................................................... 86. La Disponibilidad de los Sistemas de Información .................................... 107. Normas para la Disponibilidad de Sistemas de Información ..................... 11

7.1. Según la perspectiva de la Continuidad del Servicio .......................... 117.2. Según la perspectiva de la Reducción de la No Disponibilidad........... 147.3. Según la perspectiva de la Tolerancia a Fallos ................................... 177.4. Según la perspectiva de la Recuperación ante Desastres .................. 19


9.1. Ejemplo de Plan de Recuperación Ante Desastres............................. 22

PROPUESTA



1. Antecedentes







PROPUESTA




PROPUESTA



2. Alcance





de información. La seguridad de los datos en los sistemas de información, la cual tiene


La disponibilidad de los sistemas de información como fuente de losdatos requeridos.

En función de lo expuesto, y en relación al alcance del presente documento, elmismo tiene la finalidad de dejar constancia escrita de las normas dedisponibilidad que un sistema de información debería cumplir con miras asoportar la posterior obtención de registros administrativos.

En lo referente a la disponibilidad de los datos, las normas propuestasaportarán a la efectividad, a la fiabilidad, y a la accesibilidad de los registrosadministrativos que se pudieran obtener posteriormente.

PROPUESTA





COBIT 5:2012, Marco de Gobernabilidad

Este marco de gobierno establece procesos y controles para minimizarel riesgo y maximizar los beneficios de la aplicación de la tecnología enuna organización. En relación a la disponibilidad, este marco estableceuna serie de lineamientos y recomendaciones que deben serconsiderados en la construcción de sistemas de información.

ITIL V3, Estándar de Gestión de TI

Este estándar define un conjunto de buenas prácticas que se puedenaplicar para lograr una adecuada gestión y provisión de los servicios deTI. Su objetivo principal es mejorar la calidad de los servicios de TI quese ofertan minimizando al máximo los problemas asociados con talactividad.

ISO/IEC 24762:2008, Tecnología de Información – Técnicas deSeguridad – Lineamientos para la recuperación ante desastres deservicios de tecnología y comunicaciones.

Este estándar especifica los aspectos que una organización debe teneren cuenta para asegurar la recuperación ante desastres de servicios detecnología y comunicaciones que son proveídos internamente o porterceros.


Este marco de gobierno establece procesos y controles para minimizarel riesgo y maximizar los beneficios de la aplicación de la tecnología enuna organización. En relación a la disponibilidad, este marco estableceuna serie de controles de aplicación que deben ser considerados en laconstrucción de sistemas de información.

Es importante mencionar que para criterio del autor, las referencias normativasaquí citadas son las más apropiadas para la generación de normas para ladisponibilidad de sistemas de información.

Finalmente es necesario indicar que las versiones de las referenciasnormativas aquí citadas, son las vigentes en relación a la generación denormas sobre la disponibilidad para sistemas de información, al momento de laentrega del presente documento.

PROPUESTA





Activo Tecnológico Elementos de información, hardware y software que sonpropiedad de una organización y que son utilizados pararealizar las actividades de negocio.

Cluster Grupo de computadores (mínimo dos), que se encuentranconectados y trabajan juntos para aprovechar sucapacidad de procesamiento en conjunto, de maneratransparente para las aplicaciones y los usuarios denegocio.


Disponibilidad Propiedad de un sistema de información gracias a la cualsus usuarios pueden acceder y hacer uso del mismo.

Failover Traslado de la operación de un componente tecnológicode un ambiente primario o de producción a un ambientesecundario o en standby, tras la ocurrencia de un eventode fallo que afecta la disponibilidad del ambiente primario.


Incidente Suceso que introduce una condición de fallo que afecta ladisponibilidad de un componente tecnológico.



PROPUESTA



Standby Componente tecnológico que se encuentra en un estadopasivo, y que ha sido configurado para entrar en actividadtras la ocurrencia de un evento de fallo en un componentetecnológico de funciones similares.


PROPUESTA















PROPUESTA







En lo referente a las normas incluidas en el presente documento, las mismasserán presentadas en base a algunas de las perspectivas de aplicación delconcepto de disponibilidad en relación a los sistemas de información.

Con todo esto se pretende que los registros administrativos que se puedanobtener de los sistemas de información estén disponibles cuando seanrequeridos.

PROPUESTA



6. La Disponibilidad de los Sistemas de Información

La aplicación del concepto de disponibilidad en sistemas de información debeser abordada desde las siguientes perspectivas:

La perspectiva de la continuidad del servicio, según la cual un sistemade información continuará disponible y brindando su servicio a losusuarios de negocio, a pesar de que ocurra un evento de interrupción,como por ejemplo el daño de alguno de los componentes de hardwarede los servidores.

La perspectiva de la reducción de la no disponibilidad, según la cual lasposibles causas planeadas y no planeadas de no disponibilidad de unsistema de información deben ser identificadas y reducidas al máximo.

La perspectiva de la tolerancia a fallos (failover), según la cual cuandolos componentes de un sistema de información sufren una fallairreparable, los servicios que son provistos por tales componentes setrasladan manual o automáticamente a otros componentes que seencuentran en standby.

La perspectiva de la recuperación ante desastres, según la cual sedebería contar con planes de recuperación de la disponibilidad de lossistemas de información, ante un desastre mayor causado por lanaturaleza o humanos.

PROPUESTA



7. Normas para la Disponibilidad de Sistemas deInformación

7.1. Según la perspectiva de la Continuidad del Servicio

1. Se deben definir, implementar y comunicar formalmente las políticas yprocedimientos relacionados con el mantenimiento de la disponibilidadde los servicios que son entregados por los sistemas de información,considerando los siguiente aspectos:

a. La entrega del servicio a través de sistemas de información enlínea con los requerimientos de la organización.

b. La optima utilización de los activos tecnológicos, los recursos ylas capacidades asociados a los sistemas de información.

c. La entrega de información confiable y de valor, por parte de lossistemas informáticos, para la toma de decisiones al interior de laorganización.

d. La provisión del servicio de una manera efectiva en relación a lainversión hecha por la organización.

2. El personal del área de TI de la organización, que tiene laresponsabilidad de asegurar la continuidad de los servicios prestadospor los sistemas de información, deberá contar con las capacidadesnecesarias para cumplir con sus funciones, por lo que periódicamente sedeberá realizar una valoración de dichas capacidades, con el fin dedetectar brechas que deberán ser cubiertas a través de planes deformación y capacitación.

3. Las necesidades actuales de disponibilidad, rendimiento y capacidad delos sistemas de información, no permanecerán constantes en el tiempo,por lo que deberán ser validadas y ajustadas periódicamente en base alos requerimientos de la organización. Adicionalmente se deberálevantar la información necesaria para identificar y considerar lasnecesidades futuras.

4. Definir, implementar y comunicar formalmente los acuerdos de nivel deservicio que sean necesarios para asegurar a los usuarios de negocio lacontinuidad de los servicios prestados por los sistemas de información.Estos acuerdos de niveles de servicio deberán ser monitoreadosperiódicamente para verificar se cumplimiento.

PROPUESTA



5. El rendimiento y la capacidad de los sistemas de información deben sermonitoreados, en lo posible a través de un software, para asegurar quelos mismos se mantienen dentro de los límites adecuados, generandolas respectivas alertas cuando dichos límites estén por cumplirse ytambién cuando se hayan cumplido.

6. Todos los incidentes que afecten la continuidad de los serviciosproporcionados por los sistemas de información de una organización,deberán ser identificados, gestionados, cerrados y cuantificados, con elfin de conocer su impacto y con miras a establecer mejoras.

7. El impacto sobre el negocio, de la no continuidad de los serviciosprestados por parte de los sistemas de información, debe ser valoradaconsiderando los siguientes aspectos:

a. La identificación de las soluciones o servicios que soportan losprocesos de negocio críticos para la organización.

b. La identificación de la infraestructura de TI que soporta lassoluciones o servicios críticos.

c. El total conocimiento y la formal aceptación de parte de losusuarios de negocio del impacto de la no disponibilidad de lassoluciones o servicios críticos.

d. El cumplimiento de los acuerdos de nivel de servicio sobre lacontinuidad de las soluciones o servicios críticos.

8. Las necesidades de la organización también evolucionarán o cambiarána lo largo del tiempo, por lo que se debe identificar y preveer el impactoque esto tendrá o deberá tener sobre los requerimientos de continuidadde los servicios provistos por los sistemas de información, en relación adisponibilidad, rendimiento y capacidad. Se deberá tener enconsideración:

a. La utilización de técnicas de modelaje para validar disponibilidad,planes de rendimiento y planes de capacidad.

b. La definición de planes de rendimiento y planes de capacidad enbase a las necesidades de mejora identificadas.

c. El ajuste de planes de rendimiento, planes de capacidad yacuerdos de nivel de servicio, en base a las demandas futurasdebidamente justificadas, así también como en base a revisionesdel rendimiento y capacidad actuales.

PROPUESTA



9. Se debe monitorear, medir, analizar, reportar y revisar la disponibilidad,el rendimiento y la capacidad de los sistemas de información. Todo estocon los siguientes fines:

a. Establecer líneas base e identificar desviaciones a partir de lasmismas.

b. Generar reportes de análisis de tendencias para identificarnovedades y variaciones significativas.

c. Definir las acciones correctivas necesarias y asegurarse de sudebida ejecución.

d. Generar reportes de capacidad que servirán con fines estimativosen los procesos de presupuestación de la organización.

10.Para el caso de necesitar o contar con el soporte de proveedoresexternos para mantener la continuidad de los servicios proveídos por lossistemas de información de la organización, se debe definir losprocedimientos de interacción, los respectivos acuerdos de niveles deservicios, y los procedimientos de escalamiento, en caso de problemasemergentes de disponibilidad, rendimiento y capacidad.

11.Se debe establecer el conjunto de métricas gerenciales que seránperiódicamente reportadas, en relación a la continuidad del servicio delos sistemas de información, considerando:

a. El número de interrupciones del servicio que han causadoincidentes significativos.

b. El costo para la organización de los incidentes significativos.

c. El número de horas laborables perdidas por interrupciones noplanificadas del servicio.

d. Porcentaje de cumplimiento de los niveles de servicio acordados.PROPUESTA



7.2. Según la perspectiva de la Reducción de la NoDisponibilidad

1. Se debe realizar un análisis para identificar las posibles causas deinterrupciones no planeadas que pudieran afectar la disponibilidad de lossistemas de información de una organización. Las causas identificadasdeben ser debidamente clasificadas con el fin de guiar el diseño desoluciones de alta disponibilidad que abarquen la mayor cantidad dedichas causas.

2. El diseño de soluciones de alta disponibilidad que estén orientadas acontrarrestar el impacto de interrupciones no planeadas en ladisponibilidad de los sistemas de información, debe considerar lossiguientes aspectos:

a. Las políticas y los lineamientos de alta disponibilidad definidos porel área de TI de la organización.

b. La aplicación del concepto de redundancia de componentes entodas y cada una de las capas de la arquitectura de los sistemasde información, con el fin de lograr la eliminación de puntos defallo únicos. Esto es, se debe buscar redundancia en:

i. Instalaciones Eléctricas

ii. Hardware de Servidores

iii. Hardware de Almacenamiento

iv. Hardware de Comunicaciones

v. Software de Sistema Operativo

vi. Software de Servidores de Bases de Datos

vii. Software de Servidores de Aplicaciones

viii. Software de Servidores Web

ix. Software de Capa Media / Integración

x. Software de Replicación / Extracción – Transformación –Carga

c. La implementación de clusters de componentes para lograr nosolo la alta disponibilidad de tales componentes sino también elbalanceo de la carga de trabajo que se direcciona a dichoscomponentes.

PROPUESTA



d. La definición, implementación y formalización de estrategias derespaldo y recuperación que consideren las particularidades detodos y cada uno de los sistemas de información de laorganización.

e. Los niveles de disponibilidad y de soporte técnico del Hardwareofertado por los diferentes proveedores, los cuales deberán iracorde a la criticidad de los sistemas de información que sedesea proteger.

f. La identificación y especificación de los requerimientos de altadisponibilidad para el caso del desarrollo de nuevos sistemas deinformación, o de la modificación de los existentes.

3. Se deben definir las razones por las cuales la disponibilidad de lossistemas de información de una organización se verá interrumpida demanera planificada, con el fin de diseñar estrategias que minimicen almáximo el tiempo de indisponibilidad de los componentes afectados delos sistemas de información.

4. El diseño de estrategias encaminadas a minimizar el tiempo deindisponibilidad de los sistemas de información por razonesdebidamente planeadas, debe considerar los siguientes aspectos:

a. Las políticas y los lineamientos sobre indisponibilidad definidospor el área de TI de la organización.

b. La utilización de un servidor alterno para la obtención derespaldos, cuando ésta operación ejecutada en el ambiente deproducción de un sistema de información crítico, podría afectar sudisponibilidad.

c. El monitoreo y el control granular del uso de recursos dememoria, procesador y disco para sistemas de información quepresentan problemas de desempeño.

d. La utilización de un servidor complementario para recolectar yanalizar las pistas de auditoría generadas por sistemas deinformación críticos, altamente transaccionales y que podríanpresentar problemas de desempeño.

e. La utilización de un servidor complementario para la ejecución deprocesos batch asociados con sistemas informáticos críticos,altamente transaccionales y que podrían presentar problemas dedesempeño.

PROPUESTA



f. La reducción al mínimo, e inclusive a cero, de la indisponibilidadde un sistema de información a través de la realizaciónprogresiva, en ambientes de alta disponibilidad, de tareasrelacionadas con:

i. Actualizaciones de Hardware

ii. Actualizaciones de Sistema Operativo

iii. Actualizaciones de Bases de Datos

iv. Actualizaciones de Servidores de Aplicaciones

v. Actualizaciones de Capa Media

vi. Aplicación de Parches

vii. Mantenimiento de Hardware

viii. Cambios en configuración, que sean susceptibles deejecutarse de manera progresiva.

5. No todos los sistemas de información pueden beneficiarse de unaestrategia de alta disponibilidad, por lo que antes de diseñar unasolución de alta disponibilidad se deberá validar si los sistemas deinformación involucrados son aptos tal cual como se encuentranimplementados o y si es necesario y vale la pena realizar tareasadicionales.

6. Para el caso de sistemas de información que de manera parcial o totalse encuentren operando fuera de las instalaciones de la organizaciónbajo la gestión de terceros, se debe validar el grado de cumplimiento departe del proveedor de las normas previamente indicadas.

PROPUESTA



7.3. Según la perspectiva de la Tolerancia a Fallos

1. Para sistemas de información críticos, cuyo ambiente de producción enel cual se ejecutan, se ve comprometido por una falla permanente, sedebe garantizar la existencia de un ambiente secundario o en standby, elcual deberá entrar en funcionamiento para asegurar la disponibilidad dedichos sistemas de información.

2. Tras el evento de fallo permanente, el traslado de la operación delsistema de información, entre el ambiente primario o de producción, y elambiente secundario o en standby, puede darse de manera manual o demanera automática, dependiendo de:

a. La tecnología con la cual se implementó la solución de failover.

b. La factibilidad de que todos los componentes del sistema deinformación puedan funcionar con un failover automático.

c. Las políticas y lineamientos del área de TI de la organización.

d. Los requerimientos de negocio que influyen en la criticidad delsistema de información.

3. El ambiente de operación secundario o en standby, deberá contenertodos los componentes necesarios de la arquitectura del sistema deinformación a fin de que se pueda asegurar la disponibilidad de ésteúltimo.

4. El ambiente de operación secundario o en standby, deberá serconfigurado adecuadamente y deberá contener componentes con lascaracterísticas necesarias, para garantizar niveles aceptables dedisponibilidad del sistema de información, en relación a su desempeño ysu capacidad.

5. Para diseñar una solución de tolerancia a fallos o failover, para unsistema de información, se deberá considerar los siguientes aspectos:

a. No deberán existir puntos únicos de fallo.

b. Se debe contar con la capacidad para aislar el fallo alcomponente o componentes afectados.

c. Se debe contar con los mecanismos necesarios para evitar que elfallo y sus consecuencias se propaguen a otros componentes noafectados inicialmente.

PROPUESTA



d. Una vez que el sistema de información opera en el ambientesecundario, éste último pasa a ser el nuevo ambiente deproducción, y el ambiente de producción anterior pasa a ser elnuevo ambiente secundario.

Por este motivo, se debe contar con los mecanismos necesariospara reversar esta situación a su estado original, luego de que elambiente donde se presentó la falla esté nuevamente disponible.

6. Una solución de tolerancia a fallos, debe ser capaz de ser utilizada comouna alternativa para reducir al mínimo, e inclusive a cero, laindisponibilidad de un sistema de información, al someterlo a tareasrelacionadas con:

a. Actualizaciones de Hardware

b. Actualizaciones de Sistema Operativo

c. Actualizaciones de Bases de Datos

d. Actualizaciones de Servidores de Aplicaciones

e. Actualizaciones de Capa Media

f. Aplicación de Parches

g. Mantenimiento de Hardware

h. Cambios en configuración, que sean susceptibles de ejecutarsede manera progresiva

PROPUESTA



7.4. Según la perspectiva de la Recuperación ante Desastres

1. Toda organización debe contar con un plan de recuperación antedesastres o DRP1 (por sus siglas en inglés), el cual deberá contener laspolíticas y procedimientos que permitirán proteger y restaurar lainfraestructura de TI que la organización considere vital para sufuncionamiento y vuelta a operación tras la ocurrencia de un eventocatastrófico.

2. La definición del plan de recuperación ante desastres deberá considerarlos siguientes aspectos:

a. Deberá elaborarse siguiendo una metodología apropiada yprobada para la vertical de la industria a la cual pertenece laorganización.

b. Debe contar con el total apoyo y compromiso por parte de losaltos directivos de la organización.

c. Al ser parte del plan de continuidad del negocio, debe basarse enéste último para obtener la siguiente información:

i. El análisis de impacto sobre el negocio

ii. El análisis de riesgos asociados

iii. La cantidad de datos cuya pérdida puede ser asumida porla organización

iv. El tiempo máximo que se puede estar sin la infraestructurade TI como apoyo a las operaciones del negocio

3. Un plan de recuperación ante desastres debe considerar lainfraestructura de TI, los sistemas de información y los datos que éstosprocesan, lo cual incluye: redes, servidores, computadoras de escritorio,computadoras portátiles, dispositivos móviles, bases de datos,conectividad, entre otros.

4. La información de las bases de datos de la organización deberá serrespaldada de manera externa y segura a la organización, de tal formaque esté disponible para ser restaurada en el sitio que se hayaseleccionado para recuperarse del desastre.

1 Acrónimo de Disaster Recovery Plan.

PROPUESTA



5. Con el fin de que la organización no incurra en grandes inversiones, sedeberá evaluar la factibilidad de soportar la ejecución del plan derecuperación ante desastres utilizando las estrategias de recuperaciónpropuestas por ciertos proveedores.

Especial mención en este punto se merece la posibilidad de utilizar la“nube” (Cloud) como una opción de estrategia de recuperación antedesastres. De ser así se debe considerar no solo los aspectos técnicossino los aspectos de índole legal y regulatorio sobre la información quela organización puede llevar a la “nube”.

6. Con el fin de asegurar la factibilidad, la completitud, y la efectividad delplan de recuperación ante desastres, se deberá ponerlo a prueba por lomenos una vez por año, para lo cual se deberán definir diferentesescenarios de desastre con sus respectivas premisas y pre-condiciones.

A partir de éstas las diferentes personas de la organización que seencuentran involucradas en el plan, deberán poner a prueba el plan ensí y sus capacidades para restaurar la operación de la organización bajolas condiciones de desastre simuladas.

PROPUESTA



8. Referencias




ISACA. (2012). COBIT 5: Enabling Processes. Rolling Meadows, Illinois,Estados Unidos: ISACA.

ISO/IEC. (2008). ISO/IEC 24762:2008 Information technology - Securitytechniques - Guidelines for information and communications technologydisaster recovery services. Geneva, Suiza: ISO/IEC.

Oracle Corporation. (2010). Oracle Reference Architecture - ApplicationInfrastructure Foundation 3.1. Estados Unidos: Oracle.

Pink Elephant. (2008). Fundamentos de ITIL V3. Burlington, Ontario, Canada:Pink Elephant.

PROPUESTA



9. Anexos

9.1. Ejemplo de Plan de Recuperación Ante Desastres

A continuación se indica una dirección web a través de la cual se podráacceder a un ejemplo de plan de recuperación ante desastres, desarrollado porIBM.


http://pic.dhe.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzarm/rzarmdisastr.htm

En este sitio el lector podrá revisar las secciones en las cuales se agrupa elcontenido de un plan de recuperación ante desastres para recuperar lainfraestructura de TI según IBM.

PROPUESTA

SECRETARIA NACIONAL DE PLANIFICACION Y...

Documents

Transcript of SECRETARIA NACIONAL DE PLANIFICACION Y...