Переход от локализации учетной записи к проверенному журналу рисков утечки данных
После инцидента безопасности в приложении-компаньоне смена пароля — важное действие, но оно не отражает полной картины того, что остается уязвимым. Начинайте этот процесс только после того, как запустите официальную процедуру восстановления у поставщика услуг, защитите учетную запись электронной почты или профиль идентификации, с помощью которых можно сбросить доступ к приложению, проверите незнакомые устройства и завершите неизвестные сеансы. Затем отследите, что приложение хранило, куда оно могло отправлять данные, какой доступ к устройству у него остался, какие общедоступные ресурсы по-прежнему открыты и изменился ли какой-либо способ оплаты. Присвойте каждому пункту один наблюдаемый статус: сохранен в качестве минимального доказательства, отозван, исправлен, запрошен у поставщика, подтвержден как выполненный или запланирован к проверке на определенную дату. В этой статье рассматривается последующая работа с данными после первоначальной локализации; действия при непосредственном захвате учетной записи и выдаче себя за другое лицо описаны в соответствующем чек-листе реагирования.
Подтвердите завершение локализации перед аудитом данных
Создайте первую строку под названием «доступ локализован» и фиксируйте только наблюдаемые результаты: использованный официальный тикет или экран восстановления, проверенную основную учетную запись для входа, время смены учетных данных, проверенный список сеансов или устройств и подтвержденный дополнительный метод верификации. Отмечайте поле как неразрешенное, если продукт не отображает эту информацию. Не предполагайте, что смена пароля автоматически прекращает все существующие сеансы или делегированные токены. И FTC, и NCSC Великобритании указывают выход с устройств или из приложений, проверку каналов восстановления и включение двухфакторной аутентификации как отдельные действия, независимые от смены пароля. Google и Apple также предоставляют отдельные проверки устройств и данных безопасности. Если вы все еще наблюдаете новую активность или не можете подтвердить контроль над основным адресом электронной почты, остановите аудит данных и вернитесь к официальному восстановлению учетной записи с доверенного устройства. Не отправляйте историю переписки или коды подтверждения неофициальным контактам службы поддержки.
Составьте журнал рисков по категориям данных и местам назначения
Выделите по одной строке для каждой категории, которая фактически содержалась в учетной записи: идентификаторы профиля, текст переписки, загруженные изображения или голосовые сообщения, сохраненные воспоминания, местоположение, контакты, история использования, покупки и сообщения в службу поддержки. Добавьте столбцы: источник, функция приложения, хранилище или место назначения, заявленные поставщиком, публичная или приватная видимость, последнее известное нормальное состояние, обнаруженное изменение и следующее действие. «Данные переписки» — слишком широкое понятие, если одна ветка была общедоступной, а другие оставались приватными. «Третьи стороны» — также слишком обобщенно, если доступ к календарю можно отозвать, но уже выполненный экспорт вернуть назад нельзя. Используйте страницу конфиденциальности приложения, встроенные элементы управления, описание в магазине приложений и уведомление об инциденте как отдельные свидетельства. При отсутствии ответа статус остается «запрошены разъяснения у поставщика»; он не меняется автоматически на «не собиралось» или «удалено». Сохраняйте только те скриншоты и идентификаторы, которые необходимы для фиксации состояния, исключая конфиденциальные ключи и не относящийся к делу личный контент.
Отозовите подключения и разрешения с обеих сторон
Перечислите поставщиков услуг входа, облачные диски, календари, медиатеки, контакты, микрофоны, камеры, доступ к уведомлениям, ссылки общего доступа, расширения браузера, вебхуки и любые подключенные профили сообществ. По возможности отключите интеграцию внутри приложения-компаньона, затем проверьте соответствующую авторизацию у поставщика учетных записей, в операционной системе или подключенном сервисе. Удаление значка приложения или запрет доступа к микрофону не обязательно аннулирует существующий облачный токен; отзыв облачного токена не удаляет уже экспортированные файлы. Фиксируйте информацию с обеих сторон. Для разрешений на устройстве отметьте, отключен ли доступ полностью, ограничен ли выбранными объектами или все еще требуется для функции, которую вы решили оставить. Для публичной ссылки проверьте ее доступность в браузере в режиме инкогнито или без входа в систему после отзыва, не открывая личные материалы. Если она остается доступной, сохраните URL-адрес и время, а затем воспользуйтесь официальным каналом службы поддержки или защиты конфиденциальности поставщика.
Разделяйте исправление, экспорт, удаление и подтверждение поставщика
Это четыре разных состояния. Исправьте поля профиля, контактные данные для восстановления, адреса для уведомлений и настройки общего доступа, которые были заметно изменены. Запрашивайте экспорт данных учетной записи только тогда, когда это помогает выявить затронутые категории или сохранить собственную копию; не считайте экспорт исчерпывающим доказательством всего, что хранит поставщик. Отправьте запрос на удаление или прекращение хранения через официальный интерфейс сервиса, если вы выбрали это действие, и сохраните номер подтверждения и указанный объем запроса. Формулировка «запрос получен» не означает «выполнен». Зафиксируйте, распространяется ли ответ на основную учетную запись, резервные копии, публичные публикации, подключенные сторонние обработчики и отдельно отправленные вложения в службу поддержки. Не загружайте повторно дополнительные личные данные, пытаясь придать веса общему запросу. Если поставщик не может ответить на вопрос об объеме затронутых данных, отметьте эту строку как неразрешенную и ограничьте использование связанной функции, вместо того чтобы строить догадки.
Проверьте платежи и влияние на контакты, избегая публичной огласки
Проверьте страницу подписки в приложении, историю покупок в магазине, сохраненные способы оплаты, внутриигровую валюту, операции с подарками и чеки на предмет неизвестных изменений. При обнаружении незнакомого списания используйте официальный порядок оспаривания операций или обращения в службу поддержки платежного провайдера; не отправляйте полные данные карты в обычном сообщении. Если скомпрометированная учетная запись рассылала ссылки, запросы или публиковала посты, уведомите только тех людей или сообщества, которые действительно их получили, используя проверенный ранее канал связи, если это возможно. Укажите временной интервал, какой контент был отправлен не вами и что получателям следует игнорировать. Не называйте предполагаемого злоумышленника без доказательств и не публикуйте приватные скриншоты для подтверждения инцидента. Затем зафиксируйте отправку уведомлений, открытие спора по платежу или отсутствие наблюдаемых последствий в отдельных строках. Запись «сегодня подозрительных списаний нет» — это наблюдение с привязкой к дате, а не окончательный вывод.
Запланируйте две контрольные проверки и закройте инцидент
Выберите два момента времени для проверки на основе уведомления поставщика и обычной активности учетной записи — например, через 24 часа и затем после следующего расчетного цикла или обновления экспорта данных. При каждой проверке сверяйте только те поля, которые уже внесены в журнал: события безопасности, известные устройства, данные для восстановления, подключенный доступ, публичные ссылки, запросы поставщику и историю покупок. Добавляйте новые строки только при появлении новых свидетельств. Если нештатное состояние повторится, возобновите соответствующую официальную процедуру восстановления и зафиксируйте время повторного инцидента. Если состояния остаются стабильными, а по незавершенным запросам получен задокументированный результат, завершите процесс с итоговым резюме: локализовано, подключения отозваны, исправления проверены, запросы ожидают ответа или выполнены, платежи проверены, назначена дата следующей плановой проверки. Не проводите проверки непрерывно. Четкий журнал с ограниченным числом проверок защищает будущие решения надежнее, чем состояние бесконечной тревоги, и оставляет ясные доказательства того, что было проверено, а что остается неизвестным.
Частые вопросы
Достаточно ли сменить пароль к приложению-компаньону после инцидента?
Нет. Также необходимо проверить основную учетную запись для входа, контактные данные для восстановления, сеансы, устройства, подключенные сервисы, разрешения, публичные ссылки и способы оплаты, связанные с учетной записью.
Подтверждает ли запрос на удаление, что все копии стерты?
Нет. Зафиксируйте заявленный поставщиком объем удаления и статус выполнения, а неизвестные или исключенные места назначения отметьте отдельно.
Как долго следует проверять учетную запись?
Запланируйте небольшое количество проверок с конкретными датами, привязанными к ответам поставщика, обычной активности или расчетным периодам. Возобновляйте процедуру восстановления только при появлении новых свидетельств.