Monday, July 25, 2016

Сигнатурные и Контекстные ложные срабатывания

Все в этом мире относительно. Именно поэтому для результативности безопасности нам важен контекст, поскольку технологические сигнатуры (не важно на что: на конкретный файл или на последовательность действий) производителем СЗИ выпускаются на среднестатистическую ситуацию, которая может быть сильно различна от инфраструктуры к инфраструктуре. В качестве иллюстрации можно привести сигнатуры на отстуки по C2 ботнетов - это безусловно нехороший знак для рабочих станций рядовых сотрудников HR или бухгалтерии, однако, это вполне может быть ОК для сотрудников подразделений RnD, исследующих ботсети, и для них фиксируемые алерты в контексте конкретной ситуации вполне могут быть ложными срабатываниями. Важным моментом здесь является то, что технологически сигнатура отработала корректно и мячик находится уже на стороне адаптации решения к конкретной среде. Перевод СЗИ из дефолтной конфигурации в адаптированную для конкретной инфраструктуры - очевидная вещь о которой много написано, и сегодня не про это (хотя, в моей практике были комичные случаи, когда я так и не смог убедить в необходимости конфигурирования СЗИ из коробки :) - поэтому, если в необходимости адаптации под свою сеть есть сомнения - этому можно посветить отдельный пост).

Ложные срабатывания косвенно характеризуют качество СЗИ. Поэтому разумно желание отличать ложные срабатывания по причине того, что сигнатура СЗИ работает неправильно - сигнатурные ложные срабатывания от ложных срабатываний ввиду особенностей контекста инфраструктуры - контекстных/инфраструктурных ложных срабатываний. Несомненно, можно придумать еще более ветвистую классификацию, однако, не надо забывать о практическом смысле, дополнительных трудозатрат по учету, поэтому, думаю, на первое время этих двух ложных срабатываний вполне достаточно.

Таким образом получаем, что сигнатурные ложные срабатывания позволяют судить о качестве инструмента, т.е. характеризует работу производителя, а контекстные ложные срабатывания - характеризуют работу подразделений ИБ по интеграции инструмента в конкретную инфраструктуру и степень оперативности учета ее изменений в конфигурации СЗИ. Последовательность действий, направленная на снижение этих двух видов ложных срабатываний, различна, а, следовательно, имеет смысл их отличать.

Wednesday, July 13, 2016

IoNA: Сетевой трафик winlogon

Рассуждая о безопасности мы часто упоминаем индикаторы компрометации - все те же сигнатуры, все то же перечисление зла. Однако, для понимания происходящего, тем более для хантинга, надо не просто находить по индикаторам, а отличать "нормальное" от "подозрительного"/"не нормального" - для чего надо неплохо разбираться в том, что может быть нормальным. Имея знания о "нормальности" подход будет примитивным и, вместе с тем, вполне себе эффективным: из общего количества активностей убрали все, что "нормальны"/известны, а с оставшимися - явно ненормальными или неизвестными - разбираемся. По результатам разбора можно пополнить свой багаж знаний о "нормальности" поведения - т.е. копить не только IoC-и, но и IoNA - индикаторы нормальной активности :)

Оказывается, процесс winlogon тоже генерит сетевой трафик. Причем эта его активность не вызвана никакими инъекция зловредов в него - это его нормальная активность в случае, если у пользователя смонтированы папки WebDAV. Более того, если у вас используется WPAD, то winlogon пойдет сначала на сервер wpad, получит настройки прокси, а затем с ними устремится подключать шары. Если посмотреть dll-ки, подгруженные в winlogon, демонстрирующий такое поведение, то там можно будет обнаружить компоненты Internet Explorer%SYSTEMROOT%\system32\urlmon.dll, %SYSTEMROOT%\system32\iertutil.dll, %SYSTEMROOT%\system32\WININET.dll, %SYSTEMROOT%\system32\jsproxy.dll. Сетевой трафик от winlogon можно наблюдать в момент входа пользователя в Windows (== момент подключения сетевых папок WebDAV).

Таким образом, наш IoNA выглядит так:
1. Сетевой трафик (WPAD - если есть, HTTP - на сервер с папкой WebDAV) от легитимного процесса winlogon.exe.
2. Подгруженные в winlogon библиотеки IE.
3. У пользователя подключена сетевая папка WebDAV.

В заключение хочется отметить, что это нормальное поведение может являться неплохим вектором атаки на winlogon, - уже как на клиента Интернет... - время покажет.

Thursday, July 7, 2016

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

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

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

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

Monday, May 30, 2016

Новые методы эксплуатации инъекций в ORM

27.05 мне в очередной раз посчастливилось выступать на HITB@AMS. Даю ссылку на нашу презу. Также она доступна на сайте конференции. Этот доклад - продолжение темы, подсвеченной на ZN, но более расширенное и углубленное. Заниматься этим подстегивало весьма незначительное количество публикаций по теме, надеемся, нам удастся, хотя бы частично, заполнить этот информационный вакуум.



