Antologia DSS Completa

32a

INSTITUTO TECNOLÓGICO SUPERIOR DE

CENTLA

Academia de Informática y

Sistemas Computacionales

Antología

DSB-0705 DESARROLLO DE SOFTWARE SEGURO

Presentan

Ing. Manuel Torres Vásquez

Revisado por los integrantes de la academia de Informática

y Sistemas Computacionales

Material compilado con fines académicos

Fecha elaboración: Julio 2010

Institución Certificada

Norma ISO 9001:2000

INSTITUTO TECNOLÓGICO SUPERIOR DE CENTLA Academia de Informática y Sistemas Computacionales

Asignatura: Desarrollo de Software Seguro Material compilado con fines académicos, se prohíbe su reproducción total o parcial sin autorización de cada autor.

Tabla de Contenido

Unidad I

Introducción a la seguridad del software

1.1 Concepto de Software

1.2 Casos reales de fallas en el software

1.3 Futuro del software

1.4 Fuentes para información de vulnerabilidades

1.4.1. Buqtraq

1.4.2. CERT Advisores

1.4.3. RISK Digest

1.5 Tendencias técnicas que afectan a la Seguridad del Software

1.6 Breanking and patch (romper y actualizar)

1.7 Metas de la Seguridad enfocadas al Software

1.7.1. Prevención

1.7.2. Auditable y trazable

1.7.3. Monitoreo

1.7.4. Privacidad y Confidencialidad

1.7.5. Seguridad Multiniveles

1.7.6. Anonimato

1.7.7. Autenticación

1.7.8. Integridad

1.8 Conocer al enemigo

1.9 Metas de proyecto de Software



Unidad II

Administración de los riesgos en la seguridad del software

2.1 Descripción de la administración de los riesgos en la Seguridad del

Software

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

práctica

2.2.1 Pruebas de Caja Negra

2.2.2 Equipo Rojo

2.3 Criterios Comunes

Unidad III

Código abierto o cerrado

3.1 Seguridad por Oscuridad

3.2 Ingeniería en Reversa

3.3 Código Fuente Abierto

3.4 Falacias del código abierto



Unidad IV

Principios guías del software seguro

4.1 Principio 1. Reducir las líneas débiles

4.2 Principio 2. Defensa por pasos o capas

4.3 Principio 3. Seguramente fallará

4.4 Principio 4. Menos privilegios

4.5 Principio 5. Segmentación

4.6 Principio 6. Mantenerlo simple

4.7 Principio 7. Promover la privacía

4.8 Principio 8. Ocultar secretos es difícil

4.9 Principio 9. Transparentar el código

4.10 Principio 10. Usar recursos comunes

Unidad V

Auditoria de software

5.1 Definición de Arquitectura de Seguridad

5.2 Principios de la Arquitectura de Seguridad

5.3 Análisis de la Arquitectura de Seguridad

5.3.1 Diseño

5.3.2 Implementación

5.3.3 Automatización y pruebas

5.3.4 Árboles de Ataque

5.3.5 Reporte del Análisis

5.4 Implementación del Análisis de Seguridad

5.4.1 Auditoria de Código Fuente

5.4.2 Herramientas de Auditoria de Seguridad de Código



Unidad VI

Código seguro

6.1 Definición de Código Seguro

6.2 Lenguaje Ensamblador

6.3 Lenguajes de Programación

6.4 Técnicas de Código Seguro

6.4.1 Buffer Overflows

6.4.2 Heap Overflows

6.4.3 Formato de cadena

6.4.4 Exploits

6.4.5 Race conditions

6.4.6 SQL injection

6.4.7 Cross Site & Cross-Domain Scripting

6.4.8 Fault Injection



Unidad VII

Pruebas de software

7.1 Fases de las Pruebas de Software

7.1.1 Modelado del ambiente del software

7.1.2 Selección de escenarios de prueba

7.1.3 Ejecución y evaluación de los escenarios de prueba

7.1.4 Medición del progreso de las pruebas

7.2 Prácticas de las Pruebas de Software

