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

На сайте ФСТЭК 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 приказе или проекте "Мероприятий и мер". 🤷‍♂️

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

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

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

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

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

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

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

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

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

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ)

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

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ)

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ). Если провести детектирование уязвимостей в любой достаточно большой организации, неизбежно обнаружатся критические уязвимости. И это абсолютно нормально, ЕСЛИ для всех обнаруженных уязвимостей выполняются следующие условия:

🔹 В организации уже знали про уязвимость на активе, т.е. обнаруживали её с помощью собственных средств детектирования.
🔹 Уязвимость уже была оценена и ей была присвоена степень критичности.
🔹 Для устранения уязвимости уже была заведена задача на конкретного исполнителя с зафиксированным сроком выполнения (в соответствии с принятым SLA) и этот срок ещё не вышел.

Это значит, что VM-процесс в организации успешно функционирует (по БОСПУУ 😉), и АЗ успешно пройден. 🥇👏

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

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

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

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)? Понимая под АЗ детектирование уязвимостей в инфраструктуре организации третьей стороной. Для исполнителя критерии успеха: найти максимум уязвимостей с минимумом FP и FN. А для заказчика? 🤔 Обычно для него успехом считают отсутствие обнаруженных критичных уязвимостей. А если такие есть - их нужно срочно устранить или доказать, что они некритичные. 👌

Однако организациям без работающего VM-процесса такое разовое латание дыр не особо поможет - через полгода в инфре снова будет адище. 😈 А организациям с работающим VM-процессом требование устранять уязвимости в пожарном режиме, игнорируя SLA по существующим задачам на устранение, внесёт неразбериху и может сломать VM-процесс. 🤷‍♂️

Имхо, по-хорошему, АЗ должен проверять не текущее состояние инфры (постоянно меняющееся), а состояние VM-процесса. С соответствующими критериями успеха. 😉

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

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

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

Вчера на сайте ФСТЭК был опубликован важный VM-ный документ - "Методика анализа защищённости информационных систем" от 25 ноября 2025 г. Основное назначение методики - описать работы по анализу защищённости (выявлению уязвимостей) при аттестации объектов информатизации (77 приказ), а конкретно в ходе:

🔹 аттестации информационных систем (ИС) на соответствие требованиям по защите информации (ЗИ);
🔹 контроля уровня защищённости конфиденциальной информации от НСД и её модификации в ИС;
🔹 оценки соответствия ИС требованиям по ЗИ (испытания) и достаточности принимаемых мер по ЗИ (обеспечению безопасности).

Кроме того, это (первая? 🤔) попытка регулятора определить, что такое Анализ Защищённости (АЗ) как услуга.

Особенно интересны:

🔻 Раздел 3.4. Оценка выявленных уязвимостей. Здесь определяются критерии успешности АЗ.

🔻 Таблицы 2 и 3, содержащие перечни работ в ходе внешнего и внутреннего сканирования и, фактически, определяющие требования к функциональности средств АЗ. 😉