TALLER FINAL LOGS

SEGMENTO DOCUMENTAL.

ESTRATEGIAS:
Identificar los sistemas involucrados.
lIdentificar el alcance y objetivo para el cual se realizará la consolidación de logs.
lSincronizar el reloj de los sistemas involucrados.
lIdentificar los eventos que se desee monitorear.
lIdentificar los tipos de logs que serán almacenados.
lDefinir una estrategia de control de integridad de los archivos.
lDimensionar el tamaño, crecimiento y rotación de cada uno de los logs.
lIdentificar el mecanismo de almacenamiento de los backups.
lIdentificar las herramientas comerciales o gratuitas que pueden ayudar a examinar y correlacionar los logs.

POLÍTICAS: (DOCUMENTAR)

Las políticas más comunes son:
No almacenar
Resetearlos periódicamente
Rotarlos, manteniendo datos por un período fijo de tiempo hacia atrás
Archivar en cinta u otro medio de respaldo toda la historia
El primer método no es para nada recomendable dado que los logs son una de las principales herramientas para determinar la causa de un malfuncionamiento y para detectar algún acceso no autorizado al sistema.
La política de borrar los archivos de log cada vez que toman un tamaño que los hace molestos, si bien en la mayoría de los casos nos permite disponer de información, no nos garantiza disponer de los registros de un tiempo hacia atrás. Por otra parte si el tamaño de los logs crece excesivamente puede hacerse inmanejable extraer de ellos información o incluso pueden llegar a llenar el disco.

La práctica más usual consiste en ir "rotando" los nombres de archivo diariamente o semanalmente, de manera de ir descartando los archivos más antiguos y mantener información de una cantidad fija de días anteriores. Un ejemplo elemental de un script que se podría lanzar desde cron para realizar esto es el que sigue:
#!/bin/sh
cd /var/log
rm logfile.3
mv logfile.2 logfile.3
...
mv logfile logfile.0
cat /dev/null > logfile


LEGALIDAD: (SINCRONIZAR)

Exactitud de los archivos de log.

La exactitud significa que se puede probar que los archivos de log representan con precisión la actividad del sistema. Incluso la más pequeña imprecisión en los archivos de logs pueden llevar a cuestionar la validez de toda la evidencia.

La siguientes son pautas para que los logs estén creados con exactitud.

REGISTRAR TODO EN LOS ARCHIVOS LOGS:

Configurar los logs de los sistemas para registrar la mayoría de la información que se pueda. Mientras algunos administradores ven poca utilidad almacenar información extra, cada campo de estos archivos tiene mucho significado en a la hora de una investigación forense.

Por ejemplo, supongamos que un administrador web aduce que un hackerhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn9 [9] ha quebrantado la seguridad de su máquina y ha introducido un //backdoorhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn10 [10]//, un servidor proxy para relanzar ataques a otras máquinas. ¿Cómo se logra probar que el tráfico viene desde un usuario especifico o que fue un ataque realizado por alguien más?, mientras esto no se pueda probar siempre, entre más información se registre más probabilidad de salir exitoso en estos casos se tiene.

MANTENIENDO EL TIEMPO REAL:

Sincronizando las maquinas con un fuente de tiempo externa. En
http://tycho.usno.navy.mil/ntp.html se puede encontrar una lista de servidores NTP.

USAR MÚLTIPLES SENSORES:

Es difícil perder información de entrada a un logs si múltiples dispositivos están registrando la misma información. Combinando logs de varios dispositivos, se aumenta el valor dado a cada uno. Los logs de firewalls, IDS (Intrusion Detection System) e incluso algo tan simple comoTCPDumphttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn11 [11] puede ayudar a probar que desde una dirección IP se realizó un ataque a una maquina especifica a un tiempo específico.

En http://www.iissecurity.net/4361.htm se puede encontrar un ejemplo del uso de un Snorthttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn12 [12] como suplemento de los logs de un servidor.

LEGITIMIDAD: (ENCRIPTAR)
Autenticidad de los archivos de log:
Se puede decir que un archivo de log es autentico si se puede probar que ellos no han sido modificados desde que ellos fueron originalmente registrados. Generalmente los archivos de logs son archivos de texto muy fácilmente modificables, incluyendo su fecha y hora. Desde este aspecto no se podría dar la autenticidad pero llevando a cabo ciertos procedimientos se puede lograr este aspecto:

FIRMAS, ENCRIPCIÓN Y CHECKSUMS:

La única forma de estar absolutamente seguro que un archivo no ha sido modificado es firmar y encriptar el archivo de log usando PGPhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn13 [13] o algún otro esquema de llave-publica de encripción.

La firma de archivos es muy útil ya que si sencillamente un archivo ha sido modificado (es corrupto), este no invalida el resto de logs. Se puede utilizar herramientas como Fsumhttp://www.wikilearning.com/editor/editor/fckeditor.html?InstanceName=TA&Toolbar=Default#_ftn14 [14] que fácilmente genera MD5 hashes para los archivos.

Al encriptar los archivos se debe tener en cuenta el impacto que esto conlleva a la hora de la creación, modificación y acceso a los archivos.

ASEGURAR LA INTEGRIDAD DEL SISTEMA:

Se debe auditar permanentemente todos los cambios que se produzcan en el sistema. Si un intruso esta en capacidad de modificar cualquier archivo del sistema, los archivos de logs producidos por el mismo (sistema operativo) la validez de estos archivos como evidencia entrara en duda.

DOCUMENTACIÓN DE PROCESOS:

Mantener siempre en mente que un proceso bien establecido puede ser muy útil a la hora de evaluar autenticidad.

Establecer un proceso significa crear un// documento// que liste y detalle cada paso tomado, ya sea de forma manual o automático a la hora de recolectar la evidencia. Además, cualquier scripts que se utilice en el procesamiento y recolección de archivos de logs, deberá también contener comentarios explicando lo que exactamente se esta realizando. Las técnicas que se usen en los procesos deberán generalmente ser aceptadas legalmente para la administración y recolección de archivos de log.


CONTROL DE ACCESO

Una vez el archive de log es creado debe ser auditado y protegido para prevenir accesos no autorizados.

Si se asegura y audita un archive de log apropiadamente, se tendrá un evidencia documentada que ayuda ha establecer su credibilidad.

RESTRINGIR EL ACCESO A ARCHIVOS:

Un archive de logs necesita ciertos permisos para que la aplicación o sistema que o produce pueda registrar eventos en él. Pero luego que esto se produce el archivo se debe cerrar y nadie debe tener acceso a modificar el contenido del mismo. Se puede también considerar programar comandos para bloquear el acceso a estos archivos y auditar luego este. También se debe tener en cuenta que al cambiar la ubicación de los archivos de logs se debe establecer los permisos correctamente.

ROTACIÓN DE LOGS:

Los archivos de log pueden rápidamente consumir gran cantidad de almacenamiento en un servidor centralizado de logs, (lo cual es relativamente costoso), de igual forma determinar que archivo de log en particular en un futuro será útil en una investigación o proceso legal es muy difícil. La técnica de rotación de logs permite limitar el volumen de datos que se tienen disponibles para examinar fácilmente, en este caso en el servidor de logs, y además controlar el número de archivos de logs que estarán expuestos a un posible daño por parte de un intruso.
La estrategia de rotación de logs se basa principalmente en cambiar la ubicación de los archivos de logs a una nueva locación y renombrarlos de esta manera podrán reflejar la rotación.


BIBLIOGRAFÍA:

http://www.wikilearning.com/monografia/control_administracion_e_integridad_de_logs-estrategias_para_la_utilizacion_de_logs_como_evidencia/3485-7

LOG DE LINUX

¿Qué es un analizador de log? Los Analizadores de Log, así como de Cabeceras de Mensajes son herramientas de soporte que se encuentran ya disponibles para administradores de Google Apps. Estas herramientas permiten diagnosticar cuestiones relativas a herramientas de migración, herramientas de sincronización y la entrega de correo electrónico. Analizador de Logs: Evalua Logs de una variedad de herramientas de migración y sincronización, ofreciendo orientación en la resolución de la mayoría de los problemas visibles en los registros.

