Comments 23
чем-нибудь более детальным про саму процедуру сертификации поделитесь или предпочтете хранить эту информацию у себя как коммерческую организационную ценность?
А что конкретно интересует? Просто сама процедура сертификации в целом — довольно скучное бюрократическое мероприятие, которое, я полагал, не интересно читателям Хабра.
вот я вполне себе читатель хабра и мне очень интересны все те круги ада, по которым вы прошли =)

Можете ли назвать ориентировочную стоимость и если нет, то хотя бы от чего она зависит (скажем, 100 рублей за LOC или что-то ещё)?

Отдавали ли вы исходники людям в погонах или вообще каким-то мутным гражданским не под присягой?

Правильно ли я понимаю, что если вы отдали код на сертификацию и завтра же нашли критический баг, то всё очень и очень плохо?

Насколько сложна досертификация обновлений или это повторная сертификация того же ПО?

Кто и как готовит план сертификации ПО? Это какая-то карта вашей функциональности или что это?

Скажите пожалуйста а как быть гос. сектору с тем что ( далее цитирую):

«законодательством установлен запрет на закупку программ для электронных вычислительных машин и баз данных, реализуемых независимо от вида договора на материальном носителе и (или) в электронном виде по каналам связи, происходящих из иностранных государств, а также исключительных прав на такое программное обеспечение и прав использования такого программного обеспечения (далее — программное обеспечение и (или) права на него), для целей осуществления закупок для обеспечения государственных и муниципальных нужд, за исключением следующих случаев:
а) в реестре (https://reestr.minsvyaz.ru) отсутствуют сведения о программном обеспечении, соответствующем тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке;
б) программное обеспечение, сведения о котором включены в реестр и которое соответствует тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке, по своим функциональным, техническим и (или) эксплуатационным характеристикам не соответствует установленным заказчиком требованиям к планируемому к закупке программному обеспечению.

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

Указанные выше положения содержатся в ПП 1236 от 16.11.2015. „
Порядок подготовки обоснования невозможности закупки из Реестра подробно описан в этом же постановлении правительства ПП 1236 от 16.11.15.

На текущий момент в Реестре нет сертифицированных ФСТЭК продуктов для резервного копирования VMware vSphere и Microsoft Hyper-V. Сертификат ФСТЭК обязателен в описанных мною в посте случаях. Поэтому государственный заказчик в своем обосновании невозможности закупки из реестра, может прямо сослаться на пункт «а» в вашей цитате выше.

Примеры написания таких обоснований (и письменная работа с возражениями) для более сложного случая (пункт «б») в настоящий момент можно посмотреть на сайте госзакупок, например, закупка «Оказание услуг по предоставлению (продлению) неисключительных прав (лицензий) на использование программного обеспечения Microsoft». Кроме того, недавно опубликована подробная статья еще с одним примером:«Windows и SQL Server против российских аналогов: Результаты анализа ФОМС»

Дополнительно еще можно посмотреть в статье М.Ю. Емельянникова (ссылка №2 в разделе «ссылки» в моем посте) — в статье есть в конце раздел «что делать в эпоху импортозамещения».
Возможно ли сертифицировать уже купленный продукт. Если да, то какова процедура?
Увы, нет- в прайсе есть SKU только под новые продажи ФСТЭК версии. Логика здесь в том, что если у заказчика установлена обычная версия Veeam, то ему, вроде бы, незачем переходить на сертифицированную версию, так как она старее, а при этом сертификат, видимо, заказчику не обязателен.
ЗСВ.8 элементарно закрывается орг мерами.

СЗИ от НДС типа SecretNet и Vgate, которые и так должны стоять на всех компонентах ИС (если конечно хотите аттестоваться), и так позволят использовать любой бакапер по вкусу.

Сертифицированный бакапер можно конечно купить, если деньги девать некуда.
Это сложный вопрос, отвечу по пунктам:

Про vGate и SecretNet и меру ЗСВ.8.
SecretNet — это СЗИ от НСД, которое в среде виртуализации защищает от НСД только виртуальные машины и меру ЗСВ.8 не реализует. На хост ESX SecretNet вообще нельзя установить; на хост Hyper-V установить можно, но он будет защищать от НСД только сам физический хост, но не виртуальные машины и не среду виртуализации от угроз, которые специфичны для этой среды.

