Архив рубрики: Темы

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Добавить комментарий

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решениеПро SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение.

В первой части определили, что SSVC это по сути опросник. Задаем значения некоторых параметров связанных с уязвимостью, получаем в результате решение по уязвимости (Track, Track*, Attend, Act).

В документе процесс принятия решения визуализируется в виде дерева по которому мы идем и в итоге получаем итоговое значение. Поэтому "параметры" там именуются как "точки принятия решения" ("decision points"). Типа приходим на такую развилку и решаем куда дальше идти. Кажется никакой смысловой нагрузки это не несет, а только запутывает. Поэтому для меня это будут просто "параметры".

Итак, параметры следующие:

1. (State of) Exploitation - (Состояние) Эксплуатации
2. Automatable - Автоматизируемость
3. Technical Impact - Техническое Воздействие
4. Mission Prevalence and Public Well-Being Impact - Целевая Распространенность (понимаю, что так себе перевод, но это хитро вводится, будем разбираться позже) и Воздействие на Общественное Благополучие

Часть из них могут принимать 2 значения, часть 3 значения. Значения "фиг его знает" умышленно нет. Когда выбрать значения сложновато "CISA определяет значение, которое является наиболее разумным предположением, основанным на предыдущих событиях" ("the most reasonable assumption based on prior events"). "Такой подход требует надежных исторических данных, и будущие события могут со временем изменить эти предположения." Что за события и исторические данные имеются ввиду сказать сложно. Подозреваю, что все же имеет место быть традиционный "пол, палец, потолок". Если есть идеи, напишите в комментах.

Всего 36 комбинаций параметров и все они представлены на 10-й странице SSVC Guide от CISA.
Каждый из этих параметров заслуживает детального рассмотрения и медитации, что я и планирую далее по этой теме делать.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям

1 комментарий

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям.

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

1. Отслеживать (Track). В настоящее время каких-то особых действий по уязвимости не требуется. Организация продолжает отслеживать новую информацию по уязвимости и проводить её переоценку. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

2. Внимательно отслеживать (Track*). Уязвимость содержит определенные характеристики, которые могут потребовать более тщательного мониторинга изменений. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

