В первые часы инцидента безопасности невозможно составить полную техническую картину произошедшего. Ваша команда может все еще пытаться понять, какой аккаунт был скомпрометирован, к каким данным получен доступ, насколько далеко продвинулся злоумышленник и продолжается ли инцидент.
Параллельно с расследованием сразу же возникает давление: нужно действовать. Сотрудники слышат обрывки информации и хотят знать, что делать. Клиенты могут заметить перебои в работе сервиса, подозрительную активность или необычные запросы на сброс пароля. Деловые партнеры могут спрашивать, затронуты ли их системы или данные. А руководству нужно решить, кто говорит, что можно подтвердить и когда молчание само по себе становится риском.
Коммуникация при инциденте безопасности сложна тем, что бизнесу приходится быть прозрачным, еще не имея всех ответов, но при этом достаточно информированным, чтобы не строить догадок. Сообщения, отправленные слишком рано, могут вызвать путаницу, а отправленные слишком поздно — подорвать доверие, замедлить защитные действия и вызвать вопросы у регуляторов.
Маловероятно, что малый и средний бизнес разработал или отработал план реагирования на инциденты, и это может усилить хаос. Даже у крупных компаний с таким планом технические шаги могут быть задокументированы: локализовать инцидент, сбросить доступ, сохранить доказательства, восстановить системы. А коммуникация откладывается на потом — пока инцидент внезапно не обострится или не изменится.
Часть подготовки к инциденту — знать, кто должен получить от вас информацию, что им нужно знать, кто утверждает сообщение и как четко доносить факты, пока расследование еще продолжается.
Планирование коммуникации — часть реагирования на инцидент
Двухтрековая структура вашего реагирования
Начните с аудитории, а не с объявления
Как уведомить клиентов об утечке
Когда уведомлять регулирующие органы
Чем может помочь Proton Pass for Business
Планирование коммуникации — часть реагирования на инцидент
Реагирование на инциденты часто описывают как технический процесс, но реальный инцидент быстро становится межфункциональным. ИТ-команды могут локализовать угрозу, но руководство, юридический отдел, поддержка клиентов, отдел кадров, коммуникации и операционный отдел — все должны знать, что происходит и что им разрешено говорить.
В рекомендациях NCSC об эффективной коммуникации при киберинциденте(новое окно) — общих передовых практиках, применимых далеко за пределами Великобритании, — эта мысль выражена четко: организации часто ставят техническое реагирование на первое место, а коммуникацию отодвигают на второй план, хотя именно она формирует то, как сотрудники, клиенты, заинтересованные стороны и СМИ воспринимают организацию во время кризиса.
Не каждый инцидент требует публичного заявления. Но бизнес должен заранее знать, кто решает, о чем сообщать, кто утверждает внешние сообщения, кто общается с клиентами и кто занимается отчетностью перед регуляторами.
Хороший план реагирования на утечку данных должен включать коммуникационный уровень. В него стоит включить практические детали:
- Списки контактов
- Шаблоны черновиков
- Маршруты согласования
- Юридическая проверка
- Тезисы для поддержки клиентов
- Ответственность за уведомление регуляторов
- Записи о том, что, когда и кому было отправлено.
Двухтрековая структура вашего реагирования
Реагирование на инцидент требует двух треков: технического реагирования и коммуникационного реагирования. Они идут параллельно друг другу, а руководитель инцидента или ответственный за реагирование связывает их между собой.
| Левый трек: техническое реагирование | Правый трек: коммуникационное реагирование |
| Локализовать инцидент | Обновить информацию для внутренней команды |
| Защитить затронутые аккаунты | Уведомить затронутых клиентов или партнеров |
| Сохранить доказательства | Оценить необходимость уведомления регуляторов |
| Восстановить системы | Поддерживать единообразие сообщений по мере изменения фактов |
Это позволяет структурировать реагирование и обеспечить непрерывность совместной работы, когда члены команды берут на себя разные задачи.
Начните с аудитории, а не с объявления
Коммуникация при инциденте безопасности терпит неудачу, когда одно сообщение пытается охватить всех. Сотрудникам, клиентам, партнерам и регуляторам нужны разные уровни детализации, потому что им предстоит принимать разные решения.
Вашей внутренней команде в первую очередь нужна ясность
Им не нужны все подробности — особенно пока расследование продолжается, — но им нужна ясность в том, что подтверждено, что делать прямо сейчас и кто руководит реагированием. Это значит знать, каких систем или аккаунтов следует избегать, какие действия предпринять немедленно и какие вопросы остаются открытыми.
Сотрудникам также нужно знать, чего делать нельзя. Например:
- Не обсуждать инцидент публично
- Не сбрасывать учетные данные вне утвержденного процесса
- Не обращаться к клиентам с импровизированными объяснениями
- Не пересылать подозрительные сообщения без указаний.
Клиенты и партнеры должны знать, как это их затрагивает
Они хотят знать, затронуты ли их данные, доступ, платежи, обслуживание или операции. Хорошее уведомление клиентов должно объяснять:
- Что известно
- Какие данные могут быть затронуты
- Что делает компания
- Что клиентам нужно сделать сейчас, если это вообще необходимо
- Где можно узнать обновления.
Тон должен быть простым и прямым. Клиенту также не нужны детали расследования — достаточно информации, чтобы защитить себя.
Регуляторам нужен документально подтверждённый факт
Уведомление об утечке в соответствии с GDPR, направляемое в надзорный орган (в Великобритании — ICO(новое окно), в каждой стране ЕС — национальный орган по защите данных), — это не маркетинговое сообщение и не заверение клиентов. Это документально подтверждённый факт: что произошло, кто пострадал и что вы делаете для устранения последствий. Что именно следует включать в уведомление регуляторов, мы расскажем ниже.
Что сообщать внутри компании
Ваши сотрудники участвуют в реагировании, даже если они не входят в группу реагирования на инцидент. Растерянная команда может невольно создать дополнительный шум, поделиться недостоверной информацией или замедлить локализацию. С другой стороны, хорошо информированная команда поможет защитить аккаунты, направить клиентов в нужный канал и не допустить роста домыслов.
Объявление о внутреннем инциденте безопасности должно включать:
- Понятное изложение того, что уже подтверждено, простым языком
- Какие системы, аккаунты, команды или данные потенциально затронуты
- Что компания делает сейчас
- Что сотрудникам следует сделать немедленно
- Кто имеет право общаться с внешними сторонами
- Где будут публиковаться обновления
- Как сообщать о связанной подозрительной активности
Есть аспекты, которые включать не стоит: векторы атак, анализ первопричин и конкретные уязвимости, как правило, не раскрываются внутри компании, пока инцидент активен, а часто и после него, поскольку такая информация может помочь другим злоумышленникам, создать юридические риски или выявить ещё не закрытые пробелы.
Первое внутреннее сообщение не обязано отвечать на все вопросы — оно должно создать порядок. Например, сотрудникам может потребоваться сбрасывать пароли только через утверждённый процесс, не использовать конкретную систему, сохранять подозрительные электронные письма или прекратить использование общих учётных данных, пока группа реагирования не завершит проверку.
Также важно оценить существующие средства контроля доступа на соответствие рекомендациям по управлению паролями. Во время инцидента устаревший или неформальный обмен учётными данными затрудняет понимание того, что именно было раскрыто.
Руководства Proton по защите от утечек данных и предотвращению утечек данных для бизнеса объясняют, как многоуровневые средства контроля снижают риск до возникновения утечки. Безопасное управление учётными данными — один из таких уровней: оно помогает компании знать, какие аккаунты существуют, кто может получить к ним доступ и что нужно оперативно изменить.
Как уведомить клиентов об утечке
Уведомить клиентов об утечке данных сложнее, поскольку это связано с репутационными и юридическими последствиями. Люди могут беспокоиться о краже личных данных, захвате аккаунта, финансовом мошенничестве или раскрытии конфиденциальной информации. Они также могут быть разочарованы тем, что компания не предотвратила инцидент.
Хорошее сообщение для клиентов должно быть честным, но не пугающим. Следует избегать технического жаргона, но при этом быть понятным. Клиенты должны понимать, какие данные были затронуты, какие риски это создаёт и что им делать дальше.
Полезная структура такова:
- Что произошло, с уровнем детализации, подходящим для клиентов
- Когда компания узнала об этом
- Какая информация или услуги могут быть затронуты
- Какие меры приняла компания
- Что клиентам следует сделать сейчас
- Как компания будет предоставлять обновления
- К кому клиенты могут обратиться с вопросами
Если расследование ещё продолжается, об этом следует сообщить. Точность и прозрачность помогают восстановить доверие. Открытость в отношении последствий не требует раскрытия технических деталей, которые помогли бы кому-то повторить атаку.
При серьёзных инцидентах клиентам могут потребоваться практические инструкции: сменить пароль, включить MFA, следить за фишинговыми письмами, связаться со своим банком и игнорировать сообщения, якобы отправленные компанией, если они приходят не по официальному каналу. Уведомление должно сделать эти шаги понятными.
Когда и как уведомлять регулирующие органы
Не каждый инцидент безопасности требует уведомления надзорных органов. Утечка, подлежащая уведомлению в соответствии с GDPR Великобритании и ЕС, зависит от того, может ли утечка персональных данных создать риск для прав и свобод людей.
Руководство ICO по утечкам персональных данных(новое окно) отражает требование, общее для GDPR Великобритании и ЕС: организации обязаны сообщать об утечке, подлежащей уведомлению, без неоправданной задержки и не позднее чем через 72 часа после того, как узнали о ней. При позднем уведомлении нужно указать причины задержки.
Этот 72-часовой срок может создавать давление, особенно когда расследование ещё не завершено. GDPR признаёт, что у организаций может не быть всех деталей в первые 72 часа, поэтому информацию можно предоставлять поэтапно, при условии что дальнейшие обновления передаются без неоправданной задержки.
Уведомление в соответствующий надзорный орган (ICO в Великобритании или национальный орган по защите данных в ЕС) обычно должно включать:
- Характер утечки персональных данных
- Категории и примерное число затронутых лиц
- Категории и примерное число затронутых записей персональных данных
- Имя и контактная информация DPO или другой контактной точки
- Вероятные последствия утечки
- Принятые или предлагаемые меры по устранению
ICO также предоставляет центральную страницу, чтобы сообщить об утечке(новое окно) и направить организации к соответствующему процессу уведомления.
Для пострадавших лиц порог иной. Если утечка персональных данных может создать высокий риск для прав и свобод людей, их необходимо уведомить без неоправданной задержки. В такой ситуации юридические службы, специалисты по конфиденциальности и руководство должны быть вовлечены с самого начала, даже в малом бизнесе.
Подготовьте сообщения заранее
Худшее время для разработки процесса коммуникации — во время инцидента. Не стоит публиковать заявления или рекомендации, которые придётся обновлять и менять.
Поэтому полезно подготовить структуру сообщений заранее. Не окончательные формулировки, потому что каждый инцидент будет разным, а именно структуру: кто должен утвердить сообщение, какие сведения обязательно включить, где будут фиксироваться обновления и кто отвечает за каждую аудиторию.
Простого набора для коммуникации достаточно, чтобы первый час прошел менее хаотично. В него могут войти:
- Шаблон внутреннего объявления об инциденте
- Шаблон уведомления клиентов
- Шаблон сообщения партнерам или поставщикам
- Тезисы для поддержки клиентов
- Чек-лист уведомления надзорного органа
- Список утвержденных спикеров
- Контакты для эскалации в юридическом отделе, ИТ-отделе, службе конфиденциальности, руководстве и отделе коммуникаций
- Место для записи всех обновлений и решений
Подготовка дает команде надежную отправную точку, когда важны и скорость, и точность. Готовый шаблон позволяет уделить больше внимания фактам инцидента: что произошло, кто пострадал, что уже сделано и что людям нужно сделать дальше.
Как может помочь Proton Pass for Business
Коммуникация о инциденте безопасности зависит от фактов. Чем понятнее бизнес управляет доступом до инцидента, тем проще объяснить, что произошло, что может быть затронуто и что было изменено.
Корпоративный менеджер паролей, такой как Proton Pass for Business, помогает командам снизить риски, связанные с учетными данными. Сотрудники могут создавать надежные пароли, хранить их в зашифрованных хранилищах паролей, использовать автозаполнение, безопасно делиться учетными данными, управлять ключами доступа и использовать встроенную двухфакторную аутентификацию. Администраторы могут применять политики паролей, просматривать журналы активности, управлять доступом с помощью ролевых механизмов и поддерживать провизионинг через интеграции SCIM и SSO.
Во время инцидента эти функции помогают бизнесу действовать увереннее. Если аккаунт сотрудника раскрыт, администраторы могут проверить доступ, выявить общие учетные данные, которые, возможно, нужно сменить, усилить аутентификацию и снизить зависимость от паролей, передаваемых через чат или электронные таблицы.
Будьте готовы реагировать до того, как произойдет утечка, с помощью корпоративного менеджера паролей.
