Модель угроз безопасности по 17 приказу фстэк


ФСТЭК пояснила, как следует согласовывать модели угроз безопасности информации при создании государственных IT-систем

кибербезопасность безопасность защита замок

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

Постановлением правительства Российской Федерации от 11 мая 2017 г. N 555 внесены изменения в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации, утверждённые постановлением правительства Российской Федерации от 6 июля 2015 г. N 676.

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

Ведомство поясняет, что рассмотрение документов на создание федеральных информационных систем осуществляется центральным аппаратом ФСТЭК России, региональных систем – управлениями ФСТЭК России по федеральным округам.

Срок рассмотрения проектов составляет не более 30 дней.

Правовую основу при рассмотрении и согласовании проектов моделей угроз безопасности информации и технических заданий на создание государственных информационных систем составляют:

  • Федеральный закон от 27 июля 2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите информации»;
  • Федеральный закон от 27 июля 2006 г. N 152-ФЗ «О персональных данных»;
  • Требования к защите персональных данных при их обработке в информационных системах персональных данных, утвержденные постановлением Правительства Российской Федерации от 1 ноября 2012 г. N 1119;
  • Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденные приказом ФСТЭК России от 11 февраля 2013 г. N 17;
  • Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных, утвержденные приказом ФСТЭК России от 18 февраля 2013 г. N 21.

Минкомсвязь подготовила изменения в требования к жизненному циклу государственных информационных систем

Кроме того, при рассмотрении и согласовании моделей угроз безопасности информации и технических заданий на создание государственных информационных систем будут учитываться методические документы ФСТЭК России и национальные стандарты в области защиты информации, национальные стандарты, регламентирующие вопросы создания автоматизированных систем, а также сведения, содержащиеся в банке данных угроз безопасности информации (www.bdu.fstec.ru), сообщило ведомство.

Изменения, внесенные постановлением правительства от 11 мая 2017 г. № 555 в требования к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации

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

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

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

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

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

Напомним, на конференции OS DAY, прошедшей в Москве в мае, заместитель директора Федеральной службы по техническому и экспортному контролю России Виталий Лютиков отмечал необходимость дожидаться устранения уязвимостей в программных продуктах иностранными разработчиками. В этом ФСТЭК видит проблему обеспечения безопасности информации российских государственных организаций. Представитель ФСТЭК сообщил также, что отечественные поставщики программных продуктов, бывает, пытаются заставить заказчика заплатить за установку патчей, блокирующих уязвимости. Такая практика неприемлема, и ФСТЭК намерен её пресекать, фиксируя обязанность поставщика обновлять программные продукты для устранения уязвимостей – такое требование, по словам Лютикова, должно содержаться в техническом задании на поставку программных продуктов.

ЗПДн. ПП 1119, Приказ ФСТЭК №21 и Модель угроз

Попробую привести порядок построения Модели Угроз (далее МУ), в соответствии с требованиями Постановления Правительства от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» и требованиями Приказа ФСТЭК от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».

При составлении МУ буду опираться на действующие в настоящий момент нормативные и правовые акты, а также рекомендации регуляторов.

Общая блок-схема построения МУ представлена на Рисунке 1.

 Рисунок 1

          1. В соответствии с требованиями ПП № 1119 – определяем уровень защищенности исследуемой ИСПДн (по Таблице, представленной на Рисунке 2.)

Рисунок 2

Что касается типа угроз, который мы будем рассматривать в качестве актуального - в соответствии со ст. 7 ПП №1119 «Определение типа угроз безопасности персональных данных, актуальных для информационной системы, производится оператором с учетом оценки возможного вреда…», включив «фантазию» и «экспертный подход» - можем попробовать снизить планку рассматриваемых угроз до 2-го или 3-го типа (правда все это будет профанацией... но тут уж как сможете обосновать). Если оценивать объективно - кроме как применять СПО, имеющее сертификаты ФСТЭК на отсутствие НДВ, другого легального способа уйти от угроз 1-го типа, не вижу....

