Куда я попал?
ГОСТ Р № 22301 от 01.01.2022
Надежность в технике. Системы менеджмента непрерывности деятельности. Требования
Р. 8 п. 4 пп. 2 ппп. 1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РИ.8
РИ.8 Определение и назначение ролей, связанных с реагированием на инциденты защиты информации - ролей группы реагирования на инциденты защиты информации (ГРИЗИ)
3-Н 2-О 1-О
3-Н 2-О 1-О
NIST Cybersecurity Framework (RU):
PR.IP-9
PR.IP-9: Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное восстановление)
PR.IP-1
PR.IP-1: С учетом соответствующих принципов безопасности (например, концепция минимальной функциональности) создается и поддерживается базовая конфигурация информационных технологий / промышленных систем управления
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ИНЦ.1
ИНЦ.1 Определение лиц, ответственных за выявление инцидентов и реагирование на них
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.7.4
ВРВ.7.4 Ролей, связанных с реагированием на инциденты;
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.16.1.5
A.16.1.5 Реагирование на инциденты информационной безопасности
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами
Мера обеспечения информационной безопасности: Реагирование на инциденты информационной безопасности должно осуществляться в соответствии с документально оформленными процедурами
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.4.2
6.4.2
Определенные Требования к Подходу:
Для общедоступных веб-приложений развертывается автоматизированное техническое решение, которое постоянно обнаруживает и предотвращает веб-атаки, по крайней мере, со следующими:
Определенные Требования к Подходу:
Для общедоступных веб-приложений развертывается автоматизированное техническое решение, которое постоянно обнаруживает и предотвращает веб-атаки, по крайней мере, со следующими:
- Устанавливается перед общедоступными веб-приложениями и настраивается для обнаружения и предотвращения веб-атак.
- Активно работает и обновляется по мере необходимости.
- Создание журналов аудита.
- Настроен либо на блокировку веб-атак, либо на генерацию предупреждения, которое немедленно проверяется.
Цель Индивидуального подхода:
Общедоступные веб-приложения защищены в режиме реального времени от вредоносных атак.
Примечания по применению:
Это новое требование заменит требование 6.4.1, как только наступит дата его вступления в силу.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Общедоступные веб-приложения защищены в режиме реального времени от вредоносных атак.
Примечания по применению:
Это новое требование заменит требование 6.4.1, как только наступит дата его вступления в силу.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 6.4.2 Для общедоступных веб-приложений изучите параметры конфигурации системы и журналы аудита, а также опросите ответственный персонал, чтобы убедиться, что автоматизированное техническое решение, которое обнаруживает и предотвращает веб-атаки, действует в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Общедоступные веб-приложения являются основными целями для злоумышленников, а плохо закодированные веб-приложения обеспечивают злоумышленникам легкий путь для получения доступа к конфиденциальным данным и системам.
Надлежащая практика:
При использовании автоматизированных технических решений важно включить процессы, которые облегчают своевременное реагирование на предупреждения, генерируемые решениями, чтобы можно было смягчить любые обнаруженные атаки. Такие решения также могут быть использованы для автоматизации смягчения последствий, например, контроля ограничения скорости, который может быть реализован для смягчения последствий атак методом перебора и атак с перечислением.
Примеры:
Брандмауэр веб-приложений (WAF), который может быть локальным или облачным, устанавливаемый перед общедоступными веб-приложениями для проверки всего трафика, является примером автоматизированного технического решения, которое обнаруживает и предотвращает веб-атаки (например, атаки, включенные в требование 6.2.4). WAFS фильтруют и блокируют несущественный трафик на прикладном уровне. Правильно настроенный WAF помогает предотвратить атаки прикладного уровня на приложения, которые неправильно закодированы или настроены.
Общедоступные веб-приложения являются основными целями для злоумышленников, а плохо закодированные веб-приложения обеспечивают злоумышленникам легкий путь для получения доступа к конфиденциальным данным и системам.
Надлежащая практика:
При использовании автоматизированных технических решений важно включить процессы, которые облегчают своевременное реагирование на предупреждения, генерируемые решениями, чтобы можно было смягчить любые обнаруженные атаки. Такие решения также могут быть использованы для автоматизации смягчения последствий, например, контроля ограничения скорости, который может быть реализован для смягчения последствий атак методом перебора и атак с перечислением.
Примеры:
Брандмауэр веб-приложений (WAF), который может быть локальным или облачным, устанавливаемый перед общедоступными веб-приложениями для проверки всего трафика, является примером автоматизированного технического решения, которое обнаруживает и предотвращает веб-атаки (например, атаки, включенные в требование 6.2.4). WAFS фильтруют и блокируют несущественный трафик на прикладном уровне. Правильно настроенный WAF помогает предотвратить атаки прикладного уровня на приложения, которые неправильно закодированы или настроены.
Requirement 6.3.1
6.3.1
Определенные Требования к Подходу:
Уязвимости в системе безопасности выявляются и устраняются следующим образом:
Определенные Требования к Подходу:
Уязвимости в системе безопасности выявляются и устраняются следующим образом:
- Новые уязвимости в системе безопасности выявляются с использованием признанных в отрасли источников информации об уязвимостях системы безопасности, включая оповещения от международных и национальных групп реагирования на компьютерные чрезвычайные ситуации (CERT).
- Уязвимостям присваивается рейтинг рисков на основе лучших отраслевых практик и учета потенциального воздействия.
- Рейтинги рисков определяют, как минимум, все уязвимости, которые считаются высокорискованными или критичными для окружающей среды.
- Рассматриваются уязвимости для индивидуального и пользовательского программного обеспечения, а также программного обеспечения сторонних производителей (например, операционных систем и баз данных).
Цель Индивидуального подхода:
Новые системные и программные уязвимости, которые могут повлиять на безопасность данных учетной записи или CDE, отслеживаются, каталогизируются и оцениваются риски.
Примечания по применению:
Это требование не достигается и не совпадает с проверками уязвимостей, выполняемыми для требований 11.3.1 и 11.3.2. Это требование касается процесса активного мониторинга отраслевых источников информации об уязвимостях и определения организацией ранжирования рисков, связанных с каждой уязвимостью.
Определенные Процедуры Тестирования Подхода:
Новые системные и программные уязвимости, которые могут повлиять на безопасность данных учетной записи или CDE, отслеживаются, каталогизируются и оцениваются риски.
Примечания по применению:
Это требование не достигается и не совпадает с проверками уязвимостей, выполняемыми для требований 11.3.1 и 11.3.2. Это требование касается процесса активного мониторинга отраслевых источников информации об уязвимостях и определения организацией ранжирования рисков, связанных с каждой уязвимостью.
Определенные Процедуры Тестирования Подхода:
- 6.3.1.a Изучите политики и процедуры для выявления уязвимостей в системе безопасности и управления ими, чтобы убедиться, что процессы определены в соответствии со всеми элементами, указанными в этом требовании.
- 6.3.1.b Опросите ответственный персонал, изучите документацию и проследите за процессами, чтобы убедиться, что уязвимости в системе безопасности выявлены и устранены в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Классификация рисков (например, как критических, высоких, средних или низких) позволяет организациям быстрее выявлять, расставлять приоритеты и устранять элементы с наибольшим риском и снижать вероятность использования уязвимостей, представляющих наибольший риск.
Надлежащая практика:
Методы оценки уязвимостей и присвоения рейтингов рисков будут варьироваться в зависимости от среды организации и стратегии оценки рисков.
Когда организация присваивает свои рейтинги рисков, ей следует рассмотреть возможность использования формальной, объективной, обоснованной методологии, которая точно отражает риски уязвимостей, относящихся к организации, и переводит их в соответствующий приоритет, присвоенный организации для устранения.
Процессы организации по управлению уязвимостями должны быть интегрированы с другими процессами управления — например, управление рисками, управление изменениями, управление исправлениями, реагирование на инциденты, безопасность приложений, а также надлежащий мониторинг и протоколирование этих процессов. Это поможет обеспечить надлежащее выявление и устранение всех уязвимостей. Процессы должны поддерживать текущую оценку уязвимостей. Например, уязвимость, первоначально идентифицированная как низкая степень риска, может впоследствии стать более высокой степенью риска. Кроме того, уязвимости, которые по отдельности считаются низким или средним риском, могут в совокупности представлять высокий или критический риск, если они присутствуют в одной и той же системе или если они используются в системе с низким уровнем риска, что может привести к доступу к CDE.
Примеры:
Некоторые организации, которые выпускают предупреждения для информирования организаций о срочных уязвимостях, требующих немедленных исправлений/обновлений, - это национальные группы компьютерной готовности к чрезвычайным ситуациям/ реагирования (сертификаты) и поставщики.
Критерии ранжирования уязвимостей могут включать критичность уязвимости, выявленной в предупреждении от Форума Групп реагирования на инциденты и безопасности (FIRST) или сертификата, рассмотрение оценки CVSS, классификацию поставщиком и/или тип затронутых систем.
Дополнительная информация:
Надежные источники информации об уязвимостях включают веб-сайты поставщиков, отраслевые группы новостей, списки рассылки и т.д. Если программное обеспечение разрабатывается собственными силами, внутренняя команда разработчиков должна также рассмотреть источники информации о новых уязвимостях, которые могут повлиять на приложения, разработанные внутри компании. Другие методы обеспечения выявления новых уязвимостей включают решения, которые автоматически распознают и предупреждают об обнаружении необычного поведения. Процессы должны учитывать широко опубликованные эксплойты, а также атаки “нулевого дня”, нацеленные на ранее неизвестные уязвимости.
Для программного обеспечения, изготовленного на заказ и изготовленного на заказ, организация может получать информацию о библиотеках, фреймворках, компиляторах, языках программирования и т.д. из общедоступных надежных источников (например, специальных ресурсов и ресурсов от разработчиков компонентов). Организация также может самостоятельно анализировать сторонние компоненты и выявлять уязвимости.
Для контроля над программным обеспечением, разработанным собственными силами, организация может получать такую информацию из внешних источников. Организация может рассмотреть возможность использования программы “вознаграждение за ошибки”, в рамках которой она размещает информацию (например, на своем веб-сайте), чтобы третьи стороны могли связаться с организацией с информацией об уязвимостях. Внешние источники могут включать независимых исследователей или компании, которые сообщают организации о выявленных уязвимостях, и могут включать такие источники, как Общая система оценки уязвимостей (CVSS) или Методология оценки рисков OWASP
Классификация рисков (например, как критических, высоких, средних или низких) позволяет организациям быстрее выявлять, расставлять приоритеты и устранять элементы с наибольшим риском и снижать вероятность использования уязвимостей, представляющих наибольший риск.
Надлежащая практика:
Методы оценки уязвимостей и присвоения рейтингов рисков будут варьироваться в зависимости от среды организации и стратегии оценки рисков.
Когда организация присваивает свои рейтинги рисков, ей следует рассмотреть возможность использования формальной, объективной, обоснованной методологии, которая точно отражает риски уязвимостей, относящихся к организации, и переводит их в соответствующий приоритет, присвоенный организации для устранения.
Процессы организации по управлению уязвимостями должны быть интегрированы с другими процессами управления — например, управление рисками, управление изменениями, управление исправлениями, реагирование на инциденты, безопасность приложений, а также надлежащий мониторинг и протоколирование этих процессов. Это поможет обеспечить надлежащее выявление и устранение всех уязвимостей. Процессы должны поддерживать текущую оценку уязвимостей. Например, уязвимость, первоначально идентифицированная как низкая степень риска, может впоследствии стать более высокой степенью риска. Кроме того, уязвимости, которые по отдельности считаются низким или средним риском, могут в совокупности представлять высокий или критический риск, если они присутствуют в одной и той же системе или если они используются в системе с низким уровнем риска, что может привести к доступу к CDE.
Примеры:
Некоторые организации, которые выпускают предупреждения для информирования организаций о срочных уязвимостях, требующих немедленных исправлений/обновлений, - это национальные группы компьютерной готовности к чрезвычайным ситуациям/ реагирования (сертификаты) и поставщики.
Критерии ранжирования уязвимостей могут включать критичность уязвимости, выявленной в предупреждении от Форума Групп реагирования на инциденты и безопасности (FIRST) или сертификата, рассмотрение оценки CVSS, классификацию поставщиком и/или тип затронутых систем.
Дополнительная информация:
Надежные источники информации об уязвимостях включают веб-сайты поставщиков, отраслевые группы новостей, списки рассылки и т.д. Если программное обеспечение разрабатывается собственными силами, внутренняя команда разработчиков должна также рассмотреть источники информации о новых уязвимостях, которые могут повлиять на приложения, разработанные внутри компании. Другие методы обеспечения выявления новых уязвимостей включают решения, которые автоматически распознают и предупреждают об обнаружении необычного поведения. Процессы должны учитывать широко опубликованные эксплойты, а также атаки “нулевого дня”, нацеленные на ранее неизвестные уязвимости.
Для программного обеспечения, изготовленного на заказ и изготовленного на заказ, организация может получать информацию о библиотеках, фреймворках, компиляторах, языках программирования и т.д. из общедоступных надежных источников (например, специальных ресурсов и ресурсов от разработчиков компонентов). Организация также может самостоятельно анализировать сторонние компоненты и выявлять уязвимости.
Для контроля над программным обеспечением, разработанным собственными силами, организация может получать такую информацию из внешних источников. Организация может рассмотреть возможность использования программы “вознаграждение за ошибки”, в рамках которой она размещает информацию (например, на своем веб-сайте), чтобы третьи стороны могли связаться с организацией с информацией об уязвимостях. Внешние источники могут включать независимых исследователей или компании, которые сообщают организации о выявленных уязвимостях, и могут включать такие источники, как Общая система оценки уязвимостей (CVSS) или Методология оценки рисков OWASP
NIST Cybersecurity Framework (EN):
PR.IP-9
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-1
PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g. concept of least functionality)
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
16.1.5
16.1.5 Реагирование на инциденты информационной безопасности
Мера обеспечения ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документально оформленными процедурами.
Руководство по применению
Реагирование на инциденты ИБ должно осуществляться назначенными контактными лицами и другими соответствующими лицами из числа самой организации или сторонних организаций (см. 16.1.1).
Реагирование должно включать в себя следующее:
- a) как можно более быстрый сбор свидетельств произошедшего;
- b) проведение криминалистического анализа ИБ по мере необходимости (см. 16.1.7);
- c) эскалация, если требуется;
- d) обеспечение того, что все выполняемые действия по реагированию соответствующим образом зарегистрированы для дальнейшего анализа;
- e) информирование о факте инцидента ИБ или любых существенных деталях о нем других лиц из числа самой организации или сторонних организаций в соответствии с принципом "необходимого знания";
- f) устранение недостатка(ов) ИБ, которые могут стать причиной или способствовать возникновению инцидента;
- g) после того, как инцидент успешно отработан, необходимо формально закрыть и записать его.
После инцидента должен проводиться анализ для выявления первопричины инцидента.
Дополнительная информация
Первоочередной целью реагирования на инцидент является возобновление "нормального уровня безопасности", а затем инициирование необходимого восстановления.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.