DDS

32a
INSTITUTO TECNOLÓGICO SUPERIOR DE
CENTLA
Academia de Informática y
Sistemas Computacionales
Antología
DSB-0705 DESARROLLO DE SOFTWARE SEGURO
Presentan
Ing. Manuel Torres Vásquez
Revisado por los integrantes de la academia de Informática
y Sistemas Computacionales
Material compilado con fines académicos
Fecha elaboración: Julio 2010
Institución Certificada
Norma ISO 9001:2000

INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA
Academia de Informática y Sistemas Computacionales
Asignatura: Desarrollo de Software Seguro
Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor.
Tabla de Contenido
Unidad I
Introducción a la seguridad del software
1.1 Concepto de Software
1.2 Casos reales de fallas en el software
1.3 Futuro del software
1.4 Fuentes para información de vulnerabilidades
1.4.1. Buqtraq
1.4.2. CERT Advisores
1.4.3. RISK Digest
1.5 Tendencias técnicas que afectan a la Seguridad del Software
1.6 Breanking and patch (romper y actualizar)
1.7 Metas de la Seguridad enfocadas al Software
1.7.1. Prevención
1.7.2. Auditable y trazable
1.7.3. Monitoreo
1.7.4. Privacidad y Confidencialidad
1.7.5. Seguridad Multiniveles
1.7.6. Anonimato
1.7.7. Autenticación
1.7.8. Integridad
1.8 Conocer al enemigo
1.9 Metas de proyecto de Software

Unidad II
Administración de los riesgos en la seguridad del software
2.1 Descripción de la administración de los riesgos en la Seguridad del
Software
2.2 Administración de los riesgos en la seguridad del Software en la
práctica
2.2.1 Pruebas de Caja Negra
2.2.2 Equipo Rojo
2.3 Criterios Comunes
Unidad III
Código abierto o cerrado
3.1 Seguridad por Oscuridad
3.2 Ingeniería en Reversa
3.3 Código Fuente Abierto
3.4 Falacias del código abierto

Unidad IV
Principios guías del software seguro
4.1 Principio 1. Reducir las líneas débiles
4.2 Principio 2. Defensa por pasos o capas
4.3 Principio 3. Seguramente fallará
4.4 Principio 4. Menos privilegios
4.5 Principio 5. Segmentación
4.6 Principio 6. Mantenerlo simple
4.7 Principio 7. Promover la privacía
4.8 Principio 8. Ocultar secretos es difícil
4.9 Principio 9. Transparentar el código
4.10 Principio 10. Usar recursos comunes
Unidad V
Auditoria de software
5.1 Definición de Arquitectura de Seguridad
5.2 Principios de la Arquitectura de Seguridad
5.3 Análisis de la Arquitectura de Seguridad
5.3.1 Diseño
5.3.2 Implementación
5.3.3 Automatización y pruebas
5.3.4 Árboles de Ataque
5.3.5 Reporte del Análisis
5.4 Implementación del Análisis de Seguridad
5.4.1 Auditoria de Código Fuente
5.4.2 Herramientas de Auditoria de Seguridad de Código

Unidad VI
Código seguro
6.1 Definición de Código Seguro
6.2 Lenguaje Ensamblador
6.3 Lenguajes de Programación
6.4 Técnicas de Código Seguro
6.4.1 Buffer Overflows
6.4.2 Heap Overflows
6.4.3 Formato de cadena
6.4.4 Exploits
6.4.5 Race conditions
6.4.6 SQL injection
6.4.7 Cross Site & Cross-Domain Scripting
6.4.8 Fault Injection

Unidad VII
Pruebas de software
7.1 Fases de las Pruebas de Software
7.1.1 Modelado del ambiente del software
7.1.2 Selección de escenarios de prueba
7.1.3 Ejecución y evaluación de los escenarios de prueba
7.1.4 Medición del progreso de las pruebas
7.2 Prácticas de las Pruebas de Software
7.2.1 Básicas
7.2.1.1 Especificaciones funcionales
7.2.1.2 Revisión e inspección
7.2.1.3 Entrada formal y criterios de salida
7.2.1.4 Prueba funcional
7.2.1.5 Pruebas multiplataforma
7.2.1.6 Ejecución automatizada de prueba
7.2.1.7 Programas beta
7.2.2 Fundamentales
7.2.2.1 Escenarios de usuario
7.2.2.2 Pruebas de utilidad
7.2.2.3 Requerimientos para la planificación de la prueba
7.2.2.4 Generación automatizada de la prueba
7.2.3 Incrementales
7.2.3.1 Cobertura de código
7.2.3.2 Generador de ambiente automatizado
7.2.3.3 Diagrama del estado de la prueba
7.2.3.4 Simulación de falla en la memoria
7.2.3.5 Pruebas estadísticas
7.2.3.6 Métodos semiformales
7.2.3.7 Registro de la prueba para el código
7.2.3.8 Benchmark
7.2.3.9 Generación de errores (bugs)

Unidad VIII
Derechos de autor en México (software)
8.1 Ley Federal del Derecho de Autor (LFDA) en México
8.1.1 Definición
8.1.2 Artículos para la protección jurídica del software
8.1.3 Derechos que se confieren a través de la LFDA
8.1.3.1 Derechos morales
8.1.3.2 Derechos patrimoniales
8.2. Instituto Nacional del Derecho de Autor (INDAUTOR)
8.2.1 Definición
8.2.2 Ubicación del INDAUTOR
8.3 Dirección General de Asuntos Jurídicos de la UNAM (DGAJ)
8.3.1 Definición
8.3.2 Relación con el INDAUTOR
8.3.3 Ubicación de la DGAJ
8.4 Registro del software
8.4.1 Procedimiento y requerimientos para registrar software en el
INDAUTOR.
8.4.2 Procedimiento y requerimientos para registrar software en la
DGAJ.
8.4.3 Ventajas y desventajas al registrar software
8.5 Violación a los Derechos de Autor
8.6 Leyes que brindan protección jurídica al software en caso de
violación.
8.7 Sociedades de Gestión Colectiva
8.7.1 ¿Qué es una Sociedad de Gestión Colectiva?
8.7.2 Procedimiento y requerimientos para registrar una Sociedad
de Gestión Colectiva.
8.7.3 Obligaciones y privilegios al formar parte de una Sociedad de
Gestión Colectiva.

Unidad I
Introducción a la seguridad del software
Objetivo: El alumno conocerá y comprenderá los fundamentos teóricos,
tendencias y metas de la seguridad en el software.
Contenido:
1.1 Concepto de Software
1.2 Casos reales de fallas en el software
1.3 Futuro del software
1.4 Fuentes para información de vulnerabilidades
1.4.1. Buqtraq
1.4.2. CERT Advisores
1.4.3. RISK Digest
1.5 Tendencias técnicas que afectan a la Seguridad del Software
1.6 Breanking and patch (romper y actualizar)
1.7 Metas de la Seguridad enfocadas al Software
1.7.1. Prevención
1.7.2. Auditable y trazable
1.7.3. Monitoreo
1.7.4. Privacidad y Confidencialidad
1.7.5. Seguridad Multiniveles
1.7.6. Anonimato
1.7.7. Autenticación
1.7.8. Integridad
1.8 Conocer al enemigo
1.9 Metas de proyecto de Software

1.1 CONCEPTO DE SOFTWARE
El software es el nexo de unión entre el hardware y el hombre. El computador, por
sí solo, no puede comunicarse con el hombre y viceversa, ya que lo separa la
barrera del lenguaje. El software trata de acortar esa barrera, estableciendo
procedimientos de comunicación entre el hombre y la máquina; es decir, el
software obra como un intermediario entre el hardware y el hombre.
El software es un conjunto de programas elaborados por el hombre, que controlan
la actuación del computador, haciendo que éste siga en sus acciones una serie de
esquemas lógicos predeterminados.
Tal característica ‗lógica‘ o ‗inteligente‘ del software es lo que hace que se le
defina también como la parte inmaterial de la informática, ya que aunque los
programas que constituyen el software residan en un soporte físico, como la
memoria principal o los disquetes (o cualquier dispositivo rígido de
almacenamiento), la función de los programas en un computador es semejante a
la del pensamiento en un ser humano.
Si bien el progreso del hardware es cada vez mayor y los dispositivos físicos se
construyen cada vez con más ‗inteligencia‘ incluida, en forma que se resuelven por
hardware funciones anteriormente sólo factibles por software, es prácticamente
imposible que el avance tecnológico llegue algún día a eliminar la necesidad de
software, ya que éste también evoluciona y las facilidades que el usuario pide al
computador son cada día más sofisticadas.
La clasificación básica es: Software de Sistema y Software de Aplicación.
 El software de sistema es el software básico o sistema operativo.
Es un conjunto de programas cuyo objeto es facilitar el uso del computador (aísla
de la complejidad de cada dispositivo, y presenta al exterior un modelo común de
sistema de manejo para todos los dispositivos) y conseguir que se use
eficientemente
 El software de aplicación
Son los programas que controlan y optimización la operación de la máquina,
establecen una relación básica y fundamental entre el usuario y el computador,
hacen que el usuario pueda usar en forma cómoda y amigable complejos sistemas

hardware, realizan funciones que para el usuario serían engorrosas o
incluso imposibles, y actúan como intermediario entre el usuario y el hardware.
1.2 CASOS REALES DE FALLAS EN EL SOFTWARE
 El caso del desastre del Ariane-5, famoso por haberse producido por una
falla en el software de abordo. Según la European Spacial Agency (ESA),
administradora del programa, la desviación en la trayectoria fue ocasionada
por la computadora que controlaba los dos poderosos impulsores del
cohete. Se especulo que la computadora creyó que el cohete se estaba
saliendo de curso y de esta manera trataba de corregir la trayectoria de
vuelo. De acuerdo con el reporte final, la causa de la falla del sistema
ocurrió durante la conversión de un número flotante de 64 bits a un número
entero de 16 bits.
 Otro de los casos de fallas en software que causó graves daños a la
integridad de las personas, Therac-25. Era un aparato para el tratamiento
del cáncer por emisión de rayos cuyos controles (de la cantidad de energía
emitida) implementados en hardware fueron removidos y sólo se dejaron
los de software que (obviamente) fallaron.
 Error en un sistema de autenticación de tarjetas de crédito (1995)