После определения уровня защищенности рассматриваемой нами ИС – переходим непосредственно к определению перечня угроз безопасности персональных данных (УБПДн). 2. Формируем список возможных УБПДн, которые могут быть нейтрализованы требованиями из Приказа ФСТЭК №21, а также добавляем в перечень угрозы, связанные с использованием в ИС «новых информационных технологий» и для которых не определены меры обеспечения их безопасности в Приказе ФСТЭК №21 (Рисунок №3).

Рисунок 3

3. По итогу сопоставления «Требование/Мера Приказа ФСТЭК №21» и «Возможных угроз» мы можем сформировать итоговый перечень угроз безопасности ПДн, который и будем рассматривать далее.

4. К сформированному перечню возможных УБПДн применяем «Методику определения актуальных угроз безопасности ПДн при их обработке в ИСПДн» ФСТЭК (Рисунок 4.)

Рисунок 4

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

Рисунок 5

Поверхностный обзор 17 приказа ФСТЭК

Один из главных регламентирующих документов по защите информации. Применяется к Государственным и Муниципальным информационным системам, также может применяться к любым информационным системам, по желанию их владельцев. Выписал наиболее интересные пункты, остальное интуитивно понятно. Но при внедрении любой системы защиты информации рекомендую почитать. Да и для общего развития полезно будет. Официальщина читается жутко, конечно.
  • 4 Лицо, обрабатывающее информацию, являющуюся государственным информационным ресурсом, по поручению обладателя информации (заказчика) или оператора и (или) предоставляющее им вычислительные ресурсы (мощности) для обработки информации на основании заключенного договора (далее – уполномоченное лицо), обеспечивает защиту информации в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации. В договоре должна быть предусмотрена обязанность уполномоченного лица обеспечивать защиту информации, являющейся государственным информационным ресурсом, в соответствии с настоящими Требованиями.
  • 10 Для проведения работ по защите информации в ходе создания и эксплуатации информационной системы обладателем информации (заказчиком) и оператором в соответствии с законодательством Российской Федерации при необходимости привлекаются организации, имеющие лицензию на деятельность по технической защите конфиденциальной информации в соответствии с Федеральным законом от 4 мая 2011 г. N 99-ФЗ «О лицензировании отдельных видов деятельности» (Собрание законодательства Российской Федерации, 2011, N 19, ст. 2716; N 30, ст. 4590; N 43, ст. 5971; N 48, ст. 6728; 2012, N 26, ст. 3446; N 31, ст. 4322; 2013, N 9, ст. 874).
  • 11  Для обеспечения защиты информации, содержащейся в информационной системе, применяются средства защиты информации, прошедшие оценку соответствия в форме обязательной сертификации на соответствие требованиям по безопасности информации в соответствии со статьей 5 Федерального закона от 27 декабря 2002 г. N 184-ФЗ «О техническом регулировании» (Собрание законодательства Российской Федерации, 2002, N 52, ст. 5140; 2007, N 19, ст. 2293; N 49, ст. 6070; 2008, N 30, ст. 3616; 2009, N 29, ст. 3626; N 48, ст. 5711; 2010, N 1, ст. 6; 2011, N 30, ст. 4603; N 49, ст. 7025; N 50, ст. 7351; 2012, N 31, ст. 4322; 2012, N 50, ст. 6959).
  • 14. Формирование требований к защите информации, содержащейся в информационной системе, осуществляется с учетом ГОСТ Р 51583 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения» и ГОСТ Р 51624 «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования»
  • 14.2 Класс защищенности определяется для информационной системы в целом и, при необходимости, для ее отдельных сегментов (составных частей). Требование к классу защищенности включается в техническое задание на создание информационной системы и (или) техническое задание (частное техническое задание) на создание системы защиты информации информационной системы, разрабатываемые с учетом ГОСТ 34.602 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» (далее – ГОСТ 34.602), ГОСТ Р 51583 и ГОСТ Р 51624.
  • 14.3 Для определения угроз безопасности информации и разработки модели угроз безопасности информации применяются методические документы, разработанные и утвержденные ФСТЭК России в соответствии с подпунктом 4 пункта 8 Положения о Федеральной службе по техническому и экспортному контролю, утвержденного Указом Президента Российской Федерации от 16 августа 2004 г. N 1085 (Собрание законодательства Российской Федерации, 2004, N 34, ст. 3541; 2006, N 49, ст. 5192; 2008, N 43, ст. 4921; N 47, ст. 5431; 2012, N 7, ст. 818).
  • 14.4 При определении требований к системе защиты информации информационной системы учитываются положения политик обеспечения информационной безопасности обладателя информации (заказчика) в случае их разработки по ГОСТ Р ИСО/МЭК 27001 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования», а также политик обеспечения информационной безопасности оператора и уполномоченного лица в части, не противоречащей политикам обладателя информации (заказчика).
  • 15 Разработка системы защиты информации информационной системы осуществляется в соответствии с техническим заданием на создание информационной системы и (или) техническим заданием (частным техническим заданием) на создание системы защиты информации информационной системы с учетом ГОСТ 34.601 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» (далее – ГОСТ 34.601), ГОСТ Р 51583 и ГОСТ Р 51624
  • 15.1 Результаты проектирования системы защиты информации информационной системы отражаются в проектной документации (эскизном (техническом) проекте и (или) в рабочей документации) на информационную систему (систему защиты информации информационной системы), разрабатываемых с учетом ГОСТ 34.201 «Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем» (далее – ГОСТ 34.201).
  • 16 К внедрению системы защиты информации информационной системы привлекается оператор информационной системы в случае, если он определен таковым в соответствии с законодательством Российской Федерации к моменту внедрения системы защиты информации информационной системы и не является заказчиком данной информационной системы.
  • 16.4. Предварительные испытания системы защиты информации информационной системы проводятся с учетом ГОСТ 34.603 «Информационная технология. Виды испытаний автоматизированных систем» (далее – ГОСТ 34.603) и включают проверку работоспособности системы защиты информации информационной системы, а также принятие решения о возможности опытной эксплуатации системы защиты информации информационной системы.
  • 20. Организационные и технические меры защиты информации, реализуемые в информационной системе в рамках ее системы защиты информации, в зависимости от угроз безопасности информации, используемых информационных технологий и структурно-функциональных характеристик информационной системы должны обеспечивать:

    идентификацию и аутентификацию субъектов доступа и объектов доступа;

    управление доступом субъектов доступа к объектам доступа;

    ограничение программной среды;

    защиту машинных носителей информации;

    регистрацию событий безопасности;

    антивирусную защиту;

    обнаружение (предотвращение) вторжений;

    контроль (анализ) защищенности информации;

    целостность информационной системы и информации;

    доступность информации;

    защиту среды виртуализации;

    защиту технических средств;

    защиту информационной системы, ее средств, систем связи и передачи данных.

  • 25. Выбранные и реализованные в информационной системе в рамках ее системы защиты информации меры защиты информации должны обеспечивать:

    в информационных системах 1 класса защищенности – нейтрализацию (блокирование) угроз безопасности информации, связанных с действиями нарушителя с высоким потенциалом; в информационных системах 2 класса защищенности – нейтрализацию (блокирование) угроз безопасности информации, связанных с действиями нарушителя с потенциалом не ниже среднего;

    в информационных системах 3 и 4 классов защищенности – нейтрализацию (блокирование) угроз безопасности информации, связанных с действиями нарушителя с низким потенциалом. Потенциал нарушителя определяется в ходе оценки его возможностей, проводимой при определении угроз безопасности информации в соответствии с пунктом 14.3 настоящих

    Требований.

