компьютеры способны сложить два 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, когда стало ясно, что многие пользователи и не беспокоятся по поводу установки исправления.
Кто-нибудь обращает внимание на подобные вещи?
На самом деле никто. Или, по крайней мере, совсем немногие. Поскольку потребность в средствах защиты программных продуктов огромна, их появляется все больше. А постоянная нехватка действительно компетентных экспертов приводит к тому, что все меньшее количество людей уделяют внимание проблемам безопасности.
Можно описать сценарий, по которому происходит проектирование большинства программных продуктов, имеющих средства защиты «внутри». Менеджер находит какого-нибудь парня, который считает, что безопасность – «это круто», и назначает его ответственным за эту часть системы. Этот человек может кое-что знать о безопасности, а может и не знать. Может, он прочитал одну-две книги по этой теме, а может быть, и нет. Проектирование системы защиты – вообще забавная вещь. Это как игра в «кошки- мышки». Или как в кино: агент против агента.
Проверка системы защиты происходит так же, как и проверка любой другой части системы: вы смотрите, как это работает, и делаете выводы. Все работает великолепно – в конце концов, безопасность не имеет никакого отношения к функциональным возможностям, – и менеджер счастлив.
Однако, поскольку уровень экспертизы систем безопасности вообще низок, оказывается, средства защиты совершенно неэффективны. Но никто не догадывается об этом.
Ситуация несколько лучше, если программный продукт является средством защиты. Более вероятно, что проектировщики что-то смыслят в безопасности. Но они не могут делать все. Однажды
