Архив метки: VMprocess

О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями

О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями. Сегодня последний день сбора предложений по доработке проекта руководства, поэтому захотелось дополнить пост про "нечеловеческий процесс" тем, что описанный процесс и не очень-то про автоматический детект уязвимостей. Поясню. Слово "сканирование" в тексте упоминается 9 раз в описании операций:

Этап мониторинга уязвимостей и оценки их применимости

• Принятие решений на получение дополнительной информации
• Постановка задачи на сканирование объектов
• Сканирование объектов

Этап контроля устранения уязвимостей

• Принятие решения о способе контроля
• Проверка объектов на наличие уязвимостей

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

1. Нет требований, что все активы в организации должны быть покрыты средствами анализа защищенности.
2. Нет требований, что в любой момент времени необходимо иметь актуальные данные о состоянии инфраструктуры с точки зрения имеющихся уязвимостей.
3. Нет требований к средствам анализа защищённости, как они должны работать и какие возможности по детектированию уязвимостей должны иметь.
4. Не предусмотрено процедуры оценки полноты и качества детектирования уязвимостей.

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

И, говоря об оценке качества детектирования, раз уж есть ScanOVAL (для российских Linux-ов и Windows), то почему бы не зафиксировать его статус в качестве эталонного средства анализа защищенности и не обязать периодически проводить сверку результатов детектирования ScanOVAL c результатами полученными от средств анализа защищенности, используемых в организации? Как минимум это привлечет внимание к проблеме качества детектирования уязвимостей (как соответствию эталону, так и улучшению эталона), которая сейчас, к сожалению практически не обсуждается.

Читая проект руководства по Vulnerability Management от ФСТЭК

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

Читая проект руководства по Vulnerability Management от ФСТЭК. Процесс не для человеков. Если брать совсем упрощенно, то в руководстве описан процесс, где на входе мы имеем общий поток уязвимостей (не только от сканеров, а вообще всех известных BDU/CVE уязвимостей!), который мы пропускаем по хитрому многоступенчатому процессу, несколько напоминающему Gartner Vulnerability Management Сycle. В рамках этого процесса мы делаем вывод о релевантности уязвимости и если уязвимость релевантна, устраняем её срочно, устраняем планово или применяем компенсирующие меры.

Главное, что вызывает озабоченность это кажущаяся окончательность принятия решения по уязвимости. Приняли решение, что уязвимость нерелевантная и забыли о ней. Приняли решение, что она не особо критичная и может быть устранена планово, закинули в неприоритетную задачку на IT и забыли об этой уязвимости (как минимум на время фикса).

Проблема в том, что входные данные об уязвимостях и об инфраструктуре будут постоянно меняться. Поэтому нерелевантная уязвимость может внезапно стать релевантной (и наоборот), а несрочная срочной (и наоборот).

Рассмотрим примеры:

1. Мы на этапе мониторинга уязвимостей и оценки их применимости пришли к выводу, что уязвимость нерелевантная. На следующей день изменились входные данные по уязвимости (уточнили тип, был EoP, стал RCE) или составу инфраструктуры (думали нет таких софтов у нас, а они появились) и она уже становится релевантной. А мы её уже убрали из рассмотрения и пропустили поэтому супер-критичную уязвимость.

2. Возьмем "этап оценки уязвимостей". Там есть "Определение уровня опасности уязвимости" - Расчет базовой, контекстной и временной метрик CVSS. Как минимум временная метрика требует постоянной актуализации. Там есть Exploit Code Maturity (E). Сегодня эксплоита для уязвимости нет, а завтра он появится.

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

- ранее нерелевантные уязвимости пускать в исправление (и наоборот)
- плановое исправление заменять на срочное (и наоборот)
- планировали патчить, а теперь решили компенсировать (и наоборот).

Естественно для десятков тысяч уязвимостей и достаточно большой инфраструктуры это не получится сделать силами героев-аналитиков с эксельками. Здесь требуется серьезная автоматизация. Аналитик в такой автоматизированной системе не должен принимать решение по конкретной уязвимости, его задача корректировать общий управляющий алгоритм.

В рамках руководства весь этот момент можно снять одним уточнением в разделе "2. ПРОЦЕСС УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ", что все уязвимости должны постоянно и непрерывно пропускаться по всему процессу и при изменении их статуса (релевантность, тип исправления) должны корректироваться фактические способы устранения уязвимостей. Причем не только уязвимости, которые детектируются в инфраструктуре сканерами, но и вообще все. Даже если уязвимости уже ранее устранялись. Безусловно, это сразу поменяет характер документа, по сути он превратится в ТЗ для разработки автоматизированной системы, но по-другому здесь вряд ли получится.

