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

Разбираю ответы на мои вопросы с эфира 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

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

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

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

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 2/3. Эталонный сканер.

Вопрос был такой:  

> 2. Вы согласны, что бесплатный сканер ScanOVAL ФСТЭК может рассматриваться как эталонное средство детектирования уязвимостей для хостов под управлением Windows и отечественных Linux-ов?

Зачем я задал этот вопрос? Давайте начнем с того, что такое эталонный сканер уязвимостей.

Начнем просто с эталона. Возьмем, для примера, эталон единицы измерения массы. "Международный прототип (эталон) килограмма хранится в Международном бюро мер и весов (расположено в Севре близ Парижа) и представляет собой цилиндр диаметром и высотой 39,17 мм из платино-иридиевого сплава (90 % платины, 10 % иридия)." Вряд ли вы будете использовать этот цилиндр для того, чтобы отвесить себе килограмм помидоров. Скорее всего вы просто положите свои помидоры на электронные весы. А вот для того, чтобы проверить, что эти весы работают корректно, некоторый эталон очень даже пригодится.

Теперь по поводу сканеров уязвимостей. Не секрет, что если вы просканируете один и тот же хост различными сканерами уязвимостей, то вы получите различные же результаты. Иногда практически не пересекающиеся по CVE идентификаторам. Тут дело не в том, что различные VM-вендоры поддерживают различные наборы Third-party софтов, это ещё простительно. Но даже если мы ограничимся только детектированием уязвимостей ОС, по KB-шкам Windows или бюллетеням безопасности Linux, всё равно разница будет, потому что каждый VM-вендор реализует свои собственные алгоритмы детектирования. А уязвимость на хосте либо есть, либо нет. Это вещь объективная. И если результаты различаются, значит как минимум одно из средств детектирования работает неправильно.

Есть ли у нас такой сканер уязвимостей, результаты детектирования которого мы могли бы принять за эталон? Есть один претендент - ScanOVAL. Он общедоступный, бесплатный и самое главное выпущен ФСТЭК. С ним вполне удобно сравнивать результаты детектирования уязвимостей для Windows и российских Linux-ов.

Так готовы ли VM-вендоры признать ScanOVAL за эталон качества детектирования уязвимостей?

Каверзность вопроса в том, что если ответить "да", то все различия при сравнении со ScanOVAL будут автоматически являться ошибками. А если ответить "нет", то получается сканер уязвимостей регулятора некорректно уязвимости детектирует? Давайте-ка с этого момента поподробнее. 😏

Любой ответ представителя VM-вендора, сулит проблемы для него. А для клиентов наоборот - любой ответ выгоден, т.к. подсвечивает проблемы детектирования уязвимостей и улучшает либо возможности продукта VM-вендора, либо ScanOVAL. Ну или хотя бы дискуссию провоцирует о качестве детектирования, и то неплохо.

В итоге вопрос про ScanOVAL задали в 2:22:01 в таком виде:

"А у нас ещё такой провокационный немного вопрос в сторону присутствующих здесь вендоров. А что если просто взять ScanOVAL и с помощью умелых рук организовать весь процесс, чем это будет слабее Enterprise решений?" 🤦🏻‍♂️

Как видите, вопрос не про эталон, не про качество сканирования, а из серии можно ли выкопать котлован малой сапёрной лопаткой. Ну и ответы соответствующие. 🤷‍♂️

В общем, жаль, что обсуждение этой темы не получилось, но попробуем пропедалировать её в следующий раз. 😉

Часть 1

Все, о чем вы хотели, но боялись спросить регулятора

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

Все, о чем вы хотели, но боялись спросить регулятора

Все, о чем вы хотели, но боялись спросить регулятора

Виталий Лютиков, ФСТЭК России. Ответ про уязвимости в контексте использования зарубежных NGFW:

"Сам факт использования зарубежного сетевого экрана, особенно в КИИ, не столько критичен, сколько использование уязвимого зарубежного межсетевого экрана. Поэтому я всем рекомендую, у кого на периметре стоят такие средства, озадачиться вопросом анализа уязвимоcтей (которые сейчас по некоторым классам продуктов всё чаще и чаще появляются, и критичные, в том числе эксплуатируемые удаленно) и формированием компенсирующих мер, выработкой сигнатур, постановке на мониторинг, анализом событий и т.д. Для того, чтобы эти риски компенсировать. Вот это более критично чем факт использования зарубежного сетевого экрана, по крайней мере до 25го года."

"Если отсутствие технической поддержки привело к наличию уязвимости, которое не компенсируется другими способами или средствами, то тогда данное нарушение мы рассматриваем с соответствующими санкциями. Если [компенсирующие меры] выработаны, тогда рекомендация по переходу к соответствующему сроку, но санкции не применяются."

Владимир Бенгин, Минцифры России. Рассказал про положительный опыт багбаунти Госуслуг. Нашли десятки уязвимостей, хотя ожидалось, что после всех пентестов ничего не найдут. Опыт будут масштабировать и будут продвигать. Завтра будут подробности.

Ещё было пара реплик, что "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК могут на днях зарелизить. Видимо об этом было на предыдущих секциях. Ждем. 🙂

Завтра открывается фестиваль PHDays 12!

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

Завтра открывается фестиваль PHDays 12! Непосредственно про Vulnerability Management я выступлений в программе не нашел. Но есть разборы конкретных уязвимостей и выступления на смежные темы, которые я себе наметил. Возможно кому-то тоже будет интересно. Первый день буду слушать фоном в онлайне, а в субботу планирую быть на площадке в Парке Горького.

Обязательно загляну на стенд Positive Technologies с MaxPatrol VM, вчера на AM Live обещали показать реализацию оценки критичности уязвимостей по методике ФСТЭК! 🔥Очень интересно откуда они временные и контекстные метрики CVSS берут, а также тип уязвимого актива. 🙂

19 мая

🔸12:00–13:00 Кто, как и зачем атакует Linux-инфраструктуры. DEFENSE
Олег Скулкин. BIZONE

🔸13:45–14:45 Все, о чем вы хотели, но боялись спросить регулятора. БИЗНЕС ТРЕК 1
Виталий Лютиков, ФСТЭК России
Владимир Бенгин, Минцифры России
Алексей Лукацкий, Positive Technologies

🔸15:00–16:00 Интернет-картография в 2023 году. Чего не может Shodan. OFFENSE
Сергей Гордейчик, CyberOK
Александр Гурин, CyberOK

🔸15:00–16:00 SCAзка о SCAнерах. DEVELOPMENT
Виктор Бобыльков, Райффайзенбанк
Дмитрий Евдокимов, Luntry

🔸17:00–18:00 Опыт тестирования и верификации ядра Linux. DEVELOPMENT
Алексей Хорошилов, ИСП РАН

🔸17:15–18:30 Киберсуверенитет: вклад открытого кода. БИЗНЕС ТРЕК 1
Сергей Гордейчик, CyberOK
Кирилл Севергин, АЛРОСА
Сергей Золотарев, Arenadata
Александр Гутин, ГК «Астра»
Иван Панченко, Postgres Professional

-------------------------

20 мая

🔹11:00–11:40 People as code: сотрудник как актив и объект защиты. БИЗНЕС ТРЕК 2
Сергей Волдохин, «Антифишинг»

🔹13:00–14:00 Внедрение кода в процессы из контекста ядра Linux. OFFENSE
Илья Матвейчиков

🔹13:00–14:00 Как обезопасить от санкций ваш открытый проект на GitHub. DEVELOPMENT
Александр Попов, Positive Technologies

🔹14:00–15:00 История одной уязвимости. DEVELOPMENT
Андрей Наенко, Kaspersky

🔹14:00–15:00 Топ-10 артефактов Linux для расследования инцидентов. DEFENSE
Лада Антипова, Angara Security

