Приказ о модели угроз

Модель угроз, у кого какие мнения? — Форум по вопросам информационной безопасности

Модель угроз, у кого какие мнения? — Форум по вопросам информационной безопасности

to Илья
«По совести» — нельзя. По иным «причинам и понятиям» — можно все. Лучше (если вариантов нет и ЧМУ с Актом надо выдать сейчас) — вы правильно думаете — сделать оговорку о моделировании и классификации в «переходный момент», т.е. непосредственно во время перехода ИС от состояния А к состоянию Б. Расписать существующие и предполагаемые (после модернизации) угрозы. Расписать, какие из существующих будут неактуальны после модернизации. Указать перечень обязательных характеристик системы, которые должны быть приведены к состоянию Б после проведения модернизации. Чтобы заказчик не мог внезапно во время модернизации «передумать» и изменить процесс и конечный результат. А после всего этого — еще раз провести оценку и выдать уточненную ЧМУ. Возможно даже с повторной классификацией (при необходимости). Но, сами понимаете, это вначале надо с заказчиком обсудить и согласовать. А то может «обидеться» и думать, что вы его хотите «подставить». Впрочем, в оценке актуальных угроз никогда не должна принимать участие только экспертная сторона. От заказчика все равно должны быть представители и на этапе оценки, и на этапе моделирования, и на этапе согласования и утверждения. Так что это в его же интересах.

ЗЫ А вообще, заниматься моделированием в «переходном» состоянии системы — моветон. И до заказчика это надо доводить до начала выполнения любых работ.

to Илья
Дык: «В качестве исходных данных при приемочных испытаниях используются модель угроз безопасности информации, акт классификации автоматизированной системы управления, техническое задание на создание (модернизацию) автоматизированной системы управления и (или) техническое задание (частное техническое задание) на создание системы защиты автоматизированной системы управления, проектная и эксплуатационная документация на систему защиты автоматизированной системы управления. » и далее по тексту. Т.е. в сущности, если фактическое состояние явно отличается от проекта, проект — от модели и акта классификации, то и приемочные испытания принимать нельзя. Конечно, это не повод распилить *зачеркнуто*. но обоснование делать все «как надо», а не «как всегда» все же есть и явное.
То же самое, кстати, касается и 17 Приказа. А превратность прочтения — это уже на совести читавших, ага.

ЗЫ Главный вопрос, который надо было задать изначально: под «модернизацией» понимается изменение самой АСУТП или встраивание в нее системы защиты информации? В первом случае — уже ответил. Во втором — да, модель и акт разрабатываются до модернизации, а задачи ТЗ и ТП уже правильно описать (для последующего внедрения) систему защиты, основываясь на результатах моделирования, анализа уязвимостей и т.д.

Илья, не путайте мух и котлет.

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

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

По хорошему, модели угроз должно быть две. Модель угроз исходной системы и модель угроз целевой системы.

Приказ о модели угроз

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

Но, как думаю я, могу ошибаться.
1. Определяете базовый набор мер защиты (из 17 приказа соответственно классу)
2. Адаптируйте базовый набора мер защиты (под свою АС)
3. Уточняете адаптированный базовый набор мер защиты, исходя из вашей актуальной модели угроз. Т. е. берёте свою модель угроз, и смотрите перекрывают ли меры из адаптированного набора мер защиты, все угрозы ваши.
4. Дополнение адаптированного базового набора мер защиты (меры защиты, которые вы должны выполнить, по иным нормативным документам).

А у вас ГИС или ИСПДН? вы сделали акт классификации, говорите свой класс, вам быстренько накидаем что надо, какие СЗИ и какие документы нужны. Вы частная контора или нет? в Роскомнадзоре как оператор или пока он о вас не знает?

Если планируете это дело провести в 2017. СЗИ уже есть, только его сертифицируют, в нем будут механизмы СОВ, СДЗ, САЗ,МЭ, и все компоненты — и стоить будет копейки, и управлять просто.

Это небось про сикрет нет студио. Там можно будет набирать в лицензию различные модули. Не хочешь хостовый мэ, не бери . Да, за счёт всей пачки сертификатов решение у госов может выстрелить. А вот по реальной защите вопрос. Решение узко нишевое и молодое, в боях с трояноводами не участвовало.
Надо будет сравнить чтоли по фитчастости с касперычем.

Приказ о модели угроз

Вопрос обеспечения информационной безопасности Государственных Информационных Систем не только не теряет актуальности, но с развитием концепции электронного правительства и увеличением количества электронных услуг, становится более значимым. Так, около месяца назад большой резонанс на Хабрахабре вызвала статья «И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках».

Используя терминологию проекта документа «Методика определения угроз безопасности информации в ИС», эту ситуацию потенциально можно описать следующим образом:

  • Орган государственной власти, орган местного самоуправления и организация, являющихся в соответствии с законодательством Российской Федерации обладателями информации, заказчиками и (или) операторами информационных систем: Федеральная служба по надзору в сфере образования и науки.
  • Источник угроз НСД в ИСПДн: внешние субъекты (физические лица)
  • В качестве возможных целей (мотивации) реализации нарушителями угроз безопасности информации в информационной системе могут быть: любопытство или желание самореализации; выявление уязвимостей с целью их дальнейшей продажи и получения финансовой выгоды;
  • Для достижения своей цели нарушитель выбирает наиболее слабое звено информационной системы: «Для получение информации о документе об образовании достаточно просто заполнить форму, передвинуть слайдер и нажать кнопку.»
  • Анализ прав доступа проводится, как минимум, в отношении следующих компонент информационной системы: программных, программно-технических и технических средств обработки информации; каналов связи, выходящих за пределы контролируемой зоны: в этом кейсе была выявлена возможность SQL Injection.
  • Также оценке подлежат последствия реализации угрозы, в том числе экономические, социальные, политические и т. д. Для примера посмотрим, что относится к социальным последствиям: Появление негативных публикаций в общедоступных источниках. Невозможность (прерывание) предоставления социальных услуг (сервисов). Другие последствия, приводящие к нарастанию социальной напряженности в обществе.
  • Пересмотр (переоценка) угроз безопасности информации осуществляется как минимум в случаях: выявления уязвимостей, приводящих к возникновению новых угроз безопасности информации или к повышению возможности реализации существующих; появления сведений и фактов о новых возможностях нарушителей. Уязвимость была закрыта, сервис временно не работал.

Как известно, требования по защите Государственных Информационных Систем (ГИС) регламентируются приказом ФСТЭК от 11 февраля 2013 г. N 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».

В данном приказе содержатся требования по защите информации и определены этапы работ по созданию защиты информации. Ниже приведена краткая выписка таких этапов.
Для обеспечения защиты информации, содержащейся в информационной системе, проводятся следующие мероприятия:

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

В контексте данной статьи нас будет в первую очередь интересовать этап формирования требований к защите.

Формирование требований к защите информации, содержащейся в информационной системе, осуществляется с учетом ГОСТ Р 51583 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения» и ГОСТ Р 51624 «Защита информации. Автоматизированные системы в защищенном исполнении. Общие требования» и в том числе включает:

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

Как мы видим, приказом №17 отдельно вынесено определение угроз безопасности, а проверяющие органы запрашивают при проверках документ, под названием «Модель угроз».

Итак, попробуем разобраться с данным документом.

Непосредственно разработка модели угроз должна основываться на следующих документах ФСТЭК:

  • «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных», Федеральная служба по техническому и экспортному контролю, 2008 год
  • «Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных», Федеральная служба по техническому и экспортному контролю, 2008 год.

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

Подробнее о проекте документа «Методика определения угроз безопасности информации в ИС» можно прочитать на Хабре в статье «Документ, который ждали».

Однако, возвращаясь 17-му приказу мы читаем следующее.
Угрозы безопасности информации определяются по результатам оценки возможностей (потенциала) внешних и внутренних нарушителей, анализа возможных уязвимостей информационной системы, возможных способов реализации угроз безопасности информации и последствий от нарушения свойств безопасности информации (конфиденциальности, целостности, доступности).
В качестве исходных данных для определения угроз безопасности информации используется банк данных угроз безопасности информации (bdu.fstec.ru), а также иные источники, содержащие сведения об уязвимостях и угрозах безопасности информации. А вот здесь возникает заминка, банк данных создан, есть программные продукты автоматизирующие анализ защищенности в соответствии с данным банком, а вот упоминания про этот банк в действующих документах «Базовой модели» и «Методиках определения актуальных угроз» нет.

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

Что нужно определить и учесть согласно приказу:

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

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

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

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

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

Приказ о модели угроз

>> т.е. если в ваших как вы думаете ТИПОВЫХ ИСПДн реализована хотябы одна из характеристик безопасности отличная от конфиденциальности, то она СПЕЦИАЛЬНАЯ . о как

Исходим из предположения, что товарищ АлександрМ документы прочитал внимательно и этот момент учел 😉

>> и даже резервирование не нать. делааа

Почему бы и нет?
Я могу брать данные для обработки у другого оператора (с подписанием всяких бумажек, все дела, т.е. законно).
Потеря этих данных мной лично в результате, например, аппаратного сбоя моих серверов меня ни разу не волнует — я в любой момент могу получить эти данные снова от оператора, с которым работаю.

Т.е. для своей ИСПДн требования по резервированию я могу и не предъявлять — это будет заботой того оператора, у которого я беру данные для обработки.

Максим,
по необходимости составлять модель угроз и для типовых систем вынужден согласиться — от ПП никуда не уйдешь.
А вот по необходимости резервирования:

>> Как Вы допустим восстановите персональные данные, которые уже обработали (изменили, дополнили и так далее)

А если я их не изменяю, не дополняю, а только читаю?

Приказ о модели угроз

Товарищи, интересует мнение.
Может ли быть такое, что в модели угроз вообще все представленные угрозы — не актуальны?

Т.е. есть процедура разработки системы защиты ИС — в 17 приказе описана.
В том числе, разрабатывается модель угроз+базовый набор мер и ПОТОМ уже применяются меры ЧТОБЫ нейтрализовать угрозы.

В организации были реализованы технические меры из базового набора. Они были реализованы просто без моделе, проектов и т.п.

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

Но ведь так не может быть!
Потому что СНАЧАЛА модель, а потом меры, то, что соотвествующий софт был установлен и настроен — не значит, что нужно воспринимать это как исходное состояние системы.

Разве не нужно было игнорировать эти СЗИ и относиться к системе, как чистенькой без СЗИ?

to sekira
Как при реализованной СЗИ (комплексной, разумеется) «вероятность» реализации УБИ может быть признана «высокой»? Про «степень ущерба» молчу — в большинстве своем бездарно введенный параметр в Методику-2008. Но даже с ней — СЗИ должна предусматривать снижение ущерба в случае реализации УБИ (тот же периодический бэкап критичных данных, к примеру). Так что не верю.
Эффективность можно подтвердить на практике и описать отдельным документом, на который будет ссылаться ЧМУ; можно приложением к ЧМУ — без разницы. В чем вопрос?

Рассматривайте ИС+СЗИ как АСЗИ и моделируйте для нее угрозы с учетом реализованной системы защиты. Если по результатам выйдет, что актуальные угрозы отсутствуют — ничего страшного, на то она и АСЗИ.

Ущерб не зависит от применяемых СЗИ.

«Так что не верю. »
Это надо регулятору сказать.

«что актуальные угрозы отсутствуют — ничего страшного»

дак что там с п.п.п. 4 п 2. ст 19 ФЗ 152 . оценкой эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных;
п6. пр 21 Оценка эффективности реализованных в рамках системы защиты персональных данных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно или с привлечением на договорной основе юридических лиц и индивидуальных предпринимателей, имеющих лицензию на осуществление деятельности по технической защите конфиденциальной информации. Указанная оценка проводится не реже одного раза в 3 года.

Смотрите так же:  Федеральный закон 103 от 03.06.2009

Как оценивать? Так в заключении и напишите — Угроз нет — эффективность СЗИ и мер обеспечивается! Все требования 21 приказа не нужны потому что — все угрозы неактуальны — держи оператор аттестат (Заключение по проверке).

to sekira
Товарищ, вы сообщение топикстартера читали вообще? Как бэ 17 приказ (ГИС, не ИСПДн, хотя, конечно, одно другому не мешает, но мы не будем экстрасенсорикой баловаться). Как бэ «В организации были реализованы технические меры из базового набора».
Так что все в порядке. А что ЧМУ не сделали первично — и что с того? Провели моделирование угроз по прошествии времени эксплуатации с уже установленной СЗИ — доказали, что актуальных угроз (требующих новых мер защиты) нет. Где криминал?
*в сторону* оценка всегда «ручная» с выдачей соответствующего Протокола/Заключения. Только к первичному вопросу это все отношения не имеет.

Про ущерб, который не зависит. Знаете, тогда по логике вещей в более-менее критичных ИС мы всегда будем получать актуализацию угроз безопасности вне зависимости от любых факторов. Про эту глупость в Методике2008 я и говорил. Реализованная система защиты может и обязана снижать степень ущерба ИС от реализации УБИ. А не только устранять каналы утечки, блокировать атаки и т.п.

«как бы 17 приказ»
да не увидел.

а тогда тем более..
«. определение угроз безопасности информации, реализация которых может привести к нарушению безопасности информации в информационной системе, и разработку на их основе модели угроз безопасности информации»

Речь не идет об актуальности угроз для ГИС.

«Знаете, тогда по логике вещей в более-менее критичных ИС мы всегда будем получать актуализацию угроз безопасности вне зависимости от любых факторов».

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

А методики оценки угроз ФСТЭК для ГИС нет утвержденной. Есть только .». Для определения угроз безопасности информации и разработки модели угроз безопасности информации применяются методические документы, разработанные и утвержденные ФСТЭК России в соответствии с подпунктом 4 пункта 8. «

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

Про выбор СЗИ..
Мет. рекомендации ГИС 11 февраля 2014 г «. Выбор мер защиты информации осуществляется исходя из класса
защищенности информационной системы, определяющего требуемый уровень
защищенности содержащейся в ней информации, и угроз безопасности
информации, включенных в модель угроз безопасности информационной
системы. »
Включенных в модель! Не актуальных, а просто рассматриваемых.

Требования первичны.
А так получается требования обходятся якобы «неактуальными» угрозами (квазивыполняются-недовыполняются) тем что должно эти требования выполнять СЗИ и мерами.

Приказ Министерства здравоохранения Республики Тыва от 30 мая 2017 г. N 617 «Об утверждении модели угроз безопасности персональных данных при их обработке в информационных системах персональных данных Министерстве здравоохранения Республики Тыва»

Приказ Министерства здравоохранения Республики Тыва от 30 мая 2017 г. N 617
«Об утверждении модели угроз безопасности персональных данных при их обработке в информационных системах персональных данных Министерстве здравоохранения Республики Тыва»

В соответствии с Федеральным законом от 27 июля 2006 года N 149-ФЗ «Об информации, информационных технологиях и о защите информации»; Федеральным законом от 27 июля 2006 года N 152-ФЗ «О персональных данных», постановлением Правительства Российской Федерации от 1 ноября 2012 года N 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных», постановлением Правительства Российской Федерации от 21 марта 2012 года N 211 «Об утверждении перечня мер, направленных на обеспечение выполнения обязанностей, предусмотренных Федеральным законом «О персональных данных» и принятыми в соответствии с ним нормативными правовыми актами, операторами, являющимися государственными или муниципальными органами» приказываю:

1. Утвердить прилагаемую Модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных Министерстве здравоохранения Республики Тыва (далее — Модель угроз).

2. Начальникам отделов организовать ознакомление подчиненных специалистов с настоящим приказом.

3. Возложить на начальника отдела организационно-правового обеспечения и кадровой политики Болаа А.А. персональную ответственность за исполнение требований настоящего приказа.

4. ГБУ «Медицинский информационно-аналитический центр Республики Тыва» разместить настоящий приказ на официальном сайте Министерства здравоохранения Республики Тыва.

5. Контроль за выполнением настоящего приказа возложить на заместителя министра здравоохранения Республики Тыва К.К. Монгуш.

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

Модель
угроз безопасности персональных данных при их обработке в информационных системах персональных данных Министерства здравоохранения Республики Тыва
(утв. приказом Минздрава РТ от 30 мая 2017 г. N 617)

Обозначения и сокращения

ABC — антивирусные средства

АРМ — автоматизированное рабочее место

ВТСС — вспомогательные технические средства и системы

ИСПДн — информационная система персональных данных

КЗ — контролируемая зона

ЛВС — локальная вычислительная сеть

МЭ — межсетевой экран

НСД — несанкционированный доступ

ОС — операционная система

ПДн — персональные данные

ПМВ — программно-математическое воздействие

ПО — программное обеспечение

ГТЭМИН — побочные электромагнитные излучения и наводки

САЗ — система анализа защищенности

СЗИ — средства защиты информации

СЗПДн — система (подсистема) защиты персональных данных

СОВ — система обнаружения вторжений

ТКУ И — технические каналы утечки информации

УБПДн — угрозы безопасности персональных данных

ФСТЭК России — Федеральная служба по техническому и экспортному контролю