А вы уже прочитали проект руководства по Управлению Уязвимостями от ФСТЭК? Дали фидбек?

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

А вы уже прочитали проект руководства по Управлению Уязвимостями от ФСТЭК? Дали фидбек? 😏

Поигрался немножко с новой версией @kandinsky21_bot от Сбера. Местами неплохо генерит. 🙂

Проект руководства по Vulnerability Management от ФСТЭК

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

Проект руководства по Vulnerability Management от ФСТЭК. Уже в паблике. 26 страниц. (upd. после окончания сбора отзывов первоначальная ссылка перестала работать)

Что вас ждет внутри:

1. Общая схема VM-процесса и его связи с другими ИБ процессами организации
2. Перечень участников процесса и выполняемых ими операций
3. Подробное описание 5 этапов процесса, их схемы, описания операций:
3.1. Мониторинг уязвимостей и оценка их применимости
3.2. Оценка уязвимостей
3.3. Определение методов и приоритетов устранения
3.4. Устранение уязвимостей
3.5. Контроль устранения уязвимостей

Вещь абсолютно монументальная. Без шуток. Ничего более детализированного на тему VM-а я ещё не видел.

А вот будет ли это работать на практике? Зависит от нас и от наших правок:

"ФСТЭК России предлагает специалистам в области защиты информации заинтересованных государственных органов власти, организаций, субъектов критической информационной инфраструктуры рассмотреть проект методического документа и направить предложения по доработке указанного документа в соответствии с прилагаемой формой на адрес электронной почты otd22@fstec.ru.

Предложения и замечания по проекту методического документа принимаются до 17 апреля 2023 г."

Давайте все ознакомимся и дадим полезную обратную связь. Нам потом с этим жить и свои VM-процессы в соответствии с этими рекомендациями выстраивать.

upd. Мои посты-комментарии:

1. Читая проект руководства по Vulnerability Management от ФСТЭК. Процесс не для человеков.
2. О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями.

Сколько нужно VM-щиков, чтобы поменять лампочку?

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

Сколько нужно VM-щиков, чтобы поменять лампочку? Андрей Прозоров спрашивает про ИБ-шников, но я за них за всех не скажу, поэтому давайте сфокусируемся на решении задачи именно с точки зрения Управления Уязвимостями.

Для начала нужно понять, а какую задачу мы решаем. Нас волнует именно эта конкретная лампочка в этом конкретном месте или проблема шире: лампочки перегорают, их вовремя не заменяют, это создает угрозы, которые требуется минимизировать. Если первое, то достаточно одного письма в АХО (Административно-хозяйственный отдел) от сотрудника, которого бесит перегоревшая лампочка, этим сотрудником может быть VM-щик. Возможно потребуется ещё одно письмо через пару дней для эскалации. Если второе, то нужно строить нормальный процесс, вернее даже несколько связанных процессов:

1. Инвентаризация и аудит состояния (в первую очередь светимости). Мы вообще понимаем сколько у нас лампочек в организации, где они расположены, какого они типа, какой у них ресурс, какой регламент по их замене? Если нет, то это нужно собирать и поддерживать в актуальном состоянии (проверять, что в данных нет аномалий). В качестве исходных данных можно взять планы помещений, информацию по закупкам и остаткам на складе. Аудит может представлять собой периодический поэтажный обход, а возможно есть и более продвинутые способы мониторинга. Возможно в компании используются smart-лампочки, к которым можно относиться как к части IT-инфраструктуры? А возможно перегоревшие лампочки можно детектировать через анализ изображения с камер? Вариантов может быть много, нужно обсуждать с IT и АХО. VM-щик здесь должен быть заинтересован в первую очередь в том, чтобы процессом были покрыты все лампочки во всех помещениях (и во всех филиалах).

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

3.* Приоиритизация и применение компенсирующих мер. По мне если лампочка перегорела - она должна быть оперативно заменена. Но есть разные взгляды на этот вопрос. Например, лампочки могут перегорать слишком быстро и их будут не успевать менять. Как по мне, то это вопрос к инфраструктуре и архитектуре, почему нам так сложно лампочки заменять? Нормально ли это вообще? Но есть мнение, что нужно наоборот смириться с обстоятельствами и заменять лампочки только там где это ДЕЙСТВИТЕЛЬНО НУЖНО. Там, где люди уже ноги ломали, нужно менять в первую очередь, а там где просто мигать начала или из трех одна пока светит, менять во вторую очередь или вообще не менять. В принципе это также можно учитывать в заведении тасков. VM-щик здесь должен принимать во внимание кучу факторов о локациях и лампочках, чтобы ставить в приоритет к исполнению именно то, что требуется в первую очередь. Но как по мне, лучше этой ерундой не заниматься вовсе, если есть такая возможность.

