5.

NIVELES DE MADUREZ PARA EL PROCESO DE SEGURIDAD DE

LA INFORMACIÓN.

Basado en el Modelo CMMI y en la Norma ISO/IEC 17799 se desarrollo un modelo de

madurez para la seguridad de la información, con el propósito de ayudar a los
encargados de evaluar la seguridad de la información de la organización, a determinar
en que nivel o grado se encuentra está y así tomar decisiones al respecto que permitan
identificar las falencias que se tienen en un determinado nivel.

Figura 7: Niveles de Madurez

NIVEL 1 NIVEL 2 NIVEL 3 NIVEL 4 NIVEL 5

NIVEL 1 NIVEL 2 NIVEL 3 NIVEL 4 NIVEL 5

Fuente: Adaptado del Modelo CMMI para Seguridad de la Información.

 Cuadro 13. Niveles de Madurez para la Seguridad de la Información.

NIVELES DE MADUREZ

Descripción

Se identifican en forma general los activos de la organización.

Se clasifican los activos de la organización como la información,

la seguridad, los equipos y la sede, para así poder darle la
protección adecuada a cada uno de ellos.

Se observan eventos que atentan contra la información, los

activos y la continuidad del negocio, pero no se le da la debida
Nivel 1 importancia a estos eventos.
(Inicial) Los empleados no tienen conciencia de la seguridad informática
(prestan sus claves, dejan sus equipos sin cerrar sesión).

Se responde reactivamente a las amenazas de intrusión, virus,

robo de equipos y de información.

No se cuenta con un grupo interdisciplinario para tratar temas

de seguridad informática dentro de la organización.

Se cuenta con un proceso de desarrollo de software, pero este

no tiene en cuenta las normas de la seguridad informática.

Nivel 2 Descripción
(Gestionado) Se empiezan a definir las Políticas de Seguridad de la
Información de la organización basada en la Norma ISO/IEC
17799 debido a que se incrementa el interés por buscar las
causas que originaron la ocurrencia de los eventos que
atentaron contra la información, los activos y la continuidad del
negocio. Además se cuenta con un plan de divulgación de las
Políticas de Seguridad de la Información.

Se cuenta con un grupo interdisciplinario, con el cuál se busca

trabajar temas de seguridad informática que sean de interés
para la organización.
 De la clasificación de los activos se genera un inventario del
hardware y software que hay en la organización.

Se identifican riesgos asociados con la información, los equipos

de cómputo y las sedes, así mismo se identifican
vulnerabilidades de éstos por medio de las políticas.

Se empieza a elaborar un informe de los incidentes de seguridad

ocurridos.

Se cuentan con Planes de continuidad del negocio, que

contemplan solo los procesos críticos del negocio (los que
garantizan la continuidad del mismo), no obstante se dejan
otros procesos de la organización por fuera.

Los roles del área de Seguridad Informática están bien definidos

y se lleva un registro de las actividades que realiza cada rol.

Se va incluyendo la seguridad informática dentro del proceso de

desarrollo de software, pero aún en la metodología de desarrollo
de software de la organización no se documenta esta inclusión.

Se empieza a observar en los empleados una conciencia de la

seguridad informática, pero aún no demuestran un compromiso
con ella.

Nivel 3 Descripción
(Definido) Se divulgan las Políticas de Seguridad de la Información en toda
la organización.

El grupo interdisciplinario divulga a cada una de las áreas a las

que representan, las medidas de seguridad que deberán ser
tomadas para la conservación de la información de la
organización.

Se empieza a observar un compromiso de los empleados con la

seguridad informática.

Se incluye dentro del proceso de desarrollo de software las

normas de seguridad informática.

Se van estableciendo los controles y las medidas necesarias

 para disminuir los incidentes y para prevenir su ocurrencia en el
futuro.

Se cuenta con procedimientos que enseñan a los empleados a

manejar la información y los equipos de cómputo en forma
segura.

Se monitorea la red de la organización, como una medida

preventiva contra intrusiones, o infecciones de virus.

Descripción

Se hacen revisiones periódicas o monitoreos a los activos de la

organización.

Se utiliza un indicador de cumplimiento para establecer si las

Políticas de Seguridad de la Información y las cláusulas de
seguridad establecidas por la organización en los contratos de
trabajo, están siendo acatadas correctamente.

Se realizan de manera sistemática pruebas a los controles, para

Nivel 4
determinar si están funcionando correctamente.
(Gestionado
Cuantitativamente) Se hacen simulacros de incidentes de seguridad, para probar la
efectividad de los planes de respuesta a incidentes.

Se realizan pruebas a las aplicaciones o software desarrollados,

para verificar que sí están cumpliendo con los requisitos de
seguridad definidos en la metodología de desarrollo de software
de la organización.

Se hacen pruebas de intrusión a los equipos de cómputo de la

organización, para detectar, claves débiles o fáciles de adivinar,
y accesos a ciertos sistemas por usuarios no autorizados.

Nivel 5 Descripción
(En Optimización) Los empleados apoyan y contribuyen al mejoramiento de la
seguridad informática en la organización.

La organización aprende continuamente sobre los incidentes de

seguridad presentados.

Se deben analizar los datos arrojados por la evaluación de

 seguridad de la información para que se puedan definir acciones
preventivas mas claras.

Se incluyen todas las áreas de la organización (críticas y no

críticas), en los planes de respuesta a incidentes.

Fuente: Elaboración Propia

5.1. LOS NIVELES DE MADUREZ CON SUS RESPECTIVAS PRÁCTICAS DE

SEGURIDAD.

Cuadro 14. Prácticas de Seguridad al Interior de Cada Nivel

Nivel 1 Práctica de la Norma ISO/IEC 17799

(Inicial) 5.2 Clasificación de la Información

Nivel 2 Práctica de la Norma ISO/IEC 17799

(Gestionado) 3.1 Políticas de Seguridad de la Información

4.1.1 Foro Gerencial sobre la Seguridad de la Información

4.1.2 Coordinación de la Seguridad de la Información

4.1.3 Asignación de responsabilidades en materia de la

seguridad de la información

5.1.1 Inventario de activos o recursos de información

6.3 Respuesta a incidentes y anomalías en materia de

seguridad

10.1.1 Análisis y especificaciones de los requerimientos de