7.2.1 Básicas

7.2.1.1 Especificaciones funcionales

7.2.1.2 Revisión e inspección

7.2.1.3 Entrada formal y criterios de salida

7.2.1.4 Prueba funcional

7.2.1.5 Pruebas multiplataforma

7.2.1.6 Ejecución automatizada de prueba

7.2.1.7 Programas beta

7.2.2 Fundamentales

7.2.2.1 Escenarios de usuario

7.2.2.2 Pruebas de utilidad

7.2.2.3 Requerimientos para la planificación de la prueba

7.2.2.4 Generación automatizada de la prueba

7.2.3 Incrementales

7.2.3.1 Cobertura de código

7.2.3.2 Generador de ambiente automatizado

7.2.3.3 Diagrama del estado de la prueba

7.2.3.4 Simulación de falla en la memoria

7.2.3.5 Pruebas estadísticas

7.2.3.6 Métodos semiformales

7.2.3.7 Registro de la prueba para el código

7.2.3.8 Benchmark

7.2.3.9 Generación de errores (bugs)



Unidad VIII

Derechos de autor en México (software)

8.1 Ley Federal del Derecho de Autor (LFDA) en México

8.1.1 Definición

8.1.2 Artículos para la protección jurídica del software

8.1.3 Derechos que se confieren a través de la LFDA

8.1.3.1 Derechos morales

8.1.3.2 Derechos patrimoniales

8.2. Instituto Nacional del Derecho de Autor (INDAUTOR)

8.2.1 Definición

8.2.2 Ubicación del INDAUTOR

8.3 Dirección General de Asuntos Jurídicos de la UNAM (DGAJ)

8.3.1 Definición

8.3.2 Relación con el INDAUTOR

8.3.3 Ubicación de la DGAJ

8.4 Registro del software

8.4.1 Procedimiento y requerimientos para registrar software en el

INDAUTOR.

8.4.2 Procedimiento y requerimientos para registrar software en la

DGAJ.

8.4.3 Ventajas y desventajas al registrar software

8.5 Violación a los Derechos de Autor

8.6 Leyes que brindan protección jurídica al software en caso de

violación.

8.7 Sociedades de Gestión Colectiva

8.7.1 ¿Qué es una Sociedad de Gestión Colectiva?

8.7.2 Procedimiento y requerimientos para registrar una Sociedad

de Gestión Colectiva.

8.7.3 Obligaciones y privilegios al formar parte de una Sociedad de

Gestión Colectiva.



Unidad I

Introducción a la seguridad del software

Objetivo: El alumno conocerá y comprenderá los fundamentos teóricos, tendencias y metas de la seguridad en el software.

Contenido:

1.1 Concepto de Software

1.2 Casos reales de fallas en el software

1.3 Futuro del software

1.4 Fuentes para información de vulnerabilidades

1.4.1. Buqtraq

1.4.2. CERT Advisores

1.4.3. RISK Digest

1.5 Tendencias técnicas que afectan a la Seguridad del Software

1.6 Breanking and patch (romper y actualizar)

1.7 Metas de la Seguridad enfocadas al Software

1.7.1. Prevención

1.7.2. Auditable y trazable

1.7.3. Monitoreo

1.7.4. Privacidad y Confidencialidad

1.7.5. Seguridad Multiniveles

1.7.6. Anonimato

1.7.7. Autenticación

1.7.8. Integridad

1.8 Conocer al enemigo

1.9 Metas de proyecto de Software



1.1 CONCEPTO DE SOFTWARE

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

sí solo, no puede comunicarse con el hombre y viceversa, ya que lo separa la

barrera del lenguaje. El software trata de acortar esa barrera, estableciendo

procedimientos de comunicación entre el hombre y la máquina; es decir, el

software obra como un intermediario entre el hardware y el hombre.

El software es un conjunto de programas elaborados por el hombre, que controlan

la actuación del computador, haciendo que éste siga en sus acciones una serie de

esquemas lógicos predeterminados.

