🚧 Две недели в офлайне
В продолжение прошлого поста подведём промежуточные итоги и обсудим, почему расследование ИБ-инцидента — это не про «переустановить винду» 🌅.
Сайт компании Tez tour недоступен уже практически две недели. Напомню: речь идёт не о визитке с контактами, а об одном из основных источников продаж и выручки, так как через него работают и туристические брокеры. Для бизнеса 14 дней простоя канала, который генерирует продажи, — это прямые финансовые потери и репутационный удар.
Обычно в такие моменты у руководства и бизнеса возникает логичный и очень эмоциональный запрос к ИТ и ИБ: «Почему так долго? Накатите бэкап и включайте обратно!»
Но в реальности всё работает совершенно иначе. Полная проверка, локализация и очистка инфраструктуры после серьёзного инцидента — это физически небыстрый процесс, и вот почему:
⏺Если просто развернуть вчерашний бэкап, злоумышленники или их автоскрипты вернутся в систему через пару минут. Закрепление в инфраструктуре могло произойти недели или даже месяцы назад, а значит, и сами бэкапы уже могут содержать закладки 🚰.
⏺Нужно собрать и проанализировать огромные массивы логов (если они вообще велись и сохранились), проверить точки входа, учётные записи, цепочки горизонтального перемещения.
⏺Безопасное восстановление сервиса потребует пересборки окружения, ротации всех ключей, сертификатов, паролей и токенов, а также закрытия конкретных уязвимостей, через которые пролезли атакующие.
Если инфраструктура сложная, а видимости и нормального логирования до инцидента не было — расследование превращается в археологические раскопки. И ускорить их без риска повторного взлома невозможно. А если для проведения расследования потребуется изъятие физического оборудования, то ситуация существенно усложняется.
Пока главный вывод, как всегда, в том, что к такому инциденту нужно готовиться заранее, в мирное время.
💬 Готовьте планы восстановления. Бизнес должен заранее понимать, каков допустимый уровень простоя (RTO/RPO) и как поддерживать продажи, пока основной сайт «лежит».
💬Периодически тестируйте восстановления и проводите учения с бизнесом.
Если у вас нет настроенных средств защиты (SIEM/NTA/EDR) и централизованного сбора / анализа логов, то период простоя кратно увеличивается, и это нужно учитывать.
💬 В современном мире ИИ и вабкодинга инциденты будут происходить постоянно. Вопрос давно не в «взломают ли?», а «когда?» и «как?» взломают.
📖InfoSec Context | TG | Max | Web
В продолжение прошлого поста подведём промежуточные итоги и обсудим, почему расследование ИБ-инцидента — это не про «переустановить винду» 🌅.
Сайт компании Tez tour недоступен уже практически две недели. Напомню: речь идёт не о визитке с контактами, а об одном из основных источников продаж и выручки, так как через него работают и туристические брокеры. Для бизнеса 14 дней простоя канала, который генерирует продажи, — это прямые финансовые потери и репутационный удар.
Обычно в такие моменты у руководства и бизнеса возникает логичный и очень эмоциональный запрос к ИТ и ИБ: «Почему так долго? Накатите бэкап и включайте обратно!»
Но в реальности всё работает совершенно иначе. Полная проверка, локализация и очистка инфраструктуры после серьёзного инцидента — это физически небыстрый процесс, и вот почему:
⏺Если просто развернуть вчерашний бэкап, злоумышленники или их автоскрипты вернутся в систему через пару минут. Закрепление в инфраструктуре могло произойти недели или даже месяцы назад, а значит, и сами бэкапы уже могут содержать закладки 🚰.
⏺Нужно собрать и проанализировать огромные массивы логов (если они вообще велись и сохранились), проверить точки входа, учётные записи, цепочки горизонтального перемещения.
⏺Безопасное восстановление сервиса потребует пересборки окружения, ротации всех ключей, сертификатов, паролей и токенов, а также закрытия конкретных уязвимостей, через которые пролезли атакующие.
Если инфраструктура сложная, а видимости и нормального логирования до инцидента не было — расследование превращается в археологические раскопки. И ускорить их без риска повторного взлома невозможно. А если для проведения расследования потребуется изъятие физического оборудования, то ситуация существенно усложняется.
Пока главный вывод, как всегда, в том, что к такому инциденту нужно готовиться заранее, в мирное время.
💬 Готовьте планы восстановления. Бизнес должен заранее понимать, каков допустимый уровень простоя (RTO/RPO) и как поддерживать продажи, пока основной сайт «лежит».
💬Периодически тестируйте восстановления и проводите учения с бизнесом.
Если у вас нет настроенных средств защиты (SIEM/NTA/EDR) и централизованного сбора / анализа логов, то период простоя кратно увеличивается, и это нужно учитывать.
💬 В современном мире ИИ и вабкодинга инциденты будут происходить постоянно. Вопрос давно не в «взломают ли?», а «когда?» и «как?» взломают.
📖InfoSec Context | TG | Max | Web