Nombre del Log	Path	Objetivo
Lastlog	/var/adm/	contiene un registro para cada usuario con la fecha y hora de su última conexión
Wtmp	/usr/adm/wtmp	almacena cada acceso al sistema y cada salida del mismo
Adm	/var/admspan>	Info administrativa del sistema
Acces_log_acces_log	/var/www/logs/access_log	archivos de registros del servidor Apache
Messages	/var/log/messages	aquí encontraremos los logs que llegan con prioridad info (información), notice (notificación) o warn (aviso).
Boot	/var/log/boot.log	Muestra mensajes referentes al arranque del sistema.
Debug	/var/log/debug	Muestra mensajes de depuracion.
Auth.log	/var/log/auth.log	se registran los login en el sistema, las veces que hacemos su, etc. Los intentos fallidos se registran en líneas con información del tipo invalid password oauthentication failure.
Daemon.log	/var/log/daemon.log	Muestra mensajes sobre demonios (permisos) o servicios corriendo en el sistema.
Dmesg	/var/log/dmesg	en este archivo se almacena la información que genera el kernel durante el arranque del sistema
Dpkg.log	/var/log/dpkg.log	Muestra un registro de los paquetes binarios instalado.
Faillog	/var/log/faillog	Muestra los intentos de acceso fallidos
Kern.log	/var/log/kern.log	se almacenan los logs del kernel, generados por klogd.
Lpr.log	/var/log/lpr.log	Muestra mensajes sobre la impresora
Mail	/var/log/mail.err   /var/log/mail.info   /var/log/mail.warn   /var/log/mail.log	Archivos varios que muestran mensajes sobre error, informacion, alertas y registro (respectivamente) para los correos (requiere tener un servicio de correos funcionando)
Mysql	/var/log/mysql.*	Archivos varios de registro para el servicio mysql (requiere tener un servicio mysql).
User.log	/var/log/user.log	Muestra informacion acerca de los procesos usados por el usuario
Xorg.0.log	/var/log/Xorg.0.log	Muestra registros de Xorg
Secure	/var/log/secure	Registra los accesos al servidor que tienen relación con procesos de autentificación.
Maillog	/var/log/maillog	Sucesos servidor de correo
Spooler	/var/log/spooler	Mensajes de cola de impresion
Entre otros	/var/log/samba	Mensajes del servicio samba

PLAN DE CONTINGENCIA PARA SISTEMAS INFORMATICOS

DEFINICION


Consiste en la identificación de aquellos sistemas de información y/o recursos informáticos aplicados que son susceptibles de deterioro, violación o pérdida y que pueden ocasionar graves trastornos para el desenvolvimiento normal de la organización, con el propósito de estructurar y ejecutar aquellos procedimientos y asignar responsabilidades que salvaguarden la información y permitan su recuperación garantizando la confidencialidad, integridad y disponibilidad de ésta en el menor tiempo posible y a unos costos razonables.

El plan de contingencia debe cubrir todos los aspectos que se van a adoptar tras una interrupción, lo que implica suministrar el servicio alternativo y para lograrlo no solo se deben revisar las operaciones cotidianas, sino que también debe incluirse el análisis de los principales distribuidores, clientes, negocios y socios, así como la infraestructura en riesgo. Esto incluye cubrir los siguientes tópicos: hardware, software, documentación, talento humano y soporte logístico; debe ser lo más detallado posible y fácil de comprender.


GUÍA GENERAL PARA ELABORAR UN PLAN DE CONTINGENCIAS



Los conceptos básicos son los siguientes:

Análisis y valoración de riesgos.
Jerarquización de las aplicaciones.
Establecimientos de requerimientos de recuperación.
Ejecución.
Pruebas.
Documentación.
Difusión y mantenimiento.

Análisis y valoración de Riesgos. El proyecto comienza con el análisis del impacto en la organización. Durante esta etapa se identifican los procesos críticos o esenciales y sus repercusiones en caso de no estar en funcionamiento. El primer componente del plan de contingencia debe ser una descripción del servicio y el riesgo para ese servicio, igualmente se debe determinar el costo que representa para la organización el experimentar un desastre que afecte a la actividad empresarial.


Se debe evaluar el nivel de riesgo de la información para hacer:

Un adecuado estudio costo/beneficio entre el costo por pérdida de información y el costo de un sistema de seguridad.
Clasificar la instalación en términos de riesgo (alto, mediano, bajo) e identificar las aplicaciones que representen mayor riesgo.
Cuantificar el impacto en el caso de suspensión del servicio.
Determinar la información que pueda representar cuantiosas pérdidas para la organización o bien que pueda ocasionar un gran efecto en la toma de decisiones.