vGate реализует меры ЗСВ.1- ЗСВ.7 и ЗСВ.10, и НЕ реализует меру ЗСВ.8 — например, можете это посмотреть в документе RISSPA “Проблема выбора средств защиты информации для виртуализированных инфраструктур”:
Таблица №1.


Про организационные меры и «любой бэкапер». Оргмеры — это, например, решетки на окнах, изоляция рабочего места от сети, и автоматчик на входе, проверяющий документы. Вне всяких сомнений подобными оргмерами можно заменить СЗИ от НСД, которые реализуют меры по аутентификации, авторизации и разграничению доступа. Но как решетки на окнах помогут пользователю выполнить требование на резервное копирование информации (ЗСВ.8)?

Особенность резервного копирования в том, что это не просто мера защиты (с 2013 года), а это еще и т.н. «функция общесистемного назначения», которая нужна пользователю системы вне зависимости от того, как строится система безопасности информации, и поэтому ее нельзя заменить оргмерами. Скажем, если объект критической инфраструктуры (например, АЭС) остановиться (=отключиться свет в ближайшем городе) из-за того, что не было бэкапа в АСУ ТП, потому что он был заменен «решетками на окнах», то ответственность за такой результат ляжет на системного администратора (условное название должности). Аналогичный результат будет, если в качестве бэкап продукта использовалась «условно-бесплатная программа» без сертификата, подтверждающего что ею можно бэкапить АСУ ТП на АЭС, и эта программа вдруг в нужный момент не отработала корректно.

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

Про компенсирующие меры. Тем не менее, я предположу, что вы на самом деле имели в виду не организационные, а “компенсирующие меры”, возможность применения которых указана в подпункте “д” пункта 2.3 методического документа ФСТЭК “меры защиты информации в государственных информационных системах”. Да, программно-техническую реализацию меры ЗСВ.8 (сертифицированный продукт) можно заменить в проекте безопасности компенсирующими мерами, для чего компания-проектировщик ИБ (с лицензией ФСТЭК) должна выполнить следующее:
Цитата из п. 2.3-д
При этом должно быть проведено обоснование применения компенсирующих мер защиты информации, включающее:
— изложение причин исключения меры (мер) защиты информации;
— сопоставление исключаемой меры (мер) защиты информации с блокируемой (нейтрализуемой) угрозой (угрозами) безопасности информации;
— описание содержания компенсирующих мер защиты информации;
— сравнительный анализ компенсирующих мер защиты информации с исключаемыми мерами защиты информации;
— аргументацию, что предлагаемые компенсирующие меры защиты информации обеспечивают адекватное блокирование (нейтрализацию) угроз безопасности информации.

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


Будет ли действительно дешевле это все спроектировать и выполнить, чем те 5%, на которые сертифицированный продукт стоит дороже не сертифицированного — это вопрос, который нужно считать в каждом конкретном случае.

Про деньги. Как я уже сказал, сертифицированная версия продукта стоит всего на 5% дороже обычной версии, а, поскольку резервное копирование типично требуется организации в любом случае, то нужно сравнивать именно эту наценку со стоимостью разработки проекта безопасности, в котором мера 3СВ.8 будет заменена компенсирующими мерами. Такие проекты тоже дешево не стоят (по крайней мере в Москве).
Компенсирующие меры применяются когда исключаем какие то меры.

ЗСВ.8 мы не исключаем, а реализуем орг мерами.
Н
ЗСВ.8 это частный случай ОДТ.2, ОДТ.4, ОДТ.5. которые закрываются через организационно-распорядительные документы оператора. Приписывается что да бакапимся, да исправно. А чем уже до лампочки.

Что касается вашего сертификата, то ТУ это ни о чем. Если бы было про сзи от НДС, или соответствие профилю защиты, То было бы интересно. Но увы бакапер это не сзи в контексте регулятора )
В мерах по резервному копированию нет требований по автоматизированному процессу резервного копирования с применением дополнительных средств, т.е можно закрыться орг. мерами (инструкция по резервному копированию, когда админ периодически копирует инфу на зарегистрированные носители).

