Комментарии 23
чем-нибудь более детальным про саму процедуру сертификации поделитесь или предпочтете хранить эту информацию у себя как коммерческую организационную ценность?
А что конкретно интересует? Просто сама процедура сертификации в целом — довольно скучное бюрократическое мероприятие, которое, я полагал, не интересно читателям Хабра.
вот я вполне себе читатель хабра и мне очень интересны все те круги ада, по которым вы прошли =)
Можете ли назвать ориентировочную стоимость и если нет, то хотя бы от чего она зависит (скажем, 100 рублей за LOC или что-то ещё)?
Отдавали ли вы исходники людям в погонах или вообще каким-то мутным гражданским не под присягой?
Правильно ли я понимаю, что если вы отдали код на сертификацию и завтра же нашли критический баг, то всё очень и очень плохо?
Насколько сложна досертификация обновлений или это повторная сертификация того же ПО?
Кто и как готовит план сертификации ПО? Это какая-то карта вашей функциональности или что это?
Можете ли назвать ориентировочную стоимость и если нет, то хотя бы от чего она зависит (скажем, 100 рублей за LOC или что-то ещё)?
Отдавали ли вы исходники людям в погонах или вообще каким-то мутным гражданским не под присягой?
Правильно ли я понимаю, что если вы отдали код на сертификацию и завтра же нашли критический баг, то всё очень и очень плохо?
Насколько сложна досертификация обновлений или это повторная сертификация того же ПО?
Кто и как готовит план сертификации ПО? Это какая-то карта вашей функциональности или что это?
Скажите пожалуйста а как быть гос. сектору с тем что ( далее цитирую):
«законодательством установлен запрет на закупку программ для электронных вычислительных машин и баз данных, реализуемых независимо от вида договора на материальном носителе и (или) в электронном виде по каналам связи, происходящих из иностранных государств, а также исключительных прав на такое программное обеспечение и прав использования такого программного обеспечения (далее — программное обеспечение и (или) права на него), для целей осуществления закупок для обеспечения государственных и муниципальных нужд, за исключением следующих случаев:
а) в реестре (https://reestr.minsvyaz.ru) отсутствуют сведения о программном обеспечении, соответствующем тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке;
б) программное обеспечение, сведения о котором включены в реестр и которое соответствует тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке, по своим функциональным, техническим и (или) эксплуатационным характеристикам не соответствует установленным заказчиком требованиям к планируемому к закупке программному обеспечению.
В случаях, если:
а) в едином реестре российских программ для электронных вычислительных машин и баз данных (далее — реестр) отсутствуют сведения о программном обеспечении, соответствующем тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке;
б) программное обеспечение, сведения о котором включены в реестр и которое соответствует тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке, по своим функциональным, техническим и (или) эксплуатационным характеристикам не соответствует установленным заказчиком требованиям к планируемому к закупке программному обеспечению,
должно быть подготовлено обоснование невозможности соблюдения запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд.
Указанные выше положения содержатся в ПП 1236 от 16.11.2015. „
«законодательством установлен запрет на закупку программ для электронных вычислительных машин и баз данных, реализуемых независимо от вида договора на материальном носителе и (или) в электронном виде по каналам связи, происходящих из иностранных государств, а также исключительных прав на такое программное обеспечение и прав использования такого программного обеспечения (далее — программное обеспечение и (или) права на него), для целей осуществления закупок для обеспечения государственных и муниципальных нужд, за исключением следующих случаев:
а) в реестре (https://reestr.minsvyaz.ru) отсутствуют сведения о программном обеспечении, соответствующем тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке;
б) программное обеспечение, сведения о котором включены в реестр и которое соответствует тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке, по своим функциональным, техническим и (или) эксплуатационным характеристикам не соответствует установленным заказчиком требованиям к планируемому к закупке программному обеспечению.
В случаях, если:
а) в едином реестре российских программ для электронных вычислительных машин и баз данных (далее — реестр) отсутствуют сведения о программном обеспечении, соответствующем тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке;
б) программное обеспечение, сведения о котором включены в реестр и которое соответствует тому же классу программного обеспечения, что и программное обеспечение, планируемое к закупке, по своим функциональным, техническим и (или) эксплуатационным характеристикам не соответствует установленным заказчиком требованиям к планируемому к закупке программному обеспечению,
должно быть подготовлено обоснование невозможности соблюдения запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд.
Указанные выше положения содержатся в ПП 1236 от 16.11.2015. „
Порядок подготовки обоснования невозможности закупки из Реестра подробно описан в этом же постановлении правительства ПП 1236 от 16.11.15.
На текущий момент в Реестре нет сертифицированных ФСТЭК продуктов для резервного копирования VMware vSphere и Microsoft Hyper-V. Сертификат ФСТЭК обязателен в описанных мною в посте случаях. Поэтому государственный заказчик в своем обосновании невозможности закупки из реестра, может прямо сослаться на пункт «а» в вашей цитате выше.
Примеры написания таких обоснований (и письменная работа с возражениями) для более сложного случая (пункт «б») в настоящий момент можно посмотреть на сайте госзакупок, например, закупка «Оказание услуг по предоставлению (продлению) неисключительных прав (лицензий) на использование программного обеспечения Microsoft». Кроме того, недавно опубликована подробная статья еще с одним примером:«Windows и SQL Server против российских аналогов: Результаты анализа ФОМС»
Дополнительно еще можно посмотреть в статье М.Ю. Емельянникова (ссылка №2 в разделе «ссылки» в моем посте) — в статье есть в конце раздел «что делать в эпоху импортозамещения».
На текущий момент в Реестре нет сертифицированных ФСТЭК продуктов для резервного копирования VMware vSphere и Microsoft Hyper-V. Сертификат ФСТЭК обязателен в описанных мною в посте случаях. Поэтому государственный заказчик в своем обосновании невозможности закупки из реестра, может прямо сослаться на пункт «а» в вашей цитате выше.
Примеры написания таких обоснований (и письменная работа с возражениями) для более сложного случая (пункт «б») в настоящий момент можно посмотреть на сайте госзакупок, например, закупка «Оказание услуг по предоставлению (продлению) неисключительных прав (лицензий) на использование программного обеспечения Microsoft». Кроме того, недавно опубликована подробная статья еще с одним примером:«Windows и SQL Server против российских аналогов: Результаты анализа ФОМС»
Дополнительно еще можно посмотреть в статье М.Ю. Емельянникова (ссылка №2 в разделе «ссылки» в моем посте) — в статье есть в конце раздел «что делать в эпоху импортозамещения».
Возможно ли сертифицировать уже купленный продукт. Если да, то какова процедура?
ЗСВ.8 элементарно закрывается орг мерами.
СЗИ от НДС типа SecretNet и Vgate, которые и так должны стоять на всех компонентах ИС (если конечно хотите аттестоваться), и так позволят использовать любой бакапер по вкусу.
Сертифицированный бакапер можно конечно купить, если деньги девать некуда.
СЗИ от НДС типа SecretNet и Vgate, которые и так должны стоять на всех компонентах ИС (если конечно хотите аттестоваться), и так позволят использовать любой бакапер по вкусу.
Сертифицированный бакапер можно конечно купить, если деньги девать некуда.
Это сложный вопрос, отвечу по пунктам:
Про vGate и SecretNet и меру ЗСВ.8.
SecretNet — это СЗИ от НСД, которое в среде виртуализации защищает от НСД только виртуальные машины и меру ЗСВ.8 не реализует. На хост ESX SecretNet вообще нельзя установить; на хост Hyper-V установить можно, но он будет защищать от НСД только сам физический хост, но не виртуальные машины и не среду виртуализации от угроз, которые специфичны для этой среды.
vGate реализует меры ЗСВ.1- ЗСВ.7 и ЗСВ.10, и НЕ реализует меру ЗСВ.8 — например, можете это посмотреть в документе RISSPA “Проблема выбора средств защиты информации для виртуализированных инфраструктур”:
Про организационные меры и «любой бэкапер». Оргмеры — это, например, решетки на окнах, изоляция рабочего места от сети, и автоматчик на входе, проверяющий документы. Вне всяких сомнений подобными оргмерами можно заменить СЗИ от НСД, которые реализуют меры по аутентификации, авторизации и разграничению доступа. Но как решетки на окнах помогут пользователю выполнить требование на резервное копирование информации (ЗСВ.8)?
Особенность резервного копирования в том, что это не просто мера защиты (с 2013 года), а это еще и т.н. «функция общесистемного назначения», которая нужна пользователю системы вне зависимости от того, как строится система безопасности информации, и поэтому ее нельзя заменить оргмерами. Скажем, если объект критической инфраструктуры (например, АЭС) остановиться (=отключиться свет в ближайшем городе) из-за того, что не было бэкапа в АСУ ТП, потому что он был заменен «решетками на окнах», то ответственность за такой результат ляжет на системного администратора (условное название должности). Аналогичный результат будет, если в качестве бэкап продукта использовалась «условно-бесплатная программа» без сертификата, подтверждающего что ею можно бэкапить АСУ ТП на АЭС, и эта программа вдруг в нужный момент не отработала корректно.
Поэтому, использование сертифицированных продуктов там, где это требуется по закону, — это еще и способ снять ответственность с администратора системы за выбор технического решения.
Про компенсирующие меры. Тем не менее, я предположу, что вы на самом деле имели в виду не организационные, а “компенсирующие меры”, возможность применения которых указана в подпункте “д” пункта 2.3 методического документа ФСТЭК “меры защиты информации в государственных информационных системах”. Да, программно-техническую реализацию меры ЗСВ.8 (сертифицированный продукт) можно заменить в проекте безопасности компенсирующими мерами, для чего компания-проектировщик ИБ (с лицензией ФСТЭК) должна выполнить следующее:
Будет ли действительно дешевле это все спроектировать и выполнить, чем те 5%, на которые сертифицированный продукт стоит дороже не сертифицированного — это вопрос, который нужно считать в каждом конкретном случае.
Про деньги. Как я уже сказал, сертифицированная версия продукта стоит всего на 5% дороже обычной версии, а, поскольку резервное копирование типично требуется организации в любом случае, то нужно сравнивать именно эту наценку со стоимостью разработки проекта безопасности, в котором мера 3СВ.8 будет заменена компенсирующими мерами. Такие проекты тоже дешево не стоят (по крайней мере в Москве).
Про 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. которые закрываются через организационно-распорядительные документы оператора. Приписывается что да бакапимся, да исправно. А чем уже до лампочки.
Что касается вашего сертификата, то ТУ это ни о чем. Если бы было про сзи от НДС, или соответствие профилю защиты, То было бы интересно. Но увы бакапер это не сзи в контексте регулятора )
ЗСВ.8 мы не исключаем, а реализуем орг мерами.
Н
ЗСВ.8 это частный случай ОДТ.2, ОДТ.4, ОДТ.5. которые закрываются через организационно-распорядительные документы оператора. Приписывается что да бакапимся, да исправно. А чем уже до лампочки.
Что касается вашего сертификата, то ТУ это ни о чем. Если бы было про сзи от НДС, или соответствие профилю защиты, То было бы интересно. Но увы бакапер это не сзи в контексте регулятора )
В мерах по резервному копированию нет требований по автоматизированному процессу резервного копирования с применением дополнительных средств, т.е можно закрыться орг. мерами (инструкция по резервному копированию, когда админ периодически копирует инфу на зарегистрированные носители).
В случае если данная мера реализуется дополнительным средством, например Veeam Backup, то для ГИС и ИСПДн это средство должно пройти процедуру оценки соответствия (сертификацию). Мера ЗСВ.8, согласно ФСТЭК, является обязательной для ГИС К1 и К2, ИСПДн УЗ1 и УЗ2. Для этих классов СЗИ, закрывающие определенные меры, должны пройти контроль отсутвия недакларированных возмодностей, как минимум по уровню НДВ4.
Итого, если хотим закрыть ЗСВ.8 есть два способа:
• Орг. меры, т.е. ручками по инструкции.
• Применением специализированного ПО, но в этом случае оно должно пройти оценку соответствия
В случае если данная мера реализуется дополнительным средством, например Veeam Backup, то для ГИС и ИСПДн это средство должно пройти процедуру оценки соответствия (сертификацию). Мера ЗСВ.8, согласно ФСТЭК, является обязательной для ГИС К1 и К2, ИСПДн УЗ1 и УЗ2. Для этих классов СЗИ, закрывающие определенные меры, должны пройти контроль отсутвия недакларированных возмодностей, как минимум по уровню НДВ4.
Итого, если хотим закрыть ЗСВ.8 есть два способа:
• Орг. меры, т.е. ручками по инструкции.
• Применением специализированного ПО, но в этом случае оно должно пройти оценку соответствия
Ой, лукавите вы конечно, когда пишите, что нужно обязательно использовать сертифицированный бэкапер. Как минимум, вопрос не такой однозначный. По сути бэкапер относится к средствам отказоустойчивости. Если говорить, что отказоустойчивость должна обеспечиваться только сертифицированными ФСТЭК решениями, то по такой логике все ИБП на машинах пользователей и в серверной должны иметь заветную голограмму. Еще, как пример, криптошлюз и межсетевой экран ViPNet Coordinator HW1000 сам по себе сертифицирован, а компонент failover, который позволяет держать две железки в горячем отказоустойчивом кластере — нет, и у ФСТЭК никогда претензий к этому факту не возникало, хотя в том же ЗСВ.8 прописано и резервирование технических средств. К тому же нигде не написано, что резервное копирование данных должно производиться специализированными бэкаперами, мы можем в техническом задании на систему защиты информации прописать, что это делается админом руками, что в этом случае сертифицировать?
Я не хочу сказать, что это плохо, иметь такой продукт на рынке, очень даже хорошо и многим будет полезно. Но вопрос обязательности сертификации здесь как минимум обсуждаем и неоднозначен.
Я не хочу сказать, что это плохо, иметь такой продукт на рынке, очень даже хорошо и многим будет полезно. Но вопрос обязательности сертификации здесь как минимум обсуждаем и неоднозначен.
боюсь, что вы не совсем правильно рисуете себе ситуацию =)
Вряд ли кто-то будет писать ужасный закон или указ по которому только сертифицированное ПО. Другой вопрос в том, что покупатель теперь может указать что он хочет только с сертификатом и тем самым сузит круг предложения.
Можете сказать: «взятки», «купленный тендер» и будете и правы, и не правы. Механизм тендеров подразумевает, что закупщик делает всё новые (обоснованные) условия, что бы выбрать того, с кем уже договорился и тем самым стимулирует других игроков рынка развиваться и идти дальше, добавляя эти фичи к себе в продукт.
Гонка фич помогает сбросить тендерный фрод. Одно дело собрать однодневную компанию, которая занимается тендерным рейдерством, взяв у кого-то на реализацию софт 10-летней давности, другое дело гнаться за растущим перечнем требований.
Так что тут есть разные грани ситуации.
Вряд ли кто-то будет писать ужасный закон или указ по которому только сертифицированное ПО. Другой вопрос в том, что покупатель теперь может указать что он хочет только с сертификатом и тем самым сузит круг предложения.
Можете сказать: «взятки», «купленный тендер» и будете и правы, и не правы. Механизм тендеров подразумевает, что закупщик делает всё новые (обоснованные) условия, что бы выбрать того, с кем уже договорился и тем самым стимулирует других игроков рынка развиваться и идти дальше, добавляя эти фичи к себе в продукт.
Гонка фич помогает сбросить тендерный фрод. Одно дело собрать однодневную компанию, которая занимается тендерным рейдерством, взяв у кого-то на реализацию софт 10-летней давности, другое дело гнаться за растущим перечнем требований.
Так что тут есть разные грани ситуации.
"К тому же нигде не написано, что резервное копирование данных должно производиться специализированными бэкаперами" — увы, но статья М.Ю. Емельянникова (ссылка №2 в разделе ссылок в моем посте) как раз содержательно (18 страниц) описывает в каких законах, приказах и постановлениях правительства это написано.
Да, ранее (до 2013 года) много лет резервное копирование данных считалось «общесистемной функцией», а не средством обеспечения защищенности системы, и на бэкап требования ФСТЭК не распространялись, потому что это не считалось средством защиты. Но приказы ФСТЭК 17, 21 и 31 отнесли бэкап к средствам защиты — для определенных систем и видов информации. Логика приказов состоит в том, что есть системы (например, в МЧС) для которых требуется государственный контроль за резервным копированием этих систем в виду их критичности. Или допустим вирус-шифровальщик зашифрует АСУ ТП на АЭС. Последствия могут быть плачевными, если нет бэкапа. Поэтому средства резервного копирования для определенных случаев были отнесены к средствам защиты, и стали подпадать под требования ФСТЭК к этим системам, что влечет необходимость сертификации в этих оговоренных в законодательстве случаях.
Касательно резервирования или отказоустойчивости самих СЗИ — насколько я знаю, у ФСТЭК нет явных требований к отказоустоячивости СЗИ, поэтому эти механизмы и могут оставаться несертифицированными. Эти механизмы предлагаются производителями не в силу требований ФСТЭК, а в силу ожиданий заказчиков (требований бизнеса).
Касательно «возможности делать бэкап руками» (т.н. «компенсирующие меры»), смотрите этот мой ответ на другой комментарий.
Да, ранее (до 2013 года) много лет резервное копирование данных считалось «общесистемной функцией», а не средством обеспечения защищенности системы, и на бэкап требования ФСТЭК не распространялись, потому что это не считалось средством защиты. Но приказы ФСТЭК 17, 21 и 31 отнесли бэкап к средствам защиты — для определенных систем и видов информации. Логика приказов состоит в том, что есть системы (например, в МЧС) для которых требуется государственный контроль за резервным копированием этих систем в виду их критичности. Или допустим вирус-шифровальщик зашифрует АСУ ТП на АЭС. Последствия могут быть плачевными, если нет бэкапа. Поэтому средства резервного копирования для определенных случаев были отнесены к средствам защиты, и стали подпадать под требования ФСТЭК к этим системам, что влечет необходимость сертификации в этих оговоренных в законодательстве случаях.
Касательно резервирования или отказоустойчивости самих СЗИ — насколько я знаю, у ФСТЭК нет явных требований к отказоустоячивости СЗИ, поэтому эти механизмы и могут оставаться несертифицированными. Эти механизмы предлагаются производителями не в силу требований ФСТЭК, а в силу ожиданий заказчиков (требований бизнеса).
Касательно «возможности делать бэкап руками» (т.н. «компенсирующие меры»), смотрите этот мой ответ на другой комментарий.
Читал я статью Емельянникова, сразу же как она вышла. Там, как и в любом маркетинговом материале, «необходимость» притянута за уши. Вот вы пишите, что там описана необходимость использовать специализированные средства для бэкапа, но нет, там этого нет. Там написано о том, что согласно законодательству нужно делать резервные копии и обеспечить возможность восстановления из них, а дальше идет манипулятивный и спекулятивный пассаж автора «логично предположить, что...». Но вот какая ерунда получается — Емельянникову логично, а мне и ФСТЭКу не логично. Ибо сколько уже прошло положительных проверок ГИСов 1 и 2 класса, где бэкапы делались руками или даже несертифицированными автоматическими средствами — я затрудняюсь сосчитать.
Похоже пора писать очередное официальное письмо во ФСТЭК за разъяснениями, правда они уже 2 месяца не отвечают на вопросы про аттестацию типовых сегментов, но попробовать думаю стоит.
Похоже пора писать очередное официальное письмо во ФСТЭК за разъяснениями, правда они уже 2 месяца не отвечают на вопросы про аттестацию типовых сегментов, но попробовать думаю стоит.
В методичке к 17 приказу все в принципе расписано. Когда дело касается автоматизации, там применятся пассаж про «свойства» ОИ. В иных случаях просто говориться про выстраивание процессов оргмерами.
Емельяников признанный спец, но тут видно писал чисто под заказ )
Емельяников признанный спец, но тут видно писал чисто под заказ )
Мне кажется, у регулятора (ФСТЭК) вполне понятная логика. СЗИ используются для нейтрализации актуальных угроз. Определяются системы, где сертификация СЗИ обязательна (приказ № 17 п.15.1 «осуществляется выбор средств защиты информации, сертифицированных на соответствие требованиям по безопасности информации, с учетом их стоимости, совместимости с информационными технологиями и техническими средствами, функций безопасности этих средств и особенностей их реализации, а также класса защищенности информационной системы»). Определяются системы, где сертифицированные (прошедшие процедуру оценки соответствия) СЗИ необходимы для нейтрализации актуальных угроз (ст.19 152-ФЗ для ИСПДн). А про СЗИ без сертификатов на аттестованных объектах информатизации я и сам рассказать могу много. И про аттестаты на системы с единственных сертифицированным СЗИ тоже.
C СЗИ-то понятно, раньше могли в техническом задании обосновать использование несертефицированного бэкапера тем, что сертифицированных нет на рынке, сейчас уже будет сложнее, хотя 17 приказ любую меру компенсировать, которую затруднительно выполнить по следующим причинам: высокая стоимость, отсутствие апробированных технических реализаций, неприемлемо большие сроки реализации, отсутствие компетенции для эксплуатации и другие. Сложно, но возможно. Но нас тут пытаются убедить, что мы не можем прописать, что резервирование и восстановление мы делаем руками и тем самым выполняем требования и нейтрализуем угрозы. Я, как уже сказал, не против этого продукта, скорее даже за, пусть будет. А по поводу ручного/автоматического бэкапа все же напишу запрос на разъяснение во ФСТЭК. Мне-то в принципе все равно что ответят, мне главное получить ясность позиции регулятора.
Я много раз сталкивался с тем, что позиция регулятора и надзора может быть очень разной, в зависимости от объекта и целей проверки, мнения конкретного исполнителя и т.д.И з приведенного мною текста, на мой взгляд, однозначно следует, что если угроза утраты целостности и доступности признана актуальной, для ее нейтрализации необходимо использовать сертифицированное СЗИ. Да, про компенсирующие меры и их обоснование в методичке очень много и правильно, но формальный повод для привлечения к административке по части 2 ст.13.12 КоАП существует. Все — на откуп надзору. А запросить разъяснение — это правильно. Только вот нормативного характера оно носить не будет, но это общая беда.
Ну вроде как и вернулись к тому, что как минимум вопрос не такой уж и однозначный =)
Если проверка приходит с целью в итоге наказать, то формальный повод они найдут всегда, как бы прилизано все ни было.
Скан письма с разъяснением всегда можно показать проверяющему, если он пытается продвигать противоположное мнение том, что изложено в письме, подписанном его начальством, обычно действует отрезвляюще.
А так, да — даже у одного и того же сотрудника регулятора может быть сегодня одно мнение, а завтра диаметрально противоположное по одному и тому же вопросу. Это действительно проблема.
Если проверка приходит с целью в итоге наказать, то формальный повод они найдут всегда, как бы прилизано все ни было.
Скан письма с разъяснением всегда можно показать проверяющему, если он пытается продвигать противоположное мнение том, что изложено в письме, подписанном его начальством, обычно действует отрезвляюще.
А так, да — даже у одного и того же сотрудника регулятора может быть сегодня одно мнение, а завтра диаметрально противоположное по одному и тому же вопросу. Это действительно проблема.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сертифицированная ФСТЭК версия Veeam Backup and Replication: резервное копирование конфиденциальной информации