5. Обработка случаев нарушения безопасности
Эта глава предоставляет руководство, которое следует использовать до, во время и после инцидента в ЭВМ, сети или в многоузловой системе. Философия реагирования на вторжение заключается в последовательности действий в соответствии с заранее подготовленным планом. Это должно быть так, как в случае внешней атаки, так и при нанесении непреднамеренного ущерба студентом, тестирующим некоторую новую программу, или раздраженным служащим. Каждый из возможных типов событий, таких как перечислены выше, должны иметь планы действий, подготовленные заранее.
Традиционная безопасность ЭВМ, являясь крайне важной в рамках общей безопасности узла, обычно уделяет мало внимания тому, как действовать в случае, если атака действительно произошла. Результатом является то, что при атаке, многие решения принимаются в спешке и могут оказаться разрушительными для отслеживания источника инцидента, сбора данных, которые будут использованы для пресечения атаки, приготовления восстановления системы, и защиты ценных данных, содержащихся в системе.
Одной из наиболее важных, но часто упускаемой выгод для эффективной обработки инцидентов, является экономический аспект. Даже при наличии технического управленческого персонала, реагирование на инцидент требует значительных ресурсов. Если персонал обучен и тренирован, то его численность может быть меньше, а работа по ликвидации инцидента эффективнее.
Благодаря всемирному характеру сети большинство инцидентов не ограничиваются одним узлом. Уязвимости операционных систем относятся (в некоторых случаях) к нескольким миллионам систем, и многие слабости используются атакерами в самой сети. Следовательно, жизненно важно, чтобы все заинтересованные узлы были проинформированы об инциденте как можно быстрее.
Другая выгода связана с общественным мнением. Новости об инцидентах, сопряженных с компьютерной безопасностью обычно приводит к разрушению позитивного образа организации в глазах настоящих и потенциальных клиентов. Эффективная ликвидация инцидента минимизирует негативные последствия.
Последняя выгода от эффективной обработки инцидента связана юридическими обстоятельствами. Возможно, что в ближайшем будущем организации могут оказаться ответственными в случае, когда один из ее узлов использовался для сетевой атаки. Аналогично, люди, разрабатывающие корректировки программ (patches) или их доработки могут отвечать, если эти программы окажутся неэффективными, приводящими к компрометации систем, или, если эти поправки вызовут поломку программы. Разделы этой главы предоставляют обзор и перечень стартовых мер для формирования политики безопасности вашего узла при проведении работ в случае инцидентов. Это:
Подготовка и планирование (каковы цели и предпосылки анализа инцидентов).
Уведомление (с кем следует контактировать в случае инцидента).
- Местные менеджеры и персонал
- Правовое обеспечение и следственные органы
- Группы реагирования на инциденты, сопряженные с компьютерной безопасностью
- Узлы, вовлеченные или пострадавшие от инцидента
- Внутренние коммуникации
- Связь с общественностью и пресс-релизы
Идентификация инцидента (является ли это инцидентом и насколько он серьезен).
Обработка (что следует сделать, когда инцидент произошел).
- Оповещение (кто должен быть уведомлен об инциденте)
- Журналы свидетельств и активности (какие записи до, во время инцидента и после него должны быть рассмотрены)
- Ограничение последствий (как можно минимизировать ущерб)
- Искоренение (как исключить причины инцидента)
- Восстановление (как восстановить услуги и системы)
- Ликвидация последствий (какие действия должны быть предприняты после инцидента)
Последствия (каковы последствия последних инцидентов).
Административная реакция на инцидент.