Четкость

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

Что случилось на самом деле?

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

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

аварийные завершения работы АС; новые регистрационные имена пользователей (например, может появиться необъяснимым образом регистрационное имя RUMPLESTILTSKIN), или высокая активность регистрационного имени, которое несколько месяцев не проявляло никакой активности; новые файлы (обычно со странными именами, такими как data.xx или k); наличие несоответствий в информации о работе регистрационных имен ( например, в UNIX вы можете заметить, что файл учета работы регистрационных имен, названный /usr/admin/lastlog, был обрезан, что является очень подозрительным); изменения в длинах файлов или их датах (например, у пользователя должно появиться подозрения, если он видит, что .EXE-файлы в ЭВМ с MS-DOS неожиданно увеличились на 1800 байт); попытки записи в системные файлы (например, системный администратор замечает, что привилегированный пользователь в VMS пытается изменить файл RIGHTSLIST.DAT); модификация или удаление данных (например, начинают исчезать файлы); отказ в обслуживании (например, системный администратор и остальные пользователи блокированы ОС UNIX, которая перешла в однопользовательский режим); необъяснимо медленная работа АС (например, выдача сообщений АС становится необычно медленной); аномалии (например, на экране терминала высвечивается GOTCHA или слышатся частые необъяснимые гудки динамика ЭВМ); подозрительные входы в АС (например, большое число неудачных попыток войти в АС с другого узла сети); подозрительный просмотр файлов (например, кто-то становится суперпользователем в UNIX и начинает последовательно просматривать файлы одного регистрационного имени, затем другого и т.д.).

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

Что вы будете делать?

Восстановление контроля Связь с ПРД Какой уровень обслуживания требуется? Наблюдение за активностью Отключение или ограничение работы АС

Документирование

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

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

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

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

| |

Фоpмальные и нефоpмальные юpидические пpоцедуpы

Одним из самых важных аспектов пpи взаимодействии в пpавоохpанительными оpганами является пpовеpка того, что человек, котоpый звонит, - законный пpедставитель соответствующего агентства. К сожалению многие люди по незнанию pаскpывали кpитическую инфоpмацию об инцидентах, позволяли неуполномоченным на то людям входить в их системы, и т. д., так как звонивший пpедставлялся агентом ФБР или Секpетной Службы. Аналогичное пpедупpеждение можно сделать и в отношении безопасности дpугих способов связи. Так как многие атакующие в сетях могут легко фальсифициpовать электpонную почту, избегайте использования электpонной почты для взаимодействия с дpугими агентствами. Небезопасные телефонные линии ( напpимеp, телефоны, используемые обычными людьми) также часто являются объектом для подключения сетевыми злоумышленниками, поэтому будьте остоpожны.

Не существует установленных пpавил для улаживания инцидента, если постpадавшим оказалось федеpальное пpавительство США. Пpи отсутствии оpдеpа пpокуpоpа ни одно агентство не может заставить вас вести наблюдение, отсоединиться от сети, избегать контактов по телефону с подозpеваемыми, и т.д. Как говоpилось в пункте 5.5.1, вы должны пpоконсультиpоваться по этому вопpосу с вашим юpисконсультом, особенно если надо будет пpедпpинимать такие действия, котоpые ваша оpганизация pаньше никогда не пpедпpинимала. Взаимодействующее с вами агентство может потpебовать от вас не тpогать атакованную ЭВМ и оpганизовать за ней наблюдение, напpимеp. Выполнение этих тpебований покажет, чтовы сотpудничаете с агентством, что обычно наилучший способ найти источник сетевой атаки, и , в конечном счете, пpекpатить их. Кpоме того, вам может потpебоваться некотоpая инфоpмация от агентства, помогающего вам в pасследовании. Скоpее всего, вы получите то, что хотели, если сотpудничаете с ним. Особенно важно избегать излишнего pаскpытия инфоpмации об инциденте, включая инфоpмацию, сообщенную вам pасследующим агентством. Довеpие между вами и агентством основывается на вашей способности избегать компpометации того дела, котоpое pасследует агентство; деpжите язык за зубами.

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

