История неба

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

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

Сначала была большая Компания, в ней было свое подразделение ИТ, числящееся в штате Компании (упустим те времена, когда Компания была, а ИТ еще не было). Они работали прекрасно, но ....

Откуда-то прилетела весть об ITIL, о том, что он нам улучшит все, что можно улучшить, повысит все что можно положительно повысить, что создаст для бизнеса возможность двигаться в еще более светлое будущее. И кто-то решил, что отношения между подразделением ИТ и остальными надо строить по модели Подрядчик-Заказчик, когда подразделение ИТ превращается в поставщика услуг, а остальные (назовем собирательно - Бизнес) - в потребителей этих услуг. Немного покорежили терминологию: теперь хелпдеск не просто ходит по пользователям и решает проблемы, а ИТ-подразделение оказывает услугу сопровождения рабочих мест, а в целом все осталось как прежде (упустим все что негативного получилось из преобразования работы "по щелчку" в работу "по SLA"

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

Долго или коротко ли они так работали, когда ИТ не обладало своими средствами производства и происходили интересные диалоги, когда Бизнес говорил ИТ, что мне нужно такое-то бухгалтерское ПО, а ИТ заявляло, что для того, чтобы оно заработало нужно построить кучу инфраструктуры: купить и отремонтировать серверные и кроссовые, купить сетевое оборудование, все его настроить, купить кучу серверов, внедрить какой-то каталог (пусть будет MS Active Directory), ...., потом все это поддерживать.... Бизнесу нужно все эти средства амортизировать, учитывать,... какой-то Change Management, Configuration Management, .... какой кошмар! Зачем мне все это железо? Мне нужна только ERP и то, мне не важно на каком железе оно там живет и как сложно это все поддерживать, нужно только чтобы сотрудники могли там работать.... + выполнялись требования по доступности, конфиденциальности, целостности, аутентичности и т.п. И Бизнес решил вслед за людьми продать и все железо. Какая красота: не нужны эти дорогущие ЦОДы, не нужно все это железо вечно закупать, складировать, учитывать, утилизировать. Просто сказка!

Так появились Облака.


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

COA и KPA на пальцах

Памятью от PHD осталась книжка Шнаера. Купил я ее давно, прочитал тоже, а вот подписать у автора получилось только сейчас.

Ну, конечно, Брюс не упустил возможность вкрутить что-то "криптографическое".

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

Были испробованы:
- сложения букв с разными константами (циклический сдвиг),
- сложения букв со своим порядковым номером (снова сдвиг, но по-другому),
- сложения букв со словами типа "PHD", "Schneier", "2012" (тоже сдвиг)


.... для чего были сооружены нехитрые программки на C.

Собственно, что я делал - атака COA. Шифртекст - все что у меня есть.

К своему стыду, я так и не догадался почитать текст в различных направлениях!

Как и предполагалось Гугль дал ссылку. Из нее стал известен открытый текст: "Enjoy the book". Теперь я перешел в режим KPA.

Дальнейший "взлом" занял меньше секунды.

Читаем из правого верхнего угла сверху вниз по столбцам :-)

Мораль: прежде чем кидаться в сложности, посмотри внимательно задачу (сначала думаем, потом трясем!)

Mimikatz/WCE1.3 vs. MS Digest/WDigest

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

Из первоначальной RFC26117 следует, что "by design" использование аутентификации Digest требует "знание" сервером оригинала пароля. Это просто понять, если посмотреть на формулы в Википедии. Ну и Бог бы с ним, все-таки 1999 год, да и цель свою - не передавать пароль в открытом виде по сети, в отличие от Basic (хотя, при использовании SSL/TLS получается даже безопаснее, поскольку для Basic серверу достаточно знание хеша пароля) - протокол реализует.

Как отключить все эти пережитки прошлого (допустим, что я готов к последствиям), я так и не нашел. Однако, в technet-е , указано, что фичу хранения пароля в открытом виде можно отключить. Цитата:
"Digest authentication is successful only if the domain controller has a reversibly encrypted (plaintext) copy of the requesting user's password stored in Active Directory. To allow passwords to be stored in plaintext, you need to activate the Store password using the reversible encryption setting on the Account tab of the user in Active Directory. Alternatively, you can set group policy to enable this capability. After making this setting, you need to set a new password in order to activate this feature because the old password cannot be determined. "

Как этот параметр ставить и где он есть написано здесь.

Я игрался с WCE. На моей, полностью запатченной и забезопашеной Win7 wce1.3beta работала на раз: пароли доменных учеток дампились в открытом виде. Причем ее x64-версия даже не палилась антивирусом.  Единственная проблема - если в пароле есть русские буквы, пароль не показывается, пишется "<contains-non-printable-chars>" => ищу (может не так целенаправленно) исходники, готов поправить.

Важно отметить, что параметр "Store password using the reversible encryption", по-русски это выглядит так (кое-что пришлось замулевать):

 Отключен. Если я правильно понимаю что написано:

то не должен пароль дампиться, а все работает.....

Какие у кого есть предложения? Как можно обезопаситься?

Бороться с 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 для автоматизации части базовых функций по предоставлению прав. Об этом уже писал. Механизм реализации пока не прозрачен, поэтому откладывается. Заказывать новую систему, не вижу смысла, тк "молоко еще не остыло". Писать столь сложную систему самостоятельно - нет времени и желания. Может космический разум подскажет достойное решение?

Управление заявками на коленке

Получилось так, что на нынешнем месте работы до моего прихода использовались "твердые" заявки на доступ к информационным ресурсам. Минусы такой системы очевидны. Добавим к ним погибающие деревья и эрозию почвы. Плюсы - в случае возникновения инцидента существовала ненулевая вероятность найти заявку с живой подписью провинившегося и жестко его наказать.
Забавно то, что человечек подписывая заявку, обещал все исполнять и утверждал, что ознакомился со всеми стандартами - существующими и не очень. Про несуществующие стандарты - люди расписывались в знании документа "политики информационной безопасности", который не существовал в компании.
Появилось желание ситуацию подправить и за несколько присестов было написано техническое задание (ТЗ) на создание системы управления заявками на доступ к информационным ресурсам. По сути ТЗ было достаточно примитивным, тк оно переносило механизмы движения бумажных заявок в "киберпространство". ТЗ попало к проектировщикам, точнее аналитикам, там было переработано в соответствии с рекомендациями ITIL, соблюдениями SLA и прочей высокоуровневой премудрости. В результате родилось многостраничное ТЗ, со схемами, картинками, табличками, которое нельзя было прочесть меньше чем за час. Стоимость реализации ТЗ и сроки убили первый добрый порыв.  Но ведь мы работаем в крупной серьезной компании! У нас есть что потратить и желание! Был сыгран тендер, он был выигран и компания победитель начала кодить.
Но бумажные заявки раздражали с прежней силой. Тогда мы повстречались с уважаемыми коллегами из техподдержки, которые согласились копировать бумажные заявки в веб-форму, перенабивая каждую строчку (за что им низкий поклон). Затем, с помощью той же техподдержки, на базе уже развернутого шарепоинта, мы сделали табличку, в которой каждая заявка отображалась в виде одной или нескольких строк. Мы договорились, что каждая заявка имеет несколько статусов и каждый человек из цепочки, отработав заявку должен изменить ее статус, для того, чтобы в работу включился следующий. Мы несколько раз встречались с разными исполнителями заявок и их руководителями, чтобы вбить в их светлые головы, что работа без заявок есть зло. В последний момент, когда мы все проверили между собой, я написал формальное письмо о том, что служба безопасности не возражает против оборота заявок без живых подписей и осознает риски возникающие при этом.
Первая живая заявка была введена в систему 18.09.2008, ровно через 4 месяца после трудоустройства и через 2 месяца после появления "неправильной" версии ТЗ.
Так начала жизнь система, работающая по сегодняшний день.
На данный момент, спустя почти 4 года, через нее прошло более 20000 заявок, сделаны некоторые усовершенствования механизмов приема заявок и их сопровождения.
А что же с той замечательной системой, которая разрабатывалась за деньги уважаемой компанией, победителем тендера, спросите Вы. Ее судьба печальна. Акты готовности системы подписаны нужными людьми год спустя. Но новая система требует 8 «кликов» мышкой и отдельного согласования каждой заявки, против 3 нажатий клавиш на клавиатуре в старой системе и возможности согласования заявок группой. А поиск и фильтрация заявок реализовывались в последний момент и как попало.