seguridad

11.1.1 Proceso de administración de la continuidad del negocio

11.1.2 Continuidad del negocio y análisis del impacto

 11.1.3 Elaboración e implementación de planes de continuidad
del negocio

11.1.4 Marco para la planificación de la continuidad del

negocio

Práctica de la Norma ISO/IEC 17799

6.2 Capacitación del usuario

7 Seguridad Física y Ambiental

Nivel 3 8.1.3 Procedimiento y manejo de incidentes

(Definido) 8.5 Administración de la red

9.4 Control de acceso a la red

9.5 Control de acceso al sistema operativo

10.2 Seguridad en los sistemas de aplicación

Práctica de la Norma ISO/IEC 17799

9.2 Administración de acceso de usuario

9.3 Responsabilidad del usuario

9.5.4 Sistema de Administración de Contraseñas

Nivel 4 9.6 Controles de Acceso a las aplicaciones

(Gestionado 9.7 Monitoreo del acceso y uso de los sistemas
Cuantitativamente)
10.3 Controles criptográficos

10.4 Seguridad de los archivos del sistema

11.1.5 Prueba, mantenimiento y reevaluación de los planes de

continuidad del negocio

12.3.1. Controles de auditoría de sistemas

Nivel 5 Práctica de la Norma ISO/IEC 17799

(En Optimización) 11.1.5.1 Mantenimiento y reevaluación del plan

Fuente: Elaboración Propia

 CALIDAD

1. CALIDAD

Según la Norma ISO/IEC 9000: Sistemas de gestión de la Calidad, la calidad es el

conjunto de características inherentes de un producto, proceso o sistema que permiten
satisfacer las necesidades y expectativas de los usuarios y de otras partes interesadas.

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad,

mantenibilidad, portabilidad, usabilidad, seguridad e integridad.

La calidad es una medida de “protección” que debe englobar, entre otros:

• Métodos y herramientas de análisis, diseño, codificación y pruebas.

• Revisiones técnicas formales.
• Estrategias de prueba.
• Control de documentación del software.
• Estándares de desarrollo.
• Mecanismos de medida de información.

Los factores que determinan la calidad del software son:

• Factores que son medidos directamente (errores, líneas de programación, tiempo

de respuesta)
• Factores que son medidos indirectamente (facilidad de uso, mantenimiento)

La Figura 8 muestra que la calidad es un conjunto de características inherentes de un

producto, proceso o sistema que permiten satisfacer las necesidades y expectativas de
los clientes y de otras partes interesadas.
 Figura 8: calidad

Fuente: Appluscorp. Costa Rica, 2004

Para entender con mayor precisión esta Figura, la explicación de cada uno de sus
elementos es la siguiente:

1.1. CONTROL DE CALIDAD

Es el conjunto de métodos y actividades de carácter operativo, que se utilizan para

satisfacer el cumplimiento de los requisitos de calidad establecidos. Estas actividades
se realizan en la etapa de construcción del software y se utiliza como método la
detección y corrección de errores por medio de las pruebas de software.

Dos conceptos muy importantes son inherentes al control de calidad:

• Garantía de la Calidad. Es la forma en que se asegura la calidad en un producto

o servicio, mediante la prevención de errores; este enfoque significa controlar la
calidad durante el proceso, o sea durante la realización del trabajo y así asegurar la
 calidad del producto y/o servicio (resultado). Con este enfoque se logra un
beneficio económico mayor.

• Círculos de Calidad. Son grupos voluntarios de individuos cuyo objetivo es lograr

la calidad y el desarrollo del personal. La preparación de un plan de control de la
calidad del software para cada proyecto es una de las principales responsables del
grupo de control de calidad.

Para lograr la calidad y la productividad en forma conjunta que nos llevará a la

creación de la infraestructura administrativa y operativa para la mejora continua, es
necesario llevar a cabo un nuevo sistema y concepto de trabajo denominado Control
Total y Mejoramiento de la Calidad, la cual se puede definir como la búsqueda continua
y participativa de la calidad en los productos, servicios y trabajos que se planeen
desarrollar. La calidad debe aplicarse a todos los niveles de la organización, sin
embargo es necesario que sea adoptada una estructura organizacional, la cual ayudará
a evitar el desperdicio de esfuerzo y de recursos.

1.1.1. Detección y Corrección. La práctica más conocida de detección de errores es

el testeo o pruebas de software. Aparte de ser un proceso de ingeniería (Verificación y
Validación) para asegurar que los requerimientos del usuario se satisfacen, las pruebas
de software también pertenecen a las actividades de detección de la gestión de la
calidad pues ellas pueden detectar fallos de calidad.

1.1.1.1. Validación. Es el proceso de evaluación de una solución o de uno de sus

componentes durante o al final del proceso de Desarrollo de Software para determinar
si se satisfacen todos los requisitos establecidos por el usuario inicialmente, es decir,
comprueba si lo que se ha especificado (y construido) es lo que el usuario realmente
desea; responde a ¿se ha construido el software correcto?
Los criterios de validación son:

• Es una meta numérica que la solución debe cumplir.

• No se puede diseñar una solución con un requerimiento específico, sin una manera
de saber si se ha logrado resolverlo o no.
• Para los requerimientos funcionales, el criterio especifica el cómo establecer si se
cumple sus objetivos.
• Para los requerimientos no funcionales, se cuantifica el comportamiento resultante.

1.1.1.2. Verificación. Es el proceso de evaluación de una solución o de uno de sus

componentes para determinar si la respuesta de una fase dada satisfacen las
condiciones impuestas al comienzo de dicha fase, es decir, comprueba la consistencia
del software con respecto a especificaciones y requisitos; responde a ¿se ha construido
correctamente el software?

Los criterios de verificación son:

• Determinar qué actividades se llevarán a cabo.

• Existencia de un responsable que construya el proceso y evalúe los resultados.
• Establecer un método de revisión.
• Elegir las áreas específicas de la solución a ser y a no ser revisadas
• Qué prioridades tienen las áreas a revisar.
• Qué riesgo conlleva el no revisar algunas áreas.

1.1.2. ¿Qué es un Error (Bug)? Es una variación en los atributos deseados para la
solución. Existen las siguientes categorías para los defectos:

• Variación Desde las Especificaciones del Producto. El producto construido

