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

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

Предельно упрощая, допустим, что система имеет 10 различных настроек, по 2 возможных варианта. Тогда 45 различных комбинаторных сочетаний могут взаимодействовать самым неожиданным образом, и в целом наберется 1024 различные конфигурации. Каждое взаимодействие способно привести к недостаткам безопасности и должно быть особо проверено. Теперь предположите, что система имеет 20 различных настроек. Это означает 190 различных сочетаний (по 2 из 20) и примерно 1 миллион конфигураций (2^20). 30 различных настроек определяют 435 различных пар и миллиард конфигураций. Даже небольшие увеличения в сложности системы означают стремительный рост количества различных конфигураций.

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

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

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

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

Реальные системы не показывают никаких признаков уменьшения сложности. Фактически они становятся более громоздкими все быстрее и быстрее. Microsoft Windows – пример такой тенденции. Windows 3.1, выпущенная в 1992 году, имеет 3 миллиона строк кода. В 1998 году Windows NT 5.0 насчитывала уже 20 миллионов строк кода, а в 1999 году она была переименована в Windows 2000 и содержала в среднем от 35 до 60 миллионов строк кода. Сравнительные данные приведены в табл. 23.1.

Операционная система (Год) – Количество строк кода

Windows 3.1 (1992) – 3 млн

Windows NT (1992) – 4 млн

Windows 95 (1995) – 15 млн

Windows NT 4.0 (1996) – 16,5 млн

Windows 98 (1998) – 18 млн

Windows 2000 (2000) – 35-60 млн (приблизительно)

Windows 2000 ошеломляет своим размером, и будет иметь больше изъянов защиты, чем Windows NT 4.0 и Windows 98 вместе взятые. В свое оправдание Microsoft утверждала, что нужно потратить 500 человеко-лет, чтобы сделать Windows 2000 безопасной. Я привел эти цифры только для того, чтобы продемонстрировать, насколько неадекватна эта оценка[65].

Вы также можете видеть, что сложность увеличивается, по количеству системных вызовов. Версия UNIX 1971 года имела 33 вызова. В начале 1990-х их количество в операционных системах достигало уже 150. Windows NT 4.0 SP3 имеет 3433. Количество системных вызовов для различных операционных систем представлено в табл. 23.2.

Вначале брандмауэры имели дело только с FTP (протоколом передачи файлов), протоколами Telnet, SMTP, NNTP и службой DNS. И это все. Современные брандмауэры должны взаимодействовать с сотнями протоколов и с запутанным набором правил доступа к сети. Некоторые новые протоколы разработаны подобно HTTP, чтобы они могли «работать с брандмауэром» (то есть обходить его). И пользователи, устанавливающие автоматическую связь, могут не беспокоиться о брандмауэре; теперь для этой цели существуют широкополосные аппаратно-программные средства с DSL и кабельными модемами. Хуже того, существует доступное программное обеспечение, позволяющее пользователям домашних компьютеров представлять себя в качестве веб-серверов. Больше особенностей, больше сложности, меньше надежности.

Операционная система(Год) – Количество системных вызовов

UNIX 1ed (1971) – 33

UNIX 2ed (1979) – 47

SunOS 4.1 (1989) – 171

4.3 BSD Net 2 (1991) – 136

SunOS 4.5 (1992) – 219

HP UX 9.05 (1994) – 163

Line 1.2 (1996) – 211

SunOS 5.6 (1997) – 190

Linux 2.0 (1998) – 229

Windows NT 4.0 SP3 (1999) – 3 433

Сертифицированный открытый ключ в Х.509 версии 1 был определен на 20 строках ASN.1. Сертификат Х.509 версии 3 занимает приблизительно 600 строк. Сертификат SET – 3000 строк.

Полный стандарт SET занимает 254 страницы. И это только формальная спецификация протокола; есть еще руководство для программиста на 619 страницах и бизнес-описание на 72 страницах. По различным причинам SET никогда не будет широко использоваться, но в любом случае я полагаю, что никто не способен пробраться через все эти лабиринты, не наделав ошибок. Ошибки в работе программного обеспечения обнаруживаются главным образом во время бета-тестирования, но при этом недостатки защиты, скорее всего, не будут найдены. Тем не менее они там будут. Если их найдет порядочный человек, то он опубликует свои исследования в печати. Если их обнаружит мошенник, то он воспользуется ими для внедрения в систему кредитных карт: возможно, для получения крупной суммы денег или для создания поддельного счета на кредитной карте, возможно, затем, чтобы повлиять на обработку данных кредитных карточек и подчинить себе всю систему.

