lunes, 20 de septiembre de 2010

PLAN DE CONTINGENCIAS

PLAN DE CONTINGENCIAS

¿…Por qué se necesita un Plan de Contingencia?

A medida que las empresas se han vuelto cada vez más dependientes de las computadoras y las redes para manejar sus actividades, la disponibilidad de los sistemas informáticos se ha vuelto crucial. Actualmente, la mayoría de las empresas necesitan un nivel alto de disponibilidad y algunas requieren incluso un nivel continuo de disponibilidad, ya que les resultaría extremadamente difícil funcionar sin los recursos informáticos. 

Los procedimientos manuales, si es que existen, sólo serían prácticos por un corto periodo. En caso de un desastre, la interrupción prolongada de los servicios de computación puede llevar a pérdidas financieras significativas, sobre todo si está implicada la responsabilidad de la gerencia de informática. Lo más grave es que se puede perder la credibilidad del público o los clientes y, como consecuencia, la empresa puede terminar en un fracaso total.

"¿Por qué se necesita un plan de contingencia para desastres si existe una póliza de seguro para esta eventualidad?“

La respuesta es que si bien el seguro puede cubrir los costos materiales de los activos de una organización en caso de una calamidad, no servirá para recuperar el negocio. No ayudará a conservar a los clientes y, en la mayoría de los casos, no proporcionará fondos por adelantado para mantener funcionando el negocio hasta que se haya recuperado.
En un estudio realizado por la Universidad de Minnesota, se ha demostrado que más del 60% de las empresas que sufren un desastre y que no tienen un plan de recuperación ya en funcionamiento, saldrán del negocio en dos o tres años. Mientras vaya en aumento la dependencia de la disponibilidad de los recursos informáticos, este porcentaje seguramente crecerá.
Por lo tanto, la capacidad para recuperarse exitosamente de los efectos de un desastre dentro de un periodo predeterminado debe ser un elemento crucial en un plan Estratégico de Seguridad para una organización.
Imagínese una situación que interrumpa las operaciones de las computadoras durante una semana o un mes; imagine la pérdida de todos los datos de la empresa, todas las unidades de respaldo del sitio y la destrucción de equipos vitales del sistema,
¿Cómo se manejaría semejante catástrofe?
Si Ud. se ve en esta situación y lo único que puede hacer es preguntarse
"¿Y ahora qué?"
¡Ya es demasiado tarde!
La única manera efectiva de afrontar un desastre es tener una solución completa y totalmente probada para recuperarse de los efectos del mismo.

Plan de Contingencia:

Hoy por hoy, la información es uno de los principales activos que la empresa debe cautelar mediante el desarrollo de un plan de contingencia, que permita el adecuado funcionamiento del negocio frente a un cese prolongado del servicio informático.
El objetivo del plan no es evitar los riesgos, sino minimizar el impacto que las incidencias podrían producir en la organización.
La alta dirección debe tomar conciencia que el desarrollo y la implantación de planes de contingencia comprende toda la organización, pues se trata de una situación de negocios y no puramente informática.

¿Qué es un desastre?

Se puede considerar como un desastre la interrupción prolongada de los recursos informáticos y de comunicación de una organización, que no puede remediarse dentro de un periodo predeterminado aceptable y que necesita el uso de un sitio o equipo alterno para su recuperación.
Ejemplos obvios son los grandes incendios, las inundaciones, los terremotos, las explosiones, los actos de sabotaje, etcétera.

Estadísticas recientes sobre los tipos más comunes de desastres que ocurren muestran que el terrorismo, los incendios y los huracanes son las causas más comunes en muchos países.


miércoles, 3 de marzo de 2010

RIESGOS DE OPERACIÓN

RIESGOS DE OPERACIÓN

Riesgos de Operación: Es la posibilidad de ocurrencia de pérdidas financieras por deficiencias o fallas en los procesos internos, en la tecnología de información, en las personas o por ocurrencia de eventos externos adversos (Según SBS)

Evento externo: Un terremoto

Una definición aceptada universalmente
Cualquier cosa que pueda evitar que la organización cumpla con sus objetivos

El riesgo de pérdidas directas o indirectas resultantes de un inadecuado o fallido proceso interno, personal y fallas de sistemas o de eventos externos.

El riesgo de pérdidas originadas por un procesamiento transaccional.

Administración de Riesgos de Operación: Es un proceso efectuado por el Directorio, Gerencia y otros miembros del personal, aplicado en la planeación estratégica y en todos los niveles de la organización, diseñado para identificar los eventos potenciales que puedan afectarla y administrar los riesgos de acuerdo a las políticas establecidas de modo de proveer seguridad razonable en cuanto al logro de los objetivos de la organización

PERMANECER EN EL NEGOCIO

La Administración de Riesgos de Operación debe asegurar, que:

No se pierdan oportunidades
Mejore las ventajas competitivas. ventaja competitiva es una ventaja que una compañía tiene respecto a otras compañías competidoras inca coca cola por la formula y no va poder igualar
Se realicen menos acciones correctivas.

¿Qué tópicos abarca el Riesgo de Operación?

PÉRDIDAS PORCENTUALES POR TIPO DE RIESGO



LOS ANÁLISIS SUGIEREN QUE LOS R.O. SON MAYORES QUE LO ESTIMADO EN EL PASADO
PIRÁMIDE DEL FRAUDE: VALIDO PARA LA GESTIÓN DE R.O.P



COSTOS DE NO GESTIONAR RIESGOS DE OPERACIÓN (IMPACTOS POSIBLES)
SE DEBEN ASUMIR RIESGOS

Por la naturaleza de su actividad las empresas financieras asumen riesgos que pueden conllevar perdidas económicas.

Sin riesgos no hay actividad
• Por lo tanto, deben establecer mecanismos que permitan:


EXISTE EL RIESGO 0 ?

Elementos que Originan los Riesgos de Operación:

PERSONAL

Fraude interno y/o errores
Fraude a través del computador
Mal uso de información confidencial del cliente

SISTEMAS

Fallas de sistemas
Hardware
Software
Fallas no intencionales de operación

EVENTOS EXTERNOS

Satisfacción del cliente
Riesgo regulatorio
Servicios provistos por terceros
Fraude externo
Daño a los recursos físicos

PROCESOS

Prácticas de empleo y seguridad del lugar de trabajo.
Fallas de comunicación
Inadecuados reportes
Errores de entrada de datos.
Caso de Riesgo de Operación

Procesos:

Riesgos Típicos:
Definición inapropiada de requerimientos
Inadecuados formatos para ingreso de datos
Demora en la implementación del nuevo producto en el sistema.
Insuficiente capacidad de personas para hacer frente a volumen de nuevas operaciones.
Falta de reportes apropiados
Términos y cláusulas inadecuadas del contrato.

Impacto :
Servicios al cliente
PublicidadReputación

lunes, 1 de marzo de 2010

ADMINISTRACIÓN DE RIESGOS DE NEGOCIO

ADMINISTRACIÓN DE RIESGOS DE NEGOCIO

En la actualidad, las organizaciones están enfocando los esfuerzos corporativos en la búsqueda de nuevas opciones para incrementar el valor para sus accionistas.

El riesgo genera oportunidades; las oportunidades generan valor y el valor se convierte en mejoras para el negocio y los accionistas.

Se puede resaltar que en la mayoría de las industrias y organizaciones, está reconociendo que los riesgos no son solamente peligros a ser evadidos sino que, en muchos casos, son oportunidades a ser asumidas. “El riesgo como tal no es malo, lo malo es el riesgo mal manejado, mal entendido, mal valorizado, no planeado” asegura Suzanne Labarage, CRO en el Royal Bank of Canadá.

Un enfoque orientado a lo integral, incorporado y con visión de futuro, ayuda a la organización a administrar sus riesgos claves de negocio y aprovechar sus oportunidades para maximizar el valor para los accionistas y del negocio como un todo.
Algunos modelos actuales sostienen que la administración de los riesgos debe estar intrínsecamente ligada a la estrategia del negocio, la cual incluye la visión, misión y objetivos ya establecidos; así como los procesos para definir sus operaciones de mayor importancia y sus filosofías, políticas, planes e iniciativas de crecimiento y desarrollo.
ENTORNO ACTUAL:
En la medida en la que los riesgos cambian y se incrementen, las administraciones de varias industrias buscan asegurar que se esté considerando adecuadamente tanto los riesgos como el monto de riesgos – comparado con el apetito de riesgos de sus unidades o divisiones en la organización y comparado con otras organizaciones dentro de sus mismos mercados e industria ó con la competencia. La tolerancia al riesgo de cada organización es única y varia de acuerdo a la cultura organizacional, así como a los factores externos. Un aspecto crítico de la responsabilidad de la administración es determinar qué riesgos serán prioridad y después reevaluar periódicamente esa elección conforme a las circunstancias.


ADMINISTRACIÓN DE LOS RIESGOS:
Es el término aplicado a un método lógico y sistemático de establecer el contexto, identificar, analizar, evaluar, tratar, monitorear y comunicar los riesgos asociados con una actividad, función o proceso de una forma que a las organizaciones minimizar pérdidas y maximizar oportunidades, es decir, es tanto identificar las oportunidades como también evitar o mitigar las pérdidas.



ESTABLECER EL CONTEXTO:
Establecer el contexto estratégico, organizacional y de administración de riesgos en el cual tendrá lugar el resto del proceso. Deberían establecerse criterios contra los cuales se evaluarán los riesgos y definirse la estructura del análisis.

IDENTIFICAR RIESGOS:

Identificar qué, por qué y cómo pueden surgir las cosas como base para análisis posterior.

ANALIZAR RIESGOS:

Determinar los controles existentes y analizar riesgos en términos de consecuencias y probabilidades en el contexto de esos controles. El análisis debería considerar el rango de consecuencias potenciales y cuán probable es que ocurran esas consecuencias.
Consecuencias y probabilidades pueden ser combinadas para producir un nivel estimado de Riesgo.

EVALUAR RIESGOS:
Comparar niveles estimados de riesgos contra los criterios preestablecidos. Esto posibilita que los riesgos sean ordenados como para identificar las prioridades de administración.
Si los niveles de riesgo establecidos son bajos, los riesgos podrían caer en una categoría aceptable y no se requeriría un tratamiento.

TRATAR RIESGOS:

Aceptar y monitorear los riesgos de baja prioridad. Para otros riesgos, desarrollar e implementar un plan de administración especifico que incluya consideraciones de fondo.

MONITOREAR Y REVISAR:
Monitorear y revisar el desempeño del sistema de administración de riesgos y los cambios que podrían afectarlo.

COMUNICAR Y CONSULTAR:
Comunicar y consultar con interesados internos y externos según corresponda en cada etapa del proceso de administración de riesgos y concerniendo al proceso como un todo.

ADMINISTRACIÓN DE LOS RIESGOS:
Una vez que se ha hecho un análisis de los riesgos existente en la organización, para algunos de ellos no se requerirá tomar acciones inmediatas, sin embargo cuando exista un riesgo con una probabilidad alta de ocurrencia y con un alto impacto, la administración deberá tomar acciones inmediatas para mover ese riesgo a un rango aceptable e incluso eliminarlo, basándose en un análisis de riesgo / beneficio para la organización.

Habiendo evaluado y clasificado sistemáticamente los riesgos y tal vez habiendo tratado de entender su impacto, muchas organizaciones pueden determinar qué riesgos deben ser administrados a nivel corporativo y cuáles riesgos deben ser administrados en los niveles medios dentro de la organización.

La administración de riesgo centralizada tiende a enfocarse a los riesgos que afectan el logro de los objetivos y estrategias claves de la organización y que afectan significativamente casi todas las funciones y casi todos los procesos (ejemplo; prestigio, imagen, etc.). La responsabilidad de estos riesgos debe recaer en la dirección general y/o consejo superior, los otros riesgos que podrían ser administrados de manera centralizada son aquéllos que requieren habilidades especializadas y que no pueden ser trabajados al nivel de división, o aquellos que requieran de contratación de servicios externos.

Los riesgos que deben administrarse de manera descentralizada podrían hacerse al nivel de división o proceso, aquéllos que son importantes únicamente en un proceso particular, pero que no afectan a la organización en la implementación exitosa de sus estrategias generales.

Acciones a seguir derivadas de la Evaluación de Riesgo:
La evaluación de riesgo ha probado ser un proceso altamente útil para identificar, categorizar y evaluar riesgos críticos, con base en su probabilidad de ocurrencia y magnitud de impacto. El punto clave que ha surgido, sin embargo, es ¿qué hacer con la información, cuando la evaluación de riesgo ha sido terminada?

En algunos casos, las organizaciones se encuentran con que el proceso ha identificado tantos riesgos que no es posible darle seguimiento a todos, y en otros casos, se encuentra con que no se ha podido trasladar la evaluación de riesgo a pasos de acción específicos - en el contexto de administración de apetito de riesgo – que aporten valor a la organización.

OPTIMIZACIÓN DE RIESGOS:
Comprende el concepto de alternativas; es decir, es un proceso repetitivo, mientras una táctica es implementada, los riesgos deben ser re - evaluados. Siendo que la re - evaluación no se puede hacer por cada acción, las organizaciones han empezado a dar surgimiento a las acciones relacionadas con los riesgos más importantes y materiales de la organización.

MEDICIÓN Y MONITOREO PARA INCREMENTAR VALOR:
La medición y el monitoreo se vuelven acciones necesarias, como un medio continuo de entendimiento y entrega de reportes para analizar el verdadero impacto de los riesgos. Las organizaciones deben definir los sistemas de monitoreo y medición que mejor les sirvan a sus estilos de trabajo y características de administración.

LA ESTRATEGIA Y LA ESTRUCTURA DE RIESGOS
La estrategia de riesgo proporciona los lineamientos para las actividades dentro de la organización; es la columna vertebral para dar a la organización la cultura del negocio central. La estrategia de riesgo debe llevarse a cabo con base en la estructura de riesgo, que engloba los roles y responsabilidades para la administración de riesgos.

Estas estructuras definen responsabilidades y líneas que reporten información, las cuales facultan a los administradores a actuar bajo límites relacionados con el apetito de riesgo.

La comunicación de la estrategia de riesgo es esencial y debe estar diseñada para asegurar que todos los empleados e inversionistas entiendan la misión, visión y objetivos de la organización.
Los líderes deben demostrar claramente la relevancia de la estrategia de la administración de riesgos, proporcionando historias de éxito, para maximizar valor en el proceso de la comunicación.

Habiendo establecido la responsabilidad y confianza, los lideres deben también ser cuidadosos al asegurarse que todo el personal de la organización tenga las habilidades necesarias para la ejecución y monitoreo de la administración de riesgo.
Comparación del tratamiento del riesgo, si existe una adecuada administración del mismo

EN EL PASADO

Riesgos considerados individualmente

Identificación y evaluación del riesgo

Enfoque en todos los riesgos

Mitigación de riesgo

Límite del riesgo

Riesgos que no tienen responsables

Cuantificación de riesgos inconsistentes

Riesgo no es mi responsabilidad

HOY EN DÍA

Riesgos en el contexto de la estrategia

Desarrollo del portafolio de riesgos

Enfoque en los riesgos críticos

Optimización de riesgo

Estrategia del riesgo

Responsabilidad sobre riesgo definida

Monitoreo y medición

Riesgo es responsabilidad de todos

CONCLUSIONES
La administración de riesgo ayuda a la organización a tener más clara su situación tanto interna como externamente, ya que se convierte en un medio de ayuda para que la organización cambie su enfoque de respuesta, y pueda reaccionar de una manera proactiva y no reactiva hacia los eventos que puedan surgir. La evaluación de riesgos en algunos casos puede salvar a las organizaciones de irse a la quiebra, ya que protege contra sorpresas.

Al hacer una evaluación constante de riesgos se constituye en valor organizacional que permite el éxito futuro de la organización en un entorno cambiante y competitivo, obteniendo una mejora en el desarrollo y desempeño de la organización.

Identificar, optimizar y administrar el portafolio de riesgos permite a la organización tener un enfoque claro para mejorar la asignación de recursos; estabiliza los resultados y encuentra nuevas oportunidades para mejorar los aspectos críticos del negocio, obteniendo beneficios económicos medibles

La administración de riesgos permite adoptar uno de los elementos más importantes que apoyan la transparencia, certidumbre a terceros y confianza en los inversionistas. Da respuesta a las necesidades del consejo superior y al comité de auditoria, se reenfoca de este modo el concepto de auditoria interna, el plan y la ejecución de las auditorias.
“Si logramos los objetivos del negocio, seremos muy exitoso; si no los logramos, una de la razones será una deficiente Administración de Riesgos”.

viernes, 26 de febrero de 2010

ESTANDARIZACION Y CERTIFICACION EN SEGURIDAD INFORMATICA

ESTANDARIZACION Y CERTIFICACION EN SEGURIDAD INFORMATICA

Estándares de Seguridad

Propósito de los Estándares:

En general, los estándares cumplen hoy en día un importante papel en la sociedad y en desarrollo de muchas actividades empresariales, sobre todo a raíz de la implantación de las técnicas de gestión de la calidad y la homologación y certificación de productos en numerosos sectores.

Podemos considerar que en el caso concreto de los estándares de seguridad existen al menos tres razones que justifican su desarrollo e implantación:
  1. Suministrar normas de seguridad a los fabricantes de productos.
  2. Definir métricas de evaluación, de certificación y de acreditación
  3. Transmitir la confianza necesaria a los usuarios y consumidores
Propósito de los Estándares:

1.- Suministrar normas de seguridad a los fabricantes de productos:
Los estándares permiten establecer una serie de orientaciones para el desarrollo de nuevos producto. Para cumplir de forma adecuada con este principio, los fabricantes de productos certificados deben ofrecer una documentación exhaustiva sobre la seguridad de estos productos.

Propósito de los Estándares:

2. - Definir métricas de evaluación, de certificación y de acreditación: Aplicadas tanto a procesos como a técnicas de gestión y al desarrollo y comercialización de productos y servicios. Las evaluaciones y certificaciones no pueden ser realizadas por el mismo fabricante vendedor, sino que correspondería este papel a organismos independientes acreditados para llevar a cabo estas tareas.

Propósito de los Estándares

3. Transmitir la confianza necesaria a lo usuarios y consumidores:
De tal manera que los usuarios puedan comparar sus requerimientos específicos de seguridad frente a lo establecido en distintos estándares para poder determinar cual es el nivel de seguridad que necesitan, y en consecuencia, que características o atributos, deberían exigir a los productos o servicios que vayan a adquirir. Por otra parte, gracias a los estándares los usuarios y consumidores pueden más fácilmente cuándo un producto o servicio cumple una serie de requisitos.

Propósito de los Estándares:

Se suele hablar de criterios cuando nos referimos a unas escalas utilizadas para poder medir la seguridad de los sistemas y productos tecnológicos. Las metodologías definen cómo debe realizarse la evaluación de acuerdo con los criterios utilizados. Por su parte los esquemas nacionales e internacionales permiten establecer el marco y los procedimientos de actuación para la evaluación y certificación de la seguridad de los productos tecnológicos.

La evaluación consiste en el análisis de la capacidad de un determinado producto para proteger la información de acuerdo a unos criterios establecidos.

La evaluación se lleva a cabo siguiendo una determinada metodología y tiene por objeto determinar si el producto puede ser certificado. La credibilidad de este proceso dependerá de los métodos utilizados y del rigor y nivel de detalle del análisis del producto: ¿Qué aspectos de la seguridad se evalúan?, ¿Cómo se evalúan?, ¿Quién se encarga de llevar a cabo esta evaluación y que confianza nos merece?

La certificación es el proceso que permite determinar la capacidad de un determinado producto para proteger la información de acuerdo a unos criterios establecidos.

Mediante el proceso de certificación se puede confirmar de forma independientemente la validez de los resultados y conclusiones de la evaluación previa, y si esta evaluación se ha llevado a cabo de acuerdo con el procedimiento establecido.

De acuerdo con algunos expertos se pueden distinguir cuatro tipos de certificaciones:

  • Certificación de la Seguridad de las Tecnologías de la Información.
  • Certificación de la Seguridad Criptológica.
  • Certificación de la Seguridad Física.
  • Certificación de la Seguridad de Emanaciones Radioeléctricas (según la normativa TEMPEST).

La Acreditación permite valorar la capacidad de los sistemas informáticos para resistir, hasta un determinado nivel de confianza, accidentes o acciones maliciosas que puedan comprometer la confidencialidad, integridad, autenticidad y disponibilidad de la información que manejan.

Organismos responsables de la estandarización:

Los principales organismos responsables de la elaboración de estándares a nivel internacional son:
La Comisión Electrotécnica Internacional ( IEC ): responsable de la elaboración de normas sobre electrotecnia y electrónica.

La Organización Internacional de Normalización ( ISO ): responsable de la estandarización en el resto de los sectores de actividad. Tanto ISO como IEC comparten la responsabilidad de la elaboración de normas relativas a las Tecnologías de la Información y la Comunicación ( TICs ).


ORGANIZACIÓN INTERNACIONAL DE NORMALIZACION (ISO)

ES UNA FEDERACIÓN MUNDIAL DE ORGANISMOS DE NORMALIZACION DE 138 PAISES
MISIÓN
PROMOVER EL DESARROLLO DE LA NORMALIZACIÓN EN EL MUNDO Y DE LAS ACTIVIDADES CON ELLA RELACIONADAS, CON VISTAS A FACILITAR EL INTERCAMBIO INTERNACIONAL DE BIENES Y SERVICIOS Y DESARROLLAR LA COOPERACIÓN EN EL CAMPO DE LA ACTIVIDAD INTELECTUAL, CIENTÍFICA Y ECONÓMICA

