Проект изменений в 31 приказ ФСТЭК России (ЗИ в АСУ ТП). - Выявление и оперативное устранение уязвимостей Astra Linux производится разработчиком в соответствии с «Требованиями к уровням доверия», утвержденным приказом ФСТЭК России №76, и ГОСТ Р 56939. Приказом ФСТЭК России № 44 от 07.03.2023 утверждены "Требования по безопасности информации к многофункциональным межсетевым экранам уровня сети".
ДОКУМЕНТЫ ФСТЭК РОССИИ
С утверждением приказа ФСТЭК России № 31 мероприятия по защите информации в АСУ ТП стали носить обязательный характер. РИА Новости: Подозрительную радиостанцию из леса в Пушкино изъяли для проверки. Согласно требованиям приказа ФСТЭК России №131 SafeERP будет проходить сертификацию как СЗИ 5-го уровня доверия.
Приказ ФСТЭК России от 14.03.2014 № 31
В таблице № 1 представлено описание выполнения базового набора мер 31-го приказа ФСТЭК по защите информации в автоматизированной системе управления путем применения ПАК СЗИ НСД «Центр-Т». Главные выдержки из Приказа ФСТЭК от 14 марта 2014 г. N 31: 1. Цель документа: утвердить требования к обеспечению защиты информации в АСУТП на критически важных объектах, потенциально опасных объектах, а также объектах. Содержание мер и правила их реализации устанавливаются методическим документом, разработанным ФСТЭК России в соответствии с пунктом 5 и подпунктом 4 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю. 3. Контроль за исполнением настоящего приказа возложить на первого заместителя директора ФСТЭК России С.Ф. Якимова.
Новости нормативки по ИБ. Сентябрь — октябрь 2023 года
Этап внедрения системы защиты информации включает следующие мероприятия: настройку ПО АСУ ТП; проведение предварительных испытаний, опытной эксплуатации и приемочных испытаний системы; анализ уязвимостей АСУ ТП, в рамках которого по решению заказчика может проводиться тестирование на проникновение; разработку документов, определяющих правила и процедуры, реализуемые для защиты информации. В этом случае, аттестация системы защиты информации проводится в соответствии с национальными стандартами и методическим документами ФСТЭК России с оформлением соответствующих программ и методик аттестационных испытаний, протоколов и заключений. Этапы обеспечения защиты информации в ходе эксплуатации системы защиты и при выводе ее из действия предусматривают реализацию определенных процедур управления информационной безопасностью, таких как: планирование мероприятий по обеспечению защиты в автоматизированных системах управления производственными и технологическими процессами; обеспечение действий в нештатных ситуациях; обучение персонала; выявление инцидентов в ходе эксплуатации и реагирование на них; контроль за обеспечением уровня защищенности; управление системой защиты, а также управление конфигурацией автоматизированных систем управления производственными и технологическими процессами; архивирование информации, а также уничтожение данных и остаточной информации при выводе автоматизированных систем управления производственными и технологическими процессами из эксплуатации. Состав мер защиты информации, описанных в документе, приведен в таблице Таблица 1. Каждая группы мер защиты включает требование по обязательному документированию соответствующей процедуры управления информационной безопасности. Таблица 1 — Наборы мер защиты информации Условное обозначение.
Общие требования» можно обеспечить реализацию и проведение мер по разработке безопасного программного обеспечения непосредственно в процессах его жизненного цикла. Целесообразно проводить исследования по выявлению уязвимостей и НДВ: при выполнении проектирования и разработки ПО этап разработки ; при выполнении квалификационного тестирования ПО этап тестирования ; при выполнении инсталляции программы и поддержки приемки ПО этап реализации и эксплуатации. Одним из способов упростить и автоматизировать проведение таких исследований является применение СЗИ для анализа кода.
Необходимо отметить важность проверки программного кода, содержащегося в транспортных запросах, при переносе данных по ландшафту системы от этапа к этапу. В таком варианте исследований применение СЗИ позволит снизить процент небезопасных конструкций в коде к моменту эксплуатации программного обеспечения, провести работы по выявлению уязвимостей и НДВ без выгрузки и передачи исходного кода на исследования третьей стороне. При этом средства защиты информации могут быть интегрированы в систему разработки.
Единственное утешение для владельцев таких АСУ ТП будет только отсутствие риска уголовного преследования по ст. УК РФ. Присвоите вы категорию значимости КИИ или примете решение о "незначимости" - это никак не повлияет на необходимость выполнять меры безопасности от ФСТЭК. Будете 239 приказ выполнять или 31, а наборы мер в них одинаковые..
Репетиция «плана спасения» важна также для понимания сотрудниками своей роли в процессах управления инцидентами безопасности. Код в программном обеспечении АСУ ТП зачастую просто ужасен, а на большинстве критически значимых предприятий можно обнаружить уязвимости 10—15-летней давности. Обновления часто не устанавливаются в принципе, что обусловлено множеством факторов, начиная от непрерывности технологического процесса и заканчивая неосведомленностью сотрудников об угрозах. Поэтому наилучшее решение — принимать всевозможные меры для исправления ошибок в АСУ ТП на этапе разработки. Подобные требования практически не отражены в зарубежных стандартах, что еще раз говорит в пользу авторов российского документа. Их наличие означает формирование защиты на основании характерных для системы рисков: это позволяет учитывать новые угрозы и улучшать процессы обеспечения ИБ. Что хотелось бы увидеть Скорейшее появление детальных рекомендаций и методических указаний для специалистов ИБ и аудиторов. Требование о необходимости сегментирования ЛВС в приказе присутствует ЗИС-17 , однако в соответствующем методическом документе наилучшим решением будет явно отметить необходимость отделения технологических сетей от корпоративных.
Новости нормативки по ИБ. Сентябрь — октябрь 2023 года
Проверка выполнения юридическим лицом или индивидуальным предпринимателем требований технических регламентов. Добровольная сертификация Добровольное подтверждение соответствия может осуществляться для установления соответствия национальным стандартам, предварительным национальным стандартам, стандартам организаций, сводам правил, системам добровольной сертификации, условиям договоров. При этом добровольное подтверждение соответствия осуществляется по инициативе заявителя на условиях договора между ним и органом по сертификации, который осуществляет подтверждение соответствия. Например, есть отраслевые системы добровольной сертификации, подтверждающие соответствие СрЗИ стандартам организации данной отрасли.
Формирование требований к защите информации в автоматизированной системе управления 13. Формирование требований к защите информации в автоматизированной системе управления осуществляется заказчиком. Формирование требований к защите информации в автоматизированной системе управления осуществляется с учетом ГОСТ Р 51583 "Защита информации. Порядок создания автоматизированных систем в защищенном исполнении.
Автоматизированные системы в защищенном исполнении. Общие требования" далее - ГОСТ Р 51624 и стандартов организации и в том числе включает: принятие решения о необходимости защиты информации в автоматизированной системе управления; классификацию автоматизированной системы управления по требованиям защиты информации далее - классификация автоматизированной системы управления ; определение угроз безопасности информации, реализация которых может привести к нарушению штатного режима функционирования автоматизированной системы управления, и разработку на их основе модели угроз безопасности информации; определение требований к системе защиты автоматизированной системы управления. При принятии решения о необходимости защиты информации в автоматизированной системе управления осуществляются: анализ целей создания автоматизированной системы управления и задач, решаемых этой автоматизированной системой управления; определение информации, нарушение доступности, целостности или конфиденциальности которой может привести к нарушению штатного режима функционирования автоматизированной системы управления определение критически важной информации , и оценка возможных последствий такого нарушения; анализ нормативных правовых актов, локальных правовых актов, методических документов, национальных стандартов и стандартов организаций, которым должна соответствовать автоматизированная система управления; принятие решения о необходимости создания системы защиты автоматизированной системы управления и определение целей и задач защиты информации в автоматизированной системе управления. Классификация автоматизированной системы управления проводится заказчиком или оператором в зависимости от уровня значимости критичности информации, обработка которой осуществляется в автоматизированной системе управления. Устанавливаются три класса защищенности автоматизированной системы управления, определяющие уровни защищенности автоматизированной системы управления. Самый низкий класс - третий, самый высокий - первый. Класс защищенности автоматизированной системы управления определяется в соответствии с приложением N 1 к настоящим Требованиям.
Класс защищенности может быть установлен отдельно для каждого из уровней автоматизированной системы управления или иных сегментов при их наличии. Результаты классификации автоматизированной системы управления оформляются актом классификации. Требование к классу защищенности включается в техническое задание на создание автоматизированной системы управления и или техническое задание частное техническое задание на создание системы защиты автоматизированной системы управления, разрабатываемые с учетом ГОСТ 34. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" далее - ГОСТ 34. Класс защищенности автоматизированной системы управления сегмента подлежит пересмотру только в случае ее модернизации, в результате которой изменился уровень значимости критичности информации, обрабатываемой в автоматизированной системе управления сегменте. Определение угроз безопасности информации осуществляется на каждом из уровней автоматизированной системы управления и должно включать: а выявление источников угроз безопасности информации и оценку возможностей потенциала внешних и внутренних нарушителей; б анализ возможных уязвимостей автоматизированной системы и входящих в ее состав программных и программно-аппаратных средств; в определение возможных способов сценариев реализации возникновения угроз безопасности информации; г оценку возможных последствий от реализации возникновения угроз безопасности информации, нарушения отдельных свойств безопасности информации целостности, доступности, конфиденциальности и автоматизированной системы управления в целом.
В качестве исходных данных при определении угроз безопасности информации используется банк данных угроз безопасности информации, ведение которого осуществляется ФСТЭК России в соответствии с подпунктом 21 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю, утвержденного Указом Президента Российской Федерации от 16 августа 2004 г. N 1085 Собрание законодательства Российской Федерации, 2004, N 34, ст. При определении угроз безопасности информации учитываются структурно-функциональные характеристики автоматизированной системы управления, включающие наличие уровней сегментов автоматизированной системы управления, состав автоматизированной системы управления, физические, логические, функциональные и технологические взаимосвязи в автоматизированной системе управления, взаимодействие с иными автоматизированными информационными системами и информационно-телекоммуникационными сетями, режимы функционирования автоматизированной системы управления, а также иные особенности ее построения и функционирования. По результатам определения угроз безопасности информации могут разрабатываться рекомендации по корректировке структурно-функциональных характеристик автоматизированной системы управления, направленные на блокирование нейтрализацию отдельных угроз безопасности информации. Требования к системе защиты автоматизированной системы управления определяются в зависимости от класса защищенности автоматизированной системы управления и угроз безопасности информации, включенных в модель угроз безопасности информации. Требования к системе защиты автоматизированной системы управления включаются в техническое задание на создание модернизацию автоматизированной системы управления и или техническое задание частное техническое задание на создание системы защиты автоматизированной системы управления, разрабатываемые с учетом ГОСТ 34. Методы и средства обеспечения безопасности.
Системы менеджмента информационной безопасности. Требования", а также политик обеспечения информационной безопасности оператора в части, не противоречащей политикам заказчика.
Устанавливаются три класса защищенности автоматизированной системы управления. Самый низкий класс - третий, самый высокий - первый. Класс защищенности автоматизированной системы управления определяется в соответствии с уровнем значимости критичности информации. Определение угроз безопасности информации осуществляется на каждом из уровней автоматизированной системы управления и должно включать: выявление источников угроз безопасности информации и оценку возможностей потенциала внешних и внутренних нарушителей; анализ возможных уязвимостей автоматизированной системы и входящих в ее состав программных и программно-аппаратных средств; определение возможных способов сценариев реализации возникновения угроз безопасности информации; оценку возможных последствий от реализации возникновения угроз безопасности информации, нарушения отдельных свойств безопасности информации целостности, доступности, конфиденциальности и автоматизированной системы управления в целом. При проектировании системы защиты автоматизированной системы управления должны учитываться особенности функционирования программного обеспечения и технических средств на каждом из уровней этой системы.
Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды : приказ ФСТЭК России от 14 марта 2014 г. Базовая модель угроз безопасности информации в ключевых системах информационной инфраструктуры : утв. Методика определения актуальных угроз безопасности информации в ключевых системах информационной инфраструктуры : утв.
Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры : утв. Рекомендации по обеспечению безопасности информации в ключевых системах информационной инфраструктуры : утв. Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах : приказ ФСТЭК России от 11 фев.
Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных : приказ ФСТЭК России от 18 фев. О классификации чрезвычайных ситуаций природного и техногенного характера : постановление Правительства Российской Федерации от 21 мая 2007 г.
Публикации
- Читайте также:
- Кодексы РФ
- Приказ ФСТЭК № 31 - Контроль соответствия
- Популярные материалы
- Оценка соответствия СрЗИ согласно Приказу ФСТЭК №31 | ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ
- Популярные материалы
Изменения в НПА по информационной безопасности
Приказ ФСТЭК России N 31 от 14 марта 2014 «Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах. приказа ФСТЭК №31. Утверждена приказом ФСТЭК России от 19 февраля 2018 г. N 31.
ДОКУМЕНТЫ ФСТЭК РОССИИ
приказа ФСТЭК №31. ФЕДЕРАЛЬНАЯ СЛУЖБА ПО ТЕХНИЧЕСКОМУ И ЭКСПОРТНОМУ КОНТРОЛЮ ПРИКАЗ от 14 марта 2014 года № 31 Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и. Приказ ФСТЭК России от 11.02.2013 N 17 "Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах" (Зарегистрировано в Минюсте России 31.05.2013 N 28608). Описание на русском: Приказ ФСТЭК России № 31 от 14.03.2014 (ред. от 15.03.2021) 'Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на. Главная» Новости» Фстэк новости.
Приказ ФСТЭК России от 14.03.2014 № 31
Может проводиться в соответствии с ГОСТ 34. Получается, что использовать сертифицированные СрЗИ добровольная, обязательная сертификация гораздо проще, чем СрЗИ, прошедшие оценку соответствия в какой-либо другой форме. И причины, как нам кажется, следующие: —отсутствие четкого толкования условий и результата проведения оценки соответствия в других формах; —устоявшаяся практика применения сертифицированных СрЗИ «чтобы регулятор не придирался» ; —отсутствие практики применения СрЗИ, прошедших оценку соответствия в других формах следствие из предыдущего пункта. Услуги Аудит информационной безопасности Аудит информационной безопасности — это процесс получения объективных оценок о текущем состоянии защищенности информационных ресурсов компании в соответствии с российскими и международными нормативами.
В этом списке КСИИ могли, оказаться и банки, и любые другие организации, но при этом не учитывались особенности применения АСУ ТП как систем реального времени, а также тенденции развития IТ-инфраструктур к примеру, работа в визуализированных средах. Часто российское нормотворчество упрекают в том, что оно оторвано от передового международного опыта и не соответствует последним тенденциям. Это важные меры: любой процесс обеспечения безопасности, причем не только информационной, начинают строить с тщательного документирования всех процедур. Регулярный чекинг можно сравнить с предполетным осмотром самолета и проверкой бортового журнала, и звучит все это скучновато для пассажира лишь до тех пор, пока пассажир не поднялся на высоту 10 тысяч метров. Требования к защите среды виртуализации ЗСВ.
Технологии виртуализации позволяют оптимизировать ресурсы, однако порождают новые угрозы. Понятно, что снижение издержек интереснее борьбы за безопасность, поэтому критически важные системы в целом и АСУ ТП в частности очень быстро оказываются в не совсем безопасных облаках, и этот процесс необходимо как-то контролировать. Обучение и отработка действий пользователей в случае возникновения нештатных непредвиденных ситуаций ДНС.
Ответственный за ИБ промышленных систем автоматизации должен относиться к подразделению ИБ и обладать компетенциями в сфере автоматизации. Стоит учитывать также зарубежный опыт в данном вопросе: самым подходящим решением является создание по примеру NIST SP 800-82 [12] межфункциональной команды кибербезопасности, обеспечивающей плотное взаимодействие этих направлений. Об утверждении требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды : приказ ФСТЭК России от 14 марта 2014 г. Базовая модель угроз безопасности информации в ключевых системах информационной инфраструктуры : утв. Методика определения актуальных угроз безопасности информации в ключевых системах информационной инфраструктуры : утв.
Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры : утв. Рекомендации по обеспечению безопасности информации в ключевых системах информационной инфраструктуры : утв. Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах : приказ ФСТЭК России от 11 фев.
Сам стандарт очень удобно использовать для формирования должностных обязанностей специалистов по ИБ разных направлений, в том числе перечисленных мной двумя абзацами выше. Порядок этих действий в общих чертах такой: при выявлении инцидента ИБ кредитная организация направляет уведомление по форме и в порядке Банка России и одновременно по форме и в порядке НКЦКИ. Если инцидент привел к утечке персональных данных, НКЦКИ надо дополнительно уведомить по еще одной форме в еще одном порядке ; кредитной организации рекомендуется сохранить следы компрометации. Например, образы оперативки, скомпрометированных жестких дисков, информацию о сетевой активности во время и до атаки; эти следы следует проанализировать в порядке, приведенном в стандарте Банка России СТО БР ИББС-1. Сбор и анализ технических данных при реагировании на инциденты информационной безопасности при осуществлении переводов денежных средств»; если инцидент ИБ привел к каким-то потерям, масштаб трагедии определяется в соответствии с пунктами 7. Как видим, у Банка России имеется инструкция для кредитно-финансовых организаций на любой случай жизни, что, с моей точки зрения, похвально. Некоторые меня критикуют за то, что я не критикую регуляторов по ИБ, как это принято в нашем комьюнити: «А ты не на зарплате у них?
Я и дальше буду искать и находить плюсы в плодах работы наших регуляторов по ИБ — слава богу, их достаточно! Чего и вам желаю: искать и находить, а также достаточного количества плодов и плюсов.
ДОКУМЕНТЫ ФСТЭК РОССИИ
Чтобы поверить это предположение, мы сравнили требования приказа ФСТЭК № 31 с ведущими зарубежными стандартами в области систем промышленной автоматизации, а именно. Приказ ФСТЭК России от 01.06.2023 №106 признает утратившими силу административные регламенты по контролю за соблюдением лицензионных требований при осуществлении деятельности по технической защите конфиденциальной. Обзор приказа ФСТЭК №31 | Будьте в курсе актуальных новостей в области информационных технологий и кибербезопасности. используемых Федеральной службой по техническому и экспортному контролю в процессе лицензирования деятельности по технической защите конфиденциальной информации, и признании утратившими силу приказа ФСТЭК России от 17 июля 2017 г. Главная» Новости» Фстэк новости. Приказом ФСТЭК России № 44 от 07.03.2023 утверждены "Требования по безопасности информации к многофункциональным межсетевым экранам уровня сети".
В следующем номере
- Приказ ФСТЭК России от 19.02.2018 N 31
- В следующем номере
- Жизнь 80 на 20: Инфосообщение ФСТЭК про Приказ №31
- Приказ ФСТЭК от 14 марта 2014 г. N 31