Три факта о квантовой криптографии

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

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

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

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

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

MS10-015 2.0

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

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

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

Управление рисками с учетом человеческого фактора

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

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

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

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

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

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

Другой пример -- мотивировать процентами премии и отгулами участие в программе информационной безопасности. Обнаружил инцидент -- получи +5%; предотвратил инцидент -- +10% и отгул; и так далее. Разумеется, такой подход следует обсуждать с руководством и закладывать в бюджет нужные средства. (Признаюсь честно, такое я в своей жизни видел только однажды и, к сожалению, не у нас в стране).

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

Управление обновлениями (Patch Management)

В начале века, после нескольких ошибок, совершенных компанией Майкрософт в ходе первых попыток наладить систему обновлений ОС Windows, в умах миллионов ИТ-специалистов закрепился один очень опасный стереотип. Дело было примерно так: молодой и неотесанный Майкрософт выдал на гора несколько патчей, которые предварительно, чего уж греха таить, не очень усердно протестировал. В результате, сотни тысяч серверов и ПК по всему миру получили обновления, которые, при взаимодействии с существующими до их установки программами и настройками, привели операционные системы к полному краху. Из этого неприятного эпизода ИТ-специалисты сделали совершенно неправильный вывод. Вместо того, чтобы в дальнейшем тщательно тестировать обновления перед их установкой в продуктивной среде, они решили (где там наш easy button?..) отказаться от установки обновлений вообще. Этот глубокомысленное умозаключение ярко проиллюстрировано в старом анекдоте про Билла Гейтса, его сына и ежедневное путешествие солнца с востока на запад: "Пока все работает, ничего не трогай." Оно настолько широко присуще ИТ-специалистам старой закалки, что я даже не постесняюсь добавить его в категорию "ctrl+shift".

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

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

Вот и после последнего "вторника обновлений" ("Patch Tuesday") по рядам сисадминов пронесся недобрый шепот. Видите, мол, что ваш MS10-015 натворил, мы же вас предупреждали... Все же работало! Что случилось на самом деле, и почему многие компьютеры отвечали на установку обновления отчаянным Blue Screen of Death, пока точно не известно. Но по последним данным, Майкрософт не исключает, что такой результат стал следствием несовместимости обновления с якобы установленным в операционной системе руткитом (rootkit). Если это правда, представляете каким ударом для противников обновлений безопасности это может стать?

Итого, каковы позитивные выводы. Не обновляемая система намного более уязвима к атакам. То есть, обновляться нужно. Запятая. Если опасаетесь негативных последствий применения обновлений -- тестируйте их на тестовых ОС перед установкой в продуктивную среду. Точка.

Теперь о том, как организовать процесс тестирования и установки обновлений. Для тестирования очень удобно использовать операционные системы, установленные на виртуальных машинах: благо, VMWare Server бесплатен и потрясающе прост в использовании. Также, стоит отметить, что не все обновления ОС являются обновлениями безопасности. В принципе, какие обновления к чему относятся можно посмотреть в коротком описании к каждому патчу, предлагаемом к установке при помощи Microsoft Update. С другой стороны, эти описания малоинформативны и не содержат никакой классификации ("Low", "Medium", "High"). Для установки обновлений в "ручном" режиме, Майкрософт предлагает утилиту Microsoft Baseline Security Analyzer, о которой я уже неоднократно писал в этом блоге. В отличие от Microsoft Update, MBSA ранжирует обновления безопасности в зависимости от критичности той уязвимости, которую это обновление исправляет.

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

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

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

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

[19.02.2010] Update Спустя неделю после обнаружения проблемы, в Майкрософт подтвердили, что BSoD после установки MS10-015 вызван присутствием в системе вредоносного ПО Win32/Alureon. Детали: http://news.cnet.com/8301... http://blogs.technet.com/msrc...

Аспекты безопасности Google Buzz

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

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

1. Естественно, содержимое почтового ящика. Надеюсь, этот факт ни у кого сомнений не вызывает.
2. По некоторым соображениям, -- список контактов. Мне, например, совсем не хочется, чтобы кто попало знал о том, с кем я переписываюсь приватно. Надеюсь, я не одинок.
3. Собственно, контент, который доступен вашим читателям или фоловерам (followers). Теоретически, это все, что размещается вами на сайтах, значащихся в вашем Google-профиле.

Теперь подробнее.

Сначала о хорошем. Слава яйцам, добраться до почты фоловеры, будто бы, пока что не могут. Это радует.

