Сообщение об инцидентах¶
Этот регламент помогает команде Weblate обрабатывать сообщения о безопасности продукта и инциденты безопасности, затрагивающие службы, управляемые Weblate. Политика отчётности и сроки изложены в Обработка уязвимостей и инцидентов. Для локализации и восстановления службы используйте План реагирования на инциденты для Weblate.
Один человек обрабатывает инцидент, а доступный коллега выступает в качестве резерва. Эти же люди расследуют, отчитываются и общаются по мере необходимости. Назначения контактов, сведения о доступе и заполненные заметки об инциденте относятся к приватным записям команды.
Принять инцидент¶
Тот, кто увидит достоверное сообщение об активной эксплуатации или серьёзном инциденте безопасности, оповещает коллег через Signal. Доступный коллега берёт ответственность на себя и назначает резерв; для реагирования не требуется одобрения руководства. Резерв принимает на себя обязанности, если ответственный становится недоступен. Записывайте передачу обязанностей в заметке об инциденте, чтобы сроки и обещанные обновления оставались видимыми.
Немедленно заведите одну приватную заметку об инциденте. Запишите, когда команда узнала соответствующие факты, используя временные метки с указанием часового пояса, предпочтительно UTC. Отличайте получение первоначального сообщения от осведомлённости об активной эксплуатации или серьёзном инциденте, фиксируя доказательства для каждого. Не ждите исправления, официального объявления или полного расследования, чтобы начать подготовку к отчётности.
Оцените сообщение¶
Активная эксплуатация означает надёжные доказательства того, что злоумышленник использовал уязвимость без разрешения владельца системы. Теоретическая уязвимость, доказательство концепции или отсутствие разрешения сами по себе не устанавливают злонамеренную эксплуатацию. Незамедлительно расследуйте подозрение на эксплуатацию и фиксируйте, что известно и что неясно. См. CRA Article 3(42).
Оценивайте инцидент безопасности продукта как серьёзный, когда он наносит или может нанести ущерб защите важных или конфиденциальных данных или функций, или приводит или может привести к внедрению или выполнению вредоносного кода в продукте или системах пользователей. Это включает выполнение уже присутствующего вредоносного кода. См. CRA Article 14(5). Учитывайте доступность, подлинность, целостность и конфиденциальность. Только серьёзность операционного сбоя не определяет эту классификацию.
Проверьте затронутые версии, артефакты выпуска и поставляемые зависимости, включая инциденты, о которых сообщили операторы самостоятельно размещённых установок. Локальная локализация остаётся обязанностью оператора; здесь оценивается отчётность о продукте. Решение о находке времени выполнения в соответствии с Модель угроз Weblate само по себе не определяет, нужно ли сообщать об инциденте.
Оценивайте оба направления отчётности, когда активная эксплуатация также вызывает серьёзный инцидент. При необходимости фиксируйте отдельные моменты осведомлённости и отслеживайте оба срока окончательного отчёта.
Сразу проверяйте наличие утечки персональных данных, включая случайное или незаконное уничтожение, потерю или изменение, а также несанкционированное раскрытие или доступ. Оценивайте уведомления о конфиденциальности, даже если данные не были раскрыты. При необходимости обращайтесь за внешней консультацией, продолжая расследование и подготовку к отчётности.
Запишите, является ли отчётность обязательной или добровольной для события и почему. Неопределённость требует незамедлительной консультации, а не паузы в подготовке или применимых сроках. Базовая политика не определяет регуляторную роль Weblate; см. Информация о продукте и контактах. Оценивайте затронутую размещённую службу или загружаемый дистрибутив отдельно, вместо того чтобы предполагать у них одинаковую регуляторную сферу.
Ведите одну приватную заметку об инциденте¶
Скопируйте эти поля в приватную запись команды об инциденте:
Идентификатор дела, сводка, ответственный, резерв и передачи обязанностей.
Продукт, затронутые версии или дайджесты артефактов, развёртывания и известные государства-члены, где затронутый продукт был доступен, с указанием источника и ограничений этой информации. Записывайте места воздействия инцидента отдельно, когда они уже известны и актуальны.
Временные метки осведомлённости, подтверждающие доказательства, неизвестные данные и обоснование классификации, включая решение об обязательной или добровольной отчётности.
Сроки отчётности, напоминания и любые отдельные задачи по уведомлению о конфиденциальности.
Хронология расследования, воздействие, меры по смягчению и когда каждая корректирующая или смягчающая мера стала доступна.
Копии отправленных отчётов, временные метки отправки, ссылки на платформу, квитанции, сбои и запрошенные последующие отчёты.
Предупреждения пользователей, получатели или ссылки на публичные уведомления, обещанные обновления и любое отложенное техническое раскрытие с его причиной и датой пересмотра.
Оставшиеся действия и результат короткого обзора командой.
Храните конфиденциальные доказательства и вложения вместе с приватной записью, ограничив доступ людьми, обрабатывающими инцидент. Храните учётные данные в хранилище учётных данных команды. Signal предназначен для координации; копируйте решения и соответствующие временные метки в долговременную заметку. Не используйте публичные задачи для этих записей.
Отправьте и следите¶
Используйте актуальное руководство ENISA Single Reporting Platform для проверки координирующей CSIRT, условий доступа и маршрута обязательной или добровольной подачи. Национальный портал отчётности об инцидентах не обязательно является конечной точкой CRA. Обратитесь к координатору, если маршрут неясен.
Ответственный отправляет отчёты; резерв принимает на себя обязанности при необходимости. Попросите коллегу проверить, когда это практично, но не пропускайте срок в ожидании проверки. Используйте сроки из Отчётность перед органами и текущие формы платформы. Своевременно отправляйте доступную информацию, указывайте неизвестные данные и дополняйте её по мере расследования.
В любом из направлений раннего предупреждения укажите событие и, где известно, государства-члены, где затронутый продукт был доступен. Это информация о распространении, а не местоположение отдельных пользователей или только места, где наблюдалась эксплуатация. Для серьёзного инцидента также укажите, подозреваются ли противоправные или злонамеренные действия. Оба направления запрашивают государства-члены распространения в соответствии с CRA Article 14(2)(a) and (4)(a).
В основном уведомлении об эксплуатируемой уязвимости укажите затронутый продукт и опишите общий характер как эксплойта, так и уязвимости. Включите уже принятые корректирующие или смягчающие меры, меры, которые могут предпринять пользователи, и чувствительность информации, где применимо, как требуется статьёй 14(2)(b) CRA.
В основном уведомлении о серьёзном инциденте опишите характер инцидента и предоставьте первоначальную оценку, включая известное воздействие. Включите уже принятые корректирующие или смягчающие меры, меры, которые могут предпринять пользователи, и чувствительность информации, где применимо, как требуется статьёй 14(4)(b) CRA.
В окончательном отчёте об эксплуатируемой уязвимости опишите уязвимость, включая её серьёзность и воздействие. Включите любую доступную информацию о злоумышленниках, которые использовали или используют её, и сведения об обновлении безопасности или других корректирующих мерах, предоставленных для её устранения, как требуется статьёй 14(2)(c) CRA. Наличие меры по смягчению может запустить этот срок до готовности окончательного патча.
В окончательном отчёте о серьёзном инциденте предоставьте подробное описание инцидента, включая его серьёзность и воздействие, тип угрозы или первопричину, вероятно, вызвавшую его, а также применённые и продолжающиеся меры по смягчению, как требуется статьёй 14(4)(c) CRA. Явно укажите, когда нет продолжающихся мер по смягчению.
Для информации о распространении используйте существующие записи о клиентах или распространении, например страны известных платящих клиентов. Укажите ограничения этих записей: местоположение других пользователей может быть неизвестно. Не делайте вывод о распространении в каждом государстве-члене из общей доступности в ЕС. Эта процедура не требует отслеживания местоположения отдельных пользователей или сбора новых данных о местоположении. Сообщайте то, что известно, не откладывая подачу для выяснения других местоположений, и обновляйте информацию по мере необходимости. См. поле доступности продукта в словаре ENISA SRP.
Сохраняйте квитанции и ссылки на отчёты. Отслеживайте запросы промежуточных отчётов и обновляйте более ранние подачи при изменении фактов. Для события, запускающего оба направления, свяжите записи и убедитесь, что оба набора требований отчётности охвачены; один окончательный отчёт не должен молча заменять другой.
Если платформа недоступна, записывайте неудачные попытки и временные метки, свяжитесь с координатором через его опубликованные резервные каналы и следуйте его инструкциям. Завершите подачу на платформе, когда доступ вернётся. Альтернативный контакт не является автоматическим доказательством того, что юридическая обязанность отчётности выполнена.
Предупредите пользователей и следите¶
Отправляйте защитные рекомендации, не дожидаясь исправления или полного технического раскрытия, используя каналы электронной почты и публичных уведомлений в Обработка уязвимостей и инцидентов. Указывайте затронутые версии, известное воздействие, доступные действия и оставшуюся неопределённость. Записывайте, что было сообщено, и выполняйте обещанные обновления.
Отчётность перед органами, предупреждения пользователей и подробное раскрытие могут происходить в разное время. Записывайте причины безопасности для задержки технических подробностей и пересматривайте решение в записанную дату пересмотра.
После восстановления проверьте оставшиеся сроки отчётности, запрошенные обновления и решения о раскрытии. Проведите короткий обзор командой, запишите улучшения и закройте заметку об инциденте, как только незавершённые действия будут выполнены или явно переданы с ответственным и сроком.
Контрольный список подготовки¶
Это задачи по настройке, которые нужно выполнить и записать приватно. Публикация этого регламента не означает, что доступ или учения уже организованы.
Выберите обычный контакт для отчётности и резерв и договоритесь, как коллеги оповещают друг друга, когда кто-либо из них недоступен.
Проверьте доступ к отчётности, условия восстановления, координирующую CSIRT и опубликованные резервные контакты с помощью руководства ENISA Single Reporting Platform. Держите сведения об учётных записях в тайне.
Выберите приватное место, доступное ответственному и резерву, для заметок об инцидентах и используйте существующие инструменты команды для напоминаний о сроках и передаче обязанностей.
Проверьте доступ к спискам контактов клиентов и уведомлениям о безопасности GitHub.
Проведите короткое офлайн-учение, охватывающее сообщение об эксплуатации в пятницу вечером, серьёзный инцидент без известной уязвимости, сообщение о самостоятельно размещённой или поставляемой зависимости и событие, запускающее оба направления отчётности. Включите недоступного ответственного, сбой платформы, неполную информацию и меру по смягчению, доступную до окончательного патча. Проверьте сроки в часах и календарных месяцах через февраль. Запишите пробелы и последующие действия, не отправляя отчёты учения реальным получателям.