И самое интересное содержится в приложениях к приказу! 

Почему отсутствие новой методики моделирования угроз от ФСТЭК это проблема?

Весной (уже далекого) 2015 года для общего доступа был опубликован проект новой методики определения угроз безопасности информации в информационных системах. Уже тогда многие специалисты обрадовались факту разработки ФСТЭКом такого документа, потому что даже 2 года назад было понятно, что старая связка документов «Методика определения…» и «Базовая модель угроз…» мягко говоря, слегка устарели. Но, несмотря на то, что на дворе уже июнь 2017-го, новая методика так и не утверждена и не опубликована. И это является серьезной проблемой, дальше попробую объяснить почему.

Сначала рассмотрим, что же не так со старой методикой.

Для определения актуальности/неактуальности для каждой угрозы нужно определить ряд параметров. Одни из них являются глобальными (одинаковые для разных угроз), другие – локальными (варьируются от угрозы к угрозе). Одним из таких глобальных параметров является коэффициент исходной защищенности (Y1). Определяется этот парень следующим образом: у нас есть семь технических и эксплуатационных характеристик информационной системы, для каждой из них есть несколько вариантов, из которых нужно выбрать только один. Выбранный вариант ответа соответствует низкому, среднему или высокому уровню защищенности. Далее мы подсчитываем количество «плюсиков» для низкого, среднего и высокого уровней защищенности и по методике определяем общий уровень исходной защищенности информационной системы. Начало этой таблицы выглядит так:

