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

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

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

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем. Документ на 6 страниц, содержит требования, оформленные в 8 групп (символом ✳️ я отметил то, что непосредственно относится к Управлению Уязвимостями):

1. Администрирование, управление конфигурацией и эксплуатацией сетевых устройств: 1.1 администрировать пограничные устройства с изолированных рабочих мест; 1.2 использовать сертификаты или сложные пароли; 1.3 применять уникальные пароли; 1.4 контролировать и журналировать изменения конфигурации; ✳️ 1.5 выявлять и блокировать нелегитимные внешние сервисы; ✳️ 1.6 вести учёт устройств на сетевом периметре; ✳️ 1.7 управлять устройствами с истекающей поддержкой; 1.8 запретить внешнее удалённое администрирование; 1.9 согласовывать изменения с ИБ; 1.10 использовать безопасные протоколы мониторинга.

2. Повышение устойчивости к DDoS-атакам: 2.1 настроить блокировку неразрешённого трафика; 2.2 фильтровать трафик через WAF; 2.3 включить защиту от DDoS; 2.4 ограничивать подключения с одного IP; 2.5 взаимодействовать с оператором связи для противодействия DDoS.

3. Сегментация сети и контроль доступа для защиты ключевых сегментов: 3.1 сегментировать сеть VLAN и локальными сетями; 3.2 контролировать трафик через ACL; 3.3 внедрить ZTNA; 3.4 запретить удалённое администрирование ядра сети; 3.5 создать DMZ с ограниченным доступом к внутренним сегментам.

4. Резервное копирование конфигов: 4.1 назначить ответственного за резервное копирование; 4.2 хранить ≥3 копий на разных носителях, одну отдельно; 4.3 копировать ежемесячно; 4.4 определить права на копирование; 4.5 сохранять критичные конфигурации (ACL, VLAN, NAT, учетные записи); 4.6 проверять восстановление каждые три месяца.

✳️ 5. Управление уязвимостями: 5.1 реализовать управление уязвимостями по Методике анализа защищенности (ФСТЭК 25.11.2025) и Руководству по управлению уязвимостями (ФСТЭК 17.05.2023); 5.2 устанавливать обновления безопасности на пограничных устройствах и тестировать их по Методике тестирования обновлений безопасности (ФСТЭК 28.10.2022) и Методике оценки критичности уязвимостей (ФСТЭК 30.06.2025).

6. Аутентификация и управление доступом: 6.1 централизованный контроль доступа через NAC и межсетевые экраны; 6.2 многофакторная аутентификация для админ-доступа; 6.3 разграничение ролей с минимальными привилегиями.

7. Регистрация и анализ событий ИБ: 7.1 централизованный сбор и анализ событий через SIEM; 7.2 хранение детальных журналов безопасности с временными метками; 7.3 оповещение администраторов о подозрительных действиях и изменениях.

8. Регулярные учения по реагированию на инциденты для проверки их эффективности и восстановления инфраструктуры.

Интересный и подробный документ. 👍 По VM-ной части весьма примечательно, что VM-процесс для периметра рекомендуют строить в соответствии с

🔹 Руководством по Анализу защищённости. Имеются в виду периодические внешние аудиты периметра сторонней организацией с соответствующими критериями успешности? 🤔

🔹 Руководством по организации процесса управления уязвимостями в органе/организации. Был весьма удивлён, т.к. давненько не встречал прямую ссылку на него в документах ФСТЭК. 😲 Всё больше общие требования к VM-процессу, как в 117 приказе или проекте "Мероприятий и мер". 🤷‍♂️

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)

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

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement). Jonathan описывает ситуацию, когда в организаций вроде как есть всё необходимое для нормального VM/EM процесса: сканеры, дашборды, SLA, процессы эскалации. Но принуждение к исполнению в организации слабое, и система постепенно адаптируется: дедлайны превращаются в рекомендации, ответственность ("ownership") становится предметом обсуждений, а принятые риски годами не пересматриваются ("stops being revisited"). 🫠 При этом вроде какая-то активность есть, но экспозиции практически не устраняются, растёт exposure debt.

Что имеет смысл делать в такой ситуации VM/EM-специалисту?

🔊 Попробовать достучаться до руководства. Подсветить управленческую проблему: решения принимаются, но не исполняются, поэтому экспозиции не снижаются и это приведёт к инцидентам.

📝 Формализовать всё. Фиксировать владельцев активов, конкретные задачи по исправлению, этапы исправления, risk acceptance, нарушения SLA и т.д. Это делает процессы максимально прозрачными и вы, как VM-щик, с меньшей вероятностью окажитесь "крайними".