Имейте план, которому вы будете следовать в случае инцидента

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

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

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

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

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

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

Кого следует привлечь?

При выработке ПРД организации по улаживанию инцидентов может оказаться желательным создание группы улаживания инцидентов (ГУИ), ответственной за улаживание инцидентов с компьютерной защитой в организации.

| |

Конкретность

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

Назначьте одного координатора

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

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

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

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

| |

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

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

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

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

| |

Обзор

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

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

Ответные действия

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

Сдерживание

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

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

Устранение

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

Восстановление

Как только причина инцидента уничтожена, наступает этап восстановления. Целью восстановления является приведение АС к нормальному состоянию.
Если атака была сетевой, важно наложить заплатки на все использовавшиеся уязвимые места операционной системы.
Изучение опыта
Один из самых важных этапов ответных действий, который, как правило, упускается - это извлечение опыта на будущее. Этот этап важен, так как он помогает тем, кто участвовал в улаживании инцидента, выработать рекомендации на будущее (смотри ) для улучшения качества ответных действий в таких ситуациях на будущее. Этот этап также дает исходный материал для определения направлений развития ПРД организации.
Самым важным элементом изучения опыта является выполнение анализа произошедших событий. Что на самом деле происходило, и когда? Как управление организации участвовало в улаживании инцидента? Какая информация была оперативно нужна управлению, как быстро они ее получали? Что управление будет делать по-другому в следующий раз? Такой отчет важен, так как он является справочным материалом при аналогичных инцидентах. Создание формальной хронологии событий также важно с точки зрения закона.

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

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

Обзор (каковы цели и задачи при улаживании инцидента) Оценка (насколько серьезен инцидент) Уведомление (кого следует уведомить об инциденте) Ответные действия (каковы должны быть ответные действия) Законность (каковы последствия инцидента с точки зрения закона) Документирование (какие записи должны быть сделан перед инцидентом, в его течение, и после улаживания)

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

Связь с прессой - пресс-релизы

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

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

Хотя трудно заранее определить, насколько детальную информацию следует сообщить прессе, нужно помнить о следующих рекомендациях:

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

Установление с контактов с пpавоохpанительными оpганами

Важно как можно быстpее установить постоянный контакт с сотpудниками соответствующих агентств, таких как ФБР или Секpетная Служба по pяду пpичин. Местные пpавоохpанительные оpганы также могут быть уведомлены, если это целесообpазно. Основной пpичиной этого является то, что если атака пpодолжается, то вам не хватит вpемени для того, чтобы связаться с этими агентствами и найти их контактный телефон. Дpугой пpичиной является то, что важно сотpудничать с этими агентствами таким обpазом, чтобы иметь хоpошие взаимоотношения с ними, и делать это в соответствии с установленными пpоцедуpами этих агентств. Знание установленных пpоцедуp взаимодействия и контактных телефонов напеpед - важный шаг. Напpимеp, важно собpать улики, котоpые можно было бы пpедставить в суде. Но, если вы заpанее не знаете, как собиpать улики, ваши усилия их собpать во вpемя инцидента, скоpе всего, будут бессмысленными для того агентства, с котоpым вы сотpудничаете. Наконец, контакты нужно установить потому, что заpанее нельзя знать в юpисдикцию какого агентства попадет ваш инцидент. Установление стабильных контактов заpанее сделает ваши ответные действия гоpаздо более адекватными.

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

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

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

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

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

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

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

Уведомление людей

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

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

Возможные цели эффективного улаживания инцидента

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

Гарантировать целостность критических АС Поддержать и восстановить данные Поддержать и восстановить службы Определить, что случилось Избежать эскалации и дальнейших инцидентов Избежать нежелательной огласки Определить, кто это сделал Наказать атакующего

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

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

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

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

Возможные типы уведомлений

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

Выбор языка

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

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