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

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

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

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

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

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

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

Проект руководства по 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"?

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

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

Чем плохо:

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

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

Вчера на 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 можно, но нельзя отдавать функцию принятия решения об исправлении, т.к. из организации это видно всегда лучше.