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

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации"

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

Вышел драфт Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что там с Управлением Уязвимостями?

Есть 2 показателя безопасности, зависящие от оперативности устранения уязвимостей:

🔸 3.2. "На устройствах и интерфейсах, доступных их сети Интернет, отсутствуют уязвимости критического уровня опасности с датой публикации обновлений (компенсирующих мер по устранению) в банке данных угроз ФСТЭК России, на официальных сайтах разработчиков, иных открытых источниках более 30 дней"

🔸 3.3 "На пользовательских устройствах и серверах отсутствуют уязвимости критического уровня с датой публикации обновления (компенсирующих мер по устранению) более 90 дней (не менее 90% устройств и серверов)"

❓Во втором случае не указано откуда дату публикации обновления брать. Наверное нужно сделать единообразно.
❓"доступных их сети Интернет" - опечаточка, "из".

Из пунктов следует, что нужно:

🔻 покрывать все активы детектами уязвимостей
🔻 понимать какие именно активы опубликованы в Интернет
🔻 уметь оценивать критичность уязвимостей по методике ФСТЭК
🔻 отслеживать дату публикации обновления (а не дату публикации самой уязвимости!) в разных источниках 😲

Последнее выглядит как нетривиальная задача, т.к. общего реестра данных по обновлениям не наблюдается, получается ведение такого реестра и наполнение его ляжет на организацию. На практике, скорее всего, придется ориентироваться именно на дату публикации уязвимости, т.к. её гораздо проще определять (непосредственно в NVD/BDU) и, по идее, она должна быть всегда более ранней или равной дате публикации обновления. 🤔 Поэтому, возможно, имеет смысл подкрутить формулировочку, например на "дата публикации уязвимости или обновления (компенсирующих мер по устранению)". И сделать пометочку, что допустимо взять наибольшую из имеющихся дат.

И, в идеале, хотелось бы ещё видеть аналог CISA KEV с непосредственно указанными датами, когда конкретные уязвимости должны быть исправлены.

Колядка про Vulnerability Management "Пропатчите уязвимость"

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

Колядка про Vulnerability Management "Пропатчите уязвимость". 🙂 Наигрывал сегодня разные новогодние и рождественские песенки, и мне пришла в голову идея, что "We Wish You a Merry Christmas" с требованием инжирного пудинга отличное описывает процесс пушинга исправления критичных уязвимостей.

Что, в общем, и накидал по-быстрому. Подозреваю, что это первая песня, которая упоминает "НКЦКИ". 😅

Поздравляю всех с наступающим Новым 2024 Годом! Всем здоровья, счастья и интересных задачек! Ура! 🎄🎉

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr

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

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.

00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X

ФСТЭК России 50 лет!

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

ФСТЭК России 50 лет!

ФСТЭК России 50 лет! Сегодня день основания Гостехкомиссии СССР (18 декабря 1973), которая в итоге превратилась во ФСТЭК. С праздником, коллеги! 🎉

ФСТЭК это главный российский регулятор в области Управления Уязвимостями:

🔸 Руководство по организации процесса управления уязвимостями в органе (организации)
🔸 Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
🔸 База угроз и уязвимостей; регламент добавления
🔸 Бесплатный сканер уязвимостей ScanOVAL
🔸 ГОСТ Р 56546-2015 Классификация уязвимостей информационных систем
🔸 ГОСТ Р 56545-2015 Правила описания уязвимостей
🔸 Методика тестирования обновлений безопасности программных, программно-аппаратных средств

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python

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

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python. Bash-скрипт был примитивный: скачать zip-архив с XML-выгрузкой из БДУ ФСТЭК, распаковать, поискать уязвимости, которые были добавлены в этом году. Я такое накидываю быстро и на автомате. Расплачиваюсь за это последующим рутинным переписыванием на Python. 😕 Автоматизированную же трансляцию толком не сделаешь - слишком много утилит и их особенностей. Или сделаешь? 😏

