Дошедшие до первой линии подозрения на инцидент мы называем кейсами. Где то 85% на этом этапе фильтруется, а инцидентами оказываются около 3-4%.
Такая цифра вызвана тем, что часть показателей (критичность инцидента, хоста и УЗ), влияющих на итоговую критичность, проставляется совместно с клиентами.
Также, как правило, скоуп подключенных источников ограничивается системами с довольно высокой критичностью.
Этой задачей в данный момент как раз занимается команда развития :)
Сейчас часть вопросов автоматизировано в SIEM посредством трендов по ключевым индикаторам компрометации – попробуем описать механизм в отдельной статье.
Но у нас есть несколько идей, которые мы прорабатываем, возможно, поделимся ими чуть позже.
Спасибо, что читаете нас.
Интересен ваш опыт по Incident Response с точки зрения людей.
Насколько я помню по прошлым публикациям у вас есть 2 линии обработки инцидентов. Первая линия «массовка» обрабатывает «типовые» сценарии. Вторая «тру-антихакеров» подключается в сложных случаях. Как обучаете 1-ю линию? Проводите ли «Курс молодого бойца» по разбору инцидентов? Есть ли инструкции на каждый типовой инцидент (при бруте делай то, смотри туда)?
Про это мы чуть позже напишем отдельный материал, но общая механика такая:
Да, первую линию обучаем — и основам информационной безопасности, и опыту работы с логами, и тому как устроены Kill Chain, и какой импакто может лежать за каждым инцидентом.
Инструкции по типовым инцидентам есть, но они не пошаговые — cлишком много сценариев и вариантов. Это скорее описание того, что нужно найти по итогам инцидента, основных мест, где можно анализировать информацию, и того, что обязательно надо проверить (критерии false-positive, обязательная к предоставлению информация по инциденту и т.д.)
Дальше много нюансов, но это уже в отдельной статье :)
А 2 линия «тру-антихакеры» у вас свободные художники которые разбирают APT стоящие вне типовых задач? Какие критерии подключения к делу (порог критичности инцидента) этих более опытных товарищей?
За 2-й линией стоит еще и 3-я, и 4-я, и отдельная команда форенсики, но да, идея примерно такая. У инженеров 2-й линии больше опыта и есть некоторая специализация по задачам. К анализу инцидента они подключаются в нескольких случаях:
когда инцидент априори сложный или еще не обкатан массово по 1-й линии;
когда с заказчиком согласована углубленная аналитика по инциденту;
когда конкретный инженер 1-й линии или не может справиться с задачей, или увидел «странное»;
ну, и наконец, когда очень высока нагрузка и нужно просто помочь 1-й линии. SOC — это командная работа :)
Вот ровно в этом вопросе и заключен весь смысл сделанного.
Все изменения структуры таблиц мы “запихнули” в скрипты. Да, исторические данные при подключении конвертируются автоматически. Там возникают ошибки, верно, мы отлаживали эту систему 5-7 лет в общей сложности. Изменения были разные, простые и сложные. Упор был именно на то, что обычный администратор (не DBA!) при нашей поддержке, не обладая знаниями и умениями (ну, или обладая начальными), сможет проводить работу по управлению секциями. Мы очень часто, особенно на раннем этапе, входили в организации, где не было Oracle, и должны были работать в таких условиях.
Часть скриптов обеспечивает трансформацию данных из старых форматов (не только перестроение структуры таблиц, но и их логическое наполнение ), и еще часть пытается обеспечить надежное выполнение этих действий в отсутствие ораклового специалиста. Понятно, что эта цель выглядит крайне амбициозной, но система доказала свою жизнеспособность и работает. На поддержке у нас есть проблемы, связанные с отключением/подключением секций, но, как правило, они связаны со внешними причинами технического характера.
Да, скрипты целиком выложить не можем — это часть продукта, и они раскрывают схему хранения.
Но мы готовы отвечать на вопросы, если вам интересно, как реализованы какие-то конкретные вещи. Кусками можем проиллюстрировать.
1. Сделайте, пожалуйста, картинку с описанием сценария заражения кликабельной — очень мелко, сложно прочитать.
При открытии в новой вкладке картинка, вроде бы, грузится в полном размере.
Вопросы:
1. В статье указано, что заказчику были переданы образы, логи и т.д. для подачи в правоохранительные органы. Вы фиксировали доказательства с процессуальной точки зрения таким образом, чтобы они были приняты судом? (например жесткие диски были запечатаны в конверты и вскрытие только в присутствии эксперта, комиссии и т.д.). Интересно узнать практику оформления таких мероприятий.
Образы были сделаны с помощью специализированного АПК, сами жесткие диски модификации не подвергались. При исследовании образов мы преследовали не криминалистические, а скорее технические цели. Для полноценного криминалистического исследования заказчик самостоятельно должен отдать жесткие диски на экспертизу в некоммерческую организацию. Но наше заключение хоть и не является экспертизой, вполне сойдет за косвенное доказательство как исследование. Практика чаще всего такова, что если заказчик изначально хочет идти в правоохранительные органы, он привлекает соответствующие организации, которые имеют право проводить соответствующую экспертизу.
2. Злоумышленники получили УЗ доменного админа. Удалось установить, как это было сделано?
К сожалению, в силу давности событий нам не удалось установить, как произошла компрометация.
3. У меня сложилось впечатление, что векторов атаки все же могло быть несколько — через УЗ доменного админа (хотя эта УЗ, на мой взгляд, стала бонусом) и/или локального админа (он, скорее всего, был с одинаковым паролем, как минимум для пользовательских машин), а потом получили уже и доменного админа. Еще вариант: пользователь с правами локального администратора.
Почти наверняка Вы правы. Скорее всего, произошла компрометация обычной пользовательской машины, потом mimikatz, получение новых учеток, а дальше уже и доменный администратор.
Если говорить про сотрудников компании, то признаков их вовлеченности в процесс хищения критичной информации мы не обнаружили. Если у заказчика и были внутренние подозрения в отношении сотрудников, нам они неизвестны.
Что касается поиска внешних злоумышленников, то информацию по всем индикаторам, внешним адресам, участвующим в атаке, снятые образы хостов и значимые исходные логи мы передали заказчику для дальнейшего разбирательства с правоохранителями. Финал истории нам, увы, неизвестен.
Сейчас тема о «размытии сетевого периметра», облаков и BYOD в большом почете. Надо только расписать руководству все риски таких подходов. Если руководство подписывается под этими рисками, то безопаснику только и остаётся работать в заданных условиях.
Целиком согласны. Именно о таких ситуациях с заданными условиями мы и пишем статьи :)
Тут кстати интересный вопрос, что еще дешевле выйдет, закрыть прямой доступ в интернет (воздушный зазор) или доступ оставить и озаботиться услугами SOC аутсорсера.
К сожалению, здесь вопрос не про деньги. Первый подход с точки зрения расходов ИБ стоит дешево, но целиком сказывается на динамике и мобильности самого бизнеса, которую «в лоб» деньгами не измерить. И чаще всего именно из-за этого и редко применяется в принципе и практически отсутствует в коммерческом секторе.
Милитаристский подход к обеспечению безопасности — достаточно эффективный и позволяет закрыть много векторов угроз. Но сторонники этого подхода сейчас находятся скорее в начале пути с согласованием политик и блокировок (закрыть прямой доступ в интернет в крупной компании и обеспечить управление уязвимостями — те еще задачи, каждая на медаль тянет), а безопасность нужна уже сейчас. А вообще большинство организаций, особенно коммерческих, все чаще двигаются в обратную сторону: минимизация жестких запретов и предоставление допустимой свободы бизнес-пользователям, но при этом всеобъемлющий мониторинг активностей с возможностью вмешаться и воздействовать в критической ситуации.
Скажем так, построить «SOC в базовой комплектации» из 5 элементов реально. Но если мы сейчас назовем их, какой же людям будет интерес дальше отвечать?)
К тому же, все-таки компании, понимающие, что им нужен SOC, обычно уже обзавелись, как минимум, антивирусом. Поэтому если мы подразумеваем, что у заказчика есть базовые системы защиты, дальше многое зависит от специфики его бизнеса.
Вы абсолютно правы, задача действительно очень сложная, но, как правило, детализация нужна вокруг критичных систем и данных, там важны нюансы. А общие пользовательские сети для оценки защищенности зачастую достаточно описать в «крупную клетку». Именно поэтому мы рекомендуем начинать с общего описания (филиал такой-то, dmz в ИА, VPN-пул, сеть АРМ КБР). Все остальное по мере возникновения инцидентов попадает в условную зону Unknown, и в момент анализа инцидента заодно уточняется информация.
Какие гарантии производитель дает организации-заказчику? Т.е. если данные утекли мимо DLP программы, то какая компенсация предусмотрена?
Гарантий никто не дает. Информация может пройти мимо DLP, это не секрет. Если Вы узнаете о предстоящем слиянии Uber и Яндекс.Такси и посоветуете друзьям срочно покупать акции «Яндекса», это будет утечка. Но техническими мерами предотвратить такое пока нельзя.
Как вы ловите утечки через DNS/IP туннели, передача информаций с помощью звуковых разъемов и т.д.?
Конкретно Solar Dozor контролирует утечки через каналы, где невозможно снятие копии трафика с помощью скриншотов экрана. В некоторых решениях стоит кейлоггер. Через звуковые разъемы — никак. Некоторые заявляют о контроле голосовых сообщений, но там пока остается вопрос качества распознавания речи.
Как защищают DLP решения от подделки логов, т.е. какая защита от того, что один сотрудник может скомпрометировать другого сотрудника? Какую ответственность несет производитель DLP решения, если такое произошло?
Это технически нереализуемо (по крайней мере, в известных нам DLP-решениях).
Такая цифра вызвана тем, что часть показателей (критичность инцидента, хоста и УЗ), влияющих на итоговую критичность, проставляется совместно с клиентами.
Также, как правило, скоуп подключенных источников ограничивается системами с довольно высокой критичностью.
Сейчас часть вопросов автоматизировано в SIEM посредством трендов по ключевым индикаторам компрометации – попробуем описать механизм в отдельной статье.
Но у нас есть несколько идей, которые мы прорабатываем, возможно, поделимся ими чуть позже.
Спасибо, что читаете нас.
Про это мы чуть позже напишем отдельный материал, но общая механика такая:
Дальше много нюансов, но это уже в отдельной статье :)
За 2-й линией стоит еще и 3-я, и 4-я, и отдельная команда форенсики, но да, идея примерно такая. У инженеров 2-й линии больше опыта и есть некоторая специализация по задачам. К анализу инцидента они подключаются в нескольких случаях:
Все изменения структуры таблиц мы “запихнули” в скрипты. Да, исторические данные при подключении конвертируются автоматически. Там возникают ошибки, верно, мы отлаживали эту систему 5-7 лет в общей сложности. Изменения были разные, простые и сложные. Упор был именно на то, что обычный администратор (не DBA!) при нашей поддержке, не обладая знаниями и умениями (ну, или обладая начальными), сможет проводить работу по управлению секциями. Мы очень часто, особенно на раннем этапе, входили в организации, где не было Oracle, и должны были работать в таких условиях.
Часть скриптов обеспечивает трансформацию данных из старых форматов (не только перестроение структуры таблиц, но и их логическое наполнение ), и еще часть пытается обеспечить надежное выполнение этих действий в отсутствие ораклового специалиста. Понятно, что эта цель выглядит крайне амбициозной, но система доказала свою жизнеспособность и работает. На поддержке у нас есть проблемы, связанные с отключением/подключением секций, но, как правило, они связаны со внешними причинами технического характера.
Но мы готовы отвечать на вопросы, если вам интересно, как реализованы какие-то конкретные вещи. Кусками можем проиллюстрировать.
При открытии в новой вкладке картинка, вроде бы, грузится в полном размере.
Образы были сделаны с помощью специализированного АПК, сами жесткие диски модификации не подвергались. При исследовании образов мы преследовали не криминалистические, а скорее технические цели. Для полноценного криминалистического исследования заказчик самостоятельно должен отдать жесткие диски на экспертизу в некоммерческую организацию. Но наше заключение хоть и не является экспертизой, вполне сойдет за косвенное доказательство как исследование. Практика чаще всего такова, что если заказчик изначально хочет идти в правоохранительные органы, он привлекает соответствующие организации, которые имеют право проводить соответствующую экспертизу.
К сожалению, в силу давности событий нам не удалось установить, как произошла компрометация.
Почти наверняка Вы правы. Скорее всего, произошла компрометация обычной пользовательской машины, потом mimikatz, получение новых учеток, а дальше уже и доменный администратор.
Что касается поиска внешних злоумышленников, то информацию по всем индикаторам, внешним адресам, участвующим в атаке, снятые образы хостов и значимые исходные логи мы передали заказчику для дальнейшего разбирательства с правоохранителями. Финал истории нам, увы, неизвестен.
К сожалению, здесь вопрос не про деньги. Первый подход с точки зрения расходов ИБ стоит дешево, но целиком сказывается на динамике и мобильности самого бизнеса, которую «в лоб» деньгами не измерить. И чаще всего именно из-за этого и редко применяется в принципе и практически отсутствует в коммерческом секторе.
К тому же, все-таки компании, понимающие, что им нужен SOC, обычно уже обзавелись, как минимум, антивирусом. Поэтому если мы подразумеваем, что у заказчика есть базовые системы защиты, дальше многое зависит от специфики его бизнеса.
Сейчас поправим заголовок во избежание :)
Пример:
Конкретно Solar Dozor контролирует утечки через каналы, где невозможно снятие копии трафика с помощью скриншотов экрана. В некоторых решениях стоит кейлоггер. Через звуковые разъемы — никак. Некоторые заявляют о контроле голосовых сообщений, но там пока остается вопрос качества распознавания речи.
Это технически нереализуемо (по крайней мере, в известных нам DLP-решениях).