ГАЛАКТИКО ВБЕЗОПАСНАСТЕ!!1

О создании ОО "UISG"

2012-01-20T10:57:00.001+02:00

На рубеже 2011 и 2012 годов в жизни украинских профессионалов в области информационной безопасности, образовавших на страницах Linkedin-а сообщество Ukrainian Information Security Group (UISG), произошло два очень важных (эпохальных) события: нас стало более тысячи человек и мы смогли материализовать виртуальное сообщество в реальную Общественную организацию «Украинская группа информационной безопасности».

Здесь, у нас в UISG по состоянию на январь 2012 года зарегистрировано более тысячи участников, но лишь немногие знают, и всего единицы помнят - с чего все начиналось?

Итак,

Украинская группа информационной безопасности (Ukrainian Information Security Group) родилась в 2008 году в социальной сети Linkedin как виртуальное сообщество, объединенное по профессиональному признаку - информационная безопасность. Группа UISG в Linkedin была создана Алексеем Полонским. Модераторами группы стали Глеб Пахаренко, Павел Хмелевский и Артем Карпинский.

В UISG обсуждались насущные на тот момент, но довольно узкоспециальные аспекты конкретных проблем информационной безопасности, а встречи участников проводились в киевских пабах.

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

На определенном этапе формат обсуждений «под пиво» стал тесен для уровня затрагиваемых проблем, поэтому он стал двигаться в сторону большей «официозности». Поначалу эти конференции тоже походили на очень неформальную встречу, только без пива. Но начиная с Конференции UISG-5 (декабрь 2010) эти собрания можно смело называть полноформатными Конференциями - с презентациями и докладами, приглашенными «звездами» международной Information Security и представителями государственных регуляторов, деловыми переговорами в кулуарах и рекламными акциями компаний-организаторов.

Тогда же, на Конференции UISG-5 впервые громко прозвучали предложения трансформировать результаты интересных и плодотворных дискуссий элиты украинской информационной безопасности в нечто осязаемое, то, что можно предложить использовать всем пользователям информационных систем. Не всегда оправданная, но печальная слава Украины как страны со слабым контролем государства за соблюдением кибер-законодательства (и его несовершенством) не давала покоя многим украинским кибер-безопасникам. Идея создания общественной организации Ukrainian Information Security Group на базе имеющегося виртуального сообщества витала в воздухе уже давно, а впервые публично была озвучена Владимиром Ткаченко, Сергеем Дьяченко и Константином Корсуном во время проведения UISG-5.

Все так бы и осталось на уровне призывов и предложений, если бы к осени 2011 года не сформировалась инициативная группа из 9 человек, которая, убедившись во время проведении очередной Конференции UISG-7 в моральной поддержке и одобрении большинства коллег, взяла на себя смелость и труд зарегистрировать общественную организацию «Украинская Группа Информационной Безопасности», что и случилось 12 января 2012 года.

«12.01.2012 Главным Управлением юстиции в г. Киеве выдано свидетельство № 0001-2012 ГО, о регистрации объединения граждан - Общественная организация "Украинская группа информационной безопасности".»

Но настоящим днем рождения организации является вечер 22 декабря 2011 года, когда 9 активистов, презрев предновогодние хлопоты, и преисполнившись решимости, собралась в одном из киевских офисов и приняли ряд принципиальных решений – Организации быть! При этом все понимали, что сама по себе общественная организация бесполезна, а ценность ее будет определяться делами и реальными достижениями. Поэтому тогда же были обсуждены первые шаги и проекты новорожденной организации.

На сегодня группа Ukrainian Information Security Group в Linkedin насчитывает более тысячи членов и все они желанные гости в Общественной организации UISG. Все, кому небезразличны проблемы информационной безопасности в банковском секторе, телекоммуникациях, сферах аудита и консалтинга, интеграции ИТ-решений, правоохранительной деятельности и международном сотрудничестве и во многих других направлениях ИБ – всем найдется кусок общественной нагрузки в организации профессионалов информационной безопасности.

Учредители Общественной организации «Украинская группа информационной безопасности» ставят перед собой весьма серьезные задачи:

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

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

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

О SOPA по-русски

2012-01-19T13:00:00.000+02:00

Многие неверняка знали заранее, остальные ощутили за последние сутки, что американский сегмент Интернета буквально перетряхивает от глобального протеста против находившихся до недавнего времени на рассмотрении Конгресса законопроектов SOPA и PIPA. За этими забавными аббревиатурами скрывается очередной раунд попыток древних медиакомпаний в который раз ограничить доступ к материалам, защищенным авторским правом. Это, казалось бы, благое начинание обладает двумя очень серьезными недостатками, которые в случае принятия соответствующих законов привели бы к изменению Интернета как такового.

Во-первых, законопроекты предписывают провайдерам DNS, то есть Самой Главной Службы в Интернете, превращающей читаемые имена веб-сайтов в цифровые и не запоминаемые IP-адреса, блокировать доступ к веб-сайтам, на которых размещается, либо которые (!) способствуют распространению защищенного содержимого. Также, ссылки на такие ресурвсы должны безжалостно удаляться из индексов поисковых систем типа Google и Bing. Иными словами, если я вставлю в этот пост картинку Микки-мауса, мой блог должен будет быть заблокирован для доступа из США, ссылки на блог удалены из Google, а сам блог удален, так как размещается на американском сервере.

Во-вторых, предлагаемые в законопроектах технические методы контроля за выполнением требований, как обычно в таких случаях, совершенно неадекватны поставленным задачам. Как и чем может помешать блокирование на уровне DNS? Его можно обойти элементарным изменением настроек операционной системы для использования других серверов DNS, находящихся за пределами Штатов и не подпадающих под действие этих законов. То есть, бессмысленные требования и некомпетентные методы снова приведут к немыслимому распилу, в итоге выливающемуся в отсутствие решения задачи. Напоминаю: "заблокированный" в Турции по DNS youtube.com несколько лет находился в пятерке самых посещаемых сайтов в этой стране.

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

Я не призываю никого ни к протесту, ни к поддержке протестующих. Это решение каждый принимает самостоятельно. Но осознать значимость событий очень и очень стоит и вот почему. Я не слежу за развитием этой темы в России, но в Белоруссии и Украине цензура в Интернете насаждается полным ходом. Вспомните "Закон 404" и недавние поправки к Закону об общественной морали. В парламентах очень мало опытных айтишников и безопасников, без общественного влияния их попытки этой борьбы будут иметь очень много неприятных побочных эффектов для демократии и свободы слова. Украинскому обществу давно пора брать пример с наций, отстаивающих свое право на свободный доступ к информации, которое правительства стараются ограничить под любым предлогом: будь то защита авторских прав, забота об информационной безопасности государства или борьба с распространением материалов "для взрослых".

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

Информационная безопасность Украины

2012-01-05T00:59:00.002+02:00

Новость о создании подразделения в составе Службы безопасности Украины, призванного обеспечивать информационную безопасность Украины, всколыхнула общественность, причем не только отечественную. Вот сегодня, например, известный сайт securitylab.ru опубликовал новость о подписании Президентом изменений к закону о структуре СБУ, которыми создается это подразделение.

В связи с этим вношу ясность.

Информационная безопасность в понимании украинского законодательства и государственной политики это не совсем то, вернее, совсем не то, о чем сайт securitylab.ru и этот блог. А именно, это не обеспечение целостности, доступности, конфиденциальности и т.д. информации и тем более не безопасность информационных технологий, а обеспечение безопасности государства Украина в информационном пространстве. И там и там есть и информация, и безопасность, но в случае с нашей "привычной" ИБ речь идет о безопасности информационных активов (данных, систем и т.д.), а в случае с законом - о безопасности конкретной страны. В общем, все намного глобальнее, на грани философии.

Кому интересно, по ссылке можно найти проект Закона об ИБ 2004 года, там все очень подробно описано. Обратите внимание на объекты информационной безопасности, особенно в части "мировоззрение человека, его жизненные ценности и идеалы" и "система создания, принятия и воплощения политических решений". Проект, естественно, на украинском, но Google Translate все организует.

Уязвимость точек доступа WiFi со включенным WPS

2012-01-03T00:07:00.000+02:00

[UPDATE 03.01.2012 11:54]: Точные цифры по статистике использования WPS следующие: из 15424 точек доступа, со включенным шифрованием, WPS поддерживают 5306, что составляет 34%. Данные получены по результатам исследования информации о 16439 точках доступа в г. Киеве. Прошу прощения за устаревшие данные в первой версии поста.

Практически все беспроводные точки доступа, выпускаемые в настоящее время для частного использования, позволяют своим владельцам избежать тягот настройки шифрования при помощи функции WiFi Protected Setup (WPS). Вы можете прямо сейчас проверить, поддерживает ли ваше устройство этот протокол. Найдите на корпусе щиток со штрих-кодом, серийным номером, MAC-адресом и т.д. Если помимо всего прочего на нем значится WPS PIN, то обсуждаемая нынче уязвимость протокола WPS распространяется и на вас. (В этом месте нужно понемногу начинать бояться. А что ж вы думали, блог ведь о безопасности).

Немного истории. Как и большинство других плохих инструментов безопасности, WPS придумали для удобства. Обычно, для того, чтобы настроить шифрование на точке доступа, пользователям приходится довольно долго ковыряться в слабо понятных нормальному человеку настройках меню, а также выдумывать длиннющий ключ шифрования, чтобы потом с третьего-четвертого раза вводить его на ноутбуке, планшете и мобильном телефоне. Чтобы избавить мир от этих мучений, в 2007 году организация WiFi Alliance выпустила протокол WPS, который оставляет всю черную работу на усмотрение точки доступа и ее программного обеспечения. Пользователю остается всего лишь ввести в каждое подключаемое к беспроводной сети устройство короткий восьмициферный PIN-код, что, несомненно, намного проще. (В этом месте самое время для саркастического "Казалось бы, что могло пойти не так?")

Протокол WPS получил самое широкое распространение. По моим подсчетам, в Киеве более 40% точек доступа, настроенных на шифрование трафика, поддерживают WPS (если точнее, это почти 4300 из приблизительно 10000 устройств).

Теперь о главном: WPS был взломан. (Здесь не помешает еще немного сарказму: "Что и требовалось доказать.") А именно, 26 декабря Stefan Viehböck опубликовал статью на тему взлома PIN-кодов WPS путем неполного перебора. В коде всего 8 символов, причем восьмой играет роль контрольной суммы, то есть, является функцией первых семи. Оставшиеся семь можно подобрать менее чем за 10 часов, а для некоторых моделей точек доступа - за 4 часа, используя при переборе небольшую хитрость, позволяющую атакующему удостовериться в том, что первые 4 символа подобраны верно, еще до того, как он приступил к подбору последних трех.

Тема эта широко освещается в прессе, хотя я не видел пока, чтобы в русскоязычном ИБ-сообществе кто-то ее затрагивал. В частности, о провале WPS написали Brian Krebs и "страшный и ужасный" Dan Kaminsky. Вот ссылка на первоисточник и на утилиту Reaver, предназначенную для демонстрации простоты атаки на WPS.

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

Есть и неприятный момент: в некоторых моделях WPS просто невозможно отключить, но это уже вопрос к выбору поставщика оборудования. Оставайтесь в безопасности.

2012

2012-01-01T10:49:00.001+02:00

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

Просто спасибо тем, кто сделал 2011 год интересным и познавательным: семье, друзьям, работе, клиентам, читателям этого блога и слушателям подкаста Securit13.

С Новым годом!

Об опыте

2011-12-28T19:10:00.001+02:00

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

Упдатефобия. Часть I.

2011-12-26T17:26:00.000+02:00

Длинный злой мизантропический пост №1 из серии публикаций об упдатефобии - боязни обновлений.

Никогда не думал, что массовая фобия, вызванная несколькими факапами Майкрософта, сможет продолжаться так долго (уже 6 лет). Все началось с того, что плохо протестированное обновление Microsoft Windows XP уложило систему напрочь. Или, если быть точным, система отправлялась в нескончаемый цикл перезагрузки. Майкрософт принес свои извинения, выпустил исправление ну и в общем-то потихоньку забыл об этом. А админы не забыли.

Какое-то время царствовал режим полного отрицания обновлений, который позже сменился непринятием обновлений автоматических. Помог этому еще один фактор: Майкрософт выпустил Windows Genuine Advantage, инструмент проверки винды "на вшивость", который распространялся в виде автоматического обновления ОС и заставлял владельцев пиратских копий Windows активировать систему "повторно".

