Showing posts with label Security Incidents. Show all posts
Showing posts with label Security Incidents. Show all posts

Sunday, December 25, 2016

Полечить нельзя форенсить

Наверно, многим читателям этот пост покажется очевидным баяном, однако, к сожалению, мой опыт общения с разными людьми не позволяет утверждать это с уверенностью, поэтому вынужден в очередной раз прибегнуть к созданию поста, который в дальнейшем можно будет давать ссылкой и не тратить много времени на объяснения.

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

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

Но бывает и иной сценарий - ВПО является кастомизированным инструментом проведения атаки. Тут миллион различных вариантов, но принципиально, что в этом случае за атакой стоит целеустремленный человек, который в случае неуспеха будет пробиваться до последнего, пока цель не будет достигнута. Здесь хорошим сравнением может служить команда пентестеров, которая рано или поздно совершит успешный взлом через тот или иной вектор. Вот это и есть "Целевая атака".

При расследовании инцидентов ИБ принципиально отличать "Обычную малвару" от "Целевой атаки", поскольку принципиально различная реакция требуется.

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

А вот с целевой атакой все наоборот, - обнаружив какой ее компонент просто детектить ее нельзя. Помним, что за ней стоят конкретные люди, которые превосходят в технических познаниях и возможностях нас с вами, бумажных интерпрайзных безопасников, голова которых забита космосом про СУИБ, governance и пр., безусловно, важными вещами, но, как правило, далекими от практической стороны вопроса, - заметив, что мы их стали детектить - они сменят тактику\инструменты\процедуры и мы снова будем вынуждены их искать, или надежно уничтожат свои следы и мы не сможем их исследовать, или обидятся и что-нибудь нам поломают - мы же пока еще не знаем как глубоко они в нас попали и какие у них есть возможности по управлению нашими системами, как они закрепились и т.п. В случае целевой атаки надо проводить полноценное расследование, получить ответы, как минимум, на следующие вопросы:
- как они получают к нам доступ, как осуществляется контроль со стороны атакующего, как устроена С&C, как передаются данные;
- как они к нам попали (вектор проникновения);
- все стадии атаки (для затруднения расследования, уничтожения следов, а также множества других плюсов с т.з. разработки атаки, применяются многоступенчатые комбинации, когда одно [В]ПО запускает другое [В]ПО, которое надежно удаляет первое, которое запускает третье и т.п.);
- какие инструменты они используют, и как все эти компоненты работают совместно, управляются;
- как и где они закрепились, как реализовано обеспечение высокой доступности инфраструктуры атаки (плохие ребята, безусловно, готовы к тому, что их когда-то начнут детектить, поэтому у них есть миллион вариантов, как обеспечить живучесть своей атаки - многократное закрепление с использованием различных техник, взаимный контроль закрепления - сервисы которые поднимают друг друга и перепрописывают правильные слова в конфигах и реестре в т.ч. и по сети и т.п.)

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

Я люблю для пояснения использовать аналогии - здесь подходит аналогия с захватом ОПГ. Чтобы затем не гоняться за ее участниками, каждый из которых может собрать по такой же ОПГ, что явно прибавит работы и увеличит ущерб, лучше придумать как накрыть всех сразу.

"Все здорово", - скажете вы, - "но как же отличить "целевую атаку" от "обычной малвары"? Наверно, и в этом случае отвечать пришлось бы очень долго, однако накидаю первые пришедшие на мысли:
- анализ найденного ВПО - в случае целевой атаки процесс будет превышать одну итерацию: нашел подозрительный образец, отреверсили, достали из него IoC-и (какие-то связанные компоненты, какие-то конфиги, ветки реестра, адреса С&С - да что угодно, по чему можно поискать и быть уверенным, что найденное будет относиться к нашему кейсу), поискали данные IoC-и по всей нашей сети, нашли еще файлы, компьютеры - их тоже отреверсили\отфоренсили, вытащили новые IoC-и - поискали уже по ним и т.п.;
- установленный функционал - что файлик делает, понятно ли вообще на текущем этапе его назначение;
- популярность - видели ли это где-нибудь когда-нибудь у кого-либо раньше;
- пересечения по имеющемуся Threat intelligence - может, что-то совпадает по C&C, по хешам компонент, по поведенческим сигнатурам, по любым другим IoC-ам и атрибутам атаки.

Буквально пару слов про атаки без применения ВПО (возможно, об этом надо отдельно написать поподробнее). Такие атаки находятся исключительно по поведению в тесной коммуникации с владельцем инфраструктуры, ибо здесь без "situational awareness" не обойтись - отличить легитимное использование psexec, teamviewer или powershell-скрипта, запускаемого из Word-а от нелигитимного, к сожалению, можно только спросив. В большинстве случаев нелегальных действий без применения ВПО мы будем иметь дело с целевой атакой.

В заключение, приведу простую последовательность действий (эдакий дайджест из всего, что я выше написал):
1. Если вы что-то обнаружили - начинаем строить цепочку расследования: (то, что обнаружили) -> IoC1 -> (то, что нашли по IoC1) -> IoC2 -> (то, что нашли по IoC2) -> ... .
2. Если цепочка закончилась на том, что обнаружили (нет связных компонентов, функционал понятен и т.п.) - можно просто продетектить\пролечить, как  yet another malware и закрыть инцидент.
3. Если цепочка длинная, то надо пройти ее до конца, вытащив всю информацию об атаке, достаточную для того, чтобы накрыть всех сразу.
4. Придумать как накрыть всех сразу и сделать это.
5. Придумать как защититься в будущем.


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.