🔹15:10–15:40 Отечественные ОС сегодня: вызовы, задачи, перспективы. ЭФИРНАЯ СТУДИЯ
Александр Попов, Positive Technologies
Алексей Хорошилов, ИСП РАН
Владимир Тележников, «РусБИТех»

🔹16:00–17:00 Антология способов программного мониторинга и защиты Linux в пользовательском пространстве. OFFENSE
Тимур Черных, F.A.С.С.T.

🔹17:00–18:00 Positive Awards. ЭФИРНАЯ СТУДИЯ

Методические документы регуляторов, связанные с Управлением Уязвимостями

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

Методические документы регуляторов, связанные с Управлением Уязвимостями. В презентации, которую я сейчас готовлю к ISCRA Talks, будет слайд про документы регуляторов связанные с VM-ом, выпущенные за последние 1,5 года. Если я что-то важное пропустил, напишите мне, пожалуйста, в личку или комментом в пост в ВК.

1. НКЦКИ "Критерии для принятия решения по обновлению критичного ПО, не относящегося к open-source". Рекомендательный алгоритм, помогающий принять решение: установить обновление с риском привнести НДВ (недекларированные возможности)/блокировку функциональности или не обновлять с риском получить эксплуатацию уязвимости. Этого алгоритма я касался в выступлении на PHDays 11 и писал скрипты автоматизации проверок по нему в рамках опенсурсного проекта Monreal.

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

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