Сложность пробирается во все. В 2000 году вычислительные возможности «Мерседес 500» были больше, чем 747—200[66]. Мой старый термостат имел один наборный диск, и было легко установить температуру. Мой новый термостат имеет цифровой интерфейс и руководство по программированию. Я гарантирую, что большинство людей понятия не имеют, как его заставить работать. Термостаты, основанные на системе Home Gateway от Sun Microsystems, могут быть подключены к Интернету, так что вы можете заключить договор с какой-нибудь компанией, занимающейся контролем окружающей среды, для управления вашим хитроумным устройством. Sun рисует в своем воображении связь с Интернетом для всех ваших приборов и дверных замков. Вы думаете, кто-нибудь проверит программное обеспечение рефрижератора на наличие изъянов защиты? Я уже рассказывал о современном злонамеренном коде и о взаимодействии сценариев Java, HTML, CGI и веб-браузеров. Есть кто-нибудь, кто беспокоится, что новые сотовые телефоны, работающие с Wireless Access Protocol, будут способны пересылать апплеты Java? И только вопрос времени, когда появится вирус, поражающий сотовые телефоны.

Компьютерные игры имели обыкновение быть простыми. Теперь можно играть, используя сеть. Любой в состоянии зайти на веб-сайт и принять участие в игре с несколькими игроками. Сейчас кто-нибудь еще может войти в систему компьютера игрока через Интернет. Престо, теперь он «сервер»! Мама и папа могут держать в компьютере некую конфиденциальную информацию (рабочие секреты, финансовые данные) а их отрок предоставляет всем возможность проникнуть внутрь. Кто-нибудь проверяет безопасность этих игр? Уязвимость в функции автоматического обновления игры Quake3 Arena позволяет нападающему модернизировать любой файл на компьютере пользователя. Napster также делает доступным ваш компьютер, после чего вы, скорее всего, найдете ошибки переполнения в программном обеспечении.

Положение ухудшается. Нынешнее поколение игровых приставок (Sega Dreamcast, Sony PlayStation 2) выпускается с такими свойствами, как 56-килобайтовые модемы, IP-стеки и веб-браузеры. Миллионы из них уже проданы. Возможно, браузеры и операционные системы будут безопасны; если – да, то такое случится впервые. Хорошая шутка: вы играете с кем-нибудь в Sonic через модем, и вдруг этот игрок проникает в ваш компьютер и побеждает! Если это только игровой пульт, то круто! Это не повод для волнения. Но не забывайте, что игровые компании требуют, чтобы вы делали все электронные покупки с помощью игрового пульта. Там будут и номера кредитной карточки, и электронный бумажник, и много чего еще. Добро пожаловать в мир, в котором ошибка переполнения буфера в Tekken 3 поставит под угрозу вашу финансовую безопасность.

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

Конечно, ошибки безопасности обнаруживаются и исправляются, но это сизифов труд. Изделие «программное обеспечение» уже выпущено. Через какое-то время ошибки безопасности найдены и устранены, и безопасность улучшается. Затем выходит версия 2.0 с новым кодом, с добавленными особенностями и увеличенной сложностью – и мы опять там же, откуда и начинали. Бывает и хуже.

У военных это называется «среда, насыщенная целями»[67].

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

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

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

Я повторюсь: сложность – самый ярый враг безопасности. Безопасные системы должны быть «обрезаны до кости» и сделаны настолько простыми, насколько это возможно. И нет никакой замены этой простоте. К сожалению, простота противоречит основным тенденциям развития цифровых технологий.

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

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

Крупные достижения факторизации. Вызывает опасение, что все алгоритмы открытых ключей базируются в основном на двух математических задачах: проблеме разложения на множители больших чисел (факторизации) или проблеме дискретного логарифмирования. Разложение на множители становится осуществлять все легче, и это происходит намного быстрее, чем кто-либо думал. Не доказано математически, что эти проблемы невозможно решить, и, хотя математики так не думают, может быть, кто-нибудь придумает способ эффективного решения этих проблем еще в наши дни. Если это случится, то мы окажемся в мире, где криптография открытых ключей не будет работать, и тогда главы этой книги будут представлять только исторический интерес. Но все не так страшно; инфраструктура аутентификации, основанная на симметричном шифровании, может служить для той же цели. Но в любом случае я не думаю, что это произойдет[68].

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

Аппаратные средства сопротивления вторжению. Многие проблемы безопасности устраняются, если использовать для защиты информации аппаратные средства сопротивления вторжению. Бурное развитие технологий привело к значительному уменьшению стоимости средств защиты от несанкционированного вмешательства[70].

Искусственный интеллект. Работа многих защитных средств может быть сведена к выполнению простой задачи: пропускать полезное содержимое, задерживая при этом вредоносное. Так работают брандмауэры, системы обнаружения вторжения, антивирусное программное обеспечение, VPN, системы защиты от мошенничества с кредитными картами и множество других вещей. Они подразумевают два подхода: неосмысленный (если есть любой из десятков тысяч образцов поиска в файле, следует, что файл заражен вирусом) или интеллектуальный (если программа начинает делать подозрительные вещи, скорее всего, завелся вирус, и вы должны все исследовать). Последнее кажется внушающим ужас, вызывает пугающие ассоциации с искусственным интеллектом. Что-то подобное было испытано как антивирусный механизм и в конце концов оказалось менее эффективным, чем примитивная модель проверочного сканера. Подобные идеи моделируются в некоторых продуктах обнаружения вторжения, и все еще неясно, делают ли они что-нибудь лучше, чем методичный поиск сигнатур, которые свидетельствуют о внедрении[71]. Однако когда-нибудь это может стать большим делом: если в области искусственного интеллекта со временем произойдет существенный прогресс, мы получим революцию в компьютерной безопасности.

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

