Дэйв Армстронг являлся системным администратором корпоративной сети банка First Fidelity Bank в округе Анаканст. В понедельник, поздно вечером, Дэйв обнаружил, что какой-то хакер полностью контролирует все 200 с лишним систем банка и «бродит» по ним, собирая пароли и тщательно просматривая данные.

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

Теперь представим себе на мгновение, что хакер бесконтрольно «бродит» по сети вашего банка в течение трех дней, собирает имена и номера счетов и, возможно, изменяет информацию, переводя денежные средства или уничтожая записи. Уже думаете о том, как нам сменить банк? Я — тоже!

Как возникают подобные ситуации? В данном случае Дэйв установил конфигурацию программного сервера таким образом, чтобы ему доверяли все остальные системы. Доверие здесь означает то, что все системы сети предоставили программному серверу удаленный привилегированный доступ (remote root access) без требования пароля при входе (конфигурация по типу «доверяемая сеть» — web-of-trust). Несколько сотен систем доверяли программному серверу.

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

Это как раз и произошло в корпоративной сети банка First Fidelity. Сотни систем этой сети поверили программному серверу. В результате сервер стал привлекательным для хакера, искавшего вход в сеть компьютеров банка. Дэйву не приходило в голову, что его система подвержена риску и не способна противостоять атаке. Ни он, ни его управляющий не знали случая, когда единственная незащищенная система может открыть дверь к остальной сети. Доверяемая сеть банка First Fidelity проникала далеко в глубины его интранета (более 200 систем). При наличии сотен систем, доверяющих программному серверу, сервер следует защищать надлежащими мерами безопасности. Но сервер сети банка тем не менее не обладал достаточной степенью защиты. Он был широко открыт и ждал, когда в него зайдет хакер.

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

Давайте рассмотрим подробнее этот случай вторжения и то, что последовало за ним в последующие дни.

День 1-й: Неавторизованный доступ

Дэйв обнаружил хакера в системе в 11. 45 ночи в понедельник, во время плановой проверки сети. Он заметил, что выполняются необычные процессы и загруженность ценфальпого процессора значительно выше нормальной загруженности для этого позднего времени. Эта необычная активность разожгла любопытство в Дэйве, и он продолжил исследование. Просмотрев регистрацию, он обнаружил, что в системе зарегистрировался Майк Нельсон, сотрудник группы обеспечения безопасности банка. Майк являлся законным пользователем, но он должен был входить в систему, вначале предупредив об этом кого-нибудь из группы Дэйва. Может быть это хакер маскирующийся под Майка? Или это сам Майк работает над проблемами безопасности? Но если это Майк, то он либо забыл сделать предварительное уведомление, либо умышленно его не сделал.

Дэйв запутался. Хуже того, он не знал, кого позвать и что ему самому делать.

Затем произошло то, что случается с большинством людей, которые впервые обнаружили вторжение хакера в их систему, Дэйв ощутил прилив адреналина, вызванный чувством возбуждения, смешанного со страхом и отсутствием определенности необходимых в таком случае действий. Он был в одиночестве посреди ночи. Если бы он не работал в столь позднее время, то, может быть, никто бы и не узнал об этой атаке. И он решил, что раз он отвечает за систему, то должен сделать что-то для восстановления контроля над ней. Он удалил пользователя из системы, а затем отключил учетную запись, заблокировав пароль пользователя. Дэйв восстановил контроль над системой и, думая, что выполнил свою миссию, отправился домой.

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

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

День 2-й: Проблема решена

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

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

День 3-й: Защита взломана снова

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

При дальнейшем исследовании Дэйв обнаружил, что ложный «Эд» пришел с системы Майка. Более того, этот пользователь не только проверял, кто еще находится в системе, но и запускал анализатор паролей. Дэйв подумал, что это Майк проверяет систему, и вошел в нее, маскируясь под Эда. (Дэйв не допускал ситуации, в которой неизвестный хакер находится в системе и крадет информацию.) Теперь Дэйву это стало действительно надоедать. Он считал, что Майк заставляет его ходить по кругу и тратить время зря. Дэйв был нетерпелив. Он удалил из системы «Эда», заблокировал его пароль и сообщил о новом повороте событий управляющему.

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

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

Дни с 4-й по 7-й: Эскалация инцидента

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

Но хакер уже не появлялся. Руководитель внутреннего аудита продолжал сомневаться, что главной причиной произошедшего был хакер. Достаточно ли было удаления того из системы, чтобы он отказался от дальнейших атак? Может быть, это Майк сам занимался взломом ради забавы и затих, когда осознал, что все ополчились против него?

День 8-й: Слишком поздно собирать улики

Только спустя неделю после вторжения отдел внутреннего аудита связался с Дэйвом и запросил техническую информацию, полученную им во время инцидента, которая бы могла показать действия хакера на сервере. Так как банк не имел штатного эксперта по безопасности, то руководитель аудита нанял меня. Я должна была определить по этой технической информации, кто же проник в сервер.

День 9-й: Кто был этим плохим парнем?

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

Когда Дэйв удалил Майка из системы, то он не оставил возможности отследить источник вторжения. Любой из моих ответов был бы чистой догадкой. Опрос сотрудников не дал результатов. Многие указывали на Майка, но не приводили ни одного доказательства. Оставив это, я посчитала лучшим посоветовать руководителю аудита поскорее разработать и внедрить процедуры реагирования на инцидент.

Если это был хакер, то, возможно, в системе остался «черный ход». В деловом мире неделя может показаться не таким большим сроком. Но при расследовании места компьютерного преступления (а взлом систем является преступлением!) — это вечность. Когда так много времени проходит между взломом и расследованием, ценная информация изменяется, теряется и иногда невозможно найти какие-либо следы.

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

Я сообщила руководителю аудита обо всех этих фактах, которые очевидны любому. Один незащищенный сервер открывает доступ ко всей сети. Так как система может быть взломана реальным хакером, то Дэйву нужно переустановить сервер, добавить соответствующие средства защиты сервера и подумать о других технических решениях по обновлению программного обеспечения своей корпоративной сети.

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

Резюме: Атаки изнутри

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

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

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

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

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

Сосредоточиться на упреждающих мерах

Зная теперь об альтернативных решениях, вы, возможно, удивляетесь, почему в First Fidelity использовалась столь уязвимая конфигурация. Так зачем подвергать и вашу информацию такому риску? Возможен уверенный ответ: «А почему бы и нет?» В конце концов, ведь хакер вторгся не в вашу систему. Поразительно, но во многих компаниях думают именно так.

Не думать, что такое не может случиться с ними

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

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

Рисунок 1.1

Строго говоря, неавторизованным использованием является любое использование компьютерной системы без разрешения на это системного администратора. Поэтому неавторизованным пользователем нужно считать и хакера-злоумышленника, и безвредного путешественника по киберпространству, и даже сотрудника компании, не имеющего разрешения на работу в конкретной системе в определенное время или с определенной целью. В инциденте, произошедшем с First Fidelity, таким неавторизованным пользователем мог быть любой из трех его типов, описанных выше.

Как видно из недавнего обзора CSI (Института защиты информации в компьютерных системах), результаты которого показаны на рисунке 1.2, слишком многие из руководителей компаний не представляют себе, как широко распространен неавторизованный доступ и незаконное использование.

Рисунок 1.2

Знать, что началась атака

Главным при отражении вторжения является способность распознать, что ваша система взламывается! Вам нужно точно знать, что наблюдаемое вами явление действительно взлом, а не аппаратный или программный сбой или причуда пользователя. Определить, подвергается ли ваша система атаке, помогут вам в первую очередь программы-детекторы вторжения. Поэтому установка программ-детекторов до того, как вы подвергнетесь атаке, абсолютно оправдана. Вспомним недавнее вторжение вируса Code Red. 19 июля 2001 года Code Red «заразил» 359 104 хост-компьютера, которые были взломаны всего лишь за 13 часов. На пике своих действий вирус поражал около 2000 новых сайтов в минуту, даже тех, на которых были установлены программы обнаружения вторжения.

Большинство IDS (Intrusion-Detection Systems — систем обнаружения вторжения) могут определить атаку, только если имеется сигнатура атаки.

Если подумать, то это выглядит глупо. Это похоже на то, что вы думаете, что грабитель не заберется в дом, но забыли купить замок на дверь. Более того, после установки у себя такой сигнатуры у вас не будет уверенности в том, что противник не запустит новый вариант атаки и будет пропущен IDS.

Убедитесь в том, что ваша IDS может обнаруживать атаки «дня Зеро» (zero-day attacks), или атаки «первого удара» (first-strike attacks), или «неизвестные атаки» (unknown attacks), названные так потому, что о них еще не сообщалось, о них ничего пока не знают и их сигнатур не существует. Если ваша IDS не может определять атаки «дня Зеро», то нужно усовершенствовать вашу архитектуру. Это поможет защититься от атак, нацеленных на протоколы и осуществляемых вирусами Code Red, Nimda и их разновидностями.

Я не предлагаю вам устанавливать программы-детекторы на каждую систему вашей сети. Но стратегическое размещение их в ключевых местах (в сетях и наиболее важных для работы системах) даст вам несомненное преимущество.

Готовиться к худшему

Хотя предупредительные меры составляют 80 % всех средств, остаются еще целых 20 %. В действительности, как бы тщательно вы ни планировали, всегда остаются непредвиденные проблемы. Способность их решать часто сводится к подготовке к неожиданностям. Поэтому, чтобы избежать ситуации, в которой оказался First Fidelity, нужно проделать следующее.

Разработать политику действий при вторжении в письменном виде

Если в вашей компании нет политики действий при вторжении в письменном виде, то вы не одиноки. Хотя мы сосредоточились на больших компаниях США, но ослабленное внимание к безопасности простирается далеко за национальные границы. Опрос, проведенный KPMG в 2001 году среди канадских фирм, показал, что только у половины респондентов имелись стандартные процедуры на случай взлома систем безопасности электронной торговли.

Рисунок 1.3

При необходимости нанять эксперта

Создание группы реагирования на инциденты (IRT — Incident-Response Team), разработка политик и процедур и поддержание общей обстановки на современном уровне является объемной задачей. Это требует времени, знаний и координации сотрудников и ресурсов. Если у вас нет процедур и у компании нет опыта по их разработке, то наймите эксперта. «Эксперт» не надо переводить как «хакер». Будьте внимательны к тому, кого нанимаете. Как показывает рисунок 1.3, большинство компаний не хочет принимать на работу бывших хакеров в качестве консультантов.

Есть ряд компаний, серьезно относящихся к этому вопросу и могущих оказать ценные услуги. (Подробнее см. Приложение А, «Люди и продукты, о которых следует знать».) При разработке процедур реагирования на инциденты для одной из компаний я беседовала с ответственным сотрудником консультационной компании, занимающейся вопросами безопасности, о том, какую поддержку они могут предоставлять. Я спросила, как скоро может их эксперт прибыть на место происшествия. «У нас глобальный охват, — ответил тот, — и мы можем прислать команду сотрудников на требуемое место в любой точке земли в течение минут или часов, в зависимости от вашего местонахождения». Компании, занимающиеся вопросами безопасности и предлагающие такой вид услуг, готовы и стремятся вам помочь. Они пришлют немедленно своих экспертов, как только возникнет проблема. Они повидали много бедствий и знают, как трудно наводить порядок после серьезного взлома. Важно установить с ними контакт до того, как взлом произойдет. При этом у вас появится уверенность в том, что кто-то способен откликнуться на ваш зов, когда вы окажетесь в зоне бедствия.

Обучиться самому (или обеспечить обучение сотрудников)

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

Хорошей идеей является проверка ваших политик и процедур до возникновения инцидента. Можно провести имитационный прогон. Вы можете захотеть привлечь группу проникновения к тестированию безопасности вашего сайта. Скажем, «Группа тигров» попытается взломать ваш сайт и в то же время проверить действия вашей группы при взломе. Было бы неверным заставлять людей гадать о том, реальный ли это взлом или нет. Другими словами, не кричите «Волк!». Если вы привлекли консультанта по безопасности для тестирования защиты вашего сайта и реагирования на взлом, то предупредите об этом обслуживающий персонал. Пусть они знают, что это имитационный прогон, а не реальное событие.

Установить точку контакта

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

Понять цели и установить их приоритеты

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

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

Защитить информацию клиента. Возможно, ваша сеть хранит важную для клиентов информацию. Если хакер похитит, изменит, уничтожит или даже выставит такую информацию в Интернете, то вы можете предстать перед судом.

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

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

Обеспечить документирование события. Запись всех подробностей может помочь руководству в получении информации по оценке взлома и при проведении расследований в отношении конкретных лиц.

Сделать «моментальный снимок» системы. «Моментальный снимок» представляет собой содержимое памяти компьютера (ОЗУ, регистров и т. д.) в определенный момент времени. (Иногда «моментальный снимок» называют «разгрузка памяти» или «дамп».) В «моментальном снимке» может сохраниться информация, которую хакер не успел стереть до завершения или отражения атаки и которая может помочь поймать взломщика. Для расследования такая информация может оказаться крайне важной.

Соединитесь с группой реагирования на инциденты, связанные с компьютерной безопасностью (CSIRT - Computer Security Incident Response Team). Важно связаться с одной из CSIRT на ранней стадии вторжения, так как, возможно, у них имеется информация, которая может помочь вам прервать вторжение. Например, они могут знать, как устранить «дыру» в программе или аппаратуре изготовителя, через которую взломщик способен проникнуть в вашу сеть. Они также накапливают статистику по общему количеству взломов и способов, применяемых хакерами для получения доступа. Если вы добились контроля над ситуацией и устранили проблему доступа хакера в сеть, вам все равно следует обратиться к CSIRT для пополнения их статистики. Они не будут предавать огласке название вашей компании и тот факт, что она подверглась взлому. В мире существует множество CSIRT. Подробнее о них можно узнать в Приложении А, «Люди и продукты, о которых следует знать».

Установить взломщика. Данный пункт кажется очевидным, но не все помнят о его важности. Конечно, проще оставить все как есть. Но лучше его поймать. Не сдавайтесь в своих попытках установить взломщика, который нанес вред вашей информации. Если вам не удается сразу отследить путь атаки на вашу сеть, не оставляйте мысли о том, как важно иметь возможность для этого. Ряд изготовителей предлагают программное обеспечение, способное легко отследить путь атаки (если оно установлено на коммутирующем узле). Такая мера должна быть предусмотрена в стратегии вашего руководства.

Знать, кто и за что отвечает. Четко очерченные обязанности устраняют возникновение неопределенности. Знание того, кто и за что отвечает, ускоряет расследование и помогает установить виновного.

Знать, кому вы можете доверять. Сам по себе взлом оказался лишь частью реальной проблемы в First Fidelity. Другой ее частью явилось отсутствие доверия между главными игроками. Если предположить, что Майк виновен, то вопрос доверия превратится в проблему подбора сотрудников. Проводились ли соответствующие проверки персонала? Хотя это может показаться вторжением в чью-то личную жизнь, все же нужно проверять каждого, кто будет отвечать за компьютерную безопасность.

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

Реагировать быстро и решительно

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

Действуйте быстро!

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

Придерживайтесь плана действий

Главная цель заблаговременного написания процедур реагирования на инцидент состоит в том, что вы (или ваши сотрудники) можете реагировать немедленно и не раздумывая. Не пытайтесь как-либо истолковывать план — просто выполняйте его!

Записывайте все!

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

При необходимости прибегайте к эскалации проблемы

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

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

Также важно иметь в плане способ эскалации в условиях конфликта интересов. Он необходим, если под подозрение попадает кто-нибудь из группы обслуживания. (В случае с First Fidelity главный подозреваемый входил в группу безопасности. Эскалация при конфликте интересов могла бы разрядить стрессовую ситуацию и последующие проблемы с персоналом.)

Создайте надежную систему отчетов

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

После взлома вы должны провести оценку случившегося. Следовал ли ваш персонал намеченным целям и приоритетам? Какие уроки вы извлекли? Что бы вы хотели в дальнейшем сделать по-другому? Возвращены ли ваши системы в безопасное состояние и не осталось ли «черного хода»?

После любого инцидента, связанного с безопасностью, проделайте следующее.

Просмотрите ваши политики и процедуры

Тщательно изучите надежность работы ваших процедур и примите решение, нужно ли их изменить на будущее.

Представьте отчет по инциденту (и как вы действовали в нем) руководству

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

По-новому взгляните на ваш бюджет

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

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

Маркус Ранум (Marcus Ranum), часто упоминающийся как отец брандмауэров, однажды сказал: «Когда дело доходит до безопасности, то нужно, чтобы парень, стоящий рядом с вами, получил пулю в голову прежде, чем руководство обратит внимание на безопасность». Если вы руководитель, отвечающий за безопасность, то не занимайте позицию «ожидания пули» в этих вопросах. Ведь на самом деле стоимость восстановления после серьезного взлома значительно превосходит расходы на установку защиты. Для уменьшения этой стоимости до минимума в будущем убедитесь, что в бюджет включено финансирование требуемой безопасности.

Контрольный список

Используйте этот список для определения готовности вашей компании реагировать на взлом. Можете ли вы поставить «Да» напротив каждого пункта?

— Есть ли у вас процедуры реагирования на инцидент?

— Понятны ли эти процедуры и отвечают ли они современным требованиям?

— Обучены ли все ответственные сотрудники использованию этих процедур?

— Есть ли в процедурах инструкции по контакту с экспертами по безопасности 24 часа в сутки и 7 дней в неделю?

— Предусмотрена ли процедура эскалации проблемы на вышестоящий уровень, если не удается связаться с экспертом по безопасности?

— Есть ли процедура, определяющая, когда обращаться за внешней помощью и к кому?

— Предусмотрено ли в процедурах немедленное уведомление руководителя информационной службы при возникновении вторжения и после его отражения?

— Выделено ли достаточно средств на разработку и поддержание реагирования на инциденты, связанные со взломом?

— Действительно ли ответственные сотрудники посещают все требуемые занятия?

— Проводятся ли личные проверки ответственного персонала?

