Распоряжение Министерства государственного управления, информационных технологий и связи Московской области от 27 июня 2023 г. N 11-99/РВ-08 "Об утверждении регламента выявления, анализа и устранения уязвимостей, а также тестирования и установки обновлений программного обеспечения в информационных системах, эксплуатируемых в центральных исполнительных органах Московской области, государственных органах Московской области, подведомственных им государственных учреждениях и организациях, органах местного самоуправления Московской области"

В соответствии с Положением о Министерстве государственного управления, информационных технологий и связи Московской области, утвержденным постановлением Правительства Московской области от 13.06.2012 N 820/19 "Об утверждении Положения о Министерстве государственного управления, информационных технологий и связи Московской области и установлении штатной численности Министерства государственного управления, информационных технологий и связи Московской области", в целях исполнения требований ФСТЭК России от 28.03.2022 N 240/22/1409 по проведению мероприятий по снижению возможности информационно-технологических воздействий на информационные системы Московской области через уязвимые и/или незадействованные службы (сервисы), доступные из информационно-телекоммуникационной сети Интернет:

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

2. Руководителям, центральных исполнительных органов Московской области, государственных органов Московской области, подведомственных им государственных учреждений и организаций обеспечить исполнение Регламента со дня вступления в силу настоящего распоряжения.

3. Рекомендовать органам местного самоуправления муниципальных образований Московской области организовать исполнение Регламента со дня вступления в силу настоящего распоряжения.

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

5. Контроль за выполнением настоящего распоряжения возложить на заместителя министра государственного управления, информационных технологий и связи Московской области Коношенко С.А.

Министр государственного управления, информационных технологий и связи Московской области

Н.В. Куртяник

Утвержден
распоряжением Министерства
государственного управления,
информационных технологий
и связи Московской области
от 27.06.2023 N 11-99/РВ-08

Регламент
выявления, анализа и устранения уязвимостей, а также тестирования и установки обновлений программного обеспечения в информационных системах, эксплуатируемых в центральных исполнительных органах Московской области, государственных органах Московской области, подведомственных им государственных учреждениях и организациях, органах местного самоуправления Московской области

I. Общие положения

1. Настоящий Регламент выявления, анализа и устранения уязвимостей, а также тестирования и установки обновлений программного обеспечения в информационных системах, эксплуатируемых в центральных исполнительных органах Московской области, государственных органах Московской области, подведомственных им государственных учреждениях и организациях, органах местного самоуправления Московской области (далее - Регламент) устанавливает порядок взаимодействия центральных исполнительных органов государственной власти Московской области, государственных органов Московской области, подведомственных им государственных учреждений и организаций, органов местного самоуправления Московской области (далее - Оператор информационной системы), Министерства государственного управления, информационных технологий и связи Московской области (далее - Мингосуправления Московской области) и Государственного казенного учреждения Московской области "Центр информационной безопасности Московской области" (далее - ГКУ МО "ЦИБ МО") при выявлении и устранении уязвимостей в информационных системах Операторов ИС с целью реализации ими возложенных на них функций и полномочий.

2. Регламент разработан в соответствии с требованиями следующих нормативных правовых актов и методических документов:

Федеральный закон от 27.07.2006 N 149-ФЗ "Об информации, информационных технологиях и о защите информации";

Федеральный закон от 27.07.2006 N 152-ФЗ "О персональных данных";

Федеральный закон от 26.07.2017 N 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации";

постановление Правительства Российской Федерации от 06.07.2015 N 676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации";

постановление Правительства Московской области от 13.06.2012 N 820/19 "Об утверждении Положения о Министерстве государственного управления, информационных технологий и связи Московской области и установлении штатной численности Министерства государственного управления, информационных технологий и связи Московской области";

Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств, утвержденная приказом ФСТЭК России от 28.10.2022 (далее - Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств от 28.10.2022);

Руководство по организации процесса управления уязвимостями в органе (организации), утвержденное ФСТЭК России от 17.05.2023;

Методика тестирования обновлений безопасности программных, программно-аппаратных средств, утвержденная приказом ФСТЭК России от 28.10.2022 (далее - Методика тестирования обновлений безопасности программных, программно-аппаратных средств от 28.10.2022).

3. Термины и сокращенные наименования, используемые в настоящем Регламенте:

Информационная безопасность (ИБ) - свойство информации сохранять конфиденциальность, целостность и доступность.

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