Как обычно, в нашем докладе были демки, которые традиционно доступны на YouTube у Миши, ссылки на видео есть на слайдах презентации, дублирую здесь:
Exploiting JPQL injection against EclipseLink ORM
Exploiting HQL injection against Hibernate ORM with Unicode method
Exploiting HQL injection against Hibernate ORM with Java Constants method

После доклада был вопрос, на котором стоит также остановиться: "Как находить такие инъекции?" Они находятся также как и обычные SQLi, однако, в отличии от них они эксплуатируются несколько иначе. Собственно, доклад как раз о том, как такие инъекции эксплуатировать - предложены методы, которыми можно пользоваться в зависимости от комбинации СУБД-ORM - см таблицу на слайде 81.


Thursday, May 12, 2016

Хонипоты в интерпрайзе

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

Я много игрался с хонипотами, но потребность в них по-прежнему не очевидна. Просматриваются две основные идеи их применения. Во-первых, это может замедлить потенциальную атаку, о чем с некоторой подменой смысла повествовалось в статье уважаемого института. Однако, беря во внимание первый абзац этого поста, если мы имеем дело с "типовой" атакой, мои "стандартные" средства защиты прекрасно с этим справятся и без хонипота. Если же мы имеем дело с профессиональной атакой, то такой злоумышлениик раскусит наш хонипот за время, едва ли имеющее важное значение в общем таймлайне атаки. В этом случае, эффективность хонипота сводится к эффективности стандартной IDS - просто обнаружить то, с чем далее надо разбираться. Следует признаться, что когда в Амстердаме мы показывали видео про то, как ловить "хакеров" с помощью kippo, народ в зале отметил, что демонстрируемое поведение позволяет судить о далеко не высоком профессионализме атакующего. Если же мы будем разворачивать более хорошую эмуляцию (high-interaction honeypots), то это - полноценная новая система, которая, по Закону сохранения, утянет ресурсы, которые было бы куда более разумно потратить на обеспечение безопасности реальных информационных активов. Итого, от сложных неизвестных атак мы этим не защитимся, от известных - поможет "антивирус" (далее буду использовать как собирательный образ типовых привентивных технических средств обеспечения безопасности).

Второй задачей, решаемой хонипотом, обычно называют возможность исследования атаки: пока злоумышленник понимает, что он атакует хонипот, мы собираем эвиденс, который позволяет нам расследовать что происходит. Понятно, что едва ли нужно расследовать типовые атаки, где "антивирус" все заблокирует... Однако, хонипот не нужен и для сложных атак, поскольку, а) как было отмечено выше, его быстро раскусят, б) в случае необходимости расследования сложной целевой атаки у нас есть неотъемлемый "хонипот" - вся наша инфраструктура и приложения. Поэтому не надо сразу кидаться все вычищать, надо сначала понаблюдать и разобраться - это позволит избежать потенциальных проблем и радикально повысить эффективность вашего респонса. Об этом пишут все умные книжки про Incident response и об этом же говорил коллега в презентации (шикарная, на мой взгляд преза, полезно ознакомиться) - прежде чем кидаться в бой, надо максимально изучить противника (ну, безусловно, надо смотреть по обстоятельствам, не надо злоупотреблять "созерцанием и ничего не деланием", никогда не надо перегибать палку, красота - посередине). Итого, для исследования сложных атак в интерпрайзе хонипот тоже не нужен, так как все самое нужное и актуальное можно собраться собственно с защищаемой сети. А для "типовых" атак - достаточно, что хонипоты или любые другие подобные эмуляторы есть у производителей систем "антивирусов", которые я использую, и они регулярно и своевременно поставляют мне сигнатуры, защищающие меня от ~99% зла. 

Tuesday, April 19, 2016

Соответствие Спроса и Предложения

Так сложилось, что сегодня, общаясь с приятелями, я в разном контексте и абсолютно от разных людей услышал, по сути, один вопрос - почему, несмотря на то, что мы все тут CISO встречаемся и, вроде как, друг друга понимаем, читаем одни и те же книжки, однако, как правило, на предприятии все наоборот: культивируем перегибы, охотимся на ведьм, осваиваем бюджеты, вместо решения конкретных задач... - в общем, делаем типовые действия по инерции, ошибочность которых вполне очевидна. Я не раз утверждал, что Умный учится на своих ошибках, и поэтому не отвергаю необходимость хождения по граблям, однако, сколько же можно делать одно и то же!? А ответ прост - столько, сколько соответствует нашему пониманию. К сожалению, единственный инструмент дифференциации "правильно" от "неправильно" - это наше понимание действительности, этакая наша собственная Модель зрелости. Говоря максимально предметно: чтобы понимать, что "правильно" - это  на самом деле правильно ("правильно" - то, что лучше адаптировано к фактической действительности), нужно иметь определенную Модель зрелости, наша Модель зрелости - характеризует нашу способность выбирать из возможных вариантов развития наиболее правильный. В целом, это то же, что опыт и профессионализм, однако мысль поста - другая, а именно - для осознания действительной необходимости того  или иного продукта (не важно, будь то коробка или сервис) нужно иметь определенную Модель зрелости. Не достигнув определенной модели зрелости мы не будем в состоянии выбрать правильный продукт, а если даже выберем, мы не сможем его использовать эффективно. Как не странно на первый взгляд, второй исход для производителя еще более неудачен - его продукт будет неэффективен и никто не будет разбираться в причинно-следственной связи о том, что его не умеют использовать, или используют неправильно, или не использую вовсе. Тень неудачи продукта в конкретном случае упадет на производителя и мы получим эффект отсутствующей плитки.

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

