• No se han encontrado resultados

ESPECIFICACIÓN DE MÉTRICAS PARA LA EVALUACIÓN DE LA SEGURIDAD EN PRODUCTOS SOFTWARE

N/A
N/A
Protected

Academic year: 2020

Share "ESPECIFICACIÓN DE MÉTRICAS PARA LA EVALUACIÓN DE LA SEGURIDAD EN PRODUCTOS SOFTWARE"

Copied!
11
0
0

Texto completo

(1)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

35

ESPECIFICACIÓN DE MÉTRICAS PARA LA EVALUACIÓN DE LA

SEGURIDAD EN PRODUCTOS SOFTWARE

METRICS SPECIFICATION FOR EVALUATING SECURITY AT

SOFTWARE PRODUCTS

González Obregón, W., Almeida González, G., Díaz Fuentes, D.

Universidad de las Ciencias Informáticas

Resumen

Garantizar la confidencialidad, autenticidad y disponibilidad de la información consiste en un proceso de vital importancia en la actualidad. Para cumplir estos principios, los distintos productos software deben lograr que los datos que manejan sean utilizados de la manera que se decidió. Teniendo en cuenta lo anterior, no solo es necesario planear y ejecutar un conjunto de actividades para lograr la seguridad de un sistema informático, sino efectuar procedimientos de control, que permitan asegurar que dichas actividades se realizaron de acuerdo a parámetros establecidos. En el presente trabajo se estudian modelos, normas y estándares para garantizar la seguridad informática en estos productos, proponiendo, a partir de este estudio, un conjunto de 5 métricas seleccionadas para evaluar su seguridad y planteando una especificación de las variables que las componen.

Palabras clave

: Evaluación de la seguridad, métrica, seguridad informática.

Abstract

Ensure the confidentiality, authenticity and availability of information is a vital process today. To achieve these principles, the different software products must ensure that the data they handle are used in the manner previously decided. Having this into consideration, it is not only necessary to plan and execute a set of activities to achieve the security of a computer system, it will also require the development of control procedures which allows that such activities were performed according to established parameters. In this research, models, norms and standards to ensure security in these products are studied, proposing based on this study, a set of 5 selected metrics to evaluate its safety and proposing a specification of the variables that compose them.

(2)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

36

1. Introducción

En el siglo XXI, la información se ha convertido en uno de los activos más importante de todo negocio a proteger. En el entorno empresarial se expresa esta preocupación, pues toda entidad siempre se encuentra expuesta al robo o sabotaje de información por parte de la competencia, antiguos empleados o personas que deseen hacerlo por el simple hecho de obtener alguna ganancia o beneficio. En consonancia con esto, la seguridad informática se ha visto obligada a perfeccionar sus técnicas, debido a la equivalente evolución de la calidad de los ataques desarrollados por los intrusos sobre los productos software, que manejan como principal elemento dicha información. Los métodos de intrusión en los sistemas informáticos se han desarrollado mediante herramientas de ataques cada vez más sofisticadas y automatizadas. Los atacantes han evolucionado de tal forma, que si al principio penetrar en un sistema informático era tarea solo de piratas informáticos; hoy lo pueden hacer personas con escasos conocimientos, pero que gracias a los avances en el campo de la computación cuentan con herramientas automatizadas que hacen prácticamente todo el trabajo.

Este aumento de ataques informáticos, representa un nuevo desafío para controlar y evaluar la seguridad de la información, provocando un incremento en las exigencias de los clientes por adquirir productos de software más seguros que garanticen la confidencialidad, autenticidad y disponibilidad de los datos.

Ante estas circunstancias, la implementación de esquemas de administración de la seguridad informática, en mayoría se rige por criterios a tener en cuenta durante el desarrollo de los sistemas de computación, se enfoca en políticas o procedimientos organizacionales o apuntan a áreas muy específicas de negocio y no tanto en la evaluación del producto final sin importar su temática (1).

Teniendo en cuenta esta necesidad, el presente trabajo aborda las principales normas, estándares y modelos de seguridad con el objetivo de proponer una forma de evaluar la confidencialidad, autenticidad y disponibilidad de la información que manejan los productos software para garantizar su seguridad.

2. Desarrollo

(3)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

37

con esta definición, no solo es necesario planear y ejecutar un conjunto de actividades, sino efectuar procedimientos de control que permitan asegurar que dichas actividades se realizaron de acuerdo a parámetros establecidos. En el caso de un producto software, la evaluación de su seguridad consiste en determinar el nivel de confidencialidad, autenticidad y disponibilidad de la información que maneja (1; 2; 3).

El presente trabajo aborda los principales elementos de normas, estándares y modelos relacionados con las anteriores definiciones, mediante la aplicación de un método analítico-sintético, que permita a partir de la documentación consultada, proponer una forma de evaluar la seguridad de productos software.

2.1 Normas, estándares y modelos para el control de la Seguridad Informática

En la presente investigación se asume como estándar un documento aprobado por consenso por un organismo reconocido, que proporciona reglas, pautas y/o características para uso común, con el objetivo de obtener un óptimo nivel de resultados en un contexto dado. Los estándares brindan los medios para que todos los procesos se realicen siempre de la misma forma, mientras surjan ideas para mejorarlos. Una norma es toda actividad documentada que guía el comportamiento de un grupo de personas, es decir, qué hay que proteger y cómo; mientras que como modelo de seguridad se entiende la expresión formal de una política de seguridad y se utiliza como directriz para evaluar los sistemas de información, entendiendo como formal el que estará redactado fundamentalmente en términos técnicos y matemáticos.

(4)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

38

anteriormente. Por su parte, la ISO (International Organization for Standardization) y la IEC (International Electrotechnical Commission), han desarrollado un conjunto de estándares que proporcionan un marco de gestión de la seguridad de la información utilizable por cualquier tipo de organización, destacando la ISO 9126 para la evaluación de la calidad del software. Esta fue actualizada por el proyecto SQuaRE (Software Product Quality Requeriments and Evaluation), ISO 25000:2005, el cual sigue los mismos conceptos. El objetivo general de la creación del estándar ISO/IEC 25000 SQuaRE es organizar, enriquecer y unificar las series que cubren dos procesos principales: especificación de requerimientos de calidad del software y evaluación de la calidad del software, soportada por el proceso de medición de calidad (4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15).

En Cuba ha sido elaborada una norma cubana NC ISO/IEC 17799: 2007, elaborada por el Comité Técnico de Normalización NC/CTN 18 de Tecnología de la Información, en el que están representadas las siguientes organizaciones: Ministerio de las Comunicaciones, SEGURMATICA, DESOFT, Universidad de las Ciencias Informáticas (UCI), Universidad Central “Marta Abreu” de Las Villas, Ministerio de Ciencia, Tecnología y Medio Ambiente (CITMATEL), Instituto Superior Politécnico José A. Echeverría, Ministerio de Salud Pública (Centro de Control Estatal de Equipos Médicos), Oficina de Seguridad de las Redes Informáticas y la Oficina Nacional de Normalización. Esta norma es una adopción idéntica por el método de traducción de la Norma Internacional ISO/IEC 17799:2005. Se cuenta también en el tema en el ámbito nacional además con la NC ISO/IEC 9126-1, titulada Modelo de Calidad, adaptación también de la norma internacional de igual numeración (16).

Los estándares, normas y modelos mencionados son solo algunos de los existentes y, pese a la diversidad, la mayoría comparte una estructura común forzando un ciclo de desarrollo y definiendo la documentación requerida así como una serie de técnicas y buenas prácticas a seguir en cada una de las fases del desarrollo de un producto software, es común también su aplicación en un área específica de negocio. De los anteriores, los estándares propuestos por la ISO/IEC destacan por proponer recomendaciones de las mejores prácticas en la gestión de la seguridad de la información a todos los interesados y responsables en iniciar, implantar o mantener sistemas de gestión de la seguridad de la información. Se destacan además, por proponer métricas para su aplicación. Teniendo en cuenta los elementos anteriores, la propuesta de métricas para evaluar los productos software, el amplio reconocimiento a nivel mundial y la aplicación con éxito en otros atributos de calidad, se decide adoptar esta variante de los estándares de la ISO/IEC en la presente investigación, realizando la adaptación de las métricas necesarias.

2.2 ¿Qué son las métricas?

