Много последнее время шума об APT почему-то. Наверно, кому-то это надо. Лично мое убеждение, что коммерческой компании, не занимающейся ИБ, вообще бороться с этим не надо, поскольку "типовых" мероприятий обеспечения ИБ точно будет недостаточно, а "не типовые" - во-первых - экономически нецелесообразны, во-вторых - их тяжело угадать. Тут ровно та же история, что 0-day. На вопрос: "Как вы боретесь с 0-day", я отвечаю: "Никак!". Все разумное, что я могу сделать - дождаться патча от вендора, на что я влиять не могу, а значит это не стоит моих усилий.Есть, правда, одна очень важная разница: 0-day - проблема общества, тогда как APT - исключительно ваша. Тем не менее, я склонен считать, что наиболее эффективная борьба с APT лежит вне плоскости технической информационной безопасности. Подобные атаки следует расследовать, прогнозировать заблаговременно, действовать проактивно, ну а если судьба, - то вкладываться в BCP и DRP .
Собственно, мне и писать-то об этом не хотелось, но прочитав очередную статью , почему-то захотелось ее прокомментировать. Наверно правильно, что статья популяризует "типовые" мероприятия обеспечения безопасности (за что автору следует сказать: "Спасибо", но неправильно, что автор утверждает, что этого достаточно.
Итак, по тексту. Я буду давать в "кавычках" курсивом начало фрагмента к которому относятся мысли. Просто начало фрагмента без каких-либо попыток "выкусить" из контекста и прочих дурных помыслов.
"Первый способ - сотруднику компании присылается письмо с документом...."
О Первом способе или 0-day vs. 1-day - традиционно про патчи. Могу с уверенностью предположить, что ни одна коммерческая компания не ставит обновления сразу как они возникли, так как а) экономически не целесообразно делать это каждый месяц, так как б) надо тщательно тестировать со всей прикладухой, коей может быть очень много. Поэтому этот вектор всегда работает.
"Также ошибочным оказалось распространенное суждение о том, что альтернативные платформы защищены от подобных атак и практически неуязвимы....."
Об альтернативной платформе. Очевидно, что эксплуатируют то, что популярно. Много ли у нас десктопов с Debian на борту? Мало, так вот => а) их эксплуатировать не рентабельно, б) даже если и есть успешные компрометации – шума мало, так как, банально, пользователей мало, => может, до нас и не долетает.
"Второй способ – атаки на внешние сервисы, такие как сайт компании...."
О втором способе – см. первый способ. Снова о патчах, которые надо ставить. Не надо думать, что на серверах они ставятся лучше чем на десктопах. Тут та же проблема с необходимостью тестирования, только риск больше: если после патчевания встанет десктоп бухгалтера ущерб значительно меньше, чем если встанет внешний почтовый шлюз или интернет-представительство Компании. Отчасти для соблюдения этого баланса между необходимостью регулярно обновляться и экономической невозможностью это делать, можно использовать "навесные" системы безопасности, типа HIPS и т.п.
О втором способе – см. первый способ. Снова о патчах, которые надо ставить. Не надо думать, что на серверах они ставятся лучше чем на десктопах. Тут та же проблема с необходимостью тестирования, только риск больше: если после патчевания встанет десктоп бухгалтера ущерб значительно меньше, чем если встанет внешний почтовый шлюз или интернет-представительство Компании. Отчасти для соблюдения этого баланса между необходимостью регулярно обновляться и экономической невозможностью это делать, можно использовать "навесные" системы безопасности, типа HIPS и т.п.
"Так, существенной преградой на пути APT является отказ от работы пользователей с привилегиями локального администратора..."
Про отказ от административных прав. Получение непривилегированного доступа – тоже уже много, так как а) зловред можно запускать от пользователя и поставить в профиль, б) известно куча уязвимостей повышения привилегий как 0-, так и 1-day (вспоминаем Никиту Тараканова ), причем в нотации Micosoft – они не Critical (обычно - Important), т.е. они не в первом эшелоне патчевания =>, помноженное на нерентабельность патчевания и его запазывание, получаем достаточно большое exposure.
"Но предпочтительным остается быстрое обновление всего ПО, установленного на ПК, серверах организации..."
С ПО от третьих сторон – вообще кошмар, говорить об этом не будем. Согласен.
С ПО от третьих сторон – вообще кошмар, говорить об этом не будем. Согласен.
"Как я писал в предыдущем посте, после того как злоумышленники закрепились на одной из ваших систем они попытаются собирать хеши паролей пользователей организации...."
Про дамп хешей – это снова про административные права – см выше. Можно повышать привилегии, что снова сводится к патчеванию.
Про дамп хешей – это снова про административные права – см выше. Можно повышать привилегии, что снова сводится к патчеванию.
"На этом этапе ваши системы аудита могут заметить огромное количество соединений между системами, которые ранее очень редко общались друг с другом..."
Про соединения между системами, которые раньше не общались. По началу я это не понял, поскольку одним из объектов моей атаки всегда будет контроллер домена, а если мы вспомним как работает протокол Kerberos , поймем, что любое внутридоменное общение порождает трафик на контроллер домена => тарфик с любого доменного объекта на контроллер домена не будет подозрительным. Про хонипоты – идея хорошая. Из практики - на одном из аудитов, аудитор не сразу понял, что радостно ломает подставу :-), а время тикало, и IDS не спала :-)
"Согласно исследованию большинство вредоносного ПО, контролируемого снаружи, попытается связаться с контрольным центром в первую же минуту после установки и затем регулярно повторяет попытки..."
Про C&C да, согласен. Традиционно все боты стремятся куда-то в blackhole-ы, которые неплохо заметны по банальным логам HTTP-прокси . Но, хочу добавить, что известны зловреды использующие всякие ICQ/AOL/Jabber/Skype для управления и транспорта данных. Хорошо, если они не шифрованы, но если там Skype – разобраться нет шансов. Мораль – банально запрещать, но бизнес хочет…
Про 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.
С сегментированием все понятно, а вот про грамотную структуру доменов - нет. Порекомендуйте рекомендации! На моей памяти сначала хорошей практикой являлось много доменов в одном лесу, потом – единый домен в пустом лесу. Как правильно-то?
Про 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, усиливайте меры там, где ожидается удар.... или вкладывайтесь в восстановление после возможных сбоев. Тут уже исключительно техническими средствами обеспечения ИБ не обойтись.
Пожалуйста, критикуйте меня, если я тут где-то неправ!
