Я не говорю, что белые шляпы должны подождать. Я говорю лишь о том, что вендор, который хочет сделать хороший и безопасный продукт, должен содержать в своем штате исследователей (белых шляп), и развить для начала внутри все процессы. И когда он почувствует, что его белые шляпы уже ничего нового найти не могут, вот тогда отправляться на площадки Bug Bounty, для обеспечения внешнего элемента проверки, когда внутренние уже не результативны. Иначе получается, что сам вендор сделать ничего не может и передает это дело людям на сторону и зависит чисто от их желания/сообразительности/времени и т.п. При этом на таких площадках чаще всего тестируют Black Box, и если уж ребята с площадки находят у тебя уязвимости не видя кода твоего изделия, то встает вопрос: "А твои то люди чем занимаются в компании? У них есть доступ к коду, есть всевозможные анализаторы и еще кучу приблуд. Почему люди на площадке методом Black Box что-то находят, а твои методом White Box найти не могут?". Тут сразу думается, что либо вендор экономит на специалистах, либо специалисты у него не очень, либо внутренние процессы работают неправильно, либо все вместе взятое. И тогда получается, почему я должен отдавать приоритет этому вендору, если у него внутри такие проблемы? Я лучше отдам приоритет вендору, которого нет на Bug Bounty площадках, но у которого и уязвимости внутри находятся и устраняются, и про которого не пишут на Хабре или других площадках о том, что в составе его ОС уязвимости нулевых годов. И вот только поэтому не вижу смысла этот пункт добавлять:)
Да е-мае, с телефона не удобно и задачи смотреть и комментарии набирать. По второй задаче тоже корректировка. 3 курицы за 12 дней снесут 12 яиц, а если куриц становится в 4 раза больше, то 12х4 = 48
И по первой задаче корректировка. Думал, что всего людей 9, а там 9 и я, т.е. 10. Тогда логика та же, но цифры другие: 45 дорог всего, получается 45 - 9 = 36 дорог можно не чистить
Прошу прощения, в 4й задаче забыл про условие - у фермера 3000 яблок. Тогда вообще не понятно, на обратном пути до фермы он как бы без яблок может обходиться? Если так, то довезет он 3 яблока. Суть та же, что описал выше, но только вместо одной будет 3 поездки
1. 45 дорог всего (9+8+7+6+5+4+3+2+1), чтобы пройти от дома к любому дому нужно оставить 9 дорог, это будет выглядеть как дерево с корнем в одном доме. В таком случае 45 - 9 = 36 дорог можно не чистить.
2. 12х4=48 яиц.
3. 14.57 - время на часах, Андрей думает, что 14.55, реальное время - 15.00., т.е. Андрей опаздает на 5 минут. У кати на часах 15.02, она думает, что 14.59, а реально 15.00, т.е. Катя опаздает на встречу на 1 минуту. При таком раскладе опаздают оба, но Кате придётся ждать Андрея лишних 4 минуты.
4. 3 яблока, т.к. он съедает яблоко только проехав 1 км, поэтому последний 1000й километр он проедет, но не успеет съесть яблоко, т.к. достигнет прилавка. И так 3 раза, при условии, что на обратном пути он может обходиться без яблок. Иначе придётся решать задачу с условием складирования яблок, но условие задачи этого не предполагает.
С точки зрения функционала, что несертифицированная ОС + СЗИ от НСД, что сертифицированная ОС - одинаковы (за исключением пары функций, таких как, например наличие/отсутствие сертифицированного МЭ). Дьявол кроется в деталях. СЗИ от НСД ставится поверх ОС, при этом заменяя важные компоненты ОС (компоненты разграничения доступа, контроля целостности и т.п.) своими компонентами. Кто знает, поломает ли такая замена что-то в ОС или нет? Обычно вендоры СЗИ от НСД пытаются тестировать совместимость своих средств с различными ОС, но даже в таком случае, гарантировать, что все будет работать штатно нельзя. Например, с мажорной версией ОС (чаще всего тестируют именно с ней) их СЗИ будет работать штатно, но после установки обновлений ОС все слетит из-за того, что вендор ОС повысил версию пакета какого-то компонента ради устранения в нем уязвимости, а СЗИ от НСД с пакетом старшей версии работать не сможет.
На практике встречал такие случаи и заканчивались они следующим: пользователь приходил к вендору СЗИ от НСД с проблемой, те отправляли его к вендору ОС. Вендор ОС разбирался в проблеме и отправлял пользователя обратно к вендору СЗИ от НСД. И так по кругу... И доказать, что кто-то из них не прав - тяжело.
Если вы рассматриваете такой вариант применения, то обязательно уточните у обоих вендоров, ведут ли они процесс по взаимной поддержке мажорных и минорных версий СЗИ от НСД и ОС между собой. Тестироваться должно любое изменение одного из продуктов с актуальной версией другого и только после этого попадать к пользователю. Реализация такого процесса у этих вендоров - трудный процесс (один хочет быстрее выпустить обновление, другой ленится переписывать свое изделие, т.к. нужно проводить по новой сертификацию и т.п.). На практике очень трудно найти 2х таких вендоров, которые будут работать как единая команда. Самый идеальный вариант при необходимости применения такого решения найти вендора, который будет поставщиком обоих решений, и в случае каких-либо проблем вы будете обращаться в единое окно.
Описанное выше - это только малая часть проблем, с которыми можно столкнуться при таком подходе. Выбирая его нужно быть осторожным. Я опишу все нюансы, о которых мне известно, в отдельной статье про выбор несертифицированной ОС (выйдет позже...может быть в июле-августе).
Вывод: если хотите работать с меньшим количеством проблем, то лучше брать сертифицированную ОС. Если по тем или иным причинам нет возможности взять сертифицированную ОС, то уточняйте про то, как проводится тестирование совместимости и кто будет отвечать в случае поломки, а также будьте готовы работать на необновленной уязвимой ОС какое-то время, пока вендор СЗИ от НСД не пройдет сертификацию на обновление своего СЗИ, работающего с новой минорной версией ОС.
P.S. В вашем случае я бы все-таки рассмотрел вариант взять сертифицированную ОС и поставить туда МЭ, пусть и с дополнительным функционалом СКЗИ или СОВ. По крайней мере это средство не будет заменять компоненты ОС своими и у вас не образуется зависимая связка этих продуктов.
P.P.S. Посмотрите еще Secret Net Studio 8, в его состав входит МЭ типа В, и вроде как его можно приобрести отдельно как модуль. Если это так, то можно купить сертифицированную ОС + Модуль персонального межсетевого экрана Средства защиты информации Secret Net Studio 8, тогда проблем, думаю, будет меньше, чем применять целиком СЗИ от НСД + несертифицированную ОС.
Однако же наличие сертифицированного ФСБ СКЗИ в этих продуктах не мешает применять большинство из них именно как МЭ. И самое главное, что на них есть действующий сертификат ФСТЭК на ИТ.МЭ.В4.ПЗ, что позволяет их применять на объектах информатизации для нейтрализации существующих угроз, которые можно закрыть МЭ такого типа и класса защиты.
Если вы ищете на рынке чистый FW без лишнего функционала, добавленного вендорами, то получается, что да, таких экранов не будет. Тут как покупать машину: я хочу, чтобы у нее было 4 колеса, руль и мотор. Больше мне ничего не нужно. Но когда я прихожу к дилерам, то они мне зачем-то дают машину с климат-контролем, автоматом, кожаными сидениями, кучей всякой электроники и т.п. И сколько бы я не искал машину на рынке чисто с 4 колесами, рулем и мотором, я ее не найду. В случае с FW, думаю, работает так же.
С вашими доводами полностью согласен и поддерживаю. Я этот момент как раз буду поднимать в следующей части статьи. Существует только одно "но"...На рынке сейчас только одна ОС вышла на такие площадки с программой Bug Bounty. Это круто, когда вендор ОС вкладывает деньги в безопасность, выходит на такие площадки и т.п., но мне кажется (ИМХО), сначала нужно поднять хороший процесс по безопасности внутри компании и только потом выходить на такие площадки. Иначе, как писал Михаил Булгаков:
"Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут"
Что в целом и произошло по результатам выхода этой компании на площадку (сужу по статьям на хабре, в которых исследователи описывали как они тестили, как им деньги не платили, какие доисторические уязвимости находили в ключевых компонентах ОС и т.п.).
Когда вендоры ОС в нашей стране достигнут того уровня внутренних процессов по обеспечению безопасности своих продуктов, чтобы можно было выходить на площадки и показывать, что мол "у нас безопасные системы, попробуйте что-нибудь в них найти", тогда такой пункт будет показателем их реальной работы и его и правда можно будет добавить в список. А пока что выход на Bug Bounty площадки таких вендоров - это не показатель их крутой внутренней работы по поиску уязвимостей, а скорее просьба о помощи к народу, вроде "ребята, у меня нет хороших спецов, которые могут найти уязвимости, прошу помощи и готов заплатить вам деньги". Я бы к такому вендору наоборот не пошел (ИМХО). Поэтому, на сегодняшний день, не считаю данный пункт необходимым в списке вопросов.
Хороший вопрос. Вендор, с которым вы общались, прав. МЭ, который входит в состав сертифицированной ОС и правда выполняет не все функции безопасности, которые предусматриваются профилем защиты (далее по тексту - ПЗ) на МЭ типа В. Если быть точнее, то МЭ, который входит в состав ОС, конечно, может выполнять все необходимые функции, но проблема в том, что в соответствии с профилем защиты на ОС половина необходимых для МЭ функций просто не проверяется при сертификации, т.к. ПЗ на ОС не предполагает проверок этих функций. В связи с этим МЭ с одной стороны по функционалу может подходить, но с другой стороны этот функционал никто не проверял при испытаниях, в связи с чем нельзя сказать, что все функции работают так, как предписано профилем защиты на МЭ. Отсюда вытекают требования регулятора приобретать именно тот МЭ, который был сертифицирован на ПЗ к МЭ типа В, т.к. его функциональные возможности точно проверялись и можно быть уверенным, что он будет обеспечивать защиту от угроз, которые приведены в ПЗ на МЭ типа В.
Относительно средств, которые можно применять в таком случае: не только в СЗИ от НСД (Dallas или SecretNet) входят МЭ. На рынке есть ряд самостоятельных продуктов, которые можно применять. Пожалуйста, не сочтите за рекламу, но в реестре ФСТЭК я вижу как минимум следующие самостоятельные средства, которые можно рассмотреть к применению:
Формально, эти пакеты являются составной частью AL, за них разработчик (РусБИТех-Астра, далее РБТ-А) несет полную ответственность перед конечным потребителем (исправляет уязвимости при обнаружении, восстанавливает работоспособность при ошибках и т.п.). У РБТ-А есть их исходный код, они могут его переписывать, компилировать и собирать. Права по лицензии они никакие не нарушают. Поэтому, да, считается, что РБТ-А является владельцем этих компонент, но только в составе своей ОС. И отсюда следует, что данное ПО можно назвать отечественным.
P.S. Знаю, сейчас могут полететь упреки в мою сторону, но не я это придумал, так работает система, а я просто озвучил принципы ее работы:)
Нет. Я принципиально пишу не рекламную статью, а делюсь опытом, который собирал больше 10 лет. Ни одного упоминания про любые существующие ОС на рынке вы не увидите. Первая статья была вводной, тут ничего интересного нет. Вторая будет уже более интересной. Далее спойлер - А закончится это всем чек-листом по подбору ОС на нашем рынке.
То, о чем вы говорите, тоже имеет место быть. Я с этим не спорю. Однако, хотелось бы дать пару своих комментариев. Вы говорите о коммерческом рынке, к большей части которого регулятор не предъявляет никаких требований. В связи с этим они, конечно, могут и свой Линукс сделать и много чего еще. При этом довольно большую часть рынка занимают компании, которые вынуждены приобретать сертифицированные ОС, чтобы выполнить требования регулятора. В таком случае тоже можно пойти по пути "сделать свою ОС, получить на нее сертификат ФСТЭК и внедрить". Однако, чтобы получить сертификат нужно соответствовать тем требованиям, которые я привел в статье. Это значит, что нужно нанять штат людей (кроме разработчиков, QA и т.п.), которые будут заниматься выстраиванием внутренних процессов по разработке безопасного ПО (далее по тексту - РБПО), проводить различные виды тестирований с целью улучшения безопасности ОС (стат. и дин. анализ, фаззинг, пентесты, антивирусные проверки, поиск и устранение известных уязвимостей компонент ОС и т.п.), разрабатывать необходимую документацию (по сертификации порядка 15 документов и по РБПО еще столько же), выполнять SLA регулятора на устранение уязвимостей, на обеспечение поддержки и еще много чего. Реализация всех этих процессов обойдется в "копеечку", плюс еще дальше придется все это сертифицировать - это стоит еще одну "копеечку" и потраченного времени - минимум полгода будут идти испытания. Такие процессы мало кто сможет себе позволить, а те кто может, тот и является сегодня вендором ОС.
Относительно этого высказывания:
Во-вторых, они не будут покупать "российские системы" пока их не заставят, а будут использовать Линукс. А когда заставят, купят самую дешёвую, поставят в угол сервера и будут и дальше использовать Линукс.
Такое можно представить, и я даже знаю несколько компаний, которые пытались так сделать. Существует только одна проблема - если это компания подпадает под требования регулятора, то к ней приходят люди и аттестуют системы, и такие вот "фокусы" вскрываются очень быстро и очень быстро приводятся в порядок. Поэтому, если правильно "заставить", то все будет работать и на полочках лежать не будет. Но это если заставлять будет регулятор. А если "заставляет" руководство коммерческой компании, то тут уже все будет зависеть от зрелости процессов этой компании. Знаю несколько коммерческих компаний, которые сделали ровно так как вы и написали, т.к. внутри контроль отсутствовал от слова "совсем", а внешнего контроля не было. В итоге лежали на полочке купленные средства, а ДИТ продолжал работать по своим правилам на том, на чем хотел.
Но в целом, все о чем вы говорите имеет место быть. И то, о чем я писал в комментарии выше, этому никак не противоречит. В итоге все равно придет к тому, что останутся только самые стойкие и им уже придется бороться за своего клиента.
Соглашусь с вами. Речь идет, конечно, не обо всех вендорах на рынке. Бывают разные вендоры, у каждого свои цели - кто-то хочет заработать, кто-то хочет сделать мир лучше и т.п. Можно сказать, что я идеализирую, чтобы никого не обидеть своими комментариями:)
Да уж, согласен. Каждый вендор смотрит на конкурентов, видит в их продуктах какие-то недостатки и пытается сделать свой, в котором эти недостатки устраняет (при этом создавая другие). С одной стороны - это грустно, с другой стороны - это естественный этап отбора. В результате победит сильнейший, а слабые со временем уйдут в небытие...К тому времени на рынке образуется несколько крупных вендоров, которые в конкурентной гонке будут вынуждены делать более качественные продукты, что для простых пользователей несомненно будет плюсом. Конкуренция - двигатель прогресса:)
Как я сказал в статье - их 15. И их количество продолжает увеличиваться.
Я не говорю, что белые шляпы должны подождать. Я говорю лишь о том, что вендор, который хочет сделать хороший и безопасный продукт, должен содержать в своем штате исследователей (белых шляп), и развить для начала внутри все процессы. И когда он почувствует, что его белые шляпы уже ничего нового найти не могут, вот тогда отправляться на площадки Bug Bounty, для обеспечения внешнего элемента проверки, когда внутренние уже не результативны. Иначе получается, что сам вендор сделать ничего не может и передает это дело людям на сторону и зависит чисто от их желания/сообразительности/времени и т.п. При этом на таких площадках чаще всего тестируют Black Box, и если уж ребята с площадки находят у тебя уязвимости не видя кода твоего изделия, то встает вопрос: "А твои то люди чем занимаются в компании? У них есть доступ к коду, есть всевозможные анализаторы и еще кучу приблуд. Почему люди на площадке методом Black Box что-то находят, а твои методом White Box найти не могут?". Тут сразу думается, что либо вендор экономит на специалистах, либо специалисты у него не очень, либо внутренние процессы работают неправильно, либо все вместе взятое. И тогда получается, почему я должен отдавать приоритет этому вендору, если у него внутри такие проблемы? Я лучше отдам приоритет вендору, которого нет на Bug Bounty площадках, но у которого и уязвимости внутри находятся и устраняются, и про которого не пишут на Хабре или других площадках о том, что в составе его ОС уязвимости нулевых годов. И вот только поэтому не вижу смысла этот пункт добавлять:)
Да е-мае, с телефона не удобно и задачи смотреть и комментарии набирать. По второй задаче тоже корректировка. 3 курицы за 12 дней снесут 12 яиц, а если куриц становится в 4 раза больше, то 12х4 = 48
И по первой задаче корректировка. Думал, что всего людей 9, а там 9 и я, т.е. 10. Тогда логика та же, но цифры другие: 45 дорог всего, получается 45 - 9 = 36 дорог можно не чистить
Прошу прощения, в 4й задаче забыл про условие - у фермера 3000 яблок. Тогда вообще не понятно, на обратном пути до фермы он как бы без яблок может обходиться? Если так, то довезет он 3 яблока. Суть та же, что описал выше, но только вместо одной будет 3 поездки
1. 45 дорог всего (9+8+7+6+5+4+3+2+1), чтобы пройти от дома к любому дому нужно оставить 9 дорог, это будет выглядеть как дерево с корнем в одном доме. В таком случае 45 - 9 = 36 дорог можно не чистить.
2. 12х4=48 яиц.
3. 14.57 - время на часах, Андрей думает, что 14.55, реальное время - 15.00., т.е. Андрей опаздает на 5 минут. У кати на часах 15.02, она думает, что 14.59, а реально 15.00, т.е. Катя опаздает на встречу на 1 минуту. При таком раскладе опаздают оба, но Кате придётся ждать Андрея лишних 4 минуты.
4. 3 яблока, т.к. он съедает яблоко только проехав 1 км, поэтому последний 1000й километр он проедет, но не успеет съесть яблоко, т.к. достигнет прилавка. И так 3 раза, при условии, что на обратном пути он может обходиться без яблок. Иначе придётся решать задачу с условием складирования яблок, но условие задачи этого не предполагает.
С точки зрения функционала, что несертифицированная ОС + СЗИ от НСД, что сертифицированная ОС - одинаковы (за исключением пары функций, таких как, например наличие/отсутствие сертифицированного МЭ). Дьявол кроется в деталях. СЗИ от НСД ставится поверх ОС, при этом заменяя важные компоненты ОС (компоненты разграничения доступа, контроля целостности и т.п.) своими компонентами. Кто знает, поломает ли такая замена что-то в ОС или нет? Обычно вендоры СЗИ от НСД пытаются тестировать совместимость своих средств с различными ОС, но даже в таком случае, гарантировать, что все будет работать штатно нельзя. Например, с мажорной версией ОС (чаще всего тестируют именно с ней) их СЗИ будет работать штатно, но после установки обновлений ОС все слетит из-за того, что вендор ОС повысил версию пакета какого-то компонента ради устранения в нем уязвимости, а СЗИ от НСД с пакетом старшей версии работать не сможет.
На практике встречал такие случаи и заканчивались они следующим: пользователь приходил к вендору СЗИ от НСД с проблемой, те отправляли его к вендору ОС. Вендор ОС разбирался в проблеме и отправлял пользователя обратно к вендору СЗИ от НСД. И так по кругу... И доказать, что кто-то из них не прав - тяжело.
Если вы рассматриваете такой вариант применения, то обязательно уточните у обоих вендоров, ведут ли они процесс по взаимной поддержке мажорных и минорных версий СЗИ от НСД и ОС между собой. Тестироваться должно любое изменение одного из продуктов с актуальной версией другого и только после этого попадать к пользователю. Реализация такого процесса у этих вендоров - трудный процесс (один хочет быстрее выпустить обновление, другой ленится переписывать свое изделие, т.к. нужно проводить по новой сертификацию и т.п.). На практике очень трудно найти 2х таких вендоров, которые будут работать как единая команда. Самый идеальный вариант при необходимости применения такого решения найти вендора, который будет поставщиком обоих решений, и в случае каких-либо проблем вы будете обращаться в единое окно.
Описанное выше - это только малая часть проблем, с которыми можно столкнуться при таком подходе. Выбирая его нужно быть осторожным. Я опишу все нюансы, о которых мне известно, в отдельной статье про выбор несертифицированной ОС (выйдет позже...может быть в июле-августе).
Вывод: если хотите работать с меньшим количеством проблем, то лучше брать сертифицированную ОС. Если по тем или иным причинам нет возможности взять сертифицированную ОС, то уточняйте про то, как проводится тестирование совместимости и кто будет отвечать в случае поломки, а также будьте готовы работать на необновленной уязвимой ОС какое-то время, пока вендор СЗИ от НСД не пройдет сертификацию на обновление своего СЗИ, работающего с новой минорной версией ОС.
P.S. В вашем случае я бы все-таки рассмотрел вариант взять сертифицированную ОС и поставить туда МЭ, пусть и с дополнительным функционалом СКЗИ или СОВ. По крайней мере это средство не будет заменять компоненты ОС своими и у вас не образуется зависимая связка этих продуктов.
P.P.S. Посмотрите еще Secret Net Studio 8, в его состав входит МЭ типа В, и вроде как его можно приобрести отдельно как модуль. Если это так, то можно купить сертифицированную ОС + Модуль персонального межсетевого экрана Средства защиты информации Secret Net Studio 8, тогда проблем, думаю, будет меньше, чем применять целиком СЗИ от НСД + несертифицированную ОС.
Однако же наличие сертифицированного ФСБ СКЗИ в этих продуктах не мешает применять большинство из них именно как МЭ. И самое главное, что на них есть действующий сертификат ФСТЭК на ИТ.МЭ.В4.ПЗ, что позволяет их применять на объектах информатизации для нейтрализации существующих угроз, которые можно закрыть МЭ такого типа и класса защиты.
Если вы ищете на рынке чистый FW без лишнего функционала, добавленного вендорами, то получается, что да, таких экранов не будет. Тут как покупать машину: я хочу, чтобы у нее было 4 колеса, руль и мотор. Больше мне ничего не нужно. Но когда я прихожу к дилерам, то они мне зачем-то дают машину с климат-контролем, автоматом, кожаными сидениями, кучей всякой электроники и т.п. И сколько бы я не искал машину на рынке чисто с 4 колесами, рулем и мотором, я ее не найду. В случае с FW, думаю, работает так же.
С вашими доводами полностью согласен и поддерживаю. Я этот момент как раз буду поднимать в следующей части статьи. Существует только одно "но"...На рынке сейчас только одна ОС вышла на такие площадки с программой Bug Bounty. Это круто, когда вендор ОС вкладывает деньги в безопасность, выходит на такие площадки и т.п., но мне кажется (ИМХО), сначала нужно поднять хороший процесс по безопасности внутри компании и только потом выходить на такие площадки. Иначе, как писал Михаил Булгаков:
Что в целом и произошло по результатам выхода этой компании на площадку (сужу по статьям на хабре, в которых исследователи описывали как они тестили, как им деньги не платили, какие доисторические уязвимости находили в ключевых компонентах ОС и т.п.).
Когда вендоры ОС в нашей стране достигнут того уровня внутренних процессов по обеспечению безопасности своих продуктов, чтобы можно было выходить на площадки и показывать, что мол "у нас безопасные системы, попробуйте что-нибудь в них найти", тогда такой пункт будет показателем их реальной работы и его и правда можно будет добавить в список. А пока что выход на Bug Bounty площадки таких вендоров - это не показатель их крутой внутренней работы по поиску уязвимостей, а скорее просьба о помощи к народу, вроде "ребята, у меня нет хороших спецов, которые могут найти уязвимости, прошу помощи и готов заплатить вам деньги". Я бы к такому вендору наоборот не пошел (ИМХО). Поэтому, на сегодняшний день, не считаю данный пункт необходимым в списке вопросов.
Хороший вопрос. Вендор, с которым вы общались, прав. МЭ, который входит в состав сертифицированной ОС и правда выполняет не все функции безопасности, которые предусматриваются профилем защиты (далее по тексту - ПЗ) на МЭ типа В. Если быть точнее, то МЭ, который входит в состав ОС, конечно, может выполнять все необходимые функции, но проблема в том, что в соответствии с профилем защиты на ОС половина необходимых для МЭ функций просто не проверяется при сертификации, т.к. ПЗ на ОС не предполагает проверок этих функций. В связи с этим МЭ с одной стороны по функционалу может подходить, но с другой стороны этот функционал никто не проверял при испытаниях, в связи с чем нельзя сказать, что все функции работают так, как предписано профилем защиты на МЭ. Отсюда вытекают требования регулятора приобретать именно тот МЭ, который был сертифицирован на ПЗ к МЭ типа В, т.к. его функциональные возможности точно проверялись и можно быть уверенным, что он будет обеспечивать защиту от угроз, которые приведены в ПЗ на МЭ типа В.
Относительно средств, которые можно применять в таком случае: не только в СЗИ от НСД (Dallas или SecretNet) входят МЭ. На рынке есть ряд самостоятельных продуктов, которые можно применять. Пожалуйста, не сочтите за рекламу, но в реестре ФСТЭК я вижу как минимум следующие самостоятельные средства, которые можно рассмотреть к применению:
ViPNet 4;
ViPNet Personal Firewall 4.5;
ViPNet EndPoint Protection;
С-Терра Клиент. Версия 4.2;
С-Терра Клиент. Версия 4.3;
Diamond VPN/FW;
«ЗАСТАВА-Клиент «VPN/FW «ЗАСТАВА, версия 6».
Вы считаете, что это массовый критерий, которым пользуется большинство людей при выборе ОС?
Формально, эти пакеты являются составной частью AL, за них разработчик (РусБИТех-Астра, далее РБТ-А) несет полную ответственность перед конечным потребителем (исправляет уязвимости при обнаружении, восстанавливает работоспособность при ошибках и т.п.). У РБТ-А есть их исходный код, они могут его переписывать, компилировать и собирать. Права по лицензии они никакие не нарушают. Поэтому, да, считается, что РБТ-А является владельцем этих компонент, но только в составе своей ОС. И отсюда следует, что данное ПО можно назвать отечественным.
P.S. Знаю, сейчас могут полететь упреки в мою сторону, но не я это придумал, так работает система, а я просто озвучил принципы ее работы:)
Я же уже сказал - ни одного названия ОС или вендора вы не увидите в статье. Это не рекламная статья:)
Нет. Я принципиально пишу не рекламную статью, а делюсь опытом, который собирал больше 10 лет. Ни одного упоминания про любые существующие ОС на рынке вы не увидите. Первая статья была вводной, тут ничего интересного нет. Вторая будет уже более интересной. Далее спойлер - А закончится это всем чек-листом по подбору ОС на нашем рынке.
То, о чем вы говорите, тоже имеет место быть. Я с этим не спорю. Однако, хотелось бы дать пару своих комментариев. Вы говорите о коммерческом рынке, к большей части которого регулятор не предъявляет никаких требований. В связи с этим они, конечно, могут и свой Линукс сделать и много чего еще. При этом довольно большую часть рынка занимают компании, которые вынуждены приобретать сертифицированные ОС, чтобы выполнить требования регулятора. В таком случае тоже можно пойти по пути "сделать свою ОС, получить на нее сертификат ФСТЭК и внедрить". Однако, чтобы получить сертификат нужно соответствовать тем требованиям, которые я привел в статье. Это значит, что нужно нанять штат людей (кроме разработчиков, QA и т.п.), которые будут заниматься выстраиванием внутренних процессов по разработке безопасного ПО (далее по тексту - РБПО), проводить различные виды тестирований с целью улучшения безопасности ОС (стат. и дин. анализ, фаззинг, пентесты, антивирусные проверки, поиск и устранение известных уязвимостей компонент ОС и т.п.), разрабатывать необходимую документацию (по сертификации порядка 15 документов и по РБПО еще столько же), выполнять SLA регулятора на устранение уязвимостей, на обеспечение поддержки и еще много чего. Реализация всех этих процессов обойдется в "копеечку", плюс еще дальше придется все это сертифицировать - это стоит еще одну "копеечку" и потраченного времени - минимум полгода будут идти испытания. Такие процессы мало кто сможет себе позволить, а те кто может, тот и является сегодня вендором ОС.
Относительно этого высказывания:
Такое можно представить, и я даже знаю несколько компаний, которые пытались так сделать. Существует только одна проблема - если это компания подпадает под требования регулятора, то к ней приходят люди и аттестуют системы, и такие вот "фокусы" вскрываются очень быстро и очень быстро приводятся в порядок. Поэтому, если правильно "заставить", то все будет работать и на полочках лежать не будет. Но это если заставлять будет регулятор. А если "заставляет" руководство коммерческой компании, то тут уже все будет зависеть от зрелости процессов этой компании. Знаю несколько коммерческих компаний, которые сделали ровно так как вы и написали, т.к. внутри контроль отсутствовал от слова "совсем", а внешнего контроля не было. В итоге лежали на полочке купленные средства, а ДИТ продолжал работать по своим правилам на том, на чем хотел.
Но в целом, все о чем вы говорите имеет место быть. И то, о чем я писал в комментарии выше, этому никак не противоречит. В итоге все равно придет к тому, что останутся только самые стойкие и им уже придется бороться за своего клиента.
Соглашусь с вами. Речь идет, конечно, не обо всех вендорах на рынке. Бывают разные вендоры, у каждого свои цели - кто-то хочет заработать, кто-то хочет сделать мир лучше и т.п. Можно сказать, что я идеализирую, чтобы никого не обидеть своими комментариями:)
Да уж, согласен. Каждый вендор смотрит на конкурентов, видит в их продуктах какие-то недостатки и пытается сделать свой, в котором эти недостатки устраняет (при этом создавая другие). С одной стороны - это грустно, с другой стороны - это естественный этап отбора. В результате победит сильнейший, а слабые со временем уйдут в небытие...К тому времени на рынке образуется несколько крупных вендоров, которые в конкурентной гонке будут вынуждены делать более качественные продукты, что для простых пользователей несомненно будет плюсом. Конкуренция - двигатель прогресса:)