— Все ли гладко во взаимоотношениях между системными администраторами и группами обеспечения безопасности?

— Имеются ли планы восстановления системы после инцидента?

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

— Включены ли контрольные журналы систем?

— Просматриваются ли периодически журналы регистрации в системах?

— Установлены и работают ли необходимые инструменты по обнаружению вторжения?

— Установлены ли в вашей сети программы-детекторы, обнаруживающие «неизвестные» атаки?

— Можете ли вы обнаружить и предотвратить атаки как на сеть, так и на хост-компьютер (многоуровневый подход к обнаружению)?

— Легко ли отслеживается путь атаки в вашей сети?

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

Джордж и Натан назвали свою новую компанию «TransWorld Internet Services». Занятая ими ниша предоставляла их клиентам дешевый и высококачественный доступ в Интернет и хранение их информации. Обычно TransWorld обеспечивала простым домашним пользователям соединение с Интернетом и легкодоступное хранение их информации, не беспокоясь о резервном копировании информации.

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

День 1-й: Ложное чувство безопасности

Способности Джорджа и Натана по работе на рынке услуг были почти на той же высоте, как и их техническая подготовка. Через шесть месяцев TransWorld обслуживала личные каталоги и веб-страницы более чем 1000 клиентов.

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

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

Два года спустя: Замечена атака

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

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

+Две недели: Хакер возвращается

Двумя неделями позднее хакер вновь всплыл в сети TransWorld. На этот раз хакер переписал на их сервер программу, которая при исполнении могла пересылать по почте файл с паролями на другую систему в Интернете. Вначале Натан не мог понять, как хакер вошел в его сеть. При дальнейшем исследовании Натан обнаружил, что установленная им система позволяла переписывать на его сервер и исполнять файлы из Интернета. Хакер просто переписал программу на сервер TransWorld и запустил ее на исполнение.

При исполнении эта программа скопировала файл TransWorld с паролями и переслала его по почте на неизвестную систему в Интернете. Затем хакер взломал пароль. Удача! И вот хакер внутри. Программа Натана по отслеживанию использования системы была хорошей, но она не могла заменить собой контрольные журналы.

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

+Три недели: Усиление защиты

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

В этот момент Джордж позвал меня на помощь. Так как Джордж и Натан были моими старыми друзьями, то я согласилась проверить их системы в обмен на приятную беседу и пару банок холодного пива.

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

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

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

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

Утром в 6.30 я подъехала к дому Натана. Натан предложил мне чашку кофе. Но я уже и так была взвинчена — адреналин уже начал выделяться. «Нет, спасибо, — сказала я. — Где система?» Он подвел меня к клавиатуре.

В течение пяти минут после входа в систему я обнаружила, в чем заключается проблема безопасности. Безопасности не было вообще! Системы были установлены «как есть», стандартным способом, и подключены к Интернету.

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

По мере того как я просматривала настройки системы, я удивлялась своим находкам. Они экспортировали личные каталоги через Интернет с разрешениями чтения/записи (с глобальным доступом). Я не верила своим глазам! Экспортирование файловых систем через Интернет с разрешениями чтения/записи позволяло каждому в Интернете читать, красть или уничтожать информацию. О чем эти парни думали? Я проверяла снова и снова, надеясь, что результаты будут как-то меняться, так как не хотела верить в то, что увидела.

Такого со мной еще не случалось. Два парня, которые намного умнее меня в программировании и которые берут деньги с клиентов за доступ в Интернет и хранение информации, создали сеть без установки каких-либо средств обеспечения безопасности.

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

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

Как только у меня появилась возможность обдумать его вопрос, я ему позвонила и сказала, что проблем безопасности в его домашней сети так много, что я не могу даже сказать, с чего ему начать. Лучше всего провести полномасштабный аудит безопасности его сети. Я сказала, что очень занята работой в Sun, помогая клиентам защищать свои сети от Интернета, и что смогу вернуться к нему только через несколько недель. Кроме того, я не собиралась тратить время на помощь ему в установке защиты, я могла только сообщить ему о результатах моих исследований. Я полагала, что он наймет кого-то для проведения аудита и принятия мер безопасности в своей сети.

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

Продолжение саги: Сеть остается под угрозой

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

Более того, все адреса и учетная информация клиентов были в персональных компьютерах (ПК). ПК имели резервное копирование, но устройства для этого находились прямо рядом с ними. Любой, кто бы ни пожелал, мог перепрыгнуть через невысокие стенки, взять систему и устройство резервного копирования и просто уйти. Разве это не беспорядок? Представьте себе, что ваш провайдер вызывает вас, чтобы поискать, заплатили ли вы ему за прошедший месяц!

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

Я обычно выискиваю подобные программные ошибки, когда пытаюсь взломать корневой каталог в системе. Если мне удается взломать корневой каталог за считанные секунды, то я точно знаю, перед чем я оказалась. И обычно за этим стоит серьезный риск.

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

И снова масса уязвимых мест в безопасности. Список разновидностей риска, которым подвергалась TransWorld, возглавляли следующие пункты:

• Существовала избыточность разрешений на доступ к файлам.

• Не были стерты старые учетные записи пользователей.

• В программы не были внесены исправления (патчи), повышающие безопасность.

• Не была обеспечена надлежащая физическая безопасность.

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

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

Резюме: Будете ли вы подключаться через такого провайдера?

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

У Джорджа и Натана могут возникнуть реальные причины для беспокойства в будущем. Взаимоотношения «провайдер/клиент» подразумевают ответственность провайдера, хранящего вашу веб-страницу и личный каталог, за безопасность, надежность и целостность вашей информации. Но до настоящего времени через суд не прошло ни одного дела в отношении безответственного провайдера, потерявшего информацию клиента. Довольно трудно сказать, чем должны руководствоваться судьи. Я считаю (и большинство клиентов думает так же), что суд должен принимать во внимание то, что если вы оплатили данную услугу, то ваша информация попадает в руки к специалистам, которые должны обеспечить ее защиту и безопасность. В конце концов, разве не за это вы платите?

Так или иначе, клиентам TransWorld пока везет. Забавно, но они даже не знают о том, что их информация находится на краю пропасти. И она может безвозвратно в ней исчезнуть.

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

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

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

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

Помните, что руководители отвечают за надежность и целостность информации.

Знать, каким рискам вы подвергаетесь

Знаете ли вы, какому риску подвергается информация в сети вашей компании? Большинство хакеров ищут информацию, которую можно продать: финансовую информацию, информацию о клиентах, номера кредитных карточек. В «Обзоре компьютерных преступлений и вопросов безопасности» CSI 2002 года указывается, что инциденты, о которых сообщили только 26 респондентов, причинили убытки в 170 827 000 долларов от кражи информации о собственности.

И если вы еще думаете, что «стандартный» хакер является рано развившимся тинейджером, без присмотра и с плохой социальной ориентацией, то зря. Все в большем количестве «хакерские» кражи совершаются намеренно и хорошо организованно. Есть случаи, когда участие в них переходит на правительственный уровень. В марте 2002 года официальные представители ФБР сообщили о непрекращающихся взломах компьютеров со стороны организованных преступных группировок из России и Украины, в результате которых было украдено более миллиона номеров кредитных карточек. Пятнадцатилетний мальчик, о котором думает большинство людей, может вполне оказаться пятидесятилетним бюрократом, собирающим компромат по заданию своего правительства. Помните это, думая о том, какие части и стороны вашей корпоративной информации вам необходимо защищать. Постарайтесь убедиться в том, что все люди, имеющие доступ к вашей информации, понимают, что и от кого им следует защищать.

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

Избегать стандартных установок систем

Стандартная установка систем без проведения настроек безопасности может проводиться только при отсутствии риска для информации в сети. Ваша сеть установлена стандартно? Правильно ли это? А может быть, в вашей компании забыли простые истины?

Так же как и оценка риска, политики и процедуры настройки систем должны отражать конкретные нужды компании. В защите вашей сети могут оставаться многочисленные дыры в случае, если вы не приняли нужных мер предосторожности при установке и поддержке систем сети. Если интранет вашей компании состоит из одних стандартно установленных систем, то будьте уверены — ваша информация под угрозой.

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

Протестировать вашу сеть

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

Доступен широкий выбор инструментов проведения аудита безопасности. (Подробнее см. в Приложении А, «Люди и продукты, о которых следует знать».)

Не надейтесь и не притворяйтесь, что ваша сеть в безопасности. Полную уверенность можно получить только после аудита!

Изучить людей, которые знают вашу информацию

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

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

И они их «окучивают». В феврале 2000 года какой-то тинейджер, используя уже готовые и широко доступные инструменты, запустил атаки по типу «отказа от обслуживания», которые заблокировали доступ законным пользователям на сайты Amazon, eBay и Buy.com. Хотя доступ на сайты не был полностью блокирован, все же доступ к наиболее важным страницам был закрыт. Так, участники аукциона на сайте eBay обнаружили, что не могут видеть описание выставленных предметов. Доходы продавцов соответственно упали, что отразилось и на прибыли eBay, которому пришлось любезно продлять время проведения всех аукционов, пострадавших от атаки. Подобная атака на Yahoo в том же месяце была столь интенсивной, что почти на три часа заблокировала его пользователей. Для компаний, существующих главным образом в киберпространстве, атаки по типу «отказа от обслуживания» могут стать фатальными. Британский Интернет-провайдер Cloud-Nine Communications в конце концов закрылся в начале 2002 года после того, как подвергся широкой кампании атак по типу «отказ от обслуживания». Как сказал Бернгард Уорнер (Bernhard Warner) из агентства «Рейтер», промышленные эксперты описывали это закрытие как «первый пример компании, прекратившей свое существование из-за хакеров». Может быть и первый, но определенно — не последний.

Как широко распространены подобные атаки? В 2001 году исследователи из University of California в Сан-Диего зафиксировали 12 800 атак по типу «отказ от обслуживания» в течение одного трехнедельного интервала.

Предусмотреть или потребовать необходимое финансирование безопасности

Безопасность всегда зависит от ее финансирования. Очевидно, что вы не захотите потратить на защиту какого-либо объекта больше того, чем он стоит. Поэтому вам нужно знать, какую информацию вам нужно защитить и сколько она стоит. Думайте об информации как о деньгах. Допустим, вам нужно защитить 10 миллиардов долларов. Сколько вы собираетесь потратить для их защиты? Возможно, вам следует начать с крепкого, безопасного сейфа, сигнализации и круглосуточной камеры наблюдения. Возможно, вы захотите добавить вооруженную охрану. И снова это будет зависеть от степени риска. Степень риска может определяться местоположением. В какой вы стране? В каком городе? Что по соседству? В любом случае анализ риска означает определение различных его уровней. К примеру, ваш сейф расположен в Соединенных Штатах, одном из самых безопасных государств на планете. Никаких проблем. Но подождите. Определяем конкретное место внутри Соединенных Штатов: южный район центра Лос-Анджелеса, первый этаж, общественное здание, в зале, напротив ломбарда. Уже проблема? Подобным же подходом нужно пользоваться при оценке риска для вашей информации. Детальная и методическая оценка покажет вам, что нужно защитить и какой уровень защиты вам потребуется. Первым шагом, конечно, является определение риска. Люди в TransWorld никогда не проводили оценку риска, так как считали, что риску ничто не подвергается. Они полагали, что хакер никогда не заберется в их сеть. Не думайте так же. Это приведет вас к тому, что вы окажетесь неподготовленными и уязвимыми к моменту атаки. Иммунитета нет даже у экспертов. Спросите об этом в координационном центре CERT, главный офис которого размещен в Carnegie Mellon University (CMU). Это — одна из ведущих организаций, ответственных за предупреждение общества о новых вирусах и других угрозах безопасности в киберпространстве. В мае 2001 года CERT сама подверглась атаке по типу «отказ от обслуживания». Оценка риска, знание того, как вы должны реагировать, и стремление защитить свою сеть являются главными составляющими отражения атаки, подобной этой. Анализируя стоимость вашей информации при оценке риска, берите в расчет реальную цену потери этой информации. Приведу результаты состязания Forensic Challenge, проведенного в марте 2001 года некоммерческой группой профессионалов в области безопасности Honey Project. Участники состязания должны были проанализировать реальный компьютерный взлом, кропотливо установить, к чему был доступ, и определить, какой ущерб (если таковой имелся) был нанесен.

Какие были показаны результаты? Взломщик менее чем за минуту вторгся в университетский компьютер через Интернет и находился в нем менее получаса. Но поиск того, что он наделал за это время, занял в среднем у каждого участника состязания более 34 часов. В реальной ситуации пострадавшие компании выплатили бы специалистам по 2000 долларов. Подобное неравенство, выявленное в проведенном состязании Forensic Challenge, еще раз подчеркивает большую стоимость «чистки» после того, как взломщик скомпрометировал сеть, говорит Дэвид Диттрич (David Dittrich), старший инженер по безопасности в University of Washington и главный судья состязания. По его оценке, если бы у штатных сотрудников не хватило опыта и был бы приглашен консультант со стороны, то эти 34 часа обошлись бы компании примерно в 22 000 долларов.

Не экспортировать глобальные разрешения чтения/записи

Не делайте этого! Разрешения на доступ к файлам, устанавливающие, кто может читать и изменять файл, — очень простое понятие. Главное заключается в том, что чем больше вы предоставляете доступа к файлам вашей системы, тем выше риск того, что эти файлы будут изменены, уничтожены или украдены. Если вы предоставляете возможность всему миру читать вашу информацию и иметь к ней доступ, то рано или поздно кто-нибудь сделает это таким способом, которого вы не желали, не предполагали и не представляли себе. Такую ошибку сделали парни из Trans World.

Я видела много прорех в безопасности, но эта заслуживает главного приза. Я впервые увидела, как кто-то экспортирует разрешения чтения/записи файловых систем (глобальные) через Интернет. И хотя это была чрезвычайная ситуация, я далее сталкивалась с избыточностью разрешений на доступ к файлам снова и снова. В чем причина? Системные администраторы часто не ограничивают разрешения на доступ к файлам. Иногда они просто не знают, как это делать. В других случаях они слишком заняты, чтобы об этом беспокоиться. Но беспокоиться нужно!

Стереть старые учетные записи

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

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

Тестировать пароли

Надо отдать должное — люди из TransWorld хорошо позаботились о паролях. Из 1000 учетных записей пользователей я смогла взломать лишь четыре пароля. Правда, это на три пароля больше, чем мне было нужно! Не ждите, когда хакер пройдется по вашим паролям и взломает их. Запускайте программу-«взломщика паролей» (password cracker) в ваших файлах с паролями и учите ваших пользователей тому, как выбрать надежный пароль.

Пароли образуют первую линию обороны против неавторизованных пользователей, и их взлом является одной из самых популярных форм компьютерной атаки. Хороший пароль не может быть обычным словом. Его легко взломать, найдя это слово в словаре. Хороший пароль должен представлять собой выражение, не являющееся словом (nonword). Учите своих пользователей, как выбрать хороший пароль, не являющийся словом и удобный для запоминания.

Системным администраторам также нужно проверить, насколько надежно выбрали пароли их пользователи, при помощи программы, названной "Crack". Если вы — системный администратор и не имеете копии программы "Crack", то постарайтесь получить ее, так как хакеры уже ее имеют. Гарантирую!

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

Сделать исправления программ (патчи), повышающие безопасность

Нет идеальных систем. Во всех есть дыры, которые нужно залатать. При установке любой системы в сети нужно устанавливать и патчи безопасности в них (в операционные системы). Также необходимо установить патчи безопасности, предусмотренные для решения известных проблем в коммуникационных программах (таких, как Netscape Navigator, Java, HTML и т. п.). Если ваша сеть велика и вручную вам с этим не справиться, то подумайте об установке программного обеспечения, позволяющего ставить патчи в автоматическом режиме.

Выполнять политики и процедуры

Как минимум, должны разрабатываться и совершенствоваться политики и процедуры для установки систем, обслуживания информации и обеспечения основной физической безопасности. Если у вашего системного администратора не будет системных политик и процедур, то системы после установки могут иметь рискованные настройки. Это случилось в сети TransWorld. У них не было ни политик, ни процедур настройки безопасности, и система после установки была подвержена риску.

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

Использовать экспертов

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

Не так давно я беседовала с руководителем информационной службы компании, входящей в список Fortune 500. Я сообщила ему, что от инженеров и руководящих работников его компании я узнала о нескольких рискованных настройках систем в их сети. Им следовало бы нанять аудитора безопасности и протестировать их сеть. Я сказала, что аудит не обойдется им дорого и позволит точно узнать, какому риску они подвергаются. Ответ руководителя информационной службы был необычным. Он сказал: «Линда, это как если бы из моего самого дорогого костюма вытащили одну нитку. Ничего не стоит это сделать, но последствия будут дорогими». Я поняла его так, что по-настоящему дорогим будет не аудит, а «чистка» выявленных во время него зон риска. Проблемой при таком подходе будет то, что рано или поздно кто-то будет готов выдернуть эту нитку. Вопросами будут (кроме «Когда?»): «Кто?» и «С какой целью?». Надеюсь, что на вопрос «Кто?» будет ответ — аудитор, а не хакер, а на вопрос «С какой целью?» — анализ риска, а не выискивание возможной добычи.

Обучать использованию

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

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

Контрольный список

Используйте этот контрольный список для определения того, рискует ли ваша компания из-за стандартных установок систем. Можете ли вы поставить «Да» напротив каждого пункта?

— Знаете ли вы, что пытаетесь защитить в вашей сети?

— Участвует ли руководство в оценке риска?

— Имеются ли политики и процедуры для настройки систем?

— Охватывают ли эти политики и процедуры разрешение доступа к файлам, пароли и установку патчей?

— Имеется ли политика, охватывающая физическую безопасность?

— Все ли учетные записи пользователей имеют пароли?

— Были ли изменены учетные записи, по умолчанию установленные во время установки системы?

— Входит ли в политику запрещение гостевых учетных записей, установленных по умолчанию?

— Регулярно ли отключаются неактивные учетные записи?

— Устанавливаются ли патчи безопасности совместно с установкой всех новых систем?