Инцидент ИБ - одно или несколько незапланированных событий, приводящих к нарушению функционирования информационной системы или возникновению угроз безопасности информации или нарушению требований по защите информации.

Уязвимость - недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который(ая) может быть использован(а) для реализации угроз безопасности информации.

Эксплуатация уязвимостей - использование уязвимости, приводящее к инциденту ИБ.

Межведомственная система электронного документооборота Московской области (далее - МСЭД) - система автоматизации делопроизводства и документооборота, посредством которой создаются, обрабатываются, хранятся документы, составляющие бумажный и электронный документооборот.

ЗК МСЭД - закрытый контур МСЭД.

Сегмент информационной системы - совокупность нескольких компонентов информационной системы (информации и обеспечивающих ее обработку отдельных информационных технологий и технических средств), объединенных для единства решения функциональных задач.

ЕИТО - единая инфраструктура технологического обеспечения Правительства Московской области.

ПО - программное обеспечение.

ТС - технические средства.

ПТК (программно-технический комплекс) - совокупность средств вычислительной техники и программного обеспечения.

СУБД - система управления базами данных.

СрЗИ - средство защиты информации - техническое, программное, программно-техническое средство, предназначенные или используемые для защиты информации.

Эксплоит (от англ. exploit) - специализированное программное обеспечение, разработанное для проведения атак с использованием конкретной уязвимости.

СУУ - система управления уязвимостями.

API - Application Programming Interface.

ARC - Automatic Reference Counting.

CA - Certification authority.

CSRF - Cross-Site Request Forgery.

DHCP - Dynamic Host Configuration Protocol.

DNS - Domain Name System.

DTP - Dynamic Trunking Protocol.

HTTP - HyperText Transfer Protocol.

IP - Internet Protocol.

IPC - Inter-process Communication.

LFI - Local File Inclusion.

MAS VS - The Mobile Application Security Verification Standard.

OWASP - Open Web Application Security Project.

PIE - Position Independent Executable.

RFI - Remote File Inclusion.

SQL - Structured Query Language.

SSL - Secure Sockets Layer.

TLS - Transport Layer Security.

URL - Uniform Resource Locator.

VLAN - Virtual Local Area Network.

VPN - Virtual Private Network.

WAF - Web Application Firewall.

WSDL - Web Services Description Language.

XML - extensible Markup Language.

XSS - Cross-Site Scripting.

CVE - Common Vulnerabilities and Exposures.

CVSS - Common Vulnerability Scoring System.

FQDN Fully - Qualified Domain Name.

OSVDB - Open Source Vulnerability Database.

БДУ - Банк данных угроз.

II. Разграничение ответственности

4. Мингосуправления Московской области обеспечивает:

контроль за исполнением Оператором ИС требований настоящего Регламента.

5. ГКУ МО "ЦИБ МО" обеспечивает:

выявление уязвимостей, связанных с ошибками кода в ИС, ПО, ПТК и СрЗИ;

выявление уязвимостей, связанных с настройками ИС, ПО, ПТК и СрЗИ;

выявление уязвимостей, связанных с взаимодействием СрЗИ с ИС, ПО и ПТК;

разработку отчетов о выявленных уязвимостях;

информирование Оператора ИС о выявленных уязвимостях;

подготовку указаний и рекомендаций по устранению выявленных уязвимостей;

ведение и актуализацию реестра уязвимостей;

анализ и оценку достаточности реализации мер по устранению уязвимостей;

контроль устранения уязвимостей.

6. Оператор ИС обеспечивает:

предоставление актуальных сведений в ГКУ МО "ЦИБ МО" о контактных лицах, ответственных за информационную безопасность и взаимодействие с Центром системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Московской области (далее - контактное лицо), в течение суток со дня назначения контактного лица;

предоставление актуальных сведений о ИС, ПО, ПТК и СрЗИ, эксплуатируемых оператором ИС, по запросу в ГКУ МО "ЦИБ МО";

мониторинг задач на устранение уязвимостей;

своевременное оповещение ГКУ МО "ЦИБ МО" об инцидентах ИБ, связанных с эксплуатацией уязвимостей;

реализацию всех доступных мер для обеспечения необходимого уровня защиты информации и постоянный контроль уровня защищенности информации в эксплуатируемой информационной системе;

реализацию доступных мер по устранению уязвимостей эксплуатируемой ИС;

организацию и проведение тестирования, установку обновлений ПО, ПТК и СрЗИ, подготовку отчетов о тестировании обновлений, планируемых к применению в продуктивном контуре ИС в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств от 28.10.2022 (при наличии технической возможности);

