Архив метки: ФСТЭК

Первоначальные намётки по ОСОКА

5 комментариев

Первоначальные намётки по ОСОКА. 🙂 Думаю должно быть три группы метрик:

▪️Базовые
▪️Эксплуатационные
▪️Инфраструктурные

1. Базовые метрики будут ровно такие же как в CVSS v3.0/3.1. Почему? Это текущий стандарт, использующийся с 2015 года. Для большей части уязвимостей из NVD можно будет взять CVSS v3 Base вектор как он есть. Для уязвимостей, у которых доступен только CVSS v2 Base вектор есть более-менее рабочие способы конвертации в v3, которые можно будет взять за основу. Когда CVSS v4 появится в NVD, проблемы с конвертацией v4->v3 будут только из-за исключения метрики Scope, её придется как-то генерить, скорее всего из Impact Metrics для Subsequent Systems (но это неточно). Также для User Interaction будет 3 значения, а не два, но это тривиально схлопывается. В общем, оставаться на базовых метриках полностью повторяющих CVSS v3 нам должно быть достаточно комфортно.

2. Эксплуатационные предлагаю сделать такие:

Exploit Maturity: Not Defined (X), High (H), Functional (F), Proof-of-Concept ℗, Unreported (U) - эту штуку можно заполнять через анализ баз эксплоитов/малварей и получать из CVSS Temporal вектора некоторых вендоров (например Microsoft).

Exploitation Activities: Not Defined (X), Reported ®, Unreported (U) - это можно заполнять на основе баз отслеживающих эксплуатацию типа CISA KEV или AttackerKB. Фактов эксплуатации in the wild никогда не было в CVSS и не будет в 4.0 - преимущество ОСОКи. 😉

Exploitation Probability: Not Defined (X), High (H), Medium (M), Low (L) - это можно заполнять на основе EPSS. Я думаю, что EPSS пока ещё полный шлак, но возможно такие системы скоро станут гораздо лучше и неплохо бы заранее их поддержать.

Кажется с такими метриками по эксплуатации можно будет не упахиваться ручным описанием и получить приоритизацию с учётом того, что нужно зафиксить ASAP.

3. Инфраструктурные думаю лучше взять ровно как в методике ФСТЭК, чтобы повысить шансы на официальное признание. 😉 Кроме того, они в принципе неплохие. Во всяком случае всяко лучше абстрактного CVSS Environmental. Хотя и придется все активы покрыть VM-процессом и знать об активах хотя бы их тип и доступность на периметре.

Тип компонента информационной системы, подверженного уязвимости
- Не определено
- Компоненты ИС обеспечивающие реализацию критических процессов (бизнес-процессов), функций, полномочий
- Серверы
- Телекоммуникационное оборудование, система управления сетью передачи данных
- Рабочие места
- Другие компоненты

Количество уязвимых активов
- Не определено
- Более 70%
- 50-70%
- 10-50%
- Менее 10%

Влияние на эффективность защиты периметра системы, сети
- Не определено
- Уязвимое программное, программно-аппаратное средство доступно из сети «Интернет»
- Уязвимое программное, программно-аппаратное средство недоступно из сети «Интернет»

Конечно, нужно будет конкретные формулировки подправить, чтобы было единообразна с другими метриками, а подробности убрать в руководство по заполнению, но по смыслу должно быть ровно так как в методике ФСТЭК.

Как вам?

По итогам выступления на Positive Customer Day

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

По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅

В целом же, по итогам Q&A для себя сформулировал следующее:

1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.

Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.

На Positive Hack Days я в этом году не выступал (не считая пары слов на награждении), зато буду выступать на Positive Customer Day в четверг 22 июня

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

На Positive Hack Days я в этом году не выступал (не считая пары слов на награждении), зато буду выступать на Positive Customer Day в четверг 22 июня. Доделал слайды для доклада "Управление Уязвимостями и методики ФСТЭК: оценка критичности, анализ обновлений, процесс". 😇 Доклад будет по мотивам постов про нормативку. Также подсвечу CVSS 4.0 и ОСОКу. В части руководства по VM-процессу кратко рассмотрю 3 вопроса, которые меня больше всего волнуют:

1. Окончательность решения по статусу уязвимости и способу исправления. Здесь есть важные изменения между проектом руководства и релизом. 😉
2. Качество детекта и полнота покрытия активов.
3. Безусловный процесс регулярного патчинга.

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

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

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0? Мне это тоже интересно.

Имхо, CVSS это не священная корова и держаться за него не стоит:

1. CVSS это результат заполнения довольно сомнительного и субъективного опросника. То, что у ресерчера, вендора и у NVD не совпадают CVSS для одной и той же уязвимости это норма.
2. CVSS v2, v3 и v4 несовместимы между собой. Сейчас в NVD есть уязвимости без CVSS, только с v2, с v2 и с v3, только с v3. Будьте уверены, что переход на v4 зоопарк усугубит. Нужно ли это и в БДУ тянуть?
3. Положа руку на сердце, кто при приоритизации уязвимостей полагается исключительно на CVSS? Это один из факторов. И не самый важный. Основная ценность CVSS, что Base метрики предоставляются NIST-ом открыто и бесплатно. А Temporal метрики никто не предоставляет, поэтому их и не используют. Не говоря уж об Environmental, которые надо самим заполнять.

Поэтому я бы рекомендовал не переходить на CVSS v4, а сделать следующее:

1. Создать свой опросник с калькулятором а-ля CVSS. Также с векторами (записываемыми в строчку) и скорами. Назвать как-нибудь оригинально, например "Общая Система Оценки Критичности Автоматизируемая" (ОСОКА). 😉 Какой конкретно это должен быть опросник - предмет отдельного обсуждения. Я бы делал его максимально простым и кратким, пусть даже в ущерб точности оценки. Лишь бы базовый скор явно критичных уязвимостей был около 10, а явно некритичных был около 0. Инфраструктурный компонент из методики оценки критичности уязвимостей также учесть в ОСОКА (сделать как в Environmental метриках CVSS).
2. САМОЕ ГЛАВНОЕ! Выпустить методические указания как использовать CVSS v2, v3, v4 в качестве входящих данных для получения вектора ОСОКА. Очень желательно, чтобы базовая часть ОСОКА автоматом получалась из Base метрик CVSS v2, v3, v4, иначе скорее всего это не взлетит.
3. В перспективе заменить все упоминания CVSS и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.

Посмотрел карту компетенций специалиста по ИБ от Positive Technologies

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

Посмотрел карту компетенций специалиста по ИБ от Positive TechnologiesПосмотрел карту компетенций специалиста по ИБ от Positive TechnologiesПосмотрел карту компетенций специалиста по ИБ от Positive Technologies

Посмотрел карту компетенций специалиста по ИБ от Positive Technologies. Что там с VM-специалистами? Карту презентовали 13 марта, но мне она только сейчас на глаза попалась. К сожалению, по PDF-ке нельзя искать, поэтому приходится смотреть только глазками.

Есть 4 специализации как-то связанные с уязвимостями:
- "Аналитик по оценке уязвимостей (пентенстер)" в группе "Мониторинг событий ИБ и реагирование на события ИБ"
- "Аналитик данных в области эксплуатации уязвимостей информационных систем" в группе "Аналитика ИБ"
- "Аналитик данных об уязвимостях эксплуатируемого ПО (разведка)" в группе "Аналитика ИБ"
- "Аналитик данных об уязвимостях эксплуатируемой сетевой инфраструктуры (разведка)" в группе "Аналитика ИБ"

2 последние специализации можно было бы определить как Vulnerability Intelligence, но обязанности там какие-то совсем загадочные. Что-то на редтимовском видимо. 🙂

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

Поэтому я бы сделал так:

1. Приписку "пентестер" перенес в специальность "Аналитик данных в области эксплуатации…"
2. Обязанности "Измеряет эффективность многослойной архитектуры защиты" тоже перенес бы в специальность "Аналитик данных в области эксплуатации…". Оценивать эффективность EDR-ов тоже пентестерская тема.
3. "Аналитик по оценке уязвимостей" переименовал бы в "Специалист по управлению уязвимостями". Если есть специалист по реагированию на инциденты, то чего бы не быть специалисту по управлению уязвимостями. 😉
4. Добавил бы этому "Специалисту по управлению уязвимостями" обязанностей по работе с уязвимостями в рамках руководства ФСТЭК: мониторинг известных уязвимостей, оценка применимости, оценка критичности уязвимостей, определения методов и приоритетов устранения, постановка задач на устранение, контроль устранения. Также добавил бы того, что нет в этом руководстве, но что критично: оценка качества детектирования уязвимостей средствами анализа защищенности и оценка покрытия инфраструктуры организации VM-процессом.
5. Обязанности "Выполняет оценку систем и сетей…" дополнил бы фразой "в части процесса управления уязвимостями", а то слишком общо получается и напоминает уже IT-аудит.

И вот в таком виде можно было бы жить. 🙂

Руководство ФСТЭК по Управлению Уязвимостями

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

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 2. Что определяет руководство?

Продолжаем увлекательное сравнение. Видим в Общих положениях новый пункт 1.2.

"Руководство определяет состав и содержание работ по анализу и устранению уязвимостей (далее – управление уязвимостями),"

Отмечаем: "управление уязвимостями" = "анализ и устранение уязвимостей" ❗️

"выявленных в

программных,
программно-аппаратных средствах"

Ага, вот куда ПО и ПАС из названия документа переехали. ПО и ПАС относящихся к чему?

"информационных систем,
информационно-телекоммуникационных сетей,
автоматизированных систем управления,
информационно-телекоммуникационных инфраструктурах [м.б. инфраструктур?] центров обработки данных, на базе которых функционируют эти системы и сети (далее – информационные системы)."

Т.е., если у вас есть ИС, ИТС, АСУ, центр обработки данных - будьте любезны внедрить VM для ПО и ПАС. 😉👍

Часть 1

Руководство ФСТЭК по Управлению Уязвимостями

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

Руководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 1. Общая структура.

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

1. Скорректировали название. Было "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)", стало "Руководство по организации процесса управления уязвимостями в органе (организации)". Новое название кажется более удачным. Тут и акцент именно на процесс, и вроде указывать уязвимости чего тоже смысла нет.
2. Общая структура документа не изменилась. Но добавили приложение с описанием BPMN элементов на схемах - полезная вещь.
3. Текстовая часть расширилась. Проект был на 29 страниц, релиз на 33 (включая одну страницу-приложение).