Antología DSS

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA
Academia de Informtica y Sistemas Computacionales
Unidad I
Introduccin a la seguridad del software Objetivo: El alumno conocer y comprender los fundamentos tericos, 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 informacin de vulnerabilidades 1.4.1. Buqtraq 1.4.2. CERT Advisores 1.4.3. RISK Digest 1.5 Tendencias tcnicas 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. Prevencin 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. Autenticacin 1.7.8. Integridad 1.8 Conocer al enemigo 1.9 Metas de proyecto de Software
Asignatura: Desarrollo de Software Seguro

Material compilado con fines acadmicos, se prohbe su reproduccin total o parcial sin autorizacin de cada autor.

1.1 CONCEPTO DE SOFTWARE El software es el nexo de unin 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 comunicacin entre el hombre y la mquina; 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 actuacin del computador, haciendo que ste siga en sus acciones una serie de esquemas lgicos predeterminados. Tal caracterstica lgica o inteligente del software es lo que hace que se le defina tambin como la parte inmaterial de la informtica, ya que aunque los programas que constituyen el software residan en un soporte fsico, como la memoria principal o los disquetes (o cualquier dispositivo rgido de almacenamiento), la funcin 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 fsicos se construyen cada vez con ms inteligencia incluida, en forma que se resuelven por hardware funciones anteriormente slo factibles por software, es prcticamente imposible que el avance tecnolgico llegue algn da a eliminar la necesidad de software, ya que ste tambin evoluciona y las facilidades que el usuario pide al computador son cada da ms sofisticadas. La clasificacin bsica es: software de sistema y software de aplicacin.
El software de sistema es el software bsico o sistema operativo.
Es un conjunto de programas cuyo objeto es facilitar el uso del computador (asla de la complejidad de cada dispositivo, y presenta al exterior un modelo comn de sistema de manejo para todos los dispositivos) y conseguir que se use eficientemente
El software de aplicacin
Son los programas que controlan y optimizacin la operacin de la mquina, establecen una relacin bsica y fundamental entre el usuario y el computador, hacen que el usuario pueda usar en forma cmoda y amigable complejos sistemas hardware, realizan funciones que para el usuario seran engorrosas o incluso imposibles, y actan 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. Segn la European Spacial Agency (ESA), administradora del programa, la desviacin 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 conversin de un nmero flotante de 64 bits a un nmero entero de 16 bits. Otro de los casos de fallas en software que caus graves daos a la integridad de las personas, Therac-25. Era un aparato para el tratamiento del cncer por emisin de rayos cuyos controles (de la cantidad de energa emitida) implementados en hardware fueron removidos y slo se dejaron los de software que (obviamente) fallaron. Error en un sistema de autenticacin de tarjetas de crdito (1995) Los dos sistemas ms grandes en ese pas para la autorizacin de crdito ( Barclays PQD y NatWests Streamline) fallaron el sbado 28 de octubre de 1995 imposibilitando que los comercios verificaran las tarjetas de crdito de sus clientes. En el caso de Barclay, ms 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 comunicacin por razones desconocidas, y que retraso la autentificacin 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 dlares 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 compaa. Error en sistema de cobranza de MCI (1996). En la edicin de 29 de marzo de 1996 del Washington Post, MCI reporto que le devolveran aproximadamente 40 millones de dlares a sus clientes por un error de cobranza causada por un sistema de cmputo. El error de cobranza fue descubierto por un reportero investigador de una estacin local de televisin 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 investigacin.
1.3 FUTURO DEL SOFTWARE


"El futuro del software es un desafo" 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 estn sustituyendo al software estndar para consumidores, cada vez ms aplicaciones empresariales estn trasladndose 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 desafo interesante para todos los involucrados en el desarrollo de software. Y el hardware, que durante muchos aos ha sido el cuello de botella de los sistemas informticos, crecer hasta volverse de 50 a 100 veces ms 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 sera inteligente tomar sistemas que actualmente desperdician millones de ciclos de CPU y agregarle ms capacidad sin modificar el uso que reciben, para de ese modo desperdiciar ms poder an. Sin dudas, "se avecina un nuevo paradigma de software, y he aqu el mayor desafo". Cualquier especulacin sobre el futuro del software merece, como mnimo, una revisin 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 transicin desde sistemas existentes a sistemas empresariales estndar. El auge de los ordenadores personales que desemboc en una productividad de los usuarios sin precedentes, as como una proliferacin de islas de datos. El auge de Internet, que condujo a una explosin de informacin y cambi el modo en que millones de personas trabajan, juegan y compran. Tambin el aumento del uso de Internet y el acceso permanente a la red. La aparicin de estndares y tecnologas 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 integracin con los sistemas de servidor. La aparicin del modelo On-Demand, que supona 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 ms satisfactorios de este modelo con 55,400 clientes y ms de 800 aplicaciones.
1.4 FUENTES PARA LA INFORMACIN DE VULNERABILIDADES En cualquier caso conviene indicar las fuentes ms importantes de informacin asociada a vulnerabilidades de seguridad. No hay que olvidar que la mayor parte de esta informacin es de dominio pblico 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 corporacin 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 coordinacin 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 informacin 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 ms 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 compaa (herramientas de deteccin de intrusos, sistemas de anlisis de vulnerabilidades...) como de servicios comerciales basados en sta. La base de datos ICAT publicada por el instituto de estndares del Gobierno norteamericano, el NIST, y disponible en http://icat.nist.gov. Se trata de una metabase de datos de informacin de vulnerabilidades, con ms 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 utilizacin.
Dentro de estas fuentes de informacin podemos encontrar todo tipo de vulnerabilidades, desde ataques a servidores IIS de Microsoft a travs de cdigo Unicode hasta desbordamientos de bfer de Oracle Application Server, pasando por pequeas vulnerabilidades de sistemas Windows como las existentes en la ayuda online de Windows. Como es lgico todas estas bases

de datos se estn actualizando continuamente, a medida que se publicitan nuevos fallos de seguridad. Las fuentes de informacin 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, informacin 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 informacin 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 SOFWARE
Tendencias que afectan a los sistemas de informacin Al considerar un Sistema de Informacin 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 informacin de cualquier empresa, debe ser revisado peridicamente; 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 estadsticos, es recomendable dentro de un ao cambiarlo, todo lo que es mquinas y software; porque si no realizaramos esto, se cambiara toda la estructura organizacional de la misma).
Reestructuracin Organizacional (Puede ser una reestructuracin con los mismos puestos). Una reestructuracin organizacional con cualquier empresa, implica cambios siempre en vista a buscar un mejor funcionamiento, evitar la burocracia, agilitar trmites o procesos, la reestructuracin puede ser de varios tipos, as por ejemplo. Aumentar o disminuir departamentos, puestos, reestructuracin de objetivos, etc. Siempre la reestructuracin afecta a los sistemas de informacin de la empresa. Revisin y Valorizacin del escalafn (No es para bien si no tambin para mal) La revisin y la revalorizacin del escalafn se espera que afecte a favor de los sistemas de informacin de las empresas, si el efecto es contrario el auditor deber emitir un informe del empleado a los empleados (Especficamente de departamentos), que estn boicoteando la informacin de la empresa. Cambios en el flujo de Informacin

(Datos para el sistema de Informacin) Se refiere al cambio de flujo de datos exclusivamente en el rea informtica, esto afecta directamente en sistema informtico y por tanto al sistema de informacin. En lo que respecta a la Auditora informtica, el efecto puede ser positivo y negativo, dependiendo a los resultados obtenidos en cuanto al proceso de datos (menos seguridad, ms seguridad, backup). As por ejemplo: Se ha cambiado el flujo de informacin 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 informacin, en el cual se ingresan los datos a un sistema informtico, y de acuerdo a los parmetros y normas de la empresa el sistema arroja un sueldo lquido a cobrarse, genera automticamente el reporte, los cheques y el contador solo aprueba este reporte). (Un ejemplo es cuando existe migracin de datos, la informacin migra o se cambia a otro sistema ms sofisticado).
1.6 Actualizacin
BREAKING AND PATCH
Modificacin que se aplica al software para corregir un problema o incorporar una funcin nueva. Realizar los pasos necesarios para aplicar actualizaciones a un sistema. El sistema se analiza y, a continuacin, se descargan y se aplican las actualizaciones. Se denomina tambin patch. Actualizacin con firma Actualizacin que incluye una firma digital vlida. Las actualizaciones firmadas ofrecen mayor seguridad que las que no disponen de firma. La firma digital de la actualizacin puede verificarse antes de aplicarla al sistema. Las firmas digitales vlidas 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). Actualizacin de funcin Actualizacin que incorpora una nueva funcin en el sistema. Actualizacin sin firma Actualizacin que no incluye una firma digital.

Parche (informtica) En informtica, un parche es una seccin de cdigo que se introduce a un programa. Dicho cdigo puede tener varios objetivos; sustituir cdigo errneo, agregar funcionalidad al programa, aplicar una actualizacin, etc. Los parches suelen ser desarrollados por programadores ajenos al equipo de diseo inicial del proyecto (aunque no es algo necesariamente cierto). Como los parches se pueden aplicar tanto a un binario ejecutable como al cdigo 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 segn su propsito Parches de depuracin El objetivo de este tipo de parches es reparar bugs, o errores de programacin 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 versin 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 actualizacin Consiste en modificar un programa para convertirlo en un programa que utilice metodologas ms nuevas. Por ejemplo, optimizar en tiempo cierto programa, utilizar algoritmos mejorados, aadir funcionalidades, eliminar secciones obsoletas de software, etc. 1.7 METAS DE LA SEGURIDAD ENFOCADAS AL SOFTWARE La Arquitectura de Seguridad de Informacin es la prctica de aplicar un mtodo riguroso y comprensivo para describir una estructura actual y/o futura y el comportamiento de los procesos de seguridad de una organizacin, sistemas de seguridad de informacin y subunidades de personal y organizativas, para que se alineen con las metas comunes de la organizacin y la direccin estratgica. Aunque a menudo se asocie estrictamente con tecnologas para la seguridad de la informacin, se relaciona en trminos ms generales con la prctica de seguridad de optimizacin del negocio, donde dirige la arquitectura de seguridad del negocio, la realizacin de gestiones y tambin la arquitectura de procesos de seguridad. La Arquitectura de Seguridad de Informacin en la Empresa est convirtindose en una prctica habitual dentro de las instituciones financieras

alrededor del mundo. El propsito fundamental de crear una arquitectura de seguridad de informacin en la empresa es para asegurar que la estrategia de negocio y la seguridad de las tecnologas de la informacin (TI) estn alineadas. Como tal, la arquitectura de seguridad de la informacin en la empresa permite la trazabilidad desde la estrategia de negocio hasta la tecnologa subyacente.
Metas de la Seguridad

Proporcionar estructura, coherencia y cohesin 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 atrs hasta la estrategia de negocio, especficamente requerimientos de negocio y principios clave Proveer abstraccin para que factores complicados puedan ser eliminados y reinstalados en niveles de detalle diferente slo cuando sean requeridos Establecer un lenguaje comn para la seguridad de la informacin dentro de la organizacin
Proteccin del software: Los programas de ordenador actualmente estn expresamente excluidos de la proteccin a travs de patentes en el artculo 4 de la Ley espaola de patentes 11/1986. La proteccin que se aplica con carcter general a este tipo de resultado de investigacin ser la que le otorga la Ley de Propiedad Intelectual. Concretamente el ttulo VII se dedica los programas de ordenador. Una caracterstica principal de este tipo de proteccin consiste en que los derechos sobre la obra (en este caso programa de ordenador) se generan automticamente desde el momento en que se ha creado el programa. Esto significa: Que no hace falta inscribir el programa en ningn 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 ningn caso es conveniente desvelar el cdigo fuente a terceros. 1.7.1 PREVENCION


Un sistema de prevencin/proteccin para defenderse de las intrusiones y no slo para reconocerlas e informar sobre ellas, como hacen la mayora de los IDS. El software de prevencin contempla: Gestin de prevencin de riesgos a nivel de centros de trabajo y trabajadores. Gestin de subcontratas. Histrico de evaluaciones de riesgos realizadas. Composicin de equipos de emergencia. Histrico de cursos de prevencin y seguridad realizados. Estadsticas de siniestralidad. Anlisis de accidentes. Control de la Formacin en materia de prevencin. Gestin de Equipos de proteccin individual entregados al personal. La efectividad de la prevencin general tiene una doble vertiente: La prevencin general positiva: es aqulla que va encaminada a restablecer la confianza del resto de la sociedad en el sistema. La prevencin general negativa: es aqulla que va encaminada a disuadir a los miembros de la sociedad que no han delinquido, pero que se pueden ver tentados a hacerlo, a travs de la amenaza de la pena. 1.7.2 AUDITABLE Y TRAZABLE Auditable: es tanto la solucin tecnolgica, como sus componentes de hardware y/o software debe ser abierta e ntegramente auditable antes y posteriormente a su uso. Consideramos que tambin debe ser auditable durante su uso y no restringirlo nicamente a las etapas del antes o el despus. AUDITABILIDAD DE BASES DE DATOS El acceso global a la Informacin que trajo el advenimiento de la Tecnologa de Internet, ha hecho que el problema de Seguridad de la Informacin se acrecentara de manera alarmante. En funcin de esta realidad, se deben extremar los requerimientos de Seguridad en todos los elementos que configuren el Sistema de Informacin. El Sistema de Base de Datos que decidamos utilizar en una aplicacin determinada, deber ser valorada,fundamentalmenta por la Seguridad que brinde.Existen,actualmente,Criterios de Evaluacin de Seguridad, con validez internacional, que permiten clasificar cada Sistema de Base de Datos en distintas categoras de acuerdo a la valoracin, 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 informacin genera ,con qu facilidad se pueden definir opciones ,etc. Un aspecto que merecer tambin nuestra atencin ser el control de acceso que posea, la posibilidad de definicin de perfiles y grupos de perfiles. Si el procesamiento es distribuido ser objeto de nuestra atencin el procesamiento y replicacin segura, cmo as tambin todo mecanismo que garantice la integridad de los Datos en forma automtica. La propiedad del resultado de una medida o del valor de un estndar donde este pueda estar relacionado con referencias especificadas, usualmente estndares nacionales o internacionales, a travs de una cadena continua de comparaciones todas con incertidumbres especificadas. En la actualidad existe una propuesta de formato estndar 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... Adems de con una larga lista de sistemas estndar de los ms importantes fabricantes de software. Esta consiste en la capacidad para reconstruir la historia, recorrido o aplicacin de un determinado producto, identificando:

Origen de sus componentes. Historia de los procesos aplicados al producto. Distribucin y localizacin despus de su entrega. a la a el
Al contar con esta informacin es posible entregar productos definidos mercados especficos, con la garanta de conocer con certeza el origen y historia del mismo. El concepto de trazabilidad est asociado, sin duda, procesos productivos modernos y productos de mayor calidad y valor para 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 automocin, aeronutica, distribucin logstica, electrnica 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 histrico, la ubicacin y la trayectoria de un producto, o lote de productos a lo largo de la


cadena de suministros, en un momento dado y a travs de unas herramientas determinadas", un sistema de trazabilidad deber de estar compuesto por: 1. Sistemas de identificacin 1. Un sistema de identificacin del producto unitario 2. Un sistema de identificacin del embalajes o cajas 3. Un sistema de identificacin 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 almacn 3. Software para la gestin 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 gestin empresariales Cuando un sistema de trazabilidad est soportado sobre una infraestructura, basa en las tecnologas de la informacin y las comunicaciones (TIC), la trazabilidad puede brindar importantes utilidades a los diferentes actores de una cadena de valor como ser: gestin eficiente de la logstica 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 solicuitud de servicio. El desarrollo de las soluciones para el control de la trazabilidad ha venido desarrollndose 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 informacin en tiempo real con el fin de fidelizar a los clientes 3. Al desarrollo tecnolgico en plataformas informticas y tecnologa para la identificacin de productos y obtener la informacin 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 patrn 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 fabricacin de un producto deba cumplir normativas diferentes dependiendo del pas al que vaya destinado. 1.7.3 MONITOREO El Monitoreo es el proceso continuo y sistemtico mediante el cual verificamos la eficiencia y la eficacia de un proyecto mediante la identificacin de sus logros y debilidades y en consecuencia, recomendamos medidas correctivas para optimizar los resultados esperados del proyecto. Es, por tanto, condicin para la rectificacin o profundizacin de la ejecucin y para asegurar la retroalimentacin entre los objetivos y presupuestos tericos y las lecciones aprendidas a partir de la prctica. Asimismo, es el responsable de preparar y aportar la informacin que hace posible sistematizar resultados y procesos y, por tanto, es un insumo bsico para la Evaluacin.
Monitoreo de Sistemas de Seguridad