управление рисками при установке обновлений ПО, ПТК и СрЗИ в эксплуатируемой ИС.

III. Порядок выявления уязвимостей

7. В ходе мероприятий по поиску уязвимостей в информационных системах Операторов ИС, работники ГКУ МО "ЦИБ МО" могут использовать различные инструменты и работы в соответствии с приложением к настоящему Регламенту.

8. Доступ к инструментам выявления (поиска) уязвимостей осуществляется уполномоченными работниками ГКУ МО "ЦИБ МО" в соответствии с их должностными обязанностями.

9. Перечень проверяемых уязвимостей подлежит обновлению в реестре уязвимостей еженедельно, а также в случае появления информации о новых уязвимостях.

10. Актуализация реестра уязвимостей осуществляется из доверенных источников, в том числе базы уязвимостей CVE, OSVDB и ФСТЭК России.

11. Выявление, анализ и контроль устранения уязвимостей, как на этапе создания/модернизации, так и в процессе эксплуатации ИС, производится ГКУ МО "ЦИБ МО" с периодичностью:

ПО и ПТК - не реже 1 раз в месяц;

СУБД - не реже 1 раз в полгода;

гипервизоры - не реже 1 раз в полгода;

сетевое оборудование - не реже 1 раз в 3 месяца;

ресурсов, опубликованных в общедоступную сеть Интернет, - не реже 1 раза в неделю.

12. В случае появления информации о новых уязвимостях, входящих в модель угроз ИС или имеющих оценку 9.5 и выше, ГКУ МО "ЦИБ МО" в течение 7 дней проводит работы по их выявлению на всех информационных ресурсах, размещенных в ЕИТО Московской области.

13. В случае публикации в общедоступных источниках информации о новых уязвимостях в ПО, ПТК и СрЗИ, используемых в ИС, ГКУ МО "ЦИБ МО" проводит работы по выявлению, анализу и контролю устранения уязвимостей.

14. Оценка критичности уязвимостей проводится ГКУ МО "ЦИБ МО" в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств от 28.10.2022.

IV. Порядок регистрации выявленных уязвимостей

15. При выявлении уязвимостей в ПО, ПТК и СрЗИ, используемых в ИС операторов ИС, ГКУ МО "ЦИБ МО" готовит отчет, содержащий следующую информацию:

о критичности уязвимостей;

об объекте уязвимости;

описание выявленной уязвимости;

рекомендации по устранению.

16. Сформированный отчет направляется в адрес ответственных за информационную безопасность Операторов ИС посредством трекера задач на устранение уязвимостей в ССУ, расположенной по адресу cib.rm.mosreg.ru, или на электронную почту, или МСЭД, или ЗК МСЭД.

V. Порядок устранения уязвимостей

17. Оператор ИС самостоятельно проводит мониторинг появления задач на устранение уязвимостей.

18. В зависимости от уровня критичности выявленных уязвимостей ПО, ПТК и СрЗИ, в ИС, используемых операторов ИС, работниками ГКУ МО "ЦИБ МО" принимается решение о необходимости их устранения.

19. В отношении уязвимостей ПО, ПТК и СрЗИ, которым в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств от 28.10.2022 присвоен критический уровень, рекомендуется принять меры по их устранению в течение 24 часов.

20. В отношении уязвимостей ПО, ПТК и СрЗИ, которым в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств от 28.10.2022 присвоен высокий уровень критичности, рекомендуется принять меры по их устранению в течение 7 дней.

21. В отношении уязвимостей ПО, ПТК и СрЗИ, которым в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств от 28.10.2022 присвоен средний уровень критичности, рекомендуется принять меры по их устранению в течение 4 недель.

22. В отношении уязвимостей ПО, ПТК и СрЗИ, которым в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств от 28.10.2022 присвоен низкий уровень критичности, рекомендуется принять меры по их устранению в течение 4 месяцев.

23. Уязвимости программных, программно-аппаратных средств могут быть устранены путем установки обновления ПО, ПТК и СрЗИ или принятия компенсирующих организационных и технических мер защиты информации.

24. В случае если уязвимости содержатся в ПО, ПТК, СрЗИ, которые отсутствуют в едином реестре российских программ для электронных вычислительных машин и баз данных, формирование которого осуществляет Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации, и уязвимость можно устранить посредством установки обновления, то решение об установке такого обновления принимается Оператором ИС с учетом результатов тестирования этого обновления, проведенного в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств от 28.10.2022, и оценки ущерба от нарушения функционирования информационной системы по результатам установки обновления.

