Sunday, November 27, 2016

Attack Kill Chain

Очевидна необходимость анализа компьютерных атак с позиции Cyber Kill Chain. Как минимум, полезно самим увидеть на каких этапах происходит детектирование - отсюда можно сделать выводы об эффективности тех или иных типов средств защиты информации (превентивных, детективных и т.п.), об эффективности конкретных систем безопасности.
Сама идея - превосходна и стадии, в общем-то правильные, однако, с точки зрения корпоративного мониторинга, как правило, действующего без поддержки всеобъемлющего Threat intelligence-а (в совокупности с телепатией), позволяющего узнавать об атаке практически сразу как о ней подумал атакующий (действительно, едва ли я смогу задетектить атаку на этапе Weapoization, а этап Delivery настолько краткосрочен, что его можно совместить с Exploitaion без ущерба для идеи; а  с другой стороны упущена необходимость атакующему "осмотреться внутри, куда он попал", "повысить свои привилегии" - когда для достижения целей надо быть админом, а проэксплуатировав периметр удалось стать лишь рядовым сотрудником Бухгалтерии). К сожалению, в подавляющем большинстве случаев, об атаке мы узнаем когда нас уже начали атаковывать, или, хотя бы, активно инвентаризировать.
Поэтому, вынужден позволить себе переписать стадии Kill Chain на более, на мой взгляд, приближенные к практике обнаружения атак.

Recon - первоначальная рекогносцировка. Здесь имеется в виду, что меня пассивно (можно заметить только Threat Intelligence-ом) или активно (можно увидеть, например, сканирования) исследуют, чтобы найти потенциально удачные для атаки уязвимые места.
Initial compromise - атакующий эксплуатирует обнаруженную на этапе Recon уязвимость. Это может быть эксплоит, эксплуатирующий техническую уязвимость в применяемом у меня ПО, или социальная инженерия, эксплуатирующие уязвимости в моей программе повышения осведомленности.
Persistence establishment - успешно проэксплуатировав уязвимость, атакующему надо закрепиться в моей инфраструктуре. Здесь можно обнаруживать записи в autoruns, планировщики задач, исталляцию сервисов и пр. техники. 
Privileges escalation - повышение привилегий - также неотъемлемый этап атаки, в рамках которого можно обнаруживать попытки неавторизованного доступа, применение инструментов, атакующих аутентификационные данные и т.п. Этап будет выполняться атакующим, например, для обеспечения lateral movement или обеспечения дополнительных возможностей для достижения конечных целей атаки.
Internal recon - получив возможность перемещения по сети, атакующий ищет свою конечную цель. Здесь можно наблюдать внутренние сканирования, выполняемые уже закрепившимся и получившим необходимый доступ атакующим.
Post-exploitation - когда все сложности преодолены и атакующему остается только реализовывать свою конечную цель атаки. Здесь можно наблюдать уже какие-то сливы данных, исполнение команд, полученных с C&C, а может, и участие в DDOS или майнинг Bitcoin-ов, и т.п.






Saturday, November 19, 2016

Как реализовать требования ИБ и не потерять внутреннюю свободу @ZN2016

Вместе с Наташей рассказывали как, оставаясь человеком, контролировать исполнение требований ИБ.
По ходу прощупывали почву для следующих докладов на тему мониторинга инфраструктуры.
Постарались рассказать, что в условиях, когда требования бизнеса первичны, безопасность может существовать и не мешать бежать, но помогать сохранять.


Сам себе Threat hunter @ZN2016

Как обещал на BIS Summit-е на ZN рассказали техническую составляющую тематики Threat Hunting-а, с позиции как это можно сделать самому, при остром нежелании (или отсутствии возможности) приобретения полноценного коммерческого сервиса.
В докладе были затронуты сначала теоретико-процессная сторона вопроса, затем подробно рассказано о собранном лабораторном стенде и, в заключении, продемонстрирован наглядный пример расследования целевой спам-рассылки с последующей эксплуатацией.
Презентация:


Все конфиги: https://github.com/votadlos/ZN2016

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






Friday, October 14, 2016

IoNA: ADS офисных приложений

Полезно следить за ADS.

Подозрительные с первого взгляда ADS вида "c:\programdata\temp:58a5270d", создаваемые офисными приложениями powerpnt.exe, winword.exe, excel.exe - нормальная активность, если имеет место использование ПО Office Tab.

Monday, October 10, 2016

Охота на угрозы @BIS SUMMIT