(5)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

39

El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) en su Glosario Estándar de Terminología de Ingeniería de Software define una métrica como: “una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado”. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas (17).

Para que sea útil en el contexto del mundo real, una métrica debe ser fácil de obtener, que se entienda por qué y para qué se utiliza, que los cálculos no produzcan resultados ambiguos, y que la interpretación de valores obtenidos esté acorde a las nociones intuitivas del ingeniero de software. Las características que debe tener una métrica son (18):

 Simple y fácil de calcular: Debería ser relativamente fácil de aprender a obtener la métrica y su cálculo no obligar a un esfuerzo o a una cantidad de tiempo inusuales.

 Empírica e intuitivamente persuasiva: La métrica debería satisfacer las nociones intuitivas del ingeniero de software sobre el atributo del producto en cuestión (por ejemplo: una métrica que mide la cohesión de un módulo debería aumentar su valor a medida que crece el nivel de cohesión).

 Consistente en el empleo de unidades y tamaños: El cálculo matemático de la métrica debería utilizar medidas que no lleven a extrañas combinaciones de unidades. Por ejemplo, multiplicando el número de personas de un equipo por las variables del lenguaje de programación en el programa resulta una sospechosa mezcla de unidades que no son intuitivamente concluyentes.

 Independiente del lenguaje de programación: Las métricas deberían apoyarse en el modelo de análisis, modelo de diseño o en la propia estructura del programa. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación.

 Un eficaz mecanismo para la realimentación de calidad: La métrica debería suministrar al desarrollador de software información que le lleve a un producto final de superior calidad.  Consistentes y objetivas: La métrica debería siempre producir resultados sin ambigüedad. Un

tercer equipo debería ser capaz de obtener el mismo valor de métrica usando la misma información del software.

2.3 Categorías de las métricas

Roger Pressman (autor de: Ingenieria del Software. Un Enfoque Práctico) clasifica el campo de las métricas en 6 categorías o grupos de métricas distintos: Métricas técnicas, Métricas de calidad, Métricas de productividad, Métricas orientadas al tamaño, Métricas orientadas a la función, Métricas orientadas a la persona.

(6)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

40 2.4 Métricas de seguridad

Las métricas de seguridad son herramientas diseñadas para facilitar la toma de decisiones y mejorar resultados mediante la recogida, análisis y elaboración de información sobre datos relevantes relacionados con los procesos de seguridad y sus resultados. Una métrica de seguridad podría definirse como el conjunto de preceptos y reglas, necesarios para poder medir de forma real el nivel de seguridad de una organización.

Las métricas de seguridad permiten conocer el estado de la seguridad de una forma clara y concisa huyendo de “falsas expectativas”. Anticiparse a las necesidades, de forma que puedan preverse las inversiones necesarias para garantizar, al menos, el cumplimiento de los objetivos de seguridad de la entidad. Disponer de herramientas que permitan a los responsables de seguridad realizar informes detallados del estado de sus sistemas y detectar las variaciones que puedan producirse en la seguridad. En general, el uso de las métricas se está poniendo en práctica con éxito en el amplio mercado del software pues las empresas productoras están reconociendo la importancia que tienen las mediciones para cuantificar y por consiguiente gestionar de forma más efectiva la seguridad del software (19).

2.5 Especificación de métricas

En el presente trabajo se propone para la evaluación de productos software una especificación de las métricas de seguridad propuestas por la Norma Internacional ISO/IEC TR 9126-2, la 9126-3 y la 25010, esta última es una versión actualizada de la ISO 9126 que incorpora nuevas pautas para medir con mayor exactitud la seguridad de un software, por lo que ambas normas siguen los mismos conceptos generales. La norma internacional ISO/IEC 25010 en su Informe Técnico Internacional ha añadido la seguridad como una característica, en lugar de una subcaracterística de funcionalidad que es como aparece en la ISO 9126. La Norma Internacional ISO/IEC TR 9126 a pesar de ser de las más antiguas se ha extendido en todo el mundo y en Cuba es una de las más utilizadas. Dicha norma se divide en cuatro partes: modelo de la calidad (9126-1); métricas externas (9126-2); métricas internas (9126-3); y modelo de la calidad durante el uso la 9126-4 (20; 21).