Los dos sistemas más grandes en ese país para la autorización de crédito
(Barclay´s PQD y NatWest´s Streamline) fallaron el sábado 28 de octubre
de 1995 imposibilitando que los comercios verificaran las tarjetas de crédito
de sus clientes. En el caso de Barclay, más de 40% de las transacciones
fallaron por un error en el sistema de software. Para NatWest, el problema
fue ocasionado por una gran cola de llamadas, que obstruyo la
comunicación por razones desconocidas, y que retraso la autentificación de
tarjetas.
 Software inapropiado llevó a un distribuidor de medicina a la quiebra. El 27
de agosto de 1998 la revista Der Spiege, en Alemania, informó de una
demanda de 500 millones de dólares a SAP por parte del distribuidor de
medicinas FoxMeyer Corp. Esta última acusó a SAP de venderle software
inapropiado para sus necesidades, lo cual tuvo como resultado la quiebra
de Fox Meyre. Analistas alemanes comentaron que no consideran que un
―software sea apropiado para llevar a la ruina a una compañía‖.

 Error en sistema de cobranza de MCI (1996). En la edición de 29 de marzo
de 1996 del Washington Post, MCI reporto que le devolverían
aproximadamente 40 millones de dólares a sus clientes por un error de
cobranza causada por un sistema de cómputo.
 El error de cobranza fue descubierto por un reportero investigador de una
estación local de televisión en Richmond, VA, quien encontró que fueron
facturados por 4 minutos siendo que en realidad la llamada fue de 2.5
minutos, dando lugar a una profunda investigación.
1.3 FUTURO DEL SOFTWARE
"El futuro del software es un desafío"
Empecemos con una paradoja: el futuro del software comienza con el fin del
software. Al menos, el fin del software tal y como lo conocemos. El software
cliente/servidor tradicional es un modelo acabado, en particular para las
organizaciones de TI que desean contribuir realmente al balance final.
Para comprender el futuro del software empresarial, no hace falta ir muy lejos: la
Web de consumidores. Al igual que los servicios Web para consumidores como
Google, eBay y Amazon.com están sustituyendo al software estándar para
consumidores, cada vez más aplicaciones empresariales están trasladándose a la
Web. En 2005, se calculó que las ventas de SaaS (software como servicio)
supusieron un 5% del total de las ventas de software empresarial. En 2011, se
prevé que la cuota aumente hasta el 25%.
Los cambios implican un desafío interesante para todos los involucrados en el
desarrollo de software. Y el hardware, que durante muchos años ha sido el cuello
de botella de los sistemas informáticos, crecerá hasta volverse de 50 a 100 veces
más poderoso que en la actualidad.
Esto representa una dificultad adicional, la de utilizar toda esa capacidad ociosa
para convertirla en algo productivo, ya que no sería inteligente tomar sistemas que
actualmente desperdician millones de ciclos de CPU y agregarle más capacidad

sin modificar el uso que reciben, para de ese modo desperdiciar más poder
aún. Sin dudas, "se avecina un nuevo paradigma de software, y he aquí el mayor
desafío".
Cualquier especulación sobre el futuro del software merece, como mínimo, una
revisión de los principales cambios a lo largo de su historia, como:
 El paso del ordenador central a los sistemas cliente/servidor, que tuvo como
consecuencia la transición desde sistemas existentes a sistemas
empresariales estándar.
 El auge de los ordenadores personales que desembocó en una
productividad de los usuarios sin precedentes, así como una proliferación
de islas de datos.
 El auge de Internet, que condujo a una explosión de información y cambió
el modo en que millones de personas trabajan, juegan y compran. También
el aumento del uso de Internet y el acceso permanente a la red.
 La aparición de estándares y tecnologías de servicios Web, como las
arquitecturas multiusuario.
 El paso hacia los enfoques de arquitectura orientada a servicios (SOA) por
parte de los principales proveedores de software, lo que facilitaba la
integración con los sistemas de servidor.
 La aparición del modelo On-Demand, que suponía el cambio de un modelo
en propiedad a un modelo ―en alquiler‖ y que liberaba a las empresas de los
problemas y los gastos que conllevaba la propiedad. Salesforce.com es uno
de los ejemplos más satisfactorios de este modelo con 55,400 clientes y
más de 800 aplicaciones.

1.4 FUENTES PARA LA INFORMACIÓN DE VULNERABILIDADES
En cualquier caso conviene indicar las fuentes más importantes de información
asociada a vulnerabilidades de seguridad. No hay que olvidar que la mayor parte
de esta información es de dominio público y que los desarrollos posteriores que
puedan hacerse (bien a medida internamente o contratados) van a estar basados
en las mismas fuentes:
 El diccionario CVE, desarrollado por la corporación Mitre y disponible en
http: //cve.mitre.org, que sirve como un elemento integrado de distintas
fuentes y herramientas de seguridad. En esencia se trata de llamar a una
vulnerabilidad siempre ―igual‖ (con el mismo identificador).
 La base de datos de vulnerabilidades y alertas del centro de respuesta y
coordinación ante emergencias de Internet, el CERT/CC, disponible en
http:// www.kb.cert.org/vuls. Las bases de datos de vulnerabilidades son
una herramienta clave a la hora de detectar posibles problemas de
seguridad y prevenirlos
 La famosa base de datos de Bugtrag (basada en gran parte en la
información publicada en la lista de correo de seguridad del mismo
nombre), adquirida por la empresa de seguridad Symantec, disponible en
http: //www.securityfocus.com/bid. Es posiblemente la más completa
(alrededor de 10.000 vulnerabilidades hasta la fecha) y sobre ésta
Symantec ha desarrollado un servicio comercial.
 La base de datos de Xforce, desarrollada por el fabricante de productos
de seguridad Internet Security Systems (ISS), disponible en
http://xforce.iss.net. Sirve de base tanto a los productos de seguridad de la
compañía (herramientas de detección de intrusos, sistemas de análisis de
vulnerabilidades...) como de servicios comerciales basados en ésta.
 La base de datos ICAT publicada por el instituto de estándares del
Gobierno norteamericano, el NIST, y disponible en http://icat.nist.gov. Se
trata de una metabase de datos de información de vulnerabilidades, con
más de 6.500 referencias a CVE y a las bases de datos arriba indicadas. Se

distribuye como un fichero de Microsoft Access (o en formato CSV)
para su libre utilización.
Dentro de estas fuentes de información podemos encontrar todo tipo de
vulnerabilidades, desde ataques a servidores IIS de Microsoft a través de código
Unicode hasta desbordamientos de búfer de Oracle Application Server, pasando
por pequeñas vulnerabilidades de sistemas Windows como las existentes en la
ayuda online de Windows. Como es lógico todas estas bases de datos se están
actualizando continuamente, a medida que se publicitan nuevos fallos de
seguridad.
Las fuentes de información de vulnerabilidades de seguridad y, entre ellas, las
bases de datos de vulnerabilidades, son una herramienta clave a la hora de
detectar posibles problemas de seguridad y prevenirlos. Estas fuentes dan, si bien
no en tiempo real, información de los principales problemas asociados a los
principales fabricantes de software y hardware (y algunos menos conocidos), en
muchos casos con sus posibles soluciones, y con información que permitirá
determinar la premura con la que se debe arreglar la vulnerabilidad (en base a su
impacto, al riesgo existente debido a la existencia o no de aprovechamientos de la
misma...).
1.5 TENDENCIAS TECNICAS QUE AFECTAN A LAS ENTIDADES DEL
SOFTWARE
Tendencias que afectan a los sistemas de información
Al considerar un Sistema de Información como un conjunto de normas y procesos
generales de una determinada, se deben considerar algunos puntos negativos y
positivos que afectan directamente al sistema:
Actualizaciones
Se refiere a que los sistemas de información de cualquier empresa, debe ser
revisado periódicamente; no con una frecuencia continua, sino mas bien
espaciada, se recomienda las revisiones bianuales (No se recomienda que se
actualice en una empresa paulatinamente, por ejemplo el software, cuadros
estadísticos, es recomendable dentro de un año cambiarlo, todo lo que es
máquinas y software; porque si no realizaríamos esto, se cambiaría toda la
estructura organizacional de la misma).

Reestructuración Organizacional
(Puede ser una reestructuración con los mismos puestos). Una reestructuración
organizacional con cualquier empresa, implica cambios siempre en vista a buscar
un mejor funcionamiento, evitar la burocracia, agilitar trámites o procesos, la
reestructuración puede ser de varios tipos, así por ejemplo. Aumentar o disminuir
departamentos, puestos, reestructuración de objetivos, etc. Siempre la
reestructuración afecta a los sistemas de información de la empresa.
Revisión y Valorización del escalafón
(No es para bien si no también para mal)
La revisión y la revalorización del escalafón se espera que afecte a favor de los
sistemas de información de las empresas, si el efecto es contrario el auditor
deberá emitir un informe del empleado a los empleados (Específicamente de
departamentos), que están boicoteando la información de la empresa.
Cambios en el flujo de Información
(Datos para el sistema de Información)
Se refiere al cambio de flujo de datos exclusivamente en el área informática, esto
afecta directamente en sistema informático y por tanto al sistema de información.
En lo que respecta a la Auditoría informática, el efecto puede ser positivo y
negativo, dependiendo a los resultados obtenidos en cuanto al proceso de datos
(menos seguridad, más seguridad, backup).
Así por ejemplo:
Se ha cambiado el flujo de información en el área contable, para generar los roles
mensuales (De inicio del rol era realizado por la secretaria, la cual ingresaba las
existencias, fallas, atrasos, etc.; determinando un monto a descontar. Un monto
bruto y un salario final, esto pasaba a la contadora para que justifique
especialmente multas, se rectificaba en algunos casos, y se mandaba a imprimir el
rol. Se considera un nuevo flujo de información, en el cual se ingresan los datos a
un sistema informático, y de acuerdo a los parámetros y normas de la empresa el
sistema arroja un sueldo líquido a cobrarse, genera automáticamente el reporte,
los cheques y el contador solo aprueba este reporte).
(Un ejemplo es cuando existe migración de datos, la información migra o se
cambia a otro sistema más sofisticado).

1.6 BREAKING AND PATCH
Actualización
Modificación que se aplica al software para corregir un problema o incorporar una
función nueva.
Realizar los pasos necesarios para aplicar actualizaciones a un sistema. El
sistema se analiza y, a continuación, se descargan y se aplican las
actualizaciones.
Se denomina también patch.
Actualización con firma
Actualización que incluye una firma digital válida. Las actualizaciones firmadas
ofrecen mayor seguridad que las que no disponen de firma. La firma digital de la
actualización puede verificarse antes de aplicarla al sistema. Las firmas digitales
válidas aseguran que las actualizaciones no se han modificado desde que éstas
se aplicaron. Las actualizaciones firmadas se almacenan en archivos con formato
Java Archive (JAR).
Actualización de función
Actualización que incorpora una nueva función en el sistema.
Actualización sin firma
Actualización que no incluye una firma digital.
Parche (informática)
En informática, un parche es una sección de código que se introduce a un
programa. Dicho código puede tener varios objetivos; sustituir código erróneo,
agregar funcionalidad al programa, aplicar una actualización, etc.
Los parches suelen ser desarrollados por programadores ajenos al equipo de
diseño inicial del proyecto (aunque no es algo necesariamente cierto). Como los
parches se pueden aplicar tanto a un binario ejecutable como al código fuente,
cualquier tipo de programa, incluso un sistema operativo, puede ser objeto de un
parche.
El origen del nombre probablemente se deba a la utilidad de Unix llamada patch
creada por Larry Wall

Tipos según su propósito
Parches de depuración
El objetivo de este tipo de parches es reparar bugs, o errores de programación
que no fueron detectados a tiempo en su etapa de desarrollo. Se dice que un
programa que se lanza con una alta probabilidad de contener este tipo de errores
se le llama versión beta.
Parches de seguridad
Los parches de seguridad solucionan agujeros de seguridad y, siempre que es
posible, no modifican la funcionalidad del programa. Los parches de seguridad son
especialmente frecuentes en aplicaciones que utilizan la red.
Parches de actualización
Consiste en modificar un programa para convertirlo en un programa que utilice
metodologías más nuevas. Por ejemplo, optimizar en tiempo cierto programa,
utilizar algoritmos mejorados, añadir funcionalidades, eliminar secciones obsoletas
de software, etc.

1.7 METAS DE LA SEGURIDAD ENFOCADAS AL SOFTWARE
La Arquitectura de Seguridad de Información es la práctica de aplicar un método
riguroso y comprensivo para describir una estructura actual y/o futura y el
comportamiento de los procesos de seguridad de una organización, sistemas de
seguridad de información y subunidades de personal y organizativas, para que se
alineen con las metas comunes de la organización y la dirección estratégica.
Aunque a menudo se asocie estrictamente con tecnologías para la seguridad de la
información, se relaciona en términos más generales con la práctica de seguridad
de optimización del negocio, donde dirige la arquitectura de seguridad del negocio,
la realización de gestiones y también la arquitectura de procesos de seguridad.
La Arquitectura de Seguridad de Información en la Empresa está convirtiéndose
en una práctica habitual dentro de las instituciones financieras alrededor del
mundo. El propósito fundamental de crear una arquitectura de seguridad de
información en la empresa es para asegurar que la estrategia de negocio y la
seguridad de las tecnologías de la información (TI) están alineadas. Como tal, la
arquitectura de seguridad de la información en la empresa permite la trazabilidad
desde la estrategia de negocio hasta la tecnología subyacente.
Metas de la Seguridad
Proporcionar estructura, coherencia y cohesión
Debe permitir un alineamiento del negocio hacia la seguridad
Principios inicio-fin definidos con estrategias de negocio
Asegurar que todos los modelos e implementaciones pueden ser trazados
hacia atrás hasta la estrategia de negocio, específicamente requerimientos
de negocio y principios clave
Proveer abstracción para que factores complicados puedan ser eliminados
y reinstalados en niveles de detalle diferente sólo cuando sean requeridos
Establecer un lenguaje común para la seguridad de la información dentro
de la organización

Protección del software:
Los programas de ordenador actualmente están expresamente excluidos de la
protección a través de patentes en el artículo 4 de la Ley española de patentes
11/1986.
La protección que se aplica con carácter general a este tipo de resultado de
investigación será la que le otorga la Ley de Propiedad Intelectual.
Concretamente el título VII se dedica los programas de ordenador.
Una característica principal de este tipo de protección consiste en que los
derechos sobre la obra (en este caso programa de ordenador) se generan
automáticamente desde el momento en que se ha creado el programa.
Esto significa:
Que no hace falta inscribir el programa en ningún tipo de registro para que
nazcan derechos de exclusiva sobre el mismo.
Que se puede publicar cualquier referencia al programa en revistas
especializadas haciendo referencia a los derechos de la UPV y a los
autores.
En ningún caso es conveniente desvelar el código fuente a terceros.

1.7.1 PREVENCION
Un sistema de prevención/protección para defenderse de las intrusiones y no sólo
para reconocerlas e informar sobre ellas, como hacen la mayoría de los IDS.
El software de prevención contempla:
 Gestión de prevención de riesgos a nivel de centros de trabajo y
trabajadores.
 Gestión de subcontratas.
 Histórico de evaluaciones de riesgos realizadas.
 Composición de equipos de emergencia.
 Histórico de cursos de prevención y seguridad realizados.
 Estadísticas de siniestralidad.
 Análisis de accidentes.
 Control de la Formación en materia de prevención.
 Gestión de Equipos de protección individual entregados al personal.
 La efectividad de la prevención general tiene una doble vertiente:
 La prevención general positiva: es aquélla que va encaminada a restablecer
la confianza del resto de la sociedad en el sistema.
 La prevención general negativa: es aquélla que va encaminada a disuadir a
los miembros de la sociedad que no han delinquido, pero que se pueden
ver tentados a hacerlo, a través de la amenaza de la pena.

1.7.2 AUDITABLE Y TRAZABLE
Auditable: es tanto la solución tecnológica, como sus componentes de hardware
y/o software debe ser abierta e íntegramente auditable antes y posteriormente a
su uso. Consideramos que también debe ser auditable durante su uso y no
restringirlo únicamente a las etapas del antes o el después.
Auditabilidad de bases de datos
El acceso global a la Información que trajo el advenimiento de la Tecnología de
Internet, ha hecho que el problema de Seguridad de la Información se acrecentara
de manera alarmante. En función de esta realidad, se deben extremar los
requerimientos de Seguridad en todos los elementos que configuren el Sistema de
Información.
El Sistema de Base de Datos que decidamos utilizar en una aplicación
determinada, deberá ser valorado fundamentalmente por la Seguridad que brinda.
Existen, actualmente, criterios de Evaluación de Seguridad, con validez
internacional, que permiten clasificar cada Sistema de Base de Datos en distintas
categorías de acuerdo a la valoración, que de él hagan, grupos de expertos en el
tema.
Asimismo deberá estudiarse con sumo cuidado las facilidades que el Sistema de
Base de Datos ofrezca para su auditabilidad, qué tipo de información generan, con
qué facilidad se pueden definir opciones, etc.
Un aspecto que merecerá también nuestra atención será el control de acceso que
posea, la posibilidad de definición de perfiles y grupos de perfiles.
Si el procesamiento es distribuido será objeto de nuestra atención el
procesamiento y replicación segura, cómo así también todo mecanismo que
garantice la integridad de los Datos en forma automática.
La propiedad del resultado de una medida o del valor de un estándar donde este
pueda estar relacionado con referencias especificadas, usualmente estándares
nacionales o internacionales, a través de una cadena continúa de comparaciones
todas con incertidumbres especificadas.
En la actualidad existe una propuesta de formato estándar para contener,
transmitir y compartir la trazabilidad. Son los archivos ILE de trazabilidad
encapsulada. Estos archivos pueden contener la historia completa de cualquier
producto, de acuerdo con las restricciones formales de cualquiera de las
legislaciones vigentes en cuanto a trazabilidad y seguridad alimentaria. Estos
archivos de trazabilidad encapsulada se pueden ver y editar de manera gratuita

con el software freeware ilEAN Writer 2.0 e ilEAN Reader 2.0... Además de
con una larga lista de sistemas estándar de los más importantes fabricantes de
software.
Esta consiste en la capacidad para reconstruir la historia, recorrido o aplicación de
un determinado producto, identificando:
Origen de sus componentes.
Historia de los procesos aplicados al producto.
Distribución y localización después de su entrega.
Al contar con esta información es posible entregar productos definidos a mercados
específicos, con la garantía de conocer con certeza el origen y la historia del
mismo. El concepto de trazabilidad está asociado, sin duda, a procesos
productivos modernos y productos de mayor calidad y valor para el cliente final.
La trazabilidad es aplicada por razones relacionadas con mejoras de negocio las
que justifican su presencia: mayor eficiencia en procesos productivos, menores
costes ante fallos, mejor servicio a clientes, etc. En este ámbito cabe mencionar
sectores como los de automoción, aeronáutica, distribución logística, electrónica
de consumo, etc.,
Un sistema de trazabilidad es un conjunto de disciplinas de diferente naturaleza
que, coordinadas entre si, nos permiten obtener el seguimiento de los productos a
lo largo de cualquier cadena del tipo que sea.
Si entendemos como trazabilidad a: "un conjunto de procedimientos
preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y
la trayectoria de un producto, o lote de productos a lo largo de la cadena de
suministros, en un momento dado y a través de unas herramientas determinadas",
un sistema de trazabilidad deberá de estar compuesto por:
1. Sistemas de identificación
1. Un sistema de identificación del producto unitario
2. Un sistema de identificación del embalajes o cajas
3. Un sistema de identificación de bultos o palets
2. Sistemas para la captura de datos
1. Para las materias primas
2. Para la captura de datos en planta
3. Para la captura de datos en almacén
3. Software para la gestión de datos
1. Capaz de imprimir etiquetas