25. В случае невозможности получения, установки и тестирования обновлений ПО, ПТК и СрЗИ, то в целях предотвращения эксплуатации выявленных уязвимостей принимаются компенсирующие меры защиты информации.

26. Выбор компенсирующих мер по защите информации осуществляется Оператором ИС по согласованию с ГКУ МО "ЦИБ МО" в установленном ГКУ МО "ЦИБ МО" порядке.

27. Компенсирующими организационными и техническими мерами, направленными на предотвращение возможности эксплуатации уязвимостей, могут являться:

изменение конфигурации уязвимых компонентов ИС, в том числе в части предоставления доступа к их функциям, исполнение которых может способствовать эксплуатации выявленных уязвимостей;

ограничение по использованию уязвимых программных, программно-аппаратных средств или их перевод в режим функционирования, ограничивающий исполнение функций, обращение к которым связано с использованием выявленных уязвимостей (например, отключение уязвимых служб и сетевых протоколов, использование WAF и др.);

резервирование компонентов ИС, включая резервирование серверов, телекоммуникационного оборудования и каналов связи;

использование сигнатур, решающих правил средств защиты информации, обеспечивающих выявление в информационной системе признаков эксплуатации уязвимостей;

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

28. По результатам устранения уязвимостей Операторами ИС в течение семи дней со дня их устранения направляется информация в адрес ГКУ МО "ЦИБ МО" о принятых мерах по устранению уязвимостей способами, предусмотренными в пункте 4.2 настоящего Регламента.

ГАРАНТ:

По-видимому, в предыдущем абзаце допущена опечатка. В настоящем Регламенте не содержится пункт 4.2

29. В случае если в установленные настоящим Регламентом сроки Оператор ИС не предпринял мер по устранению уязвимостей или не оповестил о невозможности принятия таких мер, то ГКУ МО "ЦИБ МО" незамедлительно информирует об этом Мингосуправления Московской области в целях принятия им решения о прекращении доступа к ресурсам ИС, размещенных на вычислительных ресурсах ЕИТО в соответствии с распоряжением Министерства государственного управления, информационных технологий и связи Московской области от 19.07.2017 N 10-87/РВ "Об утверждении регламента предоставления доступа к ресурсам информационных систем, размещенных на вычислительных ресурсах Единой инфраструктуры технологического обеспечения Правительства Московской области".

Приложение
к Регламенту

Основные инструменты и работы,
которые могут проводиться работниками ГКУ МО "ЦИБ МО" в ходе мероприятий по поиску уязвимостей

I. Анализ защищенности веб-сервисов методом белого ящика

1. Независимый просмотр программного кода и порядок ввода ИС в эксплуатацию.

До передачи ПО в эксплуатацию выполняется независимый просмотр программного кода. Для этого в ГКУ МО "ЦИБ МО" назначаются ответственные работники, обладающие необходимой квалификацией в анализе безопасности программного кода (далее - Ответственный работник) либо проводятся работы с привлечением подрядной организации.

Ответственные работники выполняют анализ программного кода на предмет наличия ошибок, потенциальных уязвимостей и угроз.

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

После устранения всех найденных уязвимостей выполняется повторный независимый просмотр программного кода. Только при получении положительного заключения от ГКУ МО "ЦИБ МО" об отсутствии уязвимостей и ошибок в программном коде, ПО может быть передано в эксплуатацию.

Заключение независимого просмотра программного кода отражается в отчете тестирования ПО и подписывается лицом, уполномоченным приказом ГКУ МО "ЦИБ МО".

2. Статический анализ кода (SAST).

Статический анализ исходного кода программы применяется для выявления недостатков ПО (потенциально уязвимых конструкций) при выполнении конструирования и комплексирования ПО. Использование статического анализа позволяет находить и устранять недостатки программы на раннем этапе процесса разработки до начала выполнения квалификационного тестирования ПО.

При реализации статического анализа кода Ответственный работник получает файлы исходного кода, в отношении которых необходимо проведение статического анализа исходного кода программы.

Ответственный работник:

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

выполняет запуск инструментальных средств для проведения статического анализа исходного кода программы;

выполняет периодический мониторинг средства статического анализа, разрешает при необходимости проблемы, возникающие в процессе его функционирования;

выгружает отчеты из инструментальных средств, проводят валидацию и анализ полученных результатов, с последующей корректировкой отчетов при необходимости;

направляет материалы (отчеты), проанализированные на предыдущем этапе Оператору ИС для его доработки.

Оператор ИС организует доработку программы, а также отражает в эксплуатационных документах описания организационных или технических мер среды эксплуатации ПО, направленных на нейтрализацию уязвимости программы в соответствии с выбранной стратегией, если необходимо.

3. Требования к защищенности веб-сервисов.

В таблице 1 представлены обобщенные требования, на соответствие которым может проверяться веб-сервис, при анализе защищенности методом белого ящика.

Таблица 1

Категория	Описание
Основное	Наличие не описанных классов бизнес-логики
	Классы, содержащие секреты безопасности (например, пароли), доступны только через защищенные API
	Секреты с открытым текстом не хранятся в памяти в течение длительного времени
	Проверяются границы массива на предмет возможного доступа к данным вне массива
	Вся конфиденциальная информация, используемая приложением, была идентифицирована
	Являются ли внешние библиотеки, инструменты, плагины, используемые функциями приложения, самой последней версией?
Бизнес-логика и дизайн	Наличие неиспользуемых конфигураций бизнес-логики
	Если параметры запроса используются для идентификации методов бизнес-логики, существует ли правильное сопоставление прав пользователей и разрешенных им действий
	Присутствуют ли динамические переменные экземпляра в объектах формы, которые привязываются к пользовательским вводам. Есть ли у них значения по умолчанию?
	Присутствуют ли динамические переменные экземпляра в объектах формы, которые привязываются к пользовательским вводам. Инициализированы ли они перед привязкой формы?
	Присутствуют ли динамические переменные экземпляра в объектах формы, которые привязываются к пользовательским вводам. Есть ли у них значения по умолчанию?
	Есть ли какая-нибудь конфигурация по умолчанию, такая как Access-ALL?
	Применяется ли конфигурация ко всем файлам и пользователям?
	Применяется ли проверка ко всем запросам и всем входным данным?
	Присутствует ли проверка специальных символов?
	Есть ли какие-то особые запросы, пропущенные без валидации передаваемых/получаемых данных проверки?
	Поддерживается ли в проекте какой-либо список исключений для параметров или функций, подлежащих проверке?
	Включает ли проект совместное использование сеанса между компонентами/модулями? Правильно ли подтвержден сеанс на обоих концах?
	Использует ли дизайн какие-либо повышенные права операционной системы (далее - ОС)/системы для внешних подключений/команд?
	Есть ли какие-либо известные недостатки в используемых API/технологиях?
	Обеспечивает ли структура проектирования какие-либо встроенные средства контроля безопасности?
	Сокращаются ли привилегии по возможности?
	Корректно ли обрабатывается отказы в работе?
Авторизация	Правильно ли размещена проверка подлинности и авторизации
	Запрещено выполнение действий после недопустимого запроса. Т.е. когда проверка аутентификации/авторизации не проходит
	Правильно ли выполнены проверки? Есть ли какой-нибудь недокументированный параметр?
	Применена ли проверка ко всем необходимым файлам и папкам в корневом веб-каталоге?
	Проводятся ли проверки безопасности перед обработкой входных данных?
	В случае аутентификации, управляемой контейнером: основана ли аутентификация только на веб-методах?
	В случае аутентификации, управляемой контейнером: применяется ли аутентификация ко всем ресурсам?
	Раскрывается ли пользовательский пароль в файлах/журналах/консоли?
	Требует ли дизайн приложения проверки подлинности сервера (меры защиты от спуфинга)?
	Поддерживает ли приложение срок действия пароля?
	Применяется ли проверка сложности пароля?
Менеджмент сессий	Надежно ли работает обработка сессий?
Криптография	Пароль хранится в зашифрованном виде
	Учетные данные базы данных хранятся в зашифрованном формате
	Данные отправляются по зашифрованному каналу
	Вся ли личная и конфиденциальная информация пересылается по сети в зашифрованном виде?
	Использует ли приложение пользовательские схемы для хеширования и/или криптографии?
	Ключи не хранятся в коде
	Являются ли криптографические функции, используемые приложением, последней версией этих протоколов, исправлены ли они и предусмотрены ли они для их обновления?
	Есть ли какие-то особые запросы, пропущенные при проверке?
