Бороться с APT?

Много последнее время шума об APT почему-то. Наверно, кому-то это надо. Лично мое убеждение, что коммерческой компании, не занимающейся ИБ, вообще бороться с этим не надо, поскольку "типовых" мероприятий обеспечения ИБ точно будет недостаточно, а "не типовые" - во-первых - экономически нецелесообразны, во-вторых - их тяжело угадать. Тут ровно та же история, что 0-day. На вопрос: "Как вы боретесь с 0-day", я отвечаю: "Никак!". Все разумное, что я могу сделать - дождаться патча от вендора, на что я влиять не могу, а значит это не стоит моих усилий.Есть, правда, одна очень важная разница: 0-day - проблема общества, тогда как APT - исключительно ваша. Тем не менее, я склонен считать, что наиболее эффективная борьба с APT лежит вне плоскости технической информационной безопасности. Подобные атаки следует расследовать, прогнозировать заблаговременно, действовать проактивно, ну а если судьба, - то вкладываться в BCP и DRP.

Собственно, мне и писать-то об этом не хотелось, но прочитав очередную статью, почему-то захотелось ее прокомментировать. Наверно правильно, что статья популяризует "типовые" мероприятия обеспечения безопасности (за что автору следует сказать: "Спасибо", но неправильно, что автор утверждает, что этого достаточно.

Итак, по тексту. Я буду давать в "кавычках" курсивом начало фрагмента к которому относятся мысли. Просто начало фрагмента без каких-либо попыток "выкусить" из контекста и прочих дурных помыслов.

"Первый способ - сотруднику компании присылается письмо с документом...."

О Первом способе или 0-day vs. 1-day - традиционно про патчи. Могу с уверенностью предположить, что ни одна коммерческая компания не ставит обновления сразу как они возникли, так как а) экономически не целесообразно делать это каждый месяц, так как б) надо тщательно тестировать со всей прикладухой, коей может быть очень много. Поэтому этот вектор всегда работает.

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

Об альтернативной платформе. Очевидно, что эксплуатируют то, что популярно. Много ли у нас десктопов с Debian на борту? Мало, так вот => а) их эксплуатировать не рентабельно, б) даже если и есть успешные компрометации – шума мало, так как, банально, пользователей мало, => может, до нас и не долетает.

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

"Так, существенной преградой на пути APT является отказ от работы пользователей с привилегиями локального администратора..."

Про отказ от административных прав. Получение непривилегированного доступа – тоже уже много, так как а) зловред можно запускать от пользователя и поставить в профиль, б) известно куча уязвимостей повышения привилегий как 0-, так и 1-day (вспоминаем Никиту Тараканова), причем в нотации Micosoft – они не Critical (обычно - Important), т.е. они не в первом эшелоне патчевания =>, помноженное на нерентабельность патчевания и его запазывание, получаем достаточно большое exposure.

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

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

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

Про соединения между системами, которые раньше не общались. По началу я это не понял, поскольку одним из объектов моей атаки всегда будет контроллер домена, а если мы вспомним как работает протокол Kerberos, поймем, что любое внутридоменное общение порождает трафик на контроллер домена => тарфик с любого доменного объекта на контроллер домена не будет подозрительным. Про хонипоты – идея хорошая. Из практики - на одном из аудитов, аудитор не сразу понял, что радостно ломает подставу :-), а время тикало, и IDS  не спала :-)

"Согласно исследованию большинство вредоносного ПО, контролируемого снаружи, попытается связаться с контрольным центром в первую же минуту после установки и затем регулярно повторяет попытки..."
Про C&C да, согласен. Традиционно все боты стремятся куда-то в blackhole-ы, которые неплохо заметны по банальным логам HTTP-прокси. Но, хочу добавить, что известны зловреды использующие всякие ICQ/AOL/Jabber/Skype для управления и транспорта данных. Хорошо, если они не шифрованы, но если там Skype – разобраться нет шансов. Мораль – банально запрещать, но бизнес хочет…

"Еще одной распространённой проблемой является отсутствие грамотной структуры доменов AD..."
С сегментированием все понятно, а вот про грамотную структуру доменов - нет. Порекомендуйте рекомендации! На моей памяти сначала хорошей практикой являлось много доменов в одном лесу, потом – единый домен в пустом лесу. Как правильно-то?
Про IPSec внутри локальной сети - наверно, я про это еще напишу - это похоронит IDS, так как эксплоиты начнут ходить внутри шифрованного туннеля и увидеть их не будет шансов, т.е. IPSec использовать - дело хорошее, но без шифрования, только для аутентификации.

