Рассмотрим алгоритмы шифрования. Закрытые секретные алгоритмы появляются постоянно и затем вскрываются самым банальным образом. Каждый раз мы убеждаемся, что закрытые секретные алгоритмы – плохая идея. Тем не менее многие компании в различных отраслях промышленности продолжают выбирать частные, закрытые алгоритмы взамен открытых.
Обратимся к проблемам исправления ошибок. В начале 2000 года всего одна прореха в защите Microsoft Internet Information Server помогла хакерам украсть тысячи номеров кредитных карточек с разных сайтов электронной торговли. Microsoft выпустила «заплату», в которой эта ошибка была исправлена еще в июле 1998, и еще раз напомнила о необходимости установить эту «заплату» в июле 1999, когда стало ясно, что многие пользователи и не беспокоятся по поводу установки исправления.
Кто-нибудь обращает внимание на подобные вещи?
На самом деле никто. Или, по крайней мере, совсем немногие. Поскольку потребность в средствах защиты программных продуктов огромна, их появляется все больше. А постоянная нехватка действительно компетентных экспертов приводит к тому, что все меньшее количество людей уделяют внимание проблемам безопасности.
Можно описать сценарий, по которому происходит проектирование большинства программных продуктов, имеющих средства защиты «внутри». Менеджер находит какого-нибудь парня, который считает, что безопасность – «это круто», и назначает его ответственным за эту часть системы. Этот человек может кое-что знать о безопасности, а может и не знать. Может, он прочитал одну-две книги по этой теме, а может быть, и нет. Проектирование системы защиты – вообще забавная вещь. Это как игра в «кошки-мышки». Или как в кино: агент против агента.
Проверка системы защиты происходит так же, как и проверка любой другой части системы: вы смотрите, как это работает, и делаете выводы. Все работает великолепно – в конце концов, безопасность не имеет никакого отношения к функциональным возможностям, – и менеджер счастлив.
Однако, поскольку уровень экспертизы систем безопасности вообще низок, оказывается, средства защиты совершенно неэффективны. Но никто не догадывается об этом.
Ситуация несколько лучше, если программный продукт является средством защиты. Более вероятно, что проектировщики что-то смыслят в безопасности. Но они не могут делать все. Однажды разработчик брандмауэра рассказал мне о недостатках в его коде, приводящих к переполнению буфера. Он сказал, что сделал все возможное, чтобы гарантировать отсутствие подобных вещей, но он не мог проверять всех остальных программистов в команде. Он пробовал, но не смог. Несколько серьезных недостатков в коде, связанных с переполнением буфера, были обнаружены и исправлены за последующие годы. И нет оснований предполагать, что необнаруженных ошибок больше не осталось.