модель угроз - это когда вместо очевидного разделения на плохишей и кибальчишей, внезапно возникает цветовая дифференциация штанов: сидят такие сотрудники ИБ и выдумывают креатив в духе "нам нужна роль настройщика logback приложения X", там появляются штатные единицы, у руководителей растет ЧСВ и пр. - ну вот в этом месте внезапно случается, что администратор логов может себе позволить нечто большее, а на вполне резонный вопрос: ну а что с того, можно же было аппендер с правильным кодом вставить или лог куда нужно направить (тут в первом приближении уже DoS)? тебе отвечают: в документации же не написано что при обращении по JNDI оно код выполнять может.

интересно было бы выслушать мнение почему у https://nvd.nist.gov/vuln/detail/CVE-2021-27568 скор 9.1, а у https://nvd.nist.gov/vuln/detail/CVE-2015-6420, которая в свое время вообще все подряд пробивала, всего лишь 7.5 (причем последнюю довольно криво анонсировали из-за чего много кто пострадал). Вопрос не в том что спорить/не спорить, обновляться/не обновляться, а в том, чтобы наводимый шухер был адекватен угрозе, в противном случае условно завтра все побегут обновлять томкаты, потому что там же тоже можно локатор JNDI прописать.

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

по калькулятору считают: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator, но нужно понимать, что корректность вектора, указанного в CVE, скорее исключение, чем правило, например для smart-json правильный вектор это AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N , т.е. выбивает 0, а нарисовали 9.1. Подобные несостыковки вызваны тем, что объективным анализом уязвимостей фактически никто не занимается (кроме злодеев, которые хотят нас взломать), поскольку процесс выглядит примерно так как описано ниже (дальше нужно учитывать, что про то как работают различные bug bounty программы я не в курсе, ибо не участвовал, поэтому в случае bug bounty что-то может идти иначе)

если нам повезло и мы нашли уязвимость, то есть три варианта (помимо того, чтобы просто опубликовать в твитере и наблюдать что будет):
- просто перетереть с вендором, и здесь все может закончиться или успешно или не успешно в самом широком понимании этого слова, ну например если выяснится, что наши исследования основываются на декомпилировании бинарников, то вместо удлинения ЧСВ можно на самом деле озалупиться: у вендора может быть какой-нить EULA явно запрещающий подобные действия
- продать кому-то: с одной стороны не факт что купят (здесь самыми ликвидными считаются уязвимости в браузерах, а повышение привилегий с оператора до dba в каком-нить оракле никому не интересно), с другой стороны как-то не особо красиво это (но это уже каждый сам для себя решает)
- идти по пути coordinated vulnerability disclosure (далее CVD)

В случае CVD первым делом нужно выбрать CNA и здесь уже нас ждет сюрприз: все крупные вендоры являются CNA, существует вариант выбрать какой-нить CERT, но они первым делом порекомендуют обратиться к соответствующему CNA, а выступать в качестве координатора будут только в крайнем случае (вендор не является CNA, либо нужно как-то обосновать почему мы не хотим общаться с вендором, например вендор не идет на контакт, мы не хотим светиться перед вендором), но здесь нужно понимать что у CERT нет функций оценки уязвимостей - они только координируют процесс, а оценивать будет или вендор (в случае если он выпускает бюллетень) или заявитель (если бюллетень выпускает CERT или заявитель), и в этом месте как раз возникают несостыковки связанные с правильной оценкой:
- заявителю условно выгодно чтобы скор был повыше - ЧСВ никто еще не отменил, в итоге получаем high вместо положенных medium или low
- в большинстве случаев вендор стремится занизить скор потому что критические уязвимости портят карму, а занизить его довольно просто: переключение Attack Complexity с Low на High сразу снимает единицу (причем наличие эксплоита само по себе подразумевает Low, но о наличии можно и умолчать и не разглашать информацию о том, где именно нашлась уязвимость), игра с Impact Metrics тоже позволяет еще пару очков скинуть - и вот получаем medium вместо high

Итог всего этого безобразия такой, что непонятно что делать на самом деле:
- далеко не факт, что в случае high нужно бросаться и срочно все обновлять
- с другой стороны medium вполне себе может быть на самом деле high - либо вендор сознательно скор занизил, либо наша среда выполнения, настройки или процессы довольно специфичные
- практически никто не публикует бюллетени, если информация об уязвимостях была получена не в результате CVD или где-то еще не всплыла, по крайней мере фразу в духе "This vulnerability was discovered by Cisco during internal testing" я видел только в бюллетенях от циски, да и то довольно редко

В целом же ситуация с ИБ довольно плачевная:
- по истине крутые чуваки в ОИБ не работают, а те которые работают в ОИБ предпочитают перебздеть чем недобздеть - я встречался с типами, которые в свое время постоянно обновляли серверную жаву после того как оракл публиковал бюллетени об очередном пробитии песочницы в апплетах
- различные сертификации/аттестации ПО работают тоже так себе, вот лично сталкивался со следующими случаями:
-- в ПО, уже сертифицированном по Common Criteria, выявлялась эскалация привилегий исключительно за счет вдумчивого чтения документации - как раз сценарий про цветовую дифференциацию штанов: пользователь, наделенный привилегиями чуть выше обычного, имел возможность повысить привилегии до суперпользователя
-- приглашенные пентестеры тупо не находили уязвимости, которые были уже опубликованы - толи сканер обновления не скачал, толи подписку не продлили
- иногда бизнес продавливает кривые решения, иногда подрядчик скрывает проблемы, однако чаще всего ИБ откровенно вставляет палки в колеса