🎯 Фокусироваться на реальном риске. Если всё не исправить, закрывать то, что действительно эксплуатируется (в первую очередь трендовые уязвимости) на наиболее критичных для бизнеса системах.

🚪 Если система не меняется - задуматься о смене работы. Это весьма грустно, но если в организации сплошная "электрификация" ("всем всё до лампочки" 😉), снизу это исправить практически нереально. А вот стать в итоге "козлом отпущения" можно запросто. Обязательно это учитывайте.

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision

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

Продолжу разбирать 10 неудобных вопросов Product Manager-у по VM из подкаста коллег из R-Vision

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision.

Вопрос 2: Вы можете гарантировать, что в вашем сканере уязвимостей не будет фолзов?

💬 Андрей Селиванов сначала пошутил, что можно гарантировать отсутствие фолзов, если просто не проводить сканирование. 😏 Далее сказал, что фолзы (некорректные детекты каких-то уязвимостей) есть в абсолютно любом решении. Причин для этого может быть масса: от некорректной информации по детектированию уязвимости в источнике данных об уязвимости (например, бюллетене RHSA вендора Red Hat или на странице с описанием уязвимости Microsoft) до ошибок при написании правил детектирования на стороне VM-вендора. Важны два параметра: процент допустимых фолзов в решении VM-вендора и то, как быстро VM-вендор их устраняет (принимая от клиентов через форму обратной связи).

#️⃣ С этим тоже не поспоришь. Но я бы посмотрел несколько шире. Фолзы - это не только про то, что какие-то конкретные правила детектирования были реализованы некорректно. Хотя, безусловно, и это тоже, и хотелось бы, чтобы такие проблемы VM-вендор ловил самостоятельно, а не только после того, как их зарепортят клиенты. 😉 Это ещё и про зрелое восприятие возможностей VM-продукта и зрелое позиционирование VM-продукта вендором.

🔹 Если сканер не детектирует какие-то уязвимости в инфраструктуре, потому что не поддерживает те или иные продукты или способы установки, это со стороны клиента может выглядеть как false negative. А может как вполне осознаваемые ограничения детектирования VM-продукта.

🔹 И с другой стороны, то, что упомянул вскользь Андрей "многое зависит от окружения, от специфических условий", когда сканер детектирует уязвимости в библиотеке, которая по факту не используется, это может восприниматься со стороны клиента как жуткие false positive ошибки. А может как особенность детектирования "потенциальных" уязвимостей сканером.

Тут, наверное, хотелось бы, чтобы мы (как VM-комьюнити) отходили от восприятия любых средств анализа защищённости как волшебных оракулов, которые выдадут все 100% имеющихся уязвимостей в инфраструктуре. Конечно же, нет. 🤷‍♂️

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

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM"

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

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) 10 неудобных вопросов Product Manager-у по VM

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM". Естественно, обсуждение шло в контексте решения R-Vision VM. Интересный формат и подборка вопросов. 🔥 Собираюсь их постепенно разобрать и добавить свои комментарии. 😉

Вопрос 1: Класс Vulnerability Management решений - это маркетинговая обёртка сканеров уязвимостей или за этим есть какие-то дополнительные технологии?

💬 Андрей Селиванов ответил в духе, что VM-решения - эволюционное развитие сканеров уязвимостей, потребность в которых возникла с увеличением количества активов (сказал, что у них есть клиент с 300 000 конечных точек и сотней миллионов уязвимостей) и увеличением разнообразия типов активов. Все уязвимости на этих активах необходимо эффективно детектировать, приоритизировать и ставить задачи на устранение. С простым сканером уязвимостей с таким объёмом справляться сложно, требуется более функциональное решение. "Но сканер - это то, по чему встречают решение в любом пилоте и у любого клиента". Важно, насколько качественно выявляются уязвимости, насколько широкое покрытие. "Если у тебя не будет нормального сканера, называться полноценным VM-решением - ну такое себе".

#️⃣ В целом, согласен со сказанным. Особенно в части качества детектирования. 👍 Единственное я бы выделил такие формальные признаки сканера уязвимостей и VM-решения: если средство анализа защищённости (САЗ) работает в парадигме отдельных сканов - это сканер уязвимостей. Классический пример - Nessus. А если САЗ хранит картину текущего состояния всей инфраструктуры (активов и уязвимостей на них), позволяет делать выборки по уязвимостям, делать приоритизацию уязвимостей, заводить и отслеживать задачи на устранение (через встроенную тикетницу или через интеграции) и производить прочую высокоуровневую обработку, то это уже решение класса Vulnerability Management. Потому что это решение реализует внутри себя Vulnerability Management процесс. Ну или, во всяком случае, вендор решения это декларирует и к этому стремится. 😉