Валидация входных данных	Все ли ненадежные входные данные проверяются? Входные данные ограничиваются и проверяются по типу, длине, формату и диапазону
Логгирование и аудит	Регистрируются ли в журналах личная информация, пароли или другая конфиденциальная информация?
	Регистрируют ли журналы аудита попытки подключения (как успешные, так и неудачные)?
	Есть ли процесс(ы) для чтения журналов аудита на предмет непреднамеренного/вредоносного поведения?
Управление пользователями и аутентификация	Документированы привилегии на основе пользователей и ролей
	Файлы cookie аутентификации не сохраняются
	Файлы cookie аутентификации зашифрованы
	Учетные данные для аутентификации не передаются в HTTP GET запросе
	Проверки авторизации являются детальными (на уровне страницы и каталога)
	Авторизация на основе четко определенных ролей
	Авторизация работает правильно и ее нельзя обойти при манипуляциях с параметрами
	Авторизацию нельзя обойти манипуляциями с файлами cookie
Управление сессиями	В URL-адресах не передаются параметры сеанса
	Срок действия сессионных файлов cookie истекает в разумные сроки
	Сессионные cookie-файлы зашифрованы
	Данные сессии валидируются
	Идентификатор сессии сложный
	Сессионное хранилище безопасно
	Сессия имеет таймаут бездействия
	Данные проверяются на стороне сервера
	Все ли входные данные XML проверяются на соответствие согласованной схеме?
	Правильная ли кодировка применена ко всем данным, выводимым приложением?
	Заголовки HTTP проверяются для каждого запроса
Веб-сервисы	Адрес конечных точек веб-служб на языке описания веб-служб (WSDL) проверяется на достоверность
	Ненужные протоколы веб-служб отключены
	Веб-сервис имеет протокол документации, отключен, если приложение не требует динамической генерации WSDL

II. Анализ защищенности веб-сервисов методом черного ящика (DAST)

1. На данном этапе производятся ручные и автоматические проверки на наличие уязвимостей в приложении, в том числе из списка OWASP Тор-10.

Осуществляется проверка наличия следующих уязвимостей:

доступ к файлам, содержащим учетные данные пользователей, архивам с базами данных и другим файлам, раскрывающим чувствительную информацию об ИС;

использование незащищенного соединения при работе с чувствительными пользовательскими данными;

отсутствие кодирования пользовательских данных перед выводом в браузер (XSS);

вывод отладочной информации в сообщениях об ошибках;

возможность использования функций исполнения или включения кода (eval, require, use) или исполнения системных команд (system, qx, exec) с пользовательскими данными;

отсутствие фильтрации пользовательских данных, удаляющей служебные специальные символы, перед обработкой данных веб-приложением (SQL-Injection);

возможность обхода ограничений безопасности при загрузке файлов на сервер;

получение доступа с помощью специально сформированных запросов к произвольным файлам, хранящимся на сервере (LFI);

исполнение, с помощью специально сформированного запроса, удаленного файла на сервере (RFI);

отсутствие использования уникальных для каждого пользователя токенов или проверки заголовка HTTP_REFERER (CSRF);

использование нестойких алгоритмов шифрования;

использование слабых хэш-функций;

отсутствие ограничений на количество попыток прохождения авторизации пользователями.

2. Для автоматизированного анализа безопасности веб-приложений используются различные специализированные программные средства.

III. Анализ защищенности мобильных приложений под управлением операционных систем Android и iOS

1. Ответственный работник до передачи мобильного приложения (далее - МП) в эксплуатацию производит ручные проверки безопасности мобильного приложения на соответствие стандарту MASVS (The Mobile Application Security Verification Standard), а также возможен независимый просмотр программного кода с привлечением профильной подрядной организации.

2. При реализации анализа мобильного приложения Ответственный работник получает файлы формата АРК для Android систем и расшифрованные файлы формата IPA для IOS, в отношении которых необходимо проведение анализа мобильного приложения.

3. Ответственный работник выполняет анализ мобильных приложений на предмет наличия ошибок, потенциальных уязвимостей и угроз.

4. По результатам анализа мобильных приложений формируется отчет, который содержит описание всех замечаний и направляется в ИС для доработки ПО.

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

6. Заключение анализа защищенности мобильного приложения отражается в акте тестирования ПО и подписывается лицом, уполномоченным приказом ГКУ МО "ЦИБ МО".

IV. Анализ защищенности внешней и внутренней инфраструктур