2. Capaz de grabar chips RFID
3. Capaz de almacenar los datos capturados
4. Capaz de intercambiar datos con los sistemas de gestión
empresariales
Cuando un sistema de trazabilidad está soportado sobre una infraestructura, basa
en las tecnologías de la información y las comunicaciones (TIC), la trazabilidad
puede brindar importantes utilidades a los diferentes actores de una cadena de
valor como ser: gestión eficiente de la logística y del suministro y aumento de la
productividad.
El Software Trazabilidad es el aplicativo de software capaz de registrar la traza
de los productos a lo largo de la cadena de suministro interna o externa,[1]
empaquetarlos en un formato legible y prepararlos para poder ser gestionados por
el propio software o como respuesta a una solicitud de servicio.
El desarrollo de las soluciones para el control de la trazabilidad ha venido
desarrollándose parejo a:
1. Los esfuerzos de las administraciones para controlar la calidad del producto
que llega al usuario final para crear las legislaciones pertinentes.
2. Las necesidades empresariales para obtener información en tiempo real
con el fin de fidelizar a los clientes.
3. Al desarrollo tecnológico en plataformas informáticas y tecnología para la
identificación de productos y obtener la información en la medida de sus
movimientos.
Parece curioso que a medida que se han ido generando exigencias y normativas
por parte de las administraciones para proteger al consumidor final, falta la figura
de un organismo regulador general, o de un sistema globalizado para determinar
que aspectos debe tener un registro de trazabilidad. Así, se han ido creando
normativas y legislaciones sobre trazabilidad por organismos de la EU.
Para un software de trazabilidad, la dificultad radica en que no existe un patrón de
empaquetamiento e intercambio de datos entre ninguno de ellos, por lo que las
exigencias de dichas normativas son diferentes entre sí, lo que provoca que la
fabricación de un producto deba cumplir normativas diferentes dependiendo del
país al que vaya destinado.

1.7.3 MONITOREO
El Monitoreo es el proceso continuo y sistemático mediante el cual verificamos la
eficiencia y la eficacia de un proyecto mediante la identificación de sus logros y
debilidades y en consecuencia, recomendamos medidas correctivas para
optimizar los resultados esperados del proyecto. Es, por tanto, condición para la
rectificación o profundización de la ejecución y para asegurar la retroalimentación
entre los objetivos y presupuestos teóricos y las lecciones aprendidas a partir de la
práctica. Asimismo, es el responsable de preparar y aportar la información que
hace posible sistematizar resultados y procesos y, por tanto, es un insumo básico
para la Evaluación.
Monitoreo de Sistemas de Seguridad
Este sistema permite el monitoreo desde cualquier lugar usando una simple
computadora con acceso a internet. Instalación, suministro, sistemas de c.c.t.v.,
sensores de humo, depende de que esté siempre conectado a la red, y si no es
así la seguridad de su casa o su negocio puede estar en peligro.
Nuestro sistema de monitoreo le permite conocer cuando su sistema de vigilancia
se encuentra no disponible y le permite tomar acciones de emergencia, ya sea
ponerse en contacto con su personal de vigilancia, centrales de monitoreo o con
su proveedor de internet.
Cómo monitoreo servidores de bases de datos detrás de un firewall
Use su lenguaje de programación web preferido (por ejemplo, ASP, JSP, PHP,
ColdFusion, Perl) para escribir un script para conectarse al servidor de base de
datos y realizar una simple consulta. Si la consulta se ejecuta exitosamente, el
script retorna algo como "Servidor de base de datos está ARRIBA".
Finalmente, vaya a Monitoreo -> Agregar un Test y seleccione monitorear un sitio
web. Ingrese la URL del script y especifique la palabra clave requerida "Servidor
de base de datos está ARRIBA". Si nuestro sistema no puede hallar la palabra
clave en la página, le notificará y sabrá que el servidor de base de datos está
caído.

Monitoreo de Dominios
El monitoreo de URLs le ayuda a monitorear la disponibilidad de su sitio Web (o
sitios Web, si tiene más de uno) y a verificar si están sirviendo páginas en tiempo
real. Algunas tipos de monitoreo se encuentran: Monitoreo de URLs, directorios
virtuales, coincidencia de contenido, servidores y aplicaciones Web.
El Software de Excelencia para Vigilancia y Monitoreo en Internet
Spector Pro es el software más vendido en el mundo para monitorear y grabar
cada detalle de la PC o de la actividad en Internet, para tu oficina o tu casa.
Sistema Avanzado de Advertencia.
Este software Aparte de monitorear y grabar, cuenta con un Sistema Avanzado de
Advertencia que te informará cuando una PC monitoreada ha sido utilizada de
manera no apropiada. A través del uso de palabras y frases claves que tú
especifiques, Spector Pro estará "en alerta", enviándote por e-mail inmediata y
detalladamente el reporte de cuándo, dónde y cómo una palabra específica fue
usada – cada vez que se escriba, que aparezca en la PC, en un sitio Web, en el
Chat/mensaje instantáneo o en un e-mail. La alerta se enviará a tu oficina, casa,
celular o a donde tú quieras.
1.7.4 PRIVACIDAD Y CONFIDENCIALIDAD
La privacidad puede ser definida como el ámbito de la vida personal de un
individuo que se desarrolla en un espacio reservado y debe mantenerse
confidencial.
Como cuidar nuestra privacidad
Instalar un cortafuegos ayudara mucho evitando que un sujeto pueda entrar
a nuestra computadora o bien que usen un troyano y quizá pueda robar
información valiosa como tarjetas de crédito o claves, etc.
Un antivirus que en lo posible también detecte spyware servirá mucho para
evitar que nos manden troyanos o spyware que envie información
confidencial aunque si tenemos un firewall es probable que este bloquee el
troyano/spyware al tratar de conectarse.

Un antispyware que ayuda a eliminar el spyware que entro a través
de distintas páginas.
Usar un explorador alternativo a Internet Explorer o bien mantenerlo
actualizado completamente.
Mantener actualizado nuestro sistema operativo es importante para evitar
que a través de un fallo del mismo alguien se pueda apoderar de nuestra
computadora y posteriormente de algo valioso.
No entrar en páginas web sospechosas de robar contraseñas o de mandar
virus/spyware al PC.
Cuando envíen un correo electrónico a varios contactos utilicen el CCO
'correo oculto' para no mostrar los contactos y parezcan como privados
La confiabilidad de software significa que un programa particular debe de seguir
funcionando en la presencia de errores. Los errores pueden ser relacionados al
diseño, a la implementación, a la programación, o el uso de errores. Así como los
sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de
errores. Como mencionamos, es increíblemente difícil demonstrar que un sistema
sea seguro. Ross Anderson dice que la seguridad de computación es como
programar la computadora del Satán. Software seguro debe de funcionar abajo de
un ataque. Aunque casi todos los software tengan errores, la mayoría de los
errores nunca serán revelados debajo de circunstancias normales. Un atacante
busca esta debilidad para atacar un sistema.
La Confidencialidad es la propiedad de un documento o mensaje que únicamente
está autorizado para ser leído o entendido por algunas personas o entidades.Se
dice que un documento o mensaje es confidencial si éste sólo está autorizado a
ser leído o entendido por un destinatario designado.
CONFIDENCIALIDAD
Compromiso de no dar información sobre un hecho mas que a la persona
involucrada y a quienes ella autorice. Los resultados de análisis clínicos y en
especial el de VIH deben ser confidenciales. En la práctica muchos doctores,
incluyendo los de instancias públicas, comunican un resultado positivo a las
autoridades de quien depende la persona afectada, violando con ello la
confidencialidad y provocando en muchos casos el despido o la no aceptación en
un nuevo trabajo de la persona seropositiva.
La confidencialidad se refiere a que la información solo puede ser conocida por
individuos autorizados. Existen infinidad de posibles ataques contra la privacidad,
especialmente en la comunicación de los datos. La transmisión a través de un

medio presenta múltiples oportunidades para ser interceptada y copiada:
las líneas "pinchadas" la intercepción o recepción electromagnética no autorizada
o la simple intrusión directa en los equipos donde la información está físicamente
almacenada.
1.7.5 SEGURIDAD MULTINIVELES
La seguridad multinivel dispara el mercado antivirus y las aplicaciones de software
antivirus están experimentando un notable crecimiento como consecuencia del
gran incremento y la compleja naturaleza de la actividad de intrusión de los virus,
causantes de la infección masiva de sistemas y un importante impacto económico.
Con las mejoras que brindan los nuevos sistemas de protección multinivel en su
esfuerzo por combatir todos los perjuicios comunes más extendidos, las grandes
compañías en particular, están aumentando su inversión destinada a la
erradicación de los fallos de seguridad. El cambio gradual en la protección
multinivel contra los virus en el mercado empresarial, ofrece oportunidades a un
amplio abanico de vendedores de sistemas de seguridad.
La seguridad multinivel (MLS) proviene de los sistemas de alta seguridad
utilizados en Defensa, donde la información es manejada de acuerdo a su nivel de
sensibilidad y a los permisos que tiene la persona que desea acceder a ella, es
también actualmente, una de las mayores preocupaciones en el entorno
empresarial.
La seguridad multinivel tiene los siguientes aspectos diferenciales:
La suite protege la seguridad en todo momento, incluso antes del arranque
del sistema operativo.
Posibilidad de proteger la información mediante cifrado
Compatibilidad con DNI electrónico y Smartcards como tarjeta de
autenticación
Control de los dispositivos de almacenamiento que pueden conectarse al
PC (memorias USB, MP3, etc.)
Control de las aplicaciones que pueden ser ejecutadas
Nivel de seguridad adaptable a las necesidades de la empresa, con gestión
centralizada y políticas definibles en base a perfil de usuario, PC y
dispositivos concretos