Каким-то непостижимым образом эта зараза переметнулась с виндовых админов на юниксоидов (наверное передается воздушно-капельным путем). В итоге все твердо усвоили, что вендоры пока не готовы качественно выполнять обязательства по качеству обновлений. Также, были усвоены страшно умные слова SDLC и Regression Test, и тот факт, что у Майкрософта, Сана и Оракла этого нет. Разумеется, идея внедрить эти практики "на местах" возникала, но ее гнали прочь поганой метлой.

Некоторые не поддались общей тенденции и таки устанавливали обновления. Кто-то сразу же после выхода - на свой страх и риск, кто-то после тщательного тестирования и опытной эксплуатации на выборке систем (таких было минимум: common sense is not that common). Таких нонконформистов презрительно называли early adopter-ами и затаив дыхание ждали, когда же им ойкнется.

Безопасники заикнулись было о вреде отставания от рекомендуемого уровня обновлений, но были резко осаждены. Мол, вот вам антивирусы, с ними играйтесь. К слову сказать, вирусы на ту пору были наиболее распространенной угрозой ИБ и антивирусные компании появлялись как грибы после дождя и росли как на дрожжах (которые, строго говоря, тоже грибы). Долго ли, коротко ли, а случилось так, что кроме антивирусов на компьютерах уже ничего и никогда не обновлялось. И тут, как и полагается в таких случаях, бахнуло.

Первым был Касперский, обознавшийся и определивший как вирусы важные системные файлы винды (в частности, explorer.exe). Угроза была устранена и как побочный эффект операционная система пришла в негодность.

Продолжение следует...

Все о PowerShell, SQL, SHELL, CMD, VBScript в одном месте

2011-12-22T11:37:00.001+02:00

На протяжении последних лет пяти я регулярно обращаюсь за советом к веб-сайту http://ss64.com/. Странно, что я не упоминал о нем ранее.

Спам года

2011-12-20T22:22:00.002+02:00

Пришло сегодня с остальным спамом приглашение на ликбез-семинар по (внимание) Закону Украины "О защите персональных данных". Знаете, сейчас полно таких проводится. Доминирующая тема: как читать закон.

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

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

Как надо (и не надо) писать нормативные документы

2011-12-12T16:56:00.001+02:00

Читал давеча произведение по теме Business Continuity Planning одного ~~укротителя бумажных тигров~~ CISO. Некоторые перлы оказались настолько яркими, что я не поленился выписать их на полях.

Итак, как распознать плохого CISO по написанному им документу? Оригинал был на иностранном языке, заранее прошу простить за трудности перевода.

1. Текст пестрит словами стратегия, организация, управление, обеспечение и бизнес-процесс, причем от уровня (политика, процедура, руководство и т.д.) и типа (технический, административный, организационный) документа плотность этого сквернословия не зависит.

2. Зачастую за один и тот же участок фронта работ определяется ответственность двух и более должностных лиц, а иногда целых групп и категорий сотрудников.

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

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

В связи с этим несколько советов тем, кого судьба привела к пробе пера в области нормативной документации, в частности по ИБ.

1. Чем меньше слов, тем лучше. После написания предложения/абзаца/документа или электронного письма перечитайте его внимательно несколько раз и избавьтесь от слов, удаление которых не меняет смысла написанного. Главные претенденты: данный, этот, все, также, соответственно, организовать, обеспечить, управлять, и производные.

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

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

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

На правах рекламы

2011-12-09T15:13:00.001+02:00

Мой блог, что хочу, то и пишу :)

Мы ищем таланты!

Департамент информационной безопасности компании БМС Консалтинг примет в свой дружный коллектив Консультанта по информационной безопасности и Консультанта по информационной безопасности (направление PCI DSS).

Описание вакансий:

1. Консультант по информационной безопасности

Мы предлагаем:

участие в проектах по аудиту и тестированию ИБ, а также по построению и аудиту систем управления ИБ для крупнейших украинских компаний;
профессиональное развитие, сертификацию и всяческое признание заслуг;
достойное вознаграждение (по результатам собеседования);
работу в дружной команде профессионалов ©

Идеальный кандидат не испугается следующих требований:

от 2 до 5 лет опыта в ИБ или ИТ-безопасности;
наличие профессиональных сертификатов по ИБ или что-нибудь от Cisco;
опыт использования или администрирования широкого спектра ОС, СУБД и прикладного ПО;
знакомство с одним и более скриптовым языком программирования;
знание международных стандартов серии ISO/IEC 27001:2005 и опыт их применения;
понятие о методах аудита и тестирования безопасности;
знакомство и опыт использования ПО аудита и тестирования безопасности.

2. Консультант по информационной безопасности - аудитор PCI DSS

Мы предлагаем:

участие в крупных проектах по аудиту на соответствие требованиям стандарта PCI DSS, а также по оказанию консультаций в этой области;
профессиональное развитие, сертификацию и всяческое признание заслуг;
достойное вознаграждение (по результатам собеседования);
работу в дружной команде профессионалов ©

Наши ожидания:

от 3 лет опыта в ИБ или ИТ-безопасности;
наличие профессиональных сертификатов в области ИБ (сертификаты CISA, PCI DSS QSA или PCI DSS ISA являются преимуществом);
опыт использования или администрирования широкого спектра ОС, СУБД и прикладного ПО;
знание стандарта PCI DSS и опыт его применения;
понятие о методах аудита и тестирования безопасности;
знакомство и опыт использования ПО аудита и тестирования безопасности;
хорошее знание английского языка.

Дополнительным преимуществом будут:

знание международных стандартов серии ISO/IEC 27х;
опыт работы в банке в сфере обеспечения безопасности данных платежных карт.

Если вас заинтересовало это объявление, напишите или позвоните нам:

Дмитрий Петращук, директор Департамента ИБ

Dmitriy_Petrashchuk@bms-consulting.com
+380 (67) 243-05-12

Владимир Стыран, ведущий консультант

Vladimir_Styran@bms-consulting.com
+380 (67) 659-13-42

Оригинал: http://besecure.bms-consulting.com/2011/12/blog-post.html

Креативный фишинг

2011-12-08T13:33:00.001+02:00

Прикольным примером фишингового письма поделился сегодня утром один мой коллега. Текст и комментарии следуют.

Предупреждение! Ни в коем случае не ходите по ссылке в письме: этот сайт распространяется зловредный код (условное название VirTool:JS/Obfuscator.CC)

Письмо выглядит как стандартное приглашение пользователю открыть документ в Google Docs. Ощущения легитимности письму добавляет указание имени пользователя адресата в последней ссылке внизу. Но обратите внимание на доменное имя в этом URL. Ключевыми являются два последних элемента: cn.com. Это Китай. Ничего против Китая я не имею. Вот только уж слишком часто он в последнее время фигурирует в новостях о кибер-атаках.

Читайте письма внимательно, особенно ссылки, которые в них содержаться.

О двухфакторной аутентификации, "секретных" вопросах и хранении паролей

2011-12-07T17:17:00.000+02:00

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

Первое: два фактора аутентификации всегда лучше, чем один, а три - лучше, чем два. Поэтому на вопросы "Нужно ли пользоваться двухэтапным входом в Google или двухфакторной аутентификацией в Facebook?" или типа этого я всегда однозначно отвечаю "Да, нужно." В особенности это касается владельцев смартфонов, у которых все всегда "под рукой" и в случае утери/кражи телефона это "все" автоматически попадает в руки кому-то другому. Апелляции типа "а что, если потеряю учетку" или "эсэмэски туго доходят" - из разряда толстого троллинга: есть способы восстановления учетной записи с нуля, а SMS есть, были и будут дополнительными услугами со всеми вытекающими.

Второе: "секретные" вопросы это уязвимость безопасности. Никогда не пользуйтесь ими в том виде, в котором это задумано. Если же того требуют условия регистрации, обязательно (если это возможно) выбирайте свой вариант вопроса. И еще одно: ответ не должен быть как-то связан с вопросом. Например, я всегда составляю ответы на секретные вопросы случайным образом. Для этого можно использовать прием "ярость оператора ПК" или все тот же генератор паролей, о котором ниже.

Третье: пароли везде должны быть разными. А в идеале и имена пользователей. Благо, для этого можно использовать особенности работы GMail: в его понимании sapran@gmail.com и s.a.p.r.a.n+4linkedin@gmail.com это одинаковые адреса. Для создания и хранения длинных, сложных и разных паролей можно использовать парольные менеджеры - специальные программы типа KeePass, 1Password и тому подобное. Да, первое время будет медленно и неудобно, но потом привыкните - все привыкают.

На этом все, буду рад комментариям с дополнениями. Подойдут любые советы по обеспечению безопасности online-аутентификации.

Оставайтесь в безопасности!

Почему "контроль" <> "средство защиты"

2011-11-23T16:19:00.000+02:00

Многим известно, что Национальный банк Украины в прошлом году снабдил отечественные банки стандартом систем управления информационной безопасностью, основанным на международных стандартах серии ISO/IEC 27000. Некоторые его даже читали и знают, что в ходе ~~вольного~~ перевода текста стандарта был допущен ряд стилистических ошибок и упущений. Совсем немногие в курсе, что "под раздачу" толкователей попали и основные термины оригинального стандарта: информационный актив и контроль безопасности.

Активы в переведенном стандарте названы ресурсами СУИБ. Это было сделано, чтобы не вносить панику в ряды банковских служащих, потому что от информационных активов у них возникает ложная ассоциация устоявшимся термином банковский актив, в результате чего наступает масштабнейший когнитивный диссонанс. Новый термин ресурс СУИБ (в смысле актив) моментально коррелирует с фигурирующими в стандарте ресурсами СУИБ в их оригинальном значении: тем, чем СУИБ снабжается и без чего ее быть не может.

Фундаментальное понятие контроль безопасности переводчик опрометчиво нарек средством безопасности (укр.: засіб безпеки), и если в случае с активами причины более или менее ясны и последствия достаточно скромные, то здесь мы имеем расхождение менее очевидное, но более серьезное. Контроль безопасности это регулярно выполняемый процесс, то есть нечто уже спроектированное, реализованное и исполняемое; существующее в реальности и дающее некий результат после каждого выполнения контроля. В то время, как средство защиты обладает потенциальным характером: это один из факторов, который может способствовать построению контроля, если это средство применить.

Например: программа-антивирус это средство защиты, а антивирусная защита это контроль, который состоит из:

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

Так что, если поразмыслить минуту-другую, разница оказывается не такой уж и маленькой. Каковы могут быть последствия такого отождествления? В первую очередь, ментальные: украинская (в частности, банковская) ИБ как отрасль еще какое-то время пробудет в состоянии неведения о том, что такое внутренние контроли и зачем их строить и выполнять, если можно приобрести и установить программу или устройство, или привлечь внешних консультантов и написать неработающую стратегию/политику/процедуру. Винить в этом некого, слабое понимание понятия контроль это глобальная проблема, которой не удалось избежать даже SANS.

Выборы в Совет директоров (ISC)2

2011-11-16T15:56:00.001+02:00

Сегодня начинается голосование в Совет директоров (ISC)2. Если вы CISSP и хотите этим гордиться, голосуйте за Вима Ремеса.

Не для кого не секрет, что в последние годы произошла тотальная гиперинфляция сертификата CISSP, а консорциум (ISC)2 постоянно поддается критике мирового сообщества специалистов по информационной безопасности: отчасти из-за непрозрачной политики руководства организации, отчасти из-за способствования размытию ценности сертификата.

(ISC)2 нужны реформы, которые необходимо начать с обновления руководства консорциума. И в списке кандидатов на нынешних выборах есть человек, который способен инициировать и провести необходимые изменения.

Голосуйте, или не возмущайтесь.

CTF QUALS

2011-11-15T10:14:00.001+02:00

Еще не поздно зарегистрироваться:

CTF QUALS
PHD CTF Quals - отборочный этап международных соревнований по защите информации PHD CTF.
PHD CTF Quals: 10 декабря (10.00 МСК) - 11 декабря (18.00 МСК)
Регистрация: 14-28 ноября 2011 г.

УСЛОВИЯ КОНКУРСА PHD CTF QUALSУчастие в PHD CTF Quals могут принять все желающие. Условия: предварительная регистрация, 5 человек в команде и безоговорочное следование правилам соревнований. Победители получают право принять участие в PHD CTF в мае 2012 года.
Для регистрации необходимо нажать на кнопку "Принять участие" и получить учетные данные для входа в раздел участника, который будет доступен в течение соревнований.

Zero Nights

2011-11-15T10:09:00.001+02:00

Смотрите, какая вкусная конференция пройдет 25.11.11 в Питере: http://zeronights.ru/

