DDS

1,542 views

Published on

No es mi autoría

Published in: Engineering
  • Be the first to comment

DDS

  1. 1. 32a INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Antología DSB-0705 DESARROLLO DE SOFTWARE SEGURO Presentan Ing. Manuel Torres Vásquez Revisado por los integrantes de la academia de Informática y Sistemas Computacionales Material compilado con fines académicos Fecha elaboración: Julio 2010 Institución Certificada Norma ISO 9001:2000
  2. 2. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Tabla de Contenido Unidad I Introducción a la seguridad del software 1.1 Concepto de Software 1.2 Casos reales de fallas en el software 1.3 Futuro del software 1.4 Fuentes para información de vulnerabilidades 1.4.1. Buqtraq 1.4.2. CERT Advisores 1.4.3. RISK Digest 1.5 Tendencias técnicas que afectan a la Seguridad del Software 1.6 Breanking and patch (romper y actualizar) 1.7 Metas de la Seguridad enfocadas al Software 1.7.1. Prevención 1.7.2. Auditable y trazable 1.7.3. Monitoreo 1.7.4. Privacidad y Confidencialidad 1.7.5. Seguridad Multiniveles 1.7.6. Anonimato 1.7.7. Autenticación 1.7.8. Integridad 1.8 Conocer al enemigo 1.9 Metas de proyecto de Software
  3. 3. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad II Administración de los riesgos en la seguridad del software 2.1 Descripción de la administración de los riesgos en la Seguridad del Software 2.2 Administración de los riesgos en la seguridad del Software en la práctica 2.2.1 Pruebas de Caja Negra 2.2.2 Equipo Rojo 2.3 Criterios Comunes Unidad III Código abierto o cerrado 3.1 Seguridad por Oscuridad 3.2 Ingeniería en Reversa 3.3 Código Fuente Abierto 3.4 Falacias del código abierto
  4. 4. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad IV Principios guías del software seguro 4.1 Principio 1. Reducir las líneas débiles 4.2 Principio 2. Defensa por pasos o capas 4.3 Principio 3. Seguramente fallará 4.4 Principio 4. Menos privilegios 4.5 Principio 5. Segmentación 4.6 Principio 6. Mantenerlo simple 4.7 Principio 7. Promover la privacía 4.8 Principio 8. Ocultar secretos es difícil 4.9 Principio 9. Transparentar el código 4.10 Principio 10. Usar recursos comunes Unidad V Auditoria de software 5.1 Definición de Arquitectura de Seguridad 5.2 Principios de la Arquitectura de Seguridad 5.3 Análisis de la Arquitectura de Seguridad 5.3.1 Diseño 5.3.2 Implementación 5.3.3 Automatización y pruebas 5.3.4 Árboles de Ataque 5.3.5 Reporte del Análisis 5.4 Implementación del Análisis de Seguridad 5.4.1 Auditoria de Código Fuente 5.4.2 Herramientas de Auditoria de Seguridad de Código
  5. 5. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad VI Código seguro 6.1 Definición de Código Seguro 6.2 Lenguaje Ensamblador 6.3 Lenguajes de Programación 6.4 Técnicas de Código Seguro 6.4.1 Buffer Overflows 6.4.2 Heap Overflows 6.4.3 Formato de cadena 6.4.4 Exploits 6.4.5 Race conditions 6.4.6 SQL injection 6.4.7 Cross Site & Cross-Domain Scripting 6.4.8 Fault Injection
  6. 6. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad VII Pruebas de software 7.1 Fases de las Pruebas de Software 7.1.1 Modelado del ambiente del software 7.1.2 Selección de escenarios de prueba 7.1.3 Ejecución y evaluación de los escenarios de prueba 7.1.4 Medición del progreso de las pruebas 7.2 Prácticas de las Pruebas de Software 7.2.1 Básicas 7.2.1.1 Especificaciones funcionales 7.2.1.2 Revisión e inspección 7.2.1.3 Entrada formal y criterios de salida 7.2.1.4 Prueba funcional 7.2.1.5 Pruebas multiplataforma 7.2.1.6 Ejecución automatizada de prueba 7.2.1.7 Programas beta 7.2.2 Fundamentales 7.2.2.1 Escenarios de usuario 7.2.2.2 Pruebas de utilidad 7.2.2.3 Requerimientos para la planificación de la prueba 7.2.2.4 Generación automatizada de la prueba 7.2.3 Incrementales 7.2.3.1 Cobertura de código 7.2.3.2 Generador de ambiente automatizado 7.2.3.3 Diagrama del estado de la prueba 7.2.3.4 Simulación de falla en la memoria 7.2.3.5 Pruebas estadísticas 7.2.3.6 Métodos semiformales 7.2.3.7 Registro de la prueba para el código 7.2.3.8 Benchmark 7.2.3.9 Generación de errores (bugs)
  7. 7. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad VIII Derechos de autor en México (software) 8.1 Ley Federal del Derecho de Autor (LFDA) en México 8.1.1 Definición 8.1.2 Artículos para la protección jurídica del software 8.1.3 Derechos que se confieren a través de la LFDA 8.1.3.1 Derechos morales 8.1.3.2 Derechos patrimoniales 8.2. Instituto Nacional del Derecho de Autor (INDAUTOR) 8.2.1 Definición 8.2.2 Ubicación del INDAUTOR 8.3 Dirección General de Asuntos Jurídicos de la UNAM (DGAJ) 8.3.1 Definición 8.3.2 Relación con el INDAUTOR 8.3.3 Ubicación de la DGAJ 8.4 Registro del software 8.4.1 Procedimiento y requerimientos para registrar software en el INDAUTOR. 8.4.2 Procedimiento y requerimientos para registrar software en la DGAJ. 8.4.3 Ventajas y desventajas al registrar software 8.5 Violación a los Derechos de Autor 8.6 Leyes que brindan protección jurídica al software en caso de violación. 8.7 Sociedades de Gestión Colectiva 8.7.1 ¿Qué es una Sociedad de Gestión Colectiva? 8.7.2 Procedimiento y requerimientos para registrar una Sociedad de Gestión Colectiva. 8.7.3 Obligaciones y privilegios al formar parte de una Sociedad de Gestión Colectiva.
  8. 8. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad I Introducción a la seguridad del software Objetivo: El alumno conocerá y comprenderá los fundamentos teóricos, tendencias y metas de la seguridad en el software. Contenido: 1.1 Concepto de Software 1.2 Casos reales de fallas en el software 1.3 Futuro del software 1.4 Fuentes para información de vulnerabilidades 1.4.1. Buqtraq 1.4.2. CERT Advisores 1.4.3. RISK Digest 1.5 Tendencias técnicas que afectan a la Seguridad del Software 1.6 Breanking and patch (romper y actualizar) 1.7 Metas de la Seguridad enfocadas al Software 1.7.1. Prevención 1.7.2. Auditable y trazable 1.7.3. Monitoreo 1.7.4. Privacidad y Confidencialidad 1.7.5. Seguridad Multiniveles 1.7.6. Anonimato 1.7.7. Autenticación 1.7.8. Integridad 1.8 Conocer al enemigo 1.9 Metas de proyecto de Software
  9. 9. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.1 CONCEPTO DE SOFTWARE El software es el nexo de unión entre el hardware y el hombre. El computador, por sí solo, no puede comunicarse con el hombre y viceversa, ya que lo separa la barrera del lenguaje. El software trata de acortar esa barrera, estableciendo procedimientos de comunicación entre el hombre y la máquina; es decir, el software obra como un intermediario entre el hardware y el hombre. El software es un conjunto de programas elaborados por el hombre, que controlan la actuación del computador, haciendo que éste siga en sus acciones una serie de esquemas lógicos predeterminados. Tal característica ‗lógica‘ o ‗inteligente‘ del software es lo que hace que se le defina también como la parte inmaterial de la informática, ya que aunque los programas que constituyen el software residan en un soporte físico, como la memoria principal o los disquetes (o cualquier dispositivo rígido de almacenamiento), la función de los programas en un computador es semejante a la del pensamiento en un ser humano. Si bien el progreso del hardware es cada vez mayor y los dispositivos físicos se construyen cada vez con más ‗inteligencia‘ incluida, en forma que se resuelven por hardware funciones anteriormente sólo factibles por software, es prácticamente imposible que el avance tecnológico llegue algún día a eliminar la necesidad de software, ya que éste también evoluciona y las facilidades que el usuario pide al computador son cada día más sofisticadas. La clasificación básica es: Software de Sistema y Software de Aplicación.  El software de sistema es el software básico o sistema operativo. Es un conjunto de programas cuyo objeto es facilitar el uso del computador (aísla de la complejidad de cada dispositivo, y presenta al exterior un modelo común de sistema de manejo para todos los dispositivos) y conseguir que se use eficientemente  El software de aplicación Son los programas que controlan y optimización la operación de la máquina, establecen una relación básica y fundamental entre el usuario y el computador, hacen que el usuario pueda usar en forma cómoda y amigable complejos sistemas
  10. 10. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. hardware, realizan funciones que para el usuario serían engorrosas o incluso imposibles, y actúan como intermediario entre el usuario y el hardware. 1.2 CASOS REALES DE FALLAS EN EL SOFTWARE  El caso del desastre del Ariane-5, famoso por haberse producido por una falla en el software de abordo. Según la European Spacial Agency (ESA), administradora del programa, la desviación en la trayectoria fue ocasionada por la computadora que controlaba los dos poderosos impulsores del cohete. Se especulo que la computadora creyó que el cohete se estaba saliendo de curso y de esta manera trataba de corregir la trayectoria de vuelo. De acuerdo con el reporte final, la causa de la falla del sistema ocurrió durante la conversión de un número flotante de 64 bits a un número entero de 16 bits.  Otro de los casos de fallas en software que causó graves daños a la integridad de las personas, Therac-25. Era un aparato para el tratamiento del cáncer por emisión de rayos cuyos controles (de la cantidad de energía emitida) implementados en hardware fueron removidos y sólo se dejaron los de software que (obviamente) fallaron.  Error en un sistema de autenticación de tarjetas de crédito (1995) Los dos sistemas más grandes en ese país para la autorización de crédito (Barclay´s PQD y NatWest´s Streamline) fallaron el sábado 28 de octubre de 1995 imposibilitando que los comercios verificaran las tarjetas de crédito de sus clientes. En el caso de Barclay, más de 40% de las transacciones fallaron por un error en el sistema de software. Para NatWest, el problema fue ocasionado por una gran cola de llamadas, que obstruyo la comunicación por razones desconocidas, y que retraso la autentificación de tarjetas.  Software inapropiado llevó a un distribuidor de medicina a la quiebra. El 27 de agosto de 1998 la revista Der Spiege, en Alemania, informó de una demanda de 500 millones de dólares a SAP por parte del distribuidor de medicinas FoxMeyer Corp. Esta última acusó a SAP de venderle software inapropiado para sus necesidades, lo cual tuvo como resultado la quiebra de Fox Meyre. Analistas alemanes comentaron que no consideran que un ―software sea apropiado para llevar a la ruina a una compañía‖.
  11. 11. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor.  Error en sistema de cobranza de MCI (1996). En la edición de 29 de marzo de 1996 del Washington Post, MCI reporto que le devolverían aproximadamente 40 millones de dólares a sus clientes por un error de cobranza causada por un sistema de cómputo.  El error de cobranza fue descubierto por un reportero investigador de una estación local de televisión en Richmond, VA, quien encontró que fueron facturados por 4 minutos siendo que en realidad la llamada fue de 2.5 minutos, dando lugar a una profunda investigación. 1.3 FUTURO DEL SOFTWARE "El futuro del software es un desafío" Empecemos con una paradoja: el futuro del software comienza con el fin del software. Al menos, el fin del software tal y como lo conocemos. El software cliente/servidor tradicional es un modelo acabado, en particular para las organizaciones de TI que desean contribuir realmente al balance final. Para comprender el futuro del software empresarial, no hace falta ir muy lejos: la Web de consumidores. Al igual que los servicios Web para consumidores como Google, eBay y Amazon.com están sustituyendo al software estándar para consumidores, cada vez más aplicaciones empresariales están trasladándose a la Web. En 2005, se calculó que las ventas de SaaS (software como servicio) supusieron un 5% del total de las ventas de software empresarial. En 2011, se prevé que la cuota aumente hasta el 25%. Los cambios implican un desafío interesante para todos los involucrados en el desarrollo de software. Y el hardware, que durante muchos años ha sido el cuello de botella de los sistemas informáticos, crecerá hasta volverse de 50 a 100 veces más poderoso que en la actualidad. Esto representa una dificultad adicional, la de utilizar toda esa capacidad ociosa para convertirla en algo productivo, ya que no sería inteligente tomar sistemas que actualmente desperdician millones de ciclos de CPU y agregarle más capacidad
  12. 12. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. sin modificar el uso que reciben, para de ese modo desperdiciar más poder aún. Sin dudas, "se avecina un nuevo paradigma de software, y he aquí el mayor desafío". Cualquier especulación sobre el futuro del software merece, como mínimo, una revisión de los principales cambios a lo largo de su historia, como:  El paso del ordenador central a los sistemas cliente/servidor, que tuvo como consecuencia la transición desde sistemas existentes a sistemas empresariales estándar.  El auge de los ordenadores personales que desembocó en una productividad de los usuarios sin precedentes, así como una proliferación de islas de datos.  El auge de Internet, que condujo a una explosión de información y cambió el modo en que millones de personas trabajan, juegan y compran. También el aumento del uso de Internet y el acceso permanente a la red.  La aparición de estándares y tecnologías de servicios Web, como las arquitecturas multiusuario.  El paso hacia los enfoques de arquitectura orientada a servicios (SOA) por parte de los principales proveedores de software, lo que facilitaba la integración con los sistemas de servidor.  La aparición del modelo On-Demand, que suponía el cambio de un modelo en propiedad a un modelo ―en alquiler‖ y que liberaba a las empresas de los problemas y los gastos que conllevaba la propiedad. Salesforce.com es uno de los ejemplos más satisfactorios de este modelo con 55,400 clientes y más de 800 aplicaciones.
  13. 13. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.4 FUENTES PARA LA INFORMACIÓN DE VULNERABILIDADES En cualquier caso conviene indicar las fuentes más importantes de información asociada a vulnerabilidades de seguridad. No hay que olvidar que la mayor parte de esta información es de dominio público y que los desarrollos posteriores que puedan hacerse (bien a medida internamente o contratados) van a estar basados en las mismas fuentes:  El diccionario CVE, desarrollado por la corporación Mitre y disponible en http: //cve.mitre.org, que sirve como un elemento integrado de distintas fuentes y herramientas de seguridad. En esencia se trata de llamar a una vulnerabilidad siempre ―igual‖ (con el mismo identificador).  La base de datos de vulnerabilidades y alertas del centro de respuesta y coordinación ante emergencias de Internet, el CERT/CC, disponible en http:// www.kb.cert.org/vuls. Las bases de datos de vulnerabilidades son una herramienta clave a la hora de detectar posibles problemas de seguridad y prevenirlos  La famosa base de datos de Bugtrag (basada en gran parte en la información publicada en la lista de correo de seguridad del mismo nombre), adquirida por la empresa de seguridad Symantec, disponible en http: //www.securityfocus.com/bid. Es posiblemente la más completa (alrededor de 10.000 vulnerabilidades hasta la fecha) y sobre ésta Symantec ha desarrollado un servicio comercial.  La base de datos de Xforce, desarrollada por el fabricante de productos de seguridad Internet Security Systems (ISS), disponible en http://xforce.iss.net. Sirve de base tanto a los productos de seguridad de la compañía (herramientas de detección de intrusos, sistemas de análisis de vulnerabilidades...) como de servicios comerciales basados en ésta.  La base de datos ICAT publicada por el instituto de estándares del Gobierno norteamericano, el NIST, y disponible en http://icat.nist.gov. Se trata de una metabase de datos de información de vulnerabilidades, con más de 6.500 referencias a CVE y a las bases de datos arriba indicadas. Se
  14. 14. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. distribuye como un fichero de Microsoft Access (o en formato CSV) para su libre utilización. Dentro de estas fuentes de información podemos encontrar todo tipo de vulnerabilidades, desde ataques a servidores IIS de Microsoft a través de código Unicode hasta desbordamientos de búfer de Oracle Application Server, pasando por pequeñas vulnerabilidades de sistemas Windows como las existentes en la ayuda online de Windows. Como es lógico todas estas bases de datos se están actualizando continuamente, a medida que se publicitan nuevos fallos de seguridad. Las fuentes de información de vulnerabilidades de seguridad y, entre ellas, las bases de datos de vulnerabilidades, son una herramienta clave a la hora de detectar posibles problemas de seguridad y prevenirlos. Estas fuentes dan, si bien no en tiempo real, información de los principales problemas asociados a los principales fabricantes de software y hardware (y algunos menos conocidos), en muchos casos con sus posibles soluciones, y con información que permitirá determinar la premura con la que se debe arreglar la vulnerabilidad (en base a su impacto, al riesgo existente debido a la existencia o no de aprovechamientos de la misma...). 1.5 TENDENCIAS TECNICAS QUE AFECTAN A LAS ENTIDADES DEL SOFTWARE Tendencias que afectan a los sistemas de información Al considerar un Sistema de Información como un conjunto de normas y procesos generales de una determinada, se deben considerar algunos puntos negativos y positivos que afectan directamente al sistema: Actualizaciones Se refiere a que los sistemas de información de cualquier empresa, debe ser revisado periódicamente; no con una frecuencia continua, sino mas bien espaciada, se recomienda las revisiones bianuales (No se recomienda que se actualice en una empresa paulatinamente, por ejemplo el software, cuadros estadísticos, es recomendable dentro de un año cambiarlo, todo lo que es máquinas y software; porque si no realizaríamos esto, se cambiaría toda la estructura organizacional de la misma).
  15. 15. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Reestructuración Organizacional (Puede ser una reestructuración con los mismos puestos). Una reestructuración organizacional con cualquier empresa, implica cambios siempre en vista a buscar un mejor funcionamiento, evitar la burocracia, agilitar trámites o procesos, la reestructuración puede ser de varios tipos, así por ejemplo. Aumentar o disminuir departamentos, puestos, reestructuración de objetivos, etc. Siempre la reestructuración afecta a los sistemas de información de la empresa. Revisión y Valorización del escalafón (No es para bien si no también para mal) La revisión y la revalorización del escalafón se espera que afecte a favor de los sistemas de información de las empresas, si el efecto es contrario el auditor deberá emitir un informe del empleado a los empleados (Específicamente de departamentos), que están boicoteando la información de la empresa. Cambios en el flujo de Información (Datos para el sistema de Información) Se refiere al cambio de flujo de datos exclusivamente en el área informática, esto afecta directamente en sistema informático y por tanto al sistema de información. En lo que respecta a la Auditoría informática, el efecto puede ser positivo y negativo, dependiendo a los resultados obtenidos en cuanto al proceso de datos (menos seguridad, más seguridad, backup). Así por ejemplo: Se ha cambiado el flujo de información en el área contable, para generar los roles mensuales (De inicio del rol era realizado por la secretaria, la cual ingresaba las existencias, fallas, atrasos, etc.; determinando un monto a descontar. Un monto bruto y un salario final, esto pasaba a la contadora para que justifique especialmente multas, se rectificaba en algunos casos, y se mandaba a imprimir el rol. Se considera un nuevo flujo de información, en el cual se ingresan los datos a un sistema informático, y de acuerdo a los parámetros y normas de la empresa el sistema arroja un sueldo líquido a cobrarse, genera automáticamente el reporte, los cheques y el contador solo aprueba este reporte). (Un ejemplo es cuando existe migración de datos, la información migra o se cambia a otro sistema más sofisticado).
  16. 16. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.6 BREAKING AND PATCH Actualización Modificación que se aplica al software para corregir un problema o incorporar una función nueva. Realizar los pasos necesarios para aplicar actualizaciones a un sistema. El sistema se analiza y, a continuación, se descargan y se aplican las actualizaciones. Se denomina también patch. Actualización con firma Actualización que incluye una firma digital válida. Las actualizaciones firmadas ofrecen mayor seguridad que las que no disponen de firma. La firma digital de la actualización puede verificarse antes de aplicarla al sistema. Las firmas digitales válidas aseguran que las actualizaciones no se han modificado desde que éstas se aplicaron. Las actualizaciones firmadas se almacenan en archivos con formato Java Archive (JAR). Actualización de función Actualización que incorpora una nueva función en el sistema. Actualización sin firma Actualización que no incluye una firma digital. Parche (informática) En informática, un parche es una sección de código que se introduce a un programa. Dicho código puede tener varios objetivos; sustituir código erróneo, agregar funcionalidad al programa, aplicar una actualización, etc. Los parches suelen ser desarrollados por programadores ajenos al equipo de diseño inicial del proyecto (aunque no es algo necesariamente cierto). Como los parches se pueden aplicar tanto a un binario ejecutable como al código fuente, cualquier tipo de programa, incluso un sistema operativo, puede ser objeto de un parche. El origen del nombre probablemente se deba a la utilidad de Unix llamada patch creada por Larry Wall
  17. 17. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Tipos según su propósito Parches de depuración El objetivo de este tipo de parches es reparar bugs, o errores de programación que no fueron detectados a tiempo en su etapa de desarrollo. Se dice que un programa que se lanza con una alta probabilidad de contener este tipo de errores se le llama versión beta. Parches de seguridad Los parches de seguridad solucionan agujeros de seguridad y, siempre que es posible, no modifican la funcionalidad del programa. Los parches de seguridad son especialmente frecuentes en aplicaciones que utilizan la red. Parches de actualización Consiste en modificar un programa para convertirlo en un programa que utilice metodologías más nuevas. Por ejemplo, optimizar en tiempo cierto programa, utilizar algoritmos mejorados, añadir funcionalidades, eliminar secciones obsoletas de software, etc.
  18. 18. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.7 METAS DE LA SEGURIDAD ENFOCADAS AL SOFTWARE La Arquitectura de Seguridad de Información es la práctica de aplicar un método riguroso y comprensivo para describir una estructura actual y/o futura y el comportamiento de los procesos de seguridad de una organización, sistemas de seguridad de información y subunidades de personal y organizativas, para que se alineen con las metas comunes de la organización y la dirección estratégica. Aunque a menudo se asocie estrictamente con tecnologías para la seguridad de la información, se relaciona en términos más generales con la práctica de seguridad de optimización del negocio, donde dirige la arquitectura de seguridad del negocio, la realización de gestiones y también la arquitectura de procesos de seguridad. La Arquitectura de Seguridad de Información en la Empresa está convirtiéndose en una práctica habitual dentro de las instituciones financieras alrededor del mundo. El propósito fundamental de crear una arquitectura de seguridad de información en la empresa es para asegurar que la estrategia de negocio y la seguridad de las tecnologías de la información (TI) están alineadas. Como tal, la arquitectura de seguridad de la información en la empresa permite la trazabilidad desde la estrategia de negocio hasta la tecnología subyacente. Metas de la Seguridad Proporcionar estructura, coherencia y cohesión Debe permitir un alineamiento del negocio hacia la seguridad Principios inicio-fin definidos con estrategias de negocio Asegurar que todos los modelos e implementaciones pueden ser trazados hacia atrás hasta la estrategia de negocio, específicamente requerimientos de negocio y principios clave Proveer abstracción para que factores complicados puedan ser eliminados y reinstalados en niveles de detalle diferente sólo cuando sean requeridos Establecer un lenguaje común para la seguridad de la información dentro de la organización
  19. 19. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Protección del software: Los programas de ordenador actualmente están expresamente excluidos de la protección a través de patentes en el artículo 4 de la Ley española de patentes 11/1986. La protección que se aplica con carácter general a este tipo de resultado de investigación será la que le otorga la Ley de Propiedad Intelectual. Concretamente el título VII se dedica los programas de ordenador. Una característica principal de este tipo de protección consiste en que los derechos sobre la obra (en este caso programa de ordenador) se generan automáticamente desde el momento en que se ha creado el programa. Esto significa: Que no hace falta inscribir el programa en ningún tipo de registro para que nazcan derechos de exclusiva sobre el mismo. Que se puede publicar cualquier referencia al programa en revistas especializadas haciendo referencia a los derechos de la UPV y a los autores. En ningún caso es conveniente desvelar el código fuente a terceros.
  20. 20. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.7.1 PREVENCION Un sistema de prevención/protección para defenderse de las intrusiones y no sólo para reconocerlas e informar sobre ellas, como hacen la mayoría de los IDS. El software de prevención contempla:  Gestión de prevención de riesgos a nivel de centros de trabajo y trabajadores.  Gestión de subcontratas.  Histórico de evaluaciones de riesgos realizadas.  Composición de equipos de emergencia.  Histórico de cursos de prevención y seguridad realizados.  Estadísticas de siniestralidad.  Análisis de accidentes.  Control de la Formación en materia de prevención.  Gestión de Equipos de protección individual entregados al personal.  La efectividad de la prevención general tiene una doble vertiente:  La prevención general positiva: es aquélla que va encaminada a restablecer la confianza del resto de la sociedad en el sistema.  La prevención general negativa: es aquélla que va encaminada a disuadir a los miembros de la sociedad que no han delinquido, pero que se pueden ver tentados a hacerlo, a través de la amenaza de la pena.
  21. 21. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.7.2 AUDITABLE Y TRAZABLE Auditable: es tanto la solución tecnológica, como sus componentes de hardware y/o software debe ser abierta e íntegramente auditable antes y posteriormente a su uso. Consideramos que también debe ser auditable durante su uso y no restringirlo únicamente a las etapas del antes o el después. Auditabilidad de bases de datos El acceso global a la Información que trajo el advenimiento de la Tecnología de Internet, ha hecho que el problema de Seguridad de la Información se acrecentara de manera alarmante. En función de esta realidad, se deben extremar los requerimientos de Seguridad en todos los elementos que configuren el Sistema de Información. El Sistema de Base de Datos que decidamos utilizar en una aplicación determinada, deberá ser valorado fundamentalmente por la Seguridad que brinda. Existen, actualmente, criterios de Evaluación de Seguridad, con validez internacional, que permiten clasificar cada Sistema de Base de Datos en distintas categorías de acuerdo a la valoración, que de él hagan, grupos de expertos en el tema. Asimismo deberá estudiarse con sumo cuidado las facilidades que el Sistema de Base de Datos ofrezca para su auditabilidad, qué tipo de información generan, con qué facilidad se pueden definir opciones, etc. Un aspecto que merecerá también nuestra atención será el control de acceso que posea, la posibilidad de definición de perfiles y grupos de perfiles. Si el procesamiento es distribuido será objeto de nuestra atención el procesamiento y replicación segura, cómo así también todo mecanismo que garantice la integridad de los Datos en forma automática. La propiedad del resultado de una medida o del valor de un estándar donde este pueda estar relacionado con referencias especificadas, usualmente estándares nacionales o internacionales, a través de una cadena continúa de comparaciones todas con incertidumbres especificadas. En la actualidad existe una propuesta de formato estándar para contener, transmitir y compartir la trazabilidad. Son los archivos ILE de trazabilidad encapsulada. Estos archivos pueden contener la historia completa de cualquier producto, de acuerdo con las restricciones formales de cualquiera de las legislaciones vigentes en cuanto a trazabilidad y seguridad alimentaria. Estos archivos de trazabilidad encapsulada se pueden ver y editar de manera gratuita
  22. 22. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. con el software freeware ilEAN Writer 2.0 e ilEAN Reader 2.0... Además de con una larga lista de sistemas estándar de los más importantes fabricantes de software. Esta consiste en la capacidad para reconstruir la historia, recorrido o aplicación de un determinado producto, identificando: Origen de sus componentes. Historia de los procesos aplicados al producto. Distribución y localización después de su entrega. Al contar con esta información es posible entregar productos definidos a mercados específicos, con la garantía de conocer con certeza el origen y la historia del mismo. El concepto de trazabilidad está asociado, sin duda, a procesos productivos modernos y productos de mayor calidad y valor para el cliente final. La trazabilidad es aplicada por razones relacionadas con mejoras de negocio las que justifican su presencia: mayor eficiencia en procesos productivos, menores costes ante fallos, mejor servicio a clientes, etc. En este ámbito cabe mencionar sectores como los de automoción, aeronáutica, distribución logística, electrónica de consumo, etc., Un sistema de trazabilidad es un conjunto de disciplinas de diferente naturaleza que, coordinadas entre si, nos permiten obtener el seguimiento de los productos a lo largo de cualquier cadena del tipo que sea. Si entendemos como trazabilidad a: "un conjunto de procedimientos preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y la trayectoria de un producto, o lote de productos a lo largo de la cadena de suministros, en un momento dado y a través de unas herramientas determinadas", un sistema de trazabilidad deberá de estar compuesto por: 1. Sistemas de identificación 1. Un sistema de identificación del producto unitario 2. Un sistema de identificación del embalajes o cajas 3. Un sistema de identificación de bultos o palets 2. Sistemas para la captura de datos 1. Para las materias primas 2. Para la captura de datos en planta 3. Para la captura de datos en almacén 3. Software para la gestión de datos 1. Capaz de imprimir etiquetas
  23. 23. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 2. Capaz de grabar chips RFID 3. Capaz de almacenar los datos capturados 4. Capaz de intercambiar datos con los sistemas de gestión empresariales Cuando un sistema de trazabilidad está soportado sobre una infraestructura, basa en las tecnologías de la información y las comunicaciones (TIC), la trazabilidad puede brindar importantes utilidades a los diferentes actores de una cadena de valor como ser: gestión eficiente de la logística y del suministro y aumento de la productividad. El Software Trazabilidad es el aplicativo de software capaz de registrar la traza de los productos a lo largo de la cadena de suministro interna o externa,[1] empaquetarlos en un formato legible y prepararlos para poder ser gestionados por el propio software o como respuesta a una solicitud de servicio. El desarrollo de las soluciones para el control de la trazabilidad ha venido desarrollándose parejo a: 1. Los esfuerzos de las administraciones para controlar la calidad del producto que llega al usuario final para crear las legislaciones pertinentes. 2. Las necesidades empresariales para obtener información en tiempo real con el fin de fidelizar a los clientes. 3. Al desarrollo tecnológico en plataformas informáticas y tecnología para la identificación de productos y obtener la información en la medida de sus movimientos. Parece curioso que a medida que se han ido generando exigencias y normativas por parte de las administraciones para proteger al consumidor final, falta la figura de un organismo regulador general, o de un sistema globalizado para determinar que aspectos debe tener un registro de trazabilidad. Así, se han ido creando normativas y legislaciones sobre trazabilidad por organismos de la EU. Para un software de trazabilidad, la dificultad radica en que no existe un patrón de empaquetamiento e intercambio de datos entre ninguno de ellos, por lo que las exigencias de dichas normativas son diferentes entre sí, lo que provoca que la fabricación de un producto deba cumplir normativas diferentes dependiendo del país al que vaya destinado.
  24. 24. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.7.3 MONITOREO El Monitoreo es el proceso continuo y sistemático mediante el cual verificamos la eficiencia y la eficacia de un proyecto mediante la identificación de sus logros y debilidades y en consecuencia, recomendamos medidas correctivas para optimizar los resultados esperados del proyecto. Es, por tanto, condición para la rectificación o profundización de la ejecución y para asegurar la retroalimentación entre los objetivos y presupuestos teóricos y las lecciones aprendidas a partir de la práctica. Asimismo, es el responsable de preparar y aportar la información que hace posible sistematizar resultados y procesos y, por tanto, es un insumo básico para la Evaluación. Monitoreo de Sistemas de Seguridad Este sistema permite el monitoreo desde cualquier lugar usando una simple computadora con acceso a internet. Instalación, suministro, sistemas de c.c.t.v., sensores de humo, depende de que esté siempre conectado a la red, y si no es así la seguridad de su casa o su negocio puede estar en peligro. Nuestro sistema de monitoreo le permite conocer cuando su sistema de vigilancia se encuentra no disponible y le permite tomar acciones de emergencia, ya sea ponerse en contacto con su personal de vigilancia, centrales de monitoreo o con su proveedor de internet. Cómo monitoreo servidores de bases de datos detrás de un firewall Use su lenguaje de programación web preferido (por ejemplo, ASP, JSP, PHP, ColdFusion, Perl) para escribir un script para conectarse al servidor de base de datos y realizar una simple consulta. Si la consulta se ejecuta exitosamente, el script retorna algo como "Servidor de base de datos está ARRIBA". Finalmente, vaya a Monitoreo -> Agregar un Test y seleccione monitorear un sitio web. Ingrese la URL del script y especifique la palabra clave requerida "Servidor de base de datos está ARRIBA". Si nuestro sistema no puede hallar la palabra clave en la página, le notificará y sabrá que el servidor de base de datos está caído.
  25. 25. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Monitoreo de Dominios El monitoreo de URLs le ayuda a monitorear la disponibilidad de su sitio Web (o sitios Web, si tiene más de uno) y a verificar si están sirviendo páginas en tiempo real. Algunas tipos de monitoreo se encuentran: Monitoreo de URLs, directorios virtuales, coincidencia de contenido, servidores y aplicaciones Web. El Software de Excelencia para Vigilancia y Monitoreo en Internet Spector Pro es el software más vendido en el mundo para monitorear y grabar cada detalle de la PC o de la actividad en Internet, para tu oficina o tu casa. Sistema Avanzado de Advertencia. Este software Aparte de monitorear y grabar, cuenta con un Sistema Avanzado de Advertencia que te informará cuando una PC monitoreada ha sido utilizada de manera no apropiada. A través del uso de palabras y frases claves que tú especifiques, Spector Pro estará "en alerta", enviándote por e-mail inmediata y detalladamente el reporte de cuándo, dónde y cómo una palabra específica fue usada – cada vez que se escriba, que aparezca en la PC, en un sitio Web, en el Chat/mensaje instantáneo o en un e-mail. La alerta se enviará a tu oficina, casa, celular o a donde tú quieras. 1.7.4 PRIVACIDAD Y CONFIDENCIALIDAD La privacidad puede ser definida como el ámbito de la vida personal de un individuo que se desarrolla en un espacio reservado y debe mantenerse confidencial. Como cuidar nuestra privacidad Instalar un cortafuegos ayudara mucho evitando que un sujeto pueda entrar a nuestra computadora o bien que usen un troyano y quizá pueda robar información valiosa como tarjetas de crédito o claves, etc. Un antivirus que en lo posible también detecte spyware servirá mucho para evitar que nos manden troyanos o spyware que envie información confidencial aunque si tenemos un firewall es probable que este bloquee el troyano/spyware al tratar de conectarse.
  26. 26. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Un antispyware que ayuda a eliminar el spyware que entro a través de distintas páginas. Usar un explorador alternativo a Internet Explorer o bien mantenerlo actualizado completamente. Mantener actualizado nuestro sistema operativo es importante para evitar que a través de un fallo del mismo alguien se pueda apoderar de nuestra computadora y posteriormente de algo valioso. No entrar en páginas web sospechosas de robar contraseñas o de mandar virus/spyware al PC. Cuando envíen un correo electrónico a varios contactos utilicen el CCO 'correo oculto' para no mostrar los contactos y parezcan como privados La confiabilidad de software significa que un programa particular debe de seguir funcionando en la presencia de errores. Los errores pueden ser relacionados al diseño, a la implementación, a la programación, o el uso de errores. Así como los sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de errores. Como mencionamos, es increíblemente difícil demonstrar que un sistema sea seguro. Ross Anderson dice que la seguridad de computación es como programar la computadora del Satán. Software seguro debe de funcionar abajo de un ataque. Aunque casi todos los software tengan errores, la mayoría de los errores nunca serán revelados debajo de circunstancias normales. Un atacante busca esta debilidad para atacar un sistema. La Confidencialidad es la propiedad de un documento o mensaje que únicamente está autorizado para ser leído o entendido por algunas personas o entidades.Se dice que un documento o mensaje es confidencial si éste sólo está autorizado a ser leído o entendido por un destinatario designado. CONFIDENCIALIDAD Compromiso de no dar información sobre un hecho mas que a la persona involucrada y a quienes ella autorice. Los resultados de análisis clínicos y en especial el de VIH deben ser confidenciales. En la práctica muchos doctores, incluyendo los de instancias públicas, comunican un resultado positivo a las autoridades de quien depende la persona afectada, violando con ello la confidencialidad y provocando en muchos casos el despido o la no aceptación en un nuevo trabajo de la persona seropositiva. La confidencialidad se refiere a que la información solo puede ser conocida por individuos autorizados. Existen infinidad de posibles ataques contra la privacidad, especialmente en la comunicación de los datos. La transmisión a través de un
  27. 27. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. medio presenta múltiples oportunidades para ser interceptada y copiada: las líneas "pinchadas" la intercepción o recepción electromagnética no autorizada o la simple intrusión directa en los equipos donde la información está físicamente almacenada. 1.7.5 SEGURIDAD MULTINIVELES La seguridad multinivel dispara el mercado antivirus y las aplicaciones de software antivirus están experimentando un notable crecimiento como consecuencia del gran incremento y la compleja naturaleza de la actividad de intrusión de los virus, causantes de la infección masiva de sistemas y un importante impacto económico. Con las mejoras que brindan los nuevos sistemas de protección multinivel en su esfuerzo por combatir todos los perjuicios comunes más extendidos, las grandes compañías en particular, están aumentando su inversión destinada a la erradicación de los fallos de seguridad. El cambio gradual en la protección multinivel contra los virus en el mercado empresarial, ofrece oportunidades a un amplio abanico de vendedores de sistemas de seguridad. La seguridad multinivel (MLS) proviene de los sistemas de alta seguridad utilizados en Defensa, donde la información es manejada de acuerdo a su nivel de sensibilidad y a los permisos que tiene la persona que desea acceder a ella, es también actualmente, una de las mayores preocupaciones en el entorno empresarial. La seguridad multinivel tiene los siguientes aspectos diferenciales: La suite protege la seguridad en todo momento, incluso antes del arranque del sistema operativo. Posibilidad de proteger la información mediante cifrado Compatibilidad con DNI electrónico y Smartcards como tarjeta de autenticación Control de los dispositivos de almacenamiento que pueden conectarse al PC (memorias USB, MP3, etc.) Control de las aplicaciones que pueden ser ejecutadas Nivel de seguridad adaptable a las necesidades de la empresa, con gestión centralizada y políticas definibles en base a perfil de usuario, PC y dispositivos concretos
  28. 28. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. La seguridad de software aplica los principios de la seguridad de información al desarrollo de software. La seguridad de información se refiere a la seguridad de información comúnmente como la protección de sistemas de información contra el acceso desautorizado o la modificación de información, si esta en una fase de almacenamiento, procesamiento o tránsito. También la protege contra la negación de servicios a usuarios desautorizados y la provisión de servicio a usuarios desautorizados, incluyendo las medidas necesarias para detectar, documentar, y contrarear tales amenazas. 1.7.6 ANONIMATO Anónimo proviene del griego anonymos "sin nombre", compuesto del prefijo negativo an- "sin" y onoma "nombre". El anonimato es el estado de una persona siendo anónima, es decir, que la identidad de dicha persona es desconocida. El anonimato es la condición de la persona que oculta su nombre o su personalidad, simplemente porque no se lo ha identificado o porque la persona no puede o no quiere revelar su identidad. El nombre de Peer-to-Peer anónimo puede entenderse como un nombre equivocado. Esto es debido a su diseño, un nodo de la red debe tener pseudónimo desde que tiene que tener una "dirección" para poder ser alcanzado por otro nodo igual para intercambiar datos. Sin embargo, normalmente esta dirección, especialmente en redes anónimas, no contiene ninguna información que pueda permitir la identificación. Por tanto, un usuario es casi pero no completamente anónimo. En las redes amigo-a-amigo, sólo tus amigos pueden saber que tu dirección está siendo usada para intercambiar ficheros. La navegación Web, algo que suele verse como una actividad anónima, temporal e irrelevante. Pero cuando navegamos, es frecuente que vayamos dejando muchos rastros respecto a lo que hacemos. Quizá a algunos no les importe todo esto, a otros sí que les preocupará.
  29. 29. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.7.7 AUTENTICACIÓN Autenticación o autentificación es el acto de establecimiento o confirmación de algo (o alguien) como auténtico, es decir que reclama hecho por, o sobre la cosa son verdadero. La autenticación de un objeto puede significar (pensar) la confirmación de su procedencia, mientras que la autenticación de una persona a menudo consiste en verificar su identidad. La autenticación depende de uno o varios factores. Autenticación o autentificación, en términos de seguridad de redes de datos, se puede considerar uno de los tres pasos fundamentales (AAA). Cada uno de ellos es, de forma ordenada: Autenticación En la seguridad de ordenador, la autenticación es el proceso de intento de verificar la identidad digital del remitente de una comunicación como una petición para conectarse. El remitente siendo autenticado puede ser una persona que usa un ordenador, un ordenador por sí mismo o un programa del ordenador. En un web de confianza, "autenticación" es un modo de asegurar que los usuarios son quién ellos dicen que ellos son - que el usuario que intenta realizar funciones en un sistema es de hecho el usuario que tiene la autorización para hacer así. Autorización Proceso por el cual la red de datos autoriza al usuario identificado a acceder a determinados recursos de la misma. Auditoría Mediante la cual la red o sistemas asociados registran todos y cada uno de los accesos a los recursos que realiza el usuario autorizados o no. El problema de la autorización a menudo, es idéntico a la de autenticación; muchos protocolos de seguridad extensamente adoptados estándar, regulaciones obligatorias, y hasta estatutos están basados en esta asunción. Sin embargo, el uso más exacto describe la autenticación como el proceso de verificar la identidad de una persona, mientras la autorización es el proceso de verificación que una persona conocida tiene la autoridad para realizar una cierta operación. La autenticación, por lo tanto, debe preceder la autorización. Para distinguir la autenticación de la autorización de término estrechamente relacionada, existen unas notaciones de taquigrafía que son: A1 para la autenticación y A2 para la autorización que de vez en cuando son usadas, también existen los términos AuthN y AuthZ que son usados en algunas comunidades.
  30. 30. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.7.8 INTEGRIDAD El término integridad de datos se refiere a la corrección y completitud de los datos en una base de datos. Cuando los contenidos se modifican con sentencias INSERT, DELETE o UPDATE, la integridad de los datos almacenados puede perderse de muchas maneras diferentes. Pueden añadirse datos no válidos a la base de datos, tales como un pedido que especifica un producto no existente. Pueden modificarse datos existentes tomando un valor incorrecto, como por ejemplo si se reasigna un vendedor a una oficina no existente. Los cambios en la base de datos pueden perderse debido a un error del sistema o a un fallo en el suministro de energía. Los cambios pueden ser aplicados parcialmente, como por ejemplo si se añade un pedido de un producto sin ajustar la cantidad disponible para vender. Una de las funciones importantes de un DBMS relacional es preservar la integridad de sus datos almacenados en la mayor medida posible. Tipos de restricciones de integridad Datos Requeridos: establece que una columna tenga un valor no NULL. Se define efectuando la declaración de una columna es NOT NULL cuando la tabla que contiene las columnas se crea por primera vez, como parte de la sentencia CREATE TABLE. Chequeo de Validez: cuando se crea una tabla cada columna tiene un tipo de datos y el DBMS asegura que solamente los datos del tipo especificado sean ingresados en la tabla. Integridad de entidad: establece que la clave primaria de una tabla debe tener un valor único para cada fila de la tabla; si no, la base de datos perderá su integridad. Se especifica en la sentencia CREATE TABLE. El DBMS comprueba automáticamente la unicidad del valor de la clave primaria con cada sentencia INSERT Y UPDATE. Un intento de insertar o actualizar una fila con un valor de la clave primaria ya existente fallará. Integridad referencial: asegura la integridad entre las claves ajenas y primarias (relaciones padre/hijo). Existen cuatro actualizaciones de la base de datos que pueden corromper la integridad referencial:
  31. 31. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. La inserción de una fila hijo se produce cuando no coincide la clave ajena con la clave primaria del padre. La actualización en la clave ajena de la fila hijo, donde se produce una actualización en la clave ajena de la fila hijo con una sentencia UPDATE y la misma no coincide con ninguna clave primaria. La supresión de una fila padre, con la que, si una fila padre -que tiene uno o más hijos- se suprime, las filas hijos quedarán huérfanas. La actualización de la clave primaria de una fila padre, donde si en una fila padre, que tiene uno o más hijos se actualiza su clave primaria, las filas hijos quedarán huérfanas. 1.8 CONOCER EL ENEMIGO Medias de seguridad a tener en cuenta por las empresas: Establecer una política adecuada en la que deben figurar cuáles son los puntos críticos de la red corporativa y las medidas que se van a tomar para protegerlos. Instalar una solución de seguridad eficiente tanto en los equipos de los trabajadores como en los servidores. Las contraseñas de acceso a los equipos deber ser seguras. Contar con programas y soluciones de seguridad actualizada y protección en sus equipos portátiles y en sus redes inalámbricas. Conocer quién accede a la información. Realizar auditorías para saber qué ha pasado y cuándo y así poder responder a las necesidades legales. Establecer distintos perfiles de acceso a intranets y extranet. Precauciones de los usuarios: Mantener actualizados los programas. No abrir corres que procedan de fuentes desconocidas. No seguir ningún vínculo que llegue por correo o mensajería instantánea. No ejecutar archivos que procedan de fuentes desconocidas. No descargarse por P2P archivos sospechosos. No conectar dispositivos móviles como llaves USB o PDA sin haberse asegurado antes de que no están infectados. Bloquear el equipo cuando no se esté en el puesto de trabajo.
  32. 32. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 1.9 META DE PROYECTO DE SOFTWARE Las metas y los objetivos proporcionan la dirección uniforme en un proyecto y aseguran una visión constante a través del cuerpo de tenedores de apuestas. Idealmente, las metas y los objetivos sirven como referencia constante para la toma de decisión relacionada con el proyecto. Uso Las metas y los objetivos son público los elementos de información disponibles que se comparten normalmente o a través de la documentación de la reunión o mientras que la información introductoria en los planes del proyecto y el otro proyecto apoya la documentación. Las metas y los objetivos se utilizan para unificar la visión del equipo y la organización con respecto a cuál debe el proyecto lograr y el acercamiento general a lograr esa meta. Pueden ser fijadas en una localización altamente visible para asegurarse de que están fácilmente disponibles para todos los miembros del equipo. El teórico Peter Drucker de la gerencia sugiere que las metas de un negocio conduzcan sus objetivos específicos del trabajo, y que esos objetivos necesitan ser delineados claramente para asegurar niveles más altos del funcionamiento. Contenido Las metas y los objetivos deben indicar claramente el intento de la organización, el proyecto, y las tareas o el esfuerzo bajo consideración—y los objetivos de trabajadores individuales en la organización deben ser complementarios en servir la meta. Las declaraciones de la meta se fijan en un alto nivel, describiendo lo que espera la organización alcanzar. Se atan de cerca a las declaraciones de la visión en que las metas son descripciones de lo que espera la organización lograr. Las metas se pueden construir en el nivel de organización (―hacer un innovador reconocido del software cambiando cómo se diseña y se apoya el software‖) o en un más detallado, proyecto llano (―proveer de la cumbre el software innovador de la logística que apoya su seguir y mantenimiento del inventario‖). En cualquier caso, las metas son las declaraciones generales que son apoyadas por objetivos. Los objetivos sirven la meta. Proporcionan claramente, dirección inequívoca en cómo las metas serán resueltas. Idealmente, deben estar suficientemente claros que permiten autodominio y self-monitoring de los miembros del equipo a quienes se dan, que significa que cada uno objetivo debe tener cierta forma métrica de medida que refleje los valores de la organización s. Si la meta es proporcionar
  33. 33. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. software innovador de la logística a la cumbre de la ayuda, los objetivos pudieron incluir el siguiente: • Para proporcionar un sistema que proporciona la información en tiempo real con respecto la localización, el almacenaje, y al envejecimiento materiales; • Para proporcionar un sistema que responde con la dirección (detallada, paso a paso) modificada para requisitos particulares en las fuentes alternativas para el material que está fuera de acción o en fuente baja. Los términos llegan a ser importantes en establecer metas y objetivos. La asunción que cualquier cosa que puede ser malinterpretada será malinterpretada es una asunción justa y razonable. Una visión de la persona s ―de la fuente baja‖ pudo ser diferente que otros. El esfuerzo en objetivos del edificio es reducir al mínimo la ambigüedad tanto como es posible y razonable. Acercamientos Una línea blurry existe entre las metas y los objetivos y entre los objetivos y los requisitos. Como tal, una declaración general de la meta ―de la persona‖ s se pudo detallar suficientemente para ser un objetivo para algún otro (particularmente alguien en un nivel más alto en la organización). Porque los objetivos se deben rendir tan claramente como sea posible, el esfuerzo de construir en el nivel apropiado del detalle genera a veces los requisitos nacientes. Para construir metas y objetivos mejores, las metas deben tratar el estado futuro del proyecto, entregable, o de la organización. Los objetivos deben indicar cómo el equipo y el proyecto trabajarán en esa dirección. En algunas organizaciones, la declaración objetiva se liga siempre a las limitaciones del momento específico y del coste. Consideraciones Porque las metas y los objetivos proporcionan la dirección, deben ser declaraciones públicas. En reuniones y en instalaciones del proyecto, los objetivos y las metas de un proyecto se deben fijar claramente para asegurar familiaridad del equipo con la documentación. Tal franqueza sobre las metas y los objetivos puede imposibilitar algo de las riñas inherentes a veces evidentes cuando los miembros del equipo de proyecto se parecen trabajar en los propósitos cruzados.
  34. 34. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Unidad II Administración de los riesgos en la seguridad del software Objetivo: El alumno conocerá e identificará los riesgos que se tienen al poner en práctica la seguridad del software, así como los mecanismos para la evaluación del desarrollo de sistemas seguros. Contenido: 2.1 Descripción de la administración de los riesgos en la Seguridad del Software 2.2 Administración de los riesgos en la seguridad del Software en la práctica 2.2.1 Pruebas de Caja Negra 2.2.2 Equipo Rojo 2.3 Criterios Comunes
  35. 35. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 2.1 DESCRIPCIÒN DE LA ADMINISTRACIÒN DE LOS RIESGOS EN LA SEGURIDAD DEL SOFTWARE La administración de riesgo es un proceso de identificación y análisis de riesgos y de creación de un plan para administrarlos. Un riesgo de seguridad se define como la pérdida esperada debida o como consecuencia de amenazas anticipadas por vulnerabilidades del sistema y la fuerza y determinación de los agentes amenazantes correspondientes. Identificación de los riesgos de seguridad La identificación de los riesgos de seguridad es el primer paso en la evaluación de la seguridad de la organización. Para administrar el riesgo de seguridad de forma eficaz, debe establecerse claramente de modo que el equipo del proyecto llegue a un consenso y se disponga a analizar las consecuencias y crear un plan de acción para solucionar el riesgo. Aunque el ámbito del riesgo de seguridad está limitado a la tecnología que el equipo del proyecto trata de proteger, la atención del equipo debe ser lo suficientemente amplia como para abordar todas las fuentes de riesgos de seguridad, incluido la tecnología, proceso, entorno y personas. Actividades de identificación de riesgos Durante el paso de identificación de riesgos de seguridad, el equipo deberá indicar o enumerar de forma precisa los problemas de seguridad mediante la declaración concisa de los riesgos a los que se enfrenta la organización. Resulta útil organizar una serie de talleres o sesiones de brainstorming del equipo de seguridad con el objetivo de identificar los riesgos asociados con una nueva situación. Debido al cambio constante de la tecnología y los entornos, es importante que la identificación de riesgos de seguridad no se considere una actividad aislada, sino que el proceso debe repetirse periódicamente durante el ciclo de vida de las operaciones de la organización. Enfoque estructurado El uso de un enfoque estructurado con relación a la administración de riesgos de seguridad es fundamental porque permite que todos los miembros del equipo utilicen un mecanismo sólido para tratar los problemas de seguridad. La clasificación de las amenazas durante este paso es una forma útil de proporcionar un enfoque sólido, reproducible y perceptible.
  36. 36. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Desarrollo de las soluciones a los riesgos de seguridad El desarrollo de las soluciones a los riesgos de seguridad es el proceso por el que se toman los planes que se han creado en la fase de evaluación y se utilizan para generar una nueva estrategia de seguridad que incluya administración de configuración y revisiones, supervisión y auditoría del sistema, y directivas y procedimientos operativos. Dado que se desarrollan diversas contramedidas, es importante realizar un seguimiento e informe minuciosos de este proceso. Declaración de riesgos de seguridad Una declaración de riesgos de seguridad es una expresión del lenguaje normal de la relación causal entre el estado de seguridad existente de la organización y un resultado posible que no se ha realizado. La primera parte de la declaración de riesgos de seguridad se denomina "la condición", en la que se proporciona la descripción de un estado existente o amenaza potencial que el equipo considera que puede causar algún daño. La segunda parte de la declaración de riesgos se denomina "consecuencia", y en ella se describe la pérdida no deseada de confidencialidad, integridad y disponibilidad de un activo. Las dos declaraciones están unidas por un término como "entonces" o "puede resultar en" que implica una relación no confiable (es decir, menos del 100%) o causal. Modelo de proceso de seguridad El modelo de proceso MSF se puede usar para desarrollar aplicaciones de software e implementar tecnología de infraestructura. Este modelo sigue un ciclo iterativo diseñado para abordar cambios de los requisitos de proceso en ciclos de desarrollo cortos y versiones incrementales de la solución. Esto es posible gracias a la administración de riesgo continua y los ciclos de pruebas. Marco de administración de riesgos de seguridad Descripción general El marco utiliza el modelo de proceso MSF y describe una secuencia de alto nivel de actividades para la creación e implementación de las soluciones de seguridad de TI. En lugar de recomendar una determinada serie de procedimientos, el marco es lo suficientemente flexible como para incorporar una amplia gama de procesos
  37. 37. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. de TI. El modelo de proceso abarca el ciclo de vida de una solución desde el inicio del proyecto hasta la implementación activa. Figura 1
  38. 38. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 2.2 ADMINISTRACIÒN DE LOS RIESGOS EN LA SEGURIDAD DEL SOFTWARE EN LA PRÀCTICA Prácticas de administración de riesgos de seguridad y de marco de seguridad Mientras se ejecuta el plan de seguridad, se llevan a cabo dos tipos de actividades de administración de riesgo durante el ciclo de vida del proyecto. La primera es administrar el riesgo inherente al propio proyecto y la segunda es administrar el riesgo asociado a los componentes de seguridad. Los riesgos del proyecto se evalúan sólo durante el ciclo de vida del proyecto, mientras que los riesgos de seguridad se deben evaluar durante el ciclo de vida completo de la solución o el sistema. La disciplina de administración de riesgo MSF sirve como base para la administración de riesgos de las evaluaciones de los proyectos y de la seguridad. La seguridad del sistema informático se debe realizar de forma preventiva y continua para garantizar la seguridad de los activos de información y supervisar nuevas amenazas y vulnerabilidades. Siempre que se agreguen funcionalidades nuevas a la infraestructura de tecnología de la organización deberá tomarse en cuenta la seguridad de la información. Además, es posible que algunos procesos y procedimientos empresariales deban alterarse para operar en el entorno modificado y proporcionar protección a los activos de información nuevos. Los nueve pasos de la Disciplina de administración de riesgos de seguridad en la práctica son: 1. Evaluación y valoración del activo 2. Identificación de los riesgos de seguridad 3. Análisis y ordenación según prioridad de los riesgos de seguridad 4. Seguimiento, planeamiento y programación de los riesgos de seguridad desarrollo e implementación 5. Desarrollo de las soluciones de seguridad 6. Pruebas de las soluciones de seguridad 7. Obtención de información sobre seguridad Operación 8. Reevaluación de los riesgos de seguridad y los activos nuevos y cambiados 9. Estabilización e implementación de contramedidas nuevas o cambiadas
  39. 39. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Análisis de los riesgos de seguridad El análisis de los riesgos de seguridad se utiliza para examinar los posibles ataques, herramientas, métodos y técnicas que permiten explotar una posible vulnerabilidad. Se trata de un método de identificación de riesgos y evaluación de posibles daños que podrían producirse para justificar las salvaguardas de seguridad. Un análisis de este tipo presenta tres objetivos principales: identificar riesgos, cuantificar la repercusión de posibles amenazas y proporcionar un balance económico entre el efecto del riesgo y el coste de la contramedida. Se recopila información para calcular el nivel de riesgo de modo que el equipo pueda tomar decisiones razonables y centrar todos los esfuerzos en la solución de los riesgos de seguridad. Este análisis se utiliza posteriormente para dar prioridad a los riesgos de seguridad y permitir a la organización asignar recursos con los que se solucionarán los problemas de seguridad más importantes. Un análisis de riesgo permite integrar los objetivos del programa de seguridad en los objetivos y requisitos comerciales de la compañía. Cuanto más coordinados resulten los objetivos comerciales y los de seguridad, más fácil será cumplirlos. Etapa: Pruebas La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica: Verificar la interacción de componentes. Verificar la integración adecuada de los componentes. Verificar que todos los requisitos se han implementado correctamente. Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software al cliente. Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida: podemos probar la funcionalidad de los primeros prototipos; probar la estabilidad, cobertura y rendimiento de la arquitectura; probar el producto final, etc.
  40. 40. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Plan de Pruebas Un plan de pruebas está constituido por un conjunto de pruebas. Cada prueba debe: dejar claro qué tipo de propiedades se quieren probar (corrección, robustez, fiabilidad, amigabilidad, ...) dejar claro cómo se mide el resultado especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta) definir cual es el resultado que se espera (identificación, tolerancia, ...) ¿Cómo se decide que el resultado es acorde con lo esperado? La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces. La prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software. 2.2.1 PRUEBA DE CAJA NEGRA Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa. Los casos de prueba de la caja negra pretende demostrar que: Las funciones del software son operativas. La entrada se acepta de forma adecuada. Se produce una salida correcta, y La integridad de la información externa se mantiene. Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa. La prueba de la caja negra intenta encontrar errores de las siguientes categorías: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas.
  41. 41. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Errores de rendimiento. Errores de inicialización y de terminación. Los casos de prueba deben satisfacer los siguientes criterios: Reducir, en un coeficiente que es mayor que uno, el número de casos de prueba adicionales. Que digan algo sobre la presencia o ausencia de clases de errores. Métodos de prueba de caja negra Algunos de los métodos empleados en las pruebas de caja negra son los siguientes: Métodos de prueba basados en grafos: en este método se debe entender los objetos (objetos de datos, objetos de programa tales como módulos o colecciones de sentencias del lenguaje de programación) que se modelan en el software y las relaciones que conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas. En este método: 1. Se crea un grafo de objetos importantes y sus relaciones. 2. Se diseña una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir errores. Describe un número de modelados para pruebas de comportamiento que pueden hacer uso de los grafos:  Modelado del flujo de transacción. Los nodos representan los pasos de alguna transacción (por ejemplo, los pasos necesarios para una reserva en una línea aérea usando un servicio en línea), y los enlaces representan las conexiones lógicas entre los pasos (por ejemplo, vuelo, información, entrada es seguida de validación /disponibilidad, procesamiento).  Modelado de estado finito. Los nodos representan diferentes estados del software observables por el usuario (por ejemplo, cada una de las pantallas que aparecen cuando un telefonista coge una petición por teléfono), y los enlaces representan las transiciones que ocurren para moverse de estado a estado (por ejemplo, petición-información se verifica durante inventario- disponibilidad-búsqueda y es seguido por cliente-factura-información- entrada).
  42. 42. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor.  Modelado de flujo de datos. Los nodos objetos de datos y los enlaces son las transformaciones que ocurren para convertir un objeto de datos en otro.  Modelado de planificación. Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecución requeridos al ejecutarse el programa.  Gráfica Causa-efecto. La gráfica Causa-efecto. representa una ayuda gráfica en seleccionar, de una manera sistemática, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigüedades en la especificación. Un gráfico de causa-efecto es un lenguaje formal al cual se traduce una especificación. El gráfico es realmente un circuito de lógica digital (una red combinatoria de lógica), pero en vez de la notación estándar de la electrónica, se utiliza una notación algo más simple. No hay necesitad de tener conocimiento de electrónica con excepción de una comprensión de la lógica booleana (entendiendo los operadores de la lógica y, o, y no). Partición equivalente: Presenta la partición equivalente como un método de prueba de caja negra que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores que, de otro modo, requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar. Una clase de equivalencia representa un conjunto de estados válidos o no válidos para condiciones de entrada. Típicamente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica. El objetivo de partición equivalente es reducir el posible conjunto de casos de prueba en uno más pequeño, un conjunto manejable que evalúe bien el software. Se toma un riesgo porque se escoge no probar todo. Así que se necesita tener mucho cuidado al escoger las clases. La partición equivalente es subjetiva. Dos probadores quienes prueban un programa complejo pueden llegar a diferentes conjuntos de particiones.
  43. 43. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. En el diseño de casos de prueba para partición equivalente se procede en dos pasos: 1. Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condición de entrada (generalmente una oración o una frase en la especificación) y repartiéndola en dos o más grupos. Es de notar que dos tipos de clases de equivalencia están identificados: las clases de equivalencia válidas representan entradas válidas al programa, y las clases de equivalencia inválidas que representan el resto de los estados posibles de la condición (es decir, valores erróneos de la entrada). 2. Se define los casos de prueba. El segundo paso es el uso de las clases de equivalencia para identificar los casos de prueba. El proceso es como sigue: se asigna un número único a cada clase de equivalencia. Hasta que todas las clases de equivalencia válidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia válida. Y por último hasta que los casos de prueba hallan cubierto todas las clases de equivalencia inválidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia inválidas descubiertas. Prueba de la tabla ortogonal: hay aplicaciones donde el número de parámetros de entrada es pequeño y los valores de cada uno de los parámetros está claramente delimitado. Cuando estos números son muy pequeños (por ejemplo, 3 parámetros de entrada tomando 3 valores diferentes), es posible considerar cada permutación de entrada y comprobar exhaustivamente el proceso del dominio de entrada. En cualquier caso, cuando el número de valores de entrada crece y el número de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva se hace impracticable. La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de entrada es relativamente pequeño pero demasiado grande para posibilitar pruebas exhaustivas. El método de prueba de la tabla ortogonal es particularmente útil al encontrar errores asociados con fallos localizados -una categoría de error asociada con defectos de la lógica dentro de un componente software.
  44. 44. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 2.2.2 EQUIPO ROJO A finales de 1996, Dan Farmer (creador de una de las herramientas más útiles en la detección de intrusos: SATAN) realizó un estudio sobre seguridad analizando 2.203 sistemas de sitios en Internet. Los sistemas objeto del estudio fueron Web Sites orientados al comercio y con contenidos específicos, además de un conjunto de sistemas informáticos aleatorios con los que realizar comparaciones. El estudio se realizó empleando técnicas sencillas y no intrusivas. Se dividieron los problemas potenciales de seguridad en dos grupos: rojos (red) y amarillos (yellow). Los problemas del grupo rojo son los más serios y suponen que el sistema está abierto a un atacante potencial, es decir, posee problemas de seguridad conocidos en disposición de ser explotados. Así por ejemplo, un problema de seguridad del grupo rojo es un equipo que tiene el servicio de FTP anónimo mal configurado. Los problemas de seguridad del grupo amarillo son menos serios pero también reseñables. Implican que el problema detectado no compromete inmediatamente al sistema pero puede causarle serios daños o bien, que es necesario realizar tests más intrusivos para determinar si existe o no un problema del grupo rojo. La Agencia de Seguridad Nacional americana, una de los organismos más poderosos del planeta, ayudó a mejorar la seguridad de Windows Vista. (DT, AGENCIAS) El Washington Post publico que la agencia ha admitido su 'colaboración no específica' en Vista. Tony Sager, el jefe de análisis de vulnerabilidades y del grupo de operaciones de la NSA, le dijo al rotativo que la intención de esta agencia era la de ayudar a todo el mundo en todo lo posible. La NSA utilizó un equipo azul y otro rojo para analizar el software. El equipo rojo tenía el rol de tratar de corromper o robar información como si de un "adversario técnicamente competente y muy decidido" se tratase. El equipo azul ayudó a los administradores del departamento de defensa con la configuración de Windows Vista.
  45. 45. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. 2.3 CRITERIOS COMUNES Los Criterios Comunes(CC) tienen su origen en 1990 y surgen como resultado de la armonización de los criterios sobre seguridad de productos software ya utilizados por diferentes países con el fin de que el resultado del proceso de evaluación pudiese ser aceptado en múltiples países. Los CC permiten comparar los resultados entre evaluaciones de productos independientes. Para ello, se proporcionan un conjunto común de requisitos funcionales para los productos de TI (Tecnologías de la Información). Estos productos pueden ser hardware, software o firmware. El proceso de evaluación establece un nivel de confianza en el grado en el que el producto TI satisface la funcionalidad de seguridad de estos productos y ha superado las medidas de evaluación aplicadas. Los CC son útiles como guía para el desarrollo, evaluación o adquisición de productos TI que incluyan alguna función de seguridad. La lista de productos certificados según los CC se encuentra disponible en la web de Common Criteria. Este estándar, los Criterios Comunes (CC), tiene como finalidad el ser usado como base para la evaluación de las propiedades de seguridad de los productos y sistemas de Tecnologías de la Información (TI). Estableciendo esta base de criterios comunes, los resultados de una evaluación de seguridad de TI será significativa para una mayor audiencia. Los CC permitirán la comparación entre los resultados de evaluaciones de seguridad independientes, al proporcionar un conjunto común de requisitos para las funciones de seguridad de los productos y sistemas de TI y para las medidas de garantía aplicadas a éstos durante la evaluación de seguridad. El proceso de evaluación establece un nivel de confianza del grado en que las funciones de seguridad de tales productos y sistemas y las medidas de garantía aplicadas coinciden con aquellos requisitos. Los CC son útiles como guía para el desarrollo de productos o sistemas con funciones de seguridad de TI y para la adquisición de productos y sistemas comerciales con dichas funciones. Los CC tratan la protección de la información contra la revelación no autorizada, modificación o pérdida de uso. Las categorías de protección relacionadas con estos tres tipos de fallos de seguridad son llamadas normalmente confidencialidad, integridad y disponibilidad respectivamente. Los CC pueden ser también aplicables en aspectos de seguridad de TI distintos a estos tres. Los CC se concentran en aquellas amenazas que provienen de una actividad humana, ya sea maliciosa o de otro tipo, pero también pueden ser aplicables a otras amenazas no humanas. Además, los CC pueden ser aplicados
  46. 46. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. en otras áreas distintas de TI pero no se hace ninguna declaración de competencia fuera del estricto ámbito de la seguridad de TI. Los CC son aplicables a las medidas de seguridad de TI implementadas en hardware, firmware o software. Cuando se pretenda tratar aspectos particulares de evaluación a aplicar sólo en determinados métodos de implementación, se indicará expresamente en las declaraciones de los criterios correspondientes. Algunos temas, porque involucran técnicas especializadas o porque son, de alguna manera, adyacentes a la seguridad de TI, son considerados ajenos a la finalidad de los CC. Entre estos cabe destacar los siguientes:  Los CC no contienen criterios de evaluación de la seguridad correspondientes a medidas de seguridad administrativa no relacionadas directamente con las medidas de seguridad de TI. Sin embargo, se reconoce que una parte significativa de la seguridad de un TOE puede, a menudo, proporcionarse a través de medidas administrativas (organizativas, de personal, físicas y control de procedimientos). Las medidas de seguridad administrativas, en el entorno operativo del TOE, son tratadas como hipótesis de un uso seguro donde éstas tienen un impacto importante en la capacidad de las medidas de seguridad de TI para contrarrestar las amenazas identificadas.  La evaluación de aspectos técnicos físicos de la seguridad de TI como control de radiaciones electromagnéticas no se trata específicamente, aunque varios de los conceptos tratados serán aplicables en esta área. En particular, los CC tratan algunos aspectos de la protección física del TOE.  Los CC no tratan ni la metodología de evaluación ni el marco administrativo y legal bajo el cual los criterios pueden ser aplicados por las autoridades de evaluación. Sin embargo, se espera que los CC sean usados para propósitos de evaluación en el contexto de un determinado marco administrativo y con una determinada metodología.  Los procedimientos para el uso de los resultados de la evaluación en la acreditación de productos o sistemas están fuera del objetivo de los CC. La acreditación de un producto o sistema es el proceso administrativo por el que se autoriza el uso de dicho producto o sistema de TI en su entorno operativo. La evaluación se centra en las partes de seguridad de TI del producto o sistema y en aquellas partes del entorno operativo que pueden
  47. 47. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. afectar directamente el seguro uso de los elementos de TI. Los resultados del proceso de evaluación son, por lo tanto, un dato de valor para el proceso de acreditación. Sin embargo, como hay otras técnicas más apropiadas para la valoración, tanto de las propiedades de seguridad de un producto o sistema no relacionados con TI, como de su relación con las partes de seguridad de TI, los acreditadores deberán establecer separadamente estos aspectos.  Los criterios para la valoración de las cualidades inherentes de los algoritmos criptográficos no se tratan en los CC. Si se necesita una valoración independiente de las propiedades matemáticas de la criptografía introducida en un TOE, deberá ser proporcionada por el esquema bajo el cual se están aplicando los CC. Funcionamiento Con el fin de poder certificar un producto según los Criterios Comunes se deben comprobar, por parte de uno de los laboratorios independientes aprobados, numerosos parámetros de seguridad que han sido consensuados y aceptados por 22 países de todo el mundo. El proceso de evaluación incluye la certificación de que un producto software específico verifica los siguientes aspectos: Los requisitos del producto están definidos correctamente. Los requisitos están implementados correctamente. El proceso de desarrollo y documentación del producto cumple con ciertos requisitos previamente establecidos. Los Criterios Comunes establecen entonces un conjunto de requisitos para definir las funciones de seguridad de los productos y sistemas de Tecnologías de la Información y de los criterios para evaluar su seguridad. El proceso de evaluación, realizado según lo prescrito en los Criterios Comunes, garantiza que las funciones de seguridad de tales productos y sistemas reúnen los requisitos declarados. Así, los clientes pueden especificar la funcionalidad de seguridad de un producto en términos de perfiles de protección estándares y de forma independiente seleccionar el nivel de confianza en la evaluación de un conjunto definido desde el EAL1 al EAL7.
  48. 48. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. Perfiles de protección Un perfil de protección (Protection Profile) define un conjunto de objetivos y requisitos de seguridad, independiente de la implantación, para un dominio o categoría de productos que cubre las necesidades de seguridad comunes a varios usuarios. Los perfiles de protección son reutilizables y normalmente públicos y están compuestos de: Requisitos funcionales (SFR, Security Funcional Requirement) proporcionan mecanismos para hacer cumplir la política de seguridad. Como ejemplos de requisitos funcionales mencionar la protección de datos de usuario, el soporte criptográfico, la autenticación, la privacidad o el control de acceso. Requisitos de confianza o aseguramiento (SAR, Security Assurance Requirement) proporcionan la base para la confianza en que un producto verifica sus objetivos de seguridad. Los requisitos de confianza se han agrupado en niveles de confianza en la evaluación (EAL, Evaluation Assurance Levels) que contienen requisitos de confianza construidos específicamente en cada nivel. Los EALs proporcionan una escala incremental que equilibra el nivel de confianza obtenido con el coste y la viabilidad de adquisición de ese grado de confianza. El incremento de confianza de un EAL a otro se obtiene incrementando rigor, alcance y/o profundidad en el componente y añadiendo componentes de confianza de otras familias de confianza (por ejemplo, añadiendo nuevos requisitos funcionales). Niveles de confianza Los niveles de confianza en la evaluación definidos en el ISO/IEC 15408-3 [ISO 15408-3 2005] van desde EAL1 (el menor) a EAL 7 (el mayor) y se definen de forma acumulativa (verificaciones de nivel n+1 implican realizar las de nivel n, 1 ≤ n ≥ 7):  EAL1 (funcionalidad probada): es aplicable donde se requiere tener cierta confianza de la operación correcta, y donde además, las amenazas a la seguridad no son vistas como serias. Una evaluación en este nivel debe proporcionar evidencia de que las funciones del objeto de evaluación son consistentes con su documentación, y que proporcionan protección útil contra amenazas identificadas.
  49. 49. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor.  EAL2 (estructuralmente probado): requiere la cooperación del desarrollador en términos de la distribución de la información del diseño, y los resultados de las pruebas y proporciona confianza a través de un análisis de las funciones de seguridad, usando una especificación funcional y de interfaz, manuales y diseño de alto nivel del producto para entender el comportamiento de seguridad. Además, en este nivel se verifica que el desarrollador realizó un análisis de vulnerabilidades a través de la ejecución de pruebas de caja negra (Black-box).  EAL3 (probado y verificado metódicamente): permite a un desarrollador alcanzar una máxima garantía de ingeniería de seguridad positiva en el estado de diseño sin la alteración substancial de prácticas de desarrollo válidas existentes. El análisis en este nivel se apoya en las pruebas de caja gris (grey box), la confirmación selectiva independiente de los resultados de las pruebas del desarrollador, y la evidencia de búsqueda de vulnerabilidades obvias del desarrollador. Además, se realizan controles del entorno de desarrollo y de gestión de configuración del producto.  EAL4 (diseñado, probado y revisado metódicamente): este nivel le permite a un desarrollador alcanzar máxima garantía de ingeniería de seguridad positiva basada en buenas prácticas de desarrollo comercial, las cuales, aunque rigurosas, no requieren del conocimiento especializado substancial, destreza, ni otros recursos. En este caso, el análisis se apoya en el diseño de bajo nivel de los módulos del producto y se realiza búsqueda de vulnerabilidades independiente de las pruebas realizadas por el desarrollador.  EAL5 (diseñado y probado semiformalmente): permite a un desarrollador alcanzar máxima garantía de ingeniería de seguridad positiva mediante la aplicación moderada de técnicas de ingeniería de seguridad. La confianza se apoya, en este caso, en un modelo formal y una presentación semiformal de la especificación funcional y el diseño de alto nivel. La búsqueda de vulnerabilidades debe asegurar la resistencia relativa a los ataques de penetración.  EAL6 (diseño verificado y probado semiformalmente): permite a los desarrolladores alcanzar una alta garantía en la aplicación de técnicas de ingeniería de seguridad para un entorno de desarrollo riguroso y donde el objeto de evaluación es considerado de gran valor para la protección del alto costo o estimación de esos bienes contra riesgos significativos. Además, es aplicable para el desarrollo de objetos de evaluación, destinados a salvaguardar la seguridad informática en situaciones de alto
  50. 50. INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor. riesgo donde el valor de los bienes protegidos justifica los costos adicionales. El análisis en este nivel se apoya en un diseño modular y en una presentación estructurada de la implementación del producto. La búsqueda de vulnerabilidades debe mostrar una alta resistencia a los ataques de penetración.  EAL7 (diseño verificado y probado formalmente): es aplicable al desarrollo de objetos de evaluación de seguridad, para su aplicación en situaciones de muy alto riesgo o donde el alto valor de los bienes justifica los más altos costos. La aplicación práctica del nivel EAL7 está limitada actualmente a objetos de evaluación con seguridad estrechamente enfocada a la funcionalidad, y que es sensible al análisis formal y extenso. Este EAL representa un incremento Significativo respecto a la garantía de nivel EAL6 a través del requisito de análisis de gran amplitud, mediante representaciones formales y correspondencia formal y pruebas de gran amplitud. Además, el evaluador confirmará de forma independiente y completa los resultados de las pruebas de caja blanca (White- box) realizadas por el desarrollador. Los niveles EAL 5 al 7 incluyen modelos y demostraciones semiformales y formales por tanto, se aplican a productos con objetivos de seguridad muy específicos (entorno militar, por ejemplo). Por otra parte, estos niveles requieren de la generación de una gran cantidad de documentación durante el proceso de desarrollo que debe entregarse al evaluador para que éste pueda confirmar la información. Finalmente, para la aplicación de los Criterios Comunes, existe una metodología con los criterios a evaluar para cada uno de los niveles de confianza estandarizada por la Norma ISO/IEC 18045 (ISO 18045, 2008) y denominada CEM (Common Methodology for IT Security Evaluation) disponible en la web de Common Criteria.

×