La seguridad de software aplica los principios de la seguridad de
información al desarrollo de software. La seguridad de información se refiere a la
seguridad de información comúnmente como la protección de sistemas de
información contra el acceso desautorizado o la modificación de información, si
esta en una fase de almacenamiento, procesamiento o tránsito. También la
protege contra la negación de servicios a usuarios desautorizados y la provisión
de servicio a usuarios desautorizados, incluyendo las medidas necesarias para
detectar, documentar, y contrarear tales amenazas.
1.7.6 ANONIMATO
Anónimo proviene del griego anonymos "sin nombre", compuesto del prefijo
negativo an- "sin" y onoma "nombre".
El anonimato es el estado de una persona siendo anónima, es decir, que la
identidad de dicha persona es desconocida. El anonimato es la condición de la
persona que oculta su nombre o su personalidad, simplemente porque no se lo ha
identificado o porque la persona no puede o no quiere revelar su identidad.
El nombre de Peer-to-Peer anónimo puede entenderse como un nombre
equivocado. Esto es debido a su diseño, un nodo de la red debe tener pseudónimo
desde que tiene que tener una "dirección" para poder ser alcanzado por otro nodo
igual para intercambiar datos. Sin embargo, normalmente esta dirección,
especialmente en redes anónimas, no contiene ninguna información que pueda
permitir la identificación. Por tanto, un usuario es casi pero no completamente
anónimo. En las redes amigo-a-amigo, sólo tus amigos pueden saber que tu
dirección está siendo usada para intercambiar ficheros.
La navegación Web, algo que suele verse como una actividad anónima, temporal
e irrelevante. Pero cuando navegamos, es frecuente que vayamos dejando
muchos rastros respecto a lo que hacemos. Quizá a algunos no les importe todo
esto, a otros sí que les preocupará.

1.7.7 AUTENTICACIÓN
Autenticación o autentificación es el acto de establecimiento o confirmación de
algo (o alguien) como auténtico, es decir que reclama hecho por, o sobre la cosa
son verdadero. La autenticación de un objeto puede significar (pensar) la
confirmación de su procedencia, mientras que la autenticación de una persona a
menudo consiste en verificar su identidad. La autenticación depende de uno o
varios factores.
Autenticación o autentificación, en términos de seguridad de redes de datos, se
puede considerar uno de los tres pasos fundamentales (AAA). Cada uno de ellos
es, de forma ordenada:
Autenticación En la seguridad de ordenador, la autenticación es el proceso de
intento de verificar la identidad digital del remitente de una comunicación como
una petición para conectarse. El remitente siendo autenticado puede ser una
persona que usa un ordenador, un ordenador por sí mismo o un programa del
ordenador. En un web de confianza, "autenticación" es un modo de asegurar que
los usuarios son quién ellos dicen que ellos son - que el usuario que intenta
realizar funciones en un sistema es de hecho el usuario que tiene la autorización
para hacer así.
Autorización Proceso por el cual la red de datos autoriza al usuario identificado a
acceder a determinados recursos de la misma.
Auditoría Mediante la cual la red o sistemas asociados registran todos y cada uno
de los accesos a los recursos que realiza el usuario autorizados o no.
El problema de la autorización a menudo, es idéntico a la de autenticación;
muchos protocolos de seguridad extensamente adoptados estándar, regulaciones
obligatorias, y hasta estatutos están basados en esta asunción. Sin embargo, el
uso más exacto describe la autenticación como el proceso de verificar la identidad
de una persona, mientras la autorización es el proceso de verificación que una
persona conocida tiene la autoridad para realizar una cierta operación. La
autenticación, por lo tanto, debe preceder la autorización. Para distinguir la
autenticación de la autorización de término estrechamente relacionada, existen
unas notaciones de taquigrafía que son: A1 para la autenticación y A2 para la
autorización que de vez en cuando son usadas, también existen los términos
AuthN y AuthZ que son usados en algunas comunidades.

1.7.8 INTEGRIDAD
El término integridad de datos se refiere a la corrección y completitud de los
datos en una base de datos. Cuando los contenidos se modifican con sentencias
INSERT, DELETE o UPDATE, la integridad de los datos almacenados puede
perderse de muchas maneras diferentes. Pueden añadirse datos no válidos a la
base de datos, tales como un pedido que especifica un producto no existente.
Pueden modificarse datos existentes tomando un valor incorrecto, como por
ejemplo si se reasigna un vendedor a una oficina no existente. Los cambios en la
base de datos pueden perderse debido a un error del sistema o a un fallo en el
suministro de energía. Los cambios pueden ser aplicados parcialmente, como por
ejemplo si se añade un pedido de un producto sin ajustar la cantidad disponible
para vender.
Una de las funciones importantes de un DBMS relacional es preservar la
integridad de sus datos almacenados en la mayor medida posible.
Tipos de restricciones de integridad
Datos Requeridos: establece que una columna tenga un valor no NULL. Se
define efectuando la declaración de una columna es NOT NULL cuando la tabla
que contiene las columnas se crea por primera vez, como parte de la sentencia
CREATE TABLE.
Chequeo de Validez: cuando se crea una tabla cada columna tiene un tipo de
datos y el DBMS asegura que solamente los datos del tipo especificado sean
ingresados en la tabla.
Integridad de entidad: establece que la clave primaria de una tabla debe tener un
valor único para cada fila de la tabla; si no, la base de datos perderá su integridad.
Se especifica en la sentencia CREATE TABLE. El DBMS comprueba
automáticamente la unicidad del valor de la clave primaria con cada sentencia
INSERT Y UPDATE. Un intento de insertar o actualizar una fila con un valor de la
clave primaria ya existente fallará.
Integridad referencial: asegura la integridad entre las claves ajenas y primarias
(relaciones padre/hijo). Existen cuatro actualizaciones de la base de datos que
pueden corromper la integridad referencial:

La inserción de una fila hijo se produce cuando no coincide la clave ajena
con la clave primaria del padre.
La actualización en la clave ajena de la fila hijo, donde se produce una
actualización en la clave ajena de la fila hijo con una sentencia UPDATE y la
misma no coincide con ninguna clave primaria.
La supresión de una fila padre, con la que, si una fila padre -que tiene uno o más
hijos- se suprime, las filas hijos quedarán huérfanas.
La actualización de la clave primaria de una fila padre, donde si en una fila padre,
que tiene uno o más hijos se actualiza su clave primaria, las filas hijos quedarán
huérfanas.
1.8 CONOCER EL ENEMIGO
Medias de seguridad a tener en cuenta por las empresas:
Establecer una política adecuada en la que deben figurar cuáles son los
puntos críticos de la red corporativa y las medidas que se van a tomar para
protegerlos.
Instalar una solución de seguridad eficiente tanto en los equipos de los
trabajadores como en los servidores.
Las contraseñas de acceso a los equipos deber ser seguras.
Contar con programas y soluciones de seguridad actualizada y protección
en sus equipos portátiles y en sus redes inalámbricas.
Conocer quién accede a la información.
Realizar auditorías para saber qué ha pasado y cuándo y así poder
responder a las necesidades legales.
Establecer distintos perfiles de acceso a intranets y extranet.
Precauciones de los usuarios:
Mantener actualizados los programas.
No abrir corres que procedan de fuentes desconocidas.
No seguir ningún vínculo que llegue por correo o mensajería instantánea.
No ejecutar archivos que procedan de fuentes desconocidas.
No descargarse por P2P archivos sospechosos.
No conectar dispositivos móviles como llaves USB o PDA sin haberse
asegurado antes de que no están infectados.
Bloquear el equipo cuando no se esté en el puesto de trabajo.

1.9 META DE PROYECTO DE SOFTWARE
Las metas y los objetivos proporcionan la dirección uniforme en un proyecto y
aseguran una visión constante a través del cuerpo de tenedores de apuestas.
Idealmente, las metas y los objetivos sirven como referencia constante para la
toma de decisión relacionada con el proyecto.
Uso
Las metas y los objetivos son público los elementos de información disponibles
que se comparten normalmente o a través de la documentación de la reunión o
mientras que la información introductoria en los planes del proyecto y el otro
proyecto apoya la documentación. Las metas y los objetivos se utilizan para
unificar la visión del equipo y la organización con respecto a cuál debe el proyecto
lograr y el acercamiento general a lograr esa meta.
Pueden ser fijadas en una localización altamente visible para asegurarse de que
están fácilmente disponibles para todos los miembros del equipo. El teórico Peter
Drucker de la gerencia sugiere que las metas de un negocio conduzcan sus
objetivos específicos del trabajo, y que esos objetivos necesitan ser delineados
claramente para asegurar niveles más altos del funcionamiento.
Contenido
Las metas y los objetivos deben indicar claramente el intento de la organización, el
proyecto, y las tareas o el esfuerzo bajo consideración—y los objetivos de
trabajadores individuales en la organización deben ser complementarios en servir
la meta. Las declaraciones de la meta se fijan en un alto nivel, describiendo lo que
espera la organización alcanzar. Se atan de cerca a las declaraciones de la visión
en que las metas son descripciones de lo que espera la organización lograr. Las
metas se pueden construir en el nivel de organización (―hacer un innovador
reconocido del software cambiando cómo se diseña y se apoya el software‖) o en
un más detallado, proyecto llano (―proveer de la cumbre el software innovador de
la logística que apoya su seguir y mantenimiento del inventario‖). En cualquier
caso, las metas son las declaraciones generales que son apoyadas por objetivos.
Los objetivos sirven la meta. Proporcionan claramente, dirección inequívoca en
cómo las metas serán resueltas. Idealmente, deben estar suficientemente claros
que permiten autodominio y self-monitoring de los miembros del equipo a quienes
se dan, que significa que cada uno objetivo debe tener cierta forma métrica de
medida que refleje los valores de la organización s. Si la meta es proporcionar

software innovador de la logística a la cumbre de la ayuda, los objetivos
pudieron incluir el siguiente:
• Para proporcionar un sistema que proporciona la información en tiempo real con
respecto la localización, el almacenaje, y al envejecimiento materiales;
• Para proporcionar un sistema que responde con la dirección (detallada, paso a
paso) modificada para requisitos particulares en las fuentes alternativas para el
material que está fuera de acción o en fuente baja.
Los términos llegan a ser importantes en establecer metas y objetivos. La
asunción que cualquier cosa que puede ser malinterpretada será malinterpretada
es una asunción justa y razonable. Una visión de la persona s ―de la fuente baja‖
pudo ser diferente que otros. El esfuerzo en objetivos del edificio es reducir al
mínimo la ambigüedad tanto como es posible y razonable.
Acercamientos
Una línea blurry existe entre las metas y los objetivos y entre los objetivos y los
requisitos. Como tal, una declaración general de la meta ―de la persona‖ s se
pudo detallar suficientemente para ser un objetivo para algún otro
(particularmente alguien en un nivel más alto en la organización). Porque los
objetivos se deben rendir tan claramente como sea posible, el esfuerzo de
construir en el nivel apropiado del detalle genera a veces los requisitos nacientes.
Para construir metas y objetivos mejores, las metas deben tratar el estado futuro
del proyecto, entregable, o de la organización. Los objetivos deben indicar cómo
el equipo y el proyecto trabajarán en esa dirección.
En algunas organizaciones, la declaración objetiva se liga siempre a las
limitaciones del momento específico y del coste.
Consideraciones
Porque las metas y los objetivos proporcionan la dirección, deben ser
declaraciones públicas. En reuniones y en instalaciones del proyecto, los objetivos
y las metas de un proyecto se deben fijar claramente para asegurar familiaridad
del equipo con la documentación. Tal franqueza sobre las metas y los objetivos
puede imposibilitar algo de las riñas inherentes a veces evidentes cuando los
miembros del equipo de proyecto se parecen trabajar en los propósitos cruzados.

