Antologia DSS Completa PDF

32a
Institución Certificada
Norma ISO 9001:2000
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

INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA
Academia de Informática y Sistemas Computacionales
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
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

Unidad IV
Principios guías del software seguro
4.1 Principio 1. Reducir las líneas débiles

4.2 Principio 2. Defensa por pasos o capas
4.3 Principio 3. Seguramente fallará
4.4 Principio 4. Menos privilegios
4.5 Principio 5. Segmentación
4.6 Principio 6. Mantenerlo simple
4.7 Principio 7. Promover la privacía
4.8 Principio 8. Ocultar secretos es difícil
4.9 Principio 9. Transparentar el código
4.10 Principio 10. Usar recursos comunes
Unidad V
Auditoria de software
5.1 Definición de Arquitectura de Seguridad

5.2 Principios de la Arquitectura de Seguridad
5.3 Análisis de la Arquitectura de Seguridad
5.3.1 Diseño
5.3.2 Implementación
5.3.3 Automatización y pruebas
5.3.4 Árboles de Ataque
5.3.5 Reporte del Análisis
5.4 Implementación del Análisis de Seguridad
5.4.1 Auditoria de Código Fuente
5.4.2 Herramientas de Auditoria de Seguridad de Código

Unidad VI
Código seguro
6.1 Definición de Código Seguro

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

Unidad VII
Pruebas de software
7.1 Fases de las Pruebas de Software

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

Unidad VIII
Derechos de autor en México (software)
8.1 Ley Federal del Derecho de Autor (LFDA) en México

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

Unidad I
Introducción a la seguridad del software
Objetivo: El alumno conocerá y comprenderá los fundamentos teóricos,

tendencias y metas de la seguridad en el software.
Contenido:
1.1 Concepto de Software

1.2 Casos reales de fallas en el software
1.3 Futuro del software
1.4 Fuentes para información de vulnerabilidades
1.4.1. Buqtraq
1.4.2. CERT Advisores
1.4.3. RISK Digest
1.5 Tendencias técnicas que afectan a la Seguridad del Software
1.6 Breanking and patch (romper y actualizar)
1.7 Metas de la Seguridad enfocadas al Software
1.7.1. Prevención
1.7.2. Auditable y trazable
1.7.3. Monitoreo
1.7.4. Privacidad y Confidencialidad
1.7.5. Seguridad Multiniveles
1.7.6. Anonimato
1.7.7. Autenticación
1.7.8. Integridad
1.8 Conocer al enemigo
1.9 Metas de proyecto de Software

1.1 CONCEPTO DE SOFTWARE
El software es el nexo de unión entre el hardware y el hombre. El computador, por

sí solo, no puede comunicarse con el hombre y viceversa, ya que lo separa la
barrera del lenguaje. El software trata de acortar esa barrera, estableciendo
procedimientos de comunicación entre el hombre y la máquina; es decir, el
software obra como un intermediario entre el hardware y el hombre.
El software es un conjunto de programas elaborados por el hombre, que controlan

la actuación del computador, haciendo que éste siga en sus acciones una serie de
esquemas lógicos predeterminados.
Tal característica ‗lógica‘ o ‗inteligente‘ del software es lo que hace que se le

defina también como la parte inmaterial de la informática, ya que aunque los
programas que constituyen el software residan en un soporte físico, como la
memoria principal o los disquetes (o cualquier dispositivo rígido de
almacenamiento), la función de los programas en un computador es semejante a
la del pensamiento en un ser humano.
Si bien el progreso del hardware es cada vez mayor y los dispositivos físicos se
construyen cada vez con más ‗inteligencia‘ incluida, en forma que se resuelven por
hardware funciones anteriormente sólo factibles por software, es prácticamente
imposible que el avance tecnológico llegue algún día a eliminar la necesidad de
software, ya que éste también evoluciona y las facilidades que el usuario pide al
computador son cada día más sofisticadas.
La clasificación básica es: Software de Sistema y Software de Aplicación.
 El software de sistema es el software básico o sistema operativo.

Es un conjunto de programas cuyo objeto es facilitar el uso del computador (aísla
de la complejidad de cada dispositivo, y presenta al exterior un modelo común de
sistema de manejo para todos los dispositivos) y conseguir que se use
eficientemente
 El software de aplicación
Son los programas que controlan y optimización la operación de la máquina,
establecen una relación básica y fundamental entre el usuario y el computador,
hacen que el usuario pueda usar en forma cómoda y amigable complejos sistemas

hardware, realizan funciones que para el usuario serían engorrosas o

incluso imposibles, y actúan como intermediario entre el usuario y el hardware.
1.2 CASOS REALES DE FALLAS EN EL SOFTWARE
 El caso del desastre del Ariane-5, famoso por haberse producido por una
falla en el software de abordo. Según la European Spacial Agency (ESA),
administradora del programa, la desviación en la trayectoria fue ocasionada
por la computadora que controlaba los dos poderosos impulsores del
cohete. Se especulo que la computadora creyó que el cohete se estaba
saliendo de curso y de esta manera trataba de corregir la trayectoria de
vuelo. De acuerdo con el reporte final, la causa de la falla del sistema
ocurrió durante la conversión de un número flotante de 64 bits a un número
entero de 16 bits.
 Otro de los casos de fallas en software que causó graves daños a la

integridad de las personas, Therac-25. Era un aparato para el tratamiento
del cáncer por emisión de rayos cuyos controles (de la cantidad de energía
emitida) implementados en hardware fueron removidos y sólo se dejaron
los de software que (obviamente) fallaron.
 Error en un sistema de autenticación de tarjetas de crédito (1995)

Los dos sistemas más grandes en ese país para la autorización de crédito
(Barclay´s PQD y NatWest´s Streamline) fallaron el sábado 28 de octubre
de 1995 imposibilitando que los comercios verificaran las tarjetas de crédito
de sus clientes. En el caso de Barclay, más de 40% de las transacciones
fallaron por un error en el sistema de software. Para NatWest, el problema
fue ocasionado por una gran cola de llamadas, que obstruyo la
comunicación por razones desconocidas, y que retraso la autentificación de
tarjetas.
 Software inapropiado llevó a un distribuidor de medicina a la quiebra. El 27

de agosto de 1998 la revista Der Spiege, en Alemania, informó de una
demanda de 500 millones de dólares a SAP por parte del distribuidor de
medicinas FoxMeyer Corp. Esta última acusó a SAP de venderle software
inapropiado para sus necesidades, lo cual tuvo como resultado la quiebra
de Fox Meyre. Analistas alemanes comentaron que no consideran que un
―software sea apropiado para llevar a la ruina a una compañía‖.

 Error en sistema de cobranza de MCI (1996). En la edición de 29 de marzo

de 1996 del Washington Post, MCI reporto que le devolverían
aproximadamente 40 millones de dólares a sus clientes por un error de
cobranza causada por un sistema de cómputo.
 El error de cobranza fue descubierto por un reportero investigador de una

estación local de televisión en Richmond, VA, quien encontró que fueron
facturados por 4 minutos siendo que en realidad la llamada fue de 2.5
minutos, dando lugar a una profunda investigación.
1.3 FUTURO DEL SOFTWARE
"El futuro del software es un desafío"
Empecemos con una paradoja: el futuro del software comienza con el fin del
software. Al menos, el fin del software tal y como lo conocemos. El software
cliente/servidor tradicional es un modelo acabado, en particular para las
organizaciones de TI que desean contribuir realmente al balance final.
Para comprender el futuro del software empresarial, no hace falta ir muy lejos: la
Web de consumidores. Al igual que los servicios Web para consumidores como
Google, eBay y Amazon.com están sustituyendo al software estándar para
consumidores, cada vez más aplicaciones empresariales están trasladándose a la
Web. En 2005, se calculó que las ventas de SaaS (software como servicio)
supusieron un 5% del total de las ventas de software empresarial. En 2011, se
prevé que la cuota aumente hasta el 25%.
Los cambios implican un desafío interesante para todos los involucrados en el

desarrollo de software. Y el hardware, que durante muchos años ha sido el cuello
de botella de los sistemas informáticos, crecerá hasta volverse de 50 a 100 veces
más poderoso que en la actualidad.
Esto representa una dificultad adicional, la de utilizar toda esa capacidad ociosa
para convertirla en algo productivo, ya que no sería inteligente tomar sistemas que
actualmente desperdician millones de ciclos de CPU y agregarle más capacidad

sin modificar el uso que reciben, para de ese modo desperdiciar más poder
aún. Sin dudas, "se avecina un nuevo paradigma de software, y he aquí el mayor
desafío".
Cualquier especulación sobre el futuro del software merece, como mínimo, una
revisión de los principales cambios a lo largo de su historia, como:
 El paso del ordenador central a los sistemas cliente/servidor, que tuvo como
consecuencia la transición desde sistemas existentes a sistemas
empresariales estándar.
 El auge de los ordenadores personales que desembocó en una

productividad de los usuarios sin precedentes, así como una proliferación
de islas de datos.
 El auge de Internet, que condujo a una explosión de información y cambió

el modo en que millones de personas trabajan, juegan y compran. También
el aumento del uso de Internet y el acceso permanente a la red.
 La aparición de estándares y tecnologías de servicios Web, como las

arquitecturas multiusuario.
 El paso hacia los enfoques de arquitectura orientada a servicios (SOA) por

parte de los principales proveedores de software, lo que facilitaba la
integración con los sistemas de servidor.
 La aparición del modelo On-Demand, que suponía el cambio de un modelo

en propiedad a un modelo ―en alquiler‖ y que liberaba a las empresas de los
problemas y los gastos que conllevaba la propiedad. Salesforce.com es uno
de los ejemplos más satisfactorios de este modelo con 55,400 clientes y
más de 800 aplicaciones.

1.4 FUENTES PARA LA INFORMACIÓN DE VULNERABILIDADES
En cualquier caso conviene indicar las fuentes más importantes de información

asociada a vulnerabilidades de seguridad. No hay que olvidar que la mayor parte
de esta información es de dominio público y que los desarrollos posteriores que
puedan hacerse (bien a medida internamente o contratados) van a estar basados
en las mismas fuentes:
 El diccionario CVE, desarrollado por la corporación Mitre y disponible en

http: //cve.mitre.org, que sirve como un elemento integrado de distintas
fuentes y herramientas de seguridad. En esencia se trata de llamar a una
vulnerabilidad siempre ―igual‖ (con el mismo identificador).
 La base de datos de vulnerabilidades y alertas del centro de respuesta y

coordinación ante emergencias de Internet, el CERT/CC, disponible en
http:// www.kb.cert.org/vuls. Las bases de datos de vulnerabilidades son
una herramienta clave a la hora de detectar posibles problemas de
seguridad y prevenirlos
 La famosa base de datos de Bugtrag (basada en gran parte en la

información publicada en la lista de correo de seguridad del mismo
nombre), adquirida por la empresa de seguridad Symantec, disponible en
http: //www.securityfocus.com/bid. Es posiblemente la más completa
(alrededor de 10.000 vulnerabilidades hasta la fecha) y sobre ésta
Symantec ha desarrollado un servicio comercial.
 La base de datos de Xforce, desarrollada por el fabricante de productos

de seguridad Internet Security Systems (ISS), disponible en
http://xforce.iss.net. Sirve de base tanto a los productos de seguridad de la
compañía (herramientas de detección de intrusos, sistemas de análisis de
vulnerabilidades...) como de servicios comerciales basados en ésta.
 La base de datos ICAT publicada por el instituto de estándares del

Gobierno norteamericano, el NIST, y disponible en http://icat.nist.gov. Se
trata de una metabase de datos de información de vulnerabilidades, con
más de 6.500 referencias a CVE y a las bases de datos arriba indicadas. Se

distribuye como un fichero de Microsoft Access (o en formato CSV)

para su libre utilización.
Dentro de estas fuentes de información podemos encontrar todo tipo de

vulnerabilidades, desde ataques a servidores IIS de Microsoft a través de código
Unicode hasta desbordamientos de búfer de Oracle Application Server, pasando
por pequeñas vulnerabilidades de sistemas Windows como las existentes en la
ayuda online de Windows. Como es lógico todas estas bases de datos se están
actualizando continuamente, a medida que se publicitan nuevos fallos de
seguridad.
Las fuentes de información de vulnerabilidades de seguridad y, entre ellas, las

bases de datos de vulnerabilidades, son una herramienta clave a la hora de
detectar posibles problemas de seguridad y prevenirlos. Estas fuentes dan, si bien
no en tiempo real, información de los principales problemas asociados a los
principales fabricantes de software y hardware (y algunos menos conocidos), en
muchos casos con sus posibles soluciones, y con información que permitirá
determinar la premura con la que se debe arreglar la vulnerabilidad (en base a su
impacto, al riesgo existente debido a la existencia o no de aprovechamientos de la
misma...).
1.5 TENDENCIAS TECNICAS QUE AFECTAN A LAS ENTIDADES DEL

SOFTWARE
Tendencias que afectan a los sistemas de información

Al considerar un Sistema de Información como un conjunto de normas y procesos
generales de una determinada, se deben considerar algunos puntos negativos y
positivos que afectan directamente al sistema:
Actualizaciones
Se refiere a que los sistemas de información de cualquier empresa, debe ser
revisado periódicamente; no con una frecuencia continua, sino mas bien
espaciada, se recomienda las revisiones bianuales (No se recomienda que se
actualice en una empresa paulatinamente, por ejemplo el software, cuadros
estadísticos, es recomendable dentro de un año cambiarlo, todo lo que es
máquinas y software; porque si no realizaríamos esto, se cambiaría toda la
estructura organizacional de la misma).

Reestructuración Organizacional
(Puede ser una reestructuración con los mismos puestos). Una reestructuración
organizacional con cualquier empresa, implica cambios siempre en vista a buscar
un mejor funcionamiento, evitar la burocracia, agilitar trámites o procesos, la
reestructuración puede ser de varios tipos, así por ejemplo. Aumentar o disminuir
departamentos, puestos, reestructuración de objetivos, etc. Siempre la
reestructuración afecta a los sistemas de información de la empresa.
Revisión y Valorización del escalafón

(No es para bien si no también para mal)
La revisión y la revalorización del escalafón se espera que afecte a favor de los
sistemas de información de las empresas, si el efecto es contrario el auditor
deberá emitir un informe del empleado a los empleados (Específicamente de
departamentos), que están boicoteando la información de la empresa.
Cambios en el flujo de Información

(Datos para el sistema de Información)
Se refiere al cambio de flujo de datos exclusivamente en el área informática, esto
afecta directamente en sistema informático y por tanto al sistema de información.
En lo que respecta a la Auditoría informática, el efecto puede ser positivo y
negativo, dependiendo a los resultados obtenidos en cuanto al proceso de datos
(menos seguridad, más seguridad, backup).
Así por ejemplo:
Se ha cambiado el flujo de información en el área contable, para generar los roles
mensuales (De inicio del rol era realizado por la secretaria, la cual ingresaba las
existencias, fallas, atrasos, etc.; determinando un monto a descontar. Un monto
bruto y un salario final, esto pasaba a la contadora para que justifique
especialmente multas, se rectificaba en algunos casos, y se mandaba a imprimir el
rol. Se considera un nuevo flujo de información, en el cual se ingresan los datos a
un sistema informático, y de acuerdo a los parámetros y normas de la empresa el
sistema arroja un sueldo líquido a cobrarse, genera automáticamente el reporte,
los cheques y el contador solo aprueba este reporte).
(Un ejemplo es cuando existe migración de datos, la información migra o se
cambia a otro sistema más sofisticado).

1.6 BREAKING AND PATCH
Actualización
Modificación que se aplica al software para corregir un problema o incorporar una
función nueva.
Realizar los pasos necesarios para aplicar actualizaciones a un sistema. El
sistema se analiza y, a continuación, se descargan y se aplican las
actualizaciones.
Se denomina también patch.
Actualización con firma

Actualización que incluye una firma digital válida. Las actualizaciones firmadas
ofrecen mayor seguridad que las que no disponen de firma. La firma digital de la
actualización puede verificarse antes de aplicarla al sistema. Las firmas digitales
válidas aseguran que las actualizaciones no se han modificado desde que éstas
se aplicaron. Las actualizaciones firmadas se almacenan en archivos con formato
Java Archive (JAR).
Actualización de función
Actualización que incorpora una nueva función en el sistema.
Actualización sin firma

Actualización que no incluye una firma digital.
Parche (informática)
En informática, un parche es una sección de código que se introduce a un
programa. Dicho código puede tener varios objetivos; sustituir código erróneo,
agregar funcionalidad al programa, aplicar una actualización, etc.
Los parches suelen ser desarrollados por programadores ajenos al equipo de
diseño inicial del proyecto (aunque no es algo necesariamente cierto). Como los
parches se pueden aplicar tanto a un binario ejecutable como al código fuente,
cualquier tipo de programa, incluso un sistema operativo, puede ser objeto de un
parche.
El origen del nombre probablemente se deba a la utilidad de Unix llamada patch
creada por Larry Wall

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

1.7 METAS DE LA SEGURIDAD ENFOCADAS AL SOFTWARE
La Arquitectura de Seguridad de Información es la práctica de aplicar un método

riguroso y comprensivo para describir una estructura actual y/o futura y el
comportamiento de los procesos de seguridad de una organización, sistemas de
seguridad de información y subunidades de personal y organizativas, para que se
alineen con las metas comunes de la organización y la dirección estratégica.
Aunque a menudo se asocie estrictamente con tecnologías para la seguridad de la
información, se relaciona en términos más generales con la práctica de seguridad
de optimización del negocio, donde dirige la arquitectura de seguridad del negocio,
la realización de gestiones y también la arquitectura de procesos de seguridad.
La Arquitectura de Seguridad de Información en la Empresa está convirtiéndose

en una práctica habitual dentro de las instituciones financieras alrededor del
mundo. El propósito fundamental de crear una arquitectura de seguridad de
información en la empresa es para asegurar que la estrategia de negocio y la
seguridad de las tecnologías de la información (TI) están alineadas. Como tal, la
arquitectura de seguridad de la información en la empresa permite la trazabilidad
desde la estrategia de negocio hasta la tecnología subyacente.
Metas de la Seguridad
Proporcionar estructura, coherencia y cohesión

Debe permitir un alineamiento del negocio hacia la seguridad
Principios inicio-fin definidos con estrategias de negocio
Asegurar que todos los modelos e implementaciones pueden ser trazados
hacia atrás hasta la estrategia de negocio, específicamente requerimientos
de negocio y principios clave
Proveer abstracción para que factores complicados puedan ser eliminados
y reinstalados en niveles de detalle diferente sólo cuando sean requeridos
Establecer un lenguaje común para la seguridad de la información dentro
de la organización

Protección del software:
Los programas de ordenador actualmente están expresamente excluidos de la

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

1.7.1 PREVENCION
Un sistema de prevención/protección para defenderse de las intrusiones y no sólo

para reconocerlas e informar sobre ellas, como hacen la mayoría de los IDS.
El software de prevención contempla:
 Gestión de prevención de riesgos a nivel de centros de trabajo y

trabajadores.
 Gestión de subcontratas.
 Histórico de evaluaciones de riesgos realizadas.
 Composición de equipos de emergencia.
 Histórico de cursos de prevención y seguridad realizados.
 Estadísticas de siniestralidad.
 Análisis de accidentes.
 Control de la Formación en materia de prevención.
 Gestión de Equipos de protección individual entregados al personal.
 La efectividad de la prevención general tiene una doble vertiente:
 La prevención general positiva: es aquélla que va encaminada a restablecer

la confianza del resto de la sociedad en el sistema.
 La prevención general negativa: es aquélla que va encaminada a disuadir a

los miembros de la sociedad que no han delinquido, pero que se pueden
ver tentados a hacerlo, a través de la amenaza de la pena.

1.7.2 AUDITABLE Y TRAZABLE
Auditable: es tanto la solución tecnológica, como sus componentes de hardware

y/o software debe ser abierta e íntegramente auditable antes y posteriormente a
su uso. Consideramos que también debe ser auditable durante su uso y no
restringirlo únicamente a las etapas del antes o el después.
Auditabilidad de bases de datos

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

con el software freeware ilEAN Writer 2.0 e ilEAN Reader 2.0... Además de
con una larga lista de sistemas estándar de los más importantes fabricantes de
software.
Esta consiste en la capacidad para reconstruir la historia, recorrido o aplicación de
un determinado producto, identificando:
Origen de sus componentes.

Historia de los procesos aplicados al producto.
Distribución y localización después de su entrega.
Al contar con esta información es posible entregar productos definidos a mercados

específicos, con la garantía de conocer con certeza el origen y la historia del
mismo. El concepto de trazabilidad está asociado, sin duda, a procesos
productivos modernos y productos de mayor calidad y valor para el cliente final.
La trazabilidad es aplicada por razones relacionadas con mejoras de negocio las
que justifican su presencia: mayor eficiencia en procesos productivos, menores
costes ante fallos, mejor servicio a clientes, etc. En este ámbito cabe mencionar
sectores como los de automoción, aeronáutica, distribución logística, electrónica
de consumo, etc.,
Un sistema de trazabilidad es un conjunto de disciplinas de diferente naturaleza
que, coordinadas entre si, nos permiten obtener el seguimiento de los productos a
lo largo de cualquier cadena del tipo que sea.
Si entendemos como trazabilidad a: "un conjunto de procedimientos
preestablecidos y autosuficientes que permiten conocer el histórico, la ubicación y
la trayectoria de un producto, o lote de productos a lo largo de la cadena de
suministros, en un momento dado y a través de unas herramientas determinadas",
un sistema de trazabilidad deberá de estar compuesto por:
1. Sistemas de identificación
1. Un sistema de identificación del producto unitario
2. Un sistema de identificación del embalajes o cajas
3. Un sistema de identificación de bultos o palets
2. Sistemas para la captura de datos
1. Para las materias primas
2. Para la captura de datos en planta
3. Para la captura de datos en almacén
3. Software para la gestión de datos
1. Capaz de imprimir etiquetas

2. Capaz de grabar chips RFID

3. Capaz de almacenar los datos capturados
4. Capaz de intercambiar datos con los sistemas de gestión
empresariales
Cuando un sistema de trazabilidad está soportado sobre una infraestructura, basa

en las tecnologías de la información y las comunicaciones (TIC), la trazabilidad
puede brindar importantes utilidades a los diferentes actores de una cadena de
valor como ser: gestión eficiente de la logística y del suministro y aumento de la
productividad.
El Software Trazabilidad es el aplicativo de software capaz de registrar la traza
de los productos a lo largo de la cadena de suministro interna o externa,[1]
empaquetarlos en un formato legible y prepararlos para poder ser gestionados por
el propio software o como respuesta a una solicitud de servicio.
El desarrollo de las soluciones para el control de la trazabilidad ha venido
desarrollándose parejo a:
1. Los esfuerzos de las administraciones para controlar la calidad del producto

que llega al usuario final para crear las legislaciones pertinentes.
2. Las necesidades empresariales para obtener información en tiempo real
con el fin de fidelizar a los clientes.
3. Al desarrollo tecnológico en plataformas informáticas y tecnología para la
identificación de productos y obtener la información en la medida de sus
movimientos.
Parece curioso que a medida que se han ido generando exigencias y normativas
por parte de las administraciones para proteger al consumidor final, falta la figura
de un organismo regulador general, o de un sistema globalizado para determinar
que aspectos debe tener un registro de trazabilidad. Así, se han ido creando
normativas y legislaciones sobre trazabilidad por organismos de la EU.
Para un software de trazabilidad, la dificultad radica en que no existe un patrón de
empaquetamiento e intercambio de datos entre ninguno de ellos, por lo que las
exigencias de dichas normativas son diferentes entre sí, lo que provoca que la
fabricación de un producto deba cumplir normativas diferentes dependiendo del
país al que vaya destinado.

1.7.3 MONITOREO
El Monitoreo es el proceso continuo y sistemático mediante el cual verificamos la

eficiencia y la eficacia de un proyecto mediante la identificación de sus logros y
debilidades y en consecuencia, recomendamos medidas correctivas para
optimizar los resultados esperados del proyecto. Es, por tanto, condición para la
rectificación o profundización de la ejecución y para asegurar la retroalimentación
entre los objetivos y presupuestos teóricos y las lecciones aprendidas a partir de la
práctica. Asimismo, es el responsable de preparar y aportar la información que
hace posible sistematizar resultados y procesos y, por tanto, es un insumo básico
para la Evaluación.
Monitoreo de Sistemas de Seguridad
Este sistema permite el monitoreo desde cualquier lugar usando una simple
computadora con acceso a internet. Instalación, suministro, sistemas de c.c.t.v.,
sensores de humo, depende de que esté siempre conectado a la red, y si no es
así la seguridad de su casa o su negocio puede estar en peligro.
Nuestro sistema de monitoreo le permite conocer cuando su sistema de vigilancia

se encuentra no disponible y le permite tomar acciones de emergencia, ya sea
ponerse en contacto con su personal de vigilancia, centrales de monitoreo o con
su proveedor de internet.
Cómo monitoreo servidores de bases de datos detrás de un firewall
Use su lenguaje de programación web preferido (por ejemplo, ASP, JSP, PHP,
ColdFusion, Perl) para escribir un script para conectarse al servidor de base de
datos y realizar una simple consulta. Si la consulta se ejecuta exitosamente, el
script retorna algo como "Servidor de base de datos está ARRIBA".
Finalmente, vaya a Monitoreo -> Agregar un Test y seleccione monitorear un sitio
web. Ingrese la URL del script y especifique la palabra clave requerida "Servidor
de base de datos está ARRIBA". Si nuestro sistema no puede hallar la palabra
clave en la página, le notificará y sabrá que el servidor de base de datos está
caído.

Monitoreo de Dominios
El monitoreo de URLs le ayuda a monitorear la disponibilidad de su sitio Web (o
sitios Web, si tiene más de uno) y a verificar si están sirviendo páginas en tiempo
real. Algunas tipos de monitoreo se encuentran: Monitoreo de URLs, directorios
virtuales, coincidencia de contenido, servidores y aplicaciones Web.
El Software de Excelencia para Vigilancia y Monitoreo en Internet
Spector Pro es el software más vendido en el mundo para monitorear y grabar

cada detalle de la PC o de la actividad en Internet, para tu oficina o tu casa.
Sistema Avanzado de Advertencia.
Este software Aparte de monitorear y grabar, cuenta con un Sistema Avanzado de
Advertencia que te informará cuando una PC monitoreada ha sido utilizada de
manera no apropiada. A través del uso de palabras y frases claves que tú
especifiques, Spector Pro estará "en alerta", enviándote por e-mail inmediata y
detalladamente el reporte de cuándo, dónde y cómo una palabra específica fue
usada – cada vez que se escriba, que aparezca en la PC, en un sitio Web, en el
Chat/mensaje instantáneo o en un e-mail. La alerta se enviará a tu oficina, casa,
celular o a donde tú quieras.
1.7.4 PRIVACIDAD Y CONFIDENCIALIDAD
La privacidad puede ser definida como el ámbito de la vida personal de un

individuo que se desarrolla en un espacio reservado y debe mantenerse
confidencial.
Como cuidar nuestra privacidad
Instalar un cortafuegos ayudara mucho evitando que un sujeto pueda entrar

a nuestra computadora o bien que usen un troyano y quizá pueda robar
información valiosa como tarjetas de crédito o claves, etc.
Un antivirus que en lo posible también detecte spyware servirá mucho para
evitar que nos manden troyanos o spyware que envie información
confidencial aunque si tenemos un firewall es probable que este bloquee el
troyano/spyware al tratar de conectarse.

Un antispyware que ayuda a eliminar el spyware que entro a través

de distintas páginas.
Usar un explorador alternativo a Internet Explorer o bien mantenerlo
actualizado completamente.
Mantener actualizado nuestro sistema operativo es importante para evitar
que a través de un fallo del mismo alguien se pueda apoderar de nuestra
computadora y posteriormente de algo valioso.
No entrar en páginas web sospechosas de robar contraseñas o de mandar
virus/spyware al PC.
Cuando envíen un correo electrónico a varios contactos utilicen el CCO
'correo oculto' para no mostrar los contactos y parezcan como privados
La confiabilidad de software significa que un programa particular debe de seguir

funcionando en la presencia de errores. Los errores pueden ser relacionados al
diseño, a la implementación, a la programación, o el uso de errores. Así como los
sistemas llegan a ser cada vez más complejos, aumenta la probabilidad de
errores. Como mencionamos, es increíblemente difícil demonstrar que un sistema
sea seguro. Ross Anderson dice que la seguridad de computación es como
programar la computadora del Satán. Software seguro debe de funcionar abajo de
un ataque. Aunque casi todos los software tengan errores, la mayoría de los
errores nunca serán revelados debajo de circunstancias normales. Un atacante
busca esta debilidad para atacar un sistema.
La Confidencialidad es la propiedad de un documento o mensaje que únicamente
está autorizado para ser leído o entendido por algunas personas o entidades.Se
dice que un documento o mensaje es confidencial si éste sólo está autorizado a
ser leído o entendido por un destinatario designado.
CONFIDENCIALIDAD
Compromiso de no dar información sobre un hecho mas que a la persona
involucrada y a quienes ella autorice. Los resultados de análisis clínicos y en
especial el de VIH deben ser confidenciales. En la práctica muchos doctores,
incluyendo los de instancias públicas, comunican un resultado positivo a las
autoridades de quien depende la persona afectada, violando con ello la
confidencialidad y provocando en muchos casos el despido o la no aceptación en
un nuevo trabajo de la persona seropositiva.
La confidencialidad se refiere a que la información solo puede ser conocida por

individuos autorizados. Existen infinidad de posibles ataques contra la privacidad,
especialmente en la comunicación de los datos. La transmisión a través de un

medio presenta múltiples oportunidades para ser interceptada y copiada:

las líneas "pinchadas" la intercepción o recepción electromagnética no autorizada
o la simple intrusión directa en los equipos donde la información está físicamente
almacenada.
1.7.5 SEGURIDAD MULTINIVELES
La seguridad multinivel dispara el mercado antivirus y las aplicaciones de software

antivirus están experimentando un notable crecimiento como consecuencia del
gran incremento y la compleja naturaleza de la actividad de intrusión de los virus,
causantes de la infección masiva de sistemas y un importante impacto económico.
Con las mejoras que brindan los nuevos sistemas de protección multinivel en su
esfuerzo por combatir todos los perjuicios comunes más extendidos, las grandes
compañías en particular, están aumentando su inversión destinada a la
erradicación de los fallos de seguridad. El cambio gradual en la protección
multinivel contra los virus en el mercado empresarial, ofrece oportunidades a un
amplio abanico de vendedores de sistemas de seguridad.
La seguridad multinivel (MLS) proviene de los sistemas de alta seguridad

utilizados en Defensa, donde la información es manejada de acuerdo a su nivel de
sensibilidad y a los permisos que tiene la persona que desea acceder a ella, es
también actualmente, una de las mayores preocupaciones en el entorno
empresarial.
La seguridad multinivel tiene los siguientes aspectos diferenciales:
La suite protege la seguridad en todo momento, incluso antes del arranque

del sistema operativo.
Posibilidad de proteger la información mediante cifrado
Compatibilidad con DNI electrónico y Smartcards como tarjeta de
autenticación
Control de los dispositivos de almacenamiento que pueden conectarse al
PC (memorias USB, MP3, etc.)
Control de las aplicaciones que pueden ser ejecutadas
Nivel de seguridad adaptable a las necesidades de la empresa, con gestión
centralizada y políticas definibles en base a perfil de usuario, PC y
dispositivos concretos

La seguridad de software aplica los principios de la seguridad de

información al desarrollo de software. La seguridad de información se refiere a la
seguridad de información comúnmente como la protección de sistemas de
información contra el acceso desautorizado o la modificación de información, si
esta en una fase de almacenamiento, procesamiento o tránsito. También la
protege contra la negación de servicios a usuarios desautorizados y la provisión
de servicio a usuarios desautorizados, incluyendo las medidas necesarias para
detectar, documentar, y contrarear tales amenazas.
1.7.6 ANONIMATO
Anónimo proviene del griego anonymos "sin nombre", compuesto del prefijo
negativo an- "sin" y onoma "nombre".
El anonimato es el estado de una persona siendo anónima, es decir, que la

identidad de dicha persona es desconocida. El anonimato es la condición de la
persona que oculta su nombre o su personalidad, simplemente porque no se lo ha
identificado o porque la persona no puede o no quiere revelar su identidad.
El nombre de Peer-to-Peer anónimo puede entenderse como un nombre

equivocado. Esto es debido a su diseño, un nodo de la red debe tener pseudónimo
desde que tiene que tener una "dirección" para poder ser alcanzado por otro nodo
igual para intercambiar datos. Sin embargo, normalmente esta dirección,
especialmente en redes anónimas, no contiene ninguna información que pueda
permitir la identificación. Por tanto, un usuario es casi pero no completamente
anónimo. En las redes amigo-a-amigo, sólo tus amigos pueden saber que tu
dirección está siendo usada para intercambiar ficheros.
La navegación Web, algo que suele verse como una actividad anónima, temporal
e irrelevante. Pero cuando navegamos, es frecuente que vayamos dejando
muchos rastros respecto a lo que hacemos. Quizá a algunos no les importe todo
esto, a otros sí que les preocupará.

1.7.7 AUTENTICACIÓN
Autenticación o autentificación es el acto de establecimiento o confirmación de

algo (o alguien) como auténtico, es decir que reclama hecho por, o sobre la cosa
son verdadero. La autenticación de un objeto puede significar (pensar) la
confirmación de su procedencia, mientras que la autenticación de una persona a
menudo consiste en verificar su identidad. La autenticación depende de uno o
varios factores.
Autenticación o autentificación, en términos de seguridad de redes de datos, se

puede considerar uno de los tres pasos fundamentales (AAA). Cada uno de ellos
es, de forma ordenada:
Autenticación En la seguridad de ordenador, la autenticación es el proceso de

intento de verificar la identidad digital del remitente de una comunicación como
una petición para conectarse. El remitente siendo autenticado puede ser una
persona que usa un ordenador, un ordenador por sí mismo o un programa del
ordenador. En un web de confianza, "autenticación" es un modo de asegurar que
los usuarios son quién ellos dicen que ellos son - que el usuario que intenta
realizar funciones en un sistema es de hecho el usuario que tiene la autorización
para hacer así.
Autorización Proceso por el cual la red de datos autoriza al usuario identificado a

acceder a determinados recursos de la misma.
Auditoría Mediante la cual la red o sistemas asociados registran todos y cada uno
de los accesos a los recursos que realiza el usuario autorizados o no.
El problema de la autorización a menudo, es idéntico a la de autenticación;

muchos protocolos de seguridad extensamente adoptados estándar, regulaciones
obligatorias, y hasta estatutos están basados en esta asunción. Sin embargo, el
uso más exacto describe la autenticación como el proceso de verificar la identidad
de una persona, mientras la autorización es el proceso de verificación que una
persona conocida tiene la autoridad para realizar una cierta operación. La
autenticación, por lo tanto, debe preceder la autorización. Para distinguir la
autenticación de la autorización de término estrechamente relacionada, existen
unas notaciones de taquigrafía que son: A1 para la autenticación y A2 para la
autorización que de vez en cuando son usadas, también existen los términos
AuthN y AuthZ que son usados en algunas comunidades.

1.7.8 INTEGRIDAD
El término integridad de datos se refiere a la corrección y completitud de los

datos en una base de datos. Cuando los contenidos se modifican con sentencias
INSERT, DELETE o UPDATE, la integridad de los datos almacenados puede
perderse de muchas maneras diferentes. Pueden añadirse datos no válidos a la
base de datos, tales como un pedido que especifica un producto no existente.
Pueden modificarse datos existentes tomando un valor incorrecto, como por

ejemplo si se reasigna un vendedor a una oficina no existente. Los cambios en la
base de datos pueden perderse debido a un error del sistema o a un fallo en el
suministro de energía. Los cambios pueden ser aplicados parcialmente, como por
ejemplo si se añade un pedido de un producto sin ajustar la cantidad disponible
para vender.
Una de las funciones importantes de un DBMS relacional es preservar la

integridad de sus datos almacenados en la mayor medida posible.
Tipos de restricciones de integridad
Datos Requeridos: establece que una columna tenga un valor no NULL. Se

define efectuando la declaración de una columna es NOT NULL cuando la tabla
que contiene las columnas se crea por primera vez, como parte de la sentencia
CREATE TABLE.
Chequeo de Validez: cuando se crea una tabla cada columna tiene un tipo de
datos y el DBMS asegura que solamente los datos del tipo especificado sean
ingresados en la tabla.
Integridad de entidad: establece que la clave primaria de una tabla debe tener un
valor único para cada fila de la tabla; si no, la base de datos perderá su integridad.
Se especifica en la sentencia CREATE TABLE. El DBMS comprueba
automáticamente la unicidad del valor de la clave primaria con cada sentencia
INSERT Y UPDATE. Un intento de insertar o actualizar una fila con un valor de la
clave primaria ya existente fallará.
Integridad referencial: asegura la integridad entre las claves ajenas y primarias

(relaciones padre/hijo). Existen cuatro actualizaciones de la base de datos que
pueden corromper la integridad referencial:

La inserción de una fila hijo se produce cuando no coincide la clave ajena

con la clave primaria del padre.
La actualización en la clave ajena de la fila hijo, donde se produce una

actualización en la clave ajena de la fila hijo con una sentencia UPDATE y la
misma no coincide con ninguna clave primaria.
La supresión de una fila padre, con la que, si una fila padre -que tiene uno o más
hijos- se suprime, las filas hijos quedarán huérfanas.
La actualización de la clave primaria de una fila padre, donde si en una fila padre,
que tiene uno o más hijos se actualiza su clave primaria, las filas hijos quedarán
huérfanas.
1.8 CONOCER EL ENEMIGO
Medias de seguridad a tener en cuenta por las empresas:
Establecer una política adecuada en la que deben figurar cuáles son los
puntos críticos de la red corporativa y las medidas que se van a tomar para
protegerlos.
Instalar una solución de seguridad eficiente tanto en los equipos de los
trabajadores como en los servidores.
Las contraseñas de acceso a los equipos deber ser seguras.
Contar con programas y soluciones de seguridad actualizada y protección
en sus equipos portátiles y en sus redes inalámbricas.
Conocer quién accede a la información.
Realizar auditorías para saber qué ha pasado y cuándo y así poder
responder a las necesidades legales.
Establecer distintos perfiles de acceso a intranets y extranet.
Precauciones de los usuarios:
Mantener actualizados los programas.

No abrir corres que procedan de fuentes desconocidas.
No seguir ningún vínculo que llegue por correo o mensajería instantánea.
No ejecutar archivos que procedan de fuentes desconocidas.
No descargarse por P2P archivos sospechosos.
No conectar dispositivos móviles como llaves USB o PDA sin haberse
asegurado antes de que no están infectados.
Bloquear el equipo cuando no se esté en el puesto de trabajo.

1.9 META DE PROYECTO DE SOFTWARE
Las metas y los objetivos proporcionan la dirección uniforme en un proyecto y

aseguran una visión constante a través del cuerpo de tenedores de apuestas.
Idealmente, las metas y los objetivos sirven como referencia constante para la
toma de decisión relacionada con el proyecto.
Uso
Las metas y los objetivos son público los elementos de información disponibles
que se comparten normalmente o a través de la documentación de la reunión o
mientras que la información introductoria en los planes del proyecto y el otro
proyecto apoya la documentación. Las metas y los objetivos se utilizan para
unificar la visión del equipo y la organización con respecto a cuál debe el proyecto
lograr y el acercamiento general a lograr esa meta.
Pueden ser fijadas en una localización altamente visible para asegurarse de que
están fácilmente disponibles para todos los miembros del equipo. El teórico Peter
Drucker de la gerencia sugiere que las metas de un negocio conduzcan sus
objetivos específicos del trabajo, y que esos objetivos necesitan ser delineados
claramente para asegurar niveles más altos del funcionamiento.
Contenido
Las metas y los objetivos deben indicar claramente el intento de la organización, el

proyecto, y las tareas o el esfuerzo bajo consideración—y los objetivos de
trabajadores individuales en la organización deben ser complementarios en servir
la meta. Las declaraciones de la meta se fijan en un alto nivel, describiendo lo que
espera la organización alcanzar. Se atan de cerca a las declaraciones de la visión
en que las metas son descripciones de lo que espera la organización lograr. Las
metas se pueden construir en el nivel de organización (―hacer un innovador
reconocido del software cambiando cómo se diseña y se apoya el software‖) o en
un más detallado, proyecto llano (―proveer de la cumbre el software innovador de
la logística que apoya su seguir y mantenimiento del inventario‖). En cualquier
caso, las metas son las declaraciones generales que son apoyadas por objetivos.
Los objetivos sirven la meta. Proporcionan claramente, dirección inequívoca en

cómo las metas serán resueltas. Idealmente, deben estar suficientemente claros
que permiten autodominio y self-monitoring de los miembros del equipo a quienes
se dan, que significa que cada uno objetivo debe tener cierta forma métrica de
medida que refleje los valores de la organización s. Si la meta es proporcionar

software innovador de la logística a la cumbre de la ayuda, los objetivos

pudieron incluir el siguiente:
• Para proporcionar un sistema que proporciona la información en tiempo real con

respecto la localización, el almacenaje, y al envejecimiento materiales;
• Para proporcionar un sistema que responde con la dirección (detallada, paso a

paso) modificada para requisitos particulares en las fuentes alternativas para el
material que está fuera de acción o en fuente baja.
Los términos llegan a ser importantes en establecer metas y objetivos. La

asunción que cualquier cosa que puede ser malinterpretada será malinterpretada
es una asunción justa y razonable. Una visión de la persona s ―de la fuente baja‖
pudo ser diferente que otros. El esfuerzo en objetivos del edificio es reducir al
mínimo la ambigüedad tanto como es posible y razonable.
Acercamientos
Una línea blurry existe entre las metas y los objetivos y entre los objetivos y los
requisitos. Como tal, una declaración general de la meta ―de la persona‖ s se
pudo detallar suficientemente para ser un objetivo para algún otro
(particularmente alguien en un nivel más alto en la organización). Porque los
objetivos se deben rendir tan claramente como sea posible, el esfuerzo de
construir en el nivel apropiado del detalle genera a veces los requisitos nacientes.
Para construir metas y objetivos mejores, las metas deben tratar el estado futuro
del proyecto, entregable, o de la organización. Los objetivos deben indicar cómo
el equipo y el proyecto trabajarán en esa dirección.
En algunas organizaciones, la declaración objetiva se liga siempre a las

limitaciones del momento específico y del coste.
Consideraciones
Porque las metas y los objetivos proporcionan la dirección, deben ser

declaraciones públicas. En reuniones y en instalaciones del proyecto, los objetivos
y las metas de un proyecto se deben fijar claramente para asegurar familiaridad
del equipo con la documentación. Tal franqueza sobre las metas y los objetivos
puede imposibilitar algo de las riñas inherentes a veces evidentes cuando los
miembros del equipo de proyecto se parecen trabajar en los propósitos cruzados.

Unidad II
Administración de los riesgos en la seguridad del software
Objetivo: El alumno conocerá e identificará los riesgos que se tienen al poner en

práctica la seguridad del software, así como los mecanismos para la evaluación
del desarrollo de sistemas seguros.
Contenido:
2.1 Descripción de la administración de los riesgos en la Seguridad del

Software
2.2 Administración de los riesgos en la seguridad del Software en la

práctica
2.2.1 Pruebas de Caja Negra

2.2.2 Equipo Rojo
2.3 Criterios Comunes

2.1 DESCRIPCIÒN DE LA ADMINISTRACIÒN DE LOS RIESGOS EN LA

SEGURIDAD DEL SOFTWARE
La administración de riesgo es un proceso de identificación y análisis de riesgos y

de creación de un plan para administrarlos. Un riesgo de seguridad se define
como la pérdida esperada debida o como consecuencia de amenazas anticipadas
por vulnerabilidades del sistema y la fuerza y determinación de los agentes
amenazantes correspondientes.
Identificación de los riesgos de seguridad
La identificación de los riesgos de seguridad es el primer paso en la evaluación de

la seguridad de la organización. Para administrar el riesgo de seguridad de forma
eficaz, debe establecerse claramente de modo que el equipo del proyecto llegue a
un consenso y se disponga a analizar las consecuencias y crear un plan de acción
para solucionar el riesgo. Aunque el ámbito del riesgo de seguridad está limitado a
la tecnología que el equipo del proyecto trata de proteger, la atención del equipo
debe ser lo suficientemente amplia como para abordar todas las fuentes de
riesgos de seguridad, incluido la tecnología, proceso, entorno y personas.
Actividades de identificación de riesgos
Durante el paso de identificación de riesgos de seguridad, el equipo deberá indicar

o enumerar de forma precisa los problemas de seguridad mediante la declaración
concisa de los riesgos a los que se enfrenta la organización. Resulta útil organizar
una serie de talleres o sesiones de brainstorming del equipo de seguridad con el
objetivo de identificar los riesgos asociados con una nueva situación.
Debido al cambio constante de la tecnología y los entornos, es importante que la

identificación de riesgos de seguridad no se considere una actividad aislada, sino
que el proceso debe repetirse periódicamente durante el ciclo de vida de las
operaciones de la organización.
Enfoque estructurado
El uso de un enfoque estructurado con relación a la administración de riesgos de

seguridad es fundamental porque permite que todos los miembros del equipo
utilicen un mecanismo sólido para tratar los problemas de seguridad. La
clasificación de las amenazas durante este paso es una forma útil de proporcionar
un enfoque sólido, reproducible y perceptible.

Desarrollo de las soluciones a los riesgos de seguridad
El desarrollo de las soluciones a los riesgos de seguridad es el proceso por el que

se toman los planes que se han creado en la fase de evaluación y se utilizan para
generar una nueva estrategia de seguridad que incluya administración de
configuración y revisiones, supervisión y auditoría del sistema, y directivas y
procedimientos operativos. Dado que se desarrollan diversas contramedidas, es
importante realizar un seguimiento e informe minuciosos de este proceso.
Declaración de riesgos de seguridad
Una declaración de riesgos de seguridad es una expresión del lenguaje normal de

la relación causal entre el estado de seguridad existente de la organización y un
resultado posible que no se ha realizado.
La primera parte de la declaración de riesgos de seguridad se denomina "la

condición", en la que se proporciona la descripción de un estado existente o
amenaza potencial que el equipo considera que puede causar algún daño. La
segunda parte de la declaración de riesgos se denomina "consecuencia", y en ella
se describe la pérdida no deseada de confidencialidad, integridad y disponibilidad
de un activo.
Las dos declaraciones están unidas por un término como "entonces" o "puede
resultar en" que implica una relación no confiable (es decir, menos del 100%) o
causal.
Modelo de proceso de seguridad
El modelo de proceso MSF se puede usar para desarrollar aplicaciones de

software e implementar tecnología de infraestructura. Este modelo sigue un ciclo
iterativo diseñado para abordar cambios de los requisitos de proceso en ciclos de
desarrollo cortos y versiones incrementales de la solución. Esto es posible gracias
a la administración de riesgo continua y los ciclos de pruebas.
Marco de administración de riesgos de seguridad

Descripción general
El marco utiliza el modelo de proceso MSF y describe una secuencia de alto nivel
de actividades para la creación e implementación de las soluciones de seguridad
de TI. En lugar de recomendar una determinada serie de procedimientos, el marco
es lo suficientemente flexible como para incorporar una amplia gama de procesos

de TI. El modelo de proceso abarca el ciclo de vida de una solución desde

el inicio del proyecto hasta la implementación activa.
Figura 1

2.2 ADMINISTRACIÒN DE LOS RIESGOS EN LA SEGURIDAD DEL

SOFTWARE EN LA PRÀCTICA
Prácticas de administración de riesgos de seguridad y de marco de

seguridad
Mientras se ejecuta el plan de seguridad, se llevan a cabo dos tipos de actividades

de administración de riesgo durante el ciclo de vida del proyecto. La primera es
administrar el riesgo inherente al propio proyecto y la segunda es administrar el
riesgo asociado a los componentes de seguridad. Los riesgos del proyecto se
evalúan sólo durante el ciclo de vida del proyecto, mientras que los riesgos de
seguridad se deben evaluar durante el ciclo de vida completo de la solución o el
sistema. La disciplina de administración de riesgo MSF sirve como base para la
administración de riesgos de las evaluaciones de los proyectos y de la seguridad.
La seguridad del sistema informático se debe realizar de forma preventiva y

continua para garantizar la seguridad de los activos de información y supervisar
nuevas amenazas y vulnerabilidades. Siempre que se agreguen funcionalidades
nuevas a la infraestructura de tecnología de la organización deberá tomarse en
cuenta la seguridad de la información. Además, es posible que algunos procesos y
procedimientos empresariales deban alterarse para operar en el entorno
modificado y proporcionar protección a los activos de información nuevos.
Los nueve pasos de la Disciplina de administración de riesgos de seguridad en la

práctica son:
1. Evaluación y valoración del activo

2. Identificación de los riesgos de seguridad
3. Análisis y ordenación según prioridad de los riesgos de seguridad
4. Seguimiento, planeamiento y programación de los riesgos de seguridad
desarrollo e implementación
5. Desarrollo de las soluciones de seguridad
6. Pruebas de las soluciones de seguridad
7. Obtención de información sobre seguridad
Operación
8. Reevaluación de los riesgos de seguridad y los activos nuevos y cambiados
9. Estabilización e implementación de contramedidas nuevas o cambiadas

Análisis de los riesgos de seguridad
El análisis de los riesgos de seguridad se utiliza para examinar los posibles

ataques, herramientas, métodos y técnicas que permiten explotar una posible
vulnerabilidad. Se trata de un método de identificación de riesgos y evaluación de
posibles daños que podrían producirse para justificar las salvaguardas de
seguridad.
Un análisis de este tipo presenta tres objetivos principales: identificar riesgos,

cuantificar la repercusión de posibles amenazas y proporcionar un balance
económico entre el efecto del riesgo y el coste de la contramedida. Se recopila
información para calcular el nivel de riesgo de modo que el equipo pueda tomar
decisiones razonables y centrar todos los esfuerzos en la solución de los riesgos
de seguridad.
Este análisis se utiliza posteriormente para dar prioridad a los riesgos de
seguridad y permitir a la organización asignar recursos con los que se
solucionarán los problemas de seguridad más importantes.
Un análisis de riesgo permite integrar los objetivos del programa de seguridad en
los objetivos y requisitos comerciales de la compañía. Cuanto más coordinados
resulten los objetivos comerciales y los de seguridad, más fácil será cumplirlos.
Etapa: Pruebas
La prueba del software es un elemento crítico para la garantía de la calidad del

software. El objetivo de la etapa de pruebas es garantizar la calidad del producto
desarrollado. Además, esta etapa implica:
Verificar la interacción de componentes.

Verificar la integración adecuada de los componentes.
Verificar que todos los requisitos se han implementado correctamente.
Identificar y asegurar que los defectos encontrados se han corregido antes
de entregar el software al cliente.
Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de
errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
La prueba no es una actividad sencilla, no es una etapa del proyecto en la cual se

asegura la calidad, sino que la prueba debe ocurrir durante todo el ciclo de vida:
podemos probar la funcionalidad de los primeros prototipos; probar la estabilidad,
cobertura y rendimiento de la arquitectura; probar el producto final, etc.

Plan de Pruebas
Un plan de pruebas está constituido por un conjunto de pruebas. Cada prueba

debe:
dejar claro qué tipo de propiedades se quieren probar (corrección, robustez,

fiabilidad, amigabilidad, ...)
dejar claro cómo se mide el resultado
especificar en qué consiste la prueba (hasta el último detalle de cómo se
ejecuta)
definir cual es el resultado que se espera (identificación, tolerancia, ...)
¿Cómo se decide que el resultado es acorde con lo esperado?
La prueba es un proceso que se enfoca sobre la lógica interna del software y las
funciones externas. La prueba es un proceso de ejecución de un programa con la
intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta
probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene
éxito si descubre un error no detectado hasta entonces.
La prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que

existen defectos en el software.
2.2.1 PRUEBA DE CAJA NEGRA
Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente

indiferente el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretende demostrar que:
Las funciones del software son operativas.

La entrada se acepta de forma adecuada.
Se produce una salida correcta, y
La integridad de la información externa se mantiene.
Se derivan conjuntos de condiciones de entrada que ejerciten completamente

todos los requerimientos funcionales del programa.
La prueba de la caja negra intenta encontrar errores de las siguientes categorías:
Funciones incorrectas o ausentes.

Errores de interfaz.
Errores en estructuras de datos o en accesos a bases de datos externas.

Errores de rendimiento.
Errores de inicialización y de terminación.
Los casos de prueba deben satisfacer los siguientes criterios:
Reducir, en un coeficiente que es mayor que uno, el número de casos de

prueba adicionales.
Que digan algo sobre la presencia o ausencia de clases de errores.
Métodos de prueba de caja negra
Algunos de los métodos empleados en las pruebas de caja negra son los
siguientes:
Métodos de prueba basados en grafos: en este método se debe entender

los objetos (objetos de datos, objetos de programa tales como módulos o
colecciones de sentencias del lenguaje de programación) que se modelan
en el software y las relaciones que conectan a estos objetos. Una vez que
se ha llevado a cabo esto, el siguiente paso es definir una serie de pruebas
que verifiquen que todos los objetos tienen entre ellos las relaciones
esperadas. En este método:
1. Se crea un grafo de objetos importantes y sus relaciones.
2. Se diseña una serie de pruebas que cubran el grafo de manera que
se ejerciten todos los objetos y sus relaciones para descubrir errores.
Describe un número de modelados para pruebas de comportamiento que pueden

hacer uso de los grafos:
 Modelado del flujo de transacción. Los nodos representan los pasos de

alguna transacción (por ejemplo, los pasos necesarios para una reserva en
una línea aérea usando un servicio en línea), y los enlaces representan las
conexiones lógicas entre los pasos (por ejemplo, vuelo, información,
entrada es seguida de validación /disponibilidad, procesamiento).
 Modelado de estado finito. Los nodos representan diferentes estados del
software observables por el usuario (por ejemplo, cada una de las pantallas
que aparecen cuando un telefonista coge una petición por teléfono), y los
enlaces representan las transiciones que ocurren para moverse de estado a
estado (por ejemplo, petición-información se verifica durante inventario-
disponibilidad-búsqueda y es seguido por cliente-factura-información-
entrada).

 Modelado de flujo de datos. Los nodos objetos de datos y los

enlaces son las transformaciones que ocurren para convertir un objeto de
datos en otro.
 Modelado de planificación. Los nodos son objetos de programa y los
enlaces son las conexiones secuenciales entre esos objetos. Los pesos de
enlace se usan para especificar los tiempos de ejecución requeridos al
ejecutarse el programa.
 Gráfica Causa-efecto. La gráfica Causa-efecto. representa una ayuda
gráfica en seleccionar, de una manera sistemática, un gran conjunto de
casos de prueba. Tiene un efecto secundario beneficioso en precisar
estados incompletos y ambigüedades en la especificación.
Un gráfico de causa-efecto es un lenguaje formal al cual se traduce una

especificación. El gráfico es realmente un circuito de lógica digital (una red
combinatoria de lógica), pero en vez de la notación estándar de la electrónica, se
utiliza una notación algo más simple. No hay necesitad de tener conocimiento de
electrónica con excepción de una comprensión de la lógica booleana (entendiendo
los operadores de la lógica y, o, y no).
Partición equivalente: Presenta la partición equivalente como un método

de prueba de caja negra que divide el campo de entrada de un programa en
clases de datos de los que se pueden derivar casos de prueba. Un caso de
prueba ideal descubre de forma inmediata una clase de errores que, de otro
modo, requerirían la ejecución de muchos casos antes de detectar el error
genérico. La partición equivalente se dirige a la definición de casos de
prueba que descubran clases de errores, reduciendo así el número total de
casos de prueba que hay que desarrollar.
Una clase de equivalencia representa un conjunto de estados válidos o no válidos

para condiciones de entrada. Típicamente, una condición de entrada es un valor
numérico específico, un rango de valores, un conjunto de valores relacionados o
una condición lógica.
El objetivo de partición equivalente es reducir el posible conjunto de casos de

prueba en uno más pequeño, un conjunto manejable que evalúe bien el software.
Se toma un riesgo porque se escoge no probar todo. Así que se necesita tener
mucho cuidado al escoger las clases.
La partición equivalente es subjetiva. Dos probadores quienes prueban un

programa complejo pueden llegar a diferentes conjuntos de particiones.

En el diseño de casos de prueba para partición equivalente se procede en

dos pasos:
1. Se identifican las clases de equivalencia. Las clases de equivalencia son

identificadas tomando cada condición de entrada (generalmente una
oración o una frase en la especificación) y repartiéndola en dos o más
grupos. Es de notar que dos tipos de clases de equivalencia están
identificados: las clases de equivalencia válidas representan entradas
válidas al programa, y las clases de equivalencia inválidas que representan
el resto de los estados posibles de la condición (es decir, valores erróneos
de la entrada).
2. Se define los casos de prueba. El segundo paso es el uso de las clases
de equivalencia para identificar los casos de prueba. El proceso es como
sigue: se asigna un número único a cada clase de equivalencia. Hasta que
todas las clases de equivalencia válidas han sido cubiertas por los casos de
prueba, se escribe un nuevo caso de prueba que cubra la clase de
equivalencia válida. Y por último hasta que los casos de prueba hallan
cubierto todas las clases de equivalencia inválidas, se escribe un caso de la
prueba que cubra una, y solamente una, de las clases de equivalencia
inválidas descubiertas.
Prueba de la tabla ortogonal: hay aplicaciones donde el número de parámetros

de entrada es pequeño y los valores de cada uno de los parámetros está
claramente delimitado. Cuando estos números son muy pequeños (por ejemplo, 3
parámetros de entrada tomando 3 valores diferentes), es posible considerar cada
permutación de entrada y comprobar exhaustivamente el proceso del dominio de
entrada. En cualquier caso, cuando el número de valores de entrada crece y el
número de valores diferentes para cada elemento de dato se incrementa, la
prueba exhaustiva se hace impracticable.
La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de

entrada es relativamente pequeño pero demasiado grande para posibilitar pruebas
exhaustivas. El método de prueba de la tabla ortogonal es particularmente útil al
encontrar errores asociados con fallos localizados -una categoría de error
asociada con defectos de la lógica dentro de un componente software.

2.2.2 EQUIPO ROJO
A finales de 1996, Dan Farmer (creador de una de las herramientas más útiles en
la detección de intrusos: SATAN) realizó un estudio sobre seguridad analizando
2.203 sistemas de sitios en Internet. Los sistemas objeto del estudio fueron Web
Sites orientados al comercio y con contenidos específicos, además de un conjunto
de sistemas informáticos aleatorios con los que realizar comparaciones.
El estudio se realizó empleando técnicas sencillas y no intrusivas. Se dividieron los
problemas potenciales de seguridad en dos grupos: rojos (red) y amarillos
(yellow).
Los problemas del grupo rojo son los más serios y suponen que el sistema está
abierto a un atacante potencial, es decir, posee problemas de seguridad conocidos
en disposición de ser explotados. Así por ejemplo, un problema de seguridad del
grupo rojo es un equipo que tiene el servicio de FTP anónimo mal configurado.
Los problemas de seguridad del grupo amarillo son menos serios pero también
reseñables. Implican que el problema detectado no compromete inmediatamente
al sistema pero puede causarle serios daños o bien, que es necesario realizar
tests más intrusivos para determinar si existe o no un problema del grupo rojo.
La Agencia de Seguridad Nacional americana, una de los organismos más

poderosos del planeta, ayudó a mejorar la seguridad de Windows Vista.
(DT, AGENCIAS) El Washington Post publico que la agencia ha admitido su
'colaboración no específica' en Vista. Tony Sager, el jefe de análisis de
vulnerabilidades y del grupo de operaciones de la NSA, le dijo al rotativo que la
intención de esta agencia era la de ayudar a todo el mundo en todo lo posible. La
NSA utilizó un equipo azul y otro rojo para analizar el software. El equipo rojo tenía
el rol de tratar de corromper o robar información como si de un "adversario
técnicamente competente y muy decidido" se tratase. El equipo azul ayudó a los
administradores del departamento de defensa con la configuración de Windows
Vista.

2.3 CRITERIOS COMUNES
Los Criterios Comunes(CC) tienen su origen en 1990 y surgen como resultado de

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

en otras áreas distintas de TI pero no se hace ninguna declaración de

competencia fuera del estricto ámbito de la seguridad de TI.
Los CC son aplicables a las medidas de seguridad de TI implementadas en
hardware, firmware o software. Cuando se pretenda tratar aspectos particulares de
evaluación a aplicar sólo en determinados métodos de implementación, se
indicará expresamente en las declaraciones de los criterios correspondientes.
Algunos temas, porque involucran técnicas especializadas o porque son, de
alguna manera, adyacentes a la seguridad de TI, son considerados ajenos a la
finalidad de los CC.
Entre estos cabe destacar los siguientes:
 Los CC no contienen criterios de evaluación de la seguridad

correspondientes a medidas de seguridad administrativa no relacionadas
directamente con las medidas de seguridad de TI. Sin embargo, se
reconoce que una parte significativa de la seguridad de un TOE puede, a
menudo, proporcionarse a través de medidas administrativas
(organizativas, de personal, físicas y control de procedimientos). Las
medidas de seguridad administrativas, en el entorno operativo del TOE, son
tratadas como hipótesis de un uso seguro donde éstas tienen un impacto
importante en la capacidad de las medidas de seguridad de TI para
contrarrestar las amenazas identificadas.
 La evaluación de aspectos técnicos físicos de la seguridad de TI como

control de radiaciones electromagnéticas no se trata específicamente,
aunque varios de los conceptos tratados serán aplicables en esta área. En
particular, los CC tratan algunos aspectos de la protección física del TOE.
 Los CC no tratan ni la metodología de evaluación ni el marco administrativo

y legal bajo el cual los criterios pueden ser aplicados por las autoridades de
evaluación. Sin embargo, se espera que los CC sean usados para
propósitos de evaluación en el contexto de un determinado marco
administrativo y con una determinada metodología.
 Los procedimientos para el uso de los resultados de la evaluación en la

acreditación de productos o sistemas están fuera del objetivo de los CC. La
acreditación de un producto o sistema es el proceso administrativo por el
que se autoriza el uso de dicho producto o sistema de TI en su entorno
operativo. La evaluación se centra en las partes de seguridad de TI del
producto o sistema y en aquellas partes del entorno operativo que pueden

afectar directamente el seguro uso de los elementos de TI. Los

resultados del proceso de evaluación son, por lo tanto, un dato de valor
para el proceso de acreditación. Sin embargo, como hay otras técnicas más
apropiadas para la valoración, tanto de las propiedades de seguridad de un
producto o sistema no relacionados con TI, como de su relación con las
partes de seguridad de TI, los acreditadores deberán establecer
separadamente estos aspectos.
 Los criterios para la valoración de las cualidades inherentes de los

algoritmos criptográficos no se tratan en los CC. Si se necesita una
valoración independiente de las propiedades matemáticas de la criptografía
introducida en un TOE, deberá ser proporcionada por el esquema bajo el
cual se están aplicando los CC.
Funcionamiento
Con el fin de poder certificar un producto según los Criterios Comunes se deben
comprobar, por parte de uno de los laboratorios independientes aprobados,
numerosos parámetros de seguridad que han sido consensuados y aceptados por
22 países de todo el mundo. El proceso de evaluación incluye la certificación de
que un producto software específico verifica los siguientes aspectos:
Los requisitos del producto están definidos correctamente.

Los requisitos están implementados correctamente.
El proceso de desarrollo y documentación del producto cumple con ciertos
requisitos previamente establecidos.
Los Criterios Comunes establecen entonces un conjunto de requisitos para definir

las funciones de seguridad de los productos y sistemas de Tecnologías de la
Información y de los criterios para evaluar su seguridad. El proceso de evaluación,
realizado según lo prescrito en los Criterios Comunes, garantiza que las funciones
de seguridad de tales productos y sistemas reúnen los requisitos declarados. Así,
los clientes pueden especificar la funcionalidad de seguridad de un producto en
términos de perfiles de protección estándares y de forma independiente
seleccionar el nivel de confianza en la evaluación de un conjunto definido desde el
EAL1 al EAL7.

Perfiles de protección
Un perfil de protección (Protection Profile) define un conjunto de objetivos y

requisitos de seguridad, independiente de la implantación, para un dominio o
categoría de productos que cubre las necesidades de seguridad comunes a varios
usuarios. Los perfiles de protección son reutilizables y normalmente públicos y
están compuestos de:
Requisitos funcionales (SFR, Security Funcional Requirement)

proporcionan mecanismos para hacer cumplir la política de seguridad.
Como ejemplos de requisitos funcionales mencionar la protección de datos
de usuario, el soporte criptográfico, la autenticación, la privacidad o el
control de acceso.
Requisitos de confianza o aseguramiento (SAR, Security Assurance
Requirement) proporcionan la base para la confianza en que un producto
verifica sus objetivos de seguridad.
Los requisitos de confianza se han agrupado en niveles de confianza en la

evaluación (EAL, Evaluation Assurance Levels) que contienen requisitos de
confianza construidos específicamente en cada nivel. Los EALs proporcionan una
escala incremental que equilibra el nivel de confianza obtenido con el coste y la
viabilidad de adquisición de ese grado de confianza. El incremento de confianza
de un EAL a otro se obtiene incrementando rigor, alcance y/o profundidad en el
componente y añadiendo componentes de confianza de otras familias de
confianza (por ejemplo, añadiendo nuevos requisitos funcionales).
Niveles de confianza
Los niveles de confianza en la evaluación definidos en el ISO/IEC 15408-3 [ISO

15408-3 2005] van desde EAL1 (el menor) a EAL 7 (el mayor) y se definen de
forma acumulativa (verificaciones de nivel n+1 implican realizar las de nivel n, 1 ≤
n ≥ 7):
 EAL1 (funcionalidad probada): es aplicable donde se requiere tener cierta

confianza de la operación correcta, y donde además, las amenazas a la
seguridad no son vistas como serias. Una evaluación en este nivel debe
proporcionar evidencia de que las funciones del objeto de evaluación son
consistentes con su documentación, y que proporcionan protección útil
contra amenazas identificadas.

 EAL2 (estructuralmente probado): requiere la cooperación del

desarrollador en términos de la distribución de la información del diseño, y
los resultados de las pruebas y proporciona confianza a través de un
análisis de las funciones de seguridad, usando una especificación funcional
y de interfaz, manuales y diseño de alto nivel del producto para entender el
comportamiento de seguridad. Además, en este nivel se verifica que el
desarrollador realizó un análisis de vulnerabilidades a través de la ejecución
de pruebas de caja negra (Black-box).
 EAL3 (probado y verificado metódicamente): permite a un desarrollador

alcanzar una máxima garantía de ingeniería de seguridad positiva en el
estado de diseño sin la alteración substancial de prácticas de desarrollo
válidas existentes. El análisis en este nivel se apoya en las pruebas de caja
gris (grey box), la confirmación selectiva independiente de los resultados de
las pruebas del desarrollador, y la evidencia de búsqueda de
vulnerabilidades obvias del desarrollador. Además, se realizan controles del
entorno de desarrollo y de gestión de configuración del producto.
 EAL4 (diseñado, probado y revisado metódicamente): este nivel le

permite a un desarrollador alcanzar máxima garantía de ingeniería de
seguridad positiva basada en buenas prácticas de desarrollo comercial, las
cuales, aunque rigurosas, no requieren del conocimiento especializado
substancial, destreza, ni otros recursos. En este caso, el análisis se apoya
en el diseño de bajo nivel de los módulos del producto y se realiza
búsqueda de vulnerabilidades independiente de las pruebas realizadas por
el desarrollador.
 EAL5 (diseñado y probado semiformalmente): permite a un desarrollador
alcanzar máxima garantía de ingeniería de seguridad positiva mediante la
aplicación moderada de técnicas de ingeniería de seguridad. La confianza
se apoya, en este caso, en un modelo formal y una presentación
semiformal de la especificación funcional y el diseño de alto nivel. La
búsqueda de vulnerabilidades debe asegurar la resistencia relativa a los
ataques de penetración.
 EAL6 (diseño verificado y probado semiformalmente): permite a los

desarrolladores alcanzar una alta garantía en la aplicación de técnicas de
ingeniería de seguridad para un entorno de desarrollo riguroso y donde el
objeto de evaluación es considerado de gran valor para la protección del
alto costo o estimación de esos bienes contra riesgos significativos.
Además, es aplicable para el desarrollo de objetos de evaluación,
destinados a salvaguardar la seguridad informática en situaciones de alto

riesgo donde el valor de los bienes protegidos justifica los costos

adicionales. El análisis en este nivel se apoya en un diseño modular y en
una presentación estructurada de la implementación del producto. La
búsqueda de vulnerabilidades debe mostrar una alta resistencia a los
ataques de penetración.
 EAL7 (diseño verificado y probado formalmente): es aplicable al

desarrollo de objetos de evaluación de seguridad, para su aplicación en
situaciones de muy alto riesgo o donde el alto valor de los bienes justifica
los más altos costos. La aplicación práctica del nivel EAL7 está limitada
actualmente a objetos de evaluación con seguridad estrechamente
enfocada a la funcionalidad, y que es sensible al análisis formal y extenso.
Este EAL representa un incremento
Significativo respecto a la garantía de nivel EAL6 a través del requisito de análisis

de gran amplitud, mediante representaciones formales y correspondencia formal y
pruebas de gran amplitud. Además, el evaluador confirmará de forma
independiente y completa los resultados de las pruebas de caja blanca (White-
box) realizadas por el desarrollador.
Los niveles EAL 5 al 7 incluyen modelos y demostraciones semiformales y

formales por tanto, se aplican a productos con objetivos de seguridad muy
específicos (entorno militar, por ejemplo). Por otra parte, estos niveles requieren
de la generación de una gran cantidad de documentación durante el proceso de
desarrollo que debe entregarse al evaluador para que éste pueda confirmar la
información. Finalmente, para la aplicación de los Criterios Comunes, existe una
metodología con los criterios a evaluar para cada uno de los niveles de confianza
estandarizada por la Norma ISO/IEC 18045 (ISO 18045, 2008) y denominada
CEM (Common Methodology for IT Security Evaluation) disponible en la web de
Common Criteria.

Unidad III
Código abierto o cerrado
Objetivo: El alumno conocerá los mecanismos que emplea la industria del

software para proteger sus códigos, tanto de los competidores como de los
crackers; así como las ventajas y desventajas del código abierto.
Contenido:
3.1 Seguridad por Oscuridad

3.2 Ingeniería en Reversa
3.3 Código Fuente Abierto
3.4 Falacias del código abierto

3.1 SEGURIDAD POR OSCURIDAD
Seguridad: certeza, firmeza, confianza. Sin riesgo.

Oscuridad: Puedes estar seguro... de que, al final la vulnerabilidad será
encontrada.
Definición de seguridad por oscuridad:

En criptografía y seguridad informática, la seguridad por oscuridad o por
ocultación es un controvertido principio de ingeniería de la seguridad, que intenta
utilizar el secreto (de diseño, de implementación, etc.) para garantizar la
seguridad. Un sistema que se apoya en la seguridad por ocultación puede tener
vulnerabilidades teóricas o prácticas, pero sus propietarios o diseñadores creen
que esos puntos débiles no se conocen, y que es probable que los atacantes no
los descubran
Argumentos
Si la seguridad de un sistema depende única o principalmente de mantener oculta
una debilidad. Se argumenta que permitir a cualquier persona revisar la seguridad
repercutirá en una pronta identificación y corrección de cualquier fallo o debilidad.
Introducción
La seguridad por oscuridad es la creencia de que cualquier sistema puede ser

seguro mientras nadie fuera de su grupo de implementación de seguridad se le
permita conocer nada de sus mecanismos internos. Ocultando contraseñas en
archivos binarios o esconder scripts suponiendo que "nadie lo va a encontrar
nunca" es un buen ejemplo de Seguridad por oscuridad.
La seguridad por oscuridad es la principal filosofía de las agencias burocráticas, y

es el método más utilizado para proveer "pseudoseguridad" en sistemas de
cómputo.
Esta filosofía ha ido decreciendo en el mundo de la computación con el aumento

de los sistemas abiertos, Internet, la mayor comprensión de técnicas de
programación, y también el crecimiento de conocimiento computacional en una
persona promedio.
Las bases de la seguridad por oscuridad es que si una persona no sabe como
hacer algo para tener un impacto en la seguridad del sistema, entonces esa
persona no es peligrosa.

Sin duda, esto es en teoría, ya que esto te ata a confiar en un pequeño

grupo de personas, tanto tiempo, como el que ellos vivan. Si tus empleados tiene
una mejor oferta o les pagan mejor en otro lugar, sus conocimientos se van con
ellos, ya sea que ese conocimiento sea reemplazable o no. Una vez que los
secretos están fuera, ahí esta el fin de nuestra seguridad.
Actualmente hay una gran necesidad de los usuarios ordinarios por conocer
detalles de como funciona su sistema como nunca antes, y como resultado la
Seguridad por oscuridad falla. Hoy en día muchos usuarios tienen conocimientos
avanzados de como funcionan sus sistemas operativos, y porque toda su
experiencia le permite obtener todo el conocimiento que el "necesite obtener".
Esto esquiva todas las bases de la seguridad por oscuridad, y hace tu seguridad
inútil.
Por lo tanto actualmente existe la necesidad de crear sistemas que intenten ser
algorítmicamente seguros (Kerberos, Secure RPC), que es mejor que ser
filosóficamente seguro.
El sistema "Shadow" para contraseñas en muchas ocasiones se incluyen en el

grupo de la seguridad por oscuridad, pero esto es incorrecto, ya que la seguridad
por oscuridad depende de restringir el acceso a algún algoritmo o técnica,
mientras que las contraseñas Shadow nos proveen seguridad restringiendo el
acceso a datos vitales.
Argumentos contra la seguridad por oscuridad
Muchos argumentan que la seguridad por oscuridad es débil. Si la seguridad de un

sistema depende única o principalmente de mantener oculta una debilidad,
entonces, claramente, si esa debilidad es descubierta, la seguridad se
compromete fácilmente. Se argumenta que mantener ocultos los detalles de
sistemas y algoritmos ampliamente utilizados es difícil. En criptografía, por
ejemplo, hay un buen número de ejemplos de algoritmos de cifrado que han
pasado a ser de conocimiento público, bien por ingeniería inversa bien por una
fuga de información.
Más aún, el mantener algoritmos y protocolos ocultos significa que la revisión de

seguridad está limitada a unos pocos. Se argumenta que permitir a cualquier
persona revisar la seguridad repercutirá en una pronta identificación y corrección
de cualquier fallo o debilidad.

En la práctica
Los operadores, desarrolladores y vendedores de sistemas que confían en la

seguridad por oscuridad a menudo mantienen en secreto que sus sistemas tienen
fallos, para evitar crear desconfianza en sus servicios o productos y por tanto, en
su imagen de mercado. Es posible que esto pudiera conducir en algunos casos a
una representación fraudulenta de la seguridad de sus productos, aunque la
aplicación de la ley a este respecto ha sido poco contundente, en parte porque las
condiciones de uso impuestas por los vendedores como parte del contrato de
licencia redimen (con más o menos éxito) sus aparentes obligaciones bajo el
estatuto legal de muchas jurisdicciones que requieren una adecuación para el uso
o estándares de calidad similares.
A menudo esos diseñadores o vendedores, o incluso ejecutivos, realmente creen

que han garantizado la seguridad al mantener el diseño del sistema en secreto.
Para quienes abordan la seguridad de esta manera les resulta difícil tener la
suficiente perspectiva para darse cuenta de que están dirigiéndose a un problema,
y a veces un gran problema. El autoengaño o la ignorancia son generalmente
problemas muy difíciles que tienen consecuencias (casi universalmente)
desafortunadas.
Cuando se usa software seguro por estar oculto de manera amplia, existe un
riesgo potencial de problema global; por ejemplo, vulnerabilidades en las
diferentes versiones del sistema operativo Windows o sus componentes
obligatorios como su navegador web Internet Explorer, o sus aplicaciones de
correo electrónico (Microsoft Outlook o Outlook Express) han causado problemas
a lo largo y ancho del planeta cuando virus, troyanos, gusanos y demás se han
aprovechado de ellas.
Seguridad por diseño Vs Seguridad por oscuridad
Cuando hablamos de seguridad por oscuridad, aunque el nombre asuste un poco,

nos estamos refiriendo a que se utiliza el secreto para garantizar la seguridad de
algún programa, como ser un sistema operativo, navegador web, etc., este es el
caso del software de código cerrado o propietario, en donde los desarrolladores
quizás conocen que el software tiene agujeros de seguridad pero, como nadie
tiene acceso al código, confían en este secreto siga siendo secreto para evitar que
dichas vulnerabilidades sean explotadas. Cuidado, esto no quiere decir que todo el
software propietario base su seguridad en este concepto, pero si que los más
grandes ejemplos de agujeros y vulnerabilidades que aprovechan este tipo de

seguridad se han dado en este tipo de software. Para que entendamos un

poquito mejor, hagamos una analogía. Supongamos que a la llave de nuestra casa
la escondemos abajo del felpudo de la puerta de entrada cuando salimos de
vacaciones, solo nosotros sabemos que la llave está escondida ahí y confiamos
que nadie más sabe la ubicación de la misma y creemos que es muy improbable
que un ladrón la encuentre.
Por otro lado, existe lo que se llama seguridad por diseño, esta es aplicada
claramente en aplicaciones que son de código abierto, en donde la seguridad de
los programas se basa en el diseño de los mismos el cual es conocido por todos,
inclusive los atacantes, un ejemplo claro es el caso del software libre, (GNU/Linux,
etc) donde desde el mismo kernel (núcleo) hasta los firewalls, antivirus,
navegadores ponen a disposición su diseño y su código haciendo que la seguridad
de los mismos no se base en ocultar sus vulnerabilidades, sino en un buen
desarrollo. Aún así, el software libre es escrito por seres humanos, por lo que no
es invulnerable, aunque si muy seguro.
3.2 INGENIERÍA INVERSA
Definición: Es la actividad que se ocupa de descubrir cómo funciona un programa,

función o característica de cuyo código fuente no se dispone, hasta el punto de
poder modificar ese código.
Trata de tomar algo (un dispositivo mecánico o electrónico, un software de

computadora, etc.) para analizar su funcionamiento en detalle, generalmente para
intentar crear un dispositivo o programa que haga la misma o similar tarea sin
copiar la original.
Es denominado ingeniería inversa porque avanza en dirección opuesta a las
tareas habituales de ingeniería, que consisten en utilizar datos técnicos para
elaborar un producto determinado.
Objetivo:
Es obtener información a partir de un producto accesible al público, con el fin de
determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado.
Usos de la ingeniería inversa

Suele ser empleada por empresas, para analizar si el producto de su competencia
infringe patentes de sus propios productos.

En el software y en el hardware, es empleada para desarrollar productos

que sean compatibles con otros productos, sin conocer detalles de desarrollo de
éstos últimos. Es empleada para comprobar la seguridad de un producto.
La gran mayoría del software de pago incluye en su licencia una prohibición

expresa de aplicar ingeniería inversa a su código, con el intento de evitar que se
pueda modificar su código y que así los usuarios tengan que pagar si quieren
usarlo.
Los conceptos de reingeniería e ingeniería inversa están ligados al desarrollo de
software a gran escala, donde una mejora en proceso de este desarrollo supone
un aumento en la competitividad de la empresa.
Aunque hay que tener en cuenta que esta mejora es, en general a largo plazo
(normalmente de uno a dos años) ambas actividades, están orientadas a
automatizar el mantenimiento de aplicaciones. Esta es una tarea que consume
gran cantidad de recursos, por lo que cualquier reducción en el tiempo y recursos
empleados en ella supone una importante mejora en la productividad del proceso.
Este es el principal objetivo de la reingeniería. Se trata, de analizar el código o el
diseño actual y modificarlo con la ayuda de herramientas automáticas para
traducirlos a códigos más estructurados, y más eficientes.
La reingeniería e ingeniería inversa prolongan la vida del software. Dado que es
una labor estratégica, es conveniente conocer cuando conviene realizar la tarea
de reingeniería para una aplicación y cuándo es más rentable sustituirla e
implementar una nueva.
Las aplicaciones para el primer paso, son aquellas en la que se produce las
siguientes situaciones:
Fallos frecuentes, que son difíciles de localizar
Son poco eficientes, pero realizan la función esperada
Dificultades en la integración con otros sistemas
Calidad pobre del software final
Resistencia a introducir cambios
Pocas personas capacitadas para realizar modificaciones
Dificultades para realizar pruebas
El mantenimiento consume muchos recursos
Es necesario incluir nuevos requisitos, pero los básicos se mantienen.

Desarrollo de software con y para reúso
El desarrollo de software con reúso consiste en desarrollar una aplicación usando

software ya existente. Cualquier profesional lo utiliza.
El desarrollo de software para reuso consiste en la construcción de un sistema con
la intención de reutilizar partes de él en futuros desarrollos. Con software a gran
escala, un buen profesional con experiencia puede desarrollarlo.
Estudios realizados determinan que la práctica de reutilización del software en un
proyecto aumenta la productividad durante el desarrollo de dicho proyecto.
Sin embargo, la reutilización del software no cubre solo el reúso de códigos,
abarca todo un amplio de posibilidades en los diferentes niveles, metodología,
ciclos de vida, planes del proyecto, especificaciones de requisitos, diseños,
arquitectura software, planes de validación, juegos de prueba y documentación.
3.3 CÓDIGO FUENTE ABIERTO.
Es el término con el que se conoce al software distribuido y desarrollado

libremente Open Source centra su atención en la premisa de que al compartir el
código el programa resultante tiende a ser de calidad superior al software
propietario.
Código abierto (en inglés open source) es el término con el que se conoce al
software distribuido y desarrollado libremente. Fue utilizado por primera vez en
1998 por algunos usuarios de la comunidad del software libre, tratando de usarlo
como reemplazo al ambiguo nombre original en inglés del software libre (free
software).
Free en inglés puede significar diferentes cosas: gratuidad y libertad. Por ello, por
un lado, permite pensar en "software por el que no hay que pagar" (software
gratuito) y, por otro, se adapta al significado que se pretendió originalmente
(software que posee ciertas libertades). El término para algunos no resultó
apropiado como reemplazo para el ya tradicional free software, pues eliminaba la
idea de libertad (incluso hay algunos que usan —en inglés— el término libre
software para evitar la ambigüedad de free).

Desde el punto de vista de una "traducción estrictamente literal", el significado

obvio de "código abierto" es que "se puede mirar el código fuente", por lo que
puede ser interpretado como un término más débil y flexible que el del software
libre. Basado en ello se argumenta que un programa de código abierto puede ser
software libre, pero también puede ser semilibre o incluso completamente no libre.
Sin embargo, por lo general, un programa de código abierto puede ser y de hecho
es software libre, como igualmente un programa Software Libre es Open Source.
Esto ocurre dado que ambos movimientos reconocen el mismo conjunto de
licencias y tiene principios equivalentes.
¿Por qué es importante el open source?
 Los programadores en Internet pueden leer, modificar y redistribuir el

código fuente de un programa.
 El software evoluciona, se desarrolla y mejora.
 Los usuarios lo adaptan a sus necesidades, corrigen sus errores a una

velocidad impresionante, mayor a la aplicada en el desarrollo de software
convencional o cerrado.
 Se obtiene la producción de un mejor software.
Decálogo para ser código abierto open source
1. Libre redistribución
2. Código fuente
3. Trabajos derivados
4. Integridad del código fuente del autor
5. Sin discriminación de personas o grupos
6. Sin discriminación de áreas de iniciativa
7. Distribución de la licencia
8. La licencia no debe ser específica de un producto
9. La licencia no debe restringir otro software

10. La licencia debe ser tecnológicamente neutral:
Características y ventajas
 Flexibilidad.
 Fiabilidad y seguridad.
 Rapidez de desarrollo.
 Relación con el usuario.
 Libre.
 Combate efectivamente la piratería de software
Abierto y cerrado (la OpenDoc Society)

Podrá parecer a algunos un tema arcano e incluso ajeno, sobre todo a aquellos
editores cuya relación con la tecnología sea todavía tirante, tensa, pero lo que se
está debatiendo hoy mismo en el seno de la ISO, resulta decisivo para que el
circuito de generación, intercambio, circulación y consulta de contenidos escritos,
editoriales, dependa de la intermediación de formatos propietarios o, al contrario,
del uso gratuito y universal de un formato de documentos abierto y compatible,
independiente.
La OpenDoc Society pretende, precisamente, alejar a las instituciones públicas

del uso de formatos cerrados y propietarios, con manifiestas incompatibilidades
retrospectivas y dependientes, siempre, de que el código del programa utilizado
sea desentrañado por sus creadores. La apuesta, por tanto, una vez más, es la
del código abierto como fundamento de la libre circulación de contenidos en la
web, como garantía de que el acceso a la información sea un derecho
garantizado mediante el uso de formatos inteligibles por todos, sostenidos en el
tiempo, sin incompatibilidades arteras entre versiones.

Software abierta
Software que –gracias a estándares- permite su integración o la
complementación por otros
Código Abierto
Software donde se tiene acceso al Código Fuente en algún lenguaje de
Programación
Código sin aranceles de licencias
Software donde no se paga una licencia para usarla
Código con licencias abiertas
Software donde se tiene el derecho de incorporarla en otros sistemas o
de modificarla 0
Diferencia entre código de fuente abierto & software libre.

El Código Fuente Abierto se basa en hacer software confiable y poderoso.
Enfatizan los valores prácticos y se garantiza los derechos de modificación y
redistribución de dichas versiones modificadas del programa. En tanto que el
software libre brinda libertad a los usuarios sobre su producto adquirido puede ser
usado, copiado, estudiado, modificado y redistribuido libremente. Se refiere a la
libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar
el software.
3.4 LAS FALACIAS DEL CÓDIGO ABIERTO
―No hay ningún beneficio en regalar las naranjas ni en enseñar a otros a

cultivarlas‖
De acuerdo con la definición de Software Libre, tenemos que es:
La libertad de usar el programa, con cualquier propósito (libertad 0).

La libertad de estudiar cómo funciona el programa, y adaptarlo a tus necesidades
(libertad 1). El acceso al código fuente es una condición previa para esto.
La libertad de distribuir copias, con lo que puedes ayudar a tu vecino (libertad 2).
La libertad de mejorar el programa y hacer públicas las mejoras a los demás, de
modo que toda la comunidad se beneficie. (libertad 3). El acceso al código fuente
es un requisito previo para esto. Como fabricante de software, voy a ver si podría
vender o distribuir software libre (ya que está tan en boga):
Libertad 0 (parece que las libertades las han asignado a una Matriz ―Dim Libertad
(2) as Variant‖)
Mis programas los pueden usar los clientes para lo que quieran. Que no me
demanden si el programa para un PC lo instalan en un horno y se les quema la

comida. En una sociedad como la norteamericana donde te demandan por

cualquier motivo y donde las botellas de leche dicen ―Para beber y por la boca. No
nos hacemos responsables si Vd. se atraganta‖ esta restricción me parece normal
y prudente.
Libertad 1 Si alguien pudiese tener acceso a mis programas, por lo pronto ya

pierde la garantía. Lo segundo es que ¿quién le impide que copie y pegue el
código en una solución suya, lo venda y me haga la competencia? Un código
fuente cerrado protege la propiedad intelectual.
Libertad 2 Libertad de distribuir copias. Vaya que bien!!! Si tu negocio se basa en

vender programas, directamente cierra el negocio. Vende… ¿qué? ¿Servicios
que nadie demanda? ¿Soporte? La mayoría de las empresas no pagan soporte
por algo que cueste 100, 200 euros. Pagan soporte por algo que cueste 30.000
euros.
Libertad 3 ¿Quién hace eso? ¿Cuantos programadores avanzados se ponen a

tocar el código fuente? Los que están aburridos o los que le dan un uso intensivo.
Y luego… ¿cuántos después de estar trabajando 1 mes para revisar todos los
errores de programación de un módulo o crear otro módulo nuevo… van a
compartirlo con el resto? Conociendo la faceta egoísta del alma humana, creo que
pocos.
Recordemos las 4 libertades del software libre que son lo que la GPL (General
Public License) defiende desde el punto de vista legal.
1. Ejecutar el software con cualquier propósito.

2. Estudiar el código del software y poder adaptarlo a las necesidades, por lo
tanto la liberación del código es un requisito fundamental.
3. Libertad de distribución.
4. Libertad de mejorar el software y distribuir la mejora.
Estas 4 libertades defienden los derechos que debería tener cualquier persona
sobre cualquier producto adquirido, si yo me compro una escoba soy libre de
usarla, de ver como funciona, dejársela a mis amigos o de construir mis propias
escobas con un mango más cómodo y venderlas (o regalarlas si lo prefiero),
¿parece lógico verdad?, es lo que a lo largo del tiempo ha permitido el desarrollo y
la evolución, lo que todos conocemos como la competencia.

Falacias
Software abierto = Código Abierto

Falso:
Bastan Interfaces abiertos para SW Abierta
Código abierto sin estándares no es SW-A
Software sin pago de licencias = CA

Falso:
Hay sistemas CA donde se paga licencias
Hay Software sin pago que no es CA
Licencias abiertas = Código Abierto

Falso:
Partes cerradas pero licencias abiertas
Código Abierto sin licencia abierta
Software sin pago de licencias = Lic. Abierta

Falso:
Licencias Abiertas que se paga (caras a veces)
Licencias ―free‖ sin derecho a Integración o Modificación
Linux es la base del Software Libre

Falso
Corre más SW Código abierto / Licencia Abierta en Windows que en LINUX
Hay bastante SW cerrada que se usa encima de LINUX IBM, Oracle ....
JAVA no es Licencia Abierta ni Código abierto
Software libre es más económico

Falso:
Que no se tiene que pagar licencias no implica de por si menores
costos
Costo total de usar SW contiene además
Costos de Entrenamiento
Costos de Mantenimiento
Costos recurrentes de Conversión
Costos en 1+2+3 >> Licencias muchas veces
Costos mano de obra mas bajos
Costos de licencia igual o mas alto
= Rentable gastar en trabajo no en licencias
Argumento valido para
1. El estado (sector público)
2. Empresas formales
3. Receptores de cooperación externa
4. Hasta cierto grado: Instituciones educativas

¡Pero no para quienes no pagan ni pagarán licencias!
Software libre se puede modificar fácilmente

Falso cuando son centenares de miles de líneas de código
1. Sin documentación ni herramientas imposible salvo después de un

intensivo estudio
2. Se tiene que garantizar compatibilidad con otros
3. Al modificar una versión se tiene que congelarse o enfrentar nuevo trabajo
por cada nueva versión
Software libre es más fácil a mantener

Falso
1. Nadie garantiza la compatibilidad entre los diferentes versiones de los
diferentes paquetes de diferentes orígenes
2. No hay actualizaciones ―automáticas‖, ni en caso de errores garrafales
3. Sin ―conectes virtuales‖ ni habilidades de buscar remedios – imposible
Software libre no es un negocio ni una mercancía

Falso
Explotar SL es costoso, tan que
IBM, JBOSS, MYSQL, Otros lo han hecho base de su modelo de negocios
Agencias de Cooperación lo usan para traspasar costos no pagan ni
licencias ni personal
Centenares de ONG y Consultores viven de SL solo que no es el cliente
final que paga

Unidad IV
Principios guías del software seguro
Objetivo: El alumno conocerá e identificará los principios más importantes que

deben estar presentes usando el diseño o construyendo un sistema seguro,
evitando los problemas más comunes de seguridad.
Contenido:
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

4.1 PRINCIPIO 1. REDUCIR LAS LINEAS DÉBILES
El eslabón más débil se basa en la idea de que una cadena es tan fuerte como su
eslabón más débil. Se deben conocer los puntos débiles de las defensas para, si
es posible, eliminarlos o monitorizarlos. Aunque no por esto debe restarse
importancia a la seguridad de otros aspectos del sistema.
Esta estrategia, aplicada a las redes, establece que un sitio es tan seguro como lo
es su enlace más débil. Este enlace suele ser el objetivo de los ataques a la
privacidad de una red.
Siempre habrá algún punto que será el más débil de todos, la idea es que ese
enlace debe ser lo suficientemente seguro en proporción al riesgo que implica que
sea vulnerado. Algunos afirman que el eslabón más débil en la cadena de la
seguridad informática es el usuario.
Un punto débil es un recurso que puede utilizar una amenaza para tener acceso a
través de una vulnerabilidad en el entorno. Para poder realizar un análisis de
amenazas adecuado, es necesario compilar una lista con los agentes de amenaza
más comunes en el entorno. Una amenaza es cualquier peligro potencial para la
información o los sistemas en el entorno. Un agente amenazante es la persona o
el proceso que ataca a la red a través de un puerto vulnerable en el servidor de
seguridad, o un proceso que se utiliza para obtener acceso a información de una
forma que infringe las directivas de seguridad.
Tipos de puntos débiles
 Punto de vulnerabilidad técnica
Ejemplo:
 Ataque de fuerza bruta
 Desbordamiento de buffer
 Configuración errónea
 Reproducción de ataque
 Secuestro de sesiones
 Recolección de información
 Identificación de dirección
 Destrucción de documento
 Identificación del SO
 Análisis de puerto
 Análisis de respuesta

 Ingeniería social
 Análisis de servicio y aplicación
 Enumeración de usuario
 Análisis de vulnerabilidad
 Fuga inalámbrica
 Denegación del servicio (DoS)
 Daño físico
 Extracción de recursos
 Modificación de recursos
 Saturación de recursos
 Los intrusos buscan el eslabón más débil.
 Tener un buen análisis.
 El programa no siempre es débil.
4.2 PRINCIPIO 2.DEFENSA POR PASO O CAPA
La política de seguridad define qué es lo que desea proteger y qué espera de los
usuarios del sistema.
El uso de un enfoque por capas al planificar la estrategia de seguridad de Internet

garantiza que el atacante que penetre en una de las capas de defensa será
detenido en la capa siguiente.
Capas del modelo informático de red tradicional:
 Seguridad a nivel de sistema
Las medidas de seguridad del sistema representan la última línea de defensa

contra un problema de seguridad debido a Internet
 Seguridad a nivel de red
Cuando se conecta la red a Internet, debe asegurarse de que dispone de las

medidas correctas de seguridad a nivel de red para proteger los recursos internos

de la red contra la intrusión y el acceso no autorizado. El medio más común

para garantizar la seguridad de la red es unos cortafuegos.
 Seguridad a nivel de aplicaciones
Controlan la forma de interacción de los usuarios con las distintas aplicaciones.
 Seguridad a nivel de transmisión
Las medidas de Seguridad a nivel de transmisión protegen la comunicación de

datos dentro de la red y entre varias redes.

4.3 PRINCIPIO 3.SEGURAMENTE FALLARÁ.
Cualquier sistema suficientemente complejo fallará procurando que eso no

suponga un problema de seguridad.
La seguridad absoluta no existe, por tanto, en la medida de lo posible los sistemas

deben tener una falla segura, es decir, si van a fallar deben hacerlo de tal forma
que nieguen el acceso a un atacante en lugar de dejarlo entrar, o dejen de
funcionar si detectan alguna anomalía.
Los sistemas de software generalmente están expuestos a muchos errores y fallas

además de que si sus usuarios no toman los recaudos apropiados, puede llegar a
contraer algún virus informático el cual puede llegar a ser muy dañino o no,
dependiendo del tipo de virus del que estemos hablando, es por eso que siempre
que trabajemos con algún sistema, sin importar si lo hacemos por trabajo o bien,
por entretenimiento, siempre tenemos que contar con algún tipo de seguridad
en sistemas de software que son muy utilizados por nosotros mismos, ya
que seguramente no querremos tener que hacernos cargo de los problemas que
nos puede llegar a ocasionar el simple de hecho de no tener ningún tipo de
protección. Ahora bien, es importante tener en cuenta a los riesgos que estamos
exponiendo nuestro sistema, y uno de los más comunes es, como mencionamos,
las fallas en el sistema.
No necesariamente la computadora debe estar infectada por algún virus
informático ara que esto suceda, ya que puede llegar a ocurrir que ya se por que
se guarda mal un documento o porque instalamos algún programa nuevo que se
encuentra dañado sin darnos cuenta, ya son dos motivos para ocasionarle un falla
general al sistema, especialmente en el segundo caso que es mucho más común.
Si bien la seguridad en sistemas software está garantizada aunque la misma
sea mínima ya que cualquier sistema operativo viene con un software básico de
protección, debemos decir que justamente al tratarse de un software básico es
común que muchas veces se le escapen algunas pequeñas fallas que pueden
resultar muy dañinas para el sistema en general.
Este tipo de seguridad en sistemas software simplemente se encarga de
anunciarla al usuario sobre la presencia de algún documento o programa que
resulte riesgoso para el sistema, y será justamente el usuario el que deba
encargarse de eliminarlo, pero como bien dijimos antes, al tratarse de un software

de seguridad muy básico, puede llegar a ocurrir que el mismo falle y no

filtre algún error o directamente no lo encuentre.
Por otro lado, la seguridad en sistemas software especialmente desarrollada
para evitar todo tipo de problemas, se encarga principalmente de detectar
las fallas y eliminarlas automáticamente del sistema, para evitar mayores
problemas, es por eso que recomendamos que siempre se cuente con algún
software que sea especializado para la seguridad de nuestro sistema en general,
especialmente si exponemos al mismo a las descargas de archivos o a la
navegación por Internet.
La seguridad en sistemas de software debe ser una prioridad
Como ya hemos mencionado en reiteradas oportunidades es importante que

contemos siempre con algún tipo de seguridad en los sistemas software que
utilicemos para evitar problemas y fallas en el funcionamiento de los mismos, en
este sentido debemos decir que una de las más comunes que suele darse,
especialmente cuando la falla se produce por el ingreso de un virus al sistema, es
la pérdida total de todos los archivos que guardamos en nuestro sistema, por
eso es importante que siempre tengamos una copia de seguridad de todo lo que
guardamos en nuestro disco rígido. Ahora bien, antes de adquirir la seguridad para
sistemas software debemos primero determinar cuáles son los riesgos de nuestro
sistema.
Es decir que si utilizamos nuestra computadora únicamente para navegar por

Internet, entonces deberemos adquirir algún tipo de seguridad de sistemas
software para evitar que ingresen virus en el mismo y algo parecido sucede con
las descargas online de archivos. Pero por ejemplo, si el sistema que utilizamos es
el de una empresa entonces deberemos asegurarnos de que el mismo se
encuentre asegurado contra los archivos de espionaje y robo de la información,
algo que suele pasar mucho más seguido en empresas comerciales que se
mueven en un sistema competitivo.
También se debe ser muy cuidadoso con todos aquellos archivos que se ingresan
permanentemente al sistema central de una empresa, ya que aquí también
corremos el riesgo de que alguno de ellos posea alguna falla y que de esta
manera produzca una falla general en el funcionamiento de todo el sistema, por
eso es importante que siempre que se utilice algún tipo de sistema operativo,

tengamos muy en cuenta que la seguridad en sistemas software debe

ser una prioridad.
4.4 PRINCIPIO 4. MENOS PRIVILEGIOS
Dar el acceso mínimo necesario para la tarea encargada.

Este es uno de los principios más fundamentales de seguridad. La estrategia
consiste en conceder a cada objeto (usuario, programa, sistema, etc.) solo
aquellos permisos o privilegios que son necesarios para realizar las tareas que se
programó para ellos. El tipo de objeto al cual se apliquen los permisos determinará
la granularidad —el grado de detalle— de la seguridad obtenida. Esta estrategia
permite limitar la exposición a ataques y limitar el daño causado por ataques
particulares.
Se basa en el razonamiento de que todos los servicios ofrecidos por una red están
pensados para ser utilizados por algún perfil de usuario en particular, y no que
todos los usuarios pueden utilizar todos los servicios de la red. De esta forma es
posible reducir los privilegios requeridos para varias operaciones sin afectar al
servicio prestado a los usuarios del sistema.
Esta estrategia es difícil de implementar cuando no está prevista como una

característica de diseño en los programas y protocolos que estén siendo
utilizados. Debe tenerse cuidado en asegurarse si realmente se está logrando
implementar esta estrategia. En cualquier caso, es posible que se termine por
implementar algo menos que el mínimo privilegio, o mucho más.
Esta consideración esta relacionada con el objeto sobre el cual se aplica la

restricción, es decir la granularidad de la protección. Por ejemplo, aplicar la
restricción sobre los usuarios, puede restringir el uso de servicios que fueron
pensados para todos los usuarios.
Al restringir qué privilegios tienen los usuarios y el software, usted puede ayudar a
que el sistema sea más seguro. Algunas de estas protecciones son invisibles,
como el endurecimiento de servicio. Algunos pueden tomar tiempo para
acostumbrarse, como el Control de cuentas de usuario. Y algunos tal vez
requieran que el software se actualice para funcionar bien para las cuentas de
Usuarios estándar antes de que todos puedan aprovechar los beneficios.

“Cada programa y cada usuario del sistema debe operar utilizando el menor
conjunto de privilegios necesario para completar el trabajo.” Este es el principio de
menos privilegios. El consejo sigue siendo cierto hasta ahora. Al restringir qué
privilegios tienen los usuarios y el software, usted puede ayudar a que el sistema
sea más seguro.
Éste fue uno de los principios guía de seguridad detrás del desarrollo de Windows
Vista. ¿Por qué es importante ejecutar un sistema con un menor número de
privilegios? Veamos el privilegio de las cuentas de usuarios como ejemplo. Si está
ejecutando su PC con una cuenta de administrador completa, cualquier programa
que ejecute y cualquier malware que pueda explotar ese programa, también se
estará ejecutando con privilegios completos de administrador. Esos privilegios son
suficientes para abrir puertos de firewall, crear cuentas de administrador
adicionales e incluso instalar un kit raíz para ocultar la presencia de malware. Sin
embargo, si el código intenta explotar el software que se está ejecutando con
privilegios limitados, el malware podrá descubrir que no puede ejecutar su ataque
planeado y puede ser eliminado fácilmente debido a que no pudo crear ganchos
profundos en el sistema.
Cuentas de usuarios
La mayoría de las personas utilizan Windows® hoy con cuentas de administrador.
Esto los coloca en un mayor riesgo de malware serio y dificulta tener un entorno
de PC administrado, debido a que los usuarios pueden modificar las
configuraciones confidenciales o instalar software no aprobado y posiblemente
malicioso. La solución es ejecutar Windows utilizando una cuenta estándar que no
sea de administrador. Aún así, esto puede ser difícil de hacer debido a que los
usuarios estándar no pueden ejecutar muchos programas y esto los restringe de
realizar muchas tareas comunes por sí mismos, tareas tan comunes como
modificar sus configuraciones de energía o su zona horaria.
Los usuarios estándar ahora pueden hacer más tareas por sí mismos, incluyendo
modificar la zona horaria y las configuraciones de energía, conectarse a redes
inalámbricas seguras e instalar dispositivos y controles ActiveX aprobados.
Mejorar la compatibilidad de las aplicaciones para cuentas de usuarios estándar.
Actualmente, muchas aplicaciones se rompen cuando intentan escribir en áreas
protegidas del sistema de archivos y del registro a los cuales el usuario estándar
no tiene acceso. Para permitir que muchas aplicaciones funcionen para los
usuarios estándar, Windows Vista incluye tecnología de virtualización de archivos
y registros que redirecciona las escrituras (y lecturas subsecuentes) a una
ubicación por usuario dentro del perfil del usuario. Al eliminar las barreras para

ejecución con un menor número de privilegios, esperamos que la mayoría

de las cuentas de usuarios sean implementadas con permisos de Usuarios
estándar en Windows Vista.
Exploración del Web

Internet Explorer® es el programa más utilizado en muchos PCs, pero lo que hace
la mayor parte del tiempo requiere muy pocos privilegios del sistema. Descarga
contenido del Web, lo muestra y cuando el usuario hace clic en el siguiente
vínculo, lo hace de nuevo. El explorador no necesita tener acceso a muchos
recursos del sistema para hacer eso, aunque los exploradores Web actuales se
ejecutan con todos los privilegios del usuario conectado. Lo que significa que el
malware que explota vulnerabilidades en el explorador o un control que se ejecuta
en el explorador puede hacer cualquier cosa que el usuario pueda hacer, de
manera programática, sin conocimiento o interacción del usuario.
En lugar de dar al explorador Web más privilegios de los que necesita, hemos
aplicado el principio de menor número de privilegios a la tarea de exploración del
Web. Por predeterminación, los sitios de Internet se ejecutarán en Modo protegido,
lo cual limita el acceso de un explorador a las ubicaciones que se necesitan para
las tareas arriba mencionadas: el directorio temporal de archivos de Internet, la
carpeta de favoritos y unos cuantos directorios o configuraciones de registro. Por
lo tanto, ayuda a evitar que los archivos o las configuraciones del usuario del
sistema sean modificados sin el permiso explícito del usuario. Si los usuarios
desean realizar una tarea que requiere mayores privilegios que los que tiene
Internet Explorer por predeterminación, existe un proceso de intermediario que les
permite aprobar una acción que requiera privilegios adicionales. Sin embargo, el
modo de menor número de privilegios es el predeterminado.
Servicios
Los servicios Windows por lo general se ejecutan en la cuenta LocalSystem, la
cuenta más poderosa en el sistema. Esto hace que tales servicios sean objetivos
atractivos para desarrolladores de virus. Algunos de los gusanos Windows más
severos —Slammer, Blaster y Sasser — todos estaban dirigidos a los servicios.
De manera ideal, los servicios deben limitar su potencial de daño al ejecutarse en
una cuenta con menores privilegios, tal como LocalService o NetworkService. Sin
embargo, muchos servicios requieren por lo menos algunos privilegios que sólo
soporta LocalSystem. El modelo ―todo o nada‖ que se utilizó antes de Windows
Vista significaba que un servicio que requiriera cualquier privilegio de LocalSystem

tenía también que incluir todos los demás privilegios de LocalSystem. Esto
con frecuencia significaba incluir privilegios que el servicio no requería.
En Windows Vista, hemos aplicado el principio de menor número de privilegios a
servicios con un concepto nuevo llamado Windows Service Hardening. Los
servicios se perfilan para tener sólo los privilegios que necesitan. Un menor
número de procesos en Windows Vista utiliza la cuenta SYSTEM. En comparación
con Windows XP, ocho servicios que acostumbraban ejecutarse con privilegios
SYSTEM ahora se ejecutan como LOCAL SERVICE, y ahora cuatro se ejecutan
como NETWORK SERVICE.
Además, los servicios que no requerían la cuenta SYSTEM se pueden perfilar
para restringirlos contra escrituras en el sistema de archivos o al enviar tráfico de
salida, si el servicio no necesita esos privilegios para hacer la función para la cual
se creó. Por ejemplo, el servicio Llamada de procedimiento remoto en Windows
Vista está restringido contra el reemplazo de archivos del sistema, modificar el
registro o manipular con otra configuración de servicio en el sistema (tal como la
configuración de software antivirus y archivos de definición de firma). Terceros
también pueden aprovechar estas capacidades para que sus servicios sean más
seguros.
Controladores
Los controladores por lo general se ejecutan en el kernel, lo que les da el mayor
privilegio de todos. Con acceso al kernel, es posible crear un kit de raíz que oculta
todos los tipos de actividad maliciosa en el sistema. Windows Vista aplica el
principio de menor número de privilegios a los controladores al ejecutar muchos
controladores que normalmente se ejecutaban en modo de kernel en el modo de
usuario más restringido en cambio. Esto también mejorar la estabilidad del
sistema, debido a que un bloqueo en el kernel con frecuencia podía resultar en un
bloqueo de la pantalla azul de todo el sistema operativo, pero con frecuencia se
puede recuperar de un bloqueo en modo de usuario.

4.5 PRINCIPIO 5. SEGMENTACIÓN
Es un esquema de manejo de memoria mediante el cual la estructura del

programa refleja su división lógica; llevándose a cabo una agrupación lógica de la
información en bloques de tamaño variable denominados segmentos. Cada uno
de ellos tienen información lógica del programa: subrutina, arreglo, etc. Luego,
cada espacio de direcciones de programa consiste de una colección de
segmentos, que generalmente reflejan la división lógica del programa.
Un fallo que muchas veces ocurre es el de enviar el mismo mail a todo el mundo
por igual. Una alternativa es la segmentación. No hacen falta grandes recursos
para segmentar la lista de distribución.
Las organizaciones deben definir una serie de prioridades y la mayoría de las
veces la seguridad no suele ser de alta prioridad. A menudo, no es rentable hacer
un sistema tan seguro como sea posible, ya que el riesgo es bajo y el coste es
alto.
Cuando recibimos los estudios de viabilidad de los clientes, revisamos en busca

de requisitos de seguridad pero éstos son escasos y en muchas ocasiones
inexistentes. Si los analistas son buenos éstos se encargan de incluir algunos,
pero como las estimaciones de los proyectos suelen ser en la mayoría de los
casos muy ajustadas, tienden a omitirlos.
El software está en la raíz de la mayoría de los problemas de seguridad

informática, si éste no se comporta de forma adecuada surgirán problemas de
integridad, disponibilidad, confidencialidad... Los bugs y vulnerabilidades son la
causa de un mal diseño y una mala implementación. Debemos empezar a
concienciarnos: la seguridad debe estar presente en todas las fases del ciclo de
vida de un producto.

4.6 PRINCIPIO 6. MANTENERLO SIMPLE
La simplicidad es una estrategia de seguridad que se basa en dos principios:
1. Mantener las cosas sencillas las hace más fáciles de comprender —Si algo
no se entiende, no se puede saber si es seguro o no—, y
2. Lo complejo proporciona muchos escondites para que se oculten toda clase
de cosas (por ejemplo, es más fácil mantener seguro un apartamento que
una mansión).
Se sabe que cuanto más grande y complejo es un sistema, más errores tendrá,
será más difícil de utilizar y más costoso de testear. Además, probablemente
posea agujeros de seguridad no conocidos que un atacante puede explotar, por
más complejos que sean.
La simplicidad de los sistemas de seguridad es un factor importante de una sólida
defensa de red. Particularmente los sistemas de seguridad de red a nivel de
aplicación no deberían tener funcionalidades desconocidas y deberían mantenerse
lo más simples posible.
4.7 PRINCIPIO 7. PROMOVER LA PRIVACIA
Tenemos que tratar de no comprometer los datos de nuestros usuarios.
La mayoría de sitios `serios' no guarda nuestra clave, ni el número de la tarjeta,
 Al menos, no mostrarla (nunca entera)

 Almacenarla cifrada
 Almacenarla en otra máquina diferente.
Ejemplos:
Microsoft dedica recursos importantes a la mejora de la protección de la
privacidad, tanto en lo que se refiere al software, servicios y productos que
ofrecemos a nuestros clientes para ayudarles a administrar la privacidad de su
información como en lo que respecta al modo en que hacemos negocios. Como
resultado de esto, la privacidad se ha incorporado a la cultura de Microsoft como
una prioridad automática en cada área de la compañía. Los esfuerzos para ayudar
a nuestros clientes a proteger su información están centrados en tres áreas clave:
inversiones en tecnología, liderazgo responsable y compromiso y orientación al
cliente.

Inversiones en tecnología
Comprendemos que nuestros clientes esperan que les proporcionemos

herramientas que les permitan protegerse. Como resultado, Microsoft da prioridad
al desarrollo de tecnologías que incorporen herramientas o servicios de mejora de
la privacidad que contribuyan a proteger a nuestros clientes y a su información.
Entre los ejemplos recientes de tecnología de mejora de la privacidad se incluyen:
 Windows Defender. La herramienta antispyware de Microsoft mejora la

seguridad de navegación por Internet ayudando a salvaguardar contra
spyware y eliminando paquetes de spyware ya instalados en su ordenador.
Es la descargar más popular de Microsoft download.
 Microsoft Windows Vista Service Pack 1. Microsoft ha llevado a cabo
nuevas mejoras de seguridad y privacidad en Windows Vista SP1 para
proteger mejor los equipos de piratas informáticos, virus y otras amenazas en
línea.
 Lucha contra el correo electrónico no deseado y filtrado de contenido.

En colaboración con Microsoft Research, MSN, Microsoft Office, Microsoft
Exchange Server y otros grupos internos, el grupo de tecnologías y
estrategias contra el correo electrónico no deseado contribuye a integrar
nuevas tecnologías contra el correo no deseado.
 Administración de derechos. Windows Rights Management Services

(RMS) es una nueva tecnología de aplicación de directivas que permite
proteger el contenido en el nivel de archivo. Esta protección de nivel de
archivo siempre está aplicada, independientemente del lugar donde se
encuentre.
 MSN. La tecnología avanzada en la red MSN y servicios de comunicación

(protección infantil de MSN, protección contra elementos emergentes,
protección contra correo electrónico no deseado) contribuye a proteger a los
clientes de las amenazas en línea, incluido el correo electrónico no deseado
y los virus.
 Sender ID. Sender ID es un nuevo estándar e iniciativa de lucha contra el

correo electrónico no deseado de AOL, Yahoo!, EarthLink, Comcast, British
Telecom y Microsoft. Sender ID combate un tipo específico de falsificación de
correo electrónico denominado suplantación de dominio, que falsifica la
información de encabezado para dar la impresión de que un mensaje
procede de un remitente legítimo.

 Internet Explorer. Internet Explorer 8 ofrece seguridad gracias a una nueva

estructura más sólida, características de seguridad que le protegen frente al
software malicioso (también conocido como malware) y nuevas vías para
proteger mejor su información personal frente a sitios Web fraudulentos, una
práctica conocida como "phising".
Liderazgo responsable
Reconocemos que compartir nuestros conocimientos, aprender de otros y

colaborar con socios del sector en cada fase contribuye a que cada eslabón
posterior de la cadena sea más fuerte. En este sentido, invertimos en numerosos
tipos de organizaciones y asociaciones. Por ejemplo:
 Anti-Phishing Working Group. Como miembro colaborador de APWG,

Microsoft tiene un compromiso activo con otros líderes del sector en reducir
la amenaza de ataques tipo "phishing" elaborando y compartiendo
información acerca del problema y promoviendo la visibilidad y la adopción
de soluciones para el sector.
 Antispam Technology Alliance. Microsoft y los miembros de ASTA

trabajan conjuntamente, además de otros participantes del sector y de otros
sectores, en impulsar estándares técnicos y en promover la colaboración en
el desarrollo de directrices del sector para solucionar el problema del correo
electrónico no deseado.
 Online Privacy Alliance Microsoft es mimbro de Online Privacy Alliance,

cuya finalidad es: identificar y anticipar medidas de protección de la
privacidad en el sector privado, ofrecer apoyo y fomentar el desarrollo y el
uso de mecanismos y actividades de aplicación autorregulados, así como
tecnologías y estándares que contribuyan a proteger la privacidad y facilitar
el cumplimiento y la aplicación estrictos de las legislaciones y normativas
vigentes.
 Trustworthy Computing Academic Curriculum. La creación de este

programa académico fundará una serie de proyectos académicos para
presentar los aspectos básicos de Informática de confianza en los currículos
técnicos y de negocio.

 Trustworthy Computing Academic Advisory Board. La junta se creó para

asesorar a Microsoft con respecto a las mejoras de seguridad, privacidad y
confiabilidad en las tecnologías de Microsoft.
 TRUSTe proporciona aprobación global líder para generar confianza en las

transacciones en línea. Ofrecemos apoyo a TRUSTe tanto como
patrocinador líder como propietario de licencia global.
 Global Infrastructure Alliance. Microsoft forma parte de este grupo de

trabajo, que se ha diseñado para ofrecer un entorno de Internet más seguro
a todos los consumidores del mundo. GIAIS cubre el 60% de los suscriptores
a Internet del mundo.
Compromiso y orientación al cliente
Las tecnologías de privacidad de Microsoft funcionan mejor cuando los clientes

disponen de los conocimientos y de la orientación que precisan para utilizarlas de
una forma más eficaz. Pretendemos mejorar las funciones de los clientes y las
asociaciones mediante cursos, colaboración con el cliente y el compromiso.
 MSN Protect Your Privacy Online. En este sitio Web se ofrece información a
los usuarios acerca de cómo mantener el control de su información, cómo
pueden los criminales invadir su privacidad y qué pueden hacer para
protegerse.
 Seguridad en el hogar. Este sitio Web está dedicado a ayudar a los usuarios
a obtener soporte técnico para problemas relacionados con la seguridad,
como virus y actualizaciones de seguridad.
 Guía de privacidad en Microsoft. Punto de vista de Microsoft a través de la

explicación de sus innovaciones tecnológicas, prácticas y procedimientos
internos, orientación al consumidor y su liderazgo y cooperación en el sector.
 Colaboración en la aplicación de la legislación. Microsoft tiene el

compromiso de trabajar en la aplicación de la legislación en todo el mundo
para encontrar modos de detener la piratería y otros sabotajes de software
mediante prácticas de seguridad proactivas. Un ejemplo de la dedicación de
Microsoft a su objetivo de colaboración en la aplicación de la legislación lo

constituye el programa de recompensa de antivirus (Antivirus Reward

Program). Esta iniciativa consiste en fondos donados por Microsoft para
ayudar a la aplicación de la legislación con el fin de descubrir a los autores de
gusanos, virus y otro código malintencionado.
 Enterprise Engineering Center. Este recurso permite a los clientes

implementar y probar las soluciones de Microsoft en una recreación de su
entorno heterogéneo. Los programadores de Microsoft colaboran con los
clientes para garantizar una configuración correcta y solucionar los problemas
que se produzcan en el momento.
 Campaña de cursos en todo el mundo. Estamos trabajando en una

campaña de cursos en todo el mundo con fabricantes de equipos,
distribuidores, proveedores de servicios Internet y otros socios para mantener
a los profesionales de TI actualizados con las prácticas recomendadas en
comprobación y protección de equipos y cómo facilitar la habilitación de las
tecnologías de protección.
4.8 PRINCIPIO 8. OCULTAR SECRETOS ES DIFICIL
La idea de esta estrategia está basada en mantener oculta la verdadera

naturaleza de seguridad, de esta forma, un atacante lo pasará por alto como una
posible víctima. Pero esta suposición es algo ingenua ya que varios estudios han
demostrado que el interés de un atacante por un determinado sitio no solo está
determinado por el interés que éste tenga sobre la información del sistema
Seguridad a través de oscuridad.
La idea de esta estrategia está basada en mantener oculta la verdadera

naturaleza del sistema de seguridad, de esta forma, un atacante lo pasará por alto
como una posible víctima. Pero esta suposición es algo ingenua ya que varios
estudios han demostrado que el interés de un atacante por un determinado sitio no
solo está determinado por el interés que éste tenga sobre la información del
sistema.

4.9 PRINCIPIO 9.TRANSPARENTAR EL CÓDIGO
Un software es seguro cuando ha sido bien desarrollado y se utiliza de forma

correcta, y esto es independiente de la forma bajo la que se distribuya. Sin
embargo, el software libre es más transparente que el software propietario, ya que
permite comprobar que fue desarrollado de forma correcta.
Otra de las ventajas del software libre es que está basado en estándares abiertos,
es decir cualquier empresa puede crear un programa que maneje la información
que genera en ese software. De ese modo no se produce una dependencia
tecnológica hacía una determinada empresa. Siempre es el usuario quien elige el
programa con el que manejará sus datos, pudiendo cambiar su elección cuando lo
desee, ya que la información estará almacenada en formatos estándar, que
pueden ser manejados por otros programas diferentes al nuestro. Un ejemplo de
esto son los ficheros jpg o png: cada usuario puede utilizar el programa que más le
guste para ver las imágenes almacenadas en estos formatos, ya que son formatos
públicos.
Diseño para transparencia
 Además de aplicar toda las tácticas para mantener el código simple se

debe pensar en las maneras que el código se va comunicar con los
seres humanos.
 Las cualidades en la reacción humana al software son esenciales para
reducir sus errores e incrementar su mantenibilidad.

4.10 PRINCIPIO 10. USAR RECURSOS COMUNES
 Uso Aceptable
Aquel que demande un gasto adicional para el organismo, excepto el que derive
del uso normal de los recursos informáticos.
 Usos Indebidos
Acceder al código fuente de una obra de software sin autorización explícita del
autor (área de software y aplicaciones) con la finalidad de modificarlo.
 Usos Prohibidos
Prohibido el uso de cualquier recurso informático para:

Grabar, modificar o borrar software, información, bases de datos, que no estén
incluidas como tareas propias del usuario.

Unidad V
Auditoria de software
Objetivo: El alumno conocerá e identificará las etapas que se requieren para

poder llevar a cabo la auditoría de software una vez que éste ha sido terminado;
así como las herramientas que permiten realizar auditoría al código fuente.
Contenido:
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

AUDITORIA DEL SOFTWARE
CONCEPTO
La Auditoría de Software es un término general que se refiere a la investigación y
al proceso de entrevistas que determina cómo se adquiere, distribuye y usa el
software en la organización. Conducir la auditoría es una de las partes más
críticas de un Programa de Administración de Software, porque la auditoría ayuda
a la organización a tomar decisiones que optimicen sus activos de software.
Un estudio de Print UK Limited, firma de Administración de auditoría, descubrió
que una organización típica con más de 500 PCs muchas veces tiene un 20% más
de computadoras de lo que cree. El Gartner Group también descubrió que más de
un 90% de las organizaciones han incrementado su base de activos de TI sin
haber hecho ningún proceso para su seguimiento. Una de las razones por las que
las organizaciones no maximizan su inversión en activos de software es que no
hay información exacta disponible. La recopilación de toda la información
necesaria es un proceso intenso, especialmente cuando se hace por primera vez.
Otro problema es que la perspectiva de una auditoría puede ser vista con algunas
reservas por algunos directivos de la organización, preocupados porque pueda
interrumpir el flujo de trabajo, y por algunos usuarios finales que pueden ser
forzados a abandonar sus programas o procedimientos favoritos.
Una de las formas de evitar las objeciones y dejar de lado estos problemas es
planificar cuidadosamente la Auditoría de Software y comunicar su valor por
adelantado. Los siguientes factores favorecerán la colaboración entre la gerencia y
el personal a través del proceso de planificación, el cual es una llave para el éxito
de cualquier auditoría de software.
Establecer y acordar una serie clara de objetivos y comunicarla a todos los
empleados asociados con la auditoría. Focalizarse en los resultados que se
requieran de la auditoría y discutir las áreas donde se crea pueda haber
problemas.
Identificar las áreas simples pero muchas veces olvidadas que necesitan ser
consideradas, tales como: Acceso a sitios y creación de mapas de esas
locaciones Conocer con anticipación los log-on scripts de seguridad o claves.
Horario de la auditoría (durante el día, noche o fin de semana). Diseñar el plan y el
cronograma de la auditoría, así como también las herramientas de auditoría que
serán usadas. Asignar recursos para cada elemento específico de la auditoría.

5.1 DEFINICION DE ARQUITECTURA DE SEGURIDAD
La seguridad de datos (seguridad lógica) se define en función de tres atributos,

todos los cuáles se deben mantener para garantizar la seguridad del sistema:
I. CONFIABILIDAD (INTEGRIDAD): Se refiere a que la información a transmitir NO

sea modificada durante la transmisión. Un interceptor NO debe ser capaz de
cambiar un mensaje verdadero por uno falso.
II. CONFIDENCIALIDAD (PRIVACIDAD / ANONIMATO): La información sólo
puede ser accedida por personas autorizadas.
III. CONTINUIDAD OPERATIVA (DISPONIBILIDAD): Se refiere a la operación
ininterrumpida en el tiempo del sistema.
5.2 PRINCIPIOS DE LA ARQUITECTURA DE SEGURIDAD
Los principios son leyes naturales de carácter general que actúan

independientemente a que nosotros tengamos conocimientos o no de ellos, los
principios pueden aparecer en la mayoría de las doctrinas.
Principios
 Confidencialidad
 Integridad
 Disponibilidad
 Autenticación
 Autorización
 Auditabilidad
Confidencialidad: Asegura que solos los individuos autorizados tengan accesos

a los recursos que se intercambien.
Integridad: Garantizan que los datos sean lo que se supone que son.
Disponibilidad: Garantiza el correcto funcionamiento de los sistemas de
información.

Autenticación: Asegura que los individuos autorizados tengan accesos a

los recursos (confirmación de la entidad de un usuario)
Autorización: Asegura que los individuos que accedan a la información tienen la
suficiente autorización para ello.
Auditabilidad: Asegura de que el sistema pueda ser sometido a demostraciones,
verificaciones, o comprobaciones con el fin de buscar una mejora.
5.3 ANALISIS DE LA ARQUITECTURA DE SEGURIDAD
Diseño de la Entrada y Salida

Entrada: consiste en realizar formato que permitan a los usuarios introducir datos,
los formales serán pantallas que simularan que en estas se escriba la información.
Salida: El diseño de salida en sí, es diseñar los formatos de salida comúnmente
esta puede ser reporte de resultado.
Análisis
Seleccionar un lenguaje de programación, el lenguaje que se selecciona cumple
con los requisitos tales como fácil de manejar y es conocido como el equipo de
trabajo. Cada código debe ser explicado a los trabajadores o a la persona que
tendrá uso de este, se tuvo que seleccionar un lenguaje que permitiera que el
manejo de este sea sencillo.
5.3.1 DISEÑO
Se define como el conjunto de controles de infraestructura de TI recomendados

para brindar, un ambiente que minimice los riesgos asociados a la utilización de
tecnologías de información y apoye las estrategias de negocio
1.-Definición del esquema de Autenticación, Autorización y Auditoria
2.- Definición de seguridad perimetral
3.- Definición de conectividad segura
4.- Definición de esquema de monitoreo
5.-Definición de administración Centralizada Con base en los
requerimientos normativos establecidos en la ISO 27001 y los controles

recomendados en ISO27002, se establece el marco metodológico

que apoya la definición de Arquitectura de Seguridad
5.3.2 IMPLEMENTACION
El proceso de implementación contiene las actividades y tareas del operador. El

proceso cubre la operación del producto software y el apoyo a la operación de los
usuarios. Ya que la operación del producto software está integrada a la operación
del sistema, las actividades y tareas de este proceso hacen referencia al sistema.
El operador gestiona el proceso de operación a nivel de proyecto usando el
proceso de gestión, que se emplea en este proceso; establece una infraestructura
basada en el proceso que se sigue en el proceso de infraestructura; adapta el
proceso al proyecto siguiendo el proceso de adaptación; y gestiona el proceso al
nivel de organización siguiendo el proceso de mejora de proceso y el proceso de
recursos humanos. Cuando el operador es el proveedor del servicio de operación,
el operador lleva a cabo proceso de suministro. Lista de actividades. Este proceso
consta de las siguientes actividades:
a) Implementación del proceso.

b) Pruebas de operación.
c) Operación del sistema.
d) Soporte al usuario.
Implementación del proceso: Esta actividad consta de las siguientes tareas: El

operador debería preparar un plan y establecer un conjunto de normas de
operación para llevar a cabo las actividades y tareas de este proceso. Se deberá
documentar y ejecutar el plan. El operador deberá establecer procedimientos para
recibir, registrar, solucionar y hacer un seguimiento de los problemas y
proporcionar información sobre su situación. En cuanto se encuentren problemas,
se deberán registrar e introducir en el proceso de solución de problemas.
Pruebas de operación: Esta actividad consta de las siguientes tareas: Para cada
reléase del producto software, el operador deberá llevar a cabo pruebas de
operación y tras satisfacerse los criterios especificados, liberar el software para
uso en operación. El operador deberá asegurar que el código software y las bases
de datos se inicializan, ejecutan y terminan tal como se describe en el plan.

Operación del sistema: Esta actividad consta de la siguiente tarea: El

sistema deberá ser operado en el entorno previsto de acuerdo con la
documentación de usuario.
Soporte al usuario: Esta actividad consta siguientes tareas: El operador deberá
proporcionar asistencia y consultoría a los usuarios cuando la pidan. Estas
peticiones y las acciones subsecuentes se deberán registrar y supervisar. El
operador deberá pasar las peticiones del usuario, cuando sea necesario, al
proceso de mantenimiento para su solución. Estas peticiones se deberán tramitar
y el originador de la petición deberá ser informado de las acciones que se
planifiquen y se tomen. Se deberá hacer un seguimiento de todas las decisiones
hasta su conclusión. Si un problema reportado tiene una solución temporal, antes
de que se pueda liberar una solución permanente, se deberá dar la opción a quien
reportó el problema para que la use. Se deberán aplicar al software en operación,
usando el proceso de mantenimiento, las correcciones permanentes, los raleases
que incluyan funciones o característica omitidas anteriormente y las mejoras del
sistema.
5.3.3 AUTOMATIZACÓN Y PRUEBA

Las pruebas de seguridad permiten mitigar los riesgos asociados a posibles
ataques tanto internos como externos a los sistemas y aplicaciones del cliente.
Los ataques pueden explotar defectos de diseño de la arquitectura, de la
plataforma, y de las aplicaciones utilizadas por la organización.
Las organizaciones que manejan software de seguridad se divide su actividad en
dos grandes ámbitos:
1. Revisiones de seguridad de sistemas. Bajo esta actividad se realizan

análisis del nivel de aplicación de:
o Normativas internas de la organización

o Mejores prácticas
o Estándares internacionales
o Parches y actualizaciones de los fabricantes
2. Pruebas de seguridad en el nivel de aplicación, con dos aproximaciones:
o Pruebas de caja negra automatizadas, que permitan simular

ataques estándar

o Pruebas de caja blanca que permiten simular ataques

desde dentro de la organización pues presuponen conocimiento
de la arquitectura de seguridad del cliente
En todas las áreas de una organización puede aportar su conocimiento y

experiencia con herramientas específicas.
La automatización en un software seguro se refiere a realizar las tareas más
rápidas del software.
Objetivos de la automatización
 Esfuerzo La tarea cuesta menos y se hace menos tediosa. Cuanto mayor

tiempo lleva la tarea, menor es la probabilidad de hacerla. Y cuando la
dejamos de hacer, minimizamos el valor del trabajo que hacemos.
 Reduce el tiempo
 Aumenta la previsibilidad
 Consistencia
 Extensibilidad Al ganar / ahorrar tiempo, surge la oportunidad de mejorar
otras cosas.
 Métricas Tomar métricas en un proceso automatizado es mucho más
fácil que en un proceso manual.
5.3.4 ARBOLES DE ATAQUE
¿Qué es un árbol de ataque?
Los arboles de ataques ofrecen otro modo de controlar las amenazas

potenciales. Un árbol de ataques es un diagrama jerárquico de los ataques
posibles contra un sistema. La raíz del diagrama en forma de árbol invertido
representa el objetivo final de un atacante, como robar contraseñas. Las ramas
del árbol representan las acciones que pueden realizar los atacantes para
alcanzar el objetivo. Al retrasar las rutas por el diagrama, los desarrolladores
pueden descubrir que tipo s de ataques son los más fáciles los cuales son los
más difíciles de detectar y cuales pueden provocar el mayor daño. Los arboles de
ataques son utilizados por los análisis de la seguridad en muchos campos.

5.3.5 REPORTE DE ANALISIS
La información acerca del sistema actual se estudia en detalle, y se entrevista a

los usuarios, se toman medidas, se desarrollan pronósticos de necesidades
futuras y se toman todos los demás pasos necesarios para determinar lo que el
nuevo sistema debe realizar.
Los resultados de esta actividad minuciosa llevan al informe de especificaciones

de requerimientos del sistema, con la cual termina la fase de análisis de sistemas.
(Este es el punto más temprano del ciclo de vida de unos sistemas ene el cual se
prepara un pedido de propuestas, o PP).
El reporte escrito de la propuesta de sistemas debe contener:
Memorándum de la portada.
Resumen de recomendaciones.
Panorama del estudio de sistemas.
Hechos detallados.
Otras soluciones.
Recomendaciones.
Presentación oral.
El análisis de software también previene que las aplicaciones se vuelvan

obsoletas y confirma si usted posee las funciones más actualizadas y el software
apropiado para subsistema.
5.4 IMPLEMENTACION DEL ANALISIS DE SEGURIDAD
Debemos instalar herramientas, divulgar reglas, concienciar a los usuarios sobre

el valor de la información, configurar los ambientes etc. Debemos elegir e
implementar cada medida de protección, para contribuir con la reducción de las
vulnerabilidades.
El siguiente listado de ejemplos nos permite darnos una idea de lo que se

requiere para la protección de los activos en la organización:
 Control de acceso a los recursos de la red
Implementación de controles en las estaciones de trabajo que permiten la gestión

de acceso, en diferentes niveles, a los recursos y servicios disponibles en la red.

 Protección contra virus
Implementación de un software que prevenga y detecte software maliciosos,

como virus.
 Seguridad para equipos portátiles
Implantación de aplicaciones y dispositivos para la prevención contra accesos

indebidos y el robo de información.
 Detección y control de invasiones
Implantación de una herramienta que analice el tránsito de la red en busca de

posibles ataques para permitir dar respuestas en tiempo real, y reducir así los
riesgos de invasiones en el ambiente.
 Firewall
Sistema que controla el tránsito entre dos o más redes, permite el aislamiento de
diferentes perímetros de seguridad, como por ejemplo, la red Interna e Internet.
 Seguridad en correo electrónico
Utiliza certificados digitales para garantizar el sigilo de las informaciones y

software para filtro de contenido, y proteger a la empresa de aplicaciones
maliciosas que llegan por ese medio.
 Seguridad para las aplicaciones
Implementación de dispositivos y aplicaciones para garantizar la confidencialidad,

el sigilo de las informaciones y el control del acceso, además del análisis de las
vulnerabilidades de la aplicación, al suministrar una serie de recomendaciones y
estándares de seguridad.
 Monitoreo y gestión de la seguridad
Implementación de sistemas y procesos para la gestión de los eventos de

seguridad en el ambiente tecnológico, haciendo posible un control mayor del
ambiente, para dar prioridad a las acciones e inversiones.

 Seguridad en comunicación Móvil
Acceso a Internet para usuarios de aparatos móviles como teléfonos celulares y

PDA‘s, para permitir transacciones e intercambiar información con seguridad vía
Internet.
 Seguridad para servidores
Configuración de seguridad en los servidores, para garantizar un control mayor en

lo que se refiere al uso de servicios y recursos disponibles.
 Firewall interno
Este firewall funciona al aislar el acceso a la red de servidores críticos,

minimizando los riesgos de invasiones internas a servidores y aplicaciones de
misión crítica
5.4.1 AUDITORIA DE CÓDIGO FUENTE
Es el proceso de revisar el código de una aplicación para encontrar errores en

tiempo de diseño.
Motivos para auditar el código de una aplicación:
La auditoría de código es parte del ciclo de vida en el desarrollo de

Software.
Dejar la revisión de código para el último momento es mucho más costoso
en tiempo y en recursos que realizarlo como un proceso continuo.
Es una forma sencilla de ‗educar‘ al equipo de desarrollo viendo por qué no
se deben realizar ciertas codificaciones.
Fomenta el uso de buenas prácticas. Mejora la calidad y minimiza el
mantenimiento del código que realizamos.

5.4.2 HERRAMIENTAS DE AUDITORIA DE SEGURIDAD
Fuente herramientas de auditoría de código generalmente buscan

vulnerabilidades comunes y el trabajo sólo para determinados lenguajes de
programación. Estas herramientas automatizadas se podrían utilizar para ahorrar
tiempo, pero no debe ser invocado por una auditoría a fondo. La aplicación de
herramientas como parte de un enfoque político basado es recomendable.
Ejemplos de herramientas de auditoría incluyen Skavenger, SSW Código Auditor
y muchos de los instrumentos enumerados en la lista de herramientas para
análisis de código estático.
Una auditoría de código de software es un análisis completo de código fuente en

una programación de proyectos con la intención de descubrir los errores, fallos de
seguridad o violaciones de los convenios de programación. Es una parte integral
de la programación defensiva paradigma, que intenta reducir los errores antes de
que el software es puesto en libertad. C y C + + código fuente es el código más
común de ser controladas desde muchos lenguajes de alto nivel, como Python,
tienen menos funciones potencialmente vulnerables
Mediante la auditoría de código fuente le proporcionamos a empresas que

desarrollen su propio software la facilidad de externalizar las auditorías de código,
que permitirán a sus aplicaciones convertirse en software más seguro y que le
garantizarán la eliminación de gran cantidad de vulnerabilidades conocidas en su
código. Entre los lenguajes de programación que auditamos, se encuentran
lenguajes de servidor como PHP, ASP, JSP y .NET
CONCLUSIÓN
En este tema pude aprender que la auditoria del software es el proceso de

recoger, agrupar y evaluar evidencias para determinar si un Sistema de
Información para salvaguarda la información de una organización, mantiene la
integridad de los datos, lleva a cabo eficazmente los fines de la organización y
utiliza eficientemente los recursos. Por eso es importante porque tiene la
capacidad de verificar la integridad de la información mediante estas revisiones
que se le efectúa a los sistemas de información.

Unidad VI
Código seguro
Objetivo: El alumno conocerá, identificará y aplicará diferentes lenguajes de

programación que le permitan analizar, diseñar y desarrollar las diferentes
técnicas de código de seguro.
Contenido:
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.1 DEFINICIÓN DE CODIGO SEGURO
Es un código diseñado para soportar ataques de usuarios maliciosos. Las

instrucciones siguientes proporcionan varias técnicas para escribir código seguro.
Se requiere
Utilice las herramientas de análisis de código. Visual Studio Team

Edition para Developers se distribuye con herramientas de análisis de
código que pueden aumentar en gran medida la posibilidad de encontrar los
errores de seguridad del código. Estas herramientas encuentran errores
ocultos con mayor eficacia y menos esfuerzo.
Realice una revisión de seguridad. El objetivo de toda revisión de
seguridad es mejorar la seguridad de los productos que ya se han lanzado
o garantizar que no se distribuya ningún producto nuevo hasta que sea lo
más seguro posible. No revise el código de forma aleatoria. Prepare de
antemano la revisión de seguridad y comience por crear un modelo
exhaustivo de amenazas. Si no hace, puede desperdiciar mucho tiempo de
su equipo. Dé prioridad al código que debe recibir la revisión de seguridad
más intensa e indique qué errores de seguridad hay que buscar.
Utilice una lista de comprobación de revisión de código para mayor
seguridad. Independientemente de la función que desempeñe en el
equipo de desarrollo de software, resulta de gran utilidad disponer de una
lista de comprobación que seguir a fin de garantizar que el diseño y el
código cumplen los requisitos mínimos.
Valide todos los datos introducidos por los usuarios. Si permite que la
aplicación acepte datos proporcionados por los usuarios, directa o
indirectamente, debe validar esos datos antes de utilizarlos. Los usuarios
malintencionados intentarán provocar errores en la aplicación manipulando
los datos de modo que representen datos no válidos. La primera regla para
los datos introducidos por el usuario es: todos los datos son erróneos hasta
que se demuestre lo contrario.
Valide perfectamente todos los parámetros de las interfaces de
programación de aplicaciones (API) exportadas. Asegúrese de que
todos los parámetros de las API exportadas son válidos. Esto incluye los
datos que parecen ser coherentes pero que están más allá del intervalo de
valores aceptado, como los tamaños búfer excesivos. No utilice aserciones
para comprobar los parámetros de las API exportadas, porque las
aserciones se quitarán en la versión de lanzamiento.

Utilice las API criptográficas de Windows. En lugar de escribir a

su propio software criptográfico, utilice la API criptográfica de Microsoft, que
ya está disponible. Al utilizar una API criptográfica de Microsoft, los
desarrolladores quedan libres para concentrarse en la generación de
aplicaciones. Recuerde: el cifrado resuelve muy bien un reducido conjunto
de problemas y se utiliza con frecuencia de maneras para las que no está
diseñado.
Se debe evitar
Las saturaciones del búfer.
Una saturación del búfer estática se produce cuando un búfer declarado en la pila
se sobrescribe porque se copian datos más grandes que él. Las variables
declaradas en la pila se ubican junto a la dirección de devolución del llamador de
la función. Las saturaciones del búfer también pueden aparecer en el montón y
son igualmente peligrosas. Normalmente, la causa suele residir en datos
introducidos por el usuario que se pasan a una función como strcpy, con el
resultado de que la dirección de devolución de la función se sobrescribe por una
dirección elegida por el atacante. Para evitar las saturaciones del búfer, es
fundamental escribir una aplicación robusta.
Aserciones para la comprobación de los datos externos.
Las aserciones no se compilan en las versiones de lanzamiento. No utilice

aserciones para comprobar los datos externos. Todos los parámetros de las
funciones y los métodos exportados, todos los datos introducidos por el usuario y
todos los datos de los archivos y socket deben verificarse atentamente para
comprobar su validez, y rechazarse si hay algún error.
Combinaciones de Id. de usuario y contraseña dentro del código.
No utilice contraseñas contenidas dentro del código. Modifique el instalador para

que, al crear las cuentas de usuario integradas, se soliciten al administrador
contraseñas seguras para cada cuenta. De esta manera, se puede mantener la
seguridad de los sistemas de nivel de producción del cliente.

Utilizar el cifrado para resolver todos los problemas de

seguridad.
El cifrado resuelve muy bien un reducido conjunto de problemas y se utiliza con

frecuencia de maneras para las que no está diseñado.
Rutas de acceso a archivos y direcciones URL canónicas.
Evite situaciones donde sea importante la ubicación de un archivo o una dirección

URL. Utilice ACL del sistema de archivos en lugar de reglas basadas en nombres
de archivo canónicos.
6.2 LENGUAJE ENSAMBLADOR
El lenguaje ensamblador es un tipo de lenguaje de bajo nivel utilizado para escribir

programas informáticos, y constituye la representación más directa del código
máquina específico para cada arquitectura de computadoras legible por un
programador.
Fue usado principalmente en los inicios del desarrollo de software, cuando aún no
se contaba con los potentes lenguajes de alto nivel. Actualmente se utiliza con
frecuencia en ambientes académicos y de investigación, especialmente cuando se
requiere la manipulación directa de hardware, se pretenden altos rendimientos o
un uso de recursos controlado y reducido. Muchos dispositivos programables aun
cuentan con el lenguaje ensamblador como la única manera de ser manipulados.
Características:
El código escrito en lenguaje ensamblador posee una cierta dificultad

de ser entendido directamente por un ser humano ya que su
estructura se acerca más bien al lenguaje máquina, es decir,
lenguaje de bajo nivel.
El lenguaje ensamblador es difícilmente portable, es decir, un código
escrito para un microprocesador, suele necesitar ser modificado,
muchas veces en su totalidad para poder ser usado en otra máquina
distinta, aun con el mismo microprocesador.
Los programas hechos en lenguaje ensamblador son generalmente
más rápidos y consumen menos recursos del sistema

Con el lenguaje ensamblador se tiene un control muy preciso

de las tareas realizadas por un microprocesador por lo que se
pueden crear segmentos de código difíciles de programar en un
lenguaje de alto nivel.
También se puede controlar el tiempo en que tarda una rutina en
ejecutarse, e impedir que se interrumpa durante su ejecución.
TIPOS DE LENGUAJES ENSAMBLADOR
Ensambladores básicos. Son de muy bajo nivel, y su tarea consiste básicamente

en ofrecer nombres simbólicos a las distintas instrucciones de la máquina
apropiada, además de ofrecer un formato de escritura cómodo para expresar los
parámetros y cosas tales como los modos de direccionamiento.
Ensambladores modulares, o macro ensambladores. Descendientes de los
ensambladores básicos, fueron muy populares en las décadas de los 50 y los 60,
antes de la generalización de los lenguajes de alto nivel. Hacen todo lo que puede
hacer un ensamblador, y además proporcionan una serie de directivas para definir
e invocar macro instrucciones.
Ensambladores modulares 32-bits. Pueden ser de alto y bajo nivel, pero solo
emulado en 32-bits. Microsoft aun está reproduciendo el Microsoft Macro
Assembler, es reproducido por un paquete preparado. El ml 6.14 emula poderosos
compilados en 32-bits, su sintaxis es mezcla de; C API, ensamblador, y macros.
HLA High-Level Assembler, es un lenguaje poderoso que soporta de bajo y alto-
nivel pero solo en 32-bits. También tiene fama de usar macros como los de más.
Otros ensambladores populares de 32-bits que emulan casi lo mismo aunque
pueden soportar programar en 16-bits también llamados registros de segmento.
6.3 LENGUAJE DE PROGRAMACION
Un lenguaje de programación es un idioma artificial diseñado para expresar

computaciones que pueden ser llevadas a cabo por máquinas como las
computadoras. Pueden usarse para crear programas que controlen el
comportamiento físico y lógico de una máquina, para expresar algoritmos con
precisión, o como modo de comunicación humana. Está formado de un conjunto
de símbolos y reglas sintácticas y semánticas que definen su estructura y el
significado de sus elementos y expresiones. Al proceso por el cual se escribe, se
prueba, se depura, se compila y se mantiene el código fuente de un programa
informático se le llama programación.

También la palabra programación se define como el proceso de creación de

un programa de computadora, mediante la aplicación de procedimientos lógicos, a
través de los siguientes pasos:
El desarrollo lógico del programa para resolver un problema en particular.

Escritura de la lógica del programa empleando un lenguaje de
programación específico (codificación del programa)
Ensamblaje o compilación del programa hasta convertirlo en lenguaje de
máquina.
Prueba y depuración del programa.
Desarrollo de la documentación.
Existe un error común que trata por sinónimos los términos 'lenguaje de
programación' y 'lenguaje informático'. Los lenguajes informáticos engloban a los
lenguajes de programación y a otros más, como por ejemplo el HTML.
Permite especificar de manera precisa sobre qué datos debe operar una
computadora, cómo deben ser almacenados o transmitidos y qué acciones debe
tomar bajo una variada gama de circunstancias. Todo esto, a través de un
lenguaje que intenta estar relativamente próximo al lenguaje humano o natural, tal
como sucede con el lenguaje Léxico. Una característica relevante de los lenguajes
de programación es precisamente que más de un programador pueda usar un
conjunto común de instrucciones que sean comprendidas entre ellos para realizar
la construcción del programa de forma colaborativa.
Los lenguajes de programación facilitan la tarea de programación, ya que
disponen de formas adecuadas que permiten ser leídas y escritas por personas, a
su vez resultan independientes del modelo de computador a utilizar.
Existen estrategias que permiten ejecutar en una computadora un programa
realizado en un lenguaje de programación simbólico. Los procesadores del
lenguaje son los programas que permiten el tratamiento de la información en
forma de texto, representada en los lenguajes de programación simbólicos. Hay
lenguajes de programación que utilizan compilador.
La ejecución de un programa con compilador requiere de dos etapas:
1) Traducir el programa simbólico a código máquina

2) Ejecución y procesamiento de los datos.
Otros lenguajes de programación utilizan un programa intérprete o traductor, el

cual analiza directamente la descripción simbólica del programa fuente y realiza
las instrucciones dadas.

El intérprete en los lenguajes de programación simula una máquina virtual,

donde el lenguaje de máquina es similar al lenguaje fuente.
La ventaja del proceso interprete es que no necesita de dos fases para ejecutar el
programa, sin embargo su inconveniente es que la velocidad de ejecución es más
lenta ya que debe analizar e interpretar las instrucciones contenidas en el
programa fuente.
Los tipos de lenguajes de programación los podemos clasificar en dos grandes
grupos. Los lenguajes de programación de bajo nivel y los de alto nivel. El tipo de
lenguaje de programación de bajo nivel depende totalmente de la máquina, en
este caso de la computadora u ordenador, estos solos entienden el lenguaje
binario o el código máquina, que consiste en ceros y unos. Es decir, que para
realizar cualquier acción, solo utilizan este tipo de lenguaje de programación.
El tipo de lenguaje de programación de bajo nivel es totalmente dependiente de la
computadora u ordenador, es decir que no podemos utilizarlo en cualquier otra.
Este tipo de lenguaje de programación está prácticamente diseñado a la medida
del hardware y aprovecha las características de este. Dentro de este tipo de
lenguajes de programación podemos citar al lenguaje máquina y al lenguaje
ensamblador.
Dentro del tipo de lenguajes de programación de alto nivel tenemos a todos
aquellos lenguajes de programación que son más afines al lenguaje natural que al
lenguaje máquina. Estos lenguajes de programación son completamente
independientes de la arquitectura del hardware de la computadora u ordenador.
Por lo que en general, un programa escrito con un lenguaje de programación de
alto nivel lo podemos utilizar en cualquier otra computadora.
6.4 TECNICAS DE CODIGO SEGURO
1. Instrucciones para realizar revisiones de diseño y de código: Proporciona

varias técnicas para realizar la revisión del diseño y del código a fin de descubrir
errores y supuestos incorrectos solicitando a sus homólogos que revisen el código.
2. Instrucciones para escribir código seguro: Describe técnicas y estrategias
para escribir código seguro.
3. Instrucciones para la protección de código de calidad: Muestra
instrucciones para comprobar el código de maneras diferentes a fin de garantizar
que incorpora lo que estaba previsto en el diseño de calidad.

4. Instrucciones de depuración: Proporciona varias instrucciones para

encontrar defectos de código.
5. Instrucciones de uso de las herramientas de análisis de código:
Proporciona varias instrucciones para utilizar las herramientas de análisis de
código.
6. Detectar y corregir defectos de código de C/C++: Describe cómo detectar y
corregir defectos de código utilizando la herramienta de análisis de código para
C/C++.
7. Detectar y corregir defectos de código administrado: Describe cómo
detectar y corregir defectos de código utilizando la herramienta de análisis de
código para código administrado.
8. Directivas de protección de los análisis de código: Describe cómo crear
directivas de protección personalizadas asociadas con las protecciones de control
del código fuente de Control de código fuente Team Foundation.
6.4.1 BUFFER OVER FLOWS
En seguridad informática y programación, un desbordamiento de buffer (del inglés

buffer over flows o buffer overrun) es un error de software que se produce cuando
se copia una cantidad de datos sobre un área que no es lo suficientemente grande
para contenerlos, sobrescribiendo de esta manera otras zonas de memoria. Esto
se debe en general a un fallo de programación. La consecuencia de escribir en
una zona de memoria imprevista puede resultar impredecible. Existen zonas de
memoria protegidas por el sistema operativo. Si se produce la escritura fuera de
una zona de memoria protegida se producirá una excepción del sistema de acceso
a memoria seguido de la terminación del programa. Bajo ciertas condiciones, un
usuario obrando con malas intenciones puede aprovecharse de este mal
funcionamiento o una vulnerabilidad para tener control sobre el sistema.
En algunas ocasiones eso puede suponer la posibilidad de alterar el flujo del
programa pudiendo hacer que éste realice operaciones no previstas. Esto es
posible dado que en las arquitecturas comunes de computadoras, la memoria no
tiene separación entre la dedicada a datos y a programa.
Si el programa que tiene el error en cuestión tiene privilegios especiales se
convierte además en un fallo de seguridad. El código copiado especialmente
preparado para obtener los privilegios del programa atacado se llama shellcode.

6.4.2 HEAP OVERFLOWS
Un desbordamiento de pila es un tipo de desbordamiento de búfer que se produce

en la zona montón de datos.
Al igual que todos los desbordamientos de búfer, un desbordamiento de pila puede
ser introducida accidentalmente por un programador de la aplicación, o puede ser
consecuencia de una explotación deliberada. En cualquier caso, el
desbordamiento se produce cuando los datos de una aplicación más copias en un
búfer que el búfer se propuso contener. Una rutina es vulnerable a la explotación
si las copias de datos a un búfer sin comprobar primero que la fuente de ajustar en
el destino.
Un desbordamiento accidental puede dar lugar a la corrupción de datos o un
comportamiento inesperado por cualquier procedimiento que utiliza el área de
memoria afectada. En los sistemas operativos, sin protección de memoria, esto
podría ser un proceso en el sistema. Un ataque intencional puede dar lugar a los
datos a una ubicación específica, siendo la alteración de manera arbitraria, o en
código arbitrario ser ejecutado. El Microsoft GDI + JPEG vulnerabilidad MS04-028
es un ejemplo del peligro que un desbordamiento de pila puede representar a un
usuario de la computadora.
6.4.3 FORMATO DE CADENA
Los problemas de cadena de formato constituyen uno de los pocos ataques

realmente nuevos que surgieron en años recientes. Al igual que con muchos
problemas de seguridad, la principal causa de los errores de cadena de formato es
aceptar sin validar la entrada proporcionada por el usuario. En C/C++ es posible
utilizar errores de cadena de formato para escribir en ubicaciones de memoria
arbitrarias, y el aspecto más peligroso es que esto llega a suceder sin manipular
bloques de memoria adyacentes. Esta capacidad de diseminación permite a un
atacante eludir protecciones de pila, e incluso modificar partes my pequeñas de
memoria. El problema también llega a ocurrir cuando las cadenas de formato se
leen a partir de una ubicación no confiable que controla el atacante. Este último
aspecto del problema tiende a ser más frecuente en sistemas UNIX y Linux. En
sistemas Windows las tablas de cadena de aplicación suelen mantenerse dentro
del programa ejecutable o de las bibliotecas de vínculo dinámico (DLL, Dynamic
Link Libraries) del recurso. Si un atacante reescribe el ejecutable principal o de las

DLL, tendrá la posibilidad de realizar ataques mucho más directos que con
errores de cadena de formato.
Aunque no esté trabajando con C/C++, los ataques de cadena de formato quizá
conduzcan a problemas importantes; el más obvio es engañar a los usuarios, pero
bajo ciertas circunstancias es posible que un atacante lance ataques de creación
de script de sitio cruzado o de inyección de SQL, los cuales también se utilizan
para corregir o transformar datos.
Explicación del problema de cadena de formato
El formateo de datos para despliegue o almacenamiento tal vez represente una
tarea un poco difícil; por tanto, en muchos lenguajes de computadora se incluyen
rutinas para reformatear datos con facilidad. En casi todos los lenguajes la
información de formato se describe a través de un tipo de cadena, denominada
cadena de formato. En realidad, la cadena de formato se define con el uso de
lenguaje de procesamiento de datos limitado que está diseñado para facilitar la
descripción de formatos de salida. Sin embargo, muchos desarrolladores cometen
un sencillo error: utilizan datos de usuarios no confiables como cadena de formato;
el resultado es que los atacantes pueden escribir cadenas en el lenguaje de
procesamiento de datos para causar muchos problemas.
El diseño de C/C++ hace que esto sea especialmente peligroso: dificulta la
detección de problemas de cadena de formato, y entre las cadenas de formato se
incluyen algunos comandos muy peligrosos que no existen en lenguajes de
cadena de formato de algunos otros lenguajes.
Explicación del problema de cadena de formato
El formateo de datos para despliegue o almacenamiento tal vez represente una
tarea un poco difícil; por tanto, en muchos lenguajes de computadora se incluyen
rutinas para reformatear datos con facilidad. En casi todos los lenguajes la
información de formato se describe a través de un tipo de cadena, denominada
cadena de formato. En realidad, la cadena de formato se define con el uso de
lenguaje de procesamiento de datos limitado que está diseñado para facilitar la
descripción de formatos de salida. Sin embargo, muchos desarrolladores cometen
un sencillo error: utilizan datos de usuarios no confiables como cadena de formato;
el resultado es que los atacantes pueden escribir cadenas en el lenguaje de
procesamiento de datos para causar muchos problemas.
El diseño de C/C++ hace que esto sea especialmente peligroso, dificulta la
detección de problemas de cadena de formato, y entre las cadenas de formato se
incluyen algunos comandos muy peligrosos que no existen en lenguajes de
cadena de formato de algunos otros lenguajes.

6.4.4 EXPLOIT
Un exploit es una pieza de software, un fragmento de datos, o una secuencia de

comandos con el fin de automatizar el aprovechamiento de un error, fallo o
vulnerabilidad, a fin de causar un comportamiento no deseado o imprevisto en los
programas informáticos, hardware, o componente electrónico. Con frecuencia,
esto incluye cosas tales como la violenta toma de control de un sistema de
cómputo o permitir la escalada de privilegios o un ataque de denegación de
servicio.
El fin del Exploit puede ser violar las medidas de seguridad para poder acceder al
mismo de forma no autorizada y emplearlo en beneficio propio o como origen de
otros ataques a terceros. Los Exploits pueden ser escritos empleando una
diversidad de lenguajes de programación, aunque mayoritariamente se suele
utilizar lenguaje C. También puede aprovecharse de distintos tipos de ataques
tales como desbordamiento de búfer, Cross Site Scripting, Format Strings,
Inyección SQL, entre otros.
Un exploit es un programa o técnica que aprovecha una vulnerabilidad. Los
exploits dependen de los sistemas operativos y sus configuraciones, de las
configuraciones de los programas que se están ejecutando en un ordenador y de
la LAN donde están
Una de las herramientas más utilizadas para trabajar con este tipo de software es
Metasploit Framework, una plataforma de test de penetración escrita en lenguaje
de programación Ruby, como así también otros frameworks como Core Impact.
6.4.5 RACE CONDITION
Race condition es un error de programación en un sistema multitareas cuando el

trabajo del sistema depende del orden en que secciones de código se ejecutan. La
raza es una condición Heisenbug clásica. Condición de anticipación se produce
cuando varios hilos de una aplicación multi-hilo tratar de conseguir al mismo
tiempo el acceso a los datos, mientras que al menos un hilo realiza el ahorro.
Condición de carrera puede dar lugar a resultados impredecibles ya menudo son
difíciles de detectar. A veces las consecuencias de condición de carrera se
producen sólo después de un largo periodo de tiempo y en alguna otra parte de la
solicitud. Además, esos errores son muy difíciles de reproducir. Para evitar la
condición de carrera, los métodos de sincronización se utilizan lo que le permite
organizar adecuadamente las operaciones ejecutadas por diferentes hilos.

Este tipo de vulnerabilidad ocurre cuando un evento se produce fuera del

periodo previsto, con un resultado imprescindible. El fallo puede ser utilizado para
falsificar la barra de direcciones en la ventana del navegador mostrando un
archivo. SWF desde un sitio web malicioso. Sin embargo, el impacto de este
problema se ve reducido por la dirección del archivo flash malicioso, es visible
como titulo de la ventana del navegador.
6.4.7 SQL INJECTION
Es una vulnerabilidad informática en el nivel de la validación de las entradas a la

base de datos de una aplicación. El origen es el filtrado incorrecto de las variables
utilizadas en las partes del programa con código SQL. Es, de hecho, un error de
una clase más general de vulnerabilidades que puede ocurrir en cualquier
lenguaje de programación o de script que esté incrustado dentro de otro.
Una inyección SQL sucede cuando se inserta o "inyecta" un código SQL "invasor"
dentro de otro código SQL para alterar su funcionamiento normal, y hacer que se
ejecute maliciosamente el código "invasor" en la base de datos.
La inyección SQL es un problema de seguridad informática que debe ser tomado

en cuenta por el programador para prevenirlo. Un programa hecho con descuido,
displicencia, o con ignorancia sobre el problema, podrá ser vulnerable y la
seguridad del sistema puede quedar ciertamente comprometida. Esto puede
suceder tanto en programas ejecutándose en computadores de escritorio, como
en páginas Web, ya que éstas pueden funcionar mediante programas
ejecutándose en el servidor que las aloja.
La vulnerabilidad puede ocurrir cuando un programa "arma" descuidadamente una

sentencia SQL, con parámetros dados por el usuario, para luego hacer una
consulta a una base de datos. Dentro de los parámetros dados por el usuario
podría venir el código SQL inyectado.
Al ejecutarse esa consulta por la base de datos, el código SQL inyectado también
se ejecutará y podría hacer un sinnúmero de cosas, como insertar registros,
modificar o eliminar datos, autorizar accesos e, incluso, ejecutar código malicioso
en el computador.
SQL injection es una técnica de ataque que utiliza inyección SQL cuando una
página web por motivos de seguridad no muestra mensajes de error de la base de
datos al no haber un resultado correcto mostrándose siempre el mismo contenido.

6.4.7 CROSS-SITE Y CROSS DOMAN SCRIPTING
Cross Site Scripting es el nombre que recibe una vulnerabilidad que afecta no
tanto a los servidores como a los usuarios que navegan a páginas de Internet. La
causa de la vulnerabilidad radica en la pobre verificación por parte de los sitios
web de las cadenas de entrada enviadas por los usuarios a través de formularios,
o directamente a través del URL. Estas cadenas, en el caso de ser maliciosas,
podrían llegar a contener scripts completos. Cuando esta entrada se le muestra
dinámicamente a un usuario dentro de una página web, en caso de contener un
script, éste se ejecutará en el navegador del usuario dentro del contexto de
seguridad de la página web visitada. Como consecuencia, podrá realizar en el
ordenador del usuario todas las acciones que le sean permitidas a ese sitio web,
como por ejemplo interceptar entradas del usuario víctima o leer sus cookies.
El mayor riesgo de este tipo de ataques es que la entrada maliciosa no la

proporciona el mismo usuario que ve la página, sino un atacante, que consigue
que el script se ejecute en el navegador del usuario. La víctima ejecuta el código
de manera indirecta cuando confiadamente hace clic sobre un hiperenlace
fraudulento, que puede estar presente en el sitio web del atacante, en un mensaje
de correo electrónico o de un grupo de noticias, o en cualquier otro lugar que no
levante sospechas.
Estos errores se pueden encontrar en cualquier aplicación que tenga como

objetivo final, el presentar la información en un navegador web. No se limita a
sitios web, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso
el navegador en sí. El problema está en que usualmente no se validan
correctamente los datos de entrada que son usados en cierta aplicación. Esta
vulnerabilidad puede estar presente de forma directa o indirecta.
Directa: este tipo de XSS comúnmente filtrado, y consiste en invadir código

HTML peligroso en sitios que así lo permiten; incluyendo así etiquetas como
lo son <script> o <iframe>.
Indirecta: este tipo de XSS consiste en modificar valores que la aplicación
web utiliza para pasar variables entre dos páginas, sin usar sesiones y
sucede cuando hay un mensaje o una ruta en la URL del navegador, en
una cookie, o cualquier otra cabecera HTTP.
Normalmente el atacante tratara de insertar tags como <iframe>, o <script>, pero

en caso de fallar, el atacante puede tratar de poner tags que casi siempre están
permitidas y es poco conocida su capacidad de ejecutar código. De esta forma el
atacante podría ejecutar código malicioso.

6.4.8 FAUL INJECTION
En las pruebas de software, la inyección de fallos (faul injection) es una técnica

para mejorar la cobertura de una prueba mediante la introducción de faltas para
probar las rutas de código, en particular, el manejo de error rutas de código, que
de otra forma rara vez se debe seguir. Es de uso frecuente con pruebas de
esfuerzo y es ampliamente considerado como una parte importante del desarrollo
de software robusto. Robustez prueba es un tipo de inyección de fallos de uso
común para detectar vulnerabilidades en los interfaces de comunicación como los
protocolos, los parámetros de línea de comandos, o APIs.
La propagación de un fallo a través de un fallo observable sigue un ciclo bien

definido. Cuando se ejecuta, una falla puede provocar un error, que es un estado
no válido dentro de un límite del sistema. Un error puede causar errores
adicionales en la frontera del sistema, por lo que cada nuevo error actúa como una
falla, o se puede propagar a la frontera del sistema y ser observable. Cuando los
estados de error se observan en la frontera del sistema se denominan fallas. Este
mecanismo se denomina el ciclo de culpa-error-error y es un mecanismo clave en
la fiabilidad.
CONCLUSIÓN
Para concluir con esta unidad es importante decir que los códigos también
requieren de seguridad, como ya sabemos la codificación es la que hace funcionar
a un software y si por equivocación hacemos una modificación puede fallar el
software incluso dañar la integridad de la información. Como pudimos ver en esta
unidad existen tipos de lenguajes en el cual los códigos es el enlace entre la
computadora y el hombre permitiendo realizar tareas tan importantes para las
organizaciones. Otra cosa importante son las técnicas que se utiliza para
garantizar la seguridad de los códigos estas técnicas más que nada realizan
monitoreo de seguridad y en algunos casos bloquean el acceso a usuarios no
autorizados.

Unidad VII
Pruebas de software
Objetivo: El alumno conocerá e identificará las fases y los diferentes tipos de

pruebas que se realizan al software.
Contenido:
7.3 Fases de las Pruebas de Software

7.3.1 Modelado del ambiente del software
7.3.2 Selección de escenarios de prueba
7.3.3 Ejecución y evaluación de los escenarios de prueba
7.3.4 Medición del progreso de las pruebas
7.4 Prácticas de las Pruebas de Software
7.4.1 Básicas
7.4.1.1 Especificaciones funcionales
7.4.1.2 Revisión e inspección
7.4.1.3 Entrada formal y criterios de salida
7.4.1.4 Prueba funcional
7.4.1.5 Pruebas multiplataforma
7.4.1.6 Ejecución automatizada de prueba
7.4.1.7 Programas beta
7.4.2 Fundamentales
7.4.2.1 Escenarios de usuario
7.4.2.2 Pruebas de utilidad
7.4.2.3 Requerimientos para la planificación de la prueba
7.4.2.4 Generación automatizada de la prueba
7.4.3 Incrementales
7.4.3.1 Cobertura de código
7.4.3.2 Generador de ambiente automatizado
7.4.3.3 Diagrama del estado de la prueba
7.4.3.4 Simulación de falla en la memoria
7.4.3.5 Pruebas estadísticas
7.4.3.6 Métodos semiformales
7.4.3.7 Registro de la prueba para el código
7.4.3.8 Benchmark
7.4.3.9 Generación de errores (bugs)

7.1 FASES DE LAS PRUEBAS DE SOFTWARE
En la ingeniería del software el término fases de desarrollo expresa cómo ha

progresado el desarrollo de un software y cuánto desarrollo puede requerir.
Cada versión importante de un producto pasa generalmente a través de una etapa

en la que se agregan las nuevas características (etapa alfa), después una etapa
donde se eliminan errores activamente (etapa beta), y finalmente una etapa en
donde se han quitado todos los bugs importantes (etapa estable).
Las etapas intermedias pueden también ser reconocidas. Las etapas se pueden
anunciar y regular formalmente por los desarrolladores del producto, pero los
términos se utilizan a veces de manera informal para describir el estado de un
producto.
Normalmente muchas compañías usan nombres en clave para las versiones antes
del lanzamiento de un producto, aunque el producto y las características reales
son raramente secretas.
La fase conocida como pre-alfa se publica a veces antes del lanzamiento de una
versión alfa o beta. En contraste con la versión alfa y las versiones beta, la pre-alfa
no tiene sus características completas.
Los diseñadores todavía están determinando en esta etapa exactamente qué

funcionalidades debe tener el producto. Tales etapas se pueden llamar también
development releases o nightly builds.
La versión alfa de un producto es la primera para la que el equipo de desarrollo

decide que implementa todas las funcionalidades especificadas en los requisitos.
Es la primera versión del programa que se envía a los verificadores para probarla.
Algunos equipos de desarrollo utilizan el término alfa informalmente para referirse

a una fase donde un producto todavía es inestable, aguarda todavía a que se
eliminen los errores o a la puesta en práctica completa de toda su funcionalidad,
pero satisface la mayoría de los requisitos.
Cuando una versión beta llega a estar disponible para el público en general, a
menudo es utilizada extensamente por los tecnológicamente expertos o
familiarizados con versiones anteriores, como si el producto estuviera acabado.

Generalmente los desarrolladores de las versiones betas del software

gratuito o de código abierto los lanzan al público en general, mientras que las
versiones betas propietarias van a un grupo relativamente pequeño de
probadores.
En el siguiente diagrama mostramos las fases de pruebas, asi de la misma

manera como se encuentran relacionadas con los diferentes tipos de pruebas con
las que interactúan:
7.1.1. MODELADO DEL AMBIENTE DEL SOFTWARE
Al trabajo con ordenador se destina hoy gran parte del tiempo laboral. Sin
embargo, las facilidades que genera el uso de datos digitales implican para el
trabajador nuevas cargas de índole física y anímica.
Esta actividad, que el usuario lleva a cabo la mayor parte del tiempo sentado,
puede ocasionar daños en la columna vertebral y la musculatura, además de
producir una mala circulación sanguínea, dolores de cabeza y trastornos de la
visión.

Por otro lado, debido a que la comunicación y colaboración entre colegas

es poco frecuente, esta situación puede implicar a largo plazo el aislamiento
social.
Según un decreto de la Unión Europea sobre seguridad y protección de la salud

ante el trabajo con ordenadores, aprobado el 21 de agosto de 1997, las empresas
de más de diez trabajadores deben cumplir una serie de normativas que hacen
referencia al lugar de trabajo (mesa, silla, superficie de trabajo), a las herramientas
utilizadas (tipo de monitor y tamaño del mismo, teclado, escabel, software), al
ambiente de trabajo (iluminación, acústica, temperatura, humedad del aire) y a la
propia habitación (superficie de movimiento, altura de la habitación, contacto
visual).
En la práctica son numerosas las empresas que ignoran esta normativa debido a
los costes que generaría su puesta en práctica.
7.1.2. SELECCIÓN DE ESCENARIOS DE PRUEBA
1. Creando escenarios:
Cuando ya tenemos un producto debemos:
Saber a quien se lo queremos vender.

Olvidar mercados y hablar de personas
Caracterizar a la persona a la que le quieres vender
Crear al menos 5 fichas que definan a la persona a la que le quieres
vender.
2. Elige a alguien de tu tamaño:
Si eres pequeño elige a alguien de tu tamaño.

Debes ser capaz de llegar al menos a la mitad del escenario que elijas en el
primer año.
3. Crea una página por cada escenario, y numera cada Uno.
Antes y al final realiza una hoja de Excel con todos los datos numéricos de
todos los escenarios.
Número de clientes posibles.

Facturación.
Nº empleado.
Todos los campos claves que utilices para definir el escenario.
4. Haz tormenta de ideas con tu equipo:
Debes involucrar a todo el mundo en las valoraciones de los diferentes escenarios,

y realiza media de las puntuaciones que haga cada uno.
Ejemplo:
Ocupando un Rango del (0 A 5) aplicado a:
Dificultad de venta.
Instalación.
Facilidad de mantenimiento.
5. Ordena:
Resultados por puntuaciones medias.

Elimina los escenarios que no pasen el primer corte.
Repite una votación privada de los escenarios finales.
Vuelve a discutir.
Puedes introducir más indicadores de decisión sobre el escenario previsto.
Lo importante es que el grupo de trabajo se implique en la decisión final.
6. Resultado final: Depende los resultados puede pasar los siguientes:
a) El grupo está de acuerdo de cual es el escenario adecuado: A por él, sin

miramientos, sin dudas, sin arrepentimientos, sin cambios, pelea por conseguir los
objetivos marcados.
b) El grupo no se pone de acuerdo en el escenario a elegir: Elige a una persona

para que desarrolle la teoría de bolos y elige el primer bolo de la teoría.
c) No hay ningún escenario que supere los mínimos:
No trates de crecer.
Quizá no sea el momento.
El producto no está preparado.

La empresa, sigue vendiendo a clientes cercanos hasta que el

momento y el escenario correcto se presenten.
7.1.3. EJECUCIÓN Y EVALUACIÓN DE LOS ESCENARIOS DE PRUEBAS
La aplicación manual de los escenarios de prueba es una tarea que

consume demasiado tiempo.
La evaluación de los escenarios de prueba es un proceso que se puede
descomponer en las siguientes fases:
a) Revisar lo que dice la documentación del software respecto a las funciones que
debe realizar.
b) Comparar los resultados de la ejecución de los escenarios de prueba con lo que

dice la documentación.
c) La documentación se asume correcta. Desviaciones se consideran fallos.
Una alternativa para permitir la evaluación de los escenarios de prueba es la

formalización de la escritura de las especificaciones del software.
Formalizar escritura de las especificaciones y la forma en que el código se genera

basado en las especificaciones definidas.
En muchos casos esta tarea es dejada de lado y se procede a desarrollar software

de manera informal, pero sin estas especificaciones los escenarios de prueba
podrán detectar los errores más obvios y nada más.
7.1.4 MEDICIÓN DEL PROGRESO DE LAS PRUEBAS
Nuevas Necesidades para Pruebas
La necesidad de pruebas nunca había sido tan grande.

Las expectativas del consumidor han aumentado:
a) Se requiere la integración de funciones en espacios reducidos y a un bajo

costo.
b) Quien sea que cumpla estas demandas; rápido, confiable y consistentemente,

tiene la ventaja competitiva del mercado.

El sistema tendrá que demostrar ser el mejor posible.
La instrumentación virtual es una solución innovadora a estos retos:
Combina el rápido desarrollo de software con el hardware modular y flexible

para crear sistemas de prueba definidos por el usuario.
Ofrece Herramientas de software intuitivas para pruebas de desarrollo
rápidas
Ofrece E/S basadas en tecnologías comerciales innovadoras, rápidas y
precisas.
Rapidez en el Desarrollo de Software de Prueba
La automatización se ha convertido en un requisito para probar rápidamente

sistemas complejos.
El software se ha convertido en un elemento esencial en todos los sistemas de

prueba, desde verificación de diseño hasta pruebas de manufactura
automatizadas.
Para entregar sistemas de prueba que se adapten a probar nuevas características

rápidamente, se requiere de un conjunto de herramienta de desarrollo de pruebas
integradas.
Estas pruebas incluyen pruebas de administración y desarrollo, así como

hardware de Entrada/Salida.
7.2 PRÁCTICAS DE LAS PRUEBAS DE SOFTWARE
Existen muchos prácticas y métodos para la prueba del Software. Entre ellas:
Métodos Pruebas del software (Dinámico): consisten en ejecutar comprobando

que distintos valores de entrada producen los resultados deseados.
Métodos de inspección del software (Estático): se basan en la revisión de la

documentación, requisitos, incluso código sin ejecutar nada. Esta tarea puede
realizarse por un grupo de expertos
Pruebas de caja negra: no conocemos la implementación del código, sólo la

interfaz. Tan sólo podemos probar dando distintos valores a las entradas y salidas.

Pruebas de caja blanca: conocemos el código (la implementación de éste)

que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles
caminos del código.
Pero a las que nos enfocaremos son a las pruebas básicas
7.2.1 BÁSICAS
En la evolución de la creación del software tenemos que responder

constantemente a las preguntas:
¿Estamos construyendo el producto correctamente? Dada la especificación que

hemos tomado del usuario
¿Estamos construyendo bien el código?
¿El resultado final del desarrollo software concuerda con la especificación

(requisitos) del sistema? Hay que intentar asegurar que el desarrollo final coincide
con dicha especificación.
Las practicas en las fases de prueba para determinar que nuestro software cumpla
el objetivo del cliente y como empresa pueden ser:
Especificaciones funcionales
Revisión e inspección
Entrada formal y criterios de salida
Prueba funcional
Pruebas multiplataforma
Ejecución automatizada de prueba
Programas beta
7.2.1.1 ESPECIFICACIONES FUNCIONALES
Describe cómo funcionará un producto completamente desde la perspectiva del

usuario.
No le importa cómo se implemente la cosa. Habla de funciones. Especifica

pantallas, menús, diálogos, etcétera.
Podemos decir que una especificación es una declaración de un acuerdo entre

quien brinda un servicio y el consumidor del mismo.

Por ejemplo, las especificaciones de requerimiento son cuando el acuerdo

es entre el usuario final y el desarrollador del sistema; especificaciones de diseño
entre el diseñador o arquitecto del sistema y el programador que implementa el
diseño.
Una especificación nos puede decir qué queremos que el sistema haga, en el caso
de los modelos de Análisis.
Otras veces indican al implementarlo cómo debe hacerlo, como en el caso de las
especificaciones de Diseño.
Esta división a veces no es tan clara.
Muchas veces la manera de especificar qué es lo que queremos es por medio de

un ejemplo de cómo debería hacerse (lo que no implica necesariamente que deba
hacerse de esa forma sino que debe comportarse como si se hiciese así).
7.2.1.2 REVISIÓN E INSPECCIÓN
Las inspecciones:
Surgen a partir de la necesidad de producir software de alta calidad.
Las podemos ver como una implementación de las revisiones formales del
software las cuales representan un filtro para el proceso de ingeniería de software,
éstas se aplican en varios momentos del desarrollo y sirven para detectar defectos
que pueden así ser eliminados.
Freeman y Weinberg [Fre90] argumentan de la siguiente forma la necesidad de

revisiones: Una revisión es una forma de aprovechar la diversidad de un grupo de
personas para:
1. Señalar la necesidad de mejoras en el producto de una sola persona o de un

equipo.

7.2.1.3 ENTRADA FORMAL Y CRITERIOS DE SALIDA
Entrada/salida (I/O, de Input/Output):
Engloba las tareas complementarias de obtención de datos que procesa el

microprocesador y de entrega de los resultados a través de un dispositivo:
La pantalla
La unidad de disco o la impresora, etc.
Un dispositivo de entrada/salida transfiere información en las dos direcciones

posibles.
Para introducir datos se emplean dispositivos muy diversos. La mayoría de las

computadoras personales incluyen un teclado.
El reconocimiento de voz es muy empleado en algunas aplicaciones, pero estos

dispositivos de entrada son todavía imperfectos y sólo responden a un pequeño
vocabulario de instrucciones.
Los dispositivos de salida más habituales son las impresoras y los monitores en
color.
La salida de audio también es corriente, así como las complejas conexiones con
sintetizadores que producen una amplia gama de sonidos musicales.
7.2.1.4 PRUEBA FUNCIONAL
Functional Testing, son pruebas de software que tienen por objetivo probar que los
sistemas desarrollados, cumplan con las funciones específicas para los cuales han
sido creados, es común que este tipo de pruebas sean desarrolladas por analistas
de pruebas con apoyo de algunos usuarios finales, esta etapa suele ser la ultima
etapa de pruebas y al dar conformidad sobre esta el paso siguiente es el pase a
producción.
Objetivo:
Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo la

navegación, entrada de datos, procesamiento y obtención de resultados.

Metas:
Verificar el procesamiento, recuperación e implementación adecuada de las

reglas del negocio.
Verificar la apropiada aceptación de datos.
Enfoque:
Los requisitos funcionales (Casos de Uso) y las reglas del negocio.
Estas pruebas nos dicen que:
Se aplique apropiadamente cada regla de negocio.

Los resultados esperados ocurran cuando se usen datos válidos.
Sean desplegados los mensajes apropiados de error y precaución cuando
se usan datos inválidos.
En la mayoría de los casos éstas pruebas son realizadas manualmente por el

analista de pruebas, también es posible automatizarlas utilizando herramientas
como WinRunner o SilkTest las cuales permiten generar scripts conforme nosotros
hagamos interacciones con el aplicativo a probar.
7.2.1.5 PRUEBAS MULTIPLATAFORMA
Que tiene la capacidad de soportar múltiples plataformas.
Esto significa que el software que es multiplataforma tiene la característica de

funcionar de forma similar en distintas plataformas (distintos sistemas operativos
por ejemplo).
Una plataforma es, por ejemplo, un sistema operativo, un gran software que sirve
como base para ejecutar determinadas aplicaciones compatibles con este.
También son plataformas la arquitectura de hardware, los lenguajes de
programación y sus librerías en tiempo de ejecución, las consolas de videojuegos,
etc.
Existen programas multiplataforma, que permiten ejecutarse en diversas

plataformas. También existen emuladores, programas que permiten ejecutar
desde una plataforma programas de otra emulando su funcionamiento. Las
aplicaciones multiplataforma son aquellas que pueden funcionar en diferentes
sistemas operativos y/o ordenadores, pero el código fuente es el mismo. Los

programadores tendemos a escribir programas sólo válidos para nuestra

plataforma, olvidándonos de que hay usuarios que trabajan en otras.
Una de las grandes ventajas de las aplicaciones multiplataformas es que dan la

libertad al usuario de poder utilizar la máquina que más le guste. Unos usuarios
prefieren Linux (como es mi caso), otros prefieren Windows, otros MAC, etc. El
usuario debe poder elegir. Normalmente, son los fabricantes los que deciden por
nosotros: cuando sacan un nuevo software, sólo está disponible para las
máquinas que ellos decidan.
En este cuaderno técnico se explica cómo desarrollar aplicaciones para consola

(no gráficas) en entornos Linux que se puedan compilar para máquinas Windows,
sin tener que cambiar ni una sola línea de código fuente.
Es por ello que las pruebas del sistema desarrollado se debe tomar en cuenta que
funcione en la mayoría o todos los sistemas operativos que hay sin tener posibles
fallos, eso hace de el sistema más confiable y estable al momento de ser
implantado en una empresa u organización.
7.2.1.6 EJECUCIÓN AUTOMATIZADA DE PRUEBA
Una herramienta automatizada de la accesibilidad es un pedazo del software que

puede probar un Web page, o aún de un Web site entero, para la accesibilidad.
Free Articles. Las herramientas automatizadas de la accesibilidad son útiles
porque pueden ahorrarte una cantidad de tiempo enorme.
¿No desean comprobar las imágenes para saber si hay texto del alt en cada
página en tu Web site?
Funcionar el sitio a través de un probador automatizado.
Las herramientas de prueba automatizadas de la accesibilidad utilizan

generalmente las pautas de la accesibilidad de W3C. Estas pueden ser útiles
mientras que pueden ahorrar una cantidad de tiempo grande en la ejecución de
algunas comprobaciones para muy básicas accesibilidad.
Sin embargo, deben ser utilizadas con la precaución y no pueden ser utilizadas
como guía independiente para la comprobación de la accesibilidad. Herramienta
de validación de los colores de un website de acuerdo al Web Content
Accessibility Guidelines.

Check My Colour es una aplicación web con la que determinar la

conformidad de nuestro website con el WCAG, el estándar centrado en los
aspectos visuales, con el que lograr que nuestra web sea más fácil de leer,
mejorando el contraste de colores y la luminosidad.
Simplemente con introducir la URL de nuestra web, obtendremos en apenas unos

segundos y tras realizar una serie de pruebas basadas en World Wide Web
Consortium (W3C), una tabla completa donde ver cada uno de los aciertos
(verde) y los errores (rojo) encontrados, señalando en qué parte del código se
encuentra el error. http://www.checkmycolours.com
7.2.1.7 PROGRAMAS BETA
Cuando la palabra ―beta‖ se utiliza para referirse a un software, se trata de un

término corto para ―beta-test‖ también llamada versión beta.
Un periodo donde dicho software está técnicamente acabado, lo cual significa que
no se le añadirán de momento más funciones, y presumiblemente será lo
suficientemente estable para trabajar con normalidad. En contraste, la versión alfa,
lo cual ocurre antes de la versión beta, más inestable y no está completa.
Hay betas que son realmente software por testear, y otros que, simplemente, son
etiquetados como beta por los programadores por miedo a que puedan contener
algún error.
La beta es un comodín, haces algo si arriesgarte a que te critiquen por algún bug o
problema que cause tu software.
7.2.2 FUNDAMENTALES
El software será fundamental para los nuevos servicios que traiga la telefonía
móvil y Microsoft está trabajando para garantizar la interoperatibilidad de los
sistemas.
Se trata de facilitar el acceso universal a la información y la creación de nuevos

servicios, aplicaciones y dispositivos móviles. El software es el que hará inteligente
al dispositivo móvil que tendrá que poder utilizarse tanto cuando está en
disposición de ser utilizado para hablar o cuando está apagado como puede ser
en un avión.

Entre las pruebas fundamentales podemos mencionar:
1. Escenarios de usuarios.
2. Pruebas de utilidad.
3. Requerimientos para la planificación de la prueba.
4. Generación Automatizada de la prueba.
7.2.2.1 ESCENARIOS DE USUARIO
En estos escenarios, el administrador desea controlar las aplicaciones que un

usuario puede instalar y ejecutar.
Al utilizar una directiva de restricción de software, los administradores controlan

qué aplicaciones pueden instalar los usuarios con sus niveles de permiso
habituales.
AIS, Application Information Service) es un nuevo servicio de Microsoft Windows

Vista que implementa Protección de cuentas de usuario (UAP, User Account
Protection).
Repaso De los escenarios de prueba:
Para probar una directiva de restricción de software y la interacción con AIS, se

requiere que un usuario del dominio inicie la sesión en un equipo cliente de

Windows Vista con UAP habilitado y que intente instalar, ejecutar y

desinstalar una aplicación permitida y una no permitida, según lo defina la directiva
del dominio.
Escenario 1
Solicite al usuario del dominio que intente instalar una aplicación permitida.
El usuario debería poder instalar la aplicación sin que se le soliciten
credenciales de administrador.
Escenario 2
Para instalar una aplicación permitida:
Intente instalar una aplicación que el administrador del dominio no haya

permitido instalar explícitamente mediante una directiva.
El usuario no debería poder instalar la aplicación.
Escenario 3
Intente ejecutar una aplicación que el administrador del dominio haya

permitido que los usuarios ejecuten.
El usuario debería poder ejecutar la aplicación.
Escenario 4
Para ejecutar una aplicación permitida:
Intente ejecutar una aplicación que el administrador de dominio no haya

permitido que los usuarios ejecuten.
El usuario no debería poder ejecutar la aplicación.
Escenario 5
Para intentar ejecutar una aplicación no permitida:
Intente desinstalar una aplicación que el administrador del dominio haya

permitido que los usuarios puedan desinstalar.

Nota:
Esta prueba examina la interacción del Servicio de información de aplicaciones y

que el objeto de la directiva del dominio permite a los usuarios quitar aplicaciones
sin la necesidad de utilizar credenciales administrativas. En este caso, se aplica
configuración de directivas del dominio para permitir al usuario instalar, actualizar
y desinstalar aplicaciones.
7.2.2.2 PRUEBAS DE UTILIDAD
Todo debe ser modificado
Todas las cualidades relevantes del sistema deben ser verificadas:
Corrección: la implementación se comporta de acuerdo con las

especificaciones;
Portabilidad,
Modificabilidad,
Performance. Etc.
La verificación debe realizarse por distintas personas durante distintas etapas del
desarrollo del software; La gente del equipo de desarrollo podría realizar esto.
Objetivos de la Prueba de Software
Las pruebas del software pueden usarse para demostrar la existencia de errores,
nunca su ausencia. [Dijkstra, 1972]
Utilidad de las Pruebas
Si las pruebas no dan certeza sobre la corrección del software, ¿tienen alguna
utilidad?
Si bien no proporcionan certeza, las pruebas pueden aumentar nuestra confianza

en que el sistema se comportará como es esperado.
Lo esencial de las pruebas es:
elegir un conjunto de datos de prueba apropiados,

aplicar las pruebas en forma sistemática.

Valores Aleatorios de Prueba
Los datos aleatorios de prueba suelen no ser los más apropiados.
Sólo el desarrollador del programa sabe cuáles son los datos sensibles para cada
aplicación y cuáles los resultados esperados.
En el ejemplo no sirven una cantidad de casos de diferentes valores de (x,y), sino

solamente dos:
un caso con x igual a y,

un caso con x distinto de y.
Localizable, Repetible y Precisas
Las pruebas no solamente deben detectar la presencia de errores, sino que

deben indicar cuál es el error y dónde se encuentra.
Las pruebas deben organizarse para que provean información acerca de la
localización de los errores.
Las pruebas también deben ser repetibles: aplicadas dos veces, debieran
producir los mismos resultados.
La influencia del ambiente de ejecución atenta contra la repetibilidad de las
pruebas.
Los resultados esperados deben definirse dependiendo de los datos de
entrada y de otros eventos del ambiente.
Si la variable x no está inicializada y se tiene este trozo de programa, ¿cuál será el

resultado?
a veces ―anormal‖,
a veces ―normal‖.
Esta prueba no es repetible.
Algunos lenguajes no chequean que las variables estén inicializadas, por razones
de eficiencia.
Especificaciones Precisas
Las especificaciones del software deben ser suficientemente precisas como para
guiar las pruebas:

―como consecuencia del estímulo X, el sistema debe producir la
¿Qué prueba debe aplicarse?
Dar el estímulo X al sistema,

medir el tiempo hasta que produzca la salida,
segundos.
Pero, ¿qué sucede si ocurren otros eventos después de dar el estímulo X? ¿Cómo
se prueba un sistema concurrente?
Defectos, Fallas y Faltas
La presencia de un error o defecto se demuestra encontrando un d tal que P(d) es

incorrecto. Una falla es el síntoma de que existe un error; se da durante la
ejecución, pero un error puede existir en el código sin causar ninguna falla, el
objetivo de las pruebas es tratar de que todos los defectos existentes provoquen
fallas.
Una falta es un estado intermedio incorrecto en que entra un programa durante su

ejecución. Una falla solamente ocurre si existe una falta, ¿Qué ocurre si un
defecto no provoca una falla?, ¿Qué ocurre si una falta no produce una falla?
7.2.2.3 REQUERIMIENTOS PARA LA PLANIFICACIÓN DE LA PRUEBA
Durante la fase de requerimientos de software, las actividades deben realizarse de

acuerdo a los planes definidos en la fase UR. La principal actividad de esta fase
corresponde a la traducción de los requerimientos del usuario a requerimientos de
software. Las actividades a realizar son las siguientes:
Construcción del Modelo Lógico: Se debe construir un modelo independiente de la

implementación que especifica lo que el usuario requiere. Las herramientas CASE
facilitan la creación y modificación del modelo.
El estándar ESA explicita una serie de reglas para lograr un modelo lógico de
calidad (por ejemplo: Identificar Funciones Criticas).
Especificación de los Requerimientos de Software:

Los requerimientos de software son obtenidos analizando en el modelo

lógico creado.
Esta clasificación de requerimientos es:
a) Funcionales: Especifica lo que el software debe hacer.

b) Performance: Especifica valores numéricos para variables medibles (por
ejemplo: velocidad y capacidad).
c) Interfaz: Especifica los componentes de hardware, software o BD con que
el sistema o parte del sistema debe interactuar.
d) Operacionales: Especifica como el sistema funcionara y se comunicara con
los operadores.
e) Recursos: Especifica la necesidad de procesamiento, capacidad de
memoria, entre otros, que el sistema debe tener.
f) Verificación: Especifica las restricciones que serán verificadas.
g) Aceptación: Especifica las restricciones que serán validadas.
h) Documentación: Especifica documentación adicional al estándar para el
sistema.
i) Seguridad: Especifica lo necesario en seguridad del sistema para que sea
confiable, integro y disponible en todo momento.
j) Portabilidad: Especifica la facilidad del sistema para funcionar en otros PC o
sistemas operativos.
k) Calidad: Especifica atributos del sistema que asegurar que el sistema
estará a la altura de su propósito.
l) Confiabilidad: Especifica los intervalos de tiempo aceptable entre fallas del
sistema.
m) Mantenibilidad: Especifica la facilidad con se puede reparar las fallas en el
sistema o realizar up grades de este.
n) ―Safety‖: Especifica los requerimientos para reducir las posibilidades de
daño que pueden darse cuando falla el sistema.
Consistencia de los Requerimientos de Software:
Debe existir consistencia entre todos los requerimientos de software, es decir,

términos con un solo significado y usados para un solo propósito, actividades
secuencialmente realizadas y correctamente, etc
Duplicación de los Requerimientos de Software: Debe evitarse la duplicaron de

requerimientos de software.
Revisiones: Debe realizarse una revisión técnica en la fase SR/R

Con su estrategia de prueba, apunte a responder las siguientes preguntas:
¿Qué estamos verificando?, ¿Qué enfoque tomaremos?, ¿Qué otra información

necesito para planificar con eficacia?
Cuando planifique, formule preguntas como las siguientes:
¿Cómo llevaremos a cabo nuestras pruebas?, ¿Dónde las llevaremos a cabo?,

¿Cuándo las llevaremos a cabo?, ¿Cómo gestionaremos los problemas que
encontremos?, Etc.
Los siguientes son temas que usted puede encarar en su planificación de

prueba:
Preparaciones
Asignación de personal
Cobertura de la prueba
Todos los requerimientos de prueba (técnicos u otros)
Entornos de prueba
Criterios de ingreso
Criterios de salida
Delegación de responsabilidades
Adquisición de instalaciones
Planificación de tareas
Programación
Documentación sobre la coordinación y colaboración con otros equipos
Riesgos y problemas que puedan impactar sobre las pruebas
Entregables específicos del proyecto de prueba
Cuando usted lleva a cabo la planificación, deberá contar con:
Información sobre su contexto

Información sobre el problema (o proyecto)
Ideas sobre las pruebas
Ideas sobre la cobertura de las pruebas
Ideas sobre los riesgos del proyecto
Ideas sobre los detalles de la ejecución
Documentos o artefactos que apuntan a compartir las ideas que usted
tiene, y que resultan útiles para cuestionar los supuestos y las nociones

Documentos o artefactos que puedan ser necesarios para avanzar

en el proceso (según el contexto)
7.2.2.4 GENERACIÓN AUTOMATIZADA DE LA PRUEBA
(Rice 2002) enumera y explica los diez retos más importantes en la

automatización del proceso de pruebas. De acuerdo con este autor, éstos son los
siguientes:
1. Falta de herramientas, debida fundamentalmente a su elevado recio o a

que las existentes no se ajusten al propósito o entorno para el que se
necesitan. La primera razón parece deberse a la no mucha importancia que
habitualmente se le da a la fase de pruebas, y eso que el costo de corregir
un error puede, en muchos casos, superar al de la licencia de uso. Sería
conveniente evaluar el coste de corrección de defectos del software
entregado y compararlo con el de la licencia de la herramienta de pruebas.
2. Falta de compatibilidad e interoperabilidad entre herramientas.
3. Falta de proceso de gestión de la configuración. Igual que las diferentes
versiones del código fuente, las pruebas, especialmente las de regresión,
deben someterse a un control de versiones. Recuérdese que el proceso de
Gestión de la Configuración es uno de los procesos de soporte del estándar
ISO/IEC 12207 (ISO/IEC 1995), que debería utilizarse en la ejecución de
los procesos principales, y muy especialmente en los de Desarrollo y
Mantenimiento.
4. Falta de un proceso básico de pruebas y de conocimiento de qué es lo que
se debe probar.
5. Falta de uso de las herramientas de prueba que ya se poseen, bien por su
dificultad de uso, por falta de tiempo para aprender a manejarla, por falta de
soporte técnico, obsolescencia, etc.
6. Formación inadecuada en el uso de la herramienta.
7. La herramienta no cubre todos los tipos de prueba que se desean
(corrección, fiabilidad, seguridad, rendimiento, etc.). Obviamente, a la hora
de elegir la herramienta, deberían tenerse priorizados los tipos de pruebas,
y entonces hacer la elección de la herramienta basados en esto. A veces
también es necesario utilizar no una, sino varias herramientas de prueba,
así como tener en cuenta que es imposible automatizar el 100% de las
pruebas.
8. Falta de soporte o comprensión por parte de los jefes, debido otra vez a la
escasa importancia que habitualmente se le da a la fase de pruebas.
9. Organización inadecuada del equipo de pruebas.
10. Adquisición de una herramienta inadecuada

7.2.3 INCREMENTALES
Entre estas prácticas de pruebas se destacan las siguientes:
Cobertura de código
Generador de ambiente automatizado
Diagrama del estado de la prueba
Simulación de falla en la memoria
Pruebas estadísticas
Métodos semiformales
Registro de la prueba para el código
Benchmark
Generación de errores (bugs)
7.2.3.1 COBERTURA DE CÓDIGO
La cobertura de código es una medida que se utiliza en las disciplinas de

comprobación automática (automated testing) de software. Esta medida indica la
fracción de del software que las pruebas han cubierto. Si las pruebas nos indican
que nuestro software es correcto, la cobertura de código nos indica que partes de
nuestro software son correctas (esto no es del todo cierto, como veremos más
adelante). Es decir, La cobertura de código es una medida de calidad, pero no de
calidad de nuestro software, sino de nuestras pruebas: nos indica que partes del
software están comprobando nuestras pruebas y, lo más importante, cuáles partes
no estamos comprobando.
La cobertura de código, como las pruebas automáticas y la documentación del

código son ―cosas que hacen perder el tiempo‖ a los desarrolladores tontos y
―salvadores‖ para los desarrolladores con cabeza, aunque en realidad La
cobertura de código no nos hace perder mucho el tiempo, ya que la mayoría de los
casos es cuestión de utilizar alguna herramienta sobre nuestro software,
preferentemente sobre el ejecutable que realiza nuestras pruebas (si lo probamos
sobre un ejecutable final lo máximo que obtendremos es las partes del software
que el usuario ha utilizado).
La medida de La cobertura de código de nuestro software siempre será mejor

cuanto más cerca del 100% esté, pero llegar a esos números o incluso cerca
puede llegar a ser contra productivo. La idea es utilizar la herramienta de
cobertura de código sobre nuestras pruebas, comprobar que partes del código no
se han ejercitado y escribir nuevas pruebas que utilicen esas partes. Una
cobertura de código superior a 95% es un buen punto para detenerse.

Sin embargo la mayoría de herramientas de cobertura de código no son

capaces de comprobar más que lo que se llama ―cobertura de instrucción‖ o ―de
línea‖ (statement coverage o line coverage, a veces denominado C0), que indica si
una instrucción se ha ejecutado o no. En la mayoría de los casos esta medida ya
dice mucho de la calidad de las pruebas, pero no siempre: por ejemplo, el
siguiente código obtendría un 100% de cobertura si se ejecutase cualquiera de las
ramas:
If (condicion) {código 1;} else {código 2;}
Pero obviamente sí solo se ha ejecutado una de las ramas no se han comprobado

todos los caminos posibles. Otras medidas como la ―cobertura de ramas‖ o la
―cobertura de bloques‖ (branch coverage o C1, y block coverage) resuelven este
problema.
Más allá de C1 existen algunas medidas más de cobertura de código: entre las
más interesantes está C2 o ―cobertura de caminos‖ (path coverage) que se
encarga de comprobar que todos los caminos posibles entre el punto de entrada
de una función y el/los puntos de salida han sido cubiertos.
Int función (bool condicion1, bool condicion2, bool condicion3)
{Int resultado = 0;
If (condicion1) resultado += 1;
Return resultado;}
En el fragmento de código anterior existen 23=8 caminos posibles. Nuestras

pruebas deberían comprobar cada una de esas 8 posibilidades para conseguir una
cobertura C2 del 100%, mientras que con una única prueba conseguiríamos una
cobertura C0 total. Es por esto que los números que nos proporcionan las
herramientas para medir La cobertura de código no deben ser tomados como
valores absolutos, sino como indicaciones sobre como orientar nuestras siguientes
pruebas.
Para realizar las medidas de code coverage existen multitud de herramientas,

sobre todo para Java y .Net (los lenguajes con máquina virtual y grandes

capacidades de reflexividad son más sencillos de comprobar que

programas nativos, además de que últimamente son mucho más utilizados), pero
se puede encontrar casi para cualquier lenguaje. Podéis ver una pequeña lista de
herramientas de code coverage en el wiki de C2.
La mayoría de herramientas open source proporcionan medidas de C0 (que ya es

bastante, tengo que decir) y si tenemos suerte de C1. Pocas herramientas open
source proporcionan medidas de C2 o medidas más sofisticadas, aunque sí
existen herramientas comerciales que dicen proporcionar tales medidas.
Generalmente C0 nos da una buena idea de la calidad de nuestras pruebas y C1
nos proporciona más seguridad sobre esas medidas, con lo que la mayoría de
herramientas open source nos bastarán para quitarnos un gran peso de encima.
Una Herramienta ocupada para test de cobertura de código en Windows es:
Rational PurifyPlus for Windows.
Ayuda a los desarrolladores a identificar los errores de fiabilidad y rendimiento en

código. Incluye detección de corrupción de memoria, detección de pérdidas de
memoria, parametrización del rendimiento de aplicaciones y análisis de cobertura
del código.

7.2.3.2 GENERADOR DE AMBIENTE AUTOMATIZADO
Al diseñar sistemas de prueba automatizadas, resulta clave la maximización de

exactitud.
La mayoría de los ingenieros de prueba tornan su mirada a las hojas de datos

para los instrumentos que están evaluando con la esperanza de que estos
documentos proporcionen todas las respuestas.
Sin embargo, otros factores son igualmente importantes en la maximización de la

exactitud de sus sistemas de prueba automatizados.
A continuación se proponen cuatro estrategias que se pueden seguir para

maximizar la exactitud de sus sistemas de prueba automatizados.
1. Comprender las Especificaciones del Instrumento.
Resulta importante comprender que los diferentes vendedores de instrumentos

con frecuencia especifican la exactitud de medida utilizando ya sea diferente
terminología o terminología similar con diferentes significados. Es importante tener
en claro todos los parámetros involucrados en definir las características de un
instrumento.
2. Considerar Requerimientos de Calibración.
A pesar de la exactitud de los instrumentos que usted selecciona para sus

sistemas de prueba automatizados, es importante darse cuenta que las
exactitudes de los componentes electrónicos utilizados en todos los instrumentos
cambian a través del tiempo.
3. Monitoree el Sistema Operativo
No todos los instrumentos tienen las mismas especificaciones ambientales. Sus

sistemas de prueba automatizadas pueden encontrarse en un ambiente de oficina
donde la temperatura y humedad están altamente controladas, pero puede haber
una fábrica u otra instalación industrial.
4. Utilice la Configuración Apropiada.
Conectar su sistema de prueba automatizado al dispositivo bajo prueba (DUT)

puede ser tan simple como conectar cables entre instrumentos hacia una caja de

escape o terminales de refuerzo y conectarlas al DUT para sistemas con

menor de 50 puntos de prueba o bien, solo algunos instrumentos.
Los efectos del tiempo en el servicio así como condiciones ambientales, se

incorporan a este cambio. Para resolver este conflicto, sus instrumentos deben
calibrarse a intervalos regulares.
7.2.3.3 DIAGRAMA DEL ESTADO DE LA PRUEBA
Los diagramas de estado de la prueba:
Describen gráficamente los eventos y los estados de los objetos.

Son útiles, entre otras cosas, para indicar los eventos del sistema en los
casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el
sistema.
Un estado es la condición de un objeto en un momento determinado:
El tiempo que transcurre entre eventos. Una transición es una relación entre dos
estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior
al siguiente.
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos

que le ocurren, sus transiciones, y los estados que median entre estos
eventos.
Es útil hacer diagramas de estado para describir la secuencia permitida de
eventos en los casos de uso.
Una transición puede tener una protección condicional, o prueba booleana,
que permite pasar al siguiente estado solemente si esta protección es
válida. Estas protecciones se colocan entre paréntesis debajo de los
eventos
Los diagramas de estado describen gráficamente los eventos y los estados de los
objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los
eventos del sistema en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un

estado es la condición de un objeto en un momento determinado: el tiempo que
transcurre entre eventos. Una transición es una relación entre dos estados, e
indica que, cuando ocurre un evento, el objeto pasa del estado anterior al
siguiente.

En UML, los estados se representan mediante óvalos. Las transiciones se

representan mediante flechas con el nombre del evento respectivo. Se acostumbra
poner un estado inicial (círculo negro). Por ejemplo:
Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le

ocurren, sus transiciones, y los estados que median entre estos eventos.
En particular, es útil hacer diagramas de estado para describir la secuencia

permitida de eventos en los casos de uso. Por ejemplo, en el caso de uso comprar
Productos no está permitido efectuar pago Tarjeta mientras no haya ocurrido el
evento terminar Venta.
Un diagrama de estado que describe los eventos globales del sistema y su

secuencia en un caso de uso es un diagrama de estado para casos de uso. Por
ejemplo, una versión simplificada del diagrama de estados para el caso de uso
comprar Productos es el siguiente:

Una versión más completa del diagrama anterior se muestra en la siguiente

figura:
El diagrama anterior aun no está completo, pues falta considerar algunos casos
excepcionales, como por ejemplo, si al rechazar una tarjeta de crédito o un
cheque, el cliente decide pagar usando otro método, por ejemplo pagando en
efectivo.
Una transición puede tener una protección condicional, o prueba booleana, que
permite pasar al siguiente estado solamente si esta protección es válida. Estas
protecciones se colocan entre paréntesis debajo de los eventos (ver validación del
usuario al descolgar el auricular, en la siguiente figura). También se pueden tener
sub-estados anidados.

Las herramientas usadas en la etapa de análisis (investigación del

problema) se pueden resumir en la siguiente tabla.
7.2.3.4 SIMULACIÓN DE FALLA EN LA MEMORIA
El manejo de memoria consiste en la asignación y liberación de bloques de

memoria a medida que un programa lo solicite. Particularmente, la liberación de
memoria puede realizarse en forma manual o mediante técnicas automatizadas,
también conocidas como técnicas de recolección de basura, pues consisten en
identificar y liberar los bloques asignados que ya no serán accedidos desde la
aplicación (Simsek, 2005).
La Simulación de falla en la memoria evalúa si las aplicaciones no exceden los

límites de memoria en los peores casos, o situaciones criticas.
Puede ser utilizado para comprender el diseño de nuestro software que ejecuten
de forma óptima un determinado tipo de programas paralelos o para mejorar el
modo de operar de una arquitectura paralela concreta.
Permite establecer la configuración de los parámetros que definen la arquitectura

del sistema, ofreciéndonos la respuesta del mismo al someterlo a los accesos de
memoria generados por los programas permitiendo evaluar si nuestro sistema no
satura la memoria.
7.2.3.5 PRUEBAS ESTADÍSTICAS
Pruebas Estadísticas
A continuación se presentan algunas de las opciones que el software debe

proporcionar para la realización de las pruebas estadísticas que se utilizan para
validar el cumplimiento de los supuestos planteados durante la elaboración del
modelo.

Estadísticas Descriptivas
Incluye valor medio, desviación estándar, altura, esbeltez, normalidad de los datos
y valores máximos y mínimos. Principalmente utilizado para chequear si los datos
se distribuyen en forma normal y con valor medio cero para el caso de los
residuales.
Test de Heterocedasticidad
En primer lugar se debe crear una variable que contenga los valores de los
residuales (previa definición del modelo como fue indicado anteriormente), para
luego continuar con el siguiente procedimiento.
Test de Auto correlación
Luego de definirse el modelo, se puede chequear la presencia de auto correlación

mediante varios pasos. Entregando como resultado la aceptación o rechazo de la
hipótesis nula de no existencia de auto correlación.
Test de Multicolinealidad
Para chequear si las variables independientes se encuentran o no relacionadas en

forma lineal, se debe obtener la matriz de correlación.
El programa devuelve una matriz en donde aparecen las correlaciones entre todas
las variables incorporadas al modelo y sólo resta interpretar los resultados.
Test de inferencia
El programa incluye los test para verificar el cumplimiento de las hipótesis.
Implica tener un método para medir la fiabilidad. Este sistema, al contrario que los
sistemas de test, no busca el fallo sino todo lo contrario Tiene cuatro etapas:
1. Obtención de un perfil operativo de los sistemas en uso.

2. El perfil operativo es el estudio de conjunto de posibles entradas.
3. Se construye un conjunto de entrada de test en función del perfil anterior
4. Se prueba el sistema contra estos datos y se computa:
• Número de fallos
• Tiempo o frecuencia de los errores

7.2.3.6 MÉTODOS SEMIFORMALES
Se encuentran dentro de las Metodologías o técnicas de Desarrollo del Software,

hablamos de especificaciones semi-formales cuando hacemos uso de un lenguaje
semi-formal, es decir, un lenguaje que tiene una sintaxis más o menos precisa y
una semántica informal. Un ejemplo de este tipo de notación son los diagramas de
UML, los diagramas de Entidad-Relación, etc.
Notación especifica y definida sigue reglas y normas que se pueden validar,

Cuando hacemos uso de un lenguaje semiformal, es decir, un lenguaje que tiene
una sintaxis más o menos precisa y una semántica informal por ejemplo:
Modelos Gráficos.
Notaciones.
Métodos Estructurados
SA/SD (structured analysis & structured design)

Métrica
Métodos Orientados a Objetos
OMT
UML
Métodos Orientados a la Estructura de los Datos, Métodos de flujo de datos

Los métodos orientados a objeto describen e implementan los sistemas de

información desde un punto de vista ontológico.
7.2.3.7 REGISTRO DE LA PRUEBA PARA EL CÓDIGO
Test Driven Development (TDD) es una práctica de programación que involucra

otras dos prácticas: Escribir las pruebas primero (Test First Development) y
Refactorización (Refactoring). Para escribir las pruebas generalmente se utiliza la
Prueba Unitaria (unit test en inglés).
Primeramente se escribe una prueba y se verifica que las pruebas fallen, luego se
implementa el código que haga que la prueba pase satisfactoriamente y
seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado
por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that
Works). La idea es que los requerimientos sean traducidos a pruebas, de este
modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan
implementado correctamente.
Estas pruebas son una herramienta esencial para la investigación de la interacción

persona ordenador, y también dentro del campo que ha venido a llamarse
"usabilidad".
TDD se propone agilizar el ciclo de escritura de código y realización de pruebas de

unidad. Las pruebas de unidad son las que se aplican a una parte de un programa
para comprobar que cumpla su función específica. En los métodos tradicionales
de desarrollo de software, estas pruebas son llevadas a cabo por personas cuya
única tarea es asegurar la calidad del producto final.
El hecho de que quienes estén a cargo de escribir el código y quienes deban

probarlo sean grupos distintos suele originar cierto nivel de competencia: los
programadores se esfuerzan por escribir código correcto, que luego deberán
entregar a sus "oponentes" para que traten de demostrar lo contrario, encontrando
los casos en que el programa falla. Si bien la competencia resulta provechosa en
ciertas circunstancias, un equipo de desarrollo debería estar conformado por

individuos que realizaran un esfuerzo conjunto detrás de un objetivo común,

sin enfrentarse entre ellos.
Además, el trámite que supone enviar el código para que sea probado demora el
avance del proyecto. El programador no entrega su código hasta que lo ha
revisado lo suficiente. Recién en ese momento se lo prueba, se documentan los
errores y, para resolverlos, el programador - quien ha estado esperando o ha
comenzado a trabajar en otra parte del proyecto - tiene que volver a sumergirse en
ese código que había dejado de lado.
La propuesta del Desarrollo guiado por Pruebas es radicalmente distinta a la

explicada en el párrafo anterior. Según esta práctica, es el programador quien
realiza las pruebas de unidad de su propio código, e implementa esas pruebas
antes de escribir el código a ser probado.
Cuando el programador recibe el requerimiento de implementar una parte del

sistema, y una vez que comprendió cuál es la funcionalidad pretendida, debe
empezar por pensar qué pruebas va a tener que pasar ese fragmento de
programa (o unidad) para que se considere correcto. Luego procede a programar,
pero no el código de la unidad que le tocó, sino el código que se va a encargar de
llevar a cabo las pruebas. Cuando está satisfecho de haber escrito todas las
pruebas necesarias (y no antes), comienza a programar la unidad, con el objetivo
de pasar las pruebas que programó.
La forma de trabajo del programador también cambia mucho durante la escritura

del código funcional propiamente dicho. En lugar de trabajar durante horas o días
hasta tener la primera versión en condiciones de ser probada, va creando
pequeñas versiones que puedan ser compiladas y pasen por lo menos algunas de
las pruebas. Cada vez que hace un cambio y vuelve a compilar, también ejecuta
las pruebas de unidad. Y trata de que su programa vaya pasando más y más
pruebas hasta que no falle en ninguna, que es cuando lo considera listo para ser
integrado con el resto del sistema.
Una de las grandes diferencias con el estilo de trabajo tradicional es que ya no

compite con otro u otros, sino que compite consigo mismo; se enfrenta al desafío
de escribir código que pase las pruebas que él mismo programó. Y siguiendo las
premisas de muchos de los métodos ágiles, solamente programará lo que sea
estrictamente necesario para ese fin.
Pasemos a un ejemplo muy simple, para ilustrar cómo funciona este proceso.
Supongamos que me toca desarrollar un componente .NET que se encargue de

ordenar un arreglo de valores enteros y que, como parte del diseño, se ha

decidido hacerlo mediante el algoritmo de bubble sort u ordenamiento por
burbujeo. Para los que no recuerden o no conozcan este algoritmo; se trata de
recorrer el arreglo intercambiando entre sí los elementos contiguos que se
encuentren en el orden inverso al buscado, y recomenzar ese procedimiento
tantas veces como sea necesario, hasta que no queden pares por intercambiar.
Como estoy haciendo TDD, tengo que empezar por decidir qué pruebas voy a
hacer. Elijo probar con varios arreglos de cinco elementos que siempre serán los
números del 1 al 5. Y se me ocurren las siguientes pruebas:
1. Un arreglo ordenado;
2. Un arreglo que tenga solamente un par de elementos contiguos fuera de
orden;
3. Un arreglo que tenga el último elemento al principio (y el resto de ellos en
orden);
4. Un arreglo que tenga el primer elemento al final;
5. Un arreglo completamente invertido.
Tal vez no sea suficiente, pero yo me siento conforme. Pienso que si logro escribir
un programa que pase odas estas pruebas, habré cumplido con lo pedido. l paso
siguiente es implementar las pruebas en la forma de un programa que examine mi
componente.
Dado que todo desarrollador guiado por pruebas tiene que crear frecuentemente
programas de este tipo, existen herramientas que facilitan el trabajo.
7.2.3.8 BENCHMARK
Un benchmark es un conjunto de procedimientos (programas de computación)

para evaluar el rendimiento de un ordenador. Hay cuatro categorías generales de
pruebas de comparación:
Pruebas aplicaciones-base (application-based) las ejecuta y las cronometra.

Pruebas playback (playback test), las cuales usan llamadas al sistema
durante actividades especificas de una aplicación (Ej.: Llamados a gráficos
o uso del disco) y las ejecuta aisladamente.
Prueba sintética (synthetic test), la cual enlaza actividades de la aplicación
en subsistemas específicos.

Prueba de inspección (inspection tests), la cual no intenta imitar la

actividad de la aplicación, sino que las ejecuta directamente en los
subsistemas específicos.
Los test de aplicaciones base entregan la mejor forma de medir el rendimiento

completo de el sistema en el mundo real.
El programa Winstone de Zdnet, ejecuta mas de una docena de las aplicaciones

más populares en el ambiente Windows, es un ejemplo de este tipo de
comparadores.
Donde sea factible la tecnología playback le da la manera más real de medir

subsistemas individuales en aislación.
El programa WinBench de ZDnet utiliza la tecnología playback para probar

gráficos, Cd-rom y subsistemas de disco duro, también corre cientos de otras
pruebas en áreas especificas del computador.
Los test Synthetic continúan en el estado de medición del rendimiento es por eso
que winbench usa las pruebas de procesadores.
Los test de inspección tienen su lugar verificando el comportamiento libre de fallas

y midiendo rendimiento operación por operación, por esto se incluye el test de
inspección en el winbench.
Dhrystone
Dhrystone es una medida de rendimiento de la CPU en entero, expresado en

Millones de instrucciones por segundo (MIPS).
El Dhrystone benchmark es ampliamente usado en la industria de las

computadoras como una medida de rendimiento, Wintune (programa benchmark)
usa la versión modificada del Dhrystone que mantiene sus datos en el
almacenador del programa. Esto permite al benchmarks trabajar apropiadamente
en múltiple threads en Windows NT.
El Dhrystone estándar, fue originalmente diseñado para un único ambiente (single-

threaded), manteniendo alguno de sus datos en variables estáticas globales.
El Dhrystone es un benchmark sintético, diseñado para contener ejemplos

representativos de las operaciones normalmente requeridas por las aplicaciones.

Estas no calculan el resultado de ningún tipo, pero hacen enlaces de

complicadas secuencias de instrucciones usadas por las aplicaciones.
El resultado del Dhrystone es determinado por el tiempo que toma la medición

para ejecutar esta secuencia de instrucciones.
La aritmética del entero simple, decisiones lógicas, y accesos de memoria son las
actividades dominantes de la CPU en la mayoría de los programas Windows.
El Dhrystone benchmark hace un uso intensivo de estas áreas. Por lo tanto el

Dhrystone no tiene suficiente código de programa o acceso suficiente a las
locaciones de memoria para simular la actividad de la mayoría de los programas
reales.
Su lugar de trabajo de código y datos puede generalmente ser mantenido en el

cache de la CPU, con lo cual resulta con un alto rendimiento.
Desde que el Dhrystone no ofrece una buena indicación del rendimiento de

memoria, Wintune tiene un set separado de prueba de memoria.
Whetstone
Whetstone es una medida de rendimiento de la CPU en punto flotante, expresado

en Millones de operaciones de punto flotante por segundo (MFLOPS).
El Whetstone benchmark es ampliamente usado en la industria de la computación

como una medida de rendimiento, Wintune usa una versión modificada del
Whetstone que mantiene sus datos en el programa de almacenamiento. Esto
permite al benchmarks trabajar apropiadamente en múltiples threads en Windows
NT.
El Whetstone estándar, fue originalmente diseñado para un ambiente único,

manteniendo alguno de sus datos en variables estáticas globales.
La aritmética del punto flotante es la más significativa en programas que requieren

FPU. Estos son en su mayoría ingeniería científica, de estadísticas, y programas
de ayuda de diseño en computación. Es también un pequeño componente en hoja
de cálculo, dibujo y pintado de programas. (Aunque la hoja de cálculo trabaja con
números también tiene una mejor presentación en pantalla.) Los programas
procesadores de texto típicamente no hacen ningún computo en punto flotante. El
Whetstone hace mucha aritmética del punto flotante un poco de acceso de
memoria, y un poco la aritmética del entero.

¿Porqué considerar el Rendimiento?
Juzgar el rendimiento de un sistema cuando se están tomando decisiones de

compra es algo crítico a fin de retardar la obsolescencia y proteger su inversión.
7.2.3.9 GENERACIÓN DE ERRORES (BUGS)
Resolver los problemas cuando se presentan es un proceso fácilmente

determinado, pero prevenir problemas es una tarea muy minuciosa y muy difícil de
determinar.
“En la antigua china existía una familia de curadores, uno de los integrantes de
esta familia siendo ya muy reconocido fue contratado por uno de los grandes
Señores del territorio como su medico personal. Una noche mientras cenaban el
Señor le pregunta al medico cual de sus otros familiares era tan poderoso como el,
entonces el medico comento; Yo atiendo a personas con grandes males, casi
moribundos llegan a mi con cierta fe, y algunas veces logro curarlos, y mi nombre
es reconocido en casi todo el territorio. Mi hermano mayor cura las enfermedades
cuando recién comienzan a hacer raíz en el cuerpo y su nombre es reconocido en
los vecindarios, mi hermano menor cura enfermedades antes de que aparezcan y
solo es conocido por la familia y su nombre no ha salido de la casa.”
Es decir, arreglar o corregir un problema o bug después que sale a la luz es una
tarea relativamente sencilla, ya que se conoce el foco del problema, el
inconveniente esta en corregir un error que no esta visible o no ha sucedido
todavía.
¿Cuales son las razones para que un programa contenga Bugs?
Poca o falta de comunicación entre diferentes aplicaciones. (Requerimientos

de las aplicaciones.)
Complejidad del software:
Causa dificultad en la reutilización de código y generalmente requiere personas

con experiencia en desarrollo de software moderno como por ejemplo en sistemas
cliente servidor, aplicaciones distribuidas, comunicación de datos, manejo de
enormes bases de datos relacionales y un gran manejo de técnicas orientadas a
objetos. A veces estos conocimientos también pueden causar más errores de los
que corrigen.

Errores de programación: Los programadores son uno de los principales

factores en la causa de errores o Bugs.
Requerimiento de cambio en el sistema:
El rediseño y la re planificación causan efectos en otros proyectos que trabajan en

conjunto o a partir de resultados del sistema modificado.
Estos procesos cooperativos generan más complejidad en las diferentes pruebas y

en el control y generalmente el entusiasmo de los desarrolladores del sistema se
ve afectado al tener que realizar actividades diferentes o no correspondientes a su
labor.
Como por ejemplo el de los ingenieros al tener que hacer un análisis funcional a
partir de su planificación, todo esto influye y atenta con la integridad del programa
y genera riesgos de una gran cantidad de errores.
Presiones de tiempos:
Una buena planificación y un buen análisis con sus respectivos controles de

calidad y prueba se ven afectados por un lapso corto de tiempo para que esto sea
completo. La falta de tiempo generalmente conlleva a no considerar u omitir
ciertas fases de prueba y control.
El ego (aspecto psicológico del personal):
A veces la situación y el contexto llevan a que la gente diga:
- No hay problema
- Es muy fácil.
- Puedo terminar esto en pocas horas.
-No habrá inconvenientes en adaptar ese viejo código.
En vez de decir:
-Eso es muy complejo.

-Nos llevara a cometer varios errores.
-No puedo estimar cuanto tiempo me llevara este trabajo.
-No se como readaptar ese código.
Son muchas las ocasiones en las que un “No hay problema” genera un Bugs.

Pobre documentación del código:
Es difícil poder modificar código cuya documentación es escasa o esta mal escrita.
En muchas organizaciones los directivos no incentivan a los programadores a

realizar una buena documentación e incluso a no darle importancia a la
entendibilidad del código, como también el hecho de incentivar demasiada
seguridad en la documentación y escritura del código. Lo que fue difícil de escribir
podría llegar a ser difícil de leer y aun mas complicado de modificarlo.
Herramientas de desarrollo de software:
Herramientas visuales, librerías de clases, compiladores, herramientas de

escritura, etc., a menudo introducen código extra con pobre documentación lo cual
genera un Bugs en el programa en cuestión.
Un serio manejo de control de calidad en la codificación es absolutamente

necesario para evitar estos Bugs, por lo que un nuevo software debe garantizar
cumplir con lo formalizado.
Un Buen código es aquel que funciona sin Bugs, además debe ser legible y
mantenible, se debe ajustar a los estándares de la organización para que todos los
desarrolladores del sistema manejen y entiendan las mismas herramientas y
mecanismos en la codificación.

Unidad VIII
Derechos de autor en México (software)
Objetivo: El alumno conocerá y aprenderá cómo proteger y registrar un programa

de cómputo en México a través la Ley Federal del Derecho de Autor.
Contenido:
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.7.1 Definición
8.7.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.1. LEY FEDERAL DEL DERECHO DE AUTOR EN MÉXICO.
El Derecho de autor es un conjunto de normas y principios que regulan los

derechos morales y patrimoniales que la ley concede a los autores por el solo
hecho de la creación de una obra literaria, artística o científica, tanto publicada o
que todavía no se haya publicado.
¿Quién es el autor?
La persona física que ha creado una obra literaria y artística.
¿Qué es el Derecho de Autor?
Es el reconocimiento que hace el Estado a favor de todo creador de obras

literarias y artísticas, en virtud del cual otorga su protección para que el autor goce
de privilegios exclusivos de carácter personal y patrimonial.
¿Qué vigencia tiene el Derecho de Autor?
La vida del autor y, a partir de su muerte, cien años más, cuando la obra
pertenezca a varios coautores los cien años se contarán a partir de la muerte del
último, y cien años después de divulgadas.
¿Qué tipo de obras protege el Derecho de Autor?
Aquellas de creación original susceptibles de ser divulgadas o reproducidas

en cualquier forma o medio, las cuales están incluidas en las siguientes ramas:
• Literaria.
• Musical, con o sin letra.
• Dramática.
• Danza.
• Pictórica o de dibujo.
• Escultórica y de carácter plástico.
• Caricatura e historieta.
• Arquitectónica.
• Cinematográfica y demás obras audiovisuales.
• Programas de radio y televisión.
• Programas de cómputo.
• Fotográfica.

• Obras de arte aplicado que incluyen el diseño gráfico o textil.

• Colección de obras de arte.
BREVE DESCRIPCIÓN DE LOS SERVICIOS EN MÉXICO:
El área de los Derechos de Autor se ocupa de la presentación de solicitudes

de registros de los distintos tipos de obras protegidas por el Derecho de Autor, de
la inscripción de contratos y de la presentación de recursos legales por violación
de los Derechos de Autor de los clientes.
8.1.1 DEFINICION
El derecho de autor (del francés droit d' auteur) es un conjunto de normas y

principios que regulan los derechos morales y patrimoniales que la ley concede a
los autores (los derechos de autor), por el solo hecho de la creación de una obra
literaria, artística, científica o didáctica, esté publicada o inédita.
En el derecho anglosajón se utiliza la noción de copyright (traducido

literalmente como "derecho de copia") que -por lo general- comprende la parte
patrimonial de los derechos de autor (derechos patrimoniales).
Una obra pasa al dominio público cuando los derechos patrimoniales han
expirado. Esto sucede habitualmente trascurrido un plazo desde la muerte del
autor (post mortem auctoris). Por ejemplo, en el derecho europeo, 70 años desde
la muerte del autor. Dicha obra entonces puede ser utilizada en forma libre,
respetando los derechos morales.
El titular de los derechos de autor goza de derechos exclusivos respecto de:
• Reproducir la obra en copias o fonogramas.

• Preparar obras derivadas basadas en la obra.
• Distribuir copias o fonogramas de la obra al público vendiéndolas o
haciendo otro tipo de transferencias de propiedad tales como alquilar,
arrendar o prestar dichas copias.
• Presentar la obra públicamente, en el caso de obras literarias, musicales,
dramáticas y coreográficas, pantomimas, películas y otras producciones
audiovisuales.
• Mostrar la obra públicamente, en el caso de obras literarias, musicales,
dramáticas coreográficas, pantomimas, obras pictóricas, gráficas y
esculturales, incluyendo imágenes individuales de películas u otras
producciones audiovisuales.

• En el caso de grabaciones sonoras, interpretar la obra públicamente

a través de la transmisión audio digital.
La protección del derecho de autor existe desde que la obra es creada de

una forma fijada. El derecho de autor sobre una obra creada se convierte
inmediatamente en propiedad del autor que creó dicha obra. Sólo el autor o
aquellos cuyos derechos derivan del autor pueden reclamar propiedad.
Los autores de una obra colectiva son co-dueños del derecho de autor de
dicha obra a menos que haya un acuerdo que indique lo contrario.
El derecho de autor de cada contribución individual de una publicación

periódica o en serie, o cualquier otra obra colectiva, existen a parte del derecho de
autor de una obra colectiva en su totalidad y están conferidos inicialmente al autor
de cada contribución. La mera posesión de un libro, manuscrito, pintura o
cualquier otra copia o fonograma le otorga al dueño el derecho de autor.
Los menores de edad pueden reclamar derecho de autor, pero las leyes
específicas pueden reglamentar cualquier transacción relacionada con este tema
donde ellos sean parte.
CLASES DE DERECHOS DE AUTOR
Dentro de la tradición jurídica del Derecho continental, Derecho internacional, y

Derecho mercantil, se suelen distinguir los siguientes tipos de derechos de autor:
• Derechos patrimoniales: son aquellos que permiten de manera exclusiva la

explotación de la obra hasta un plazo contado a partir de la muerte del
último de los autores, posteriormente pasan a formar parte del dominio
público pudiendo cualquier persona explotar la obra.
• Derechos morales: son aquellos ligados al autor de manera permanente y
son irrenunciables e imprescriptibles.
• Derechos conexos: son aquellos que protegen a personas distintas al autor,
como pueden ser los artistas, intérpretes, traductores, editores, productores,
etc.
• Derechos de reproducción: es un fundamento legal que permite al autor de
la obra impedir a terceros efectuar copias o reproducciones de sus obras.
• Derecho de comunicación pública: derecho en virtud del cual el autor o
cualquier otro titular de los derechos puede autorizar una representación o
ejecución viva o en directo de su obra, como la representación de una pieza
teatral o la ejecución de una sinfonía por una orquesta en una sala de

concierto. Cuando los fonogramas se difunden por medio de un

equipo amplificador en un lugar público, como una discoteca, un avión o un
centro comercial, también están sujetos a este derecho.
• Derechos de traducción: para reproducir y publicar una obra traducida se
debe solicitar un permiso del titular de la obra en el idioma original.
8.1.2 ARTICULOS PARA LA PROTECCION JURIDICA DEL SOFTWARE.
La protección de la propiedad intelectual en el mercado mundial ha tomado

reciente significación en los recientes años. Los propietarios de tecnología del
mundo desarrollado, particularmente los estadounidenses, han presionado
recientemente para obtener un régimen legal de propiedad intelectual fuerte y
relativamente uniforme, como piedra de toque para obtener un tratamiento
equitativo en el sistema global del comercio que emerge. Por otro lado, la
posibilidad de incorporar a la protección jurídica estos programas de computo en
el ámbito del derecho, específicamente en el de la propiedad intelectual y
particularmente en las normas autorales, viene dictada por consideraciones de
oportunidad, dada la dimensión económica de los intereses en juego entre los que
cabe destacar: la posible conservación de la industria nacional frente a una fuerte
concurrencia extranjera, la protección de un producto cuya elaboración requiere un
gran esfuerzo de inversión, investigación y posterior difusión, y sobre todo, la
evidente necesidad de una armonización internacional de reglamentaciones.
En la práctica jurídica internacional, la evolución de la materia no es

específica. Se puede comprobar, como en un principio, los programas de
computadora fueron objeto de protección a través de diversas formulas como el
secreto industrial, las cláusulas de confidencialidad en los contratos y la
competencia desleal, pero pronto se puso de manifiesto su insuficiencia, y los
medios profesionales interesados solicitaron una regulación que les asegurara la
propiedad y la protección derivada de la misma.
PROTECCION JURIDICA EN NUESTRO PAÍS
En nuestro país, la Ley de Fomento y Protección de la Propiedad

Industrial, publicada en el diario oficial de la federación el 27 de junio de 1991 y
modificada en su denominación el 29 de julio de 1994 por la Ley de Propiedad
Industrial, establece que los programas de computo no son considerados como
invenciones y, por tanto no son susceptibles de protección por la vía de patentes.

Esta nueva Ley viene a complementar e innovar la reglamentación

respecto a los programas de cómputo, que, si bien ya eran regulados por la
anterior ley autoral de 1956, no se constituían en formación y estructuración como
en el actual capitulo IV del titulo IV de la Ley Federal.
En efecto, esta Ley Federal del derecho de autor, publicada en le Diario

Oficial de la Federación con fecha 24 de diciembre de 1996 cuya entrada en vigor
se dio noventa días posteriores a su publicación, establece un capitulo en
particular aquellas regulaciones respecto a ―los programas de computación y las
bases de datos‖.
LEY DE DERECHOS DE AUTOR EN SOFTWARE
Capítulo I
DISPOSICIONES GENERALES
Artículo 1º.- Para efectos de la presente ley, se entiende por programa de

computación la expresión original en cualquier forma, lenguaje o código, de un
conjunto de instrucciones que, con una secuencia, estructura y organización
determinada, tiene como propósito que una computadora o dispositivo realice una
tarea o función específica. Tendrán igual significado y connotación, para los
efectos de sistematización del presente ordenamiento jurídico, los siguientes
términos:
a) "programa de cómputo",
b) "programa de computación",
c) "programa para computadora", o
d) "software".
Artículo 2º.- La protección a los derechos de autor de programas de

computación queda sujeta a lo previsto en la presente ley. A falta de
disposición expresa, se estará a las prevenciones de la Ley Federal de Derechos
de Autor.
Artículo 3º.- La protección a que se refiere esta ley, se extiende tanto a los
programas operativos como a los programas aplicativos, ya sea en forma de
código fuente o de código objeto. Se exceptúan aquellos programas de cómputo
que tengan por objeto causar efectos nocivos a otros programas o equipos.

Artículo 4º.- Para efectos de la presente ley, un programa de computadora

será considerado similar a otro cuando cumpla las condiciones siguientes:
I. Ser funcionalmente equivalente, considerando que debe:
a) Ser original y desarrollado de manera independiente.

b) Tener, fundamentalmente, las mismas características de desempeño,
considerando el tipo de aplicación a que está destinado.
c) Operar en equipo similar y en un ambiente de procesamiento similar.
II. Ejecutar substancialmente las mismas funciones, considerando el tipo de

aplicación al que está destinado y las características del mercado nacional.
III. Presentar analogías en cuanto a los parámetros relevantes, incluyendo los

numéricamente mensurables, los requisitos de memoria, tiempo de procesamiento
y capacidad de transacción entre usuarios y sistemas.
Artículo 5º.- Por lanzamiento se entenderá el momento en que el autor del

programa lo utiliza o pone a disposición de otro. Queda asegurada la tutela de los
derechos relativos a los programas para computadora por un plazo de 25
(veinticinco) años, contados a partir de su lanzamiento en cualquier país.
Los derechos atribuidos por la presente Ley a los extranjeros con

domicilio en el exterior, quedan asegurados siempre que el país de origen del
programa mantenga reciprocidad con México, y conceda derechos equivalentes
en extensión y duración a los establecidos en el párrafo anterior del presente
artículo.
Artículo 6º.- Salvo pacto en contrario, los derechos patrimoniales relativos al

programa para computadora, desarrollado y elaborado durante la vigencia del
contrato o del vínculo estatutario, expresamente destinado a la investigación y
desarrollo, o donde esté prevista la actividad del empleado, funcionario o
prestador de servicios, o que pertenezca a la propia naturaleza de los encargos
contratados, pertenecerán exclusivamente al empleador o contratante de
servicios. Salvo cláusula en contrario, la compensación del trabajo o servicio
prestado se limitará a la remuneración o salario convenido. Los derechos
concernientes al programa para computadora creado sin relación al contrato de
trabajo, vínculo estatutario o prestación de servicios, y sin utilizar recursos,
informaciones tecnológicas, materiales, instalaciones o equipos del empleador o

contratante de servicios, pertenecerán con exclusividad al creador de dicho

software.
Artículo 7º.- Cuando se estipule en contrato firmado entre las partes, los
derechos sobre las modificaciones tecnológicas y derivaciones, pertenecerán a la
persona autorizada que las haga, y que los ejercerá autónomamente.
Artículo 8º.- El plazo de la cesión de derechos en materia de informática no está

sujeto a limitación alguna; excepto en los casos en que no exista estipulación
expresa, y siendo así toda transmisión de derechos patrimoniales se considerará
por el término de 5 años, pudiendo pactarse por más de 15 años cuando la
magnitud de la inversión así lo justifique.
Artículo 9º.- No constituirán ofensa al derecho de autor de un programa de

cómputo:
I. La reproducción de una copia legítimamente adquirida, siempre que sea

indispensable para la utilización adecuada del programa.
II. La citación parcial para fines didácticos, siempre que se identifiquen el autor y el
programa referido.
III. La semejanza entre un programa y otro ya existente, siempre que la misma

esté causada por las características funcionales de su aplicación, por la
observación de los preceptos legales, reglamentarios o de normas técnicas o de
la limitación de la forma alternativa para su expresión.
IV. La integración de un programa, con todas sus características esenciales, a un

sistema aplicativo u operacional, técnicamente indispensable para las necesidades
del usuario siempre que sea para uso exclusivo de quien lo promovió.
Capítulo II
DE LA INSCRIPCIÓN DEL PROGRAMA DE CÓMPUTO
Artículo 10.- Los programas de cómputo serán inscritos en el Registro Nacional

de Programas de Cómputo, creado al efecto. Para llevar a cabo la
comercialización de un programa de computación, será necesaria la inscripción
del programa o conjunto de programas bajo las siguientes categorías de
clasificación, las cuales deberán ser proporcionadas por el interesado junto con el
pedido de inscripción y aprobadas por el Registro:

I. Por su procedencia:
a) Nacionales: a aquellos creados y producidos en nuestro país.

b) Internacionales: los creados y producidos en cualquier otro país del
extranjero.
c) Mixto: aquellos creados en asociación de nacionales e internacionales.
II. Por sus componentes:
a) De comando.
b) Ejecutables.
c) De complemento para aplicaciones.
d) De control de periféricos o drivers.
e) De sistema.
f) De datos.
III. Por su estado de desarrollo:
a) Core code o código base.

b) Demoware o programa de demostración.
c) Versiones beta o programas de prueba.
d) Software V 1.0.0. ó programa comercializable.
IV. Por su destino:
a) De investigación y científico.
b) Industrial.
c) Gubernamental.
d) Entretenimiento.
e) Empresarial.
f) Uso doméstico.
Los demás programas de cómputo que, por analogía, puedan considerarse

innovadores dentro de su medio, se incluirán dentro de las clasificaciones que les
sean más afines a su naturaleza. Los procedimientos operacionales serán
regulados por el Reglamento del Registro Nacional de Programas de Cómputo.
Artículo 11.- La aprobación de los actos y contratos referidos en la presente Ley

por parte de la Dirección General del Derecho de Autor y la inscripción del
programa de cómputo, son condiciones previas y esenciales para:

I. La validez y eficacia de cualquier tipo de negocio jurídico relacionado con

software.
II. La producción de efectos fiscales, así como la legitimación de pagos, créditos o

remesas correspondientes, cuando sea el caso, sin perjuicio de otros requisitos y
condiciones establecidas por ley.
Artículo 12.- La inscripción de programas de computadora quedará sin efecto, en

cualquier momento:
I. Por sentencia judicial tramitada en juzgado.
II. Por acto administrativo, cuando quede comprobado que las informaciones
presentadas por el interesado para presentar su pedido de registro no fueran
verídicas.
Artículo 13.-Las acciones de nulidad del registro podrán ser intentadas por
cualquier interesado, ya sea particular o cualquier dependencia gubernamental.
Artículo 14.-Para solicitar un pedido de registro de programa de cómputo, el autor

deberá presentar las siguientes informaciones:
I. Título del programa para computadora.
II. Nombre civil, fecha de nacimiento, nacionalidad y domicilio del autor.
III. Fecha de terminación del programa para computadora.
IV. Indicación de la fecha y lugar del lanzamiento del programa.
V. En el caso de un software resultante de modificaciones tecnológicas y

derivaciones, indicación del programa que modifica o del que deriva,
acompañando en este caso, el documento de autorización.
VI. Indicación de que el programa fue desarrollado por un particular, empleado,

funcionario o prestador de servicios.
VII. Indicación de los lenguajes de programación utilizados en el desarrollo del

programa de cómputo.

Además, en cualquier caso de solicitud de registro de programa para

computadora, el requirente deberá presentar los elementos esenciales para
caracterizar la creación independiente e identificar el programa, de manera que
permita la lectura directamente por el hombre.
Artículo 15.- No estarán sujetos a inscripción, aquellos programas de cómputo:
I. Importados por el usuario final para su uso exclusivo, en la forma de copia única.
II. Importados por el usuario final para su uso exclusivo, en asociación a

máquinas, equipos y dispositivos basados en técnica digital.
III. Residentes e integrados en máquinas, equipos y dispositivos basados en

técnica digital, siempre que esos programas no sean comercializados de manera
separada de los productos que los contengan.
Artículo 16.-Los programas de cómputo podrán ser inscritos de manera colectiva

cuando constituyan un conjunto de programas destinados a una aplicación
específica, recibiendo en este caso, un único número de orden en el Registro
Público del Derecho de Autor.
Artículo 17.-La versión de un programa ya registrado deberá ser también

inscrita cuando presente características funcionales y condiciones de
comercialización diferentes de la versión anterior.
Artículo 18.-La Dirección General del Derecho de Autor permitirá el acceso a las
informaciones de interés público que consten en el Registro de programas para
computadora; siendo dichas informaciones las que a continuación se enumeran:
a) Nombre del programa de cómputo.

b) Descripción funcional de dicho programa.
c) Nombre y domicilio del titular de la comercialización en el país.
d) Clasificaciones dentro de las que podría encuadrarse.
e) Categoría, número de orden de registro y su validez.
f) Ambiente de procesamiento
g) Plazo de validez técnica establecido por el titular de los derechos de
comercialización en el país.
Artículo 19.-Cuando la transferencia de tecnología haya sido resuelta de

común acuerdo entre las partes, se hará necesario registrar los respectivos
actos y contratos en el Instituto Mexicano de Propiedad Industrial (IMPI). En los

casos de programas de cómputo destinados a la aplicación en áreas de

relevante interés estratégico o económico, la Dirección General del Derecho de
Autor podrá condicionar el registro de los actos o contratos a la transferencia de la
tecnología correspondiente.
Artículo 20.-Con el objeto de la creación y posterior financiamiento del Fondo

Nacional de Informática (FNI), el 8% (ocho por ciento) de las erogaciones por
costo de inscripción de programas de cómputo en el Registro Público del Derecho
de Autor serán destinadas a dicho Fondo.
Capítulo III
DEL FONDO NACIONAL DE INFORMÁTICA
Artículo 21.-El Fondo Nacional de Informática (FNI) será destinado a la

financiación de programas de:
a) Investigación y desarrollo de tecnología de informática.

b) Formación de recursos humanos en el área de informática.
c) Equipamiento de Centros de Investigación en Informática.
d) Transferencia y difusión de los hallazgos a la planta productiva, al sistema
educativo y a la sociedad en general.
Artículo 22.- El Fondo Nacional de Informática estará constituido por:
a) Asignaciones del presupuesto.

b) El 8% de los emolumentos por costo de inscripción de software en el
Registro Nacional de Programas de Cómputo.
c) Cuotas de contribución y derechos.
d) Donaciones de origen interno o externo.
Artículo 23.-De manera paralela a este Fondo Nacional de Informática, y como

forma de incentivo, los organismos y entidades de la Administración Pública
Directa o Indirecta, Fundaciones instituidas o mantenidas por el Poder Público y
las demás entidades bajo control directo o indirecto del Poder Público, darán
preferencia, en igualdad de condiciones, al uso de programas para computadora
desarrollados en el país por empresas públicas o privadas nacionales.

Capítulo IV
DE LA COMERCIALIZACIÓN DEL SOFTWARE
Artículo 24.- El titular de los derechos de programas de computación y de su

comercialización es responsable ante el usuario por la calidad técnica adecuada,
así como por la calidad de fijación o grabación de los mismos en los respectivos
soportes físicos, cabiendo la acción regresiva contra eventuales titulares
anteriores de esos mismos derechos.
Artículo 25.- Los soportes físicos de los programas de cómputo y sus

embalajes respectivos, así como los contratos referidos, deberán consignar de
manera fácilmente legible por el usuario, el número de orden de registro y el
plazo de validez técnica de la versión comercializada.
Artículo 26.-Durante el plazo de validez técnica de la versión respectiva, el titular

de los derechos de comercialización queda obligado a:
I. Divulgar, sin carga adicional, las correcciones de errores eventuales.
II. Asegurar a los respectivos usuarios la prestación de servicios técnicos

complementarios relativos al funcionamiento adecuado del programa de cómputo,
considerando sus especificaciones y las particulares del usuario.
III. No retirar dicho programa de la circulación comercial sin indemnizar los

perjuicios eventuales causados a terceros, y previa comunicación de dicha salida
a la Dirección General del Derecho de Autor.
Artículo 27.-Cuando un programa para computadora presente una relación de

dependencia funcional con otro programa, será necesario caracterizar claramente
ante el usuario las responsabilidades individuales de los respectivos productores o
titulares de los derechos de comercialización en lo referente al funcionamiento
conjunto adecuado de los programas.
Artículo 28.- La explotación económica de los programas de cómputo en el país,

será objeto de contratos de licencia o cesión efectuados libremente entre las
partes, y en los que se fijará la responsabilidad por los pagos respectivos en lo
referente a materia fiscal y tasas exigibles en el país. En relación a lo anterior,
además, se anularán las cláusulas que:

a) Fijen exclusividad.
b) Limiten la producción, distribución y comercialización.
c) Eximan a cualquiera de los contratantes de responsabilidad por eventuales
acciones de terceros en virtud de vicios, defectos o violación de derechos
de autor.
Artículo 29.-Como excepción a lo previsto en el artículo anterior, el titular de los

derechos de autor sobre un programa de cómputo conservará, aún después de la
venta de ejemplares de los mismos, el derecho de autorizar o prohibir el
arrendamiento de dichos ejemplares. Este precepto no se aplicará cuando el
ejemplar del programa de computación no constituya en sí mismo un objeto
esencial de la licencia de uso.
Artículo 30.- Queda prohibida la importación, fabricación, distribución y utilización

de aparatos o la prestación de servicios destinados a eliminar la protección técnica
de los programas de cómputo, de las transmisiones a través del espectro
electromagnético y de redes de telecomunicaciones y de los programas de
elementos electrónicos, ya sean estos visuales, sonoros, tridimensionales o
animados.
Artículo 31.-Los programas, sus interpretaciones o ejecuciones transmitidos por

medios electrónicos a través del espectro electromagnético y de redes de
telecomunicaciones, así como el resultado que se obtenga de dicha transmisión
deberán adecuarse a lo establecido por la legislación mexicana.
Artículo 32.-El derecho patrimonial sobre un programa de computación

comprende la facultad de autorizar o prohibir:
I. La traducción, la adaptación, el arreglo o cualquier otra modificación de un

programa y la reproducción del programa resultante.
II. La reproducción permanente o provisional del programa en todo o en parte, por

cualquier medio y forma.
III. Cualquier forma de distribución del programa o de una copia del mismo,
incluido el alquiler, y
IV. La descompilación, los procesos para revertir la ingeniería de un programa de

computación y el desensamblaje.

Artículo 33.-La obtención de copias de un programa de computación por

parte del Registro Público del Derecho de Autor, sólo se permitirá mediante
autorización del titular del derecho patrimonial o por mandamiento judicial.
Capítulo V
DE LA COMPETENCIA
Artículo 34.- Para los fines previstos en esta Ley, corresponde:
I. A la Dirección General del Derecho de Autor decidir la forma del Reglamento

Interno del Fondo Nacional de Informática y del Reglamento Interno del Registro
Nacional de Programas de Cómputo.
II. A la Secretaría de Educación Pública:
a) Establecer normas a ser publicadas en el Diario Oficial de la Federación,

que reglamenten los procedimientos referentes al registro de programas de
cómputo.
b) Decidir sobre los recursos relativos al registro de programas de
computación.
III. A la unidad administrativa correspondiente de la Secretaría de Educación

Pública, resolver los recursos administrativos de reconsideración interpuestos ante
las decisiones tomadas por la Dirección General de Derechos de Autor, o
dependencias derivadas de ésta.
IV. A la Dirección General del Derecho de Autor, por conducto del Registro
Nacional de Programas de Cómputo:
a) Analizar, clasificar y decidir favorablemente sobre la inscripción de

programas para computadora.
b) Analizar y aprobar actos y contratos relativos a la comercialización de
programas de cómputo desarrollados tanto por empresas nacionales como no
nacionales.
c) Analizar y aprobar proyectos de diseño y desarrollo de programas para
computadora.
d) Expresar su opinión, previamente, sobre cualquier importación de
programas para computadora.

V. Al Instituto Mexicano de Propiedad Industrial, analizar y registrar

contratos de transferencia de tecnología de programas para computadora.
Capítulo VI
DE LAS PRESCRIPCIONES
Artículo 35.-La responsabilidad civil derivada de la violación a los derechos

autorales de un programa de cómputo prescribe en 5 (cinco) años.
Artículo 36.-Prescriben también en 5 (cinco) años las acciones fundamentadas en

la falta de pago de las obligaciones respectivas, contando el plazo de la fecha:
a) Que constituye el plazo final de validez técnica de la versión

comercializada.
b) De la licencia de uso de programas de cómputo.
c) De la terminación de la garantía, en el caso de software desarrollado y
elaborado por pedido.
Capítulo VII
DE LAS SANCIONES
Artículo 37.-Se impondrá prisión de seis meses a seis años y multa por el
equivalente de cincuenta a quinientos días de salario mínimo, en los siguientes
casos:
I. Al que sin consentimiento del titular del derecho de autor, explote con fines de
lucro un programa de cómputo registrado.
II. A la persona que reproduzca, sin consentimiento del autor o sus

causahabientes, un número mayor de los ejemplares autorizados o de los
estipulados en el contrato.
III. Al que sin autorización de la Federación, los Estados o los Municipios,

comercialice el software destinado para su servicio oficial.
Artículo 38.- Se impondrá prisión de ocho meses a cuatro años al que importe,
mantenga en depósito o exponga, para fines de comercialización, programas de
cómputo de origen externo no registrados. Lo dispuesto en el párrafo anterior, no
se aplica a los programas destinados exclusivamente a la demostración o

apreciación de mercado en ferias o congresos de naturaleza técnica,

científica o industrial.
Artículo 39.- Se impondrá prisión de uno a cinco años y multa por el equivalente
de ochenta a seiscientos días de salario mínimo, en los casos siguientes:
I. Al que modifique o altere sin autorización del creador, un programa de cómputo

registrado.
II. Al que publique compendios, adaptaciones, traducciones o modificaciones de

programas de cómputo, sin la autorización del titular del derecho de autor sobre el
programa original.
III. Al que dolosamente emplee el título de un programa que induzca a confusión

con otro publicado con anterioridad.
IV. Al que comercialice con el software de distribución gratuita, sin autorización de

su titular, además de que en este caso en específico, se deberá reembolsar las
regalías obtenidas por dicho comercializador.
Artículo 40.- Se impondrá prisión de treinta días a un año o multa por el

equivalente de cincuenta a trescientos días de salario mínimo, o ambas sanciones
a juicio del juez, a quienes estando autorizados para comercializar un programa de
cómputo, no consignen de manera legible la orden de registro y el plazo de validez
técnica de la versión comercializada del software en los soportes físicos y sus
respectivos embalajes, así como en los contratos.
TRANSITORIOS
PRIMERO.- El presente Decreto entrará en vigor a partir del día siguiente de su

publicación en el Diario Oficial de la Federación.
SEGUNDO.- Quedan revocadas las disposiciones en contrario existentes dentro

de la legislación mexicana.
TERCERO.- Se concede a los titulares de programas de cómputo que estén

siendo comercializados en el país, un plazo de 180 (ciento ochenta) días a partir
de la entrada en vigor de la presente ley, para inscribirlos en el Registro Nacional
de Programas de Cómputo.

CUARTO.- La Dirección General del Derecho de Autor contará con un

plazo de 30 (treinta) días para establecer los procedimientos operacionales
previstos en la presente ley.
8.1.3. DERECHOS QUE SE CONFIEREN A TRAVES DE LA L.F.D.A (LEY

FEDERAL DE DERECHOS DE AUTOR)
Titulo I
Capítulo Único
Artículo 1º.-La presente Ley, reglamentaria del artículo 28 constitucional, tiene por
objeto la salvaguarda y promoción del acervo cultural de la Nación; protección de
los derechos de los autores, de los artistas intérpretes o ejecutantes, así como de
los editores, de los productores y de los organismos de radiodifusión, en relación
con sus obras literarias o artísticas en todas sus manifestaciones, sus
interpretaciones o ejecuciones, sus ediciones, sus fonogramas o videogramas, sus
emisiones, así como de los otros derechos de propiedad intelectual.
Artículo 2º.-Las disposiciones de esta Ley son de orden público, de interés social
y de observancia general en todo el territorio nacional. Su aplicación administrativa
corresponde al Ejecutivo Federal por conducto del Instituto Nacional del Derecho
de Autor y, en los casos previstos por esta Ley, del Instituto Mexicano de la
Propiedad Industrial.
Para los efectos de esta Ley se entenderá por Instituto, al Instituto Nacional del
Derecho de Autor.
Artículo 3º.-Las obras protegidas por esta Ley son aquellas de creación original
susceptibles de ser divulgadas o reproducidas en cualquier forma o medio.
Artículo 4º.-Las obras objeto de protección pueden ser:
A. Según su autor:
I. Conocido: Contienen la mención del nombre, signo o firma con que se identifica
a su autor.
II. Anónimas: Sin mención del nombre, signo o firma que identifica al autor, bien
por voluntad del mismo, bien por no ser posible tal identificación.

III. Seudónimas: Las divulgadas con un nombre, signo o firma que no revele la
identidad del autor;
B. Según su comunicación:
I. Divulgadas: Las que han sido hechas del conocimiento público por primera vez
en cualquier forma o medio, bien en su totalidad, bien en parte, bien en lo esencial
de su contenido o, incluso, mediante una descripción de la misma;
II. Inéditas: Las no divulgadas, y
III. Publicadas:
a) Las que han sido editadas, cualquiera que sea el modo de reproducción de
los ejemplares, siempre que la cantidad de éstos, puestos a disposición del
público, satisfaga razonablemente las necesidades de su explotación, estimadas
de acuerdo con la naturaleza de la obra.
b) Las que han sido puestas a disposición del público mediante su
almacenamiento por medios electrónicos que permitan al público obtener
ejemplares tangibles de la misma, cualquiera que sea la índole de estos
ejemplares.
C. Según su origen:
I. Primigenias: Las que han sido creadas de origen sin estar basadas en otra
preexistente, o que estando basadas en otra, sus características permitan afirmar
su originalidad.
II. Derivadas: Aquellas que resulten de la adaptación, traducción u otra

transformación de una obra primigenia.
D. Según los creadores que intervienen:
I. Individuales: Las que han sido creadas por una sola persona.
II. De colaboración: Las que han sido creadas por varios autores.
III. Colectivas: Las creadas por la iniciativa de una persona física o moral que las
publica y divulga bajo su dirección y su nombre y en las cuales la contribución
personal de los diversos autores que han participado en su elaboración se funde

en el conjunto con vistas al cual ha sido concebida, sin que sea posible
atribuir a cada uno de ellos un derecho distinto e indiviso sobre el conjunto
realizado.
Artículo 5º.-La protección que otorga esta Ley se concede a las obras desde el
momento en que hayan sido fijadas en un soporte material, independientemente
del mérito, destino o modo de expresión. El reconocimiento de los derechos de
autor y de los derechos conexos no requiere registro ni documento de ninguna
especie ni quedará subordinado al cumplimiento de formalidad alguna.
Artículo 6º.-Fijación es la incorporación de letras, números, signos, sonidos,

imágenes y demás elementos en que se haya expresado la obra, o de las
representaciones digitales de aquellos, que en cualquier forma o soporte material,
incluyendo los electrónicos, permita su percepción, reproducción u otra forma de
comunicación.
Artículo 7º.-Los extranjeros autores o titulares de derechos y sus causahabientes

gozarán de los mismos derechos que los nacionales, en los términos de la
presente Ley y de los tratados internacionales en materia de derechos de autor y
derechos conexos suscritos y aprobados por México.
Artículo 8º.-Los artistas intérpretes o ejecutantes, los editores, los productores de

fonogramas o videogramas y los organismos de radiodifusión que hayan realizado
fuera del territorio nacional, respectivamente, la primera fijación de sus
interpretaciones o ejecuciones, sus ediciones, la primera fijación de los sonidos de
estas ejecuciones o de las imágenes de sus videogramas o la comunicación de
sus emisiones, gozarán de la protección que otorgan la presente Ley y los tratados
internacionales en materia de derechos de autor y derechos conexos suscritos y
aprobados por México.
Artículo 9º.-Todos los plazos establecidos para determinar la protección que

otorga la presente Ley se computarán a partir del 1º de enero del año siguiente al
respectivo en que se hubiera realizado el hecho utilizado para iniciar el cómputo,
salvo que este propio ordenamiento establezca una disposición en contrario.
Artículo 10.-En lo no previsto en la presente Ley, se aplicará la legislación

mercantil, el Código Civil para el Distrito Federal en Materia Común y para toda la
República en Materia Federal y la Ley Federal del Procedimiento Administrativo.
Titulo II

DEL DERECHO DE AUTOR
Capítulo I
Reglas Generales
Artículo 11.-El derecho de autor es el reconocimiento que hace el Estado en favor

de todo creador de obras literarias y artísticas previstas en el artículo 13 de esta
Ley, en virtud del cual otorga su protección para que el autor goce de
prerrogativas y privilegios exclusivos de carácter personal y patrimonial. Los
primeros integran el llamado derecho moral y los segundos, el patrimonial.
Artículo 12.-Autor es la persona física que ha creado una obra literaria y artística.
Artículo 13.-Los derechos de autor a que se refiere esta Ley se reconocen

respecto de las obras de las siguientes ramas:
I. Literaria.
II. Musical, con o sin letra.
III. Dramática.
IV. Danza.
V. Pictórica o de dibujo
VI. Escultórica y de carácter plástico.
VII. Caricatura e historieta.
VIII. Arquitectónica.
IX. Cinematográfica y demás obras audiovisuales.
X. Programas de radio y televisión.
XI. Programas de cómputo.
XII. Fotográfica.
XIII. Obras de arte aplicado que incluyen el diseño gráfico o textil.
XIV. De compilación, integrada por las colecciones de obras, tales como las
enciclopedias, las antologías, y de obras u otros elementos como las bases
de datos, siempre que dichas colecciones, por su selección o la disposición
de su contenido o materias, constituyan una creación intelectual.
Las demás obras que por analogía puedan considerarse obras literarias o
artísticas se incluirán en la rama que les sea más afín a su naturaleza.
Artículo 14.-No son objeto de la protección como derecho de autor a que se

refiere esta Ley:

I. Las ideas en sí mismas, las fórmulas, soluciones, conceptos,

métodos, sistemas, principios, descubrimientos, procesos e invenciones de
cualquier tipo.
II. El aprovechamiento industrial o comercial de las ideas contenidas en las

obras.
III. Los esquemas, planes o reglas para realizar actos mentales, juegos o
negocios.
IV. Las letras, los dígitos o los colores aislados, a menos que su estilización
sea tal que las conviertan en dibujos originales.
V. Los nombres y títulos o frases aislados.
VI. Los simples formatos o formularios en blanco para ser llenados con
cualquier tipo de información, así como sus instructivos.
VII. Las reproducciones o imitaciones, sin autorización, de escudos, banderas o

emblemas de cualquier país, estado, municipio o división política equivalente, ni
las denominaciones, siglas, símbolos o emblemas de organizaciones
internacionales gubernamentales, no gubernamentales, de cualquier otra
organización reconocida oficialmente, así como la designación verbal de los
mismos.
VIII. Los textos legislativos, reglamentarios, administrativos o judiciales, así

como sus traducciones oficiales. En caso de ser publicados, deberán apegarse al
texto oficial y no conferirán derecho exclusivo de edición. Sin embargo, serán
objeto de protección las concordancias, interpretaciones, estudios comparativos,
anotaciones, comentarios y demás trabajos similares que entrañen, por parte de
su autor, la creación de una obra original.
IX. El contenido informativo de las noticias, pero sí su forma de expresión.
X. La información de uso común tal como los refranes, dichos, leyendas,

hechos, calendarios y las escalas métricas.
Artículo 15.-Las obras literarias y artísticas publicadas en periódicos o revistas o

transmitidas por radio, televisión u otros medios de difusión no pierden por ese
hecho la protección legal.

Artículo 16.-La obra podrá hacerse del conocimiento público mediante los
actos que se describen a continuación:
I. Divulgación: El acto de hacer accesible una obra literaria y artística por

cualquier medio al público, por primera vez, con lo cual deja de ser inédita.
II. Publicación: La reproducción de la obra en forma tangible y su puesta a

disposición del público mediante ejemplares, o su almacenamiento permanente o
provisional por medios electrónicos, que permitan al público leerla o conocerla
visual, táctil o auditivamente.
III. Comunicación pública: Acto mediante el cual la obra se pone al alcance

general, por cualquier medio o procedimiento que la difunda y que no consista en
la distribución de ejemplares.
IV. Ejecución o representación pública: Presentación de una obra, por cualquier

medio, a oyentes o espectadores sin restringirla a un grupo privado o círculo
familiar. No se considera pública la ejecución o representación que se hace de la
obra dentro del círculo de una escuela o una institución de asistencia pública o
privada, siempre y cuando no se realice con fines de lucro.
V. Distribución al público: Puesta a disposición del público del original o copia

de la obra mediante venta, arrendamiento y, en general, cualquier otra forma.
VI. Reproducción: La realización de uno o varios ejemplares de una obra, de un

fonograma o de un videograma, en cualquier forma tangible, incluyendo cualquier
almacenamiento permanente o temporal por medios electrónicos, aunque se trate
de la realización bidimensional de una obra tridimensional o viceversa.
Artículo 17.-Las obras protegidas por esta Ley que se publiquen, deberán ostentar
la expresión ―Derechos Reservados‖, o su abreviatura ―D. R.‖, seguida del símbolo
©; el nombre completo y dirección del titular del derecho de autor y el año de la
primera publicación. Estas menciones deberán aparecer en sitio visible. La
omisión de estos requisitos no implica la pérdida de los derechos de autor, pero
sujeta al licenciatario o editor responsable a las sanciones establecidas en la Ley.

Capítulo II
DE LOS DERECHOS MORALES
Artículo 18.-El autor es el único, primigenio y perpetuo titular de los derechos

morales sobre las obras de su creación.
Artículo 19.-El derecho moral se considera unido al autor y es inalienable,

imprescriptible, irrenunciable e inembargable.
Artículo 20.-Corresponde el ejercicio del derecho moral, al propio creador de la

obra y a sus herederos. En ausencia de éstos, o bien en caso de obras del
dominio público, anónimas o de las protegidas por el Título VII de la presente Ley,
el Estado los ejercerá conforme al artículo siguiente, siempre y cuando se trate de
obras de interés para el patrimonio cultural nacional.
Artículo 21.-Los titulares de los derechos morales podrán en todo tiempo:
I. Determinar si su obra ha de ser divulgada y en qué forma, o la de

mantenerla inédita.
II. Exigir el reconocimiento de su calidad de autor respecto de la obra por él

creada y la de disponer que su divulgación se efectúe como obra anónima o
seudónima.
III. Exigir respeto a la obra, oponiéndose a cualquier deformación, mutilación u

otra modificación de ella, así como a toda acción o atentado a la misma que cause
demérito de ella o perjuicio a la reputación de su autor.
IV. Modificar su obra.
V. Retirar su obra del comercio.
VI. Oponerse a que se le atribuya al autor una obra que no es de su creación.

Cualquier persona a quien se pretenda atribuir una obra que no sea de su
creación podrá ejercer la facultad a que se refiere esta fracción. Los herederos
sólo podrán ejercer las facultades establecidas en las fracciones I, II, III y VI del
presente artículo y el Estado, en su caso, sólo podrá hacerlo respecto de las
establecidas en las fracciones III y VI del presente artículo.

Artículo 22.-Salvo pacto en contrario entre los coautores, el director o

realizador de la obra, tiene el ejercicio de los derechos morales sobre la obra
audiovisual en su conjunto, sin perjuicio de los que correspondan a los demás
coautores en relación con sus respectivas contribuciones, ni de los que puede
ejercer el productor de conformidad con la presente Ley y de lo establecido por su
artículo 99.
Artículo 23.-Salvo pacto en contrario, se entiende que los autores que aporten
obras para su utilización en anuncios publicitarios o de propaganda, han
autorizado la omisión del crédito autoral durante la utilización o explotación de las
mismas, sin que esto implique renuncia a los derechos morales.
Capítulo III
DE LOS DERECHOS PATRIMONIALES
Artículo 24.- En virtud del derecho patrimonial, corresponde al autor el derecho de

explotar de manera exclusiva sus obras, o de autorizar a otros su explotación, en
cualquier forma, dentro de los límites que establece la presente Ley y sin
menoscabo de la titularidad de los derechos morales a que se refiere el artículo 21
de la misma.
Artículo 25.-Es titular del derecho patrimonial el autor, heredero o el adquirente

por cualquier título.
Artículo 26.-El autor es el titular originario del derecho patrimonial y sus herederos
o causahabientes por cualquier título serán considerados titulares derivados.
Artículo 26 bis.-El autor y su causahabiente gozarán del derecho a percibir una

regalía por la comunicación o transmisión pública de su obra por cualquier medio.
El derecho del autor es irrenunciable. Esta regalía será pagada

directamente por quien realice la comunicación o transmisión pública de las obras
directamente al autor, o a la sociedad de gestión colectiva que los represente, con
sujeción a lo previsto por los Artículos 200 y 202 Fracciones V y VI de la Ley. El
importe de las regalías deberá convenirse directamente entre el autor, o en su
caso, la Sociedad de Gestión Colectiva que corresponda y las personas que
realicen la comunicación o transmisión pública de las obras en términos del
Artículo 27 Fracciones II y III de esta Ley. A falta de convenio el Instituto deberá
establecer una tarifa conforme al procedimiento previsto en el Artículo 212 de esta
Ley.

Artículo 27.-Los titulares de los derechos patrimoniales podrán autorizar o

prohibir:
I. La reproducción, publicación, edición o fijación material de una obra en

copias o ejemplares, efectuada por cualquier medio ya sea impreso, fonográfico,
gráfico, plástico, audiovisual, electrónico, fotográfico u otro similar.
II. La comunicación pública de su obra a través de cualquiera de las siguientes

maneras:
a) La representación, recitación y ejecución pública en el caso de las obras

literarias y artísticas.
b) La exhibición pública por cualquier medio o procedimiento, en el caso de
obras literarias y artísticas.
c) El acceso público por medio de la telecomunicación.
III. La transmisión pública o radiodifusión de sus obras, en cualquier modalidad,

incluyendo la transmisión o retransmisión de las obras por:
a) Cable.
b) Fibra óptica.
c) Microondas.
d) Vía satélite.
e) Cualquier otro medio conocido o por conocerse.
IV. La distribución de la obra, incluyendo la venta u otras formas de transmisión de

la propiedad de los soportes materiales que la contengan, así como cualquier
forma de transmisión de uso o explotación. Cuando la distribución se lleve a cabo
mediante venta, este derecho de oposición se entenderá agotado efectuada la
primera venta, salvo en el caso expresamente contemplado en el artículo 104 de
esta Ley.
V. La importación al territorio nacional de copias de la obra hechas sin su

autorización.
VII. La divulgación de obras derivadas, en cualquiera de sus modalidades, tales

como la traducción, adaptación, paráfrasis, arreglos y transformaciones.
VIII. Cualquier utilización pública de la obra salvo en los casos expresamente

establecidos en esta Ley.

Artículo 28.-Las facultades a las que se refiere el artículo anterior, son

independientes entre sí y cada una de las modalidades de explotación también lo
son.
Artículo 29.-Los derechos patrimoniales estarán vigentes durante:
I. La vida del autor y, a partir de su muerte, cien años más. Cuando la obra le
pertenezca a varios coautores los cien años se contarán a partir de la muerte del
último.
II. Cien años después de divulgadas. Si el titular del derecho patrimonial

distinto del autor muere sin herederos la facultad de explotar o autorizar la
explotación de la obra corresponderá al autor y, a falta de éste, corresponderá al
Estado por conducto del Instituto, quien respetará los derechos adquiridos por
terceros con anterioridad.
Pasados los términos previstos en las fracciones de este artículo, la obra pasará al
dominio público.
Titulo III
DE LA TRANSMISIÓN DE LOS DERECHOS PATRIMONIALES
Capítulo I
Disposiciones Generales
Artículo 30.- El titular de los derechos patrimoniales puede, libremente, conforme

a lo establecido por esta Ley, transferir sus derechos patrimoniales u otorgar
licencias de uso exclusivas o no exclusivas. Toda transmisión de derechos
patrimoniales de autor será onerosa y temporal. En ausencia de acuerdo sobre el
monto de la remuneración o del procedimiento para fijarla, así como sobre los
términos para su pago, la determinarán los tribunales competentes.
Los actos, convenios y contratos por los cuales se transmitan derechos

patrimoniales y las licencias de uso deberán celebrarse, invariablemente, por
escrito, de lo contrario serán nulos de pleno derecho.
Artículo 31.-Toda transmisión de derechos patrimoniales deberá prever en favor

del autor o del titular del derecho patrimonial, en su caso, una participación

proporcional en los ingresos de la explotación de que se trate, o una

remuneración fija y determinada. Este derecho es irrenunciable.
Artículo 32.-Los actos, convenios y contratos por los cuales se transmitan

derechos patrimoniales deberán inscribirse en el Registro Público del Derecho de
Autor para que surtan efectos contra terceros.
Artículo 33.- A falta de estipulación expresa, toda transmisión de derechos

patrimoniales se considera por el término de 5 años. Solo podrá pactarse
excepcionalmente por más de 15 años cuando la naturaleza de la obra o la
magnitud de la inversión requerida así lo justifiquen.
Artículo 34.-La producción de obra futura sólo podrá ser objeto de contrato
cuando se trate de obra determinada cuyas características deben quedar
establecidas en él. Son nulas la transmisión global de obra futura, así como las
estipulaciones por las que el autor se comprometa a no crear obra alguna.
Artículo 35.-La licencia en exclusiva deberá otorgarse expresamente con tal

carácter y atribuirá al licenciatario, salvo pacto en contrario, la facultad de explotar
la obra con exclusión de cualquier otra persona y la de otorgar autorizaciones no
exclusivas a terceros.
Artículo 36.-La licencia en exclusiva obliga al licenciatario a poner todos los

medios necesarios para la efectividad de la explotación concedida, según la
naturaleza de la obra y los usos y costumbres en la actividad profesional, industrial
o comercial de que se trate.
Artículo 37.-Los actos, convenios y contratos sobre derechos patrimoniales que

se formalicen ante notario, corredor público o cualquier fedatario público y que se
encuentren inscritos en el Registro Público del Derecho de Autor, traerán
aparejada ejecución.
Artículo 38.-El derecho de autor no está ligado a la propiedad del objeto material
en el que la obra esté incorporada. Salvo pacto expreso en contrario, la
enajenación por el autor o su derechohabiente del soporte material que contenga
una obra, no transferirá al adquirente ninguno de los derechos patrimoniales sobre
tal obra.
Artículo 39.-La autorización para difundir una obra protegida, por radio, televisión
o cualquier otro medio semejante, no comprende la de redifundirla ni explotarla.

Artículo 40.-Los titulares de los derechos patrimoniales de autor y de los derechos

conexos podrán exigir una remuneración compensatoria por la realización de
cualquier copia o reproducción hecha sin su autorización y sin estar amparada por
alguna de las limitaciones previstas en los artículos 148 y 151 de la presente Ley.
Artículo 41.-Los derechos patrimoniales no son embargables ni pignorables

aunque pueden ser objeto de embargo o prenda los frutos y productos que se
deriven de su ejercicio.
Capítulo II
DEL CONTRATO DE EDICIÓN DE OBRA LITERARIA
Artículo 42.-Hay contrato de edición de obra literaria cuando el autor o el titular de

los derechos patrimoniales, en su caso, se obliga a entregar una obra a un editor y
éste, a su vez, se obliga a reproducirla, distribuirla y venderla cubriendo al titular
del derecho patrimonial las prestaciones convenidas.
Las partes podrán pactar que la distribución y venta sean realizadas por terceros,
así como convenir sobre el contenido del contrato de edición, salvo los derechos
irrenunciables establecidos por esta Ley.
Artículo 43.-Como excepción a lo previsto por el artículo 33 de la presente Ley, el

plazo de la cesión de derechos de obra literaria no estará sujeta a limitación
alguna.
Artículo 44.-El contrato de edición de una obra no implica la transmisión de los

demás derechos patrimoniales del titular de la misma.
Artículo 45.-El editor no podrá publicar la obra con abreviaturas, adiciones,

supresiones o cualesquiera otras modificaciones, sin consentimiento escrito del
autor.
Artículo 46.-El autor conservará el derecho de hacer a su obra las correcciones,

enmiendas, adiciones o mejoras que estime convenientes antes de que la obra
entre en prensa.
Cuando las modificaciones hagan más onerosa la edición, el autor estará obligado
a resarcir los gastos que por ese motivo se originen, salvo pacto en contrario.

Artículo 47.-El contrato de edición deberá contener como mínimo los

siguientes elementos:
I. El número de ediciones o, en su caso, reimpresiones, que comprende.
II. La cantidad de ejemplares de que conste cada edición.
III. Si la entrega del material es o no en exclusiva.
IV. La remuneración que deba percibir el autor o el titular de los derechos

patrimoniales.
Artículo 48.-Salvo pacto en contrario, los gastos de edición, distribución,

promoción, publicidad, propaganda o de cualquier otro concepto, serán por cuenta
del editor.
Artículo 49.-El editor que hubiere hecho la edición de una obra tendrá el derecho
de preferencia en igualdad de condiciones para realizar la siguiente edición.
Artículo 50.-Si no existe convenio respecto al precio que los ejemplares deben
tener para su venta, el editor estará facultado para fijarlo.
Artículo 51.-Salvo pacto en contrario, el derecho de editar separadamente una o

varias obras del mismo autor no confiere al editor el derecho para editarlas en
conjunto. El derecho de editar en conjunto las obras de un autor no confiere al
editor la facultad de editarlas separadamente.
Artículo 52.-Son obligaciones del autor o del titular del derecho patrimonial:
I. Entregar al editor la obra en los términos y condiciones contenidos en el

contrato.
II. Responder ante el editor de la autoría y originalidad de la obra, así como

del ejercicio pacífico de los derechos que le hubiera transmitido.
Artículo 53.-Los editores deben hacer constar en forma y lugar visibles de las
obras que publiquen, los siguientes datos:
I. Nombre, denominación o razón social y domicilio del editor.
II. Año de la edición o reimpresión.

III. Número ordinal que corresponde a la edición o reimpresión, cuando esto

sea posible.
IV. Número Internacional Normalizado del Libro (ISBN), o el Número

Internacional Normalizado para Publicaciones Periódicas (ISSN), en caso de
publicaciones periódicas.
Artículo 54.-Los impresores deben hacer constar en forma y lugar visible de las
obras que impriman:
I. Su nombre, denominación o razón social.
II. Su domicilio.
III. La fecha en que se terminó de imprimir.
Artículo 55.-Cuando en el contrato de edición no se haya estipulado el término

dentro del cual deba quedar concluida la edición y ser puestos a la venta los
ejemplares, se entenderá que este término es de un año contado a partir de la
entrega de la obra lista para su edición. Una vez transcurrido este lapso sin que el
editor haya hecho la edición, el titular de los derechos patrimoniales podrá optar
entre exigir el cumplimiento del contrato o darlo por terminado mediante aviso
escrito al editor. En uno y otros casos, el editor resarcirá al titular de los derechos
patrimoniales los daños y perjuicios causados.
El término para poner a la venta los ejemplares no podrá exceder de dos años,
contado a partir del momento en que se pone la obra a disposición del editor.
Artículo 56.-El contrato de edición terminará, cualquiera que sea el plazo

estipulado para su duración, si la edición objeto del mismo se agotase, sin
perjuicio de las acciones derivadas del propio contrato, o si el editor no
distribuyese la obra en los términos pactados. Se entenderá agotada una edición,
cuando el editor carezca de los ejemplares de la misma para atender la demanda
del público.
Artículo 57.-Toda persona física o moral que publique una obra está obligada a
mencionar el nombre del autor o el seudónimo en su caso. Si la obra fuere
anónima se hará constar. Cuando se trate de traducciones, compilaciones,
adaptaciones u otras versiones se hará constar además, el nombre de quien la
realiza.

Capítulo III
DEL CONTRATO DE EDICIÓN DE OBRA MUSICAL
Artículo 58.-El contrato de edición de obra musical es aquél por el que el autor o
el titular del derecho patrimonial, en su caso, cede al editor el derecho de
reproducción y lo faculta para realizar la fijación y reproducción fonomecánica de
la obra, su sincronización audiovisual, comunicación pública, traducción, arreglo o
adaptación y cualquier otra forma de explotación que se encuentre prevista en el
contrato; y el editor se obliga por su parte, a divulgar la obra por todos los medios
a su alcance, recibiendo como contraprestación una participación en los beneficios
económicos que se obtengan por la explotación de la obra, según los términos
pactados.
Sin embargo, para poder realizar la sincronización audiovisual, la adaptación con

fines publicitarios, la traducción, arreglo o adaptación el editor deberá contar, en
cada caso específico, con la autorización expresa del autor o de sus
causahabientes.
Artículo 59.-Son causas de rescisión, sin responsabilidad para el autor o el titular

del derecho patrimonial:
I. Que el editor no haya iniciado la divulgación de la obra dentro del término
señalado en el contrato.
II. Que el editor incumpla su obligación de difundir la obra en cualquier tiempo

sin causa justificada.
III. Que la obra materia del contrato no haya producido beneficios económicos
a las partes en el término de tres años, caso en el que tampoco habrá
responsabilidad para el editor.
Artículo 60.-Son aplicables al contrato de edición musical las disposiciones del

contrato de edición de obra literaria en todo aquello que no se oponga a lo
dispuesto en el presente capítulo.
Capítulo IV
DEL CONTRATO DE REPRESENTACIÓN ESCÉNICA

Artículo 61.-Por medio del contrato de representación escénica el autor o el

titular del derecho patrimonial, en su caso, concede a una persona física o moral,
llamada empresario, el derecho de representar o ejecutar públicamente una obra
literaria, musical, literario musical, dramática, dramático musical, de danza,
pantomímica o coreográfica, por una contraprestación pecuniaria; y el empresario
se obliga a llevar a efecto esa representación en las condiciones convenidas y con
arreglo a lo dispuesto en esta Ley.
El contrato deberá especificar si el derecho se concede en exclusiva o sin ella y,

en su caso, las condiciones y características de las puestas en escena o
ejecuciones.
Artículo 62.-Si no quedara asentado en el contrato de representación escénica el

período durante el cual se representará o ejecutará la obra al público, se
entenderá que es por un año.
Artículo 63.-Son obligaciones del empresario:
I. Asegurar la representación o la ejecución pública en las condiciones

pactadas.
II. Garantizar al autor, al titular de los derechos patrimoniales o a sus

representantes el acceso gratuito a la misma.
III. Satisfacer al titular de los derechos patrimoniales la remuneración

convenida.
Artículo 64.-Salvo pacto en contrario, el contrato de representación escénica

suscrito entre el autor y el empresario autoriza a éste a representar la obra en todo
el territorio de la República Mexicana.
Artículo 65.-Son aplicables al contrato de representación escénica las

disposiciones del contrato de edición de obra literaria en todo aquello que no se
oponga a lo dispuesto en el presente capítulo.
Capítulo V
DEL CONTRATO DE RADIODIFUSIÓN

Artículo 66.-Por el contrato de radiodifusión el autor o el titular de los

derechos patrimoniales, en su caso, autoriza a un organismo de radiodifusión a
transmitir una obra.
Las disposiciones aplicables a las transmisiones de estos organismos resultarán

aplicables, en lo conducente, a las efectuadas por cable, fibra óptica, ondas
radioeléctricas, satélite o cualquier otro medio análogo, que hagan posible la
comunicación remota al público de obras protegidas.
Artículo 67.-Son aplicables al contrato de radiodifusión las disposiciones del

contrato de edición de obra literaria en todo aquello que no se oponga a lo
dispuesto por el presente capítulo.
Capítulo VI
DEL CONTRATO DE PRODUCCIÓN AUDIOVISUAL
Artículo 68.-Por el contrato de producción audiovisual, los autores o los titulares de

los derechos patrimoniales, en su caso, ceden en exclusiva al productor los
derechos patrimoniales de reproducción, distribución, comunicación pública y
subtitulada de la obra audiovisual, salvo pacto en contrario. Se exceptúan de lo
anterior las obras musicales.
Artículo 69.-Cuando la aportación de un autor no se completase por causa de

fuerza mayor, el productor podrá utilizar la parte ya realizada, respetando los
derechos de aquél sobre la misma, incluso el del anonimato, sin perjuicio, de la
indemnización que proceda.
Artículo 70.-Caducarán de pleno derecho los efectos del contrato de producción, si

la realización de la obra audiovisual no se inicia en el plazo estipulado por las
partes o por fuerza mayor.
Artículo 71.-Se considera terminada la obra audiovisual cuando, de acuerdo con lo

pactado entre el director realizador por una parte, y el productor por la otra, se
haya llegado a la versión definitiva.
Artículo 72.-Son aplicables al contrato de producción audiovisual las disposiciones

del contrato de edición de obra literaria en todo aquello que no se oponga a lo
dispuesto en el presente capítulo.
Capítulo VII

DE LOS CONTRATOS PUBLICITARIOS
Artículo 73.-Son contratos publicitarios los que tengan por finalidad la explotación
de obras literarias o artísticas con fines de promoción o identificación en anuncios
publicitarios o de propaganda a través de cualquier medio de comunicación.
Artículo 74.-Los anuncios publicitarios o de propaganda podrán ser difundidos
hasta por un período máximo de seis meses a partir de la primera comunicación.
Pasado este término, su comunicación deberá retribuirse, por cada período
adicional de seis meses, aun cuando sólo se efectúe en fracciones de ese
período, al menos con una cantidad igual a la contratada originalmente. Después
de transcurridos tres años desde la primera comunicación, su uso requerirá la
autorización de los autores y de los titulares de los derechos conexos de las obras
utilizadas.
Artículo 75.-En el caso de publicidad en medios impresos, el contrato deberá

precisar el soporte o soportes materiales en los que se reproducirá la obra y, si se
trata de folletos o medios distintos de las publicaciones periódicas, el número de
ejemplares de que constará el tiraje. Cada tiraje adicional deberá ser objeto de un
acuerdo expreso.
Articulo 76.-Son aplicables a los contratos publicitarios las disposiciones del

contrato de edición de obra literaria, de obra musical y de producción audiovisual
en todo aquello que no se oponga a lo dispuesto en el presente capítulo.
TITULO IV
DE LA PROTECCIÓN AL DERECHO DE AUTOR
Capítulo I
Artículo 77.-La persona cuyo nombre o seudónimo, conocido o registrado,

aparezca como autor de una obra, será considerada como tal, salvo prueba en
contrario y, en consecuencia, se admitirán por los tribunales competentes las
acciones que entable por transgresión a sus derechos.
Respecto de las obras firmadas bajo seudónimo o cuyos autores no se hayan

dado a conocer, las acciones para proteger el derecho corresponderán a la
persona que las haga del conocimiento público con el consentimiento del autor,

quien tendrá las responsabilidades de un gestor, hasta en cuanto el titular

de los derechos no comparezca en el juicio respectivo, a no ser que existiera
convenio previo en contrario.
Artículo 78.-Las obras derivadas, tales como arreglos, compendios, ampliaciones,

traducciones, adaptaciones, paráfrasis, compilaciones, colecciones y
transformaciones de obras literarias o artísticas, serán protegidas en lo que tengan
de originales, pero sólo podrán ser explotadas cuando hayan sido autorizadas por
el titular del derecho patrimonial sobre la obra primigenia, previo consentimiento
del titular del derecho moral, en los casos previstos en la Fracción III del Artículo
21 de la Ley.
Cuando las obras derivadas sean del dominio público, serán protegidas en lo que
tengan de originales, pero tal protección no comprenderá el derecho al uso
exclusivo de la obra primigenia, ni dará derecho a impedir que se hagan otras
versiones de la misma.
Artículo 79.-El traductor o el titular de los derechos patrimoniales de la traducción

de una obra que acredite haber obtenido la autorización del titular de los derechos
patrimoniales para traducirla gozará, con respecto de la traducción de que se trate,
de la protección que la presente Ley le otorga. Por lo tanto, dicha traducción no
podrá ser reproducida, modificada, publicada o alterada, sin consentimiento del
traductor. Cuando una traducción se realice en los términos del párrafo anterior, y
presente escasas o pequeñas diferencias con otra traducción, se considerará
como simple reproducción.
Artículo 80.-En el caso de las obras hechas en coautoría, los derechos otorgados
por esta Ley, corresponderán a todos los autores por partes iguales, salvo pacto
en contrario o que se demuestre la autoría de cada uno.
Para ejercitar los derechos establecidos por esta Ley, se requiere el

consentimiento de la mayoría de los autores, mismo que obliga a todos. En su
caso, la minoría no está obligada a contribuir a los gastos que se generen, sino
con cargo a los beneficios que se obtengan. Cuando la mayoría haga uso o
explote la obra, deducirá de la percepción total, el importe de los gastos
efectuados y entregará a la minoría la participación que corresponda.
Cuando la parte realizada por cada uno de los autores sea claramente
identificable, éstos podrán libremente ejercer los derechos a que se refiere esta
Ley en la parte que les corresponda. Salvo pacto en contrario, cada uno de los
coautores de una obra podrán solicitar la inscripción de la obra completa. Muerto

alguno de los coautores o titulares de los derechos patrimoniales, sin

herederos, su derecho acrecerá el de los demás.
Artículo 81.-Salvo pacto en contrario, el derecho de autor sobre una obra con
música y letra pertenecerá, por partes iguales al autor de la parte literaria y al de la
parte musical. Cada uno de ellos, podrá libremente ejercer los derechos de la
parte que le corresponda o de la obra completa y, en este último caso, deberá dar
aviso en forma indubitable al coautor, mencionando su nombre en la edición,
además de abonarle la parte que le corresponda cuando lo haga con fines
lucrativos.
Artículo 82.- Quienes contribuyan con artículos a periódicos, revistas, programas

de radio o televisión u otros medios de difusión, salvo pacto en contrario,
conservan el derecho de editar sus artículos en forma de colección, después de
haber sido transmitidos o publicados en el periódico, la revista o la estación en que
colaboren.
Artículo 83.-Salvo pacto en contrario, la persona física o moral que comisione la

producción de una obra o que la produzca con la colaboración remunerada de
otras, gozará de la titularidad de los derechos patrimoniales sobre la misma y le
corresponderán las facultades relativas a la divulgación, integridad de la obra y de
colección sobre este tipo de creaciones.
La persona que participe en la realización de la obra, en forma remunerada, tendrá

el derecho a que se le mencione expresamente su calidad de autor, artista,
intérprete o ejecutante sobre la parte o partes en cuya creación haya participado.
Artículo 83 bis.- Adicionalmente a lo establecido en el Artículo anterior, la persona

que participe en la realización de una obra musical en forma remunerada, tendrá
el derecho al pago de regalías que se generen por la comunicación o transmisión
pública de la obra, en términos de los Artículos 26 bis y 117 bis de esta Ley.
Para que una obra se considere realizada por encargo, los términos del contrato
deberán ser claros y precisos, en caso de duda, prevalecerá la interpretación más
favorable al autor. El autor también está facultado para elaborar su contrato
cuando se le solicite una obra por encargo.
Artículo 84.-Cuando se trate de una obra realizada como consecuencia de una

relación laboral establecida a través de un contrato individual de trabajo que
conste por escrito, a falta de pacto en contrario, se presumirá que los derechos
patrimoniales se dividen por partes iguales entre empleador y empleado.

El empleador podrá divulgar la obra sin autorización del empleado, pero no

al contrario. A falta de contrato individual de trabajo por escrito, los derechos
patrimoniales corresponderán al empleado.
Capítulo II
DE LAS OBRAS FOTOGRÁFICAS, PLÁSTICAS Y GRÁFICAS
Artículo 85.-Salvo pacto en contrario, se considerará que el autor que haya

enajenado su obra pictórica, escultórica y de artes plásticas en general, no ha
concedido al adquirente el derecho de reproducirla, pero sí el de exhibirla y el de
plasmarla en catálogos. En todo caso, el autor podrá oponerse al ejercicio de
estos derechos, cuando la exhibición se realice en condiciones que perjudiquen su
honor o reputación profesional.
Artículo 86.-Los fotógrafos profesionales sólo pueden exhibir las fotografías

realizadas bajo encargo como muestra de su trabajo, previa autorización. Lo
anterior no será necesario cuando los fines sean culturales, educativos, o de
publicaciones sin fines de lucro.
Artículo 87.-El retrato de una persona sólo puede ser usado o publicado, con su
consentimiento expreso, o bien con el de sus representantes o los titulares de los
derechos correspondientes. La autorización de usar o publicar el retrato podrá
revocarse por quien la otorgó quién, en su caso, responderá por los daños y
perjuicios que pudiera ocasionar dicha revocación.
Cuando a cambio de una remuneración, una persona se dejare retratar, se

presume que ha otorgado el consentimiento a que se refiere el párrafo anterior y
no tendrá derecho a revocarlo, siempre que se utilice en los términos y para los
fines pactados.
No será necesario el consentimiento a que se refiere este artículo cuando se trate

del retrato de una persona que forme parte menor de un conjunto o la fotografía
sea tomada en un lugar público y con fines informativos o periodísticos. Los
derechos establecidos para las personas retratadas durarán 50 años después de
su muerte.
Artículo 88.-Salvo pacto en contrario, el derecho exclusivo a reproducir una obra

pictórica, fotográfica, gráfica o escultórica no incluye el derecho a reproducirla en
cualquier tipo de artículo así como la promoción comercial de éste.

Artículo 89.-La obra gráfica y fotográfica en serie es aquella que resulta de

la elaboración de varias copias a partir de una matriz hecha por el autor.
Artículo 90.-Para los efectos de esta Ley, los ejemplares de obra gráfica y
fotográfica en serie debidamente firmados y numerados se consideran como
originales.
Artículo 91.-A las esculturas que se realicen en serie limitada y numerada a partir
de un molde se les aplicarán las disposiciones de este capítulo.
Artículo 92.-Salvo pacto en contrario, el autor de una obra de arquitectura no

podrá impedir que el propietario de ésta le haga modificaciones, pero tendrá la
facultad de prohibir que su nombre sea asociado a la obra alterada.
Artículo 92 bis.-Los autores de obras de artes plásticas y fotográficas tendrán

derecho a percibir del vendedor una participación en el precio de toda reventa que
de las mismas se realice en pública subasta, en establecimiento mercantil, o con
la intervención de un comerciante o agente mercantil, con excepción de las obras
de arte aplicado.
I. La mencionada participación de los autores será fijada por el Instituto en los

términos del Artículo 212 de la Ley.
II. El derecho establecido en este Artículo es irrenunciable, se transmitirá
únicamente por sucesión mortis causa y se extinguirá transcurridos cien años a
partir de la muerte o de la declaración de fallecimiento del autor.
III. Los subastadores, titulares de establecimientos mercantiles, o agentes

mercantiles que hayan intervenido en la reventa deberán notificarla a la sociedad
de gestión colectiva correspondiente o, en su caso, al autor o sus derecho-
habientes, en el plazo de dos meses, y facilitarán la documentación necesaria
para la práctica de la correspondiente liquidación. Asimismo, cuando actúen por
cuenta o encargo del vendedor, responderán solidariamente con éste del pago del
derecho, a cuyo efecto retendrán del precio la participación que proceda. En todo
caso, se considerarán depositarios del importe de dicha participación.
IV. El mismo derecho se aplicará respecto de los manuscritos originales de las

obras literarias y artísticas.
Artículo 93.-Las disposiciones de este capítulo serán válidas para las obras de arte
aplicado en lo que tengan de originales. No será objeto de protección el uso que
se dé a las mismas.

Capítulo III
DE LA OBRA CINEMATOGRÁFICA Y AUDIOVISUAL
Artículo 94.-Se entiende por obras audiovisuales las expresadas mediante una
serie de imágenes asociadas, con o sin sonorización incorporada, que se hacen
perceptibles, mediante dispositivos técnicos, produciendo la sensación de
movimiento.
Artículo 95.-Sin perjuicio de los derechos de los autores de las obras adaptadas o
incluidas en ella, la obra audiovisual, será protegida como obra primigenia.
Artículo 96.-Los titulares de los derechos patrimoniales podrán disponer de sus

respectivas aportaciones a la obra audiovisual para explotarlas en forma aislada,
siempre que no se perjudique la normal explotación de dicha obra.
Artículo 97.-Son autores de las obras audiovisuales:
I. El director realizador.
II. Los autores del argumento, adaptación, guión o diálogo.
III. Los autores de las composiciones musicales.
IV. El fotógrafo.
V. Los autores de las caricaturas y de los dibujos animados.
VI. Salvo pacto en contrario, se considera al productor como el titular de los

derechos patrimoniales de la obra en su conjunto.
Artículo 98.-Es productor de la obra audiovisual la persona física o moral que tiene
la iniciativa, la coordinación y la responsabilidad en la realización de una obra, o
que la patrocina.
Artículo 99.-Salvo pacto en contrario, el contrato que se celebre entre el autor o los
titulares de los derechos patrimoniales, en su caso, y el productor, no implica la

cesión ilimitada y exclusiva a favor de éste de los derechos patrimoniales

sobre la obra audiovisual.
Una vez que los autores o los titulares de derechos patrimoniales se hayan
comprometido a aportar sus contribuciones para la realización de la obra
audiovisual, no podrán oponerse a la reproducción, distribución, representación y
ejecución pública, transmisión por cable, radiodifusión, comunicación al público,
subtitulado y doblaje de los textos de dicha obra.
Sin perjuicio de los derechos de los autores, el productor puede llevar a cabo
todas las acciones necesarias para la explotación de la obra audiovisual.
Artículo 100.-Las disposiciones contenidas en el presente capítulo se aplicarán en

lo pertinente a las obras de radiodifusión.
Capítulo IV
DE LOS PROGRAMAS DE COMPUTACIÓN Y LAS BASES DE DATOS
Artículo 101.-Se entiende por programa de computación la expresión original en

cualquier forma, lenguaje o código, de un conjunto de instrucciones que, con una
secuencia, estructura y organización determinada, tiene como propósito que una
computadora o dispositivo realice una tarea o función específica.
Artículo 102.-Los programas de computación se protegen en los mismos términos

que las obras literarias. Dicha protección se extiende tanto a los programas
operativos como a los programas aplicativos, ya sea en forma de código fuente o
de código objeto. Se exceptúan aquellos programas de cómputo que tengan por
objeto causar efectos nocivos a otros programas o equipos.
Artículo 103.- Salvo pacto en contrario, los derechos patrimoniales sobre un

programa de computación y su documentación, cuando hayan sido creados por
uno o varios empleados en el ejercicio de sus funciones o siguiendo las
instrucciones del empleador, corresponden a éste. Como excepción a lo previsto
por el artículo 33 de la presente Ley, el plazo de la cesión de derechos en materia
de programas de computación no está sujeto a limitación alguna.
Artículo 104.- Como excepción a lo previsto en el artículo 27 fracción IV, el titular

de los derechos de autor sobre un programa de computación o sobre una base de
datos conservará, aún después de la venta de ejemplares de los mismos, el
derecho de autorizar o prohibir el arrendamiento de dichos ejemplares. Este

precepto no se aplicará cuando el ejemplar del programa de computación

no constituya en sí mismo un objeto esencial de la licencia de uso.
Artículo 105.-El usuario legítimo de un programa de computación podrá realizar el

número de copias que le autorice la licencia concedida por el titular de los
derechos de autor, o una sola copia de dicho programa siempre y cuando:
I. Sea indispensable para la utilización del programa.

II. Sea destinada exclusivamente como resguardo para sustituir la copia
legítimamente adquirida, cuando ésta no pueda utilizarse por daño o pérdida. La
copia de respaldo deberá ser destruida cuando cese el derecho del usuario para
utilizar el programa de computación.
Artículo 106.-El derecho patrimonial sobre un programa de computación

comprende la facultad de autorizar o prohibir:
I. La reproducción permanente o provisional del programa en todo o en parte,

por cualquier medio y forma.
II. La traducción, la adaptación, el arreglo o cualquier otra modificación de un
programa y la reproducción del programa resultante.
III. Cualquier forma de distribución del programa o de una copia del mismo,
incluido el alquiler.
IV. La decompilación, los procesos para revertir la ingeniería de un programa
de computación y el desensamblaje.
Artículo 107.-Las bases de datos o de otros materiales legibles por medio de

máquinas o en otra forma, que por razones de selección y disposición de su
contenido constituyan creaciones intelectuales, quedarán protegidas como
compilaciones. Dicha protección no se extenderá a los datos y materiales en sí
mismos.
Artículo 108.-Las bases de datos que no sean originales quedan, sin embargo,
protegidas en su uso exclusivo por quien las haya elaborado, durante un lapso de
5 años.
Artículo 109.-El acceso a información de carácter privado relativa a las personas,

contenida en las bases de datos a que se refiere el artículo anterior, así como la
publicación, reproducción, divulgación, comunicación pública y transmisión de
dicha información, requerirá la autorización previa de las personas de que se trate.

Quedan exceptuados de lo anterior, las investigaciones de las autoridades

encargadas de la procuración e impartición de justicia, de acuerdo con la
legislación respectiva, así como el acceso a archivos públicos por las personas
autorizadas por la ley, siempre que la consulta sea realizada conforme a los
procedimientos respectivos.
Artículo 110.-El titular del derecho patrimonial sobre una base de datos tendrá el
derecho exclusivo, respecto de la forma de expresión de la estructura de dicha
base, de autorizar o prohibir:
I. Su reproducción permanente o temporal, total o parcial, por cualquier medio

y de cualquier forma.
II. Su traducción, adaptación, reordenación y cualquier otra modificación.
III. La distribución del original o copias de la base de datos;
IV. La comunicación al público.
V. La reproducción, distribución o comunicación pública de los resultados de
las operaciones mencionadas en la fracción II del presente artículo.
Artículo 111.-Los programas efectuados electrónicamente que contengan

elementos visuales, sonoros, tridimensionales o animados quedan protegidos por
esta Ley en los elementos primigenios que contengan.
Artículo 112.-Queda prohibida la importación, fabricación, distribución y utilización

de aparatos o la prestación de servicios destinados a eliminar la protección técnica
de los programas de cómputo, de las transmisiones a través del espectro
electromagnético y de redes de telecomunicaciones y de los programas de
elementos electrónicos señalados en el artículo anterior.
Artículo 113.-Las obras e interpretaciones o ejecuciones transmitidas por medios

electrónicos a través del espectro electromagnético y de redes de
telecomunicaciones y el resultado que se obtenga de transmisión estarán
protegidas por esta Ley.
Artículo 114.-La transmisión de obras protegidas por esta Ley mediante cable,
ondas radioeléctricas, satélite u otras similares, deberán adecuarse, en lo
conducente, a la legislación mexicana y respetar en todo caso y en todo tiempo las
disposiciones sobre la materia.

Titulo V
DE LOS DERECHOS CONEXOS
Capítulo I
Artículo 115.-La protección prevista en este título dejará intacta y no afectará en

modo alguno la protección de los derechos de autor sobre las obras literarias y
artísticas. Por lo tanto, ninguna de las disposiciones del presente título podrá
interpretarse en menoscabo de esa protección.
Capítulo II
DE LOS ARTISTAS INTÉRPRETES O EJECUTANTES
Artículo 116.-Los términos artista intérprete o ejecutante designan al actor,

narrador, declamador, cantante, músico, bailarín, o a cualquiera otra persona que
interprete o ejecute una obra literaria o artística o una expresión del folclor o que
realice una actividad similar a las anteriores, aunque no haya un texto previo que
norme su desarrollo. Los llamados extras y las participaciones eventuales no
quedan incluidos en esta definición.
Artículo 117.-El artista intérprete o ejecutante goza del derecho al reconocimiento

de su nombre respecto de sus interpretaciones o ejecuciones así como el de
oponerse a toda deformación, mutilación o cualquier otro atentado sobre su
actuación que lesione su prestigio o reputación.
Artículo 117 bis.-Tanto el artista intérprete o el ejecutante, tiene el derecho

irrenunciable a percibir una remuneración por el uso o explotación de sus
interpretaciones o ejecuciones que se hagan con fines de lucro directo o indirecto,
por cualquier medio, comunicación pública o puesta a disposición.
Artículo 118.-Los artistas intérpretes o ejecutantes tienen el derecho de oponerse

a:
I. La comunicación pública de sus interpretaciones o ejecuciones.
II. La fijación de sus interpretaciones o ejecuciones sobre una base material.

III. La reproducción de la fijación de sus interpretaciones o ejecuciones.
Estos derechos se consideran agotados una vez que el artista intérprete o

ejecutante haya autorizado la incorporación de su actuación o interpretación en
una fijación visual, sonora o audiovisual, siempre y cuando los usuarios que
utilicen con fines de lucro dichos soportes materiales, efectúen el pago
correspondiente.
Artículo 119.-Los artistas que participen colectivamente en una misma actuación,

tales como grupos musicales, coros, orquestas, de ballet o compañías de teatro,
deberán designar entre ellos a un representante para el ejercicio del derecho de
oposición a que se refiere el artículo anterior. A falta de tal designación se
presume que actúa como representante el director del grupo o compañía.
Artículo 120.-Los contratos de interpretación o ejecución deberán precisar los

tiempos, períodos, contraprestaciones y demás términos y modalidades bajo los
cuales se podrá fijar, reproducir y comunicar al público dicha interpretación o
ejecución.
Artículo 121.-Salvo pacto en contrario, la celebración de un contrato entre un

artista intérprete o ejecutante y un productor de obras audiovisuales para la
producción de una obra audiovisual conlleva el derecho de fijar, reproducir y
comunicar al público las actuaciones del artista. Lo anterior no incluye el derecho
de utilizar en forma separada el sonido y las imágenes fijadas en la obra
audiovisual, a menos que se acuerde expresamente.
Artículo 122.-La Duración de la protección concedida a los artistas intérpretes o

ejecutantes será de setenta y cinco años contados a partir de:
I. La primera fijación de la interpretación o ejecución en un fonograma.
II. La primera interpretación o ejecución de obras no grabadas en fonogramas.
III. La transmisión por primera vez a través de la radio, televisión o cualquier

medio.
Capítulo III
DE LOS EDITORES DE LIBROS

Artículo 123.-El libro es toda publicación unitaria, no periódica, de carácter

literario, artístico, científico, técnico, educativo, informativo o recreativo, impresa
en cualquier soporte, cuya edición se haga en su totalidad de una sola vez en un
volumen o a intervalos en varios volúmenes o fascículos. Comprenderá también
los materiales complementarios en cualquier tipo de soporte, incluido el
electrónico, que conformen, conjuntamente con el libro, un todo unitario que no
pueda comercializarse separadamente.
Artículo 124.-El editor de libros es la persona física o moral que selecciona o

concibe una edición y realiza por sí o a través de terceros su elaboración.
Artículo 125.-Los editores de libros tendrán el derecho de autorizar o prohibir:
I. La reproducción directa o indirecta, total o parcial de sus libros, así como la

explotación de los mismos.
II. La importación de copias de sus libros hechas sin su autorización.
III. La primera distribución pública del original y de cada ejemplar de sus libros
mediante venta u otra manera.
Artículo 126.-Los editores de libros gozarán del derecho de exclusividad sobre las
características tipográficas y de diagramación para cada libro, en cuanto
contengan de originales.
Artículo 127.-La protección a que se refiere este capítulo será de 50 años

contados a partir de la primera edición del libro de que se trate.
Artículo 128.-Las publicaciones periódicas gozarán de la misma protección que el

presente capítulo otorga a los libros.
Capítulo IV
DE LOS PRODUCTORES DE FONOGRAMAS
Artículo 129.-Fonograma es toda fijación, exclusivamente sonora, de los sonidos

de una interpretación, ejecución o de otros sonidos, o de representaciones
digitales de los mismos.
Artículo 130.-Productor de fonogramas es la persona física o moral que fija por

primera vez los sonidos de una ejecución u otros sonidos o la representación

digital de los mismos y es responsable de la edición, reproducción y

publicación de fonogramas.
Artículo 131.-Los productores de fonogramas tendrán el derecho de autorizar o

prohibir:
I. La reproducción directa o indirecta, total o parcial de sus fonogramas, así

como la explotación directa o indirecta de los mismos.
II. La importación de copias del fonograma hechas sin la autorización del

productor.
III. La distribución pública del original y de cada ejemplar del fonograma

mediante venta u otra incluyendo su distribución a través de señales o emisiones.
IV. La adaptación o transformación del fonograma.
V. El arrendamiento comercial del original o de una copia del fonograma, aún

después de la venta del mismo, siempre y cuando no se lo hubieren reservado los
autores o los titulares de los derechos patrimoniales.
Artículo 131 bis.-Los productores de fonogramas tienen el derecho a percibir una

remuneración por el uso o explotación de sus fonogramas que se hagan con fines
de lucro directo o indirecto, por cualquier medio o comunicación pública o puesta a
disposición.
Artículo 132.-Los fonogramas deberán ostentar el símbolo (P) acompañado de la

indicación del año en que se haya realizado la primera publicación. La omisión de
estos requisitos no implica la pérdida de los derechos que correspondan al
productor de fonogramas pero lo sujeta a las sanciones establecidas por la Ley.
Se presumirá, salvo prueba en contrario, que es Productor de Fonogramas,

la persona física o moral cuyo nombre aparezca indicado en los ejemplares
legítimos del fonograma, precedido de la letra "P", encerrada en un círculo y
seguido del año de la primera publicación. Los productores de fonogramas
deberán notificar a las sociedades de gestión colectiva los datos de etiqueta de
sus producciones y de las matrices que se exporten, indicando los países en cada
caso.
Artículo 133.-Una vez que un fonograma haya sido introducido legalmente a

cualquier circuito comercial, ni los artistas intérpretes o ejecutantes, ni los

productores de fonogramas podrán oponerse a su comunicación directa al

público, siempre y cuando los usuarios que lo utilicen con fines de lucro efectúen
el pago correspondiente a aquéllos. A falta de acuerdo entre las partes, el pago de
sus derechos se efectuará por partes iguales.
Artículo 134.-La protección a que se refiere este Capítulo será de setenta y cinco
años, a partir de la primera fijación de los sonidos en el fonograma.
Capítulo V
DE LOS PRODUCTORES DE VIDEOGRAMAS
Artículos 135.-Se considera videograma a la fijación de imágenes asociadas, con

o sin sonido incorporado, que den sensación de movimiento, o de una
representación digital de tales imágenes de una obra audiovisual o de la
representación o ejecución de otra obra o de una expresión del folclor, así como
de otras imágenes de la misma clase, con o sin sonido.
Artículo 136.-Productor de videogramas es la persona física o moral que fija por

primera vez imágenes asociadas, con o sin sonido incorporado, que den
sensación de movimiento, o de una representación digital de tales imágenes,
constituyan o no una obra audiovisual.
Artículo 137.-El productor goza, respecto de sus videogramas, de los derechos de

autorizar o prohibir su reproducción, distribución y comunicación pública.
Artículo 138.-La duración de los derechos regulados en este capítulo es de

cincuenta años a partir de la primera fijación de las imágenes en el videograma.
Capítulo VI
DE LOS ORGANISMOS DE RADIODIFUSIÓN
Artículo 139.-Para efectos de la presente Ley, se considera organismo de

radiodifusión, la entidad concesionada o permisionada capaz de emitir señales
sonoras, visuales o ambas, susceptibles de percepción, por parte de una
pluralidad de sujetos receptores.
Artículo 140.-Se entiende por emisión o transmisión, la comunicación de obras, de

sonidos o de sonidos con imágenes por medio de ondas radioeléctricas, por cable,
fibra óptica u otros procedimientos análogos. El concepto de emisión comprende

también el envío de señales desde una estación terrestre hacia un satélite

que posteriormente las difunda.
Artículo 141.-Retransmisión es la emisión simultánea por un organismo de
radiodifusión de una emisión de otro organismo de radiodifusión.
Artículo 142.-Grabación efímera es la que realizan los organismos de

radiodifusión, cuando por razones técnicas o de horario y para el efecto de una
sola emisión posterior, tienen que grabar o fijar la imagen, el sonido o ambos
anticipadamente en sus estudios, de selecciones musicales o partes de ellas,
trabajos, conferencias o estudios científicos, obras literarias, dramáticas,
coreográficas, dramáticomusicales, programas completos y, en general, cualquier
obra apta para ser difundida.
Artículo 143.-Las señales pueden ser:
I. Por su posibilidad de acceso al público:
a) Codificadas, cifradas o encriptadas: las que han sido modificadas con el

propósito de que sean recibidas y descifradas única y exclusivamente por quienes
hayan adquirido previamente ese derecho del organismo de radiodifusión que las
emite.
b) Libres: las que pueden ser recibidas por cualquier aparato apto para recibir
las señales.
II. Por el momento de su emisión:

a) De origen: las que portan programas o eventos en vivo.
b) Diferidas: las que portan programas o eventos previamente fijados.
Artículo 144.- Los organismos de radiodifusión tendrán el derecho de autorizar o

prohibir respecto de sus emisiones:
I. La retransmisión.
II. La transmisión diferida.
III. La distribución simultánea o diferida, por cable o cualquier otro sistema.
IV. La fijación sobre una base material.
V. La reproducción de las fijaciones.

VI. La comunicación pública por cualquier medio y forma con fines

directos de lucro.
Artículo 145.-Deberá pagar daños y perjuicios la persona que sin la autorización

del distribuidor legítimo de la señal:
I. Descifre una señal de satélite codificada portadora de programas.
II. Reciba y distribuya una señal de satélite codificada portadora de programas

que hubiese sido descifrada ilícitamente.
III. Participe o coadyuve en la fabricación, importación, venta, arrendamiento o

realización de cualquier acto que permita contar con un dispositivo o sistema que
sea de ayuda primordial para descifrar una señal de satélite codificada, portadora
de programas.
Artículo 146.-Los derechos de los organismos de radiodifusión a los que se refiere

este Capítulo tendrán una vigencia de cincuenta años a partir de la primera
emisión o transmisión original del programa.
Título VI
DE LAS LIMITACIONES DEL DERECHO DE AUTOR Y DE LOS DERECHOS

CONEXOS
Capítulo I
DE LA LIMITACIÓN POR CAUSA DE UTILIDAD PÚBLICA
Artículo 147.-Se considera de utilidad pública la publicación o traducción de obras

literarias o artísticas necesarias para el adelanto de la ciencia, la cultura y la
educación nacionales. Cuando no sea posible obtener el consentimiento del titular
de los derechos patrimoniales correspondientes, y mediante el pago de una
remuneración compensatoria, el Ejecutivo Federal, por conducto de la Secretaría
de Educación Pública, de oficio o a petición de parte, podrá autorizar la
publicación o traducción mencionada. Lo anterior será sin perjuicio de los tratados
internacionales sobre derechos de autor y derechos conexos suscritos y
aprobados por México.

Capítulo II
DE LA LIMITACIÓN A LOS DERECHOS PATRIMONIALES
Artículo 148.-Las obras literarias y artísticas ya divulgadas podrán utilizarse,

siempre que no se afecte la explotación normal de la obra, sin autorización del
titular del derecho patrimonial y sin remuneración, citando invariablemente la
fuente y sin alterar la obra, sólo en los siguientes casos:
I. Cita de textos, siempre que la cantidad tomada no pueda considerarse

como una reproducción simulada y sustancial del contenido de la obra.
II. Reproducción de artículos, fotografías, ilustraciones y comentarios

referentes a acontecimientos de actualidad, publicados por la prensa o difundidos
por la radio o la televisión, o cualquier otro medio de difusión, si esto no hubiere
sido expresamente prohibido por el titular del derecho.
III. Reproducción de partes de la obra, para la crítica e investigación científica,

literaria o artística.
IV. Reproducción por una sola vez, y en un sólo ejemplar, de una obra literaria
o artística, para uso personal y privado de quien la hace y sin fines de lucro. Las
personas morales no podrán valerse de lo dispuesto en esta fracción salvo que se
trate de una institución educativa, de investigación, o que no esté dedicada a
actividades mercantiles.
V. Reproducción de una sola copia, por parte de un archivo o biblioteca, por

razones de seguridad y preservación, y que se encuentre agotada, descatalogada
y en peligro de desaparecer.
VI. Reproducción para constancia en un procedimiento judicial o administrativo.
VII. Reproducción, comunicación y distribución por medio de dibujos, pinturas,

fotografías y procedimientos audiovisuales de las obras que sean visibles desde
lugares públicos.
Artículo 149.-Podrán realizarse sin autorización:

I. La utilización de obras literarias y artísticas en tiendas o establecimientos
abiertos al público, que comercien ejemplares de dichas obras, siempre y cuando
no hayan cargos de admisión y que dicha utilización no trascienda el lugar en

donde la venta se realiza y tenga como propósito único el de promover la

venta de ejemplares de las obras.
II. La grabación efímera, sujetándose a las siguientes condiciones:
a) La transmisión deberá efectuarse dentro del plazo que al efecto se

convenga.
b) No debe realizarse con motivo de la grabación, ninguna emisión o
comunicación concomitante o simultánea.
c) La grabación sólo dará derecho a una sola emisión.
La grabación y fijación de la imagen y el sonido realizada en las condiciones

que antes se mencionan, no obligará a ningún pago adicional distinto del que
corresponde por el uso de las obras. Las disposiciones de esta fracción no se
aplicarán en caso de que los autores o los artistas tengan celebrado convenio de
carácter oneroso que autorice las emisiones posteriores.
Artículo 150.- No se causarán regalías por ejecución pública cuando concurran de

manera conjunta las siguientes circunstancias:
I. Que la ejecución sea mediante la comunicación de una transmisión recibida

directamente en un aparato mono receptor de radio o televisión del tipo
comúnmente utilizado en domicilios privados.
II. No se efectúe un cobro para ver u oír la transmisión o no forme parte de un

conjunto de servicios.
III. No se retransmita la transmisión recibida con fines de lucro.
IV. El receptor sea un causante menor o una microindustria.
Artículo 151.-No constituyen violaciones a los derechos de los artistas intérpretes

o ejecutantes, productores de fonogramas, de videogramas u organismos de
radiodifusión la utilización de sus actuaciones, fonogramas, videogramas o
emisiones, cuando:
I. No se persiga un beneficio económico directo.
II. Se trate de breves fragmentos utilizados en informaciones sobre sucesos

de actualidad.

III. Sea con fines de enseñanza o investigación científica.
IV. Se trate de los casos previstos en los artículos 147, 148 y 149 de la
presente Ley.
Capítulo III
DEL DOMINIO PÚBLICO
Artículo 152.-Las obras del dominio público pueden ser libremente utilizadas por
cualquier persona, con la sola restricción de respetar los derechos morales de los
respectivos autores.
Artículo 153.-Es libre el uso de la obra de un autor anónimo mientras el mismo no

se dé a conocer o no exista un titular de derechos patrimoniales identificado.
Titulo VII
DE LOS DERECHOS DE AUTOR SOBRE LOS SÍMBOLOS PATRIOS Y DE LAS

EXPRESIONES DE LAS CULTURAS POPULARES
Capítulo I
Artículo 154.-Las obras a que se refiere este Título están protegidas

independientemente de que no se pueda determinar la autoría individual de ellas o
que el plazo de protección otorgado a sus autores se haya agotado.
Capítulo II
DE LOS SÍMBOLOS PATRIOS
Artículo 155.-El Estado Mexicano es el titular de los derechos morales sobre los
símbolos patrios.
Artículo 156.-El uso de los símbolos patrios deberá apegarse a lo establecido por
la Ley sobre el Escudo, la Bandera y el Himno Nacionales.

Capítulo III
DE LAS CULTURAS POPULARES
Artículo 157.-La presente Ley protege las obras literarias, artísticas, de arte
popular o artesanal, así como todas las manifestaciones primigenias en sus
propias lenguas, y los usos, costumbres y tradiciones de la composición
pluricultural que conforman al Estado Mexicano, que no cuenten con autor
identificable.
Artículo 158.-Las obras literarias, artística, de arte popular o artesanal;

desarrolladas y perpetuadas en una comunidad o etnia originaria o arraigada en la
República Mexicana, estarán protegidas por la presente Ley contra su
deformación, hecha con objeto de causar demérito a la misma o perjuicio a la
reputación o imagen de la comunidad o etnia a la cual pertenecen.
Artículo 159.-Es libre la utilización de las obras literarias, artísticas, de arte popular
o artesanal; protegidas por el presente capítulo, siempre que no se contravengan
las disposiciones del mismo.
Artículo 160.-En toda fijación, representación, publicación, comunicación o

utilización en cualquier forma, de una obra literaria, artística, de arte popular o
artesanal; protegida conforme al presente capítulo, deberá mencionarse la
comunidad o etnia, o en su caso la región de la República Mexicana de la que es
propia.
Artículo 161.-Corresponde al Instituto vigilar el cumplimiento de las disposiciones

del presente capítulo y coadyuvar en la protección de las obras amparadas por el
mismo.
Título VIII
DE LOS REGISTROS DE DERECHOS
Capítulo I
DEL REGISTRO PÚBLICO DEL DERECHO DE AUTOR
Artículo 162.-El Registro Público del Derecho de Autor tiene por objeto garantizar
la seguridad jurídica de los autores, de los titulares de los derechos conexos y de
los titulares de los derechos patrimoniales respectivos y sus causahabientes, así

como dar una adecuada publicidad a las obras, actos y documentos a

través de su inscripción. Las obras literarias y artísticas y los derechos conexos
quedarán protegidos aun cuando no sean registrados.
Artículo 163.-En el Registro Público del Derecho de Autor se podrán inscribir:
I. Las obras literarias o artísticas que presenten sus autores.
II. Los compendios, arreglos, traducciones, adaptaciones u otras versiones de

obras literarias o artísticas, aun cuando no se compruebe la autorización
concedida por el titular del derecho patrimonial para divulgarla. Esta inscripción no
faculta para publicar o usar en forma alguna la obra registrada, a menos de que se
acredite la autorización correspondiente. Este hecho se hará constar tanto en la
inscripción como en las certificaciones que se expidan.
III. Las escrituras y estatutos de las diversas sociedades de gestión colectiva y

las que los reformen o modifiquen.
IV. Los pactos o convenios que celebren las sociedades mexicanas de gestión
colectivas con las sociedades extranjeras.
V. Los actos, convenios o contratos que en cualquier forma confieran,
modifiquen, transmitan, graven o extingan derechos patrimoniales.
VI. Los convenios o contratos relativos a los derechos conexos;
VII. Los poderes otorgados para gestionar ante el Instituto, cuando la

representación conferida abarque todos los asuntos que el mandante haya de
tramitar ante él.
VIII. Los mandatos que otorguen los miembros de las sociedades de gestión
colectiva en favor de éstas.
IX. Los convenios o contratos de interpretación o ejecución que celebren los

artistas intérpretes o ejecutantes.
X. Las características gráficas y distintivas de obras.
Artículo 164.-El Registro Público del Derecho de Autor tiene las siguientes
obligaciones:
I. Inscribir, cuando proceda, las obras y documentos que le sean presentados.

II. Proporcionar a las personas que lo soliciten la información de las

inscripciones y, salvo lo dispuesto en los párrafos siguientes, de los documentos
que obran en el Registro. Tratándose de programas de computación, de contratos
de edición y de obras inéditas, la obtención de copias sólo se permitirá mediante
autorización del titular del derecho patrimonial o por mandamiento judicial. Cuando
la persona o autoridad solicitante requiera de una copia de las constancias de
registro, el Instituto expedirá copia certificada, pero por ningún motivo se permitirá
la salida de originales del Registro. Las autoridades judiciales o administrativas
que requieran tener acceso a los originales, deberán realizar la inspección de los
mismos en el recinto del Registro Público del Derecho de Autor.
Cuando se trate de obras fijadas en soportes materiales distintos del papel,

la autoridad judicial o administrativa, el solicitante o, en su caso, el oferente de la
prueba, deberán aportar los medios técnicos para realizar la duplicación. Las
reproducciones que resulten con motivo de la aplicación de este artículo
únicamente podrán ser utilizadas como constancias en el procedimiento judicial o
administrativo de que se trate.
III. Negar la inscripción de:
a) Lo que no es objeto de protección conforme al artículo 14 de esta Ley.

b) Las obras que son del dominio público.
c) Lo que ya esté inscrito en el Registro.
d) Las marcas, a menos que se trate al mismo tiempo de una obra artística y
la persona que pretende aparecer como titular del derecho de autor lo sea
también de ella.
e) Las campañas y promociones publicitarias.
f) La inscripción de cualquier documento cuando exista alguna anotación
marginal, que suspenda los efectos de la inscripción, proveniente de la
notificación de un juicio relativo a derechos de autor o de la iniciación de
una averiguación previa.
g) En general los actos y documentos que en su forma o en su contenido
contravengan o sean ajenos a las disposiciones de esta Ley.
Artículo 165.-El registro de una obra literaria o artística no podrá negarse ni

suspenderse bajo el supuesto de ser contraria a la moral, al respeto a la vida
privada o al orden público, salvo por sentencia judicial.
Artículo 166.-El registro de una obra artística o literaria no podrá negarse ni

suspenderse so pretexto de algún motivo político, ideológico o doctrinario.

Artículo 167.-Cuando dos o más personas soliciten la inscripción de una misma

obra, ésta se inscribirá en los términos de la primera solicitud, sin perjuicio del
derecho de impugnación del registro.
Artículo 168.-Las inscripciones en el registro establecen la presunción de ser

ciertos los hechos y actos que en ellas consten, salvo prueba en contrario. Toda
inscripción deja a salvo los derechos de terceros. Si surge controversia, los
efectos de la inscripción quedarán suspendidos en tanto se pronuncie resolución
firme por autoridad competente.
Artículo 169.-No obstante lo dispuesto en el artículo anterior, los actos, convenios

o contratos que se otorguen o celebren por personas con derecho para ello y que
sean inscritos en el registro, no se invalidarán en perjuicio de tercero de buena fe,
aunque posteriormente sea anulada dicha inscripción.
Artículo 170.-En las inscripciones se expresará el nombre del autor y, en su caso,

la fecha de su muerte, nacionalidad y domicilio, el título de la obra, la fecha de
divulgación, si es una obra por encargo y el titular del derecho patrimonial. Para
registrar una obra escrita bajo seudónimo, se acompañarán a la solicitud en sobre
cerrado los datos de identificación del autor, bajo la responsabilidad del solicitante
del registro. El representante del registro abrirá el sobre, con asistencia de
testigos, cuando lo pidan el solicitante del registro, el editor de la obra o los
titulares de sus derechos, o por resolución judicial. La apertura del sobre tendrá
por objeto comprobar la identidad del autor y su relación con la obra. Se levantará
acta de la apertura y el encargado expedirá las certificaciones que correspondan.
Artículo 171.-Cuando dos a más personas hubiesen adquirido los mismos

derechos respecto a una misma obra, prevalecerá la autorización o cesión inscrita
en primer término, sin perjuicio del derecho de impugnación del registro.
Artículo 172.-Cuando el encargado del registro detecte que la oficina a su cargo ha

efectuado una inscripción por error, iniciará de oficio un procedimiento de
cancelación o corrección de la inscripción correspondiente, respetando la garantía
de audiencia de los posibles afectados.

Capítulo II
DE LAS RESERVAS DE DERECHOS AL USO EXCLUSIVO
Artículo 173.-La reserva de derechos es la facultad de usar y explotar en forma

exclusiva títulos, nombres, denominaciones, características físicas y psicológicas
distintivas, o características de operación originales aplicados, de acuerdo con su
naturaleza, a alguno de los siguientes géneros:
I. Publicaciones periódicas: Editadas en partes sucesivas con variedad de

contenido y que pretenden continuarse indefinidamente.
II. Difusiones periódicas: Emitidas en partes sucesivas, con variedad de

contenido y susceptibles de transmitirse.
III. Personajes humanos de caracterización, o ficticios o simbólicos.
IV. Personas o grupos dedicados a actividades artísticas.
V. Promociones publicitarias: Contemplan un mecanismo novedoso y sin

protección tendiente a promover y ofertar un bien o un servicio, con el incentivo
adicional de brindar la posibilidad al público en general de obtener otro bien o
servicio, en condiciones más favorables que en las que normalmente se encuentra
en el comercio; se exceptúa el caso de los anuncios comerciales.
Artículo 174.-El Instituto expedirá los certificados respectivos y hará la inscripción

para proteger las reservas de derechos a que se refiere el artículo anterior.
Artículo 175.-La protección que ampara el certificado a que se refiere el artículo

anterior, no comprenderá lo que no es materia de reserva de derechos, de
conformidad con el artículo 188 este ordenamiento, aun cuando forme parte del
registro respectivo.
Artículo 176.-Para el otorgamiento de las reservas de derechos, el Instituto tendrá

la facultad de verificar la forma en que el solicitante pretenda usar el título,
nombre, denominación o características objeto de reserva de derechos a fin de
evitar la posibilidad de confusión con otra previamente otorgada.
Artículo 177.-Los requisitos y condiciones que deban cubrirse para la obtención y

renovación de las reservas de derechos, así como para la realización de cualquier

otro trámite previsto en el presente capítulo, se establecerán en el

Reglamento de la presente Ley.
Artículo 178.-Cuando dos o más personas presenten a su nombre una solicitud de

reserva de derechos, salvo pacto en contrario se entenderá que todos serán
titulares por partes iguales.
Artículo 179.-Los títulos, nombres, denominaciones o características objeto de

reservas de derechos, deberán ser utilizados tal y como fueron otorgados;
cualquier variación en sus elementos será motivo de una nueva reserva.
Artículo 180.-El Instituto proporcionará a los titulares o sus representantes, o a

quien acredite tener interés jurídico, copias simples o certificadas de las
resoluciones que se emitan en cualquiera de los expedientes de reservas de
derechos otorgadas.
Artículo 181.-Los titulares de las reservas de derechos deberán notificar al Instituto

las transmisiones de los derechos que amparan los certificados correspondientes.
Artículo 182.-El Instituto realizará las anotaciones y, en su caso, expedirá las

constancias respectivas en los supuestos siguientes:
I. Cuando se declare la nulidad de una reserva.
II. Cuando proceda la cancelación de una reserva.
III. Cuando proceda la caducidad.
IV. En todos aquellos casos en que por mandamiento de autoridad competente

así se requiera.
Artículo 183.-Las reservas de derechos serán nulas cuando:
I. Sean iguales o semejantes en grado de confusión con otra previamente

otorgada o en trámite.
II. Hayan sido declarados con falsedad los datos que, de acuerdo con el
reglamento, sean esenciales para su otorgamiento.
III. Se demuestre tener un mejor derecho por un uso anterior, constante e

ininterrumpido en México, a la fecha del otorgamiento de la reserva.

IV. Se hayan otorgado en contravención a las disposiciones de este capítulo.
Artículo 184.-Procederá la cancelación de los actos emitidos por el Instituto, en los

expedientes de reservas de derechos cuando:
I. El solicitante hubiere actuado de mala fe en perjuicio de tercero, o con

violación a una obligación legal o contractual.
II. Se haya declarado la nulidad de una reserva.
III. Por contravenir lo dispuesto por el artículo 179 esta Ley, se cause confusión
con otra que se encuentre protegida.
IV. Sea solicitada por el titular de una reserva.
V. Sea ordenado mediante resolución firme de autoridad competente.
Artículo 185.-Las reservas de derechos caducarán cuando no se renueven en los

términos establecidos por el presente capítulo.
Artículo 186.-La declaración administrativa de nulidad, cancelación o caducidad se

podrá iniciar en cualquier tiempo, de oficio por el Instituto, a petición de parte, o del
Ministerio Público de la Federación cuando tenga algún interés la Federación. La
caducidad a la que se refiere el artículo anterior, no requerirá declaración
administrativa por parte del Instituto.
Artículo 187.-Los procedimientos de nulidad y cancelación previstos en este

capítulo, se substanciarán y resolverán de conformidad con las disposiciones que
para tal efecto se establezcan en el Reglamento de la presente Ley.
Artículo 188.-No son materia de reserva de derechos:
I. Los títulos, los nombres, las denominaciones, las características físicas o

psicológicas, o las características de operación que pretendan aplicarse a alguno
de los géneros a que se refiere el artículo 173 la presente Ley, cuando:
a) Por su identidad o semejanza gramatical, fonética, visual o conceptual

puedan inducir a error o confusión con una reserva de derechos previamente
otorgada o en trámite. No obstante lo establecido en el párrafo anterior, se podrán

obtener reservas de derechos iguales dentro del mismo género, cuando

sean solicitadas por el mismo titular.
b) Sean genéricos y pretendan utilizarse en forma aislada.
c) Ostenten o presuman el patrocinio de una sociedad, organización o
institución pública o privada, nacional o internacional, o de cualquier otra
organización reconocida oficialmente, sin la correspondiente autorización expresa.
d) Reproduzcan o imiten sin autorización, escudos, banderas, emblemas o
signos de cualquier país, estado, municipio o división política equivalente.
e) Incluyan el nombre, seudónimo o imagen de alguna persona determinada,
sin consentimiento expreso del interesado.
f) Sean iguales o semejantes en grado de confusión con otro que el Instituto
estime notoriamente conocido en México, salvo que el solicitante sea el titular del
derecho notoriamente conocido.
II. Los subtítulos.
III. Las características gráficas.
IV. Las leyendas, tradiciones o sucedidos que hayan llegado a individualizarse

o que sean generalmente conocidos bajo un nombre que les sea característico.
V. Las letras o los números aislados.
VI. La traducción a otros idiomas, la variación ortográfica caprichosa o la

construcción artificial de palabras no reservables.
VII. Los nombres de personas utilizados en forma aislada, excepto los que sean
solicitados para la protección de nombres artísticos, denominaciones de grupos
artísticos, personajes humanos de caracterización, o simbólicos o ficticios en cuyo
caso se estará a lo dispuesto en el inciso e) de la fracción I de este artículo.
VIII. Los nombres o denominaciones de países, ciudades, poblaciones o de

cualquier otra división territorial, política o geográfica, o sus gentilicios y
derivaciones, utilizados en forma aislada.
Artículo 189.-La vigencia del certificado de la reserva de derechos otorgada a

títulos de publicaciones o difusiones periódicas será de un año, contado a partir de
la fecha de su expedición. Para el caso de publicaciones periódicas, el certificado
correspondiente se expedirá con independencia de cualquier otro documento que
se exija para su circulación.

Artículo 190.-La vigencia del certificado de la reserva de derechos será de

cinco años contados a partir de la fecha de su expedición cuando se otorgue a:
I. Nombres y características físicas y psicológicas distintivas de personajes,

tanto humanos de caracterización como ficticios o simbólicos.
II. Nombres o denominaciones de personas o grupos dedicados a actividades

artísticas.
III. Denominaciones y características de operación originales de promociones

publicitarias.
Artículo 191.-Los plazos de protección que amparan los certificados de reserva de

derechos correspondientes, podrán ser renovados por periodos sucesivos iguales.
Se exceptúa de este supuesto a las promociones publicitarias, las que al término
de su vigencia pasaran a formar parte del dominio público. La renovación a que se
refiere el párrafo anterior, se otorgará previa comprobación fehaciente del uso de
la reserva de derechos, que el interesado presente al Instituto dentro del plazo
comprendido desde un mes antes, hasta un mes posterior al día del vencimiento
de la reserva de derechos correspondiente.
El Instituto podrá negar la renovación a que se refiere el presente artículo,

cuando de las constancias exhibidas por el interesado, se desprenda que los
títulos, nombres, denominaciones o características, objeto de la reserva de
derechos, no han sido utilizados tal y como fueron reservados.
Titulo IX
DE LA GESTIÓN COLECTIVA DE DERECHOS
Capítulo Único
DE LAS SOCIEDADES DE GESTIÓN COLECTIVA
Artículo 192.-Sociedad de gestión colectiva es la persona moral que, sin ánimo de

lucro, se constituye bajo el amparo de esta Ley con el objeto de proteger a autores
y titulares de derechos conexos tanto nacionales como extranjeros, así como
recaudar y entregar a los mismos las cantidades que por concepto de derechos de
autor o derechos conexos se generen a su favor. Los causahabientes de los
autores y de los titulares de derechos conexos, nacionales o extranjeros,
residentes en México podrán formar parte de sociedades de gestión colectiva. Las

sociedades a que se refieren los párrafos anteriores deberán constituirse

con la finalidad de ayuda mutua entre sus miembros y basarse en los principios de
colaboración, igualdad y equidad, así como funcionar con los lineamientos que
esta Ley establece y que los convierte en entidades de interés público.
Artículo 193.-Para poder operar como sociedad de gestión colectiva se requiere

autorización previa del Instituto, el que ordenará su publicación en el Diario Oficial
de la Federación.
Artículo 194.-La autorización podrá ser revocada por el Instituto si existiese

incumplimiento de las obligaciones que esta Ley establece para las sociedades de
gestión colectiva o si se pusiese de manifiesto un conflicto entre los propios socios
que dejara acéfala o sin dirigencia a la sociedad, de tal forma que se afecte el fin y
objeto de la misma en detrimento de los derechos de los asociados. En los
supuestos mencionados, deberá mediar un previo apercibimiento del Instituto, que
fijará un plazo no mayor a tres meses para subsanar o corregir los hechos
señalados.
Artículo 195.-Las personas legitimadas para formar parte de una sociedad de

gestión colectiva podrán optar libremente entre afiliarse a ella o no; asimismo,
podrán elegir entre ejercer sus derechos patrimoniales en forma individual, por
conducto de apoderado o a través de la sociedad. Las sociedades de gestión
colectiva no podrán intervenir en el cobro de regalías cuando los socios elijan
ejercer sus derechos en forma individual respecto de cualquier utilización de la
obra o bien hayan pactado mecanismos directos para dicho cobro.
Por el contrario, cuando los socios hayan dado mandato a las sociedades de
gestión colectiva, no podrán efectuar el cobro de las regalías por sí mismos, a
menos que lo revoquen. Las sociedades de gestión colectiva no podrán imponer
como obligatoria la gestión de todas las modalidades de explotación, ni la totalidad
de la obra o de producción futura.
Artículo 196.-En el caso de que los socios optaran por ejercer sus derechos
patrimoniales a través de apoderado, éste deberá ser persona física y deberá
contar con la autorización del Instituto. El poder otorgado a favor del apoderado no
será sustituible ni delegable.
Artículo 197.-Los miembros de una sociedad de gestión colectiva cuando opten

por que la sociedad sea la que realice los cobros a su nombre deberán otorgar a
ésta un poder general para pleitos y cobranzas.

Artículo 198.-No prescriben en favor de las sociedades de gestión colectiva

y en contra de los socios los derechos o las percepciones cobradas por ellas. En
el caso de percepciones o derechos para autores del extranjero se estará al
principio de la reciprocidad.
Artículo 199.- El Instituto otorgará las autorizaciones a que se refiere el artículo

193 concurren las siguientes condiciones:
I. Que los estatutos de la sociedad de gestión colectiva solicitante cumplan, a

juicio del Instituto, con los requisitos establecidos en esta Ley.
II. Que de los datos aportados y de la información que pueda allegarse el

Instituto, se desprenda que la sociedad de gestión colectiva solicitante reúne las
condiciones necesarias para asegurar la transparente y eficaz administración de
los derechos, cuya gestión le va a ser encomendada.
III. Que el funcionamiento de la sociedad de gestión colectiva favorezca los

intereses generales de la protección del derecho de autor, de los titulares de los
derechos patrimoniales y de los titulares de derechos conexos en el país.
Artículo 200.-Una vez autorizadas las sociedades de gestión colectiva por parte
del Instituto, estarán legitimadas en los términos que resulten de sus propios
estatutos para ejercer los derechos confiados a su gestión y hacerlos valer en toda
clase de procedimientos administrativos o judiciales. Las sociedades de gestión
colectiva están facultadas para presentar, ratificar o desistirse de demanda o
querella a nombre de sus socios, siempre que cuenten con poder general para
pleitos y cobranzas con cláusula especial para presentar querellas o desistirse de
ellas, expedido a su favor y que se encuentre inscrito en el Instituto, sin que sea
aplicable lo dispuesto por el artículo 120 del Código Federal de Procedimientos
Penales y sin perjuicio de que los autores y que los titulares de derechos
derivados puedan coadyuvar personalmente con la sociedad de gestión colectiva
que corresponda. En el caso de extranjeros residentes fuera de la República
Mexicana se estará a lo establecido en los convenios de reciprocidad respectivos.
Artículo 201.-Se deberán celebrar por escrito todos los actos, convenios y
contratos entre las sociedades de gestión colectiva y los autores, los titulares de
derechos patrimoniales o los titulares de derechos conexos, en su caso, así como
entre dichas sociedades y los usuarios de las obras, actuaciones, fonogramas,
videogramas o emisiones de sus socios, según corresponda.

Artículo 202.-Las sociedades de gestión colectiva tendrán las siguientes

finalidades:
I. Ejercer los derechos patrimoniales de sus miembros.
II. Tener en su domicilio, a disposición de los usuarios, los repertorios que

administre.
III. Negociar en los términos del mandato respectivo las licencias de uso de los
repertorios que administren con los usuarios, y celebrar los contratos respectivos.
IV. Supervisar el uso de los repertorios autorizados.
V. Recaudar para sus miembros las regalías provenientes de los derechos de

autor o derechos conexos que les correspondan, y entregárselas previa deducción
de los gastos de administración de la Sociedad, siempre que exista mandato
expreso.
VI. Recaudar y entregar las regalías que se generen en favor de los titulares de
derechos de autor o conexos extranjeros, por sí o a través de las sociedades de
gestión que los representen, siempre y cuando exista mandato expreso otorgado a
la sociedad de gestión mexicana y previa deducción de los gastos de
administración.
VII. Promover o realizar servicios de carácter asistencial en beneficio de sus

miembros y apoyar actividades de promoción de sus repertorios.
VIII. Recaudar donativos para ellas así como aceptar herencias y legados.
IX. Las demás que les correspondan de acuerdo con su naturaleza y que sean
compatibles con las y con la función de intermediarias de sus miembros con los
usuarios o ante las autoridades.
Artículo 203.-Son obligaciones de las sociedades de gestión colectiva:
I. Intervenir en la protección de los derechos morales de sus miembros.
II. Aceptar la administración de los derechos patrimoniales o derechos

conexos que les sean encomendados de acuerdo con su objeto o fines.

III. Inscribir su acta constitutiva y estatutos en el Registro Público del

Derecho de Autor, una vez que haya sido autorizado su funcionamiento, así como
las normas de recaudación y distribución, los contratos que celebren con usuarios
y los de representación que tengan con otras de la misma naturaleza, y las actas y
documentos mediante los cuales se designen los miembros de los organismos
directivos y de vigilancia, sus administradores y apoderados, todo ello dentro de
los treinta días siguientes a su aprobación, celebración, elección o nombramiento,
según corresponda.
IV. Dar trato igual a todos los miembros.
V. Dar trato igual a todos los usuarios.
VI. Negociar el monto de las regalías que corresponda pagar a los usuarios del
repertorio que administran y, en caso de no llegar a un acuerdo, proponer al
Instituto la adopción de una tarifa general presentando los elementos justificativos.
VII. Rendir a sus asociados, anualmente un informe desglosado de las

cantidades de cada uno de sus socios haya recibido y copia de las liquidaciones,
las cantidades que por su conducto se hubiesen enviado al extranjero, y las
cantidades que se encuentren en su poder, pendientes de ser entregadas a los
autores mexicanos o de ser enviadas a los autores extranjeros, explicando las
razones por las que se encuentren pendientes de ser enviadas. Dichos informes
deberán incluir la lista de los miembros de la sociedad y los votos que les
corresponden.
VIII. Entregar a los titulares de derechos patrimoniales de autor que representen,

copia de la documentación que sea base de la liquidación correspondiente. El
derecho a obtener la documentación comprobatoria de la liquidación es
irrenunciable.
IX. Liquidar las regalías recaudadas por su conducto, así como los intereses
generados por ellas, en un plazo no mayor de tres meses, contados a partir de la
fecha en que tales regalías hayan sido recibidas por la sociedad.
Artículo 204.-Son obligaciones de los administradores de la sociedad de gestión

colectiva:
I. Responsabilizarse del cumplimiento de las obligaciones de la sociedad a
que se refiere el artículo anterior.

II. Responder civil y penalmente por los actos realizados por ellos
durante su administración.
III. Entregar a los socios la copia de la documentación a que se refiere la

fracción VIII del artículo anterior.
IV. Proporcionar al Instituto y demás autoridades competentes la información y

documentación que se requiera a la sociedad, conforme a la Ley.
V. Apoyar las inspecciones que lleve a cabo el Instituto.
VI. Las demás a que se refieran esta Ley y los estatutos de la sociedad.
Artículo 205.-En los estatutos de las sociedades de gestión colectiva se hará

constar, por lo menos, lo siguiente:
I. La denominación.
II. El domicilio.
III. El objeto o fines.
IV. Las clases de titulares de derechos comprendidos en la gestión.
V. Las condiciones para la adquisición y pérdida de la calidad de socio.
VI. Los derechos y deberes de los socios.
VII. El régimen de voto:
a) Establecerá el mecanismo idóneo para evitar la sobre representación de los

miembros.
b) Invariablemente, para la exclusión de socios, el régimen de voto será el de
un voto por socio y el acuerdo deberá ser del 75% de los votos asistentes a la
Asamblea.
VIII. Los órganos de gobierno, de administración, y de vigilancia, de la sociedad

de gestión colectiva y su respectiva competencia, así como las normas relativas a
la convocatoria a las distintas asambleas, con la prohibición expresa de adoptar
acuerdos respecto de los asuntos que no figuren en el orden del día.

IX. El procedimiento de elección de los socios administradores. No se

podrá excluir a ningún socio de la posibilidad de fungir como administrador.
X. El patrimonio inicial y los recursos económicos previstos.
XI. El porcentaje del monto de recursos obtenidos por la sociedad, que se

destinará a:
a) La administración de la sociedad.
b) Los programas de seguridad social de la sociedad.
c) Promoción de obras de sus miembros.
XII. Las reglas a que han de someterse los sistemas de reparto de la

recaudación. Tales reglas se basarán en el principio de otorgar a los titulares de
los derechos patrimoniales o conexos que representen, una participación en las
regalías recaudadas que sea estrictamente proporcional a la utilización actual,
efectiva y comprobada de sus obras, actuaciones, fonogramas o emisiones.
Artículo 206.-Las reglas para las convocatorias y quórum de las asambleas se

deberán apegar a lo dispuesto por esta Ley y su reglamento y por la Ley General
de Sociedades Mercantiles.
Artículo 207.- Previa denuncia de por lo menos el diez por ciento de los miembros
el Instituto exigirá a las sociedades de gestión colectiva, cualquier tipo de
información y ordenará inspecciones y auditorías para verificar que cumplan con la
presente Ley y sus disposiciones reglamentarias.
Titulo X
DEL INSTITUTO NACIONAL DEL DERECHO DE AUTOR
Capítulo Único
Artículo 208.-El Instituto Nacional del Derecho de Autor, autoridad administrativa

en materia de derechos de autor y derechos conexos, es un órgano
desconcentrado de la Secretaría de Educación Pública.
Artículo 209.-Son funciones del Instituto:
I. Proteger y fomentar el derecho de autor.

II. Promover la creación de obras literarias y artísticas.
III. Llevar el Registro Público del Derecho de Autor.
IV. Mantener actualizado su acervo histórico.
V. Promover la cooperación internacional y el intercambio con instituciones

encargadas del registro y protección del derecho de autor y derechos conexos.
Artículo 210.-El Instituto tiene facultades para:
I. Realizar investigaciones respecto de presuntas infracciones administrativas.
II. Solicitar a las autoridades competentes la práctica de visitas de inspección.
III. Ordenar y ejecutar los actos provisionales para prevenir o terminar con la
violación al derecho de autor y derechos conexos.
IV. Imponer las sanciones administrativas que sean procedentes.
V. Las demás que le correspondan en los términos de la presente Ley, sus

reglamentos y demás disposiciones aplicables.
Artículo 211.-El Instituto estará a cargo de un Director General que será nombrado
y removido por el Ejecutivo Federal, por conducto del Secretario de Educación
Pública, con las facultades previstas en la presente Ley, en sus reglamentos y
demás disposiciones aplicables.
Artículo 212.-Las tarifas para el pago de regalías serán propuestas por el Instituto
a solicitud expresa de las sociedades de gestión colectiva o de los usuarios
respectivos. El Instituto analizará la solicitud tomando en consideración los usos y
costumbres en el ramo de que se trate y las tarifas aplicables en otros países por
el mismo concepto. Si el Instituto está en principio de acuerdo con la tarifa cuya
expedición se le solicita, procederá a publicarla en calidad de proyecto en el Diario
Oficial de la Federación y otorgará a los interesados un plazo de 30 días para
formular observaciones. Si no hay oposición, el Instituto procederá a proponer la
tarifa y a su publicación como definitiva en el Diario Oficial de la Federación. Si
hay oposición, el Instituto hará un segundo análisis y propondrá la tarifa que a su
juicio proceda, a través de su publicación en el Diario Oficial de la Federación.

Titulo XI
DE LOS PROCEDIMIENTOS
Capítulo I
DEL PROCEDIMIENTO ANTE AUTORIDADES JUDICIALES
Artículo 213.-Los Tribunales Federales conocerán de las controversias que se

susciten con motivo de la aplicación de esta Ley, pero cuando dichas
controversias sólo afecten intereses particulares, podrán conocer de ellas, a
elección del actor, los tribunales de los Estados y del Distrito Federal. Las
acciones civiles que se ejerciten se fundarán, tramitarán y resolverán conforme a
lo establecido en esta Ley y en sus reglamentos, siendo supletorio el Código
Federal de Procedimientos Civiles ante Tribunales Federales y la legislación
común ante los Tribunales del orden común.
Artículo 214.-En todo juicio en que se impugne una constancia, anotación o

inscripción en el registro, será parte el Instituto y sólo podrán conocer de él los
tribunales federales.
Artículo 215.-Corresponde conocer a los Tribunales de la Federación de los delitos

relacionados con el derecho de autor previstos en el Título Vigésimo Sexto del
Código Penal para el Distrito Federal en
Materia de Fuero Común y para toda la República en Materia de Fuero Federal.
Artículo 216.-Las autoridades judiciales darán a conocer al Instituto la iniciación de

cualquier juicio en materia de derechos de autor.
Asimismo, se enviará al Instituto una copia autorizada de todas las resoluciones
firmes que en cualquier forma modifiquen, graven, extingan o confirmen los
derechos de autor sobre una obra u obras determinadas. En vista de estos
documentos se harán en el registro las anotaciones provisionales o definitivas que
correspondan.
Artículo 216 bis.- La reparación del daño material y/o moral así como la
indemnización por daños y perjuicios por violación a los derechos que confiere
esta Ley en ningún caso será inferior al cuarenta por ciento del precio de venta al
público del producto original o de la prestación original de cualquier tipo de
servicios que impliquen violación a alguno o algunos de los derechos tutelados por
esta Ley.

El juez con audiencia de peritos fijará el importe de la reparación del

daño o de la indemnización por daños y perjuicios en aquellos casos en que no
sea posible su determinación conforme al párrafo anterior.
Para los efectos de este Artículo se entiende por daño moral el que
ocasione la violación a cualquiera de los derechos contemplados en las
Fracciones I, II, III, IV y VI del Artículo 21 de esta Ley.
Capítulo II
DEL PROCEDIMIENTO DE AVENENCIA
Artículo 217.-Las personas que consideren que son afectados en alguno de los
derechos protegidos por esta Ley, podrán optar entre hacer valer las acciones
judiciales que les correspondan o sujetarse al procedimiento de avenencia. El
procedimiento administrativo de avenencia es el que se substancia ante el
Instituto, a petición de alguna de las partes para dirimir de manera amigable un
conflicto surgido con motivo de la interpretación o aplicación de esta Ley.
Artículo 218.- El procedimiento administrativo de avenencia lo llevará a cabo el
Instituto conforme a lo siguiente:
I. Se iniciará con la queja, que por escrito presente ante el Instituto quien se
considere afectado en sus derechos de autor, derechos conexos y otros derechos
tutelados por la presente Ley.
II. Con la queja y sus anexos se dará vista a la parte en contra de la que se
interpone, para que la conteste dentro de los diez días siguientes a la notificación.
III. Se citará a las partes a una junta de avenencia, apercibiéndolas que de no

asistir se les impondrá una multa de cien veces el salario mínimo general diario
vigente en el Distrito Federal. Dicha junta se llevará a cabo dentro de los veinte
días siguientes a la presentación de la queja.
IV. En la junta respectiva el Instituto tratará de avenir a las partes para que
lleguen a un arreglo. De aceptarlo ambas partes, la junta de avenencia puede
diferirse las veces que sean necesarias a fin de lograr la conciliación. El convenio
firmado por las partes y el Instituto tendrá el carácter de cosa juzgada y título
ejecutivo.

V. Durante la junta de avenencia, el Instituto no podrá hacer

determinación alguna sobre el fondo del asunto, pero si podrá participar
activamente en la conciliación.
VI. En caso de no lograrse la avenencia, el Instituto exhortará a las partes para

que se acojan al arbitraje establecido en el Capítulo III de este Título; Las
actuaciones dentro de este procedimiento tendrán el carácter de confidenciales y,
por lo tanto, las constancias de las mismas sólo serán enteradas a las partes del
conflicto o a las autoridades competentes que las soliciten.
Capítulo III
DEL ARBITRAJE
Artículo 219.-En el caso de que surja alguna controversia sobre los derechos
protegidos por esta Ley, las partes podrán someterse a un procedimiento de
arbitraje, el cual estará regulado conforme a lo establecido en este Capítulo, sus
disposiciones reglamentarias y, de manera supletoria, las del Código de Comercio.
Artículo 220.-Las partes podrán acordar someterse a un procedimiento arbitral por

medio de:
I. Cláusula Compromisoria: El acuerdo de arbitraje incluido en un contrato
celebrado con obras protegidas por esta Ley o en un acuerdo independiente
referido a todas o ciertas controversias que puedan surgir en el futuro entre ellos.
II. Compromiso Arbitral: El acuerdo de someterse al procedimiento arbitral

cuando todas o ciertas controversias ya hayan surgido entre las partes al
momento de su firma. Tanto la cláusula compromisoria como el compromiso
arbitral deben constar invariablemente por escrito.
Artículo 221.-El Instituto publicará en el mes de enero de cada año una lista de las
personas autorizadas para fungir como árbitros.
Artículo 222.-El grupo arbitral se formará de la siguiente manera:

I. Cada una de las parte elegirá a un árbitro de la lista que proporcionen el
Instituto.
II. Cuando sean más de dos partes las que concurran, se deberán poner de
acuerdo entre ellas para la designación de los árbitros, en caso de que no haya
acuerdo, el Instituto designará a los dos árbitros.

III. Entre los dos árbitros designados por las partes elegirán, de la propia
lista al presidente del grupo.
Artículo 223.-Para ser designado árbitro se necesita:
I. Ser Licenciado en Derecho.
II. Gozar de reconocido prestigio y honorabilidad.
III. No haber prestado durante los cinco años anteriores sus servicios en
alguna sociedad de gestión colectiva.
IV. No haber sido abogado patrono de alguna de las partes.
V. No haber sido sentenciado por delito doloso grave.
VI. No ser pariente consanguíneo o por afinidad de alguna de las partes hasta
el cuarto grado, o de los directivos en caso de tratarse de persona moral.
VII. No ser servidor público.
Artículo 224.-El plazo máximo del arbitraje será de 60 días, que comenzará a
computarse a partir del día siguiente a la fecha señalada en el documento que
contenga la aceptación de los árbitros.
Artículo 225.- El procedimiento arbitral podrá concluir con el laudo que lo dé por
terminado o por acuerdo entre las partes antes de dictarse éste.
Artículo 226.-Los laudos del grupo arbitral:
I. Se dictarán por escrito.
II. Serán definitivos, inapelables y obligatorios para las partes.
III. Deberán estar fundados y motivados.
IV. Tendrán el carácter de cosa juzgada y título ejecutivo.
Artículo 227.-Dentro de los cinco días siguientes a la notificación del laudo,

cualquiera de las partes podrá requerir del grupo arbitral, notificando por escrito al
Instituto y a la otra parte, que aclare los puntos resolutivos del mimo, rectifique

cualquier error de cálculo, tipográfico o cualquier otro de naturaleza similar,

siempre y cuando no se modifique el sentido del mismo.
Artículo 228.-Los gastos que se originen con motivo del procedimiento arbitral
serán a cargo de las partes. El pago de honorarios del grupo arbitral será cubierto
conforme al arancel que expida anualmente el Instituto.
Titulo XII
DE LOS PROCEDIMIENTOS ADMINISTRATIVOS
Capítulo I
DE LAS INFRACCIONES EN MATERIA DE DERECHOS DE AUTOR
Artículo 229.-Son infracciones en materia de derecho de autor:
I. Celebrar el editor, empresario, productor, empleador, organismo de

radiodifusión o licenciatario un contrato que tenga por objeto la transmisión de
derechos de autor en contravención a lo dispuesto por la presente Ley.
II. Infringir el licenciatario los términos de la licencia obligatoria que se hubiese

declarado conforme al artículo 146 la presente Ley.
III. Ostentarse como sociedad de gestión colectiva sin haber obtenido el

registro correspondiente ante el Instituto.
IV. No proporcionar, sin causa justificada, al Instituto, siendo administrador de

una sociedad de gestión colectiva los informes y documentos a que se refieren los
artículos 204 fracción IV y 207 de la presente Ley.
V. No insertar en una obra publicada las menciones a que se refiere el artículo

17 de la presente Ley.
VI. Omitir o insertar con falsedad en una edición los datos a que se refiere el
artículo 53 de la presente Ley.
VII. Omitir o insertar con falsedad las menciones a que se refiere el artículo 54
de la presente Ley.

VIII. No insertar en un fonograma las menciones a que se refiere el

artículo 132 de la presente Ley.
IX. Publicar una obra, estando autorizado para ello, sin mencionar en los
ejemplares de ella el nombre del autor, traductor, compilador, adaptador o
arreglista.
X. Publicar una obra, estando autorizado para ello, con menoscabo de la

reputación del autor como tal y, en su caso, del traductor, compilador, arreglista o
adaptador.
XI. Publicar antes que la Federación, los Estados o los Municipios y sin
autorización las obras hechas en el servicio oficial.
XII. Emplear dolosamente en una obra un título que induzca a confusión con
otra publicada con anterioridad.
XIII. Fijar, representar, publicar, efectuar alguna comunicación o utilizar en

cualquier forma una obra literaria y artística, protegida conforme al capítulo III, del
Título VII, de la presente Ley, sin mencionar la comunidad o etnia, o en su caso la
región de la República Mexicana de la que es propia.
XIV. Las demás que se deriven de la interpretación de la presente Ley y sus

reglamentos.
Artículo 230.-Las infracciones en materia de derechos de autor serán sancionadas

por el Instituto con arreglo a lo dispuesto por la Ley Federal de Procedimiento
Administrativo con multa:
I. De cinco mil hasta quince mil días de salario mínimo en los casos previstos
en las fracciones I, II, III, IV, XI, XII, XIII y XIV del artículo anterior.
II. De mil hasta cinco mil días de salario mínimo en los demás casos previstos
en el artículo anterior.
Se aplicará multa adicional de hasta quinientos días de salario mínimo por día, a
quien persista en la infracción.

Capítulo II
DE LAS INFRACCIONES EN MATERIA DE COMERCIO
Artículo 231.-Constituyen infracciones en materia de comercio las siguientes

conductas cuando sean realizadas con fines de lucro directo o indirecto:
I. Comunicar o utilizar públicamente una obra protegida por cualquier medio, y

de cualquier forma sin la autorización previa y expresa del autor, de sus legítimos
herederos o del titular del derecho patrimonial de autor.
II. Utilizar la imagen de una persona sin su autorización o la de sus

causahabientes.
III. Producir, reproducir, almacenar, distribuir, transportar o comercializar

copias de obras, fonogramas, videogramas o libros, protegidos por los derechos
de autor o por los derechos conexos, sin la autorización de los respectivos titulares
en los términos de esta ley.
IV. Ofrecer en venta, almacenar, transportar o poner en circulación obras

protegidas por esta Ley que hayan sido deformadas, modificadas o mutiladas sin
autorización del titular del derecho de autor.
V. Importar, vender, arrendar o realizar cualquier acto que permita tener un

dispositivo o sistema cuya finalidad sea desactivar los dispositivos electrónicos de
protección de un programa de computación.
VI. Retransmitir, fijar, reproducir y difundir al público emisiones de organismos

de radiodifusión y sin la autorización debida.
VII. Usar, reproducir o explotar una reserva de derechos protegida o un

programa de cómputo sin el consentimiento del titular.
VIII. Usar o explotar un nombre, título, denominación, características físicas o

psicológicas, o características de operación de tal forma que induzcan a error o
confusión con una reserva de derechos protegida.
IX. Utilizar las obras literarias y artísticas protegidas por el capítulo III, del Título
VII de la presente Ley en contravención a lo dispuesto por el artículo 158 de la
misma.

X. Las demás infracciones a las disposiciones de la Ley que impliquen

conducta a escala comercial o industrial relacionada con obras protegidas por esta
Ley.
Artículo 232.-Las infracciones en materia de comercio, previstos en la presente

Ley serán sancionadas por el Instituto Mexicano de la Propiedad Industrial con
multa:
I. De cinco mil hasta diez mil días de salario mínimo en los casos previstos en
las fracciones I, III, IV, V, VII, VIII y IX del artículo anterior.
II. De mil hasta cinco mil días de salario mínimo en los casos previstos en las
fracciones II y VI del artículo anterior.
III. De quinientos hasta mil días de salario mínimo en los demás casos a que
se refiere la fracción X del artículo anterior.
Se aplicará multa adicional de hasta quinientos días de salario mínimo

general vigente por día, a quien persista en la infracción.
Artículo 233.-Si el infractor fuese un editor, organismo de radiodifusión, o cualquier

persona física o moral que explote obras a escala comercial, la multa podrá
incrementarse hasta en un cincuenta por ciento respecto de las cantidades
previstas en el artículo anterior.
Artículo 234.-El Instituto Mexicano de la Propiedad Industrial sancionará las

infracciones materia de comercio con arreglo al procedimiento y las formalidades
previstas en los Títulos Sexto y Séptimo de la Ley de la Propiedad Industrial. El
Instituto Mexicano de la Propiedad Industrial podrá adoptar las medidas
precautorias previstas en la Ley de Propiedad Industrial.
Para tal efecto, el Instituto Mexicano de la Propiedad Industrial, tendrá las

facultades de realizar investigaciones; ordenar y practicar visitas de inspección;
requerir información y datos.
Artículo 235.-En relación con las infracciones en materia de comercio, el Instituto

Mexicano de la Propiedad Industrial queda facultado para emitir una resolución de
suspensión de la libre circulación de mercancías de procedencia extranjera en
frontera, en los términos de lo dispuesto por la Ley Aduanera.

Artículo 236.-Para la aplicación de las sanciones a que se refiere este Título

se entenderá como salario mínimo el salario mínimo general vigente en el Distrito
Federal en la fecha de la comisión de la infracción.
Capítulo III
DE LA IMPUGNACIÓN ADMINISTRATIVA
Artículo 237.-Los afectados por los actos y resoluciones emitidos por el Instituto
que pongan fin a un procedimiento administrativo, a una instancia o resuelvan un
expediente, podrán interponer recurso de revisión en los términos de la Ley
Federal del Procedimiento Administrativo.
Artículo 238.-Los interesados afectados por los actos y resoluciones emitidos por
el Instituto Mexicano de la Propiedad Industrial por las infracciones en materia de
comercio que pongan fin a un procedimiento administrativo, a una instancia o
resuelvan un expediente, podrán interponer los medios de defensa establecidos
en la Ley de la Propiedad Industrial.
8.1.3.1 DERECHOS MORALES
Los derechos morales en el campo del derecho de autor incluyen dos

aspectos específicos, el derecho al reconocimiento de la paternidad de la obra
(autoría) y el derecho de un autor a preservar la integridad de la obra, es decir, a
negarse a la realización de modificaciones u obras derivadas de la misma.
El reconocimiento de los derechos morales apunta esencialmente a la idea

de una supuesta conexión entre el autor y su obra, a la reputación del autor y al
derecho inalienable de este a disponer de la obra en términos de reconocimiento
así como de integridad. La infracción más común a los derechos morales es el
plagio.
1) Independientemente de los derechos patrimoniales del autor, e incluso después

de la cesión de estos derechos, el autor conservará el derecho de reivindicar la
paternidad de la obra y de oponerse a cualquier deformación, mutilación u otra
modificación de la misma o a cualquier atentado a la misma que cause perjuicio a
su honor o a su reputación.
2) Los derechos reconocidos al autor en virtud del párrafo 1) serán mantenidos

después de su muerte, por lo menos hasta la extinción de sus derechos
patrimoniales, y ejercidos por las personas o instituciones a las que la legislación

nacional del país en que se reclame la protección reconozca derechos. Sin

embargo, los países cuya legislación en vigor en el momento de la ratificación de
la presente Acta o de la adhesión a la misma, no contenga disposiciones relativas
a la protección después de la muerte del autor de todos los derechos reconocidos
en virtud del párrafo 1) anterior, tienen la facultad de establecer que alguno o
algunos de esos derechos no serán mantenidos después de la muerte del autor.
8.1.3.2 DERECHOS PATRIMONIALES
El software, en tanto que es un bien, está sujeto a las reglas del derecho
civil y, en tanto que es intangible, sujeto a las reglas de propiedad intelectual. No
obstante, la actividad humana de desarrollarlo y otras relacionadas, como lo son
su comercialización, implementación, integración o mantenimiento, están o
pueden estar sujetas a una multiplicidad de reglas más, como lo son las del
derecho mercantil, fiscal, de la propiedad industrial y de la protección al
consumidor. Asimismo, en tanto más amplia y compleja sea una organización
dedicada al desarrollo de software, la aplicación de reglas adicionales se hace
evidente, tales como las del derecho laboral y societario.
La protección legal que se le otorga al software varía significativamente de

país a país, dependiendo de cómo se perciba, el régimen legal aplicable, e incluso
su historia y cultura económica. Por ejemplo, en Asia el desarrollo de software se
percibe como una industria manufacturera, en donde los desarrolladores son
fabricantes y el software un bien de producción que juega un rol dentro de los
procesos de otras industrias. En Norteamérica se percibe una industria, como una
actividad creativa, pero con fines meramente económicos. De ahí que la
protección otorgada por el Copyright se limite precisamente al derecho de prohibir
o autorizar su reproducción.
En México, al igual que en Europa, donde nuestro régimen legal tiene como
base al llamado Civil Law o Derecho Romano-Germánico, el desarrollo de
software es considerado como un arte y los programas en sí mismos son obras
que merecen ser protegidas por el llamado Droit d‘ Auteur o Derecho de Autor, el
cual no se limita únicamente al derecho de prohibir o autorizar su reproducción,
sino que otorga al creador de una obra la protección al vínculo que lo une con su
creación intelectual, tanto desde una perspectiva personal como real, toda vez que
protege su autoría y sus derechos de propiedad sobre el mismo. Es por ello que
nuestra legislación protege tanto los derechos patrimoniales como morales de los
desarrolladores de software.

El derecho patrimonial o económico es el que el autor tiene para

explotar de forma exclusiva su software o de permitir a otros explotarlo (copyright).
Es decir, de autorizar o prohibir su reproducción, publicación o transmisión en
cualquier medio (papel, CD, Internet). El autor de un software puede transmitir
este derecho sobre su obra sin limitación alguna. Por su parte, el derecho moral es
el derecho que el autor tiene de decidir sobre si ha de divulgar o no su obra y la
forma de hacerlo, así como de exigir su reconocimiento como autor de la misma,
de modificarla y de oponerse a cualquier modificación, deformación o mutilación.
En este caso, este derecho es irrenunciable e intransferible.
Cabe señalar que la protección legal es inmediata, sin necesidad de registro

alguno, desde el momento en que la obra se fija en un soporte material, por
ejemplo, en un papel o en un archivo electrónico. El registro de un programa de
cómputo ante el Instituto Nacional del Derecho de Autor es meramente
declarativo, más no constitutivo de derechos, por lo que su utilidad principal es
como medio de prueba.
CONSIDERACIONES JURÍDICAS.
Siendo el desarrollo de software una actividad que nuestros legisladores

optaron por regular como un arte, no como una ciencia y mucho menos como una
industria, los empresarios mexicanos que buscan expandir el desarrollo de
software bajo un esquema de negocios deben tomar en cuenta no sólo este
enfoque regulatorio, sino muchas otras consideraciones jurídicas más.
Antes de constituirse como entidad legal, el empresario mexicano debe

definir el core business de su empresa y su mercado. Decidir desarrollar software
a la medida o software empaquetado, o prestar servicios de integración o
implementación de software, tiene una incidencia directa en el tipo legal más
adecuado bajo el cual debe constituir su empresa. No pocas veces ha sucedido
que por esta falta de enfoque se elija, por ejemplo, constituir una sociedad
anónima en vez de una sociedad civil, sujetándose así, sin ninguna necesidad, a
un régimen fiscal mucho más estricto.
Asimismo, por muy pequeña que parezca su empresa en un inicio, la

integración de la definición del core business con la visión de crecimiento que se
tenga a mediano o largo plazo, deben ir de la mano con el establecimiento del
objeto social de la empresa y la estructura corporativa idónea. En el mejor de los
casos, una falta de previsión en cualquiera de estos sentidos puede implicar
gastos innecesarios en modificaciones a los estatutos de su empresa o en su
representación legal; pero en el peor de ellos, podría impedir la inclusión de

nuevos inversionistas en el momento y lugar adecuados, dejando pasar así

valiosas oportunidades de crecimiento.
Otra consideración de vital importancia es la aplicabilidad de legislación

especial, como es el caso de la laboral. Hay que recordar que esta regulación es
de orden público y en todo caso, en situación de conflicto, la carga de la prueba la
tiene el empleador. Por lo anterior, es muy importante que queden bien
documentadas todas las obligaciones que los empleados de una empresa
dedicada al desarrollo de software tienen, tanto los desarrolladores, como el
personal administrativo. Hay que tener en mente que la protección mínima que la
ley otorga a los desarrolladores de software como empresarios es la presunción
de que, salvo pacto en contrario, los derechos patrimoniales del software
desarrollado por el empleado —dentro de las funciones de su cargo y bajo
instrucciones del empleador únicamente—, pertenecen a este último. Por lo
anterior, esta protección mínima debe complementarse con disposiciones
contractuales explícitas en materia de renuncia de derechos y secretos
industriales, mediante sólidos contratos laborales y cláusulas de confidencialidad.
No hay que olvidar que la protección legal otorgada por la legislación en

materia de derechos de autor se restringe a la protección de la obra tal cual es
fijada sobre el soporte material (código fuente y código objeto), no a la idea. Por lo
que debe también considerarse la protección adicional de elementos no visibles,
tales como la estructura, organización, secuencia, interfaces (el llamado look &
feel de un programa), así como las bases de datos y contenidos relacionados. De
esta forma, en la manera de lo posible pueden tenerse maneras efectivas de
combatir prácticas de clean room de posibles competidores.
Finalmente, las nuevas formas de comercialización y distribución merecen

una atención legal especial. Por su naturaleza, la distribución y comercialización
de software a través de medios electrónicos, como Internet, no sólo es
conveniente, sino eficiente. En estos casos, no deben considerarse únicamente
los términos y condiciones de la licencia de uso de los programas de cómputo así
distribuidos, sino la forma y sustancia de la contratación electrónica para fines de
validez y como medio de prueba. Asimismo, hay que recordar que los usuarios
finales son consumidores y están amparados bajo una regulación especial y
favorable en cuanto a contratación de bienes y servicios se refiere.
8.2 INSTITUTO NACIONAL DEL DERECHO DE AUTOR (INDA-AUTOR).
Dominada desde hace más de una década por el ensamble de equipo para
cómputo y las redes de telecomunicaciones, televisores y teléfonos celulares, la

manufactura high-tech ha sido una de las joyas de la corona del sector

exportador de México.
Firmas como LG, Samsung, Sony, así como Jabil Electronics, Sanmina,
Flextronics, Elcoq y Hon Hai son parte de un sector que exportó 12,000 millones
de dólares en 2008 y este año podría facturar 5% más. Nada mal si se considera
que el PIB caería hasta -9%.
A diferencia de la debacle automotriz global, con cierres de líneas de

producción y de plantas de autopartes desde 2007 (a un costo de miles de plazas
laborales), la electrónica se ha mantenido, con altibajos y cierres en ciudades
como Reynosa, Hermosillo y la propia Guadalajara, pero no a un ritmo tan
dramático. Además, entró en vigor algo que se venía gestando desde hace por lo
menos cinco años: el cambio de vocación en el cluster tapatío de la electrónica,
con más personal dedicado a servicios que al ensamble propiamente.
―Sí padecimos el cierre de una planta de Hitachi, pero muchos de los 5,000
empleados se pudieron incorporar con otros fabricantes y sectores nuevos, como
el del software, los servicios y nichos como la aeronáutica y la biomédica‖, dice
Jacobo González, director de Promoción a la Inversión de la Secretaría de
Promoción Económica (Seproe) de Jalisco. México 2.0
Parte del equipo de GlobalVantage ocupa algunas de las salas del Parque
de Tecnología del ITESO, ubicado en un frío edificio de cemento a un costado del
campus de la Universidad Jesuita de Guadalajara.
En medio de la efervescencia de unos 80 empleados de una docena de

firmas del Programa de Gestión de Innovación y Tecnología, Gisel Hernández,
gerente de Incubación, dice que hay una inquietud muy grande que lleva a
egresados del ITESO a montar empresas de software y servicios.
―La vinculación de empresas, gobierno y universidades está generando una

idea de que podemos competir con India y otros mercados globales emergentes
del software, como Rusia y Filipinas; ciertamente, nos va mejor que a Brasil y
Argentina‖, dice Hernández.
Este sentir lo confirman estudios de consultoras en el ramo que ubican a

México como décimo lugar en el índice global de acceso al mercado de las TI
(dice la consultora en gestión ATKearney); o como el primer mercado en América
Latina en ambiente de negocios para esta industria, así como poseedor de la

novena reserva mundial de capital humano para TI (según McKinsey, una

empresa de consultoría de negocios).
Por su parte, Gartner, una compañía que analiza el mercado de bienes y

servicios tecnológicos, dice que México es uno de los principales destinos globales
de servicios y que desde 2004 el país es el cuarto más buscado para el
outsourcing.
En encuestas con empresas de Estados Unidos, el principal comprador de

este tipo de aplicaciones, Gartner reporta que México es visto como el segundo
mercado al que firmas gringas considerarían como destino de su inversión en caso
de buscar proveedores de servicios de software.
―Vemos un gran potencial en este país‖, dice Donald Feinberg,

vicepresidente de Investigación de Gartner durante una charla en un foro de
tecnología en la Ciudad de México.
―Y esto no es en cuanto al número de profesionales y personal técnico o

firmas proveedoras, pues China o India son 10 veces más grandes‖, dice
Feinberg. ―Pero sí en lo que vemos por la calidad del trabajo y el costo total de los
proyectos‖.
8.2.1 DEFINICIÓN
Es una institución que salvaguarda los derechos autorales, promueve su

conocimiento en los diversos sectores de la sociedad, fomenta la creatividad y el
desarrollo cultural e impulsa la cooperación internacional y el intercambio con
instituciones encargadas del registro y protección del derecho de autor.
Como hacer tramites en el INDAUTOR.
En el caso de proyectos editoriales externos a la UNAM, los trámites

pueden realizarse de manera personal ante el Instituto Nacional del Derecho de
Autor (INDAUTOR), tanto la reserva de derechos al uso exclusivo del título, como
los registros ISBN e ISSN. El registro de obras y la inscripción de instrumentos,
como convenios y contratos, deben hacerse en el Registro Público del Derecho de
Autor del INDAUTOR.
Para realizar un trámite es necesario anexar a las formas de datos del

INDAUTOR, la información o los documentos correspondientes, así como los
pagos al Servicio de Administración Tributaria (SAT), en su caso, señalados por la

Ley General de Derechos, de la misma manera como se presentan en la

Dirección General de Asuntos Jurídicos. Las formas, así como información
relacionada, pueden localizarse en la página web ubicada en:
http://www.sep.gob.mx/wb/sep1/sep1_INDAUTOR.
Una gran ventaja que ofrece el sitio web mencionado es que las formas
pueden seleccionarse de acuerdo al tipo de trámite e imprimirse, con el fin de
agregar los datos correspondientes al titular para realizar el pago de derechos. Los
pagos al SAT deben realizarse ante una sucursal bancaria, por medio de la ―Hoja
de Ayuda para el pago en Ventanilla Bancaria‖, cuyu ejemplo se encuentran en la
pagina http://www.sep.gob.mx/work/resources/LocalContent/35798/15/Reg1.pdf
8.2.2 UBICACIÓN DE INDA-AUTOR
Esta institución se encuentra ubicada en la calle de Puebla 143 en la

colonia Roma, delegación Cuauhtémoc, C. P. 06600, México, D.F.
8.3 DIRECCION GENERAL DE ASUNTOS JURIDICOS DE LA UNAM (DGAJ)
Parte su labor y actividad es resolver los distintos conflictos entre los

diferentes individuos que se relacionan en sociedad.
8.3.1 DEFINICION
―Coordinación General de Asuntos Jurídicos y Derechos Humanos provee

asesoría y consultoría jurídica en general, así como la defensa de los intereses
jurídicos y patrimoniales de la Secretaría de Salud y del Sector coordinado por
ésta, a su petición.‖
8.3.2 RELACION CON EL INDA-AUTOR
La reserva de derechos al uso exclusivo del título, es la facultad que se

tiene para que el título empleado en una publicación periódica (gacetas, revistas,
boletines, catálogos o folletos); una difusión periódica (programas de radio o
televisión), o una definición vía red de cómputo (como red UNAM e Internet), no
sea utilizado en ninguna otra publicación o difusión, de acuerdo con el artículo 173
de la Ley Federal del Derecho de Autor.
Cabe señalar que con esta reserva también se tiene el derecho de explotar,
de manera exclusiva, nombres y características de personajes; nombres o

denominaciones de personas o grupos dedicados a actividades artísticas, y

nombres y características de operación de promociones publicitarias.
La UNAM aprovecha la reserva de derechos al uso exclusivo del título en

los campos de la docencia, la investigación, la divulgación del conocimiento y la
ciencia, así como en la promoción y la difusión de la cultura. Ésta consta en un
certificado que expide el Instituto Nacional del Derecho de Autor, a solicitud de la
Dirección General de Asuntos Jurídicos, con el que se otorga protección jurídica al
uso exclusivo, precisamente, del título de sus publicaciones y difusiones
periódicas, no así al contenido de las mismas.
Para las publicaciones o difusiones periódicas, la reserva tiene una vigencia

de un año, mientras que para los nombres y características físicas y psicológicas
de personajes; nombres o denominaciones de personas o grupos artísticos, y las
denominaciones y características de promociones publicitarias, esta vigencia es
de cinco años. La reserva puede ser renovada cada año, a excepción de las
promociones publicitarias, que al término de los cinco años de vigencia del
certificado, pasan a formar parte del dominio público.
Así, la reserva de derechos al uso exclusivo del título comprende tres

etapas para su gestión ante el Instituto Nacional del Derecho de Autor, a solicitud
de la Dirección General de Asuntos Jurídicos:
1. Análisis y búsqueda de antecedentes de títulos reservados. Para asegurar

la exclusividad del título que se quiere utilizar, el INDAUTOR hace un estudio
acerca de la no existencia de un título igual o similar que cause alguna confusión.
Si después de la búsqueda y el análisis de dichos antecedentes no se localiza un
título igual o similar que cause confusión, el INDAUTOR expide un dictamen
favorable a la Universidad;
2. Expedición del certificado. El dictamen favorable se presenta junto con la
solicitud de reserva de derechos al uso exclusivo del título, y si ésta cumple con
todos los requisitos que estipula la LFDA, el INDAUTOR expide el certificado de
reserva de derechos al uso exclusivo del título solicitado, y
3. Renovación de la reserva. Una vez transcurridos los plazos de protección
de los títulos, de uno o cinco años, según corresponda, las dependencias editoras
deben solicitar la renovación de la reserva de derechos al uso exclusivo del título,
para lo cual deberán exhibir el último ejemplar de la publicación editada dentro del
periodo que se comprueba. Para solicitar la renovación, es indispensable que el
título siempre sea utilizado como aparece en el certificado de la reserva, en la
misma forma y tamaño.

Para la realización de los trámites ante el INDAUTOR, es necesario que las

dependencias editoras envíen a la DGAJ lo siguiente:
1. Análisis y búsqueda de antecedentes de títulos reservados. Oficio firmado

por el titular de la dependencia, proporcionando el título que se pretende utilizar;
2. Expedición del certificado de reserva de derechos al uso exclusivo del título.
Oficio firmado por el titular de la dependencia; un ejemplar de la publicación, domi
o portada, en que esté plasmado el diseño y la ubicación del título, indicando el
título, la fecha de la primera edición y la periodicidad. Para las difusiones
periódicas es importante la carta programática certificada por el titular de la
dependencia.
3. Renovación de la reserva. Oficio firmado por el titular de la dependencia; el
último ejemplar publicado dentro del periodo que se va a comprobar, sin cambios
en el título, en cuanto a forma, tamaño y orden de las palabras.
8.3.3 UBICACIÓN DE LA DGAJ
Periférico Sur, número 3453, Col. San Jerónimo Lídice, Delegación Magdalena
Contreras, C. P. 10200.
8.4 REGISTRO DEL SOFTWARE
Es posible registrar un manual sobre programas informáticos o software, así

como el software en si, como obra literaria. La protección derivada del registro de
sus obras dura toda la vida del autor más 100 años posteriores a su muerte, es
decir, en un aproximado de 4 generaciones descendientes del autor gozaran aun
de los derechos de autor.El derecho de autor es un término jurídico que describe
los derechos concedidos a los creadores por sus obras literarias y artísticas.
El derecho de autor en sí mismo no depende de procedimientos oficiales. Una

obra creada se considera protegida por el derecho de autor desde que existe. No
obstante, numerosos países cuentan con una oficina nacional de derecho de autor
y algunas legislaciones permiten registrar obras con objeto, por ejemplo, de
identificar y distinguir los títulos de las obras.
8.4.1 PROCEDIMIENTOS Y REQUERIMIENTOS PARA REGISTRAR EL

SOFTWARE EN EL INDA-AUTOR.
Convertir tu producto o servicio en una marca registrada es sencillo: sólo

necesitas un nombre, un logotipo, algunos documentos, dinero y mucha paciencia.
Acude al Instituto Mexicano de la Propiedad Industrial (IMPI) y haz lo siguiente:

1.- Solicita un servicio de búsqueda para asegurarte de que no existe una

marca idéntica o similar a la tuya. El costo de este trámite es de 113 pesos y se
solicita mediante un escrito.
2.- Llena la solicitud de registro de marca. Te pedirán, entre otros datos:
• Tu nombre y domicilio.
• El tipo de marca que quieres registrar. Hay cuatro opciones: nominativa
(palabras sin diseños), innominada (diseños sin palabras), tridimensional (envases
o empaques en tres dimensiones, que no contengan palabras o dibujos) y mixta
(combinación de las anteriores).
• Etiqueta o impresión fotográfica de tu marca.
• La fecha en que comenzaste a usar la marca con fines comerciales.
• La clase a la que pertenece tu producto o servicio.
• Tu firma y la fecha.
3.- Paga en el banco. El costo total por el registro de una marca es de 2,497 pesos
y se paga mediante un formato que es proporcionado por el IMPI.
4.- Lleva tus documentos:

• Solicitud de registro (necesitas el original y tres copias).
• Comprobante de pago (original y copia).
• Seis etiquetas o impresiones fotográficas de tu marca.
5.- Si tu marca es aprobada y se convierte en una marca registrada, tardarán seis

meses en entregarte tu ‗título de registro de marca‘, que te ampara como único
dueño de tu idea por los próximos 10 años.
8.4.3 VENTAJAS Y DESVENTAJAS AL REGISTRAR EL SOFTWARE
El software licenciado consiste en todos aquellos programas que son

distribuidos bajo una licencia donde se especifica su condición de uso por parte
del usuario, estos conforman los que son programas de pago como por ejemplo:
nero, delphi, visual studio, fruity loops studio, etc.
Entre sus ventajas se puede citar:
1 - Mantiene protegido el trabajo realizado por los creadores del software de la

distribución de su producto sin recibir algún beneficio por el mismo.
2 - Algunos proveen soporte técnico 24 gratis a sus usuarios.

3 – Actualizaciones (mayormente gratis) o cambio de version a un costo menor

que si comprara la nueva versión.
Algunas de sus desventajas se pueden mencionar:
1 - Hay que realizar el pago de cuotas anuales para poder seguir usando el
producto.
2 - El costo de las licencias pueden llegar a ser muy caras por lo que puede incitar
a la piratería por parte del usuario en caso de que este muy exasperado por
conseguirlo.
3 - El usuario no puede modificar el programa para que se ajuste o realice

acciones que este deseara que hiciera sin tener que violar el acuerdo de la
licencia.
4 - No puede distribuirse libremente o instalarse en una cantidad de equipos que

excedan la cantidad máxima especificada en la licencia.
Existen mas ventajas y desventajas todo depende desde el punto de vista que se
mire espero que hayan ayudado las que te mencione.
8.5 VIOLACIÓN A LOS DERECHOS DEL AUTOR
La Internet, como cualquier otro medio digitalizado, permite la fácil copia de

los contenidos que se presentan en la misma, bien sea en los mensajes de correo,
sistemas de mensajería por boletín, o en las páginas Web. Sin embargo, la
facilidad de copia, aunque invita, no autoriza la copia indiscriminada de
contenidos. Los derechos de autor existen en este medio como en cualquier otro.
Hay muchos mitos alrededor del proceso de protección de los derechos de

autor y de a qué se tiene derecho por parte del dueño. Sin embargo, con el
advenimiento de una mayor digitalización de contenidos y con la facilidad de
distribución (copiadores de CD's, copia de contenido Web, etc.) las empresas
propietarias de derechos han ejercido presiones para que en cada país se acojan
leyes internacionales sobre la materia y se persiga a los infractores.
El autor de una obra (o su patrono en algunos casos) es el propietario de

los derechos de autor sobre la obra. Estas obras incluyen trabajos literarios como
libros, artículos de revistas, boletines (como éste), trabajos musicales, películas de

cine, programas de televisión, en fin, donde se pueda catalogar el trabajo

como propiedad intelectual de un individuo o empresa. No se incluyen elementos
funcionales como una máquina. Se puede proteger la descripción de la máquina,
más no la máquina. Tampoco se puede proteger por derechos de autor y copiado
los títulos, nombres y eslogan de campañas. Estas se pueden proteger por
Registro de Marca en algunas ocasiones.
El autor tiene derecho, entre otros, a detener procesos de copiado y

reproducción del trabajo, detener la elaboración de trabajo derivado del trabajo
original (como nuevos trabajos basados en trabajos actuales así se usen otras
palabras para describir lo mismo), detener la venta o distribución de copias del
trabajo, impedir que se presente el trabajo públicamente. En términos generales,
tiene derecho sobre la vida, distribución y reproducción de la obra, por hasta 70
años después de su muerte.
Muchas copias se hacen bajo los mitos de que "como no cobro por la copia,
lo puedo hacer", "me llegó a mi, por lo que lo puedo distribuir", "estoy dando
publicidad gratuita". Todos estos argumentos ni cualquier otro justifican la copia de
ningún documento, a menos que el autor expresamente haya dado su
autorización. Hay algo llamado "uso justo" de la copia y se permite, por ejemplo,
que se cite una frase para probar un punto, con el adecuado crédito a la fuente, o
que se utilice para la educación sin animo de lucro. Este uso justo está dado por la
naturaleza para la cual se utilizará la copia, y el posible daño que le pueda causar
al dueño de los derechos.
Es claro, que el único que puede determinar si los argumentos son validos o
no es el dueño de los derechos y ninguno de los argumentos anteriores autorizan
a su copia. Hay un ejemplo claro para la clasificación del uso justo. Si toma una
porción de un periódico para criticar su contenido es válido su uso, pero si la toma
porque no tuvo tiempo de elaborar su propio trabajo se considera violación de los
derechos de autor.
La violación de los derechos de autor se constituye en un proceso civil más

no penal. Si se violan los derechos de autor, lo más probable es que se gesten
demandas y no acusaciones criminales. Sin embargo, con los castigos por daños
y perjuicios pudiendo llegar a valores altos, pueden ocasionar cargos de fraude en
algunas legislaciones y pueden tomar visos de cargos penales.
Hasta antes de 1978 se consideraba que un autor debía estipular

claramente sus derechos de copiado en cada obra para que esta no pudiera ser
copiada; se suponía que si no decía nada, no tenía restricciones. Hoy en día se ha

abolido este requerimiento y se supone de antemano que TODA obra está

protegida por los derechos, esté estipulado o no en los documentos.
Los autores tienen formas de ser más explícitos en sus derechos para que
no queden dudas al quien quiera efectuar una copia. Aunque no es requisito hacer
nada en un documento para decir que tiene derechos de autor, se recomienda que
sea explícito incluyendo la (c) (la letra c en un circulo) ola palabra "Copyright" o
ambas, el año (normalmente el de creación o publicación) y el nombre del dueño
de los derechos. Aunque no es crítico el lugar donde coloque el aviso, hágalo
visible a quien lo esté buscando.
Por otro lado, hay que ser muy explícitos en cuanto a la cesión de derechos
o autorización de copias. Un autor puede autorizar a alguien a que publique su
artículo, sin embargo esta autorización puede no cobijar ni edición, ni derechos
sobre la autoría del mismo. Por lo tanto si un tercero quisiera utilizar la misma
obra, deberá pedir la autorización al autor y no a quien pudo copiarla.
Es muy claro el tema para quienes manejamos este tipo de publicaciones, y

por lo general se autorizan las copias para ser utilizadas en ciertas circunstancias.
Sin embargo, lo que no es aceptable es el uso del trabajo de otros aduciendo
ignorancia sobre el tema. Si se desea utilizar un contenido que le parece
interesante, nuestra recomendación es que acuda al autor, y solicite su permiso.
En la mayoría de los casos, gustosamente le será otorgada. Cabe otro refrán:
¡ante la duda, absténgase!
8.6 LEYES QUE BRINDAN PROTECCIÓN JURÍDICA EN CASO DE VIOLACIÓN
¿Cómo se protege el autor intelectual y la propiedad intelectual?
En sus inicios los programas de computación eran registrados ante el

registro público del derecho de autor, pero no es sino hasta 1991 cuando se
incluye como una obra autora expresamente protegida dentro del artículo 7 inciso
(j) de la Ley Federal de Derechos de autor. Actualmente de acuerdo al artículo 135
de la Ley Federal de Derechos de autor es ilegal realizar, distribuir, o en su caso
reproducir copias de una obra protegida sin autorización del titular del derecho. La
única excepción de acuerdo al artículo 18 inciso (f), es para quien adquiera el uso
autorizado de un programa de computación quien podrá realizar una copia para
uso exclusivo como archivo o respaldo.
Sanciones

En las modificaciones realizadas a la ley en 1991, se instituyeron las

sanciones penales para la violación de los derechos de autor de los programas de
computación. Éstas penalidades incluyen: cárcel de hasta 6 años, multas de hasta
500 días de salario mínimo, o ambos, por la reproducción o distribución no
autorizada de software protegido por la ley antes mencionada.
Una sanción civil será instituida a petición del titular de derecho, quien podrá
solicitar entre otras cosas la reparación de los daños y perjuicios causados,
además de generar al infractor costos y gastos por la violación del derecho de
autor.
8.7 SOCIEDAD DE GESTION COLECTIVA
La gestión colectiva de derecho de autor nació y se desarrollo a través de

entidades de carácter privado, sin propósito de lucro, formadas por autores (con
participación de los editores de obras musicales en muchas sociedades de
derecho de ejecución), con el objeto de defender los intereses de carácter
personal (derecho moral) y de administrar los derecho patrimoniales de los autores
de obras de creación.
El 3 de julio de 1985 fue impuesto con carácter general en Francia, que las
agrupaciones de autores en su forma jurídica se convirtieran en sociedades
civiles.
Sin embargo, no todas las sociedades de autores han adoptado esta forma,
y ni siquiera todas las organizaciones de gestión de derecho de autor son
personas jurídicas de derechos privados. en consecuencia, si bien el carácter
privado de las entidades y la forma jurídica bajo la cual se constituyen, varía según
la singularidades nacionales la ausencia de fines lucrativos es condición sine qua
non (ósea no pueden repartir utilidades), como lo expresa nuestra ley en el art. 89,
párrafo 1 y el articulo 91, numeral 11, del reglamento de aplicación no. 362-01 de
la ley 65-00 al decir: "el destino del patrimonio o del activo neto resultante en los
supuestos de liquidación de la entidad que, en ningún caso, podrá ser objeto de
reparto entre los asociados, solo pueden retener las sumas indispensables para
atender su funcionamiento."
Con relación a esto en la carta de derecho de autor, adoptada por la CISAC

en su congreso numero XIX, declara enfáticamente lo siguiente: "la sociedad de
autores, sea cual fuere su forma jurídica, son organismo de administración de los
intereses patrimoniales de los autores y de sus derechohabientes. No son
organizaciones comerciales ni empresas que persigan fines de lucro.

En consecuencia, solo retienen sobre las percepciones efectuadas, los

porcentajes necesarios para cubrir sus gastos. Por lo tanto, deben gozar del
régimen legal apropiado, particularmente en materia fiscal."
En torno a esto muchos países que regularon sus asociaciones bajo

estatutos de enfoque privado, necesitaron texto que correspondieran a ambos
enfoques, subrayando que, en todo caso los textos surgidos, de sus
deliberaciones no constituyan sino marcos, y que incumbían a los estados decidir
la naturaleza de los organismo, que habrían de constituirse en su territorio, ya sea
en forma de sociedades privadas o de oficinas o agencias de derechos públicos.
Naturaleza jurídica de la representación que ejerce la organización de

gestión colectiva
Con independencia de carácter y de la forma jurídica de las organizaciones

gestión colectiva de los derechos de autor, su objeto principal es defender los
intereses de carácter morales y administrar los derechos patrimoniales de los
autores sobre obras de creación.
En base a esto, el art.5, de los estatutos de la CISAC dispone que por

propiedad de derechos de autor se entiende cualquier organismo que:
Proclame en su objeto y asegure efectivamente la promoción de los autores

y la defensa de sus interés patrimoniales.
Cuente con un dispositivo eficaz de recaudación y reparte de los ingresos a

títulos de derecho de autor y a suma total responsabilidad sobre las
operaciones correspondiente a la gestión de los derechos a él."
En relación a esto nuestro ordenamiento jurídico expresa, en el art. 162,

párrafo I y IV - letra C, un objeto y finalidad similares.
En cuanto a la autorización que da el autor a una sociedad en el orden

publico es diferente al del orden privado que emana de un contrato de sociedad,
mandato, cesión o aportes sociales, en lo publico la representatividad de los
titulares de derecho que ejerce el organismo emana de la norma legal que lo crea,
es exclusivamente de ley, y así se puede ver en el art. 162, de la ley 65-00. De
acuerdo a esto se dice que este sistema es más equitativo por su protección
social directa, el cual evita otras regulaciones más que las dispuestas por la ley y
sus reglamentos.

Sociedad de gestión colectiva y derechos conexos en cuanto a su

marco legal, tanto para existir, o no en defensa de los derechos de autor.
Según el art.162, párrafo II de la ley 65-00 y el art. 87 del reglamento de

aplicación no. 362-01 de dicha ley, la sociedad de gestión colectiva serán
autorizadas para su existencia y entrada en funcionamiento por el poder ejecutivo,
luego del dictamen favorable de la unidad de derecho de autor.
Dicha unidad de derecho de autor, además se encargara de supervisar la

forma de ejecución de las funciones de la sociedad de gestión colectiva y podrá
sancionar y/o cambiar sus reglamentos internos, siempre y cuando sea pertinente
a favor de la defensa de los autores y afines.
Para la defensa de los derechos de los autores, tanto en materia penal

como en civil, el párrafo del art.164 de la ley 65-00 establece que:
"Quien explote una obra, interpretación o producción administrado con una

sociedad de gestión colectiva sin que se hubiere otorgado la respectiva licencia de
uso, debe pagar, a titulo de indemnización un recargo del cincuenta por ciento
(50%) sobre la remuneración en la tarifa, aplicada durante todo el tiempo en que
se hay efectuado la explotación, siempre que no se pruebe un daño superior en el
caso concreto".
En el párrafo del art. 68 da otra protección económica al autor o a sus

causahabientes en caso de reventa de una obra pictórica, o de artes plásticas en
general, dándole un derecho inalienable de percibir en su menor caso el dos por
ciento (2%) de la reventa.
Pero más dirigido al ámbito penal se ven las acciones que puede ejercer la
sociedad colectiva en contra de los infractores en los art.169, 173 párrafo I de la
ley 65-00, y art. 111, 114 y 116 del reglamento de aplicación no.362-01 de la ya
mencionada ley.
Sociedad única por cada categoría de derecho administrado o pluralidad de

sociedades.
La organización de gestión colectiva en una sola entidad general

administradora del conjunto de los distintos géneros de derecho o en diferentes
sociedades que se ocupan de una o más categorías de derecho. Ambos sistemas
pueden resultar igualmente eficaz pero a condición, cuando actúan varias

sociedades de cada especie de derecho sobre del mismo de genero de

obras y sea administrado por estas.
En cuanto a esto se ha dicho y lo veo con mucha lógica el hecho de que

ofrece ventajas fundamentales en una sola organización en lo que respecta a la
facilidad y la seguridad jurídica del otorgamiento de las licencias de utilización, la
posibilidad de autorizar la utilización de todo el repertorio mundial en una única
licencia, la reducción considerable de los gastos administrativos, entre otros; y
por tanto, parece conveniente evitar las organizaciones paralelas y crear una única
organización para cada categoría de derechos.
En nuestro país utilizamos el método de organizaciones por género de

obras, por ejemplo, en Rep. Dom. La ley 65-00 sobre derecho de autor establece
en el numeral 6 del art. 19 que los autores cuentan con el derecho exclusivo de
autorizar o prohibir la comunicación de la obra al publico; el art.120 establece que
es ilícita la comunicación publica de la obra sin el consentimiento del autor o de los
otros titulares reconocidos por esta ley, en su caso SGACEDOM, única sociedad
de gestión de la Rep. Dom. Autorizada para gestionar los derecho de los autores
de manera colectiva.
Ahora bien, el art.142 establece que las personas que utilicen un fonograma
para fines de comunicación al público, deberá pagar una remuneración al
productor del fonograma. En ese sentido, el art. 162 de la ley establece la
imposibilidad de crear más de una sociedad por rama artística o literaria, ósea, no
puede haber más de una sociedad que gestione los derecho de comunicación
pública de obras musicales (como es el caso SGACEDOM ), y en es e mismo
tenor no puede haber más de una sociedad que gestione los derecho de
comunicación publicas de fonogramas publicados con fines comerciales (como es
el caso otra sociedad llamada SODRINPRO la cual agrupa titulares derecho
conexos o afines de todo el mundo en cuanto a productores de fonograma o casas
disqueras); por lo tanto vemos que el sistema nuestro como otrora dijimos es el
régimen de organización por genero de obras. Todo esto para reconocer la paga
de licencias depende de que las obras sean de dominio público o no.
Las remuneraciones
Esta que es la suma fijada para saldar o cubrir la parte patrimonial de los
autores, conseguidos por la entidad colectiva. En nuestro país se utiliza el sistema
de remuneración tanta a los artistas intérpretes o ejecutantes, como también a los
productores de fonogramas, basándose en el art.12 de la convención de roma que
establece:

"el utilizador abonará una remuneración equitativa y única a los

artistas intérpretes o ejecutantes, a los productores de fonogramas, o unos y otros
(…)"
En nuestro derecho de autor se encuentra los art.113 y siguientes de la ley

65-00 y en su reglamento de aplicación 362-01 art. 92 párrafos 6, 9,10.
Las remuneraciones pueden ser fijadas por la sociedad de autores, pero se

prefiere que sea el resultado de acuerdos, en razón de los obvios beneficios que
para todos los integrantes reporta que las relaciones entre los representantes de
los autores y los usuarios se desarrollen en forma pacífica y concertada y sin
recurrir al albitreo de organismo gubernamentales o de los tribunales.
En nuestra ley 65-00 se regula esto en los art. 1
8.7.1 ¿QUÉ ES UNA SOCIEDAD DE GESTION COLECTIVA?
Una sociedad colectiva, en Derecho mercantil, es uno de los posibles tipos

de sociedad mercantil. Se trata de una sociedad externa (que actúa y responde
frente a terceros como una persona distinta a la de sus socios), que realiza
actividades mercantiles o civiles bajo una razón social unificada, respondiendo los
socios de las deudas que no pudieran cubrirse con el capital social.
La sociedad colectiva tiene como rasgo principal y que le diferencia de otros

tipos de sociedades como la sociedad anónima o de responsabilidad limitada, el
hecho de que la responsabilidad por las deudas de la sociedad es ilimitada. Esto
significa que en caso de que su propio patrimonio no sea bastante para cubrir
todas las deudas lo que normalmente la llevará a un procedimiento concursal
(quiebra, suspensión de pagos o similares) los socios deben responder con su
propio patrimonio del pago de las deudas pendientes a los acreedores.
La sociedad colectiva es heredera de la sociedad mercantil originaria y,

como tal, una de las formas societarias mercantiles más antiguas que existen. No
obstante, la ausencia de limitación de responsabilidad para sus socios ha hecho
que haya ido desapareciendo de forma gradual. Actualmente la forma
predominante de sociedad mercantil es la sociedad de responsabilidad limitada,
en sus distintas variantes, quedando otras sociedades como la sociedad colectiva
reducida a un papel marginal en el tráfico comercial. En algunos países, como
España, su régimen legal es el aplicable para las sociedades mercantiles que no
han cumplido con la obligación de registro (sociedad irregular).

8.7.2 PROCEDIMIENTOS Y REQUERIMIENTOS PARA REGISTRAR UNA

SOCIEDAD DE GESTIÓN COLECTIVA.
Por el contrato de sociedad, dos o más personas se obligan a efectuar un

aporte en dinero, en trabajo o en otros bienes apreciables en dinero, con el fin de
repartirse entre sí las utilidades del respectivo ejercicio social. Una vez constituida
en debida forma, la sociedad es persona jurídica diferente de los socios que la
integran. Estas sociedades deben matricularse en el Registro Mercantil de la
Cámara de Comercio con jurisdicción en lugar donde establecen el domicilio
principal.
Requisitos para su inscripción:
Las sociedades comerciales deben formular la solicitud de matrícula a

través de sus representantes legales, dentro del mes siguiente a la a fecha de la
escritura pública de constitución, acompañando dicho documento y tramitando los
formularios y el anexo tributario Para ello:
• Diligencie el formulario de Registro Único Empresarial (Carátula Única y Anexo

Mercantil), firmado por el representante legal de la sociedad.
• Solicite y diligencie el anexo tributario con la firma del representante legal.
• Anexe copia de la escritura pública de constitución, la cual debe contener por lo
menos los siguientes aspectos para que proceda su inscripción, sin perjuicio de
los demás requisitos Contenidos en el artículo 110 de Código de Comercio:
-Nombre completo de los constituyentes con sus documentos de identidad. En el

caso de que los participantes en la constitución de la sociedad sean personas
jurídicas (sociedades, entidades sin ánimo de lucro etc.), es necesario indicar en el
documento el NIT correspondiente.
-Denominación o razón social. Esta debe responder al tipo de sociedad que se

constituye: Colectiva, Limitada, En Comandita Simple o por Acciones o Anónima.
Antes de registrar el nombre utilice nuestro servicio de verificación de homonimia.
-Domicilio principal (ciudad o municipio donde se establece).
-Vigencia o término de duración de la sociedad.
-Objeto social o actividades que desarrollará. El objeto social debe estar descrito
de manera clara y determinada.

-Capital social y su distribución entre los socios, indicando las formas como
fue pagado (dinero, especie, o industria). En cuanto a la distribución del capital
debe indicar el número de cuotas o acciones según el caso y el valor nominal de
cada una.
-Representación legal y nombramientos.
-Cuando se aporten a la sociedad activos tales como bienes inmuebles, deberá

inscribirse la escritura en el registro de instrumentos públicos del lugar de
ubicación del inmueble.
-Carta de aceptación del cargo con indicación del número del documento de
identidad por parte de los designados como representantes legales, miembros de
junta directiva y revisores fiscales. Si se deja constancia en la escritura pública de
constitución de tal aceptación, no es necesario este requisito.
8.7.3 PUBLICACIONES Y PRIVILEGIOS AL FORMAR PARTE DE UNA

SOCIEDAD DE GESTION COLECTIVA
Obligaciones y derechos de los socios
Obligaciones:
• Hacer entrega de los aportes convenidos en el tiempo y forma en que se

hubieren convenido en el tiempo y forma en que se hubiere pactado
• Hay un deber de lealtad del socio para con la empresa que le impide dedicarse a
negocios similares a los de la compañía haciendo a la misma competencia. Según
el art. 321 del CC el socio estará obligado a entregar a la compañía cualquier
ganancia o lucro procedente de dichos negocios siendo responsable, caso de no
hacerlo, de los daños y perjuicios que ocasione con su omisión debiendo además
reconocer intereses al tipo comercial corriente sobre las cantidades retenidas,
también incurrirá en responsabilidad aquel que utilice el capital o cualquier bien de
la sociedad en beneficio propio o de terceros.
• Es obligación de los administradores es la de cumplir el encargo hasta el fin de
la sociedad, respondiendo a ésta de los daños y perjuicios que le ocasionaron con
su negligencia en la gestión del negocio social.
Derechos
• Hacer uso de la firma social, si alguno de ellos no hubiere sido especialmente

designado administrador, ya fuere en el pacto social o por un acuerdo posterior

• Los socios tienen derechos a tomar parte en las deliberaciones y votar,

cuando se trate de asuntos que deben ser consultados, o cuando los
administradores quisieren conocer la opinión de los demás socios. En tal caso de
no haberse estipulado en el contrato de sociedad la manera de computar los votos
de los socios, cuando fuere necesario, estos se tomarán por personas y no por
capitales.
• Derecho de los socios a investigar el curso de los negocios sociales, examinar
los libros y la correspondencia y demás documentos referentes a la administración
y oponerse a cualquier reforma del pacto social que se proyecte y con la que no
este de acuerdo
• Los socios tienen derechos a participar en las ganancias en la proporción que se
hubiere acordado en el pacto social, o en otro caso, en proporción la valor de su
aportación y retirarse de la sociedad cuando lo crea conveniente no tipificando su
intención con 6 meses de anticipación
• Tiene derecho el socio a llenar por cuenta de la sociedad los requisitos de
inscripción en el registro de la escritura de constitución de la sociedad y de la
publicación

BIBLIOGRAFIA:
• CORREA, Carlos y otros, "DERECHO INFORMÁTICO", Argentina, Ed. De

Palma, 1987. 207 p.
• FERNÁNDEZ de León, Gonzalo, "DICCIONARIO JURÍDICO", Tomo II,
Argentina, Ed. Abece, 1963. 571 p.
• FREEDMAN, Alan, "DICCIONARIO DE COMPUTACIÓN", Colombia, Ed.
McGraw Hill, 1994. 492 p.
• GARCÍA, Eduardo Augusto, "LA DEFRAUDACIÓN EN MATERIA DE
DERECHOS DE AUTOR", Argentina, Ed. Troquel, 1969. 285 p.
• JESSEN, Henery, "DERECHOS INTELECTUALES DE LOS AUTORES,
ARTISTAS, PRODUCTORES DE FONOGRAMAS Y OTROS TITULARES", Chile,
Ed. Jurídica Chile, 1970. 428 p.


Antologia DSS Completa PDF

Cargado por

Copyright:

Formatos disponibles

Antologia DSS Completa PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Antologia DSS Completa PDF

Cargado por

Copyright:

Formatos disponibles

32a

INSTITUTO TECNOLÓGICO SUPERIOR DE

DSB-0705 DESARROLLO DE SOFTWARE SEGURO

Ing. Manuel Torres Vásquez

Revisado por los integrantes de la academia de Informática

Material compilado con fines académicos

Fecha elaboración: Julio 2010

Introducción a la seguridad del software

1.1 Concepto de Software

Asignatura: Desarrollo de Software Seguro

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

2.2 Administración de los riesgos en la seguridad del Software en la

2.2.1 Pruebas de Caja Negra

2.3 Criterios Comunes

Código abierto o cerrado

3.1 Seguridad por Oscuridad

Asignatura: Desarrollo de Software Seguro

Principios guías del software seguro

4.1 Principio 1. Reducir las líneas débiles

5.1 Definición de Arquitectura de Seguridad

Asignatura: Desarrollo de Software Seguro

6.1 Definición de Código Seguro

Asignatura: Desarrollo de Software Seguro

7.1 Fases de las Pruebas de Software

Asignatura: Desarrollo de Software Seguro

Derechos de autor en México (software)

8.1 Ley Federal del Derecho de Autor (LFDA) en México

Asignatura: Desarrollo de Software Seguro

Introducción a la seguridad del software

Objetivo: El alumno conocerá y comprenderá los fundamentos teóricos,

1.1 Concepto de Software

Asignatura: Desarrollo de Software Seguro

1.1 CONCEPTO DE SOFTWARE

El software es el nexo de unión entre el hardware y el hombre. El computador, por

El software es un conjunto de programas elaborados por el hombre, que controlan

Tal característica ‗lógica‘ o ‗inteligente‘ del software es lo que hace que se le

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.

Asignatura: Desarrollo de Software Seguro

hardware, realizan funciones que para el usuario serían engorrosas o

 Otro de los casos de fallas en software que causó graves daños a la

 Error en un sistema de autenticación de tarjetas de crédito (1995)

 Software inapropiado llevó a un distribuidor de medicina a la quiebra. El 27

Asignatura: Desarrollo de Software Seguro

 Error en sistema de cobranza de MCI (1996). En la edición de 29 de marzo

 El error de cobranza fue descubierto por un reportero investigador de una

1.3 FUTURO DEL SOFTWARE

"El futuro del software es un desafío"

Los cambios implican un desafío interesante para todos los involucrados en el

Asignatura: Desarrollo de Software Seguro

 El auge de los ordenadores personales que desembocó en una

 El auge de Internet, que condujo a una explosión de información y cambió

 La aparición de estándares y tecnologías de servicios Web, como las

 El paso hacia los enfoques de arquitectura orientada a servicios (SOA) por

 La aparición del modelo On-Demand, que suponía el cambio de un modelo

Asignatura: Desarrollo de Software Seguro

1.4 FUENTES PARA LA INFORMACIÓN DE VULNERABILIDADES

En cualquier caso conviene indicar las fuentes más importantes de información