На удачу забил этот bash-скрипт в сервис с комментарием "rewrite in python" и железяка практически справилась. 🤩 Скачала архив по урлу, распаковала, циклически прошлась по файлу и поискала то, что нужно. Было только несколько минорных ошибок. Magic. 🪄

Продолжу эксперименты с чем-то посложнее, с кучей sed-ов и awk. Но похоже, что будет можно по кайфу фигачить парсеры на Bash-е и влегкую превращать это потом в приличный Python. 😊 Если не прямо сейчас, то в обозримом будущем.

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

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

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 6 лет VM-ом в банке занимался, было интересно послушать. 🙂 Выписал некоторые тезисы.

1. IT стремятся занять позицию "давайте мы сейчас построим, а потом вы к нам придёте, мы вас послушаем и может быть что-то поправим". ИБ должны не допускать такого.
2. VM это прежде всего процесс взаимодействия людей. Важно уметь договариваться, в том числе на уровне руководства. Необходимость VM следует доносить грамотно, аргументированно и регулярно.
3. Доказывать необходимость исправления уязвимостей непросто, но это развивает технически и IT, и ИБ.
4. В ПСБ был выстроенный процесс обновления десктопов (АРМов), но после 22 года он усложнился. Теперь есть команда в составе RedTeam, которая проверяет обновления и новые версии западного ПО на закладки (дополнительно к проверенным обновлениям из БДУ). Также проходят проверки и собственные разработки.
5. Также применяется исправление уязвимостей путем отказа от legacy систем или внедрения компенсирующих мер (аудит сетевых подключений, максимальное урезание интеграций, обслуживание через терминальные станции).
6. Есть проблема с отсутствием бюллетеней безопасности отечественных вендоров. Отечественных вендоров СЗИ/САЗ это тоже касается.
7. Категоризация активов по сегментам, бизнесам, выделение наиболее критичных скоупов (например, DMZ).
8. Категоризация уязвимостей по автоматизированной методике оценки критичности уязвимостей ФСТЭК.
9. В идеале информацию об активах нужно забирать из супер-актуальной CMDB, которую обслуживает IT. А ИБ должна проводить поиск теневых активов в факультативном режиме. На практике вовлеченность ИБ в поиск проблем CMDB выше, в т.ч. приходится самим искать владельцев систем и обслуживающих подразделений. Периодичность рескана фиксируется в документации на IT-систему. Статус комплаенса систем будет виден на уровне CMDB. Необходимо внедрять VM в ITSM.
10. Проводится сканирование периметра извне. Необходимо следить за состоянием внешних сканеров, т.к. они зачастую добавлены в white list. Для внутренних сканеров, проводящих сканирование с аутентификацией, это ещё более критично.
11. У каждого компонента IT-систем есть утвержденный стандарт настроек. Разработка стандартов настроек выполняется внешней организацией. Проверки на соответствие реализуют сами. Конкретные требования зависят от контура, в котором находится сервер. Желательно иметь возможность перенести этот набор скриптов в VM-решение.
12. Этапы процесса Управления Соответствием: утверждение стандарта, тестирование на ограниченном скоупе, расширение скоупа и контроль соответствия. Центр IT-архитектуры утверждает единый тех. стек допустимых технологий. Его необходимо ограничивать и иметь в виде реестра а-ля CMDB. Проблема расширения стека (в глобальном смысле) это и проблема VM-вендора, который должен уметь всё.
13. При наслоении стандартов (например, ОС и СУБД) могут быть конфликты. Отхождения от стандарта должны согласовываться и журналироваться.
14. Трендовые уязвимости на периметре фиксятся оперативно без формального обоснования критичности. Согласование в рамках конфколла. Но тестирование патча на ограниченном скоупе всё равно необходимо выполнять.
15. Еженедельные отчёты: новая инфраструктура введенная в эксплуатацию, какая инфраструктура прошла проверки, какие уязвимости выявлены с приоритизацией. Отчёты также нужны для аудиторов.
16. Нужно стремиться к открытости VM-решений: полнота базы знаний детектов, обязательство поддерживать API-интеграции.

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости

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

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из PT Expert Security Center (ESC). Для меня особенно интересный эпизод, т.к. ответ на вопрос куда именно в PT я вышел - вот конкретно к ним. 🙂 Выписал некоторые тезисы.