В настоящем документе используются следующие термины и их определения:

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

Блокирование персональных данных — временное прекращение сбора, систематизации, накопления, использования, распространения, персональных данных, в том числе их передачи.

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

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

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

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

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

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

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

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

Смотрите так же:  Заявление на регистрацию в гаи нового образца

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

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

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

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

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

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

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

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

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

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

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

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

1. Общие положения

Настоящая модель определяет актуальные угрозы безопасности персональных данных, при их обработке в информационных системах персональных данных с использованием средств автоматизации (далее — информационная система) в М3 РТ.

Настоящая модель угроз разработана в соответствии со следующими основными документами:

Федеральный закон от 27 июля 2006 года N 149-ФЗ «Об информации, информационных технологиях и о защите информации»;

Федеральный закон от 27 июля 2006 года N 152-ФЗ «О персональных данных»;

Положение об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных, утвержденное постановлением Правительства Российской Федерации от 17 ноября 2007 года N 781 (далее — Положение);

Постановлением Правительства РФ от 1 ноября 2012 г. N 1119 названное Положение признано утратившим силу

См. Требования к защите персональных данных при их обработке в информационных системах персональных данных, утвержденные постановлением Правительства РФ от 1 ноября 2012 г. N 1119)

Порядок проведения классификации информационных систем персональных данных, утвержденный приказом ФСТЭК России, ФСБ России и Мининформсвязи России от 13 февраля 2008 года N 55/86/20 (зарегистрирован Минюстом России 3 апреля 2008 года, регистрационный N 11462) (далее — Порядок);

Приказом ФСТЭК России, ФСБ России и Мининформсвязи России от 31 декабря 2013 г. N 151/786/461 названный Порядок признан утратившим силу

Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных (Утверждена Заместителем директора ФСТЭК России 15 февраля 2008 г.);

Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных (Утверждена Заместителем директора ФСТЭК России 14 февраля 2008 г.).

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

В соответствии с п. 12 Положения необходимым условием разработки системы защиты персональных данных является формирование модели угроз безопасности персональных данных (далее — модель угроз).

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

Модель угроз формируется и утверждается оператором в соответствии с методическими документами, разработанными в соответствии с пунктом 2 постановления Правительства Российской Федерации от 17 ноября 2007 г. N 781 «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных».

Модель угроз может быть пересмотрена:

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

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

2. Описание ИСПДн

Описание ИСПДн является первым шагом при построении модели угроз и осуществляется на этапе сбора и анализа исходных данных.

Описание ИСПДн состоит из следующих пунктов:

1) Описание условий создания и использования ПДн;

Описание форм представления ПДн;

Описание структуры ИСПДн;

Описание характеристик безопасности.

2.1. Определение характеристик безопасности

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

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

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

При обработке персональных данных в ИСПДн МЗ РТ необходимо обеспечить следующие характеристики безопасности — конфиденциальность, целостность.

3. Пользователи ИСПДн М3 РТ

Основные группы пользователей ИСПДн:

Администратор ИСПДн, осуществляющий настройку и установку технических средств ИСПДн и обеспечивающий ее бесперебойную работу;

Операторы ИСПДн, осуществляющие текущую работу с персональными данными.

Матрица доступа для ИСПДн М3 РТ представлена в таблице 1.

Приказ о модели угроз

РОССИЙСКАЯ ФЕДЕРАЦИЯ

АДМИНИСТРАЦИЯ ТРУБЧЕВСКОГО МУНИЦИПАЛЬНОГО РАЙОНА

Р А С П О Р Я Ж Е Н И Е

от «23» 10.2015г. №807-р

Во исполнение требований Федерального закона от 27.07.2006 № 152 «О персональных данных», постановления Правительства Российской Федерации от 01.11.2012 года № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных», Приказа ФСТЭК России от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных», в соответствии с Методикой определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных», утвержденной ФСТЭК России 14.02.2008, а также иных нормативных документов по защите информации:

1. Утвердить прилагаемую частную модель угроз безопасности персональных данныхпри их обработке в информационной системе персональных данных администрации Трубчевского муниципального района «СБиС++».

2. Контроль за исполнением настоящего распоряжения возложить на заместителя главы администрации Трубчевского муниципального района Тубол С.Н.

Глава администрации

Трубчевского муниципального района И.И. Обыдённов

108shagov.ru. Все права защищены. 2019