Comments 29
мы имеем порядка 15 операционных систем, имеющих сертификат соответствия
А куда столько? Not invented here?
Да уж, согласен. Каждый вендор смотрит на конкурентов, видит в их продуктах какие-то недостатки и пытается сделать свой, в котором эти недостатки устраняет (при этом создавая другие). С одной стороны - это грустно, с другой стороны - это естественный этап отбора. В результате победит сильнейший, а слабые со временем уйдут в небытие...К тому времени на рынке образуется несколько крупных вендоров, которые в конкурентной гонке будут вынуждены делать более качественные продукты, что для простых пользователей несомненно будет плюсом. Конкуренция - двигатель прогресса:)
Ой какие сказки венского леса.
Каждый вендор смотрит на конкурентов, потом на законы, и понимает, что взять ванильный Дебиан ему не позволят, а если заключить контракт с имеющимся вендором, то тот ими сможет крутить как ребёнок куклой. Поэтому никакой альтернативы, кроме как делать "свою" систему у них нет, а так как сделана она через нехочу, то и качество там отсутствует как концепция.
А никакой конкуренции между ними нет, кроме ценовой-договорной. Потому что те, кто принимают решение о закупке системы и те, кто реально будут её эксплуатировать - это совершенно разные люди между которыми нет никакого диалога и связи. Поэтому качество на такую конкуренцию не влияет никак, пока всё хоть как-то работает.
Коммерческих же структур, которые вынуждены считать свою производительность и убытки, во-первых будет всё меньше. Во-вторых, они не будут покупать "российские системы" пока их не заставят, а будут использовать Линукс. А когда заставят, купят самую дешёвую, поставят в угол сервера и будут и дальше использовать Линукс.
Так что эти "операционные системы" и дальше будут плодиться, пока их указом министерства не закроют и не прикажут всем перейти на одну-две.
То, о чем вы говорите, тоже имеет место быть. Я с этим не спорю. Однако, хотелось бы дать пару своих комментариев. Вы говорите о коммерческом рынке, к большей части которого регулятор не предъявляет никаких требований. В связи с этим они, конечно, могут и свой Линукс сделать и много чего еще. При этом довольно большую часть рынка занимают компании, которые вынуждены приобретать сертифицированные ОС, чтобы выполнить требования регулятора. В таком случае тоже можно пойти по пути "сделать свою ОС, получить на нее сертификат ФСТЭК и внедрить". Однако, чтобы получить сертификат нужно соответствовать тем требованиям, которые я привел в статье. Это значит, что нужно нанять штат людей (кроме разработчиков, QA и т.п.), которые будут заниматься выстраиванием внутренних процессов по разработке безопасного ПО (далее по тексту - РБПО), проводить различные виды тестирований с целью улучшения безопасности ОС (стат. и дин. анализ, фаззинг, пентесты, антивирусные проверки, поиск и устранение известных уязвимостей компонент ОС и т.п.), разрабатывать необходимую документацию (по сертификации порядка 15 документов и по РБПО еще столько же), выполнять SLA регулятора на устранение уязвимостей, на обеспечение поддержки и еще много чего. Реализация всех этих процессов обойдется в "копеечку", плюс еще дальше придется все это сертифицировать - это стоит еще одну "копеечку" и потраченного времени - минимум полгода будут идти испытания. Такие процессы мало кто сможет себе позволить, а те кто может, тот и является сегодня вендором ОС.
Относительно этого высказывания:
Во-вторых, они не будут покупать "российские системы" пока их не заставят, а будут использовать Линукс. А когда заставят, купят самую дешёвую, поставят в угол сервера и будут и дальше использовать Линукс.
Такое можно представить, и я даже знаю несколько компаний, которые пытались так сделать. Существует только одна проблема - если это компания подпадает под требования регулятора, то к ней приходят люди и аттестуют системы, и такие вот "фокусы" вскрываются очень быстро и очень быстро приводятся в порядок. Поэтому, если правильно "заставить", то все будет работать и на полочках лежать не будет. Но это если заставлять будет регулятор. А если "заставляет" руководство коммерческой компании, то тут уже все будет зависеть от зрелости процессов этой компании. Знаю несколько коммерческих компаний, которые сделали ровно так как вы и написали, т.к. внутри контроль отсутствовал от слова "совсем", а внешнего контроля не было. В итоге лежали на полочке купленные средства, а ДИТ продолжал работать по своим правилам на том, на чем хотел.
Но в целом, все о чем вы говорите имеет место быть. И то, о чем я писал в комментарии выше, этому никак не противоречит. В итоге все равно придет к тому, что останутся только самые стойкие и им уже придется бороться за своего клиента.
При госзакупках практика заключается в том, что финальный поставщик, передающий продукт потребителю, несёт ответственность за все косяки в системе, а уже потом, если останется жив, может спрашивать со своих поставщиков. В суде, если хочет.
Поэтому, если вас угораздило поставить для государства программно-аппаратный комплекс, то есть компы с операционкой, то у вас есть всего два варианта:
Взять Дебиан или Редхат, переклеить на нём логотипы на название своей фирмы, зарегистрировать это как отечественную операционную систему. Впредь нести ответственность, вплоть до уголовной, за любые косяки в ней, если те кому-то сильно навредят. Всю прибыль класть в карман.
Взять Астра Линукс. Без права переклеить в нём логотип на название своей фирмы. Впредь нести ответственность, вплоть до уголовной, за любые косяки в нём, если те кому-то сильно навредят. Прибылью делиться с производителем Астра Линукс.
Вот вам что больше нравится?
Ну если государство за любые косяки без разбирательств грозит уголовной ответственностью, то мне нравится третий вариант: не поставлять программно-аппаратные комплексы вообще - пусть карандашом в столбик считают
Ну во-первых, G уже год с лишним выпустило закон, позволяющий приказать любому B с ним связаться, причём до выполнения контракта B не имеет права закрыться, а его сотрудники - уволиться. А во-вторых, что вы тогда делаете в этой теме про отечественные ОС? Они больше никому, кроме около-госов, нафиг не сдались.
Вангую, что весь цикл статей закончится рекламой Инферит ОС - МСВСфера АРМ/Сервер
Нет. Я принципиально пишу не рекламную статью, а делюсь опытом, который собирал больше 10 лет. Ни одного упоминания про любые существующие ОС на рынке вы не увидите. Первая статья была вводной, тут ничего интересного нет. Вторая будет уже более интересной. Далее спойлер - А закончится это всем чек-листом по подбору ОС на нашем рынке.
А закончится это всем чек-листом по подбору ОС на нашем рынке.
Астра
РЕД
Алт
Я угадал?
Я же уже сказал - ни одного названия ОС или вендора вы не увидите в статье. Это не рекламная статья:)
Роса
Какой смысл писать статью в трёх частях, если в конечном итоге количество сертифицированных ОС в России можно пересчитать по пальцам одной руки?
А почему в голосовалке нет пункта о наличии и количестве участников программы Bug Bounty, выплаченных вознаграждениях? Соотношении обнаруженных и закрытых уязвимостей, среднем времени их устранения?..
Вы считаете, что это массовый критерий, которым пользуется большинство людей при выборе ОС?
Конечно! Поскольку не бывает ПО без уязвимостей, покупателей волнует как у разработчика поставлен процесс управления уязвимостями. Если статистики по обнаруженным/исправленным нет, то либо их никто не тестирует, либо не исправляет, либо исправляет, но так долго, что стыдно это публиковать. Наиболее зрелые компании не ограничиваются внутренним тестированием, т.к. его охват ограничен ресурсами, и запускают публичные программы. Посмотрите, например, результаты https://communityblog.fedoraproject.org/exploring-our-bugs-part-1-the-basics/, https://www.wired.com/story/hack-the-pentagon-bug-bounty-results/. Вот наши площадки https://codeby.school/blog/informacionnaya-bezopasnost/ohota-na-bagi-spisok-ploschadok-dlya-bug-bounty.
С вашими доводами полностью согласен и поддерживаю. Я этот момент как раз буду поднимать в следующей части статьи. Существует только одно "но"...На рынке сейчас только одна ОС вышла на такие площадки с программой Bug Bounty. Это круто, когда вендор ОС вкладывает деньги в безопасность, выходит на такие площадки и т.п., но мне кажется (ИМХО), сначала нужно поднять хороший процесс по безопасности внутри компании и только потом выходить на такие площадки. Иначе, как писал Михаил Булгаков:
"Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут"
Что в целом и произошло по результатам выхода этой компании на площадку (сужу по статьям на хабре, в которых исследователи описывали как они тестили, как им деньги не платили, какие доисторические уязвимости находили в ключевых компонентах ОС и т.п.).
Когда вендоры ОС в нашей стране достигнут того уровня внутренних процессов по обеспечению безопасности своих продуктов, чтобы можно было выходить на площадки и показывать, что мол "у нас безопасные системы, попробуйте что-нибудь в них найти", тогда такой пункт будет показателем их реальной работы и его и правда можно будет добавить в список. А пока что выход на Bug Bounty площадки таких вендоров - это не показатель их крутой внутренней работы по поиску уязвимостей, а скорее просьба о помощи к народу, вроде "ребята, у меня нет хороших спецов, которые могут найти уязвимости, прошу помощи и готов заплатить вам деньги". Я бы к такому вендору наоборот не пошел (ИМХО). Поэтому, на сегодняшний день, не считаю данный пункт необходимым в списке вопросов.
Белые шляпы, конечно, могут и подождать. А что делать с черными? У них ипотека, им ждать некогда.
Я не говорю, что белые шляпы должны подождать. Я говорю лишь о том, что вендор, который хочет сделать хороший и безопасный продукт, должен содержать в своем штате исследователей (белых шляп), и развить для начала внутри все процессы. И когда он почувствует, что его белые шляпы уже ничего нового найти не могут, вот тогда отправляться на площадки Bug Bounty, для обеспечения внешнего элемента проверки, когда внутренние уже не результативны. Иначе получается, что сам вендор сделать ничего не может и передает это дело людям на сторону и зависит чисто от их желания/сообразительности/времени и т.п. При этом на таких площадках чаще всего тестируют Black Box, и если уж ребята с площадки находят у тебя уязвимости не видя кода твоего изделия, то встает вопрос: "А твои то люди чем занимаются в компании? У них есть доступ к коду, есть всевозможные анализаторы и еще кучу приблуд. Почему люди на площадке методом Black Box что-то находят, а твои методом White Box найти не могут?". Тут сразу думается, что либо вендор экономит на специалистах, либо специалисты у него не очень, либо внутренние процессы работают неправильно, либо все вместе взятое. И тогда получается, почему я должен отдавать приоритет этому вендору, если у него внутри такие проблемы? Я лучше отдам приоритет вендору, которого нет на Bug Bounty площадках, но у которого и уязвимости внутри находятся и устраняются, и про которого не пишут на Хабре или других площадках о том, что в составе его ОС уязвимости нулевых годов. И вот только поэтому не вижу смысла этот пункт добавлять:)
Автору как к специалисту в этой сфере вопрос. Вот у нас есть сертифицированная ОС на отдельно стоящем АРМ с интернетом. Нам надо закрыть требование к МЭ типа «В» (межсетевой экран уровня узла). Как рассказал нам один вендор, они не выполняют требования к МЭ в их ОС, т. к. профиль защиты для ОС предполагает куда меньший функционал, чем предъявляется для сертифицированного МЭ. Отсюда вопрос: как быть, если отдельных софтовых МЭ нет, есть только в составе комплексного СЗИ (Dallas или SecretNet)? Но если брать эти СЗИ, тогда зачем сертифицированная ОС? Поправьте, может, я что-то упустил.
Хороший вопрос. Вендор, с которым вы общались, прав. МЭ, который входит в состав сертифицированной ОС и правда выполняет не все функции безопасности, которые предусматриваются профилем защиты (далее по тексту - ПЗ) на МЭ типа В. Если быть точнее, то МЭ, который входит в состав ОС, конечно, может выполнять все необходимые функции, но проблема в том, что в соответствии с профилем защиты на ОС половина необходимых для МЭ функций просто не проверяется при сертификации, т.к. ПЗ на ОС не предполагает проверок этих функций. В связи с этим МЭ с одной стороны по функционалу может подходить, но с другой стороны этот функционал никто не проверял при испытаниях, в связи с чем нельзя сказать, что все функции работают так, как предписано профилем защиты на МЭ. Отсюда вытекают требования регулятора приобретать именно тот МЭ, который был сертифицирован на ПЗ к МЭ типа В, т.к. его функциональные возможности точно проверялись и можно быть уверенным, что он будет обеспечивать защиту от угроз, которые приведены в ПЗ на МЭ типа В.
Относительно средств, которые можно применять в таком случае: не только в СЗИ от НСД (Dallas или SecretNet) входят МЭ. На рынке есть ряд самостоятельных продуктов, которые можно применять. Пожалуйста, не сочтите за рекламу, но в реестре ФСТЭК я вижу как минимум следующие самостоятельные средства, которые можно рассмотреть к применению:
ViPNet 4;
ViPNet Personal Firewall 4.5;
ViPNet EndPoint Protection;
С-Терра Клиент. Версия 4.2;
С-Терра Клиент. Версия 4.3;
Diamond VPN/FW;
«ЗАСТАВА-Клиент «VPN/FW «ЗАСТАВА, версия 6».
ViPNet 4 - Это все же СКЗИ
ViPNet Personal Firewall 4.5 - По слухам умрет в этом году;
ViPNet EndPoint Protection - МЭ как модуль, по факту это СОВ со срочными лицензиями;
С-Терра Клиент. Версия 4.2 - СКЗИ с МЭ;
С-Терра Клиент. Версия 4.3 - СКЗИ с МЭ;
Diamond VPN/FW - очень спорный вариант, по сути СКЗИ с МЭ.
«ЗАСТАВА-Клиент «VPN/FW «ЗАСТАВА, версия 6». - честно не изучали, но я так понимаю тоже СКЗИ с МЭ.
Однако же наличие сертифицированного ФСБ СКЗИ в этих продуктах не мешает применять большинство из них именно как МЭ. И самое главное, что на них есть действующий сертификат ФСТЭК на ИТ.МЭ.В4.ПЗ, что позволяет их применять на объектах информатизации для нейтрализации существующих угроз, которые можно закрыть МЭ такого типа и класса защиты.
Если вы ищете на рынке чистый FW без лишнего функционала, добавленного вендорами, то получается, что да, таких экранов не будет. Тут как покупать машину: я хочу, чтобы у нее было 4 колеса, руль и мотор. Больше мне ничего не нужно. Но когда я прихожу к дилерам, то они мне зачем-то дают машину с климат-контролем, автоматом, кожаными сидениями, кучей всякой электроники и т.п. И сколько бы я не искал машину на рынке чисто с 4 колесами, рулем и мотором, я ее не найду. В случае с FW, думаю, работает так же.
Логика производителей понятна. Но СКЗИ это все же привязка к какой либо сети с доп накладными расходами. Для себя мы склоняемся к варианту СЗИ от НСД с МЭ (Dallas Lock или SecretNet) и не сертифицированная ОС. По цене выходит +- тоже самое местами даже дешевле. При этом возникает вопрос:
Но если брать эти СЗИ, тогда зачем сертифицированная ОС?
С точки зрения функционала, что несертифицированная ОС + СЗИ от НСД, что сертифицированная ОС - одинаковы (за исключением пары функций, таких как, например наличие/отсутствие сертифицированного МЭ). Дьявол кроется в деталях. СЗИ от НСД ставится поверх ОС, при этом заменяя важные компоненты ОС (компоненты разграничения доступа, контроля целостности и т.п.) своими компонентами. Кто знает, поломает ли такая замена что-то в ОС или нет? Обычно вендоры СЗИ от НСД пытаются тестировать совместимость своих средств с различными ОС, но даже в таком случае, гарантировать, что все будет работать штатно нельзя. Например, с мажорной версией ОС (чаще всего тестируют именно с ней) их СЗИ будет работать штатно, но после установки обновлений ОС все слетит из-за того, что вендор ОС повысил версию пакета какого-то компонента ради устранения в нем уязвимости, а СЗИ от НСД с пакетом старшей версии работать не сможет.
На практике встречал такие случаи и заканчивались они следующим: пользователь приходил к вендору СЗИ от НСД с проблемой, те отправляли его к вендору ОС. Вендор ОС разбирался в проблеме и отправлял пользователя обратно к вендору СЗИ от НСД. И так по кругу... И доказать, что кто-то из них не прав - тяжело.
Если вы рассматриваете такой вариант применения, то обязательно уточните у обоих вендоров, ведут ли они процесс по взаимной поддержке мажорных и минорных версий СЗИ от НСД и ОС между собой. Тестироваться должно любое изменение одного из продуктов с актуальной версией другого и только после этого попадать к пользователю. Реализация такого процесса у этих вендоров - трудный процесс (один хочет быстрее выпустить обновление, другой ленится переписывать свое изделие, т.к. нужно проводить по новой сертификацию и т.п.). На практике очень трудно найти 2х таких вендоров, которые будут работать как единая команда. Самый идеальный вариант при необходимости применения такого решения найти вендора, который будет поставщиком обоих решений, и в случае каких-либо проблем вы будете обращаться в единое окно.
Описанное выше - это только малая часть проблем, с которыми можно столкнуться при таком подходе. Выбирая его нужно быть осторожным. Я опишу все нюансы, о которых мне известно, в отдельной статье про выбор несертифицированной ОС (выйдет позже...может быть в июле-августе).
Вывод: если хотите работать с меньшим количеством проблем, то лучше брать сертифицированную ОС. Если по тем или иным причинам нет возможности взять сертифицированную ОС, то уточняйте про то, как проводится тестирование совместимости и кто будет отвечать в случае поломки, а также будьте готовы работать на необновленной уязвимой ОС какое-то время, пока вендор СЗИ от НСД не пройдет сертификацию на обновление своего СЗИ, работающего с новой минорной версией ОС.
P.S. В вашем случае я бы все-таки рассмотрел вариант взять сертифицированную ОС и поставить туда МЭ, пусть и с дополнительным функционалом СКЗИ или СОВ. По крайней мере это средство не будет заменять компоненты ОС своими и у вас не образуется зависимая связка этих продуктов.
P.P.S. Посмотрите еще Secret Net Studio 8, в его состав входит МЭ типа В, и вроде как его можно приобрести отдельно как модуль. Если это так, то можно купить сертифицированную ОС + Модуль персонального межсетевого экрана Средства защиты информации Secret Net Studio 8, тогда проблем, думаю, будет меньше, чем применять целиком СЗИ от НСД + несертифицированную ОС.
Как выбрать сертифицированную ОС на российском рынке. Часть 1