— Пытались ли вы взломать пароли системы (систем), которую вы обслуживаете, с целью тестирования ненадежных паролей?

— Проводите ли вы периодический аудит для проверки состояния имеющихся средств безопасности?

— Отслеживаете ли вы неавторизованные изменения файлов?

— Уверены ли вы в том, что все сотрудники, устанавливающие ваши системы, обучены политикам и процедурам безопасности вашей компании?

— Проверяете ли вы дважды, что все известные проблемы безопасности решены, перед тем, как подключить к сети новое оборудование или программы?

— Достаточно ли у вас финансируется безопасность?

— Первоочередными ли являются нужды оценки риска, обучения, проведения аудита и разработки политик и процедур?

— Настраиваете и просматриваете ли вы контрольные журналы?

— Принимаете ли вы меры предосторожности при экспорте файловых систем?

— Отключаете ли вы ненужные службы?

Миссис Смит, генеральный директор и основатель Internet Software Design (ISD), превратила идею, набросанную на салфетке, в процветающую компанию. Ее компания из Силиконовой долины вошла в список преуспевающих компаний Fortune 500, осваивала новые области передовых технологий и добивалась превосходства над своими конкурентами. Работая в сфере программного обеспечения для Интернета, компания присвоила компьютерной безопасности наивысший приоритет. Миссис Смит постоянно подчеркивала свою приверженность компьютерной безопасности своему руководящему персоналу. Все хорошо знали ее прямолинейный стиль работы, и она всегда добивалась того, чего хотела. Ну, почти всегда.

Как многие руководители, отдающие распоряжения и следящие за их исполнением, миссис Смит считала, что глобальная сеть ее компании безопасна. Так было до того, пока однажды хакер не взломал финансовую сеть компании. Не замеченный обслуживающим персоналом, хакер переслал всю финансовую информацию компании на другую систему в Интернете. Когда пересылка закончилась, хакер послал по электронной почте финансовое положение миссис Смит (включая прогноз доходов) фирме Fishman & McDonald Investors.

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

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

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

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

День 1-й: Незащищенные системы

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

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

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

Далее Мартин узнал, что системы были широко открыты и не имели контрольных или отслеживающих механизмов. Это облегчало доступ и сводило к нулю шансы быть пойманным. Любой с самыми небольшими знаниями в области безопасности мог приятно провести целый день в этой сети.

Чарльз также попросил Мартина найти источник посылки электронного письма с прогнозами доходов. Поэтому после тестирования систем Мартин попытался отследить путь электронного письма. Он предполагал, что его попытки будут бесплодными. Так и оказалось. Мартин зашел в тупик, пытаясь установить «дом» хакера.

Хотя финансовый директор не мог поверить в то, что путь электронного письма нельзя отследить, для меня в этом не было ничего удивительного. Довольно легко можно обмануть Sendmail и создать иллюзию, что электронное письмо послано от кого-то другого. С таким заданием легко могла бы справиться моя 13-летняя сестра Лаура.

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

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

Оценив тщательность работы, проделанной Мартином, Чарльз вместе с тем был абсолютно поражен ее результатами. Чарльз был крайне уверен в том, что все системы сети были защищены. Так же считали и все другие руководители. И все же аудит показывал, как легко информация могла быть изменена, украдена или уничтожена без оставления хотя бы одного следа для поимки взломщика. Чарльз поблагодарил Мартина за предоставленные факты (Майк даже стал как бы героем!) и немедленно отдал распоряжение подчиненным ему менеджерам исправить положение.

Год спустя: Неавторизованный доступ продолжается

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

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

Несмотря на такую удачу, Чарльз оставался в плохом положении. Он был разъярен и не переставал удивляться, что в его сети оставались дыры. Разве он не приказал своим сотрудникам устранить проблему еще в прошлом году? Может быть, кто-то не выполнил его указаний? Теперь Чарльз стал искать головы. И я не думаю, что они ему нужны были для расширения штата сотрудников. Он хотел положить их на плаху.

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

Рисуя общую картину, я опиралась на опыт ранее проведенных аудитов. Это — большое преимущество! Обычно аудитор тратит много времени на интервьюирование сотрудников, про смотр схем сети и зондирование информации для определения незащищенных систем.

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

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

Отчеты, представляемые вышестоящему руководству, должны быть короткими (в идеале — в одну страницу и никогда больше двух), легко читаемыми и легко понятными.

Результаты моего аудита позволяли легко передать их смысл руководству. Я уже представляла, как будет выглядеть график, еще до начала проведения аудита. Я решила показать процентное отношение незащищенных мест, найденных в прошлом году, к найденным сейчас. Это было бы замечательно! Я запомнила эту мысль и начала аудит.

Знакомясь с отчетом по аудиту, составленным Мартином в прошлом году, я обнаружила, что его трудно читать. В нем сообщалось обо всех рисках, но техническим языком и без каких-либо логических связей. Если бы руководство получило этот отчет, то оно бы не знало с чего начать. Я потратила больше времени, чем планировала, чтобы докопаться до полезной информации в отчете.

Разобравшись с отчетом Мартина, я поняла, с какими системами финансовой сети связан наибольший риск. Я прозондировала вначале информацию этих систем. Затем сняла копию таблицы паролей и запустила программу Crack. Мне нравится начинать аудит с взлома паролей, потому что я хочу увидеть, как много можно их взломать с первого захода. В таблице содержалось 520 паролей пользователей — это довольно много. Поэтому мне, возможно, удастся взломать некоторые из них. И мне удалось. Просмотр файла crack.out показал, что 10 паролей были угаданы с первого раза. Я столько и ожидала. Оставив просмотр дальнейших результатов программы Crack на более позднее время, я сосредоточилась на аудите систем повышенного риска.

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

Я не считаю, что тест на проникновение всегда необходим. Например, в системе оказалась старая версия Sendmail. Общеизвестно, что такая система может быть взломана. Зачем же тратить время для того, чтобы доказать, что вода мокрая?

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

В данном аудите тест на проникновение, определенно, не был необходим. Руководство знало, что сеть может быть взломана. (И я была здесь потому, что хакерам это было тоже известно!) Аудит должен был ответить на вопрос, почему сеть все еще уязвима. Зная это, я отказалась от проведения теста на проникновение и пошла дальше.

Я приступила к проверке наиболее ответственной финансовой системы. Она была широко открыта и не имела патчей безопасности. Я взломала корневой каталог, использовав очень старую программную ошибку в защите. Легко обнаруживалось, что эти системы имели стандартные настройки и не было установлено никаких дополнительных средств защиты. Я протестировала вторую систему, затем третью и четвертую. Та же история. Насколько мне было видно, абсолютно ничего не изменилось с тех пор, как был проведен последний аудит безопасности. Было ясно, что сотрудники нижнего уровня («находящиеся в окопах») не устранили проблем.

Вопрос, вполне подходящий для телевикторины $64 000 Question: почему не устранили? Определенно, проблемы безопасности в ISD должны были быть решены. Либо линейные менеджеры не слышали распоряжения Чарльза сверху, либо они не хотели его услышать.

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

Говоря о результатах, я вспомнила, что у меня все еще работает Crack. Желая узнать, как много еще паролей Crack может взломать, я проверила файл crack.out снова. Невероятно! Было взломано еще 100 паролей. Еще более удивительным было то, что Crack не закончил свою работу! Он все еще «долбил», пытаясь угадать пароли. Очевидно, что пользователей никогда не учили тому, как выбирать надежные пароли. Также было очевидно, что системный администратор никогда не заботился о проверке надежности паролей.

Я схожу с ума, когда узнаю, что системные администраторы не обучают своих пользователей. Слишком часто при установке систем и формировании учетных записей пользователям не объясняют важность правильного выбора и правила обращения с паролем. Также довольно распространенным среди системных администраторов является отсутствие привычки тестировать пароли. Иногда у них действительно на это нет времени. Но во многих случаях они просто не знают, как это делать, и боятся или затрудняются спросить об этом.

Кстати, на проблему ненадежности паролей было указано в отчете по аудиту прошлого года. И в отличие от некоторых других проблем, указанных в отчете, проблема паролей могла быть решена с минимальными усилиями. Мне кажется, что никто так и не смог сделать эти усилия.

Тому, кто проводил аудит в прошлом году, должно быть стыдно за то, что в отчете не указывается, сколько ненадежных паролей было обнаружено. Мне трудно поверить, что положение с ними было хуже, чем в этом году. К тому времени, как Crack завершил свою работу, им было взломано целых 190 паролей в системе с 520 пользователями. Почти каждый второй пользователь имел ненадежный пароль. При таком соотношении лучше было бы отказаться от паролей вообще. Почему бы просто не транслировать пароли по National Public Radio, чтобы напоминать их любому служащему, который позабыл свое второе имя или день рождения?!

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

Для определения нарушений связей между сотрудниками я начала с верхнего уровня руководства и пошла сверху вниз. На своем пути я сделала ряд блестящих открытий.

• Руководство высшего уровня никогда не требовало и не получало отчетов о том, делаются ли какие-либо изменения в сети, повышающие ее безопасность.

• Руководители просто считали, что проблемы безопасности будут решены только потому, что они об этом сказали.

• Отдел системных администраторов был неукомплектован, и его сотрудникам не хватало времени на решение этих проблем в системах.

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

• Системные администраторы также не умели решать проблемы безопасности. Они обратились за помощью к руководству, но подобный вид обучения не был предусмотрен в бюджете. Поэтому их запрос был отложен для рассмотрения в будущем.

• Линейные менеджеры также запросили расширить штат сотрудников по обеспечению безопасности сети. На это в бюджете опять не оказалось денег. И снова окончательный ответ на этот запрос был отложен на будущее.

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

Удивительно, как много можно узнать из бесед с сотрудниками. Досадным в этой истории являлось то, что линейные менеджеры знали, что их системы все еще оставались незащищенными. Тем не менее высшее руководство было в неведении. Это случилось потому, что оно не потребовало отчета о решении проблем. Линейные менеджеры знали, что ничего не делается, но не проявляли инициативы в докладе наверх. В результате этого высшее руководство по-прежнему оставалось в неведении. Оно твердо было уверено в том, что все сделано и все шло своим чередом.

Данная ситуация не является чем-то необычным. Как и многие компании, ISD проводила сокращение числа сотрудников. Поэтому запрос на увеличение штата сотрудников просто отклонялся. Может быть, линейные менеджеры недостаточно убедительно доказывали, почему такое увеличение штата сотрудников было абсолютно необходимо. Или их запрос потерялся среди других многочисленных запросов. Вы, возможно, знаете, что когда идет борьба за каждое рабочее место в условиях их ограниченности, то каждый запрос на нового сотрудника становится вопросом жизни или смерти.

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

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

Правильно относиться к безопасности на любом уровне сотрудников

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

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

Не перекладывать работу на другие плечи

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

Просто возвысить голос о важности безопасности недостаточно. Фактически каждому известно, что компьютерная безопасность — это важная проблема. К несчастью, все думают, что эта проблема важна для кого-то другого.

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

Уменьшать количество уровней руководства до минимума

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

Рисунок 3.1

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

Предоставлять отчеты вышестоящему руководству

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

Я задала ей следующие вопросы:

1. Получали ли вы когда-нибудь итоговые отчеты по вопросам безопасности?

2. Есть ли у вас руководитель службы безопасности?

3. Есть ли у вас эксперты по вопросам безопасности?

Генеральный директор ответила «Нет» на каждый из вопросов. Она также не была уверена в том, проводился ли в ее фирме когда-нибудь аудит безопасности. Она не знала, нанимать ли ей консультанта по вопросам безопасности. Я посоветовала ей попросить своих линейных менеджеров провести аудит безопасности и представить ей одностраничный итоговый отчет в течение 30 дней. Я также сказала: «Если ваши сотрудники не смогут провести аудит безопасности или представить вам итоговый отчет по вопросам безопасности, то, определенно, вы нуждаетесь в помощи со стороны».

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

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

Сделать безопасность общей целью

Трудности по обеспечению безопасности, возможно, у вас возникают из-за того, что все слишком заняты своей работой. Если такие трудности в вашей компании возникают, то постарайтесь, чтобы в задачи руководителя любого уровня были включены и вопросы безопасности.

Учить или учиться самому сколько нужно

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

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

ИТОГОВЫЙ ОТЧЕТ ПО ВОПРОСАМ БЕЗОПАСНОСТИ

Дата: мая 22, 2002

Кому Изабель Уинфри, вице-президенту и директору по информационным технологиям

Джеффу Сен-Пьеру, вице-президенту и финансовому директору

От кого: Майка Нельсона, директора внутреннего аудита

По вопросу: Аудит финансовой безопасности

ОБЩАЯ ОЦЕНКА

НАСТОЯЩЕЕ СОСТОЯНИЕ СРЕДСТВ БЕЗОПАСНОСТИ ФИНАНСОВОЙ СЕТИ НЕ ОБЕСПЕЧИВАЕТ ДОСТАТОЧНОЙ ЗАЩИТЫ ИНФОРМАЦИИ КОМПАНИИ ISD.

ИНФОРМАЦИЯ В СЕТИ ISD ПОДВЕРГАЕТСЯ СЕРЬЕЗНОМУ РИСКУ НЕАВТОРИЗОВАННОГО РАСКРЫТИЯ, ИЗМЕНЕНИЯ И УНИЧТОЖЕНИЯ.

РИСКИ ДЛЯ БЕЗОПАСНОСТИ, О КОТОРЫХ БЫЛО ДОЛОЖЕНО ГОД НАЗАД, НЕ УСТРАНЕНЫ. РЕЗУЛЬТАТЫ АУДИТА ПОКАЗЫВАЮТ, ЧТО РИСКИ ДЛЯ БЕЗОПАСНОСТИ ФИНАНСОВОЙ СЕТИ В ДЕЙСТВИТЕЛЬНОСТИ ВОЗРОСЛИ.

Обнаружен ряд причин такого положения дел:

• Недостаточное обучение.

• Недостаточность средств для расширения штата специалистов по вопросам безопасности.

• Плохая связь между высшим руководством и линейными менеджерами.

• Отсутствие стандартов на настройки безопасности рабочих станций.

• Неправильное использование механизмов предупреждения, обнаружения и докладов о неавторизованном доступе к информации.

РУКОВОДСТВО ДОЛЖНО ПРИНЯТЬ НЕОТЛОЖНЫЕ МЕРЫ ДЛЯ УМЕНЬШЕНИЯ ИМЕЮЩЕГОСЯ РИСКА.

Аудит проводил: Мартин Паттерсон, администратор по вопросам безопасности

Отчет получил:

Дата получения:

Рисунок 3.2

Обеспечить понимание вопросов безопасности всеми руководителями

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

Поддерживать прямую связь с руководством

Слишком часто системные администраторы жалуются на свои беды своим терминалам, а не начальству. Иногда системные администраторы обнаруживают, что жаловаться своему начальству не намного лучше, чем говорить со своим «железным другом».

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

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

Контрольный список

Используйте этот список, чтобы определить, позволяет ли организационное строение вашей компании и имеющиеся в ней уровни руководства надлежащим образом решать вопросы безопасности. Можете ли вы поставить «Да» напротив каждого пункта?

— Регулярно ли представляются руководству итоговые отчеты по вопросам безопасности?

— Существует ли надежный канал связи между высшим руководством и исполнителями? И что более важно — все ли знают, что он собой представляет и где находится?

— Возлагается ли ответственность за безопасность на вице-президента, директора по вопросам безопасности или другого руководителя? Чем выше такой руководитель находится в руководящей структуре, тем лучше! Убедитесь, что руководитель, отвечающий за безопасность, не спрятан в глубинах бюрократической системы и имеет реальную власть. Иначе он будет только козлом отпущения.

— Демонстрирует ли руководство свою приверженность программе безопасности компании, должным образом ее представляя и совершенствуя?

— Предусмотрено ли достаточное финансирование безопасности и доступны ли эти средства?

— Понимают ли все системные администраторы важность немедленного доклада о проблемах безопасности и их быстрого решения?

— Является ли обучение лучшему пониманию вопросов безопасности частью профессиональной ориентации новых сотрудников всех уровней — от линейных менеджеров до высшего руководства?

— Предпринимаются ли шаги в получении всеми сотрудниками (сверху донизу) ясного представления о политиках защиты информации компании?

— Учитывается ли реально существующая в компании культура общения между руководителями и исполнителями при разработке политик и процедур безопасности?

— Знают ли сотрудники, к кому обращаться в случае возникновения бреши в защите и неопределенности в своих обязанностях?

— Регулярно ли проводится аудит безопасности?

Компания JFC Farmaceutical захотела предоставить доступ к своей информации одному из своих клиентов для ускорения совместного исследовательского проекта. Клиенту, компании McConnell Drugs, был нужен доступ к информации, хранящейся на сервере базы данных (Drug10). Технической стороной подключения клиента занимался системный администратор Дэйв Ферлонг.

Так как Дэйв раньше никогда не работал над проектом такого масштаба, то он начал смотреть документацию. Он обнаружил, что у JFC нет утвержденной архитектуры или политики по подключению клиентов к ее интранет. Поэтому Дэйв попросил совета у эксперта компании по брандмауэрам Фреда Джонсона. Вместе Фред и Дэйв выработали свой план. Они подключили сервер базы данных к Интернету для того, чтобы сотрудники McConnell Drugs имели доступ к информации. К сожалению, они подключили сервер базы данных напрямую к Интернету, не поставив впереди него брандмауэр для его защиты и не проведя настроек безопасности на сервере базы данных. Такая конфигурация оставила дверь к сети JFC широко открытой. Было только вопросом времени, чтобы в нее «зашел» хакер. Это как раз и случилось — хакер зашел прямо в дверь.

Как смогли администратор по брандмауэрам и системный администратор сделать такую серьезную ошибку? Кто дал им полномочия на принятие такого решения?

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

День 1-й: Архитектура безопасности

Фред и Дэйв вместе стали решать, как обеспечить работоспособный доступ. Так как у Фреда не было письменного документа о том, как подключать клиентов к сети JFC, то они вдвоем обсудили, как предоставить клиенту доступ к информации на Drug10 (сервере базы данных) и как это реализовать. В общем, Фред и Дэйв решили подключить Drug10 прямо к Интернету, чтобы McConnell Drugs смогла иметь доступ к серверу через Интернет. Они предположили, что настроят Drug10 для двух целей. Во-первых, Drug10 должен служить брандмауэром. Во-вторых, что более важно для Дэйва, компании McConnell Drugs должен обеспечиваться доступ к нужной информации.

Фред имел опыт в установке брандмауэров и подключении систем к Интернету и поэтому согласился помочь Дэйву.

Несколько недель спустя; Политика установки средств безопасности

Дэйв закончил свою часть работы первым. Время отклика Drug10 уже его не удовлетворяло. Поэтому перед подключением сервера к Интернету Дэйв установил в него более мощную систему и загрузил программное обеспечение. Так как у Дэйва не было каких-либо политик или процедур подключения систем к Интернету, то он просто проделал стандартную установку. У Дэйва не было идей по настройке безопасности систем, и он посчитал, что с этим справится Фред как специалист по брандмауэрам. Но у Фреда тоже не было идей.

На следующий день: Кто отвечает за безопасность

Фред подключил сервер базы данных к Интернету. Затем он предоставил доступ McConnell Drugs, чтобы они могли копировать файлы из Drug10 на систему в их сети. Фред вообще не думал о настройке безопасности системы, так как считал, что это работа Дэйва. Он полагал, раз все получили доступ к тому, что им надо, то его работа на этом закончена. Фред приступил к другой работе.

Еще через 29 дней: Хакер захватывает контроль

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

С этого момента сеть компании McConnell Drugs стала тоже подвергаться риску. Сотрудники компании брали информацию из системы, которая могла быть заражена вирусом, «червем», «троянским конем» или чем-то подобным. Даже если предположить, что хакер не был злоумышленником (довольно рискованное предположение), все равно результаты взлома могли быть опустошительными. Представьте себе, что вы обнаруживаете утром в понедельник всю информацию по персоналу компании опубликованной в Интернете, Представьте себе также возмущение своих сотрудников, которые думали, что сведения о них, их заработной плате и служебные характеристики являлись конфиденциальными. Теперь вспомните, в какой стране мы живем. Как всем известно, возмущенные американцы так просто не успокаиваются — они бегут к адвокату!

Кстати, о юристах. Хакер, прогулявшийся по интранет JFC, мог уничтожить всю их информацию и заразить или уничтожить информацию McConnell Drugs тоже. Теперь подумайте об ответственности. Конечная ответственность за уничтоженную информацию, очевидно, лежит на хакере. Но корпоративные судебные разбирательства очень часто основываются на поиске того, кто может заплатить, а не того, кто должен платить. Несомненно, JFC с ее финансовым положением представляла бы собой лучшую, более крупную мишень для юристов, чем бедный хакер, даже если хакер сразу был бы пойман.

+Один месяц: Незапланированное тестирование безопасности

Drug 10 оставался подключенным к Интернету целый месяц, пока не обнаружилось, что он скомпрометирован взломщиком. Это открытие было сделано совершенно случайно. Его сделала я, когда меня наняли провести профилактический аудит некоторых систем JFC. Без такого счастливого совпадения скомпрометированный сервер мог остаться незамеченным и незащищенным до бесконечности.

Мое участие в этом началось с момента, когда руководство JFC наняло меня для проведения тестирования безопасности нескольких серверов, размещенных в их компьютерном зале. Хотя скомпрометированная система (Drug10) являлась сервером данных, она не была среди систем, которые я должна была тестировать.

JFC наняла меня провести, как они сказали, «выборочный аудит» (spot audit). В некоторых компаниях выборочный аудит проводится для выяснения уровня риска. При его проведении выбирается репрезентативная группа наиболее важных систем. Если аудит показывает, что эти системы подвержены риску, то есть вероятность риска и для остальных систем. Это — ресурсосберегающий подход в тестировании безопасности. Хотя он рангом ниже, чем полный аудит, но определенно лучше простого расчета на удачу (последнюю стратегию безопасности используют гораздо больше компаний, чем вы думаете).

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

Аудит, день 1-й: Схемы сети говорят о многом

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

У JFC была отличная схема сети. Глядя на нее, я заметила, что один из серверов базы данных, подключенных к интранет JFC, был также подключен к какой-то другой безымянной сети. Куда шла эта другая сеть? Очевидно, она куда-то уходила, но из схемы было неясно — куда. Одна линия сети, выходящая из сервера, повисала в воздухе и была проведена в том же направлении, что и брандмауэр компании. Из общего вида схемы можно было предположить, что этот сервер был подключен прямо к Интернету.

Подключение сервера базы данных к Интернету без настроек безопасности или без брандмауэра перед сервером выглядело нелепым. Этого никто бы никогда не сделал! Или все-таки сделал?

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

Просмотрев схему сети и наметив системы, которые казались наиболее подверженными риску, я встретилась с Дэйвом, чтобы узнать его мнение о том, какие системы мне бы следовало проверить. Важно узнать, что могут сказать по этому поводу люди «из окопов». Им могут быть известны скрытые риски, которым подвергается компания. Дэйв заявил, что ему все равно, какие системы я проверяю.

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

Я сказала ему, что он мог бы немного поучиться безопасности. Он нашел эту идею великолепной. Как и многие системные администраторы, Дэйв имел мало времени для обучения, так как тратил его на обслуживание систем и поддержание правильной их работы. Короче говоря, Дэйв нуждался в обучении и дополнительных сотрудниках. Для меня это было неудивительным. Считается, что системные администраторы знают все и работают непрерывно. Я была системным администратором и это знаю.

Я сказала Дэйву, что, хотя схема сети у меня есть, я все же хочу посмотреть их политики и процедуры безопасности. Он ответил, что сделает их копии для меня к завтрашнему утру.

Мне не терпелось спросить Дэйва о сервере базы данных. Он и так уже был встревожен, и я не хотела сообщать ему плохих вестей. И все же по пути к выходу у меня случайно вырвалось: «Кстати, похоже, что сервер базы данных с именем Drug10 подключен к двум сетям. Это так?» Дэйв ответил: «Да, я подключил этот сервер к Интернету для того, чтобы один из клиентов имел доступ к базе данных». Этот ответ возбудил мое любопытство. Я спросила: «Когда?» Дэйв ответил: «В прошлом месяце».

«Хмммм… я никогда не видела, чтобы кто-то подключал сервер базы данных к Интернету, не защитив его брандмауэром». Дэйв ответил: «Наш эксперт по брандмауэрам Фред настроил Drug10 после установки мной системы на выполнение им функции брандмауэра».

После этого мне все равно было трудно поверить в то, что эти два человека подсоединили их систему напрямую к Интернету. Вот и говори про риск! Так как я уже собрала достаточно информации, чтобы начать тестирование, то решила поговорить с администратором брандмауэров Фредом после проведения тестов безопасности системы. Мне хотелось поговорить с ним, имея все факты. Меня уже звал к себе Drug10. Я должна была идти.

Было уже почти 5 часов дня, и я была вынуждена перенести тестирование систем на завтра. Дэйву надо было забирать ребенка, и ему не хотелось слоняться по компьютерному залу, пока я буду проводить аудит систем. Однако он согласился завтра первым делом создать мне учетную запись на сервере Drug10, чтобы я смогла сразу же, как только приеду, приступить к работе. Договорившись, мы ушли в одно и то же время.

В отличие от Дэйва, с радостью ушедшего с работы, я не была счастлива от ожидания. Мне надо было освободить свою голову от мыслей, иначе до утра я могла бы сойти с ума. Этому могла помочь хорошая пробежка. Я пришла в себя, когда уже зашнуровывала кроссовки. Я распахнула дверь дома и выбрала маршрут потяжелее — по холмам. После пяти миль бега по холмам Портола Вэли мне плохо не стало. Пробежка была напряженной и здоровой. И это сработало! Следующее утро наступило быстро.

Аудит, день 2-й: Ничем не подкрепленные политики

Дэйв встретил меня в холле JFC. Мне хотелось поскорее добраться до клавиатуры Drug10, но сначала я должна была получить политики безопасности. Мы задержались из-за них в офисе Дэйва. Политики, распечатанные им, были немногочисленными и короткими — они умещались на нескольких дюймах бумаги. Дэйв занялся чтением электронной почты. Он тихонько ругнулся и начал выстукивать на клавиатуре ответ. Должно быть, он имел дело с трудным клиентом.

Пока он этим занимался, у меня была возможность взглянуть на политики. Это были политики очень высокого уровня — в них с высоты 30 000 футов руководство рисовало на песке линии. Хотя они удовлетворяли директора по информационным технологиям, но были не достаточны для непосредственного обслуживания или защиты систем компании. То, что я увидела, не содержало политики по защите брандмауэрами — это была, скорее, политика подключения. В ней предусматривалась защита брандмауэром лишь одного подключения интранет компании к Интернету. Без каких-либо оговорок. Что тут соблюдать?

Как только Дэйв оторвался от своей электронной почты, я попросила его провести меня в компьютерный зал. В JFC имелось несколько уровней безопасности для защиты компьютерного зала. За консолями и другим оборудованием следили четыре оператора. Они должны были обеспечить мою работу в системе, и Дэйв подтвердил, что я буду работать весь день. Физическая безопасность была хорошей. Видно было, что в нее были вложены серьезные средства.

Мы с Дэйвом прошли в середину зала. Со всех сторон нас окружали серверы выше моей головы. На всех них были таблички — Drug4, Drug5, Drug6. Уровень адреналина во мне стал расти. Я знала, что среди них искать. Я чувствую запах риска за милю. И за углом я увидела его — Drug10.

Дэйв создал мне учетную запись и сказал, что придет забрать меня на обед. Я уже почти зарегистрировалась в системе, когда он заканчивал фразу. По мере зондирования системы я не могла поверить своим глазам. Предположения подтвердились. Эта система оказалась подключенной к Интернету без какой-либо настройки безопасности. Это была еще одна стандартная установка системы.

Дальнейшее изучение показало, что сервер был очень сильно скомпрометирован хакером. Хакер даже заменил системные файлы и оставил «черный ход» для облегчения повторной прогулки! Невозможно себе представить, что будет, если из Интернета или интранет JFC придет хакер. Так как на сервере Drug10 легко может быть получен привилегированный доступ, то хакеру даже не придется много трудиться, Работу ему упрощало наличие неактивных учетных записей с легко угадываемыми паролями и тот факт, что патчи безопасности никогда не устанавливались.

Сервер Drug10 выполнял также и сетевые службы, которые бы следовало выключить. Есть много способов получения информации о системе с использованием сетевых служб. Например, с помощью команды "finger" можно получить информацию о пользователях системы. Эта информация может быть позднее использована для запуска атаки против этих пользователей. Зачем выставлять напоказ информацию без необходимости? Это — одна из причин, по которой следует выключать ненужные вам службы.

Работа хакера не просто упрощалась, она превращалась в прогулку по парку. Было так много путей для вторжения в систему, что я не могла догадаться, какой из них использовал хакер. Может быть, по одному на каждый день для разнообразия? С этим надо было немедленно что-то делать.

Так как риск для JFC (и McConnell Drugs) был слишком велик, то на написание отчета пока не было времени. Некоторые из аудиторов присваивают степеням риска цвет — например, зеленый, желтый или красный. Данной степени риска я бы присвоила категорию: «СЕЙЧАС НЕБО УПАДЕТ НА ЗЕМЛЮ».

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

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

Последний день аудита: Кто несет ответственность за безопасность

После того как риск для сети JFC был уменьшен, я смогла закончить оставшуюся часть аудита. Результаты аудита показывали серьезные нарушения безопасности у большинства наиболее важных систем.

Во главе списка рисков были следующие:

• Не были сделаны исправления программ (патчи), повышающие безопасность.

• Существовала избыточность разрешений на доступ к файлам.

• Пароли легко было отгадать.

• Были включены ненужные сетевые службы.

Большое количество рисков не удивило меня. Когда такая важная система, как Drug10, настраивается столь плохо, что информация всей компании и ее клиентов подвергается риску, то я не могла ожидать, что обнаружу должный контроль над безопасностью других систем. Перед тем как написать отчет, я решила поговорить с Фредом, так называемым экспертом JFC по брандмауэрам. Зайдя в его офис, я попросила уделить мне немного времени. Когда я села и пыталась завязать с ним разговор, Фред продолжал печатать. Мне это очень не нравится. Когда люди печатают во время разговора с вами, то этим стараются показать две вещи: 1) «У меня есть дела важнее разговора с вами». 2) «Вам вовсе не нужно мое внимание (или вы не заслуживаете его)». Я не была настроена терпеть такое отношение ко мне, поэтому встала и попросила Фреда встретиться со мной в зале заседаний в конце холла.

Фред от своих манер общения не отказался и там. Пытаясь получить от него информацию, я обнаружила, что он саркастичен, заносчив и не очень умен. По моему мнению, он был типичным неудачником. Он попытался переложить ответственность на другого. Он путано стал мне объяснять, что все было бы в порядке, если бы Дэйв настроил безопасность на сервере базы данных. Он также сказал, что в его намерения не входило настраивать безопасность системы — это, по его мнению, была работа Дэйва.

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

Мне не хотелось тратить много времени на разговор с Фредом, так как нужно было писать отчет. И все же я решила задать ему еще несколько вопросов, с тем чтобы подзадорить его, (Ладно, с моей стороны это не совсем хорошо, но всем нам хочется иногда позабавиться.)

Оказалось, что Фред работает в JFC, обслуживая сеть и настраивая брандмауэры, уже пять лет. Для JFC это означало, что пять лет ее безопасность подвергалась большому риску. Ernst & Young сообщала в 1996 году, что более 20 процентов обследованных компаний не имело сотрудников, занимающихся безопасностью. Но они не сообщили о том, что иметь недобросовестного сотрудника на этой должности может быть так же плохо, если не хуже. При отсутствии эксперта по безопасности пользователи хотя бы не будут заблуждаться, предполагая, что их информация защищена, в то время как все будет наоборот.

Прием на должность эксперта по безопасности неподходящего сотрудника может подвергнуть риску всю компанию, особенно если ее руководство недостаточно разбирается в этих вопросах и не знает, за какие промахи эксперт по безопасности должен отвечать. Начальник Фреда, кажется, совсем этого не знал, Я думаю, что он даже не понимал риска.

А риск в JFC был существенным. Из-за плохой конфигурации вы даже не могли сказать, не украл ли хакер конфиденциальную информацию для продажи конкуренту. Также нельзя было сказать, не оставил ли он за собой «троянского коня», «червя» или вируса, которые бы могли позднее заразить информацию JFC и ее клиента — McConnell.

Что касается внешних подключений, то было невозможно сказать, где сеть начинается и где кончается. Если вы работаете в JFC и хотите иметь внешнее подключение, то вам просто надо обратиться к Фреду. Фред лично разрешал все подключения и хранил информацию о них в неструктурированном файле. Поэтому нельзя было получить каких-либо отчетов по соединениям, и в файле невозможно было чего-либо найти, В общем, сплошная неразбериха.

Несколько дней у меня ушло на составление итогового отчета для руководства JFC. Я немного задержалась с его оформлением, так как хотела уместить множество факторов риска в пару страниц. Эти риски вызывались неправильной организацией разрешения внешних подключений, слабой политикой брандмауэрной защиты, плохой разработкой политик и процедур и недостатками общей конфигурации системы. В отчете также указывалось на слабое обучение, неэффективное руководство и невозможность проследить внешние подключения. Я вручила отчет Дорис и уехала. Теперь устранение этих проблем стало ее обязанностью.

При разработке нового продукта мы все стараемся держаться хотя бы на несколько шагов впереди стаи. Но волки могут быть ближе от ваших пяток, чем вы думаете. В своей книге «Информационная война: хаос на электронном суперхайвэе» Уинн Швартау замечает: «Когда-нибудь вы станете (если уже не стали) жертвой информационной войны… Если не вчера или сегодня, то обязательно завтра».

Если это звучит для вас немного мелодраматично, то задержимся и посмотрим на общую цену проблемы. По данным офиса директора национальной контрразведки, только в 2002 году потери продаж в американской экономике от промышленного шпионажа оцениваются суммой от 100 до 250 миллиардов долларов. Вы можете добавить сюда экономические и моральные убытки от потери рабочих мест.

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

Можете ли вы заявить в такой обстановке, что имеете все необходимые средства безопасности? Не начнет ли ваше будущее расплываться и исчезать, как почти случилось с JFC? Чтобы этого избежать, нужно сделать то же самое, что должна была сделать JFC.

Использовать типовые архитектурные схемы

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

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

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

Отслеживать внешние подключения

Необходимость внешних подключений может возникнуть быстро, особенно если вы работаете в растущей компании. В 1996 году Ernst & Young обнаружила, что целая треть обследованных ей компаний использует Интернет для обмена важной деловой информацией. Затем произошла революция, создавшая электронную торговлю и вызвавшая небывалый взлет количества внешних соединений. К 2002 году, уже 99 процентов респондентов имели корпоративные веб-сайты. Из них 52 процента действительно занимались электронной коммерцией на своих веб-сайтах. Сегодня реальные деньги и финансовая информация обычным образом отправляется в киберпространство. Внешние соединения не являются чем-то исключительным — они подразумеваются сами по себе.

Одна из главных проблем JFC заключалась в том, что они не могли даже сказать мне, сколько внешних подключений у них есть. Заявки на подключения хранились в ASCII-файлах, но из них не было ясно, какие заявки были утверждены и/или удовлетворены.

Поручите кому-нибудь (любому!) отслеживать внешние подключения. Дайте ему подробные инструкции, как вести записи. Если вы не сможете легко найти и получить отчет с информацией по внешним подключениям, то работа будет бесполезной. Будет лучше, если сотрудник, отвечающий за внешние подключения, станет регулярно отчитываться об их состоянии.

Отвечать за свою территорию