И уже по первой характеристике можно впасть в ступор в определенных ситуациях. Например, у нас есть организация с информационной системой, у которой есть филиалы в пределах города (или в других городах – тут это даже не суть важно), нам нужно выбрать вариант «распределенная» («городская») или «корпоративная распределенная»? Вроде подходит и то и другое, но уровень защищенности для распределенной и корпоративной распределенной – разный. А если у нас есть сотрудник с ноутбуком, который через VPN работает с базой данных? Вроде он обычно находится в пределах города, а если уедет за город? Какой вариант выбирать?

В общем, я думаю понятно, что данная таблица несколько устарела. С другими шестью характеристиками не легче. Кстати, в проекте новой методики есть нечто похожее и там уже учтены такие вещи как мобильные устройства, беспроводные каналы связи и т.д.

Другая проблема заключается в том, что старая методика привязана к информационным системам персональных данных. Так, например, одним из важнейших параметров, определяющих в итоге актуальность или неактуальность угрозы, является «опасность угрозы». Этот параметр напрямую привязан к возможному ущербу субъекту персональных данных в случае реализации угрозы. Окей, что же нам делать, если у нас государственная информационная система без персональных данных? Можно конечно привязаться к уровням значимости информации из классификации ГИС, но это костыли. А что делать, если система, для которой разрабатывается модель угроз, не классифицирована как ГИС и в ней нет ПДн? Тут опять ступор.

Но самое важное заключается в том, что ФСТЭК заставляет использовать свой банк данных угроз (БДУ) для моделирования угроз. Кто-то может спросить «а что не так с БДУ»? С БДУ все нормально, просто угрозы из него как раз-таки заточены под новую методику, которую никак не могут утвердить и опубликовать. Например, каждая угроза привязана к потенциалу нарушителя, а в старой методике нарушитель практически никак не участвует в процессе актуальности/неактуальности угрозы. Да и чем отличается нарушитель со средним потенциалом от нарушителя с высоким потенциалом описано довольно скудно. И только из проекта новой методики мы узнаем, что под нарушителем с высоким потенциалом понимаются недвусмысленно специальные службы иностранных государств (блоков государств). Да и в целом в проекте новой методики присутствует целое приложение с методикой определения потенциала нарушителя, жаль только что ею нельзя пользоваться.

Многие специалисты неоднократно сталкивались с такой ситуацией, когда берешь новые угрозы из БДУ, считаешь их актуальность по старой методике и угрозы, которые на интуитивном уровне должны быть актуальными получались неактуальными (и наоборот). Каждый в такой ситуации действует по-разному: кто-то оставляет все как есть, мол, методика есть методика, кто-то «подгоняет» коэффициенты под нужный результат. В любом случае, чего мы точно не можем делать — это пользоваться новой методикой по проекту документа, т.к. он не имеет официального статуса. К тому же, ходят слухи, что в этот проект уже внесли правок вагон и маленькую тележку. Надеемся, что утверждения и публикации документа осталось недолго ждать.


Смотрите также