Доклады, представленные на конференции, проходят тщательный отбор командой независимых специалистов. В числе программного комитета такие мировые лица, как Крис Касперски (бывший соотечественник и персона, не нуждающаяся в представлении), Дейв Аител (CEO Immunity, USA), Питер Ван Иекхаут (CorelanTeam, Бельгия), The Grugq (COSEINC, Тайланд), Евгений Климов (PWC,Россия), Илья Медведовский (Digital Security, Россия ), Никита Кислицин (журнал XAKEP, Россия), Александр Матросов (ESET, Россия).
Конференция состоит из секции докладов, секции FastTrack, круглого стола и конкурсов по живому взлому.
На аналитическом треке будут освещены такие области как:
Киберпреступность, APT;
Третья мировая в интернете;
Тестирование на проникновение.
Технический трек будет посвящен реальным примерам уязвимостей в:
Популярных WEB-сервисах: Google,Vkontakte;
Бизнес-приложениях: SAP, 1C,Documentum,Peoplesoft;
Банковских приложениях типа ДБО и АБС крупнейших российских производителей;
Программно-аппаратных комплексах: АСУ-ТП, токены, платежные терминалы, интернет-киоски, IP-телефоны;
Платформах виртуализации;
Технологиях передачи данных: 3G, LTE , IP-телефония;
Расширениях web-браузеров и клиентских приложениях.

"Дифейс" bigmir.net

2011-11-14T10:00:00.001+02:00

Без комментариев.

Почему вендорам давно пора переосмыслить свое понятие о сложности паролей

2011-11-13T12:55:00.001+02:00

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

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

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

Конкурс украинских блогов BUBA 2011

2011-11-01T12:23:00.000+02:00

Подчиняясь всеобщей вакханалии голосования за блоги в конкурсе BUBA 2011, размещаю баннер голосования за этот блог справа на приборной панели.

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

Ваш голос очень важен :)

Веб-сайт UISG v7

2011-10-26T23:16:00.001+03:00

У седьмой конференции UISG, которая состоится 2 декабря в Киеве, теперь есть веб-сайт, целиком и полностью посвященный этому событию: http://7.uisgcon.org. Надеюсь, сайт закрепится и будет служить верой и правдой во время подготовки следующих конференций.

На сайте можно удобно и быстро сделать следующее:

зарегистрироваться в качестве участника конференции - http://7.uisgcon.org/attendees
подать заявку докладчика - http://7.uisgcon.org/speakers
найти контакты организаторов конференции - http://7.uisgcon.org/contacts
принять участие в формировании программы конференции, поделившись с организаторами интересными именно вам темами докладов - http://7.uisgcon.org/program

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

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

Также, вы можете последовать примеру ребят из ААА и разместить баннер на своем сайте:

Код баннера:

UISG v7

2011-10-14T00:03:00.000+03:00

Уважаемые друзья,

С радостью сообщаю вам о начале подготовки седьмой конференции Украинской группы информационной безопасности.

Пожалуйста, ознакомьтесь с описанием события и приглашением на конференцию по следующим ссылкам:
- на русском: http://goo.gl/N3edr
- in English: http://goo.gl/0l1Lz

Документы содержат информацию, необходимую для регистрации участника и подачи заявки докладчика.

Ссылка на событие в LinkedIn:
http://events.linkedin.com/7th-Ukrainian-Information-Security-Group/pub/824461

Обновления о статусе подготовки конференции будут публиковаться в дискуссии в LinkedIn (доступно действующим членам Группы), а также будут рассылаться по email всем зарегистрировавшимся участникам. Следите за обновлениями и до встречи на UISGv7!

Спасибо за внимание.

Сложность враг безопасности

2011-09-03T23:49:00.000+03:00

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

Представьте себе модель: одна система, на ней открыт один порт. Сервис, крутящийся на этом порту, имеет, скажем, N уязвимостей. Для того, чтобы защитить этот сервис, мы устанавливаем перед нашей системой межсетевой экран. У которого открыт один порт - консоль управления. Эта самая консоль содержит, скажем, M уязвимостей. Что мы получаем? Общее количество уязвимостей, равное M + N, то есть, возросшее в результате внедрения средства защиты. Идем дальше. Перед всем этим хозяйством мы устанавливаем систему предотвращения вторжений, на которой открыт один порт, а количество потенциальных уязвимостей равно K. Итого имеем S = K + M + N уязвимостей.

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

Что в в таком случае происходит с количеством уязвимостей? О том, сколько "дыр" в облаке поставщика услуг мы не знаем. Единственное, в чем мы можем быть уверены, это то, что уязвимости в нем есть (допустим, их C). Итак, мы получаем дополнение к нашему уравнению, но не в виде слагаемого, а в виде множителя, ведь компрометация каждой существенной уязвимости в облаке приведет к раскрытию информации обо всех наших уязвимостях. Итого, S = ( K + M + N ) * C.

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

Еще об экспертах

2011-08-31T14:51:00.001+03:00

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

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

Уверен, многие знают немало представителей как первой, так и второй категорий. Цените скромных безопасников, коллеги, это исчезающий вид.

Новый блог

2011-08-20T21:11:00.000+03:00

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

Отличный пример неполного анализа рисков

2011-08-17T15:28:00.001+03:00

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

Но (в буквальном смысле) с другой стороны, проблема проникновения птицы наружу, ровно как риски, возникшие в следствие внедрения контроля, в ходе анализа рассмотрена не была. Результатом, очевидно, является выразительный facepalm.

Всем удачного дня.

Риски процесса анализа рисков

2011-08-08T14:13:00.000+03:00

Из собственных наблюдений. Весь анализ рисков (вообще -- весь, те только ИБ) можно условно поделить на Вероятностный и Мотивационный. В обоих случаях мы в какой-то момент имеем дело с такой величиной, как вероятность. Данные о вероятности наступления того или иного события (угрозы) мы черпаем из а) статистики и б) фантазии, также известной как экспертное мнение.

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

В мотивационном анализе рисков куда важнее определить не угрозы, а их источники. То есть, агентов угроз, которые могут быть мотивированы напасть на компанию. Это могут быть криминальные хакеры, конкуренты, желторотые хактивисты, недовольные клиенты и многие другие. Определившись с тем, кто может захотеть напасть, можно приступать к оценке ресурсов и, следовательно, методов атаки, доступных потенциальным агентам угроз.

И так, кропотливо и методично, одна за другой, комбинации агентов угроз и возможных каналов атак получат отражение в отчете об анализе рисков: как слабо вероятные, но неизбежные на длинной дистанции. Отталкиваясь от полученного результата можно и аудиты заказывать, и пентесты проводить, и стратегию управления уязвимостями и инцидентами строить. А "угроза взлома: 15% в год" это не анализ рисков. Это так, подогнать СУИБ под соответствие.

Извините за многословность и спасибо за внимание.

Securit13 подкаст эпизод 3

2011-08-04T09:38:00.001+03:00

В этот раз в гостях у Securit13 Глеб Пахаренко. Обсуждаются темы организации конференций по безопасности, а также их посещения. Среди всего прочего последние новости индустрии, любопытные гипотезы, догадки и, конечно же, сплетни.

Расширение приватности Firefox: ShareMeNot

2011-08-02T13:08:00.000+03:00

В продолжение темы безопасности браузера Firefox, которую я поднял в далеком 2009-ом году, хочу поделиться новым (по крайней мере для меня) расширением, которое я едва-едва начал использовать, но уже получаю от этого "много-много радости". Разрешите представить: ShareMeNot.

Вы наверняка давно подозреваете, что социальные кнопки, при помощи которых вы можете поделиться информацией со своими виртуальными друзьями, располагаются на сайтах не только для вашего удобства. Так и есть, каждая такая кнопка по сути внедряет в сайт участок кода, загружаемого с внешнего ресурса: будь то, собственно, социальная сеть типа Facebook или Twitter, или же специальные службы социального шаринга (sharing) вроде AddThis, Shareholic и т.д.

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

Стоп, так уж и ничего? Как показано на рисунке, расширение Firefox ShareMeNot отлично справляется с блокированием таких попыток. Советую вам самим в этом убедиться.

Большое спасибо господину Шнайеру за наводку.

Securit13 подкаст эпизод 2: Epic Fail

2011-07-20T17:00:00.011+03:00

Увидел свет второй эпизод подкаста Securit13. В сокращенном составе, мы обсуждаем новости информационной безопасности последних двух недель, а также делимся соображениями по поводу защиты от распределенных атак отказа в обслуживании.

Megafon + Яндекс =

2011-07-19T10:19:00.003+03:00

Все наверняка уже слышали о вакханалии нарушения тайны переписки, которую на днях учинил Мегафон. Если нет, то в двух словах: на их сайте отправки СМС Яндексом были проиндексированы более 8,000 отправленных сообщений. С подробностями можно ознакомиться на этой проиндексированной странице. По непонятным причинам оригинал с Хабра уже исчез, что совершенно бесполезно в силу надежности кеша Google и широкого распространения этой новости: вчера слова "Megafon" и "Яндекс" на короткое время попали в тренды Twitter.

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

Виноват сам Мегафон. Вчера я было подумал, что на сайте sendsms.megafon.ru неправильно настроен файл robots.txt, но как выяснилось сегодня, его там просто не было. В комбинации с "гениальнейшей" идеей хранить отправленные сообщения прямо в одном из подкаталогов сайта мы и получили это происшествие. То есть, резюмируя:

Программисты Мегафона, или кому он там аутсорсит эту функцию, ошиблись в выборе места хранения отправленных сообщений. Для этого было бы безопаснее использовать базу данных, или хотя бы неиндексируемый каталог веб-сервера (см. п. 2).
Админы Мегафона серьезно напортачили с robots.txt. Для несведущих, в файле с таким названием каждый вебмастер может запретить индексацию всего своего сайта, или его отдельных подкаталогов. Поисковый "паук", наткнувшись на robots.txt, следует изложенным в нем инструкциям. Например, файл следующего содержания скомандует поисковику индексировать все кроме каталогов private и sentsms.
```
User-agent: *
Disallow: /private
Disallow: /sentsms
```
Мегафон показал неэффективность или отсутствие контроля над изменениями и анализа рисков в этом контексте. Можно сколько угодно винить админов и программистов веб-сайта, но пока Мегафон не продемонстрирует наличие действующего контроля над изменениями, и админы, и программисты останутся всего лишь "стрелочниками".

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

Из наболевшего о PCI DSS

2011-07-12T08:33:00.010+03:00

Соответствие требованиям стандарта безопасности PCI DSS сейчас довольно горячая тема. И очень часто во время ее обсуждения участники дискуссии забывают об основном назначении стандарта. А PCI DSS был изобретен для того, чтобы перенести риски карточного мошенничества с платежных систем VISA, MasterCard, AmEx и Discover на банки-эмитенты пластиковых карт и прочие субъекты их обработки: торговцев, поставщиков услуг, процессинг, эквайринг и пр.

Вы заметили, PCI DSS не содержит раздела, касающегося оценки рисков, как это принято во многих других методиках и стандартах ИБ? Это потому, что оценка рисков, на основании результатов которой составлялись требования стандарта, уже давно выполнена Визой со товарищи. Стандарт регулирует их риски, а не ваши или ваших клиентов, и вступая в сотрудничество с платежными вендорами вы обязаны взять какую-то часть этих рисков на себя. Другими словами, если хотите работать с платежными системами, соблюдайте стандарт, или... или есть другой путь.

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

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

И не нужно причислять PCI DSS к стандартам государственного или отраслевого уровня. В этой области никогда не будет справедливости: кому-то соблюдать требования будет обязательно, а кто-то будет состоять в белом списке в силу своей важности и полезности. И надеяться на то, что грубое несоблюдение требований ИБ крупными игроками чем-то им аукнется -- тоже не стоит.

Защита персональных данных в Украине - 2

2011-07-10T11:20:00.001+03:00

Дай, думаю, почитаю "Временные рекомендации о подаче и заполнении заявки о регистрации базы персональных данных" (zpd_12.pdf). Ну и не обошлось без заглянуть в метаданные. Имя пользователя, создавшего документ: PC5. С одной стороны, это позволяет надеяться на то, что в службе ЗПД как минимум 5 ПК. С другой, наталкивает на подозрение, что персонализированных имен пользователей там пока нет.

Авторитетные высказывания

2011-07-09T12:51:00.000+03:00

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

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