Este sistema permite el monitoreo desde cualquier lugar usando una simple computadora con acceso a internet. Instalacin, 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.
Cmo monitoreo servidores de bases de datos detrs de un firewall

Use su lenguaje de programacin 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 pgina, le notificar y sabr que el servidor de base de datos est cado.
Monitoreo de Dominios
El monitoreo de URLs le ayuda a monitorear la disponibilidad de su sitio Web (o sitios Web, si tiene ms de uno) y a verificar si estn sirviendo pginas 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 ms 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 travs del uso de palabras y frases claves que t especifiques, Spector Pro estar "en alerta", envindote por e-mail inmediata y detalladamente el reporte de cundo, dnde y cmo una palabra especfica fue usada cada vez que se escriba, que aparezca en la PC, en un sitio Web, en el Chat/mensaje instantneo 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 informacin valiosa como tarjetas de crdito o claves, etc. Un antivirus que en lo posible tambin detecte spyware servir mucho para evitar que nos manden troyanos o spyware que envie informacin 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 travs de distintas pginas. Usar un explorador alternativo a Internet Explorer o bien mantenerlo actualizado completamente. Mantener actualizado nuestro sistema operativo es importante para evitar que a travs de un fallo del mismo alguien se pueda apoderar de nuestra computadora y posteriormente de algo valioso. No entrar en pginas web sospechosas de robar contraseas o de mandar virus/spyware al PC. Cuando enven un correo electrnico 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 diseo, a la implementacin, a la programacin, o el uso de errores. As como los sistemas llegan a ser cada vez ms complejos, aumenta la probabilidad de errores. Como mencionamos, es increblemente difcil demonstrar que un sistema sea seguro. Ross Anderson dice que la seguridad de computacin es como programar la computadora del Satn. Software seguro debe de funcionar abajo de un ataque. Aunque casi todos los software tengan errores, la mayora de los errores nunca sern 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 ledo o entendido por algunas personas o entidades.Se dice que un documento o mensaje es confidencial si ste slo est autorizado a ser ledo o entendido por un destinatario designado. CONFIDENCIALIDAD. Compromiso de no dar informacin sobre un hecho mas que a la persona involucrada y a quienes ella autorice. Los resultados de anlisis clnicos y en especial el de VIH deben ser confidenciales. En la prctica muchos doctores, incluyendo los de instancias pblicas, 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 aceptacin en un nuevo trabajo de la persona seropositiva. La confidencialidad se refiere a que la informacin solo puede ser conocida por individuos autorizados. Existen infinidad de posibles ataques contra la privacidad, especialmente en la comunicacin de los datos. La transmisin a travs de un medio presenta mltiples oportunidades para ser interceptada y copiada: las lneas "pinchadas" la intercepcin o recepcin electromagntica no autorizada o la simple intrusin directa en los equipos donde la informacin est fsicamente almacenada.
1.7.5 SEGURIDAD MULTINIVELES La seguridad multinivel dispara el mercado antivirus y las aplicaciones de software antivirus estn experimentando un notable crecimiento como consecuencia del gran incremento y la compleja naturaleza de la actividad de intrusin de los virus, causantes de la infeccin masiva de sistemas y un importante impacto econmico. Con las mejoras que brindan los nuevos sistemas de proteccin multinivel en su esfuerzo por combatir todos los perjuicios comunes ms extendidos, las grandes compaas en particular, estn aumentando su inversin destinada a la erradicacin de los fallos de seguridad. El cambio gradual en la proteccin 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 informacin es manejada de acuerdo a su nivel de sensibilidad y a los permisos que tiene la persona que desea acceder a ella, es tambin 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 informacin mediante cifrado Compatibilidad con DNI electrnico y Smartcards como tarjeta de autenticacin 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 gestin centralizada y polticas definibles en base a perfil de usuario, PC y dispositivos concretos

La seguridad de software aplica los principios de la seguridad de informacin al desarrollo de software. La seguridad de informacin se refiere a la seguridad de informacin comnmente como la proteccin de sistemas de informacin contra el acceso desautorizado o la modificacin de informacin, si esta en una fase de almacenamiento, procesamiento o trnsito. Tambin la protege contra la negacin de servicios a usuarios desautorizados y la provisin de servicio a usuarios desautorizados, incluyendo las medidas necesarias para detectar, documentar, y contrarear tales amenazas. 1.7.6 ANONIMATO Annimo proviene del griego annymos "sin nombre", compuesto del prefijo negativo an- "sin" y noma "nombre". El anonimato es el estado de una persona siendo annima, es decir, que la identidad de dicha persona es desconocida. El anonimato es la condicin 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 annimo puede entenderse como un nombre equivocado. Esto es debido a su diseo, un nodo de la red debe tener pseudnimo desde que tiene que tener una "direccin" para poder ser alcanzado por otro nodo igual para intercambiar datos. Sin embargo, normalmente esta direccin, especialmente en redes annimas, no contiene ninguna informacin que pueda permitir la identificacin. Por tanto, un usuario es casi pero no completamente annimo. En las redes amigo-a-amigo, slo tus amigos pueden saber que tu direccin est siendo usada para intercambiar ficheros. La navegacin Web, algo que suele verse como una actividad annima, 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 AUTENTICACIN Autenticacin o autentificacin es el acto de establecimiento o confirmacin de algo (o alguien) como autntico, es decir que reclama hecho por, o sobre la cosa son verdadero. La autenticacin de un objeto puede significar (pensar) la

confirmacin de su procedencia, mientras que la autenticacin de una persona a menudo consiste en verificar su identidad. La autenticacin depende de uno o varios factores. Autenticacin o autentificacin, en trminos de seguridad de redes de datos, se puede considerar uno de los tres pasos fundamentales (AAA). Cada uno de ellos es, de forma ordenada: Autenticacin En la seguridad de ordenador, la autenticacin es el proceso de intento de verificar la identidad digital del remitente de una comunicacin como una peticin 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, "autenticacin" es un modo de asegurar que los usuarios son quin ellos dicen que ellos son - que el usuario que intenta realizar funciones en un sistema es de hecho el usuario que tiene la autorizacin para hacer as. Autorizacin Proceso por el cual la red de datos autoriza al usuario identificado a acceder a determinados recursos de la misma. Auditora 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 autorizacin a menudo, es idntico a la de autenticacin; muchos protocolos de seguridad extensamente adoptados estndar, regulaciones obligatorias, y hasta estatutos estn basados en esta asuncin. Sin embargo, el uso ms exacto describe la autenticacin como el proceso de verificar la identidad de una persona, mientras la autorizacin es el proceso de verificacin que una persona conocida tiene la autoridad para realizar una cierta operacin. La autenticacin, por lo tanto, debe preceder la autorizacin. Para distinguir la autenticacin de la autorizacin de trmino estrechamente relacionada, existen unas notaciones de taquigrafa que son: A1 para la autenticacin y A2 para la autorizacin que de vez en cuando son usadas, tambin existen los trminos AuthN y AuthZ que son usados en algunas comunidades. 1.7.8 INTEGRIDAD El trmino integridad de datos se refiere a la correccin 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 aadirse datos no vlidos 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 energa. Los cambios pueden ser aplicados parcialmente,

como por ejemplo si se aade 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 declaracin 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 automticamente 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 insercin de una fila hijo se produce cuando no coincide la clave ajena con la clave primaria del padre. La actualizacin en la clave ajena de la fila hijo, donde se produce una actualizacin en la clave ajena de la fila hijo con una sentencia UPDATE y la misma no coincide con ninguna clave primaria. La supresin de una fila padre, con la que, si una fila padre -que tiene uno o ms hijos- se suprime, las filas hijos quedarn hurfanas. La actualizacin de la clave primaria de una fila padre, donde si en una fila padre, que tiene uno o ms hijos se actualiza su clave primaria, las filas hijos quedarn hurfanas. 1.8 CONOCER EL ENEMIGO Medias de seguridad a tener en cuenta por las empresas:
Establecer una poltica adecuada en la que deben figurar cules son los puntos crticos de la red corporativa y las medidas que se van a tomar para protegerlos.

Instalar una solucin de seguridad eficiente tanto en los equipos de los trabajadores como en los servidores. Las contraseas de acceso a los equipos deber ser seguras. Contar con programas y soluciones de seguridad actualizada y proteccin en sus equipos porttiles y en sus redes inalmbricas. Conocer quin accede a la informacin. Realizar auditoras para saber qu ha pasado y cundo 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 ningn vnculo que llegue por correo o mensajera instantnea. No ejecutar archivos que procedan de fuentes desconocidas. No descargarse por P2P archivos sospechosos. No conectar dispositivos mviles como llaves USB o PDA sin haberse asegurado antes de que no estn infectados. Bloquear el equipo cuando no se est en el puesto de trabajo. Evitar tener contraseas a la vista. 1.9 META DE PROYECTO DE SOFTWARE
Las metas y los objetivos proporcionan la direccin uniforme en un proyecto y aseguran una visin constante a travs del cuerpo de tenedores de apuestas. Idealmente, las metas y los objetivos sirven como referencia constante para la toma de decisin relacionada con el proyecto. Uso Las metas y los objetivos son pblico los elementos de informacin disponibles que se comparten normalmente o a travs de la documentacin de la reunin o mientras que la informacin introductoria en los planes del proyecto y el otro proyecto apoya la documentacin. Las metas y los objetivos se utilizan para unificar la visin del equipo y la organizacin con respecto a cul debe el proyecto lograr y el acercamiento general a lograr esa meta. Pueden ser fijadas en una localizacin altamente visible para asegurarse de que estn fcilmente disponibles para todos los miembros del equipo. El terico Peter Drucker de la gerencia sugiere que las metas de un negocio conduzcan sus objetivos especficos del trabajo, y que esos objetivos necesitan ser delineados claramente para asegurar niveles ms altos del funcionamiento. Contenido Las metas y los objetivos deben indicar claramente el intento de la organizacin, el proyecto, y las tareas o el esfuerzo bajo consideraciny los

