«Хакерский разгром: Закон и беспорядок на электронном рубеже»

Но суд над Knight Lightning 24–27 июля 1990 года сделал этого конкретного «хакера» известной на всю страну публичной фигурой. Не будет никакого особого вреда ни ему самому, ни его семье, если я повторю давно установленный факт: его зовут Крейг Нейдорф (произносится как НЭЙ-дорф).

Суд присяжных над Нейдорфом проходил в Окружном суде США по северному округу штата Илинойс (восточное отделение) под председательством судьи достопочтенного Николаса Дж. Буа. Соединенные Штаты Америки выступали в качестве истца, ответчиком был г-н Нейдорф. Адвокатом ответчика был Шелдон Т. Зеннер из чикагской фирмы Katten, Muchin and Zavis.

Обвинение возглавляли столпы чикагской Целевой группы по борьбе с компьютерным мошенничеством и злоупотреблениями: Уильям Кук, Колин Д. Кафлин и Дэвид А. Глокнер, все — помощники прокурора США. Сотрудником Секретной службы по ведению дела был Тимоти М. Фоли.

Напомним, что Нейдорф был соредактором подпольного хакерского «журнала» под названием Phrack. Phrack был полностью электронным изданием, распространяемым через доски объявлений и по электронным сетям. Это было любительское издание, которое раздавалось бесплатно. Нейдорф никогда не зарабатывал денег на своей работе в Phrack. То же самое касалось и его неофициального соредактора «Тарана Кинга», и многочисленных авторов Phrack.

Однако чикагская Целевая группа по борьбе с компьютерным мошенничеством и злоупотреблениями решила преследовать Нейдорфа как мошенника. Официально признать, что Phrack — это «журнал», а Нейдорф — «издатель», означало открыть ящик Пандоры проблем Первой поправки со стороны обвинения. Поступить так — означало подыграть Зеннеру и его советникам из EFF, в число которых теперь входила фаланга видных нью-йоркских адвокатов по гражданским правам, а также грозный юридический штат фирмы Katten, Muchin and Zavis. Вместо этого обвинение сделало упор на мошенничество с устройствами доступа: раздел 1029 титула 18, раздел, из которого Секретная служба черпала свою самую прямую юрисдикцию в отношении компьютерных преступлений.

Вменяемые Нейдорфу преступления вращались вокруг документа E911. Его обвиняли в том, что он вступил в мошеннический сговор с Профетом, который, как помнит читатель, был членом атлантской группировки LoD, незаконно скопировавшим документ E911 из системы BellSouth AIMSX.

Сам Профет также был соподсудимым по делу Нейдорфа, частью предполагаемой «мошеннической схемы» по «краже» документа E911 компании BellSouth (и пересылке этого документа через границы штатов, что помогло закрепить за процессом Нейдорфа статус федерального дела). Профет, в духе полного сотрудничества, согласился дать показания против Нейдорфа.

По сути, все три члена атлантской команды были готовы дать показания против Нейдорфа. Их собственные федеральные прокуроры в Атланте предъявили атлантской тройке обвинения в: (a) заговоре, (b) компьютерном мошенничестве, (c) мошенничестве с использованием электронных средств связи, (d) мошенничестве с устройствами доступа и (e) межштатной транспортировке краденого имущества (титул 18, разделы 371, 1030, 1343, 1029 и 2314).

Столкнувшись с этой лавиной неприятностей, Профет и Лефтист уклонились от публичного суда и признали себя виновными по смягченным обвинениям — по одному пункту обвинения в заговоре на каждого. Урвайл признал себя виновным по тому странному пункту раздела 1029, который объявляет незаконным владение «пятнадцатью или более» нелегальными устройствами доступа (в его случае — компьютерными паролями). А вынесение приговора им было назначено на 14 сентября 1990 года — уже после суда над Нейдорфом. Можно было предположить, что в качестве свидетелей они будут вести себя послушно.

Однако Нейдорф не признавал себя виновным. Почти все остальные, попавшие под жернова облавы, «полностью сотрудничали со следствием» и признали себя виновными в надежде на смягчение приговоров. (Стив Джексон был заметным исключением, разумеется, и с самого начала решительно заявлял о своей невиновности. Но Стив Джексон не мог добиться дня в суде — Стив Джексону вообще никогда не предъявляли никаких обвинений в преступлении).

Нейдорфа убеждали признать вину. Но Нейдорф специализировался на политологии и не горел желанием отправляться в тюрьму за «мошенничество», когда он не заработал никаких денег, не взламывал ни один компьютер и издавал журнал, который, по его мнению, защищен Первой поправкой.

Суд над Нейдорфом был ЕДИНСТВЕННЫМ судебным процессом за всю историю облав, в котором рассматриваемые вопросы действительно выносились на открытое разбирательство перед судом присяжных из американских граждан.

Нейдорф тоже сотрудничал со следователями. Он добровольно передал большую часть улик, которые привели к предъявлению обвинения ему самому. Он уже признался в письменной форме, что знал о том, что документ E911 был украден до того, как он «опубликовал» его в Phrack, — или, с точки зрения обвинения, незаконно переслал по проводам краденое имущество в нечто, выдававшем себя за «публикацию».

Но даже если бы «публикация» документа E911 не была признана преступлением, это не спасло бы Нейдорфа от ответственности. Нейдорф все равно получил документ E911, когда Профет переслал его ему из узла Jolnet Рича Эндрюса. В том случае он уж точно не был «опубликован» — это была хакерская добыча, в чистом виде перевезенная через границы штатов.

Чикагская Целевая группа добилась от большого жюри Чикаго предъявления Нейдорфу обвинений по такому набору пунктов, который мог упечь его за решетку на тридцать лет. Когда часть этих обвинений была успешно оспорена еще до того, как Нейдорф предстал перед судом, чикагская Целевая группа переформулировала обвинение так, что ему грозил возможный тюремный срок более чем в шестьдесят лет! Будучи правонарушителем впервые, Нейдорф вряд ли получил бы столь суровый приговор на практике; но чикагская Целевая группа явно намеревалась добиться тюремного заключения для Нейдорфа, а его заговорщический «журнал» навсегда закрыть. Это было федеральное дело, и Нейдорфа обвиняли в мошеннической краже имущества на сумму почти в восемьдесят тысяч долларов.

Уильям Кук твердо верил в резонансные судебные процессы с символическим подтекстом. Он часто публиковал статьи о своей работе в профессиональной прессе по вопросам безопасности, утверждая, что «широкой общественности и в особенности компьютерному сообществу должен быть послан четкий сигнал о том, что несанкционированные атаки на компьютеры и кража компьютеризированной информации не будут терпеться судами».

Вопросы были сложными, тактика обвинения — несколько неортодоксальной, однако до сих пор чикагская Целевая группа действовала уверенно. В 1989 году Целевая группа прямо на лету поймала «Shadowhawk», которого приговорили к девяти месяцам тюремного заключения и штрафу в 10 000 долларов. Дело Shadowhawk затрагивало обвинения по разделу 1030, статье о «компьютерах, представляющих федеральный интерес».