A nivel europeo conviene destacar el papel de los siguientes:

  • El Comité Europeo de Normalización (CEN)
  • El Instituto Europeo de Normalización de las Telecomunicaciones (CENELEC)
  • La Asociación Española de Normalización y Certificación ( AENOR )

Estándares Estadounidenses:

Se presenta de forma resumida los principales estándares en materia de Gestión de la Seguridad de la Información que se han desarrollado en Estados Unidos:

TCSEC: Trusted Computer System Evaluation Criteria

Los ” Criterios de Evaluación de Sistemas de Confianza ”, fueron desarrollados en 1985 por el Centro de Seguridad Informática Nacional de Estados Unidos, un organismo dependiente de la Agencia de Seguridad (NSA) responsable de la fiabilidad de los sistemas informáticos del gobierno de los Estados Unidos.

También conocido como el “libro naranja”, por el color de las tapas de su publicación, y definen varias clases de sistemas en función de su nivel de seguridad: D, C1, C2, B1, B2, B3 y A.

Clase D (Sin Seguridad); se otorga a aquellos sistemas que no cumplen ninguna especificación de seguridad, es decir, no se dispone de protección para el hardware, el sistema operativo es inestable y no existe autenticación con respecto a los usuarios y sus derechos en el acceso a la información. Como ejemplos podríamos citar los sistemas operativos utilizados en los PCs


Clase C1 (Control de Acceso Discrecional); el sistema informático distingue varios tipos de usuarios, disponiendo además de mecanismos fiables de autenticación y de control de acceso a la información por parte de cada usuario. El administrador del sistema es un usuario especial con control total de acceso.

Clase C2 (Protección de Acceso Controlado); además de las características ya prevista para la clase o nivel C1, en estos sistemas se debe implementar un mecanismo de auditoria de accesos e intentos fallidos de acceso a los objetos protegidos. Poseen la capacidad de definir un mayor número y tipo de restricciones sobre los usuarios del sistema: que comandos y aplicaciones pueden ejecutar, limitación de acceso a determinados archivos o servicios. Como ejemplos podríamos citar los sistemas operativos Windows NT, Windows2000, UNIX, etc.


Clase B1 (Seguridad Etiquetada); estos sistemas soportan la seguridad multinivel, mediante la cual a cada objeto del sistema (ya sea este un usuario, dato, fichero u otro recurso) se le asigna una etiqueta, con un nivel de seguridad jerárquico (alto secreto, secreto, reservado, etc.) y con unas determinadas categorías (contabilidad, ventas, personal…) de modo que cada usuario que accede a un objeto debe poseer un permiso expreso para hacerlo, es decir se establecen controles para limitar la propagación o modificación de los permisos de acceso a los distintos objetos del sistema.

Clase B2 (Protección Estructurada); se aplica a los sistemas que permiten establecer una jerarquía de objetos a la hora de definir las etiquetas de seguridad, facilitando además la comunicación entre objetos de un novel superior con otros de un nivel inferior; el sistema será capaz de alertar a los usuarios si sus condiciones de accesibilidad y seguridad han sido modificadas.

Clase B3 (Dominios de Seguridad); el sistema informático contempla la implantación de “Dominios de Seguridad”, reforzados mediante hardware especifico para facilitar la aplicación de las políticas de acceso que se hayan definido.

Clase A (Protección Verificada); se reserva para aquellos casos en los que se han utilizado métodos formales (técnicas matemáticas de verificación formal) en el proceso de diseño y verificación del sistema. El hardware y el Software son protegidos para evitar infiltraciones ante traslados de los equipos informáticos.

Federal Criteria

Se trata de una evolución de TCSEC presentada en el año 1992.

FISCAM: Federal Information System Controls Audit Manual

Estándar de auditoria y control de la seguridad de los Sistemas de Información Federales desarrollado de la Oficina de Contabilidad General de Estados Unidos.

NIST SP 800

Estándar para la certificación de sistemas basados en las Tecnologías de la Información, que ha sido desarrollados por el NIST (Instituto Nacional de estándares y Tecnología), un organismo que depende del Departamento de Comercio de Estados Unidos.

Estándares Europeos:

A nivel europeo podemos destacar los siguientes estándares y actuaciones destacadas en materia de Gestión de la Seguridad de la Información (propuestos en algunos casos como una evolución y adaptación de los estándares de estados Unidos):

ITSEC: Information Technology Security Evaluation Criteria
Los Criterios de Evaluación de la Seguridad de las Tecnologías de la Información fueron desarrollados conjuntamente por Francia, Alemania, Holanda y el Reino Unido en el año 1,991, tomando como referencia el trabajo llevado a cabo previamente por el estándar TCSEC en Estados Unidos.


ITSEM: Information Technology Security Evaluation Methodology
Se trata de la metodología de evaluación que se ha definido correspondiente a los criterios ITSEC.

Agencia Europea de Seguridad de la Información y las Redes

En Marzo del 2003 la Comisión Europea decidió crear la Agencia Europea de Seguridad de la Información y las Redes Informáticos (ENISA), con los siguientes objetivos:

Obtener un consenso en materia de seguridad informática en Europa que permita mantener permita mantener la disponibilidad y seguridad necesarias en las redes y sistemas de información de las distintas organizaciones.

Proveer asistencia para la aplicación de nuevas normativas en este campo.

Dirigir el desarrollo en estas materias.

Avisar y coordinar acerca de la información recopilada y analizada.

Dar soporte a la certificación y estandarización del mercado.

Facilitar el contacto con terceros países.

Estándares Internacionales:

Los principales estándares relacionados con la seguridad de la información y la certificación de los productos tecnológicos han sido desarrollados por la ISO y el IEC. Los estándares mas conocidos a nivel internacional son los siguientes:

ISO / IEC 13335: Guidelines for Management of Information Technologies Security (Directrices para la Gestión de la Seguridad)
Es un estándar que define un marco de referencia para las técnicas de gestión de riesgos y los criterios de selección de medidas de seguridad o salvaguardas en los sistemas y redes informáticas.

ISO / IEC 15408: Common Criteria, Criterios Comunes
Criterios Comunes para la evaluación de determinados productos de seguridad, facilitando de este modo el proceso de certificación de los noveles y servicios de seguridad que pueden proporcionar estos productos.

ISO / IEC 21827: Systems Security Engineering (Ingeniería de la Seguridad de los Sistemas)
Se ha propuesto para facilitar la evaluación del nivel de madurez de los procesos relacionados con la Gestión de la Seguridad de la Información.

ISO / IEC 17799 (BS-7799): Information Security Management (Gestión de la Seguridad de la Información)

Estándar que define un código de buenas practicas mediante un conjunto de controles que se pueden aplicar para mejorar la Gestión de la Seguridad de la Información en una organización.

ISO / IEC 27001: Information Security Management Systems Requirements (Requisitos para los Sistemas de Gestión de Seguridad de la Información)
Norma que permite certificar la implantación de un Sistema de Gestión de Seguridad de la Información en una organización.

ISM3: Information Security Management maturity Model (Modelo de madurez de la Gestión de la Seguridad de la Información)
Nuevo estándar que se estructura en distintos “niveles de madurez” para facilitar su implantación progresiva en las organizaciones, partiendo de los requerimientos básicos de seguridad del negocio o actividad que desarrollan.

COBIT: Information Systems Audit and Control Association (Asociación para el Control y la Auditoria de los Sistemas de Información)
Requerimientos de seguridad establecidos por la ISACA

RFC 2196: Internet Engineering Task Force (Grupo de Trabajo de Ingeniería de Internet)
Que constituye un Manual de Seguridad con una serie de directrices aplicables al desarrollo y explotación de un Website en Internet.

