Некоторые наблюдатели, подвергая критике ПО с открытым исходным кодом, в качестве потенциальной угрозы для безопасности называют значительную базу разработчиков Open Source. По мнению Иена Леви, технического директора одного из департаментов британской разведывательной службы GCHQ, ответственной за ведение радиоэлектронной разведки и обеспечение защиты информации органов правительства и армии, такая точка зрения лишена оснований. Эксперт полагает, что когда речь заходит о безопасности, то между ПО с открытым исходным кодом и проприетарным софтом можно поставить знак равенства.
На недавно состоявшейся в Лондоне конференции Open Source, Open Standards Леви попытался развеять существующие мифы об открытом ПО, заодно выделив подлинные проблемы в области легитимности и безопасного использования софта Open Source.
Мифы
Открытое ПО более (или менее) безопасно, нежели проприетарное
“Нет никаких объективных оснований полагать, что открытый код лучше проприетарного, равно как и наоборот”, — говорит Леви. С его точки зрения, безопасность программного кода является лишь частью более широкого круга вопросов безопасности. Эксперт ратует за то, что наиболее правильным подходом организаций к выбору открытого софта является определение базовых требований к безопасности ПО и лишь затем поиск программ, удовлетворяющих этим требованиям.
Открытость программного кода делает его безопасным “по умолчанию”
Предполагается, что поскольку Open Source открыт для всех, то сомнения в его небезопасности безосновательны. Леви это предположение считает неверным хотя бы потому, что мало кто настолько компетентен, чтобы судить о безопасности ядра Linux, содержащего 21 млн. строк кода. “Много глаз — это по большей части просто много ресниц, и ничего более”, — шутит он.
Открытый исходный код легко модифицировать для злонамеренных целей
“Это заблуждение. Поведенческий анализ создателей вредоносного софта свидетельствует о том, что они не используют исходный код напрямую, предпочитая работу с интерактивным дизассемблером IDA Pro. Это средство позволяет находить уязвимости посредством анализа работы программы, превращая её бинарный код в ассемблерный текст независимо от того, открытый ли у неё код или закрытый”, — говорит Леви.
Открытый софт хуже, потому что код для него может писать любой желающий
Это верно лишь отчасти: для некоторых общедоступных проектов код можно писать по желанию, в то время как разработкой кода для других проектов Open Source занимаются профессиональные программисты. Чтобы уменьшить риск установки низкокачественного или опасного ПО, в любом случае не будет лишним изучить историю проекта с открытым кодом, советует Леви.
Открытое ПО означает его беспрепятственное использование
“ПО с открытым исходным кодом вовсе не означает, что оно свободно от ограничений. Эти ограничения предусматриваются условиями лицензирования GPL либо более умеренными требованиями BSD-лицензий. Таким образом, лицензионные условия на Open Source не обязательно будут распространяться конкретно на вашу организацию, но они существуют”, — предупреждает эксперт. Как пример Леви привел инструмент для распределенных вычислений и хранения данных Hadoop, который упоминается в качестве проекта с открытым исходным кодом: “Это запатентованный алгоритм. Его можно использовать бесплатно, но сам алгоритм запатентован, поэтому его реализация в виде отдельного проекта невозможна”.
Весь софт должен проходить аудит с точки зрения его безопасности
Это не реализуемо чисто технически, так что гарантией безопасности софта может служить лишь соблюдение базовых правил безопасности, считает Леви.
Вероятные опасности при использовании Open Source
Скачивание открытого софта по Сети
Распространением ПО онлайн занимаются многие проекты с открытым кодом, из-за чего конечные пользователи рискуют вместо подлинного софта скачать его подмену, содержащую вредоносный код. “Нет никаких гарантий, что при скачивании софта алгоритм криптографического хеширования SHA-1 и цифровая подпись к нему отправляются одним и тем же сервером распространения. К тому же нападения на серверы, распространяющие софт, случались уже неоднократно, и хоть они и не коснулись исходного кода, но затронули бинарный, MD5, SHA-1 и PGP”, — говорит Леви.
Патчи
Ситуация с происхождением кода повторяется и в том случае, когда исправления безопасности для ПО пользователи получают с открытых источников. “Заходя в центр обновления Windows, вы вправе полагаться на многоуровневый механизм аутентификации, который исключает всякую возможность подмены. Эквивалентную защиту предложит и Red Hat. В то же время нет уверенности, что под видом HTTP-серверов для распространения Open Source не могут скрываться недобросовестные источники вредоносного софта”, — продолжает специалист разведслужбы.
Эксплуатация уязвимостей
“Как и в случае с проприетарным софтом, патчи для Open Source являются необходимым источником устранения уязвимостей. По своей сути они же являются краеугольным камнем для его безопасности. К примеру, если в продукте обнаружена уязвимость, но бинарный патч для её устранения выложен в открытом доступе, то злоумышленникам не составит большого труда декомпилировать его код и найти источник уязвимости для его последующей эксплуатации. Собственно, безопасный источник исправлений для открытого софта позволит на порядок уменьшить риски его заражения вредоносным кодом”, — делится своими размышлениями Иен Леви. Эксперт говорит, что во многих открытых проектах есть отдельные лица или целые группы, активно отслеживающие ошибки в коде, что может привлекать к этим устаревшим ошибкам внимание злоумышленников: “Выложенные на всеобщее обозрение потенциальные уязвимости “нулевого дня” изрядно упрощают хакерам задачи по созданию эксплойтов, так как патчей для них не существует даже в проекте”.
Аудит открытого кода
Как узнать, кто написал код для интересующего вас open-source-софта? Иными словами, как получить уверенность, что даже если код заимствован, он не нарушает ничьих прав? Особенно данные вопросы актуальны для организаций, поэтому перед импортированием модулей ПО целесообразно усилиями штатных юристов и инженеров провести аудит открытого софта на предмет его лицензионной чистоты, советует Леви.
“Эффект индивидуальности”
В чём привлекательность коммерческого софта для предприятий? Ответ очевиден: фирменный бренд, гарантированная поддержка на протяжении длительного времени, как правило, обеспечиваемая штатом квалифицированных инженеров, в то время как в случае с проектами Open Source, которые подчас ведутся несколькими разработчиками, не всегда можно рассчитывать на своевременную консультацию по требуемым вопросам, не говоря уже о том, что между руководителями некоторых открытых проектов нередко возникали размолвки и разногласия, приводившие к их закрытию либо к смене направления деятельности, отмечает Леви.
Отношения с разработчиками
Степень безопасности открытого софта иногда можно оценить по косвенным признакам, особенно если чётко представлять себе, является ли интересующий вас open-source-проект перспективным для разработчиков. “Оценка безопасности открытого проекта не всегда упирается в код. Любой, кто думает, что в каждой строчке кода его поджидает уязвимость, глубоко заблуждается. Существуют не менее животрепещущие вопросы типа: имеют ли разработчики долгосрочные планы по поддержанию своего софта? Планируется ли регулярный выход патчей безопасности? Есть ли у них план управления инцидентами? Не собираются ли они радикальным образом изменить дизайн софта или политики безопасности? То есть взаимоотношения с разработчиками помогут вашей организации снизить бизнес-риски при использовании проекта”, — говорит Леви.
Идентификация разработчика
В то время как коммерческая компания может иметь несколько слоев для идентификации разработчика: по Сети, корпоративный идентификатор, техническое удостоверение для проверки исходного кода, — процесс идентификации некоторых разработчиков, занятых в open-source-проектах, может представлять собой некоторые сложности. Особое внимание стоит обратить на ситуации, когда для поддержания связи разработчик указывает бесплатную почту типа Gmail. “Многие ли захотят доверить безопасность своей компании почтовому аккаунту?” — вопрошает эксперт.