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

Детали хорошо спроектированной защиты не являются секретом. В тайне сохраняются лишь некоторые изменяемые параметры: ключи шифрования, пароли, маркеры доступа и т. д. Противоположность этому – «безопасность через засекречивание» (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 и т. д. Они в равной степени удовлетворяют требованиям безопасности. Каждая сеть безопасна и каждая может быть взломана. Обычный пользователь не имеет никакой возможности увидеть разницу. Специалист в области безопасности сумеет это сделать, но уйдет полгода работы на то, чтобы он составил свое мнение. Это просто не оправдывает затрат.

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

Но даже если они оценили уровень безопасности, будет ли эта оценка применима в том случае, когда вы используете продукт некоторым вполне определенным способом? Например, я не беспокоюсь, насколько надежной можно сделать отдельную операционную систему. Меня интересует, насколько она будет защищена 90% времени в реальных ситуациях. Я тревожусь о том, насколько на ее работу могут повлиять ошибки внешнего окружения. Или насколько защищена будет система, после того как ее установит обыкновенный системный администратор. Вот в чем вопрос.

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

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

Опустить руки и отказаться от принятия решения – это не выход из положения. Существуют продукты безопасности, и потребители вынуждены выбирать из того, что имеется. Глупо отказываться от установки брандмауэра только потому, что вы не знаете, какой лучше. Кто-то сказал: «Лучше сейчас иметь посредственные средства безопасности, чем не иметь никаких, надеясь найти самые совершенные».

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

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