ГОСТ Р МЭК 62443-3-3—2016
- SL-C (UC. система управления) 3: SR 2.6;
- SL-C (UC. система управления) 4; SR 2.6.
6.9 SR 2.7 — Контроль параллельных сеансов
6.9.1 Требование
Система управления должна обеспечивать возможность ограничения числа параллельных сеан
сов на интерфейс для того или иного пользователя (физического лица, программного процесса или
устройства) до конфигурируемого числа сеансов.
6.9.2 Целесообразность и дополнительная методологическая основа
Если не налагать ограничения, то может произойти отказ в обслуживании из-за нехватки ресурсов.
Существует компромисс между потенциальной блокировкой соответствующего пользователя и блоки
ровкой всех пользователей и сервисов из-за нехватки ресурсов системы управления. По-видимому,
требуется методологическая основа от поставщиков продуктов и/или системных интеграторов для пре
доставления достаточной информации о порядке установления максимального числа сессий.
6.9.3 Расширения требований
Отсутствуют.
6.9.4 Уровни безопасности
Далее приведены требования для уровней SL. относящихся к SR 2.7 — Контроль параллельных
сеансов:
- SL-C (UC. система управления) 1; не определено;
- SL-C (UC. система управления) 2: не определено;
- SL-C (UC. система управления) 3: SR 2.7;
- SL-C (UC, система управления) 4; SR 2.7.
6.10 SR 2.8 — События, подлежащие аудиту
6.10.1 Требование
Система управления должна обеспечивать возможность генерации записей аудита, относящих
ся к безопасности, для следующих категорий; управление доступом, ошибки запроса, события опера
ционной системы, события системы управления, события дублирования и замещения, изменения в
конфигурациях, потенциальная разведывательная активность и события журнала регистрации аудита.
Отдельно взятые записи аудита должны включать в себя временную метку, источник (исходное устрой
ство. программный процесс или учетную запись пользователя — физического лица), категорию, тип,
ID
события и результат события.
6.10.2 Целесообразность и дополнительная методологическая основа
Цель этого требования — фиксация наступления важных событий, которые необходимо подвер
гать аудиту как существенные и значимые для безопасности системы управления. Аудит активности
пользователей может отражаться на функционировании систем управления. Функцию аудита безопас
ности обычно координируют с функцией мониторинга работоспособности исостояния сети, которая мо
жет быть реализована и принадлежать другой зоне безопасности. При составлении перечня событий,
подлежащих аудиту, следует учитывать общепризнанные и одобренные формы и руководства по кон
фигурированию. Политики и регламенты безопасности по возможностидолжны определять те события,
подлежащие аудиту, которые допускают поддержание исследований постфактум инцидентов безопас
ности. Кроме того, желательно, чтобы записей аудита было достаточно для отслеживания эффектив
ности и корректного функционирования механизмов безопасности, применяемых для обеспечения со
ответствия требованиям настоящего стандарта.
Следует отметить, что требование фиксации событий применимо в контексте функциональности
конкретной системы, точнее, в контексте требований безопасности конкретной системы для отдельно
взятого уровня. Например, требование фиксации событий аутентификации (в категории управления до
ступом) в системе с SL 1 применимо только к уровню функциональности аутентификации, требуемому
для SL 1 в соответствии с требованиями раздела 5. События могут наступать в любом компоненте си
стемы управления (например, события входа в систему) или отслеживаться посредством специализи
рованных мониторов. Например, сканирование портов может быть зафиксировано системой обнаруже
ния несанкционированных проникновений (IDS) или системой предотвращения несанкционированных
проникновений (IPS).
25