OCTAVE: Operationally Critical Threat, and Vulnerability Evaluation (Evaluación de Vulnerabilidades, Activos y Amenazas Criticas)
Se trata de una metodología propuesta para facilitar la evaluación y la gestión de los riesgos en una organización ( http://www.cert.org/octave/ ).

MAGERIT
Magerit, la Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información de las Administraciones Publicas, fue desarrollada por el Ministerio de Administraciones Publicas y publicada en 1997.

Los objetivos de MAGERIT son cuatro:

  1. Concienciar a los responsables de los Sistemas de Información de la existencia de riesgos y necesidades de adoptar las medidas para limitar su impacto.
  2. Ofrecer un método sistemático para analizar tales riesgos.
  3. Planificar las medidas oportunas para mantener los riesgos identificados bajo control, y
  4. Facilitar los procesos de evaluación, auditoria, certificación o acreditación.

En el mes de Julio del 2005, el Consejo Superior d administración Electrónica hizo publica la versión 2 de MAGERIT.

Proceso de Certificación

El proceso de certificación debe ser realizado por una entidad independiente y competente capaz de determinar si un determinado SGSI (Sistema de Gestión de la Seguridad de la Información) es correcto, y lo confirma mediante el correspondiente certificado por escrito.
La certificación constituye un reconocimiento al trabajo bien hecho, una garantía de “calidad de la seguridad”, que aporta beneficios para la propia organización, sus clientes, inversores y empleados. Sin embargo, la adaptación a la norma no garantiza la inmunidad total de la organización frente a problemas de seguridad, pero permite reducir el riesgo.
La Seguridad Total No Existe

CERTIFICACIÓN
PROCEDIMIENTO POR EL CUAL UNA TERCERA PARTE ASEGURA POR ESCRITO QUE UN PRODUCTO, PROCESO O SERVICIO ES CONFORME CON LOS REQUISITOS ESPECIFICADOS

El proceso de certificación consta de dos grandes etapas:
La Consultoría:

Un equipo de consultores con experiencia en la norma ayuda a la organización a cumplir con los requisitos de certificación: Políticas de seguridad, procedimientos, selección e implantación de controles, etc. En esta etapa será necesario determinar las acciones correctivas (que eliminan la causa de las no conformidades en la implantación, operación y uso del SGSI) y las acciones preventivas (que permiten eliminar la causa de no conformidades potenciales, previniendo su ocurrencia).

La Auditoría:
Un organismo acreditado, en cada país, se encarga de revisar los distintos procesos y procedimientos de gestión de seguridad exigidos por la norma, así como de revisar la implantación de los distintos controles seleccionados. Una de las instituciones de referencia a nivel internacional en auditoria de los Sistemas de Información es ISACA (Information Systems Audit and Control Association – Asociación para el Control y la Auditoria de los Sistemas de Información).

Guía para la implantación de un Sistema de Gestión de Seguridad de la Información según la norma UNE 71502:2004

Esta guía esta compuesta por 10 etapas o fases necesarias para la implantación de un SGSI y su posterior certificación de acuerdo con la norma UNE 71502:2004, que puede servir de marco de referencia para una organización interesada en obtener dicha certificación:

Definición de las Políticas de Seguridad y del Alcance del SGSI.
Definición de las partes o áreas del negocio que van a ser auditadas bajo la norma.
Especificación del alcance del proyecto identificando los procesos de negocio, los recursos de información afectados, los recursos tecnológicos y organizativos, las personas clave y las relaciones con terceros.

Establecimiento de las Políticas de Seguridad: la Dirección General, junto con los empleados de los departamentos afectados en la implantación, debe definir y desarrollar una Política de seguridad de la Información dentro de la organización

Elaboración de un Documento de seguridad en el que se debe reflejar el compromiso de la Dirección, la definición de la seguridad de la información dentro de su organización, la descripción de los principios fundamentales del sistema de Gestión de Seguridad de la Información, la definición de las responsabilidades de los usuarios, la referencia al soporte documental y el cumplimiento con los requisitos legales y contractuales.

Definición de Responsabilidades y Asignación de Recursos.

Creación de un Comité de Seguridad que se encargara de la revisión y actualización de las Políticas de Seguridad de la Información. Este comité revisara el análisis de riesgos, partiendo de la identificación de los principales activos y recursos a proteger, de sus vulnerabilidades y de las posibles amenazas que les puedan afectar.

Así mismo se debería definir un responsable de la implantación del SGSI, con la misión de apoyar al Comité de Seguridad, dirigir y mantener el SGSI, trabajar con los procesos y departamentos directamente implicados en el SGSI (actuando de interlocutor con los responsables de los activos identificados y de la correcta implantación del sistema en su proceso o área de negocio) y llevar a cabo las auditorias internas que permitan controlar la adecuada implantación del SGSI.

Identificación y Registro de Activos.
Identificación y descripción de todos los activos contemplados dentro del alcance del SGSI, así como de quienes son los responsables de gestionar dichos activos.

Análisis y Gestión de Riesgos.

Identificación de amenazas, vulnerabilidades y probabilidades de impacto en los activos.
Elaboración de un documento donde se refleje el resultado de la evaluación de las vulnerabilidades, los niveles de riesgo y la necesidad de aplicar las distintas medidas y requisitos de seguridad.

Selección e Implantación de Controles de Seguridad.

Elaboración de un Documento de Selección de Controles, documento que, por otra parte, es obligatorio según la norma UNE 71502.
Revisión de la aplicabilidad de los controles seleccionados.
Implantación de forma efectiva de los controles seleccionados.

Establecer un Programa de Mejora de la Seguridad.

Definición de un plan de acción con actuaciones concretas para mejorar la seguridad, siguiendo el modelo “PDCA”.


“Plan” (Planificar): definición y establecimiento del SGSI.
“Do” (Ejecutar): implantación y operación del SGSI.
“Check” (Verificar) comprobación y revisión del SGSI (medir la efectividad de las medidas de seguridad).
“Act” (Actuar): mantenimiento y mejora del SGSI.

Completar la Documentación del SGSI.
Planificación y Diseño del SGSI, incluyendo la definición del alcance.
Políticas de Seguridad de la Información.
Registro de Activos de Información y Valoración de Riesgos.
Documentos de Selección de Controles (DSC).
Procedimientos para la Implantación de los Controles.
Procedimientos para la gestión y operación del SGSI:

Revisión y Auditoria Interna del Proyecto de Implantación del SGSI.
Realización de la Auditoria de Certificación.
Ejecutar las Recomendaciones de la Auditoria.

Sistema de Gestión de la Seguridad de la Información
¿Qué es ISO 17799?
• ISO 17799 es una norma internacional que ofrece recomendaciones para realizar la gestión de la seguridad de la información

• ISO 17799 define la información como un activo.
• La seguridad de la información se define como la preservación de:
– Confidencialidad
– Integridad
– Disponibilidad

¿Qué es ISO 17799? (II)

• La adopción nacional de la norma se denomina ISO/IEC 17799
• Se trata de una norma NO CERTIFICABLE, pero que recoge la relación de controles a aplicar (o al menos, a evaluar) para establecer un Sistema de Gestión de la Seguridad de la Información (SGSI)

Historia de la normative

miércoles, 24 de febrero de 2010

CONTROL INTERNO Y AUDITORIA INFORMÁTICA

CONTROL INTERNO Y AUDITORIA INFORMÁTICA

INTRODUCCION

Tradicionalmente en materia de control interno se adoptaba un enfoque bastante restringido limitado a los controles contables internos.
Durante el último decenio la prensa ha informado sobre escándalos relacionados con errores en el otorgamiento de créditos con garantía de inmuebles inexistentes o sobrevalorados, la manipulación de información financiera, operaciones bursátiles realizadas con información privilegiada y otros fallos de los controles que han afectado a las empresas de diferentes sectores.

Por ellos hay cambios en las empresas que comprometen los controles internos existentes:

La reestructuración de los procesos empresariales (BPR – Bussines Process Re-enginieering).
La gestión de la calidad total (TQM-Total Quality Management).
El redimensionamiento por reducción y/o aumento del tamaño hasta el nivel correcto.
La contratación externa (outsourcing).
La descentralización.

El mundo en general está cambiando y somete a las empresas a la acción de muchas fuerzas externas tales como la creciente necesidad de acceder a los mercados mundiales la consolidación industrial, la intensificación de la competencia y las nuevas tecnologías.

Tendencias externas que influyen en las empresas:

La globalización.
La diversificación de actividades.
La eliminación de ramas de negocio no rentable o antiguas.
La introducción de nuevos productos como respuesta a la competencia.
Las fusiones y la formación de alianzas estratégicas
Ante la rapidez de los cambios los directivos toman conciencia que para evitar fallos de control significativos deben reevaluar y reestructurar sus sistemas de controles internos. Deben evaluar de manera PROACTIVA antes de que surjan los problemas, tomando medidas audaces para su tranquilidad, así como para garantizar al consejo de administración, accionistas, comités y publico, que los controles internos de la empresa están adecuadamente diseñados para hacer frente a los retos del futuro y asegurar la integridad en el momento actual.

Un centro de informática de una empresa suele tener una importancia crucial por soportar los sistemas de información del negocio, por el volumen de recursos y presupuestos que maneja, etc. Por lo tanto aumenta las necesidades de control y auditoría, surgiendo en las organizaciones, como medidas organizativas, las figuras de:

CONTROL INTERNO Y AUDITORIA INFORMATICOS.

La auditoría ha cambiado notablemente en los últimos años con el enorme impacto que ha venido obrando las técnicas informáticas en la forma de procesar la información para la gerencia. La necesidad de adquirir y mantener conocimientos actualizados de los sistemas informáticos devuelve cada vez mas acuciante.

Los auditores informáticos aportan conocimientos especializados, así como su familiaridad con la tecnología informática. Se siguen tratando las mismas cuestiones de control de auditoría, pero los especialistas en auditoría informática de sistemas basados en ordenadores prestan ayuda valiosa a la organización y a los otros auditores en todo lo relativo a los controles sobre dichos temas.
En muchas organizaciones el auditor ha dejado de centrarse en la evaluación y la comprobación de resultados de procesos, desplazando su atención a la evaluación de riesgos y comprobación de controles.

Muchos de los controles se incorporan en programas de sistemas o se realizan por parte de la función informática de la organización, representado por el control interno informático.
El enfoque centrado en controles normalmente exige conocimientos informáticos a nivel de la tecnología utilizada en el área o la organización que se examina.

LAS FUNCIONES DE CONTROL INTERNO Y AUDITORÍA INFORMÁTICA CONTROL INTERNO INFORMÁTICA C.I.I.

Control Interno Informático C.I.I. controla diariamente que todas las actividades de sistemas de información sean realizadas cumpliendo los procedimientos, estándares y normas fijados por la Dirección de la Organización y/o Dirección de Informática, así como los requerimientos legales.
La misión de C.I.I. es asegurarse de que las medidas que se obtienen de los mecanismos implantados por cada responsable sean correctas y válidas.

La función se le asigna a una unidad orgánica perteneciente al staff de la Gerencia de Informática y debe estar dotada de las personas y medios materiales requeridos para el cumplimiento de su misión.

En los tratados de auditoría se le denomina CONTROL INTERNO INFORMATICO (CII), definición que a nuestro concepto debe ser reemplazado por el titulo de ADMINISTRACION DE LA SEGURIDAD Y CONTROL DE SISTEMAS (ASYCS), en concordancia a los criterios y conceptos actualizados de las funciones especializadas de control y administración de riesgos.

C.I.I. - PRINCIPALES OBJETIVOS

Controlar que todas las actividades se realicen cumpliendo los procedimientos y normas fijados, evaluar su bondad y asegurarse del cumplimiento de las normas legales.
Asesorar sobre el conocimiento de las normas.

Colaborar y apoyar el trabajo de Auditoria Informática, así como de las auditorias externas.

Definir , implantar y ejecutar mecanismos y controles para comprobar el logro de los grados adecuados del servicio informático

C.I.I. - PRINCIPALES FUNCIONES

Realizar en los diferentes sistemas (centrales, departamentales, redes locales, Peces, etc.) y entornos informáticos (producción, desarrollo o pruebas) el control de las diferentes actividades operativas sobre:

Cumplimiento de diferentes procedimientos, normas y controles dictados. Ejemplo. Control de cambios y versiones de software.

Controles sobre la producción diaria.

Controles sobre la calidad y eficiencia del desarrollo y mantenimiento del software y del servicio informático.

Controles en las redes de comunicaciones.

Controles sobre el software de base.

Controles en los sistemas microinformáticos.

La seguridad informática:

Usuarios, responsables y perfiles de uso de archivos y bases de datos. Normas de seguridad. Control de información clasificada. Control dual de la seguridad informática.

Licencias.
Contratos con terceros.
Asesorar y transmitir cultura sobre el riesgo informático.

EL AUDITOR INFORMÁTICO (AI)

Evalúa y comprueba en determinados momentos del tiempo, los controles y procedimientos informáticos más complejos, desarrollando y aplicando técnicas mecanizadas de auditoria, incluyendo el uso de software.

En muchos casos ya no es posible verificar manualmente los procedimientos informatizados que resumen, calculan y clasifican datos, por lo que deberá emplear software de auditoría y otras técnicas asistidas por ordenador.

Es responsable de revisar e informar a la Dirección de la Empresa, sobre el diseño y funcionamiento de los controles implantados y sobre la fiabilidad de la información suministrada.

EL AUDITOR INFORMÁTICO (AI): FUNCIONES PRINCIPALES

Se pueden establecer tres grupos de funciones principales:

Participar en las revisiones durante y después del diseño, realización, implantación y explotación de aplicaciones informáticas, así como en las fases análogas de realización de cambios importantes.

Revisar y juzgar controles implantados en los sistemas informáticos para verificar su adecuación a las órdenes e instrucciones de la Dirección, requisitos legales, protección de confidencialidad y cobertura ante errores y fraudes.

Revisar y juzgar el nivel de eficacia, utilidad, fiabilidad y seguridad de los equipos e información.

CONTROL INTERNO Y AUDITORÍA INFORMÁTICOS: CAMPOS ANÁLOGOS

La evolución de ambas funciones ha sido espectacular en la última década. Muchos de los funcionarios de controles internos informáticos, fueron auditores. Han recibido formación enseguridad informática tras su paso por la formación en auditoría.
Hay una similitud de los objetivos profesionales de control y auditoría, campos análogos que propician una transición natural.
DASYCS – AI: ANALOGÍA
SISTEMA DE CONTROL INFORMÁTICO DEFINICIÓN Y TIPOS DE CONTROLES INTERNOS

Se puede definir el control interno como “cualquier actividad o acción realizada” manual y/o automáticamente para prevenir, corregir errores o irregularidades que puedan afectar al funcionamiento de un sistema para conseguir sus objetivos.


Los controles cuando se diseñen, desarrollen e implanten han de ser al menos, completos, simples, fiable, revisables, adecuados y rentables.
os controles internos que se utilizan en el entorno informático continúan evolucionando hoy en día a medida que los sistemas informáticos se vuelven complejos.

Los progresos que se producen en la tecnología de soportes físicos y de software han modificado de manera significativa los procedimientos que se empleaban tradicionalmente para controlar los procesos de aplicaciones y para gestionar los sistemas de información.

CONTROLES INTERNOS INFORMÁTICOS: CLASIFICACIÓN
Controles preventivos.- para tratar de evitar el hecho, como un software de seguridad que impida los accesos no autorizados al sistema.

Controles detectivos.- cuando fallan los preventivos, para tratar de conocer cuanto antes el evento. Por ejemplo, el registro de intentos de acceso no autorizados, el registro de la actividad diaria para detectar errores u omisiones, etc.

Controles correctivos.- facilitan la vuelta a la normalidad cuando se han producido incidencias. Por ejemplo, la recuperación de un fichero dañado a partir de las copias de seguridad.

RELACIÓN EXISTENTE ENTRE LOS MÉTODOS DE CONTROL, LOS OBJETIVOS DE CONTROL Y LOS OBJETIVOS DE AUDITORÍA

A medida que los sistemas se han vuelto más complejos, los controles informáticos han evolucionado hasta convertirse en procesos integrados en los que se atenúan las diferencias entre las categorías tradicionales de controles informáticos.

Por ejemplo, en los actuales sistemas informáticos puede resultar difícil ver la diferencia entre seguridad de los programas, de los datos y objetivos de control del software del sistema, porque el mismo grupo de métodos de control satisface casi totalmente los tres objetivos de control.

La relación entre los métodos de control y los objetivos de control puede demostrarse en el siguiente. Ejemplo, en el que un mismo conjunto de métodos de control se utiliza para satisfacer objetivos de control tanto de mantenimiento como de seguridad de programas:

Objetivo de control de mantenimiento: asegurar que las modificaciones de los procedimientos programados estén adecuadamente diseñadas, probadas, aprobadas e implantadas.

Objetivo de Control de seguridad de programas: garantizar que no se puedan efectuar cambios no autorizados en los procedimientos programados.

IMPLANTACIÓN DE UN SISTEMA DE CONTROL INTERNO INFORMÁTICO

CRITERIO BÁSICO

Los controles pueden implantarse a varios niveles.

La evaluación de controles de tecnología de la Información exige analizar diversos elementos interdependientes. Por ello es importante conocer bien la configuración del sistema, para poder identificar los elementos, productos, herramientas que existen para saber donde pueden implantarse los controles, así como para identificar los posibles riesgos.

CONOCER LA CONFIGURACIÓN DEL SISTEMA

Para llegar a conocer la configuración del sistema es necesario documentar los detalles de la red, así como los distintos niveles de control y elementos relacionados:

Entorno de red..- esquema de la red, descripción de la configuración de hardware de comunicaciones, descripción del software que se utiliza como acceso a las telecomunicaciones, control de red, situación general de los ordenadores de entornos de base que soportan las aplicaciones críticas y consideraciones relativas a la seguridad de la red.

Configuración del ordenador base.- configuración del soporte físico, entorno del sistema operativo, software con particiones, entornos (pruebas y real), bibliotecas de programas y conjunto datos.

Entorno de aplicaciones.- procesos de transacciones, sistemas de gestión de base de datos y entornos de procesos distribuidos.

Productos y herramientas.- software para desarrollo de programas, software de gestión de bibliotecas y para operaciones automáticas.

Seguridad del ordenador base.- identificar y verificar usuarios, control de acceso, registro e información, integridad del sistema, controles de supervisión, etc.

PARA LA IMPLANTACIÓN DE UN SISTEMA DE CONTROL INTERNO INFORMÁTICO DEBE DEFINIRSE:

Gestión de sistemas de información.- política, pautas y normas técnicas que sirvan para el diseño y la implantación de los sistemas de información y de los controles correspondiente.

Administración de sistemas.- controles sobre la actividad de los centros de datos y otras funciones de apoyo al sistema, incluyendo la administración de las redes.

Seguridad.-
incluye las tres clases de controles fundamentales implantados en el software del sistema, integridad del sistema, confidencialidad (control de acceso) y disponibilidad.

Gestión de cambio.- separación de las pruebas y la producción a nivel de software y controles de procedimientos para la migración de programas software aprobados y probados.

RESPALDO PARA LA IMPLANTACIÓN DE UNA POLÍTICA Y CULTURA DE SEGURIDAD

Dirección de Negocio o Dirección de Sistemas de Información (S.I).- Define la política y/o directrices para los sistemas de información en base a las exigencias del negocio, que podrán ser internas o externas.

Dirección de Informática.- Ha de definir las normas de funcionamiento del entorno informático y de cada una de las funciones de informática mediante la creación y publicación de procedimientos, estándares, metodología y normas, aplicables a todas las áreas de informática así como a los usuarios, que establezcan el marco de funcionamiento.

Control Interno Informático.- ha de definir los diferentes controles periódicos a realizar en cada una de las funciones informáticas, de acuerdo al nivel de riesgo de cada una de ellas, y ser diseñados conforme a los objetivos de negocio y dentro del marco legal aplicable. Estos se plasmarán en los oportunos procedimientos de control interno y podrán ser preventivos o de detección. Periódicamente realizará la revisión de controles establecidos de Control Interno Informático informando las desviaciones a la Dirección de Informática y sugiriendo cuantos cambios crea convenientes en los controles, así como trasmitirá constantemente a toda la organización de Informática la cultura y políticas de riesgo informático.

Auditor interno/externo informático.- ha de revisar los diferentes controles internos definidos en cada una de las funciones informáticas y el cumplimiento de normativa interna y externa, de acuerdo al nivel de riesgo, conforme a os objetivos definidos por la Dirección de Negocio y la Dirección de Informática. Informará a la Alta Dirección de los hechos observados y al detectarse deficiencias o ausencias de controles recomendarán acciones que minimicen los riesgos que puedan originarse. La creación de un sistema de control informático es una responsabilidad de la Gerencia y un punto destacable de la política en el entorno informático.
CONTROL INTERNO Y AUDITORÍA
CONTROLES INTERNOS PARA SISTEMAS DE INFORMACIÓN

AGRUPADOS POR SECCIONES FUNCIONALES Y QUE SERÍAN LOS QUE CONTROL INTERNO INFORMÁTICO Y AUDITORÍA INFORMÁTICA DEBERÍAN VERIFICAR PARA DETERMINAR SU CUMPLIMIENTO Y VALIDEZ

CONTROLES DE DESARROLLO, ADQUISICIÓN Y MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN

Para que permitan alcanzar la eficacia del sistema, economía y eficiencia, integridad de los datos, protección de los recursos y cumplimiento con las leyes y regulaciones.

Metodología del ciclo de vida del desarrollo de sistemas. Principales controles:

La Alta Dirección debe publicar una normativa sobre el uso de metodología de ciclo de vida de desarrollo de sistemas y revisar ésta periódicamente.

La metodología debe establecer los papeles y responsabilidades de las distintas áreas del Departamento de Informática y de los Usuarios, así como la composición y responsabilidades del equipo del proyecto.

Las especificaciones del nuevo sistema deben ser definidas por los usuarios y quedar escritas y aprobadas antes e que comience el proceso de desarrollo.

Debe establecerse un estudio tecnológico de viabilidad en el cual se formulen formas alternativas de alcanzar los objetivos acompañadas de un análisis costo-beneficio de cada alternativa.

Cuando se seleccione una alternativa debe formularse el plan director del proyecto. En dicho plan deberá existir una metodología de control de costos.

CONTROLES EN LA METODOLOGÍA DE DESARROLLO DE SISTEMAS

Procedimientos para la definición y documentación de especificaciones de: diseño, de entrada, de salida, de ficheros, de procesos, de programas, de controles de seguridad, de pistas de auditoría, etc.

Plan de validación, verificación y pruebas.

Estándares de prueba de programas, de pruebas de sistemas.

Plan de conversión: prueba de aceptación final.

Los procedimientos de adquisición de software deberán seguir las políticas de adquisición de la organización y dichos productos deberán ser probados y revisados antes de pagar por ellos y ponerlos en uso.

La contratación de outsourcing debe estar justificada mediante una petición escrita de un director del proyecto.

Deberán prepararse manuales de operación y mantenimiento como parte de todo proyecto de desarrollo o modificación de sistemas de información, así como manuales de usuario.

EXPLOTACIÓN Y MANTENIMIENTO

El establecimiento de controles asegurará que los datos se traten de forma congruente y exacta y que el contenido de sistemas sólo será modificado mediante autorización adecuada.

Algunos controles que deben implantarse:

Procedimiento de control de explotación.

Sistema de contabilidad para asignar usuarios de costos asociados con la explotación de un sistema de información.
Procedimientos para realizar un seguimiento y control de los cambios de un sistema de información.

CONTROLES DE EXPLOTACIÓN DE SISTEMAS DE INFORMACIÓN
Planificación y Gestión de recurso: definir el presupuesto operativo del Departamento, Plan de adquisición de equipos y gestión de la capacidad de los equipos.

Controles para usar de manera efectiva los recursos en ordenadores:

Calendario de carga de trabajo.

Programación de personal.

Mantenimiento preventivo del material.

Gestión de problemas y cambios.

Procedimientos de facturación a usuarios.

Sistemas de gestión de la biblioteca de soportes.

Procedimientos de selección del software del sistema, de instalación, de mantenimiento, de seguridad y control de cambios.

SEGURIDAD FÍSICA Y LÓGICA

Definir un grupo de seguridad de la información, siendo una de sus funciones la administración y gestión del software de seguridad, revisar periódicamente los informes de violaciones y actividad de seguridad para identificar y resolver incidentes.

Controles físicos para asegurar que el acceso a las instalaciones del Dpto. de Informática quede restringido a las personas autorizadas.

Control de visitas: personas externas a la organización.

Instalación de medidas de protección contra el fuego.

Formación y concientización en procedimientos de seguridad y evacuación del edificio.

Control de acceso restringido a los ordenadores.

Normas que regulen el acceso a los recursos informáticos.

Existencia de un plan de contingencias para el respaldo de recursos de ordenador críticos y para la recuperación de los servicios del Dpto. Informático después de una interrupción imprevista de los mismos.

CONTROLES DE APLICACIONES

Cada aplicación debe llevar controles incorporados para garantizar la entrada, actualización, validez y mantenimiento completos y exactos de los datos.

Aspectos más importantes en el control de datos:
Control de entrada de datos: procedimientos de conversión y de entrada, validación y corrección de datos.

Control de tratamientos de datos para asegurar que no se dan de alta, modifican o borran datos no autorizados para garantizar la integridad de los mismos mediante procesos no autorizados.

Controles de salidas de datos: sobre el cuadre y reconciliación de salidas, procedimientos de distribución de salidas, de gestión de errores en las salidas, etc.

CONTROLES ESPECÍFICOS DE CIERTAS TECNOLOGÍAS

Controles en sistemas de Gestión de Base de datos.

Sobre el software de gestión de BD para preveer el acceso a la estructuración de y el control sobre los datos compartidos, deberá instalarse y mantenerse de modo tal que asegure la integridad del software, las bases de datos y las instrucciones de control que definen el entorno.

Que están definidas las responsabilidades sobre la planificación, organización, dotación y control de los activos de datos, es decir, un administrador de datos.

Que existen procedimientos para la descripción y los cambios de datos así como para el mantenimiento del diccionario de datos.

Sobre el acceso de datos y la concurrencia.
Para minimizar fallos, recuperar el entorno de las bases de datos hasta el punto de la caída y minimizar el tiempo necesario para la recuperación

Controles para asegurar la integridad de los datos: programas de utilidad para comprobar los enlaces físicos – punteros – asociados a los datos, registros de control para mantener los balances transitorios de transacciones para su posterior cuadre con totales generados por el usuario o por otros sistemas.

CONTROLES ESPECÍFICOS DE CIERTAS TECNOLOGÍAS

Planes adecuados de implantación, conversión y pruebas de aceptación para la red.

Existencia de un grupo de control de red.

Controles para asegurar la compatibilidad de conjunto de datos entre aplicaciones cuando la red es distribuida.

Procedimientos que definan las medidas y controles de seguridad a ser usados en la red de informática en conexión con la distribución del contenido de bases de datos entre los departamentos que usan la red.
Que se identifiquen todos los conjuntos de datos sensibles de la red y que se han determinado las especificaciones para su seguridad.

Existencia de inventario de todos los activos de la red.

Existencia de mantenimiento preventivo de todos los activos.

Que existen controles que verifican que todos los mensajes de salida se validan de forma rutinaria para asegurar que contienen direcciones de destino válidas.

Controles de seguridad lógica: control de acceso a la red, establecimiento de perfiles de usuario.

Procedimientos de cifrado de información sensible que se transmite a través de la red.

Procedimientos de cifrado de información sensible que se transmite a través de la red.

Procedimientos automáticos para resolver cierres del sistema.

Monitorización para medir la eficiencia de la red.

Diseñar el trazado físico y las medidas de seguridad de las líneas de comunicación local dentro de la organización.

Detectar la correcta o mala recepción de mensajes.

Identificar los mensajes por una clave individual de usuario, por terminal y por el número de secuencia del mensaje.

Revisar los contratos de mantenimiento y el tiempo medio de servicio acordados con el proveedor.

Determinar si el equipo multiplexor/concentrador/procesador frontal remoto tiene lógica redundante y poder de respaldo con realimentación automática para casos de fallas.

Asegurarse de que haya procedimientos de recuperación y reinicio.

Asegurarse de que existan pistas de auditoría que puedan usarse en la reconstrucción de los archivos de datos y de las transacciones de los diversos terminales. Debe existir la capacidad de rastrear los datos entre el terminal y el usuario.

Considerar circuitos de conmutación que usen rutas alternativas para diferentes paquetes de información provenientes del mismo mensaje; esto ofrece una forma de seguridad en caso alguien intercepte los mensajes.

FUNCIÓN CONTROL EN LOS SISTEMAS

Función control esparcida en la empresa.

Consecuencia del desarrollo empresarial.

Especialización de sus áreas con infraestructura tecnológica.

Decisiones basadas en información confiable, adecuado en tiempo y forma.

Administración de empresas apoyada en tecnología.

Persona encargadas de control: cómo hacer para obtener efectividad en sus funciones, si no participan en el desarrollo de los sistemas.Tendencia se invierte con activa participación de la función de control en el desarrollo, implementación y seguimiento de los sistemas de informática.

martes, 23 de febrero de 2010

LEGALIDAD DE LA ADQUISICIÓN DE SOFTWARE Y GESTIÓN DE LOS SERVICIOS Y BIENES INFORMÁTICOS EN ENTIDADES Y DEPENDENCIAS DEL SECTOR PÚBLICO

LEGALIDAD DE LA ADQUISICIÓN DE SOFTWARE Y GESTIÓN DE LOS SERVICIOS Y BIENES INFORMÁTICOS EN ENTIDADES Y DEPENDENCIAS DEL SECTOR PÚBLICO

Introducción

El Estado Peruano, en el marco de la administración eficiente de los recursos, emite normativas que deberán ser implementadas por los responsables de la administración de cada institución.
Muchas de estas normativas están relacionadas a la Legalidad de la Adquisición de Software y Gestión de los Servicios y Bienes Informáticos.

La presente sesión de clase esta orientada a conocer algunas normas que permitirán desarrollar actividades de control relacionadas a la Legalidad de la Adquisición de Software y Gestión de los Servicios y Bienes Informáticos.

NORMATIVAS
LEGALIDAD DE SOFTWARE
DECRETO LEGISLATIVO 822 - LEY SOBRE EL DERECHO DE AUTOR.

Artículo 37º.- Siempre que la Ley no dispusiere expresamente lo contrario, es ilícita toda reproducción, comunicación, distribución, o cualquier otra modalidad de explotación de la obra, en forma total o parcial, que se realice sin el consentimiento previo y escrito del titular del derecho de autor.

Artículo 188º.- La Oficina de Derechos de Autor podrá imponer conjunta o indistintamente, las siguientes sanciones:

a) Amonestación.
b) Multa de hasta 150 Unidades Impositivas Tributarias.
c) Reparación de las omisiones.
d) Cierre temporal hasta por treinta días del establecimiento.
e) Cierre definitivo del establecimiento.
f) Incautación o comiso definitivo.
g) Publicación de la resolución a costa del infractor.