1. Трендовые уязвимости - уязвимости, которые эксплуатируются сейчас (на которые есть эксплоиты) или которые будут эксплуатироваться в ближайшее время. Это те уязвимости, на которые заказчики должны обратить внимание в первую очередь в своей инфраструктуре.
2. Трендовых уязвимостей не должно быть везде в инфраструктуре или только в DMZ? Дискуссионный вопрос, нужно исходить из модели рисков. Трендовая уязвимость на тестовом стенде внутри IT-инфраструктуры это не очень важная уязвимость.
3. Трендовость Уязвимости зависит от уязвимого продукта. Они могут быть очень специфичными: Church Management система, управления автомобилями и т.п. Необходимо учитывать реальные возможности по детектированию. Продукты, которые неинтересны ни нам, ни заказчикам, мы добавляем в black list, который, при необходимости, пересматриваем.
4. Исходные данные для оценки трендовости собираем из баз уязвимостей, бюллетеней безопасности вендоров, социальных сетей и мессенджеров, баз эксплоитов, публичных репозиториев кода.
5. Фолзы детектов уязвимостей, отчего они? Например, в детекте уязвимостей Windows по KB-шкам. Могут быть ошибки роботов-сборщиков данных. Может быть задержка реагирования на изменение в контенте вендора. Может быть вендор ПО предоставляет информацию об обновлениях недостаточно прозрачно.
6. Форки Open Source продуктов, которые не фиксят и не сообщают об уязвимостях исходного продукта. Призываем вендоров за этим следить. И желательно, чтобы вендоры публиковали информацию о своих уязвимостях в одном месте, идеально в БДУ ФСТЭК.
7. Сложности с детектами. Версионные детекты: уязвимость в выключенной фиче или выключенном ПО это уязвимость? Детекты с эксплуатацией: проверка не сработала, а насколько этому можно верить? Насколько правильно проверки реализованы и на основе каких эксплоитов?
8. Пользовательские детекты для софтов и уязвимостей - крутая тема. Идём в эту сторону.
9. Для отладки детектов необходимы реальные стенды с уязвимыми продуктами. Здесь вопросы с оценкой популярности софта (невозможно поддерживать всё) и нотификациями о выпуске новых версий софта. В эти темы тоже идём.
10. Доставка трендовых уязвимостей в MP VM за 12 часов. Трендовые уязвимости, как правило, начинают эксплуатировать через 24 часа (плюс это требование ФСТЭК из методики оценки критичности). Из них 12 нужно VM вендору на реализацию проверки и 12 нужны клиенту на детекты и исправление. Для более быстрой доставки идём к тому, что в базе MP VM будут все уязвимости, не только те, для которых есть детекты. Нужно будет только быстро добавлять детекты (возможно силами самих клиентов). Ассетная модель позволяет получить сработки без пересканирования по имеющимся данным.
11. BugBounty может использоваться для контроля известных уязвимостей сетевого периметра и выполнения SLA (например хантер может сдавать известные уязвимости старше 30 дней).
12. HCC PT Essentials это минимальный набор требований к конфигурациям, которые обязательно должны выполняться. Идём в сторону возможности реализовывать свои проверки.
13. Идеальный VM вендор. Прозрачность по текущим и будущим фичам (открытый roadmap). Улучшение покрытия продуктов. Самостоятельность заказчиков в плане наполнения базы знаний уязвимостей и детектов, возможность делиться этим контентом через маркетплейс. Метапродукты работающие с минимальным количеством людей. Автоматизированное исправление уязвимостей с аппрувом от IT.