objetivos de trabajadores individuales en la organizacin deben ser complementarios en servir la meta. Las declaraciones de la meta se fijan en un alto nivel, describiendo lo que espera la organizacin alcanzar. Se atan de cerca a las declaraciones de la visin en que las metas son descripciones de lo que espera la organizacin lograr. Las metas se pueden construir en el nivel de organizacin (hacer un innovador reconocido del software cambiando cmo se disea y se apoya el software) o en un ms detallado, proyecto llano (proveer de la cumbre el software innovador de la logstica 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, direccin inequvoca en cmo las metas sern 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 mtrica de medida que refleje los valores de la organizacin s. Si la meta es proporcionar software innovador de la logstica a la cumbre de la ayuda, los objetivos pudieron incluir el siguiente: Para proporcionar un sistema que proporciona la informacin en tiempo real con respecto la localizacin, el almacenaje, y al envejecimiento materiales; Para proporcionar un sistema que responde con la direccin (detallada, paso a paso) modificada para requisitos particulares en las fuentes alternativas para el material que est fuera de accin o en fuente baja. Los trminos llegan a ser importantes en establecer metas y objetivos. La asuncin que cualquier cosa que puede ser malinterpretada ser malinterpretada es una asuncin justa y razonable. Una visin de la persona s de la fuente baja pudo ser diferente que otros. El esfuerzo en objetivos del edificio es reducir al mnimo la ambigedad tanto como es posible y razonable. Acercamientos Una lnea blurry existe entre las metas y los objetivos y entre los objetivos y los requisitos. Como tal, una declaracin general de la meta de la persona s se pudo detallar suficientemente para ser un objetivo para algn otro (particularmente alguien en un nivel ms alto en la organizacin). 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 organizacin. Los objetivos deben indicar cmo el equipo y el proyecto trabajarn en esa direccin. En algunas organizaciones, la declaracin objetiva se liga siempre a las limitaciones del momento especfico y del coste.


Consideraciones Porque las metas y los objetivos proporcionan la direccin, deben ser declaraciones pblicas. 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 documentacin. Tal franqueza sobre las metas y los objetivos puede imposibilitar algo de las rias inherentes a veces evidentes cuando los miembros del equipo de proyecto se parecen trabajar en los propsitos cruzados. Tal visibilidad se debe tambin acompaar por el estmulo de los miembros del equipo para identificar cualquier esfuerzo que no se parezca servir claramente las metas del proyecto. Si un cierto trabajo sirve las metas del proyecto indirectamente, es importante clarificar cmo ese trabajo responder en ltima instancia a los propsitos del proyecto, as que los miembros del equipo que trabajan en esas funciones entendern su papel en el proyecto en su totalidad.


Unidad II Administracin de los riesgos en la seguridad del software

Objetivo: El alumno conocer e identificar los riesgos que se tienen al poner en prctica la seguridad del software, as como los mecanismos para la evaluacin del desarrollo de sistemas seguros. Contenido: 2.1 Descripcin de la administracin de los riesgos en la Seguridad del Software 2.2 Administracin de los riesgos en la seguridad del Software en la prctica 2.2.1 Pruebas de Caja Negra 2.2.2 Equipo Rojo 2.3 Criterios Comunes


2.1 DESCRIPCIN DE LA ADMINISTRACIN DE LOS RIESGOS EN LA SEGURIDAD DEL SOFTWARE
La administracin de riesgo es un proceso de identificacin y anlisis de riesgos y de creacin de un plan para administrarlos. Un riesgo de seguridad se define como la prdida esperada debido o como consecuencia de amenazas anticipadas por vulnerabilidades del sistema y la fuerza y determinacin de los agentes amenazantes correspondientes. Identificacin de los riesgos de seguridad La identificacin de los riesgos de seguridad es el primer paso en la evaluacin de la seguridad de la organizacin. 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 accin para solucionar el riesgo. Aunque el mbito del riesgo de seguridad est limitado a la tecnologa que el equipo del proyecto trata de proteger, la atencin del equipo debe ser lo suficientemente amplia como para abordar todas las fuentes de riesgos de seguridad, incluido la tecnologa, proceso, entorno y personas. Actividades de identificacin de riesgos Durante el paso de identificacin de riesgos de seguridad, el equipo deber indicar o enumerar de forma precisa los problemas de seguridad mediante la declaracin concisa de los riesgos a los que se enfrenta la organizacin. 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 situacin. Debido al cambio constante de la tecnologa y los entornos, es importante que la identificacin de riesgos de seguridad no se considere una actividad aislada, sino que el proceso debe repetirse peridicamente durante el ciclo de vida de las operaciones de la organizacin. Enfoque estructurado El uso de un enfoque estructurado con relacin a la administracin de riesgos de seguridad es fundamental porque permite que todos los miembros del equipo utilicen un mecanismo slido para tratar los problemas de seguridad. La clasificacin de las amenazas durante este paso es una forma til de proporcionar un enfoque slido, 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 evaluacin y se

utilizan para generar una nueva estrategia de seguridad que incluya administracin de configuracin y revisiones, supervisin y auditora del sistema, y directivas y procedimientos operativos. Dado que se desarrollan diversas contramedidas, es importante realizar un seguimiento e informe minuciosos de este proceso. Declaracin de riesgos de seguridad Una declaracin de riesgos de seguridad es una expresin del lenguaje normal de la relacin causal entre el estado de seguridad existente de la organizacin y un resultado posible que no se ha realizado. La primera parte de la declaracin de riesgos de seguridad se denomina "la condicin", en la que se proporciona la descripcin de un estado existente o amenaza potencial que el equipo considera que puede causar algn dao. La segunda parte de la declaracin de riesgos se denomina "consecuencia", y en ella se describe la prdida no deseada de confidencialidad, integridad y disponibilidad de un activo. Las dos declaraciones estn unidas por un trmino como "entonces" o "puede resultar en" que implica una relacin 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 tecnologa de infraestructura. Este modelo sigue un ciclo iterativo diseado para abordar cambios de los requisitos de proceso en ciclos de desarrollo cortos y versiones incrementales de la solucin. Esto es posible gracias a la administracin de riesgo continua y los ciclos de pruebas.
Marco de administracin de riesgos de seguridad Descripcin general El marco utiliza el modelo de proceso MSF y describe una secuencia de alto nivel de actividades para la creacin e implementacin 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 solucin desde el inicio del proyecto hasta la implementacin activa.
Figura 1
2.2 ADMINISTRACIN DE LOS RIESGOS EN LA SEGURIDAD DEL SOFTWARE EN LA PRCTICA Prcticas de administracin 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 administracin 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 evalan slo durante el ciclo de vida del proyecto, mientras que los riesgos de seguridad se deben evaluar durante el ciclo de vida completo de la solucin o el sistema. La disciplina de administracin de riesgo MSF sirve como base para la administracin de riesgos de las evaluaciones de los proyectos y de la seguridad. La seguridad del sistema informtico se debe realizar de forma preventiva y continua para garantizar la seguridad de los activos de informacin y supervisar nuevas amenazas y vulnerabilidades. Siempre que se agreguen funcionalidades nuevas a la infraestructura de tecnologa de la organizacin deber tomarse en cuenta la seguridad de la informacin. Adems, es posible que algunos procesos y procedimientos empresariales deban alterarse para operar en el entorno modificado y proporcionar proteccin a los activos de informacin nuevos. Los nueve pasos de la Disciplina de administracin de riesgos de seguridad en la prctica son: Evaluacin 1. 2. 3. 4. Evaluacin y valoracin del activo Identificacin de los riesgos de seguridad Anlisis y ordenacin segn prioridad de los riesgos de seguridad Seguimiento, planeamiento y programacin de los riesgos de seguridad desarrollo e implementacin
5. Desarrollo de las soluciones de seguridad 6. Pruebas de las soluciones de seguridad 7. Obtencin de informacin sobre seguridad Operacin 8. Reevaluacin de los riesgos de seguridad y los activos nuevos y cambiados 9. Estabilizacin e implementacin de contramedidas nuevas o cambiadas Anlisis de los riesgos de seguridad El anlisis de los riesgos de seguridad se utiliza para examinar los posibles ataques, herramientas, mtodos y tcnicas que permiten explotar una posible vulnerabilidad. Se trata de un mtodo de identificacin de riesgos y evaluacin de posibles daos que podran producirse para justificar las salvaguardas de seguridad.

Un anlisis de este tipo presenta tres objetivos principales: identificar riesgos, cuantificar la repercusin de posibles amenazas y proporcionar un balance econmico entre el efecto del riesgo y el coste de la contramedida. Se recopila informacin para calcular el nivel de riesgo de modo que el equipo pueda tomar decisiones razonables y centrar todos los esfuerzos en la solucin de los riesgos de seguridad. Este anlisis se utiliza posteriormente para dar prioridad a los riesgos de seguridad y permitir a la organizacin asignar recursos con los que se solucionarn los problemas de seguridad ms importantes. Un anlisis de riesgo permite integrar los objetivos del programa de seguridad en los objetivos y requisitos comerciales de la compaa. Cuanto ms coordinados resulten los objetivos comerciales y los de seguridad, ms fcil ser cumplirlos. Etapa: Pruebas La prueba del software es un elemento crtico para la garanta de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Adems, esta etapa implica:

Verificar la interaccin de componentes. Verificar la integracin 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. Disear pruebas que sistemticamente saquen a la luz diferentes clases de errores, hacindolo 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 (correccin, robustez, fiabilidad, amigabilidad, ...) dejar claro cmo se mide el resultado especificar en qu consiste la prueba (hasta el ltimo detalle de cmo se ejecuta) definir cual es el resultado que se espera (identificacin, tolerancia, ...) Cmo se decide que el resultado es acorde con lo esperado?


La prueba es un proceso que se enfoca sobre la lgica interna del software y las funciones externas. La prueba es un proceso de ejecucin de un programa con la intencin 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; slo 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 informacin 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 categoras:

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 inicializacin y de terminacin.
Los casos de prueba deben satisfacer los siguientes criterios:

Reducir, en un coeficiente que es mayor que uno, el nmero de casos de prueba adicionales. Que digan algo sobre la presencia o ausencia de clases de errores.
Mtodos de prueba de caja negra Algunos de los mtodos empleados en las pruebas de caja negra son los siguientes:
Mtodos de prueba basados en grafos: en este mtodo se debe entender los objetos (objetos de datos, objetos de programa tales como

mdulos o colecciones de sentencias del lenguaje de programacin) 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 mtodo: 1. Se crea un grafo de objetos importantes y sus relaciones. 2. Se disea una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores. Describe un nmero de modelados para pruebas de comportamiento que pueden hacer uso de los grafos:
Modelado del flujo de transaccin. Los nodos representan los pasos
de alguna transaccin (por ejemplo, los pasos necesarios para una reserva en una lnea area usando un servicio en lnea), y los enlaces representan las conexiones lgicas entre los pasos (por ejemplo, vuelo, informacin, entrada es seguida de validacin /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 peticin por telfono), y los enlaces representan las transiciones que ocurren para moverse de estado a estado (por ejemplo, peticin-informacin se verifica durante inventario-disponibilidad-bsqueda y es seguido por cliente-factura-informacin-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 planificacin. 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 ejecucin requeridos al ejecutarse el programa. Grfica Causa-efecto. La grfica Causa-efecto. representa una ayuda grfica en seleccionar, de una manera sistemtica, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigedades en la especificacin. Un grfico de causa-efecto es un lenguaje formal al cual se traduce una especificacin. El grfico es realmente un circuito de lgica digital (una red combinatoria de lgica), pero en vez de la notacin estndar de la electrnica, se utiliza una notacin algo ms simple. No hay necesitad de tener conocimiento de electrnica con excepcin de una comprensin de la lgica boleana (entendiendo los operadores de la lgica y, o, y no).
Particin equivalente: Presenta la particin equivalente como un mtodo 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, requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar. Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para condiciones de entrada. Tpicamente, una condicin de entrada es un valor numrico especfico, un rango de valores, un conjunto de valores relacionados o una condicin lgica. El objetivo de particin equivalente es reducir el posible conjunto de casos de prueba en uno ms pequeo, un conjunto manejable que evale 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 particin equivalente es subjetiva. Dos probadores quienes prueban un programa complejo pueden llegar a diferentes conjuntos de particiones. En el diseo de casos de prueba para particin equivalente se procede en dos pasos: 1. Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condicin de entrada (generalmente una oracin o una frase en la especificacin) y repartindola en dos o ms grupos. Es de notar que dos tipos de clases de equivalencia estn identificados: las clases de equivalencia vlidas representan entradas vlidas al programa, y las clases de equivalencia invlidas que representan el resto de los estados posibles de la condicin (es decir, valores errneos de la entrada). 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 nmero nico a cada clase de equivalencia. Hasta que todas las clases de equivalencia vlidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia vlida. Y por ltimo hasta que los casos de prueba hallan cubierto todas las clases de equivalencia invlidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia invlidas descubiertas.
2.
Prueba de la tabla ortogonal: hay aplicaciones donde el nmero de parmetros de entrada es pequeo y los valores de cada uno de los parmetros est claramente delimitado. Cuando estos nmeros son muy pequeos (por ejemplo, 3 parmetros de entrada tomando 3 valores diferentes), es posible considerar cada permutacin de entrada y comprobar exhaustivamente el proceso del dominio de entrada. En

cualquier caso, cuando el nmero de valores de entrada crece y el nmero 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 pequeo pero demasiado grande para posibilitar pruebas exhaustivas. El mtodo de prueba de la tabla ortogonal es particularmente til al encontrar errores asociados con fallos localizados -una categora de error asociada con defectos de la lgica dentro de un componente software.
2.2.2 EQUIPO ROJO A finales de 1996, Dan Farmer (creador de una de las herramientas ms tiles en la deteccin 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 especficos, adems de un conjunto de sistemas informticos aleatorios con los que realizar comparaciones. El estudio se realiz empleando tcnicas 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 ms serios y suponen que el sistema est abierto a un atacante potencial, es decir, posee problemas de seguridad conocidos en disposicin de ser explotados. As por ejemplo, un problema de seguridad del grupo rojo es un equipo que tiene el servicio de FTP annimo mal configurado. Los problemas de seguridad del grupo amarillo son menos serios pero tambin reseables. Implican que el problema detectado no compromete inmediatamente al sistema pero puede causarle serios daos o bien, que es necesario realizar tests ms intrusivos para determinar si existe o no un problema del grupo rojo. La Agencia de Seguridad Nacional americana, una de los organismos ms poderosos del planeta, ayud a mejorar la seguridad de Windows Vista. (DT, AGENCIAS) El Washington Post publico que la agencia ha admitido su 'colaboracin no especfica' en Vista. Tony Sager, el jefe de anlisis de vulnerabilidades y del grupo de operaciones de la NSA, le dijo al rotativo que la intencin 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 tena el rol de tratar de corromper o robar informacin como si de un "adversario tcnicamente competente y muy decidido" se tratase. El equipo azul ayud a los administradores del departamento de defensa con la configuracin de Windows Vista. En Microsoft dicen que la ayuda prestada por la NSA lleva producindose desde hace cuatro aos. Algunas de esas mejoras se pueden apreciar en la versin para el usuario de Windows XP y en la de usuarios corporativos para Windows Server 2003.

2.3 CRITERIOS COMUNES Los Criterios Comunes(CC) tienen su origen en 1990 y surgen como resultado de la armonizacin de los criterios sobre seguridad de productos software ya utilizados por diferentes pases con el fin de que el resultado del proceso de evaluacin pudiese ser aceptado en mltiples pases. Los CC permiten comparar los resultados entre evaluaciones de productos independientes. Para ello, se proporcionan un conjunto comn de requisitos funcionales para los productos de TI (Tecnologas de la Informacin). Estos productos pueden ser hardware, software o firmware. El proceso de evaluacin 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 evaluacin aplicadas. Los CC son tiles como gua para el desarrollo, evaluacin o adquisicin de productos TI que incluyan alguna funcin de seguridad. La lista de productos certificados segn los CC se encuentra disponible en la web de Common Criteria. Este estndar, los Criterios Comunes (CC), tiene como finalidad el ser usado como base para la evaluacin de las propiedades de seguridad de los productos y sistemas de Tecnologas de la Informacin (TI). Estableciendo esta base de criterios comunes, los resultados de una evaluacin de seguridad de TI ser significativa para una mayor audiencia. Los CC permitirn la comparacin entre los resultados de evaluaciones de seguridad independientes, al proporcionar un conjunto comn de requisitos para las funciones de seguridad de los productos y sistemas de TI y para las medidas de garanta aplicadas a stos durante la evaluacin de seguridad. El proceso de evaluacin establece un nivel de confianza del grado en que las funciones de seguridad de tales productos y sistemas y las medidas de garanta aplicadas coinciden con aquellos requisitos. Los CC son tiles como gua para el desarrollo de productos o sistemas con funciones de seguridad de TI y para la adquisicin de productos y sistemas comerciales con dichas funciones. Los CC tratan la proteccin de la informacin contra la revelacin no autorizada, modificacin o prdida de uso. Las categoras de proteccin relacionadas con estos tres tipos de fallos de seguridad son llamadas normalmente confidencialidad, integridad y disponibilidad respectivamente. Los CC pueden ser tambin 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 tambin pueden ser aplicables a otras amenazas no humanas. Adems, los CC pueden ser aplicados en otras reas distintas de TI pero no se hace ninguna declaracin 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 evaluacin a aplicar slo en determinados mtodos de implementacin, se indicar expresamente en las declaraciones de los criterios correspondientes. Algunos temas, porque involucran tcnicas 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 evaluacin 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 travs de medidas administrativas (organizativas, de personal, fsicas y control de procedimientos). Las medidas de seguridad administrativas, en el entorno operativo del TOE, son tratadas como hiptesis 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 evaluacin de aspectos tcnicos fsicos de la seguridad de TI como control de radiaciones electromagnticas no se trata especficamente, aunque varios de los conceptos tratados sern aplicables en esta rea. En particular, los CC tratan algunos aspectos de la proteccin fsica del TOE.
Los CC no tratan ni la metodologa de evaluacin ni el marco administrativo y legal bajo el cual los criterios pueden ser aplicados por las autoridades de evaluacin. Sin embargo, se espera que los CC sean usados para propsitos de evaluacin en el contexto de un determinado marco administrativo y con una determinada metodologa.
Los procedimientos para el uso de los resultados de la evaluacin en la acreditacin de productos o sistemas estn fuera del objetivo de los CC. La acreditacin 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 evaluacin 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 evaluacin son, por lo tanto, un dato de valor

para el proceso de acreditacin. Sin embargo, como hay otras tcnicas ms apropiadas para la valoracin, tanto de las propiedades de seguridad de un producto o sistema no relacionados con TI, como de su relacin con las partes de seguridad de TI, los acreditadores debern establecer separadamente estos aspectos.
Los criterios para la valoracin de las cualidades inherentes de los
algoritmos criptogrficos no se tratan en los CC. Si se necesita una valoracin independiente de las propiedades matemticas de la criptografa introducida en un TOE, deber ser proporcionada por el esquema bajo el cual se estn aplicando los CC. Funcionamiento Con el fin de poder certificar un producto segn los Criterios Comunes se deben comprobar, por parte de uno de los laboratorios independientes aprobados, numerosos parmetros de seguridad que han sido consensuados y aceptados por 22 pases de todo el mundo. El proceso de evaluacin incluye la certificacin de que un producto software especfico verifica los siguientes aspectos:

Los requisitos del producto estn definidos correctamente. Los requisitos estn implementados correctamente. El proceso de desarrollo y documentacin 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 Tecnologas de la Informacin y de los criterios para evaluar su seguridad. El proceso de evaluacin, realizado segn lo prescrito en los Criterios Comunes, garantiza que las funciones de seguridad de tales productos y sistemas renen los requisitos declarados. As, los clientes pueden especificar la funcionalidad de seguridad de un producto en trminos de perfiles de proteccin estndares y de forma independiente seleccionar el nivel de confianza en la evaluacin de un conjunto definido desde el EAL1 al EAL7.
Perfiles de proteccin Un perfil de proteccin (Protection Profile) define un conjunto de objetivos y requisitos de seguridad, independiente de la implantacin, para un dominio o categora de productos que cubre las necesidades de seguridad comunes a varios usuarios. Los perfiles de proteccin son reutilizables y normalmente pblicos y estn compuestos de:

Requisitos funcionales (SFR, Security Funcional Requirement) proporcionan mecanismos para hacer cumplir la poltica de seguridad. Como ejemplos de requisitos funcionales mencionar la proteccin de datos de usuario, el soporte criptogrfico, la autenticacin, 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 evaluacin (EAL, Evaluation Assurance Levels) que contienen requisitos de confianza construidos especficamente en cada nivel. Los EALs proporcionan una escala incremental que equilibra el nivel de confianza obtenido con el coste y la viabilidad de adquisicin 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 aadiendo componentes de confianza de otras familias de confianza (por ejemplo, aadiendo nuevos requisitos funcionales). Niveles de confianza Los niveles de confianza en la evaluacin 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 operacin correcta, y donde adems, las amenazas a la seguridad no son vistas como serias. Una evaluacin en este nivel debe proporcionar evidencia de que las funciones del objeto de evaluacin son consistentes con su documentacin, y que proporcionan proteccin til contra amenazas identificadas.
EAL2
(estructuralmente probado):requiere la cooperacin del desarrollador en trminos de la distribucin de la informacin del diseo, y los resultados de las pruebas y proporciona confianza a travs de un anlisis de las funciones de seguridad, usando una especificacin funcional y de interfaz, manuales y diseo de alto nivel del producto para entender el comportamiento de seguridad. Adems, en este nivel se verifica que el desarrollador realiz un anlisis de vulnerabilidades a travs de la ejecucin de pruebas de caja negra (black-box).
EAL3
(probado y verificado metdicamente): permite a un desarrollador alcanzar una mxima garanta de ingeniera de seguridad positiva en el estado de diseo sin la alteracin substancial de prcticas de desarrollo vlidas existentes. El anlisis en este nivel se apoya en las

pruebas de caja gris (grey box), la confirmacin selectiva independiente de los resultados de las pruebas del desarrollador, y la evidencia de bsqueda de vulnerabilidades obvias del desarrollador. Adems, se realizan controles del entorno de desarrollo y de gestin de configuracin del producto.
EAL4 (diseado, probado y revisado metdicamente): este nivel le
permite a un desarrollador alcanzar mxima garanta de ingeniera de seguridad positiva basada en buenas prcticas de desarrollo comercial, las cuales, aunque rigurosas, no requieren del conocimiento especializado substancial, destreza, ni otros recursos. En este caso, el anlisis se apoya en el diseo de bajo nivel de los mdulos del producto y se realiza bsqueda de vulnerabilidades independiente de las pruebas realizadas por el desarrollador. EAL5 (diseado y probado semiformalmente): permite a un desarrollador alcanzar mxima garanta de ingeniera de seguridad positiva mediante la aplicacin moderada de tcnicas de ingeniera de seguridad. La confianza se apoya, en este caso, en un modelo formal y una presentacin semiformal de la especificacin funcional y el diseo de alto nivel. La bsqueda de vulnerabilidades debe asegurar la resistencia relativa a los ataques de penetracin.
EAL6 (diseo verificado y probado semiformalmente): permite a los
desarrolladores alcanzar una alta garanta en la aplicacin de tcnicas de ingeniera de seguridad para un entorno de desarrollo riguroso y donde el objeto de evaluacin es considerado de gran valor para la proteccin del alto costo o estimacin de esos bienes contra riesgos significativos. Adems, es aplicable para el desarrollo de objetos de evaluacin, destinados a salvaguardar la seguridad informtica en situaciones de alto riesgo donde el valor de los bienes protegidos justifica los costos adicionales. El anlisis en este nivel se apoya en un diseo modular y en una presentacin estructurada de la implementacin del producto. La bsqueda de vulnerabilidades debe mostrar una alta resistencia a los ataques de penetracin.
EAL7 (diseo verificado y probado formalmente): es aplicable al
desarrollo de objetos de evaluacin de seguridad, para su aplicacin en situaciones de muy alto riesgo o donde el alto valor de los bienes justifica los ms altos costos. La aplicacin prctica del nivel EAL7 est limitada actualmente a objetos de evaluacin con seguridad estrechamente enfocada a la funcionalidad, y que es sensible al anlisis formal y extenso. Este EAL representa un incremento

Significativo respecto a la garanta de nivel EAL6 a travs del requisito de anlisis de gran amplitud, mediante representaciones formales y correspondencia formal y pruebas de gran amplitud. Adems, 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 semi-formales y formales por tanto, se aplican a productos con objetivos de seguridad muy especficos (entorno militar, por ejemplo). Por otra parte, estos niveles requieren de la generacin de una gran cantidad de documentacin durante el proceso de desarrollo que debe entregarse al evaluador para que ste pueda confirmar la informacin. Finalmente, para la aplicacin de los Criterios Comunes, existe una metodologa 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.


Academia de Informtica y Sistemas Computacionales Unidad III Cdigo abierto o cerrado
Objetivo: El alumno conocer los mecanismos que emplea la industria del software para proteger sus cdigos, tanto de los competidores como de los crackers; as como las ventajas y desventajas del cdigo abierto. Contenido: 3.1 Seguridad por Oscuridad 3.2 Ingeniera en Reversa 3.3 Cdigo Fuente Abierto 3.4 Falacias del cdigo abierto


Academia de Informtica y Sistemas Computacionales 3.1 seguridad por oscuridad. Seguridad: certeza, firmeza, confianza. Sin riesgo. Oscuridad: Puedes estar seguro... de que, al final la vulnerabilidad ser encontrada. Definicin de seguridad por oscuridad: Es un controvertido principio de ingeniera de seguridad, la cual intenta utilizar el secreto para garantizar la seguridad. Un sistema que se apoya en la seguridad por ocultacin puede tener vulnerabilidades de seguridad tericas o prcticas, pero sus propietarios o diseadores creen que estos puntos dbiles no se conocen, y que es probable que los atacantes no los descubran. Concepto: En criptografa y seguridad informtica, la seguridad por oscuridad o por ocultacin es un controvertido principio de ingeniera de la seguridad, que intenta utilizar el secreto (de diseo, de implementacin, etc.) para garantizar la seguridad. Un sistema que se apoya en la seguridad por ocultacin puede tener vulnerabilidades tericas o prcticas, pero sus propietarios o diseadores creen que esos puntos dbiles no se conocen, y que es probable que los atacantes no los descubran Argumentos Si la seguridad de un sistema depende nica o principalmente de mantener oculta una debilidad. Se argumenta que permitir a cualquier persona revisar la seguridad repercutir en una pronta identificacin y correccin de cualquier fallo o debilidad.
Introduccin La seguridad por oscuridad es la creencia de que cualquier sistema puede ser seguro mientras nadie fuera de su grupo de implementacin de seguridad se le permita conocer nada de sus mecanismos internos. Ocultando contraseas en archivos binarios o esconder scripts suponiendo que "nadie lo va a encontrar nunca" es un buen ejemplo de Seguridad por oscuridad. La seguridad por oscuridad es la principal filosofa de las agencias burocrticas, y es el mtodo ms utilizado para proveer "pseudoseguridad" en sistemas de cmputo.
Esta filosofa ha ido decreciendo en el mundo de la computacin con el aumento de los sistemas abiertos, Internet, la mayor comprensin de tcnicas de programacin, y tambin el crecimiento de conocimiento computacional en una persona promedio. Las bases de la seguridad por oscuridad es que si una persona no sabe como hacer algo para tener un impacto en la seguridad del sistema, entonces esa persona no es peligrosa. Sin duda, esto es en teora, ya que esto te ata a confiar en un pequeo grupo de personas, tanto tiempo, como el que ellos vivan. Si tus empleados tiene una mejor oferta o les pagan mejor en otro lugar, sus conocimientos se van con ellos, ya sea que ese conocimiento sea reemplazable o no. Una vez que los secretos estn fuera, ah esta el fin de nuestra seguridad. Actualmente hay una gran necesidad de los usuarios ordinarios por conocer detalles de como funciona su sistema como nunca antes, y como resultado la Seguridad por oscuridad falla. Hoy en da muchos usuarios tienen conocimientos avanzados de como funcionan sus sistemas operativos, y porque toda su experiencia le permite obtener todo el conocimiento que el "necesite obtener".


Academia de Informtica y Sistemas Computacionales Esto esquiva todas las bases de la seguridad por oscuridad, y hace tu seguridad intil. Por lo tanto actualmente existe la necesidad de crear sistemas que intenten ser algortmicamente seguros (Kerberos, Secure RPC), que es mejor que ser filosficamente seguro. El sistema "Shadow" para contraseas en muchas ocasiones se incluyen en el grupo de la seguridad por oscuridad, pero esto es incorrecto, ya que la seguridad por oscuridad depende de restringir el acceso a algn algoritmo o tcnica, mientras que las contraseas Shadow nos proveen seguridad restringiendo el acceso a datos vitales. Argumentos contra la seguridad por oscuridad Muchos argumentan que la seguridad por oscuridad es dbil. Si la seguridad de un sistema depende nica o principalmente de mantener oculta una debilidad, entonces, claramente, si esa debilidad es descubierta, la seguridad se compromete fcilmente. Se argumenta que mantener ocultos los detalles de sistemas y algoritmos ampliamente utilizados es difcil. En criptografa, por ejemplo, hay un buen nmero de ejemplos de algoritmos de cifrado que han pasado a ser de conocimiento pblico, bien por ingeniera inversa bien por una fuga de informacin. Ms an, el mantener algoritmos y protocolos ocultos significa que la revisin de seguridad est limitada a unos pocos. Se argumenta que permitir a cualquier persona revisar la seguridad repercutir en una pronta identificacin y correccin de cualquier fallo o debilidad. En la prctica Los operadores, desarrolladores y vendedores de sistemas que confan en la seguridad por oscuridad a menudo mantienen en secreto que sus sistemas tienen fallos, para evitar crear desconfianza en sus servicios o productos y por tanto, en su imagen de mercado. Es posible que esto pudiera conducir en algunos casos a una representacin fraudulenta de la seguridad de sus productos, aunque la aplicacin de la ley a este respecto ha sido poco contundente, en parte porque las condiciones de uso impuestas por los vendedores como parte del contrato de licencia redimen (con ms o menos xito) sus aparentes obligaciones bajo el estatuto legal de muchas jurisdicciones que requieren una adecuacin para el uso o estndares de calidad similares. A menudo esos diseadores o vendedores, o incluso ejecutivos, realmente creen que han garantizado la seguridad al mantener el diseo del sistema en secreto. Para quienes abordan la seguridad de esta manera les resulta difcil tener la suficiente perspectiva para darse cuenta de que estn dirigindose a un problema, y a veces un gran problema. El autoengao o la ignorancia son generalmente problemas muy difciles que tienen consecuencias (casi universalmente) desafortunadas. Cuando se usa software seguro por estar oculto de manera amplia, existe un riesgo potencial de problema global; por ejemplo, vulnerabilidades en las diferentes versiones del sistema operativo Windows o sus componentes obligatorios como su navegador web Internet Explorer, o sus aplicaciones de correo electrnico (Microsoft Outlook o Outlook Express) han causado problemas a lo largo y ancho del planeta cuando virus, troyanos, gusanos y dems se han aprovechado de ellas. SEGURIDAD POR DISEO Vs SEGURIDAD POR OSCURIDAD Cuando hablamos de seguridad por oscuridad, aunque el nombre asuste un poco, nos estamos refiriendo a que se utiliza el secreto para garantizar la seguridad de algn programa, como ser un sistema operativo, navegador web, etc, este es el caso del soft de cdigo cerrado o propietario, en donde los desarrolladores quizs conocen que el soft tiene agujeros de Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales seguridad pero, como nadie tiene acceso al cdigo, confan en este secreto siga siendo secreto para evitar que dichas vulnerabilidades sean explotadas. Cuidado, esto no quiere decir que todo el software propietario base su seguridad en este concepto, pero si que los ms grandes ejemplos de agujeros y vulnerabilidades que aprovechan este tipo de seguridad se han dado en este tipo de software. Para que entendamos un poquito mejor, hagamos una analoga. Supongamos que a la llave de nuestra casa la escondemos abajo del felpudo de la puerta de entrada cuando salimos de vacaciones, solo nosotros sabemos que la llave est escondida ah y confiamos que nadie ms sabe la ubicacin de la misma y creemos que es muy improbable que un ladrn la encuentre. Por otro lado, existe lo que se llama seguridad por diseo, esta es aplicada claramente en aplicaciones que son de cdigo abierto, en donde la seguridad de los programas se basa en el diseo de los mismos el cual es conocido por todos, inclusive los atacantes, un ejemplo claro es el caso del software libre, (GNU/Linux, etc) donde desde el mismo kernel (ncleo) hasta los firewalls, antivirus, navegadores ponen a disposicin su diseo y su cdigo haciendo que la seguridad de los mismos no se base en ocultar sus vulnerabilidades, sino en un buen desarrollo. An as, el software libre es escrito por seres humanos, por lo que no es invulnerable, aunque si muy seguro. 3.2 Ingeniera inversa Definicin: Es la actividad que se ocupa de descubrir cmo funciona un programa, funcin o caracterstica de cuyo cdigo fuente no se dispone, hasta el punto de poder modificar ese cdigo. Trata de tomar algo (un dispositivo mecnico o electrnico, un software de computadora, etc.) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo o programa que haga la misma o similar tarea sin copiar la original. Es denominado ingeniera inversa porque avanza en direccin opuesta a las tareas habituales de ingeniera, que consisten en utilizar datos tcnicos para elaborar un producto determinado. Objetivo: Es obtener informacin a partir de un producto accesible al pblico, con el fin de determinar de qu est hecho, qu lo hace funcionar y cmo fue fabricado. Usos de la ingeniera inversa Suele ser empleada por empresas, para analizar si el producto de su competencia infringe patentes de sus propios productos. En el software y en el hardware, es empleada para desarrollar productos que sean compatibles con otros productos, sin conocer detalles de desarrollo de stos ltimos. Es empleada para comprobar la seguridad de un producto. La gran mayora del software de pago incluye en su licencia una prohibicin expresa de aplicar ingeniera inversa a su cdigo, con el intento de evitar que se pueda modificar su cdigo y que as los usuarios tengan que pagar si quieren usarlo. Los conceptos de reingeniera e ingeniera inversa estn ligados al desarrollo de software a gran escala, donde una mejora en proceso de este desarrollo supone un aumento en la competitividad de la empresa. Aunque hay que tener en cuenta que esta mejora es, en general a largo plazo (normalmente de uno a dos aos) ambas actividades, estn orientadas a automatizar el mantenimiento de Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales aplicaciones. Esta es una tarea que consume gran cantidad de recursos, por lo que cualquier reduccin en el tiempo y recursos empleados en ella supone una importante mejora en la productividad del proceso. Este es el principal objetivo de la reingeniera. Se trata, de analizar el cdigo o el diseo actual y modificarlo con la ayuda de herramientas automticas para traducirlos a cdigos ms estructurados, y ms eficientes. La reingeniera e ingeniera inversa prolongan la vida del software. Dado que es una labor estratgica, es conveniente conocer cuando conviene realizar la tarea de reingeniera para una aplicacin y cundo es ms rentable sustituirla e implementar una nueva. Las aplicaciones para el primer paso, son aquellas en la que se produce las siguientes situaciones: Fallos frecuentes, que son difciles de localizar Son poco eficientes, pero realizan la funcin esperada Dificultades en la integracin con otros sistemas Calidad pobre del software final Resistencia a introducir cambios Pocas personas capacitadas para realizar modificaciones Dificultades para realizar pruebas El mantenimiento consume muchos recursos Es necesario incluir nuevos requisitos, pero los bsicos se mantienen.
Desarrollo de software con y para reuso El desarrollo de software con reso consiste en desarrollar una aplicacin usando software ya existente. Cualquier profesional lo utiliza. El desarrollo de software para reuso consiste en la construccin de un sistema con la intencin de reutilizar partes de l en futuros desarrollos. Con software a gran escala, un buen profesional con experiencia puede desarrollarlo. Estudios realizados determinan que la prctica de reutilizacin del software en un proyecto aumenta la productividad durante el desarrollo de dicho proyecto. Sin embargo, la reutilizacin del software no cubre solo el reuso de cdigos, abarca todo un amplio de posibilidades en los diferentes niveles, metodologa, ciclos de vida, planes del proyecto, especificaciones de requisitos, diseos, arquitectura software, planes de validacin, juegos de prueba y documentacin. 3.3 Cdigo fuente abierto.
Definicin: Es el trmino con el que se conoce al software distribuido y desarrollado libremente Open Source centra su atencin en la premisa de que al compartir el cdigo el programa resultante tiende a ser de calidad superior al software propietario. Cdigo abierto (en ingls open source) es el trmino con el que se conoce al software distribuido y desarrollado libremente. Fue utilizado por primera vez en 1998 por algunos usuarios de la comunidad del software libre, tratando de usarlo como reemplazo al ambiguo nombre original en ingls del software libre (free software). Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Free en ingls puede significar diferentes cosas: gratuidad y libertad. Por ello, por un lado, permite pensar en "software por el que no hay que pagar" (software gratuito) y, por otro, se adapta al significado que se pretendi originalmente (software que posee ciertas libertades). El trmino para algunos no result apropiado como reemplazo para el ya tradicional free software, pues eliminaba la idea de libertad (incluso hay algunos que usan en ingls el trmino libre software para evitar la ambigedad de free). Desde el punto de vista de una "traduccin estrictamente literal", el significado obvio de "cdigo abierto" es que "se puede mirar el cdigo fuente", por lo que puede ser interpretado como un trmino ms dbil y flexible que el del software libre. Basado en ello se argumenta que un programa de cdigo abierto puede ser software libre, pero tambin puede ser semilibre o incluso completamente no libre. Sin embargo, por lo general, un programa de cdigo abierto puede ser y de hecho es software libre, como igualmente un programa Software Libre es Open Source. Esto ocurre dado que ambos movimientos reconocen el mismo conjunto de licencias y tiene principios equivalentes. Por qu es importante el open source? los programadores en Internet pueden leer, modificar y redistribuir el cdigo fuente de un programa. El software evoluciona, se desarrolla y mejora. Los usuarios lo adaptan a sus necesidades, corrigen sus errores a una velocidad impresionante, mayor a la aplicada en el desarrollo de software convencional o cerrado. Se obtiene la produccin de un mejor software. Declogo para ser cdigo abierto open source 1. Libre redistribucin: 2. 3. 4. 5. 6. 7. 8. 9. 10. Cdigo fuente: Trabajos derivados: Integridad del cdigo fuente del autor: Sin discriminacin de personas o grupos: Sin discriminacin de reas de iniciativa: Distribucin de la licencia: La licencia no debe ser especfica de un producto: La licencia no debe restringir otro software: La licencia debe ser tecnolgicamente neutral:
Caractersticas y ventajas Flexibilidad. Fiabilidad y seguridad. Rapidez de desarrollo. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Relacin con el usuario. Libre. Combate efectivamente la piratera de software Abierto y cerrado (la OpenDoc Society) Podr parecer a algunos un tema arcano e incluso ajeno, sobre todo a aquellos editores cuya relacin con la tecnologa sea todava tirante, tensa, pero lo que se est debatiendo hoy mismo en el seno de la ISO, resulta decisivo para que el circuito de generacin, intercambio, circulacin y consulta de contenidos escritos, editoriales, dependa de la intermediacin de formatos propietarios o, al contrario, del uso gratuito y universal de un formato de documentos abierto y compatible, independiente. La OpenDoc Society pretende, precisamente, alejar a las instituciones pblicas del uso de formatos cerrados y propietarios, con manifestas incompatibilidades retrospectivas y dependientes, siempre, de que el cdigo del programa utilizado sea desentraado por sus creadores. La apuesta, por tanto, una vez ms, es la del cdigo abierto como fundamento de la libre circulacin de contenidos en la web, como garanta de que el acceso a la informacin sea un derecho garantizado mediante el uso de formatos inteligibles por todos, sostenidos en el tiempo, sin incompatibilidades arteras entre versiones.
Software abierta Software que gracias a estndares- permite su integracin o la complementacin por otros Cdigo Abierto Software donde se tiene acceso al Cdigo Fuente en algn lenguaje de Programacin Cdigo sin aranceles de licencias Software donde no se paga una licencia para usarla Cdigo con licencias abiertas Software donde se tiene el derecho de incorporarla en otros sistemas o de modificarla 0
Diferencia entre cdigo de fuente abierto & software libre. El Cdigo Fuente Abierto se basa en hacer software confiables y poderosos. Enfatizan los valores prcticos y se garantiza los derechos de modificacin y redistribucin de dichas versiones modificadas del programa. En tanto que el software libre brinda libertad a los usuarios sobre su producto adquirido puede ser usado, copiado, estudiado, modificado y redistribuido libremente. Se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. 3.4 Las falacias del cdigo abierto. No hay ningn beneficio en regalar las naranjas ni en ensear a otros a cultivarlas De acuerdo con la definicin de Software Libre, tenemos que es: La libertad de usar el programa, con cualquier propsito (libertad 0).


Academia de Informtica y Sistemas Computacionales La libertad de estudiar cmo funciona el programa, y adaptarlo a tus necesidades (libertad 1). El acceso al cdigo fuente es una condicin previa para esto. La libertad de distribuir copias, con lo que puedes ayudar a tu vecino (libertad 2). La libertad de mejorar el programa y hacer pblicas las mejoras a los dems, de modo que toda la comunidad se beneficie. (libertad 3). El acceso al cdigo fuente es un requisito previo para esto. Como fabricante de software, voy a ver si podra vender o distribuir software libre (ya que est tan en boga):
Libertad 0 (parece que las libertades las han asignado a una Matriz Dim Libertad(2) as Variant) Mis programas los pueden usar los clientes para lo que quieran. Que no me demanden si el programa para un PC lo instalan en un horno y se les quema la comida. En una sociedad como la norteamericana donde te demandan por cualquier motivo y donde las botellas de leche dicen Para beber y por la boca. No nos hacemos responsables si Vd. se atraganta esta restriccin me parece normal y prudente. Libertad 1Si alguien pudiese tener acceso a mis programas, por lo pronto ya pierde la garanta. Lo segundo es que quin le impide que copie y pegue el cdigo en una solucin suya, lo venda y me haga la competencia? Un cdigo fuente cerrado protege la propiedad intelectual. Libertad 2Libertad de distribuir copias. Vaya que bien!!! Si tu negocio se basa en vender programas, directamente cierra el negocio. Vende qu? Servicios que nadie demanda? Soporte? La mayora de las empresas no pagan soporte por algo que cueste 100, 200 euros. Pagan soporte por algo que cueste 30.000 euros. Libertad 3Quin hace eso? Cuantos programadores avanzados se ponen a tocar el cdigo fuente? Los que estn aburridos o los que le dan un uso intensivo. Y luego cuntos despus de estar trabajando 1 mes para revisar todos los errores de programacin de un mdulo o crear otro mdulo nuevo van a compartirlo con el resto? Conociendo la faceta egoista del alma humana, creo que pocos. Recordemos las 4 libertades del software libre que son lo que la GPL defiende desde el punto de vista legal.
1. Ejecutar el software con cualquier propsito. 2. Estudiar el cdigo del software y poder adaptarlo a las necesidades, por lo tanto la
liberacin del cdigo es un requisito fundamental.
3. Libertad de distribucin. 4. Libertad de mejorar el software y distribuir la mejora.

Estas 4 libertades defienden los derechos que debera tener cualquier persona sobre cualquier producto adquirido, si yo me compro una escoba soy libre de usarla, de ver como funciona, dejrsela a mis amigos o de construir mis propias escobas con un mango ms cmodo y venderlas (o regalarlas si lo prefiero), parece lgico verdad?, es lo que a lo largo del tiempo ha permitido el desarrollo y la evolucin, lo que todos conocemos como la competencia.


Academia de Informtica y Sistemas Computacionales Falacias Software abierto = Cdigo Abierto Falso: Bastan Interfases abiertos para SW Abierta Cdigo abierto sin estndares no es SW-A Software sin pago de licencias = CA Falso: Hay sistemas CA donde se paga licencias Hay Software sin pago que no es CA Licencias abiertas = Cdigo Abierto Falso: Partes cerradas pero licencias abiertas Cdigo Abierto sin licencia abierta Software sin pago de licencias = Lic. Abierta Falso: Licencias Abiertas que se paga (caras a veces) Licencias free sin derecho a Integracin o Modificacin Linux es la base del Software Libre Falso Corre ms SW Cdigo abierto / Licencia Abierta en Windows que en LINUX Hay bastante SW cerrada que se usa encima de LINUX IBM, Oracle .... JAVA no es Licencia Abierta ni Cdigo abierto Software abierta? Software con cdigo abierto? Software sin pago de licencias? Software con licencia abierta? Software libre es ms econmico Falso: Que no se tiene que pagar licencias no implica de por si menores costos Costo total de usar SW contiene adems Costos de Entrenamiento Costos de Mantenimiento Costos recurrentes de Conversin Costos en 1+2+3 >> Licencias muchas veces Costos mano de obra mas bajos Costos de licencia igual o mas alto = Rentable gastar en trabajo no en licencias Argumento valido para 1. El estado (sector pblico) 2. Empresas formales 3. Receptores de cooperacin externa 4. Hasta cierto grado: Instituciones educativas Pero no para quienes no pagan ni pagarn licencias! Software libre se puede modificar fcilmente Falso cuando son centenares de miles de lneas de cdigo 1. Sin documentacin ni herramientas imposible salvo despus de un intensivo estudio 2. Se tiene que garantizar compatibilidad con otros 3. Al modificar una versin se tiene que congelarse o enfrentar nuevo trabajo por cada nueva versin Software libre es ms fcil a mantener Falso


Academia de Informtica y Sistemas Computacionales 1. Nadie garantiza la compatibilidad entre los diferentes versiones de los diferentes paquetes de diferentes orgenes 2. No hay actualizaciones automticas, ni en caso de errores garrafales 3. Sin conectes virtuales ni habilidades de buscar remedios imposible Software libre no es un negocio ni una mercanca Falso Explotar SL es costoso, tan que IBM, JBOSS, MYSQL, Otros lo han hecho base de su modelo de negocios Agencias de Cooperacin lo usan para traspasar costos no pagan ni licencias ni personal Centenares de ONG y Consultores viven de SL solo que no es el cliente final que paga


Unidad VII Pruebas de software

Objetivo: El alumno conocer e identificar las fases y los diferentes tipos de pruebas que se realizan al software. Contenido: 7.1 Fases de las Pruebas de Software 7.1.1 Modelado del ambiente del software 7.1.2 Seleccin de escenarios de prueba 7.1.3 Ejecucin y evaluacin de los escenarios de prueba 7.1.4 Medicin del progreso de las pruebas 7.2 Prcticas de las Pruebas de Software 7.2.1 Bsicas 7.2.1.1 Especificaciones funcionales 7.2.1.2 Revisin e inspeccin 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 Ejecucin 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 planificacin de la prueba 7.2.2.4 Generacin automatizada de la prueba 7.2.3 Incrementales 7.2.3.1 Cobertura de cdigo 7.2.3.2 Generador de ambiente automatizado 7.2.3.3 Diagrama del estado de la prueba 7.2.3.4 Simulacin de falla en la memoria 7.2.3.5 Pruebas estadsticas 7.2.3.6 Mtodos semiformales 7.2.3.7 Registro de la prueba para el cdigo 7.2.3.8 Benchmark 7.2.3.9 Generacin de errores (bugs)


Academia de Informtica y Sistemas Computacionales 7.1. Fases de las Pruebas de Software En la ingeniera del software el trmino fases de desarrollo expresa cmo ha progresado el desarrollo de un software y cunto desarrollo puede requerir. Cada versin importante de un producto pasa generalmente a travs de una etapa en la que se agregan las nuevas caractersticas (etapa alfa), despus una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los bugs importantes (etapa estable). Las etapas intermedias pueden tambin ser reconocidas. Las etapas se pueden anunciar y regular formalmente por los desarrolladores del producto, pero los trminos se utilizan a veces de manera informal para describir el estado de un producto. Normalmente muchas compaas usan nombres en clave para las versiones antes del lanzamiento de un producto, aunque el producto y las caractersticas reales son raramente secretas. La fase conocida como pre-alfa se publica a veces antes del lanzamiento de una versin alfa o beta. En contraste con la versin alfa y las versiones beta, la pre-alfa no tiene sus caractersticas completas. Los diseadores todava estn determinando en esta etapa exactamente qu funcionalidades debe tener el producto. Tales etapas se pueden llamar tambin development releases o nightly builds. La versin alfa de un producto es la primera para la que el equipo de desarrollo decide que implementa todas las funcionalidades especificadas en los requisitos. Es la primera versin del programa que se enva a los verificadores para probarla. Algunos equipos de desarrollo utilizan el trmino alfa informalmente para referirse a una fase donde un producto todava es inestable, aguarda todava a que se eliminen los errores o a la puesta en prctica completa de toda su funcionalidad, pero satisface la mayora de los requisitos. Cuando una versin beta llega a estar disponible para el pblico en general, a menudo es utilizada extensamente por los tecnolgicamente expertos o familiarizados con versiones anteriores, como si el producto estuviera acabado. Generalmente los desarrolladores de las versiones betas del software gratuito o de cdigo abierto los lanzan al pblico en general, mientras que las versiones betas propietarias van a un grupo relativamente pequeo de probadores. En el siguiente diagrama mostramos las fases de pruebas, asi de la misma manera como se encuentran relacionadas con los diferentes tipos de pruebas con las que interactan: Asignatura: Desarrollo de Software Seguro

7.1.1. Modelado del Ambiente del Software Al trabajo con ordenador se destina hoy gran parte del tiempo laboral. Sin embargo, las facilidades que genera el uso de datos digitales implican para el trabajador nuevas cargas de ndole fsica y anmica. Esta actividad, que el usuario lleva a cabo la mayor parte del tiempo sentado, puede ocasionar daos en la columna vertebral y la musculatura, adems de producir una mala circulacin sangunea, dolores de cabeza y trastornos de la visin. Por otro lado, debido a que la comunicacin y colaboracin entre colegas es poco frecuente, esta situacin puede implicar a largo plazo el aislamiento social. Segn un decreto de la Unin Europea sobre seguridad y proteccin de la salud ante el trabajo con ordenadores, aprobado el 21 de agosto de 1997, las empresas de ms de diez trabajadores deben cumplir una serie de normativas que hacen referencia al lugar de trabajo (mesa, silla, superficie de trabajo), a las herramientas utilizadas (tipo de monitor y tamao del mismo, teclado, escabel, software), al ambiente de trabajo (iluminacin, acstica, temperatura, humedad del aire) y a la propia habitacin (superficie de movimiento, altura de la habitacin, contacto visual). En la prctica son numerosas las empresas que ignoran esta normativa debido a los costes que generara su puesta en prctica.


Academia de Informtica y Sistemas Computacionales 7.1.2. Seleccin de Escenarios de Prueba 1. Creando escenarios: Cuando ya tenemos un producto debemos: Saber a quien se lo queremos vender. Olvidar mercados y hablar de personas Caracterizar a la persona a la que le quieres vender Crear al menos 5 fichas que definan a la persona a la que le quieres vender.
2. Elige a alguien de tu tamao: Si eres pequeo elige a alguien de tu tamao. Debes ser capaz de llegar al menos a la mitad del escenario que elijas en el primer ao.
3. Crea una pgina por cada escenario, y numera cada Uno. Antes y al final realiza una hoja de Excel con todos los datos numricos de todos los escenarios. Nmero de clientes posibles. Facturacin. N empleado. Todos los campos claves que utilices para definir el escenario.
4. Haz tormenta de ideas con tu equipo: Debes involucrar a todo el mundo en las valoraciones de los diferentes escenarios, y realiza media de las puntuaciones que haga cada uno. Ejemplo: Ocupando un Rango del (0 A 5) aplicado a: Dificultad de venta. Instalacin. Facilidad de mantenimiento.
5. Ordena: Resultados por puntuaciones medias. Elimina los escenarios que no pasen el primer corte. Repite una votacin privada de los escenarios finales. Vuelve a discutir. Puedes introducir ms indicadores de decisin sobre el escenario previsto. Lo importante es que el grupo de trabajo se implique en la decisin final. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales 6. Resultado final: Depende los resultados puede pasar los siguientes: a) El grupo est de acuerdo de cual es el escenario adecuado: A por l, sin miramientos, sin dudas, sin arrepentimientos, sin cambios, pelea por conseguir los objetivos marcados. b) El grupo no se pone de acuerdo en el escenario a elegir: Elige a una persona para que desarrolle la teora de bolos y elige el primer bolo de la teora. c) No hay ningn escenario que supere los mnimos: No trates de crecer. Quiz no sea el momento. El producto no est preparado. La empresa, sigue vendiendo a clientes cercanos hasta que el momento y el escenario correcto se presenten.
7.1.3. Ejecucin y evaluacin de los escenarios de pruebas La aplicacin manual de los escenarios de prueba es una tarea que consume demasiado tiempo. La evaluacin de los escenarios de prueba es un proceso que se puede descomponer en las siguientes fases:
a) Revisar lo que dice la documentacin del software respecto a las funciones que debe realizar. b) Comparar los resultados de la ejecucin de los escenarios de prueba con lo que dice la documentacin. c) La documentacin se asume correcta. Desviaciones se consideran fallos. Una alternativa para permitir la evaluacin de los escenarios de prueba es la formalizacin de la escritura de las especificaciones del software. Formalizar escritura de las especificaciones y la forma en que el cdigo se genera basado en las especificaciones definidas. En muchos casos esta tarea es dejada de lado y se procede a desarrollar software de manera informal, pero sin estas especificaciones los escenarios de prueba podrn detectar los errores ms obvios y nada ms. 7.1.4 Medicin del progreso de las pruebas Nuevas Necesidades para Pruebas La necesidad de pruebas nunca haba sido tan grande. Las expectativas del consumidor han aumentado: Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales a) Se requiere la integracin de funciones en espacios reducidos y a un bajo costo. b) Quien sea que cumpla estas demandas; rpido, confiable y consistentemente, tiene la ventaja competitiva del mercado. El sistema tendr que demostrar ser el mejor posible. La instrumentacin virtual es una solucin innovadora a estos retos: Combina el rpido desarrollo de software con el hardware modular y flexible para crear sistemas de prueba definidos por el usuario. Ofrece Herramientas de software intuitivas para pruebas de desarrollo rpidas Ofrece E/S basadas en tecnologas comerciales innovadoras, rpidas y precisas.
Rapidez en el Desarrollo de Software de Prueba La automatizacin se ha convertido en un requisito para probar rpidamente sistemas complejos. El software se ha convertido en un elemento esencial en todos los sistemas de prueba, desde verificacin de diseo hasta pruebas de manufactura automatizadas. Para entregar sistemas de prueba que se adapten a probar nuevas caractersticas rpidamente, se requiere de un conjunto de herramienta de desarrollo de pruebas integradas. Estas pruebas incluyen pruebas de administracin y desarrollo, as como hardware de Entrada/Salida. 7.2 Prcticas de las Pruebas de Software Existen muchos prcticas y mtodos para la prueba del Software. Entre ellas: Mtodos Pruebas del software (Dinmico): consisten en ejecutar comprobando que distintos valores de entrada producen los resultados deseados. Mtodos de inspeccin del software (Esttico): se basan en la revisin de la documentacin, requisitos, incluso cdigo sin ejecutar nada. Esta tarea puede realizarse por un grupo de expertos Pruebas de caja negra: no conocemos la implementacin del cdigo, slo la interfaz. Tan slo podemos probar dando distintos valores a las entradas y salidas. Pruebas de caja blanca: conocemos el cdigo (la implementacin de ste) que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos del cdigo. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Pero a las que nos enfocaremos son a las pruebas bsicas 7.2.1 Bsicas En la evolucin de la creacin del software tenemos que responder constantemente a las preguntas: Estamos construyendo el producto correctamente? hemos tomado del usuario Estamos construyendo bien el cdigo? El resultado final del desarrollo software concuerda con la especificacin (requisitos) del sistema? Hay que intentar asegurar que el desarrollo final coincide con dicha especificacin. Las practicas en las fases de prueba para determinar que nuestro software cumpla el objetivo del cliente y como empresa pueden ser: Especificaciones funcionales Revisin e inspeccin Entrada formal y criterios de salida Prueba funcional Pruebas multiplataforma Ejecucin automatizada de prueba Programas beta Dada la especificacin que
7.2.1.1 Especificaciones funcionales Describe cmo funcionar un producto completamente desde la perspectiva del usuario. No le importa cmo se implemente la cosa. Habla de funciones. Especifica pantallas, mens, dilogos, etctera. Podemos decir que una especificacin es una declaracin de un acuerdo entre quien brinda un servicio y el consumidor del mismo. Por ejemplo, las especificaciones de requerimiento son cuando el acuerdo es entre el usuario final y el desarrollador del sistema; especificaciones de diseo entre el diseador o arquitecto del sistema y el programador que implementa el diseo. Una especificacin nos puede decir qu queremos que el sistema haga, en el caso de los modelos de Anlisis. Otras veces indican al implementarlo cmo debe hacerlo, como en el caso de las especificaciones de Diseo. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Esta divisin a veces no es tan clara. Muchas veces la manera de especificar qu es lo que queremos es por medio de un ejemplo de cmo debera hacerse (lo que no implica necesariamente que deba hacerse de esa forma sino que debe comportarse como si se hiciese as). 7.2.1.2 Revisin e inspeccin Las inspecciones: Surgen a partir de la necesidad de producir software de alta calidad. Las podemos ver como una implementacin de las revisiones formales del software las cuales representan un filtro para el proceso de ingeniera de software, stas se aplican en varios momentos del desarrollo y sirven para detectar defectos que pueden as ser eliminados. Freeman y Weinberg [Fre90] argumentan de la siguiente forma la necesidad de revisiones: Una revisin es una forma de aprovechar la diversidad de un grupo de personas para: 1. Sealar la necesidad de mejoras en el producto de una sola persona o de un equipo. 7.2.1.3 Entrada formal y criterios de salida Entrada/salida (I/O, de Input/Output): Engloba las tareas complementarias de obtencin de datos que procesa el microprocesador y de entrega de los resultados a travs de un dispositivo: La pantalla La unidad de disco o la impresora, etc.
Un dispositivo de entrada/salida transfiere informacin en las dos direcciones posibles. Para introducir datos se emplean dispositivos muy diversos. La mayora de las computadoras personales incluyen un teclado. El reconocimiento de voz es muy empleado en algunas aplicaciones, pero estos dispositivos de entrada son todava imperfectos y slo responden a un pequeo vocabulario de instrucciones. Los dispositivos de salida ms habituales son las impresoras y los monitores en color.


