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

Во-первых, простая публикация кода не означает автоматически, что его станут исследовать на предмет безопасности, и уж конечно не означает, что этим займутся специалисты. Например, исследователи нашли ошибки переполнения буфера в коде, созданном в Массачусетском технологическом институте для 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 долларов каждому, кто прорвется через ее брандмауэр (взломает ее алгоритм, успешно использует ее протокол в мошеннической операции или сделает что-либо подобное)». Эти состязания хакеров проводятся для демонстрации того, насколько сильна и надежна защита объектов, подвергающихся нападениям. Логика здесь примерно такова: «Мы предложили приз за взлом цели, но никто не сделал этого. Значит, цель хорошо защищена».

Но это не так.

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

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

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