Категорирование субъектов КИИ осуществляется на основе критериев значимости и показателей их значений, а также соблюдением установленного порядка. В решение для безопасности объектов критической информационной инфраструктуры (КИИ) мы объединили продукты Positive Technologies. По нему к субъектам КИИ относятся те организации, которые для страны жизненно важны и потому должны работать при любой ситуации. В январском письме Центральный Банк призвал поднадзорные организации провести повторное категорирование субъектов КИИ и до 31 марта 2023 отчитаться о статусе работ.
Обзор законодательства РФ о критической информационной инфраструктуре
Самих себя субъекты КИИ как владельцы информации, информационных систем или киберфизических систем как-то защищают, причем, скорее всего, вполне адекватно. В КоАП внесена ответственность за предоставление недостоверных сведений о категорировании объектов КИИ, а также утверждены правки в процедуру категорирования объектов КИИ и. В 2022 году многие организации пересмотрели свои ИБ-бюджеты, в том числе субъекты критической информационной инфраструктуры (КИИ).
Новые требования для субъектов КИИ: безопасная разработка прикладного ПО
Субъекты КИИ, разработчики, производители и ответственные ФОИВ должны работать в едином информационном поле. Так как сегодня в достаточно сжатые сроки требуется. До 1 января 2030 г. субъекты критической информационной инфраструктуры (КИИ) обязаны перевести принадлежащие им значимые объекты на доверенные программно-аппаратные. Новые субъекты КИИ, индикаторы риска нарушения требований при обработке ПДн, сертификация МЭ уровня сети и СУБД, импортозамещение в финансовой сфере. Мониторинг перехода субъектов КИИ на преимущественное применение российского ПО предлагается закрепить за Минцифры.
Критическая информационная инфраструктура (КИИ)
Постановление Правительства РФ от 08. Нарушение требований действующего законодательства в области КИИ влечет за собой административную или уголовную ответственность ст. НКЦКИ — это организация, созданная для обеспечения координации деятельности субъектов критической информационной инфраструктуры по вопросам обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты. Одной из мер обеспечения безопасности информации объекта КИИ является обмен информацией о компьютерных инцидентах с Государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации далее — ГосСОПКА , в том числе посредством организации взаимодействия с Национальным координационным центром по компьютерным инцидентам далее — НКЦКИ. Приказы ФСБ России от 24.
Как правило, в информационных системах разработки заводятся тикеты.
По данным тикетам разработчикам ставится в план задача по устранению критических уязвимостей и уязвимостей, имеющих высокий приоритет. Устранив уязвимость, разработчик в комментариях может сделать пометку с идентификатором тикета. Тем самым будет обеспечена прослеживаемость закрытия выявленных уязвимостей. Информирование о выявленных уязвимостях и компенсирующих мероприятиях конечных пользователей. В качестве примера можно привести сообщения на сайтах крупных разработчиков средств защиты информации.
Там публикуются сообщения, в которых дается ссылка на источник скачивания обновлений, указываются идентификаторы уязвимостей, а также даются ссылки на инструкции по устранению уязвимостей и проведению дополнительных мероприятий. Оповещение конечного пользователя об окончании жизненного цикла ПО. К примеру, в специальном разделе сайта разработчика могут быть организованы специальные «фильтры» по продуктам, которые ведут на страницы с планами по поддержке ПО в ходе жизненного цикла. На рис. Рекомендуем закладывать процессы таким образом, чтобы в дальнейшем расширять их до охвата всех необходимых этапов жизненного цикла.
Далее мы рассмотрим проект по внедрению процесса БРПО в соответствии с требованиями регулятора. Когда прикладное ПО разрабатывается силами собственных разработчиков, необходимо внедрить наиболее полный состав процессов безопасности. В случае заказной разработки или использования вендорского ПО необходимо обеспечить наличие всех необходимых свидетельств по процессам безопасности, выстроенным на стороне вендора — производителя ПО, и приобщить их в проектную документацию на ЗО КИИ. Как правило, типовой проект внедрения процессов безопасной разработки ПО разделяется на пять основных этапов. На первом этапе готовится технико-экономическое обоснование для руководства с верхнеуровневыми финансовыми параметрами проекта, основными этапами работ, основными результатами, которые достигаются в ходе проекта, а также персоналом, который требуется привлечь.
Процедура предполагает глубокий анализ всех аспектов деятельности с учетом предусмотренных законом критериев, в числе которых: серьезность последствий хакерской атаки для экологической обстановки, размер ущерба российскому населению и государству в целом при краже данных, влияние на обороноспособность РФ и действие правоохранительной системы. Проинформировать о проведенной категоризации ФСТЭК и добиться добавления сведений в единый Реестр объектов критической инфраструктуры. Исполнять действующие условия эксплуатации КИИ, своевременно корректировать меры безопасности в случае изменения правовых нормативов, в частности, осуществлять переход на отечественное оборудование и ПО. Как обеспечивается информационная безопасность КИИ? Проконсультироваться по поводу того, относится ли ваше предприятие к субъектам КИИ, можно у наших экспертов в сфере информационной безопасности если своими силами это определить не получается.
Следующий этап — сделать так, чтобы критическая информационная инфраструктура функционировала без сбоев, а также была в достаточной степени защищена от внешних и внутренних угроз безопасности. Весь спектр работ можно разделить на: Выделение категорий объектов по степени значимости. Процедура включает формирование комиссии, составление и согласование точного списка исследуемых объектов с последующей отправкой его в ФСТЭК, сбор исходных сведений и изучение угроз ИБ.
Закупить такое ПО можно лишь после согласования с профильным ведомством. В полном объёме мера вступит в силу в 2025 году.
Что такое критическая информационная инфраструктура?
Кто же такие субъекты КИИ? Что важно делать всем субъектам КИИ, и кто такие субъекты вообще. До 1 января 2030 г. субъекты критической информационной инфраструктуры (КИИ) обязаны перевести принадлежащие им значимые объекты на доверенные программно-аппаратные. Таким образом, закон предусматривает два вида субъектов КИИ — владельцы объектов КИИ и координаторы взаимодействия этих объектов. Категорирование субъектов КИИ осуществляется на основе критериев значимости и показателей их значений, а также соблюдением установленного порядка. Докладчик: Алексей КомаровВторой вебинар из серии: "Безопасность КИИ и требования 187-ФЗ"Темы: Главные определения, их смысловое наполнение, практические нюа.
Владельцы социально значимых объектов КИИ будут использовать ПАК
Субъектами КИИ являются государственные органы, а также госучреждения, российские юридические лица или индивидуальные предприниматели. Планы перехода субъектов КИИ на доверенные программно-аппаратные комплексы к следующему сентябрю уже должны быть утверждены. Итак, мы с вами разобрались, что такое КИИ и кого мы можем называть субъектом критической информационной инфраструктурой.
Обзор Постановления Правительства Российской Федерации от 14.11.2023 № 1912
Постановление Правительства РФ от 14. Подтверждением отсутствия произведенных в РФ доверенных программно-аппаратных комплексов, являющихся аналогами приобретенных, являются заключения, выданные Минпромторгом России Определен перечень федеральных органов исполнительной власти и российских юридических лиц, ответственных за организацию перехода субъектов КИИ на принадлежащих им значимых объектах на преимущественное применение доверенных программно-аппаратных комплексов в соответствующих сферах областях деятельности.
Пока что выходом является комбинирование нескольких продуктов для обеспечения компании необходимым функционалом. Альтернативной этому решению является использование отечественного стека совместимых продуктов от нескольких российских поставщиков. Также, переход на новое программное обеспечение требует времени. Тестирование нового решения обычно занимает от полугода до года, но перевод мощностей осуществляется постепенно и может длиться более пяти лет.
Наконец, еще одна причина медленных темпов миграции — недоверие к отечественным технологиям. В мышление российских предпринимателей и потребителей вросла установка «западное происхождение товара — гарант качества», в то время как российские продукты воспринимаются как нечто сделанное наспех, не функциональное и не надежное. Зато теперь, когда государство говорит о том, что пора делать то же самое, но с отечественными решениями — осуществлять внедрение, получать обратную связь от заказчика для доработки продукта и т. Как бы то ни было, теперь миграции не избежать. Нужно подобрать отечественные технологии и начинать тестирование как можно скорее.
Также до 1 января 2025 года в рамках 166 Указа президента все прикладное ПО на значимых объектах КИИ должно быть импортозамещено. Для примера приведем требования по безопасности прикладного ПО из различных отраслевых нормативных документов, для финансовой отрасли данные требования устанавливаются Положениями ЦБ РФ, а также национальными стандартами п. Подходы к внедрению процессов БРПО Рассматривая существующие подходы к внедрению процессов безопасной разработки ПО БРПО , можно выделить три основных направления: отечественная регуляторика, гармонизированные международные стандарты, международные стандарты и практики. В ней приводятся типовые действия в ходе подготовки и реализации меры, а также возможное распределение ролей и обязанностей участников. То есть мероприятия, которые должен формально провести оценщик для того, чтобы удостовериться, что требования стандарта 56939 выполняются. Описывать отдельно следующие три книги мы в рамках данной статьи не будем, скажем лишь кратко, что они содержат требования к методикам и инструментам, реализующим конкретные меры, в том числе требования к процессу проведения статического и динамического анализов кода.
Разработка документа «Руководства по безопасной разработке ПО». Данное руководство, помимо общих организационных моментов, касающихся области действия, определения целей, распределения ролей, должно включать указания на все процедуры безопасной разработки. Анализ и моделирование угроз информационной безопасности. На данном этапе происходит моделирование тех угроз, которые рабочая группа специалистов выявляет в предположении на каждом этапе жизненного цикла и разрабатывает компенсирующие мероприятия, которые затем отражаются на архитектуре разрабатываемого проекта ПО. Обеспечение прослеживаемости. Суть процесса заключается в том, чтобы функциональную спецификацию ПО можно было проследить до конкретных блоков функций, которые их реализуют.
Это упрощает контроль недекларированных возможностей в ходе реализации проекта ПО и внесения в него изменений. Статический анализ кода без его исполнения. Это уже техническая мера, и она требует внедрения специального инструмента — статического анализатора кода. По результатам анализа нескольких проверок безопасности статическим анализатором проекта ПО необходимо провести так называемую «разметку»: сопоставить выявленные ошибки и предупреждения с тем, являются ли они на самом деле недостатками ПО.
Структура процессов по КИИ. Рекомендуемый формат описание Процесса. Соотнесение Процессов и нормативных требований. НДС не облагается Онлайн участие —14 700 руб. НДС не облагается У вас появились вопросы?