Academia de Informtica y Sistemas Computacionales La salida de audio tambin es corriente, as como las complejas conexiones con sintetizadores que producen una amplia gama de sonidos musicales. 7.2.1.4 Prueba funcional Functional Testing, son pruebas de software que tienen por objetivo probar que los sistemas desarrollados, cumplan con las funciones especficas para los cuales han sido creados, es comn que este tipo de pruebas sean desarrolladas por analistas de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la ultima etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a produccin. Objetivo: Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo la navegacin, entrada de datos, procesamiento y obtencin de resultados. Metas: Verificar el procesamiento, recuperacin e implementacin adecuada de las reglas del negocio. Verificar la apropiada aceptacin de datos.
Enfoque: Los requisitos funcionales (Casos de Uso) y las reglas del negocio.
Estas pruebas nos dicen que:
Se aplique apropiadamente cada regla de negocio. Los resultados esperados ocurran cuando se usen datos vlidos. Sean desplegados los mensajes apropiados de error y precaucin cuando se usan datos invlidos.
En la mayora de los casos stas pruebas son realizadas manualmente por el analista de pruebas, tambin es posible automatizarlas utilizando herramientas como WinRunner o SilkTest las cuales permiten generar scripts conforme nosotros hagamos interacciones con el aplicativo a probar. 7.2.1.5 Pruebas multiplataforma Que tiene la capacidad de soportar mltiples plataformas. Esto significa que el software que es multiplataforma tiene la caracterstica de funcionar de forma similar en distintas plataformas (distintos sistemas operativos por ejemplo).


Academia de Informtica y Sistemas Computacionales Una plataforma es, por ejemplo, un sistema operativo, un gran software que sirve como base para ejecutar determinadas aplicaciones compatibles con este. Tambin son plataformas la arquitectura de hardware, los lenguajes de programacin y sus libreras en tiempo de ejecucin, las consolas de videojuegos, etc. Existen programas multiplataforma, que permiten ejecutarse en diversas plataformas. Tambin existen emuladores, programas que permiten ejecutar desde una plataforma programas de otra emulando su funcionamiento. Las aplicaciones multiplataforma son aquellas que pueden funcionar en diferentes sistemas operativos y/o ordenadores, pero el cdigo fuente es el mismo. Los programadores tendemos a escribir programas slo vlidos para nuestra plataforma, olvidndonos de que hay usuarios que trabajan en otras. Una de las grandes ventajas de las aplicaciones multiplataformas es que dan la libertad al usuario de poder utilizar la mquina que ms le guste. Unos usuarios prefieren Linux (como es mi caso), otros prefieren Windows, otros MAC, etc. El usuario debe poder elegir. Normalmente, son los fabricantes los que deciden por nosotros: cuando sacan un nuevo software, slo est disponible para las mquinas que ellos decidan. En este cuaderno tcnico se explica cmo desarrollar aplicaciones para consola (no grficas) en entornos Linux que se puedan compilar para mquinas Windows, sin tener que cambiar ni una sola lnea de cdigo fuente. Es por ello que las pruebas del sistema desarrollado se debe tomar en cuenta que funcione en la mayora o todos los sistemas operativos que hay sin tener posibles fallos, eso hace de el sistema ms confiable y estable al momento de ser implantado en una empresa u organizacin. 7.2.1.6 Ejecucin automatizada de prueba Una herramienta automatizada de la accesibilidad es un pedazo del software que puede probar un Web page, o an de un Web site entero, para la accesibilidad. Free Articles. Las herramientas automatizadas de la accesibilidad son tiles porque pueden ahorrarte una cantidad de tiempo enorme. No desean comprobar las imgenes para saber si hay texto del alt en cada pgina en tu Web site? Funcionar el sitio a travs de un probador automatizado. Las herramientas de prueba automatizadas de la accesibilidad utilizan generalmente las pautas de la accesibilidad de W3C. Estas pueden ser tiles mientras que pueden ahorrar una cantidad de tiempo grande en la ejecucin de algunas comprobaciones para muy bsicas accesibilidad.