La selección y especificación de las métricas de seguridad se ha efectuado con el objetivo de realizar una evaluación lo más completa posible, pues la seguridad en los sistemas de software nunca es completa, siempre está expuesta a nuevos ataques informáticos aún más potentes. No obstante, las métricas de seguridad seleccionadas tienen presente las principales características relativas a la protección de los sistemas de información ante ataques provocados, lo que permite evaluar el nivel de cumplimiento deseado de los requisitos de seguridad que se hayan especificado en las etapas de análisis del software, estas características son:

(7)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

41

 Identidad: Es relativo al grado en que se identifican a los sujetos antes de interactuar con ellos.

 Detección de ataques: Es el grado en que los intentos de ataque o los ataques realizados con éxito son detectados, almacenados y notificados.

 Integridad: Es el grado en que se protege a los componentes de los sistemas de información de alteraciones intencionadas por parte de sujetos no autorizados.

 Confidencialidad: Es el grado en el que se asegura que la información es solamente accesible a sujetos autorizados.

La recolección de los datos es uno de los momentos más importantes en el proceso para obtener el valor de la métrica. Los datos deben ser recogidos con precisión ya que de ellos depende que las métricas calculadas sean lo más real posible. A continuación se presenta la adecuación de las métricas seleccionadas y se realiza una especificación de las mismas mediante la propuesta de obtención de cada uno de los valores de las variables que las componen:

Auditabilidad de acceso. Descripción: ¿Cuán completo es el registro de las auditorías correspondientes a los accesos de los usuarios al sistema y los datos? Fórmula:

X= (A/B)*100 (1)

Variables: A - Número de usuarios que han ejecutado datos en el sistema. Para obtener este valor es necesario consultar la base de datos o registro de información que maneje el software y buscar todos los usuarios que han accedido al sistema y realizado alguna acción de manera exitosa que expone datos del mismo, para esto se sugiere y resulta de gran aplicación en la actualidad en la mayoría de los sistemas la gestión de trazas. B - Número de usuarios que han accedido al sistema. De manera semejante al anterior, para obtener este valor es necesario consultar la base de datos o registro de información que maneje el software y buscar todos los usuarios que han accedido al sistema, para esto se sugiere y resulta de gran aplicación en la actualidad la gestión de trazas, que almacene el registro de estas acciones realizadas sobre el software. De tomar valor cero no aplica la métrica, pues si no existe ningún acceso al sistema no sería necesario llevar a cabo la auditabilidad del proceso de acceso. Rango: 0 <= X <= 100. A mayor cercanía al valor 100 resultará mejor. Estándar que propone la métrica: ISO/IEC 9126-2.

Prevención de la corrupción de datos. Descripción: ¿Qué tan completa es la implementación de la prevención de la corrupción de datos? Fórmula:

X= 1 - (A/B) (2)

(8)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

42

aparezcan como usuarios autorizados para ejecutarlas. B – Número de posibles eventos de corrupción de datos. Para obtener este valor es necesario consultar la base de datos o registro de información que maneje el software y obtener el número total de acciones ejecutadas en el sistema, considerando que toda acción puede ocasionar la corrupción de los datos hasta diferenciar entre usuarios autorizados y no autorizados para ejecutar estas acciones. De tomar valor cero no aplica la métrica, pues de no existir la ejecución de ninguna acción sobre los datos no se sustenta por esta vía la necesidad de comprobar la corrupción de los mismos. Rango: 0 <= X <= 1. A mayor cercanía al valor 1 resultará mejor. Estándar que propone la métrica: ISO/IEC 9126-3.

Integridad de la información. Descripción: Permite conocer el grado en que se protege a los sistemas de información de alteraciones intencionadas por parte de sujetos no autorizados. Fórmula:

X= A*0.01 (3)

Variables: A - Número de vulnerabilidades tratadas para las que se han aplicado parches o han sido mitigadas. Para la obtención de este valor se propone manejar un documento de control de cambios del producto, donde se registren los cambios realizados al mismo para tratar vulnerabilidades identificadas. El número total de estos cambios consiste en el valor de esta variable. Rango: 0 <= X <= 1. A mayor cercanía al valor 1 resultará mejor. Estándar que propone la métrica: ISO/IEC 25010.