Ровно также и в жизни: чтобы приобретать эффективные продукты (сервисы и\или технологии) надо, как минимум, понимать что они есть и в чем их эффективность перед другими, возможно, имеющими даже аналогичную классификацию, а дополнительно - надо уметь ими правильно пользоваться, чтобы продукт раскрывался на все 100% своего функционала, показывая максимальную эффективность и результативность. 
К сожалению, как невозможно первокласснику объяснить все преимущества производной, так и безопаснику на определенном уровне своей Модели зрелости невозможно объяснить необходимость того или иного продукта. Очень важно понимать, что это и не хорошо и не плохо. Очевидно, почему это плохо, - потому что действительно качественные решения остаются аутсайдерами, поскольку способность понимания этого качества предъявляет определенные требования к потребителю, который действительно должен быть профессионалом. Но это и не плохо, поскольку, как я отмечал выше, профессиональный инструмент в неумелых руках, как минимум, не приносит ожидаемого эффекта (что плохо для производителя!!), а, как максимум, может сотворить беду, поэтому пускай лучше автоматом пользуется тот, кто умеет из него стрелять, а мартышка никогда не примеряет очки.
Еще один важный момент для понимания, что, как правило, руководитель имеет команду, соответствующую ему по пониманию действительности. Относительно этого поста это означает, что, как правило, и руководитель и подчиненный имеют одну Модель зрелости. Различие в Модели зрелости приведет к тому, что либо подчиненный сам уволится, потеряв надежду выровнить с собой руководство, либо руководство уволит невыравниваемого с собой подчиненного. Работающие долго команды, как правило, имеют одну Модель зрелости. Это не стоит понимать буквально, что набор предметных знаний руководителя и подчиненного одинаков, но он эквивалентен с учетом уровня позиции. Поясню проще: CEO подбирает CISO эквивалентного своей Модели зрелости в области безопасности на уровне CEO, т.е. если для CEO безопасность - это антивирус, на позицию CISO будет взят человек с таким же концептуальным пониманием, но, может быть, с более глубокими техническими знаниями, например, тот, кто был админом антивируса в бэкграунде. CISO, который будет "на другой волне" не пройдет по квалификационным требованиям, даже если он будет говорить правильные вещи, очевидные с точки зрения более высокого уровня Модели зрелости (понятно, что под уровнем Модели зрелости здесь следует понимать степень приближенности к фактической действительности). Здесь этот несчастный, своеобразная белая ворона, может быть сравним с Гигантами прошлого, чьи изобретения и произведения искусства опережали свое время и не были по достоинству оценены при жизни авторов.
В общем, идея понятна, теперь давайте разберемся что же можно сделать творцам шедевров, чтобы потребителям, находящимся на уровне ВАЗ2106 уметь предоставлять BMW5.
1. Если вопрос себестоимости просто не стоит (понятно, что делать BMW дороже чем Жигули), то можно про BMW говорить категориями, применимыми к Жигулям. Т.е. свой высокотехнологический продукт продавать в "обертке", понятной потребителю (~махорка американская). Понятно, что для разного потребителя "обертка" будет разная. Причем здесь нет никакой лжи - это аналогично изложению на понятном языке.
2. Если вопрос себестоимости стоит, то здесь надо бить на компоненты и группировать их в пакеты, соответствующие разным Моделям зрелости. При переходе на новую Модель - предлагать новые фичи. Да, да, комплектации продуктов надо компановать не только на основе каких-то сценариев использования, но и на основе потребностей (способностей понимания, Модели зрелости) потенциального клиента. Не надо предлагать сигары тому, кто курит махорку и т.п.
3. Ну и, конечно, надо бороться с невежеством. В понятной доступной форме объяснять проблематику и рассказывать о том, как эти проблемы могут быть решены - так будет повышаться Модель зрелости потребителя, и это позволит нам всем в целом повысить среднюю Модель зрелости в отрасли и тем самым сделать Мир лучше!