Shadowhawk на самом деле не был поклонником компьютеров, представляющих «федеральный интерес» как таковых. Напротив, Shadowhawk, владевший домашним компьютером AT&T, похоже, питал особую агрессию к AT&T. Он хвастался на подпольных досках «Phreak Klass 2600» и «Dr. Ripco» своими навыками взлома AT&T и своим намерением обрушить национальную телефонную систему AT&T. Хвастовство Shadowhawk заметил Генри Клюпфель из Bellcore Security, гроза пиратских досок, чьи отношения с чикагской Целевой группой были давними и тесными.

Целевая группа успешно доказала, что раздел 1030 применим к подростку Shadowhawk, несмотря на возражения его адвоката. Shadowhawk проник в компьютер, «принадлежащий» Ракетному командованию США и лишь «управляемый» AT&T. Он также проник в компьютер AT&T, находящийся на базе ВВС Роббинс в Джорджии. Атака на AT&T представляла «федеральный интерес», независимо от того, планировал это Shadowhawk или нет.

Целевая группа также убедила суд, что фрагмент программного обеспечения AT&T, который Shadowhawk незаконно скопировал из Bell Labs, «экспертная система искусственного интеллекта C5», стоил кругленький миллион долларов. Адвокат Shadowhawk утверждал, что Shadowhawk не продавал программу и не извлек никакой прибыли из незаконного копирования. И в действительности экспертная система C5 была экспериментальным ПО и не имела установленной рыночной стоимости, поскольку никогда раньше не выходила на рынок. Тем не менее оценка самой AT&T в «один миллион долларов» для ее собственного нематериального имущества была принята судом без возражений. И суд согласился с государственными прокурорами в том, что Shadowhawk продемонстрировал явное «намерение совершить мошенничество», получил ли он какие-либо деньги или нет. Shadowhawk отправился в тюрьму.

Другим известным триумфом Целевой группы было осуждение и тюремное заключение «Kyrie». Kyrie, истинная обитательница цифрового криминального подполья, была 36-летней гражданкой Канады, осужденной и заключенной в тюрьму за телекоммуникационное мошенничество в Канаде. После освобождения из тюрьмы она бежала от гнева Canada Bell и Королевской канадской конной полиции и в конце концов очень неразумно обосновалась в Чикаго.

«Kyrie», которая также называла себя «Междугородная справочная» («Long Distance Information»), специализировалась на злоупотреблениях голосовой почтой. Она собирала большое количество угнанных кодов межгорода, а затем зачитывала их вслух в серии корпоративных систем голосовой почты. Kyrie и ее друзья были цифровыми сквоттерами в корпоративных системах голосовой почты, используя их практически так же, как если бы они были пиратскими досками объявлений, а затем двигаясь дальше, когда их болтовня засоряла систему и владельцы неизбежно прозревали. Последователи Kyrie представляли собой рыхлое племя из полутора сотен телефонных фрикеров, которые следовали по ее пиратскому следу от машины к машине, страстно умоляя о ее услугах и экспертизе.

Адепты Kyrie передавали ей украденные номера кредитных карт в обмен на ее украденную «информацию о междугородной связи». Некоторые из клиентов Kyrie расплачивались с ней наличными, получая с помощью мошенничества наличные авансы по кредитным картам через Western Union.

Kyrie неустанно путешествовала, в основном за счет авиабилетов и гостиничных номеров, которые она добывала мошенническим путем с помощью украденных кредитных карт. Устав от этого, она нашла приют у другой женщины-телефонного фрикера в Чикаго. Хозяйка Kyrie, как и удивительное число телефонных фрикеров, была слепой. К тому же у нее были физические ограничения. Kyrie предположительно извлекла максимум выгоды из своего нового положения, подав заявку на получение и получив государственные средства социального обеспечения под фальшивым именем в качестве квалифицированной сиделки для инвалидов.

К сожалению, двое детей Kyrie от предыдущего брака тоже исчезли в подполье вместе с ней; эти цифровые беженцы препубертатного возраста не имели легального американского статуса и не провели в школе ни единого дня.

Kyrie страдала зависимостью от технического мастерства и была очарована собственным умом и страстным поклонением со стороны своих несовершеннолетних последователей. Это по глупости побудило ее позвонить Гейл Теккерей в Аризону, чтобы похвастаться, пофорсить, покрасоваться и предложить себя в качестве информатора. Теккерей, однако, уже узнала более чем достаточно о Kyrie, которую она откровенно презирала как взрослую преступницу, развращающую несовершеннолетних, этакую «женщину-Fagin». Теккерей передала свои записи хвастовства Kyrie в Секретную службу.

К Kyrie нагрянули с обыском, и она была арестована в Чикаго в мае 1989 года. Она во всем подробно призналась и признала себя виновной.

В августе 1990 года Кук и его коллега по Целевой группе Колин Кафлин отправили Kyrie в тюрьму на 27 месяцев за компьютерное и телекоммуникационное мошенничество. Это был заметно суровый приговор по стандартным меркам легкого похлопывания по рукам при «хакерских» облавах. Семь главных несовершеннолетних последователей Kyrie также были преданы суду и осуждены. «Высокотехнологичная уличная банда» Kyrie, как охарактеризовал ее Кук, была раздавлена. Кук и его коллеги первыми в истории упрятали кого-то за решетку за злоупотребления голосовой почтой. Их новаторские усилия принесли им внимание и похвалы.

В своей статье о Kyrie Кук донес эту мысль до читателей журнала Security Management, профессионального издания для специалистов по корпоративной безопасности. Дело, по словам Кука, и суровый приговор Kyrie «отражают новую реальность для хакеров и жертв компьютерных преступлений в 90-х годах... Частные лица и корпорации, сообщающие о компьютерных и телекоммуникационных преступлениях, теперь могут рассчитывать на то, что их сотрудничество с федеральными правоохранительными органами приведет к осмысленному наказанию. Компании и широкая общественность должны сообщать о преступлениях с использованием компьютеров, если они хотят, чтобы прокуроры и суд защищали их права на материальную и нематериальную собственность, разработанную и хранимую на компьютерах».

Кук сделал своей задачей конструирование этой «новой реальности для хакеров». Он также сделал своей задачей охрану корпоративных прав собственности на нематериальные активы.

Если бы Фонд электронных рубежей был «фондом защиты хакеров» в том понимании, в каком этот термин обычно воспринимался, они, предположительно, вступились бы за Kyrie. Ее приговор 1990 года действительно послал «сигнал» о том, что федеральные силы берутся за «хакеров». Но Kyrie не нашла защитников ни в EFF, ни где-либо еще. EFF не был фондом спасения для электронных преступников.

Дело Нейдорфа в определенных аспектах было схоже с делом Shadowhawk. Жертве вновь было позволено устанавливать стоимость «украденного» имущества. Клюпфель снова выступил одновременно в роли следователя и технического советника. Опять-таки никакие деньги не переходили из рук в руки, но решающее значение имело «намерение совершить мошенничество».

Дело обвинения с самого начала демонстрировало признаки слабости. Целевая группа изначально надеялась доказать, что Нейдорф был центром общенационального преступного заговора «Легион Сумрака». Редакторы Phrack каждое лето устраивали реальные междусобойчики, которые привлекали хакеров со всей страны; как правило, около двух дюжин любимых авторов и читателей журнала. (Такие съезды были обычным делом в хакерском сообществе; журнал 2600, например, проводил публичные встречи хакеров в Нью-Йорке каждый месяц). Авторитетные крутые парни из LoD всегда составляли мощное присутствие на этих спонсируемых Phrack «Summercon'ах».

В июле 1988 года хакер из Аризоны по кличке «Dictator» посетил Summercon в родном городе Нейдорфа Сент-Луисе. Dictator был одним из подземных информаторов Гейл Теккерей; подпольная доска Dictator в Финиксе была операцией-ловушкой Секретной службы. Dictator привел на Summercon команду агентов Секретной службы под прикрытием. Агенты просверлили глазки в стене гостиничного номера Dictator в Сент-Луисе и снимали веселящихся хакеров на видеокамеру через зеркало односторонней видимости. Как оказалось, однако, на видеокамеру не попало ничего незаконного, кроме поглощения пива парами несовершеннолетних. Summercon'ы были социальными мероприятиями, а не зловещими кликами. Пленки запечатлели пятнадцать часов бурного смеха, пожирания пиццы, внутренних шуток и похлопываний по спине.

Адвокат Нейдорфа, Шелдон Зеннер, посмотрел пленки Секретной службы до суда. Зеннер был потрясен полной безобидностью этой встречи, которую Кук ранее охарактеризовал как зловещий межштатный заговор с целью совершения мошенничества. Зеннер хотел показать пленки Summercon присяжным. Потребовались затяжные маневры со стороны Целевой группы, чтобы уберечь пленки от присяжных как «не имеющие отношения к делу».

Документ E911 также оказался ненадежной опорой. Изначально он оценивался в $79 449. В отличие от архаичной добычи Shadowhawk в виде искусственного интеллекта, документ E911 не был программным обеспечением — он был написан по-английски. Людям, разбирающимся в компьютерах, эта стоимость — за двенадцатистраничный бюрократический документ — казалась откровенно невероятной. В своем манифесте для EFF «Преступление и головоломки» Барлоу прокомментировал: «Мы, наверное, никогда не узнаем, как эта цифра была получена и кем, хотя мне нравится представлять себе оценочную группу в составе Франца Кафки, Джозефа Хеллера и Томаса Пинчона».

Как оказалось, Барлоу излишне пессимистично оценивал ситуацию. EFF в конце концов действительно выяснила, как именно была получена эта цифра и кем — но только в 1991 году, задолго после того, как суд над Нейдорфом завершился.

Ким Мегахи, менеджер по безопасности в Southern Bell, вывел стоимость документа, просто сложив «расходы, связанные с созданием» документа E911. Эти «расходы» выглядели следующим образом:

1. Был нанят технический писатель для сбора материалов и написания документа E911. 200 часов работы по 35 долларов в час обошлись в: $7000. Руководитель проекта осуществлял надзор за техническим писателем. 200 часов по 31 доллару в час составили: $6200.

2. Неделя машинописи обошлась в $721. Неделя верстки обошлась в $721. Неделя графического оформления обошлась в $742.

3. Два дня редактирования стоили $367.

4. Коробка ярлыков для заказов стоила пять долларов.

5. Подготовка заказа на поставку документа, включая набор текста и получение подписи, санкционирующей расходы, внутри бюрократии BellSouth, обошлась в $129.

6. Печать стоила $313. Рассылка документа пятидесяти людям заняла у клерка пятьдесят часов и обошлась в $858.

7. Внесение документа в указатель заняло у двух клерков по одному часу у каждого, в сумме составив $43.

Утверждалось, что только бюрократические издержки обошлись в колоссальную сумму 17 099 долларов. По словам мистера Мегахи, набор двенадцатистраничного документа занял целую неделю. На его написание ушло пять недель, включая время надсмотрщика, который, судя по всему, не занимался ничем иным, кроме как наблюдал за автором на протяжении этих пяти недель. Редактура двенадцати страниц заняла два дня. Печать и рассылка электронного документа (который и так был доступен в сети данных Southern Bell любому сотруднику телефонной компании, которому это было необходимо) обошлись более чем в тысячу долларов.

Но это было только начало. Имели место и РАСХОДЫ НА ОБОРУДОВАНИЕ. Восемьдесят пять долларов за компьютерный монитор VT220. ТРИДЦАТЬ ОДИН ТЫСЯЧА ДОЛЛАРОВ за сложный компьютер VAXstation II. Шесть тысяч долларов за компьютерный принтер. ДВАДЦАТЬ ДВЕ ТЫСЯЧИ ДОЛЛАРОВ за копию программного обеспечения Interleaf. Две тысячи пятьсот долларов за программное обеспечение VMS. И всё это ради создания двенадцатистраничного документа.

Плюс десять процентов от стоимости программного и аппаратного обеспечения на техническое обслуживание. (На самом деле затраты на техобслуживание в размере десяти процентов, хотя и упоминались, были исключены из окончательной суммы в 79 449 долларов, судя по всему, по милосердному недосмотру).

Письмо мистера Мегахи было отправлено напрямую самому Уильяму Куку в офис федеральных прокуроров в Чикаго. Правительство Соединенных Штатов приняло эти цифры от телефонной компании без каких-либо вопросов.

По мере нарастания недоверия стоимость документа E911 была официально пересмотрена в сторону понижения. На этот год Роберт Киблер из службы безопасности BellSouth оценил стоимость двенадцати страниц всего в 24 639,05 доллара — предположительно на основе «затрат на НИОКР». Но эта конкретная оценка, вплоть до цента, ничуть не убедила скептиков; напротив, она вызвала открытую насмешку и поток сарказма.

Финансовые вопросы, касающиеся кражи конфиденциальной информации, всегда были своеобразными. Можно утверждать, что BellSouth вообще не «теряла» свой документ E911 изначально и, следовательно, не понесла никакого материального ущерба от этой «кражи». И Шелдон Зеннер действительно утверждал это на суде над Нейдорфом: что рейд Prophet не был «кражей», а правильнее рассматриваться как незаконное копирование.

Однако деньги не были центральным элементом чьих-либо истинных целей в этом судебном процессе. Стратегия Кука заключалась не в том, чтобы убедить присяжных в том, что документ E911 представляет собой крупную кражу и должен быть наказан исключительно по этой причине. Его стратегия заключалась в том, чтобы доказать, что документ E911 ОПАСЕН. Он намеревался доказать, что документ E911 представляет собой «дорожную карту» к системе Enhanced 911. Нейдорф сознательно и безрассудно распространил опасное оружие. Нейдорфу и Prophet было плевать (или, возможно, они даже злорадствовали над зловещей мыслью) на то, что документ E911 мог быть использован хакерами для срыва работы службы 911 — «спасательного круга для каждого человека, безусловно, в регионе Southern Bell в Соединенных Штатах и поистине во многих общинах по всему Соединенным Штатам», выражаясь словами самого Кука. Нейдорф подверг опасности жизни людей.

В ходе до судебных маневров Кук добился того, чтобы документ E911 был признан слишком опасным для представления в ходе открытых судебных заседаний по делу Нейдорфа. САМИМ ПРИСЯЖНЫМ никогда не разрешалось даже видеть этот документ, дабы он не попал в официальные материалы судебного дела, а оттуда — в руки широкой общественности и, следовательно, каким-либо образом к злонамеренным хакерам, которые могли бы злоупотребить им во вред.

Сокрытие документа E911 от присяжных могло быть ловким юридическим маневром, но у него был серьезный изъян. На самом деле существовали сотни, возможно, тысячи людей, у которых уже был документ E911 в том виде, в каком его опубликовал Phrack. Его истинная суть уже была очевидна широкому кругу заинтересованной общественности (причем все они, к слову, по крайней мере теоретически, были участниками гигантского заговора с целью мошенничества с использованием электронных средств связи). Почти каждый в электронном сообществе, у кого был модем и хоть какой-то интерес к делу Нейдорфа, уже имел копию документа. Он уже был доступен в Phrack более года.

Люди, даже вполне нормальные люди без какого-то особого нездорового интереса к запретным знаниям, не закрывали глаза в ужасе при мыслях о том, чтобы взглянуть на «опасный» документ телефонной компании. Напротив, они склонны были доверять собственному суждению и просто прочитать документ самостоятельно. И они не были впечатлены.

Одним из таких людей был Джон Нагл. Нагл был сорокаоднолетним профессиональным программистом со степенью магистра в области компьютерных наук Стэнфордского университета. Он работал в компании Ford Aerospace, где изобрел метод компьютерного сетевого взаимодействия, известный как «алгоритм Нагла», а также в известной калифорнийской фирме по компьютерной графике Autodesk, где он являлся крупным акционером.

Нагл также был заметной фигурой в The WELL, где его весьма уважали за техническую грамотность.

Нагл внимательно следил за дебатами о гражданских свободах, поскольку был страстным сторонником телекоммуникаций. Он не был особым другом компьютерных взломщиков, но считал, что электронные публикации могут многое дать обществу в целом, и попытки сдержать их рост или подвергнуть цензуре свободное электронное выражение мнений вызывали у него сильное раздражение.

Дело Нейдорфа и документ E911 подробно обсуждались в Интернете, в электронной публикации под названием Telecom Digest. Нагл, давний знаток Интернета, был постоянным читателем Telecom Digest. Нагл никогда не видел копии Phrack, но последствия этого дела тревожили его.

Находясь в стэнфордском книжном магазине в поисках книг по робототехнике, Нагл случайно наткнулся на книгу под названием The Intelligent Network. Листая ее наугад, Нагл наткнулся на целую главу, в которой скрупулезно описывалась работа полицейских экстренных систем E911. Этот обширный текст продавался открыто, и в то же время в Иллинойсе молодому человеку грозило тюремное заключение за публикацию тонкого шестистраничного документа о службе 911.

Нагл оставил ироничный комментарий на этот счет в Telecom Digest. Оттуда Нагла свели с Митчем Капором, а затем с адвокатами Нейдорфа.

Шелдон Зеннер был рад найти эксперта по компьютерным телекоммуникациям, готового выступить в защиту Нейдорфа, причем такого, который не был чокнутым подростком-«хакером». Нагл был красноречив, зрель и респектабелен; когда-то у него был допуск к секретной информации федерального уровня.

Нагла попросили прилететь в Иллинойс, чтобы присоединиться к команде защиты.

Присоединившись к защите в качестве эксперта-свидетеля, Нагл лично прочитал весь документ E911 целиком. Он вынес собственное суждение о его потенциальной опасности.

Настал момент, когда вы сами, читатель, можете взглянуть на документ E911. Это шестистраничное творение стало предлогом для федерального судебного преследования, которое могло отправить издателя электронного журнала за решетку на тридцать или даже шестьдесят лет. Оно стало предлогом для обыска и изъятия имущества у Steve Jackson Games, легитимного издателя печатных книг. Это также стало официальным предлогом для обыска и изъятия доски объявлений Mentor под названием Phoenix Project, а также для рейда на дом Эрика Блад-Акса. Оно также имело самое прямое отношение к изъятию узла Jolnet Ричарда Эндрюса и отключению узла AT&T Чарльза Бойкина. Документ E911 был важнейшим доказательством во всей операции по подавлению хакерской активности. Ничто не может служить реальной и законной заменой самому этому документу.

==Phrack Inc.==

Том второй, выпуск 24, файл 5 из 13

Администрирование управляющего офиса расширенных служб 911 для специальных служб и центров работы со счетами

автор: Подслушивающий

March, 1988

Описание службы ~~~~~~~~~~~~~~~~~~~~~

Управляющий офис для службы экстренной помощи 911 назначается в соответствии с существующими стандартными руководящими принципами в один из следующих центров:

o Центр специальных служб (SSC) o Центр обслуживания ключевых клиентов (MAC) o Центр оперативной проверки (STC) o Центр управления тарифами и соединениями (TCC)

Обозначения SSC и MAC используются в данном документе как взаимозаменяемые для любого из этих четырех центров. Центры специальных служб (SSC) или центры обслуживания ключевых клиентов (MAC) назначены в качестве контактных пунктов по сообщению о неисправностях для всех неполадок, о которых заявляют клиенты служб E911 (PSAP). Абоненты, столкнувшиеся с неполадками при вызове E911, продолжают обращаться в местную ремонтную службу (CRSAB), которая при необходимости перенаправляет информацию о неисправности в SSC/MAC.

В силу критической важности службы E911 требуются контроль и своевременный ремонт неисправностей. Будучи основным контактным лицом по работе с клиентами E911, центр SSC/MAC обладает уникальной возможностью отслеживать состояние неисправности и обеспечивать ее устранение.

Обзор системы ~~~~~~~~~~~~~~~

Номер 911 задуман как общенациональный универсальный телефонный номер, который предоставляет общественности прямой доступ к Пункту приема экстренных вызовов (PSAP). Пункт PSAP также называется Бюро экстренных служб (ESB). Пункт PSAP — это агентство или объект, уполномоченный муниципалитетом принимать вызовы полиций, пожарных и/или служб скорой помощи и реагировать на них. На объектах PSAP находится один или несколько операторов для приема экстренных вызовов и работы с ними в соответствии с требованиями местного муниципалитета.

Важным преимуществом экстренной службы E911 является улучшенное (сокращенное) время реагирования экстренных служб. Кроме того, ценной возможностью, обеспечиваемой службой E911, является тесная координация между агентствами, предоставляющими различные экстренные услуги.