Unidad II
Administración de los riesgos en la seguridad del software
Objetivo: El alumno conocerá e identificará los riesgos que se tienen al poner en
práctica la seguridad del software, así como los mecanismos para la evaluación
del desarrollo de sistemas seguros.
Contenido:
2.1 Descripción de la administración de los riesgos en la Seguridad del
Software
2.2 Administración de los riesgos en la seguridad del Software en la
práctica
2.2.1 Pruebas de Caja Negra
2.2.2 Equipo Rojo
2.3 Criterios Comunes

2.1 DESCRIPCIÒN DE LA ADMINISTRACIÒN DE LOS RIESGOS EN LA
SEGURIDAD DEL SOFTWARE
La administración de riesgo es un proceso de identificación y análisis de riesgos y
de creación de un plan para administrarlos. Un riesgo de seguridad se define
como la pérdida esperada debida o como consecuencia de amenazas anticipadas
por vulnerabilidades del sistema y la fuerza y determinación de los agentes
amenazantes correspondientes.
Identificación de los riesgos de seguridad
La identificación de los riesgos de seguridad es el primer paso en la evaluación de
la seguridad de la organización. Para administrar el riesgo de seguridad de forma
eficaz, debe establecerse claramente de modo que el equipo del proyecto llegue a
un consenso y se disponga a analizar las consecuencias y crear un plan de acción
para solucionar el riesgo. Aunque el ámbito del riesgo de seguridad está limitado a
la tecnología que el equipo del proyecto trata de proteger, la atención del equipo
debe ser lo suficientemente amplia como para abordar todas las fuentes de
riesgos de seguridad, incluido la tecnología, proceso, entorno y personas.
Actividades de identificación de riesgos
Durante el paso de identificación de riesgos de seguridad, el equipo deberá indicar
o enumerar de forma precisa los problemas de seguridad mediante la declaración
concisa de los riesgos a los que se enfrenta la organización. Resulta útil organizar
una serie de talleres o sesiones de brainstorming del equipo de seguridad con el
objetivo de identificar los riesgos asociados con una nueva situación.
Debido al cambio constante de la tecnología y los entornos, es importante que la
identificación de riesgos de seguridad no se considere una actividad aislada, sino
que el proceso debe repetirse periódicamente durante el ciclo de vida de las
operaciones de la organización.
Enfoque estructurado
El uso de un enfoque estructurado con relación a la administración de riesgos de
seguridad es fundamental porque permite que todos los miembros del equipo
utilicen un mecanismo sólido para tratar los problemas de seguridad. La
clasificación de las amenazas durante este paso es una forma útil de proporcionar
un enfoque sólido, reproducible y perceptible.

Desarrollo de las soluciones a los riesgos de seguridad
El desarrollo de las soluciones a los riesgos de seguridad es el proceso por el que
se toman los planes que se han creado en la fase de evaluación y se utilizan para
generar una nueva estrategia de seguridad que incluya administración de
configuración y revisiones, supervisión y auditoría del sistema, y directivas y
procedimientos operativos. Dado que se desarrollan diversas contramedidas, es
importante realizar un seguimiento e informe minuciosos de este proceso.
Declaración de riesgos de seguridad
Una declaración de riesgos de seguridad es una expresión del lenguaje normal de
la relación causal entre el estado de seguridad existente de la organización y un
resultado posible que no se ha realizado.
La primera parte de la declaración de riesgos de seguridad se denomina "la
condición", en la que se proporciona la descripción de un estado existente o
amenaza potencial que el equipo considera que puede causar algún daño. La
segunda parte de la declaración de riesgos se denomina "consecuencia", y en ella
se describe la pérdida no deseada de confidencialidad, integridad y disponibilidad
de un activo.
Las dos declaraciones están unidas por un término como "entonces" o "puede
resultar en" que implica una relación no confiable (es decir, menos del 100%) o
causal.
Modelo de proceso de seguridad
El modelo de proceso MSF se puede usar para desarrollar aplicaciones de
software e implementar tecnología de infraestructura. Este modelo sigue un ciclo
iterativo diseñado para abordar cambios de los requisitos de proceso en ciclos de
desarrollo cortos y versiones incrementales de la solución. Esto es posible gracias
a la administración de riesgo continua y los ciclos de pruebas.
Marco de administración de riesgos de seguridad
Descripción general
El marco utiliza el modelo de proceso MSF y describe una secuencia de alto nivel
de actividades para la creación e implementación de las soluciones de seguridad
de TI. En lugar de recomendar una determinada serie de procedimientos, el marco
es lo suficientemente flexible como para incorporar una amplia gama de procesos

de TI. El modelo de proceso abarca el ciclo de vida de una solución desde
el inicio del proyecto hasta la implementación activa.
Figura 1

2.2 ADMINISTRACIÒN DE LOS RIESGOS EN LA SEGURIDAD DEL
SOFTWARE EN LA PRÀCTICA
Prácticas de administración de riesgos de seguridad y de marco de
seguridad
Mientras se ejecuta el plan de seguridad, se llevan a cabo dos tipos de actividades
de administración de riesgo durante el ciclo de vida del proyecto. La primera es
administrar el riesgo inherente al propio proyecto y la segunda es administrar el
riesgo asociado a los componentes de seguridad. Los riesgos del proyecto se
evalúan sólo durante el ciclo de vida del proyecto, mientras que los riesgos de
seguridad se deben evaluar durante el ciclo de vida completo de la solución o el
sistema. La disciplina de administración de riesgo MSF sirve como base para la
administración de riesgos de las evaluaciones de los proyectos y de la seguridad.
La seguridad del sistema informático se debe realizar de forma preventiva y
continua para garantizar la seguridad de los activos de información y supervisar
nuevas amenazas y vulnerabilidades. Siempre que se agreguen funcionalidades
nuevas a la infraestructura de tecnología de la organización deberá tomarse en
cuenta la seguridad de la información. Además, es posible que algunos procesos y
procedimientos empresariales deban alterarse para operar en el entorno
modificado y proporcionar protección a los activos de información nuevos.
Los nueve pasos de la Disciplina de administración de riesgos de seguridad en la
práctica son:
1. Evaluación y valoración del activo
2. Identificación de los riesgos de seguridad
3. Análisis y ordenación según prioridad de los riesgos de seguridad
4. Seguimiento, planeamiento y programación de los riesgos de seguridad
desarrollo e implementación
5. Desarrollo de las soluciones de seguridad
6. Pruebas de las soluciones de seguridad
7. Obtención de información sobre seguridad
Operación
8. Reevaluación de los riesgos de seguridad y los activos nuevos y cambiados
9. Estabilización e implementación de contramedidas nuevas o cambiadas

Análisis de los riesgos de seguridad
El análisis de los riesgos de seguridad se utiliza para examinar los posibles
ataques, herramientas, métodos y técnicas que permiten explotar una posible
vulnerabilidad. Se trata de un método de identificación de riesgos y evaluación de
posibles daños que podrían producirse para justificar las salvaguardas de
seguridad.
Un análisis de este tipo presenta tres objetivos principales: identificar riesgos,
cuantificar la repercusión de posibles amenazas y proporcionar un balance
económico entre el efecto del riesgo y el coste de la contramedida. Se recopila
información para calcular el nivel de riesgo de modo que el equipo pueda tomar
decisiones razonables y centrar todos los esfuerzos en la solución de los riesgos
de seguridad.
Este análisis se utiliza posteriormente para dar prioridad a los riesgos de
seguridad y permitir a la organización asignar recursos con los que se
solucionarán los problemas de seguridad más importantes.
Un análisis de riesgo permite integrar los objetivos del programa de seguridad en
los objetivos y requisitos comerciales de la compañía. Cuanto más coordinados
resulten los objetivos comerciales y los de seguridad, más fácil será cumplirlos.
Etapa: Pruebas
La prueba del software es un elemento crítico para la garantía de la calidad del
software. El objetivo de la etapa de pruebas es garantizar la calidad del producto
desarrollado. Además, esta etapa implica:
Verificar la interacción de componentes.
Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes
de entregar el software al cliente.
Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de
errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se
asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida:
podemos probar la funcionalidad de los primeros prototipos; probar la estabilidad,
cobertura y rendimiento de la arquitectura; probar el producto final, etc.

Plan de Pruebas
Un plan de pruebas está constituido por un conjunto de pruebas. Cada prueba
debe:
dejar claro qué tipo de propiedades se quieren probar (corrección, robustez,
fiabilidad, amigabilidad, ...)
dejar claro cómo se mide el resultado
especificar en qué consiste la prueba (hasta el último detalle de cómo se
ejecuta)
definir cual es el resultado que se espera (identificación, tolerancia, ...)
¿Cómo se decide que el resultado es acorde con lo esperado?
La prueba es un proceso que se enfoca sobre la lógica interna del software y las
funciones externas. La prueba es un proceso de ejecución de un programa con la
intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta
probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene
éxito si descubre un error no detectado hasta entonces.
La prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que
existen defectos en el software.
2.2.1 PRUEBA DE CAJA NEGRA
Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente
indiferente el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretende demostrar que:
Las funciones del software son operativas.
La entrada se acepta de forma adecuada.
Se produce una salida correcta, y
La integridad de la información externa se mantiene.
Se derivan conjuntos de condiciones de entrada que ejerciten completamente
todos los requerimientos funcionales del programa.
La prueba de la caja negra intenta encontrar errores de las siguientes categorías:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a bases de datos externas.