23.09 на конференции за 20 минут знакомил аудиторию с проблематикой Threat hunting-а. Тема обширная, говорить о ней можно значительно дольше, поэтому в отведенный тайм-слот имел цель донести почему это нужно и важно. 
Основная мысль презентации выражается примерно в следующем. 
Для того, чтобы сделать сигнатуру защиты от угрозы, необходимо эту угрозу сначала найти и проанализировать. Традиционно компании, занимающиеся исследования в области ИБ и предоставляющие своим клиентам защиту от угроз, вынуждены искать их in the wild. В случае APT поиск ITW зачастую невозможен (ну, как минимум, не очень эффективен), так как ВПО и прочие TTP, используемые в APT-кампаниях отличаются высокой кастомизацией. Именно поэтому для защиты корпорации от кастомизированных атак, необходимо уметь искать угрозы (== Threat hunting) не ITW, а непосредственно в корпоративной инфраструктуре. ТН не является простой задачей, поскольку для этого нужны специализированные инструменты, процессы, опытный персонал. Понятно, что компания, занимающаяся поиском угроз ITW и обеспечивающая для своих продуктов удовлетворительное качество обнаружения/зашиты, сконцентрировав всю мощь своего ТН на конкретной инфраструктуре конкретного предприятия, покажет еще больший Detect rate, ибо законы сохранения работают и здесь: с уменьшением объема анализа, уровень выявления повышается.
К сожалению, природа Человека такова, что ему сложно верить в то, что он понимает плохо, поэтому в презентацию были добавлены несколько тяжелых слайдов о том, как работает ТН изнутри в надежде на то, что эта вершина айсберга будет иметь положительный эффект: усилит веру в ТН и, в то же время, не загрузит окончательно, создав противоположный эффект в виде отвращения.
В завершение были приведены пара обфусцированных случаев из практики - как они были обнаружены и расследованы, несмотря на то, что в одном вовсе не применялось ВПО, а в другом использовались образцы, не обнаруживаемые на момент проведения расследования.
Я искренне надеюсь, что мне удалось просто рассказать о сложном - еще со времен института я считаю эту способность наивысшей добродетелью преподавателя, так как именно это способствует разжиганию того самого интереса аудитории, на котором впоследствии можно добиться небывалых результатов в понимании предметной области. 


Saturday, October 8, 2016

Классификация инцидентов

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

С операционной точки зрения пользой может быть тот самый "triage", необходимый для приоритезации усилий, а при постфактумном анализе, скажем, за квартал, - поможет понять сколько инцидентов какой Критичности, или, если хотите, Приоритета, у меня было за период, чтобы планировать ресурсы на мой Incident Response в будущие периоды более осмысленно, чем ППП.

Проблема всех попадающихся в Google классификаций в том, что они нередко дают противоречивые результаты, что позволяет одному аналитику получить уровень High, другому - Low, и при этом каждому быть правым. Вот давайте попробуем по этому классифицировать это. Если это просто малварь, тогда - Low-Medium, если же это APT, то надо считать High. Причем, все еще интереснее, так как пока это не было исследовано - это было APT, а когда это разобрали и добавили детекты - это уже обычное ВПО :), но не будем этим загружаться.

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

И вот что получилось.

Ущерб
Фактический
Потенциально большой
Потенциально небольшой
Тип инцидента
APT
CRITICAL
HIGH

Сетевая атака
HIGH
MEDIUM
LOW
Malware: Trojan, Criptor, etc
Запущено /активно
MEDIUM
Не запущено /неактивно

MEDIUM
LOW
Scan, Misuse, Configuration error
Adware, Riskware, Potentially unwanted program


Если у вас что-то серьезное (APT или по вам шарятся какие-то неэтичные ребята), то это -  HIGH, если предполагается наличие CRITICAL, то должен быть подтвержденный ущерб.
Если у вас просто новая недектируемая (т.к. детектируемую просто убьет антивирус) малвара - MEDIUM, но если она успела натворить Ущерб - надо повышать до HIGH.
Если ошибки пользователей или админов имеют потенциально большой ущерб - это MEDIUM, сюда же можно отнести какие-нибудь рекогносцировки неэтичных ребят, так как они еще не успели начать работать. Если же ущерб небольшой - это LOW. Я не стал рисовать, Misuse с фактическим ущербом, который надо бы классифицировать как HIGH, ибо склонен считать, что админы и пользователи у нас с вами достаточно профессиональны.
Если вы нашли ПО, которое не имеет вредоносного функционала, а просто нежелательно - это LOW.



Monday, July 25, 2016

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

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

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

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