Коммутатор 1A ESS используется в качестве транзитного узла для сети E911 для маршрутизации всех вызовов 911 в правильный (основной) пункт PSAP, предназначенный для обслуживания вызывающей станции. Функция E911 была разработана в первую очередь для обеспечения маршрутизации всех вызовов 911 в нужный пункт PSAP. Селективная маршрутизация позволяет направлять вызов 911, инициированный с конкретной станции, расположенной в определенном районе, зоне или городе, в основной пункт PSAP, предназначенный для обслуживания абонентской станции этого клиента, независимо от границ распределительных узлов связи. Таким образом, селективная маршрутизация устраняет проблему несовпадения границ распределительных узлов связи с границами районов или другими политическими границами.

Услуги, доступные в рамках функции E911, включают:

Принудительный разрыв соединения Маршрутизация по умолчанию Альтернативная маршрутизация Ночная служба Селективная маршрутизация Автоматический определитель номера (АОН / ANI) Селективный перевод вызова Автоматическое определение местонахождения (АОМ / ALI)

Рекомендации по подготовке к обслуживанию и установке ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Когда контракт на систему E911 подписан, отдел сетевого маркетинга обязан создать комитет по внедрению и вводу в эксплуатацию, в который должен входить представитель SSC/MAC. Обязанности группы внедрения E911 включают координацию всех фаз развертывания системы E911 и формирование постоянно действующего подкомитета по техническому обслуживанию E911.

Отдел маркетинга несет ответственность за предоставление следующей специфичной для клиента информации в SSC/MAC до начала тестирования вызовов:

o Все пункты PSAP (название, адрес, местный контакт) o Все идентификаторы цепей PSAP o Запрос на обслуживание 1004 911, включая детали PSAP по каждому PSAP (Раздел 1004 K, L, M) o Конфигурация сети o Любая информация о поставщике (название, номер телефона, оборудование)

Центру SSC/MAC необходимо знать, обслуживается ли оборудование и аппараты в PSAP компаниями BOC, независимой компанией, сторонним поставщиком или любой их комбинацией. Эта информация затем заносится в профильные листки PSAP и пересматривается ежеквартально на предмет изменений, дополнений и удалений.

Отдел маркетинга получает номер ключевого клиента (MAN) и предоставляет его в Центр корпоративных коммуникаций, чтобы первоначальные заказы на обслуживание содержали номер MAN и могли отслеживаться центром SSC/MAC через CORDNET. Цепи PSAP по определению являются официальными службами.

Все заказы на обслуживание, необходимые для установки системы E911, должны включать номер MAN, присвоенный городу или округу, который приобрел систему.

В соответствии с базовой стратегией SSC/MAC по предоставлению услуг, центр SSC/MAC будет являться общим управляющим офисом (OCO) для всех цепей от узла до PSAP (официальных услуг) и любых других услуг для данного клиента. Обучение должно быть запланировано для всего персонала, задействованного в SSC/MAC, на этапе подготовки к обслуживанию проекта.

Группа внедрения E911 сформирует постоянно действующий подкомитет по техническому обслуживанию до первоначального внедрения системы E911. Этот подкомитет установит послевнедренчиские процедуры обеспечения качества, чтобы гарантировать, что система E911 продолжает предоставлять качественное обслуживание клиенту. Обучение клиента и компании, интерфейсы сообщения о неисправностях для клиента, телефонной компании и любых задействованных независимых телефонных компаний должны быть проработаны и внедрены до ввода системы E911 в эксплуатацию. Эти функции лучше всего решать путем формирования подкомитета группы внедрения E911 для установления руководящих принципов и обеспечения обязательств по обслуживанию со стороны взаимодействующих организаций. Руководитель SSC/MAC должен возглавлять этот подкомитет и включать следующие организации:

1) Центр управления коммутацией - Трансляции E911 - Организация пучков линий - Аппаратное/программное обеспечение оконечного и транзитного офисов 2) Центр администрирования памяти оперативных изменений - Ежедневная активность обновления RC для трансляций TN/ESN - Обработка ошибок достоверности и отклонений 3) Администрация линий и номеров - Проверка трансляций TN/ESN 4) Центр специальных служб / Центр обслуживания ключевых клиентов - Единая точка контакта по всем неисправностям PSAP и узла до хоста - Регистрация, отслеживание и статусирование всех отчетов о неисправностях - Перенаправление неисправностей, последующий контроль и эскалация - Уведомление клиента о статусе и восстановлении - Анализ «хронических» неисправностей - Тестирование, установка и обслуживание цепей E911 5) Установка и обслуживание (SSIM/I&M) - Ремонт и обслуживание оборудования PSAP и аппаратов, принадлежащих телефонной компании 6) Оперативный центр обслуживания мини-компьютеров - Обслуживание цепей E911 (где применимо) 7) Инженер по обслуживанию района - Техническая помощь по связанным с голосовой сетью (CO-PSAP) неисправностям E911

Руководящие принципы технического обслуживания ~~~~~~~~~~~~~~~~~~~~~

CCNC протестирует цепь узла от устройства 202T на хост-сайте до устройства 202T на сайте узла. Поскольку цепи от хоста к узлу (от CCNC до MMOC) являются официальными услугами компании, CCNC будет перенаправлять все неисправности цепей узла в SSC/MAC. Центр SSC/MAC отвечает за тестирование и последующий контроль вплоть до восстановления этих цепей.

Хотя цепи от узла к PSAP являются официальными услугами, MMOC будет перенаправлять неисправности цепей PSAP в соответствующий SSC/MAC. SSC/MAC отвечает за тестирование и последующий контроль вплоть до восстановления неисправностей цепей PSAP.

SSC/MAC также будет получать отчеты от CRSAB/IMC о неисправностях абонентской связи 911, когда они не являются неисправностями линий. SSC/MAC несет ответственность за тестирование и устранение этих неисправностей.

Обязанности по техническому обслуживанию заключаются в следующем:

SCC@ Голосовая сеть (от ANI до PSAP) @SCC отвечает за транзитный коммутатор

SSIM/I&M Оборудование PSAP (модемы, блоки сопряжения интерфейсов CIU, аппараты) Поставщик Оборудование PSAP (при наличии оконечного клиентского оборудования CPE) SSC/MAC Цепи от PSAP до узла и голосовые цепи от транзита до PSAP (EMNT) MMOC Сайт узла (модемы, кабели и т. д.)

Примечание. Все вышеуказанные рабочие группы обязаны устранять неисправности путем взаимодействия с соответствующими рабочими группами для их разрешения.

Центр управления коммутацией (SCC) отвечает за трансляции E911/1AESS в транзитных центральных офисах. Эти трансляции маршрутизируют вызовы E911, селективный перевод вызовов, маршрутизацию по умолчанию, сокращенный набор номера и т. д. для каждого PSAP. SCC также отвечает за поиск и устранение неисправностей в голосовой сети (от инициирования вызова до оконечного транзитного оборудования).

