Контакты
Подписка
МЕНЮ
Контакты
Подписка

Потенциал нарушителя в Модели угроз - Форум по вопросам информационной безопасности

Потенциал нарушителя в Модели угроз - Форум по вопросам информационной безопасности

К списку тем | Добавить сообщение


Страницы: < 1 2 3 4 5 6 7 8 9 10 11 12 13 >

Автор: Константин | 110125 27.06.2022 12:44
Точнее, не угроза ПДн признается неактуальной, а негативные последствия для ПДн признаются неактуальными.

Автор: oko | 110126 27.06.2022 14:07
to Константин
"экспертная оценка" применяется не только при назначении "весов" по отношении к готовому списку последствий, но и при самом формировании списка...
см. Раздел 3 и Приложение 3. Когда архитектура/структура/базовые меры защиты/проч. уже определены эксперты переходят к оценке последствий. При этом могут брать как типовые данные из Приложения 4, так и расширять их своим "экспертным мнением". Чисто технически, imho, оптимально будет, если каждый эксперт формирует свой список последствий с "весами" для каждого последствия (читай, отнесение к У1 - У3) -> все эксперты N раундов решают "что оставим, что выбросим" -> N раундов формируется результирующий список по методу исключения и корреляции. Если же эксперты работают "сами по себе" (что тоже вариант для достижения бОльшей объективности), то задача исключения и корреляции ложится на руководителя экспертной группы...

Автор: Константин | 110127 27.06.2022 14:31
2 oko Благодарю!
А возможно ли, что ПДн есть в ГИС, но последствия связанные с ПДн выпадут из итоговых последствий из-за низких оценок экспертов? Может ли такое быть и что в таком случае делать? Будет ли это возможным замечанием от ФСТЭК при согласовании?

Автор: oko | 110128 27.06.2022 14:40
to CM
В моем захолустье большинство гос.органов давно плотно "сидит" на единой ИС документооборота, которая нещадно лагает и падает (по причине криворукости рулевых лиц). Но это никак не мешает оным органам функционировать даже в период полной недоступности оной ИС. Показатели функционирования (на мой скромный взгляд), конечно, не 100%, но, по правде сказать, они были аналогичными и до внедрения этой ИС, ага...
Это алыверды к примеру о Росреестре. К тому же, рискну напомнить вашу же логику: в любую ИС вначале нужные данные необходимо ввести, а для получения результата деятельности органа - вывести, оформить и предоставить. Тогда, раз вы так болеете душой за причинно-следственную связь "нарушение ИС -> нарушение функционирования органа", предлагаю заодно клонировать каждое ответственное за ввод/вывод лицо. Как минимум, во избежание "самопроизвольного выхода из строя" (даже без воздействий со стороны хакеров, ага)...
Что до примера с пьяным-за-рулем, то он явно не для демонстрации связи нарушений ГИС/гос.органа, а приводился вами для других целей. Впрочем, фундаментальную ошибку в контексте оных целей уже вам описал (жаль, только, что безответно, ага)...
В итоге, любезнейший, о каких примерах, имеющих непосредственное (подчеркиваю) отношение к предмету обсуждения, идет речь?

Автор: oko | 110129 27.06.2022 14:46
to Константин
Не берусь говорить за регулятора (у него, как показывает практика, мнение нестабильное), но теоретически допустить подобный вариант можно (imho, вероятнее всего в случае общедоступности ПДн). Прикол в том, что 152-ФЗ и нормативка по ПДн вообще размыты и дают возможность любому желающему "эксперту" притянуть за уши любую ситуацию. Правда, обычно это "притягивание" происходит ради "перестраховки", а не наоборот...
Если конкретно, то на практике не встречал отказа от рассмотрения последствий по ПДн, когда Владелец/Оператор ГИС является одновременно Оператором ПДн...

Автор: Константин | 110130 27.06.2022 14:56
2 oko Спасибо!

Автор: CM | 110131 28.06.2022 08:08
to oko:

> ...Но это никак не мешает оным органам функционировать даже в период полной недоступности оной ИС. Показатели функционирования (на мой скромный взгляд), конечно, не 100%, но, по правде сказать, они были аналогичными и до внедрения этой ИС, ага...

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

> Что до примера с пьяным-за-рулем, то он явно не для демонстрации связи нарушений ГИС/гос.органа, а приводился вами для других целей.

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

Автор: oko | 110133 28.06.2022 14:59
to CM
В том-то и дело, любезнейший, что... мнэ...:
<Для последствий прекращения (нарушения) функций гос органа ... пример ИС Росреестра ... был максимально показательным> - строго не согласен и тоже наглядно указал причины...
<Про единственность указанного вида последствий ... и отрицание иных видов негативных последствий ...> - это, собственно, фантазии - такие вопросы в рамках обсуждения не поднимались (сарказм про "самопроизвольный выход из строя" на то и сарказм, ага)...
<Этот пример был приведен для демонстрации разницы между угрозой и мерами с документами их отражающих ...> - отлично! Только с ним тоже не согласен и тоже объяснял почему...
По результату: вашу позицию в целом понимаю, но не разделяю и вменяемых аргументов для смены позиции пока не вижу. К слову, кол и мочало из сообщения недельной давности как бэ намекают, ага. Продолжим играть в презабавную игру под названием "перелей из пустого в порожнее" или сделаем перерыв?

