Обеспечение надежности. Надежность означает, что система делает то, что ей положено делать, и ничего лишнего. Технология, которая смогла бы обеспечить надежность программ, была бы незаменимой для компьютерной безопасности.
Большинство подобных технологий все еще находятся в стадии разработки. Я не буду делать скидок ни для одной из них. Практические результаты если и появятся, то, скорее всего, только в далеком будущем. Хотя если чему-то и научило нас двадцатое столетие, то это – как можно реже употреблять слово «невозможно».
Научимся ли мы когда – нибудь?
Рассмотрим нападения, приводящие к переполнению буфера. Впервые о них заговорили в сообществе безопасности в начале 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, который будет использован кем-нибудь для получения сорока миллионов или около того учетных записей, защищенных паролем или нет, и даже не потрудится принести извинения.
Производители программного обеспечения могут и не беспокоиться о качестве своих продуктов, так как не несут за это никакой ответственности. (То есть ответственность существует, но она ограничивается заменой гибкого диска или компакт-диска с физическими дефектами.) Поэтому средства защиты могут и вовсе не обеспечивать безопасность, так как никто не сумеет предъявить иск их производителям, обманувшим покупателя лживыми заверениями.
В конце концов, эта ситуация приводит к тому, что рынок не поощряет создание действительно безопасных продуктов. Их разработка требует больше труда, времени и средств. Покупатели же не знают, как отличить надежный продукт от негодного. На этом рынке можно добиться успеха, выпустив программное обеспечение, о надежности которого производитель позаботился лишь постольку, поскольку это ему необходимо, чтобы избежать неприятностей.
