Архив рубрики: Регуляторика

Результаты сканирования RedCheck и ScanOVAL для Windows хостов

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

Результаты сканирования RedCheck и ScanOVAL для Windows хостов

Результаты сканирования RedCheck и ScanOVAL для Windows хостов. Есть коммерческий VM-продукт RedCheck от АЛТЭКС-СОФТ и бесплатный локальный сканер уязвимостей ScanOVAL от ФСТЭК, который также использует контент от АЛТЭКС-СОФТ. Было интересно посмотреть, а есть ли какая-то разница в результатах сканирования. Возможно какая-нибудь разница в контенте или в работе движка. Сравнение отчетов по CVE-шкам для нескольких тестовых Windows хостов с разной конфигурацией подтвердило: разницы в результатах сканирования нет, совпадение по 100% CVE. Так что, если считать ScanOVAL эталонным сканером, то RedCheck будет полностью соответствовать этому эталону. Уточнение: при сканировании RedCheck-ом использовался транспорт WinRM.

Посмотрел карту компетенций специалиста по ИБ от 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

Евгений Касперский аргументирует почему Apple iPhone зло в русскоязычном посте про Triangulation

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

Евгений Касперский аргументирует почему Apple iPhone зло в русскоязычном посте про Triangulation.

"Мы считаем, что главной причиной этого инцидента является закрытость iOS. Данная операционная система является «черным ящиком», в котором годами могут скрываться шпионские программы подобные Triangulation. Обнаружение и анализ таких угроз осложняется монополизацией Apple исследовательских инструментов, что создает для шпионских программ идеальное убежище. Иными словами, как я уже не раз говорил, у пользователей создаётся иллюзия безопасности, связанная с полной непрозрачностью системы. Что на самом деле происходит в iOS, специалистам по IT-безопасности неизвестно. Отсутствие новостей об атаках отнюдь не свидетельствует о невозможности самих атак — в чем мы только что убедились."

И как бы это всё правильно. И здорово, что KUMA зараженные устройства продетектила. Но вопрос в том, а как так получилось, что сотрудники Kaspersky, в значительной части специалисты по ИБ, пользуются на работе iOS устройствами? Теми самыми, которые представляют "идеальное убежище для шпионских программ". Может вводить требования, чтобы устройства Apple не тащили в корпоративный wifi, не использовали их для работы, а ТОПы возможно не использовали их вовсе?

PS: Это, конечно очень чувствительная и непопулярная тема, понимаю. Даже в этом канале, на который далеко не случайные люди подписаны, где-то больше трети с айфонами. 🙂
PPS: НКЦКИ в своём бюллетене связали утренний пресс-релиз и "операцию триангуляцию", так что можно считать это одним кейсом.

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

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

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

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

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

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 3/3. Поддержка методик ФСТЭК.

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

> 5. Что вы думаете о проекте "Руководства по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК? Ваше VM-решение позволит работать по этому процессу?

Сложно комментировать поддержку документа, который на момент эфира существовал только в проекте (но сейчас уже официально опубликован). 🙂 По факту обсуждения руководства и не было. Был только ответ Сергея Уздемира из АЛТЭКС-СОФТ (1:07:37), что есть такой документ и с ним нужно ознакомиться. В своем ответе Сергей упомянул также и методику оценки критичности уязвимостей ФСТЭК. Поэтому когда последовал следующий вопрос "насколько вы в своих решениях сейчас им [методикам] соответствуете?", то представители VM-вендоров стали отвечать про методику оценки критичности, а про руководство по управлению уязвимостями больше не вспоминали. 😉 А жаль, в руководстве есть что пообсуждать.

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

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Positive Technologies MaxPatrol VM я смотрел текущую реализацию, для R-Vision VM, АЛТЭКС-СОФТ RedCheck и Фродекс VulnsIO пока нет.

Основной проблемой видится то, что для приоритизации по методике ФСТЭК необходимо каким-то образом получать Temporal и Environmental метрики CVSS. Теоретически это можно как-то автоматически генерировать из дополнительной информации об уязвимостях и инфраструктуре, но на практике я пока этого не видел. Так что если вам будут рассказывать про реализацию этой методики, то задавайте вопросы про CVSS. 😉

> 4. Когда ваше VM-решение рекомендует установку апдейтов западного софта, учитывается ли при этом "Методика тестирования обновлений безопасности программных, программно-аппаратных средств" ФСТЭК? Является ли тестирование обновлений по методике частью VM-процесса?

Напрямую этот вопрос не задавался, но темы проверки обновлений несколько раз касались. Причем в основном при обсуждении автопатчинга. В том смысле, что автопатчинг вещь может и хорошая, но необходимость проверки обновления западного ПО как в рамках алгоритма НКЦКИ, так и по методологии ФСТЭК никто не отменял (2:29:29). И там же была реплика "Но это же не наша зона ответственности, по идее это зона ответственности IT" (2:30:15). Это конечно же не так, потому что IT уж точно не смогут оценить безопасность патчей по сложному процессу.

Поэтому варианта 2: либо VM-вендор возьмет задачу анализа обновлений на себя, либо это так и останется проблемой на стороне клиента.

В 2:51:02 Владимир Михайлов из Фродекс/VulnsIO предложил идею проверки обновлений на стороне гипотетического консорциума VM-вендоров: "заказчик, перед тем как накатить патч, установить новую версию ПО, должен проверить его по рекомендациям ФСТЭК. Он маловероятно это сам сделает. Ни один из VM-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏

Часть 2

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)"

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

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)". Дождались, ура! 🙂 На первый взгляд не сильно отличается от исходного проекта, но нужно аккуратненько посравнивать.