Но на самом деле, как мне показалось, статья вообще не про то, поэтому и хочется ее прокомментарить. В моем искривленном понимании APT от «не APT» отличается в изначальной информированности (критикуйте меня, если я не прав!!). Это всегда WhiteBox, и в случае APT никаких «холостых выстрелов» быть не должно, если есть осечки и пробы, то просто команда подобралась непрофессиональная. Если мы рассматриваем сценарий атаки на endpoint (Первый способ, на нем и остановимся) через интернет, то в случае APT он будет выглядеть так: пользователь получит убедительное письмо от надежного адресата, с текстом, который он ожидал, он даже ожидал, что в письме будет ссылка, на которую следует нажать (если не понятен сценарий, могу дать живой пример из практики). Нажав на ссылку прилетит эксплоит, который 100% сработает в его среде (не важно, будет он 0-day или 1-day) – просто будет информация о стратегии патчевания и о том, что есть на десктопе что можно эксплуатировать. Сработавший эксплоит загрузит payload из интернет, который 100% пройдет все шлюзы и все эшелоны, так как будет точная информация о том, что какой-нибудь «shikata ga nai» гарантировано не будет правильно декодирован, а если и будет, но имеющаяся модель антивируса с текущим, известным, патчлевелом ничего не увидит (это будет оттестировано заранее!). Собранный зловред не будет сражаться с моими хонипотами и генерить нетиповой шум внутри сети для моих недремлющих IDS/IPS, а точечно атакует нужный сервер (причем опять же с учетом того, что могут увидеть мои IDS - и они не увидят!), который будет точно компрометирован по аналогии с десктопом. Будет иметься полная информация об инфраструктуре безопасности, что позволит зловреду предсказуемо долгое время оставаться незамеченным. Вот что такое APT, не все так просто!, а описанные контроли эффективно сработают против аудитора-пентестера или залетного "хакера", располагающего поверхностными знаниями об инфраструктуре, использующего "типовые" техники и инструменты, главным образом – сценарий blackbox.

Испугались? :-) Что делать? Ответ: "ничего!". Об APT достаточно знать, защищаться от этого не надо. Вернее, конечно, так (чтобы не было кривотолков, еще раз повторюсь) - если, посредством Intelligence стало известно, что атака APT реальна, то продолжайте свой Intelligence: ищите крота, выясняйте как будет проводиться APT, усиливайте меры там, где ожидается удар.... или вкладывайтесь в восстановление после возможных сбоев. Тут уже исключительно техническими средствами обеспечения ИБ не обойтись.

Пожалуйста, критикуйте меня, если я тут где-то неправ!

согласование vs возражение

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

Долго я думал над этой схемой. В интернете ничего интересного на эту тему не нашел. Изложу-ка мысли свои.

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

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

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

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

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

Может быть где-то это уже используется и у кого-то есть опыт эксплуатации такой схемы?

Конечно на пост нужно смотреть через призму работы с заявками :)

Управление заявками на коленке. Продолжение.

Продолжим.
Понятно, что набор диспетчерами заявок во вновь рожденной системе был сизифовым трудом. Поэтому была сделана небольшая веб-форма для набора заявок и пользователям под соусом ускорения обработки заявок, было предложено общаться через эту форму. В результате ее заполнения, генерировалось электронное письмо с обратным адресом диспетчерской, которое шло руководителю, указанному в форме. Руководитель в произвольном формате должен был согласовать данное письмо просто ответив на него. Дальше диспетчер копированием вводил заявку в табличку Sharepoint’а. Этот шаг был необходим по нескольким причинам:
1.    Зачастую сотрудник не знал к какому именно ресурсу (точное название) ему необходимо подключиться или формулировал заявку не верно. Поэтому диспетчер корректировал заявку.
2.    Иногда одна заявка, например «создание учетной записи», трансформировалась в несколько заявок, формирующих типовой набор прав;
3.    Банальная фильтрация «мертвых душ» и грубых ошибок заполнения.
До сих пор в электронных заявках пишется фраза "Предлагаем согласовывать заявки на предоставление доступа к информационным  ресурсам в электронном виде..."
Примерно через пол года был сформирован и заморожен актуальный список информационных ресурсов. Пользователям, сначала было рекомендовано, оформить заявку на создание информационного ресурса, с определением его параметров (опять через веб-форму). После пары недель ожидания и напоминаний, заявки на ресурсы не созданные должным образом перестали приниматься. После чего постепенно были решены все вопросы даже по ресурсам, от администрирования которых все отказывались.
Последним «усовершенствованием» оказалась заявка на блокировку учетной записи. Эта заявка должна использоваться при увольнении или переводе сотрудников. Сейчас, когда мы получаем заявку на создание учетной записи, мы просим указывать в цели подключения ФИО сотрудника, вместо которого нанят новый. Это помогло за последний год эффективно проработать механизм блокировки увольняющихся или переводящихся.

Что мы имеем в результате:
1.    все заявки за последние 4 года, с возможностью поиска и фильтрации;
2.    возможность выдать новому сотруднику все права, которые имел его предшественник;
3.    возможность выдать ИТ менеджеру все заявки оформленные сотрудниками его предприятия;
4.    актуальный, автоматически поддерживаемый, перечень информационных ресурсов;
5.    удовлетворение от проделанной работы.
Что омрачает радость:
1.    риск подделки заявок – увы, заявку может заполнить кто угодно и за кого угодно. От этого пока спасает достаточно длинная (не менее 3-х человек) цепочка согласования;
2.    риск невозможности использования заявок в случае необходимости обращения в суд;
3.    периодические попытки запустить систему, разработанную уважаемой компанией систему.

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