Cuando ocurra una contingencia, es esencial que se conozca al detalle el motivo que la originó y el daño producido mediante la evaluación y análisis del problema donde se revisen las fortalezas, oportunidades, debilidades y amenazas, lo que permitirá recuperar en el menor tiempo posible el proceso perdido.

Jerarquización de las Aplicaciones. Es perentorio definir anticipadamente cuales son las aplicaciones primordiales para la organización. Para la determinación de las aplicaciones preponderantes, el plan debe estar asesorado y respaldado por las directivas, de tal forma que permita minimizar las desavenencias entre los distintos departamentos y/o divisiones.

El plan debe incluir una lista de los sistemas, aplicaciones y prioridades, igualmente debe identificar aquellos elementos o procedimientos informáticos como el hardware, software básico, de telecomunicaciones y el software de aplicación, que puedan ser críticos ante cualquier eventualidad o desastre y jerarquizarlos por orden de importancia dentro de la organización. También se deben incluir en esta categoría los problemas asociados por la carencia de fuentes de energía, utilización indebida de medios magnéticos de resguardo o back up o cualquier otro daño de origen físico que pudiera provocar la pérdida masiva de información.

Establecimientos de requerimientos de recuperación. En esta etapa se procede a determinar lo que se debe hacer para lograr una óptima solución, especificando las funciones con base en el estado actual de la organización. De esta forma es necesario adelantar las siguientes actividades: profundizar y ampliar la definición del problema, analizar áreas problema, documentos utilizados, esquema organizacional y funcional, las comunicaciones y sus flujos, el sistema de control y evaluación, formulación de las medidas de seguridad necesarias dependiendo del nivel de seguridad requerido, justificación del costo de implantar las medidas de seguridad, análisis y evaluación del plan actual, determinar los recursos humanos, técnicos y económicos necesarios para desarrollar el plan, definir un tiempo prudente y viable para lograr que el sistema esté nuevamente en operación.

Ejecución . Una vez finalizado el plan, es conveniente elaborar un informe final con los resultados de su ejecución cuyas conclusiones pueden servir para mejorar éste ante futuras nuevas eventualidades. En esta fase hay que tener muy presente que el plan no busca resolver la causa del problema, sino asegurar la continuidad de las tareas críticas de la empresa.

En la elaboración del plan de contingencias deben de intervenir los niveles ejecutivos de la organización, personal técnico de los procesos y usuarios, para así garantizar su éxito, ya que los recursos necesarios para la puesta en marcha del plan de contingencia, necesariamente demandan mucho esfuerzo técnico, económico y organizacional.

Pruebas . Es necesario definir las pruebas del plan, el personal y los recursos necesarios para su realización. Luego se realizan las pruebas pertinentes para intentar valorar el impacto real de un posible problema dentro de los escenarios establecidos como posibles. En caso de que los resultados obtenidos difieran de los esperados, se analiza si la falla proviene de un problema en el ambiente de ejecución, con lo cual la prueba volverá a realizarse una vez solucionados los problemas, o si se trata de un error introducido en la fase de conversión; en este último caso pasará nuevamente a la fase de conversión para la solución de los problemas detectados. Una correcta documentación ayudará a la hora de realizar las pruebas. La capacitación del equipo de contingencia y su participación en pruebas son fundamentales para poner en evidencia posibles carencias del plan.

Documentación. Esta fase puede implicar un esfuerzo significativo para algunas personas, pero ayudará a comprender otros aspectos del sistema y puede ser primordial para la empresa en caso de ocurrir un desastre. Deben incluirse, detalladamente, los procedimientos que muestren las labores de instalación y recuperación necesarias, procurando que sean entendibles y fáciles de seguir.

Es importante tener presente que la documentación del plan de contingencia se debe desarrollar desde el mismo momento que nace, pasando por todas sus etapas y no dejando esta labor de lado, para cuando se concluyan las pruebas y su difusión.

Difusión y mantenimiento. Cuando se disponga del plan definitivo ya probado, es necesario hacer su difusión y capacitación entre las personas encargadas de llevarlo a cargo. El mantenimiento del plan comienza con una revisión del plan existente y se examina en su totalidad realizando los cambios en la información que pudo haber ocasionado una variación en el sistema y realizando los cambios que sean necesarios.



BIBLIOGRAFÍA.