Tal característica ‗lógica‘ o ‗inteligente‘ del software es lo que hace que se le

defina también como la parte inmaterial de la informática, ya que aunque los

programas que constituyen el software residan en un soporte físico, como la

memoria principal o los disquetes (o cualquier dispositivo rígido de

almacenamiento), la función de los programas en un computador es semejante a

la del pensamiento en un ser humano.

Si bien el progreso del hardware es cada vez mayor y los dispositivos físicos se

construyen cada vez con más ‗inteligencia‘ incluida, en forma que se resuelven por

hardware funciones anteriormente sólo factibles por software, es prácticamente

imposible que el avance tecnológico llegue algún día a eliminar la necesidad de

software, ya que éste también evoluciona y las facilidades que el usuario pide al

computador son cada día más sofisticadas.

La clasificación básica es: Software de Sistema y Software de Aplicación.

El software de sistema es el software básico o sistema operativo.

Es un conjunto de programas cuyo objeto es facilitar el uso del computador (aísla

de la complejidad de cada dispositivo, y presenta al exterior un modelo común de

sistema de manejo para todos los dispositivos) y conseguir que se use

eficientemente

El software de aplicación

Son los programas que controlan y optimización la operación de la máquina,

establecen una relación básica y fundamental entre el usuario y el computador,

hacen que el usuario pueda usar en forma cómoda y amigable complejos sistemas



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

incluso imposibles, y actúan como intermediario entre el usuario y el hardware.

1.2 CASOS REALES DE FALLAS EN EL SOFTWARE

El caso del desastre del Ariane-5, famoso por haberse producido por una

falla en el software de abordo. Según la European Spacial Agency (ESA),

administradora del programa, la desviación en la trayectoria fue ocasionada

por la computadora que controlaba los dos poderosos impulsores del

cohete. Se especulo que la computadora creyó que el cohete se estaba

saliendo de curso y de esta manera trataba de corregir la trayectoria de

vuelo. De acuerdo con el reporte final, la causa de la falla del sistema

ocurrió durante la conversión de un número flotante de 64 bits a un número

entero de 16 bits.

Otro de los casos de fallas en software que causó graves daños a la

integridad de las personas, Therac-25. Era un aparato para el tratamiento

del cáncer por emisión de rayos cuyos controles (de la cantidad de energía

emitida) implementados en hardware fueron removidos y sólo se dejaron

los de software que (obviamente) fallaron.

Error en un sistema de autenticación de tarjetas de crédito (1995)

Los dos sistemas más grandes en ese país para la autorización de crédito

(Barclay´s PQD y NatWest´s Streamline) fallaron el sábado 28 de octubre

de 1995 imposibilitando que los comercios verificaran las tarjetas de crédito

de sus clientes. En el caso de Barclay, más de 40% de las transacciones

fallaron por un error en el sistema de software. Para NatWest, el problema

fue ocasionado por una gran cola de llamadas, que obstruyo la

comunicación por razones desconocidas, y que retraso la autentificación de

tarjetas.

Software inapropiado llevó a un distribuidor de medicina a la quiebra. El 27

de agosto de 1998 la revista Der Spiege, en Alemania, informó de una

demanda de 500 millones de dólares a SAP por parte del distribuidor de

medicinas FoxMeyer Corp. Esta última acusó a SAP de venderle software

inapropiado para sus necesidades, lo cual tuvo como resultado la quiebra

de Fox Meyre. Analistas alemanes comentaron que no consideran que un

―software sea apropiado para llevar a la ruina a una compañía‖.



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

de 1996 del Washington Post, MCI reporto que le devolverían

aproximadamente 40 millones de dólares a sus clientes por un error de

cobranza causada por un sistema de cómputo.

El error de cobranza fue descubierto por un reportero investigador de una

estación local de televisión en Richmond, VA, quien encontró que fueron

facturados por 4 minutos siendo que en realidad la llamada fue de 2.5

minutos, dando lugar a una profunda investigación.

1.3 FUTURO DEL SOFTWARE

"El futuro del software es un desafío"