Автор: CM | 110134 28.06.2022 15:20
to oko:

Идея возложить на регулятора связать угрозы с мерами не является аргументом для "слияния" последних между собой в непонятную общую сущность. В остальных высказываниях по предмету обсуждения конкретики не было.

Автор: oko | 110135 28.06.2022 16:40
to CM
Японский ж бог... Короче, обсуждать вашу маничку про "нарушение ИС -> нарушение органа" смысла не имеет, а в остальном еще раз ставлю точки над i:
Положим, есть УБИ. Часть из них актуальна для конкретной ИС. Эта часть должна закрываться какими-то мерами защиты. Во всех приказах (17, 21, 31, 239) имеется общий перечень мер для разных классов/уровней ИС (ОИ), часть из которых обязательны (базовые), если это подтверждается архитектурой и условиями эксплуатации ИС (как с той же виртуализацией), часть необязательны (но могут быть реализованы), а для некоторых можно добавить "усиление" (согласно методичке 2014 г.). Итоговый выбор реализуемых мер проводится в рамках "уточненного адаптивного набора мер", направленных, напоминаю, на "нейтрализацию (блокирование) УБИ, включенных в модель". Причем выбор проводится на этапе проектирования КСЗ, а не когда-то там потом (читай, после Моделирования, но до Внедрения/Реализации КСЗ). И все это проводится в рамках единого процесса - от создания ИС до момента начала ее эксплуатации (про уже существующие ИС разговор другой, но принцип тот же). В этом главная ошибка ваших рассуждений и примеров - "актуальные УБИ -> адаптивный набор мер защиты" и точка. А что до "непонятных общих сущностей", то, помилуйте, это опять ваша фантазия - такой херни ни разу не упоминал...
Однако, раз уж регулятор сказал А (читай, дал реестр УБИ и перечень всех возможных мер), то он и должен сказать Б (читай, наглядно указать это следствие: "какие УБИ из реестра какими мерами защиты из Приказов должны блокироваться/нейтрализовываться"). Иначе нарушается и юр.сторона дела (и сторонний эксперт, и тем более регулятор может всегда подвергнуть сомнению даже не конкретику, а принципиальный выбор мер защиты против той или иной актуальной для ИС УБИ), и фактическая сторона (можно как в вашем случае - моделировать отдельно, а меры лепить отдельно по принципу "лишь бы было"). И то, и другое приходилось видеть на практике. И то, и другое, imho, бред и либо человеческая глупость, либо злой умысел. И, главное, нарушает прописанный регулятором порядок выбора, актуализации и ввода в действие КСЗ в любой ИС...
Добавим до кучи сюда непонятную концепцию с тактиками и техниками. В сущности, раз "актуальность УБИ" может зависеть от "актуальности тактик/техник" (по Методике 2021), то и "меры защиты" можно выбирать, исходя из противодействия не УБИ принципиально, а конкретным тактикам/техникам. Что вносит еще большую путаницу и открывает неограниченное пространство для профанаций (считаем, что "ломать ИС" будут так-то, поэтому от этого и закрываемся, а остальные методы не рассматриваем либо по глупости, либо из злого умысла)...
С выходом нового тестового (пока) раздела БДУ регулятор решил сменить стратегию: каждая УБИ + более-менее явный объект ее применения (объект защиты) получили наглядную связь с конкретными мерами защиты из Приказов. Безотносительно тактик/техник, прошу заметить. Конечно, это неутвержденный вариант - подождем Методику 2022 (2023+, ага). Но главное "белое пятно", означенное выше, так или иначе будет закрыто, что, imho, хорошо...
И советую еще раз внимательно почитать указанные Приказы относительно порядка работ: "Классификация -> анализ доп.условий (архитектуры, техпроцесса, прочего) -> Моделирование -> анализ доп.требований (вышестоящего ведомства, например) -> формирование итоговых Требований к КСЗ в ИС, включая требования к мерам защиты -> Проектирование КСЗ (с формированием уточненного адаптивного набора мер) -> Внедрение КСЗ (реализация мер) -> Испытания (предварительные, приемочные, оценка эффективности, оценка соответствия, аттестация - в зависимости от) -> Эксплуатация -> если что-то меняется (включая новые УБИ и уязвимости), то вплоть до перехода к началу цикла -> Вывод из эксплуатации". Хотите порвать этот цикл или внести в него избыточность, заявляя, что меры выбираются безотносительно актуальных УБИ или что любой этап цикла можно выполнять сам по себе до посинения, потому что ответственность за моделирование, ответственность за меры, ответственность за оценку и т.д. несут разные люди - ваше право. Только это, imho, дерьмо собачье, единственный смысл которого - создать иллюзию работ по ЗИ/ИБ, не более...
Теперь-то comprendo?

Страницы: < 1 2 3 4 5 6 7 8 9 10 11 12 13 >

Просмотров темы: 10065

К списку тем | Добавить сообщение



Добавить сообщение

Автор*
Компания
E-mail
Присылать уведомления да
нет
Текст сообщения*
Введите код*