Если вы являетесь системным администратором, отвечающим за конкретные системы, то помните, что эти системы представляют собой вашу территорию. Хотя вы разделяете эту ответственность с администратором безопасности, вы все же отвечаете за каждую из систем, находящихся на вашей территории. В случае с JFC Фред «перевел стрелки» на Дэйва, так как к концу того дня Drug10 уже принадлежал Дэйву.

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

Требовать утверждения внешних подключений

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

Статистика показывает увеличение количества подключений к Интернету, и стоит невероятный шум по поводу роста производительности, обеспечиваемого легким доступом к информации. Но расширение доступа не всегда ведет к повышению производительности. Семьдесят восемь процентов участников опроса, проведенного CSI в 2002 году, сообщили, что ловили своих сотрудников за использованием подключения к Интернету не по назначению. Находящийся в Калифорнии Saratoga Institute сообщает, что в 2000 году более 60 процентов американских фирм наказывали сотрудников за незаконное использование подключения к Интернету, Более того, в целых 30 процентах фирм даже прибегали к увольнению сотрудников за онлайновый трейдинг, азартные игры, посещение порносайтов и просто за перерасход времени доступа к Интернету. Прежде чем увеличивать производительность вашей компании при помощи расширения доступа, подумайте о возможных последствиях. Для начала поручите кому-нибудь из руководящих сотрудников выдавать разрешение на внешние подключения к другим сетям. Хорошо было бы также, чтобы каждое из разрешений им подписывалось. При этом ответственность немного сдвинется вверх по цепочке — и чем выше, тем лучше.

Я твердо убеждена в том, что если бы в JFC было необходимо утверждать подключение Drug10, то кто-то бы задумался. По крайней мере, при этом прекратили бы «поджаривать» Дэйва и повернулись бы к руководителю, отвечающему за выдачу разрешений.

Следить за выполнением политики процедур

По крайней мере, JFC для своей обороны предусмотрело политику для брандмауэров. Хотя это была политика, одна на все случаи и смотрящая с высоты 30 000 футов, но все-таки она была. В ней указывалось, что допускается только одно подключение к Интернету. К сожалению, за ее выполнением не следили. Если бы было иначе, то Drug10 не был бы установлен с рискованной конфигурацией.

Разработанные политики не имеют смысла, если затем они не подкреплены непрерывным и безжалостным отслеживанием их выполнения.

Выключать ненужные службы

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

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

Подчеркивать важность обучения

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

Системный администратор JFC Дэйв ясно представлял себе, что безопасность нужна. Но у него не возникло ни одной мысли, как ее настроить. Если вы окажетесь в подобной ситуации, то учитесь, как настраивать безопасность, у того, кто это знает. Ни на кого не надейтесь. Дэйв уже так поступил. Он подумал, что Фред возьмет на себя решение проблемы. К несчастью, Фред не считал обеспечение безопасности Drug 10 частью своей работы. Дэйв добился бы большего, если бы Фред научил его, как настраивать безопасность в данном случае. Еще большего Дэйв добился бы, если бы его начальник обеспечил надлежащее обучение.

Проследить весь процесс настройки

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

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

Не подключать незащищенные системы к Интернету

Это и так известно всем, но для еще большей ясности: Никогда в жизни не подключайте незащищенный сервер базы данных к Интернету! (Если, конечно, вы не задумали в дальнейшем ходить от двери к двери в униформе вашей компании и торговать энциклопедиями…)

Контрольный список

Используйте этот список для определения того, что делается в вашей компании для контроля внешних подключений. Можете ли вы поставить «Да» напротив каждого пункта?

— Участвует ли руководство в процессе утверждения внешних подключений?

— Отслеживает ли кто-либо (предпочтительнее, кто-либо важный) внешние подключения?

— Знает ли руководство, сколько сотрудников компании и подрядчиков имеет внешние подключения?

— Выключены ли ненужные сетевые службы?

— Оценивается ли необходимость всех внешних подключений перед их утверждением?

— Проводятся ли в вашей компании профилактические аудиты для поддержания контроля над внешними подключениями?

— Обеспечивается ли достаточное обучение сотрудников, отвечающих за безопасность?

— Имеются ли процедуры по отключению соединений при прекращении работы сотрудников и подрядчиков?

— Существуют ли политики и процедуры для внешних подключений?

— Существуют ли политики и процедуры для установки брандмауэров?

— Существуют ли политики и процедуры для установки клиентских подключений (экстранет)?

— И что самое главное: отслеживается ли выполнение политик и процедур, связанных с подключениями?

Несколько лет назад отдел внутреннего аудита InterMint Financial нанял меня для тестирования безопасности в офисе их компании. Работа по контракту с отделом внутреннего аудита компании является обычным делом. В состав отделов внутреннего аудита, как правило, не входят эксперты по безопасности. Поэтому эти отделы заключают контракты на выполнение работ по вопросам безопасности с экспертами, которые затем представляют отчет о рисках. В данном случае отдел аудита попросил меня взглянуть на их корпоративную сеть и представить отчет по найденным рискам.

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

День 1-й: Сбор фактов

Я начала этот аудит, как и большинство других, с просмотра сетевой схемы, чтобы понять конфигурацию сети и возможные риски. Мне нравится проводить аудит корпоративных сетей, потому что это одно из мест, в которых хакер будет искать секреты компании. Мне заплатили за то, чтобы я вычерпала всю грязь. Для этого нужно было думать как хакер. Так как я проводила аудит не сети разработчиков, то я не стала искать коды программ или результаты исследований. Вместо них я искала стратегическую информацию высшего уровня. Я делала то, что мог делать конкурент, притворившийся сотрудником компании. Я искала легкий доступ к административным системам, хранящим стратегическую информацию компании или даже личные сведения о руководителях. Так как конкуренты могут иметь такие намерения и имеют их, то системы генерального директора, директора по информационным технологиям и финансового директора нужно всегда считать потенциальными целями взлома. Для недопущения хакера к этим зонам и снижения риска должны быть приняты дополнительные меры предосторожности при установке систем и проводиться профилактический аудит.

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

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

Интересной особенностью сетевой схемы было то, что информация отделов хранилась в разных сетях, обслуживаемых разными сотрудниками. Административные системы контролировались Хосе Гарсией, юридические системы — Дон Форбс, финансовые системы — Кендзи Абэ, операционный зал — Смитой Кумар, а охрана компании — Тией Фэрчайлд. Такая структура обслуживания уже добавляла риск в общую картину. Она также увеличивала вероятность плохой обученности или плохих процедур у множества системных администраторов, отвечающих за сеть. Я понимаю, что одному системному администратору невозможно тщательно обслуживать тысячи машин, и поэтому компании обычно имеют более одного сотрудника на этом участке. Но чем больше людей занимаются одним делом, тем выше становится общий риск и, конечно, больше возможностей появляется у предприимчивого хакера. Не делайте такой ошибки. Хакеры знают о вероятности риска, связанного с чрезмерным количеством обслуживающего персонала. То, о чем они мечтают, — это толпы системных администраторов, мало знающих, как обеспечивать безопасность наиболее важных систем.

День 2-й: Тестирование систем

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

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

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

Продолжая работать на административных системах, я попросила Хосе создать мне учетную запись. Я также дала ему понять, что он хорошо поработал. Системные администраторы редко слышат такое от аудиторов безопасности, и улыбка Хосе подтвердила, что он оценил мои слова.

Я вошла в одну из систем Хосе и поискала ошибки в базовой системе файлов и настройках. Такие ошибки не могут быть обнаружены вне сети — ими являются избыточность в разрешении доступа к файлам, наличие неактивных учетных записей и программы setuid (set user ID — установка идентификатора пользователя). В общем, система выглядела хорошо. Еще оставалась возможность кое-что усовершенствовать, но ничего такого, что я могла бы указать в отчете. После выхода из системы я сообщила Хосе, что ему можно было бы ужесточить разрешения на доступ к файлам в большинстве своих систем. Короче говоря, он проделал блестящую работу. И я собиралась сказать начальству: «Этот парень — звезда!»

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

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

Системы Кендзи были защищены не лучше, чем системы Дон. Через несколько минут я имела доступ к первой системе в финансовой сети. Еще через несколько минут я получила контроль над всеми финансовыми системами. Может быть, в этой компании юридическая и финансовая информация считается не столь важной, чтобы ее защищать? Или Кендзи и Дон просто бестолковы? Моим предположением было то, что руководство не понимает вопросов безопасности и риск для своей информации. Оно никогда серьезно не смотрело на меры защиты информации в своей сети. Если бы руководство поняло, что вся их информация в сети доступна любому, то, я уверена, их бы расстроила мысль о том, что кроме штатных сотрудников во внутренней сети могут законно присутствовать и другие. Подрядчики, клиенты, консультанты, временные сотрудники, надомные работники — выбор большой. В зависимости от вида бизнеса и степени развития компании список может быть еще длиннее.

Состояние систем Смиты было еще хуже. Я смогла получить полный контроль и доступ к информации в ее системах так же, как и в двух ранее тестируемых сетях. Но действительно пугало то, что я смогла бы сменить пароль, хранящийся в PROM аппаратной части, и обрушить систему. Смита лишилась бы доступа к ее системам до тех пор, пока я не сообщила бы ей новый пароль, иначе ей пришлось бы менять PROM в аппаратуре. С небольшими творческими способностями (и еще с меньшими моральными устоями) хакер мог бы захватить власть над всем операционным залом и перевести несколько миллионов долларов на оффшорный счет. Чтобы разориться за неделю, такой компании нужно потерять несколько миллиардов долларов, поэтому что для них значат несколько миллионов при таком богатстве?

Теперь меня стала беспокоить легкость, с какой можно было взломать системы фирмы. Конечно, последняя группа (системы отдела охраны компании) должна была опровергнуть мое мнение. Уж над этими-то системами должен осуществляться тщательный контроль. Не так ли?

А вот и нет! Тию, должно быть, учили «защищать» свою сеть Дон, Кендзи или Смита! Снова я, никем не замеченная, получила полный контроль над системами. Некоторая полученная мной информация была действительно аппетитной. Среди всего прочего я смогла добраться до файлов с подробной информацией по ведущимся расследованиям. Представьте себе, что вы мошенник, по которому ведется расследование в компании. Имея самый малый опыт взлома, вы сможете получить всю информацию по расследованию, проводящемуся против вас. Убрать немного информации здесь, изменить немного информации там, и вот — никаких вопросов к вам от отдела охраны! Расследование закрыто.

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

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

Я собрала материал и отправилась в суши-бар (Хигаши-Вест). Повара Ричард, Крейг и Гарт всегда встречали меня там с улыбкой в конце тяжелого дня, Наградой мне будет лучшее суши в Пало-Альто. Немного суши, немного участия и подбадривающая беседа позволят мне забыть о депрессивном состоянии безопасности в корпоративных сетях. Так и случилось.

День 3-й: Обучение безопасности оставлено за рамками бюджета

Не успела я забыться, как зазвонил будильник. Было 4.30 утра — как раз есть время, чтобы пробежаться перед работой. В сонном состоянии я пошла на зарядку. Подсознательно я все равно прикидывала мой дневной план по завершению аудита в InterMint.

После пробежки я отправилась в InterMint и встретилась в холле с руководителем аудита Рэндаллом Милленом. Он выписал мне пропуск на этот день и определил время беседы с системными администраторами.

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

Еще раньше мое чутье подсказывало о существовании здесь проблем с обучением. Я знала, на что похожа «окопная» работа системного администратора. Во многих компаниях обучение является роскошью. Кроме того, что они должны быть быстрыми, сообразительными и способными справиться с любой неисправностью, системные администраторы считаются всезнайками, выведенными в пробирке, унаследовавшими хорошую карму или полученными с помощью другого метода, но только не в результате хорошего обучения. Администраторы, не вписывающиеся в такие рамки, будут съедены в сыром виде — совсем как суши.

Я побеседовала с каждым из системных администраторов отдельно, чтобы узнать их мнение о том, почему административная сеть защищена, а другие системы широко открыты. Чтобы сразу узнать больше, я начала с системного администратора, обслуживающего административные системы. Хосе хорошо знал свою работу, и я хотела узнать, как он смог этому научиться и почему другие этого не смогли сделать. Беседуя с Хосе, я обнаружила, что он очень много знает. Он был доброжелателен, и с ним легко было говорить. Он понимал всю важность административных систем. Как я уже говорила, система генерального директора была взломана, когда Хосе только начал работать. Он быстро выяснил, где и какой недостаток имеется в системе. После этого случая в компании усилили контроль над безопасностью, а Хосе прошел полный курс обучения по поддержанию безопасности в сети. Я спросила его, что он думает о состоянии безопасности остальных систем компании. Он не мог на это ответить, но сказал, что сомневается в хорошем состоянии безопасности, так как никто из других системных администраторов не был обучен ее поддержке. Он также деликатно заметил, что сомневается в способности коллег сделать свои системы безопасными.

Опрос остальных системных администраторов подтвердил подозрения Хосе. Ни один из них не был обучен поддержанию безопасности. С Тией даже не проводилось базового обучения как системного администратора целых шесть месяцев с момента ее поступления на работу! Для таких, как Тия, это большая проблема, так как она никогда раньше не занималась поддержкой платформ UNIX. Ее успех в настройке безопасности систем зависел от того, как она будет обучена одним из других системных администраторов. А так как другие системные администраторы не знали, как безопасность настроить, то и Тия не могла ничему от них научиться.

Дон, Кендзи, Смиту и Тию с Хосе объединяло то, что все они были очень умными людьми. У всех был опыт программирования, а Тия и Кендзи даже имели ученые степени по вычислительной технике. В нашей среде необразованных людей не встретишь. Просто их заталкивают на должности персонала технической поддержки, как это обычно случается с системными администраторами, и говорят, чтобы они учились в процессе работы.

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

Подобная ситуация сложилась по двум причинам. Во-первых, руководство обязано было обеспечить необходимое обучение. Оно не думало о проблемах безопасности в полной мере. Вместе с тем руководители не могут читать чужие мысли. Дон, Кендзи, Смита и Тия должны были указать на пробел в безопасности и попросить, чтобы им обеспечили необходимое обучение. Они этого не сделали.

По этому аудиту у меня было собрано достаточно информации. Я потратила несколько дней на составление отчета. Иногда на его составление уходит столько же времени, как и на само проведение аудита. Важно показать риски и рекомендуемые решения так, чтобы они были понятны руководству и вызывали у него стремление к действиям. На это нужно время. Некоторые аудиторы используют стандартный шаблон для всех своих аудитов и заполняют эту заготовку стандартными словами, описывая обнаруженные проблемы и рекомендации по их решению. Таким людям нужно менять профессию. Компании платят им не за стандартный набор проблем и решений. Компаниям нужно, чтобы эти специалисты ориентировались на определение рисков в их среде и на то, как в их среде эти проблемы устранить.

Написав такой ориентированный на их среду отчет, я передала мой труд нанявшему меня руководителю внутреннего аудита. Рэндаллу, в общем, он понравился. Ему не понравились мои находки, но он понял риски и узнал, что надо сделать для решения проблем. С отчетом в руках Рэндалл направился к своему начальству. Моя работа была на этом закончена.

Как и в других видах повседневной технической поддержки, в обучении безопасности не много романтики. Тем не менее оно столь же необходимо для долгой поездки, как и проверка тормозов или уровня масла в вашей машине. Игнорируя этот факт, InterMint чуть-чуть не оказалась выброшенной на обочину информационного хайвэя.

Вот что им следовало бы сделать во избежание этого.

Просвещать высшее руководство

Если руководство поднимет тревогу, что у них не все в порядке с безопасностью, то большинство в компании последует его примеру. Руководство должно обеспечить доступность занятий по безопасности для сотрудников всех уровней — это касается и высшего руководства.

Хотя все руководители должны проходить обучение безопасности, но не всегда можно на этом настаивать. По самой меньшей мере, высшее руководство должно представлять себе, почему безопасность важна.

Причина этого проста. Мало кто из генеральных директоров выделит средства, если ему непонятна важность цели. Ему нужно объяснить существующий риск. Подумайте об этом. Будете ли вы покупать страховку на случай землетрясения, если вы живете в Уэст-Бенд, штат Индиана? Вряд ли. Купите ли вы эту страховку, если ваш дом высится над разломом Сан-Андреас в штате Калифорния? Вы ответите «Да» (если только вы не законченный глупец), потому что вы осознаете риск. По моему опыту, руководители, осознавшие риски, более склонны выписывать чеки на обучение.

Отстаивать бюджет обучения безопасности

Не позволяйте выбрасывать в первую очередь статью на обучение безопасности из напряженного годового бюджета. Иначе придется заплатить позднее. Создаваемая сегодня безопасность требуется для скрепления всех последующих частей. Ведь вам не придет в голову вложить все средства в разработку нового продукта, а затем не запереть двери лабораторий? Конечно нет. Но, оставляя открытыми ваши корпоративные сети, вы с большой вероятностью можете подвергнуться такому же риску.

Включать вопросы безопасности в обязанности руководства

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

Когда система генерального директора InterMint была взломана, то перед одним из руководителей сразу же возникла цель по решению этой проблемы. Но то, что один из менеджеров имеет цель в вопросах безопасности, не много значит, если вся остальная цепочка управления не имеет таких целей. Если бы перед начальником Смиты была поставлена цель в отношении безопасности, то мне пришлось бы гораздо больше потрудиться для взлома систем операционного зала.

Делать обязательным обучение системных администраторов

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

Часто системные администраторы так заняты, что не могут оставить свои сети или клиентов. Не создавайте ситуацию, в которой системные администраторы не могут оставить свою работу хотя бы на неделю. Например, Тия не должна чувствовать, что если она будет отсутствовать неделю, то вся ее сеть обрушится, или же по возвращении ее будет ждать полный беспорядок. Для этого, пока она будет на занятиях, ее начальник должен поручить ее территорию другому сотруднику. Нельзя допускать и того, чтобы после полного учебного дня ваши люди должны были отработать еще шесть часов, делая ваших пользователей счастливыми. Системные администраторы просто сбегут с занятий, если увидят в них дополнительную нагрузку к той работе, которую они обязаны сделать в этот же день. А вы сами стали бы заниматься при таких условиях?