Empecemos con una paradoja: el futuro del software comienza con el fin del

software. Al menos, el fin del software tal y como lo conocemos. El software

cliente/servidor tradicional es un modelo acabado, en particular para las

organizaciones de TI que desean contribuir realmente al balance final.

Para comprender el futuro del software empresarial, no hace falta ir muy lejos: la

Web de consumidores. Al igual que los servicios Web para consumidores como

Google, eBay y Amazon.com están sustituyendo al software estándar para

consumidores, cada vez más aplicaciones empresariales están trasladándose a la

Web. En 2005, se calculó que las ventas de SaaS (software como servicio)

supusieron un 5% del total de las ventas de software empresarial. En 2011, se

prevé que la cuota aumente hasta el 25%.

Los cambios implican un desafío interesante para todos los involucrados en el

desarrollo de software. Y el hardware, que durante muchos años ha sido el cuello

de botella de los sistemas informáticos, crecerá hasta volverse de 50 a 100 veces

más poderoso que en la actualidad.

Esto representa una dificultad adicional, la de utilizar toda esa capacidad ociosa

para convertirla en algo productivo, ya que no sería inteligente tomar sistemas que

actualmente desperdician millones de ciclos de CPU y agregarle más capacidad



sin modificar el uso que reciben, para de ese modo desperdiciar más poder

aún. Sin dudas, "se avecina un nuevo paradigma de software, y he aquí el mayor

desafío".

Cualquier especulación sobre el futuro del software merece, como mínimo, una

revisión de los principales cambios a lo largo de su historia, como:

El paso del ordenador central a los sistemas cliente/servidor, que tuvo como

consecuencia la transición desde sistemas existentes a sistemas

empresariales estándar.

El auge de los ordenadores personales que desembocó en una

productividad de los usuarios sin precedentes, así como una proliferación

de islas de datos.

El auge de Internet, que condujo a una explosión de información y cambió

el modo en que millones de personas trabajan, juegan y compran. También

el aumento del uso de Internet y el acceso permanente a la red.

La aparición de estándares y tecnologías de servicios Web, como las

arquitecturas multiusuario.

El paso hacia los enfoques de arquitectura orientada a servicios (SOA) por

parte de los principales proveedores de software, lo que facilitaba la

integración con los sistemas de servidor.

La aparición del modelo On-Demand, que suponía el cambio de un modelo

en propiedad a un modelo ―en alquiler‖ y que liberaba a las empresas de los

problemas y los gastos que conllevaba la propiedad. Salesforce.com es uno

de los ejemplos más satisfactorios de este modelo con 55,400 clientes y

más de 800 aplicaciones.



1.4 FUENTES PARA LA INFORMACIÓN DE VULNERABILIDADES

En cualquier caso conviene indicar las fuentes más importantes de información

asociada a vulnerabilidades de seguridad. No hay que olvidar que la mayor parte

de esta información es de dominio público y que los desarrollos posteriores que

puedan hacerse (bien a medida internamente o contratados) van a estar basados

en las mismas fuentes:

El diccionario CVE, desarrollado por la corporación Mitre y disponible en

http: //cve.mitre.org, que sirve como un elemento integrado de distintas

fuentes y herramientas de seguridad. En esencia se trata de llamar a una

vulnerabilidad siempre ―igual‖ (con el mismo identificador).

La base de datos de vulnerabilidades y alertas del centro de respuesta y

coordinación ante emergencias de Internet, el CERT/CC, disponible en

http:// www.kb.cert.org/vuls. Las bases de datos de vulnerabilidades son

una herramienta clave a la hora de detectar posibles problemas de

seguridad y prevenirlos

La famosa base de datos de Bugtrag (basada en gran parte en la

información publicada en la lista de correo de seguridad del mismo

nombre), adquirida por la empresa de seguridad Symantec, disponible en

http: //www.securityfocus.com/bid. Es posiblemente la más completa

(alrededor de 10.000 vulnerabilidades hasta la fecha) y sobre ésta

Symantec ha desarrollado un servicio comercial.