3. Уделять внимание (Attend). Уязвимость требует внимания со стороны нижнего уровня менеджмента (organization's internal, supervisory-level individuals). Необходимые действия могут включать запрос помощи или информации об уязвимости, приводить к публикации внутренних и/или внешних нотификаций об уязвимости. CISA рекомендуют устранять такие уязвимости быстрее стандартных сроков обновления.

4. Действовать (Act). Уязвимость требует внимания со стороны нижнего уровня менеджмента и ТОПов (organization's internal, supervisory-level and leadership-level individuals). Необходимые действия включают запрос помощи или информации об уязвимости, а также публикацию внутренних и/или внешних нотификаций об уязвимости. Как правило, внутренние группы встречаются и договариваются как будут реагировать на эту уязвимость, а затем выполняют согласованные действия. CISA рекомендуют устранять такие уязвимости как можно скорее.

Относительно американских уровней менеджмента я не особо в курсе, а гуглится там противоречивое, но в целом оно как-то так.

Как я понимаю о чем это вообще

Кажется во многих организациях, если не во всех, есть чатики безопасников, куда кидаются уязвимости для обсуждения. И там уже сообща решается вопрос стоит ли подрываться и оперативно фиксить уязвимость, или оно в регулярном процессе само зафиксится. Очевидно какие-то уязвимости не особо критичные и вряд ли будут эксплуатироваться в реальных атаках (множество вариаций Meltdown и Spectre например). По каким-то с ходу непонятно, но выглядит подозрительно и надо бы за ними приглядывать (недавняя SQLite RCE CVE-2022-35737). Какие-то очевидно нужно оперативно брать в работу, т.к. явно опасно и в целом понятно как устранять (какая-нибудь очередная RCE в Exchange или AD). А для некоторых уязвимостей нужно на ТОПов выходить, запускать их отдельными треками и патчить пожарном режиме (Log4Shell, MS17-010).

В принципе процесс это знакомый и естественный. Но так сразу и не скажешь по какому принципу в таком чатике принимаются решения по конкретной уязвимости, "экспертная оценка" во всей красе. И цель SSVC, насколько я могу судить, этот процесс несколько формализовать.

В следующей части начнем разбираться на основании чего решение принимается. И т.к. недавняя ФСТЭКовская "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств" тоже +- про это, хотя и реализация совсем другая, напрашивается некоторое сравнение / размышление как мы до жизни такой дошли. Stay tuned.

Про Microsoft Digital Defense Report 2022 (2/2)

Добавить комментарий

Про Microsoft Digital Defense Report 2022 (2/2)

Про Microsoft Digital Defense Report 2022 (2/2).

Теперь на что можно обратить внимание.

1. Неплохая схема "Understanding the ransomware economy" на 11 странице и вообще раздел про рансомварь норм. "Существуют отдельные организации, которые создают вредоносные программы, получают доступ к жертвам, развертывают программы-вымогатели и ведут переговоры о вымогательстве". Занимательно.
По нашей теме: "В 68% затронутых организаций не было эффективного процесса управления уязвимостями и исправлениями, а высокая зависимость от ручных процессов по сравнению с автоматическим исправлением привела к критическим уязвимостям. Производственная и критическая инфраструктура по-прежнему испытывает трудности с обслуживанием и исправлением устаревших систем операционных технологий (OT)."
Лол, а в 32% затронутых организаций был эффективный VM процесс и все равно пошифровали? Я бы на такие посмотрел. 🙂 Рекомендации по борьбе с рансомварью не сказать, что какие-то новые, но в целом толковые.

2. На 26 странице раздел про атаки на роутеры неплохой со схемами атак.

3. Раздел "Nation State Threats" это один сплошной фейспалм. Но, закрыв глаза на недоказуемые геополитические набросы, можно выделить интересное по нашей теме. "Ключевой тактикой [атак] стало выявление и быстрое использование незакрытых уязвимостей. Быстрое развертывание обновлений безопасности является ключом к защите." "В среднем требуется всего 14 дней, чтобы эксплойт стал доступен в дикой природе после того, как информация об уязвимости была публично раскрыта". Это выглядит как манипуляция, т.к. для подавляющего большинства уязвимостей ни эксплуатации вживую, ни эксплоитов не появляются. Но допустим.

4. Вынесу как отдельный пункт признание МS на странице 39, что относительно новая политика Китая, регулирующая порядок раскрытия информации об уязвимостях, самым положительным образом сказалась на информированности китайских государственных структур. Там конечно приводятся всякие голословные обвинения в offensive активностях, которые внимания не заслуживают. А вот то самое китайское "Положение об администрировании уязвимостей безопасности сетевых продуктов" внимание очень даже заслуживает, надо будет его отдельно разобрать. Если американцы так возмущаются, значит хорошие сапоги, надо брать (с).

5. Рекомендации относительно 0day уязвимостей неплохие. "Уделите особое внимание исправлению уязвимостей нулевого дня сразу же после их выпуска; не ждите, пока цикл управления исправлениями будет развернут. Документируйте и инвентаризируйте все аппаратные и программные активы предприятия, чтобы определить риски и быстро определить где нужно патчить."

6. Страница 53. "Нам срочно нужна последовательная глобальная система, в которой приоритет отдается правам человека и которая защищает людей от безрассудного поведения государства в Интернете." Лол, лучше б напомнили кто MS17-010 не зарепортил, а использовал втихую, и у кого потом EternalBlue утек. 🙃

7. На 64-ой странице рекомендации по IOT снова про патчинг. "Обеспечьте надежность устройств, установив исправления, изменив пароли по умолчанию и порты SSH по умолчанию." "Как и в других системах, в прошивке устройств IoT/OT широко использовались библиотеки с открытым исходным кодом. Однако устройства часто поставляются с устаревшими версиями этих компонентов. В нашем анализе 32 процента образов содержали не менее 10 известных уязвимостей (CVE), оцененных как критические (9,0 или выше). Четыре процента содержали не менее 10 критических уязвимостей старше шести лет."

8. На странице 97 пишут, что браузеры тоже не патчат "Изучив критическую уязвимость, затронувшую 134 версии набора браузеров (set of browsers), мы обнаружили, что 78 процентов, или миллионы устройств, по-прежнему используют одну из уязвимых версий через девять месяцев после выпуска исправления."

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон

1 комментарий

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон.

"Целью SSVC является помощь в определении приоритетности устранения уязвимости на основе воздействия, которое ее эксплуатация может оказать на конкретную организацию (организации)."

Ознакомимся 🙂

Завершаю про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК

1 комментарий

Завершаю про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК. Часть 3. Как тестировать и итоговые впечатления.

Какие вводятся проверки:

1. Сверка идентичности обновлений безопасности (Т001). Пользователям с русскими IP могут прилетать зловредные обновления, а другим пользователям нет. Поэтому качаем разными способами, сверяем контрольные суммы.

2. Проверка подлинности обновлений безопасности (T002). Контрольные суммы того, что скачали должны быть равны контрольным суммам, которые сообщает вендор (если он их сообщает).

3. Антивирусный контроль обновлений безопасности (Т003). Скормили двум и более антивирусам (от разных антивирусных вендоров) файлы с обновлением и натравили на сам хост после обновления, смотрим что продетектится.

4. Поиск опасных конструкций в обновлениях безопасности (Т004). Поиск в файлах обновления опасных конструкций с помощью индикаторов компрометации, YARA-правил и других способов. Тут же занимательное "контекстный поиск политических баннеров, лозунгов и другой противоправной информации".

5. Мониторинг активности обновлений безопасности в среде тестирования (Т005). Ставим обновления и ищем НДВ, о которых первой части было. Интересно, что добавили необходимость проведения "г) сигнатурного поиска известных уязвимостей." Похоже про то, что вендор-злодей может добавить известную уязвимость в продукт, чтобы это меньше было похоже на бекдор.

6. Ручной анализ обновлений безопасности (Т006). Это самое хардкорное. Выполняется, когда предыдущие проверки выявили что-то подзрительное. Если НЕ можем такой анализ провести, то просто говорим, что есть НДВ. Если можем, то проводим… Ох, дам цитатой 😱:
"а) анализ логики работы (в том числе дизассемблирование или декомпиляция бинарного кода при наличии соответствующих возможностей);
б) исследование компонентов обновления безопасности с помощью отладчиков и трассировщиков;
в) проверки наличия в обновлении безопасности ключевой информации (паролей, секретных ключей и другой чувствительной информации);
г) статического и динамического анализа (при наличии исходных кодов обновлений безопасности)."

Если в ходе ручного анализа (Т006) что-то нашлось, нужно написать во ФСТЭК и НКЦКИ. И всеми результатами тестирования рекомендуется делиться со ФСТЭК, а ФСТЭК их будет выкладывать в БДУ.

Набор проверок для проприетарного и опенсурсного софта отличается. Для проприетарного в целом логичный набор: Т001 и/или Т002; Т003 и/или Т004; Т005. Для опенсурсного почему-то вообще не требуется проводить сверку идентичности обновлений безопасности (Т001) и поиск опасных конструкций безопасности (Т004), зато видимо обязательно проводить ручной анализ обновлений безопасности (Т006). Логика за этим кроется какая-то хитрая, я её не понял. Как это сочетается с тем, что в описании Т006 пишут, что его проводим только если предыдущие что-то продетектили, тоже не понял.

Если попробовать резюмировать впечатления от документа, то всё это выглядит страшновато (особенно Т005 и Т006). Особенно с учетом громадных объемов обновлений Microsoft и ещё больших объемов для мейнстримных Linux дистрибутивов. А ведь там ещё тучи third-party софта. 🤯 На текущий момент сложно представить, что все эти работы будут скрупулезно проводиться внутри организаций так как это описано. Трудоемкость чудовищна. Будем посмотреть во что это реально выльется. Хочется надеяться, что все же в готовые фиды.

Продолжим про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК

1 комментарий

Продолжим про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК. Часть 2. На чём тестировать и чем тестировать.

Похоже исследователь может выбирать на чём тестировать обновления. Хоть на проде! 🙂

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

Требования к инструментами для тестирования есть, но довольно общие и странновато сформулированные:

"При проведении тестирования обновлений безопасности в соответствии с настоящей Методикой должны применяться инструментальные средства анализа и контроля, функциональные возможности которых обеспечивают реализацию положений настоящей Методики,

имеющие техническую поддержку и возможность адаптации (доработки) под особенности проводимых тестирований,

свободно распространяемые в исходных кодах

или

средства тестирования собственной разработки."

Насколько я понял это 3 опции для средств: гибкие коммерческие на поддержке, опенсурс, самописное. Про готовые комплексные решения для таких задач я не слышал, но возможно они теперь появятся.

Начнем про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК

4 комментария

Начнем про "Методику тестирования обновлений безопасности программных, программно-аппаратных средств" от ФСТЭК. Часть 1. Признаки добавления НДВ.

В методике есть перечень признаков того, что вендор принес зловредную функциональность вместе с обновлениями. 6 пунктов, в целом весьма неплохие.

"2.3. Для целей настоящей Методики к признакам недекларированных ​возможностей обновлений безопасности относятся:
​а) попытки обращений к файловой системе, базам данных, электронной ​почте и другой информации, не имеющие отношения к функционалу обновляемых ​программных, программно-аппаратных средств;
​б) недокументированные обращения к сторонним (неизвестным оператору) сетевым адресам и доменным именам, не относящимся к оператору ​информационной системы;
​в) системные вызовы, характерные для вредоносного программного обеспечения (например, попытки загрузки из сети «Интернет» библиотек и программных пакетов, не имеющих отношения к функционалу программного ​обеспечения, попытки перехвата сетевого трафика другого программного ​обеспечения, попытки мониторинга действий пользователей с другим ​программным обеспечением);
​г) потенциально опасные изменения в файловой системе в результате ​установки обновления, в том числе загрузка и установка недокументированных ​программного обеспечения, драйверов и библиотек, не имеющих отношения к ​функционалу обновляемого программного, программно-аппаратного средства;
​д) изменения конфигурации среды функционирования, не имеющие ​отношения к обновляемому программному, программно-аппаратному средству ​(например, появление новых автоматически загружаемых программ);
​е) отключение средств защиты информации и функций безопасности ​информации."

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