IT-безопасность: стоит ли рисковать корпорацией?

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

К несчастью, Дэйв ничего не предпринял и просто стал наблюдать за хакером с целью выяснить, кто же среди ночи влез в систему. Хотя в 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 — систем обнаружения вторжения) могут определить атаку, только если имеется сигнатура атаки.[4]

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

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

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

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

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

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

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

Рисунок 1.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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