La base de datos de Xforce, desarrollada por el fabricante de productos

de seguridad Internet Security Systems (ISS), disponible en

http://xforce.iss.net. Sirve de base tanto a los productos de seguridad de la

compañía (herramientas de detección de intrusos, sistemas de análisis de

vulnerabilidades...) como de servicios comerciales basados en ésta.

La base de datos ICAT publicada por el instituto de estándares del

Gobierno norteamericano, el NIST, y disponible en http://icat.nist.gov. Se

trata de una metabase de datos de información de vulnerabilidades, con

más de 6.500 referencias a CVE y a las bases de datos arriba indicadas. Se



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

para su libre utilización.

Dentro de estas fuentes de información podemos encontrar todo tipo de

vulnerabilidades, desde ataques a servidores IIS de Microsoft a través de código

Unicode hasta desbordamientos de búfer de Oracle Application Server, pasando

por pequeñas vulnerabilidades de sistemas Windows como las existentes en la

ayuda online de Windows. Como es lógico todas estas bases de datos se están

actualizando continuamente, a medida que se publicitan nuevos fallos de

seguridad.

Las fuentes de información de vulnerabilidades de seguridad y, entre ellas, las

bases de datos de vulnerabilidades, son una herramienta clave a la hora de

detectar posibles problemas de seguridad y prevenirlos. Estas fuentes dan, si bien

no en tiempo real, información de los principales problemas asociados a los

principales fabricantes de software y hardware (y algunos menos conocidos), en

muchos casos con sus posibles soluciones, y con información que permitirá

determinar la premura con la que se debe arreglar la vulnerabilidad (en base a su

impacto, al riesgo existente debido a la existencia o no de aprovechamientos de la

misma...).

1.5 TENDENCIAS TECNICAS QUE AFECTAN A LAS ENTIDADES DEL

SOFTWARE

Tendencias que afectan a los sistemas de información

Al considerar un Sistema de Información como un conjunto de normas y procesos

generales de una determinada, se deben considerar algunos puntos negativos y

positivos que afectan directamente al sistema:

Actualizaciones

Se refiere a que los sistemas de información de cualquier empresa, debe ser

revisado periódicamente; no con una frecuencia continua, sino mas bien

espaciada, se recomienda las revisiones bianuales (No se recomienda que se

actualice en una empresa paulatinamente, por ejemplo el software, cuadros

estadísticos, es recomendable dentro de un año cambiarlo, todo lo que es

máquinas y software; porque si no realizaríamos esto, se cambiaría toda la

estructura organizacional de la misma).



Reestructuración Organizacional

(Puede ser una reestructuración con los mismos puestos). Una reestructuración

organizacional con cualquier empresa, implica cambios siempre en vista a buscar

un mejor funcionamiento, evitar la burocracia, agilitar trámites o procesos, la

reestructuración puede ser de varios tipos, así por ejemplo. Aumentar o disminuir

departamentos, puestos, reestructuración de objetivos, etc. Siempre la

reestructuración afecta a los sistemas de información de la empresa.

Revisión y Valorización del escalafón

(No es para bien si no también para mal)

La revisión y la revalorización del escalafón se espera que afecte a favor de los

sistemas de información de las empresas, si el efecto es contrario el auditor

deberá emitir un informe del empleado a los empleados (Específicamente de

departamentos), que están boicoteando la información de la empresa.

Cambios en el flujo de Información

(Datos para el sistema de Información)

Se refiere al cambio de flujo de datos exclusivamente en el área informática, esto

afecta directamente en sistema informático y por tanto al sistema de información.

En lo que respecta a la Auditoría informática, el efecto puede ser positivo y

negativo, dependiendo a los resultados obtenidos en cuanto al proceso de datos

(menos seguridad, más seguridad, backup).

Así por ejemplo:

Se ha cambiado el flujo de información en el área contable, para generar los roles

