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

5.4.1. Типы уведомлений и обмен информацией

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

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

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

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

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

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

  1. Временная зона журнальных записей, в формате GMT или местное время
  2. Информация об удаленной системе, включая имена ЭВМ, IP-адреса и (может быть) ID пользователей
  3. Все журнальные записи, связанные с удаленным узлом
  4. Тип инцидента (что случилось, почему вы должны принять меры)

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

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