В случае если данная мера реализуется дополнительным средством, например Veeam Backup, то для ГИС и ИСПДн это средство должно пройти процедуру оценки соответствия (сертификацию). Мера ЗСВ.8, согласно ФСТЭК, является обязательной для ГИС К1 и К2, ИСПДн УЗ1 и УЗ2. Для этих классов СЗИ, закрывающие определенные меры, должны пройти контроль отсутвия недакларированных возмодностей, как минимум по уровню НДВ4.

Итого, если хотим закрыть ЗСВ.8 есть два способа:
• Орг. меры, т.е. ручками по инструкции.
• Применением специализированного ПО, но в этом случае оно должно пройти оценку соответствия
Ой, лукавите вы конечно, когда пишите, что нужно обязательно использовать сертифицированный бэкапер. Как минимум, вопрос не такой однозначный. По сути бэкапер относится к средствам отказоустойчивости. Если говорить, что отказоустойчивость должна обеспечиваться только сертифицированными ФСТЭК решениями, то по такой логике все ИБП на машинах пользователей и в серверной должны иметь заветную голограмму. Еще, как пример, криптошлюз и межсетевой экран ViPNet Coordinator HW1000 сам по себе сертифицирован, а компонент failover, который позволяет держать две железки в горячем отказоустойчивом кластере — нет, и у ФСТЭК никогда претензий к этому факту не возникало, хотя в том же ЗСВ.8 прописано и резервирование технических средств. К тому же нигде не написано, что резервное копирование данных должно производиться специализированными бэкаперами, мы можем в техническом задании на систему защиты информации прописать, что это делается админом руками, что в этом случае сертифицировать?
Я не хочу сказать, что это плохо, иметь такой продукт на рынке, очень даже хорошо и многим будет полезно. Но вопрос обязательности сертификации здесь как минимум обсуждаем и неоднозначен.
боюсь, что вы не совсем правильно рисуете себе ситуацию =)

Вряд ли кто-то будет писать ужасный закон или указ по которому только сертифицированное ПО. Другой вопрос в том, что покупатель теперь может указать что он хочет только с сертификатом и тем самым сузит круг предложения.

Можете сказать: «взятки», «купленный тендер» и будете и правы, и не правы. Механизм тендеров подразумевает, что закупщик делает всё новые (обоснованные) условия, что бы выбрать того, с кем уже договорился и тем самым стимулирует других игроков рынка развиваться и идти дальше, добавляя эти фичи к себе в продукт.

Гонка фич помогает сбросить тендерный фрод. Одно дело собрать однодневную компанию, которая занимается тендерным рейдерством, взяв у кого-то на реализацию софт 10-летней давности, другое дело гнаться за растущим перечнем требований.

Так что тут есть разные грани ситуации.
Немного не понял к чему тут тендеры и взятки, я немного о другом. Но в конце вы пишите то же что и я — разные грани ситуации и нет однозначного ответа на вопрос «должны ли мы использовать только сертифицированные и только автоматические средства для бэкапа?».
"К тому же нигде не написано, что резервное копирование данных должно производиться специализированными бэкаперами" — увы, но статья М.Ю. Емельянникова (ссылка №2 в разделе ссылок в моем посте) как раз содержательно (18 страниц) описывает в каких законах, приказах и постановлениях правительства это написано.

Да, ранее (до 2013 года) много лет резервное копирование данных считалось «общесистемной функцией», а не средством обеспечения защищенности системы, и на бэкап требования ФСТЭК не распространялись, потому что это не считалось средством защиты. Но приказы ФСТЭК 17, 21 и 31 отнесли бэкап к средствам защиты — для определенных систем и видов информации. Логика приказов состоит в том, что есть системы (например, в МЧС) для которых требуется государственный контроль за резервным копированием этих систем в виду их критичности. Или допустим вирус-шифровальщик зашифрует АСУ ТП на АЭС. Последствия могут быть плачевными, если нет бэкапа. Поэтому средства резервного копирования для определенных случаев были отнесены к средствам защиты, и стали подпадать под требования ФСТЭК к этим системам, что влечет необходимость сертификации в этих оговоренных в законодательстве случаях.

Касательно резервирования или отказоустойчивости самих СЗИ — насколько я знаю, у ФСТЭК нет явных требований к отказоустоячивости СЗИ, поэтому эти механизмы и могут оставаться несертифицированными. Эти механизмы предлагаются производителями не в силу требований ФСТЭК, а в силу ожиданий заказчиков (требований бизнеса).