4. ФСТЭК "Рекомендации по безопасной настройке операционных систем Linux". Рекомендации распространяются на настройку НЕсертифицированных ОС (Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Я разбирал эти рекомендации.

5. ФСТЭК "Руководство по организации процесса управления уязвимостями в органе (организации)". Подробное описание этапов процесса, участников процесса и выполняемых ими операций. Я написал комментарии к проекту руководства "процесс не для человеков" и "место автоматического детектирования уязвимостей".

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies

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

Vulnerability Management чек-лист для финансовых организаций от Positive Technologies. Статья вышла в BIS Journal 22 февраля, но я только сейчас её увидел. Мне в целом, импонирует подход PT к VM процессу. Особенно то, что Евгений Полян и Анастасия Зуева транслируют в своих выступлениях. Поэтому мимо их совместной статьи пройти никак не мог. Собрал краткую выжимку, за деталями рекомендую обратиться к исходной статье.

1. ИТ и ИБ должны дружить и вместе работать над исправлением уязвимостей, иначе ничего не получится.

2. Если не исправлять уязвимости, это может привести к серьезным инцидентам и недопустимым событиям для бизнеса.

3. Разрабатываете/внедряете новую систему? Проверьте, что в ТЗ учтены:
3.1. Технологические окна для регулярных обновлений
3.2. Возможность сканирования (от меня: лучше даже шире - проверить, что есть средство детектирования уязвимостей для системы)
3.3. План реагирования на появление новых опасных уязвимостей для ИТ и ИБ

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

5. Три шага к организации процесса управления уязвимостями:
5.1. Определить перечень недопустимых для организации событий c бизнесом и ТОПами
5.2. Определить риск-рейтинг активов
5.3. Составить регламент работы и обслуживания каждого типа активов, согласовать с бизнесом и IT

6. Зафиксируйте роли подразделений:
6.1. Руководство компании - приоритеты и перечень недопустимых событий
6.2. Топ-менеджмент - перечень наиболее важных сервисов
6.3. ИТ-подразделение - обновление в соответствии с SLA
6.4. ИБ-подразделение - приоритеты устранения уязвимостей, критерии эффективности процессов ИБ, контроль уровня защищенности, определение ключевых активов

7. Определение сроков обновления систем и регламента обновлений:
7.1. Выделить ключевые активы (контроллеры домена, серверы Exchange, системы управления виртуализацией, рабочие станции администраторов и т.д.)
7.2. Установить регламенты по обновлению, определить SLA (и что делать если SLA будет нарушаться)
7.3. Для зарубежного ПО использовать алгоритм НКЦКИ и результаты тестирования обновлений ПО от ФСТЭК

Что мне нравится в этой статье: большой акцент на регулярных обновлениях. Ситуация когда месяцами-годами системы не патчатся и все ждут ИБ-шников, которые должны просканить и поставить задачу на обновление - это не норма. IT-шник, если есть обновление безопасности - иди ставь! ИБшник (VM-щик) нужен для того, чтобы удостовериться, что все хорошо и по регламенту работает, а не для того, чтобы всех пушить постоянно. Ну и для того, чтобы бить в рынду, когда появляется что-то реально критичное.

Что не особо нравится: "три шага" к организации процесса управления уязвимостями это, конечно, что-то из серии научной фантастики. Просто прекрасно, если где-то это действительно без оговорок запустилось, но это скорее не рекомендация к команде ИБ, а реклама крутого консалтинга, который такие штуки делать умеет. Про планирование новых проектов с требованиями по VM тоже все правильно, но отстаивать эти требования также будет ох как не просто. Наиболее практически полезной кажется идея, что наводить порядок нужно с ключевых активов и разгребаться дальше насколько ресурсов хватит.

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux

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

Бесплатный сканер уязвимостей для Linux от ФСТЭК + OVAL контент для Linux. Продолжаю обозревать крутые штуки от ФСТЭК.

У меня в декабре был пост, что если бы я был регулятор, то обязал бы вендоров сертифицированных Linux-ов привести в порядок бюллетени безопасности, а идеально было бы OVAL контент предоставлять. Так как это делает RedOS. И в каком-то виде это осуществилось. 🤩 Ну не силами Linux-вендоров, а силами ИБ-вендора и регулятора. И с существенными ограничениями. Но факт - вот тебе OVAL-контент для сертифицированных Linux-ов в паблике и бесплатный сканер, который с ним работает.

На сайте ФСТЭК-а выложили бесплатный локальный сканер уязвимостей ScanOVAL в версиях под Linux (раньше был только под Windows). И OVAL-контент к нему. В трёх вариантах:

1. ScanOVAL для ОС Astra Linux 1.6 SE - тестовая версия сканера и OVAL-контент
2. ScanOVAL для ОС Альт 9 - тестовая версия сканера и OVAL-контент
3. ScanOVAL для ОС Роса «Кобальт» - тестовая версия сканера (OVAL-контент пока недоступен)

ScanOVAL это, конечно, не вполне полноценный сканер. Он может сканировать только локалхост. Штатно запускается только в графическом режиме. Т.е. использовать его, чтобы вручную валидировать уязвимости на хостах получится, а приспособить для регулярного сканирования всей инфры скорее всего нет. Понятно зачем сделано, этот продукт не должен рушить бизнес VM-вендорам.

Другой вопрос, который естественно возникает, когда видишь OVAL-контент в паблике, а можно ли его использовать не в составе ScanOVAL? 😏 Например, OpenSCAP-у скормить, свой OVAL сканер написать или интерпретировать во что-нибудь? Ответ: технически реально, а юридически нельзя, т.к. EULA для ScanOVAL это отдельно оговаривает:

"Не допускается осуществлять следующие действия:
…
использовать ПО и (или) описания проверок (включая любые их фрагменты), применяемые в ее составе, с целью создания баз данных или кода, предназначенных для предотвращения угроз безопасности информации;
публиковать, а также распространять от своего имени любые фрагменты описаний проверок, применяемых в составе ПО;
…"

Тоже понятно почему. Идентификаторы дефинишенов, такие как "oval:ru.altx-soft.nix:def:156318", не оставляют сомнений в происхождении контента и понятно, что рушить свой бизнес коммерческому VM вендору совсем не нужно.

Поэтому,
1. Круто, что появилась возможность сканировать сертифицированные отечественные Linux-ы бесплатным решением. Даже если использовать его только в ручном режиме как эталонный сканер, это более чем полезно.
2. Потребность в OVAL-контенте (или просто бюллетенях хотя бы) от Linux-вендора это не снимает, т.к. EULA конечно полноценно использовать контент для ScanOVAL не позволяет, к сожалению.