varía del producto especificado.

• Variación Desde las Expectativas del Usuario. Esta variación es algo que el
usuario quería y no está en el producto construido, pero tampoco fue incluido en
las especificaciones de la solución.
• Diferencia de Valores. Ingresar datos sin conocer la diferencia entre un valor
calculado, observado o medido y el valor verdadero, especificado o teóricamente
correcto.

• Humanos. Una acción humana que conduce a un resultado incorrecto.

Los errores se clasifican en:

• Mal Implementado. Las especificaciones han sido implementadas en forma

incorrecta. Esto podría ser por una mala especificación desde el principio o porque,
aún teniendo una buena especificación, se implementó de manera incorrecta.

• Perdido. Una especificación o requerimiento deseado no está en el producto

construido; la especificación no fue implementada. Esto podría ser una omisión
desde las especificaciones o una omisión al momento de su construcción.

• Extra. Un requerimiento que ha sido incorporado en el producto y este no fue

especificado inicialmente, este es siempre una variación de la especificación pero es
un atributo deseado por el usuario del producto. Sin embargo se considera como
un error.

• Implantación. Se refiere a todos los problemas generados por una mala

implantación en los ambientes de desarrollo, prueba o producción. Es tipo de error
es una indicación de no haberse seguido las instrucciones de la documentación de
instalación de forma correcta. Si al implantarse se siguen todas las instrucciones en
la documentación y sin embargo se presentan problemas este no será un error de
implantación sino un error tipo perdido o mal implementado.

1.1.3. ¿Qué es una Falla? Es un error que causa un problema en la operación de

una solución, dada por la interrupción o reducción de la calidad del servicio o algo que
impacta negativamente al usuario.
Este error es causado quizás por un problema de diseño, construcción, programación,
un daño físico, uso, condiciones ambientales adversas o un error humano. De este
modo, las fallas pueden aparecer tanto en el hardware como en el software. La
principal preocupación con los errores es que estos puedan convertirse en fallas. Por
este motivo se debe tratar de detectar en el ambiente de pruebas antes de salir al
ambiente de producción.

Una falla puede presentarse cuando:

• Al diseñar la solución con requerimientos incompletos o errores en la toma de

decisiones.
• Al no poder programar la solución según como lo quería el usuario, podrían resultar
errores lógicos que surgirían por la programación.
• Se omite lo necesario para comprobar si los datos de salida están completos.

1.1.4. Proceso de Pruebas

1.1.4.1. ¿Qué es Probar? Es una actividad en la cual un sistema o uno de sus

componentes es ejecutado en circunstancias previamente especificadas, de la cual los
resultados se observan y registran, y se realiza una evaluación de algún aspecto. La
prueba es un elemento crítico para la calidad de las soluciones la cual determina el
estado de una solución durante y después de su construcción.

1.1.4.2. ¿Para Qué se Prueba? Para detectar errores y establecer el nivel de

satisfacción de los requerimientos. Las pruebas permiten validar y verificar,
entendiendo como validación de soluciones el proceso que determina si la solución
satisface los requisitos, y verificación como el proceso que determina si los productos
de una fase satisfacen las condiciones de dicha fase.

1.1.4.3. ¿Qué se Prueba? Para probar un programa necesitamos una serie de datos,
los datos de entrada (input) para saber si un existe un error o no, también
necesitamos saber la salida esperada (output), además del método a utilizar. Se
prueban requerimientos funcionales, no funcionales y de usabilidad. Para medir una
prueba hay que tener en cuenta el costo que genera no detectar un error.

1.1.4.4. Tips Para Realizar Pruebas. Los principios por los que se deben guiar las
pruebas de software son:

• A todas las pruebas se les debería poder hacer un seguimiento hasta los
requisitos del usuario. El objetivo de las pruebas del software es descubrir
errores, de modo que los defectos más graves, desde el punto de vista del usuario,
son aquellos que impiden al programa cumplir sus requisitos.

• Las pruebas deberían planificarse mucho antes de que empiecen. La

planificación de las pruebas puede empezar cuando esté completo el modelo de
requisitos y la definición detallada de los casos de prueba, es decir, que puede
empezar cuando el modelo de diseño se ha consolidado, de manera que se pueden
planificar y diseñar todas las pruebas antes de generar código.

• Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo
grande”. Las primeras pruebas planeadas y ejecutadas se centran generalmente
en subsistemas individuales. A medida que avanzan las pruebas, se desplazan
hacia los grupos integrados de subsistemas y finalmente en el sistema entero.

• No son posibles las pruebas exhaustivas. El número de caminos de ejecución

para un programa de tamaño moderado es excepcionalmente grande, por lo que es
imposible ejecutar todas las combinaciones de caminos durante las pruebas. Sin
embargo es posible cubrir adecuadamente la lógica del programa y asegurarse de
que se han aplicado todas las condiciones en el diseño a nivel del componente.
• Para ser más eficaces (pruebas con la más alta probabilidad de encontrar
errores), las pruebas deberían ser realizadas por una persona de QA. El
desarrollador debe evitar probar sus propios programas, ya que desea demostrar
que funcionan sin problemas. Esta actitud inadecuada lleva a realizar pruebas
menos rigurosas de lo que sería deseable. Además, es normal que las situaciones
que ha olvidado considerar al crear el programa queden de nuevo olvidadas al
escribir los casos de prueba.

• Se debe inspeccionar a conciencia el resultado de cada prueba para, así,

poder descubrir posibles síntomas de defectos. Lamentablemente, es
frecuente pasar por alto síntomas bastantes claros de defectos, lo cual invalida
todo el esfuerzo realizado en la planificación, diseño y ejecución de pruebas.

• Cada caso de prueba debe definir el resultado de salida esperado. Este

resultado esperado es el que se compara con el resultado realmente obtenido
durante la ejecución de la prueba. Las discrepancias entre ambos se consideran
síntomas de un posible defecto en el software.

• Al generar casos de prueba, se deben incluir, tanto datos de entrada

válidos y esperados, como no válidos e inesperados. Es frecuente observar
una tendencia a centrarse en lo esperado y lo válido.

• Las pruebas deben centrarse en dos objetivos (es habitual olvidar el

segundo): (1) Probar si el software no hace lo que debe hacer. (2) Probar si
el software hace lo que no debe hacer, es decir, si provoca efectos secundarios
adversos.

• Se deben evitar los casos desechables. Se deben evitar los casos de prueba no
documentados ni diseñados con cuidado, ya que suele ser necesario probar una y
otra vez el software hasta que queda libre de defectos. No documentar o guardar
los casos significa repetir constantemente el diseño de casos de prueba.
• No deben hacerse planes de prueba suponiendo que, prácticamente, no
hay defectos en los programas, y dedicando pocos recursos a las pruebas.
Hay que asumir que siempre hay defectos, y que hay que detectarlos. En este
sentido las estadísticas confirman que, prácticamente, el 40% del esfuerzo de
desarrollo se consume en pruebas y depuración.

• La experiencia indica que donde hay un defecto hay otros. La probabilidad de

descubrir nuevos defectos en una parte del software es proporcional al número de
defectos ya descubierto.

• Las pruebas son una tarea creativa. Se han considerado las pruebas como una
tarea destructiva y rutinaria. No obstante, no existen técnicas rutinarias para el
diseño de pruebas y hay que recurrir al ingenio para alcanzar un buen nivel de
detección de defectos con los recursos disponibles.

1.1.4.5. Sistema de Pruebas.

• Para toda prueba debe haber un plan que incluye:

Objetivos para cada fase de prueba.

Cronograma y responsabilidades para cada actividad de prueba.

Disponibilidad de herramientas, documentación y librerías de prueba.

Procedimientos y estándares a ser utilizados para planear y llevar a cabo las
pruebas y reportar los resultados.

Criterios para determinar si la prueba está completa, como también del éxito de
cada prueba.

• Después de tener el plan de pruebas, se deben generar los casos de prueba,

siguiendo cualquier técnica de prueba.
• Cada caso de prueba se debe ejecutar y al final debe quedar un reporte de las
pruebas con la siguiente información:

Soluciones que se están probando, objetivo de la prueba y el plan de pruebas.

Responsables y participantes de las pruebas.

Casos de prueba.

Herramientas especiales utilizadas.

Configuraciones de hardware y software utilizadas.

Resultados de las pruebas.

Identificación de los elementos que quedan en la librería de pruebas.

Aprobación de los responsables de las pruebas y certificación de que se siguió el
procedimiento apropiado.

• Como parte del reporte del proceso de pruebas, es deseable clasificar los errores
encontrados, con el fin de tomar correctivos en el proceso de prueba o
retroalimentación para los analistas y desarrolladores.

• Las pruebas deben ser analizadas teniendo en cuenta:

Los errores graves encontrados deben ser analizados, para hallar soluciones y
maneras de que no vuelvan a ocurrir.

Analizar el tipo de error más frecuente y revisar qué ocurre y cómo se pueden
mejorar las inspecciones.

Revisar la efectividad de las pruebas y reforzar aquellas que más errores
detectan.

Los métodos y las herramientas de prueba a emplear pueden ser cualquiera,
siempre y cuando se utilicen dentro de un plan de pruebas.

• Uno de los beneficios de las autoevaluaciones es que los analistas pueden sugerir
mejoras dentro de todo el proceso de desarrollo de software, para así incrementar
su calidad y productividad en el trabajo.
1.1.4.6. Plan de Pruebas

Un plan de pruebas comprende la visión global del proceso de pruebas, y la definición

de actividades involucradas en cada una de ellas. Los objetivos del plan de pruebas
son:

• Dejar claro qué tipo de propiedades se quieren probar (corrección, robustez,

fiabilidad, amigabilidad, etc.)
• Dejar claro cómo se mide el resultado.
• Especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta)
• Definir cuál es el resultado que se espera (identificación, tolerancia, etc.) ¿Cómo se
decide que el resultado es acorde con lo esperado?

En un plan de pruebas se debería contemplar:

• Objetivos de las pruebas.

• Tipos de pruebas a ejecutar.
• El esquema de actividades de prueba.
• Los elementos a probar.
• Analista líder.
• Estrategias de prueba a utilizar.
• Entregables.
• Mecanismos de comunicación
• Ambientes y herramientas a utilizar
• Mecanismos de resolución de conflictos
• Procedimientos de aprobación.

1.1.4.7. Condiciones de Pruebas

Son descripciones de situaciones que reflejan qué se quiere probar del sistema. Para
cada una de las condiciones de prueba definidas se establece el conjunto de
variaciones y alternativas necesarias para probarla completamente. Sus
características son:
• Definir cuáles son las condiciones a probar en un sistema.
• La calidad del conjunto de condiciones elegido incidirá directamente en la calidad
de la solución obtenida.
• Cada condición debe definir clara y brevemente una situación del sistema que se
desea probar. Si se precisa más, posiblemente podría dividirse en “subcondiciones”.
• Las condiciones son descripciones generales, no tienen el detalle de qué datos se
utilizarán para probar; eso se irá especificando en los casos de prueba, al igual que
los resultados esperados de su ejecución.

1.1.4.8. Datos de Prueba.

Los datos de prueba son entradas que son ideadas para probar el sistema. Los tipos de
datos de prueba son:

• Datos Reales. Permiten probar ocurrencias y casos reales que se deben presentar
en la solución, aunque no permiten probar otras rutas programadas, las cuales son
a las que el usuario no puede acceder.

• Datos Artificiales. Son los que se crean artificialmente tratando de considerar

todas las combinaciones y rutas posibles, tratando en lo posible ser preparados
por personas distintas de los analistas y de la persona que desarrolló la solución.

1.1.4.9. Casos de Prueba.

Un caso de prueba es el conjunto de entradas del sistema con condiciones de ejecución

y las salidas esperadas a partir de esas entradas, para probar si el sistema funciona de
acuerdo con su especificación. Una vez se han definido las condiciones de prueba y se
tiene la especificación del diseño de la solución construida, se empiezan a definir los
casos necesarios para probar cada condición.
Un buen caso de prueba es aquel que tiene una alta probabilidad de descubrir un error
no encontrado hasta entonces. Este debe incluir qué se debe probar mediante la
ejecución de la condición, la alternativa y la variación específica de dicha condición, los
datos de entrada que se introducirán al sistema, los pasos a seguir para ejecutarlo y la
respuesta esperada del sistema.

Al ejecutarse el caso de prueba, debe registrarse el resultado del mismo. Si la

ejecución del caso origina errores, debe registrarse en los mismos cuál fue el caso que
los originó, para facilitar posteriormente las pruebas de regresión del error, cuando
éste haya sido corregido.

Figura 9: Sistema de Pruebas

Fuente: Roger S. Pressman. Ingeniería del Software: Un Enfoque

Práctico.

1.1.5. Gestión de Fallas

Su finalidad es prevenir, detectar, diagnosticar y solucionar fallas y falencias en

equipos y servicios para mantener la disponibilidad y continuidad operativa del
servicio, y obtener evidencia razonable de que la probabilidad de repetición de la falla
es mínima.

Los indicadores que miden este proceso son:

• Disponibilidad.
• Tiempos no cumplidos según los acuerdos de atención establecidos.
• No reincidencia de la falla.

Este proceso responde inmediatamente a problemas de afectación de los servicios o

fallas causados por errores en la infraestructura tecnológica para minimizar el impacto
sobre los usuarios y restaurar el servicio tan pronto como sea posible, investigando la
causa raíz de los problemas e iniciando las acciones para mejorar o corregir la
situación. Abarca el reporte de problemas, soluciones alternas, aislamiento de la causa
raíz y resolución.

Las fallas se pueden clasificar según la siguiente tabla:

Cuadro 15: Tipo de Fallo

Fuente: Piattini Mario G. Mantenimiento del Software: Modelos, técnicas y

métodos para la gestión del cambio. Op. Cit
 Figura 10: Origen de las Fallas del Software

Fuente: Piattini Mario G. Mantenimiento del Software: Modelos, técnicas y

métodos para la gestión del cambio. Op. Cit

1.1.6. Satisfacción del Usuario. Para evaluar la satisfacción del usuario y producir
alarmas de no cumplimiento o no satisfacción, se debe definir, negociar y hacer
seguimiento a los acuerdos de niveles de servicio. Además se deben gestionar los
riesgos asociados con los usuarios, emplear prácticas activas de comunicación para
ayudar a los usuarios a comprender lo que quieren, involucrar a los usuarios en
actividades de control del progreso de la solución y asegurar que las fallas de los
sistemas y los requerimientos de los usuarios sean resueltas en los tiempos
comprometidos.

1.2. ASEGURAMIENTO DE CALIDAD

Se define como un conjunto planificado y sistemático de todas las acciones necesarias

que proveen una confianza adecuada de que una solución fue desarrollada de acuerdo
con unos requerimientos definidos.
Estas acciones involucran actividades como probar, revisar, evaluar, auditar e informar
al analista de la solución sobre los procedimientos de calidad que se han establecido en
cada una de las fases del proceso de Desarrollo de Software.
Existen dos formas de obtener software de calidad:

• Prevenir la falta de calidad, definiendo normas, estándares, métodos y técnicas

apropiadas durante el proceso de Desarrollo de Software.

• Detectar y corregir la falta de calidad (errores en el código, en el diseño, en

manuales de usuarios, etc.) a través de las revisiones y de las pruebas de software.

El aseguramiento de calidad implica:

• Diseñar la solución de forma que satisfaga los requisitos del usuario.

• Incrementar el control en el proceso de construcción de una solución con la
documentación y procedimientos para asegurar que en cada una de las etapas de
Desarrollo de Software se ha operado correctamente.
• Controlar la calidad del proceso además de la calidad de la solución.
• Detectar errores rápidamente, al principio, donde se generan y donde es más fácil
y más barato eliminarlos.

1.3. GESTIÓN DE CALIDAD

El propósito de la gestión de calidad es desarrollar un conocimiento cuantitativo de la

calidad de los productos de software y alcanzar determinados objetivos de calidad.

Estos objetivos pueden ser:

• Planificar el aseguramiento de calidad a los proyectos

• Definir objetivos medibles para la calidad de los productos de software y sus
prioridades.
• Lograr que los objetivos de calidad para los productos de software se cuantifique y
se gestionen.
1.4. CALIDAD PERCIBIDA

La calidad percibida, se refiere a la respuesta subjetiva de las personas con respecto a

los objetos y es, por ello, un fenómeno totalmente relativo que se define entre los
juicios de valor.

La calidad percibida depende de factores como:

• Las comunicaciones externas.

• La prestación de servicios en sí, que a su vez depende de la percepción o la
sensibilidad de la dirección en cuanto a las expectativas del usuario, que a su vez
debería estar condicionado por la indagación previa sobre lo que él espera.

La calidad, además, no siempre es percibida de la misma manera. Cada persona

determina en cada momento cuál es su calidad necesaria. Este es el gran reto de la
calidad, es decir, hacer coincidir los mejores atributos en el instante que los usuarios
demanden productos y servicios, allí donde se encuentran para satisfacer las
necesidades de esos momentos y en esas circunstancias. La calidad se hace patente en
cada persona cuando quien disfruta del producto o servicio lo encuentra extraordinario,
pues cumple con lo que esperaba.

La percepción es la forma en que cada usuario recoge, procesa e interpreta la

información que proviene del entorno, es una representación subjetiva del mundo real.
La experiencia demuestra que los usuarios perciben la calidad como un concepto más
amplio, que el simple hecho de percibir la calidad de un servicio o producto adquirido.
1.5. CALIDAD TOTAL

La Calidad Total es un proceso en evolución continua y que por su naturaleza misma

no se puede detener, de lo contrario deja de ser un proceso. Podemos definirla desde 3
puntos de vista:

• Principio Unificador. Total dedicación a los usuarios para satisfacer sus

necesidades y superar sus expectativas.

• Resultados. Usuarios firmemente leales. El tiempo se reduce para que bajen los
costos. Un clima que respalde el trabajo de equipo y un desempeño más
significativo. Una ética general de mejoramiento continuo.

• Herramientas y Técnicas. Control de calidad, aseguramiento de calidad,

ingeniería para la confiabilidad, sistema justo a tiempo, desarrollo organizacional,
liderazgo (para el mejoramiento).

La Calidad Total constituye una adecuada ideología, que a través de un buen manejo,
agrega en distintas etapas, valores, vigorizando el espíritu de quienes participan de
ella mediante cambio de actitudes, con las siguientes finalidades:

• Directa. Satisfacer al usuario.

• Indirecta. Obtener lucros permanentes. Mayor penetración de mercado. Aumento
de utilidades por disminución de costos.

El concepto de Calidad Total desde la óptica de la organización, involucra las siguientes

variables que se encuentran interrelacionadas:

• Ambiente Propicio. Debe consolidarse un ambiente adecuado para el desarrollo

de la calidad total, lo cual, implica lograr una cultura uniforme, compartida por toda
la organización.

• Management. Es el corazón del sistema, el cual de un modo obsesivo está en la

búsqueda de incrementar la eficiencia y la productividad.
• Empleador. Posee un excesivo respeto por el ser humano y por sus
potencialidades, motivando al personal y reconociéndole sus esfuerzos y exitosas
intervenciones. Propiciar el cambio de actitud.

• Herramientas del Sistema. No existe la posibilidad de un correcto y eficiente

funcionamiento, sin la asistencia de 2 factores concurrentes: sistema y pasión. A
veces se tiene el sistema, pero no la pasión suficiente, y ello no alcanza; o bien, a
veces se pone mucha pasión y no se tiene el sistema adecuado.

• Planeamiento y Control Estratégico. Calidad Total primero implica un cambio en

la estrategia empresarial y luego en la estrategia competitiva; logradas ambas es
sustancial la medición del desempeño, para que existan mejoras continuas.

• Proveedores. Es parte de una cadena perfectamente eslabonada que no se puede

romper. Deben tener excesivo cuidado en entregar calidad certificada a lo largo del
tiempo.

• Personal. Es una de las variables más importantes, por el grado de

involucramiento que asume, demostrando lealtad, identificación y colaboración
permanente.

• Usuario. No se justifica el diseño de la Calidad Total, si esta no se planifica a partir

de la perspectiva del usuario, protagonista central.

1.6. CALIDAD CONCERTADA

Con objeto de garantizar la calidad de los productos y servicios adquiridos a terceros,

la organización deberá implantar un programa de gestión de proveedores, desarrollado
mediante un Sistema de Calificación y Acuerdos de Calidad concertada, como pueden
ser:

• Sistema de Calificación de Proveedores. Con este sistema se garantiza que

sólo aquellos proveedores que cumplen los estándares establecidos, pueden
 suministrar los productos o servicios demandados por la Organización. Este sistema
contempla la calificación de los proveedores en los aspectos medioambientales, de
seguridad y salud laboral, estableciendo estrictos controles a las empresas
contratistas. De forma periódica se deberá realizar el seguimiento de los
proveedores calificados, evaluando su nivel de calidad y correcta actuación, de
acuerdo con los requisitos establecidos en la documentación aplicable.

• Acuerdos de Calidad Concertada. Los acuerdos de calidad concertada existentes

con los principales proveedores, demuestran la excelente relación establecida en el
marco usuario-proveedor. En estos acuerdos se desarrollan de una manera
eficiente, las relaciones contractuales necesarias para un mayor compromiso por
parte del proveedor para garantizar la calidad de sus productos o servicios.

1.7. CALIDAD SUMINISTRADA

Es la calidad que la Organización busca en un tercero para que realice todo el proceso
de Calidad.

2. TABLA DE CORRESPONDENCIA ENTRE LA NORMA ISO/IEC

9000 Y LA NORMA ISO/IEC 17799.

Esta tabla busca facilitar a las personas encargadas de implementar la Norma ISO/IEC
17799 en su organización, a observar el control correspondiente o similar en la Norma
ISO/IEC 9000:2000 para darle un valor agregado a la hora de certificarse en
cualquiera de las dos normas.
 Cuadro 16. Correspondencia de la Norma ISO/IEC 9000 y la Norma ISO/IEC
17799

ISO/IEC 9000:2000 ISO/IEC 17799

1. Objeto y campo de aplicación

1.1. Generalidades

1.2. Aplicación

2. Referencias normativas 1. Alcance

3. Términos y definiciones 2. Términos y definiciones

4. Sistema de gestión de la calidad

4.1. Requisitos generales 0. Introducción: Cómo establecer los

requerimientos de seguridad. (3)

4.2. Requisitos de la documentación

4.2.1. Generalidades 3.1.1. Documentación de la política de la

seguridad de la información.

4.2.2. Manual de la calidad 3.1.1. Documentación de la política de la

seguridad de la información.

4.2.3. Control de los documentos 3.1.2. Revisión y evaluación

4.2.4. Control de los registros de la 3.1.2. Revisión y evaluación

calidad

5. Responsabilidad de la dirección

5.1. Compromiso de la dirección 4.1.1. Foro gerencial sobre la seguridad

de la información.

5.2. Enfoque al cliente

5.3. Política de la calidad 3.1. Política de seguridad de la

información.

5.4. Planificación

5.4.1. Objetivos de la calidad 3.1.1. Documentación de la política de la

seguridad de la información.

5.4.2. Planificación del sistema de gestión 8.2.1. Planificación de la capacidad.

de la calidad 10.5.2. Revisión técnica de cambios en el
sistema operativo.
5.5. Responsabilidad, autoridad y
comunicación

5.5.1. Responsabilidad y autoridad 4.1.3. Asignación de responsabilidades en

materia de seguridad de la información.
6.1.1. Inclusión de la seguridad en las
responsabilidades de los puestos de
trabajo.

5.5.2. Representante de la dirección 4.1.5. Asesoramiento especializado en

materia de seguridad de la información.

5.5.3. Comunicación interna 6.3.1. Comunicación de incidentes

relativos a la seguridad.
6.3.2. Comunicación de debilidades en
materia de seguridad.
6.3.3. Comunicación de anomalías de
software.

5.6. Revisión por la dirección 3.1.2. Revisión y evaluación.

5.6.1. Generalidades 4.1.7. Revisión independiente de la

seguridad de la información

5.6.2. Información para la revisión

5.6.3. Resultados de la revisión

6. Gestión de los recursos

6.1. Provisión de recursos

6.2. Recursos humanos

6.2.1. Generalidades 6.1.2. Selección y política de personal

6.2.2. Competencia, toma de conciencia y 6.2.1. Formación y capacitación en

formación materia de seguridad de la información.

