Текст книги "Секреты и ложь. Безопасность данных в цифровом мире"

Автор книги: Брюс Шнайер

сообщить о нарушении

Текущая страница: 29 (всего у книги 34 страниц)

Глава 22
Испытание и верификация программных продуктов

Мы уже неоднократно затрагивали тему испытания средств безопасности. В главе 7 обсуждался выбор криптографических примитивов. Там же была выдвинута идея, что наилучшим способом проверки надежности криптографии является открытый криптоанализ, проводимый в течение многих лет. В главе 8 мы рассматривали различные стандарты безопасности компьютера – Оранжевую Книгу и Общие Критерии, а также проверку их соответствия этим стандартам. В главе 13 обсуждались надежность программного обеспечения и то, как ошибки оборачиваются уязвимостью. Испытания позволяют проверить работоспособность системы безопасности: одно дело смоделировать угрозы, разработать политику безопасности и применить меры противодействия, но будут ли эти меры работать на самом деле? Несомненно, вы уже приобрели солидный брандмауэр или антивирусную программу, или VPN (виртуальную частную сеть), или систему защиты от мошенничества для платного телевидения, или систему биометрического контроля, или основанную на использовании смарт-карт систему расчетов, или программу шифрования электронной почты и т. п., но достаточно ли прочна их защита? Большинство программных продуктов ненадежны, и причина кроется в недостаточности тестирования.

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

На протяжении всей книги я подчеркивал, насколько трудно обеспечить действительную безопасность. Одно дело – спроектировать систему обороны, другое – должным образом реализовать ее, третье – исключить влияние ятрогенных эффектов,[57]57
  Медицинский термин. «Ятрогенные заболевания (от греч. Iatros – врач и ген) – психогении, обусловленные неосторожными высказываниями или поведением медицинских работников, которые создают у человека представление о наличии у него какого-либо заболевания или об особой тяжести имеющейся у него болезни.» – Примеч. ред.


[Закрыть] но совсем другое – провести испытания и убедиться в том, что все сделано правильно.

Раньше я был президентом Counterpane Systems, консультационной компании по вопросам шифрования и безопасности. Большую часть времени я тратил на оценку продуктов компьютерной безопасности. Как правило, меня приглашали, когда продукт был почти готов, чтобы проверить, действительно ли он безопасен. Более разумные заказчики обращались ко мне на раннем этапе разработок, чтобы удостовериться в безопасности разработки. Иногда я оценивал готовый продукт, основанный на решениях, которые были проанализированы мною ранее. Эта глава – квинтэссенция того опыта.

Неудачи испытаний

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

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

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

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

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

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

К сожалению, слишком многие программные продукты, даже продукты безопасности, имеют те же проблемы.

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

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

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

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

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

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

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

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

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

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

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

Выявление недостатков защиты продуктов при использовании

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

Так или иначе, кто-нибудь да находит уязвимые места в системе безопасности. И что дальше?

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

Но сначала немного истории.

В 1988 году, после того как использование червя Морриса продемонстрировало, насколько легко провести нападение через Интернет, Агентство перспективных исследовательских программ (Defense Advanced Research Projects Agency, DARPA) начало финансирование группы, которая, как предполагалось, будет координировать ответные меры безопасности, повышать уровень осведомленности в вопросах безопасности и вообще делать много полезных вещей. Она называется Группой компьютерной «скорой помощи» (Computer Emergency Response Team, CERT), ее центральное подразделение находится в Университете Карнеги-Меллона в Питсбурге.

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

Это хорошо выглядит в теории, но плохо работает на практике. Были три главные претензии к этой системе. Во-первых, CERT медленно проверяла наличие уязвимых мест, поскольку получала множество сообщений и не успевала справляться с работой. Во-вторых, производители не торопились исправлять ошибки, о которых им сообщала CERT, поскольку она не публиковала никакие сведения, прежде чем ошибки были исправлены, и не было необходимости в спешке. И в-третьих, CERT не сразу публиковала сообщения даже после того, как все исправления были сделаны.

Практика полного раскрытия возникла из-за общего разочарования в описанной процедуре. Конференции в Интернете, такие как Bugtraq и NT Bugtraq (организованные в 1993 и в 1997 годах соответственно), превратились в форум для людей, считавших, что производителей извещать бесполезно, а единственный способ повысить безопасность – предавать гласности случаи, когда ее средства оказываются ненадежны. Это была реакция протеста на «башню из слоновой кости», воздвигнутую учеными, хранившими в тайне свои познания. Как писал один хакер: «Теперь обсуждение проблем безопасности не будет ограничено закрытыми списками рассылки так называемых специалистов по вопросам безопасности, и подробности можно будет найти не только в пространных, перегруженных деталями академических статьях. Напротив, информация станет общедоступной, и каждый сможет использовать ее по своему усмотрению».

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

В то же время хакеры используют эти рассылки для сбора информации об уязвимых местах и для написания вредоносных программ. Некоторые виды нападений довольно сложны, но те, кто способен разобраться в них, могут составить программы с интерфейсом вида «выбрать и щелкнуть», которые сумеют использовать и все остальные. Это – обратная сторона полного раскрытия, которая может быть истолкована таким образом, что публикация подробностей об уязвимых местах приносит больше вреда, чем пользы, вооружая хакеров средствами для взлома системы. Те, кто придерживается такой точки зрения, считают, что средства безопасности лучше работают, если их уязвимые места не обнажаются перед публикой.

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

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

