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

2 СМ спасибо, это я понял) а при рассмотрении в модели угроз такая же последовательность? меня именно интересует, как их в модели угроз рассматривать?

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

Во-первых, действующая редакция Методики оценки УБИ (от 05.02.2021) не предусматривает оценку уязвимостей, а только оценку УБИ.
Во-вторых, формально уязвимости в методике не рассматриваются даже в качестве исходных данных (например, п. 5.3.2, 5.2.2 и др. подобные списки). В списке исходных данных включено описание векторов компьютерных атак (например, п. 5.3.2 (б)). А это не одно и тоже. Для применения такого описания в нем должно указываться вид нарушителя (источника угроз), уровень его потенциала / уровень возможностей, определять УБИ или иметь связь с уже выделенной УБИ в БДУ. Иначе применить такое описание векторов рамках методики будет не корректно.
Схожий подход стоит применять, когда к исходным данным УБИ относят сведения об уязвимостях в нормативных требованиях ФСТЭКа. Например, п. 14.3 Требований, утв. приказом ФСТЭК России от 11.02.2013 № 17. Такие сведения должны содержать информацию, позволяющие эти сведения применить в рамках методики.
По опыту взаимодействия с регулятором любое "творчество" поверх или дополнительно к установленным требованиям им не оценивается и не учитывается при условии, если оно не мешает проверить ему предусмотренное нормативкой.
Работу с самими уязвимостями рекомендую выносить за моделирование / оценивание УБИ и проводить ее в рамках прямо предусмотренного для этого мероприятия - анализа уязвимостей. Требования для этой меры установлены, соответствующий инструментарий имеется.

2 CM самое забавное, что требование рассмотрения уязвимостей в МУ выставляет регулятор ссылаясь на предпоследний абзац п.14.3 приказ 17. И я даже вроде их рассмотрел, но в недостатках мне выставили список уязвимостей БДУ которые там считают должны быть рассмотрены в моей МУ.

А в остальном согласен)

2 СМ спасибо

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

> ...самое забавное, что требование рассмотрения уязвимостей в МУ выставляет регулятор ссылаясь на предпоследний абзац п.14.3 приказ 17.

Здесь конкретный случай. Без ознакомления с текстом самих замечаний и документом, на который эти замечания составлены, ответить предметно или что-то рекомендовать будет довольно сложно. На практике с подобным пока не сталкивался.

to Константин
imho безотносительно принципов формализма и проч.:
1. Во вменяемом случае Модель нужна как часть мероприятий защиты, а не сама по себе. Т.е. результаты Модели должны отвечать на вопрос, "от кого/чего" и "с учетом каких нюансов" защищаемся...
2. Для актуализации УБИ на любой стадии жизненного цикла ИС достаточно 1 вменяемого реального сценария, а не пачки. Пачка нужна лишь в случае целевой защиты по конкретным направлениям (чего, видимо, очень хочется нашим SOC-коллегам, но пока, благо, на уровень обязаловки не вышло). И то, модуль здравого смысла подсказывает, что защищаться от конкретных техник крайне глупо - они меняются как перчатки в наши неспокойные дни. С тактиками чуть проще, но "векторная" защита в отсутствие иных подходов тоже далеко не панацея...
3. Уязвимости однозначно должны рассматриваться как потенциальный инструмент (специфический "интерфейс", ага) нарушителя. Причем по Методике-2021 уязвимости - это не только классические "уязвимости в ПО", которые есть в БДУ/CVE, а все возможные "недостатки" ИС (орг., техн., юр., лог. и т.п.). И регулятор в своем праве требовать их рассмотрение даже (в особенности) для проектируемых ИС. Вне зависимости от явного требования по Методике-2021. А то заложат набор opensource-софта с дырками 5+ летней давности, намоделируют всяческой ерунды, а потом уставшие безопасники ругаются и исправляют ситуацию...
4. В целом, сейчас Модели можно делать по принципу "джентельменского набора" или "кандидатского минимума", т.е. ограничиться только тем, что требуется в явном виде. Затем учесть вменяемые указания регулятора (при необходимости согласования с ним вообще). С невменяемыми однозначно ругаться, ибо это повышает экспертизу самого регулятора - как показывает практика, его эксперты тоже не шибко разбираются как в Методике-2021, так и в принципах/методах построения непротиворечивой КСЗ (особенно по оптимуму "эффективность - функциональность - экономичность"). И переходить к менее "теоретическим" работам. Но ОИ ОИ рознь, поэтому в некоторых случаях имеет смысл рассмотреть куда бОльшее количество состояний, чем просит Методика-2021. Если, конечно, это в будущем - на стадиях проектирования, внедрения, оценки, эксплуатации - избавит от "узких мест" и проблем иного рода...

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

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

*на правах рубрики "Точки над i"*
Редакция нашего текстовещания в рамках указанной рубрики приводит новые комментарии к наболевшему вопросу целевой аудитории: "надо ли по умолчанию актуализировать потенциал нарушителя, прописанного в соответствующем Приказе ФСТЭК для соответствующего класса (уровня, категории) объекта, при моделировании"...
Намедни в редакцию принесли выписки из Модели, разработанной непосредственно экспертами ФСТЭК России. По результатам их анализа редакция обращает внимание наших читателей на следующие выводы в разделе, касающемся нарушителей: "В соответствии с пунктом 25 Приказа ФСТЭК России №17 ... для ... ТАКОГО-ТО КЛАССА ГИС должна обеспечиваться защита от угроз безопасности информации, связанных с действиями нарушителей с ТАКИМ-ТО ПОТЕНЦИАЛОМ". Дополнительно редакция обращает внимание на наличие в Модели отдельного обоснования, почему нарушители с потенциалом выше предусмотренного п. 25 Приказа 17 не рассматриваются, а также на проведение дальнейшего анализа УБИ в ключе актуальных нарушителей (ТАКОЙ-ТО ПОТЕНЦИАЛ и ниже)...
Резюме редакции: для ГИС, положим, класса К2 нельзя исключить (не рассматривать в качестве актуальных) нарушителей Н2 и, соответственно, нельзя автоматически отказаться от рассмотрения УБИ, связанные с нарушителем Н2. Актуальность подобных УБИ - это уже тема для отдельного эфира, либо самостоятельного изучения. Но главное, что отмазки в стиле "Моделирование отдельно ибо этап Требований (поэтому у нас все УБИ только для Н1), а Проектирование отдельно ибо этап Разработки (поэтому лепим какие-то меры защиты вроде как для нейтрализации УБИ от Н2, но выбираем их пальцем в небо, потому что Модель Н2 не рассматривала)" не канают...

ЗЫ Злым языкам, считающим, что все вышесказанное - ничего не доказывающие больные фантазии редакции и лично тов. oko ИЛИ всего лишь единичный прецедент (ошибка) неизвестных науке экспертов ИЛИ еще что-нибудь подобное - настоятельно рекомендуется еще раз подумать над принципом комплексности в ЗИ/ИБ или, pro bono commune, сменить-таки профессию...

2 oko
Я правильно понимаю, что для К2 надо рассматривать угрозы из БДУ для нарушителя со средним потенциалом?

2 oko Можно ли для К2 определить нарушителя H1, а уже угрозы рассматривать и для H3 ?