Также, не отстают от одежки всяческие научные звания, профессиональные сертификаты и прочие подобные "регалии". Причем зачастую они используются совершенно не к месту. Возможно, вы читали когда-нибудь статьи в глянцевых журналах на ИТ-шную и ИБ-шную тематику, подписанные автором с указанием дюжины известных и не очень аббревиатур: названий сертификатов. Признаюсь честно, на меня это оказывает воздействие. Например, заметка об управлении ИБ, написанная обладателем CISM, CGEIT, CRISK и PMP наталкивает на мысли о том, что даже если автор и не практикует на тему статьи направо и налево, то уж с хорошими практиками и программами обучения он точно знаком. При всем при этом аналогичная статья подписанная "кандидатом технических наук" выглядит не так внушительно и даже способна вызвать улыбку.

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

Авторитет выдвигается в качестве аргумента, когда других аргументов попросту нет, или когда ваш собеседник не считает необходимым или уместным их излагать. Будьте внимательны в таких ситуациях: очень возможно, что вас пытаются надуть.

Право собственности VS Право на тайну переписки

2011-07-06T14:22:00.001+03:00

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

Дело в том, что право Сотрудника на тайну переписки в этом случае противоборствует праву Работодателя на владение, собственно, перепиской.

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

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

Я не берусь решать кто прав, а кто не очень. Может быть потом, позже, тут есть о чем подумать. И естественно, все это актуально в демократических государствах.

Securit13 подкаст эпизод 1: Пилот

2011-07-05T01:04:00.006+03:00

скачать эпизод - детали и описание
iTunes - RSS - Twitter - facebook - Blog (under construction)

Риторика социальной инженерии

2011-07-04T11:34:00.000+03:00

Меня удивляют люди, считающие себя ИБшниками, и которым при этом не хватает выдержки воздержаться от риторических вопросов вроде:

почему люди вставляют в ПК подозрительные флешки?
почему люди открывают почтовые вложения подозрительных писем?
почему люди записывают пароли?
почему люди раскрывают информацию по телефону?
почему люди помогают незнакомцам?
почему люди... ну вы поняли.

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

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

Защита персональных данных в Украине

2011-06-26T00:39:00.002+03:00

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

Или кто-то всерьез считает, что "государственные комитеты", "положения про регистрацию" и сопутствующие им полчища оригами способны ~~кого-то~~ что-то защитить?

Слышите шорох? Это крадутся бумажные тигры.

Безопасность, управление изменениями и хранение данных в "облаках"

2011-06-21T17:33:00.000+03:00

Для несведущих: управление изменениями, это когда программу разрабатывают, тестируют и устанавливают в среде промышленной эксплуатации (АКА "продуктиве") разные люди. Вернее, это даже следствие контроля за изменениями. Но все по порядку.

Когда-то очень давно один мудрый генеральный директор решил, что хватит уже относиться к ИТ, как к шаманам и чернокнижникам, ютящимся в подвалах бизнес-центров и выполняющих одним только им известные манипуляции над многомиллионным аппаратным и программным обеспечением. Пора уже вывести этот орден рыцарей плаща и обжимки на свет божий и призвать к ответу за ИТ-бюджеты: куда, мол, и сколько было потрачено. А главное, с какой эффективностью, то есть, что компания приобрела за вложенные деньги. Последовавшие за этим попытки айтишников невнятно оправдаться за разбазаренное ~~народное~~ корпоративное добро были названы процессом обоснования или возврата инвестиций (Return on Investment, ROI). А установка жесткого бизнес-контроля над вложениями в ИТ и измерением их "выхлопа" было названо громким словом IT Governance. В основу этой новой дисциплины был заложен принцип четкого соответствия функций ИТ и целей бизнеса

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

Непредвиденные обстоятельства - это универсальное объяснение факапов (от англ. to fuck up), которых не удалось избежать при помощи денег и прочих нечеловеческих ресурсов. Иными словами, это когда и сервер новый, быстрый и места много, и сеть к нему подключена быстрая-прибыстрая, и (а чем черт не шутит?) резервирование ему сделано для высокой доступности. А бекапы на него все равно не ложатся, потому что администратор в конфигурации программы резервного копирования допустил ма-а-аленькую синтаксическую ошибку. Или другой пример, когда в новую мега-круто-распупыристую бизнес-систему в конце рабочего дня в пятницу молодой системный администратор вносит незначительное изменение, в результате чего все выходные (т.е. два, а иногда и три дня) система работает неправильно. Например, неправильно считает траффик, потребленный абонентами мобильного Интернета. В результате чего компания поставщик этого самого мобильного Интернета попадает ~~на бабло~~ в убытки.

Перечислять примеры факапов особого смысла не имеет, так как любой читатель, имеющий отношение к ИТ, может с легкостью поделиться экземпляром, очевидцем или участником которого был он сам. Для того, чтобы избежать таких ситуаций, или свести частоту их возникновения к минимуму, умные люди придумали управления изменениями (Change Management). Основной принцип прост: перед применением в продуктиве все изменения должны быть аккуратно разработаны, испытаны и утверждены руководством. Причем очень важно, чтобы разработка, испытание и применение изменений выполнялись разными сотрудниками и с использованием разных копий программы. То есть, разработчики разрабатывают ПО в среде разработки, после чего тестировщики копируют готовый код в среду тестирования и проводят испытания, вслед за чем администраторы приложения копируют испытанный код в среду промышленной эксплуатации - так называемый продуктив. Естественно, вся эта возня большинству айтишников видится совершенно бессмысленной, поэтому факапам в ближайшем будущем конца не видно.

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

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

Видео: "Социальная инжененрия для инженеров", UISG v6

2011-06-10T11:58:00.002+03:00

Социальная инженерия для инженеров, UISG#6 from Vlad Styran on Vimeo.

Слайды презентации: http://securegalaxy.blogspot.com/2011/05/uisg-v6.html

Впечатления о UISG v6

2011-05-23T09:23:00.003+03:00

Шестая (ежеквартальная, получается) конференция Украинской группы информационной безопасности порадовала нарастающим интересом публики. Как мне показалось, в i-Klass 19 мая было как минимум вдвое больше людей, чем на пятой конференции. Невольно вспомнился самый первый сбор группы, на котором о таком формате еще никто и не думал.

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

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

Для себя из конфы я вынес море общения с интересными людьми, новые знакомства и интересную информацию из докладов, которые мне удалось посетить. Если так будет продолжаться и далее, в скором времени возникнет необходимость борьбы за качество со всеми вытекающими последствиями (фильтруемый CFP, новые мероприятия, широкое освещение в профильных медиа и т.п.). Главное не упустить момент. А пока, так держать.

Слайды моей презентации на UISG v6

2011-05-20T11:26:00.004+03:00

Социальная инженерия для инженеров

View more presentations from Vlad Styran

Update: Видео презентации на UISG v6 можно увидеть здесь.

Промо слайд с завтрашней презентации "Социальная инженерия для инженеров"

2011-05-18T21:34:00.001+03:00

Объявление конкурса на UISGv6

2011-05-17T17:44:00.003+03:00

Уважаемые коллеги,

Как вам наверное известно, 19 мая, то есть послезавтра, произойдет грандиозное событие: шестая конференция нашей замечательной группы (http://goo.gl/4eq74). Многие из вас наверняка уже ознакомились с программой мероприятия (http://goo.gl/99M5Z) и недоумевают, что же означает пункт "Сессия В. Стырана и А. Карпинского" увенчивающий поток "Мастерство".

А означает это следующее: в обозначенный промежуток времени, а именно "16:50-18:00", будет объявлен победитель конкурса, который подготовлен нами с Артемом и будет проводиться... а вот прямо сейчас и будет проводиться. Пожалуйста, ознакомьтесь с условиями соревнований ниже по тексту. И да, кстати, участников ждут памятные подарки, а победителя -- большой и вкусный приз. Поэтому количество участников ограничено, так что спешите регистрироваться! Хотя все равно будет жеребьевка =)

