План реагування на інциденти для Weblate¶
Обсяг та цілі¶
Ця політика реагування на інциденти (IRP) стосується інцидентів, що впливають на конфіденційність, цілісність або доступність розгортань, що обслуговуються Weblate.
Примітка
Цей план розроблено спеціально для розгортань, що обслуговуються компанією Weblate s.r.o. Для інших розгортань необхідно адаптувати кроки, пов’язані з конкретним постачальником та організацією, до власного середовища.
Ролі та обов’язки¶
Керівник реагування на інциденти (IRL): Координує всі етапи процесу реагування.
Системний адміністратор: Виконує заходи щодо стримування та відновлення.
Співробітник служби безпеки: Оцінює вплив на безпеку та нормативні наслідки.
Спеціаліст із захисту даних (DPO): оцінює, чи було порушено безпеку персональних даних (PII), та управляє обов’язковими повідомленнями відповідно до GDPR.
Керівник відділу комунікацій: Здійснює сповіщення внутрішніх зацікавлених сторін та зовнішніх сторін, якщо це необхідно.
Логістика комунікацій¶
- Внутрішня комунікація:
Основним каналом для координації між людьми є Signal.
Технічні сповіщення залишаються поза межами Signal, щоб уникнути шуму.
- Зовнішня комунікація:
Електронна пошта використовується для зв’язку з клієнтами.
Списки контактів клієнтів зберігаються в декількох місцях, щоб забезпечити доступ до них під час перебоїв у наданні послуг.
- Публічне розкриття інформації:
Якщо виявлено вразливість безпеки, дотримуйтесь інструкцій, наведених у Вразливість та обробка інцидентів.
Категорії інцидентів та їх серйозність¶
Активація інциденту¶
Оголошувати інцидент у разі підтвердження або наявності серйозних підстав вважати, що подія впливає на конфіденційність, цілісність або доступність служби в міру, що виходить за межі звичайних експлуатаційних коливань.
Спеціаліст з безпеки реєструє інцидент, визначає його початковий рівень серйозності та призначає керівника групи реагування на інциденти (IRL).
Якщо співробітник служби безпеки відсутній, будь-який старший оператор, який перебуває на місці, може зареєструвати інцидент і передати відповідальність за його вирішення, щойно це стане можливим.
Перекласифікуйте інцидент, якщо під час розслідування зміняться його масштаби або наслідки.
Категорії інцидентів¶
Категорія 1 – Несанкціонований доступ
Категорія 2 – Порушення цілісності даних
Категорія 3 – Збій або погіршення якості обслуговування
Категорія 4 – Неправильна конфігурація або помилка розгортання
Рівні серйозності та SLA¶
Серйозність |
Визначення |
Підтвердження цілі |
Ціль Початкова дія |
|---|---|---|---|
Критичний |
Повне відключення; злом адміністраторського облікового запису; активний витік даних; необхідні негайні заходи з локалізації. |
< 30 Хвилин |
< 4 Години |
Викокий |
Відмова основної функції; витік персональних даних одного користувача. |
< 2 Години |
12 Години |
Середній |
Погіршення продуктивності; Незначна проблема безпеки. |
1 Робочий день |
3 Робочі дні |
Низький |
Помилки інтерфейсу користувача; Проблеми зі стадією; Помилки, не пов’язані з безпекою. |
Найкращі зусилля |
Найкращі зусилля |
Життєвий цикл реагування на інциденти¶
Підготовка¶
Забезпечте регулярне щоденне резервне копіювання бази даних PostgreSQL та каталогу даних за допомогою вбудованої функції резервного копіювання Weblate з ротацією, див. Резервне копіювання і пересування Weblate.
Переконайтеся, що Weblate використовує правильно налаштований зворотний проксі-сервер (наприклад, NGINX) з HTTPS (TLS 1.2+).
Увімкніть 2FA для всіх облікових записів рівня адміністратора.
Підтримуйте екземпляр Weblate та його залежності (Python, Django, Celery, базу даних тощо) в актуальному стані.
Інтеграція з SIEM-системами за допомогою протоколу GELF для аудиту та пересилання журналів додатків.
Ідентифікація¶
Моніторинг системних та програмних журналів (
journalctl, журналів зворотного проксі-серверу, журналів програм та аудиту Weblate).Аналізуйте події входу, виконання вебхуків та збої push/pull.
Налаштуйте сповіщення (через Prometheus, Zabbix або SIEM) про кілька невдалих спроб входу, несподівані перезапуски або нерегулярні дії VCS.
Стримування¶
Створіть запис про інцидент із зазначенням ідентифікатора справи та фіксуйте зміни у хронології подій у міру вжиття відповідних заходів.
Координуйте реагування персоналу в Signal та продовжуйте використовувати технічні сповіщення в існуючих системах моніторингу.
У разі інцидентів категорії 1 або 2 створіть вручну Hetzner Cloud Snapshot, перш ніж вживати заходів, що можуть спричинити перебої в роботі, коли це буде безпечно.
Форма імені:
IRP-[CaseID]-[YYYYMMDD]-Evidence.Вони відрізняються від стандартних обертових резервних копій і повинні зберігатися для аналізу.
За необхідності ізолюйте уражений хост або службу (наприклад, за допомогою правил брандмауера або ізоляції служби).
Вимкніть зовнішні інтеграції (Git/вебхуки), якщо вони є частиною вектора атаки.
Негайно призупиніть дію облікових записів користувачів, яких це стосується.
За необхідності скасуйте або змініть відповідні облікові дані для адміністративних облікових записів, API, систем контролю версій (VCS) та веб-хуків.
Збережіть відповідні докази, зокрема системні журнали, журнали зворотного проксі-сервера, журнали роботи додатка Weblate та журнали аудиту, стан конфігурації на момент інциденту, а також перелік облікових даних або інтеграцій, які зазнали впливу.
Викорінення¶
Видаліть будь-який неавторизований код або дані.
Виправте відомі вразливості, оновивши Weblate або серверні компоненти.
Перевірте цілісність бінарного файлу та репозиторію за допомогою контрольних сум SHA-256 або журналів Git.
Відновлення¶
Відновіть уражені служби або дані з останніх відомих надійних резервних копій Weblate.
Оцінка PII: DPO визначає, чи вимагає порушення 72-годинного повідомлення відповідно до GDPR.
Відновлювати послуги поетапно.
Перед відновленням нормального трафіку переконайтеся, що першопричина усунена або введено компенсаційні заходи.
Оновлюйте відповідні облікові дані та перевіряйте цілісність відновленої системи, репозиторіїв та конфігурації.
Співробітник служби безпеки та IRL схвалили повернення до звичайного режиму роботи.
Безперервно контролюйте журнали та поведінку системи протягом щонайменше 72 годин після відновлення.
Огляд після інциденту¶
Термін: Провести нараду з підбиттям підсумків протягом 5 робочих днів після закриття інциденту.
Складіть повний хронологічний опис інциденту та вжитих заходів.
Проведіть аналіз першопричин (RCA) та задокументуйте його протягом 10 робочих днів.
Оновити політику безпеки та документацію IRP на основі отриманих результатів.
Перевірте ефективність механізмів виявлення та стримування.
Перевірте, чи процедури ескалації, оповіщення та зовнішнього інформування відбулися відповідно до Вразливість та обробка інцидентів, як і передбачалося.