Что не так с новой методичкой Банка России по пентестам и анализу уязвимостей

1. Очень странно писать единые требования для анализа уязвимостей и пентестов (в Главе 1). У них даже цели не всегда совпадают, например, нахождение дыр и демонстрация способов обхода средств защиты ⚖️ А разность целей подразумевает и разные требования к реализации обоих процессов.
   

   Например, зачем мне ТЗ на поиск уязвимостей своими силами? Это же непрерывный процесс, в то время как ТЗ скорее относится к проектным работам.

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

   А как тогда пентестить клиента или искать уязвимости на клиентских устройствах? 🤔

3. Наряду с выявлением уязвимостей и способов их эксплуатации, к задачам методички отнесена и идентификация риска ИБ, включая случаи реализации недопустимых событий хищений денежных средств. Как по мне, так в методичке не хватает связки целей пентестов и поиска дыр с бизнес-целями финансовых организаций и негативными последствиями от эксплуатации уязвимостей.
   

   Хотя в приложении, в рекомендуемой форме отчета о проведенном пентесте или анализе уязвимостей, упоминаются и негативные последствия и недопустимые события…

4. Учитывая, что работы, описываемые МР-2, могут проводиться как внутренними силами, так и внешними (об этом написано), стоило бы внутри разделить и требования в зависимости от привлечения или непривлечения подрядчиков. Иначе, достаточно странно выглядит требование актуализации соглашение об ответственности сторон тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры при организации этих задач без участия внешних сил.
   

   Вообще, начиная с 4-й главы такое разделение есть. Но почему его не учли ранее по тексту?

5. Больше всего вопросов у меня к составу ТЗ, которое должно включать перечень методов пентеста и анализа уязвимостей, возможные классы атак, включая техники и тактики, и уязвимостей, используемый инструментарий, перечень источников, используемых для идентификации уязвимостей и много чего еще. Вот реально, зачем это описывать при поиске уязвимостей, если он все равно делается автоматизированно и не может выйти за пределы возможностей сканера? А если речь про пентест, то зачем таким перечислением сковывать цепями руками багхантеров и пентестеров? Они вообще могут не раскрывать свой инструментарий, А что касается техник и тактик атак и источников уязвимостей. так в том часто и суть, чтобы использовать 0Day, которых в БДУ нет, и техники, которых нет в ATT&CK. А если пентест идет в режиме black box, то вообще всей этой информации у пентестера быть не может (иначе, какой же это black box) и об этом, кстати, написано во второй главе методички.
   

   Такое впечатление, что первую главу и все остальное писали разные люди!

6. Судя по списку документов, которыми надо руководствоваться при пентестах и анализе уязвимостей, никакого творчества ЦБ от этих процессов не подразумевает — все разжевано и регламентировано.
   

   Интересно, хакерам тоже надо все эти документы предоставлять и ограничивать их в возможностях, а также определять им исключения, чего они делать не должны?

7. Первые главы документа ЦБ пронизаны мыслью, что описанные в нем работы являются проектными, у которых есть начало и конец. По итогам надо составить отчет, подписать его электронной подписью или, в бумажном варианте, прошить нитью, как я это писал вчера. Но анализ уязвимостей — это не проект, а процесс, причем непрерывный. От него нельзя требовать каждый раз заполнять отчеты. Это еще и противоречит методике ФСТЭК, на которую ЦБ же и ссылается, как на рекомендации. А еще с отчетом по уязвимостям надо знакомить заместителя руководителя финансовой организации. Зачем ему знать список из тысяч уязвимостей?
   

   Глава 1 вообще портит весь документ, если честно.

8. В процессе анализа уязвимостей их устранение обычно не проводится — это разные процессы, проводимые разными подразделениями и в разное время в зависимости от критичности. Странно их было объединять…
9. Если вы хотите самостоятельно анализировать уязвимости или проводить пентесты, то рекомендуется создать для этого отдельное подразделение. Там должно быть не менее двух специалистов и они не должны заниматься обеспечением ИБ тех объектов, которые они анализируют!
   

   Представители небольших банков и тем более некредитных финансовых организаций и все их два сотрудника на всю ИБ будут рады такому требованию!

10. Меня немного смутил пункт о том, что обычный анализ уязвимостей должен повлечь за собой уведомление ЦБ как об инциденте ИБ.
    

    А вот фразу «выявленный в рамках анализа уязвимостей инцидент защиты информации» я вообще не понял. А все потому, что авторы объединили анализ уязвимостей и пентесты в единую сущность.

11. Чего мне не хватило в документе, так это критериев качества работ по оценке защищенности, в первую очередь для пентестов, так как по анализу уязвимостей такие критерии непросто установить. А вот для пентестов вполне. На портале «Резбез» есть пример такого списка критериев (последний и для анализа уязвимостей подойдет):
    1. Цель работ достигнута или дано обоснование невозможности ее достижения
    2. Результаты работ соответствуют требованиям технического задания
    3. Границы проведения работ соблюдены
    4. Дано обоснование оценки защищенности систем
    5. Даны рекомендации по повышению защищенности систем и устранению выявленных недостатков
    6. Подтверждена возможность эксплуатации выявленных уязвимостей.

Думаю, что если в описываемую МР-2 Банка России внести незначительные изменения, удалив объединение сущностей и переписав Главу 1, то получится в целом неплохой документ.