Поскольку электронная почта встречается повсеместно, путешествующие с ее помощью опасные программы в силах проникнуть куда угодно. Они могут просочиться через такое интернет-соединение, через которое больше ничего не проходит. Их нельзя остановить брандмауэром; они проникают сквозь него, неожиданно оказываются внутри системы и производят повреждения. Эффективность брандмауэров будет снижаться по мере того, как мы будем расширять перечень используемых служб (e-mail, Веб и т. п.) и добавлять все более сложные приложения во внутреннюю сеть, а авторы разрушительных программ будут принимать все это во внимание. Такой метод «проникновения внутрь с последующей работой» еще более ухудшит ситуацию.
В настоящее время, разрабатывая средства для защиты от вирусов, червей и троянов, стараются подражать биологическим принципам борьбы с вирусами. Тем не менее я настроен скептически по двум причинам. Прежде всего биологические вирусы эволюционируют медленно: удачные новые мутации со временем могут закрепиться, а затем медленно распространиться по виду. Биологические иммунные системы приспособлены именно к атакам такого рода. А компьютерные вирусы, в отличие от биологических, специально создают «смертельными».
Вторая причина моего скепсиса в том, что биологические иммунные системы ориентированы на то, чтобы защищать вид за счет отдельной особи. Относительно генофонда – это правильная стратегия, но для защиты конкретного компьютера от разрушительных программ она не годится.
Мне кажется более интересным такое решение: связать компьютеры с центром автоматического выявления вирусов. Если какой-нибудь компьютер замечает подозрительный код, он отсылает его для последующего анализа. Такой подход имеет помимо перспективы и ряд новых опасностей. Кроме того, он все-таки не сможет обеспечить необходимую скорость обнаружения вирусов. Любая крупная рассредоточенная система в любом случае допускает возможность заражения вирусами. Если система безопасности не продумана снизу доверху, мы должны быть постоянно готовы к борьбе с попытками установить контроль над системой.
Легко критиковать Microsoft за усугубление проблемы. Языки сценариев Microsoft являются довольно мощным средством, однако они созданы в предположении, что все, с чем вы работаете, заслуживает доверия. Эти языки позволяют иметь доступ ко всем ресурсам операционной системы (сравните с моделью безопасности Java). Они позволяют разрушительным программам использовать свойства Microsoft Outlook для автоматической рассылки своих копий корреспондентам пользователя. Microsoft, безусловно, заслуживает порицания за то, что созданные ею мощные средства – Word и Excel – размывают границы между исполняемыми файлами, которые потенциально таят опасность, и файлами данных, бывшими до сих пор безопасными. Он заслуживает осуждения и за то, что интегрированная в Outlook 2000 поддержка языка HTML допускает возможность внедрения основанной на HTML разрушительной программы при простой загрузке электронного сообщения (оно автоматически открывается в режиме предварительного просмотра). А также за то, что разрушительная программа может использовать интеграцию ActiveX в Internet Explorer 5.0, чтобы распространяться без участия пользователя. Microsoft создала операционную среду, в которой разрушительные программы легко создаются, легко распространяются и могут причинять множество неприятностей. Но основная проблема, состоящая в том, что мобильный код не заслуживает доверия, намного более остра.
В прежние времена (в 1970-х) компьютерные программы были крупными и громоздкими, их было трудно писать, и еще труднее использовать. Затем кому-то пришла идея поделить большие программы на мелкие, более простые для понимания компоненты. Объектно-ориентированное программирование, C++, подключаемые модули – все это различные реализации этой идеи. Проблема в том, что современное программное обеспечение, в основе которого лежат небольшие компоненты, намного сложнее защитить.
Рисунок 10.1 иллюстрирует принцип, по которому построены старые программы: большие приложения опираются на небольшую операционную систему. Большинство современных программ похожи на Приложение 1 – приложения с компонентами – или на Приложение 2 – приложения с компонентами, состоящими из компонентов (рис. 10.2).