6.3. Infraestructura 7.1.1. Perímetro de seguridad física.

7.1.3. Protección de oficinas, recintos e
instalaciones.
7.2.1. Ubicación y protección del
equipamiento.
7.2.2. Suministros de energía.

6.4. Ambiente de trabajo
7. Realización del producto
7.1. Planificación de la realización del
producto
7.2. Procesos relacionados con el cliente
7.2.1. Determinación de los requisitos
relacionados con el producto
7.2.2 Revisión de los requisitos
relacionados con el producto
7.2.3. Comunicación con el cliente
7.3. Diseño y desarrollo
7.3.1. Planificación del diseño y desarrollo
7.2.3. Seguridad del cableado.
7.2.4. Mantenimiento de equipos.
7.1.3. Protección de oficinas, recintos e
instalaciones.
7.1.4. Desarrollo de tareas en áreas
protegidas.
10.1.1. Análisis y especificaciones de los
requerimientos de seguridad.
11.1.1. Proceso de administración de la
continuidad del negocio.
11.1.4. Marco para la planificación de la
continuidad del negocio.
11.1.5. Prueba, mantenimiento y
reevaluación de los planes de continuidad
del negocio.
11.1.1. Proceso de administración de la
continuidad del negocio.
11.1.2. Continuidad del negocio y análisis
de impacto.
11.1.5. Prueba, mantenimiento y
reevaluación de los planes de continuidad
del negocio.
12.1.2. Derechos de propiedad
intelectual.
11.1.5. Prueba, mantenimiento y
reevaluación de los planes de continuidad
del negocio.
6.3.1. Comunicación de incidentes
relativos a la seguridad.
10.1.1. Análisis y especificaciones de los
 requerimientos de seguridad.

7.3.2. Elementos de entrada para el 10.2.1. Validación de datos de entrada.

diseño y desarrollo

7.3.3. Resultados del diseño y desarrollo 10.2.4. Validación de datos de salida.

7.3.4. Revisión del diseño y desarrollo 10.2.2. Controles de procesamiento

interno.

7.3.5. Verificación del diseño y desarrollo 10.2.2. Controles de procesamiento

interno.
10.2.4. Validación de datos de salida.

7.3.6. Validación del diseño y desarrollo 10.2.1. Validación de datos de entrada.

7.3.7. Control de cambios del diseño y 10.5.1. Procedimientos de control de

desarrollo cambios.
10.5.2. Revisión técnica de los cambios
del sistema operativo.

7.4. Compras

7.4.1. Proceso de compras 10.5.5. Desarrollo externo de Software

7.4.2. Información de las compras 10.5.5. Desarrollo externo de Software

7.4.3. Verificación de los productos 10.5.5. Desarrollo externo de Software

comprados

7.5. Producción y prestación del servicio

7.5.1. Control de la producción y de la 8.2.1. Planificación de la capacidad.

prestación del servicio

7.5.2. Validación de los procesos de la 6.1.2. Selección y política de personal.

producción y de la prestación del servicio 8.2.2. Aprobación del sistema.

7.5.3. Identificación y trazabilidad 8.1.2. Control de cambios en las

operaciones.

7.5.4. Propiedad del cliente 4.3.1. Requerimientos de seguridad en

contratos de tercerización.

7.5.5. Preservación del producto 5.1.1. Inventario de activos.

8.6.3. Procedimientos de manejo de la
información.
8.6.4. Seguridad de la documentación del
 sistema.

7.6. Control de los dispositivos de 12.3.2. Protección de las herramientas de

seguimiento y de medición auditoría de sistemas.

8. Medición, análisis y mejora

8.1. Generalidades 12.2. Revisión de la política de seguridad

y la compatibilidad técnica.

8.2. Seguimiento y medición

8.2.1. Satisfacción del cliente

8.2.2. Auditoria interna 9.7.1. Registro de eventos.

12.3. Consideraciones de auditoría de
sistemas.

8.2.3. Seguimiento y medición de los 9.7.2. Monitoreo del uso de los sistemas.
procesos 12.1.5. Prevención de uso inadecuado de
los recursos informáticos de
procesamiento de información.

8.2.4. Seguimiento y medición del

producto

8.3. Control del producto no conforme 8.1.3. Procedimientos de manejo de

incidentes.

8.4. Análisis de datos 0. Introducción: Evaluación de los riesgos

en materia de seguridad (4)

8.5. Mejora

8.5.1. Mejora continua 0. Introducción: Evaluación de los riesgos

en materia de seguridad (4)

8.5.2. Acción correctiva 6.3.4. Aprendiendo de los incidentes.

11. Administración de la continuidad del
negocio.

8.5.3. Acción preventiva 0. Introducción: Evaluación de los riesgos

en materia de seguridad (4)
6.3.4. Aprendiendo de los incidentes.

Fuente: Elaboración Propia.

3. PROCESO DE NEGOCIO.

Las organizaciones que tengan un sistema de gestión de calidad implementado pero no

esta certificado o al contrario esta implementado y esta certificado en la Norma
ISO/IEC 9000:2000, deben tener en cuenta que aunque con esto se reducen ciertos
riesgos de seguridad de la información, no es suficiente para garantizar que la
información de la organización esta protegida adecuadamente, ya que los controles
necesarios para dicho fin son los que están establecidos en la Norma ISO/IEC 17799.

La Norma ISO/IEC 17799 debe estar en todo el proceso de negocio, dado que la
información en cada elemento de este proceso es importante para el buen
funcionamiento del negocio. Por lo tanto se realizó una tabla de correspondencia que
muestra cada uno de los elementos del proceso de negocio con su respectivo control
de la Norma ISO/IEC 17799.
 Figura 11: Proceso de Negocio

GERENCIAMIENTO ESTRATÉGICO

FILOSOFIA POLITICAS TOMA DE SISTEMA DIRECCION PRESUPUESTO INVERSIONES CONTROL DE

GENERAL DECISIONES GERENCIAL ESTRATEGICA DE CAPITAL CAPITAL

CADENA DE VALOR

VISIÓN DISEÑO FABRICACIÓN IMPLANTACIÓN

SOPORTE Y
MANTENIMIENTO

* Necesidades * Pre-producción. * Producción. * Ventas y Servicios.

Del Cliente. * Capacidad * Materiales. * Mercadeo.
* Información. Tecnológica. * Pruebas. * Logística.
* Compras. * Tecnología.
* Infraestructura
* Proveedores.

GESTIÓN DE CLIENTES

GESTIÓN DE TALENTO HUMANO

GESTIÓN DE CALIDAD

GESTIÓN DE BIENES Y SERVICIOS

GESTIÓN FINANCIERA

Fuente: Calidad Total - ACIS

3.1. PROCESO DE NEGOCIO INCLUYENDO LA NORMA ISO/IEC 17799.

Cuadro 17. Proceso de Negocio Incluyendo la Norma ISO/IEC 17799

PROCESO NORMA ISO/IEC 17799

3. Política de Seguridad.
4.1.1. Foro Gerencial sobre Seguridad de la
Información.
4.1.2. Coordinación de la Seguridad de la
GERENCIAMIENTO Información.
ESTRATÉGICO 11. Administración de la Continuidad del Negocio.
12.1.5. Prevención del Uso Inadecuado de los
Recursos de Procesamiento de Información.
12.1.7. Recolección de Evidencia.
12.3. Consideraciones de Auditoría de Sistemas.

8.4.1. Resguardo de la Información.

8.6.1. Administración de los Medios Informáticos
SOPORTE Y MANTENIMIENTO Removibles.
8.6.2. Eliminación de Medios Informáticos.
10.4. Seguridad de los Archivos del Sistema.

12.1.4. Protección de Datos y Privacidad de la

GESTIÓN DE CLIENTES
Información Personal.

6.1. Seguridad en la Definición de Puestos de

GESTIÓN DEL TALENTO Trabajo y la Asignación de Recursos.
6.2. Capacitación del Usuario.

Fuente: Elaboración Propia

3.2. DESCRIPCIÓN DE LA CADENA DE VALOR DEL PROCESO DE NEGOCIO.

Visión.

• Entender las necesidades de los clientes.

• Analizar la capacidad Técnica.
• Analizar la capacidad de Ejecución.
• Estudiar la capacidad de lo proveedores.
• Estudiar el comportamiento de los proveedores con otros clientes.
• Seleccionar el proveedor más adecuado para la realización del producto o para
la prestación del servicio.
• Negociar con los proveedores.
• Analizar la infraestructura física del negocio.
• Planificar los insumos a adquirir partiendo del presupuesto asignado por el nivel
gerencial.

Diseño.

• Planear la Pre-Producción.
• Establecer la capacidad del proceso.
• Validar el diseño.
• Establecer la capacidad tecnológica.

Fabricación.

• Ejecutar el Trabajo
• Establecer la capacidad de producción.
• Usar la tecnología adecuada para la elaboración de un producto o prestación de
un servicio.
• Realizar pruebas (si es requerido).
 • Utilizar adecuadamente los materiales para la elaboración de un producto o
prestación de un servicio.

Implantación.

• Seleccionar el lugar más apropiado y seguro para la entrega del producto o

prestación del servicio.
• Realizar investigación de mercados.
• Estudiar la mejor manera de llegar a los clientes del mercado objetivo.
• Recibir retroalimentación de los clientes
• Predecir las necesidades de los clientes

Al tener claro cual es el objetivo de cada elemento del proceso de negocio, se tomo la
Norma ISO/IEC 17799 y se identificaron los aspectos más importantes para cada
elemento, con respecto a la seguridad de la información.
 Cuadro 18. Cadena de Valor y Norma ISO/IEC 17799

CADENA DE VALOR NORMA ISO/IEC 17799

4.2. Seguridad Frente al Acceso por Terceros

4.3. Tercerización.
5.1.1. Inventario de Activos.
5.2. Clasificación de la Información.
6.1.3. Acuerdos de Confidencialidad
7.1. Áreas de Seguridad.
7.2. Seguridad del Equipamiento.
7.3.2. Retiro de Bienes.
8.3.1. Controles Contra Software Malicioso.
VISIÓN
8.6.3. Procedimientos de Manejo de la Información.
8.7.1. Acuerdos de Intercambio de Información y
Software.
8.7.7. Otras Formas de Intercambio de Información.
10.1. Requerimientos de Seguridad de los Sistemas.
10.3.1. Política de Utilización de Controles Criptográficos.
12.1.1. Identificación de la Legislación Aplicable.
12.1.4. Protección de Datos y Privacidad de la
Información Personal.

6.1.3. Acuerdos de Confidencialidad

8.1.3. Procedimiento de Manejo de Incidentes.
8.2.1. Planificación de la Capacidad.
DISEÑO
8.2.2. Aprobación del Sistema.
12.1.5. Prevención de Uso Inadecuado de los Recursos
de Procesamiento de Información.
 6.1.3. Acuerdos de Confidencialidad
6.3.1. Comunicación de Incidentes Relativos a la
Seguridad.
6.3.5. Procesos Disciplinarios.
7. Seguridad Física y Ambiental.
8.1.1. Documentación de los Procedimientos Operativos.
8.1.2. Control de Cambios en las Operaciones.
8.1.3. Procedimiento de Manejo de Incidentes.
8.1.4. Separación de Funciones.
8.1.5. Separación entre Ambientes de Desarrollo y
Producción.
FABRICACIÓN 8.2.2. Aprobación del Sistema.
8.4.1. Resguardo de la Información.
8.4.2. Registro de Actividades del Personal Operativo.
8.5. Administración de las Redes.
8.6.3. Procedimientos de Manejo de la Información.
8.6.4. Seguridad de la Documentación del Sistema.
9. Control de Acceso.
10.2. Seguridad en los Sistemas de Aplicación.
10.5. Seguridad de los Procesos de Desarrollo y Soporte.
12.1.2. Derechos de Propiedad Intelectual.
12.2. Revisión de la Política de Seguridad y Conformidad
Técnica.

6.3.4. Aprendiendo de los Incidentes.

8.4.3. Registro de Fallas.
8.7.2. Seguridad de los Medios en Transito.
8.7.3. Seguridad del Comercio Electrónico.
IMPLANTACIÓN
8.7.6. Sistemas de Acceso Público.
10.3.2. Cifrado.
10.3.3. Firma Digital.
10.3.5. Administración de Claves.

Fuente: Elaboración Propia