Чтобы заставить системных администраторов вашей компании получить необходимое им обучение, отражайте его в служебной характеристике.

Посещать семинары по безопасности

Семинары по вопросам безопасности — это прекрасное место для распространения и получения информации, которую трудно получить где-либо еще. Выберите некоторые из профессиональных семинаров по безопасности для посещения вашими системными администраторами (такие, как SANS и USENIX). Так как всех туда послать невозможно, то пошлите по одному человеку на каждую конференцию и поручите им поделиться полученными там знаниями. Если возможно, то пусть они сделают краткий доклад по возвращении с семинара.

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

Организовывать деловые ланчи

Большинству из нас крайне не хватает времени. Если вы пытаетесь втиснуть обучение в ваш перегруженный дневной график, то вспомните о том, что почти всем нужно есть! Попытайтесь проводить ежемесячно или ежеквартально доклады во время ланча. Выберите важные темы по безопасности и распределите намеченный материал между своими и приглашенными докладчиками. Это хороший способ держать ваших системных администраторов в курсе важных вопросов безопасности и эффективно использовать ценное время.

Распространять информацию по безопасности

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

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

Присоединиться к спискам рассылки по вопросам безопасности

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

Выпускать «белые статьи»

[34]

Я знаю множество действительно талантливых системных администраторов. Если вы один из них, то поделитесь своим опытом с другими. «Белые статьи» являются отличным способом это сделать.

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

Писать в периодические издания

Хороший материал ищут многие газеты, журналы и бюллетени, освещающие вопросы безопасности. Если у вас есть что рассказать о технической поддержке, о продуктах, инструментах и т. п., то поделитесь своей информацией с другими. Это прекрасный способ поразить публику.

Превращать инструменты в продукты

Если вы разрабатываете инструменты для поддержки безопасности в вашей среде, то подумайте о превращении их вашей компанией в выпускаемые продукты или выставьте их в Интернете для бесплатного пользования. Может быть, ваши инструменты смогут применять и другие люди.

Контрольный список

Используйте этот список для определения того, как идут дела с обучением в вашей компании. Можете ли вы поставить «Да» против каждого пункта?

— Все ли руководители (сверху донизу) выразили общее стремление к безопасности?

— Подкрепили ли они это стремление финансированием обучения безопасности?

— Имеется ли программа обязательного обучения системных администраторов?

— Включены ли в эту учебную программу темы по настройке и поддержке безопасности?

— Существуют ли политики обучения безопасности?

— Составлены ли они тщательно, отвечают ли современным требованиям и широко ли известны?

— Все ли сотрудники, включая и высшее руководство, обучаются их обязанностям в области безопасности в компании?

— Существует ли инфраструктура для повышения и продолжения образования в сфере безопасности?

Как и во многих подобных ей организациях, в больнице Rockland General решили усовершенствовать работу своих компьютерных систем путем оптимизации сети. План был прост. Выкатить за дверь старые системы, установленные на больших компьютерах (мейнфреймах), и вкатить системы с передовой архитектурой, которые перенесут Rockland в 21-й век. Для этого персонал Rockland спроектировал и установил высокопроизводительную распределенную сеть. Затем, как и планировалось, они выкатили старые компьютеры.

У руководства Rockland проект оптимизации пользовался большим успехом. Возглавившие проект специалисты по административным информационным системам Джо Дэвис и Марлен Шмидт были широко известны с лучшей стороны в медицинских кругах. К ним обращались за консультацией по подобным проектам и другие больницы. Дела Джо и Марлен шли хорошо, и они открыли свою компанию глобального масштаба по оказанию услуг больницам в оптимизации их систем.

Когда Мэтт Борланд приступил к руководству этими новыми системами, то вскоре обнаружил, что не все так хорошо, как казалось. Хотя Джо и Марлен покинули больницу героями, потребовалось лишь небольшое время, чтобы у Мэтта возникли проблемы с оставленным ими хозяйством.

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

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

Если вы недавно сами стали отвечать за техническую поддержку новых систем, то, возможно, лучше поймете затруднения Мэтта. Знаете ли вы, где в вашей сети находятся системы повышенного риска? Не оставили ли вам предшественники кошмар проблем безопасности, с которыми вы не знаете как справиться?

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

Каждый день менеджеры, директора по информационным технологиям и системные администраторы принимают системы, установленные другими людьми. Если при этом они не проводят аудит таких систем (вещь крайне редкая), то просто считают, что системы защищены. Это — рискованное предположение. Трудно обвинять в чем-то предыдущих руководителей и персонал технической поддержки, если вы уже распоряжаетесь системами шесть и более месяцев. Когда вы принимаете новые системы, то нужно немедленно их протестировать, чтобы знать, в каком состоянии они находятся. Независимо от того, что могли в прошлом наделать какие-то Мо, Ларри или Керли под конец рабочего дня, вы должны понять, что это теперь ваша система и работать с ней придется вам. Если вы являетесь системным администратором, то все обвинения будут направлены против вас. В конце концов, разве не вы обеспечиваете техническую поддержку систем?

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

Лишь случайно руководство Rockland General заглянуло за декорации. И пока вы не взглянете на состояние безопасности вашей сети, вы можете и не испытать такого счастья. Итак, рассмотрим подробнее детали этого аудита.

День 1-й: Тестирование безопасности

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

Доступность — это важная цель. Если вы не можете получить доступ к информации о пациентах из-за того, что системы постоянно не работают, то у вас появятся проблемы (и вполне осязаемые). Мэтт постарался обеспечить надежный механизм отчетов о доступности систем. Один из системных администраторов даже отвечал за отправку таких ежедневных и ежемесячных отчетов Мэтту. Таким образом, Мэтт проявлял живой интерес к производительности и доступности сети.

В это же время аудиторы больницы решили провести неплановый аудит безопасности. Аудит был задуман без оповещения кого-либо из персонала, обслуживающего компьютеры, — даже Мэтта.

Довольно занятно работать в компании десятки лет и не знать ее собственных аудиторов. Но. они действительно существуют. И появляются по малейшему сигналу. То есть как только почуют риск на вашем участке работы. Аудиторы — это особая порода людей. Они высматривают риск, докладывают о плохом состоянии дел и стараются риск уменьшить.

Менеджер аудита Rockland General Мария Планк наняла меня для проведения аудита их компьютерного зала. Как и большинство больничных аудиторов, Мария не разбиралась в системах своего заведения. Но это не представляло для нее проблем. Она чуяла риск за милю. Это было в ее крови. До нее дошли разговоры о высоком риске в компьютерном зале, и она решила нанять кого-то для проведения аудита. Ей не нужно было выяснять, каким являлся (если он только был) риск: для нее было достаточно получить результаты от эксперта. В этом месте на сцену вышла я.

Из разговора с Марией я не получила много информации. Она говорила лишь о подозрении на риск. Я попросила у нее сетевую схему компьютерного зала и список систем, подозреваемых на риск.

Мария предоставила мне временный офис с телефоном и системой. Она также создала мне в системе учетную запись — на случай, если я захочу здесь писать мой отчет. Это было прекрасно. Я взглянула на сетевую схему. Ого, да здесь тонны серверов баз данных. Меня это не удивило — так бывает после основательной оптимизации. Удивительным было другое: ни одному из этих серверов не был присвоен класс риска. Иначе говоря, ни один из них не был обозначен как критичный, особо критичный или некритичный.

Так как Мария не знала, какие серверы подвергаются большему риску, то я решила определить это сама. Есть два способа получить эту информацию. Вы можете открыть сессию на каждом сервере и осмотреть хранящуюся в них информацию. (Этот способ отнимает много времени при наличии большого количества серверов.) Вы также можете опросить системных администраторов. Я не могла этого сделать, так как их не предполагалось уведомлять об аудите. Оставался первый способ. Теперь я вступала в игру. Ее целью было раскрыть как можно больше информации и рисков прежде, чем меня обнаружат.

Первая фаза: Физическая безопасность

Чтобы начать игру, я должна была надеть костюм и исполнить свою роль. Моей целью было проникнуть в компьютерный зал без получения официального разрешения. Надев костюм, я попала в точку — я выглядела как своя.

Мария предложила мне пропуск в компьютерный зал, но я отказалась. Важной стороной моего аудита будет определение возможности, не вызвав подозрений, проникнуть в зал. Для этого я и принарядилась.

Вторая фаза: Прохождение через систему физического контроля

Я попросила Марию побыть в моем офисе и ждать моего звонка, если меня не пропустят. Легко было видеть, что мой подход ей понравился. (Ей самой, наверное, хотелось пойти со мной и посмотреть, что будет. Но она понимала, что у меня ничего не получится в ее присутствии.) Если я пройду, то одно это будет говорить многое о состоянии безопасности. Ведь положение дел, при котором любой сможет пройти в компьютерный зал, не имея на то полномочий, означало бы высокую степень риска. В случае моей удачи Мария уже бы окупила свои расходы. Все другие риски, какие я бы нашла, были бы лишь глазурью на пироге.

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

Серверы были расположены аккуратными небольшими рядами, и место выглядело чистым. Не было видно ни клочка бумаги. В принтерах тоже ничего не оставалось. Даже на полу не было ни пятнышка. С потолка не свисало кабелей, должно быть, их спрятали под пол. Можно было сказать, что эти парни здорово потрудились над внешним видом компьютерного зала.

Я прошлась вдоль рядов серверов, высматривая монитор, на котором бы не закрыли сессию. Бесполезно. Мне придется забираться в сеть другим способом. Я поблагодарила впустившего меня парня, одарила его улыбкой и вышла.

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

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

Третья фаза: Неавторизованный доступ

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

Иногда люди дают своим системам открытые имена (как в платежной ведомости), и по ним можно определить, какая информация в них хранится, даже не входя в них. Но не здесь. Все системы были обозначены буквенно-цифровой комбинацией (PR1, PR2 и т. д.). Никаких подсказок.

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

Я начала тестировать, доверяет ли мне какая-либо система компьютерного зала. В данном случае доверие означало, что системы были настроены доверять моей системе. Доверяемая система позволяет вам осуществлять легкий доступ без пароля. (Доверительные отношения в сетях могут быть опасными, так как если хакер взломает одну из систем, которой доверяют 50 других систем, то затем он сможет войти в эти 50 систем без пароля.) После того как скрипт был выполнен, оказалось, что мне доверяют десять систем. Не так плохо для меня. Но, определенно, плохо для больницы, для информации и для пациентов.

Я была в системе. Так как я имела учетную запись в машине, то мне представилась хорошая возможность получить информацию. Как только я вошла в первую машину (PR1), в мой офис зашла Мария. Я рассказала ей, что смогла без проблем пройти в компьютерный зал, но не сумела получить оттуда доступ к какой-либо информации. Она не поверила, что кто-нибудь смог бы зайти туда. Мне пришлось объяснять ей, почему я надела костюм.

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

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

Я запомнила эту мысль и начала искать доступ к остальным системам. За интересной работой время летит быстро. Я это поняла, когда было уже почти 5 часов дня. В любой момент за мной могла зайти Мария, чтобы проводить меня к выходу. Я приготовилась уйти. Результатом этого дня было получение доступа и полного контроля над 60 серверами. Кажется, системные администраторы Rockland установили их системы стандартным способом, без настройки безопасности или добавления патчей. Они также очень облегчили мне работу, установив доверительные отношения между значительным количеством серверов.

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

Мария появилась в 5.15. Всего я ей пока не рассказывала. Я дала ей понять, что смогла пробраться в некоторые системы и все еще собираю информацию. Бывает полезно придержать информацию о ходе аудита до его окончания. Я не люблю размениваться на мелочи, пока не соберу все факты.

Мария сообщила мне, что запланировала беседу на следующее утро. Я должна была встретиться с менеджером технической поддержки Мэттом Борландом и системным администратором Джилл Розенберг. Так как Мария была пунктуальна в составлении графика, то я решила закончить тестирование после проведения интервью сотрудников.

День 2-й: Риск для персональной информации

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

Джилл выглядела спокойной, но все равно волновалась из-за предстоящей беседы и проверки. (Нельзя сказать, что я всю вину перекладывала на нее, но в чем-то и она была виновна!)

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

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

Кроме отсутствия защиты систем, в Rockland также отсутствовала их классификация. Следующей моей задачей было допросить с пристрастием Джилл о содержимом систем. Получив от нее эти сведения, я могла бы больше времени уделить тестированию, сбору информации и написанию отчета. Мне нужно было узнать, какие из систем содержат критичную информацию, какой характер имеет эта информация и почему она считает эту информацию критичной. Это позволило бы мне при проведении аудита нацелиться на наиболее важные системы.

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

В моей деятельности я видела, как аудиторы задают вопросы техническому персоналу о том, на каких системах лучше запускать аудиторские программы. Иногда им отвечали честно. Иногда — нет. Даже не имея задних мыслей, персонал технической поддержки не всегда понимает, где в их сети находятся участки повышенного риска. Поэтому, если вам скажут, что DS19 является системой повышенного риска, эту информацию все равно надо проверить.

Джилл рассказала, что истории болезни пациентов хранятся на серверах с именами от PR1 до PR10. Ага! Теперь я знала, что буквы PR обозначали историю болезни. Как я об этом не догадалась раньше? Как бы то ни было, эти системы должны считаться особо критичными и в них должны быть установлены средства защиты. Как я уже рассказывала, эти системы были взломаны мной в первую очередь.

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

• Никто и никогда не проводил оценку рисков.

• Политики и процедуры были неполными.

• Системы, содержащие жизненно важную информацию, были установлены стандартным способом.

• Информация могла быть легко изменена, украдена или уничтожена без следа.

Очевидно, никто не уделил достаточно (или вовсе не уделил) внимания рискам изменения, уничтожения или кражи информации, когда ее переносили из отдельного компьютера в серверы сети. В результате оказались подвергнуты риску истории болезни.

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

В данном случае эта кривая медленного накопления опыта могла бы оказаться роковой для некоторых пациентов Rockland General. Но счастье оказалось на их стороне.

Не полагаясь на удачу в судьбе, в Rockland General должны были бы сделать следующее.

Оценить риски

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

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

Классифицировать системы

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

Так как каждая компания имеет свой уровень развития и несет ответственность за свою информацию, то классификация и определение уровней безопасности должны проводиться исходя из конкретных условий (меняющихся от компании к компании).

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

Запретить стандартные установки систем

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

Зачем оставлять приглашение хакерам, если вы можете этого не делать? Лучше внедрите правильные политики и процедуры по установке систем в вашей сети.

Не быть слишком доверчивым

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

Извлекать уроки из прошлого

Часто говорят, что тот, кто забывает историю, обречен ее повторить. Только что назначенные менеджеры и системные администраторы не должны считать безопасность принимаемых ими систем достаточной без проверки, проведенной собственноручно, — не зависимо от репутации предшественников. Если бы в данном аудите не были вскрыты оставшиеся от предшественников проблемы, то Мэтт мог бы испытать на себе, как доверие к Джо и Марлен разрушит его собственную репутацию.

Выбирать цели при сокращении бюджета

Бездонных бюджетов не бывает, и в наступившей эре бережливости трудно выжить. Но и в этой ситуации рискованно искать обходные пути.

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

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

Проводить тестирование безопасности

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

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

Сделать руководителей подотчетными

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

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

Не расплачиваться за других

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

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

Включать обучение в бюджет

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

В Rockland General технический персонал перенес всю особо критичную информацию больницы из большого старого компьютера, который они знали, как обслуживать, в незнакомую распределенную среду. И в процессе этого руководство не обеспечило им ни одного занятия по безопасности. Неудивительно, что с безопасностью возникли такие большие проблемы!

Подсчитывать очки

Мы уже обсудили виды рисков, сопровождающих краткосрочное мышление. Теперь поговорим об одном из способов эти риски избежать: о подсчете очков!

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

Контрольный список

Используйте этот список, чтобы определить, подвергается ли ваша компания риску по причине незнания того, каким этот риск является. Можете ли вы поставить «Да» напротив каждого пункта?

— Проводилась ли недавно оценка риска?

— Классифицированы ли системы по уровню риска (некритичные, критичные, особо критичные и т. д.)?

— Привязаны ли цели руководства к вопросам безопасности?

— Проводятся ли плановые аудиты для проверки ранее сделанной оценки риска?

— Привлекаются ли, при необходимости, внешние аудиторы для оценки и уменьшения риска? (Некоторые владельцы информации еще не знают, какие ценности они имеют!)

— Все ли сотрудники (как менеджеры, так и системные администраторы) назначаются на должности и оцениваются, основываясь на выполнении ими задач по обеспечению безопасности?

Когда пять лет назад компания Global Chips подключилась к Интернету, она поставила и брандмауэр. Брандмауэр в то время справлялся со своими функциями — обеспечивал сотрудникам доступ к внешнему миру и преграждал путь хакерам. Однако технологии быстро меняются, a Global Chips годами не поддерживала и не улучшала свой брандмауэр должным образом. Это открыло дверь в их сеть.

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

Администратор брандмауэра Джозеф Уизерс все же смог определить, как хакер взломал брандмауэр, и закрыл дыру.

К сожалению, сага о брандмауэре продолжалась. Global Chips столкнулась с серией взломов. Тем временем брандмауэр стал повседневной целью атак хакера. После каждого взлома Джозефу приходилось устранять новую обнаруженную проблему. Но все попытки отследить путь хакера для установления конкретного лица были бесполезны (что не является необычным). Поэтому Джозеф не знал, имеет ли он дело с хакером-одиночкой или с группой хакеров.

Директор по информационным технологиям Аманда Миткин получала информацию о каждом взломе. В сети происходило слишком уж много взломов, и Аманда захотела узнать причину этого. Довольно интересно, что менеджер, отвечавший за комплекс брандмауэра в Global Chips, не задавал себе такого же вопроса. Он считал системного администратора героем за то, что тот устранял возникающие при этом проблемы.

Аманда была рассудительна. Когда компания устанавливает брандмауэр, то весь трафик, идущий из интранет в Интернет (или наоборот), проходит через брандмауэр. Он установлен для защиты. А не для учебной стрельбы!

