В условиях современной действительности приходится констатировать, что все интерпрайзы можно поделать на два типа: те, которые знают, что их скомпрометировали, и те, кто об этом пока не догадывается. Связано это с некоторой нестыковкой "классических" подходов к обеспечению безопасности с текущей реальностью. "Классический" подход рекомендует нам иметь алерты реального времени на все возможное зло, на основании которых мы будем предпринимать, также, почти в реальном времени, определенное реагирование. Еще одной характеристикой "классики" является приоритет превентивных мер - рубить канаты как можно скорее: прервать неправильную деятельность как можно раньше. Данный подход прекрасно работает, когда определено что такое "зло" т.е. точно детерминирован алерт, а также, рубя канаты, есть уверенность что именно ты прерываешь и какая под этим мотивация. Ужасными последствиями такого "классического" подхода являются:
а) непродолжительное хранение логов в системе мониторинга, поскольку данных нужно не более, чем достаточно для генерации алерта, который, напомню, генерится в реальном времени (тут следует отметить, что предположение о том, что логи можно оставлять на самой системе для дальнейшего анализа с точки зрения любого подхода, и классического, и не очень, является полным бредом - логи всегда надо уносить, чтобы, потеряв систему, не потерять историю ее болезни и кончины),
б) нехранение "сырых" логов, а только "мета-событий", сформированных из них "на лету" на основании некой логики, известной на момент настройки алерта, несущий в себе фиксированное понимание вредоносной активности и мотивации злоумышленника (поскольку только в этом случае можно придумать эффективное реагирование, а само наличие алерта предполагает, что должно быть и реагирование).
Появление целенаправленных сложных атак дало нам понимание, что
а) скорее всего мы не увидим эксплуатацию, поэтому приоритезировать усилия разумнее на как можно более раннее обнаружение постэксплуатации,
б) скорее всего не стоит сразу "рубить концы", но потратить время на исследование\расследование атаки, что позволит понять мотивацию и выработать более эффективные защитные мероприятия (ну конечно типовые вещи должны сразу идти на типовой маршрут отработки, речь - о нестандартных ситуация, которые пока еще не исследованы и не переведены в разряд "типовых"),
в) обязательно надо иметь возможность разностороннего ретроспективного анализа логов, так как на момент обнаружения нет понимания что это мы наблюдаем и зачем это делается, поэтому не понятно где и в каком виде это может проявиться.
Адаптируя свой лог-менеджмент к этой новой парадигме получается примерно следующее:
а) собирать логи надо все и обрабатывать централизованно (т.е. искать по всем сразу), поскольку едва ли удастся угадать где что полезного можно будет обнаружить в рамках расследования,
б) хранить именно сырые логи и иметь возможность в будущем их по-разному анализировать, - технологии атак меняются, меняются и подходы их обнаружения и расследования, а раз так, то надо иметь возможность делать различные выборки, по-разному отображая одни и те же данные; иными словами, по мере расследования я буду получать все новую информацию, которая позволит мне строить более точные запросы к данным и доставать все новые детали,
в) хранить логи надо долго, так как, обнаружив сейчас постэксплуатацию, надо уметь ее "отмотать" на неопределенно долгий срок назад, с целью понять "как это было" и "с чего все началось", чтобы, в конце концов, имея целостную картину, выработать эффективное противостояние.
Получается, что в таких условиях задача службы мониторинга уже не просто "как можно раньше прокукарекать и заткнуть все, что получится", а именно расследовать с целью выработки более эффективных мер. Тут хорошая аналогия вспоминается из практики: в логах антивируса фиксировалось постоянно заражение и успешное лечение одной и той же рабочей станции. В целом, можно было бы забить - заражение завершалось успешным лечением, однако несложное исследование показало, что дроппер не обнаруживался этим антивирусом, причем сидел уже настолько хорошо, что самые свежие сигнатуры были ни по чем, а то, что успешно лечилось - это уже его "полезные нагрузки" и вопрос был только в некотором временном лаге, когда-таки прилетел бы "правильно запакованный\пересобранный" малварь, приведший уже к последствиям, совпадающим с мотивами злоумышленника. Этот банальный пример показывает, что здесь мы видим именно постэксплуатацию, ибо прошляпили как залетел и как закрепился дроппер. Анализ проводился на большом периоде, поскольку попытки закачать "полезную нагрузку" не были чаще чем раз в день, причем разброс по времени был случаен. Но уже потом, вытащив дроппер, было интересно поискать его следы в логах Web-прокси, почтовой системы, пошариться SCCM-ом и антивирусом по всем десктопам в интерпрайзе, поискать его в логах системы контроля доступа к периферийным устройствам и вообще везде, от чего у нас есть логи (очевидно желание все это сделать одним поиском). Причем, с учетом того, что "грамотный" дроппер, закрепившись, не стал бы палиться сразу, ретроспективный анализ следов его залета к нам необходимо проводить на неопределенной глубине данных.
Конечно, Истина где-то посередине, поэтому из этого поста совсем не должно делать вывод о полной бесполезности оперативной готовности, совсем нет, просто неправильно полагаться исключительно на нее. В одном из проектов построения системы мониторинга, некие архитекторы делали глубину хранения логов 1 месяц, типа "...нам нужна глубина не более, чем необходимо для формирования алерта на основании которого админ далее полезет на "проблемную" систему и будет там что-то чинить..." - вот так не надо рассуждать.
а) непродолжительное хранение логов в системе мониторинга, поскольку данных нужно не более, чем достаточно для генерации алерта, который, напомню, генерится в реальном времени (тут следует отметить, что предположение о том, что логи можно оставлять на самой системе для дальнейшего анализа с точки зрения любого подхода, и классического, и не очень, является полным бредом - логи всегда надо уносить, чтобы, потеряв систему, не потерять историю ее болезни и кончины),
б) нехранение "сырых" логов, а только "мета-событий", сформированных из них "на лету" на основании некой логики, известной на момент настройки алерта, несущий в себе фиксированное понимание вредоносной активности и мотивации злоумышленника (поскольку только в этом случае можно придумать эффективное реагирование, а само наличие алерта предполагает, что должно быть и реагирование).
Появление целенаправленных сложных атак дало нам понимание, что
а) скорее всего мы не увидим эксплуатацию, поэтому приоритезировать усилия разумнее на как можно более раннее обнаружение постэксплуатации,
б) скорее всего не стоит сразу "рубить концы", но потратить время на исследование\расследование атаки, что позволит понять мотивацию и выработать более эффективные защитные мероприятия (ну конечно типовые вещи должны сразу идти на типовой маршрут отработки, речь - о нестандартных ситуация, которые пока еще не исследованы и не переведены в разряд "типовых"),
в) обязательно надо иметь возможность разностороннего ретроспективного анализа логов, так как на момент обнаружения нет понимания что это мы наблюдаем и зачем это делается, поэтому не понятно где и в каком виде это может проявиться.
Адаптируя свой лог-менеджмент к этой новой парадигме получается примерно следующее:
а) собирать логи надо все и обрабатывать централизованно (т.е. искать по всем сразу), поскольку едва ли удастся угадать где что полезного можно будет обнаружить в рамках расследования,
б) хранить именно сырые логи и иметь возможность в будущем их по-разному анализировать, - технологии атак меняются, меняются и подходы их обнаружения и расследования, а раз так, то надо иметь возможность делать различные выборки, по-разному отображая одни и те же данные; иными словами, по мере расследования я буду получать все новую информацию, которая позволит мне строить более точные запросы к данным и доставать все новые детали,
в) хранить логи надо долго, так как, обнаружив сейчас постэксплуатацию, надо уметь ее "отмотать" на неопределенно долгий срок назад, с целью понять "как это было" и "с чего все началось", чтобы, в конце концов, имея целостную картину, выработать эффективное противостояние.
Получается, что в таких условиях задача службы мониторинга уже не просто "как можно раньше прокукарекать и заткнуть все, что получится", а именно расследовать с целью выработки более эффективных мер. Тут хорошая аналогия вспоминается из практики: в логах антивируса фиксировалось постоянно заражение и успешное лечение одной и той же рабочей станции. В целом, можно было бы забить - заражение завершалось успешным лечением, однако несложное исследование показало, что дроппер не обнаруживался этим антивирусом, причем сидел уже настолько хорошо, что самые свежие сигнатуры были ни по чем, а то, что успешно лечилось - это уже его "полезные нагрузки" и вопрос был только в некотором временном лаге, когда-таки прилетел бы "правильно запакованный\пересобранный" малварь, приведший уже к последствиям, совпадающим с мотивами злоумышленника. Этот банальный пример показывает, что здесь мы видим именно постэксплуатацию, ибо прошляпили как залетел и как закрепился дроппер. Анализ проводился на большом периоде, поскольку попытки закачать "полезную нагрузку" не были чаще чем раз в день, причем разброс по времени был случаен. Но уже потом, вытащив дроппер, было интересно поискать его следы в логах Web-прокси, почтовой системы, пошариться SCCM-ом и антивирусом по всем десктопам в интерпрайзе, поискать его в логах системы контроля доступа к периферийным устройствам и вообще везде, от чего у нас есть логи (очевидно желание все это сделать одним поиском). Причем, с учетом того, что "грамотный" дроппер, закрепившись, не стал бы палиться сразу, ретроспективный анализ следов его залета к нам необходимо проводить на неопределенной глубине данных.
Конечно, Истина где-то посередине, поэтому из этого поста совсем не должно делать вывод о полной бесполезности оперативной готовности, совсем нет, просто неправильно полагаться исключительно на нее. В одном из проектов построения системы мониторинга, некие архитекторы делали глубину хранения логов 1 месяц, типа "...нам нужна глубина не более, чем необходимо для формирования алерта на основании которого админ далее полезет на "проблемную" систему и будет там что-то чинить..." - вот так не надо рассуждать.
No comments:
Post a Comment