Теперь о плохом. Как только вы появляетесь в Google Buzz, или вернее, Google Buzz появляется у вас, вы автоматически становитесь фоловером всех ваших Gmail-контактов, а также пользователей, которые делятся с вами новостями в Google Reader. С одной стороны, ничего плохого в этом нет. С другой -- по аналогичному принципу, а также по собственной инициативе, все они в ответ фоловят вас, даже если раньше они о вашем существовании и не догадывались. Обратите внимание на то, что ваши сообщения в Buzz и комментарии к ним видны всем вашим незаблокирванным фоловерам. То есть, почитав вашу ленту на протяжении какого-то времени, возможно составить достаточно полный список ваших постоянных контактов. Но есть и приятная новость: это регулируется. Фоловеров можно редактировать и блокировать. Откройте список по ссылке справа над полем ввода, там перечислены ваши читатели. Список тех из них, кого вы читаете в ответ, можно править прямо здесь. Запретить читать вас можно открыв профиль нежелательного пользователя и нажав в нем на кнопку "Block ". Тем не менее, это не защитит ваш контент (но уже без комментариев) полностью, -- он все еще будет доступен к просмотру в вашем профиле. 

О контенте. В Buzz попадает все, что вы создаете при помощи Google. Это, на вскидку, Picasa, YouTube, Reader и Blogger. Также, там появятся ваши посты на присоединенных сайтах, список которых можно править по ссылке http://www.google.com/profiles/me. Пока не известно, что Гуглу вздумается добавить в будущем. Логично ли размещать в Buzz публичные события в Google Calendar или опубликованные документы Google Docs? Поживем -- увидим, а пока откройте и перечитайте список ресурсов, которые публикуете в Buzz (сразу над полем ввода, справа от вашего имени пользователя). Возможно, каким-то из них не обязательно там появляться.

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

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

Update [20090214] Дополняю пост ссылкой на статью, в которой рассказывается, как оключить отображение ваших подписчиков и подписок в вашем профиле.

Еще раз о доменных админах

Услышал недавно два весьма забавных заблуждения.

Заблуждение первое, молодое и бестолковое. В беседе с одним молодым коллегой пытался выяснить, что же по его мнению является успешным результатом тестирования на проникновение. Конкретного ответа не получил, вернее получил несколько неконкретных. Все они сводились к идее "root the box", то есть получению привилегированных прав доступа к той или иной системе. Окей, говорю я, получил ты root, что дальше? В ответ изумленный взгляд и полное недоумение: как что дальше? Все! Разве этого мало?

Мало. Представьте себе совершенно неосведомленного в вопросах ИТ (а тем более ИБ) генерального директора крупной (или не очень) компании. Как вы думаете, какое на него произведет впечатление заявление о том, что вам удалось получить доступ к учетной записи доменного администратора? Да никакого. У него этих доменных админов хоть пруд пруди, одним больше, одним меньше... Теперь другая ситуация, вы сообщаете ему, что вам удалось получить доступ к БД заказчиков и поставщиков, ERP-модулю заработной платы и кадрового учета, историческому хранилищу информации об обработанных кредитных картах... Да хотя бы к его корпоративному почтовому ящику! Скорее всего, эффект будет совершенно противоположным. Во втором случае бизнес-риски, сопряженные с получением доступа (не всегда обязательно -- привилегированного), намного более очевидны. Именно поэтому критерием успешности теста на проникновение очень часто является получение доступа к бизнес критичным данным, а не просто получение доменного админа или root-а. Разумеется, административный аккаунт в этом деле не помешает, но он далеко не всегда необходим. Например, обладая доступом к ПК главного бухгалтера, о доменном админе обычно можно уже не беспокоиться.

Мнение второе, закоренелое и самоуверенное. Полная противоположность предыдущему: ну и что, что у хакера есть доменный администратор? Что с того? Все наши критичные данные находятся на супер-защищенных серверах под управлением UNIX, да еще и в базах данных под не менее защищенным (ха-ха) Oracle. Я не стал обсуждать отдельные аспекты безопасности компании Oracle, в этом конкретном случае это, вероятно, было бы бесполезно. Вместо этого я тонко намекнул, что доменный администратор может установить любое ПО на рабочую станцию UNIX-администратора или Oracle DBA. В том числе и keylogger или sniffer. В ответ оппонент с гордостью заявил, что на каждом компьютере в его компании установлен мега-крутой антивирус. После моего замечания о том, что доменный админ скорее всего обладает правами на изменение настроек этого антивируса, гордости немного поубавилось.

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

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

Offtopic: выборы в Украине

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

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

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

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