Friday, August 26, 2011

эффективность против порядка

Вы отвечаете за защиту периферии в компании. Написали множество регламентов, просматриваете журналы, проводите занятия и тп.

В компании стоит... ну скажем 1000 компьютеров, мышками которых возит 1000 сотрудников. Для ремонта мышек и их подключения, в компании создана служба технической поддержки из нескольких сотрудников.

У сотрудника возникают проблемы с мышкой во момент Х.

Так как мышки ломаются не чаще раза в 2 года, сотрудник втечение Х1 единиц времени думает, как решить проблему, стучит мышкой по столу, смотрит в красный глаз, курит, снова стучит и наконец, в соответствии с регламентом, звонит на телефон 22232232 (читать с выражением) и сообщает о сути проблемы.

Телефонная сотрудница регистрирует заявку в "электронной системе электронных заявок" которая электронно, по электронной почте сообщает сотрудникам технической поддержки о возникновении проблемы.

Через время Х2 сотрудник технической поддержки обращает внимание на сообщение и откладывает его в пачку сообщений, которые предполагают поход в одно крыло здания.

Спустя Х3 единиц времени он выходит в направлении неисправной мышки и спустя Х4 единиц, он ситуацию исправляет.

Итого, на устранение неисправности ушло Х1+Х2+Х3+Х4 единиц времени. В реальной жизни это время составляет от пары часов до пары дней. Все это время сотрудник сидит и полукоматозном состоянии изучает символы на клавиатуре, сообщая руководству о невозможности исполнения служебных обязанностей.

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

Наступает момент Х, мышь у этого человека ломается! Или он регулярно находит способы сделать мышь лучше и быстрее! Или еще хуже, он делает заявки и получает форсированные мыши 1го, затем 2го и, наконец ,7го поколения с азотным ускорителем.

В первый раз он звонит на волшебный номер и ждет в течение Х2+Х3+Х4 человека, которому компания доверила техническое обслуживание мышей. Но начальство нервничает, ведь оно привыкло видеть отдачу от сотрудника.

Во второй раз и третий недовольство руководства растет....

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

О, ужас! Он не звонит в техническую поддержку, он не ловит системотехника в коридоре за руку! Он.... Как трудно сдержать гнев! Он нарушает стандарт утвержденный руководителем компании! Он, он... Он сам переподключил мышь! Коллеги в шоке, но они понимают - все это во благо компании!

А радары службы безопасности не зря потребляют электроны один за другим. Они сигнализируют красными лампами и зуммерами о нарушении, маркируя нарушителя несмываемой краской!

И вот комиссия из 3-х сотрудников сметая все на своем пути мчится к месту проступка. Нарушение будет задокументировано, нарушитель брошен в казематы, руководство уведомлено о нарушении и высокой степени эффективности новых красных ламп приобретенных взамен старых зеленых.

Вроде все хорошо:

  1. Нарушитель пойман и наказан
  2. Лампы сработали
  3. Системотехники не будут мучаться с нестандартными мышами и их труд по замене стандартных девайсов будет проще и дешевле
  4. Служба безопасности получает медали и премии
  5. Руководство спит спокойно, зная, что компания в теплых и сильных руках службы безопасности.
  6. Выпущена молния, в которой описана темная дорога нарушителя, а так же условия его нынешнего содержания.

Но откуда-то появляется кисловатый привкус:

  1. Средняя эффективность использования мышей упала
  2. Сотрудники стараются не отклоняться от утвержденных траекторий движения
  3. Сломанных мышей начинают бояться и на всякий случай отправляют в неоплачиваемый отпуск их пользователей.

Friday, July 18, 2008

Среднестатистический участник инцидента по ИБ

Анализируя статистику инцидентов по ИБ, за последний год я пришел к интересному наблюдению об уровне «просвещенности» по вопросам ИБ наиболее частого нарушителя. Странно, но следующая мысль была о целесообразности просвещения по вопросам ИБ вообще. Тем, не менее, я все же позволю себе не согласиться с Ранумом относительно полной ненужности просвещения по вопросам ИБ, поскольку, как мне кажется, – это единственное, что мы можем сделать, и не стоит от этого отказываться.

Но, ближе к делу. Я пришел к выводу, что «компьютерно низко образованные» сотрудники, как это не странно, как правило, не являются причиной инцидентов ИБ.

В свою очередь, высококвалифицированные сотрудники подразделений ИТ и ИБ, также не замечались часто в инцидентах.

Если с профессионалами все понятно, то «феномен низкообразованных» я пытаюсь объяснить тем, что недостаточные знания являются ингибитором любопытства и излишней самоуверенности.

Именно «средние компьютерно пресвященные» сотрудники являются наиболее частыми участниками инцидентов в области ИБ. Как мне кажется, здесь мы имеем дело с «синдромом опытного водителя» – когда есть некие навыки, дающие избыточную уверенность в своих возможностях, а также желание «познать неизведанное», «испробовать неиспробованное», «побывать там, где никто не бывал», пр.