Итак, правила проведения конкурса (отформатированная официальная версия - по ссылке http://goo.gl/qRoDk) :

UISGv6

IT Security Contest

Легенда

Недавно стало известно о новом DDoS-ботнете, централизованно управляемом при помощи зашифрованных сообщений. В последние несколько дней ботнету удалось вызвать отказ в обслуживании ряда сервис провайдеров и интернет ресурсов.

Задача

Провести анализ работы ботнета и остановить его работу.

Исходные данные

Бинарный код клиентской части ботнета в виде исполняемого файла Win32 с расширением .EXE. Внимание! Исполняемый код клиентской части ботнета разрешается запускать только в специально подготовленном виртуализированном окружении!

Выступить на борьбу с ботнетом

Для участия в акции вам потребуются:

* Базовые знания в области сетевых технологий и протоколов;

* Навыки анализа сетевого трафика;

* Знания в области криптографии;

* Навыки системного и прикладного программирования станут серьезным преимуществом.

Зарегистрироваться в акции и получить архив с бинарным кодом можно обратившись по адресу:

lab0t31337@gmail.com

В заявке на участие укажите:

* Имя;

* Контактный email

Желаем удачи!

P.S. Внимание! MD5 суммы клиентского ПО для проверки после загрузки:

17571c8e52784480da42ed9919e4c216 *check32.exe

9b052095fa0d7ef79a25ebb633dc2fb7 *libcurl.dll

Эти суммы сняты с официального ПО, используемого в соревнованиях. Если суммы не совпадают, НИ В КОЕМ СЛУЧАЕ НЕ ЗАПУСКАЙТЕ полученные программы!uisg.org.ua

Презентация "Социальная инженерия для инженеров" 19 мая на UISGv6

2011-05-14T16:38:00.000+03:00

И вот, когда презентация уже практически готова, мне в голову пришла идея обратиться к вселенскому разуму и спросить у вас: а что бы вы хотели увидеть в докладе о социальной инженерии, ее методах, пользе от ее использования и соответствующих рисках?

Предложения принимаются по адресу sapran@gmail.com, а также в комментариях. Всем заранее большое спасибо за участие.

Возможная утечка данных из LastPass

2011-05-10T10:43:00.000+03:00

Всем пользователям LastPass следует изменить свои мастер-пароли и переосмыслить использование этого сервиса для хранения данных доступа к важным ресурсам. Лично я советую не использовать LastPass для электронной почты, социальных сетей и сайтов, оперирующих платежной информацией и персональными данными. Для хранения многочисленных важных паролей следует использовать что-то, работающее в режиме offline: например, KeePass.

Подробное описание причины такой спешки размещено по ссылке. Существует уверенность в том, что сеть LastPass была взломана. Также, есть подозрение, что злоумышленники осуществили доступ к клиентской информации (логично, зачем еще это делать).

Видео моей презентации на UISG v5

2011-05-07T01:34:00.000+03:00

Уже UISG v6 на носу, а у меня только руки дошли пережать видеоролик с моим выступлением на предыдущей конференции группы.

UISG#5, Владимир Стыран from Vlad Styran on Vimeo.

Остальные доклады можно увидеть здесь.

Уязвимость нулевого дня в Skype для MacOS X

2011-05-07T01:24:00.002+03:00

[Updated 2011-05-09] Согласно официальному блогу Skype, уязвимость была исправлена в новой версии для MacOS X: "we recommend you update your software with the fix made available on April 14th, just click on Skype -> Check for Updates or you can download the software here."

Это очень нехорошая и заразная уязвимость. Удаленный доступ к компьютеру под управлением MacOS X может быть получен (всего лишь) при помощи отправки специально подготовленного сообщения в Skype. Последствия такого рода уязвимости могут быть очень печальны. Представьте себе сетевого червя, распространяющегося путем рассылки зловредного сообщения по спискам контактов с зараженных компьютеров.

Опечалила реакция Skype на сообщения об обнаружении уязвимости. С момента уведомления прошел уже месяц, а обещание выпустить исправление еще не выполнено. Публичное заявление о существовании "дыры" должно несколько ускорить процесс подготовки обновления, потому что там, в подполье, сотни злых хакеров уже куют соответствующий "APT". Я, конечно же, утрирую, но в каждой шутке есть доля шутки. Искать что бы то ни было становится значительно проще, когда тебе прозрачно намекают где именно.

С другой стороны, выпуск исправления не очень-то и поможет. Автоматических апдейтов у Skype пока нет, а обладая объектным кодом исправленной версии злоумышленникам будет намного проще обнаружить уязвимый участок программы при помощи обратного инжиниринга (reverse engineering). Этот метод уже давно используется блэкхэтами на продуктах Microsoft: вслед за ежемесячными "вторниками обновлений" (patch tuesday) приходят "четверги эксплойтов".

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

6-я конференция Ukrainian Information Security Group (UISG) 19 мая 2011 г.

2011-05-06T14:16:00.000+03:00

Анонс конференции размещен по адресу:

http://sites.google.com/site/uisgua/konferencii/konferencia-uisg-i-isaca-kiev-chapter-6.

Цитирую:

Добрый день!

Мы рады пригласить Вас на регулярную конференцию украинского сообщества специалистов по информационной безопасности и Киевского отделения ISACA.

Главное событие UISG пройдет 19 мая 2011г. в помещениях учебного центра i-klass по адресу ул.Лаврская, 16 (бывшая ул. И.Мазепы,34).

Конференция зарекомендовала себя как место встречи и интересного общения за чашкой кофе представителей разнообразных направлений ИТ и защиты информации. Демократичность, креативность и участие большого количества профессионалов отрасли (мы в этом году планируем принять 100 человек) выделяют это событие среди других мероприятий.

Вас ждут два потока - Технические и Организационные доклады. На конференции ожидаются лучшие докладчики из Украины, члены ISACA и UISG. Ожидаются обсуждения тематики защиты персональных данных, Cobit, реагировании на продвинутые угрозы (APT), защита цифровой личности, применение утилит для тестирования на проникновение.

Параллельно с докладами будет проходить демонстрационные сессии работы с оборудованием и программным обеспечением защиты информации. Сессии коллективной работы OpenSpace и WorldCafe сделают конференцию привлекательной площадкой для обмена опытом.

Время проведения: 19.05.2011 с 9:00 до 18:00.

Место проведения: i-Klass, ул.Лаврская, 16 (бывшая ул. И.Мазепы,34).

Стоимость участия: бесплатно (для зарегистрированных участников). При желании оплачивается бизнес-ланч - 40грн.

Регистрация: вышлите ФИО, должность, компанию, контактный телефон на адрес uisg6@hotmail.com.

Конец цитаты. Увидимся на UISG#6.

Событие в LinkedIn - Предварительная программа - Обсуждение - Страница UISG

Данные, разглашаемые мобильными приложениями

2011-04-26T16:30:00.000+03:00

Блестящее исследование провел Wall Street Journal: популярные мобильные приложение для iPhone и Android были исследованы на предмет доступа к данным на мобильных устройствах и дальнейшего использования этих данных.

Рассматривался доступ к следующим наборам данных:

логин и пароль в соответствующем сервисе (Google Maps, Youtube, Facebook etc.);
список контактов;
пол и возраст владельца устройства;
данные о местоположении (GPS, сетевое позиционирование и пр.);
ID телефона (имеются в виду различные серийные номера и прочие идентификаторы ОС и аппаратной части, такие как S/N и IMEI);
номер телефона (MSISDN).

Взгляните на результаты. Уверен, вас ждет сюрприз.

PTES Technical Guidelines

2011-04-23T11:24:00.002+03:00

Свершилось. Проект по созданию Penetration Testing Execution Standard (сокращенно PTES) начинает приносить первые плоды. Вчера после яркого анонса в прямом эфире на Source Boston на www.pentest-standard.org был опубликован документ под названием PTES Technical Guidelines, следом за чем веб-сайт благополучно загнулся под неистовым потоком желающих поскорее ознакомиться с руководством. Был среди них и я, но что поделаешь, пришлось немного подождать.

Первое впечатление от руководства: это даже подробнее, чем на www.vulnerabilityassessment.co.uk. Как я и предполагал ранее, PTES не пошел по "высокоуровневому" пути OSSTMM и делает все возможное, чтобы как можно более детально описать и упорядочить процесс тестирования на проникновение. Не скрою, такой подход мне нравятся больше.

Хочется надеяться, что в связи с развитием PTES в скором будущем нас ждут существенные изменения в области пентестов. Как минимум пора прекратить называть этим словом сканирование на уязвимости и переформатирование отчетов Qualys. Вещи должны называться своими именами. И если аудитор не провел тестирование по социальному каналу с проверкой уязвимостей на стороне клиента (client side), то для того, чтобы гордо назвать свою работу тестом на проникновение, он должен сделать соответствующие замечания в описании области действия теста (test scope): так мол и так, тестирование было неполным по пожеланию клиента.

Слайды с презентации на Source Boston:
http://www.slideshare.net/iamit/pentest-standard-keynote-sourceboston

Когда управление рисками не работает

2011-04-18T14:00:00.004+03:00

Современная индустрия информационной безопасности построена на концепции управления рисками: защищаться от угроз нужно в силу их вероятности и возможных последствий. То есть, все элементарно: Риск = Вероятность * Ущерб. Сложности начинаются, когда мы приступаем к оценке Ущерба и Вероятности.

И ущерб, и вероятность можно оценивать двумя способами: количественно и качественно. В первом случае величина выбирается из диапазона значений вроде "Высокий, Средний, Низкий", во втором - величина составляет (приблизительное, местами очень) цифровое значение (В = 0,02-0,05; У = 100-300 млн. долл.)

При всей сложности правильного выбора значений ущерба и вероятности, обсуждение которой выходит за рамки сегодняшней темы, этот выбор практически всегда удается сделать. В результате строятся корпоративные СУИБ согласно ISO/IEC 27001:2005, внедряются системы внутренних контролей ИБ, а космические корабли бороздят просторы мирового океана. И кажется все в порядке и тревожится нечего, но только где-то глубоко внутри остается чувство неразрешенности некоторых задач. Будто часть вопросов осталась без ответа.

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

Перед тем как подолжить, я сделаю небольшое <ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ>: сдается мне, что RSA, Comodo, HBGary Federal, MySQL и Epsilon выполняют управление рисками в той или иной форме. Основная причина, по которой традиционный риск менеджмент оказался слабо применим в их случаях, это сложность оценки вероятности выполнения хакером конкретного сценария атаки. Возьмем RSA - атака была осуществлена с использованием трех факторов успеха:

актуальной уязвимости в Adobe Flash (который, в прочем, уязвим перманентно),
уязвимости человеческого фактора, и
чувствительности продукта SecurID к угрозам конфиденциальности.

То есть, другими словами, если бы Flash был неуязвим или отключен, все сотрудники были обучены не открывать вложения к спаму, а SecurID был open source решением, то атака бы не удалась. Зато удалась бы другая атака, например подкуп релиз-инженера крупной суммой денег и внедрение в код SecurID злого бекдора. Улавливаете, к чему я клоню? На каждый один неудавшийся из N возможных сценариев инцидента в колоде хакера остается N-1 вариант. На этом </ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ> закончено.

Все изложенное выше подкрепляется результатами недавних исследований рабочей группы, составленной из представителей четырех научных академий США, которая была озадачена оценкой применимости техники анализа рисков к защите объектов атомной энергетики. С незначительными изменениями эти результаты можно перенести на ИБ: управление рисками очень эффективно для защиты от естественных или неумышленных угроз (например, сбоя оборудования в серверной), и не очень эффективно для защиты от умышленных угроз (хакерских атак). То есть, что хорошо для BCP, не подходит для кибер-атак. Очень рекомендую ознакомиться с отчетом (бесплатно, нужна регистрация) всем, кто в теме управления рисками. Также, советую прослушать последний эпизод подкаста Risky Business, в котором эта тема обсуждается очень подробно.

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

APSA11-02 / CVE-2011-0611 adobe 0-day

2011-04-12T11:12:00.000+03:00

"- Следующий!", - сказал заведующий.

Компания Adobe (кстати, правильно произносится "эдоуби", а не "эдоб", как многие привыкли) опубликовала вчера очередное предупреждение об уязвимости нулевого дня в Flash Player последних версий. Уязвимость была обнаружена прославленной блогершей Mila Parkour (осторожно с файлами в ее постах, это вполне себе боевые зловреды, то есть их не то что не рекомендуется, а просто категорически запрещается открывать/запускать вне лабораторий).

В ее блоге представлен пример использования этой дыры: в настоящее время по Интернетам бродит письмо с вложенным .doc-файлом, содержащим Flash-объект, эксплуатирующий данную уязвимость (очень оригинально, не правда ли? прямо как в истории с RSA SecurID). Письмо мол якобы описывает последние изменения в Китайском антимонопольном законодательстве, и эта тематическая утонченность дает надежду, что мы имеем дело с очередной целенаправленной атакой на какой-нибудь крупный международный бизнес, которую совсем скоро, буквально на днях отнесут к категории APT.

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

Больше по теме

https://krebsonsecurity.com/2011/04/new-adobe-flash-zero-day-being-exploited

http://www.theregister.co.uk/2011/04/12/attacks_exploit_adobe_flash/

Подробности инцидента RSA/SecurID

2011-04-07T22:16:00.000+03:00

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

Следовательно, теперь мы знаем, что же на самом деле означает термин Advanced Persistent Threat (APT). Это когда компанию, работающую в индустрии ИБ, "ломают" путем эксплуатации уязвимости, о которой на момент взлома гудит весь Интернет. Еще один повод задуматься о последствиях атак с использованием социальной инженерии и пользе программ осведомленности персонала.

Люди, будте бдительны.

Выбор специалиста по ИБ

2011-04-05T16:10:00.003+03:00

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

Первым методом проверки кандидата на прочность, конечно же, в голову приходит наличие у соискателя профессиональных сертификатов. О пользе сертификации сказано много, критики высказано не меньше, но факт остается фактом: рекрутеры на сертификаты обращают немало внимания. Также, при всех возможных изъянах института сертификации, у него есть ряд важных преимуществ.

Обратите внимание, речь идет не о сертификатах вендоров вроде Cisco и Microsoft, а о независимых институтах сертификации. Ни в коем случае не умаляю важности вендорных сертификаций, но они служат несколько иной цели. Сегодня речь не об эффективном использовании разного рода технологий, а об образовании в области информационной безопасности.

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

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

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

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

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

Основные "ходовые" сертификации в индустрии ИБ изложены ниже.

Certified Information Systems Security Professional (CISSP) - администрируется International Information Systems Security Certification Consortium, сокращенно (ISC)2. Охватывает область знаний по ИБ из 10 доменов, это, фактически, самая обширная программа в индустрии. Сертификация требует успешную сдачу экзамена, 5 лет опыта в ИБ и формальное принятие правил кодекса этики (ISC)2.

Systems Security Certified Practitioner (SSCP) - "младший брат" CISSP, охватывает 7 из 10 доменов области знаний (ISC)2. Требует 2 года стажа в ИБ и успешную сдачу экзамена.

Certified Information Security Manager (CISM) - администрируется ISACA и охватывает область знаний по управлению рисками и информационной безопасностью. Требует сдачу экзамена, 5 лет в аудите или безопасности ИТ-систем, выполнение правил кодекса этики ISACA.

Certified Information Systems Auditor (CISA) - пусть и не чисто ИБ-шный сертификат, но имеет отношение к безопасности. Учрежден ISACA, в области знаний освещены вопросы защиты ИТ-систем, управления рисками и непрерывностью бизнеса. Сертифицированные специалисты обязуются выполнять правила кодекса этики ISACA.

Security+ - администрируется CompTIA и является сертификатом начального уровня. Не требует опыта и охватывает подмножество области знаний CISSP.

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

Updated: Прекрасный обзорный доклад о существующих путях сертификации сделал Андрей Лысюк на конференции UISG в августе 2010.

День резервного копирования

2011-03-31T15:19:00.000+03:00

Оказывается, сегодня Всемирный день резервного копирования. Поздравляю всех, трудящихся на этой нелегкой ниве. Спасибо вам за сохранность наших фотоархивов =)

Fun of reading ISO standards

2011-03-30T22:02:00.000+03:00

(Sorry for English, Russian still not supported by Swype for Spica and I was fool enough to try an official version :)

Sometimes I think those ISO guys have some sense of humour.

In some organizations work habits or the main business have led to a specific "culture" within the organization, one which may be incompatible with the security controls.
Yeah, so true. In fact I saw few such companies. Or wait, I rather saw few dozens of them.

Vulnerability type: Organization
Vulnerability example (this means an exploitable weakness): Lack of proper allocation of information security responsibilities
Threat example (this means an evil that might exploit the vulnerability): Denial of actions.
BINGO!! Wan't do a shit unless it's in my job description :)

I don't like reading standards, but these points add some fun to it.

О том, где в ISO 27001 требования

2011-03-28T16:51:00.000+03:00

- Давно уже пора провести черту между эротикой и порнографией!

- Согласен. Вот вы, где проведете черту?

- Здесь.

- А я - здесь. Видите, сколько людей, - столько мнений.

Во истину разнообразны представления специалистов по ИБ о требованиях стандарта ISO/IEC 27001:2005. А порой даже непредсказуемы. Я в последнее время часто общаюсь на тему СУИБ, совместимых с этим стандартом и, признаться, удивлен таким разнобоем во мнениях.

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

