Thursday, July 7, 2016

Два сценария мониторинга

Несомненно, заслуживает уважения стремление Человечества все автоматизировать. Однако, концептуально непреодолимая проблема в том, что машина не может догадываться (некоторая продвинутость в вопросах машинного обучения заставляет в этом сомневаться , но на практике я не видел полностью автоматических систем безопасности, полагаю, сначала появятся пентестеры-автоматы, и это будет предвестником безопасников-автоматов :) ), а рейтинговые системы порой дают результаты, оспаривающие здравый смысл, что может служить почвой для анекдотов и прочего народного творчества. Поэтому, приходится нехотя соглашаться, что автоматикой мы способны задетектить то, с чем аналитик когда-то разбирался и придумал некоторый алгоритм, как это обнаруживать. Но, очевидная правда в том, что безопасность - бесконечная игра в кошки-мышки, где защищающие постоянно отстают от нападающих и вынуждены уже постфактумно, получив какие-либо артефакты, разгадывать неведанные, тайные и запутанные замыслы атакующих. Поскольку от детских проблем прекрасно спасает автоматика, а кибератака - эффективный инструмент влияния, получающий всю большую популярность одновременно с повышением своей эффективности, мы имеем, что для обеспечения этого эффективного влияния атакующий должен использовать недетские TTP, способные обходить автоматические средства защиты, бить в те места, где автоматика бессильна, обнажая пробельные места в защите.
Вот, как раз, эти-то пробельные места и компенсируются трудом аналитика, проводящего расследования компьютерных атак (== инцидентов ИБ). Широко смотря на проблему разделение задач такое: робот - детектит все то, что известно, а все что не известно - детектит аналитик и учит этому робота, создавая корреляционные правила/сигнатуры и т.п.. Так обеспечивается замкнутый цикл мониторинга, реализованный через симбиоз человека и робота - основа построения комплексной услуги и системного подхода.

На практике это выглядит как два сценария мониторинга. Первый назовем "Alerting" (или "Alerts"). Его суть заключается в том, что под известные TTP, выраженные в цепочках событий\нотификаций систем безопасности (да и любых других систем, способных генерить логи вообще) создаются алерты, свидетельствующие о том, что данная цепочка была обнаружена, а следовательно - обнаружена соответствующая ей атака. Достоверность (% ложных срабатываний) такого алерта будет полностью зависеть от качества цепочки (корреляционного правила, сигнатуры). Здесь задача службы мониторинга - а) понять что алерт - не фолса, б) инициировать процесс реагирования на инцидент и отработки последствий. Этот случай - классический, все, кого я спрашивал о том, что он думает о мониторинге и SOC, - отвечали примерно это.
Второй сценарий, назовем его "Hunting", менее очевидный, но все понимают его необходимость при попытке ответить на вопрос: "Откуда берутся корреляционные правила". Да, сценарий, когда аналитик почитал новости и сделал новую детектирующую цепочку все равно относится к Первому сценарию, поскольку аналитик автоматизировал уже известную атаку. А вот если хочется защищаться от неизвестных атак, обеспечивая комплексную услугу, - аналитику надо самому находить атаки, анализируя неочевидные индикаторы и признаки, совокупность которых создаст подозрения, расследование которых приведет к выявлению новых, ранее не встречаемых ITW атак. Вот это - Второй сценарий, позволяющий создавать эти корреляционные правила, и далее - учить автомат самостоятельно, насколько это возможно, это детектировать и обезвреживать.

Указанные два подхода к мониторингу принципиально отличаются и, вместе с тем, прекрасно дополняют друг друга до единого целого, необходимого, в конечном счете, потребителю. Для Первого можно придумать SLA со временем реакции и временем решения, для второго - нет. Для первого важна реалтаймовая корреляция, что обычно возникает в сознании при слове "SIEM", для второго - важна возможность разнопланового анализа, структурирование в момент поиска, позволяющее одни и те же события в разное время увидеть и интерпретировать по-разному. Первый сценарий - больше operations, оперативная готовность, тогда как Второй - research, планирование и развитие. Оба сценария важны, невозможно добиться желаемого результата реализовать лишь какой-то из них, однако, Второй, как любые исследования, достаточно дорог (нужны люди, инструменты, время), а поэтому может эффективно выполняться, скорее, специализированным компаниям, уже проводящим такие исследования в рамках своей основной деятельности, и поэтому - обречен на аутсорсинг, что, на мой взгляд, - нормально.
Очевидно, что Hunting, применяемый к угрозам ITW, а полученные сигнатуры - к угрозам на данном конкретном предприятии, дает значительно меньший эффект, чем сценарий, когда весь исследовательский потенциал специализированного аутсорсера направлен на Hunting в рамках данной конкретной инфраструктуры, в результате которого созданные корреляционные правила/сигнатуры для данной конкретной инфраструктуры, - именно поэтому он интересен для понимающего заказчика. Hunting атак ITW, сопряженный с Alerting-ом в конкретном предприятии можно сравнить со стрельбой вслепую - если везет, то по направлению предполагаемого противника, тогда как Hunting по данной конкретной инфраструктуре в совокупности с Alerting-ом по ней же, аналогичен прицельному снайперскому огню, эффективность которого, безусловно, выше.

No comments: