Цикл статей в 3-х частях
Если все сертифицированные системы обеспечивают одни и те же функции по защите информации, то нет разницы, какую покупать? На этом вопросе закончилась первая часть цикла статей по данной теме.
Отвечая на него, скажу, что разница в итоге есть. Все зависит от того, как вендор подходит к процессу разработки и поддержке своей ОС. В этой статье вы узнаете, на что стоит обратить внимание и сможете принять правильное решение при выборе сертифицированной ОС на российском рынке.
Миф № 3. «Если я установлю последние обновления безопасности ОС, то на момент их установки я буду в полной безопасности – до появления новых уязвимостей».
На самом деле, это не так. На российском рынке превалирует 2 типа вендоров ОС: первые берут за основу операционные системы, которые создаются крупными мировыми проектами, такими как Debian или Red Hat, вторые же сами компонуют свою ОС из апстрима. От конкретных реализаций этих подходов зависит качество собранного дистрибутива, а также его безопасность.
В случаях, когда за основу взяты проекты Debian или RedHat, полученная в результате ОС будет работать более стабильно и надежно, а компоненты таких систем будут более безопасны, так как над этим вопросом работают крупные организации и все мировое сообщество. Используя этот подход, вендоры российских операционных систем чаще всего выдают те же обновления, которые выдают крупные проекты (Debian, Red Hat), на основе которых строится их ОС.
Проблема безопасности при таком подходе заключается в том, что российские вендоры добавляют в состав ванильной версии дистрибутива ряд пакетов, которые позволяют обеспечить необходимую функциональность конечному потребителю, и не всегда эти пакеты проверяются также тщательно, как ванильный образ системы в рамках крупных мировых сообществ. Некоторые вендоры строят свою ОС на устаревших мажорных версиях крупных проектов и сталкиваются с проблемой устранения в них уязвимостей после того, как крупные проекты перестают их поддерживать. Дополнительно к этому возникают определенные риски с точки зрения дальнейшей поддержки таких систем, так как если по каким-то причинам российский вендор ОС перестанет получать обновления от крупных проектов (Debian, Red Hat) и при этом в моменте не будет содержать огромный штат сотрудников, то безопасность дальнейшей работы на данных системах будет под вопросом.
Компоновка ОС из апстрима дает возможность вендорам не зависеть от обновлений, выдаваемых крупными проектами. Сама же разработка здесь может вестись автономно. При этом, чтобы добиться того же качества продукта и постоянного обнаружения и устранения в нем уязвимостей, как это сделано в крупных проектах (Debian, RedHat), у вендора должен быть организован серьезный процесс поиска и исправления уязвимостей, а также процессы по тестированию, контролю качества и поддержанию совместимости с различными аппаратными платформами, что кратно увеличит штат сотрудников и соответственно затраты на производство. На рынке редко встречаются вендоры, которые способны решать эти задачи на должном уровне, в связи с чем вы можете получить некачественную или уязвимую ОС.
И тот и другой подход имеют свои плюсы и минусы. Каждый подход имеет право быть и реализовываться. Вендора с каким подходом выбирать — решать вам, я лишь подсветил те моменты, на которые стоит обратить внимание.
Возвращаясь к вопросам выбора сертифицированной операционной системы на российском рынке, я рекомендую в первую очередь обратить внимание на частоту обновлений ОС, а также на цель этих обновлений. Если вендор выпускает обновления ОС реже, чем раз в полгода, то это означает, что вам придется в течение как минимум года работать на уязвимой системе. Чем чаще выходят обновления, тем лучше. Хорошим тоном считается выпускать обновления раз в полгода и чаще. Дополнительно обратите внимание, какие уязвимости устраняет вендор в продукте при выпуске обновлений, каково их количество и насколько они старые.
У каждой уязвимости есть идентификатор. Он зависит от базы, в которой ведется информация о данной уязвимости. Рассмотрим идентификатор уязвимости на примере самой распространенной базы данных уязвимостей, которую ведет MITRE. Идентификатор содержащихся в этой базе уязвимостей имеет вид:
CVE-ХХХХ-YYYY,
где CVE — это постоянный код, обозначающий, что информация об уязвимости размещена в базе данных, которую ведет MITRE, ХХХХ — это код, который указывает год публикации информации об уязвимости, а YYYY — это порядковый номер обнаруженной уязвимости.
Вы открываете сайт продукта, смотрите обновления, видите, какие уязвимости закрываются этим обновлением и узнаете, что в последнем обновлении закрываются уязвимости вида, например, CVE-2019-8457. Какой вывод можно сделать при таких входных данных? Как минимум, закрывается уязвимость 5-летней давности. Это может означать, что процесс по управлению уязвимостями (vulnerability management) в компании отсутствует либо работает плохо, т.к. 5 лет на устранение известной уязвимости — это много. Позволительные лаги для больших систем — это 0,5-1 год. Если вы видите, что в последних обновлениях устраняются уязвимости вида CVE-2023- 22515 и CVE-2023-22510, то это приемлемо (если на календаре 2024 год), на остальное стоит обратить внимание. Конечно, могут быть случаи, когда уязвимость не могли долго устранить из-за проблем с зависимостями или еще по каким-то причинам, но все-таки это первый «звоночек», на который не стоит закрывать глаза.
Следующий шаг — обратить внимание на количество устраненных уязвимостей и на их разделение по годам. Если соотношение будет 95% новых уязвимостей и 5% старых, то это нормальная история. Если старых будет больше 5%, то стоит задуматься, т.к. приобретая такую систему потенциально вы подвергаете себя риску работы с уязвимыми компонентами, которые многие годы не будут устраняться вендором.
Следующий шаг — проанализируйте данные об устраняемых уязвимостях. Если в обновлении устраняются только уязвимости, оценка критичности которых больше 7.0 по стандарту CVSS, то это может означать, что вендор выполняет требования регулятора по устранению критичных уязвимостей в продукте, а некритичные уязвимости устранять не спешит. Это создает определенные риски безопасности для информации при дальнейшей эксплуатации таких систем.
Обычно, уязвимостей с оценками CVSS > 7.0 гораздо меньше, чем уязвимостей с оценками CVSS < 7.0. В связи с этим нормальное распределение уязвимостей должно быть примерно 25% критических уязвимостей (CVSS > 7.0) на 75% некритических уязвимостей (CVSS < 7.0) ± 10%.
Бывают случаи, когда вендоры скрывают данные об устраненных уязвимостях в минорных и мажорных обновлениях ОС, ссылаясь на то, что информация об устраненных уязвимостях в продукте может повлиять на безопасность необновленных систем, функционирующих у их заказчиков. Это, мягко говоря, странная позиция, т.к. всю информацию о найденных и устраненных уязвимостях, в соответствии с тем же 76 приказом ФСТЭК России, вендор обязан передавать в банк данных угроз (далее по тексту — БДУ), который ведет ФСТЭК.
Соответственно, если информация попадает в БДУ ФСТЭК, то она становится публичной, и любой желающий может ее получить. Данный факт не свидетельствует о наличии каких-либо проблем у вендора, но вызывает много вопросов, связанных с целью таких действий. Такое решение вендора может повлиять на вашу дальнейшую работу по выявлению уязвимостей в ОС. Чаще всего специалисты по безопасности в организациях налаживают процесс по управлению уязвимостями (vulnerability management), покупают различные сканеры безопасности и сканеры уязвимостей, производимые российскими вендорами. Сканеры анализируют пакетный состав установленной ОС и обращаются к внутренним базам данных, в соответствии с которыми проводят обработку и выявление информации об актуальных уязвимостях в обнаруженных пакетах. База данных уязвимостей для этих сканеров наполняется полной выгрузкой базы уязвимостей MITRE и, возможно, других зарубежных баз (зависит от конкретного сканера). Дополнительно, вендоры сканеров безопасности ведут работу по мониторингу сайтов российских вендоров ОС и вытягивают из них информацию об устраненных уязвимостях в конкретных версиях пакетов.
Здесь мы видим занимательную ситуацию, с которой я не раз сталкивался: исследователи безопасности, работающие у вендора ОС, находят информацию о наличии актуальных уязвимостей пакета Х, передают эти сведения разработчикам, те, в свою очередь, программно закрывают эту уязвимость и включают пересобранный пакет (не меняя его версию) в очередное минорное обновление ОС, при этом на сайте не отражают информацию о том, что в пакете Х была устранена данная уязвимость. В связи с этим сканер безопасности не может выгрузить и учесть данную информацию, поэтому использует информацию с тех баз, к которым подключен, например, с базы уязвимостей MITRE. А в этой базе для пакета Х до сих пор светится актуальной данная уязвимость. В связи с этим сканер выдает вашим специалистам по безопасности ложное срабатывание, те в свою очередь пишут обращение вендору ОС и вендор ОС тратит силы на то, чтобы исследовать данный запрос и объяснить вашим специалистам, что на самом деле данную уязвимость они уже устранили.
Такой парадокс до сих пор встречается на рынке. В связи с этим, для минимизации затрат ресурсов специалистов службы вашей информационной безопасности лучше выбирать тех вендоров ОС, которые в открытом виде публикуют данные об устраненных уязвимостях в минорных и мажорных обновлениях ОС у себя на сайте.
Миф № 4. «Если вендор заявляет о том, что у него реализован процесс по разработке безопасного ПО, значит все пакеты, входящие в ОС, проверяются в рамках различных видов тестирования и не содержат уязвимостей».
Это не так. Современные ОС представляют из себя набор из более чем 1000 различных пакетов, каждый из которых содержит множество модулей и бинарных файлов, а суммарный объем исходного кода измеряется миллионами строк. Проводимые методы исследований очень трудоемки, и штат даже из 100 исследователей безопасности не сможет обеспечить полную проверку всего кода ОС. Чаще всего вендоры определяют пакетную базу, которая является "поверхностью атаки", и углубленно исследуют именно ее. Таким образом из 1000+ пакетов ОС реально могут проверяться 30-50 пакетов, а по остальным пакетам проводится только анализ известных уязвимостей, информация о которых содержится в различных базах данных уязвимостей (БДУ ФСТЭК, MITRE и прочие), а также антивирусная проверка.
В связи с этим рекомендую поискать информацию о найденных ZeroDay-уязвимостях в рассматриваемой ОС на форумах и специализированных сайтах.
Если такую информацию получится найти — значит, в команде вендора работают квалифицированные исследователи безопасности программного обеспечения, и вендор не только выявляет актуальные уязвимости по открытым источникам, но также самостоятельно проводит исследования, позволяющие сделать его продукт еще безопаснее. ФСТЭК России создал страницу для публикации результатов таких исследований у себя в БДУ, но, к сожалению, многие исследователи не называли компанию, от имени которой проводились исследования и выявлялись подобные уязвимости, в связи с чем трудно соотнести результаты их деятельности с конкретным продуктом. Да и в целом, многие исследователи вообще не знают о существовании подобных страниц, что приводит к отсутствию на них нужной информации.
Если информацию в открытых источниках найти не удается, то можно поинтересоваться у вендора, какой штат исследователей безопасности он содержит, и сколько ZeroDay-уязвимостей в год они находят? Если штата нет, либо есть, но очень маленький (меньше 10 специалистов), то это будет означать, что вендор на самом деле не очень-то и заботится о безопасности своего продукта, а его деятельность в первую очередь направлена на извлечение прибыли за реализацию продукта на рынке. В таком случае стоит посмотреть в сторону более продвинутых вендоров, которые нашли «золотую середину» между извлечением прибыли от реализации продукта и обеспечением безопасности и качества этого самого продукта.
Миф № 5. «Если я приобрету техническую поддержку вендора, то это позволит мне очень быстро решать возникающие при работе с его ОС проблемы».
Откровенно говоря, это не всегда так. Зачастую бывает так, что недавно появившийся на рынке вендор из-за отсутствия финансирования и стабильных продаж вынужден экономить деньги на всем, в том числе и на специалистах технической поддержки. Из-за этого при возникновении у конечного пользователя проблем не представляется возможным своевременно получить поддержку.
Рекомендую обратить внимание на наличие у вендора квалифицированной технической поддержки. Важно, чтобы она была не просто «заявлена» вендором, но также быстро отрабатывала запросы пользователей и помогала решить любые технические проблемы без длительного ожидания. Проверить ее работу до приобретения лицензии на продукт и сертификата на техническую поддержку сложно, но вы можете проверить скорость реакции при обращении, позвонив по телефону горячей линии. Нередки случаи, когда до технической поддержки некоторых вендоров средств защиты информации дозвониться практически невозможно. Также вы можете почитать отзывы о технической поддержке конкретного вендора на специализированных форумах и порталах.
Миф № 6. «Я приобрету сертифицированную ОС и вендор будет поддерживать данную систему в течении срока действия сертификата соответствия».
Это тоже не не совсем так. Вендоры на рынке чаще всего один раз получают сертификат соответствия на первую мажорную версию ОС и при выходе следующей версии он не получает новый сертификат, а обновляет уже существующий. В такой ситуации вы можете столкнуться с проблемой, когда вендор безвозмездно в рамках поддержки передаст вам новую мажорную версию своей ОС и сообщит, что старую он перестает поддерживать. Конечно, это делается не мгновенно, по регламенту вендор должен предупредить вас об этом как минимум за год. Но все же - это очень большая проблема на сегодняшний день, так как все российские системы созданы на основе открытого кода GNU/Linux, а у дистрибутивов Linux до сих пор существует проблема с миграцией между мажорными версиями. В лучшем случае на некоторых Linux-дистрибутивах миграция возможна, но с потерей функциональности определенных приложений и возможно данных, а в худших случаях, что чаще всего и встречается на российском рынке — это полная переустановка системы с потерей всех рабочих данных (файлов, приложений и пр.) и возможностью получить неработоспособное приложение (при его переустановке в новую систему), которое отлично работало на предыдущей мажорной версии ОС.
Моя рекомендация заключается в следующем — выбирайте для себя ОС с максимально возможным сроком поддержки (выпуска программных обновлений, не путать с технической поддержкой!) мажорной версии, а также с более развитой и безболезненной для вас возможностью перехода на более новую мажорную версию.
Подытожим. В рамках цикла статей по данной теме я постарался подсветить те моменты, на которые стоит обратить внимание при выборе сертифицированной ОС на российском рынке. Текст получился достаточно большим и основательным. Перечитывать его каждый раз, когда кто-то столкнется с проблемой выбора ОС, не самая хорошая идея. Поэтому в третьей части статьи из цикла по этой теме я приведу короткий чек-лист, который позволит любому желающему подобрать для себя качественную и безопасную ОС, для того, чтобы пройти этот нелегкий путь импортозамещения и обеспечить полноценную работу в ней на долгие годы вперед.
Как выбрать сертифицированную ОС на российском рынке. Часть 3
