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

to Константин:

> Подскажите, пожалуйста, а, как обстоит дело с объектами и компонентам воздействия? требуется ли рассматривать исчерпывающий перечень включая средства защиты информации и тд Или тоже можно предполагать, что СЗИ на то и СЗИ, чтобы не включать их в объект воздействия?
> И не совсем ясно в МУ надо указывать конкретные объекты воздействия например СУБД PostgreSQL или достаточно написать СУБД ? для ГИС, которая находится в эксплуатации.

Пунктом 2.5 Методики оценки УБИ (от 05.02.2021) регулятор разделяет оценку угроз, проводимую на этапе создания ГИС, и оценку, проводимую в ходе эксплуатации ГИС, включая ее модернизацию. Предполагаемая архитектура ГИС предписывается только для первого случая. Во втором случае предусматривается использовать реальную архитектуру ГИС. При рассмотрении возможных объектов воздействия в пункте 4.4 Методики также сохранен подход разделения на этап создания ГИС и этап ее эксплуатации, включая модернизацию.
Средства защиты информации регулятор отнес к возможным объектам защиты (см. пунктом 4.3 (е) Методики).
Формально указанная Методика не отвечает на вопрос о достаточности описания объектов воздействия в Модели УБИ. Если учесть, что Модель УБИ является документом формирования требований к защите информации ГИС, то подробное описание объектов воздействия, включая средств защиты, будет излишним. Для этого предназначена техническая и эксплуатационная документация на ГИС (СЗИ ГИС). Для "облегчения" работы с Моделью УБИ можно вынести описательную часть про объекты воздействия в отдельное приложение к данному документу, а по тексту использовать их наименование или аббревиатуру.

2 CM Большое спасибо!

А ещё, пожалуйста, объясните разницу между п.4.3 и п.4.6 Методики 2021. п.4.6 это типа уточнение для 4.3 только согласно сетевой модели взаимодействия? В п.4.3 написано, что определяются группы, которые могут являться объектами воздействия, а в п.4.6 написано, что объекты воздействия определяются на следующих уровнях сетевой модели. Разве это не та же группировка объектов, как и в п.4.3 только в ином виде?

И ещё. В п.4.3 указывается Информация (данные), как группа, которая может являться объектом воздействия. Но при определении видов воздействия эту группу Информация (данные) мы не используем. С точки зрения логики понятно почему не используем, потому Информация это скорее не объект воздействия, а его цель. Но возможно я ошибаюсь.. И зачем тогда группа Информация нужна в п.4.3 ?

Короче, я как-то запутался в этих терминах и пунктах. Что зачем и почему. Если кому-то не трудно разъяснить, то большое спасибо!

to Константин
Нарушитель может оказывать воздействие на саму обрабатываемую информацию, на ПО/ТС ее обработки, на СЗИ для ее защиты и т.д. И на всех уровнях ее представления и обработки (аппаратный, прикладной, сетевой и т.д.). Кстати, в 4.6 не "на уровнях сетевой модели", а скорее "в том числе на сетевом уровне"...
Другой вопрос, что есть "основной защищаемый ресурс" - информация или нечто иное? Обычно учат, что информация. Но с появлением АСУТП и КИИ картинка резко поменялась и защищаемым ресурсом стал процесс (бизнес-процесс, техпроцесс и т.п.). А информация, используемая данным процессом, это либо вторичный объект защиты, либо вообще инструмент влияния на процесс (кодированная последовательность для управления каким-либо критическим оборудованием, например). В любом случае, конечно, информация будет являться объектом воздействия нарушителя, только не как самоцель (в случае нарушения конфиденциальности, например), а как сопутствующий фактор, дополнительный этап воздействия на процесс...
Короче, группировка в 4.3 и ее представление в 4.6 приведены, imho, для случая сферического коня в вакууме. На деле надо смотреть, что важнее в контексте конкретного объекта информатизации: обрабатываемая информация или процесс целиком. Если информация, то консолидировать на всех уровнях представления штатные методы ее обработки, хранения и представления. Если процесс, то в деталях и на всех уровня описать его прохождение и далее выявить возможные "точки" воздействия...

