Wednesday, November 21, 2012

Безопасность "на коленках"

Сегодня выступали на конференции.

 Выкладываю презентацию.



Хочется буквально пару слов сказать о мотивации. Изначально мы чувствовали себя как-то некомфортно среди реальных хакеров, которые разобрали по байтам сложнейшие системы, исследовали сложнейшие сетевые протоколы, обходили навороченные защиты и т.п. Тогда как мы планируем рассказывать о вещах, которые доступны для проверки и настройке любому, кто умеет пользоваться компьютером, а мотив подготовки к выступлению исключительно чтобы бесплатно туда попасть не представлялся этически правильным. 
Но все решил первый день. Во-первых я понял, что далеко не все на конференции крутые хакеры, есть достаточно много студентов, много только начинающих вставать на путь ИБ, а следовательно, наряду с тяжелыми докладами должны быть и легкие, иначе, это будет несправедливо по отношению к ребятам. Далее, все что написано в презентации достаточно просто проделать самому, поэтому это может служить неким практикумом что ли. В-третьих, в презентации приведено решение, которое, несмотря на свою бесплатность и "наколеночность" эффективно работает в боевых условиях не хуже дорогущих SIEM-ов, причем, за всю историю использования SEC-а я не смог придумать корреляционного правила, для описания которого мне не хватило бы его синтаксиса (стоит признаться, что SEC позволяет вставлять в обработчики полноценные куски кода на Perl которому доступны параметры события, что делает возможности по корреляции безграничными). Последнее (если ничего не забыл) - в конце первого дня была дискуссионная панель об исследователях и исследованиях, где обсуждалась идея о том, что ресеч никому не нужен... Нет, это не так, поскольку:
1. только благодаря этим, никому не нужным, ресечерам, даже не важно на какой стороне, мы из года в год повышаем безопасность. Старые уязвимости, как и многие старые болезни человечества, ушли в далекое прошлое и сейчас многие принципы безопасности, которые ранее были открытием, сейчас считаются очевидными вещами.
2. лично для меня лучшая мотивация - это видеть результат моей работы. Только жажда результата заставляла меня в свое время сидеть по ночам и писать какие-то программки. А когда желаемый результат наступает остается приятное ощущение маленького подвига. Это может казаться смешным, но в моем случае это так и, лично я, готов многое отдать за это короткое счастье. Могу предположить, что талантливые ресечеры имеют такой же маленький секрет, поскольку уверен, что шедевры не пишутся за деньги, ну, по крайней мере, лично я на внутренней увлеченности уеду намного дальше, чем за деньги. Самим ресечерам нужен ресеч.
3. Есть разные ресечи и почти все они нужны. Не только академические ресечи (которые не финансируются, как правило) есть, есть и сугубо практические, результат которых сразу начинает использоваться. Например, вам нужно выбрать для себя решение DLP. При этом все вендоры вам скажут, что они лучшие (скажу более, не всегда присейлы знают возможности своих продуктов хорошо - надо смотреть). Опыт показывает, что для успешности выбора надо со всеми с ними поиграться какое-то время, только после этого будет более или менее объективное мнение. Чем не ресеч? В свое время я это делал, с финансированием этой задачи проблем не было.
Ну и самое последнее (о чем мы упомянули в речи), в основном все доклады были посвящены (как это почему-то и принято на хакерской конференции) способам и средствам атак, тема защиты представлена довольно скудно. Вот мы и решили этот пробел заполнить и посвятить презентацию именно обороне, а не нападению, как большинство.

3 comments:

Nikita Remezov said...

Сергей,
Честно говоря из презентации слабо понятно, что за решение. Это syslog с перл скриптами?

Есть возможность рассказать подробнее об евентах, за которыми следите?
Если не секрет - какой у вас выстроен response?

P.S sorry за много вопросов

Sergey Soldatov said...

Это syslog-ng с Sec.pl (Simple event correlator)
Для того, чтобы Windows превращать в Syslog используется SNARE.

События, которые предлагается детектить:
1. Которых ранее не наблюдали. Правило для SEC - на слайде 18.
2. Запуск сервиса - на слайде 33.
Вообще, мы тут немного утрировали, есть еще ряд событий, которые полезно смотреть - но все зависит от наличия возможности реагирования на все эти события. Если реагировать некогда\некем - следите хотя бы так. Вообще не смотреть в логи - противопоказано!

Респонс. Вообще, вопрос работы SOC\CERT и т.п. - тема отдельная и большая, причем, дискуссионная, так как я не видел хорошего гайда.

Сразу оговорюсь, что он меняется по мере работы, так как по каждому инциденту есть "выученные уроки", которые могут менять процесс.
Если мы говорим о сервере (а мы о нем и говорим), то -- передача информации ответственному админу с рекомендациями. Самим лезть с админскими правами на сервер - неправильно.
Если у админа наблюдаются сложности, там уже смотрим по ситуации. Как правило, админ может всегда (а еще чаще - знает) понять что творится на его сервере.

В случае рабочих станций, как правило, сначала лезем сами. Когда становится точно понятно что происходит и что надо делать - туда направляется хелпдеск с инструкцией что делать (хелпдеск не обязательно идет пешком).

Как-то так. Может, Игорь что добавит (мы в разных компаниях работаем, у него, возможно, по-другому)

Nikita Remezov said...

Спасибо за коментарии.
Интересно мнение - имеет ли смысл делать алерты по принципу черных списков? (т.е используя "сигнатуры" хакерского ПО - самописные или вендорские)
С одной стороны - пока это вроде бы довольно хорошо детектит всякую пакость. Но есть личное ощущение что путь тупиковый и причём дающий ложную уверенность, что детектишь основные вещи.

Респонс да - это тема очень интересная, и гораздо более интересная (во всяком случае для меня) чем детект