На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Оценка открытости системы

Мы отнюдь не являемся пионерами в области классификации уязвимых мест программного обеспечения. Однако несколько опубликованных вариантов класси­фикации уже морально устарели и в общем уже не отвечают глобальному подходу к проблеме. Традиционно при создании классификации недостатков программного обеспечения зачастую предпринимались попытки разделить ошибки в программном коде и ошибки, возникающие вследствие неверных действий пользователя (напри­мер, в результате неправильной конфигурации и т.д.), и исследовать их как отдель­ные независимые проблемы (Красл, 1998 год)4. Проблема в том, что риск для про­граммного обеспечения может быть оценен только по отношению к конкретной сре­де исполнения. Ведь в некоторых случаях потенциально губительная атака не может принести никакого вреда системе, поскольку эта атака успешно блокируется бранд­мауэром. Хотя конкретный фрагмент программного обеспечения атакуемого компь­ютера может быть уязвимым, но окружающая среда способна защищать его от атак. Программное обеспечение всегда является частью более крупной системы, в кото­рую входят аппаратные средства, языковые технологии и протоколы. Однако влия­ние среды исполнения имеет и оборотную сторону, поскольку часто среда исполне­ния только усиливает риск использования программного обеспечения.
Концепция открытых систем была впервые внедрена в термодинамике Людвигом фон Берталланфи (Ludwig von Bertalanffy). Фундаментальный принцип заключает­ся в том, что практически каждая техническая система существует как часть более крупной системы, все компоненты которой находятся в постоянном взаимодейст­вии. В результате при анализе риска приходится рассматривать систему на несколь­ких уровнях. В некоторых методах оценки риска использования программ не учиты­вается среда исполнения, но, по нашему мнению, риск не может быть оценен в отры­ве от контекста.
Чтобы продемонстрировать влияние среды на программное обеспечение, в каче­стве примера можно взять программу, которая без всяких проблем, связанных с безопасностью, долгие годы работала в частной сети, и установить ее на компьютер, подключенный к Internet. Нетрудно предположить, что показатель риска резко из­менится. Следовательно, бессмысленно рассматривать безопасность программного кода без сведений о наличии брандмауэра или о контексте, в котором работает про­граммное обеспечение. Подобно этому, нет смысла рассматривать систему обнару­жения вторжений в отрыве ot защищаемого ею программного обеспечения как от­дельный компонент сетевого уровня. Проблема в том, что программное обеспечение участвует в процессе взаимодействия по сети и простые настройки безопасности не закроют все бреши в системе защиты. И в то же время, напоминаем, что правильная настройка брандмауэра иногда позволяет блокировать атаку, которая бы могла при­вести к взлому Web-сервера.
И напоследок, разделение программного кода и среды исполнения, в которой он запускается, выглядит искусственным и неверным способом разграничения систе­мы. И действительно, подобные границы не имеют реального смысла на практике. Усложняющим фактором является возможность представить систему в виде много­численных компонентов, построенных по иерархическому принципу детализации системы. Рассматриваемая таким образом система представляет собой набор много­численных компонентов или объектов, функционирование которых происходит на различных уровнях, причем уровней этих очень много. Таким же образом каждая часть программного обеспечения системы может быть рассмотрена как набор много­численных компонентов или объектов разного уровня. И практически на всех уров­нях эти объекты взаимодействуют между собой.
Из вышесказанного следует вывод, что стандартная концепция "Ханойской баш­ни" (1) далека от действительности. Высокоуровневые приложения вызывают
низкоуровневые элементы операционной системы (даже на уровне BIOS) значи­тельно чаще, чем полагают многие. Таким образом, вместо ясной, понятной и четко организованной иерархии взаимодействия, более реальной представляется схема, согласно которой практически любой фрагмент программного кода способен взаи­модействовать с любой другой частью программного обеспечения на любом уровне. Таким образом, задача создания надежной системы защиты становится очень труд­ной, практически невозможной. В группы и домены может входить любой набор объектов, и практически любой объект включает в себя код и возможности настрой­ки. Значит, среда действительно имеет огромное значение, а поэтому ошибочно рас­сматривать код отдельно от среды исполнения.
В большинстве книг, посвященных проблемам безопасности информационных систем, затрагивается только среда "поблизости" от программного обеспечения. На­пример, рассказывается об устранении проблем при использовании маршрутизато­ра, брандмауэра или с помощью системы обнаружения вторжений. Только недавно (в 2001 году) появились книги, посвященные разработке безопасного программного обеспечения: Building Secure Software (авторы Viega и MacGraw, 2001) и Writing Se­cure Code (авторы Michael Howard и David LeBlanc, 2002).
По нашему мнению, методы разработки безопасного кода следует рассматривать в двух аспектах: безопасность программного обеспечения и безопасность приложений.
При выборе метода безопасности программного обеспечения защита от атак реализуется за счет создания программ, для которых безопасность является приори­тетом. Это достигается благодаря правильному проектированию программ (чего до­биться очень сложно) и устранению распространенных ошибок (что является эле­ментарной задачей). Перечислим связанные с этим аспектом вопросы: управление рисками программного обеспечения, платформы и языки программирования, аудит программного обеспечения, проектирование с учетом требований безопасности, про­счеты в системе безопасности (переполнения буфера, условия "гонки на выжива­


ние", контроль доступа и проблемы выбора паролей, случайности, криптографиче­ские ошибки и т.д.), тестирование системы безопасности. При обеспечении безопас­ности программного кода основное внимание уделяется тому, что должно создавать­ся безопасное программное обеспечение, проверке того, что оно является безопас­ным, и обучению разработчиков программ и пользователей.
Метод безопасности приложений позволяет организовать защиту от взломов программ "post facto", т.е. после завершения разработки приложения. Эта техноло­гия предусматривает введение жесткой политики относительно того, что может за­пускаться, как могут изменяться данные и какие функции должны выполняться программным обеспечением. Важными вопросами также являются выполнение про­граммного кода в замкнутом пространстве, защита от вредоносного кода, блокиро­вание исполняемых файлов, отслеживание действий выполняемых программ, при­менение политик и расширяемых систем.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика