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

Добрый день!
Составляю модель угроз по методике ФСТЭК
далее делаю выбор мер защиты и после ТЗ на СЗИ
и вот тут вопрос:
после внедрения СЗИ появляются новые объекты воздействия, и новые технологии (скажем у того же антивируса СУБД, или вэб страница для какого-то СЗИ), соответственно нужны СЗИ для защиты данных объектов
получается нужно по кругу запускать процесс моделирования, техпроекта и ТЗ на СЗИ?
ведь если изначально я укажу сразу все объекты, тогда будет вопрос, откуда появилась СУБД, если она не участвует в процессе обработки информации или тот же вэб?
По сути все СЗИ выбираются в техпроекте.

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

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

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

- взяли сертиф.СЗИ, абсолютно не относящееся к решаемой задаче (например, через классическое СЗИ НСД якобы прикрыли Угрозы уровня СУБД и веб-приложений, как было модно поступать не так давно, ага)

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

to Влад
Повторюсь, загоняетесь. У вас до внедрения ЦУ АВЗ не было МЭ в сети своего ОИ? А почему? Это сейчас, считай, обязательный элемент (за редким исключением)...
МЭ было, но защиты управляющего трафика СЗИ нет? А почему? Либо вы хоть как-то трафик с ИОД внутри ОИ защищаете (тогда аналогично с управляющим для СЗИ), либо в СЗИ уже имеется тот же ГОСТ TLS...
Защита трафика и МЭ были, контур управления (в том числе для СЗИ) сегментирован. Но ЦУ СЗИ у вас, положим, виртуализирован и боитесь вы угроз со стороны гипервизора? А почему? При таком подходе с 99% вероятностью у вас виртуализация и для основных компонент ОИ применяется - почему эти угрозы до сих пор актуальны?
Все в ажурн, но управляют СЗИ обезличенные админы наполовину из ИТ-службы? А почему? Ведь принципу разнесения ролей на Сисадмина и АдминаИБ уже очень много лет, и в большинстве случаев он обязателен...
Собственно, примеры утрирую, конечно, но исключительно ради наглядности. В корректной Комплексной Системе Защиты какое-либо внедряемое СЗИ создает новый набор Угроз (векторов атак, как угодно) только при стечении одного или более описанных выше обстоятельств...
Злым языкам, напоминающим про принцип +1! из теории сложности, парирую принципом 2+ рубежей защиты - тогда все становится на свои места. А в 2026 г., imho, это уже должно быть вбито в подкорку любого безопасника...
И да, разумеется, в любых СЗИ выявляются уязвимости со временем. И Fortinet, и SecretNet не дадут соврать, ага. И именно поэтому 2+ рубежей так важен в формате построения любой КСЗ...

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