RFC: 2196
Оригинал: Site Security Handbook
Предыдущие версии: RFC 1244
Категория: Информационный
Дата публикации:
Автор:
Перевод: Семенов Юрий Алексеевич

5.1 Подготовка и планирование обработки инцидентов

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

  1. Защита объектов, которые могут быть компрометированы
  2. Защитные ресурсы, которые могли бы быть использованы с большей пользой, если инцидент не требует их услуг
  3. Выполнение регламентаций (правительственных или других)
  4. Предотвращение использования ваших систем в атаках против других систем (которые могут навлечь на вас юридическую ответственность)
  5. Минимизация потенциала негативных проявлений

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

  1. Описать, как это произошло.
  2. Выяснить, как избежать дальнейшего использование тех же самых уязвимостей.
  3. Исключить последствия и будущие инциденты.
  4. Оценить воздействие и ущерб от инцидента.
  5. Восстановить систему после инцидента.
  6. Обновить политику и процедуры, как это требуется.
  7. Найти, кто это сделал (если это возможно).

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

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

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

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

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

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

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

2007 - 2017 © Русские переводы RFC, IETF, ISOC.