Если высшие руководители спрашивают, почему происходят взломы, до того, как об этом спросят линейные менеджеры, то видно, что эта проблема последних не интересует. К счастью для Global Chips, Аманда была встревожена фактами взломов и потребовала провести расследование.

День 1-й: Как выгоняли плохих парней

Аманда поручила провести расследование директору внутреннего аудита Перри Слоуну. Перри был также озадачен количеством успешных взломов. Так как у его сотрудников не было опыта в данной области, то Перри нанял для проведения аудита консультанта по вопросам безопасности.

И тут на сцене появляюсь я. Перри сообщил, что взломы стали повседневным явлением, но это все, что он знает. Так как он уже понимал серьезность сложившейся ситуации, то я не стала тратить время на определение уровня риска. Хакер уже сделал это за меня.

Вместо этого главным в аудите было ответить на вопрос: «Почему мы не можем запереть перед хакером двери?»

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

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

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

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

В основном эти вопросы будут касаться администратора брандмауэра Джозефа Уизерса. В конце концов, это он стоял ночами, пытаясь отогнать хакера, Тед запланировал мне встречу с Джозефом на завтра, и попросил его принести необходимую документацию — политики и процедуры брандмауэра, процедуры реагирования в чрезвычайных ситуациях и сетевую схему.

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

Тед сообщил мне общие сведения о компании и произошедших взломах. Время моей командировки шло, и я начала писать отчет по аудиту. Обычно я пишу отчет в последнюю очередь, но у меня уже было достаточно информации о взломах для того, чтобы начать писать черновой вариант отчета. Тед проводил меня в офис для посетителей, я достала свой ноутбук и приступила к работе. Я закончила черновой вариант, чтобы внести в него детали после проведения аудита. (В настоящее время, я могу только строить догадки, а за них мне не платят. Эти парни хотели фактов, и у меня их скоро будет достаточно.) Для первого дня было уже хорошо.

День 2-й: Администратор брандмауэра

Тед встретил меня в холле и выписал пропуск. Он проводил меня до офиса Джозефа. При первой встрече Джозеф немного нервничал. Конечно, многие люди волнуются при приходе аудитора, поэтому я попыталась разрядить обстановку (с помощью хорошей шутки). Но Джозеф не оценил мой юмор и определенно не был склонен к приятной беседе. Отбросив мягкие манеры, я попросила у него документацию, которую заказывала. Он смог дать мне только сетевую схему. Когда я его спросила об остальной документации, то он сообщил: «У меня нет политик и процедур брандмауэра; это не моя работа - их писать. Я знаю, как настроен брандмауэр и что делать, если происходит взлом».

Вот это парень. Я ошиблась, посчитав, что он волнуется. Он был самонадеян! Он полагал, что раз знает, как поддерживать брандмауэр, то этого достаточно. Легко было видеть, что он не понимает ценность политик и процедур и видит во мне только аудитора (переводя это слово как «зануда»).

Временная безопасность

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

Я еще поговорила с Джозефом и узнала, что в Global Chips имеется отдельное подразделение обеспечения безопасности для аудита компьютерной среды, для написания некоторых (но не всех) политик безопасности и для действий на случай вторжения. Джозеф отвечал за брандмауэр. Когда происходил взлом, то он посылал сообщение по пейджеру для вызова сотрудников группы обеспечения безопасности. Джозеф настойчиво подчеркивал: «За безопасность отвечают сотрудники группы обеспечения безопасности, а не я. Это их работа — обеспечивать выполнение политик безопасности компании». Было ясно, что я должна была выслушать другую сторону и побеседовать с кем-нибудь из группы обеспечения безопасности.

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

Администрирование брандмауэра является серьезной работой. Она должна восприниматься серьезно и администратором, и его начальником. Global Chips не имела крепкой брони, чтобы отразить угрозы для их информации. В любое время хакер мог проникнуть через брандмауэр и изменить, уничтожить или украсть информацию. Временное решение проблемы, которое одобряется руководством, не может считаться ни правильной реакцией сотрудников, ни правильным отношением руководства к такой реакции.

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

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

В моем отчете было определено множество рисков для безопасности. Их перечень возглавили:

• Неправильное распределение ролей и обязанностей.

• Ненадлежащие управление брандмауэром и его поддержка.

• Отсутствие официальных политик и процедур.

Так как я начала составлять мой итоговый отчета еще вчера, то внести в него детали было легко. Я потратила еще несколько часов на отчет, затем взяла направление на свои холмы. По дороге домой я чувствовала себя опустошенно. Легче иметь дело с компьютерами, чем с людьми. Человеческие существа очень сложны — иногда даже слишком сложны!

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

Мой последний день: Отношение к работе может говорить о многом

Я услышала звонок будильника, когда он уже заканчивался. В некоторые дни 4.30 утра наступает слишком быстро. Лишь несколько минут у меня ушло на то, чтобы сосредоточиться на событиях предстоящего дня, включая и окончание моей работы в Global Chips.

Это заставило меня двигаться. Я вылезла из постели и решила побегать на домашнем тренажере, не показываясь на люди, Закончив пробежку, я быстро приняла душ, собрала себя воедино и выскочила за дверь.

По дороге в Силиконовую долину я ничем не могла объяснить слепоту Карла, который считал, что его эксперт по брандмауэрам оказывает ему хорошую услугу. Как удается людям наподобие Джозефа легко дурачить таких, как Карл? Могут ли такие руководители, как Карл, действительно быть такими беспечными и небрежными в отношении охраняемой ими информации? Может быть, они убеждают себя в том, что все в порядке, из-за того, что не хотят думать об обратном? Думаю, что это вопросы, на которые даже аудиторы не смогут ответить.

Через несколько часов отчет был закончен. Встреча с Перри была назначена на 3.00 дня, и я была к ней готова. Точно в 3.00 я и Тед прибыли в здание Перри, чтобы представить мой отчет. Перри нас ждал.

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

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

Роли и обязанности являются ключом к успеху в любой программе обеспечения безопасности. Главной проблемой в этой истории было то, что ни одна из групп технической поддержки в Global Chips не взяла на себя ответственности за написание и выполнение политик и процедур для брандмауэра. Такой подход оставил открытой всю сеть — как будто бы они ждали хакера. Вот что должна была сделать Global Chips вместо этого.

Определить роли и обязанности

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

Разработать политики и процедуры для брандмауэра

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

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

«Кормить» свой брандмауэр

Брандмауэры обычно состоят более чем из одной машины. В некоторых компаниях брандмауэром считается целый комплекс, в который входят хост-машины, сети и маршрутизаторы. Брандмауэры нужно «питать». Для поддержки «здоровья» брандмауэра обеспечьте его профессиональным администратором, регулярно проводимой модернизацией, современными патчами и обучением. Не допускайте того, чтобы замок на вашем брандмауэре заржавел, как это случилось в Global Chips.

Читать свои контрольные журналы

Вам не принесет много пользы поддержка брандмауэром множества контрольных журналов, которые вы никогда не просматриваете. Хотя Global Chips была взломана много раз, они легко отделались потому, что у них были хорошие контрольные механизмы, сообщающие им о взломе системы хакером.

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

Использовать программы обнаружения взлома

Программы-детекторы не могут со 100-процентной вероятностью обнаруживать взломщика, но они являются хорошим началом. Программы-детекторы могут дать вам лучшее представление о масштабе угрозы, с которой вы столкнулись. В течение 2000 года в Пентагоне обнаружили 245 успешных кибератак. Так как в Пентагоне были внедрены хорошие механизмы обнаружения, то его должностные лица знали о том, что вместе с тем было 24 000 безуспешных атак. Знание их количества дало более ясную картину реального риска.

Ваша информация может быть не столь привлекательной, как хранящаяся в Министерстве обороны, но не полагайтесь на это. А если вы подключились к Сети, то вряд ли будете в большей безопасности. В своем исследовании, проведенном в декабре 1996 года, Дэн Фармер (известный гуру в вопросах безопасности и соавтор таких программ, как SATAN) установил, что уровень использования программ-детекторов угрожающе низок. Дэн провел несанкционированное исследование с целью прозондировать состояние защиты коммерческих веб-сайтов. Из более 2000 сайтов, зондируемых им без уведомления, оказалось только три сайта, владельцы которых связались с ним и спросили, что он делает! Удивитесь ли вы тому, что ваш сайт был частью этого исследования?

Улучшилось ли положение с тех пор? Не настолько, как я ожидала (или мне хотелось бы). По оценке таких экспертов, как, например, поставщик средств защиты Spectrum Systems, все еще обнаруживается только 1 процент от успешных или предпринятых компьютерных атак. Главное изменение состоит в том, что сегодня стало больше онлайновых коммерческих целей и стало больше использоваться веб-сайтов для обмена финансовыми средствами и информацией. Информация о вашем местном хозяйственном магазине, может быть, и не имеет большой привлекательности, но зато информация кредитных онлайновых карточек его клиентов, скорее всего, ее имеет.

Реагировать быстро!

Быстрая реакция на взлом администратора брандмауэра и администратора группы обеспечения безопасности Global Chips объясняется тем, что их действия были отлажены реагированием на многочисленные взломы. Будем надеяться, что вы никогда в таком положении не окажетесь.

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

Требовать подтверждений безопасности

В своем Special Report on Security на сайте Computerworld Пол Страссман (Paul Strassman) поясняет: «Усовершенствование безопасности системы, проектирование которой основывалось на презумпции невиновности и честности, часто оказывается слишком дорогим или запоздалым, чтобы его стоило проводить». Чтобы избежать такой ситуации, не полагайтесь на то, что все идет гладко.

Global Chips повезло из-за того, что ее директор по информационным технологиям была информирована о происходящих взломах. Когда их количество возросло, она потребовала установить причину происходящего. Вашей компании может так не повезти, если вы не имеете хороших процедур эскалации и не в курсе состояния безопасности вашей среды. Знаете ли вы, в каком состоянии находится ваш брандмауэр? Сколько ему лет? Кто его поддерживает? Имеются ли политики и процедуры? Если вы являетесь менеджером высшего уровня, то потребуйте доказательств состояния безопасности (итоговый отчет для руководства).

Проводить аудиты

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

Также нужно обеспечивать проведение аудитов. Профилактические аудиты являются важной частью выявления проблем, пока о них не узнал хакер. Вы должны проводить тестирование вашего брандмауэра как из интранет, так и из Интернета. Тестирование на проникновение покажет вам способность вашего брандмауэра отогнать непрошеных гостей. Если вы не проверите эффективность вашего брандмауэра, то не сможете быть уверены в том, что он действительно работает.

Углублять знания

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

Я не имею в виду, что вам нужно знать каждую мельчайшую деталь, но руководители должны понимать, какие средства безопасности они используют, какие еще средства есть, а каких не хватает.

Для того чтобы отделить свои системы от сети музея, Джеральд должен был создать свою сеть и нанять своего системного администратора. На это требовалась добавка к его бюджету в виде приличного количества долларов. Для одобрения такого шага Джеральд должен был встретиться с руководством музея.

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

День 1-й: Сбор доказательств

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

Узнав это, я поняла, что впереди у меня тяжелая работа. Во-первых, я должна была установить, действительно ли системы не защищены. И если так, то затем я должна буду определить причину этого.

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

Так как главной задачей аудита была проверка предположения Джеральда, то я решила провести аудиты систем, интервьюирование персонала и тестирование на проникновение.

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

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

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

Я обратилась снова к Кирстен. Она показала мне группу систем, которые она считала представлявшими наибольший риск. Мы немного поговорили об этом, чтобы убедиться, что я ничего не пропустила. Со списком особо критичных целей я была готова начать аудит.

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

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

Очевидно, кто-то не обратил на это внимания при установке систем. А может быть, они просто доверяли каждому, кто имел доступ к сети музея, В современном мире такой уровень наивности может привести к большой беде! По словам Майкла Андерсона, эксперта по компьютерному праву и бывшего агента Министерства финансов США, в 85 процентах случаев промышленный шпионаж ведется изнутри компании-объекта.

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

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

Когда все было рассказано и сделано, мой список рисков выглядел следующим образом:

• Настройки безопасности особо критичных систем были недостаточными.

• Сами системы не были классифицированы (некритичные, особо критичные и т. д.).

• Легко можно было получить права суперпользователя.

• Пароли легко угадывались.

• Не были установлены патчи, повышающие безопасность.

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

• Контрольных журналов просто не было.

• Имелась избыточность разрешений на доступ к файлам.

• Выполнялись ненужные сетевые службы.

Короче, Кирстен была права. Системы были широко открыты. Ни один из серверов базы данных, подвергавшихся высокому риску, не имел серьезной защиты, Почему? Для завершения аудита я должна была получить ответ на этот вопрос.

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

Я уже собирала вещи, когда вспомнила, что мне нужно лететь домой и встретиться в субботу с моей сестрой. Мы поедем с ней в Сан-Франциско на уикенд, где я буду ее баловать. Она гораздо младше меня — ей. 13 лет, поэтому я по возможности выкраиваю для нее время по выходным: она удовлетворяет свои капризы, а я трачу на это деньги. Я похожа на бабушку, которая не успела состариться. В этот уикенд мы должны посетить в Сан-Франциско столько музеев, сколько сможем. Среди всего прочего, девочка занимается изобразительным искусством (и у нее это получается) и любит ходить в музеи и картинные галереи. Было бы хорошо провести с ней выходные и посмотреть на музеи с другой точки зрения — не как на объекты с высокой степенью риска и летучестью информации из-за незащищенности систем, но как на само искусство ради искусства.

Кирстен проводила меня в холл и сказала, что встретит меня в понедельник в 9.00.

День 2-й: Системные администраторы против группы обеспечения безопасности

Выходные всегда проходят быстро, Я не успела это понять, как очутилась в холле, ожидая Кирстен и в готовности закончить аудит. Я немного волновалась.

Мне предстояло во второй части аудита показать, почему системы не защищены, и это означало проведение бесед. Я не боюсь бесед и встреч с людьми, но из слов Кирстен поняла, что ввязываюсь в войну, развязанную из-за настроек, политик и процедур и продолжающуюся уже несколько лет.

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

У меня было ощущение, что за обнаруженными рисками кроется война между группой обеспечения безопасности и системными администраторами. Вскоре я в этом не сомневалась.

Кирстен запланировала интервьюирование всех причастных к этому делу игроков. Она любезно предоставила мне несколько свободных часов утром перед проведением бесед. Я это оценила. (Кто знает, как выглядят эти парни до утреннего кофе?)

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

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

Чем дальше я продвигалась по материалам, тем больше убеждалась в том, что вначале документация была составлена кем-то, кто понимал важность политик и процедур. Вместе с тем у меня складывалось впечатление, что этот человек уже ушел из группы обеспечения безопасности или даже из музея.

Теперь я была готова к встречам с персоналом. К сожалению, это будут встречи с группами. Групповое интервью часто сопровождается напряженностью, — даже когда не ведется война. Я пошла на эту первую встречу, думая, что всегда смогу затем поговорить один на один с ключевыми игроками.

В чьих руках безопасность

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

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

Я продолжала на них давить: «Разве вы не отвечаете за настройку безопасности систем?» Они отвечали: «Да, но группа обеспечения безопасности должна сказать нам, как это сделать. Так как их политики и процедуры безопасности лишены всякого смысла, то мы не знаем, как настраивать системы».

Я спросила далее о том, кто из них работает здесь дольше других. Один из системных администраторов поднял руку и ответил: «Я работаю уже пять лет».

Я спросила: «И эта проблема была все эти годы?»

«Да, я так думаю» — был его ответ.

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

Перекладывание ответственности

Затем я встретилась с группой обеспечения безопасности. Как и системные администраторы, персонал этой группы также знал, что сеть не защищена. Разумеется, они во всем обвиняли некомпетентных системных администраторов. Я их спросила, показывали ли они системным администраторам, как производить настройку безопасности, и они сообщили мне, что политики и процедуры могли быть взяты системными администраторами из Сети. Мне было сказано: «Любой, кто представляет, что он делает, должен знать, где их найти!»

Беседа с группой обеспечения безопасности подтвердила мои прежние подозрения. Действительно, парень, написавший политики и процедуры безопасности, покинул компанию два года назад. Они недавно поручили одному из сотрудников посмотреть, как их можно обновить. К сожалению, простое усовершенствование процедур на этой стадии было слишком незначительным, слишком запоздалым. Системы уже были широко открыты, а политики стали действительно непонятными.

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

• Группа обеспечения безопасности отвечала за первоначальное написание политик и процедур. Но никто из них не отвечал за их обновление.

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

• Любой из системных администраторов, кому бы посчастливилось найти эти политики и процедуры, не смог бы их понять. Большей частью эти политики и процедуры были так запутаны и плохо написаны, что были непригодны к применению.

• Руководство, очевидно, не считало проблему политик и процедур важной.

Действительные причины музейной дилеммы не были техническими. Они заключались в инертности, политиканстве и плохом руководстве. Не допускайте, чтобы такое произошло с вашей сетью.

Главной проблемой было то, что музей эксплуатировал свою сеть без политик и процедур. Политики и процедуры составляют фундамент безопасности. Без них невозможно поддерживать управление безопасностью. Как своими действиями, так и бездействием персонал музея создал обстановку, в которой стало небезопасно пользоваться их сетью.

Вот что они должны были сделать вместо этого.

Возложить на кого-либо из сотрудников ответственность за политики и процедуры.

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

Что более важно, добейтесь того, что ваши политики и процедуры выполняются. Напомню, что в 2000 году на оборонные системы США было предпринято 250 000 попыток кибератак. Из 245 атак, которые были успешными, 96 процентов могли бы потерпеть неудачу, если бы пользователи выполняли имеющиеся протоколы безопасности.

Разграничить обязанности по поддержке безопасности между группами

Если в вашей компании имеются группы обеспечения безопасности и группа системных администраторов, то вы должны ясно определить их роли и обязанности. Являются ли системные администраторы ответственными за настройку систем? Отвечает ли группа обеспечения безопасности за информирование о неувязках?