Avoiding Complete Disaster. May, 1995. Open Computing.
Bidot, Peláez. José Un Laboratorio Latinoamericano para la Protección contra los Virus Informáticos.
Cobb Stephen. 1994. Manual de seguridad para Pc y redes locales. Editorial Mc. Graw Hill.
Cook, J.W. Auditoría. 1987. Editorial Interamericana.
Echenique, José Antonio. Auditoría en informática. Editorial Mc. Graw Hill. 2001
Fine, Leonard H. 1990. Seguridad en centros de cómputo. Editorial Trillas.
Fitzgerald, Jerry. 1991. Controles Internos para Sistemas de Computación. Editorial Limusa.
Galvis P. Alvaro. 1993. Planeación estratégica informática. Universidad de los Andes.
Hernández, Hernández Enrique. 2000. Auditoría en informática. Editorial Cecsa.
Normas y procedimientos de auditoría. 1992. SAS (Statements on Auditing Standars) N°s. 41 AU 339.03, 22 AU 311, editado por el Instituto Mexicano de Contadores Públicos. A. C.
Piattini, Mario G. Auditoría Informática. 2001. Un enfoque práctico. Editorial Alfaomega.
Plata Martínez, Jesús Alberto. 1998. Curso de extensión universitaria sobre Auditoría Operacional. Universidad Nacional.
Seminario - taller Auditoría en informática. Enfoque, metodologías, técnicas y herramientas. Audisis. Ltda.
Thomas A. J., I. J. Douglas. 1987. Auditoría Informática. Editorial Paraninfo. S.A.
Ribagorda, Garnacho. Arturo. 1995. Situación Actual y Tendencias de la Seguridad de la Tecnologías de la Información.
Ribagorda, Garnacho. Arturo; J. L. Morant Ramon; J. Sancho Rodríguez. 1994. Seguridad y Protección de la Información.
Tamayo, Alzate Alonso. 2001. Sistemas de Información. Universidad Nacional de Colombia. Sede Manizales.
Tamayo, Alzate Alonso. 2001. Auditoría de Sistemas. Una visión práctica. Universidad Nacional de Colombia. Sede Manizales.

FICHA TECNICA MODELO ESPIRAL

CICLO DE VIDA
PLANIFICACIÓN: Revelación de requerimientos iniciales o luego de una iteración.
ANALISIS Y RIESGO: De acuerdo con el relevamiento de requerimientos decidimos si continuamos con el desarrollo.
IMPLEMENTACIÓN: Desarrollamos un prototipo basados en los requerimientos.
EVALUACIÓN: El cliente evalúa el prototipo, si da su conformidad, termina el proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en la siguiente interacción.

CONCEPTO
Es un modelo de proceso de software evolutivo. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
CONTEXTO DE LA APLICACIÓN ESPIRAL ENPROGRAMACIÓN
El modelo en espiral es un enfoque realista del desarrollo de sistemas. El modelo en espiral puede aplicarse a lo largo de la vida del software.
FASES
Determinar o fijar objetivos
Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.
Fijar las restricciones.
Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificación inicial.
Análisis del riesgo
Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir.
Desarrollar, verificar y validar (probar)
Tareas de la actividad propia y de prueba.
Análisis de alternativas e identificación resolución de riesgos.
Planificar
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

VENTAJAS Y DESVENTAJAS
VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora.
Como el software evoluciona a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas.
DESVENTAJAS
Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.
Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
Genera mucho tiempo en el desarrollo de sistemas.

EJEMPLOS REALES DE LA APLICACIÓN
Como equipo elegimos el modelo el modelo en espiral porque es un modelo de ciclo de vida orientado a riesgos porque, nuestro sistema aun no está completamente especificado, (esto quiere decir que está sujeto a cambios) en cuanto a los requerimientos que nuestro cliente nos pida y con este modelo creemos que nos va a dar la facilidad de cambiar y/o modificar los requerimientos anteriores.
· Determinar o fijar objetivos
Decidimos, qué proyecto íbamos a elegir.
Para donde y para quien lo vamos a realizar.
Después de la decisión del proyecto y de la aceptación que nos dio el cliente para realizar ese proyecto, empezamos a fijar objetivos y a fijar la Misión, Visión y el logo que va llevar el proyecto.
Después de tener concreto esos puntos, continuamos a realizar la entrevista al cliente, esto para ver que requerimientos va tener el proyecto que nuestro cliente necesita.
· Planificar
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.
· Desarrollar y probar
Decidimos usar el modelo en espiral, esto porque se sujeta a previos cambios.
Llevamos a cabo el desarrollo del análisis del proyecto
Realizamos actividades de prueba para el proyectó
http://elizabeth-elikas.blogspot.com/2009/12/ejemplo-de-modelo-en-espiral.html