Касательно «возможности делать бэкап руками» (т.н. «компенсирующие меры»), смотрите этот мой ответ на другой комментарий.
Читал я статью Емельянникова, сразу же как она вышла. Там, как и в любом маркетинговом материале, «необходимость» притянута за уши. Вот вы пишите, что там описана необходимость использовать специализированные средства для бэкапа, но нет, там этого нет. Там написано о том, что согласно законодательству нужно делать резервные копии и обеспечить возможность восстановления из них, а дальше идет манипулятивный и спекулятивный пассаж автора «логично предположить, что...». Но вот какая ерунда получается — Емельянникову логично, а мне и ФСТЭКу не логично. Ибо сколько уже прошло положительных проверок ГИСов 1 и 2 класса, где бэкапы делались руками или даже несертифицированными автоматическими средствами — я затрудняюсь сосчитать.

Похоже пора писать очередное официальное письмо во ФСТЭК за разъяснениями, правда они уже 2 месяца не отвечают на вопросы про аттестацию типовых сегментов, но попробовать думаю стоит.
В методичке к 17 приказу все в принципе расписано. Когда дело касается автоматизации, там применятся пассаж про «свойства» ОИ. В иных случаях просто говориться про выстраивание процессов оргмерами.
Емельяников признанный спец, но тут видно писал чисто под заказ )
Мне кажется, у регулятора (ФСТЭК) вполне понятная логика. СЗИ используются для нейтрализации актуальных угроз. Определяются системы, где сертификация СЗИ обязательна (приказ № 17 п.15.1 «осуществляется выбор средств защиты информации, сертифицированных на соответствие требованиям по безопасности информации, с учетом их стоимости, совместимости с информационными технологиями и техническими средствами, функций безопасности этих средств и особенностей их реализации, а также класса защищенности информационной системы»). Определяются системы, где сертифицированные (прошедшие процедуру оценки соответствия) СЗИ необходимы для нейтрализации актуальных угроз (ст.19 152-ФЗ для ИСПДн). А про СЗИ без сертификатов на аттестованных объектах информатизации я и сам рассказать могу много. И про аттестаты на системы с единственных сертифицированным СЗИ тоже.
C СЗИ-то понятно, раньше могли в техническом задании обосновать использование несертефицированного бэкапера тем, что сертифицированных нет на рынке, сейчас уже будет сложнее, хотя 17 приказ любую меру компенсировать, которую затруднительно выполнить по следующим причинам: высокая стоимость, отсутствие апробированных технических реализаций, неприемлемо большие сроки реализации, отсутствие компетенции для эксплуатации и другие. Сложно, но возможно. Но нас тут пытаются убедить, что мы не можем прописать, что резервирование и восстановление мы делаем руками и тем самым выполняем требования и нейтрализуем угрозы. Я, как уже сказал, не против этого продукта, скорее даже за, пусть будет. А по поводу ручного/автоматического бэкапа все же напишу запрос на разъяснение во ФСТЭК. Мне-то в принципе все равно что ответят, мне главное получить ясность позиции регулятора.
Я много раз сталкивался с тем, что позиция регулятора и надзора может быть очень разной, в зависимости от объекта и целей проверки, мнения конкретного исполнителя и т.д.И з приведенного мною текста, на мой взгляд, однозначно следует, что если угроза утраты целостности и доступности признана актуальной, для ее нейтрализации необходимо использовать сертифицированное СЗИ. Да, про компенсирующие меры и их обоснование в методичке очень много и правильно, но формальный повод для привлечения к административке по части 2 ст.13.12 КоАП существует. Все — на откуп надзору. А запросить разъяснение — это правильно. Только вот нормативного характера оно носить не будет, но это общая беда.
Ну вроде как и вернулись к тому, что как минимум вопрос не такой уж и однозначный =)
Если проверка приходит с целью в итоге наказать, то формальный повод они найдут всегда, как бы прилизано все ни было.
Скан письма с разъяснением всегда можно показать проверяющему, если он пытается продвигать противоположное мнение том, что изложено в письме, подписанном его начальством, обычно действует отрезвляюще.
А так, да — даже у одного и того же сотрудника регулятора может быть сегодня одно мнение, а завтра диаметрально противоположное по одному и тому же вопросу. Это действительно проблема.
Only those users with full accounts are able to leave comments. Log in, please.