Истина состоит в том, что требования стандарта сосредоточены в его частях 4, 5, 6, 7 и 8, и могут быть сформулированы одним предложением: Постройте СУИБ согласно модели Plan-Do-Check-Act, основываясь на результатах оценки рисков, и при помощи, где это применимо контролей из Приложения А, а где нет - ищите другие или изобретайте собственные.

Взлом RSA SecurID

2011-03-19T18:05:00.000+02:00

Все уже наверняка слышали, что 17 марта легендарная компания RSA, основанная патриархами индустрии ИТ-безопасности и производящая передовые криптографические технологии, ~~подверглась вероломному нападению~~ испытала на себе неукротимую мощь APT. Для непосвященных, APT расшифровывается как Advanced Persistent Threat, и обычно означает, что ~~взлом осуществлялся из Китая, но прямых доказательств этому пока нет~~ атака была целенаправленной, хорошо финансировалась и выполнялась мастерами своего дела.

Принимая во внимание отсутствие подробностей инцидента (известно лишь, что целью атакующих был продукт SecurID, один из признанных лидеров в области двухфакторной аутентификации пользователей), любые комментарии на эту тему являются спекуляцией. Активность конкурентов и прочих игроков на рынке безопасности выглядят не иначе, как попытки пнуть лежачего (как это сделала NSS Labs в своей аналитической записке, порекомендовав клиентам, в том числе, рассмотреть альтернативные решения по двухфакторной аутентификации).

Тем временем RSA сделала публичное заявление, проинструктировала заказчиков и затаилась в ожидании проявления последствий инцидента. (Не могу не отметить один из пунктов заявления: рекомендацию клиентам усилить парольную политику. Ирония состоит в том, что клиенты зачастую внедряют SecurID как раз для того, чтобы не париться со строгой парольной политикой.) По мере прочтения рекомендаций, между строк очень отчетливо просматривается и как ломали (We recommend customers increase their focus on security for social media applications...), и какого рода уязвимости использовали (We recommend customers re-educate employees on the importance of avoiding suspicious emails... We recommend customers follow the rule of least privilege... etc.) Но утверждать что-то наверняка все-таки нельзя: все рекомендации носят очень общий характер. RSA ограничилась намеками. В такой ситуации сложно ожидать от вендора большего.

Что нас ждет в будущем, можно только догадываться. Возможно, у SecurID очень скоро появится конкурент, производимый в Юго-восточной Азии. Вероятно, данные, полученные в результате атаки, будут использованы в масштабном нападении на одного или группу клиентов RSA, а их миллионы, причем компании со скромным бюджетом такие вещи не покупают. В настоящий момент все, что мы имеем, это подтверждения тезиса, что защититься от целенаправленной хорошо финансируемой атаки практически невозможно.

"Сильная энергетика"

2011-03-17T00:39:00.001+02:00

Часто приходится слышать что-то вроде восторженного "У него/нее такая сильная энергетика..." или "Он/она харизматичный лидер?" А может быть и с вами случается отметить такие качества в окружающих людях?

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

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

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

Иллюстрации: www.onlineshoppingideas.com

Будет день, будет Adobe 0-day

2011-03-15T11:12:00.003+02:00

Не углубляясь в детали, Adobe снова радует нас уявзимостями нулевого дня, на этот раз в Flash Player. Так как Adobe ~~тычет флэш куда попало~~ большой сторонник тесной интеграции своих продуктов, эта уязвимость наносит удар по Adobe Reader & Acrobat всех версий.

Пользователи Adobe Reader X находятся в сравнительной безопасности, потому что sandbox. Так что советую обновиться до десятой версии, если еще не.

В настоящее время по Интернету гуляет письмо, в которое вложен XLS файл, в который вложен SWF файл, который эксплуатирует данную уязвимость с целью получения контроля над ПК жертвы. [Update 18.02.2011] Microsoft опубликовала рекомендации по защите от этого конкретного метода атаки при помощи EMET. Google отреагировал обновлением Chrome.

Безопасность точек доступа WiFi в Киеве: 5176

2011-03-13T13:40:00.001+02:00

Обновлена страница, посвященная статистике настроек безопасности точек доступа беспроводной связи в Киеве. На этот раз выводы сделаны на основании базы данных, в которой сохранена информация о 5176 точках доступа WiFi.

Метод защиты	Количество
NULL	351
WEP	1417
WPA2-EAP-CCMP	36
WPA2-EAP-TKIP	17
WPA2-PSK-CCMP	1971
WPA2-PSK-TKIP	1555
WPA-EAP-CCMP	9
WPA-EAP-TKIP	42
WPA-PSK-CCMP	1247
WPA-PSK-TKIP	2173

Слайды презентации "Процедура внедрения СУИБ в Банке: основные шаги и подводные камни"

2011-03-11T11:41:00.002+02:00

3 марта в БЦ "Парус" прошла конференция "Построение СУИБ в банке - секреты и подводные камни", организованная компанией "БМС Консалтинг" при поддержке партнеров: «Microsoft», «Qualys, Inc .», «Check Point Software Technologies», «RSA The Security Division of EMC». В программе конференции у меня был небольшой методический доклад, слайды презентации которого размещаю в этом посте.

Процедура внедрения СУИБ в банке: основные шаги и подводные камни

View more presentations from Vlad Styran.

ISO 27001 (или то, во что он превратился) в редакции НБУ

2011-03-05T20:37:00.003+02:00

Уверен, не для кого не новость, что в конце прошлого года НБУ наконец-то совершил то, о чем так долго говорилось на всевозможных симпозиумах, конференциях и просто посиделках по информационной безопасности: выпустил отраслевой стандарт банков Украины СОУ Н НБУ 65.1 СУИБ:2010. Технически стандарт состоит из двух частей, которые являются переведенными и модифицированными ISO/IEC 27001 и 27002. "Модификация" состоит в основном в серии Дополнений и Пояснений, которыми пестрит текст перевода. Также, совсем недавно увидели свет Методические рекомендации НБУ по построению СУИБ и оценке рисков, которые, похоже, основываются на ISO/IEC 27003 и 27005 соответственно. По предыстории вроде бы все, теперь по сути поста.

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

<ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ />

Примеры наиболее эффектных трудностей перевода: в стандарте слова confidence, sensitivity и confidentiality переведены одинаково: конфіденційність. Это, во-первых, не совсем верно, а во-вторых, и я уже раз пять слышал это заблужнение, наталкивает читателя на мысли, что стандарт концентрируется только на конфиденциальности информации, не уделяя при этом внимание целостности и доступности, а это не совсем не так. Также, у переводчиков очень ярко получилось перевести одинаково слова shall и should, которые в стандартах, законах и аудиторских отчетах означают весьма различные типы предписаний: в случае shall требование следует выполнять без вопросов, а в случае should это и не требование вовсе, а рекомендация. В переведенном стандарте эта разница стерта и все предписания звучат именно как требования. Эта неточность порождает массу недоразумений в восприятии читателей, особенно тех, кто знает, что в оригинале 27001 является сводом требований (should встречается 11 раз, а shall – 189 раз), а 27002 - сводом практических рекомендаций (should - 1032, shall – 4).

Что касается "добавок" Нацбанка к переводу, на меня наибольшее впечатление произвела рекомендация минимальной длины пароля (6 символов) и методов безопасного удаления данных (двойное форматирование). Надеюсь, эти советы имеют под собой практические мотивы, например технические ограничения существующих legacy систем.

</ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ>

Признаюсь честно, я завершил знакомство с СОУ Н НБУ 65.1 совсем недавно, поэтому в о(б)суждении стандартов участия не принимал. Теперь, когда у меня сложилось какое-то мнение о документе, я хочу им поделиться.

Да, я полностью согласен с мнением, что стандарты не идеальны и требуют существенной до- и переработки. И номера стандартов - 1.0 и 2.0 - дают мне повод надеяться, что за первым релизом последуют версии 1.1/2.1, 1.2/2.2 и т.д., в которых документы будут улучшаться.

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

Как этим новым инструментом воспользуются банки Украины, это уже совсем другая история, так что на этом посте мои мысли на данную тему не заканчиваются. Комментарии и критика традиционно приветствуются и вызывают искреннюю благодарность.

Компромисы

2011-02-12T23:08:00.001+02:00

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

К сожалению, эта простая истина нередко понимается и трактуется неверно. Не раз (и не два, и не десять) в ответ на предложение дополнить систему средством защиты я выслушивал возражения типа "ну ты же понимаешь, что это повысит нагрузку." Выход в таком случае один: задать встречный вопрос: насколько? Без измеренного в тестовой среде прироста нагрузки такие замечания должны восприниматься как чисто теоретические предположения, коими они фактически и являются. Следом за гипотезой должны звучать факты, иначе, как говорит Джек Дэниел, "мы будем считать, что вы либо сомневаетесь, либо не уверены, либо врете."

Предупреждая еще одно распространенное заблуждение на тему вышеупомянутого баланса: отключив весь функционал системы вы не сделаете ее абсолютно безопасной. Зато нередко бывает так, что всего лишь чуточку переборщив с включенными в системе средствами защиты, ее можно превратить в непригодный для использования фортифицированный кирпич. Это плюс один повод всегда задумываться о том, какие контрмеры в системе действительно нужны из тех, которые в ней в принципе возможны.

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

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

Под настроением этой публикации.

Google Latitude

2011-01-31T06:17:00.000+02:00

Когда-то я уже делал попытку использования Google Latitude, но через какое-то время решил пока отложить, потому что только пятеро из моих знакомых использовали этот сервис. Вчера я надумал сделать вторую попытку, после чего на мой почтовый ящик Gmail пришло уведомление следующего содержания:

Hi,

To protect your privacy we would like you to know that Google Latitude is running on your mobile device and reporting your location.

If you didn't enable this or want to stop reporting your location, please open Latitude privacy settings or sign out of Latitude. To learn more, visit the Latitude Help Center.

Thanks,

Google Latitude Team

Машинный перевод - здесь.

Очень мило со стороны Google оповещать пользователей о включении в их учетной записи такой чувствительной функции, как Google Latitude. Для справки: Lattitude позволяет пользователям делиться информацией о своем расположении, отражая на Google Maps данные устройства позиционирования в КПК или мобильном телефоне. Примерно так же, как в foursquare, только в автоматическом режиме.

С другой стороны, я не припомню, чтобы такое уведомление приходило после моего первого включения сервиса. То есть, вполне возможно, что это ж-ж-ж здесь не спроста. Осмелюсь предположить, что кто-то (ревнивый муж или руководство логистической компании) уже попытались использовать ресурсы Google Latitude в сомнительных целях - для бюджетной GPS-слежки. Хотя, разумеется, все это только догадки.

Уязвимость в ОС Windows XP и выше

2011-01-30T21:13:00.000+02:00

Уязвимость под названием "MHTML Script Injection" (неинтересная ссылка на непонятный Advisory, подготовленный пиарщиками Microsoft) присутствует именно в ОС Windows всех версий начиная с XP. Хотя из названия может сложиться впечатление, что уязвим браузер Internet Explorer, это не так.

Тем не менее, основным вектором атаки остается Internet Explorer: для успешной компрометации цели атакующему нужно ~~заставить~~ убедить жертву посетить специально подготовленный веб-сайт. То есть, для рядового пользователя Интернет ничего не меняется: нажми на ~~кнопку~~ ссылку и получи Трояна в подарок. От версии IE тоже ничего не зависит.

По этой ссылке (интересная ссылка на блог классных парней из Microsoft Security Response Center) можно разузнать как уберечься от этой напасти и даже как проверить защищена ли ваша система. Для установки спасительного пакета контрмер просто скачайте и запустите файл, клацнув на дядьку с гаечным ключом.

New York Times приоткрывает тайну Stuxnet

2011-01-17T21:56:00.001+02:00

Есть основания полагать, что Stuxnet таки оказался совместной американо-израильской разработкой, предназначенной для создания препятствий иранской ядерной программе. Сегодня NYT недвусмысленно дал понять, что эта версия -- официальная, упомянув о недавних гордых заявлениях Моссада и госдепа США об откате Ирана на несколько лет назад в его ядерных исследованиях.

Хочу прокомментировать эту гипотезу. Вопреки порожденной панической моде на "кибер войны", так славно подогреваемой лоббистами, Stuxnet демонстрирует новый подход к решению стратегических проблем. В 2003 под предлогом подавления глобальной ядерной угрозы, против Ирака была развернута масштабная военная кампания. В 2010 ей предшествует интеллектуальная атака, узко сфокусированная на конечной цели. Таким образом количество возможных жертв сводится к минимуму, хотя избежать их вовсе не удалось: Иран казнил группу граждан, подозреваемых в способствовании проникновения Stuxnet на объект.

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