mensuales (De inicio del rol era realizado por la secretaria, la cual ingresaba las

existencias, fallas, atrasos, etc.; determinando un monto a descontar. Un monto

bruto y un salario final, esto pasaba a la contadora para que justifique

especialmente multas, se rectificaba en algunos casos, y se mandaba a imprimir el

rol. Se considera un nuevo flujo de información, en el cual se ingresan los datos a

un sistema informático, y de acuerdo a los parámetros y normas de la empresa el

sistema arroja un sueldo líquido a cobrarse, genera automáticamente el reporte,

los cheques y el contador solo aprueba este reporte).

(Un ejemplo es cuando existe migración de datos, la información migra o se

cambia a otro sistema más sofisticado).



1.6 BREAKING AND PATCH

Actualización

Modificación que se aplica al software para corregir un problema o incorporar una

función nueva.

Realizar los pasos necesarios para aplicar actualizaciones a un sistema. El

sistema se analiza y, a continuación, se descargan y se aplican las

actualizaciones.

Se denomina también patch.

Actualización con firma

Actualización que incluye una firma digital válida. Las actualizaciones firmadas

ofrecen mayor seguridad que las que no disponen de firma. La firma digital de la

actualización puede verificarse antes de aplicarla al sistema. Las firmas digitales

válidas aseguran que las actualizaciones no se han modificado desde que éstas

se aplicaron. Las actualizaciones firmadas se almacenan en archivos con formato

Java Archive (JAR).

Actualización de función

Actualización que incorpora una nueva función en el sistema.

Actualización sin firma

Actualización que no incluye una firma digital.

Parche (informática)

En informática, un parche es una sección de código que se introduce a un

programa. Dicho código puede tener varios objetivos; sustituir código erróneo,

agregar funcionalidad al programa, aplicar una actualización, etc.

Los parches suelen ser desarrollados por programadores ajenos al equipo de

diseño inicial del proyecto (aunque no es algo necesariamente cierto). Como los

parches se pueden aplicar tanto a un binario ejecutable como al código fuente,

cualquier tipo de programa, incluso un sistema operativo, puede ser objeto de un

parche.

El origen del nombre probablemente se deba a la utilidad de Unix llamada patch

creada por Larry Wall

http://docs.sun.com/app/docs/doc/819-7281/6n984sqlo?l=es&a=view#glossary_patch

http://es.wikipedia.org/wiki/InformÃ¡tica

http://es.wikipedia.org/wiki/Programa_(computaciÃ³n)

http://es.wikipedia.org/wiki/Programador

http://es.wikipedia.org/wiki/Archivo_binario

http://es.wikipedia.org/wiki/Ejecutable

http://es.wikipedia.org/wiki/CÃ³digo_fuente

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Unix

http://es.wikipedia.org/wiki/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.

http://es.wikipedia.org/wiki/Error_de_software

http://es.wikipedia.org/wiki/VersiÃ³n_beta

http://es.wikipedia.org/wiki/Agujero_de_seguridad

http://es.wikipedia.org/wiki/Algoritmo



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

http://es.wikipedia.org/wiki/Organizaci%C3%B3n

http://es.wikipedia.org/wiki/Plan_estrat%C3%A9gico

http://es.wikipedia.org/wiki/Tecnolog%C3%ADas_de_la_informaci%C3%B3n_y_la_comunicaci%C3%B3n

http://es.wikipedia.org/wiki/Trazabilidad

http://es.wikipedia.org/wiki/Abstracci%C3%B3n



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.

http://www.oepm.es/cs/Satellite?c=Normativa_C&cid=1150304955034&classIdioma=_es_es&pagename=OEPMSite%2FNormativa_C%2FtplContenidoHTML

http://www.oepm.es/cs/Satellite?c=Normativa_C&cid=1150304955034&classIdioma=_es_es&pagename=OEPMSite%2FNormativa_C%2FtplContenidoHTML

http://www.ctt.upv.es/docs/LegislacionConvenio_1_1996.pdf



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


http://es.wikipedia.org/wiki/Cadena_de_suministro


http://es.wikipedia.org/wiki/Embalaje

http://es.wikipedia.org/wiki/Pal%C3%A9