En términos futbolísticos, la metáfora del modelo en espiral puede representar muy bien qué es y cómo se desarrolla un Mundial (junto a todo lo relativo a su preparación); todo gira en torno a una idea: si el Mundial se puede entender como una espiral repleta de bucles internos, todo aquel que pretenda llegar lejos debe tener claro que sólo lo logrará si se impulsa en cada bucle y en cada giro para crecer, sobre todo a partir de la fase decisiva del torneo. Si no, se corre un altísimo riesgo de morir en la espiral por agotamiento, desorientación absoluta o por simple mareo.

Por eso, hay que estar preparado para crecer con el Mundial, para ir haciéndose más grande a cada paso aunque en el primer bucle uno sólo pudiera ver un laberinto intangible de un mes de duración. Los que no son capaces de crecer al ritmo que marcan los bucles se quedan a medio camino (léase Inglaterra u Holanda), los que empiezan el modelo tan crecidos que creen haberlo hecho todo ya llegan tarde al cambio de ciclo (España y, sobre todo, Brasil).
Si Italia y Francia han llegado a la final será entonces porque son los que mejor han interpretado la complejidad y extensión de este torneo desde el principio, pese a que en primera instancia no nos diese esa impresión.
http://piterino.blogspot.com/2006/07/el-mundial-en-espiral.html

TALLER PUENTE VS PAGO NOMINA

GERENCIA DE PROYECTOS

TALLER 2A

1. Analizar las razones por las cuales diseñar un puente es un proyecto y pagar la nómina mensual de los empleados no lo es.
2. Pensar un ejemplo de organización, cualquier sector, plantear un proyecto operacional o transaccional.
 Objetivo
 Programa
 Proyecto
 Proceso
 Actividad
3. Analice realice una investigación de un Macro proceso:
El ministerio de educación realiza una “licitación” para adquirir 321.629 computadores, los cuales son suministrados por computadores para educar.
DESARROLLO
Respuesta 1: las razones son las siguientes:
Un proyecto es un esfuerzo realizado para obtener un objetivo específico, para este caso, el objetivo específico sería diseñar un puente; como todo proyecto tiene un inicio y un fin.
Con respecto a la nómina no es proyecto sino una operación periódica a lo largo del tiempo.
Respuesta 2:
Objetivo: Implementar mesa de servicio
Programa: Implementación de una mesa de servicio Latín América
Proyecto:
 Creación de los diferentes servicios que se van a prestar.
 Creación de las herramientas de gestión para las soluciones de estos.
Proceso:
Los procesos que se llevarán a cabo durante la ejecución del programa son:
Iniciación, planeación, ejecución, monitoreo y control.
Actividad:
Las actividades principales del proyecto son:
Para el proyecto de mesa de servicio latín América las actividades son las siguientes:
- Evaluación financiera
- Estudios técnicos
- Construcción de las herramientas de gestión, monitoreo.
Respuesta 3:
Macro Proceso:
Licitación para adquirir 321.629 computadores, los cuales son suministrados por computadores para educar.
Procesos:
Recibir ofertas
Estudios de ofertas
Selección de oferta más adecuada para licitación.

TABLA DE ERRORES HTTP DE CLIENTE Y SERVIDOR