Вдобавок к сказанному, Bruce Schneier о Stuxnet.

Забавные фото банкоматов (и не только)

2011-01-17T14:59:00.000+02:00

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

Фальшивые банкоматы

2011-01-15T00:26:00.005+02:00

Про скимминг наверняка слышали многие, этот вид банковского мошенничества в Украине процветает уже давно. Если не слыхали, то суть следующая: в действующий банкомат монтируется специальное оборудование, а именно сканер данных магнитной ленты и поддельная PIN-клавиатура, с помощью которых осуществляется кража аутентификационной информации клиента. Далее эта информация обычно либо используется для изготовления поддельной карты, либо продается на черном рынке. Но хватит о скиммерах, есть новости по-свежее.

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

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

На фальшивом банкомате не было ни реквизитов банка, ни даже его названия. Только реклама беспроцентного снятия наличности, короткий список банков и логотипы платежных систем VISA и MasterCard. Вывод: не стоит поддаваться рекламе бесплатного сыра. Также, обращайте внимание на реквизиты владельца банкомата: на банкомате должно быть размещено название банка и контактные телефоны сервисного центра.
При попытке осуществления операции клиенту возвращался отказ типа "нет связи с банком". Это должно наталкивать на подозрения: таким образом очень часто маскируется сбор регистрационных данных на веб-сайтах и в программном обеспечении, а теперь вот и банкоматы поспели. Следовательно, в случае получения такого ответа от банкомата, стоит насторожиться.
На чеке, вручаемом клиенту, отсутствовала информация о банке и транзакции. На такой минимализм тоже следует обращать внимание, по правилам чеки банкоматов должны содержать всю идентификационную информацию о банке и транзакции, плюс немного рекламы. При получении такого "сокращенного" чека следует немедленно связаться с банком и сообщить ему об обнаружении подозрительного банкомата. Благо, практически в каждом банке есть служба безопасности, в чьих силах продолжить расследование и устранить угрозу. Что касается вашей, то ее после такого случая следует заблокировать и сменить PIN-код, а еще лучше -- перевыпустить.
Также, обращайте внимание на внешнее состояние банкомата. Признаться, по фотографиям этого чуда техники у меня сложилось впечатление, что его слепили из подручных материалов. Банкомат должен быть в хорошем состоянии, без зазоров и щелей, на нем не должно быть постороннего оборудования: торчащих антенн, выходящих из корпуса проводов, защитного кожуха над клавиатурой и т.д. При обнаружении лишних предметов сразу же звоните в колл-центр банка.
(Обновлено 15.01.2011 15:22) Прекрасный способ обнаружения подставного банкомата был предложен в комментарии к посту в Google Buzz. В том счастливом случае, если ваш банк предлагает услугу СМС-банкинг, обязательно настройте ее и при использовании подозрительного или не проверенного банкомата во время первой тестовой транзакции вводите неправильный PIN. В случае нормальной работы банкомата, в течение минуты-двух банк пришлет вам смску об отказе в аутентификации транзакции. Если этого не случиться, пользоваться таким банкоматом не стоит. Примечание: этот способ не панацея, данные магнитной ленты с карты сняты будут. Но изготовленная при помощи этой информации фальшивая карта будет непригодна для снятия денег в банкомате, таким образом риск потери денег будет существенно снижен.

Граждане, будьте бдительны. Речь идет о ваших деньгах.

Стандарты безопасной настройки

2010-12-29T17:41:00.000+02:00

Большинство программных продуктов, будь то операционные системы, системы управления базами данных, или приложения, поставляются производителями с так называемыми настройками по умолчанию (default settings). И не секрет, что зачастую эти настройки выбраны таким образом, чтобы повысить удобство использования программного обеспечения, а не его безопасность. Это естественно, так как именно удобство использования, а не безопасность, определяет популярность продукта на рынке. По крайней мере, так было до недавнего времени.

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

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

В своей практике я часто обращаюсь к материалам, размещенным на сайте The Center for Internet Security, www.cisecurity.org. Это такая международная организация, членами которой являются другие организации, как государственные, так и коммерческие, пользующиеся авторитетом в области ИТ-безопасности. Например, SANS, Carnegie Mellon University, NASA, NIST, EMC2, IBM, HP, McAfee, Rapid 7, Qualys, Smantec, Tenable etc. На сайте в свободном доступе выложены стандарты по безопасной настройке самых разнообразных продуктов. Также, за дополнительную плату в виде членских взносов, можно получить доступ к автоматическим средствам проверки конфигураций на соответствие этим стандартам.

Также, руководства по безопасной настройки можно найти на сайте NSA.gov. Здесь информации больше, - для настройки некоторых типов продуктов и технологий представлено несколько руководств, - так что есть из чего выбрать.

Документы доступные на этих сайтах не раз сослужили мне добрую службу. Надеюсь, будут полезны и вам.

Уязвимость нулевого дня (0-day) в Internet Explorer всех версий

2010-12-27T14:53:00.002+02:00

В преддверии Нового года хакеры порадовали фишеров: опубликована актуальная 0-day уязвимость во всех стабильных версиях Internet Eplorer (ссылка на демо-ролик). Более того, соответствующий эксплойт добавлен в Metasploit Framework, следовательно, теперь каждый script kiddie сможет им воспользоваться. Очень опасно и несвоевременно, с учетом того, что активность фишеров в период рождественских и новогодних праздников традиционно возрастает в несколько раз. Имея на вооружении client side уязвимость такого калибра, кибер-мошенники смогут существенно повысить свои шансы на успех.

Среди особенностей этой уязвимости ярко выделяется тот факт, что воспользоваться ею можно в обход обоих инструментов обеспечения безопасности приложений, выгодно отличающих Windows Vista & Windows 7 от их предшественниц. Да-да, DEP и ASLR против этого эксплойта не работают. Так случилось потому, что DLL библиотеки в Windows вправе самостоятельно "решать", используют они DEP/ASLR, или нет.

Риск "попасть под раздачу" может быть несколько снижен c использованием утилиты Microsoft Enhanced Mitigation Experience Toolkit (EMET) для настройки принудительного использования инструментов безопасности приложениями и разделяемыми библиотеками. Для этого следует скачать, установить и запустить EMET 2.0. Если желаете рискнуть - в настройках "Configure System" выберите в пункте "Profile Name" значение "Maximum Security Settings". Предупреждение: есть сигналы о том, что после применения настроек глобально - ко всей системе - наблюдаются проблемы с запуском отельных приложений и даже с загрузкой операционной системы. Подтвердить или опровергнуть это не могу, так как у меня на Windows 7 x64 "все работает".

Более осторожные пользователи могут настроить Internet Explorer, так сказать, персонально. Для этого идем в меню "Configure Apps", добавляем в открывшееся окошко полный путь к iexplore.exe и отмечаем все доступные галочки. Ну и как же без перезагрузки. Расположение файла iexpore.exe может отличаться для разных версий Windows, обычно это "C:\Program Files\Internet Exporer\iexplore.exe".

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

Всех с наступающим Новым годом!

Источник оригинальной новости: Krebs on Security

Предотвращение, обнаружение и реагирование

2010-12-17T23:16:00.002+02:00

Как ни крути, а ничего кроме этих трех приемов мы сделать не можем. Это касается безопасности вообще, не только информационной. Действие угрозы (известной также как "нежелательное событие", "инцидент" или "актуализированный риск") можно либо А) предотвратить, либо Б) обнаружить и отреагировать на нее надлежащим образом.

Естественно, лучше всего угрозу предотвратить. Не наступившее нежелательное событие не вызовет нежелательных последствий, следовательно никто и ничто не пострадает. На первый взгляд предотвращение -- лучшая из трех тактик защиты. Сложности начинаются, когда заходит речь о деньгах. Дело в том, что предупредительные (превентивные) контрмеры (контроли) обходятся дороже всего. Следовательно, эффективность превентивных контролей низка; хоть, с одной стороны, они способны устранить урон до его возникновения, при этом стоимость этого устранения очень велика, и не исключено, что превышает размер возможного урона. Не забывайте, также, что многие превентивные контроли никогда не срабатывают, так как призваны предотвращать редкие, но очень существенные угрозы.

В добавок, идеальных контрмер не существует, поэтому даже самые тщательно спланированные превентивные контроли иногда ломаются. Поэтому, руководствуясь принципом defense in depth, всегда следует подкреплять предупредительные контрмеры детективными. То есть, постоянно следить за происходящим, стараясь выявить инцидент на ранних стадиях.

Естественно, само по себе выявление особого смысла не имеет. На выявленный инцидент нужно реагировать, а для этого нужно быть к нему готовым. То есть, не просто написать процедуру управления инцидентами ИБ, как того требует ~~его величество~~ ISO/IEC 27001, но разработать подробный план действий в случае возникновения инцидента, а также распределить роли в этом процессе, назначить координатора и регулярно проводить тренировочные учения. Эффективна лишь та подготовка, в ходе которой участники команды реагирования выполняют запланированные действия в условиях, максимально приближенных к "боевым". В противном случае инцидент застанет команду врасплох, и реакция будет сумбурной, неорганизованной и неэффективной.

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

Видео: безопасная настройка WiFi роутеров Linksys и D-link

2010-12-05T20:48:00.002+02:00

D-link и Linksys являются наиболее популярными поставщиками беспроводных маршрутизаторов, используемых Киевлянами. В этот пост я встроил видео ролики, демонстрирующие как безопасно настроить роутеры этих линеек.

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

Демонстрация безопасной настройки роутеров Linksys.

Демо по безопасной настройке D-link.

Безопасность точек доступа WiFi в Киеве: 635

2010-12-05T16:30:00.001+02:00

После нескольких дней перемещения по городу, обновляю информацию из этого поста. На этот раз в моей базе 635 точек доступа беспроводной связи. Статистика следующая.

Метод шифрования	Качество защиты	Количество	Процент
WEP	Low	167	26,2992126
WPA-PSK-TKIP	Medium	134	21,1023622
WPA-PSK-TKIP+CCMP	Medium	129	20,31496063
WPA2-PSK-TKIP+CCMP	High	104	16,37795276
WPA2-PSK-CCMP	High	68	10,70866142
Open	Low	55	8,661417323
WPA2-PSK-TKIP+CCMP-preauth	High	49	7,716535433
WPA2-PSK-TKIP	High	31	4,881889764
WPA-PSK-CCMP	High	21	3,307086614
WPA2-PSK-CCMP-preauth	High	10	1,57480315
WPA2-PSK-TKIP-preauth	High	7	1,102362205
WPA2-EAP-CCMP-preauth	High	5	0,787401575
WPA-EAP-TKIP	Medium	3	0,472440945
WPA-EAP-TKIP-preauth	Medium	1	0,157480315
WPA2-EAP-TKIP-preauth	High	1	0,157480315
WPA2-EAP-TKIP+CCMP	High	1	0,157480315

Как видите,

WEP лидирует с 26%, а это значит, что четверть всех точек доступа защищены весьма условно и могут быть взломаны злоумышленником, обладающим минимальной квалификацией;
8,6% беспроводных сетей являются открытыми;
Еще 41% -- точки доступа, поддерживающие WPA-PSK-TKIP, потенциально небезопасны и могут быть скомпрометированы квалифицированным злоумышленником, располагающим достаточными средствами.
При этом 47% точек доступа защищены хорошо -- при условии, что администратор об этом позаботился.

Напоминаю, сумма процентов не равна 100, потому что одна точка доступа может поддерживать несколько типов защиты.

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

Даже если вам все равно, кто и для чего пользуется вашей беспроводной сетью, настройте на точке доступа шифрование WPA2+AES (он же WPA2-PSK-CCMP) и изоляцию клиентов, так чтобы и трафик шифровался, и прослушать друг друга они не могли. А ключ доступа либо выдавайте сами по запросу, либо сделайте таким же, как SSID, то есть, имя беспроводной сети.

Очень изящное решение я наблюдал однажды в Москве. Там беспроводная сеть одного ресторанчика называлась его именем (имя уже не помню) плюс пароль доступа. При просмотре доступных сетей клиент видел нечто подобное: "Cafe WiFi. Password: welcome2cafe". При этом сеть была защищена WPA2+AES.

Слайды моей презентации на UISG #5

2010-12-05T15:16:00.001+02:00