DECRETO SUPREMO Nº 013-2003-PCM. Referido a la Legalidad de la Adquisición de programas de Software en Entidades y Dependencias del Sector Público, que menciona:

Artículo 3º.- Las entidades y dependencias del sector público, deberán implementar las medidas necesarias para asegurar que las partidas presupuestales que se elaboren a partir de la vigencia del presente Decreto, incluyan recursos suficientes para el pago de las licencias de software por adquirir, en los casos en que proceda dicho pago.
Artículo 4º.- En un plazo que no exceda del 31 de marzo de 2005, las entidades y dependencias comprendidas en la presente norma deberán inventariar los software con que cuentan, procediendo a la eliminación de aquellos que no cuenten con la respectiva licencia, en tanto se requiere dicha licencia, o a la correspondiente regularización con los titulares de derechos sobre los mismos. Copia de dicho inventario será remitida a la Presidencia del Consejo de Ministros y al Instituto Nacional de Estadística e Informática – INEI, para coordinar el proceso de regularización al que hace referencia este artículo.

Artículo 5º.- Las entidades y dependencias comprendidas en la presente norma, deberán adoptar las siguientes acciones:
  • Otorgar al Jefe de Informática o al funcionario que cada entidad señale, la responsabilidad decertificar el cumplimiento de las medidas señaladas en el Decreto Supremo.
  • Adoptar la Guía para la Administración Eficiente del Software Legal en la Administración Pública.
  • Desarrollar y mantener un adecuado sistema de actualización del inventario de software de la entidad o dependencia según sea el caso.
  • Incluir expresamente el requerimiento de autorización o licencia legalmente emitida de todo proceso de compra estatal de software legal, en tanto dicha autorización o licencia se requiera.
  • Desarrollar acciones informativas dirigidas al personal de cada institución con el objeto de asegurar la correcta administración del software y el cumplimiento de las obligaciones contenidas en la presente norma.