Academia de Informtica y Sistemas Computacionales Sin embargo, deben ser utilizadas con la precaucin y no pueden ser utilizadas como gua independiente para la comprobacin de la accesibilidad. Herramienta de validacin de los colores de un website de acuerdo al Web Content Accessibility Guidelines. Check My Colour es una aplicacin web con la que determinar la conformidad de nuestro website con el WCAG, el estndar centrado en los aspectos visuales, con el que lograr que nuestra web sea ms fcil de leer, mejorando el contraste de colores y la luminosidad. Simplemente con introducir la URL de nuestra web, obtendremos en apenas unos segundos y tras realizar una serie de pruebas basadas en World Wide Web Consortium (W3C), una tabla completa donde ver cada uno de los aciertos (verde) y los errores (rojo) encontrados, sealando en qu parte del cdigo se encuentra el error. http://www.checkmycolours.com 7.2.1.7 Programas beta Cuando la palabra betase utiliza para referirse a un software, se trata de un trmino corto para beta-test tambin llamada versin beta. Un periodo donde dicho software est tcnicamente acabado, lo cual significa que no se le aadirn de momento ms funciones, y presumiblemente ser lo suficientemente estable para trabajar con normalidad. En contraste, la versin alfa, lo cual ocurre antes de la versin beta, ms inestable y no est completa. Hay betas que son realmente software por testear, y otros que, simplemente, son etiquetados como beta por los programadores por miedo a que puedan contener algn error. La beta es un comodn, haces algo si arriesgarte a que te critiquen por algn bug o problema que cause tu software. 7.2.2 Fundamentales El software ser fundamental para los nuevos servicios que traer la telefona mvil y Microsoft est trabajando para garantizar la interoperatibilidad de los sistemas. Se trata de facilitar el acceso universal a la informacin y la creacin de nuevos servicios, aplicaciones y dispositivos mviles. El software es el que har inteligente al dispositivo mvil que tendr que poder utilizarse tanto cuando est en disposicin de ser utilizado para hablar o cuando est apagado como puede ser en un avin.


Academia de Informtica y Sistemas Computacionales Entre las pruebas fundamentales podemos mencionar: 1. 2. 3. 4. Escenarios de usuarios. Pruebas de utilidad. Requerimientos para la planificacin de la prueba. Generacin Automatizada de la prueba.
7.2.2.1 Escenarios de usuario En estos escenarios, el administrador desea controlar las aplicaciones que un usuario puede instalar y ejecutar. Al utilizar una directiva de restriccin de software, los administradores controlan qu aplicaciones pueden instalar los usuarios con sus niveles de permiso habituales. AIS, Application Information Service) es un nuevo servicio de Microsoft Windows Vista que implementa Proteccin de cuentas de usuario (UAP, User Account Protection). Repaso De los escenarios de prueba: Para probar una directiva de restriccin de software y la interaccin con AIS, se requiere que un usuario del dominio inicie la sesin en un equipo cliente de Windows Vista con UAP habilitado y que intente instalar, ejecutar y desinstalar una aplicacin permitida y una no permitida, segn lo defina la directiva del dominio. Escenario 1 Solicite al usuario del dominio que intente instalar una aplicacin permitida. El usuario debera poder instalar la aplicacin sin que se le soliciten credenciales de administrador.
Escenario 2 Para instalar una aplicacin permitida: Intente instalar una aplicacin que el administrador del dominio no haya permitido instalar explcitamente mediante una directiva. El usuario no debera poder instalar la aplicacin.


Academia de Informtica y Sistemas Computacionales Escenario 3
Intente ejecutar una aplicacin que el administrador del dominio haya permitido que los usuarios ejecuten. El usuario debera poder ejecutar la aplicacin.
Escenario 4 Para ejecutar una aplicacin permitida: Intente ejecutar una aplicacin que el administrador de dominio no haya permitido que los usuarios ejecuten. El usuario no debera poder ejecutar la aplicacin.
Escenario 5 Para intentar ejecutar una aplicacin no permitida:
Nota:
Intente desinstalar una aplicacin que el administrador del dominio haya permitido que los usuarios puedan desinstalar.
Esta prueba examina la interaccin del Servicio de informacin de aplicaciones y que el objeto de la directiva del dominio permite a los usuarios quitar aplicaciones sin la necesidad de utilizar credenciales administrativas. En este caso, se aplica configuracin de directivas del dominio para permitir al usuario instalar, actualizar y desinstalar aplicaciones. 7.2.2.2 Pruebas de utilidad Todo debe ser modificado Todas las cualidades relevantes del sistema deben ser verificadas: correccin: la implementacin especificaciones; portabilidad, modificabilidad, performance. Etc. se comporta de acuerdo con las
La verificacin debe realizarse por distintas personas durante distintas etapas del desarrollo del software; La gente del equipo de desarrollo podra realizar esto. Objetivos de la Prueba de Software


Academia de Informtica y Sistemas Computacionales Las pruebas del software pueden usarse para demostrar la existencia de errores, nunca su ausencia. [Dijkstra, 1972] Utilidad de las Pruebas Si las pruebas no dan certeza sobre la correccin del software, tienen alguna utilidad? Si bien no proporcionan certeza, las pruebas pueden aumentar nuestra confianza en que el sistema se comportar como es esperado. Lo esencial de las pruebas es: elegir un conjunto de datos de prueba apropiados, aplicar las pruebas en forma sistemtica.
Valores Aleatorios de Prueba Los datos aleatorios de prueba suelen no ser los ms apropiados. Slo el desarrollador del programa sabe cules son los datos sensibles para cada aplicacin y cules los resultados esperados. En el ejemplo no sirven una cantidad de casos de diferentes valores de (x,y), sino solamente dos: un caso con x igual a y, un caso con x distinto de y.
Localizable, Repetible y Precisas Las pruebas no solamente deben detectar la presencia de errores, sino que deben indicar cul es el error y dnde se encuentra. Las pruebas deben organizarse para que provean informacin acerca de la localizacin de los errores. Las pruebas tambin deben ser repetibles: aplicadas dos veces, debieran producir los mismos resultados. La influencia del ambiente de ejecucin atenta contra la repetibilidad de las pruebas. Los resultados esperados deben definirse dependiendo de los datos de entrada y de otros eventos del ambiente.
Si la variable x no est inicializada y se tiene este trozo de programa, cul ser el resultado? a veces anormal, a veces normal. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Esta prueba no es repetible. Algunos lenguajes no chequean que las variables estn inicializadas, por razones de eficiencia. Especificaciones Precisas Las especificaciones del software deben ser suficientemente precisas como para guiar las pruebas:
como consecuencia del estmulo X, el sistema debe producir la salida Y en menos de segundos. t
Qu prueba debe aplicarse? Dar el estmulo X al sistema, medir el tiempo hasta que produzca la salida, comprobar que la salida sea Y y el tiempo sea menor o igual a t segundos.
Pero, qu sucede si ocurren otros eventos despus de dar el estmulo X? Cmo se prueba un sistema concurrente? Defectos, Fallas y Faltas La presencia de un error o defecto se demuestra encontrando un d tal que P(d) es incorrecto. Una falla es el sntoma de que existe un error; se da durante la ejecucin, pero un error puede existir en el cdigo sin causar ninguna falla, el objetivo de las pruebas es tratar de que todos los defectos existentes provoquen fallas. Una falta es un estado intermedio incorrecto en que entra un programa durante su ejecucin. Una falla solamente ocurre si existe una falta, Qu ocurre si un defecto no provoca una falla?, Qu ocurre si una falta no produce una falla? 7.2.2.3 Requerimientos para la planificacin de la prueba Durante la fase de requerimientos de software, las actividades deben realizarse de acuerdo a los planes definidos en la fase UR. La principal actividad de esta fase corresponde a la traduccin de los requerimientos del usuario a requerimientos de software. Las actividades a realizar son las siguientes: Construccin del Modelo Lgico: Se debe construir un modelo independiente de la implementacin que especifica lo que el usuario requiere. Las herramientas CASE facilitan la creacin y modificacin del modelo. El estndar ESA explicita una serie de reglas para lograr un modelo lgico de calidad (por ejemplo: Identificar Funciones Criticas). Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Especificacin de los Requerimientos de Software: Los requerimientos de software son obtenidos analizando en el modelo lgico creado. Esta clasificacin de requerimientos es: a) Funcionales: Especifica lo que el software debe hacer. b) Performace: Especifica valores numricos para variables medibles (por ejemplo: velocidad y capacidad). c) Interfaz: Especifica los componentes de hardware, software o BD con que el sistema o parte del sistema debe interactuar. d) Operacionales: Especifica como el sistema funcionara y se comunicara con los operadores. e) Recursos: Especifica la necesidad de procesamiento, capacidad de memoria, entre otros, que el sistema debe tener. f) Verificacin: Especifica las restricciones que sern verificadas. g) Aceptacin: Especifica las restricciones que sern validadas. h) Documentacin: Especifica documentacin adicional al estndar para el sistema. i) Seguridad: Especifica lo necesario en seguridad del sistema para que sea confiable, integro y disponible en todo momento. j) Portabilidad: Especifica la facilidad del sistema para funcionar en otros PC o sistemas operativos. k) Calidad: Especifica atributos del sistema que asegurar que el sistema estar a la altura de su propsito. l) Confiabilidad: Especifica los intervalos de tiempo aceptable entre fallas del sistema. m) Mantenibilidad: Especifica la facilidad con se puede reparar las fallas en el sistema o realizar up grades de este. n) Safety: Especifica los requerimientos para reducir las posibilidades de dao que pueden darse cuando falla el sistema. Consistencia de los Requerimientos de Software: Debe existir consistencia entre todos los requerimientos de software, es decir, trminos con un solo significado y usados para un solo propsito, actividades secuencialmente realizadas y correctamente, etc Duplicacin de los Requerimientos de Software: Debe evitarse la duplicaron de requerimientos de software. Revisiones: Debe realizarse una revisin tcnica en la fase SR/R Con su estrategia de prueba, apunte a responder las siguientes preguntas:


Academia de Informtica y Sistemas Computacionales Qu estamos verificando?, Qu enfoque tomaremos?, Qu otra informacin necesito para planificar con eficacia? Cuando planifique, formule preguntas como las siguientes: Cmo llevaremos a cabo nuestras pruebas?, Dnde las llevaremos a cabo?, Cundo las llevaremos a cabo?, Cmo gestionaremos los problemas que encontremos?, Etc. Los siguientes son temas que usted puede encarar en su planificacin de prueba: Preparaciones Asignacin de personal Cobertura de la prueba Todos los requerimientos de prueba (tcnicos u otros) Entornos de prueba Criterios de ingreso Criterios de salida Delegacin de responsabilidades Adquisicin de instalaciones Planificacin de tareas Programacin Documentacin sobre la coordinacin y colaboracin con otros equipos Riesgos y problemas que puedan impactar sobre las pruebas Entregables especficos del proyecto de prueba
Cuando usted lleva a cabo la planificacin, deber contar con: Informacin sobre su contexto Informacin sobre el problema (o proyecto) Ideas sobre las pruebas Ideas sobre la cobertura de las pruebas Ideas sobre los riesgos del proyecto Ideas sobre los detalles de la ejecucin Documentos o artefactos que apuntan a compartir las ideas que usted tiene, y que resultan tiles para cuestionar los supuestos y las nociones Documentos o artefactos que puedan ser necesarios para avanzar en el proceso (segn el contexto)
7.2.2.4 Generacin automatizada de la prueba (Rice 2002) enumera y explica los diez retos ms importantes en la automatizacin del proceso de pruebas. De acuerdo con este autor, stos son los siguientes:
1. Falta de herramientas, debida fundamentalmente a su elevado recio o a que

las existentes no se ajusten al propsito o entorno para el que se necesitan. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales La primera razn parece deberse a la no mucha importancia que habitualmente se le da a la fase de pruebas, y eso que el costo de corregir un error puede, en muchos casos, superar al de la licencia de uso. Sera conveniente evaluar el coste de correccin de defectos del software entregado y compararlo con el de la licencia de la herramienta de pruebas.
2. Falta de compatibilidad e interoperabilidad entre herramientas.

3. Falta de proceso de gestin de la configuracin. Igual que las diferentes versiones del cdigo fuente, las pruebas, especialmente las de regresin, deben someterse a un control de versiones. Recurdese que el proceso de Gestin de la Configuracin es uno de los procesos de soporte del estndar ISO/IEC 12207 (ISO/IEC 1995), que debera utilizarse en la ejecucin de los procesos principales, y muy especialmente en los de Desarrollo y Mantenimiento. 4. Falta de un proceso bsico de pruebas y de conocimiento de qu es lo que se debe probar. 5. Falta de uso de las herramientas de prueba que ya se poseen, bien por su dificultad de uso, por falta de tiempo para aprender a manejarla, por falta de soporte tcnico, obsolescencia, etc. 6. Formacin inadecuada en el uso de la herramienta. 7. La herramienta no cubre todos los tipos de prueba que se desean (correccin, fiabilidad, seguridad, rendimiento, etc.). Obviamente, a la hora de elegir la herramienta, deberan tenerse priorizados los tipos de pruebas, y entonces hacer la eleccin de la herramienta basados en esto. A veces tambin es necesario utilizar no una, sino varias herramientas de prueba, as como tener en cuenta que es imposible automatizar el 100% de las pruebas. 8. Falta de soporte o comprensin por parte de los jefes, debido otra vez a la escasa importancia que habitualmente se le da a la fase de pruebas. 9. Organizacin inadecuada del equipo de pruebas. 10. Adquisicin de una herramienta inadecuada 7.2.3 Incrementales Entre estas prcticas de pruebas se destacan las siguientes: Cobertura de cdigo Generador de ambiente automatizado Diagrama del estado de la prueba Simulacin de falla en la memoria Pruebas estadsticas Mtodos semiformales Registro de la prueba para el cdigo Benchmark Generacin de errores (bugs)
7.2.3.1 Cobertura de cdigo


Academia de Informtica y Sistemas Computacionales La cobertura de cdigo es una medida que se utiliza en las disciplinas de comprobacin automtica (automated testing) de software. Esta medida indica la fraccin de del software que las pruebas han cubierto. Si las pruebas nos indican que nuestro software es correcto, la cobertura de cdigo nos indica que partes de nuestro software son correctas (esto no es del todo cierto, como veremos ms adelante). Es decir, La cobertura de cdigo es una medida de calidad, pero no de calidad de nuestro software, sino de nuestras pruebas: nos indica que partes del software estn comprobando nuestras pruebas y, lo ms importante, cules partes no estamos comprobando. La cobertura de cdigo, como las pruebas automticas y la documentacin del cdigo son cosas que hacen perder el tiempo a los desarrolladores tontos y salvadores para los desarrolladores con cabeza, aunque en realidad La cobertura de cdigo no nos hace perder mucho el tiempo, ya que la mayora de los casos es cuestin de utilizar alguna herramienta sobre nuestro software, preferentemente sobre el ejecutable que realiza nuestras pruebas (si lo probamos sobre un ejecutable final lo mximo que obtendremos es las partes del software que el usuario ha utilizado). La medida de La cobertura de cdigo de nuestro software siempre ser mejor cuanto ms cerca del 100% est, pero llegar a esos nmeros o incluso cerca puede llegar a ser contra productivo. La idea es utilizar la herramienta de cobertura de cdigo sobre nuestras pruebas, comprobar que partes del cdigo no se han ejercitado y escribir nuevas pruebas que utilicen esas partes. Una cobertura de cdigo superior a 95% es un buen punto para detenerse. Sin embargo la mayora de herramientas de cobertura de cdigo no son capaces de comprobar ms que lo que se llama cobertura de instruccin o de lnea (statement coverage o line coverage, a veces denominado C0), que indica si una instruccin se ha ejecutado o no. En la mayora de los casos esta medida ya dice mucho de la calidad de las pruebas, pero no siempre: por ejemplo, el siguiente cdigo obtendra un 100% de cobertura si se ejecutase cualquiera de las ramas: if (condicion) {cdigo 1; } else {cdigo 2;} Pero obviamente s solo se ha ejecutado una de las ramas no se han comprobado todos los caminos posibles. Otras medidas como la cobertura de ramas o la cobertura de bloques (branch coverage o C1, y block coverage) resuelven este problema. Ms all de C1 existen algunas medidas ms de cobertura de cdigo: entre las ms interesantes est C2 o cobertura de caminos (path coverage) que se encarga de comprobar que todos los caminos posibles entre el punto de entrada de una funcin y el/los puntos de salida han sido cubiertos. int funcin (bool condicion1, bool condicion2, bool condicion3)


Academia de Informtica y Sistemas Computacionales {int resultado = 0; if (condicion1) resultado += 1; if (condicion2) resultado += 2; if (condicion3) resultado += 3; return resultado;} En el fragmento de cdigo anterior existen 23=8 caminos posibles. Nuestras pruebas deberan comprobar cada una de esas 8 posibilidades para conseguir una cobertura C2 del 100%, mientras que con una nica prueba conseguiramos una cobertura C0 total. Es por esto que los nmeros que nos proporcionan las herramientas para medir La cobertura de cdigo no deben ser tomados como valores absolutos, sino como indicaciones sobre como orientar nuestras siguientes pruebas. Para realizar las medidas de code coverage existen multitud de herramientas, sobre todo para Java y .Net (los lenguajes con mquina virtual y grandes capacidades de reflexividad son ms sencillos de comprobar que programas nativos, adems de que ltimamente son mucho ms utilizados), pero se puede encontrar casi para cualquier lenguaje. Podis ver una pequea lista de herramientas de code coverage en el wiki de C2. La mayora de herramientas open source proporcionan medidas de C0 (que ya es bastante, tengo que decir) y si tenemos suerte de C1. Pocas herramientas open source proporcionan medidas de C2 o medidas ms sofisticadas, aunque s existen herramientas comerciales que dicen proporcionar tales medidas. Generalmente C0 nos da una buena idea de la calidad de nuestras pruebas y C1 nos proporciona ms seguridad sobre esas medidas, con lo que la mayora de herramientas open source nos bastarn para quitarnos un gran peso de encima. Una Herramienta ocupada para test de cobertura de cdigo en windows es: Rational PurifyPlus for Windows. Ayuda a los desarrolladores a identificar los errores de fiabilidad y rendimiento en cdigo. Incluye deteccin de corrupcin de memoria, deteccin de prdidas de memoria, parametrizacin del rendimiento de aplicaciones y anlisis de cobertura del cdigo.


7.2.3.2 Generador de ambiente automatizado Al disear sistemas de prueba automatizadas, resulta clave la maximizacin de exactitud. La mayora de los ingenieros de prueba tornan su mirada a las hojas de datos para los instrumentos que estn evaluando con la esperanza de que estos documentos proporcionen todas las respuestas. Sin embargo, otros factores son igualmente importantes en la maximizacin de la exactitud de sus sistemas de prueba automatizados. A continuacin se proponen cuatro estrategias que se pueden seguir para maximizar la exactitud de sus sistemas de prueba automatizados. 1. Comprender las Especificaciones del Instrumento. Resulta importante comprender que los diferentes vendedores de instrumentos con frecuencia especifican la exactitud de medida utilizando ya sea diferente terminologa o terminologa similar con diferentes significados. Es importante tener en claro todos los parmetros involucrados en definir las caractersticas de un instrumento. 2. Considerar Requerimientos de Calibracin. A pesar de la exactitud de los instrumentos que usted selecciona para sus sistemas de prueba automatizados, es importante darse cuenta que las exactitudes de los componentes electrnicos utilizados en todos los instrumentos cambian a travs del tiempo. 3. Monitoree el Sistema Operativo No todos los instrumentos tienen las mismas especificaciones ambientales. Sus sistemas de prueba automatizadas pueden encontrarse en un ambiente de oficina Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales donde la temperatura y humedad estn altamente controladas, pero puede haber una fbrica u otra instalacin industrial. 4. Utilice la Configuracin Apropiada. Conectar su sistema de prueba automatizado al dispositivo bajo prueba (DUT) puede ser tan simple como conectar cables entre instrumentos hacia una caja de escape o terminales de refuerzo y conectarlas al DUT para sistemas con menor de 50 puntos de prueba o bien, solo algunos instrumentos. Los efectos del tiempo en el servicio as como condiciones ambientales, se incorporan a este cambio. Para resolver este conflicto, sus instrumentos deben calibrarse a intervalos regulares. 7.2.3.3 Diagrama del estado de la prueba Los diagramas de estado de la prueba: Describen grficamente los eventos y los estados de los objetos. Son tiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso. Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condicin de un objeto en un momento determinado:
El tiempo que transcurre entre eventos. Una transicin es una relacin entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren, sus transiciones, y los estados que median entre estos eventos. Es til hacer diagramas de estado para describir la secuencia permitida de eventos en los casos de uso. Una transicin puede tener una proteccin condicional, o prueba booleana, que permite pasar al siguiente estado solemente si esta proteccin es vlida. Estas protecciones se colocan entre parntesis debajo de los eventos
Los diagramas de estado describen grficamente los eventos y los estados de los objetos. Los diagramas de estado son tiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso. Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condicin de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transicin es una relacin entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.


Academia de Informtica y Sistemas Computacionales En UML, los estados se representan mediante valos. Las transiciones se representan mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado inicial (crculo negro). Por ejemplo:
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren, sus transiciones, y los estados que median entre estos eventos. En particular, es til hacer diagramas de estado para describir la secuencia permitida de eventos en los casos de uso. Por ejemplo, en el caso de uso comprarProductos no est permitido efectuar pagoTarjeta mientras no haya ocurrido el evento terminarVenta. Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un caso de uso es un diagrama de estado para casos de uso. Por ejemplo, una versin simplificada del diagrama de estados para el caso de uso comprarProductos es el siguiente:
Una versin ms completa del diagrama anterior se muestra en la siguente figura:


Academia de Informtica y Sistemas Computacionales El diagrama anterior aun no est completo, pues falta considerar algunos casos excepcionales, como por ejemplo, si al rechazar una tarjeta de crdito o un cheque, el cliente decide pagar usando otro mtodo, por ejemplo pagando en efectivo. Una transicin puede tener una proteccin condicional, o prueba booleana, que permite pasar al siguiente estado solemente si esta proteccin es vlida. Estas protecciones se colocan entre parntesis debajo de los eventos (ver validacin del usuario al descolgar el auricular, en la siguiente figura). Tambin se pueden tener sub-estados anidados.
Las herramientas usadas en la etapa de anlisis (investigacin del problema) se pueden resumir en la siguiente tabla.
7.2.3.4 Simulacin de falla en la memoria El manejo de memoria consiste en la asignacin y liberacin de bloques de memoria a medida que un programa lo solicite. Particularmente, la liberacin de memoria puede realizarse en forma manual o mediante tcnicas automatizadas, tambin conocidas como tcnicas de recoleccin de basura, pues consisten en identificar y liberar los bloques asignados que ya no sern accedidos desde la aplicacin (Simsek, 2005. La Simulacin de falla en la memoria evala si las aplicaciones no exceden los limites de memoria en los peores casos, o situaciones criticas. Puede ser utilizado para comprender el diseo de nuestro software que ejecuten de forma ptima un determinado tipo de programas paralelos o para mejorar el modo de operar de una arquitectura paralela concreta.


Academia de Informtica y Sistemas Computacionales Permite establecer la configuracin de los parmetros que definen la arquitectura del sistema, ofrecindonos la respuesta del mismo al someterlo a los accesos de memoria generados por los programas permitiendo evaluar si nuestro sistema no satura la memoria. 7.2.3.5 Pruebas estadsticas Pruebas Estadsticas A continuacin se presentan algunas de las opciones que el software debe proporcionar para la realizacin de las pruebas estadsticas que se utilizan para validar el cumplimiento de los supuestos planteados durante la elaboracin del modelo. Estadsticas Descriptivas Incluye valor medio, desviacin estndar, altura, esbeltez, normalidad de los datos y valores mximos y mnimos. Principalmente utilizado para chequear si los datos se distribuyen en forma normal y con valor medio cero para el caso de los residuales. Test de Heterocedasticidad En primer lugar se debe crear una variable que contenga los valores de los residuales (previa definicin del modelo como fue indicado anteriormente), para luego continuar con el siguiente procedimiento. Test de Autocorrelacin Luego de definirse el modelo, se puede chequear la presencia de autocorrelacin mediante varios pasos. Entregando como resultado la aceptacin o rechazo de la hiptesis nula de no existencia de autocorrelacin. Test de Multicolinealidad Para chequear si las variables independientes se encuentran o no relacionadas en forma lineal, se debe obtener la matriz de correlacin. El programa devuelve una matriz en donde aparecen las correlaciones entre todas las variables incorporadas al modelo y slo resta interpretar los resultados. Test de inferencia El programa incluye los test para verificar el cumplimiento de las hiptesis. Implica tener un mtodo para medir la fiabilidad. Este sistema, al contrario que los sistemas de test, no busca el fallo sino todo lo contrario Tiene cuatro etapas:


Academia de Informtica y Sistemas Computacionales 1. 2. 3. 4. Obtencin de un perfil operativo de los sistemas en uso. El perfil operativo es el estudio de conjunto de posibles entradas. Se construye un conjunto de entrada de test en funcin del perfil anterior Se prueba el sistema contra estos datos y se computa: Nmero de fallos Tiempo o frecuencia de los errores
7.2.3.6 Mtodos semiformales Se encuentran dentro de las Metodologas o tecnicas de Desarrollo del Software, hablamos de especificaciones semi-formales cuando hacemos uso de un lenguaje semi-formal, es decir, un lenguaje que tiene una sintaxis mas o menos precisa y una semntica informal. Un ejemplo de este tipo de notacin son los diagramas de UML, los diagramas de Entidad-Relacin, etc. Notacin especifica y definida sigue reglas y normas que se pueden validar, Cuando hacemos uso de un lenguaje semiformal, es decir, un lenguaje que tiene una sintaxis mas o menos precisa y una semntica informal por ejemplo: Modelos Grficos. Notaciones.
Mtodos Estructurados SA/SD (structured analysis & structured design) Mtrica
Mtodos Orientados a Objetos OMT UML
Mtodos Orientados a la Estructura de los Datos, Mtodos de flujo de datos
Los mtodos orientados a objeto describen e implementan los sistemas de informacin desde un punto de vista ontolgico.


7.2.3.7 Registro de la prueba para el cdigo Test Driven Development (TDD) es una prctica de programacin que involucra otras dos prcticas: Escribir las pruebas primero (Test First Development) y Refactorizacin (Refactoring). Para escribir las pruebas generalmente se utiliza la Prueba Unitaria (unit test en ingls). Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el cdigo que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el cdigo escrito. El propsito del desarrollo guiado por pruebas es lograr un cdigo limpio que funcione (Del ingls: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizar que los requerimientos se hayan implementado correctamente. Estas pruebas son una herramienta esencial para la investigacin de la interaccin persona ordenador, y tambin dentro del campo que ha venido a llamarse "usabilidad". TDD se propone agilizar el ciclo de escritura de cdigo y realizacin de pruebas de unidad. Las pruebas de unidad son las que se aplican a una parte de un programa para comprobar que cumpla su funcin especfica. En los mtodos tradicionales de desarrollo de software, estas pruebas son llevadas a cabo por personas cuya nica tarea es asegurar la calidad del producto final. El hecho de que quienes estn a cargo de escribir el cdigo y quienes deban probarlo sean grupos distintos suele originar cierto nivel de competencia: los programadores se esfuerzan por escribir cdigo correcto, que luego debern entregar a sus "oponentes" para que traten de demostrar lo contrario, encontrando los casos en que el programa falla. Si bien la competencia resulta provechosa en ciertas circunstancias, un equipo de desarrollo debera estar conformado por individuos que realizaran un esfuerzo conjunto detrs de un objetivo comn, sin enfrentarse entre ellos. Adems, el trmite que supone enviar el cdigo para que sea probado demora el avance del proyecto. El programador no entrega su cdigo hasta que lo ha revisado lo suficiente. Recin en ese momento se lo prueba, se documentan los errores y, para resolverlos, el programador - quien ha estado esperando o ha comenzado a trabajar en otra parte del proyecto - tiene que volver a sumergirse en ese cdigo que haba dejado de lado. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales La propuesta del Desarrollo guiado por Pruebas es radicalmente distinta a la explicada en el prrafo anterior. Segn esta prctica, es el programador quien realiza las pruebas de unidad de su propio cdigo, e implementa esas pruebas antes de escribir el cdigo a ser probado. Cuando el programador recibe el requerimiento de implementar una parte del sistema, y una vez que comprendi cul es la funcionalidad pretendida, debe empezar por pensar qu pruebas va a tener que pasar ese fragmento de programa (o unidad) para que se considere correcto. Luego procede a programar, pero no el cdigo de la unidad que le toc, sino el cdigo que se va a encargar de llevar a cabo las pruebas. Cuando est satisfecho de haber escrito todas las pruebas necesarias (y no antes), comienza a programar la unidad, con el objetivo de pasar las pruebas que program. La forma de trabajo del programador tambin cambia mucho durante la escritura del cdigo funcional propiamente dicho. En lugar de trabajar durante horas o das hasta tener la primera versin en condiciones de ser probada, va creando pequeas versiones que puedan ser compiladas y pasen por lo menos algunas de las pruebas. Cada vez que hace un cambio y vuelve a compilar, tambin ejecuta las pruebas de unidad. Y trata de que su programa vaya pasando ms y ms pruebas hasta que no falle en ninguna, que es cuando lo considera listo para ser integrado con el resto del sistema. Una de las grandes diferencias con el estilo de trabajo tradicional es que ya no compite con otro u otros, sino que compite consigo mismo; se enfrenta al desafo de escribir cdigo que pase las pruebas que l mismo program. Y siguiendo las premisas de muchos de los mtodos giles, solamente programar lo que sea estrictamente necesario para ese fin. Pasemos a un ejemplo muy simple, para ilustrar cmo funciona este proceso. Supongamos que me toca desarrollar un componente .NET que se encargue de ordenar un arreglo de valores enteros y que, como parte del diseo, se ha decidido hacerlo mediante el algoritmo de bubble sort u ordenamiento por burbujeo. Para los que no recuerden o no conozcan este algoritmo; se trata de recorrer el arreglo intercambiando entre s los elementos contiguos que se encuentren en el orden inverso al buscado, y recomenzar ese procedimiento tantas veces como sea necesario, hasta que no queden pares por intercambiar. Como estoy haciendo TDD, tengo que empezar por decidir qu pruebas voy a hacer. Elijo probar con varios arreglos de cinco elementos que siempre sern los nmeros del 1 al 5. Y se me ocurren las siguientes pruebas:
1. Un arreglo ordenado;
2. Un arreglo que tenga solamente un par de elementos contiguos fuera de orden; 3. Un arreglo que tenga el ltimo elemento al principio (y el resto de ellos en orden); Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales 4. Un arreglo que tenga el primer elemento al final; 5. Un arreglo completamente invertido. Tal vez no sea suficiente, pero yo me siento conforme. Pienso que si logro escribir un programa que pase odas estas pruebas, habr cumplido con lo pedido. l paso siguiente es implementar las pruebas en la forma de un programa que examine mi componente. Dado que todo desarrollador guiado por pruebas tiene que crear frecuentemente programas de este tipo, existen herramientas que facilitan el trabajo. 7.2.3.8 Benchmark Un benchmark es un conjunto de procedimientos (programas de computacin) para evaluar el rendimiento de un ordenador. Hay cuatro categoras generales de pruebas de comparacin: Pruebas aplicaciones-base (application-based) las ejecuta y las cronometra. Pruebas playback (playback test), las cuales usan llamadas al sistema durante actividades especificas de una aplicacin (Ej.: Llamados a grficos o uso del disco) y las ejecuta aisladamente. Prueba sinttica (synthetic test), la cual enlaza actividades de la aplicacin en subsistemas especficos. Prueba de inspeccin (inspection tests), la cual no intenta imitar la actividad de la aplicacin, sino que las ejecuta directamente en los subsistemas especficos.
Los test de aplicaciones base entregan la mejor forma de medir el rendimiento completo de el sistema en el mundo real. El programa Winstone de Zdnet, ejecuta mas de una docena de las aplicaciones mas populares en el ambiente Windows, es un ejemplo de este tipo de comparadores. Donde sea factible la tecnologa playback le da la manera ms real de medir subsistemas individuales en aislacin. El programa WinBench de ZDnet utiliza la tecnologa playback para probar grficos, Cd-rom y subsistemas de disco duro, tambin corre cientos de otras pruebas en reas especificas del computador. Los test Synthetic continan en el estado de medicin del rendimiento es por eso que winbench usa las pruebas de procesadores. Los test de inspeccin tienen su lugar verificando el comportamiento libre de fallas y midiendo rendimiento operacin por operacin, por esto se incluye el test de inspeccin en el winbench. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales Dhrystone Dhrystone es una medida de rendimiento de la CPU en entero, expresado en Millones de instrucciones por segundo (MIPS). El Dhrystone benchmark es ampliamente usado en la industria de las computadoras como una medida de rendimiento, Wintune (programa benchmark) usa la versin modificada del Dhrystone que mantiene sus datos en el almacenador del programa. Esto permite al benchmarks trabajar apropiadamente en mltiple threads en Windows NT. El Dhrystone estndar, fue originalmente diseado para un nico ambiente (singlethreaded), manteniendo alguno de sus datos en variables estticas globales. El Dhrystone es un benchmark sinttico, diseado para contener ejemplos representativos de las operaciones normalmente requeridas por las aplicaciones. Estas no calculan el resultado de ningn tipo, pero hacen enlaces de complicadas secuencias de instrucciones usadas por las aplicaciones. El resultado del Dhrystone es determinado por el tiempo que toma la medicin para ejecutar esta secuencia de instrucciones. La aritmtica del entero simple, decisiones lgicas, y accesos de memoria son las actividades dominantes de la CPU en la mayora de los programas Windows. El Dhrystone benchmark hace un uso intensivo de estas reas. Por lo tanto el Dhrystone no tiene suficiente cdigo de programa o acceso suficiente a las locaciones de memoria para simular la actividad de la mayora de los programas reales. Su lugar de trabajo de cdigo y datos puede generalmente ser mantenido en el cache de la CPU, con lo cual resulta con un alto rendimiento. Desde que el Dhrystone no ofrece una buena indicacin del rendimiento de memoria, Wintune tiene un set separado de prueba de memoria. Whetstone Whetstone es una medida de rendimiento de la CPU en punto flotante, expresado en Millones de operaciones de punto flotante por segundo (MFLOPS). El Whetstone benchmark es ampliamente usado en la industria de la computacin como una medida de rendimiento, Wintune usa una versin modificada del Whetstone que mantiene sus datos en el programa de almacenamiento. Esto permite al benchmarks trabajar apropiadamente en mltiples threads en Windows NT.


Academia de Informtica y Sistemas Computacionales El Whetstone estndar, fue originalmente diseado para un ambiente nico, manteniendo alguno de sus datos en variables estticas globales. La aritmtica del punto flotante es la ms significativa en programas que requieren FPU. Estos son en su mayora ingeniera cientfica, de estadsticas, y programas de ayuda de diseo en computacin. Es tambin un pequeo componente en hoja de clculo, dibujo y pintado de programas. (Aunque la hoja de clculo trabaja con nmeros tambin tiene una mejor presentacin en pantalla.) Los programas procesadores de texto tpicamente no hacen ningn computo en punto flotante. El Whetstone hace mucha aritmtica del punto flotante un poco de acceso de memoria, y un poco la aritmtica del entero. Porqu considerar el Rendimiento? Juzgar el rendimiento de un sistema cuando se estn tomando decisiones de compra es algo crtico a fin de retardar la obsolescencia y proteger su inversin. 7.2.3.9 Generacin de errores (bugs) Resolver los problemas cuando se presentan es un proceso fcilmente determinado, pero prevenir problemas es una tarea muy minuciosa y muy difcil de determinar. En la antigua china exista una familia de curadores, uno de los integrantes de esta familia siendo ya muy reconocido fue contratado por uno de los grandes Seores del territorio como su medico personal. Una noche mientras cenaban el Seor le pregunta al medico cual de sus otros familiares era tan poderoso como el, entonces el medico comento; Yo atiendo a personas con grandes males, casi moribundos llegan a mi con cierta fe, y algunas veces logro curarlos, y mi nombre es reconocido en casi todo el territorio. Mi hermano mayor cura las enfermedades cuando recin comienzan a hacer raz en el cuerpo y su nombre es reconocido en los vecindarios, mi hermano menor cura enfermedades antes de que aparezcan y solo es conocido por la familia y su nombre no ha salido de la casa. Es decir, arreglar o corregir un problema o bug despus que sale a la luz es una tarea relativamente sencilla, ya que se conoce el foco del problema, el inconveniente esta en corregir un error que no esta visible o no ha sucedido todava. Cuales son las razones para que un programa contenga Bugs? Poca o falta de comunicacin entre diferentes aplicaciones. (Requerimientos de las aplicaciones.) Complejidad del software: Causa dificultad en la reutilizacin de cdigo y generalmente requiere personas con experiencia en desarrollo de software moderno como por ejemplo en sistemas cliente servidor, aplicaciones distribuidas, comunicacin de datos, manejo de Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales enormes bases de datos relacionales y un gran manejo de tcnicas orientadas a objetos. A veces estos conocimientos tambin pueden causar ms errores de los que corrigen. Errores de programacin: Los programadores son uno de los principales factores en la causa de errores o Bugs. Requerimiento de cambio en el sistema: El rediseo y la replanificacin causan efectos en otros proyectos que trabajan en conjunto o a partir de resultados del sistema modificado. Estos procesos cooperativos generan ms complejidad en las diferentes pruebas y en el control y generalmente el entusiasmo de los desarrolladores del sistema se ve afectado al tener que realizar actividades diferentes o no correspondientes a su labor. Como por ejemplo el de los ingenieros al tener que hacer un anlisis funcional a partir de su planificacin, todo esto influye y atenta con la integridad del programa y genera riesgos de una gran cantidad de errores. Presiones de tiempos: Una buena planificacin y un buen anlisis con sus respectivos controles de calidad y prueba se ven afectados por un lapso corto de tiempo para que esto sea completo. La falta de tiempo generalmente conlleva a no considerar u omitir ciertas fases de prueba y control. El ego (aspecto psicolgico del personal): A veces la situacin y el contexto llevan a que la gente diga: - No hay problema - Es muy fcil. - Puedo terminar esto en pocas horas. -No habr inconvenientes en adaptar ese viejo cdigo. En vez de decir: -Eso es muy complejo. -Nos llevara a cometer varios errores. -No puedo estimar cuanto tiempo me llevara este trabajo. -No se como readaptar ese cdigo. Son muchas las ocasiones en las que un No hay problema genera un Bugs. Pobre documentacin del cdigo: Es difcil poder modificar cdigo cuya documentacin es escasa o esta mal escrita. Asignatura: Desarrollo de Software Seguro

Academia de Informtica y Sistemas Computacionales En muchas organizaciones los directivos no incentivan a los programadores a realizar una buena documentacin e incluso a no darle importancia a la entendibilidad del cdigo, como tambin el hecho de incentivar demasiada seguridad en la documentacin y escritura del cdigo. Lo que fue difcil de escribir podra llegar a ser difcil de leer y aun mas complicado de modificarlo. Herramientas de desarrollo de software: Herramientas visuales, libreras de clases, compiladores, herramientas de escritura, etc., a menudo introducen cdigo extra con pobre documentacin lo cual genera un Bugs en el programa en cuestin. Un serio manejo de control de calidad en la codificacin es absolutamente necesario para evitar estos Bugs, por lo que un nuevo software debe garantizar cumplir con lo formalizado. Un Buen cdigo es aquel que funciona sin Bugs, adems debe ser legible y mantenible, se debe ajustar a los estndares de la organizacin para que todos los desarrolladores del sistema manejen y entiendan las mismas herramientas y mecanismos en la codificacin.


Antología DSS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Antología DSS

Uploaded by

Copyright:

Available Formats

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Academia de Informtica y Sistemas Computacionales

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

1.3 FUTURO DEL SOFTWARE

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

BREAKING AND PATCH

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Monitoreo de Sistemas de Seguridad

Cmo monitoreo servidores de bases de datos detrs de un firewall

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Precauciones de los usuarios:

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Unidad II Administracin de los riesgos en la seguridad del software

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

2.1 DESCRIPCIN DE LA ADMINISTRACIN DE LOS RIESGOS EN LA SEGURIDAD DEL SOFTWARE

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Los casos de prueba deben satisfacer los siguientes criterios:

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Los criterios para la valoracin de las cualidades inherentes de los

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

EAL4 (diseado, probado y revisado metdicamente): este nivel le

EAL6 (diseo verificado y probado semiformalmente): permite a los

EAL7 (diseo verificado y probado formalmente): es aplicable al

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro

INSTITUTO TECNOLGICO SUPERIOR DE CENTLA

Asignatura: Desarrollo de Software Seguro