Пятая конференция Украинской группы специалистов по информационной безопасности прошла успешно (UISG). Больше полезной информации, а главное -- растет внимание со стороны профессионалов; в этот раз регистрацию прошли более пятидесяти участников, хотя, как мне кажется, их было намного больше -- по меньшей мере 75.

Ваш покорный слуга выступал с небольшим докладом, слайды к которому публикую в этом посте. Доклад называется "Социальные аспекты информационной безопасности"; ни к социальным сетям, ни к социальной инженерии материал прямого отношения не имеет. Хотя, как оказалось после выступления, участники были весьма заинтересованы послушать что-нибудь на обе темы.

Социальные аспекты ИБ

View more presentations from Vlad Styran

Более подробная информация о материалах выступлений будет доступна позже -- на сайте www.uisg.org.ua. Если вы живете в Украине и/или занимаетесь в ней информационной безопасностью, рекомендую присоединиться к группе UISG в LinkedIn.

То, что не попало в список рекомендованной литературы по информационной безопасности

2010-12-01T15:24:00.004+02:00

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

www.schneier.com

Вчера я от нее избавился. Теперь пост со списком рекомендаций обновлен и дополнен пунктом №0 - книгами Брюса Шнайера Secrets & Lies и Beyond Fear. (Полные названия: Secrets & Lies - Digital Security in a Networked World и Beyond Fear - Thinking Sensibly about Security in an Uncertain World, by Bruce Schneier).

Тем, кто слышит эту фамилию впервые, советую поскорее познакомиться с Брюсом на сайте http://www.schneier.com. Его блог обязателен к регулярному прочтению, но если нет времени следить за публикациями (а их он делает немало), подпишитесь на Crypto-Gram Newsletter и получайте самое важное раз в месяц. Брюс Шнайер представляет собой уникальное явление, я даже не стану пытаться охватить словами его вклад в развитие индустрии информационной (и не только) безопасности. Просто прочтите. Идея стать специалистом по информационной безопасности возникает после просмотра кинофильма "Хакеры" или эпизода в "Терминатор 2", в котором Джон Коннор взламывает банкомат при помощи "Атари". Решение стать специалистом по информационной безопасности принимают после прочтения книг Шнайера.

www.schneier.com

Не важно, какую вы прочтете первой, хотя я бы рекомендовал Secrets & Lies. После нее понятны основные принципы дисциплины. Beyond Fear более поздний труд, в нем меньше об информационной и больше о безопасности. Разница между выходом книг - всего три года, но за эти три года случился 9/11.

Все, аж полегчало. Читайте на здоровье. И перечитывайте регулярно - помогает не забывать о главном.

Конференция Ukrainian InfoSec Group ver. 5.0

2010-12-01T12:21:00.000+02:00

UISGCon в пятницу, третьего декабря, угрожает стать самым познавательным собранием Украинской группы специалистов по информационной безопасности. С программой мероприятия можно ознакомиться по ссылке, а вот ссылка на событие в LinkedIn для предварительной регистрации.

Я буду выступать с небольшим историко-популярным экспресс-докладом, цель которого, скорее, не поделиться знаниями, а обратить внимание слушателей на некоторые любопытные особенности индустрии информационной безопасности.

Надеюсь, там и увидимся.

Оффтопик: вопросы к (или от?) Google

2010-12-01T08:37:00.001+02:00

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

Итак,

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

почему путин краб - я был удивлен
почему я дура - =)
почему не работает контакт
почему небо голубое

от чего умер черномырдин
от чего выпадают волосы
от чего чернеет серебро
от чего предохраняет полуда - действительно, от чего?

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

кому зачем
кому принадлежат слова «пока дышу надеюсь»
кому зачем текст - популярная, оказывается, песня
кому вниз

как жрать суши
как скачать музыку с контакта
как правильно целоваться
как удалить страницу в контакте - вопрос, автоматически возвращающий этот пост в тему ИБ

что приготовить
что почитать
что такое любовь
что делать

кто первым использовал термин «алкоголь» - +1 удивление
кто я - это вообще жесть
кто тебя создал такую
кто лидер проекта request - blink... blink...

чему учат в школе
чему равен дюйм
чему равно число пи - не легче просто pi набрать?
чему равен 1 дюйм - хорошее уточнение

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

кем я был в прошлой жизни
кем я была в прошлой жизни
кем ты был в прошлой жизни
кем быть на хэллоуин - облом такой, да?

чем янукович собрался искоренять разворовывание госсобственности - хорошо, хорошо...
чем чистить серебро - ... хорошо живем!
чем заняться
чем открыть djvu - ну а что, меня жена спрашивает регулярно...

от кого мы произошли - нормально, со школы запамятовали?
от кого произошли птицы - это чтобы понять, почему мы не летаем, как они?
от кого родила кабаева - кабаева родила?
от кого мы произошли мулдашев - видать, большой знаток этого дела

откуда берутся дети
откуда беруться дети - хорошо хоть правильный вариант лидирует
откуда берутся сопли
откуда у путина синяк - бамц!

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

В общем, где-то так.

Безопасность точек доступа WiFi в Киеве

2010-11-30T19:32:00.001+02:00

Разрешите представить вашему вниманию результаты небольшого исследования. Несколько дней я, не жалея батареи в мобильном телефоне, собирал информацию о точках доступа беспроводной сети в городе Киеве. В итоге мной была собрана информация о 483 точках доступа WiFi, которая включала в том числе данные о типе шифрования настроенном на оборудовании. Не удивительно, что именно информация о защите беспроводных сетей интересовала вашего покорного слугу.

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

Тип шифрования	Количество точек доступа, %
Шифрование отсутствует	3
WEP	13
WPA-PSK-CCMP	3
WPA-PSK-TKIP	28
WPA-PSK-TKIP+CCMP	12
WPA2-PSK-CCMP	9
WPA2-PSK-TKIP	18
WPA2-PSK-TKIP+CCMP	14

Для того, чтобы связать полученные результаты с количеством точек доступа, я обобщил информацию о шифровании и сделал следующие выводы.

26% точек доступа настроены на использование слабого протокола защиты, или же предоставляют открытый доступ и не используют шифрование.
68% точек доступа настроены с использованием потенциально небезопасного протокола шифрования. Например, существует метод практической атаки на точку доступа, в которой используется шифрование типа WPA-PSK-TKIP и при этом настроены параметры Quality of Service (QoS).
68% (да, вот такое совпадение) точек доступа настроены с использованием надежных методов шифрования, и в случае выбора администратором сильного пароля могут предоставлять безопасное подключение.

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

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

Под занавес, несколько забавных фактов.

Почти треть имен точек доступа настроены по умолчанию. И да - dlink лидирует.
Несколько имен точек доступа выглядели как номера мобильных телефонов. Судя по всему, они там давно, так как начинаются с восьмерки.
Всего 8% обнаруженных точек доступа используют методы аутентификации корпоративного уровня.

Очень полезную глобальную статистику можно посмотреть на этом сайте.

Методы социальной инженерии: проникновение в офис

2010-11-28T16:30:00.004+02:00

Когда-то я писал в этом блоге шуточный пост "Топ-10 инструментов социального инженера". Речь шла о способах получения конфиденциальной информации с использованием методов социальной инженерии. Естественно, на получении конфиденциальной информации задачи социального инженера не ограничиваются.

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

Не буду надолго останавливаться на теоретической стороне вопроса. Скажу лишь, что в основе успеха атак подобного рода (а мы говорим о физическом проникновении в офис) лежит естественное стремление людей быть полезными друг другу. Большинство приемов, используемых мошенниками, промышленными шпионами и социальными инженерами, эксплуатируют именно это человеческое свойство. Множественные вспомогательные методы (такие как отвлечение внимания, создание ощущения срочности или общности с окружающими и т.д.) лишь усиливают основной принцип: общественной пользы.

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

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

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

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

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

Третий пример, классический: разносчик пиццы. Согласно необъяснимому феномену, человека со стопкой картонных коробок с ароматным содержимым пропускают всегда, везде и всюду. Правда, иногда бывают исключения, например режимные объекты и компании с четким упором на безопасность.

Список примеров можно продолжать: продавец дешевой бижутерии и белья, адепт сетевого маркетинга, сервис торговых автоматов, оператор видеосъемки и так далее, и тому подобное. Признак, который объединяет большинство из них -- люди здесь не просто так, а по делу, причем в этом деле заинтересован кто-то из сотрудников компании. Бездельникам никто не помогает -- это факт. Людям, честно выполняющим свою работу (прямо как мы с вами!) да еще и во благо знакомых или близких нам людей, -- помогают практически всегда.

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

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

Второй шаг: в любом случае (срочно, важно, секретно...) свяжитесь с сотрудником компании, к которому пришел посетитель. Не смогли связаться -- посетитель ожидает в приемной под вашим зорким наблюдением.

Третий шаг: будет лучше, если принимающий сотрудник встретит посетителя в вашем присутствии. Если это затруднительно, посетителя следует провести; согласно золотому правилу, никто из посторонних не должен находиться на территории компании без сопровождения. Еще заблудится -- оно вам надо?

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

Берегите себя.

OAuth и доступ к вашим учетным записям в социальных сетях

2010-11-22T22:49:00.001+02:00

Многие слышали, что такое OAuth, некоторые наверняка даже разобрались, что это такое. Это похвально, но поспешу отметить, что в рамках данного поста эти знания не понадобятся. Более того, речь пойдет о социальных сетях, так что обсуждать мы будем только частицу богатых возможностей OAuth.

OAuth используется для предоставления доступа к данным. Доступ этот может предоставляться согласно множества сценариев. Например, вы можете зарегистрироваться на сайте digg.com используя учетную запись Google, Facebook или Twitter. Также, вы можете предоставить доступ к вашей адресной книге в Gmail, чтобы найти ваших знакомых пользующихся Facebook или LinkedIn. Еще один распространенный пример: вы можете разрешить приложению размещать в социальных сетях интересную на ваш взгляд информацию. Или -- и этот вариант более распространен -- вы можете предоставить одной соцсети возможность размещать информацию в других соцсетях (так нередко сообщения в Twitter мгновенно отображаются в Facebook, LinkedIn, Windows Live и пр.)

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

Я рекомендую изредка, хотя бы раз в пол года, заглядывать в списки разрешенных связей в ваших профилях социальных сетей и удалять все лишнее. Не сомневайтесь, за выбором дело не станет, многие из предоставленных привилегий вы удалите незамедлительно. Это и давно не используемый веб-клиент для Twitter, уже год как удаленное приложение для iPhone т.д. и т.п. Соответствующие настройки на сайтах найти не сложно, вот ссылки в Facebook, Twitter, LinkedIn и Google. [Update] По этой ссылке можно просмотреть список компьютеров, имеющих доступ к вашим Dropbox-аккаунтам и их содержимому.

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

О позитивной коммуникации, в пятницу

2010-11-12T16:47:00.000+02:00

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

Теперь о безопасности. Может быть кому-то интересно, вот здесь мне задали несколько вопросов об эффективной коммуникации между ИБ и HR. Материал на английском.

Всем приятных выходных.

Почему не следует удалять неактивных пользователей

2010-11-10T21:22:00.001+02:00

Я не рекомендую удалять учетные записи уволившихся сотрудников, ровно как и учетные записи компьютеров из Active Directory. И вот почему.

Во-первых, сохраняя учетную запись уволившегося сотрудника, вы исключаете возможность так называемого повторного использования (object reuse). Это такая ситуация, в которой права, ранее выданные уволившемуся пользователю, автоматически назначаются новому пользователю с таким же именем. В крупных компаниях такие случаи не редки, представляете сколько может быть spetrenko-в среди 10,000 сотрудников? Эта проблема возникает в основном потому, что некоторые нерадивые программисты учат свои, с позволения сказать, программы авторизировать пользователей... по имени. Оставьте spetrenko в покое, просто заблокируйте его, удалите из всех групп безопасности и переместите в хранилище подобного рода учетных записей. Для этого в Active Directory можно создать отдельный Organizational Unit (OU). Если, спустя время, к вам на работу нагрянет еще один С. Петренко, назовите его spetrenko2 или дополните логин инициалом отчества.

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

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

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

(Не)безопасность социальных сетей

2010-10-21T22:14:00.000+03:00

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

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

Во-первых потому, что когда речь заходит о приватности, мы, ~~циничные и нахальные зануды~~ специалисты по информационной безопасности, не имеем права указывать людям что класть, а что не класть в Facebook/Vkontakte/Одноклассники и пр. Что за манера такая -- учить других распоряжаться их личной жизнью?

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

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

Собственно, все. Несогласных прошу ~~за стол~~ в комменты.