Если обязанности не будут закреплены официально, то ничего не будет делаться. И будет не с кого спросить за возникшие проблемы.

После четкого определения ролей вы должны добиться того, чтобы каждая группа делала то, чего от нее хотят. Проследите это! В нашей истории предполагалось, что группа обеспечения безопасности отвечает за политики и процедуры. И все же они не обновляли процедуры, не писали их правильно и понятно для каждого и не сделали их легкодоступными. Короче, они не выполнили своей работы. Кто-то должен был это заметить и проследить, чтобы такая работа была проделана.

Не надеяться на чудо

Системные администраторы, отвечавшие за настройку безопасности, не знали, как это делать. Из-за плохого состояния процедур в такой неразберихе действительно виноваты не они. Их вина тем не менее была в том, что, вместо того чтобы сообщить о проблеме руководству и работать над ее решением, они ничего не делали. Может быть, они ждали, когда на их серверы сойдет небесная благодать?

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

Пересматривать процессы

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

Я думаю, вы слышали рассказ об отрезанном куске говядины. Некая домохозяйка всегда отрезала конец куска мяса, перед тем как его готовить. Однажды муж спросил ее, зачем она это делает. «Я не знаю. Моя мать всегда так делала», — отвечала она и спросила свою мать об этом. Та ей ответила: «Я не знаю. Моя мать всегда так делала». Наконец, прабабушка рассказала женщине: «После этого кусок помещается в сковородку». Оказалось, что у старой женщины была только одна сковорода, и она была слишком мала, чтобы вместить кусок говядины стандартного размера. Разумеется, у ее потомков были сковородки всех размеров. Они просто выбрасывали лучшую часть куска по традиции, так как не хотели пересмотреть процесс.

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

Иногда — просто сдаться

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

Выполнять свои обязанности

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

Как и многие другие компании в 90-х годах, фирма S&B Systems искала прогрессивные методы ведения своего бизнеса. И как многие свои современники, фирма ухватилась за идею аутсорсинга.

В принципе аутсорсинг означает оплату услуг другой компании по выполнению части ваших функций. Например, S&B не хотела непосредственно нанимать (и платить им жалованье) 70 секретарей для работы по приему посетителей в различных странах. Вместо этого они передали эту службу подрядчику. Такой секретарь, сидящий в холле, выглядел внешне как служащий S&B Systems, но в действительности он работал в фирме по обеспечению обслуживающим персоналом с названием Job Power. После успешного аутсорсинга с секретарями S&B стала искать, как применить этот подход и для другого персонала.

Однажды руководство компании решило перевести на аутсорсинг все операции по перевозкам. Оно выбрало в качестве партнера фирму Express Time, имевшую многолетний опыт своевременных поставок и солидную репутацию. Для облегчения этого процесса S&B подключила Express Time к своей сети. Переход, казалось, проходил плавно. Вскоре у S&B Systems не было забот о поддержке и обеспечении персоналом отдела перевозок. Их выбор Express Time казался огромной удачей для обеих сторон.

Но высшие руководители S&B Systems и Express Time не знали, что система, соединяющая две компании, не была настроена так, чтобы обеспечивать безопасность. Каждый, кто получал доступ в эту межсетевую систему, мог заходить то в одну компанию, то в другую и собирать, изменять или уничтожать информацию как в S&B Systems, так и в Express Time.

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

И действительно, только случайно S&B Systems обнаружила, какой большой риск создает межсетевое соединение.

День 1-й: Осмотр средств обеспечения безопасности

Все началось довольно обычно. Меня наняли как независимого аудитора для тестирования безопасности некоторых систем S&B Systems. Одному из менеджеров технической поддержки S&B, Шелли Бергер, потребовался аудит клиентской сети, так как ее персонал планировал переход на новую версию (апгрейд) операционных систем сети. Планировался также апгрейд брандмауэра, соединяющего их сеть с Express Time. Перед проведением такого перехода Шелли захотела узнать, как хорошо настроены средства безопасности систем.

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

Группа Шелли уже закончила аудит брандмауэра и теперь готовилась к его апгрейду. Поэтому основное внимание я обратила на внутренние системы S&B.

Шелли предоставила мне офис для посетителей с видом из окна, собственной системой, схемой сети и толстой стопкой политик и процедур. Она также дала мне краткий список персонала технической поддержки S&B. Обязанности по обеспечению безопасности разделялись между несколькими группами. В двух словах: у них имелись группа обеспечения безопасности, группа системных администраторов и группа обслуживания сети. Группа обеспечения безопасности отвечала за проведение аудитов безопасности, реагирование на взломы и рецензирование кода. Системные администраторы отвечали за установку систем, проведение апгрейда и работу с пользователями. Группа обслуживания сети отвечала за техническую поддержку сети и брандмауэрных соединений. Я знала, что такая структура технической поддержки довольно типична для компании с размерами? как у S&B. Меня особенно впечатлила глубокая продуманность описания ролей и обязанностей.

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

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

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

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

Я знала, что Шелли скоро проводит меня к выходу, поэтому я посвятила последние минуты просмотру сетевой схемы. В компании S&B имелись тонны серверов базы данных, и клиентская сеть была видна сразу. Было также видно, что к сети было подключено три различных клиента. Каждое соединение было защищено своим брандмауэром. Я догадалась, что это были именно те брандмауэры, которые они только что проверили и готовили к апгрейду.

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

День 2-й: Сетевые соединения

Приехав в S&B Systems, я начала снова думать о сетевой схеме и вспомнила, что они только что провели аудит безопасности соединений их клиентской сети. Заехав на стоянку, я пыталась понять, кто же у них делал аудит.

Шелли уже ждала меня в холле. По дороге в мой временный офис я рассказала ей о том, что вчера потратила вторую половину дня на просмотр политик и процедур. Когда мы прибыли в мой офис, я показала ей сетевую схему и заметила: «Я не представляла себе, что несколько различных компаний подключены к вашей сети». Она ответила: «Это так. Мы многое перевели на аутсорсинг в этом году. Мы оставили в компании лишь в главные функции, а остальные отдали подрядчикам». Показывая на сетевую схему, я спросила: «Это те системы, на которых только что проводился аудит?» Она ответила: «Да, и вон те системы тоже». Шелли показала на группу серверов баз данных (обозначенных как DBS1 — DBS 10), которые явно принадлежали интранет S&B и не были похожи на клиентскую сеть (экстранет).

Но Шелли сказала: «Нет, это тоже клиентские системы. Видите ли, мы в прошлом году перевели на аутсорсинг отдел перевозок, а это системы его баз данных». Это все проясняло. DBS должно было обозначать «база данных о перевозках» (database shipping).

Теперь я почувствовала прилив энергии. Это как раз был такой риск, который я искала.

Шелли начала рассказывать мне, что когда S&B переводила на аутсорсинг операции по перевозкам, то она подключила системы DBS к сети Express Time. S&B по-прежнему поддерживала и обновляла базу данных, но Express использовала информацию о перевозках, хранящуюся на этих системах, для поставки изготовленных машин потребителям.

При более пристальном изучении схемы я заметила, что система DBS 10 имела два сетевых соединения. Одно шло к интранет S&B, а другое не имело обозначения. Я предположила, что оно идет к сети Express Time.

В технике Шелли не очень разбиралась. Иначе она бы поняла, что из сказанного ей выходило так, что серверы службы перевозок S&B были подключены к сети Express Time. Таким образом, как только вы открывали сессию на сервере перевозок, вы могли получать доступ к любой системе сети Express Time. И наоборот, открытие сессии на сервере перевозок со стороны Express Time позволяло получать доступ к любой системе сети S&B.

Чтобы пояснить сказанное, представьте себе замок на двери вашего офиса. Пусть вы работаете на 20-этаже здания. На том же этаже располагается компания, которой вы передали по аутсорсингу все ваши операции по закупкам. Разумеется, у вас есть ключ от вашего офиса на 20 этаже. Но, хотя партнер этого не знает, ваш ключ подходит и к его двери. Вы можете пробраться в его офис и просматривать его файлы, пока его там нет. Вы даже можете внести изменения в его финансовые документы, чтобы поправить свои дела за счет аутсорсинга! Таким же образом ключ вашего партнера подходит и к вашей двери. Каждый из его фирмы может пробраться к вам и тоже поменять информацию в ваших файлах по своему усмотрению.

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

Сначала Шелли устроила мне встречу с системным администратором Эндрю Клейном. Эндрю только что поступил на работу в качестве сотрудника по технической поддержке систем сети S&B. Он имел опыт по обслуживанию больших компьютеров и начал осваивать UNIX около года назад, так как считал, что мейнфреймы вымирают, как динозавры.

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

Я немного поговорила с Эндрю о риске, которому подвергаются как клиентские системы, так и системы S&B. Казалось, он очень удивлен тем, что риск, о котором я говорила, вообще возможен. Я настоятельно ему порекомендовала пройти обучение по вопросам безопасности, если он рассчитывает и дальше работать в качестве сотрудника технической поддержки сети такого типа.

Мое следующее интервью было с администратором группы обеспечения безопасности Джимом Барнсом. Джим принес мне копии отчетов по аудитам безопасности, которые охватывали и систему DBS. Просмотрев их, я увидела, что он проверил некоторые важные системные настройки, но не все из них. В его отчетах было указано на избыточность разрешений доступа к файлам и ненужные сетевые службы, но он никогда не проверял установку патчей, повышающих безопасность, и не пытался взламывать пароли пользователей. И конечно, он не ответил на вопрос, вполне подходящий для телевикторины $64 000 Question: «Почему DBS 10 была подключена к двум сетям без какой-либо защиты брандмауэром?»

Джим выглядел очень смышленым парнем, но он только начинал свою карьеру и не имел опыта в аудите систем. В этом деле он был новичком. Так как в компании бытовал подход к обучению «плыви или тони», то власть предержащие проинструктировали его: «Послушай! Иди и проведи аудит этих систем».

Разумеется, Джим не имел ни малейшего представления, как правильно проводить аудит. Требовать от кого-либо провести аудит группы систем без выработанного подхода или соответствующего обучения глупо и жестоко по отношению к этому сотруднику. Это похоже на то, как если бы ваш механик из автосервиса попросил вас припарковать машину на железнодорожных путях тогда, как вы оба знали бы, что у машины неисправен стартер. «Не беспокойтесь, — говорит он вам. — Если машина не будет заводиться, когда покажется поезд, то позвоните мне». Это не тот уровень риска, с которым бы компании могли мириться в своих сетях.

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

Дни 3-й и 4-й: Понимает ли проблему руководство?

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

Теперь мне нужно было потратить некоторое время на объяснение рисков и проблем руководству. Риск, который представляют такие виды конфигураций, труден для понимания.

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

Я покинула компанию, оставив после себя почти бесцветные лица руководителей S&B Systems. Теперь мяч был на их половине площадки, и они должны были решать проблемы сами.

Удача S&B Systems и Express Times заключалась в том, что я обнаружила представляющее риск клиентское соединение. Разумеется, такое подключение не должно было быть сделано.

Вот что S&B следовало сделать, чтобы избежать проблем.

Проводить оценку безопасности

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

Однако имейте в виду, что его не обязательно должен проводить человек. В Sun мы автоматизировали проведение аудита безопасности при помощи инструмента, названного AutoHack. AutoHack тестирует более 20 000 систем на наличие уязвимых мест и посылает системам сообщения об обнаруженных проблемах. Он отличается в лучшую сторону тем, что в своем сообщении указывает степень серьезности обнаруженной проблемы. При обнаружении в системе серьезной проблемы он сообщает о ней ее владельцу.

Проводить ее правильно

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

Проводить ее регулярно

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

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

Решать обнаруженные вами проблемы

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

Риск сам по себе со временем не исчезнет. Напротив, он использует такую передышку для того, чтобы вырасти в размерах и сделаться более сложным. Если вы откладываете решение проблемы безопасности потому, что у вас нет средств в этом квартале, то вы будете платить гораздо больше в более поздний срок. Представьте себе затраты S&B Systems в том случае, если хакер нащупает обнаруженное мной незащищенное место и перекроет сбыт всей их продукции.

Не использовать ПОДХОД «ПЛЫВИ ИЛИ ТОНИ»

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

Будет мало пользы от назначения нового администратора средств безопасности, если вы не дадите ему обучения, необходимого для работы. В идеале вы, конечно, можете нанять опытного специалиста. Но это нелегко сделать. Профессионалы в области обеспечения безопасности пользуются большим спросом. Как сообщает ZDNet, недостаток в персонале данной профессии будет составлять по прогнозу на ближайшие годы 50 000-75 000 человек. Их оклады уже возросли за 2001 год на 50 процентов — верный признак надвигающейся их нехватки.

Чувствуя отчаяние работодателей, некоторые предприимчивые хакеры пытаются выставлять себя на рынок рабочей силы как экспертов по обеспечению безопасности, заявляя, что их криминальное прошлое свидетельствует об их опытности. Министерство обороны США имеет давнее знакомство с хакерами, стоившее ему 25 миллиардов долларов, потерянных из-за 22 000 атак только в 1999 году. Сегодня Министерство обороны открыто принимает на работу хакеров-«белых шляп». Хотя его подход к «черным шляпам» менее открыт, есть сообщения о том, что им делались предложения гражданам других государств (таким, как русский хакер Верс).

При безнадежной нехватке действительно квалифицированных профессионалов, которая сопровождается стремлением хакеров замаскироваться под экспертов в области безопасности, у вас остается лишь один выбор — самим вырастить собственного эксперта.

Используйте этот список для определения того, подвергается ли ваша компания риску из-за применяемого ей аутсорсинга и/или состояния процедур проведения аудита. Можете ли вы поставить «Да» против каждого его пункта?

Аутсорсинг

— Проводятся ли аудиты клиентских подключений (экстранет) на регулярной основе?

— Существует ли официально оформленная архитектура подключения клиентов (экстранет) к вашей сети?

— Существует ли официальная политика, четко определяющая, когда, почему и каким образом должны разрешаться подключения экстранет?

— Требуется ли разрешение руководства на перевод экстранет в онлайновый режим?

— Требуется ли проведение аудита безопасности перед тем, как перевести экстранет в онлайновый режим?

Процедуры проведения аудита

— Имеется ли в вашей компании официальная политика проведения аудита?

— Имеются ли в вашей компании процедуры проведения аудита для тестирования безопасности в письменной форме?

— Находится ли в рабочем состоянии программное обеспечение для проведения аудита, установленное на всех платформах?

— Обеспечивается ли необходимое финансирование приобретения необходимых инструментов проведения аудита?

— Поддерживает ли руководство проведение аудита безопасности, обеспечивая правильную подготовку аудиторов?

Мишель почувствовала затруднения, когда ее почту (вероятнее всего) кто-то читал у нее под носом. В других более тяжелых случаях это обходится корпорациям в миллиарды долларов потерянных доходов ежегодно. Угроза в этих случаях исходит от «червей», «троянских коней», атак по типу «отказа от обслуживания», искажения внешнего вида веб-страниц и т. д. Электронная почта представляет собой одну из самых распространенных и менее всего обсуждаемых областей, в которой сегодня таится риск для делового мира.

Для защиты тайны своей переписки Мишель должна была сделать следующее.

Использовать шифрование!

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

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

Убедить компанию в необходимости шифрования

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

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

Предусмотреть в бюджете средства на шифрование

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

Отслеживать возникновение других угроз электронной почте

Как ни печально сообщать, но возможность чтения вашей почты другими людьми является не единственным риском, которому вы подвергаетесь как пользователь электронных средств информации. Вы можете подвергнуться «спаму», угрозам заражения вирусами, реальному заражению вирусами, «червями», «троянскими конями» и т. д. Соответствующие программные инструменты могут предотвратить возникновение некоторых из этих проблем. Например, хотя «спам» продолжает нарастать, только 21 процент пользователей электронной почты используют программы-фильтры «спама» (Opt-In News, май 2002 года).

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

«Спам» вреден, по меньшей мере, своей назойливостью, но вредоносные программы являются разрушительными и означают причинение ущерба. Убытки от эпидемий вредоносных программ в 2001 году составили 13,2 миллиарда долларов. Компаниям необходимо создавать многоуровневую систему обороны для защиты от этих злобных атак. Это означает защиту в каждой точке входа. Серверы, персональные компьютеры и другие устройства также должны иметь защиту (например, защиту от вирусов, брандмауэр, детектор вторжения и средство предотвращения вторжения). Атаки вредоносных программ становятся более изощренными и будут причинять больший ущерб. Защита от них является одной из приоритетных задач каждой компании.

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

Только для краткого знакомства рассмотрим наиболее распространенные типы хакеров.

Неуловимый хакер № 1: Рассерженный сотрудник

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

Неуловимый хакер № 2: Промышленный шпион

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

Неуловимый хакер № 3: Одинокий «социопат»

Таких не так уж много. Такой тип хакера наиболее близок к вашим представлениям. Он молод, ярок и, вероятнее всего, является либо студентом, либо недавним выпускником, еще не нашедшим направления своей деятельности. Однако на такого хакера вы, скорее всего, не наткнетесь в потемках вашей базы данных.

Неуловимый хакер № 4: «Хактивист»

Это новейшая и наиболее пугающая категория компьютерных преступников. «Хактивист» считает себя политическим деятелем, реформатором и даже воином. Некоторые доходят до того, что приравнивают себя к террористическим группам и берут клички «кибер-джихад», «Джи-Форс Пакистан» и «Доктор Нукер» (cyber-jihad, G-Force Pakistan, Doktor Nuker). Другие преследуют необычные политические цели, используя логику не менее бестолковую и запутанную, чем у «Унабомбера». Более часто в такую категорию попадает молодой человек, имеющий тесные связи с политически нестабильными регионами, например с Ближним Востоком или Восточной Европой. В основном являясь яркими личностями, многие из таких хакеров действительно обучились компьютерному искусству в Соединенных Штатах. Некоторые могли здесь и остаться, днем поддерживая корпоративные сети, а по ночам атакуя политические цели. Атаки «хактивистов» простираются от причинения беспокойства объектам атаки посредством искажения внешнего вида веб-сайтов до прямого экономического вредительства.

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