Incident Response
Серьезные ИБ-инциденты порой затрагивают многих участников, зачастую и тех, кто повседневно не занимается вопросами ИТ и ИБ. Понятно, что в первую очередь усилия сосредоточиваются на выявлении, сдерживании и восстановлении, но, когда пыль немного осядет, наступает время для еще одного важного этапа реагирования — извлечения уроков. Чему можно научиться по итогам инцидента? Как улучшить шансы на успешное отражение подобных атак в будущем? На эти вопросы очень полезно ответить, даже если инцидент не принес существенного ущерба из-за эффективного реагирования или просто удачного стечения обстоятельств.
Немного о людях
Разбор инцидента важен для всей организации, поэтому к нему обязательно привлекать не только команды ИТ и ИБ, но также высшее руководство, бизнес-владельцев ИТ-систем, а также подрядчиков, если они были затронуты инцидентом или привлекались к реагированию. На встречах этой рабочей группы нужно создать продуктивную атмосферу: важно донести, что это не поиск виноватых (хотя ошибки будут обсуждаться), поэтому перекладывание ответственности и манипулирование информацией исказят картину, повредят анализу и ухудшат позицию организации в долгосрочной перспективе.
Еще один важный момент: многие компании скрывают детали инцидента в страхе за репутацию или опасаясь повторной кибератаки по тому же сценарию. И хотя это вполне объяснимо и некоторые подробности действительно конфиденциальны, нужно стремиться к максимальной прозрачности в реагировании и делиться подробностями атаки и реагирования если не с широкой публикой, то как минимум с узким кругом коллег из сферы ИБ, которые могут предотвратить похожие атаки на свои организации.
Детальный анализ инцидента
Хотя многие данные об инциденте уже собраны непосредственно во время реагирования, их можно значительно обогатить и вдумчиво сопоставить постфактум. В первую очередь собрать ответы на вопросы, как и когда противник проник в организацию, какими уязвимостями, техническими и организационными недостатками он воспользовался и как развивалась атака. Полезно наложить данные о действиях злоумышленников на временную шкалу, а затем на ней же отразить действия по реагированию на инцидент. Это позволит понять, когда были замечены аномалии. Каким образом. Какими были меры реагирования. Все ли службы были своевременно привлечены. Были ли задействованы сценарии эскалации.
Ответы на все перечисленные вопросы нужно детально документировать, опираясь на фактические данные: события в SIEM-системе, время заведения задач в таск-менеджере или отправки e-mail и так далее. Это позволяет создать всеобъемлющую и детальную картину. Коллективно изучив ее, можно оценить скорость и эффективность каждого шага реагирования.
Отдельно нужно оценить влияние инцидента на бизнес в таких аспектах, как непрерывность операций, целостность данных, наличие утечек, финансовые убытки (как прямые, так и косвенные), репутация компании. Это позволит лучше соотносить масштаб и стоимость инцидента с масштабом и стоимостью мер по укреплению ИБ.
Поиск слабых и сильных мест
Технические отчеты об инцидентах на первый взгляд уже содержат нужную информацию, но на самом деле в них обычно нет нужного организационного контекста. В отчете написано, что злоумышленники проникли в систему, проэксплуатировав уязвимость Х, организации необходимо устранить уязвимость Х на всех серверах. За рамками этого поверхностного анализа остаются вопросы о том, сколько времени эта уязвимость была незакрытой со времени публикации данных о ней, какие еще известные уязвимости есть в серверах и каково соглашение ИТ и ИБ о сроках устранения этих дефектов, существует ли в компании приоритизация уязвимостей.
Подобного обсуждения заслуживает каждый этап и процесс, затронутый инцидентом, чтобы комплексно оценить дефекты в общем ландшафте ИБ, которые позволили инциденту произойти. Важно не фокусироваться только на негативе — если какие-то службы сработали быстро и слаженно, если существующие процессы и технологии ускорили обнаружение инцидента или помогли значительно снизить ущерб от него, необходимо изучить эти аспекты и понять, применим ли этот позитивный опыт где-то еще.
Отдельного внимания стоят человеческие ошибки и особенности поведения — какую роль они сыграли в инциденте? Но, еще раз, целью должен быть не поиск виновных, а выработка мер, которые могут скомпенсировать или сгладить неизбежное влияние человеческого фактора в будущем.
Планирование улучшений
Это самый творческий и организационно сложный этап «разбора полетов», потому что необходимо выработать эффективные и реально реализуемые шаги, которые помогут устранить слабые места с учетом ресурсных ограничений. Вовлечение высшего руководства в этот процесс особенно полезно — народная мудрость гласит, что никогда бюджеты на ИБ не выделяются так быстро и щедро, как после крупного инцидента. В плане надо учесть несколько аспектов:
Обновление карты ИТ-активов. Благодаря инциденту компания, возможно, узнала много нового о том, как обрабатываются ее данные и реализованы процессы в целом. Часто требуется обновление приоритетов, чтобы понять, защите каких активов уделять первоочередное внимание.
Технологии детектирования и реагирования. Анализируя, какие этапы атаки не были замечены защитниками и каких технических мер не хватало, чтобы остановить развитие атаки, можно запланировать внедрение дополнительных инструментов ИБ, например EDR, SIEM, NGFW. Иногда становится понятно, что все инструменты вроде бы уже есть, но для эффективного их применения не хватает технологий автоматизации или потоков данных, например фидов threat intelligence или автоматизированных сценариев реагирования. Или логи хранились таким образом, что злоумышленники их легко и централизованно удалили. Технологическому аспекту нужно уделить повышенное внимание, если анализ показал, что защитники потратили избыточное время на ручной поиск пораженных хостов или другую кропотливую работу, не имели доступа к критической информации, не обладали инструментарием для применения защитных мер в масштабе компании.
Процессы и политики. Разобравшись, произошел ли инцидент из-за нарушения имеющихся политик или в их отсутствие, важно скорректировать эту ситуацию, пройдя по всей цепочке событий и отразив в регламентах исправления всех найденных процессных недочетов. От процессов, политики и регламентных сроков управления уязвимостями и учетными записями до плейбуков реагирования на инциденты — нужно, чтобы скорректированные процессы компании позволяли успешно предотвратить инцидент, похожий на случившийся.
Общий план реагирования на инциденты тоже должен быть обновлен и скорректирован на базе практического опыта. Важно уточнить, какие стороны не смогли полноценно участвовать в процессе и как организовать оперативную коммуникацию между ними и обеспечить своевременное принятие экстренных решений.
Профилактические меры: техника. Инцидент позволяет взглянуть новыми глазами на сложившиеся практики управления учетными записями и патч-менеджмент. Нужно запланировать пошаговые улучшения в тех областях, где компания не соблюдала лучшие практики: внедрить принцип наименьших привилегий и централизованное управление Identity, приоритизировать и системно устранять ключевые уязвимости в инфраструктуре.
Профилактические меры: люди. Каждая ошибка, совершенная сотрудниками, требует корректирующих мер — целевых тренингов или даже учений, адаптированных к роли сотрудника. Стоит обсудить, какие тренинги требуются конкретным людям, а какие — целым отделам или всему предприятию. В целом крупный инцидент является хорошей встряской, он демонстрирует важность ИБ и позволяет провести тренинги Cybersecurity Awareness с высоким вовлечением даже тех сотрудников, которые преуменьшают важность ИБ.
Отдельных усилий по обучению заслуживают обновленные процессы — следовать им может быть сложнее, и потребуются тренинги, напоминания руководства и, быть может, программа мотивации, чтобы обновленные регламенты заработали в полную силу.
Готовимся к следующему инциденту
Все вышеперечисленные меры в теории повышают киберустойчивость и готовность к инцидентам ИБ. Но чтобы быть уверенным в результате, не лишне проверить качество их реализации — провести киберучения, тесты на проникновение или упражнения с «красной командой» (Red Teaming). Эти имитации настоящих киберинцидентов решают разные задачи, поэтому какое их сочетание лучше подходит — зависит от организации и принятых после инцидента мер.
Реализация всех улучшений и обновленных мер защиты может быть длительным и поэтапным процессом, поэтому необходимо запланировать регулярные встречи всех вовлеченных сторон, чтобы собирать обратную связь, обсуждать реализацию принятого плана, возникшие трудности, а также способы дальнейшего улучшения общей защищенности в организации. Чтобы эти встречи не были пустыми разговорами, нужно договориться о конкретных метриках и контрольных точках, которые свидетельствуют об успешной реализации плана.
