Bruce Sterling



Descargar 0.91 Mb.
Página20/24
Fecha de conversión26.03.2018
Tamaño0.91 Mb.
1   ...   16   17   18   19   20   21   22   23   24
Los cambios recientes se generan desde la actividad de orden de servicio (nuevos servicio, cambio de dirección, etc...)y se compila en un fichero diario por el centro de E911 (el ordenador del ALI/DMS E911).
El SSIM/I&M es responsable de la instalación y reparación del equipamiento del PSAP. El equipamiento del PSAP incluye un controlador ANI, un controlador ALI, conjunto de datos, cables, equipos, y otro equipamiento periférico que no es propio. El SSIM/I&M es responsable de establecer del mantenimiento de kits de pruebas, completado con otras piezas para el mantenimiento del PSAP. Este incluye equipamiento de prueba, conjuntos de datos, y partes del controlador ANI/ALI.
El Centro de Servicios Especiales (SSC) o el Centro Principal de Información (MAC) sirven como enlace para informar de todos los problemas comunicados por el cliente (PSAP). El SSC/MAC envía los problemas a las organizaciones adecuadas para que se encarguen y sigan el estado de los problemas, escalándolos cuando sea necesario. El SSC/MAC cerrará los problemas con el cliente. El SSC/MAC analizará todos los problemas y los rastreos "crónicos" del PSAP.
El Centro Corporativo de Red de Comunicaciones (CCNC) probará y enviará los problemas en todos los nodos a los circuitos de servidores. Todos los circuitos del E911 son clasificados como propiedad de una compañía oficial.
El Centro de Operaciones para el Mantenimiento del Miniordenador (MMOC) mantiene el hardware del ordenador del E911 (ALI/DMS) en el emplazamiento del servidor. Este MMOC es además responsable de la monitorización del sistema informando, por supuesto, al PSAP y a los MMOC, SCC o SSC/MAC locales de los problemas del sistema. El personal del MMOC además maneja los programas de software que mantienen la base de datos TN bajo la dirección del centro del E911. El mantenimiento del ordenador nodo (el interface entre el PSAP y el ordenador ALI/DMS) es una función del MMOC en el emplazamiento del NODO. Los MMOC en el emplazamiento del NODO pueden además implicarse en el testeo del NODO a los circuitos de servidores. El MMOC ayudará además en el Servidor al PSAP y relacionará los problemas de la red de datos no resueltos a través de procedimientos aclarando el problema estándar.
El Centro de Instalación y Mantenimiento (IMC) es responsable de los problemas remitidos por el abonado del E911, que no sean problemas de línea.
El Centro E911 realiza el papel de Administración del Sistema y es responsable de las operaciones globales del software del ordenador del E911. El Centro E911 hace análisis del problema de la A-Z y facilita información estadística del funcionamiento del sistema.
Este análisis incluye preguntas del procesamiento del PSAP (informes de problemas) y problemas referidos a la red. El Centro E911 además realiza el procesamiento de cambios recientes en tándem y facilita información al RCMAC de la entrada tándem. El Centro E911 es responsable del procesamiento diario de la base de datos del ordenador ALI/DMS y facilita los ficheros de error, etc... al Departamento de Servicios al Cliente para su investigación y corrección. El Centro E911 participa en todas las implementaciones del sistema y en el mantenimiento continuo y ayuda en el desarrollo de procedimientos, preparando e informando a todos los grupos.
Al recibir algún grupo un problema 911 desde el SSC/MAC debe terminar el problema con el SSC/MAC o facilitar un estado si el problema ha sido enviado a otro grupo. Esto permitirá al SSC/MAC facilitar un estado anterior al cliente o escalarlo en el apropiado.
Al recibir algún grupo un problema desde el emplazamiento del servidor (MMOC o CCNC) debe cerrar el problema anterior de ese grupo.
El MMOC debe notificar al SSC/MAC apropiado, que el Servidor, el Nodo o todos los circuitos del Nodo caen tanto que el SSC/MAC puede contestar las preguntas del cliente y puede ser llamado por los PSAP. Esto eliminará los informes de problemas duplicados. En interrupciones completas el MMOC investigará los procedimientos de escalada para un Nodo después de dos horas y para un PSAP después de cuatro horas. Adicionalmente el MMOC notificará al SSC/MAC apropiado que el Servidor, el Nodo o todos los circuitos del Nodo han caído.
El PSAP llamará al SSC/MAC para comunicar los problemas del E911. La persona que comunique el problema puede no tener un I.D. de circuito y por tanto comunicará al PSAP el nombre y la dirección. Los problemas de algunos PSAP no tienen circuito específico. En estos casos donde el que llama no puede facilitar un I.D. de circuito, el SSC/MAC necesita averiguar el I.D. del circuito, usando el perfil del PSAP. Bajo ningún concepto el Centro del SSC/MAC rechazará hacerse cargo del problema. El problema del E911 debe manejarse tan cuidadosamente como sea posible, con el SSC/MAC facilitando tanta asistencia como sea posible mientras se atiende el problema comunicado por el que ha llamado.
El SSC/MAC examinará y probará el problema para determinar la organización receptora apropiada, basándose en el siguiente criterio:
Problema del equipamiento del PSAP: SSIM/I&M
Problema del circuito: SSC/MAC
Problema de la red de voz: SCC (número del grupo de la línea troncal(5))
Problema que afecta a múltiples PSAP (ALI no comunica desde todos los PSAP): Ponerse en contacto con MMOC para revisar los problemas del NODO o del servidor antes de probar de nuevo.