Например, сбои АОН (ANI) в исходных офисах входят в зону ответственности SCC.

Центр администрирования памяти оперативных изменений (RCMAC) выполняет ежедневные обновления транзитных трансляций (оперативные изменения) для маршрутизации отдельных телефонных номеров.

Оперативные изменения формируются на основе заказов на обслуживание (новое обслуживание, изменение адреса и т. д.) и компилируются в ежедневный файл центром E911 (компьютером ALI/DMS E911).

SSIM/I&M отвечает за установку и ремонт оборудования PSAP. Оборудование PSAP включает контроллер ANI, контроллер ALI, модемы данных, кабели, аппараты и другое периферийное оборудование, которое не принадлежит поставщику. SSIM/I&M отвечает за создание комплектов для проверок при техобслуживании, укомплектованных запасными частями для обслуживания PSAP. Сюда входят тестовое оборудование, модемы данных и детали контроллера ANI/ALI.

Центр специальных служб (SSC) или Центр обслуживания ключевых клиентов (MAC) служит контактным лицом по сообщению о неисправностях для всех неполадок (PSAP), о которых заявляет клиент. SSC/MAC направляет неисправности в надлежащие организации для обработки и отслеживает статус неисправностей, при необходимости передавая их на более высокий уровень эскалации. SSC/MAC закрывает вопросы по неисправностям совместно с клиентом. SSC/MAC анализирует все неисправности и отслеживает «хронические» неисправности PSAP.

Сетевой центр корпоративных коммуникаций (CCNC) будет тестировать и направлять неисправности по всем цепям от узла к хосту. Все цепи E911 классифицируются как официальная собственность компании.

Оперативный центр обслуживания мини-компьютеров (MMOC) обслуживает аппаратное обеспечение компьютера E911 (ALI/DMS) на хост-сайте. Этот MMOC также отвечает за мониторинг системы и сообщение о некоторых проблемах PSAP и системы в местные MMOC, SCC или SSC/MAC. Персонал MMOC также управляет программным обеспечением, поддерживающим базу данных TN под руководством центра E911. Обслуживание компьютера УЗЛА (интерфейса между PSAP и компьютером ALI/DMS) является функцией MMOC на сайте УЗЛА. Центры MMOC на сайтах УЗЛА также могут участвовать в тестировании цепей от УЗЛА к Хосту. MMOC также будет оказывать помощь при устранении неисправностей, связанных с хостом, PSAP и сетью передачи данных, которые не были разрешены с помощью стандартных процедур устранения неполадок.

Центр установки и обслуживания (IMC) отвечает за перенаправление неисправностей абонентов E911, которые не являются проблемами абонентских линий.

Центр E911 — выполняет роль системного администрирования и отвечает за общую работу программного обеспечения компьютера E911. Центр E911 выполняет комплексный (от А до Я) анализ неисправностей и предоставляет статистическую информацию о производительности системы.

Этот анализ включает обработку запросов PSAP (отчетов о неисправностях) и перенаправление сетевых неисправностей. Центр E911 также выполняет ежедневную обработку транзитных оперативных изменений и предоставляет информацию в RCMAC для транзитного ввода. Центр E911 отвечает за ежедневную обработку базы данных компьютера ALI/DMS и предоставляет файлы ошибок и т. д. в отдел обслуживания клиентов для расследования и исправления. Центр E911 участвует во всех внедрениях систем и текущих работах по техническому обслуживанию, а также помогает в разработке процедур, обучении и передаче информации всем группам.

Любая группа, получающая информацию о неисправности 911 от SSC/MAC, должна закрыть вопрос по неисправности с SSC/MAC или предоставить статус, если неисправность была передана в другую группу. Это позволит SSC/MAC предоставить статус клиенту или эскалировать проблему надлежащим образом.

Любая группа, получающая сообщение о неисправности с хост-сайта (MMOC или CCNC), должна закрыть эту неисправность обратно на данную группу.

MMOC должен уведомить соответствующий SSC/MAC, когда хост, узел или все цепи узла не работают, чтобы SSC/MAC мог отвечать на клиентские отчеты, поступающие от PSAP. Это позволит исключить дублирование сообщений о неисправностях. При полных отключениях MMOC будет следовать процедурам эскалации для узла через два (2) часа и для PSAP через четыре (4) часа. Кроме того, MMOC уведомит соответствующий SSC/MAC, когда хост, узел или все цепи узла не работают.

Пункты PSAP будут звонить в SSC/MAC для сообщения о неисправностях E911. Лицо, сообщающее о неисправности E911, может не иметь идентификатора цепи и поэтому сообщит название и адрес PSAP. Многие неисправности PSAP не привязаны к конкретной цепи. В тех случаях, когда звонящий не может предоставить идентификатор цепи, от SSC/MAC потребуется определить его с помощью профиля PSAP. Ни при каких обстоятельствах центр SSC/MAC не должен отказываться принимать информацию о неисправности. Неисправность E911 должна обрабатываться как можно быстрее, причем SSC/MAC должен оказывать всю возможную помощь приеме отчета о неисправности от звонящего.

SSC/MAC проверит/протестирует неисправность, чтобы определить подходящую организацию для передачи на основе следующих критериев:

Проблема с оборудованием PSAP: SSIM/I&M Проблема с цепью: SSC/MAC Проблема с голосовой сетью: SCC (сообщите номер пучка соединительных линий) Проблема, затрагивающая несколько PSAP (нет отчета ALI от всех PSAP): обратитесь в MMOC для проверки проблем с компьютером NODE или Host перед дальнейшим тестированием.

SSC/MAC будет отслеживать статус сообщаемых неисправностей и при необходимости производить их эскалацию. SSC/MAC будет закрывать отчеты клиентов/компании с инициатором контакта. Группы с конкретными обязанностями по техобслуживанию, определенными выше, будут исследовать «хронические» неисправности по запросу от SSC/MAC и постоянно действующего подкомитета по техобслуживанию.

Все неисправности E911 категории «вне обслуживания» являются отчетами первого приоритета. Один вышедший из строя канал связи с PSAP считается неисправностью первого приоритета и должен обрабатываться так, как если бы PSAP был изолирован.

Пункт PSAP сообщает о неисправностях контроллера ANI, контроллера ALI или аппаратного оборудования в SSC/MAC.

НЕТ АОН (NO ANI): Если PSAP сообщает об отсутствии ANI (экран цифрового дисплея пуст), спросите, существует ли это условие на всех экранах и при всех вызовах. Важно различать пустые экраны и экраны, отображающие 911-00XX или сплошные нули.

Когда PSAP сообщает о таком состоянии на всех экранах при всех вызовах, спросите, есть ли какая-либо голосовая связь с абонентами. Если голосовой связи нет, о неисправности следует немедленно сообщить в SCC, так как вызовы 911 не проходят, что может потребовать альтернативной маршрутизации вызовов в другой PSAP.