Errores de rendimiento.
Errores de inicialización y de terminación.
Los casos de prueba deben satisfacer los siguientes criterios:
Reducir, en un coeficiente que es mayor que uno, el número de casos de
prueba adicionales.
Que digan algo sobre la presencia o ausencia de clases de errores.
Métodos de prueba de caja negra
Algunos de los métodos empleados en las pruebas de caja negra son los
siguientes:
Métodos de prueba basados en grafos: en este método se debe entender
los objetos (objetos de datos, objetos de programa tales como módulos o
colecciones de sentencias del lenguaje de programación) que se modelan
en el software y las relaciones que conectan a estos objetos. Una vez que
se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas
que verifiquen que todos los objetos tienen entre ellos las relaciones
esperadas. En este método:
1. Se crea un grafo de objetos importantes y sus relaciones.
2. Se diseña una serie de pruebas que cubran el grafo de manera que
se ejerciten todos los objetos y sus relaciones para descubrir errores.
Describe un número de modelados para pruebas de comportamiento que pueden
hacer uso de los grafos:
 Modelado del flujo de transacción. Los nodos representan los pasos de
alguna transacción (por ejemplo, los pasos necesarios para una reserva en
una línea aérea usando un servicio en línea), y los enlaces representan las
conexiones lógicas entre los pasos (por ejemplo, vuelo, información,
entrada es seguida de validación /disponibilidad, procesamiento).
 Modelado de estado finito. Los nodos representan diferentes estados del
software observables por el usuario (por ejemplo, cada una de las pantallas
que aparecen cuando un telefonista coge una petición por teléfono), y los
enlaces representan las transiciones que ocurren para moverse de estado a
estado (por ejemplo, petición-información se verifica durante inventario-
disponibilidad-búsqueda y es seguido por cliente-factura-información-
entrada).

 Modelado de flujo de datos. Los nodos objetos de datos y los
enlaces son las transformaciones que ocurren para convertir un objeto de
datos en otro.
 Modelado de planificación. Los nodos son objetos de programa y los
enlaces son las conexiones secuenciales entre esos objetos. Los pesos de
enlace se usan para especificar los tiempos de ejecución requeridos al
ejecutarse el programa.
 Gráfica Causa-efecto. La gráfica Causa-efecto. representa una ayuda
gráfica en seleccionar, de una manera sistemática, un gran conjunto de
casos de prueba. Tiene un efecto secundario beneficioso en precisar
estados incompletos y ambigüedades en la especificación.
Un gráfico de causa-efecto es un lenguaje formal al cual se traduce una
especificación. El gráfico es realmente un circuito de lógica digital (una red
combinatoria de lógica), pero en vez de la notación estándar de la electrónica, se
utiliza una notación algo más simple. No hay necesitad de tener conocimiento de
electrónica con excepción de una comprensión de la lógica booleana (entendiendo
los operadores de la lógica y, o, y no).
Partición equivalente: Presenta la partición equivalente como un método
de prueba de caja negra que divide el campo de entrada de un programa en
clases de datos de los que se pueden derivar casos de prueba. Un caso de
prueba ideal descubre de forma inmediata una clase de errores que, de otro
modo, requerirían la ejecución de muchos casos antes de detectar el error
genérico. La partición equivalente se dirige a la definición de casos de
prueba que descubran clases de errores, reduciendo así el número total de
casos de prueba que hay que desarrollar.
Una clase de equivalencia representa un conjunto de estados válidos o no válidos
para condiciones de entrada. Típicamente, una condición de entrada es un valor
numérico específico, un rango de valores, un conjunto de valores relacionados o
una condición lógica.
El objetivo de partición equivalente es reducir el posible conjunto de casos de
prueba en uno más pequeño, un conjunto manejable que evalúe bien el software.
Se toma un riesgo porque se escoge no probar todo. Así que se necesita tener
mucho cuidado al escoger las clases.
La partición equivalente es subjetiva. Dos probadores quienes prueban un
programa complejo pueden llegar a diferentes conjuntos de particiones.

En el diseño de casos de prueba para partición equivalente se procede en
dos pasos:
1. Se identifican las clases de equivalencia. Las clases de equivalencia son
identificadas tomando cada condición de entrada (generalmente una
oración o una frase en la especificación) y repartiéndola en dos o más
grupos. Es de notar que dos tipos de clases de equivalencia están
identificados: las clases de equivalencia válidas representan entradas
válidas al programa, y las clases de equivalencia inválidas que representan
el resto de los estados posibles de la condición (es decir, valores erróneos
de la entrada).
2. Se define los casos de prueba. El segundo paso es el uso de las clases
de equivalencia para identificar los casos de prueba. El proceso es como
sigue: se asigna un número único a cada clase de equivalencia. Hasta que
todas las clases de equivalencia válidas han sido cubiertas por los casos de
prueba, se escribe un nuevo caso de prueba que cubra la clase de
equivalencia válida. Y por último hasta que los casos de prueba hallan
cubierto todas las clases de equivalencia inválidas, se escribe un caso de la
prueba que cubra una, y solamente una, de las clases de equivalencia
inválidas descubiertas.
Prueba de la tabla ortogonal: hay aplicaciones donde el número de parámetros
de entrada es pequeño y los valores de cada uno de los parámetros está
claramente delimitado. Cuando estos números son muy pequeños (por ejemplo, 3
parámetros de entrada tomando 3 valores diferentes), es posible considerar cada
permutación de entrada y comprobar exhaustivamente el proceso del dominio de
entrada. En cualquier caso, cuando el número de valores de entrada crece y el
número de valores diferentes para cada elemento de dato se incrementa, la
prueba exhaustiva se hace impracticable.
La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de
entrada es relativamente pequeño pero demasiado grande para posibilitar pruebas
exhaustivas. El método de prueba de la tabla ortogonal es particularmente útil al
encontrar errores asociados con fallos localizados -una categoría de error
asociada con defectos de la lógica dentro de un componente software.

2.2.2 EQUIPO ROJO
A finales de 1996, Dan Farmer (creador de una de las herramientas más útiles en
la detección de intrusos: SATAN) realizó un estudio sobre seguridad analizando
2.203 sistemas de sitios en Internet. Los sistemas objeto del estudio fueron Web
Sites orientados al comercio y con contenidos específicos, además de un conjunto
de sistemas informáticos aleatorios con los que realizar comparaciones.
El estudio se realizó empleando técnicas sencillas y no intrusivas. Se dividieron los
problemas potenciales de seguridad en dos grupos: rojos (red) y amarillos
(yellow).
Los problemas del grupo rojo son los más serios y suponen que el sistema está
abierto a un atacante potencial, es decir, posee problemas de seguridad conocidos
en disposición de ser explotados. Así por ejemplo, un problema de seguridad del
grupo rojo es un equipo que tiene el servicio de FTP anónimo mal configurado.
Los problemas de seguridad del grupo amarillo son menos serios pero también
reseñables. Implican que el problema detectado no compromete inmediatamente
al sistema pero puede causarle serios daños o bien, que es necesario realizar
tests más intrusivos para determinar si existe o no un problema del grupo rojo.
La Agencia de Seguridad Nacional americana, una de los organismos más
poderosos del planeta, ayudó a mejorar la seguridad de Windows Vista.
(DT, AGENCIAS) El Washington Post publico que la agencia ha admitido su
'colaboración no específica' en Vista. Tony Sager, el jefe de análisis de
vulnerabilidades y del grupo de operaciones de la NSA, le dijo al rotativo que la
intención de esta agencia era la de ayudar a todo el mundo en todo lo posible. La
NSA utilizó un equipo azul y otro rojo para analizar el software. El equipo rojo tenía
el rol de tratar de corromper o robar información como si de un "adversario
técnicamente competente y muy decidido" se tratase. El equipo azul ayudó a los
administradores del departamento de defensa con la configuración de Windows
Vista.

2.3 CRITERIOS COMUNES
Los Criterios Comunes(CC) tienen su origen en 1990 y surgen como resultado de
la armonización de los criterios sobre seguridad de productos software ya
utilizados por diferentes países con el fin de que el resultado del proceso de
evaluación pudiese ser aceptado en múltiples países. Los CC permiten comparar
los resultados entre evaluaciones de productos independientes. Para ello, se
proporcionan un conjunto común de requisitos funcionales para los productos de
TI (Tecnologías de la Información). Estos productos pueden ser hardware,
software o firmware. El proceso de evaluación establece un nivel de confianza en
el grado en el que el producto TI satisface la funcionalidad de seguridad de estos
productos y ha superado las medidas de evaluación aplicadas. Los CC son útiles
como guía para el desarrollo, evaluación o adquisición de productos TI que
incluyan alguna función de seguridad. La lista de productos certificados según los
CC se encuentra disponible en la web de Common Criteria.
Este estándar, los Criterios Comunes (CC), tiene como finalidad el ser usado
como base para la evaluación de las propiedades de seguridad de los productos y
sistemas de Tecnologías de la Información (TI). Estableciendo esta base de
criterios comunes, los resultados de una evaluación de seguridad de TI será
significativa para una mayor audiencia.
Los CC permitirán la comparación entre los resultados de evaluaciones de
seguridad independientes, al proporcionar un conjunto común de requisitos para
las funciones de seguridad de los productos y sistemas de TI y para las medidas
de garantía aplicadas a éstos durante la evaluación de seguridad. El proceso de
evaluación establece un nivel de confianza del grado en que las funciones de
seguridad de tales productos y sistemas y las medidas de garantía aplicadas
coinciden con aquellos requisitos. Los CC son útiles como guía para el desarrollo
de productos o sistemas con funciones de seguridad de TI y para la adquisición de
productos y sistemas comerciales con dichas funciones. Los CC tratan la
protección de la información contra la revelación no autorizada, modificación o
pérdida de uso. Las categorías de protección relacionadas con estos tres tipos de
fallos de seguridad son llamadas normalmente confidencialidad, integridad y
disponibilidad respectivamente.
Los CC pueden ser también aplicables en aspectos de seguridad de TI distintos a
estos tres. Los CC se concentran en aquellas amenazas que provienen de una
actividad humana, ya sea maliciosa o de otro tipo, pero también pueden ser
aplicables a otras amenazas no humanas. Además, los CC pueden ser aplicados