El SSC/MAC localizará el estado de los problemas comunicados y le escalara al más apropiado. El SSC/MAC cerrara los informes cliente/compañía con el inicio del contacto.


Los grupos con responsabilidades de mantenimientos especificas investigaran sobre los problemas "crónicos" solicitados desde el SSC/MAC y el subcomité de mantenimiento continuo.
Todos los problemas del E911 del tipo "fuera de servicio" son prioritarios. Para el PSAP un enlace caído es considerado un problema prioritario y debe ser manejado como si el PSAP estuviera aislado.
El PSAP comunicará los problemas con el controlador ANI, con el controlador ALI o con el equipamiento al SSC/MAC.
NO ANI: Cuando el PSAP comunica NO ANI (la pantalla digital de demostración está en blanco) pregunta si esta condición existe en todas las pantallas y en todas las llamadas. Esto es importante para diferenciar entre pantallas en blanco y pantallas que muestran 911-00xx o todo ceros.
Cuando el PSAP presenta todas las pantallas de todas la llamadas pregunta si hay alguna voz en contacto. Si no hay voz de contacto el problema debe ser enviado al SSC inmediatamente, ya que las llamadas al 911 no se están recibiendo, lo cual puede exigir un enrutamiento alternativo de las llamadas a otro PSAP.

(1) Servicio de emergencia.

(2) Se refiere al funcionamiento que emplean este tipo de centralitas.

(3) Departamento que se encarga del marketing aplicado a la red.

(4) Punto en el que se ramifica una red.

(5) Línea principal.