1. Целью данных работ является выявление основных уязвимостей в инфраструктуре, формирование рекомендаций по устранению уязвимостей и контроль устранения выявленных уязвимостей.

Перед проведением работ необходимо сформировать:

описание ИС, архитектуру и сетевую карту инфраструктуры (при необходимости);

доступ к тестируемой инфраструктуре посредством VPN-доступа, если инфраструктура недоступна из сети Интернет;

перечень сервисов и хостов, которые необходимо проверить;

перечень наиболее критичных сервисов.

2. Работы по анализу защищенности инфраструктуры состоят из следующих этапов:

1) ответственный работник определяет оценку трудозатрат и сроков по планируемым работам, полный перечень информации и доступов, недостающих для проведения работ;

2) в назначенные даты ответственный работник проводит работы, включающие в себя следующие шаги:

производит сбор информации об объекте исследования. Целью данных работ является сбор максимально подробных сведений об ИС, ее структуре, информационных сервисах и работниках из публичных источников информации;

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

по результаты сканирования устанавливает следующие категории:

уязвимость - позволяет злоумышленнику выполнить проникновение в ИС, выполнить вредоносные действия (исключая атаки типа отказ от обслуживания). Данный вид уязвимости предполагает наличие способа эксплуатации;

потенциальная уязвимость - зафиксировано срабатывание сканера уязвимостей, но наличие уязвимости не удалось подтвердить ручной проверкой, либо эксплуатация уязвимости затруднена из-за настроек ИС. Для уязвимости может отсутствовать способ эксплуатации. Эксплуатация уязвимостей данного типа не предполагается. Наличие предполагаемой уязвимости фиксируется в отчете;

уязвимость, позволяющая выполнить атаку типа отказ от обслуживания - зафиксировано срабатывание сканера или нарушение доступности ИС в результате сканирования. Эксплуатация уязвимостей данного типа не предполагается. Наличие уязвимости фиксируется в отчете;

3) по итогам работы ответственный работник формирует отчет и передает информацию о найденных уязвимостях оператору ИС для их дальнейшего устранения.

Отчет по результатам анализа защищенности содержит:

полный перечень найденных уязвимостей;

описание уязвимостей и уровень критичности;

рекомендации по устранению уязвимостей;

заключение по уровню защищенности инфраструктуры ИС;

4) оператор ИС по результату устранения уязвимостей формирует отчет и направляет его в адрес ГКУ МО "ЦИБ МО" посредством трекера задач на устранение уязвимостей в СУУ, расположенной по адресу cib.rm.mosreg.ru, или на электронную почту, или МСЭД, или ЗК МСЭД.

V. Моделирование атаки внешнего злоумышленника

1. Сбор информации об объекте исследования.

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

2. Получение информации об используемых публичных сервисах, запущенных на серверных системах.

На данном этапе выполняется сканирование потенциальных векторов проникновения (IP-адресов хостов) с помощью сетевых сканеров уязвимостей. При этом сканер выбирается с точки зрения эффективности обнаружения им уязвимостей определенного типа и исходя из перечня служб, запущенных на хосте.

Результаты сканирования интерпретируются в соответствии с категориями, аналогичными для анализа защищенности внешней и внутренней инфраструктур.

Тестирование на проникновение в ИС осуществляется как циклический процесс, используются при этом уязвимости первой категории.

Целью процесса в данном случае является проникновение с помощью обнаруженных уязвимостей в публичных сервисах и приложениях ресурсов Московской области непосредственно в ИС.

По результатам сканирования формируется перечень методик эксплуатации выявленных уязвимостей.

3. Отчет по результатам проведения тестирования на проникновение.

Результаты тестирования на проникновение представляются в виде отчета, который включает в себя:

введение - отражает границы проведения работ и краткую суть проведенных работ, а также их цель;

резюме - содержит оценку эффективности защиты информационной системы от действий потенциальных нарушителей;

описание работ по внешнему тестированию на проникновение - отражает ход выполнения работ по внешнему тестированию на проникновение. Описываются все обнаруженные уязвимости, для каждой уязвимости указывается уровень критичности, и приводятся рекомендации по устранению уязвимости.

VI. Моделирование атаки внутреннего злоумышленника

В ходе моделирования атаки внутреннего злоумышленника (далее - внутреннее тестирование на проникновение) атака осуществляется не только на серверы, но и на оборудование других типов, в том числе сетевое оборудование и гипервизоры. Это обусловлено тем, что часть уязвимостей может находиться в том числе на сетевом оборудовании и гипервизорах.