Следующий пример поясняет сказанное. В апреле 1999 года кто-то обнаружил брешь в Microsoft Data Access Components, которая позволяла контролировать удаленную систему Windows NT. Об этом сразу же было сообщено в открытой конференции. Хотя ее модератор утаил от публики подробности этой опасности больше чем на неделю, все же какой-то хакер провел анализ и выяснил детали, которые позволяли использовать уязвимость.

Примерно в то же самое время Microsoft выпустила «заплату», которая должна была препятствовать нападающим в использовании уязвимости пользовательских систем. Microsoft также издала бюллетень по этой теме безопасности и опубликовала несколько других сообщений по вопросам безопасности.

Но «заплата» Microsoft не смогла чудесным образом устранить причину опасности. В тот же год, во время празднования Дня Всех Святых хакеры, воспользовавшись уязвимостью системы, стерли более чем 25 веб-сайтов, основанных на NT, принадлежавших администраторам безопасности, которые не беспокоились (или даже не знали, что следовало побеспокоиться) об обновлении конфигурации в течение шести месяцев.

Вот и все в двух словах.

Microsoft никогда не исправила бы это уязвимое место, если бы не существовал сценарий его использования (exploit script). В других случаях Microsoft заходила так далеко, что или полностью игнорировала проблему, объявляя опасность «чисто теоретической» и поэтому не заслуживающей внимания, или утверждала, что исследователь лжет. Вопросы болевых точек безопасности беспокоят Microsoft лишь в связи с формированием общественного мнения. Когда возникает проблема, компания что-нибудь предпринимает, но редко заранее. Таким образом, огласка сведений об уязвимых местах приводит к их устранению.

Эти сведения также позволяют написать имитатор атаки[58]58
  Exploit script – наиболее близкий перевод – «сценарий использования ошибок или дефектов в программах в своих интересах». Эквивалента в русском языке пока не имеется. Наиболее подходящее определение – «имитатор атак» – введено в употребление экспертом по сетевой безопасности А. Лукацким (exploit применяется в процессе «зондирования»). – Примеч. ред.


[Закрыть], давая возможность группе преступных хакеров извлечь выгоду из уязвимых мест как (1) в промежутке времени между их обнаружением и опубликованием «заплаты», так и (2) после этого, поскольку многие системные администраторы не используют «заплаты» Microsoft.

Что лучше: публиковать сведения или сохранять их в тайне?

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

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

Netscape обычно предлагала 1000 долларов (и тенниску в придачу) в награду нашедшему дефект в безопасности своего программного обеспечения. Было выписано всего несколько чеков, однако в 1997 году датский хакер нашел прореху в системе безопасности и потребовал большие деньги. Дело обернулось так, что он не получил своих денег: его описание эффектов, связанных с программными ошибками, позволило инженерам Netscape воспроизвести и устранить их и без его помощи. В 2000 году французский исследователь обнаружил, как взломать систему безопасности смарт-карт СВ (Groupement des Cartes Bancaries). Затем, по сведениям из разных источников, он то ли предложил свои услуги, то ли занялся шантажом. В конечном счете он был арестован и осужден условно.

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

Этот последний вопрос никогда не имел должного обсуждения. Публикация слабых мест безопасности – это своего рода «атака ради огласки»: исследователь хочет увидеть свое имя в газете. Иногда такие сведения разглашает или консультант по вопросам безопасности, или служащий компании, которая занимается оценкой уязвимости или предлагает средства защиты сети. Это особенно верно, если новость появилась в прессе; сообщение в PR Newswire или Business Wire дорого обходится, и никто не будет этого делать, не будучи уверенным, что затраты окупятся.

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

Но бывают и исключения из правил.

Во-первых, я против такой огласки, которая, прежде всего, сеет панику. Сообщения о слабых местах, о которых нет достаточных свидетельств, очень вредны. (Пример тому – случай, когда кто-то обнаружил переменную, содержащую три буквы NSA, в шифровании API Microsoft[59]59
  Программный интерфейс шифрования Crypto API, обеспечивающий шифрование и передачу электронной подписи для приложений независимых производителей. – Примеч. ред.


[Закрыть] и объявил, что Агентство национальной безопасности (National Security Agency) установило лазейку в изделия Microsoft.) Так же плохи сообщения об уязвимых местах в ответственных системах, которые не могут быть легко устранены и знания о которых способны причинить серьезный вред (например, программное обеспечение управления воздушным движением). Я полагаю, что это остается на совести исследователей – определять баланс выгоды от раскрытия уязвимости и связанных с этим опасностей.

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

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

Иногда трудно определить, что хорошо и что плохо. Средства оценки уязвимости могут использоваться как для укрепления безопасности, так и для взлома системы. Средства удаленного доступа во многом похожи на Back Orifice. Если такая компания, как Microsoft, лживо отрицает в прессе реальность обнаруженных уязвимых мест, будет ли правильным опубликовать реальный сценарий нападения? Я считаю, что нужно содействовать решению проблем, а не создавать новые. Полное раскрытие – это часть решения. Устранение проблемы и усиление безопасности сети – тоже часть решения. Я не против тех средств, которые можно применять как в хороших, так и в дурных целях, но я не приемлю те средства, которые предназначены только для скверных дел.

В холле здания ЦРУ высечена в камне цитата из Библии:

«И познаете истину, и истина сделает вас свободными»

(Ин 8: 32).

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

Открытые стандарты и открытые решения

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

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

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

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

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

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

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

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

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

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