Частые ошибки при реагировании на инциденты ИБ

Очень часто, пытаясь быстро отреагировать на атаку злоумышленника, специалисты по кибербезопасности допускают ряд ошибок, которые сильно затрудняют расследование инцидента информационной безопасности (ИБ) и в дальнейшем приводят к неверным выводам. Как вы уже поняли, сегодня мы рассмотрим самые грубые и частые ошибки при реагировании на инциденты.

План реагирования на инцидент, как правило, состоит (или как минимум должен состоять) из следующих шагов:

• детектирование потенциальной атаки;
• анализ артефактов инцидента;
• принятие мер по сдерживанию атаки;
• восстановление работоспособности системы;
• выводы по итогам расследования (для минимизации повторного инцидента аналогичного типа).

Исходя из своего опыта могу сказать, что следующие ошибки при реагировании на инциденты ИБ, являются самыми распространенными:

1. Чрезмерная уверенность в плане и в средствах защиты. Опрометчиво думать, что если вы подготовились к атаке заранее, то все точно пойдет по плану. Абсолютно безопасных систем не существует.
2. Неследование пунктам плана. Не стоит игнорировать предшествующие пункты плана, чтобы ускорить решение проблемы. Вы можете упустить ключевые моменты атаки и сделать только хуже.
3. Делать выводы из теорий, игнорируя конкретные факты. Порой, чтобы объяснить уязвимость, игнорируются факты, которые не вяжутся с вашей теорией. Такие выводы чреваты повтором инцидента в будущем.
4. Защита неверного решения перед руководством. Страх и неумение признать свои ошибки могут сыграть на руку злоумышленнику.
5. Ошибки в описании проблемы. Максимально ответственно отнеситесь к отчету по завершении инцидента. Все, что происходило, необходимо описать правильно, а также важно не писать то, чего не было, в угоду вашей теории.
6. Затирать следы (при помощи бэкапа), если планируется расследование. Прежде чем восстановить систему, используя бэкап, задумайтесь, не удалятся ли при этом важные сведения об инциденте. Иначе, если вы решите проводить тщательное расследование, можете лишиться важных данных.

Неправильно написанный отчет об инциденте также может являться источником неверных рисков и необоснованных трат для вашей компании. Следующие ошибки при составлении отчета могут ввести в заблуждение при последующей обработке информации:

• Отсутствие IP-адресов, имен хостов, атакованных сервисов. Точность крайне важна для последующей обработки информации из отчета.
• Отсутствие индикаторов компрометации. Четко описывайте причину, по которой возник инцидент. Написание предположений или очевидных вещей, без описания уязвимости, не является решением (!).
• Не бояться написать, что источник компрометации найти не удалось. Данных может и не быть, к примеру, если злоумышленник хорошо за собой "прибрал" или вы удалили все следы, восстановив образ из бэкапа, не проведя предварительно расследование.
• Не стоит писать в отчет об инциденте то, что вы сами не видели, или то, что подтвердить не удалось.

   

Надеюсь, что данная информация поможет вам получить достаточное представление о том, как НЕ надо реагировать на инцидент ИБ, и выстроить ваш процесс реагирования наилучшим образом.