1. Сбор информации об объекте исследования:

1) пассивный сбор информации.

Внутреннее тестирование на проникновение проводится без запроса каких-либо дополнительных сведений о сетевой инфраструктуре. Для проведения внутреннего тестирования используется только заранее предоставленный IP-адрес. В течение этапа пассивного сбора информации производится перехват пакетов на интерфейсе, подключенном в локальную сеть. Изучение информации, полученной посредством перехвата пакетов, позволяет получить представление об устройстве сети:

основные маршрутизаторы и промежуточное активное сетевое оборудование;

контроллеры домена (первичные и вторичные);

DNS-серверы, DHCP-серверы.

По итогам сбора информации также может быть сделан вывод о том, какую функцию выполняют рабочие станции в прослушиваемом сетевом сегменте.

Для перехвата и разбора пакетов используются специализированные программные средства;

2) получение информации об используемых публичных сервисах, запущенных на серверных системах.

В каждой подсети, в которой происходило тестирование, осуществляется сканирование сетевыми сканерами, цель которого определение активных хостов и сервисов в текущей подсети. При этом используются следующие методики сканирования:

сбор текстовых баннеров сервисов, запущенных на открытых портах;

определение названия и версии операционной системы, работающей на сканируемом адресе;

определение версий сервисов и наличия в них уязвимостей.

2. Тестирование на проникновение:

1) тестирование на проникновение на сетевом уровне.

Тестирование на проникновение на сетевом уровне необходимо для того, чтобы ответить на вопрос, возможно ли нарушителю преодолеть защитные меры в виде межсетевых экранов и сегментации на втором уровне сетевой модели OSI.

В рамках тестирования протоколов коммутации могут производится различные атаки, направленные на поиск уязвимостей в сетевых протоколах (такие как DTP Fake, VLAN hopping, VLAN double framing). Данные атаки осуществляются с помощью специализированных приложений. Перечень реализуемых атак ограничен в силу того, что остальные атаки с высокой долей вероятности приводят к отказам в обслуживании в ИС;

2) тестирование на проникновение на уровне приложений.

Тестирование на проникновение на уровне приложений необходимо для того, чтобы ответить на вопрос, возможно ли получить несанкционированный доступ к данным, обладая требуемым сетевым доступом, но не обладая достаточными правами в приложении или операционной системе;

3) попытка получения доступа к активному сетевому оборудованию.

Во время сканирования локальной сети может быть выявлено активное сетевое оборудование, на котором не изменены пароли по умолчанию на административных интерфейсах. Получение доступа к такому оборудованию позволяет изменить маршрутизацию сетевых пакетов;

4) проверка последних установленных обновлений безопасности.

Важной частью тестирования на проникновение является проверка оперативности установки обновлений на серверы и рабочие станции. Сканирование позволяет выявить наличие потенциальных уязвимостей на серверах и рабочих станциях. Для обнаруженных уязвимостей выполняется их эксплуатация;

5) тестирование системы управления базами данных.

Для тестирования уязвимостей в конфигурации СУБД используется комплекс специальных утилит. Сканирование позволяет выявить наличие потенциальных уязвимостей в СУБД и позволяют получить данные о схеме и словаре базы данных, а также о наличии уязвимостей, позволяющих повысить привилегии от пользователей до администраторов базы данных. Для обнаруженных уязвимостей выполняется попытка их эксплуатации.

3. Эксплуатация обнаруженных уязвимостей.

Для выполнения действий по подтверждению возможной эксплуатации уязвимостей могут применяться специализированные инструменты. Для некоторых видов уязвимостей возможно использование эксплоитов скомпилированных самостоятельно из исходного кода. Для получения исходного кода эксплоитов допускается использовать специализированные сайты.

При необходимости для эксплуатации уязвимостей используются также программы, написанные специально на скриптовых языках программирования Python, Perl и др.

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

4. Отчет по результатам проведения тестирования на проникновение.

Результаты тестирования на проникновение представляются в виде отчета, содержащего следующие разделы:

введение отражает границы проведения работ и краткую суть проведенных работ, а также их цель;

резюме содержит оценку эффективности защиты ИС от действий потенциальных нарушителей;

описание работ по внутреннему тестированию на проникновение отражает ход выполнения работ по внутреннему тестированию на проникновение. Описываются все обнаруженные уязвимости, для каждой уязвимости указывается уровень критичности, и приводятся рекомендации по устранению уязвимости.