en otras áreas distintas de TI pero no se hace ninguna declaración de
competencia fuera del estricto ámbito de la seguridad de TI.
Los CC son aplicables a las medidas de seguridad de TI implementadas en
hardware, firmware o software. Cuando se pretenda tratar aspectos particulares de
evaluación a aplicar sólo en determinados métodos de implementación, se
indicará expresamente en las declaraciones de los criterios correspondientes.
Algunos temas, porque involucran técnicas especializadas o porque son, de
alguna manera, adyacentes a la seguridad de TI, son considerados ajenos a la
finalidad de los CC.
Entre estos cabe destacar los siguientes:
 Los CC no contienen criterios de evaluación de la seguridad
correspondientes a medidas de seguridad administrativa no relacionadas
directamente con las medidas de seguridad de TI. Sin embargo, se
reconoce que una parte significativa de la seguridad de un TOE puede, a
menudo, proporcionarse a través de medidas administrativas
(organizativas, de personal, físicas y control de procedimientos). Las
medidas de seguridad administrativas, en el entorno operativo del TOE, son
tratadas como hipótesis de un uso seguro donde éstas tienen un impacto
importante en la capacidad de las medidas de seguridad de TI para
contrarrestar las amenazas identificadas.
 La evaluación de aspectos técnicos físicos de la seguridad de TI como
control de radiaciones electromagnéticas no se trata específicamente,
aunque varios de los conceptos tratados serán aplicables en esta área. En
particular, los CC tratan algunos aspectos de la protección física del TOE.
 Los CC no tratan ni la metodología de evaluación ni el marco administrativo
y legal bajo el cual los criterios pueden ser aplicados por las autoridades de
evaluación. Sin embargo, se espera que los CC sean usados para
propósitos de evaluación en el contexto de un determinado marco
administrativo y con una determinada metodología.
 Los procedimientos para el uso de los resultados de la evaluación en la
acreditación de productos o sistemas están fuera del objetivo de los CC. La
acreditación de un producto o sistema es el proceso administrativo por el
que se autoriza el uso de dicho producto o sistema de TI en su entorno
operativo. La evaluación se centra en las partes de seguridad de TI del
producto o sistema y en aquellas partes del entorno operativo que pueden

afectar directamente el seguro uso de los elementos de TI. Los
resultados del proceso de evaluación son, por lo tanto, un dato de valor
para el proceso de acreditación. Sin embargo, como hay otras técnicas más
apropiadas para la valoración, tanto de las propiedades de seguridad de un
producto o sistema no relacionados con TI, como de su relación con las
partes de seguridad de TI, los acreditadores deberán establecer
separadamente estos aspectos.
 Los criterios para la valoración de las cualidades inherentes de los
algoritmos criptográficos no se tratan en los CC. Si se necesita una
valoración independiente de las propiedades matemáticas de la criptografía
introducida en un TOE, deberá ser proporcionada por el esquema bajo el
cual se están aplicando los CC.
Funcionamiento
Con el fin de poder certificar un producto según los Criterios Comunes se deben
comprobar, por parte de uno de los laboratorios independientes aprobados,
numerosos parámetros de seguridad que han sido consensuados y aceptados por
22 países de todo el mundo. El proceso de evaluación incluye la certificación de
que un producto software específico verifica los siguientes aspectos:
Los requisitos del producto están definidos correctamente.
Los requisitos están implementados correctamente.
El proceso de desarrollo y documentación del producto cumple con ciertos
requisitos previamente establecidos.
Los Criterios Comunes establecen entonces un conjunto de requisitos para definir
las funciones de seguridad de los productos y sistemas de Tecnologías de la
Información y de los criterios para evaluar su seguridad. El proceso de evaluación,
realizado según lo prescrito en los Criterios Comunes, garantiza que las funciones
de seguridad de tales productos y sistemas reúnen los requisitos declarados. Así,
los clientes pueden especificar la funcionalidad de seguridad de un producto en
términos de perfiles de protección estándares y de forma independiente
seleccionar el nivel de confianza en la evaluación de un conjunto definido desde el
EAL1 al EAL7.

Perfiles de protección
Un perfil de protección (Protection Profile) define un conjunto de objetivos y
requisitos de seguridad, independiente de la implantación, para un dominio o
categoría de productos que cubre las necesidades de seguridad comunes a varios
usuarios. Los perfiles de protección son reutilizables y normalmente públicos y
están compuestos de:
Requisitos funcionales (SFR, Security Funcional Requirement)
proporcionan mecanismos para hacer cumplir la política de seguridad.
Como ejemplos de requisitos funcionales mencionar la protección de datos
de usuario, el soporte criptográfico, la autenticación, la privacidad o el
control de acceso.
Requisitos de confianza o aseguramiento (SAR, Security Assurance
Requirement) proporcionan la base para la confianza en que un producto
verifica sus objetivos de seguridad.
Los requisitos de confianza se han agrupado en niveles de confianza en la
evaluación (EAL, Evaluation Assurance Levels) que contienen requisitos de
confianza construidos específicamente en cada nivel. Los EALs proporcionan una
escala incremental que equilibra el nivel de confianza obtenido con el coste y la
viabilidad de adquisición de ese grado de confianza. El incremento de confianza
de un EAL a otro se obtiene incrementando rigor, alcance y/o profundidad en el
componente y añadiendo componentes de confianza de otras familias de
confianza (por ejemplo, añadiendo nuevos requisitos funcionales).
Niveles de confianza
Los niveles de confianza en la evaluación definidos en el ISO/IEC 15408-3 [ISO
15408-3 2005] van desde EAL1 (el menor) a EAL 7 (el mayor) y se definen de
forma acumulativa (verificaciones de nivel n+1 implican realizar las de nivel n, 1 ≤
n ≥ 7):
 EAL1 (funcionalidad probada): es aplicable donde se requiere tener cierta
confianza de la operación correcta, y donde además, las amenazas a la
seguridad no son vistas como serias. Una evaluación en este nivel debe
proporcionar evidencia de que las funciones del objeto de evaluación son
consistentes con su documentación, y que proporcionan protección útil
contra amenazas identificadas.

 EAL2 (estructuralmente probado): requiere la cooperación del
desarrollador en términos de la distribución de la información del diseño, y
los resultados de las pruebas y proporciona confianza a través de un
análisis de las funciones de seguridad, usando una especificación funcional
y de interfaz, manuales y diseño de alto nivel del producto para entender el
comportamiento de seguridad. Además, en este nivel se verifica que el
desarrollador realizó un análisis de vulnerabilidades a través de la ejecución
de pruebas de caja negra (Black-box).
 EAL3 (probado y verificado metódicamente): permite a un desarrollador
alcanzar una máxima garantía de ingeniería de seguridad positiva en el
estado de diseño sin la alteración substancial de prácticas de desarrollo
válidas existentes. El análisis en este nivel se apoya en las pruebas de caja
gris (grey box), la confirmación selectiva independiente de los resultados de
las pruebas del desarrollador, y la evidencia de búsqueda de
vulnerabilidades obvias del desarrollador. Además, se realizan controles del
entorno de desarrollo y de gestión de configuración del producto.
 EAL4 (diseñado, probado y revisado metódicamente): este nivel le
permite a un desarrollador alcanzar máxima garantía de ingeniería de
seguridad positiva basada en buenas prácticas de desarrollo comercial, las
cuales, aunque rigurosas, no requieren del conocimiento especializado
substancial, destreza, ni otros recursos. En este caso, el análisis se apoya
en el diseño de bajo nivel de los módulos del producto y se realiza
búsqueda de vulnerabilidades independiente de las pruebas realizadas por
el desarrollador.
 EAL5 (diseñado y probado semiformalmente): permite a un desarrollador
alcanzar máxima garantía de ingeniería de seguridad positiva mediante la
aplicación moderada de técnicas de ingeniería de seguridad. La confianza
se apoya, en este caso, en un modelo formal y una presentación
semiformal de la especificación funcional y el diseño de alto nivel. La
búsqueda de vulnerabilidades debe asegurar la resistencia relativa a los
ataques de penetración.
 EAL6 (diseño verificado y probado semiformalmente): permite a los
desarrolladores alcanzar una alta garantía en la aplicación de técnicas de
ingeniería de seguridad para un entorno de desarrollo riguroso y donde el
objeto de evaluación es considerado de gran valor para la protección del
alto costo o estimación de esos bienes contra riesgos significativos.
Además, es aplicable para el desarrollo de objetos de evaluación,
destinados a salvaguardar la seguridad informática en situaciones de alto

riesgo donde el valor de los bienes protegidos justifica los costos
adicionales. El análisis en este nivel se apoya en un diseño modular y en
una presentación estructurada de la implementación del producto. La
búsqueda de vulnerabilidades debe mostrar una alta resistencia a los
ataques de penetración.
 EAL7 (diseño verificado y probado formalmente): es aplicable al
desarrollo de objetos de evaluación de seguridad, para su aplicación en
situaciones de muy alto riesgo o donde el alto valor de los bienes justifica
los más altos costos. La aplicación práctica del nivel EAL7 está limitada
actualmente a objetos de evaluación con seguridad estrechamente
enfocada a la funcionalidad, y que es sensible al análisis formal y extenso.
Este EAL representa un incremento
Significativo respecto a la garantía de nivel EAL6 a través del requisito de análisis
de gran amplitud, mediante representaciones formales y correspondencia formal y
pruebas de gran amplitud. Además, el evaluador confirmará de forma
independiente y completa los resultados de las pruebas de caja blanca (White-
box) realizadas por el desarrollador.
Los niveles EAL 5 al 7 incluyen modelos y demostraciones semiformales y
formales por tanto, se aplican a productos con objetivos de seguridad muy
específicos (entorno militar, por ejemplo). Por otra parte, estos niveles requieren
de la generación de una gran cantidad de documentación durante el proceso de
desarrollo que debe entregarse al evaluador para que éste pueda confirmar la
información. Finalmente, para la aplicación de los Criterios Comunes, existe una
metodología con los criterios a evaluar para cada uno de los niveles de confianza
estandarizada por la Norma ISO/IEC 18045 (ISO 18045, 2008) y denominada
CEM (Common Methodology for IT Security Evaluation) disponible en la web de
Common Criteria.

DDS

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à DDS

Similaire à DDS (20)

Plus de Bertha Vega

Plus de Bertha Vega (20)

Dernier

Dernier (20)

DDS