О сборе логов

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

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

Адаптируя свой лог-менеджмент к этой новой парадигме получается примерно следующее:
а) собирать логи надо все и обрабатывать централизованно (т.е. искать по всем сразу), поскольку едва ли удастся угадать где что полезного можно будет обнаружить в рамках расследования,
б) хранить именно сырые логи и иметь возможность в будущем их по-разному анализировать, - технологии атак меняются, меняются и подходы их обнаружения и расследования, а раз так, то надо иметь возможность делать различные выборки, по-разному отображая одни и те же данные; иными словами, по мере расследования я буду получать все новую информацию, которая позволит мне строить более точные запросы к данным и доставать все новые детали,
в) хранить логи надо долго, так как, обнаружив сейчас постэксплуатацию, надо уметь ее "отмотать" на неопределенно долгий срок назад, с целью понять "как это было" и "с чего все началось", чтобы, в конце концов, имея целостную картину, выработать эффективное противостояние.

Получается, что в таких условиях задача службы мониторинга уже не просто "как можно раньше прокукарекать и заткнуть все, что получится", а именно расследовать с целью выработки более эффективных мер. Тут хорошая аналогия вспоминается из практики: в логах антивируса фиксировалось постоянно заражение и успешное лечение одной и той же рабочей станции. В целом, можно было бы забить - заражение завершалось успешным лечением, однако несложное исследование показало, что дроппер не обнаруживался этим антивирусом, причем сидел уже настолько хорошо, что самые свежие сигнатуры были ни по чем, а то, что успешно лечилось - это уже его "полезные нагрузки" и вопрос был только в некотором временном лаге, когда-таки прилетел бы "правильно запакованный\пересобранный" малварь, приведший уже к последствиям, совпадающим с мотивами злоумышленника. Этот банальный пример показывает, что здесь мы видим именно постэксплуатацию, ибо прошляпили как залетел и как закрепился дроппер. Анализ проводился на большом периоде, поскольку попытки закачать "полезную нагрузку" не были чаще чем раз в день, причем разброс по времени был случаен. Но уже потом, вытащив дроппер, было интересно поискать его следы в логах Web-прокси, почтовой системы, пошариться SCCM-ом и антивирусом по всем десктопам в интерпрайзе, поискать его в логах системы контроля доступа к периферийным устройствам и вообще везде, от чего у нас есть логи (очевидно желание все это сделать одним поиском). Причем, с учетом того, что "грамотный" дроппер, закрепившись, не стал бы палиться сразу, ретроспективный анализ следов его залета к нам необходимо проводить на неопределенной глубине данных.

Конечно, Истина где-то посередине, поэтому из этого поста совсем не должно делать вывод о полной бесполезности оперативной готовности, совсем нет, просто неправильно полагаться исключительно на нее. В одном из проектов построения системы мониторинга, некие архитекторы делали глубину хранения логов 1 месяц, типа "...нам нужна глубина не более, чем необходимо для формирования алерта на основании которого админ далее полезет на "проблемную" систему и будет там что-то чинить..." - вот так не надо рассуждать.
 

Сканеры уязвимостей@Enterprise

Следуя правильной причинно-следственной логике, прежде чем выбирать инструмент решения, следует понять задачу. Очевидно, сканер уязвимостей нужен для поиска уязвимостей, чтобы их потом латать и так, постепенно, улучшать свои ИТ-системы в предположении, что минимизация уязвимостей == повышение безопасности, наверно, это так и есть. 
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно. 
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница,  в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал, в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM, выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты, которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются. 
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным", поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором, и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Прниципиальная вещь: сканер не находит неизвестные уязвимости и вряд ли найдет больше, чем известно "нормальному" производителю исследуемого ПО.

Любопытно, что даже если я разрабатываю ПО, мне тоже едва ли подходит off-the-shelf сканер, - значительно эффективнее будет работать моя продуктовая безопасность, которая знает мои продукты лучше производителя сканера и имеет специализованные инструменты, адаптированные под мою продукцию, понимает, что дейстительно критично и поэтому может правильно расставлять приоритеты.

Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
0. У меня огромный разнородный ИТ-комплекс, поэтому мне невозможно детально разбираться с каждым, используемым у меня производителем (заниматься харденинком его решений), мне проще запустить комбайн, который на приемлемом уровне решит проблему (ну или хотя бы сделает что-то, что лучше, чем ничего).
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление (почти п.0, но с условием необходимости быстрых результатов при отсутствии времени).
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнаруты\профили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей (тоже почти п.0, но при отсутствии объективной невозможности разобраться с рекомендациями производителей, я просто лентяй).
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурах\проверках сканера)
7. Я хочу\должен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC.

На практике мы, конечно же, имеем комбинацию перечисленного + что-то уникальное, до чего я даже не догадываюсь.