DECRETO SUPREMO Nº 037-2005-PCM

  • Que modifica el D.S. Nº 013-2003-PCM, fijando plazo para que las entidades públicas cumplan con inventariar los software que utilizan.
  • Artículo 1º.- Modifíquese el texto del artículo 4º del Decreto Supremo Nº 013-2003-PCM en los términos siguientes:
  • “En un plazo que no exceda del 31 de diciembre de 2006, las entidades y dependencias comprendidas en la presente norma deberán inventariar los software con que cuenten, procediendo a la eliminación de aquellos que no cuenten con la respectiva licencia, en tanto se requiere dicha licencia, o a la correspondiente regularización con los titulares de derechos cobre los mismos. Copia de dicho inventario será remitida a la Presidencia del Consejo de Ministros para coordinar el proceso de regularización al que hace referencia este artículo”.

DECRETO SUPREMO Nº 002-2007-PCM

“Mediante el cual modifican el Decreto Supremo Nº 013-2003-PCM y establecen disposiciones referidas a licenciamiento de software en entidades públicas.

Artículo 1º.- Modificación del artículo 4º del Decreto Supremo Nº 013-2003-PCM.

Modifíquese el texto del artículo 4º del Decreto Supremo Nº 013-2003-PCM en los términos siguientes:

“En un plazo que no excederá del 31 de julio de 2008, las entidades y dependencias comprendidas en la presente norma deberán inventariar los software con que cuenten, procediendo a la eliminación de aquéllos que no cuenten con la respectiva licencia, en tanto se requiera dicha licencia, o a la correspondiente regularización con los titulares de derechos sobre los mismos. Copia de dicho inventario será remitida a la Oficina Nacional de Gobierno Electrónico e Informática de la Presidencia de Consejo de Ministros”.

Artículo 2º.- Equivalencias.
En un plazo de 45 días calendario, contados a partir de la vigencia del presente Decreto Supremo, la Oficina Nacional de Gobierno Electrónico e Informática publicará en el Portal del Estado Peruano un informe conteniendo las equivalencias entre software privado y software de libre disponibilidad como recomendación para la implantación de software de libre disponibilidad en las instituciones públicas.

Artículo 3º.- Adquisiciones.
Los procesos de selección de contrataciones y adquisiciones de computadoras personales que convoquen las entidades y dependencias del Sector Público durante el presente ejercicio fiscal, deberán considerar de manera obligatoria el sistema operativo y la herramienta ofimática base de acuerdo a los perfiles de usuario determinados por la institución.