При этом я НЕ считаю, что любое VM-решение априори лучше любого сканера уязвимостей и должно стоить дороже.

🔹 И сканер уязвимостей может быть оправданно дорогим, если он реализует востребованную, крутую и качественную экспертизу по детектированию. Даже если он поставляется в виде консольной утилиты, а то и вовсе в виде фида с контентом.

🔹 В свою очередь VM-решение может лишь формально реализовывать заявленную функциональность и, к примеру, не справляться с реальной нагрузкой (особенно если его навайбкодили за выходные 😉). VM-решение вообще может быть опенсурсным проектом, типа Faraday Security или DefectDojo, и стоить (ну, в теории 😏) 0 руб.

Так что маркетинговые категории мало чего значат на самом деле. Нужно смотреть в суть.

Как определяется успех Анализа Защищённости (АЗ) согласно методике ФСТЭК от 25.11.2025?

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

Как определяется успех Анализа Защищённости (АЗ) согласно методике ФСТЭК от 25.11.2025?

Как определяется успех Анализа Защищённости (АЗ) согласно методике ФСТЭК от 25.11.2025? Читаем раздел 3.4.

🔹 НЕ выявили уязвимости (3.4.2) - успех. 👍

🔹 Выявили уязвимости критического и высокого уровня (3.4.4), а также уязвимости среднего и низкого уровня, "которые по результатам экспертной оценки могут быть использованы потенциальным нарушителем для реализации угроз безопасности информации (векторов атак)" (3.4.5) - их нужно устранить "в ходе проведения анализа уязвимостей". ⚡️ Оценка критичности уязвимостей производится по методике ФСТЭК. Устранили - успех. 👍 Не устранили - "отрицательное заключение". 👎

Т.е здесь речь об одноразовом "подпрыгивании" для устранения конкретных уязвимостей, без привязки к VM-процессу в организации? 🤔

Фактически да. 🤷‍♂️

Однако и требований, однозначно препятствующих устранению выявленных с помощью АЗ уязвимостей в рамках VM-процесса, здесь нет. Всё реализуемо. 😉 Вопрос лишь в определении приоритетов и сроков устранения.

Подумалось, что это очень VM-ная тема, когда руководству трудно и даже невозможно представить себе на чём держится инфраструктура организации

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

Подумалось, что это очень VM-ная тема, когда руководству трудно и даже невозможно представить себе на чём держится инфраструктура организации

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

🔹 Предоставленные сами себе подразделения организации решают стоящие перед ними задачи наиболее простым, быстрым и привычным образом. В идеале бесплатным! 😊 Что Вася для дома для семьи когда-то использовал, то и идёт в дело. Требования и политики организации (если они вообще есть) игнорируются. 👌 Что не контролируется, то и не выполняется. 😏 В результате откровенно чудовищные, неподдерживаемые и уязвимые решения внедряются и становятся фактическим стандартом организации. 🤷‍♂️ "А чё такова? Исторически сложилось! Зато работает! Это ж прямщаз для ДЕЛА нужно!"

🔹 В результате руководство, не контролирующее реальное положение дел (и не стремящееся к этому 🙄), принимает управленческие решения, которые, по идее, никак не должны зааффектить критические процессы в организации…

Но оказывается, что они аффектят и ещё как! 😱😉

Вчера ФСТЭК выложили в открытый доступ проект документа "Мероприятия и меры по защите информации, содержащейся в информационных системах"

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

Вчера ФСТЭК выложили в открытый доступ проект документа Мероприятия и меры по защите информации, содержащейся в информационных системах

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

❗️ Согласно пункту 1.3, "методический документ детализирует мероприятия (процессы)" по защите информации (ЗИ) и "определяет содержание мер" по ЗИ в соответствии с требованиями из 117-го приказа ФСТЭК.

Документ объёмный, 185 страниц.

Структура документа:

1️⃣ Общие положения
2️⃣ Факторы, влияющие на ЗИ
3️⃣ Мероприятия по ЗИ (45 страниц) -❗️ Среди них 3.3. Управление Уязвимостями (рассмотрю содержание подробно в последующих постах)
4️⃣ Меры по ЗИ (129 страниц)

Слово "уязвимость" в различных формах встречается по тексту 104 раза в разных частях документа. 🕵️‍♂️ Будет что пообсуждать. 😉😇