Identificación y autenticación. Descripción: Permite conocer el grado en el que se garantiza que los sujetos y recursos del sistema de información son auténticos. Fórmula:

X= (A/B)*100 (4)

Variables: A - Número de usuarios con acceso a cuentas compartidas. Para obtener este valor es necesario consultar la base de datos o registro de información que maneje el software y buscar la cantidad de usuarios que comparten los mimos roles. Esto significa que estos usuarios tienen los mismos permisos y pueden manejar la misma información. B - Número total de usuarios. Para obtener este valor es necesario consultar la base de datos o registro de información que maneje el software y obtener el número total de usuarios registrados. De tomar valor cero no aplica la métrica, pues no existen usuarios sobre los cuales aplicar la identificación y autenticación. Rango: 0 <= X <= 100. A mayor cercanía al valor 0 resultará mejor. Estándar que propone la métrica: ISO/IEC 25010.

Control de acceso. Descripción: Permite conocer el grado en el que se verifica la identidad de los sujetos antes de interactuar con ellos. Fórmula:

(9)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

43

Variables: A - Número de puntos de acceso remoto usados para obtener accesos no autorizados. Este valor consiste en el número de identificadores de dispositivos (ejemplo: el IP de una computadora) que intentan acceder al sistema y que no tienen autorización para hacerlo. Para esto se sugiere el manejo del control de acceso al sistema por subredes y la gestión de trazas que almacene el identificador del dispositivo que intenta acceder. B - Número total de puntos de acceso remoto. Este valor consiste en el número total de identificadores de dispositivos (ejemplo: el IP de una computadora) registrados como autorizados para acceder al sistema. Para esto se sugiere el manejo del control de acceso al sistema por subredes, funcionalidad que brindan la mayoría de los gestores de bases de datos en la actualidad. De tomar valor cero no aplica la métrica, pues de no existir puntos de acceso válidos no existe parámetro de referencia para corroborar el control de acceso. Rango: 0 <= X <= 100. A mayor cercanía al valor 0 resultará mejor. Estándar que propone la métrica: ISO/IEC 25010.

Las 5 métricas anteriores cubren los principales elementos que definen la seguridad informática y sus variables se especifican en términos de elementos que habitualmente componen un producto software o que se recomiendan administren. De no poder identificar los valores de las variables mediante la especificación propuesta o una equivalente, es decir, concluyendo que el sistema que se evalúa no gestiona estos elementos de ninguna forma, puede considerarse como inadecuado el nivel de seguridad en ese aspecto. Los valores independientes de cada métrica evaluada que se puedan obtener, permiten establecer el nivel de seguridad informática del producto software en un aspecto determinado. Para establecer un nivel de seguridad general del producto basta con determinar una forma de relación entre estas, en dependencia de las características del sistema. A partir de la aplicación de las métricas anteriores se puede entonces evaluar la seguridad de productos software e identificar los aspectos a perfeccionar.

3. Conclusiones

La seguridad informática establece dentro de sus principales elementos la confidencialidad, autenticidad y disponibilidad de la información. La evaluación de la seguridad de productos software se basa entonces en determinar el nivel de cumplimiento de estos elementos.

Para lograr una correcta y eficiente evaluación del software en el presente trabajo se tienen en cuenta normas, estándares y modelos de seguridad. La mayoría de estos propone acciones a desarrollar durante la creación del sistema informático y es común su aplicación en un área de negocio específica.

Teniendo en cuenta lo anterior se seleccionaron las métricas propuestas por estándares de la ISO/IEC para realizar dicha evaluación, especificando las variables que las componen para facilitar su aplicación.

(10)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

44

4. Referencias

(1) Holbrook, P. and Reynolds, J., “Site Security Handbook”, LA, Network Working Group, 1991.

(2) Malagón Poyato, Ch., Monserrat Coll, F. and Martínez Moreno, D., RedIris, 2000. [En línea]. [Accesado el 2 Septiembre 2013]. Disponible en: http://www.rediris.es/cert/doc/docu_rediris/recomendaciones/html/recomendaciones.html.