Artículo 4º.- Responsable.
La Oficina Nacional de Gobierno Electrónico e Informática será responsable de determinar las condiciones necesarias para el correcto licenciamiento del software privado actualmente en uso de la administración pública.

DECRETO SUPREMO Nº 053-2008-PCM

Modifica en artículo 4º del Decreto Supremo Nº 013-2003-PCM para el cumplimiento de la Administración Pública de las normas vigentes en materia de Derechos de Autor en el Marco de la Reforma del Estado y la implementación del Acuerdo de Promoción Comercial Perú – Estados Unidos.

Establece en el Artículo 1º, se modifique el texto del Artículo 4º del D.S. Nº 013-2003-PCM en los términos siguientes.

“En un plazo que no excederá del 31 de octubre de 2008, las entidades y dependencias comprendidas en la presente norma deberán inventariar los software con que cuenten, procediendo a la eliminación de aquellos que no cuenten con la respectiva licencia, en tanto se requiera dicha licencia, o a la correspondiente regularización con los titulares de derechos sobre los mismos. Copia de dicho inventario será remitida a la Oficina Nacional de Gobierno Electrónico e Informática de la Presidencia del Consejo de Ministros”.

DECRETO SUPREMO Nº 077-2008-PCM

Modifican el Artículo 4º del Decreto Supremo Nº 013-2003-PCM para el cumplimiento en la Administración Pública de las normas vigentes en materia de derechos de autor en el marco de la reforma del Estado y la implementación del Acuerdo de Promoción Comercial Perú – Estados Unidos.

Que, luego de definirse los plazos para el uso de software legal por la administración pública, conforme al Artículo 4º del Decreto Supremo Nº 013-2003-PCM, modificado por los artículos 1º del Decreto Supremo Nº 037-2005-PCM, 1º del Decreto Supremo Nº 002-2007-PCM y 1º del Decreto Supremo Nº 053-2008-PCM, y mejorar los niveles de uso de software legal en todos los estamentos del Estado, de acuerdo a los informes de seguimiento realizados por la Oficina Nacional de Gobierno Electrónico e Informática de la Presidencia del Consejo de Ministros, se hace necesario adoptar acciones conducentes a garantizar su efectiva aplicación e implementación, y generar el marco adecuado para la reforma y modernización del Estado Peruano.

Artículo 1º.- Modificación del artículo 4º del Decreto Supremo Nº 013-2003-PCM. Modifíquese el artículo 4º del Decreto Supremo Nº 013-2003-PCM en los términos siguientes:

“El Estado iniciará un programa de renovación del parque informático que permita acelerar el proceso de modernización de la infraestructura tecnológica estatal, reemplazando antes del 31 de diciembre de 2011 los equipos necesarios para tal fin, asegurando con ello el uso de software legal en la administración pública.

Artículo 1º.- Modificación del artículo 4º del Decreto Supremo Nº 013-2003-PCM. Modifíquese el artículo 4º del Decreto Supremo Nº 013-2003-PCM en los términos siguientes:

“El Estado iniciará un programa de renovación del parque informático que permita acelerar el proceso de modernización de la infraestructura tecnológica estatal, reemplazando antes del 31 de diciembre de 2011 los equipos necesarios para tal fin, asegurando con ello el uso de software legal en la administración pública.

Las entidades y dependencias comprendidas en la presente norma deberán realizar anualmente el inventario del software con que cuentan, procediendo a la eliminación de aquel software que no cuente con la respectiva licencia en tanto ésta sea requerida para su uso, o procediendo a regularizar el uso de las licencias con los titulares de los derechos sobre el software respectivo. Copia de dicho inventario será remitida a la Oficina Nacional de Gobierno Electrónico e Informática de la Presidencia del Consejo de Ministros”.

RESOLUCION JEFATURAL Nº 199-2003-INEI.

Que en su artículo 1°, aprueba la Directiva Nº 008-2003-INEI/DTNP, sobre “Normas Técnicas para la administración del Software Libre en los Servicios Informáticos de la Administración Pública”.

DIRECTIVA Nº 008-2003-INEI/DTNP.

Referido a las normas técnicas para la administración del software libre en los servicios informáticos de la administración pública. Tiene como objetivo, dar lineamiento para el uso correcto y seguro del software libre.

II. Alcance: La presente Directiva es de cumplimiento por las entidades del Poder Ejecutivo, Legislativo y Judicial, Organismos Autónomos, Organismos Públicos Descentralizados, Gobiernos Regionales, Locales y Empresas Públicas a nivel nacional.

7.1 La Oficina de Informática (o la que haga sus veces) de cada entidad es la responsable de establecer, en el marco del Plan Estratégico de Tecnología de Información y de lo establecido en el Decreto Supremo Nº 013-2003-PCM, la implantación del software libre en una entidad pública.

RESOLUCIÓN MINISTERIAL Nº 073-2004-PCM.

Referido a la aprobación de la Guía para la Administración Eficiente del Software Legal en la Administración Pública.

Que en el Artículo 1º aprueba la Guía para la Administración Eficiente del Software Legal en la Administración Pública.

Así mismo menciona en el Artículo 2º que las entidades de la Administración Pública, integrantes del Sistema Nacional de Informática, deberán aplicar lo establecido en el Artículo 1º, siendo responsabilidad de las áreas de informática o de las que hagan sus veces, la implementación y aplicación de la presente norma.

En el artículo 3º indica que la áreas de informática o las que hagan sus veces, desarrollarán acciones informativas y de capacitación dirigidas al personal de cada institución, con el objeto de asegurar la correcta aplicación de lo establecido en el artículo 1º. Para tal efecto realizarán las coordinaciones correspondientes con las áreas de personal o las que hagan sus veces en la entidad.

GUÍA PARA LA ADMINISTRACIÓN EFICIENTE DE SOFTWARE LEGAL EN LA ADMINISTRACIÓN PÚBLICA

Establece:

En el Capítulo II, cuarto párrafo que garantiza el cumplimiento de la Ley, indica que; además de los acuerdos de licencia, la ley de derechos de autor protege, a los autores del software, de la reproducción y distribución no autorizada de software. La misma Ley prohíbe también que los usuarios carguen, descarguen o transmitan copias no autorizadas de software por Internet u otros medios electrónicos. Las violaciones de estas restricciones pueden constituir delitos, los cuales exponen al infractor a sanciones de hasta 8 años de pena privativa de la libertad, así como a multas de hasta 150 Unidades Impositivas Tributarias.

Control de costos de adquisición. Un proceso de administración eficaz reduce al mínimo los costos de adquisición de software a identificar y comunicar las necesidades de software actuales y futuras de una institución, elaborar oportunamente el presupuesto para la adquisición de software y concretar la compra solamente de aquellos recursos que se consideren necesarios en conformidad con los procedimientos de adquisición claramente identificados.

La preparación del presupuesto es clave. Deben identificarse los gastos planificados de software como una partida separada dentro del presupuesto para TI y realizar seguimiento de los gastos actuales en comparación con los proyectados. De esta manera puede evaluarse en forma más exacta las necesidades, garantizar que el software adquirido sea legal y planificar futuras adquisiciones. Como un dato adicional, cabe anotar que las organizaciones de envergadura a menudo dedican el 25 por ciento de sus presupuestos de TI a software.

Evitar procesos legales, sanciones y multas. Es deber de una institución evitar los costos en los procesos legales, las multas y las sanciones mediante la puesta en vigor del proceso de administración de activos de software descrito en la presente guía (al que hace referencia la Resolución Ministerial Nº 073-2004-PCM). El proceso generará un registro de los documentos necesarios para evitar estos riesgos.

El registro incluirá:

Una declaración escrita de la política de software de su organización

Pruebas de la aceptación y el entendimiento por parte de los empleados de la política, el proceso de administración y las responsabilidades

Un inventario completo y actual de los activos de software

Documentación sobre todas las medidas adoptadas en apoyo del proceso de administración y de aquellas señaladas en el Decreto Supremo Nº 013-2003-PCM.

En el Capítulo III, la guía en mención indica lo siguiente:
Realizar un inventario de software es un componente crítico del proceso de administración. Se debe identificar todo el software instalado en las computadoras de la institución, así como recopilar y almacenar en un depósito seguro las licencias y la documentación para el software cuyo uso en la institución haya sido aprobado.

El área de informática debe mantenerla actualizada mediante la renovación periódica de la lista de software autorizado por la institución y la actualización, en caso sea necesaria, de los términos de los acuerdos de licencias. Además, se deben adoptar medidas preventivas para reducir a un mínimo la necesidad de acciones correctivas en el futuro.

  • Formular y comunicar una política de software. la declaración política que formule la institución debe darse a conocer a los empleados a través de los diversos medios disponibles: correo electrónico, intranet, periódico mural, reuniones de trabajo, otros.
  • Especificar, comunicar y solicitar la aceptación. Inicialmente, generar apoyo mediante la especificación y la comunicación clara de una política para software, una jerarquía de mando y las responsabilidades de cada empleado. Incluir la información en el manual de funciones del empleado. Distribuir la información en cursos de orientación para nuevos empleados.
  • Evitar la confusión y solicitar a cada empleado que lea y acepte la declaración. Es necesario probar que cada empleado recibió información, ha entendido y aceptado cumplir la política interna para administración y uso de software.
  • Educar. La formación es un elemento importante para obtener la aceptación de los empleados. La institución debe diseñar un programa de formación que ofrezca preparación en tres áreas generales:
  • Comprender la declaración de la política, incluido el proceso de administración, los procedimientos de compra y las responsabilidades de los empleados.
  • Saber determinar si el software o su uso es ilegal
  • Reconocer cómo aprovechar las ventajas del activo del software utilizado por la organización.

Formas de administración. Una correcta administración de software incluye dos etapas:

  • Realizar un inventario inicial de software, y después
  • Establecer políticas y procedimientos para mantener el software sobre una base continua.

Perfil del usuario. El perfil de Usuario de Software debe ser elaborado y administrado por la Oficina de Informática para la estandarización, control y optimización del uso de los programas, según las necesidades de la institución.

Sobre el Capítulo IV, menciona lo siguiente:

Lineamientos sobre el Uso del Software y del Perfil de Usuario.

  • Los programas desarrollados en la institución y los encargados a terceros deben ser elaborados bajo los estándares de programación, leguajes y herramientas de desarrollo elaborados por la Oficina de Informática de la institución en coordinación con el área del usuario, de acuerdo con los requerimientos del Sistema definido por ellos.
  • Todo software elaborado en la institución debe ser revisado y aprobado por la Oficina de Informática. Asimismo, se sugiere su registro ante la Oficina de Derechos de Autor del INDECOPI.
  • Cada usuario debe utilizar únicamente el software que la oficina de Informática haya instalado de acuerdo al Perfil de Usuario para el uso de software, asignado según las actividades que desempeñan.
  • La Oficina de Informática de la institución deberá evaluar constantemente los programas y/o actualizaciones existentes en el mercado tecnológico para su posible incorporación dentro de la lista de programas estandarizados. Un usuario puede poseer más de un Perfil de Uso.
  • No deberá estar permitido instalar otros programas que no estén incluidos en el Perfil de Usuario, aún cuando sean éstos legales y de propiedad del usuario, salvo en casos autorizados por la Oficina de Informática con la licencia o certificado de autorización de uso del fabricante, demostrando además que son utilizadas por un periodo corto y su productividad en las labores asignadas. Igual caso se considera para los programas llamados “freeware” y “shareware”, salvo en este último caso el cual se debe eliminar una vez culminado su período de prueba. Dentro de los programas que pueden ser instalados, se encuentran los llamados “parches” o “actualizaciones” que los fabricantes distribuyen de forma gratuita para optimizar sus productos.
  • lineamientos de instalación / desinstalación
  • La Oficina de Informática deberá ser exclusivamente quien pueda instalar y desinstalar los programas en los equipos de los usuarios. Esta disposición deberá ser expresa.
  • Todos los equipos que requieran la instalación de software deben cumplir los requerimientos mínimos para su funcionamiento.
  • Es recomendable que toda solicitud de instalación de software debe estar debidamente justificada por intermedio y autorización del Jefe directo del usuario solicitante, mediante correo electrónico el cual deberá contener al menos: Nombre del Usuario del equipo a instalarse el software, Cargo, Código Patrimonial del CPU, programas requeridos, versión y período de uso así como la justificación de la solicitud.
    Lineamientos para Software base, Aplicaciones, Manejadores de Base de Datos y/o utilitarios.Es recomendable que la Oficina de Informática instale los programas en los equipos recientemente asignados según su Perfil de Usuario, eliminando aquellos que no correspondan con el nuevo perfil. En caso de no ser totalmente nuevo, se procederá a formatear el disco duro e instalar los programas.

DIRECTIVA Nº 007-95-INEI-SJI.

  • Referido a las recomendaciones técnicas para la seguridad e integridad de la información que se procesa en la administración pública. En el numeral 5.1 estipula que; En los procedimientos administrativos es recomendable la identificación previa del personal que va a ingresar a las áreas de cómputo, verificando si cuenta con la autorización correspondiente y registrándose el ingreso y salida del área.
  • En el numeral 5.11 de la presente Directiva, indica que; Cuando desee proteger especialmente una base de datos se preverá en su desarrollo, que esté garantizado un límite de instalaciones (licencias autorizadas), para su uso.

DIRECTIVA Nº 016-2002-INEI/DTNP.

Referido a las Normas Técnicas para el Almacenamiento y Respaldo de la Información Procesada por las Entidades de la Administración Pública. Establece que:

6.2.1 Copias de los medios de almacenamiento de la información se ubicarán en otro(s) local(es) distante(s) de la institución. La institución designará un responsable para realizar esta labor.

6.3.2 La Oficina de Informática especificará y documentará en el Plan de Contingencias institucional, los procedimientos utilizados en el respaldo de la información.

6.4.9 La Oficina de Informática (o la que haga sus veces) informará periódicamente a los usuarios, el cronograma de respaldo de información, asimismo, hará de conocimiento general las políticas de seguridad y respaldo de información.

RESOLUCIÓN JEFATURAL Nº 0181-2002-INEI

Referido a la aprobación de la Guía Teórico Práctica para la elaboración de Planes Estratégicos de Tecnología de Información – PETI. En su Artículo 2º establece que; Los órganos confortantes del Sistema Nacional de Informática deberán elaborar el Plan Estratégico de Tecnologías de Información de su institución, en base a la Guía Teórico Práctica aprobada en el Artículo 1º de la presente Resolución.

DIRECTIVA Nº 008-95-INEI/SJI.

Referido a las Recomendaciones Técnicas para la Protección de los Equipos y Medios de Procesamiento de la Información en la Administración Pública. Establece que:

Evitar los cableados sueltos o dispersos, éstos deberán entubarse.

Para combatir los incendios producidos por equipos eléctricos se deben utilizar extintores, hechos preferentemente de bióxido de carbono, productos químicos secos y líquido vaporizado. Estos estarán al alcance inmediato, preservando la vigencia química del extintor, e identificando su localización en el respectivo plano.

6.1Es recomendable que el acceso a los centros de cómputo sea restringido al personal autorizado, contándose con un registro de entradas y salidas de visitantes.

6.8 Contará con un plan de contingencia, así como con estrategias adecuadas para hacer frente a los desastres. Entre el área de cómputo y las demás áreas, se establecerán acuerdos acerca de las condiciones bajo las cuales el plan de contingencias ha de ser activado, considerándose la duración probable de la falta de servicio, y la pérdida (total o parcial) de la capacidad de procesamiento en una o varias instalaciones, etc.

DIRECTIVA Nº 016-94-INEI/SJI.

Referido a las Normas para la Prevención, Detección y Eliminación de Virus Informático en los Equipos de Cómputo de la Administración Pública. Establece que:
Por ningún motivo debe usarse los servidores de red como estaciones de trabajo.

DIRECTIVA Nº 010-95-INEI/SJI.

Referido a las Recomendaciones Técnicas para la Organización y Gestión de los Servicios Informáticos para la Administración Pública. Establece que:

5.1. Los tipos o formas de brindar un Servicios Informático, son los siguientes:

Centro de Cómputo, es la dependencia responsable del procesamiento automático de datos, se caracteriza por disponer de equipos de cómputo de gran capacidad operativa. Este tipo de dependencia corresponde a una organización centralizada de servicios informáticos, por lo que su gestión está basada sobre Áreas Especializadas.

5.12 Toda institución pública que disponga de un Centro de Cómputo, de Unidades de Cómputo de Usuario y Usuarios que dispongan de Computadoras deberá normar sus actividades, con la finalidad de garantizar un adecuado y ordenado desarrollo del Servicio Informático para la institución, a fin de evitar conflictos de índole técnico – administrativo que pudieran presentarse.

RESOLUCION MINISTERIAL Nº 139-2004-PCM.

Referido a la “Guía Técnica Sobre Evaluación de Software para la Administración Pública”. Establece que:

Artículo 1.- Aprobar el documento “Guía Técnica Sobre Evaluación de Software para la Administración Pública”, documento que será publicado en el Portal de la Presidencia del Consejo de Ministros (www.pcm.gob.pe)

Artículo 2.- Las entidades de la Administración Pública, integrantes del Sistema Nacional de Informática, deberán aplicar lo establecido en la “Guía Técnica Sobre Evaluación de Software para la Administración Pública” en los productos de software que desarrollen o adquieran a partir de la fecha de publicación de la presente Resolución.

GUÍA TÉCNICA SOBRE EVALUACIÓN DE SOFTWARE PARA LA ADMINISTRACIÓN PÚBLICA

PARTE 2: MÉTRICAS.

2.2. Métrica Interna.- …En el desarrollo de un producto de software, los productos intermedios deben ser evaluados usando métricas internas que permitan medir las propiedades intrínsecas, incluyendo aquellas que puedan derivarse de comportamientos simulados. El propósito primario de esta métrica interna es asegurar que se logre la calidad externa y la calidad de uso requerida. La métrica interna proporciona a los usuarios, evaluadores, verificadores y desarrolladores el beneficio de que puedan evaluar la calidad del producto de software y lo referido a problemas de calidad antes de que el producto de software sea puesto en ejecución.

2.3. Métrica Externa.- …Antes de adquirir o usar un producto de software, éste debe ser evaluado usando las métricas basadas en los objetivos del área usuaria de la institución relacionados al uso, explotación y dirección del producto, considerando la organización y el ambiente técnico. La métrica externa proporciona a los usuarios, evaluadores, verificadores y desarrolladores, el beneficio de que puedan evaluar la calidad del producto de software durante las pruebas o el funcionamiento.

PARTE 3: PROCESO DE EVALUACIÓN DE SOFTWARE

Todo proceso de evaluación de software deberá partir de una evaluación cualitativa y derivar en una evaluación cuantitativa, siendo todo el proceso documentado, cumpliendo los siguientes pasos:

3.1 Establecer el propósito de la evaluación:
Productos intermedios:

  • Decidir sobre la aceptación de un producto intermedio de un subcontratista o proveedor.
  • Decidir cuándo un proceso está completo y cuando remitir los productos al siguiente proceso.
  • Predecir o estimar la calidad del producto final.
  • Recoger información con objeto de controlar y gestionar el proceso.
  • Otros con justificación.

Producto final:

  • Decidir sobre la aceptación del producto.
  • Decidir cuándo publicar el producto.
  • Comparar el producto con otros productos competitivos.
  • Seleccionar un producto entre productos alternativos.
  • Valorar tanto el aspecto positivo, como el negativo, cuando está en uso.
  • Decidir cuándo mejorar o reemplazar un producto.
  • Otros con justificación.


3.10 Documentación

  • Todo el proceso de evaluación debe estar documentado, indicando nombres y apellidos, cargos, procedencia de las personas que participaron en el proceso de evaluación, especificando las etapas en las que participaron, si es necesario. Este documento deberá ser aprobado por el Jefe de Informática o quien haga sus veces.

COMENTARIOS

14.- Se realizó la verificación de adquisición de computadoras y licencias de software en los dos últimos años (2008 y 2009). De la verificación realizada en el Sistema Electrónico de Adquisiciones y Contrataciones del Estado – SEACE, respecto a la compra de computadoras en el ejercicio 2008 por parte de la Institución, se pudo identificar que, con proceso de selección Nº XXXXX, se llevó acabo la adquisición de 4 computadoras y dos impresoras. En las bases de convocatoria para la adquisición de estos equipos no contempla el software que utilizarán las 4 computadoras, obteniendo la buena pro el 22/08/2008 la empresa SISTERET SRL. Del mismo modo en el ejercicio 2009, con proceso de selección Nº YYYYYY, se llevó acabo la adquisición de un equipo servidor y con proceso de selección Nº ZZZZZZ, se efectuó la adquisición de 10 computadoras, para ambas adquisiciones, las bases de convocatoria no contempla el software que utilizarán los equipos, obteniendo la buena pro el proveedor Cayo Julca.

CONCLUSIONES

4.- En los procesos de selección de contrataciones y adquisiciones de computadoras personales que convoca la Institución, no considera el sistema operativo y la herramienta ofimática base, incumpliendo al artículo 3º del Decreto Supremo Nº 002-2007-PCM. (Comentario 14).

RECOMENDACIONES

4.- En los procesos de selección de contrataciones y adquisiciones de computadoras personales que convoque la Institución, deberá considerar de manera obligatoria el sistema operativo y la herramienta ofimática base de acuerdo a los perfiles de usuario determinados por la institución, en cumplimiento al artículo 3º del Decreto Supremo Nº 002-2007-PCM. (Conclusión 4)