Брюс Шнаер о безопасности и открытых исходниках

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

Безопасность — нечто иное. Представьте, что вы встраиваете функцию шифрова­ния в тот же текстовой процессор. Затем проверяете его таким же образом: шифруете ряд документов, затем расшифровываете их. Дешифрование восстанавливает откры­тый текст, а зашифрованный текст похож на бессмыслицу. Все это великолепно рабо­тает. К сожалению, эти испытания ничего не говорят о безопасности шифрования.

Функциональное тестирование хорошо для обнаружения случайных погреш­ностей, которые приводят к тому, что компьютерная программа ведет себя не­предсказуемо, в основном перестает работать. Недостатки системы защиты не проявляются столь эффектно; обычно они невидимы, пока не станут известны зло­умышленникам. Испытание средств безопасности — это не беспорядочное исполь­зование программного обеспечения и наблюдение за его работой. Это сознательное выявление проблем, создающих угрозу безопасности. Функциональное испытание никогда не выявило бы, что нападающий может создать веб-страницу, которая будет запускать некоторую программу на компьютере пользователя, просматриваю­щего эту страницу с помощью Microsoft Internet Explorer 3.0 или 3.0.1. Как раз это­го и не удастся обнаружить при бета-тестировании.

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

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

Даже достаточно полный анализ безопасности не сильно поможет. Я обнару­живал от 5 до 15 ошибок на тысячу строк кода, и это — в конечном продукте, после всех испытаний. Мы все знаем, какое огромное количество ошибок можно найти в операционной системе Microsoft, даже после сотен человеко-часов испытаний. Точно так же дни, недели и даже месяцы исследования безопасности не приведут ни к чему.

Другая сторона проблемы состоит в том, что полноценное исследование безопас­ности может быть проведено только опытными специалистами. Вспомним, что о продукте безопасности в лучшем случае можно будет сказать: «Я не могу взло­мать его, и другие умельцы также не смогут сделать этого». Только опытные спе­циалисты в области безопасности в состоянии действительно обнаружить недо­статки системы, поэтому качество любого испытания зависит от профессионализма исследователей.

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

К сожалению, еще не создана такая полезная вещь, как всеобъемлющий справоч­ник по вопросам безопасности. Те из нас, кто работают в этой области, зачастую созда­вали свои собственные справочники, содержащие перечни возможных нападений и уязвимых мест, которые встречаются в коммерческих продуктах, описаны в научной литературе или придуманы нами самими. Подобные перечни огромны — пару лет на­зад я составил такой список из 759 нападений, но и он не был исчерпывающим.

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

Обратите внимание, я не говорю «очень трудно» или «невероятно трудно». Я сказал «невозможно».

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

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

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

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

Детали хорошо спроектированной защиты не являются секретом. В тайне со­храняются лишь некоторые изменяемые параметры: ключи шифрования, пароли, маркеры доступа и т. д. Противоположность этому — «безопасность через засекречивание» (security by obscurity), где сохранение в тайне деталей системы становит­ся условием безопасности. Если система разработана таким образом, то ее защита довольно хрупкая. Как смогли убедиться разработчики системы безопасности циф­ровой сотовой связи или схемы шифрования DVD, или интерфейса FireWire, рано или поздно потаенное становится явным. Плохо разработанная система защище­на, пока детали остаются в секрете, но быстро ломается, как только о них кто-ни­будь узнает. Хорошо разработанная система безопасна, даже если ее детали обще­известны.

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

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

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

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

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

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

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

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

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

Взято из перевода книги «secrets and lies: digital security in a networked world».