Вам не мешало бы методичку перечитать...

РСБ.7Доступ к записям аудита и функциям управления механизмами регистрации (аудита) должен предоставляться только уполномоченным должностным лицам.



Какой в этом смысл? Создание очередного птичьего языка преследует только единственную цель - выкачивание денег из заказчика, здесь примерно как с юристами: что бы не произошло - юристы всегда в выигрыше (в случае ИБд - безопасники всегда не при делах). Ваша "модель угроз" - это даже не документ, а некое обоснование того, почему были выбраны те или иные меры защиты, причем это обоснование строится на совершенно неправильных концепциях, ну вот пример: ИБ определяет меры защиты для конкретной системы исходя из данных, которые в ней хранятся - это в корне неверно, поскольку:
- принципиально невозможно определить/спрогнозировать насколько важные данные могут оказаться в той или иной системе: условно есть какое-то текстовое поле в форме или возможность прикрепить файл - пользователи системы могут положить туда что угодно, тот же российский ФСТЭК пытается выкрутиться из этой ситуации за счет того, что указывает ограничения на объемы хранимой информации, т.е. предполагает что существуют специализированные системы, а на остальные плевать; в случае же, к примеру, PCI DSS если у аудиторов возникает подозрение что в системе потенциально могут храниться PAN - то иди и выполняй все требования
- пользователям свойственно везде устанавливать одни и те же пароли, поэтому защищать в инфраструктуре только какую-то конкретную систему не имеет никакого смысла

кто бюллетень публикует тот и является экспертом - такой вот процесс. Вообще гайды с примерами опубликованы - оттуда можно кое-какие знанияидеи почерпнуть, однако ясности оно особо не вносит: скор рисуют основываясь на известных прецедентах, например:
- для RCE C/I/A сейчас почти всегда ставят H/H/H
- для жавы даже потенциальные RCE через десериализацию засчитываются как 9.8 - выглядит это несколько притянутым за уши поскольку за последнее время вроде как весь опенсорс от приколов с RCE почистили и как найти уязвимое приложение - загадка, остался в основном DoS , но вот практика такова, что рисуют 9.8 поскольку никто толком не знает что там у приложения в classpath лежит



Вот нужно было с этого и начинать, а то модели угроз, ФЗ и прочие филькины грамоты

Можете дальше не отвечать, я и так знаю что там будет очередная пурга написана, то что ниже - это не для вас, а для тех, кто способен когда нужно включать мозги...

1. Так называемая "модель угроз" ни в коем случае "самостоятельным" документом не является, здесь правильно говорить, что это не документ, поскольку, согласно российским реалиям, он написан птичьим языком, а его целевая аудитория - это либо регулятор, либо аудитор (читать: ИБ пишут что-то сами для себя, чтобы избежать ответственности), и единственная цель этого "документа" - обосновать перед регулятором или аудитором минимальный набор реализованных мер исходя и данных, хранящихся в конкретной ИС и гипотетической "модели злоумышленника". Если бы эта реальная "цель" указывалась бы во введении, то вопросов бы к этому "документу" не было - все бы понимали, что это просто некая формальность необходимая для прохождения аудита, но при этом никакого отношения к информационной безопасности не имеющая, однако, ИБ действует иначе: раз бизнес "документ" подписал, то в случае чего с нас взятки гладки.
2. "нет уязвимых LDAP-серверов, которые и должны "предоставить" вредоносный код, то вам полностью NONE на уязвимость log4j2" - такое в "модель угроз" никак поместить нельзя - "документ" совсем не про это, где такое утверждение и имеет право быть, так это в "политике информационной безопасности" с формулировкой вида: "обращение из жавы к LDAP-серверам может таить скрытую угрозу, поэтому на соответствующие участки кода следует обращать особое внимание" (здесь сразу возникает очевидный вопрос: а какого хрена жава пытается до сих пытается использовать проприетарную схему в LDAP? Ну и ответ на него тоже очевидный: какие-то долбоклюи из оракла пытаются блюсти обратную совместимость, которая в данном случае никому не упала, но при этом вызывает массу проблем)
3. обычно упоротые поклонники бумажек, в т.ч. "политики информационной безопасности" на самом деле ничерта не умеют, однако, искренне полагают, что в случае использования какого-то стороннего ПО всенепременно наступит счастие - существует аж целая секта свидетелей статического анализитора, ну вот код, представленный ниже, в том же сонаркубе выглядит зеленым, хотя согласно MITRE в нем аж 2 уязвимости, одна из них - RCE:


4. здесь прав Stanislav Bashkyrtsev с утверждением "встроены в процесс разработки" - все остальное полная херня, не имеющая к ИБ никакого отношения

ну вот собственно как и было обещано:

CVE-2021-44832 :
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Судя по всему отсюда идет: https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/

Забавно что никто настоящий эксплоит не показывает, а просто пишут "вот смотрите, тут десериализация - это зашквар", однако оно уже два года как известно что в коте самый настоящий бэкдор живет: https://www.veracode.com/blog/research/exploiting-jndi-injections-java а те только недавно репу чесать начали: https://bz.apache.org/bugzilla/show_bug.cgi?id=65736