ERRORES CLIENTE 4XX
Aunque estos problemas son técnicamente el resultado de un problema con la solicitud del cliente (por ejemplo, del navegador), mucha veces son un problema en un sitio web. Por ejemplo, si tiene un enlace que no funciona en su pantalla principal, y los visitantes lo pulsan, quizás verán un error 404.
Por esta razón, es importante monitorizar estos errores e investigar sus causas. Como éstos son algunos de los códigos más vistos por los visitantes, tal vez desee personalizar sus páginas de error en cPanel.
400 BAD REQUEST
La solicitud del usuario contiene una sintaxis incorrecta.
401 UNAUTHORIZED
El archivo solicitado requiere autenticación (un nombre de usuario y contraseña).
403 FORBIDDEN
El servidor no les permitirá a los visitantes acceder el archivo solicitado. Si un visitante ve este código de error, repase las configuraciones de permiso del archivo. También puede verificar si el archivo ha sido protegido mediante administrador de índice de Panel.
404 NOT FOUND
El servidor no pudo encontrar el archivo que el visitante solicitó. Esto error ocurre a menudo cuando el URL se escribe incorrectamente.
ERRORES SERVIDOR 5XX
Los servidores que no pueden cumplir con una solicitud aparentemente válida de un visitante causan estos errores. A menudo, necesitará la ayuda de un administrador de servidor para investigar estos errores.
También es importante considerar que, muchas veces, una cadena de servidores maneja una solicitud HTTP. Así que tal vez no sea el servidor de por sí que responda al error.
500 INTERNAL SERVER ERROR
Este error significa que el servidor ha encontrado una condición inesperada. Es un error genérico que se mostrará cuando el servidor no puede conseguir información específica acerca de la condición del error. Este error ocurre a menudo cuando no se puede cumplir una solicitud por la aplicación porque la aplicación está configurada incorrectamente.
501 NOT IMPLEMENTED
Esto significa que el servidor no apoya el método HTTP enviado por el cliente. La causa más frecuente es un servidor anticuado. Este error es poco común y normalmente requiere actualizar el servidor web.
502 BAD GATEWAY
Este error normalmente lo causa una mala configuración de los servidores intermediarios. Sin embargo, el problema ocurrirá de nuevo si hay mala comunicación de IP entre computadoras en el sistema interno de la red, cuando el ISP de cliente está sobrecargado o cuando el cortafuegos no funciona correctamente.
El primer paso para resolver el problema es limpiar el caché del cliente. Esta acción deber resultar en el uso de otro intermediario para resolver el contenido del servidor web.
503 SERVICE UNAVAILABLE
Este error ocurre cuando el servidor no puede manejar solicitudes debido a una sobrecarga temporal o porque el servidor está temporalmente cerrado por mantenimiento. El error significa que el servidor estará cerrado sólo temporeramente. Es posible recibir otros errores en lugar de 503.
Comuníquese con el administrador del servidor si el problema sigue.
504 GATEWAY TIMEOUT
Esto ocurre cuando un servidor en la cadena de retransmisiones no recibe un mensaje a tiempo de un servidor más arriba en la cadena de retransmisiones. Este problema está completamente causado por una comunicación entre computadoras "más arriba".
Para resolver este problema, comuníquese con el administrador del sistema.
505 HTTP VERSION NOT SUPPORTED
Este error ocurre cuando el servidor se niega en apoyar el protocolo HTTP que ha sido especificado por la computadora del cliente. Puede causarlo un protocolo que no fue especificado correctamente por la computadora del cliente; por ejemplo, si se especificó un número inválido de la versión.
Este error no será un problema con la instalación corriente de Panel.
506 VARIANT ALSO NEGOTIATES
Este error significa que el servidor no está configurado correctamente. Por favor, comuníquese con el administrador del sistema para resolver este problema.
507 INSUFFICIENT STORAGE
Este código significa que no queda mucha memoria libre en el servidor. Esto ocurrirá cuando una aplicación solicitada no puede asignar los recursos del sistema necesarios para ejecutarla.
Para resolver este problema, puede necesitar borrar cualquier documento innecesario para liberar espacio en el disco duro del servidor, ampliar la memoria o, simplemente, hace falta reiniciarlo.
Por favor, comuníquese con el administrador del sistema para obtener más información sobre este mensaje de error.
509 BANDWIDTH LIMIT EXCEEDED
Este error ocurre cuando el límite de la banda ancha impuesto por el administrador del sistema ha llegado a su límite. La única manera de arreglar este problema es esperar hasta que se reajuste el límite en el siguiente ciclo.
Comuníquese con el administrador para obtener más información acerca de cómo adquirir más banda ancha.
510 NOT EXTENDED
Este error ocurre cuando una extensión adjunta a la solicitud de HTTP no está apoyada por el servidor web.
Para resolver este problema, quizás tendrá que actualizar el servidor. Por favor, comuníquese con el administrador del sistema para obtener más información.