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, ибо законы сохранения работают и здесь: с уменьшением объема анализа, уровень выявления повышается.
К сожалению, природа Человека такова, что ему сложно верить в то, что он понимает плохо, поэтому в презентацию были добавлены несколько тяжелых слайдов о том, как работает ТН изнутри в надежде на то, что эта вершина айсберга будет иметь положительный эффект: усилит веру в ТН и, в то же время, не загрузит окончательно, создав противоположный эффект в виде отвращения.
В завершение были приведены пара обфусцированных случаев из практики - как они были обнаружены и расследованы, несмотря на то, что в одном вовсе не применялось ВПО, а в другом использовались образцы, не обнаруживаемые на момент проведения расследования.
Я искренне надеюсь, что мне удалось просто рассказать о сложном - еще со времен института я считаю эту способность наивысшей добродетелью преподавателя, так как именно это способствует разжиганию того самого интереса аудитории, на котором впоследствии можно добиться небывалых результатов в понимании предметной области. 

Update 31.03.2017
1. Выкладываю презентацию

2. Про то же самое еще есть статья в журнале БДИ.


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.