http://es.wikipedia.org/wiki/Materia_prima

http://es.wikipedia.org/wiki/Almac%C3%A9n

http://es.wikipedia.org/wiki/Etiqueta



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.

http://es.wikipedia.org/wiki/RFID

http://es.wikipedia.org/wiki/Administraci%C3%B3n_de_empresas

http://es.wikipedia.org/wiki/Administraci%C3%B3n_de_empresas

http://es.wikipedia.org/wiki/Sistema_de_trazabilidad

http://es.wikipedia.org/wiki/TIC

http://es.wikipedia.org/wiki/Cadena_de_suministro

http://es.wikipedia.org/wiki/Software_de_trazabilidad#cite_note-0

http://es.wikipedia.org/wiki/Administraci%C3%B3n_P%C3%BAblica

http://es.wikipedia.org/wiki/Calidad

http://es.wikipedia.org/wiki/Consumidor_final

http://es.wikipedia.org/wiki/Cliente_%28econom%C3%ADa%29

http://es.wikipedia.org/wiki/Plataforma_%28inform%C3%A1tica%29

http://es.wikipedia.org/wiki/Norma_jur%C3%ADdica

http://es.wikipedia.org/wiki/Globalizaci%C3%B3n

http://es.wikipedia.org/wiki/Manufactura



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.

http://es.wikipedia.org/wiki/Confidencialidad

http://es.wikipedia.org/wiki/Cortafuegos

http://es.wikipedia.org/wiki/Antivirus



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

http://es.wikipedia.org/wiki/Antispyware

http://es.wikipedia.org/wiki/Internet_Explorer

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Computadora

http://es.wikipedia.org/wiki/P%C3%A1gina_web

http://es.wikipedia.org/wiki/Correo_electr%C3%B3nico



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á.

http://es.wikipedia.org/wiki/Nodo

http://es.wikipedia.org/wiki/Red

http://es.wikipedia.org/wiki/Pseud%C3%B3nimo

http://es.wikipedia.org/wiki/Amigo-a-amigo



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.

http://es.wikipedia.org/wiki/Seguridad_inform%C3%A1tica

http://es.wikipedia.org/wiki/Red

http://es.wikipedia.org/wiki/Datos

http://es.wikipedia.org/wiki/Autorizaci%C3%B3n

http://es.wikipedia.org/wiki/Auditor%C3%ADa



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:

http://es.wikipedia.org/wiki/Dato

http://es.wikipedia.org/wiki/Base_de_datos

http://es.wikipedia.org/wiki/Energ%C3%ADa

http://es.wikipedia.org/wiki/Bases_de_datos_relacionales

http://es.wikipedia.org/wiki/Columna_%28base_de_datos%29

http://es.wikipedia.org/wiki/Tabla_%28base_de_datos%29

http://es.wikipedia.org/wiki/Fila_%28base_de_datos%29



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

http://www.commoncriteriaportal.org/

http://www.commoncriteriaportal.org/products.html,



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.

http://www.commoncriteriaportal.org/thecc.html,

http://www.commoncriteriaportal.org/thecc.html,



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

http://es.wikipedia.org/wiki/Microsoft_Windows

http://es.wikipedia.org/wiki/Microsoft_Outlook

http://es.wikipedia.org/wiki/Outlook_Express

http://es.wikipedia.org/wiki/Virus

http://es.wikipedia.org/wiki/Troyano_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Gusano_inform%C3%A1tico



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.

http://es.wikipedia.org/wiki/Ingenier%C3%ADa



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.

http://www.monografias.com/trabajos6/dige/dige.shtml#evo

http://www.monografias.com/trabajos/competitividad/competitividad.shtml

http://www.monografias.com/trabajos11/empre/empre.shtml

http://www.monografias.com/trabajos6/meti/meti.shtml

http://www.monografias.com/trabajos11/funpro/funpro.shtml



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).

http://www.monografias.com/trabajos11/metods/metods.shtml

http://www.monografias.com/trabajos6/arma/arma.shtml

http://www.monografias.com/trabajos15/metodos-creativos/metodos-creativos.shtml

