Страница:
Netscape обычно предлагала 1000 долларов (и тенниску в придачу) в награду нашедшему дефект в безопасности своего программного обеспечения. Было выписано всего несколько чеков, однако в 1997 году датский хакер нашел прореху в системе безопасности и потребовал большие деньги. Дело обернулось так, что он не получил своих денег: его описание эффектов, связанных с программными ошибками, позволило инженерам Netscape воспроизвести и устранить их и без его помощи. В 2000 году французский исследователь обнаружил, как взломать систему безопасности смарт-карт СВ (Groupement des Cartes Bancaries). Затем, по сведениям из разных источников, он то ли предложил свои услуги, то ли занялся шантажом. В конечном счете он был арестован и осужден условно.
Безопасность рождается в соперничестве, даже в академических «башнях из слоновой кости». Кто-то предлагает новую схему: алгоритм, протокол, техника; другой взламывает ее; кто-то третий все восстанавливает и т. д. Все превращается в забаву. Но когда дело касается уже выпущенных и используемых систем, это может обернуться мошенничеством. Действительно ли выгода от огласки нападения перевешивает возрастание угрозы со стороны противника, получившего сведения о таких возможностях? (На языке Агентства национальной безопасности это называется «выпуском акций».) Почему компания должна наживаться на работе исследователя? Будет ли компания игнорировать проблему до тех пор, пока исследователь не обнародует данные? Заботит ли самого исследователя реакция публики? В любом случае, как вести себя исследователю?
Этот последний вопрос никогда не имел должного обсуждения. Публикация слабых мест безопасности – это своего рода «атака ради огласки»: исследователь хочет увидеть свое имя в газете. Иногда такие сведения разглашает или консультант по вопросам безопасности, или служащий компании, которая занимается оценкой уязвимости или предлагает средства защиты сети. Это особенно верно, если новость появилась в прессе; сообщение в PR Newswire или Business Wire дорого обходится, и никто не будет этого делать, не будучи уверенным, что затраты окупятся.
Вообще я одобряю практику полного раскрытия и думаю, что она скорее укрепляет безопасность, нежели наоборот. Эта книга, которую могут прочитать как хорошие, так и плохие парни, не представляет угрозы безопасности потому лишь, что в ней описаны методы нападений. Точно так же разглашение сведений о слабых местах не то же самое, что их появление. Производители не беспокоятся об устранении обнаруженных, но неопубликованных ошибок (этим грешит не только Microsoft, мы наблюдаем такое почти в каждой крупной компании), поэтому публикация – первый шаг к ликвидации ошибки. Наказывать того, кто разгласил сведения об ошибках, – все равно, что казнить гонца, принесшего дурные вести. Виноват во всем сам производитель, выпустивший ненадежное программное обеспечение.
Но бывают и исключения из правил.
Во-первых, я против такой огласки, которая, прежде всего, сеет панику. Сообщения о слабых местах, о которых нет достаточных свидетельств, очень вредны. (Пример тому – случай, когда кто-то обнаружил переменную, содержащую три буквы NSA, в шифровании API Microsoft[59] и объявил, что Агентство национальной безопасности (National Security Agency) установило лазейку в изделия Microsoft.) Так же плохи сообщения об уязвимых местах в ответственных системах, которые не могут быть легко устранены и знания о которых способны причинить серьезный вред (например, программное обеспечение управления воздушным движением). Я полагаю, что это остается на совести исследователей – определять баланс выгоды от раскрытия уязвимости и связанных с этим опасностей.
Во-вторых, я верю в эффективность предварительного уведомления производителей. CERT впадает в крайность, давая иногда компаниям годы для разрешения проблемы. В результате многие производители не принимают уведомление всерьез. Но если предупреждение о том, что сведения об уязвимых местах будут опубликованы через месяц, исходит от исследователя, то может оказаться, что такое сообщение появится одновременно с объявлением о сделанных исправлениях. Это выгодно каждому.
И в-третьих, я полагаю, что эта практика заходит слишком далеко. Написание научных статей по вопросам уязвимости помогает исследованиям и помогает в разработке систем безопасности. Написание демонстрационного кода – часто необходимая часть исследования. С другой стороны, массовое распространение средств нападения – плохая идея. Создание хакерских инструментов с интерфейсом «выбрать и щелкнуть», которые может использовать каждый начинающий хакер, не приводит ни к чему хорошему. Эта тенденция помогает преступникам и делает вычислительные сети менее безопасными. Она не решает проблему, а создает новые.
Иногда трудно определить, что хорошо и что плохо. Средства оценки уязвимости могут использоваться как для укрепления безопасности, так и для взлома системы. Средства удаленного доступа во многом похожи на Back Orifice. Если такая компания, как Microsoft, лживо отрицает в прессе реальность обнаруженных уязвимых мест, будет ли правильным опубликовать реальный сценарий нападения? Я считаю, что нужно содействовать решению проблем, а не создавать новые. Полное раскрытие – это часть решения. Устранение проблемы и усиление безопасности сети – тоже часть решения. Я не против тех средств, которые можно применять как в хороших, так и в дурных целях, но я не приемлю те средства, которые предназначены только для скверных дел.
В холле здания ЦРУ высечена в камне цитата из Библии:
Обратите внимание: безопасность не имеет ничего общего с функциональностью. Поэтому никакое бета-тестирование не поможет выявить недостатки безопасности. Единственный способ обрести уверенность в устойчивости системы к нападениям – это длительное испытание ее специалистами. И только одним способом можно достичь этого – сделать подробности системы общеизвестными.
Детали хорошо спроектированной защиты не являются секретом. В тайне сохраняются лишь некоторые изменяемые параметры: ключи шифрования, пароли, маркеры доступа и т. д. Противоположность этому – «безопасность через засекречивание» (security by obscurity), где сохранение в тайне деталей системы становится условием безопасности. Если система разработана таким образом, то ее защита довольно хрупкая. Как смогли убедиться разработчики системы безопасности цифровой сотовой связи или схемы шифрования DVD, или интерфейса FireWire, рано или поздно потаенное становится явным. Плохо разработанная система защищена, пока детали остаются в секрете, но быстро ломается, как только о них кто-нибудь узнает. Хорошо разработанная система безопасна, даже если ее детали общеизвестны.
Итак, поскольку хорошая разработка системы безопасности не связана с засекречиванием и можно много выгадать, если опубликовать подробности системы безопасности, имеет смысл поступать именно так. Открытые системы, скорее всего, будут тщательно исследоваться, а значит, будут и более надежны, чем закрытые системы.
Эти рассуждения применимы непосредственно к программному обеспечению. Единственный способ найти недостатки безопасности в коде состоит в том, чтобы исследовать его. Это верно для всех кодов – и открытых, и закрытых. И этим не может заниматься кто попало, требуются специалисты в области безопасности программного обеспечения. На протяжении нескольких лет их помощь неоднократно потребуется для оценки безопасности системы с различных точек зрения. Можно нанять таких экспертов, но будет намного дешевле и эффективнее позволить всему обществу заниматься этим. И лучший способ поспособствовать этому – опубликовать исходный код.
Предвижу возражение, что публикация кода подарит нападающим информацию, необходимую для обнаружения и использования уязвимых мест системы. Сохранение кода в тайне, как считается, не позволяет нападающим получить нужную информацию.
Это наивное утверждение. Обнародование исходного кода увеличивает не количество слабых мест, а осведомленность широкой публики. Производители, держащие исходный код в тайне, скорее всего, небрежны. А производители, делающие свой код открытым, имеют больше шансов обнаружить уязвимые места и устранить их. Засекреченное программное обеспечение ненадежно. Публикация исходного кода обеспечивает большую безопасность, чем сохранение его в тайне.
Однако открытое программное обеспечение не гарантирует безопасность. Нужно помнить о двух вещах.
Во-первых, простая публикация кода не означает автоматически, что его станут исследовать на предмет безопасности, и уж конечно не означает, что этим займутся специалисты. Например, исследователи нашли ошибки переполнения буфера в коде, созданном в Массачусетском технологическом институте для Kerberos, через десять лет после выпуска этого кода. Другой открытый модуль – программа Mailman, предназначенная для работы со списками адресатов конференций, – более трех лет имела бросающиеся в глаза недостатки защиты, пока сам разработчик не пересмотрел код и не обнаружил их.
Исследователи безопасности – непостоянные и вечно занятые люди. Они не имеют ни времени, ни склонности исследовать каждую часть опубликованного исходного кода. И хотя полезно сделать исходный код открытым, это не гарантирует безопасность. Я мог бы назвать дюжину библиотек открытого кода программ защиты, о которых никто никогда не слышал. С другой стороны, открытый исходный код защиты различных программных средств UNIX изучался многими профессионалами в области безопасности.
Кроме того, обнародование кода не гарантирует, что проблемы безопасности решаются сразу, как только обнаруживаются. Нет оснований надеяться, что некая часть открытого исходного кода двухлетней давности имеет меньше недостатков, чем часть закрытого кода такого же стажа. Если открытый исходный код интенсивно исследовался, это может быть похоже на правду. Но только то обстоятельство, что часть исходного кода была доступной в течение нескольких лет, само по себе ничего не означает[60].
Я – за открытый исходный код и полагаю, что таким образом можно повысить уровень безопасности. Но программное обеспечение не становится автоматически надежным только потому, что делается открытым, и, наоборот, оно не делается небезопасным, если остается закрытым. Другие отмечали, что открытый код кажется более безопасным, и эта необоснованная вера заставляет людей доверять ему больше, чем следует. Это плохо.
Также обратите внимание, что в этом исследовании полностью игнорируется существенный вопрос о том, как сделать программное обеспечение безопасным в первую очередь на стадии разработки. Использование открытого кода – это, во-первых, стратегия бизнеса и, во-вторых, стратегия безопасности. К сожалению, похоже, что традиционные методы закрытого программного обеспечения более эффективны при создании высококачественного крупного продукта. Возможно, лучше всего в отношении безопасности создать закрытое программное обеспечение и затем сделать его открытым (как поступила Netscape со своим кодом браузера).
Мы уже знаем, к чему это приводит. Ассоциация контроля за копированием DVD (DVD Copy Control Association) начала судебное преследование тех, кто перепроектировал их схему защиты DVD, и тех, кто создал общедоступные средства, позволявшие использовать слабые места. Эти люди были арестованы. Mattel выиграла дела против хакеров, которые воспроизвели средства безопасности в CyberPatrol – программе, блокирующей доступ к определенным ресурсам.
Налицо опасный прецедент. Законодательными мерами не укрепить безопасность систем и не воспрепятствовать нападающим в поисках слабых мест. Все, на что они годятся, – это дать производителям возможность не беспокоиться по поводу паршивой безопасности своих продуктов и сваливать с больной головы на здоровую. Конечно, легче реализовать плохие средства безопасности и запретить кому бы то ни было обращать на это внимание, чем трудиться над созданием надежной защиты. Несмотря на то что подобные законы помогают сдерживать распространение взломанного программного обеспечения (пример тому – случаи с DVD и Mattel), в конечном счете они надолго останавливают развитие средств безопасности.
Но это не так.
Состязания – негодный способ демонстрации безопасности. Очевидно, продукт (или система, протокол, алгоритм), выдержавший испытание, заслуживает не больше доверия, нежели тот, который ему не подвергался. Результаты состязаний вообще не содержат никакой полезной информации. Тому есть четыре основных причины.
Во-первых, состязания в основном нечестны. Криптоанализ в этом случае осуществляется в условиях, когда нападающий знаком со всем, кроме главного секрета. Он имеет доступ к алгоритмам, протоколам, исходному коду. Он знает зашифрованный и открытый тексты. Вероятно, он даже владеет частичной информацией о ключе. И результат криптоанализа может быть каким угодно. Это может быть полный взлом: когда средства безопасности удается преодолеть в разумные сроки. Это может быть доказательство того, что теоретически взлом возможен: результат, который не имеет практического применения, но все-таки показывает, что средства безопасности не так хороши, как было объявлено. Большинство состязаний по хакерству имеют произвольные правила, определяющие, с чем должен работать нападающий и что следует считать удачным взломом. По некоторым правилам алгоритмы не раскрываются.
Состязания по взлому компьютеров ничем не лучше. Они не раскрывают того, как используются программные продукты, поэтому ничего нельзя сказать относительно того, что является причиной взлома: изъяны самого продукта или ошибки, допущенные при его установке или конфигурировании. Они выявляют особенности различных частей системы: если в состязании проверяется надежность брандмауэра, то что можно сказать об уязвимости операционной системы, из-за недостатков которой этот брандмауэр может оказаться неэффективным?
Правила, по которым определяют победителя состязаний, также произвольны. В 1999 году Microsoft установила веб-сервер Windows 2000 и рискнула предложить хакерам взломать его. Внезапно сервер исчез из Интернета. Вскоре он появился вновь, и Microsoft успокоила, что причиной небытия было отключение питания. (Как это ни странно, похоже, что действительно просто забыли установить систему бесперебойного питания и это сказалось на испытании.)
Нечестные соревнования не новы. В середине 1980-х проводили состязание авторы алгоритма шифрования, названного FEAL. Они предложили файл с зашифрованным текстом и обещали награду первому, кто его прочитает. С тех пор алгоритм неоднократно взламывался. Все признают, что FEAL совершенно ненадежен, однако никто так и не был признан победителем.
Во-вторых, результаты состязания невозможно проанализировать. Они представляют собой случайные, бессистемные испытания. Вправе ли мы считать, что работа десяти человек, каждый из которых затратил по 100 часов, соответствует 1000 часов анализа? Может быть, все они пытались провести одни и те же нападения? Обладают ли они достаточной компетенцией для такого исследования, или они только случайные люди, которые услышали о состязании и захотели испытать удачу? Одно только то обстоятельство, что никто не побеждает в конкурсе, не означает, что цель надежно защищена. Из него следует всего лишь, что никто не признан победителем…
В 1999 году журнал PC Magazine объявил одновременно состязания по взлому Windows NT и Linux box. Первой была взломана вторая. Свидетельствует ли это о том, что Linux менее надежен? Конечно, нет; это означает только, что участники игры сначала проникли в Linux box.
В-третьих, объявленная награда редко бывает достаточным стимулом для участия профессионалов в состязаниях. Анализ безопасности требует большого труда. Люди, хорошо разбирающиеся в этих вопросах, берутся за такую работу по разным мотивам (деньги, престиж, борьба со скукой), но стремление выиграть тенниску едва ли побудит их к этому. Профессионалы в области безопасности зарабатывают гораздо больше, занимаясь своей обычной работой на заказчика или публикуя статьи с результатами своих исследований.
Взглянем на ситуацию с позиций материальной заинтересованности. В среднем час работы компетентного аналитика криптографии или ведущего специалиста по компьютерной безопасности стоит 200 долларов. Всего за неделю работы они получают 10 000 долларов. Этого времени недостаточно, чтобы разобраться с кодом. Вознаграждение в 100 000 долларов выглядит соблазнительно, но обратное проектирование – скучное занятие, а для исчерпывающего изучения все равно не хватит времени. Награда в миллион долларов уже вызывает интерес, но большинство компаний не могут позволить себе предложить такую сумму. Да и исследователь не имеет никакой гарантии в получении вознаграждения: он может ничего не найти или, смертельно устав от бесплодных попыток, проиграть кому-то другому, кроме того, компания способна изменить правила игры и ничего не заплатить. Неужели кто-то будет жертвовать своим временем (и рисковать добрым именем) ради рекламной акции какой-то компании?
И в-четвертых, состязания никогда не приводят к положительному результату в отношении безопасности. Если что-то было взломано, понятно, что это ненадежно. Но если цель устояла, это вовсе не означает, что она защищена.
Все эти четыре причины являются общим правилом. Бывают и исключения, но редко. Состязания по взлому RSA, как с помощью разложения на множители, так и путем лобовой атаки на симметричный алгоритм, – все это честные и хорошие соревнования. Эти соревнования успешны не потому, что исследователи борются за денежные призы, а вследствие того, что интерес к проблеме взлома этого алгоритма тем или иным способом присутствует всегда. Просто соревнования фокусируют внимание на том, что само по себе интересно. Конкурсы по взлому AES – больше соревнования, чем криптоаналитические расчеты, но они также были честными.
Состязания, если они правильно проводятся, могут принести пользу в отдельных областях исследований. Они помогают находить недостатки и исправлять их. Но они бесполезны для оценки безопасности. Хозяин может предложить 10 000 долларов тому, кто проникнет в его дом и украдет книгу с определенной полки. Но если никто не сделает этого в установленный срок, то это не значит, что дом надежно защищен. Возможно, никто из потенциальных взломщиков просто не слышал о конкурсе. Возможно, они были слишком заняты другими делами. Возможно, они не знали, как проникнуть в дом, но знали обходной путь: как подделать свидетельство о праве на недвижимость и перевести дом на свое имя. Может быть, они проникли в дом, но осмотрелись и поспешили убраться, прихватив нечто, стоящее больше 10 000 долларов. Поэтому состязания ничего не доказывают.
Состязания по криптоанализу – вообще не более чем реклама продукции. Даже честность устроителей не гарантирует того, что будет проведен анализ безопасности цели. Если цель устоит, это не будет означать, что нет недостатков в ее защите.
Первое, что приходит в голову, – а так ли уж это важно? Или, точнее, чья это проблема? Я беспокоюсь только о том, чтобы никто не вмешивался в мои частные дела. Меня мало волнует возможность мошенничества с кредитными карточками Visa. Мои возможные потери ограничены 50 долларами. Я беспокоюсь о сохранении в тайне идентификационного номера моей банковской карточки, потому что если кто-то очистит мой счет, то это будет моей проблемой, а не банка.
Меня также заботят некоторые другие вещи, но я не могу на них повлиять. От меня не зависит, какие брандмауэры и средства защиты базы данных использует IRS (информационно-поисковая система) для защиты моей налоговой информации. Или что использует мой медицинский страховщик для защиты записей о состоянии моего здоровья. Возможно, я могу поменять страховщиков, но в общем я не свободен в своем выборе. (Полагаю, что если бы я был достаточно богат, то мог бы выбирать банки в лучше регулируемых условиях, например в Швейцарии, но большинству из нас это недоступно.) Даже если законы требуют соблюдения тайны (секретности, идентификации, анонимности и неприкосновенности и т. п.), все равно нет никакой гарантии, что люди, ответственные за обеспечение мер безопасности, выполняют свою работу хорошо. Я не могу проверить государственные средства безопасности только потому, что я хочу удостовериться в их эффективности. Печально, но факт – большинство аспектов обеспечения безопасности неподконтрольны простым людям.
Ради интереса давайте представим, что система безопасности находится под вашим контролем: Кроме того, вы несете финансовую ответственность за ее функциональность: вы потеряете деньги, если идентификационная схема будет взломана. Вам предъявят иск в случае нарушения защиты и утечки информации частного характера и т. д. Вы уже оценили риск и решили, что нужно приобрести средства безопасности определенного типа. Как выбрать правильный продукт? Как оценить его возможности?
Проблема состоит в том, что плохие средства безопасности выглядят точно так же, как и хорошие. Я могу предложить два продукта – пару VPN (виртуальных частных сетей), например. Они имеют одинаковые возможности и одинаковые особенности. В них встречаются одинаковые модные словечки: тройной DES (стандарт шифрования данных), IPsec и т. д. Они в равной степени удовлетворяют требованиям безопасности. Каждая сеть безопасна и каждая может быть взломана. Обычный пользователь не имеет никакой возможности увидеть разницу. Специалист в области безопасности сумеет это сделать, но уйдет полгода работы на то, чтобы он составил свое мнение. Это просто не оправдывает затрат.
Безопасность рождается в соперничестве, даже в академических «башнях из слоновой кости». Кто-то предлагает новую схему: алгоритм, протокол, техника; другой взламывает ее; кто-то третий все восстанавливает и т. д. Все превращается в забаву. Но когда дело касается уже выпущенных и используемых систем, это может обернуться мошенничеством. Действительно ли выгода от огласки нападения перевешивает возрастание угрозы со стороны противника, получившего сведения о таких возможностях? (На языке Агентства национальной безопасности это называется «выпуском акций».) Почему компания должна наживаться на работе исследователя? Будет ли компания игнорировать проблему до тех пор, пока исследователь не обнародует данные? Заботит ли самого исследователя реакция публики? В любом случае, как вести себя исследователю?
Этот последний вопрос никогда не имел должного обсуждения. Публикация слабых мест безопасности – это своего рода «атака ради огласки»: исследователь хочет увидеть свое имя в газете. Иногда такие сведения разглашает или консультант по вопросам безопасности, или служащий компании, которая занимается оценкой уязвимости или предлагает средства защиты сети. Это особенно верно, если новость появилась в прессе; сообщение в PR Newswire или Business Wire дорого обходится, и никто не будет этого делать, не будучи уверенным, что затраты окупятся.
Вообще я одобряю практику полного раскрытия и думаю, что она скорее укрепляет безопасность, нежели наоборот. Эта книга, которую могут прочитать как хорошие, так и плохие парни, не представляет угрозы безопасности потому лишь, что в ней описаны методы нападений. Точно так же разглашение сведений о слабых местах не то же самое, что их появление. Производители не беспокоятся об устранении обнаруженных, но неопубликованных ошибок (этим грешит не только Microsoft, мы наблюдаем такое почти в каждой крупной компании), поэтому публикация – первый шаг к ликвидации ошибки. Наказывать того, кто разгласил сведения об ошибках, – все равно, что казнить гонца, принесшего дурные вести. Виноват во всем сам производитель, выпустивший ненадежное программное обеспечение.
Но бывают и исключения из правил.
Во-первых, я против такой огласки, которая, прежде всего, сеет панику. Сообщения о слабых местах, о которых нет достаточных свидетельств, очень вредны. (Пример тому – случай, когда кто-то обнаружил переменную, содержащую три буквы NSA, в шифровании API Microsoft[59] и объявил, что Агентство национальной безопасности (National Security Agency) установило лазейку в изделия Microsoft.) Так же плохи сообщения об уязвимых местах в ответственных системах, которые не могут быть легко устранены и знания о которых способны причинить серьезный вред (например, программное обеспечение управления воздушным движением). Я полагаю, что это остается на совести исследователей – определять баланс выгоды от раскрытия уязвимости и связанных с этим опасностей.
Во-вторых, я верю в эффективность предварительного уведомления производителей. CERT впадает в крайность, давая иногда компаниям годы для разрешения проблемы. В результате многие производители не принимают уведомление всерьез. Но если предупреждение о том, что сведения об уязвимых местах будут опубликованы через месяц, исходит от исследователя, то может оказаться, что такое сообщение появится одновременно с объявлением о сделанных исправлениях. Это выгодно каждому.
И в-третьих, я полагаю, что эта практика заходит слишком далеко. Написание научных статей по вопросам уязвимости помогает исследованиям и помогает в разработке систем безопасности. Написание демонстрационного кода – часто необходимая часть исследования. С другой стороны, массовое распространение средств нападения – плохая идея. Создание хакерских инструментов с интерфейсом «выбрать и щелкнуть», которые может использовать каждый начинающий хакер, не приводит ни к чему хорошему. Эта тенденция помогает преступникам и делает вычислительные сети менее безопасными. Она не решает проблему, а создает новые.
Иногда трудно определить, что хорошо и что плохо. Средства оценки уязвимости могут использоваться как для укрепления безопасности, так и для взлома системы. Средства удаленного доступа во многом похожи на Back Orifice. Если такая компания, как Microsoft, лживо отрицает в прессе реальность обнаруженных уязвимых мест, будет ли правильным опубликовать реальный сценарий нападения? Я считаю, что нужно содействовать решению проблем, а не создавать новые. Полное раскрытие – это часть решения. Устранение проблемы и усиление безопасности сети – тоже часть решения. Я не против тех средств, которые можно применять как в хороших, так и в дурных целях, но я не приемлю те средства, которые предназначены только для скверных дел.
В холле здания ЦРУ высечена в камне цитата из Библии:
«И познаете истину, и истина сделает вас свободными»Знающие правду способны использовать эти знания, чтобы добиться победы над теми, кто не знает ее (или кто отказывается поверить в нее). Полное раскрытие приводит нас ближе к истине, чем что-либо другое.
(Ин 8: 32).
Открытые стандарты и открытые решения
В главе 7 я рассказывал о преимуществах использования открытого, общедоступного шифрования вместо частного, закрытого. Поскольку единственным свидетельством в пользу безопасности криптографических примитивов является длительное исследование многими специалистами, наиболее выгодно сделать их открытыми. Именно этот довод побуждает любого разумного разработчика системы безопасности использовать открытые решения для всего, что связанно с безопасностью, включая открытый исходный код программного обеспечения.Обратите внимание: безопасность не имеет ничего общего с функциональностью. Поэтому никакое бета-тестирование не поможет выявить недостатки безопасности. Единственный способ обрести уверенность в устойчивости системы к нападениям – это длительное испытание ее специалистами. И только одним способом можно достичь этого – сделать подробности системы общеизвестными.
Детали хорошо спроектированной защиты не являются секретом. В тайне сохраняются лишь некоторые изменяемые параметры: ключи шифрования, пароли, маркеры доступа и т. д. Противоположность этому – «безопасность через засекречивание» (security by obscurity), где сохранение в тайне деталей системы становится условием безопасности. Если система разработана таким образом, то ее защита довольно хрупкая. Как смогли убедиться разработчики системы безопасности цифровой сотовой связи или схемы шифрования DVD, или интерфейса FireWire, рано или поздно потаенное становится явным. Плохо разработанная система защищена, пока детали остаются в секрете, но быстро ломается, как только о них кто-нибудь узнает. Хорошо разработанная система безопасна, даже если ее детали общеизвестны.
Итак, поскольку хорошая разработка системы безопасности не связана с засекречиванием и можно много выгадать, если опубликовать подробности системы безопасности, имеет смысл поступать именно так. Открытые системы, скорее всего, будут тщательно исследоваться, а значит, будут и более надежны, чем закрытые системы.
Эти рассуждения применимы непосредственно к программному обеспечению. Единственный способ найти недостатки безопасности в коде состоит в том, чтобы исследовать его. Это верно для всех кодов – и открытых, и закрытых. И этим не может заниматься кто попало, требуются специалисты в области безопасности программного обеспечения. На протяжении нескольких лет их помощь неоднократно потребуется для оценки безопасности системы с различных точек зрения. Можно нанять таких экспертов, но будет намного дешевле и эффективнее позволить всему обществу заниматься этим. И лучший способ поспособствовать этому – опубликовать исходный код.
Предвижу возражение, что публикация кода подарит нападающим информацию, необходимую для обнаружения и использования уязвимых мест системы. Сохранение кода в тайне, как считается, не позволяет нападающим получить нужную информацию.
Это наивное утверждение. Обнародование исходного кода увеличивает не количество слабых мест, а осведомленность широкой публики. Производители, держащие исходный код в тайне, скорее всего, небрежны. А производители, делающие свой код открытым, имеют больше шансов обнаружить уязвимые места и устранить их. Засекреченное программное обеспечение ненадежно. Публикация исходного кода обеспечивает большую безопасность, чем сохранение его в тайне.
Однако открытое программное обеспечение не гарантирует безопасность. Нужно помнить о двух вещах.
Во-первых, простая публикация кода не означает автоматически, что его станут исследовать на предмет безопасности, и уж конечно не означает, что этим займутся специалисты. Например, исследователи нашли ошибки переполнения буфера в коде, созданном в Массачусетском технологическом институте для Kerberos, через десять лет после выпуска этого кода. Другой открытый модуль – программа Mailman, предназначенная для работы со списками адресатов конференций, – более трех лет имела бросающиеся в глаза недостатки защиты, пока сам разработчик не пересмотрел код и не обнаружил их.
Исследователи безопасности – непостоянные и вечно занятые люди. Они не имеют ни времени, ни склонности исследовать каждую часть опубликованного исходного кода. И хотя полезно сделать исходный код открытым, это не гарантирует безопасность. Я мог бы назвать дюжину библиотек открытого кода программ защиты, о которых никто никогда не слышал. С другой стороны, открытый исходный код защиты различных программных средств UNIX изучался многими профессионалами в области безопасности.
Кроме того, обнародование кода не гарантирует, что проблемы безопасности решаются сразу, как только обнаруживаются. Нет оснований надеяться, что некая часть открытого исходного кода двухлетней давности имеет меньше недостатков, чем часть закрытого кода такого же стажа. Если открытый исходный код интенсивно исследовался, это может быть похоже на правду. Но только то обстоятельство, что часть исходного кода была доступной в течение нескольких лет, само по себе ничего не означает[60].
Я – за открытый исходный код и полагаю, что таким образом можно повысить уровень безопасности. Но программное обеспечение не становится автоматически надежным только потому, что делается открытым, и, наоборот, оно не делается небезопасным, если остается закрытым. Другие отмечали, что открытый код кажется более безопасным, и эта необоснованная вера заставляет людей доверять ему больше, чем следует. Это плохо.
Также обратите внимание, что в этом исследовании полностью игнорируется существенный вопрос о том, как сделать программное обеспечение безопасным в первую очередь на стадии разработки. Использование открытого кода – это, во-первых, стратегия бизнеса и, во-вторых, стратегия безопасности. К сожалению, похоже, что традиционные методы закрытого программного обеспечения более эффективны при создании высококачественного крупного продукта. Возможно, лучше всего в отношении безопасности создать закрытое программное обеспечение и затем сделать его открытым (как поступила Netscape со своим кодом браузера).
Перепроектирование и закон
Стараясь отвертеться от практики полного раскрытия и использования открытого исходного кода, некоторые компании пытались защитить себя с помощью законодательных мер и прилагали усилия к тому, чтобы обратное проектирование (reverse engineering) было объявлено незаконным. Закон Соединенных Штатов об авторском праве в компьютерной сфере DMCA (Digital Millennium Copyright Act) объявляет обратное проектирование уголовным преступлением, такое же положение содержится в UCITA (Uniform Computer Information Transactions Act). В настоящее время это становится законом в нескольких штатах.Мы уже знаем, к чему это приводит. Ассоциация контроля за копированием DVD (DVD Copy Control Association) начала судебное преследование тех, кто перепроектировал их схему защиты DVD, и тех, кто создал общедоступные средства, позволявшие использовать слабые места. Эти люди были арестованы. Mattel выиграла дела против хакеров, которые воспроизвели средства безопасности в CyberPatrol – программе, блокирующей доступ к определенным ресурсам.
Налицо опасный прецедент. Законодательными мерами не укрепить безопасность систем и не воспрепятствовать нападающим в поисках слабых мест. Все, на что они годятся, – это дать производителям возможность не беспокоиться по поводу паршивой безопасности своих продуктов и сваливать с больной головы на здоровую. Конечно, легче реализовать плохие средства безопасности и запретить кому бы то ни было обращать на это внимание, чем трудиться над созданием надежной защиты. Несмотря на то что подобные законы помогают сдерживать распространение взломанного программного обеспечения (пример тому – случаи с DVD и Mattel), в конечном счете они надолго останавливают развитие средств безопасности.
Состязания по взломам и хакерству
Мы часто сталкиваемся с объявлениями: «Компания X предлагает 10 000 долларов каждому, кто прорвется через ее брандмауэр (взломает ее алгоритм, успешно использует ее протокол в мошеннической операции или сделает что-либо подобное)». Эти состязания хакеров проводятся для демонстрации того, насколько сильна и надежна защита объектов, подвергающихся нападениям. Логика здесь примерно такова: «Мы предложили приз за взлом цели, но никто не сделал этого. Значит, цель хорошо защищена».Но это не так.
Состязания – негодный способ демонстрации безопасности. Очевидно, продукт (или система, протокол, алгоритм), выдержавший испытание, заслуживает не больше доверия, нежели тот, который ему не подвергался. Результаты состязаний вообще не содержат никакой полезной информации. Тому есть четыре основных причины.
Во-первых, состязания в основном нечестны. Криптоанализ в этом случае осуществляется в условиях, когда нападающий знаком со всем, кроме главного секрета. Он имеет доступ к алгоритмам, протоколам, исходному коду. Он знает зашифрованный и открытый тексты. Вероятно, он даже владеет частичной информацией о ключе. И результат криптоанализа может быть каким угодно. Это может быть полный взлом: когда средства безопасности удается преодолеть в разумные сроки. Это может быть доказательство того, что теоретически взлом возможен: результат, который не имеет практического применения, но все-таки показывает, что средства безопасности не так хороши, как было объявлено. Большинство состязаний по хакерству имеют произвольные правила, определяющие, с чем должен работать нападающий и что следует считать удачным взломом. По некоторым правилам алгоритмы не раскрываются.
Состязания по взлому компьютеров ничем не лучше. Они не раскрывают того, как используются программные продукты, поэтому ничего нельзя сказать относительно того, что является причиной взлома: изъяны самого продукта или ошибки, допущенные при его установке или конфигурировании. Они выявляют особенности различных частей системы: если в состязании проверяется надежность брандмауэра, то что можно сказать об уязвимости операционной системы, из-за недостатков которой этот брандмауэр может оказаться неэффективным?
Правила, по которым определяют победителя состязаний, также произвольны. В 1999 году Microsoft установила веб-сервер Windows 2000 и рискнула предложить хакерам взломать его. Внезапно сервер исчез из Интернета. Вскоре он появился вновь, и Microsoft успокоила, что причиной небытия было отключение питания. (Как это ни странно, похоже, что действительно просто забыли установить систему бесперебойного питания и это сказалось на испытании.)
Нечестные соревнования не новы. В середине 1980-х проводили состязание авторы алгоритма шифрования, названного FEAL. Они предложили файл с зашифрованным текстом и обещали награду первому, кто его прочитает. С тех пор алгоритм неоднократно взламывался. Все признают, что FEAL совершенно ненадежен, однако никто так и не был признан победителем.
Во-вторых, результаты состязания невозможно проанализировать. Они представляют собой случайные, бессистемные испытания. Вправе ли мы считать, что работа десяти человек, каждый из которых затратил по 100 часов, соответствует 1000 часов анализа? Может быть, все они пытались провести одни и те же нападения? Обладают ли они достаточной компетенцией для такого исследования, или они только случайные люди, которые услышали о состязании и захотели испытать удачу? Одно только то обстоятельство, что никто не побеждает в конкурсе, не означает, что цель надежно защищена. Из него следует всего лишь, что никто не признан победителем…
В 1999 году журнал PC Magazine объявил одновременно состязания по взлому Windows NT и Linux box. Первой была взломана вторая. Свидетельствует ли это о том, что Linux менее надежен? Конечно, нет; это означает только, что участники игры сначала проникли в Linux box.
В-третьих, объявленная награда редко бывает достаточным стимулом для участия профессионалов в состязаниях. Анализ безопасности требует большого труда. Люди, хорошо разбирающиеся в этих вопросах, берутся за такую работу по разным мотивам (деньги, престиж, борьба со скукой), но стремление выиграть тенниску едва ли побудит их к этому. Профессионалы в области безопасности зарабатывают гораздо больше, занимаясь своей обычной работой на заказчика или публикуя статьи с результатами своих исследований.
Взглянем на ситуацию с позиций материальной заинтересованности. В среднем час работы компетентного аналитика криптографии или ведущего специалиста по компьютерной безопасности стоит 200 долларов. Всего за неделю работы они получают 10 000 долларов. Этого времени недостаточно, чтобы разобраться с кодом. Вознаграждение в 100 000 долларов выглядит соблазнительно, но обратное проектирование – скучное занятие, а для исчерпывающего изучения все равно не хватит времени. Награда в миллион долларов уже вызывает интерес, но большинство компаний не могут позволить себе предложить такую сумму. Да и исследователь не имеет никакой гарантии в получении вознаграждения: он может ничего не найти или, смертельно устав от бесплодных попыток, проиграть кому-то другому, кроме того, компания способна изменить правила игры и ничего не заплатить. Неужели кто-то будет жертвовать своим временем (и рисковать добрым именем) ради рекламной акции какой-то компании?
И в-четвертых, состязания никогда не приводят к положительному результату в отношении безопасности. Если что-то было взломано, понятно, что это ненадежно. Но если цель устояла, это вовсе не означает, что она защищена.
Все эти четыре причины являются общим правилом. Бывают и исключения, но редко. Состязания по взлому RSA, как с помощью разложения на множители, так и путем лобовой атаки на симметричный алгоритм, – все это честные и хорошие соревнования. Эти соревнования успешны не потому, что исследователи борются за денежные призы, а вследствие того, что интерес к проблеме взлома этого алгоритма тем или иным способом присутствует всегда. Просто соревнования фокусируют внимание на том, что само по себе интересно. Конкурсы по взлому AES – больше соревнования, чем криптоаналитические расчеты, но они также были честными.
Состязания, если они правильно проводятся, могут принести пользу в отдельных областях исследований. Они помогают находить недостатки и исправлять их. Но они бесполезны для оценки безопасности. Хозяин может предложить 10 000 долларов тому, кто проникнет в его дом и украдет книгу с определенной полки. Но если никто не сделает этого в установленный срок, то это не значит, что дом надежно защищен. Возможно, никто из потенциальных взломщиков просто не слышал о конкурсе. Возможно, они были слишком заняты другими делами. Возможно, они не знали, как проникнуть в дом, но знали обходной путь: как подделать свидетельство о праве на недвижимость и перевести дом на свое имя. Может быть, они проникли в дом, но осмотрелись и поспешили убраться, прихватив нечто, стоящее больше 10 000 долларов. Поэтому состязания ничего не доказывают.
Состязания по криптоанализу – вообще не более чем реклама продукции. Даже честность устроителей не гарантирует того, что будет проведен анализ безопасности цели. Если цель устоит, это не будет означать, что нет недостатков в ее защите.
Оценка и выбор продуктов безопасности
Обыкновенные люди (или обычная компания, или заурядное в этом отношении государство) вообще не способны создать свои собственные средства безопасности. Чаще всего они вынуждены выбирать между множеством готовых решений и надеяться на лучшее. Вывод, содержащийся в этой книге, о том, что практически невозможно разработать безопасные программные продукты и что большинство коммерческих продуктов являются небезопасными, звучит не ободряюще. Что может сделать измотанный системный администратор, занятый обеспечением безопасности электронной почты посольства или сети своей компании? Или простой гражданин, обеспокоенный безопасностью систем электронной торговли или сохранением в тайне медицинских сведений?Первое, что приходит в голову, – а так ли уж это важно? Или, точнее, чья это проблема? Я беспокоюсь только о том, чтобы никто не вмешивался в мои частные дела. Меня мало волнует возможность мошенничества с кредитными карточками Visa. Мои возможные потери ограничены 50 долларами. Я беспокоюсь о сохранении в тайне идентификационного номера моей банковской карточки, потому что если кто-то очистит мой счет, то это будет моей проблемой, а не банка.
Меня также заботят некоторые другие вещи, но я не могу на них повлиять. От меня не зависит, какие брандмауэры и средства защиты базы данных использует IRS (информационно-поисковая система) для защиты моей налоговой информации. Или что использует мой медицинский страховщик для защиты записей о состоянии моего здоровья. Возможно, я могу поменять страховщиков, но в общем я не свободен в своем выборе. (Полагаю, что если бы я был достаточно богат, то мог бы выбирать банки в лучше регулируемых условиях, например в Швейцарии, но большинству из нас это недоступно.) Даже если законы требуют соблюдения тайны (секретности, идентификации, анонимности и неприкосновенности и т. п.), все равно нет никакой гарантии, что люди, ответственные за обеспечение мер безопасности, выполняют свою работу хорошо. Я не могу проверить государственные средства безопасности только потому, что я хочу удостовериться в их эффективности. Печально, но факт – большинство аспектов обеспечения безопасности неподконтрольны простым людям.
Ради интереса давайте представим, что система безопасности находится под вашим контролем: Кроме того, вы несете финансовую ответственность за ее функциональность: вы потеряете деньги, если идентификационная схема будет взломана. Вам предъявят иск в случае нарушения защиты и утечки информации частного характера и т. д. Вы уже оценили риск и решили, что нужно приобрести средства безопасности определенного типа. Как выбрать правильный продукт? Как оценить его возможности?
Проблема состоит в том, что плохие средства безопасности выглядят точно так же, как и хорошие. Я могу предложить два продукта – пару VPN (виртуальных частных сетей), например. Они имеют одинаковые возможности и одинаковые особенности. В них встречаются одинаковые модные словечки: тройной DES (стандарт шифрования данных), IPsec и т. д. Они в равной степени удовлетворяют требованиям безопасности. Каждая сеть безопасна и каждая может быть взломана. Обычный пользователь не имеет никакой возможности увидеть разницу. Специалист в области безопасности сумеет это сделать, но уйдет полгода работы на то, чтобы он составил свое мнение. Это просто не оправдывает затрат.