*в сторону*
А можно и тупо: взяли каждый из уровне представления объекта информатизации (аппаратный, системный, прикладной, сетевой, пользовательский), посмотрели на него под микроскопом (в пределах возможностей встроенных линз, ага) и описали, что, дескать, на таком-то уровне есть такие-то объекты воздействия (принципиально), на таком-то - такие-то (например, на сетевом уровне будет не столько "информация ограниченного доступа", сколько "сетевой трафик") и все это свели в красивую табличку...
Что с ней делать, правда, не понятно, согласно логике Методики-2021. Потому что УБИ из БДУ в означенном контексте - штуки сами по себе. И единственная параллель, которую можно провести, это тупо взять полученную табличку и сличить ее с графой "объект воздействия" безотносительно оценки влияния УБИ на характеристики всего объекта информатизации в целом. Утрируя, в итоге все объекты информатизации, где на сетевом уровне имеется "сетевой трафик", будут подвержены УБИ с "объектом воздействия" = "сетевой трафик". Стильно, модно, молодежно. Даже если "защищаемый ресурс" = ИОД, а не процесс, но на данном конкретном объекте информатизации по сети ИОД не передается, ага...

2 oko Благодарю!

to Константин:

> А ещё, пожалуйста, объясните разницу между п.4.3 и п.4.6 Методики 2021. п.4.6 это типа уточнение для 4.3 только согласно сетевой модели взаимодействия? В п.4.3 написано, что определяются группы, которые могут являться объектами воздействия, а в п.4.6 написано, что объекты воздействия определяются на следующих уровнях сетевой модели. Разве это не та же группировка объектов, как и в п.4.3 только в ином виде?
> И зачем тогда группа Информация нужна в п.4.3 ?

Пункт 4.3 Методики оценки УБИ (от 05.02.2021) говорит о ГРУППАХ объектов воздействия, а в пункте 4.6 Методики указано на каких уровнях следует определять объекты воздействия.
Группирование объектов воздействия удобно использовать при моделировании / оценки УБИ в случае их повторяемости в сегментах ГИС, АРМах, серверах. Предлагаемые варианты группирования довольно "стандартны". Их использование можно встретить у самого регулятора. Например, в БДУ.
4.3 (а) - это защищаемая информация, когда нарушителя интересуют сведения, к которым обеспечиваются требования конфиденциальности, целостности и доступности. Но не всегда нарушителя интересуют защищаемая информация. Когда его целью становится нарушение работоспособности системы, то его объектами воздействия её компоненты и связанные с ней обеспечивающие системы:
4.3 (б) - программно-аппаратные средства, когда объектом воздействия выступают схемно-конструкторские решения выпускаемого оборудования и связанное с ним специальное ПО;
4.3 (в) - в общесистемном и прикладном ПО объектом воздействия рассматриваются алгоритмические ошибки, допущенные в ходе его разработки;
4.3 (г) - МНИ, как отдельная группа переносных устройств и связанных с ними угроз, включая работу с размещенной на них ключевой информацией;
4.3 (д) - отдельная группа, связанная с телекоммуникационным оборудованием и его управлением;
4.3 (е) - группа средств защиты;
4.3 (ж) - отдельная группа объектов воздействия привилегированные и непривилегированные пользователи, как правило, связанная в нарушением прав;
4.3 (з) - перечень обеспечивающих систем перечислен в Приложении 1 к Методике.
"Методических" 4 уровня сетевой модели взаимодействия (аппаратный, системный, прикладной, пользователей) коррелируют и с 4-х уровневой моделью передачи данных (она же сетевая модель TCP/IP, сетевая модель DOD) и с 7-ми уровневой моделью OSI. Отличаются они в объединении / разбиении уровней / подуровней, которые по-разному детализируют процесс взаимодействия. В предлагаемом регулятором варианте сетевой модели взаимодействия добавлен уровень пользователей, который связан с информацией в пункте 4.3 (а). Подход рассмотрения архитектуры защиты информации через уровни взаимодействия систем можно увидеть и в ГОСТ Р 7498-2-99.

to CM
Там "запятая", т.е. перечисление: <... определяются на аппаратном, системном и
прикладном уровнях, на уровне сетевой модели взаимодействия, а также на
уровне пользователей ...>...
Так что, imho, сетевая модель (ISO/OSI) отдельно (если она вообще есть - а ну как на ОИ все взаимодействие по RS-232 какому-нибудь), а аппаратка, общесистемное ПО, прикладное ПО и работа пользователей (и воздействия на них) отдельно. Тем самым куда как бОльшее покрытие, чем классическое "давайте разберем угрозы безопасности для нашей локальной сети", ага...

2 CM Спасибо!

А есть ли способ проверить правильность выбора вида воздействия для объекта воздействия? Может на ресурсе можно найти каком-нибудь? На БДУ что-то я не увидел. И на сколько это критично при проверке регулятором? Или это на