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

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

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

Один из способов убедить руководство — это составить аналитический отчет со сравнением затрат на создание и зарплату такой команде против потерь компании в результате успешных атак. Например, в отчете ФБР и Института компьютерной защиты (Computer Security Institute, CSI) под названием «Компьютерные преступления» утверждается, что число зарегистрированных инцидентов в области защиты непрерывно возрастало в течение последних трех лет и что финансовые потери в расчете на один инцидент также увеличивались. Количественное выражение потерь от каждой атаки станет весомой поддержкой для любого аргумента, который вы сможете выдвинуть в пользу разработки политики и создания команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статья о том, как создать команду противодействия атакам, имеется на ftp://ftp.auscert.org.au/pub/auscert/papers/.

Роль команды противодействия атакам и вопросы, связанные с ее созданием и деятельностью, рассматриваются на http://www2.hunter.com/docs/rfc/rfc2196.html.

О том, как разработать политику и процедуры защиты компьютеров, подключенных к Internet, можно узнать на http://csrc.nczsi.nist.gov/fips/.