Безопасность программного обеспечения с открытым исходным кодом

Проект программного обеспечения обычно представляет собой реализацию определённого алгоритма. Хотя каждую такую реализацию можно тестировать, а тесты в состоянии лишь выявить наличие ошибок (но не могут гарантировать их отсутствие), сами алгоритмы могут быть верифицированы формально. В случаях симметричного шифрования одной из основных предпосылок считается, что алгоритм должен быть известен, а в секрете хранится лишь часть информации — секретный ключ. Таким образом, чтобы шифр считался безопасным, необходимо доказать корректность алгоритма, и доказательство должно быть доступно всем желающим использовать шифр.

В связи с этим в области компьютерной безопасности существует консенсус, что алгоритмы должны быть открытыми, однако ведутся споры относительно того, должны ли их реализации быть открытыми (доступными на условиях открытого исходного кода) или оставаться закрытыми (проприетарными).

Затраты на аудит реализации существенно снижаются, если сосредоточиться на проверке соответствия проверенному алгоритму. При этом аудит невозможен без доступа к исходному коду, который предоставляется либо в программном обеспечении с открытым кодом, либо в случае условного доступа к проприетарному исходнику.

Крайне важно понимать, что проведение аудита программного обеспечения зависит от открытости исходного кода. Новая проверка проприетарного ПО возможна только при согласии владельца, тогда как аудит открытого ПО может быть произведён любым желающим в любое время.

Эта проблема становится всё более серьёзной по мере обнаружения в ПО закладок, а ранее устойчивые зоны безопасности подвергаются сомнению. Постоянно обсуждается вопрос — способствует ли ПО с открытым исходным кодом повышению безопасности или наоборот, но становится ясно, что наличие или отсутствие уязвимостей не всегда связано с типом лицензирования: закладки могут быть и там, и там. Между тем, только открытое программное обеспечение может быть свободно проверено, поэтому проприетарное ПО следует считать изначально менее безопасным^[1].

• Чем больше людей могут изучать исходный код, тем выше вероятность обнаружения и устранения уязвимостей. Это способствует как быстрому обнаружению преднамеренных уязвимостей, так и предотвращению внедрения вредоносных закладок со стороны разработчиков.
• Проприетарное программное обеспечение вынуждает пользователя соглашаться на тот уровень безопасности, который предоставляет поставщик, а также на частоту и объём предлагаемых обновлений и «патчей»^[2].
• Конечный пользователь открытого кода может изменить источник и реализовать любые дополнительные функции безопасности, вплоть до модификации ядра.
• Считается, что любой используемый компилятор порождает надёжный код, однако Кен Томпсон показал, что компилятор может быть скомпрометирован через закладку, приводящую к незаметному внедрению ошибок даже при отсутствии злого умысла у разработчика^[1]. Имея доступ к исходному коду компилятора, есть возможность обнаружить подобные вмешательства.
  • Дэвид А. Уилер продемонстрировал, что два независимых открытых автокомпилирующих компилятора, способных собирать друг друга, позволяют создать бинарные файлы, не заражённые закладкой Томпсона^[3].
• Принцип Керкгоффса утверждает, что противник может захватить надёжную систему, но не сможет скомпрометировать информацию. Эта идея стала основой многих современных защитных практик и гласит, что безопасность через неясность — порочная практика^[4].

• Злоумышленники также могут эффективнее находить уязвимости при наличии открытого исходного кода.
• Само по себе наличие открытого кода не гарантирует проведения его аудита. Например, когда Маркус Ранум, эксперт по проектированию систем информационной безопасности, опубликовал свой первый набор инструментов для межсетевых экранов, его использовали более 2000 сайтов, но лишь 10 человек сообщили о найденных ошибках или предложили исправления^[5].
• Большое количество участников, изучающих исходники, способно создать «ложное чувство безопасности» — многочисленность аудиторов не гарантирует, что уязвимости будут выявлены и устранены^[6].

Существует множество моделей и показателей для оценки безопасности системы. Ниже описаны некоторые методы, которые могут применяться для анализа защищённости ПО.

Считается, что система наиболее уязвима в момент выявления уязвимости и до выпуска исправления. Анализируя число дней между обнаружением и устранением уязвимости, можно сделать выводы об уровне защищённости системы. Важно учитывать, что не все уязвимости одинаково критичны; быстрое исправление множества ошибок иногда оказывается хуже, чем более тщательная работа с меньшим их количеством, и многое зависит от типа операционной системы и качества патча^[1].

Процесс Пуассона позволяет оценить скорость обнаружения дефектов безопасности в открытом и закрытом ПО. Процесс разделяют между числом добровольцев N_v и оплачиваемых аудиторов N_p. Скорость поиска ошибок добровольцами обозначают λ_v, а аудиторами — λ_p. Среднее время до обнаружения дефекта добровольцами — 1/(N_v λ_v), оплачиваемыми аудиторами — 1/(N_p λ_p)^[1].

Путём сравнения большого объёма проектов открытого и закрытого типа с помощью рейтинговой системы (по аналогии с анализом инвестиционных фондов компанией Morningstar, Inc.), можно количественно оценить безопасность ПО, если имеется достаточно обширная статистика. Пример такой шкалы^[7]:

• 1 звезда: много уязвимостей
• 2 звезды: проблемы надёжности
• 3 звезды: соблюдение лучших практик безопасности
• 4 звезды: документированный безопасный процесс разработки
• 5 звёзд: успешное прохождение независимого аудита

Компания Coverity совместно со Стэнфордским университетом разработала новый стандарт качества и безопасности открытого кода в рамках контракта с Департаментом внутренней безопасности США. Для выявления критических ошибок используются современные методы автоматизированного анализа исходного кода^[8]. Оценка качества и безопасности проводится по так называемым «ступеням», определяемым по прогрессу устранения ошибок и уровню взаимодействия с разработчиками^[9]. В данный момент определены следующие градации:

• Ступень 0 — проект был проанализирован Coverity, но представители разработчиков не проводили проверку результатов^[9].
• Ступень 1 — осуществляется сотрудничество между Coverity и командой проекта. Анализ выполняется с помощью ограниченного набора функций, чтобы не перегрузить команду разработчиков^[9].
• Ступень 2 — на этот уровень переходят проекты, не имеющие ни одного дефекта за год анализа. К таким проектам относятся AMANDA, ntp, OpenPAM, OpenVPN, Overdose, Perl, PHP, Postfix, Python, Samba, tcl^[9].