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