Що має бути в редакційній хронології безпекового інциденту

Редакційна хронологія інциденту — це послідовний запис подій із чітким розмежуванням: що відомо точно, що припускається, а що залишається невідомим. Такий формат дозволяє читачеві швидко зрозуміти масштаб ситуації та прийняти рішення щодо власних активів без паніки й неперевірених дій.

Нижче — структура хронології, яку дотримується Редакція солана.укр. Кожен елемент містить критерій перевірки, щоб ви могли оцінити якість будь-якого повідомлення про інцидент.

Звідки починається історія

Навіщо: дати читачеві базову орієнтацію за кілька секунд.

Це один-два речення, які описують тип події без оцінок і без вказівки причини. Наприклад: «Виявлено ненормальні транзакції з кількох гаманців» або «Команда продукту повідомила про зупинку сервісу».

Ознака нормального результату: формулювання не містить слів на кшталт «зламали», «вкрали», «хакери атакували», якщо це не підтверджено первинними джерелами.

При відхиленні: якщо ви бачите категоричні висновки без посилання — це привід знизити довіру до матеріалу й перевірити інформацію за первинними джерелами самостійно. Детальніше про це — у матеріалі Як читати повідомлення про злам і не поширювати неперевірені висновки.

На що є пряме джерело

Навіщо: відокремити факти від інтерпретацій.

У цьому блоці наводяться лише ті твердження, які мають пряме підтвердження від:

• офіційних security advisories команди проєкту;
• статусних сторінок сервісу;
• постмортемів або офіційних розслідувань;
• документації гаманців чи протоколів.

Ознака нормального результату: кожне твердження супроводжується вказівкою на джерело. Наприклад: «Команда X опублікувала advisory, у якому вказала…»

При відхиленні: якщо в хронології є фактичні твердження без зазначення джерела — це неповна хронологія. Перевірте наявність advisory або статусної сторінки безпосередньо.

Хто залежить від результату

Навіщо: допомогти читачеві визначити, чи має він особистий ризик.

Тут вказується коло користувачів, продуктів або адрес, яких безпосередньо зачепила подія. Формулювання мають бути максимально вузькими: не «всі користувачі Solana», а, наприклад, «користувачі гаманця Y, які підписали транзакцію типу Z у період з… до…».

Ознака нормального результату: вказані конкретні критерії належності до групи ризику — продукт, дія, часовий проміжок.

При відхиленні: якщо межа групи ризику розмита або перебільшена — це привід утриматися від негайних дій і зібрати більше даних. Про те, як правильно визначати коло зачеплених, читайте в матеріалі Кого насправді зачіпає інцидент продукту, протоколу або постачальника.

Межа поточного знання

Навіщо: показати межу знань і запобігти поширенню гіпотез як фактів.

Це один із найважливіших блоків. У ньому явно перелічуються відкриті питання: причина події, точна кількість зачеплених адрес, статус розслідування, наявність виправлення. Кожне невідоме формулюється як питання, а не як припущення.

Ознака нормального результату: блок присутній і містить конкретні формулювання на кшталт «Наразі невідомо, чи був скомпрометований приватний ключ» або «Причина аномалії не встановлена».

При відхиленні: якщо хронологія не містить цього блоку — вона створює хибне відчуття повноти картини. Такий матеріал не підходить для прийняття рішень щодо безпеки.

Що варто звірити далі

Навіщо: дати читачеві безпечний наступний крок.

Тут наводяться конкретні дії для самостійної перевірки. Кожна дія має бути:

• безпечною — не вимагає введення seed-фрази, приватних ключів чи підключення до підозрілих сайтів;
• обмеженою за масштабом — перевіряється лише те, що стосується конкретного інциденту;
• зворотною — якщо дія не дає результату, читач повертається до очікування офіційної інформації.

Ознака нормального результату: наведено одну–три конкретні перевірки з описом того, що саме шукати й як інтерпретувати результат.

При відхиленні: якщо рекомендації містять команди терміналу без пояснень, прохання надіслати кошти на перевірку або вказівки підключити гаманець до невідомого сервісу — це небезпечно. Такі дії можуть погіршити ситуацію.

Чого не має бути в редакційній хронології

• Причин без доказів. Формулювання на кшталт «ймовірно, сталося через вразливість у Rust» без посилання на advisory — це гіпотеза, а не факт.
• Звинувачення користувача. Фрази «користувачі самі підписали шкідливу транзакцію» без контексту того, чи було можливість обґрунтовано розпізнати ризик — неприпустимі.
• Залучення секретів. Жодна перевірка в хронології не повинна вимагати від читача reveal seed-фрази, приватного ключа чи пароля.
• Конкретних цифр без джерела. Суми втрат, кількість зачеплених гаманців, час реагування — усе це наводиться лише з прямим посиланням на первинне джерело.
• Прогнозів. Хронологія фіксує минуле й поточний стан, а не передбачає наслідки.

Мінімальний безпечний набір дій для читача

1. Прочитайте блок «Що сталося» й визначте тип події.
2. Перевірте блок «Кого це стосується» й зіставте зі своїм досвідом використання продуктів.
3. Ознайомтеся з блоком «Що ще невідомо» — якщо ключове для вас питання там, утримайтеся від дій до появи оновлень.
4. Виконайте перевірки з блоку «Що перевірити далі», якщо вони стосуються вашої ситуації.
5. Якщо є сумніви — дочекайтеся оновленої хронології або зверніться до фахівця з безпеки.

Критерій завершення

Хронологія вважається повною, якщо в ній є всі п’ять блоків, кожне фактичне твердження має джерело, жодна рекомендація не створює додаткового ризику, а межа невідомого явно позначена.

Якщо ви шукаєте загальну довідку з безпеки в екосистемі Solana — почніть з розділу Безпека Solana: спокійно, конкретно, перевірено. Концентрований огляд поточного інциденту з усіма п’ятьма блоками — у матеріалі Інциденти без паніки: що відомо, кого зачепило, що робити.

Редакція солана.укр