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

Глава 22

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

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

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

На протяжении всей книги я подчеркивал, насколько трудно обеспечить действительную безопасность. Одно дело – спроектировать систему обороны, другое – должным образом реализовать ее, третье – исключить влияние ятрогенных эффектов,[57] но совсем другое – провести испытания и убедиться в том, что все сделано правильно.

Раньше я был президентом 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], давая возможность группе преступных хакеров извлечь выгоду из уязвимых мест как (1) в промежутке времени между их обнаружением и опубликованием «заплаты», так и (2) после этого, поскольку многие системные администраторы не используют «заплаты» Microsoft.

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

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

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

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, лживо отрицает в прессе реальность обнаруженных уязвимых мест, будет ли правильным опубликовать реальный сценарий нападения? Я считаю, что нужно содействовать решению проблем, а не создавать новые. Полное раскрытие – это часть решения. Устранение проблемы и усиление безопасности сети – тоже часть решения. Я не против тех средств, которые можно применять как в хороших, так и в дурных целях, но я не приемлю те средства, которые предназначены только для скверных дел.

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

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

(Ин 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 и т. д. Они в равной степени удовлетворяют требованиям безопасности. Каждая сеть безопасна и каждая может быть взломана. Обычный пользователь не имеет никакой возможности увидеть разницу. Специалист в области безопасности сумеет это сделать, но уйдет полгода работы на то, чтобы он составил свое мнение. Это просто не оправдывает затрат.

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