http://es.wikipedia.org/wiki/Imagen:Opensource.svg

http://es.wikipedia.org/wiki/Imagen:Opensource.svg

http://es.wikipedia.org/wiki/Ingl%C3%A9s

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/1998

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/Freeware

http://es.wikipedia.org/wiki/Freeware




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

http://es.wikipedia.org/wiki/C%C3%B3digo_fuente


http://es.wikipedia.org/wiki/Software_semilibre




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.

http://weblogs.madrimasd.org/futurosdellibro/archive/2007/11/16/78859.aspx

http://www.iso.org/iso/home.htm

http://www.opendocsociety.org/



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

http://peccataminuta.wordpress.com/2007/01/29/la-falacia-del-software-libre/

http://www.gnu.org/philosophy/free-sw.es.html



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.



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

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



¡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.

http://es.wikipedia.org/wiki/Segmentaci%C3%B3n_de_mercado



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.

http://www.monografias.com/trabajos13/mapro/mapro.shtml

http://www.monografias.com/Computacion/Programacion/

http://www.monografias.com/Computacion/index.shtml

http://www.monografias.com/trabajos12/romandos/romandos.shtml#PRUEBAS

http://www.monografias.com/trabajos11/teosis/teosis.shtml



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.

http://www.monografias.com/trabajos4/proyinf/proyinf.shtml



http://www.monografias.com/trabajos15/medio-ambiente-venezuela/medio-ambiente-venezuela.shtml

http://www.monografias.com/trabajos15/ms-windows/ms-windows.shtml

http://www.monografias.com/Tecnologia/index.shtml


http://www.monografias.com/Tecnologia/index.shtml

http://www.monografias.com/trabajos/multimediaycd/multimediaycd.shtml

http://www.monografias.com/trabajos14/discosduros/discosduros.shtml


http://www.monografias.com/trabajos15/computadoras/computadoras.shtml


http://www.monografias.com/trabajos12/elorigest/elorigest.shtml


http://www.monografias.com/trabajos5/sisope/sisope.shtml


http://www.monografias.com/trabajos16/comportamiento-humano/comportamiento-humano.shtml


http://www.monografias.com/trabajos12/comptcn/comptcn.shtml#UCP

http://www.monografias.com/trabajos16/industria-ingenieria/industria-ingenieria.shtml

http://www.monografias.com/trabajos15/computadoras/computadoras.shtml


http://www.monografias.com/trabajos11/basda/basda.shtml


http://www.monografias.com/trabajos11/introwin/introwin.shtml



http://www.monografias.com/trabajos12/guiainf/guiainf.shtml#HIPOTES

http://www.monografias.com/trabajos6/diop/diop.shtml



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.

http://www.monografias.com/trabajos6/meti/meti.shtml

http://www.monografias.com/trabajos13/memor/memor.shtml



http://www.monografias.com/trabajos15/ms-windows/ms-windows.shtml









http://www.monografias.com/trabajos6/diop/diop.shtml

http://www.monografias.com/trabajos16/industria-ingenieria/industria-ingenieria.shtml



http://www.monografias.com/trabajos12/dispalm/dispalm.shtml





http://www.monografias.com/trabajos12/guiainf/guiainf.shtml#HIPOTES


http://www.monografias.com/trabajos14/historiaingenieria/historiaingenieria.shtml

http://www.monografias.com/trabajos15/estadistica/estadistica.shtml


http://www.monografias.com/trabajos13/diseprod/diseprod.shtml


http://www.monografias.com/trabajos16/sepa-excel/sepa-excel.shtml#historia

http://www.monografias.com/trabajos16/sepa-excel/sepa-excel.shtml#historia

http://www.monografias.com/trabajos13/histarte/histarte.shtml#ORIGEN

http://www.monografias.com/trabajos15/historia-computador/historia-computador.shtml#prpoces




¿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.


http://www.monografias.com/trabajos12/cntbtres/cntbtres.shtml



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

Documents

Transcript of Antologia DSS Completa