Брюс Шнайер - Секреты и ложь. Безопасность данных в цифровом мире

Дерево атак обладает еще одним ценным свойством: содержащиеся в нем сведения остаются актуальны в дальнейшем. Однажды построив дерево атак PGP, вы сумеете использовать его в любой другой ситуации, когда речь идет о PGP. Эта схема может быть включена в другую, более обширную. Например, на рис. 21.2 представлена схема, целью которой является прочтение определенного письма, посланного с одного компьютера, использующего Windows 98, на другой. Если вы посмотрите на терминальные узлы дерева, то заметите, что целые деревья атак на PGP и на сейф вставлены в этот план нападения.

Такая возможность расширения схемы означает, что вам не обязательно знать все на свете. Если вы используете PGP, то вам не нужно знать детали дерева атак на PGP; все, что вы должны знать, – это значения корневого узла. Если вы эксперт в области компьютерной безопасности, вам не обязательно быть в курсе, насколько трудно взломать сейф определенной модели, нужна оценка значений корневого узла. Создав однажды библиотеку деревьев атак на определенные виды компьютерных программ, дверные и оконные замки, на сетевые протоколы безопасности и т п., вы можете затем использовать их где угодно.

Глава 22

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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