John Nagle leyó el Documento E911. Sacó sus propias conclusiones. Y le llevó a Zenner y a su equipo una enorme caja llena hasta los topes de material similar, obtenido sobre todo en las bibliotecas de Ingeniería de la Universidad de Stanford. Durante el juicio, el equipo de la defensa - formado por Zenner, media docena de otros abogados, Nagle, Neidorf, y la experta en seguridad informática Dorothy Denning, analizó meticulosamente línea por línea el Documento E911.
La tarde del 25 de julio de 1990, Zenner empezó a interrogar a una mujer llamada Billie Williams, una administradora de servicio de Southern Bell en Atlanta. La Sta. Williams tenía a su cargo el Documento E911. (Ella no era la autora - su "autor" original era un jefe de personal de Southern Bell llamado Richard Helms. Sin embargo, el Sr. Helms no debería ser considerado el único responsable; muchos técnicos del personal de telecomunicaciones y de mantenimiento habían corregido y modificado el Documento. Más que haber sido obra de un único autor, había sido construido con bloques de jerga técnica).
La Sta. Williams había sido llamada a declarar como testigo de la acusación, y había tratado de explicar la estructura técnica básica del sistema E911, ayudándose de gráficos y esquemas.
Ahora era el turno de Zenner. En primer lugar, demostró que el "sello de propiedad" que había usado Bellsouth en el Documento E911 se colocaba en todos y cada uno de los documentos que escribía Bellsouth - miles de documentos. "No publicamos nada que no sea de nuestra propia compañía", explicó la Sta. Williams. "Cualquier documento de la empresa de esta clase es considerado de su propiedad". Nadie se encargaba de determinar qué publicaciones necesitaban una protección especial. Todas eran especiales, no importa lo triviales que fueran ni de qué trataran - se ponía el sello en cualquier documento al terminar de escribirlo, y nunca se quitaba ese sello.
Zenner preguntó ahora si los gráficos que ella había estado usando para explicar la mecánica del sistema E911 eran también "propiedad de la empresa". ¿Eran información pública esos esquemas y gráficos, todos sobre PSAPs, ALIs, nodos, conmutadores locales finales? ¿Podría sacar los gráficos a la calle y mostrárselos a cualquier persona, "sin violar algún concepto de propiedad de Bellsouth"?
La Sta. Williams se mostró algo confusa, pero finalmente confirmó que los gráficos eran públicos.
"Pero esto que usted dijo aquí, ¿no es básicamente lo que apareció en Phrack?"
La Sta. Williams lo negó.
Zenner señaló ahora que la edición del Documento E911 en Phrack era sólo la mitad del documento E911 original (lo que Prophet había logrado sustraer). La mitad había sido borrada - editada por Neidorf.
La Sta. Williams dijo que "la mayoría de la información que hay en el archivo de texto es redundante".
Zenner continuó con su interrogatorio. Exactamente, ¿cuántos bits de información del Documento eran, de hecho, algo desconocido por el público? ¿La situación de los ordenadores del sistema E911? ¿Números de teléfono del personal de telecomunicaciones? ¿Subcomités de mantenimiento en activo?
Entonces se lanzó a la carga. "¿Conoce usted el Documento de Referencia Técnica de Bellcore TR-TSY-000350?" Su título oficial era, explicó Zenner, "Interfaces de Puntos de Respuesta de Seguridad Pública E911 entre Conmutadores 1-1AESS y Equipos de las Instalaciones del Cliente". Contenía información técnica altamente detallada y específica sobre el sistema E911. Fue publicado por Bellcore, y costaba unos 20 dólares.
Mostró a la testigo un catálogo de Bellcore que listaba miles de documentos de ésta y de todas las Baby Bells, incluyendo a Bellsouth. El catálogo, dijo Zenner, era gratuito. Cualquiera que tuviera una tarjeta de crédito podía llamar al número gratuito 800 de Bellcore y encargar cualquiera de los documentos, sin que se le preguntara nada. Incluyendo, por ejemplo, "Interfaces del Servicio E911 de Bellsouth para Equipos en las Instalaciones del Cliente en un Punto de Respuesta de Seguridad Pública".
Zenner dio a la testigo una copia de "Interfaces del Servicio E911 de Bellsouth", que costaba, mirando el catálogo, 13 dólares. "Examínelo cuidadosamente", pidió a la Sta. Williams, "y dígame si contiene o no al menos el doble de información detallada sobre el sistema E911 de Bellsouth que lo que apareció en Phrack".
"Usted quiere que yo...", musitó la Sta. Williams. "No le entiendo".
"Examínelo cuidadosamente", insistió Zenner. "Mire este documento, y cuando haya acabado, dígame si contiene o no al menos el doble de información detallada sobre el sistema E911 de Bellsouth que lo que apareció en Phrack".
"Lo de Phrack no salió de aquí", dijo la Sta. Williams.
"¿Cómo dice?", preguntó Zenner.
"Lo de Phrack no salió de aquí".
"No puedo oírla bien", dijo Zenner.
"Lo de Phrack no salió de aquí. No comprendo qué es lo que usted me pide que haga".
"Supongo que no", dijo Zenner.
En este momento, el caso de la acusación quedó herido de muerte. La Sta. Williams estaba anonadada. Su confusión era auténtica. Lo de Phrack no se había escrito a partir de un documento público de Bellcore. El Documento E911 de Phrack había sido robado de los ordenadores de su propia compañía, de sus archivos de texto, los que habían escrito y revisado con mucho esfuerzo sus propios colegas.
Pero el "valor" del Documento se había reducido a la nada. No valía ochenta de los grandes. De acuerdo con Bellcore, eran sólo trece pavos. Y la terrible amenaza que su conocimiento al parecer suponía se había reducido a un espantajo. La misma Bellcore estaba vendiendo material mucho más detallado y "peligroso" a cualquiera que tuviera una tarjeta de crédito y un teléfono.
En realidad, Bellcore no daba esta información a cualquiera. Se la daba a cualquiera que la pidiera, pero no muchos la pedían. Poca gente sabía que Bellcore disponía de un catálogo gratuito y de un número 800. John Nagle lo sabía, pero con seguridad el típico phreak adolescente no. "Tuc", un amigo de Neidorf y colaborador ocasional de Phrack, lo sabía, y Tuc había sido de gran ayuda para el equipo de la defensa trabajando entre bastidores. Pero la Legion of Doom no lo sabía, si no, no habrían perdido tanto tiempo rebuscando entre la basura. Cook no lo sabía. Foley tampoco. Ni Kluepfel. La mano derecha de Bellcore no sabía lo que hacía la mano izquierda. La mano derecha estaba aplastando hackers sin piedad, mientras que la izquierda distribuía propiedad intelectual de Bellcore a cualquiera que estuviera interesado en las trivialidades técnicas de un sistema telefónico - aparentemente, casi nadie.
El underground digital estaba tan pobremente organizado que no habían llegado a descubrir este tesoro repleto de riquezas sin vigilar. La torre de marfil de los de telecomunicaciones estaba tan envuelta en la niebla de su propia oscuridad técnica que se había dejado todas las puertas y ventanas abiertas de par en par. Y nadie se había dado cuenta.
Zenner puso otro clavo en la tapa del ataúd. Mostró un ejemplar impreso de Telephone Engineer & Management, una importante publicación quincenal del sector que cuesta 27 dólares al año. Este número en concreto de TE&M, llamado "Actualización del 911", incluía una miríada de detalles técnicos sobre el servicio 911 y un glosario mucho más extenso que el de Phrack.
En este punto, por así decirlo, el juicio se desbocó. Tim Foley testificó con respecto a los interrogatorios que realizó a Neidorf. La declaración por escrito de Neidorf en la que admitía que sabía que el Documento E911 había sido robado se leyó oficialmente ante el tribunal.
Se dio a conocer otro asunto: "Terminus" le había pasado una vez a Neidorf un software UNIX de AT&T, un programa de login que había sido alterado astutamente para que capturara contraseñas. El propio software UNIX era una propiedad de AT&T ilegalmente copiada, y las alteraciones que había introducido "Terminus" lo habían transformado en un dispositivo que facilitaba la intrusión en un ordenador. Terminus se acabaría declarando culpable del robo de este software, y la brigada de Chicago le enviaría a prisión por ello. Pero era de dudosa relevancia en el caso Neidorf. Neidorf no había escrito el programa. Ni siquiera se le había acusado de usarlo. Y Neidorf no había sido acusado por robo de software o por poseer un programa que capturara contraseñas.
Al día siguiente, Zenner pasó a la ofensiva. Los activistas pro derechos civiles tenían ahora su propio misterioso armamento legal aún no probado dispuesto para lanzarlo - El Acta sobre Privacidad en las Comunicaciones Electrónicas (ECPA) de 1986, Código de EE.UU. 18, Sección 2701 y siguientes. La Sección 2701 considera un crimen acceder intencionadamente sin autorización a una instalación en la que se proporcione un servicio de comunicación electrónica - es, en esencia, una ley antipinchazos y antiespionaje, preparada para establecer la protección tradicional de los teléfonos en otros canales electrónicos de comunicación. Aunque impone penas a los fisgones aficionados, la Sección 2703 de la ECPA también impone algunas restricciones a los pinchazos realizados por la policía.
El Servicio Secreto, en la persona de Tim Foley, había enviado a Richard Andrews una orden de registro autorizada por un tribunal federal en su persecución de Prophet, el Documento E911 y el software de Terminus. Pero según la ECPA, el "proveedor de un servicio de computación remoto" tenía el derecho a recibir una "notificación previa" del gobierno si se iba a realizar una inspección. Richard Andrews y su nodo UNIX base, Jolnet, no habían recibido una "notificación previa". ¡Tim Foley había así violado la ECPA y había cometido un delito electrónico! Zenner solicitó al juez interrogar a Foley sobre sus delitos electrónicos.
Cook protestó argumentando que Jolnet era una BBS de propiedad privada, y por tanto no estaba protegida por la ECPA. El juez Bua aceptó la petición del gobierno que solicitaba que no se realizara el interrogatorio sobre este punto, y la ofensiva de Zenner fracasó. Este fue, sin embargo, el primer asalto directo que cuestionaba la legalidad de las acciones de la Brigada de Delitos Informáticos - la primera insinuación de que ellos mismos habían violado la ley y de que, quizás, se les iba a pedir cuentas por ello.
De cualquier forma, Zenner no necesitaba realmente la ECPA. En lugar de eso, acribilló a preguntas a Foley sobre las claras contradicciones en el supuesto valor del Documento E911. También puso en evidencia el embarazoso hecho que suponía el que el ultrasecreto Documento E911 había estado durante meses en Jolnet, y Kluepfel lo sabía, aunque no hizo nada.
Por la tarde, la acusación llamó a declarar a Prophet. (Prophet, como ya se ha dicho, también había sido implicado en el caso como compañero de actividades delictivas de Neidorf.) En Atlanta, Prophet se había declarado culpable de cargos por conspiración, fraude por medios electrónicos y transporte interestatal de propiedad robada. Los dos últimos cargos estaban relacionados directamente con el Documento E911.
Prophet, de veinte años, se mostraba arrepentido, respondiendo a las preguntas educadamente pero con un murmullo apenas audible, cayendo en picado el tono de su voz al final de las frases. Se le pedía constantemente que hablara más alto.
Cook, al interrogar a Prophet, le hizo admitir que una vez había tenido "un problema con las drogas", tomando anfetaminas, marihuana, cocaína y LSD. Esto podría haber hecho creer al jurado que los "hackers" son, o pueden ser, personas con vidas sórdidas, pero también pudo dañar en cierta forma la credibilidad de Prophet. Zenner sugirió después que las drogas podrían haber afectado a la memoria de Zenner. El otro hecho interesante que se descubrió es que Prophet nunca se había encontrado físicamente con Craig Neidorf. Ni siquiera conocía el verdadero nombre de Neidorf - al menos, hasta el juicio.
Prophet confirmó los hechos básicos de su carrera de hacker. Era un miembro de Legion of Doom. Había utilizado ilegalmente códigos, había accedido a centrales de conmutación y había redireccionado llamadas, había pasado muchas horas en BBS piratas. Había entrado en el ordenador AIMSX de Bellsouth, había copiado el Documento E911, lo había guardado en Jolnet, se lo había enviado a Neidorf. Neidorf y él lo habían editado, y Neidorf sabía de dónde procedía.
Zenner, sin embargo, hizo que Prophet confirmara que Neidorf no era un miembro de Legion of Doom, y que no había empujado a Prophet a entrar en los ordenadores de Bellsouth. Neidorf no había incitado a Prophet ni al fraude ni al robo. Prophet también admitió que no sabía de ningún caso en el que Neidorf hubiera entrado ilegalmente en ningún ordenador. Nadie de Legion of Doom consideraba a Craig Neidorf un "hacker". Neidorf no era un loco del UNIX, y carecía de los conocimientos y la habilidad necesarios para acceder ilegalmente a un ordenador. Neidorf simplemente publicaba una revista.
El viernes 27 de julio de 1990 el caso contra Neidorf se vino abajo. Cook solicitó que se archivara el caso, citando "información de la que disponemos ahora y que no poseíamos al comenzar el juicio". El juez Bua elogió a la acusación por esta acción, que describió como "muy responsable", y declaró que se archivaba el caso.
Neidorf era un hombre libre. Su defensa, sin embargo, se había cobrado un alto precio en él y en su familia. Meses de su vida se habían visto consumidos en la angustia; había visto cómo sus amigos más íntimos le miraban como a un criminal. Le debía a sus abogados unos cien mil dólares, a pesar de una generosa contribución de Mitch Kapor.
Neidorf no fue declarado inocente. Simplemente, se archivó el caso. De todas formas, el 9 de septiembre de 1991 el juez Bua concedió a Neidorf la eliminación de todo su archivo de acusación. Se ordenó al Servicio Secreto de Estados Unidos que destruyera todas las huellas dactilares, fotografías y fichas del arresto y procesamiento de Neidorf, incluyendo sus documentos en papel y sus archivos informáticos.
Neidorf volvió a la universidad, decidido a convertirse en abogado. Habiendo visto cómo funcionaba el sistema de justicia, Neidorf perdió buena parte de su entusiasmo por el simple poder técnico. En el momento de escribir este libro, Craig Neidorf trabaja en Washington como investigador contratado por la American Civil Liberties Union.
#
El resultado del juicio a Neidorf hizo que la EFF pasara de ser una voz en el desierto a ser la estrella de la nueva frontera.
Legalmente hablando, el caso Neidorf no fue un triunfo aplastante para ninguno de los que tuvieron relación con él. No se habían establecido principios constitucionales. Un tema como la "libertad de prensa" de los editores electrónicos había permanecido en el limbo legal. El público no comprendió bien algunas cosas del caso. Mucha gente creyó que Neidorf había sido declarado inocente y liberado de todas sus deudas legales por Kapor. La verdad era que el gobierno simplemente había abandonado el caso, y que la familia de Neidorf se había empeñado para poder defenderle.
Pero el caso Neidorf proporcionó una única frase demoledora y con gran resonancia pública: Los federales decían que valía ochenta de los grandes, y sólo valía trece pavos.
Este es el elemento más memorable del caso Neidorf. Ningún informe serio sobre el caso lo obvió. Incluso los policías no podían leer esto sin sentir un escalofrío. Dejaba en evidencia la credibilidad pública de los agentes que realizaron la cacería de hackers.
Sin embargo, la caza continuó. Los dos cargos contra Prophet que se basaban en el Documento E911 fueron silenciosamente olvidados en su sentencia - aunque Prophet se había declarado culpable. La acusación federal de Georgia pidió sin dudar penas de cárcel para los Tres de Atlanta, insistiendo en "la necesidad de enviar un mensaje a la comunidad", "el mensaje que necesitan oír los hackers de todo el país".
Hubo gran cantidad de referencias en sus conclusiones a las terribles cosas que habían hecho otros hackers (aunque los Tres de Atlanta no hubieran cometido esos delitos). Hubo además mucha especulación sobre las terribles cosas que los Tres de Atlanta podrían haber hecho y eran capaces de hacer (incluso aunque no las hubieran hecho). Los argumentos de la acusación triunfaron. Se envió a prisión a los Tres de Atlanta: Urvile y Leftist fueron condenados a 14 meses cada uno, mientras que Prophet (un reincidente) fue condenado a 21 meses.
También se condenó a los Tres de Atlanta a pagar enormes multas como "compensación": 233.000 dólares cada uno. Bellsouth dijo que los acusados habían "robado información de acceso a ordenadores propiedad de la compañía por valor de 233.880 dólares" - específicamente, 233.880 dólares por unas contraseñas y direcciones de conexión. La sorprendente reclamación de Bellsouth, que daba un valor altísimo a sus contraseñas y direcciones de acceso fue aceptada sin pestañear por el tribunal de Georgia. Más aún (como si quisieran enfatizar su naturaleza teórica), esta enorme suma no se repartió entre los Tres de Atlanta, sino que cada uno de ellos tenía que pagar la cantidad fijada.



Compartir con tus amigos:
1   ...   16   17   18   19   20   21   22   23   24


La base de datos está protegida por derechos de autor ©psicolog.org 2019
enviar mensaje

    Página principal
Universidad nacional
Curriculum vitae
derechos humanos
ciencias sociales
salud mental
buenos aires
datos personales
Datos personales
psicoan lisis
distrito federal
Psicoan lisis
plata facultad
Proyecto educativo
psicol gicos
Corte interamericana
violencia familiar
psicol gicas
letras departamento
caracter sticas
consejo directivo
vitae datos
recursos humanos
general universitario
Programa nacional
diagn stico
educativo institucional
Datos generales
Escuela superior
trabajo social
Diagn stico
poblaciones vulnerables
datos generales
Pontificia universidad
nacional contra
Corte suprema
Universidad autonoma
salvador facultad
culum vitae
Caracter sticas
Amparo directo
Instituto superior
curriculum vitae
Reglamento interno
polit cnica
ciencias humanas
guayaquil facultad
desarrollo humano
desarrollo integral
redes sociales
personales nombre
aires facultad