(3) TSEC, Information Technology Security Evaluation Criteria: Preliminary Harmonised Criteria, 1991. [En línea]. [Accesado el 4 Mayo 2013]. Disponible en: http://www.ssi.gouv.fr/site_documents/ITSEC/ITSEC-uk.pdf.

(4) AENOR, “UNE-EN-50128 Aplicaciones ferroviarias. Sistemas de comunicación, señalización y procesamiento. Software para sistemas de control y protección de ferrocarril”, 2002.

(5) ECSS, “ECSS-ST-40C Space Engineering. Software”, 2009.

(6) HIS, “Source Code Metrics. Herfseller Initiative Software”, 2008.

(7) IEC, “IEC-26262-6 Road vehicles – Functional safety. Part 6. Product development. Software Level”, 2009.

(8) IEC, “IEC-61508-3 Seguridad funcional de los sistemas eléctricos, electrónicos y electrónicos-programables relacionados con la seguridad. Parte 3: Requisitos del Software (soporte lógico)”, IEC, 2004.

(9) IEC, “IEC-61513 Nuclear power plants. Instrumentation and control for systems important to safety. General requirements for systems”, 2011.

(10)ISACA, An Introduction to the Business Model for Information Security, 2009. [En línea]. [Accesado el 3 Mayo 2013]. Disponible en: http://www.isaca.org/Knowledge-Center/Research/Documents/Intro-Bus-Model-InfoSec-22Jan09-Research.pdf.

(11)ISACA, Business-Model-for-Information-Security, 2013. [En línea]. [Accesado el 3 Mayo 2013]. Disponible en: http://www.isaca.org/Knowledge-Center/BMIS/Pages/Business-Model-for-Information-Security.aspx.

(12)ISACA, COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, 2013. [En línea]. [Accesado el 3 Mayo 2013]. Disponible en: www.isaca.org/cobit.

(13)NASA, “NASA 8739.8 Software assurance standard”, 2004.

(14)OSIATIS, ITIL V3 Gestión de servicio TI, 2013. [En línea]. [Accesado el 4 Mayo 2013].

Disponible en:

(11)

Iberoamerican Journal of Project Management (IJoPM). www.riipro.org/journal. Vol.5, No.1, A.I., pp.35-45. 2014.

45

(15)RTCA, “RTCA, DO-178B. Software Considerations in Airborne Systems and Equipment Certification”, 1992.

(16)NC/CTN, “Norma cubana ISO/IEC17799:2005”, Comité Técnico de Normalización, Habana, Oficina nacional de normalización, 2007.

(17)IEEE, “IEEE 610.12-1990 Standard Glossary of Software Engineering Terminology”, 2002.

(18)Pressman, R. “Ingenieria del Software. Un Enfoque Práctico. 6ta Edición”, 2009.

(19)Castillo, E., Evaluación de la seguridad de los sistemas informáticos, 2009. [En línea].

[Accesado el 5 Mayo 2013]. Disponible en:

http://www.tescam.edu.mx/principal/sylabus/fpdb/recursos/r78013.doc.

(20)ISO, “ISO/IEC FDIS 25010:2010(E)”, 2012.

(21)ISO, “ISO/IEC TR 9126-3”, 2005.

Correspondencia

Ing. William González Obregón

Subdirección de Producción, CEIGE. Facultad 3. Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños km 2 ½. Torrens, La Lisa.

La Habana, Cuba.

Teléfonos: 0053-78358244, 0053-78372317 E-mail: wobregon@uci.cu

Ing. Giselle Almeida González

Subdirección de Producción, CEIGE. Facultad 3. Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños km 2 ½. Torrens, La Lisa.

La Habana, Cuba.

Teléfonos: 0053-78358290 E-mail: galmeida@uci.cu Ing. Dailys Díaz Fuentes

Subdirección de Producción, CEIGE. Facultad 3. Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños km 2 ½. Torrens, La Lisa.

La Habana, Cuba.

Referencias

Documento similar

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)

D) El equipamiento constitucional para la recepción de las Comisiones Reguladoras: a) La estructura de la administración nacional, b) La su- prema autoridad administrativa

b) El Tribunal Constitucional se encuadra dentro de una organiza- ción jurídico constitucional que asume la supremacía de los dere- chos fundamentales y que reconoce la separación