Когда PSAP сообщает о таком состоянии на всех экранах, но не при всех вызовах, и имеет голосовую связь с абонентами, отчет следует передать в SSIM/I&M для отправки специалистов. SSC/MAC должен убедиться в SCC, что импульсы ANI поступают, прежде чем отправлять SSIM.

Когда PSAP сообщает о таком состоянии на одном экране для всех вызовов (остальные работают нормально), неисправность следует передать в SSIM/I&M для отправки специалистов, поскольку неисправность локализована в одном элементе оборудования на территории клиента.

Сбой ANI (т. е. сплошные нули) указывает на то, что ANI не была получена PSAP от транзитного офиса или была потеряна контроллером ANI PSAP. PSAP может получать сигналы тревоги «02», которые могут быть вызваны тем, что контроллер ANI регистрирует более трех сбоев со сплошными нулями на одной и той же линии. Пункт PSAP получил указание сообщать об этом состоянии в SSC/MAC, так как это может указывать на проблему с оборудованием в PSAP, которая может затрагивать всех абонентов, звонящих в PSAP. Когда при всех вызовах поступают нули или продолжаются тревоги «02», тестировщик должен проанализировать состояние, чтобы определить необходимые действия. Тестировщик должен выполнить совместное тестирование с SCC, когда на транзитно-PSAP линиях обнаруживается проблема, прежде чем запрашивать отправку специалистов.

При сообщении о периодическом возникновении состояния сплошных нулей SSC/MAC должен направить SSIM/I&M для проверки планового оборудования в ходе «хронической» проверки.

Пунктам PSAP поручено сообщать о случайных сбоях ANI в BOC по бумажному талону запроса о неисправности PSAP, который отправляется в группу обслуживания клиентов E911 и при необходимости пересылается в центр E911. Обычно это касается только конкретного телефонного номера и не является условием, требующим отчета в SSC/MAC. Множественные сбои ANI, происходящие из одного и того же оконечного офиса (XX обозначает оконечный офис), указывают на то, что в оконечном офисе или на транзитных линиях оконечного офиса может существовать серьезная проблема. PSAP сообщит о таком типе проблемы в SSC/MAC, а SSC/MAC должен перенаправить отчет в SCC, отвечающий за транзитный офис. ПРИМЕЧАНИЕ: XX — это ESCO (номер экстренной службы), связанный с входящими линиями 911 в транзит. Для С/MAC важно сообщить SCC, что отображается на PSAP (например, 911-0011), что указывает SCC, у какого оконечного офиса возникла проблема.

Примечание: Важно, чтобы PSAP заполнял форму запроса при каждом сбое ANI.

Пункт PSAP будет сообщать о неисправности каждый раз, когда адрес не поступает при вызове E911 на дисплей адреса (экран пуст). (Если запись отсутствует в базе данных 911 или происходит сбой ANI, на экране появится сообщение об этом состоянии). SSC/MAC должен уточнить у PSAP, наблюдается ли состояние NO ALI на одном экране или на всех экранах.

Когда это состояние наблюдается на одном экране (на остальных экранах информация ALI принимается), SSC/MAC запросит отправку SSIM/I&M.

Если ни один экран не получает информацию ALI, обычно имеет место неисправность цепи между PSAP и хост-компьютером. SSC/MAC должен протестировать неисправность и передать ее для восстановления.

Примечание: Если SSC/MAC получает звонки от нескольких PSAP, у каждого из которых наблюдается состояние NO ALI, имеется проблема с узлом, цепями от узла к хосту или самим хост-компьютером. Перед передачей неисправности SSC/MAC должен позвонить в MMOC, чтобы узнать, есть ли проблемы с узлом или хостом.

О состояниях тревоги на цифровом дисплее контроллера ANI в PSAP должны сообщать пункты PSAP. Эти тревоги могут указывать на различные неисправности, поэтому SSC/MAC должен спросить PSAP, не функционирует ли какая-либо часть системы E911 должным образом.

SSC/MAC должен убедиться у оператора PSAP, что основной функцией оборудования является ответ на вызовы E911. Если это так, SSC/MAC должен запросить отправку SSIM/I&M. Если оборудование не используется в основном для E911, то SSC/MAC должен посоветовать PSAP обратиться к своему поставщику оконечного клиентского оборудования.

Примечание: Эти неисправности могут сильно запутывать, когда в PSAP оборудование поставщика смешано с оборудованием, которое обслуживает BOC. Представитель отдела маркетинга должен предоставить SSC/MAC информацию относительно любых необычных или исключительных случаев, когда PSAP должен обратиться к своему поставщику. Эта информация должна быть включена в профильные листки PSAP.

Контроллер ANI или ALI не работает: Когда хост-компьютер видит, что оборудование PSAP не работает, и оно не восстанавливается, MMOC сообщит о неисправности в SSC/MAC; оборудование не работает в PSAP, потребуется выезд специалистов.

Канал (цепь) PSAP не работает: MMOC предоставит в SSC/MAC идентификатор цепи, которая, по данным хост-компьютера, имеет неполадки. Хотя каждый PSAP имеет две цепи, при выходе из строя любой из них это состояние должно рассматриваться как аварийное, поскольку отказ второй цепи приведет к изоляции PSAP.

Любые проблемы, которые MMOC выявляет на участке от местоположения узла до хост-компьютера, будут решаться напрямую с соответствующими MMOC/CCNC.

Примечание: Клиент будет звонить только тогда, когда проблема очевидна для PSAP. Когда до PSAP не работает только одна цепь, клиент может не подозревать о наличии проблемы; несмотря на то, что не работает один канал, уведомление должно появиться на экране PSAP. О неисправностях, сообщенных в SSC/MAC из MMOC или от другого сотрудника компании, не следует закрывать вопросом путем звонка в PSAP, поскольку это может привести к тому, что клиент ответит об отсутствии неисправности. Эти отчеты могут быть закрыты только после получения информации о том, что неисправность устранена, и путем проверки у сотрудника компании, сообщившего о ней. Персонал MMOC сможет подтвердить устранение неисправности, просмотрев распечатку с хоста.

Когда CRSAB получает жалобу абонента (например, не может набрать 911), RSA должен получить как можно больше информации, пока клиент находится на линии.

Например, что произошло, когда абонент набрал 911? Отчет автоматически направляется в IMC для тестирования абонентской линии. Когда неисправность линии не обнаружена, IMC передает информацию о неисправности в SSC/MAC. SSC/MAC связывается с группой обслуживания клиентов E911 и проверяет, что абонент должен иметь возможность звонить по номеру 911 и получать ESN. SSC/MAC проверяет ESN через 2SCCS. Когда обе проверки совпадают, SSC/MAC передает отчет в SCC, отвечающий за транзитный офис 911, для расследования и разрешения. MAC отвечает за отслеживание неисправности и информирование IMC о ее разрешении.

Для получения дополнительной информации обратитесь к «Глоссарию терминов E911».

Конец файла Phrack _____________________________________

