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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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