Безопасные сетевые инфраструктуры. Интернет не безопасен, безопасность никогда не стояла в планах для этой системы. Люди, которые будут работать в Интернете II, должны в первую очередь подумать о безопасности. При создании этой новой сети следует допустить, что кто-то будет перехватывать и пытаться похищать сетевые соединения и что заголовок пакета данных, возможно, будет подделан[72]. Нужно учесть, что пользователи в большинстве случаев не могут доверять друг другу, и рассматривать с этой точки зрения все виды приложений. Существует множество проблем, которые нельзя разрешить с помощью самых лучших протоколов сети, но некоторые можно.

Анализ трафика. Технология анализа трафика все еще находится в периоде становления, и я думаю, что новые интересные достижения в этой области появятся в следующем десятилетии[73]. Методы защиты трафика должны еще долго совершенствоваться, чтобы они могли обеспечить должный уровень защиты любой сети.

Обеспечение надежности. Надежность означает, что система делает то, что ей положено делать, и ничего лишнего. Технология, которая смогла бы обеспечить надежность программ, была бы незаменимой для компьютерной безопасности.

Большинство подобных технологий все еще находятся в стадии разработки. Я не буду делать скидок ни для одной из них. Практические результаты если и появятся, то, скорее всего, только в далеком будущем. Хотя если чему-то и научило нас двадцатое столетие, то это – как можно реже употреблять слово «невозможно».

Рассмотрим нападения, приводящие к переполнению буфера. Впервые о них заговорили в сообществе безопасности в начале 1960-х (система с разделением времени пострадала от такой атаки), и, вероятно, они описывались в литературе по безопасности еще раньше. В 70-е годы первые компьютерные сети имели много недостатков, которые часто использовались для нападения. В 1988 году компьютерный червь Морриса вызывал переполнение буфера, используя команду fingerd UNIX (распространенный способ нападения этого типа). Теперь, через 10 лет после появления червя Морриса и примерно через 35 лет после первоначального обнаружения такого способа нападения, можно было бы предполагать, что сообщество безопасности наконец-то решило проблему защиты буфера. Но это не так. В 1998 году более чем две трети всех обращений в CERT были связаны с проблемами, вызванными переполнением буфера. В 1999 году в течение двух особенно неудачных для Windows NT недель, в NT-приложениях было обнаружено 18 различных изъянов, открывающих дорогу для такой атаки. Когда в первую неделю марта 2000 года я стал собирать факты, с описания которых начал эту книгу, среди них мне встретились три случая ошибки переполнения буфера. Пример с переполнением буфера – это низко висящий плод. Но если мы когда-либо и научимся решать эту проблему, тут же появятся другие, возможно, еще более сложные.

Рассмотрим алгоритмы шифрования. Закрытые секретные алгоритмы появляются постоянно и затем вскрываются самым банальным образом. Каждый раз мы убеждаемся, что закрытые секретные алгоритмы – плохая идея. Тем не менее многие компании в различных отраслях промышленности продолжают выбирать частные, закрытые алгоритмы взамен открытых.

Обратимся к проблемам исправления ошибок. В начале 2000 года всего одна прореха в защите Microsoft Internet Information Server помогла хакерам украсть тысячи номеров кредитных карточек с разных сайтов электронной торговли. Microsoft выпустила «заплату», в которой эта ошибка была исправлена еще в июле 1998, и еще раз напомнила о необходимости установить эту «заплату» в июле 1999, когда стало ясно, что многие пользователи и не беспокоятся по поводу установки исправления.

Кто-нибудь обращает внимание на подобные вещи?

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

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

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

Однако, поскольку уровень экспертизы систем безопасности вообще низок, оказывается, средства защиты совершенно неэффективны. Но никто не догадывается об этом.

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

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

Они ничему не учатся, потому что и не должны учиться.

Средства защиты компьютера, так же как и программное обеспечение в общем, обычно соответствуют довольно странным представлениям о качестве. Здесь ситуация другая, чем в случае с автомобилем, небоскребом или упаковкой с жареным цыпленком. Если вы покупаете какую-либо вещь и терпите урон по вине изготовителя, вы можете предъявить иск и выиграть дело. Производителю автомобилей не избежать неприятностей, если автомобиль взорвется при столкновении. Буфетчик не останется без проблем после продажи земляничного пирога с крысой внутри. Чего никогда не скажут подрядчики-строители, так это: «Ну что ж. Мы скоро построим второй небоскреб, и уж он не упадет на все 100%». Эти компании ответственны за свои действия.

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

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

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

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

Крупные производители знают это, как и то, что создавать надежное программное обеспечение не выгодно. Согласно исследованиям, 90-95% всех программных изъянов безобидны, они не сказываются на работе программ, и пользователи их не замечают. Намного дешевле выпускать программное обеспечение с дефектами и затем исправлять обнаруженные 5-10% ошибок.

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

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