Читателю будет простительно, если он или она окажутся совершенно не в состоянии прочитать этот документ. Джон Перри Барлоу от души поиздевался над ним в эссе «Преступление и недоумение» (Crime and Puzzlement): «Бюрократический новояз превосходящей непроницаемости... Чтобы прочитать все это от корки до корки, не впав в кому, требуется либо машина, либо человек, у которого слишком много практики мышления подобно машине. Любой, кто способен понять его полностью и бегло, изменил свое сознание настолько, что уже никогда не сможет читать Блейка, Уитмена или Толстого... документ представляет собой мало интересного для кого-либо, кроме исследователя продвинутого организационного склероза».

Однако, имея под рукой сам документ ровно в том виде, в каком он был опубликован (в виде отредактированных шести страниц) в Phrack, читатель может проверить несколько фактов о его природе. Во-первых, в документе нет никакого программного обеспечения, никакого компьютерного кода. Это не язык компьютерного программирования, такой как FORTRAN или C++, это английский язык; во всех предложениях есть существительные, глаголы и пунктуация. В нем не объясняется, как взломать систему E911. В нем не предлагаются способы уничтожения или повреждения системы E911.

В документе нет кодов доступа. Нет никаких компьютерных паролей. В нем не объясняется, как украсть междугородную связь. В нем не объясняется, как проникать на коммутационные станции телефонных компаний. В нем нет ни слова об использовании персонального компьютера или модема для каких-либо целей вообще, хороших или плохих.

Внимательное изучение покажет, что этот документ посвящен не технике. Документ E911 посвящен АДМИНИСТРИРОВАНИЮ. В нем описывается, как создавать и администрировать определенные подразделения бюрократии телефонной компании: Центры специальных служб и Центры обслуживания ключевых клиентов (SSC/MAC). В нем описывается, как эти центры должны распределять ответственность за службу E911 между другими подразделениями телефонной бюрократии по цепочке подчинения, в рамках формальной иерархии. В нем описывается, кто отвечает на жалобы клиентов, кто фильтрует звонки, кто сообщает об отказах оборудования, кто отвечает на эти отчеты, кто занимается техобслуживанием, кто возглавляет подкомитеты, кто отдает приказы, кто подчиняется приказам, КТО и КОМУ говорит, что делать. Этот документ — вовсе не «дорожная карта» к компьютерам. Этот документ — дорожная карта к ЛЮДЯМ.

В качестве подспорья для взлома компьютерных систем этот документ БЕСПОЛЕЗЕН. Однако в качестве подспорья для досаждения сотрудникам телефонных компаний и их введения в заблуждение документ вполне может оказаться полезным (особенно с его глоссарием, который я не стал включать). Интенсивное и длительное изучение этого документа и его глоссария в сочетании со множеством других подобных документов может научить говорить как сотрудник телефонной компании. А сотрудники телефонных компаний живут РЕЧЬЮ — они живут телефонной связью. Если вы можете имитировать их язык по телефону, вы можете применить к ним «социальную инженерию». Если вы можете облапошить сотрудников телефонной компании, вы можете посеять хаос в их рядах. Вы можете заставить их перестать доверять друг другу; вы можете разорвать телефонные связи, которые скрепляют их сообщество; вы можете сделать их параноиками. И люди будут сражаться за защиту своего сообщества яростнее, чем за защиту самих себя.

В этом и заключалась подлинная, глубинная угроза, исходившая от журнала Phrack. Настоящая борьба шла за контроль над языком телефонных компаний, за контроль над знаниями телефонных компаний. Это была борьба за защиту социальной «мембраны дифференциации», которая образует стены башни из слоновой кости сообщества связистов — того специального жаргона, который позволяет профессионалам телефонной сферы узнавать друг друга и отсекать шарлатанов, воров и выскочек. И обвинение вынесло этот факт на свет. Они неоднократно ссылались на угрозу, которой подвергаются профессионалы телефонных компаний со стороны хакеров, использующих «социальную инженерию».

Однако Крейг Нейдорф не предстал перед судом за обучение разговорной речи профессионального эксперта по телекоммуникациям. Крейг Нейдорф предстал перед судом за мошенничество с устройствами доступа и транспортировку краденого имущества. Он предстал перед судом за кражу документа, который предположительно являлся крайне конфиденциальным и предположительно стоил десятки тысяч долларов.

#

Джон Нагл прочитал документ E911. Он сделал собственные выводы. И он вручил Зеннеру и его команде защиты ломящуюся от материалов коробку с аналогичными материалами, почерпнутыми в основном из инженерных библиотек Стэнфордского университета. Во время судебного процесса команда защиты — Зеннер, полдюжины других адвокатов, Нагл, Нейдорф и эксперт по компьютерной безопасности Дороти Деннинг — все вместе построчно изучали документ E911.

Днем 25 июля 1990 года Зеннер начал перекрестный допрос женщины по имени Билли Уильямс, менеджера по обслуживанию компании Southern Bell в Атланте. Мисс Уильямс отвечала за документ E911. (Она не была его автором — его первоначальным «автором» был штатный менеджер Southern Bell по имени Ричард Хелмс. Однако мистер Хелмс не должен нести всю вину; множество сотрудников аппарата и персонала техобслуживания телефонной компании вносили правки в документ. Он был не столько «написан» единственным автором, сколько собран комитетом из бетонных блоков жаргона).

Мисс Уильямс была вызвана в качестве свидетеля обвинения и при помощи диаграмм мужественно пыталась объяснить базовую техническую структуру системы E911.

Теперь наступила очередь Зеннера. Сперва он установил, что «знак конфиденциальности», который BellSouth ставила на документе E911, проставлялся на КАЖДОМ ДОКУМЕНТЕ, который писала BellSouth — ТЫСЯЧАХ документов. «Мы ничего не публикуем иначе как для собственной компании, — пояснила мисс Уильямс. — Любой документ компании такого рода считается конфиденциальным». Никто не отвечал за выделение специальных высокозащищенных публикаций для специальной высокозащищенной защиты. Они ВСЕ были особенными, какими бы тривиальными они ни были, независимо от их тематики — штамп ставился сразу же после написания любого документа, и этот штамп никогда не удалялся.

Тогда Зеннер спросил, являются ли диаграммы, которые она использовала для объяснения механики системы E911, тоже «конфиденциальными». Являются ли эти диаграммы ОБЩЕДОСТУПНОЙ ИНФОРМАЦИЕЙ, все эти сведения о PSAP, ALI, узлах, локальных оконечных коммутаторах? Может ли он вынести эти диаграммы на улицу и показать кому угодно, «не нарушая каких-либо представлений о конфиденциальности, имеющихся у BellSouth»?

Мисс Уильямс продемонстрировала некоторую растерянность, но в конце концов согласилась, что диаграммы на самом деле общедоступны.

«Но разве не об этом вы говорили, что в основном появилось в Phrack?»

Мисс Уильямс отрицала это.

Тогда Зеннер указал на то, что опубликованный в Phrack документ E911 составлял лишь половину от объема оригинального документа E911 (в том виде, в каком его похитил Prophet). Половина была удалена — отредактирована Нейдорфом.