Соответствие требованиям

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

CIS Critical Security Controls v8 (The 18 CIS CSC)

Framework

18.2

Для проведения оценки соответствия по документу войдите в систему.

Список требований

Похожие требования

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":

п. 6. п.п. 5

6.5. Кредитные организации в части тестирования операционной надежности технологических процессов должны принимать организационные и технические меры, направленные на проведение сценарного анализа (в части возможной реализации информационных угроз в отношении критичной архитектуры, а также возникновения сбоев объектов информационной инфраструктуры), с учетом требований подпункта 2.1.5 пункта 2.1 Положения Банка России N 716-П и проводить с использованием результатов сценарного анализа тестирование готовности кредитной организации противостоять реализации информационных угроз в отношении критичной архитектуры.

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":

Requirement 11.4.3

11.4.3
Defined Approach Requirements:
External penetration testing is performed:

Per the entity’s defined methodology
At least once every 12 months
After any significant infrastructure or application upgrade or change
By a qualified internal resource or qualified external third party
Organizational independence of the tester exists (not required to be a QSA or ASV).

Customized Approach Objective:
External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities.

Defined Approach Testing Procedures:

11.4.3.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement.
11.4.3.b Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":

A.12.6.1

A.12.6.1 Процесс управления техническими уязвимостями
Мера обеспечения информационной безопасности: Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям, и должны быть приняты соответствующие меры в отношении связанного с этим риска информационной безопасности

A.18.2.3

A.18.2.3 Анализ технического соответствия
Мера обеспечения информационной безопасности: Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам информационной безопасности организации

CIS Critical Security Controls v7.1 (SANS Top 20):

CSC 20.2 CSC 20.2 Conduct Regular External and Internal Penetration Tests
Conduct regular external and internal penetration tests to identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully.

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":

Requirement 11.4.3

11.4.3
Определенные Требования к Подходу:
Выполняется внешнее тестирование на проникновение:

В соответствии с определенной организацией методологией
Не реже одного раза в 12 месяцев
После любого значительного обновления или изменения инфраструктуры или приложения
Квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной
Существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

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

Определенные Процедуры Тестирования Подхода:

11.4.3.a Изучите объем работ и результаты последнего внешнего теста на проникновение, чтобы убедиться, что тестирование на проникновение выполнено в соответствии со всеми элементами, указанными в этом требовании.
11.4.3.b Провести собеседование с персоналом, чтобы убедиться, что внешний тест на проникновение был выполнен квалифицированным внутренним ресурсом или квалифицированной внешней третьей стороной и что существует организационная независимость тестировщика (не обязательно быть QSA или ASV).

Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":

п. 1.8.

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

ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":

18.2.3

18.2.3 Анализ технического соответствия

Мера обеспечения ИБ

Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам ИБ организации.

Руководство по применению

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

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

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

Дополнительная информация

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

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

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

ИСО/МЭК ТО 27008 [13] содержит конкретные рекомендации, связанные с проверками технического соответствия.

12.6.1

12.6.1 Процесс управления техническими уязвимостями

Мера обеспечения ИБ

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

Руководство по применению

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

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

a) организация должна определить и установить роли и обязанности, связанные с управлением техническими уязвимостями, включая их мониторинг, оценку риска, исправление ошибок, отслеживание активов и любые необходимые обязанности по координации процесса;
b) для программного обеспечения и других технологий (на основе перечня активов, см. 8.1.1) следует идентифицировать информационные ресурсы, которые будут использоваться для выявления соответствующих технических уязвимостей и поддержания осведомленности о них; эти информационные ресурсы должны обновляться в соответствии с изменениями в перечне активов или при обнаружении новых и полезных ресурсов;
c) следует определить сроки реагирования на уведомления о потенциально значимых технических уязвимостях;
d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать применение пакетов исправлений к уязвимым системам или применение компенсирующих мер обеспечения ИБ;
e) в зависимости от того, насколько срочно необходимо устранить техническую уязвимость, предпринимаемые действия должны проводиться в соответствии с мерами по управлению изменениями (см. 12.1.2) или в соответствии с процедурами реагирования на инциденты ИБ (см. 16.1.5);
f) если доступно официальное исправление, следует оценить риски, связанные с его установкой (риски, связанные с уязвимостью, следует сравнить с рисками, которые могут возникнуть вследствие установки исправления);
g) пакеты исправлений должны быть проверены и оценены до их установки, чтобы быть уверенным в том, что они не приведут к недопустимым побочным эффектам; если исправлений не выпущено, следует рассмотреть иные меры обеспечения информационной безопасности, такие как:

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

h) следует вести журнал всех предпринятых действий;
i) процесс управления техническими уязвимостями следует регулярно контролировать и оценивать для обеспечения его эффективности и результативности;
j) в первую очередь следует обращать внимание на системы с высоким уровнем риска;
k) эффективный процесс управления техническими уязвимостями должен быть согласован с действиями по управлению инцидентами, что позволит передавать данные об уязвимостях группе реагирования на инциденты и дополнит процесс техническими процедурами, которые должны быть выполнены в случае инцидента;
l) необходимо определить процедуру для решения ситуации, когда уязвимость была выявлена, но подходящих мер еще не существует. В этой ситуации организация должна оценить риски, связанные с известной уязвимостью, и определить соответствующие действия по обнаружению и корректировке.

Дополнительная информация

Управление техническими уязвимостями может рассматриваться как подфункция процесса управления изменениями и, как следствие, может использовать преимущества процессов и процедур управления изменениями (см. 12.1.2 и 14.2.2).

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

Если адекватное тестирование исправлений невозможно, например из-за затрат или нехватки ресурсов, то следует рассмотреть возможность задержки его применения и оценить связанные с этим риски, основываясь на опыте, полученном от других пользователей. Может оказаться полезным использование ИСО/МЭК 27031 [14].

Связанные защитные меры

Ничего не найдено

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