Можно ли покрыть эти процессы одним человеком? Можно, но он будет постоянно переключать контекст, будет малоэффективно. Лучше чтобы это были разные люди, которые бы специализировались и целиком отвечали за свою часть работы. Т.е. от 2-3 человек, затем увеличивать при необходимости. 🙂

А есть ли смысл в "Vulnerability Management Сycle"?

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

А есть ли смысл в "Vulnerability Management Сycle"? Со временем все больше начинают подбешивать картинки циклов управления уязвимостями. Особенно картинка из "The New Vulnerability Management Guidance Framework" (2019). Хотя когда-то сам такое рисовал. 🙃

Чем плохо:

1. Создается иллюзия, что есть какие-то шаги, которые выполняются последовательно. "ручками похлопали, потом ножками потопали". Это представимо в рамках каких-то ежегодных аудитов, но Continuos VM так уже не работает. Все, что в "лепестках" должно идти одновременно, параллельно, автоматически. Нет "сканов-ресканов", есть процесс поддержания инвентори/детектов и его улучшения. Разбор и переоценка уязвимостей отдельный процесс. Пушинг их исправления тоже.
2. Зачастую VM-вендоры пытаются проектировать свои решения по этой схеме, стараясь всё, что отмечено как-то покрыть. Как правило, такие комбайны ни одну из заявленных задач толком не решают, а пользоваться ими так, как рекомендует вендор невозможно.

Вчера на Anti-Malware вышло интервью c Максимом Бронзинским

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

Вчера на Anti-Malware вышло интервью c Максимом Бронзинским. Он руководитель направления Vulnerability Management платформы Solar MSS. Более чем годное интервью, нерекламное. Я на прошлом двухчасовом эфире на Anti-Malware как раз говорил, что неплохо было бы VM вендорам больше времени уделять методологической работе: как внедрять VM процесс, какие люди должны этим заниматься и как. И вот наметки как раз в эту сторону. Сделал небольшой конспект.

Большая опасность внедрения VM процесса, что он выродится в Vulnerability Assessment. Т.е. с детектированием уязвимостей все будет ок, а до непосредственного исправления уязвимостей не дойдет. Это происходит из-за того, что ИБ с детектированием уязвимостей справляется, а с передачей в IT на исправление нет. Важно встроиться в IT-шные процессы исправления. Для этого нужно общаться с IT, доносить до них информацию об исправлении уязвимостей в наиболее конкретной и доступной форме.

Какие роли/квалификации есть в Vulnerability Management процессе со стороны ИБ:

1. Инженер
- Отвечает за инвентаризацию активов, стремится к максимальному охвату активов VM процессом.
- Правильно настраивает сканирование, стремится к тому, чтобы мы имели полную актуальную информацию об уязвимостях активов.

2. Аналитик
- Описывает, категоризирует, приоритизирует уязвимостей.
- Составляет плана на устранение уязвимостей (собирает несколько мнений, делает вывод на основе экспертности – это сложнее чем выгрузить TOP 50 уязвимостей из сканера).
- Подготавливает отчеты
-- Отчет для Бизнеса отражающий угрозы процессам.
-- Отчет для IT, критерии: понятность, удобность (в т.ч. машиночитаемость), решение о приоритизации.

Рекомендации к внедрению в организации:

- Защищать сразу ТОЛЬКО самые критичные хосты неправильно, пропускаем точки, где злоумышленник может закрепиться.
- Защищать сразу все не получится, т.к. будет слишком сложно добавиться исправления.
- Рекомендуется заходить постепенно, начиная с критических хостов; затем постепенно ужесточать SLA.
- Необходимо отслеживать сколько уязвимостей IT готовы взять в работу (в зависимости от типа уязвимых хостов) с согласованным SLA (в зависимости от типа и критичности уязвимости) и вгружать в IT правильный объем работы.

Рекомендации для продажи VM-процесса бизнесу:

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

Аутсорсить VM можно, но нельзя отдавать функцию принятия решения об исправлении, т.к. из организации это видно всегда лучше.

Александр В. Леонов

Управление Уязвимостями и прочее