SWIFT Customer Security Controls Framework v2022

РЗИ.5 Определение лиц, которым разрешены действия по внесению изменений в конфигурацию информационной инфраструктуры
3-О 2-О 1-О

4.1 Establish and Maintain a Secure Configuration Process 
Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications). Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard 

16.7 Use Standard Hardening Configuration Templates for Application Infrastructure
Use standard, industry-recommended hardening configuration templates for application infrastructure components. This includes underlying servers, databases, and web servers, and applies to cloud containers, Platform as a Service (PaaS) components, and SaaS components. Do not allow in-house developed software to weaken configuration hardening. 

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

УИ.2 Классификация в целях приоритизации изменений (например, плановые, срочные и критичные изменения) в критичную архитектуру.

УИ.1 Планирование, информирование вовлеченных подразделений о вносимых изменениях и контроль внесения изменений в критичную архитектуру.

4.1 Реализован и поддерживается процесс конфигурирования мер защиты
Описание процесса анализируется и обновляется раз в год или чаще.

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

2.2.4
Defined Approach Requirements: 
Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled. 

Customized Approach Objective:
System components cannot be compromised by exploiting unnecessary functionality present in the system component. 

Defined Approach Testing Procedures:

Purpose:
Unnecessary services and functions can provide additional opportunities for malicious individuals to gain access to a system. By removing or disabling all unnecessary services, protocols, daemons, and functions, organizations can focus on securing the functions that are required and reduce the risk that unknown or unnecessary functions will be exploited. 

Good Practice:
There are many protocols that could be enabled by default that are commonly used by malicious individuals to compromise a network. Disabling or removing all services, functions, and protocols that are not used minimizes the potential attack surface—for example, by removing or disabling an unused FTP or web server. 

Examples:
Unnecessary functionality may include, but is not limited to scripts, drivers, features, subsystems, file systems, interfaces (USB and Bluetooth), and unnecessary web servers. 

/STANDARD
Depending on his level of IT security practices, the user, a great deal of the time, is the first port of call for hackers trying to enter the system. It is therefore fundamental to implement a minimum level of security across the entire IT stock of the organization (user devices, servers, printers, phones, USB peripherals, etc.) by implementing the following measures:

In the event of a necessary exception from the general security rules applicable to devices, these devices must be isolated from the system (if it is impossible to update certain applications for interoperability reasons for example). 

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

2.2.4
Определенные Требования к Подходу:
Включаются только необходимые службы, протоколы, демоны и функции, а все ненужные функции удаляются или отключаются.

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

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

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

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

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

Operating system hardening (including for network devices) based on a Standard Operating Environment, disabling unneeded functionality (e.g. RDP, AutoRun, LanMan, SMB/NetBIOS, LLMNR and WPAD).
Relative Security Effectiveness:  Very Good | Potential User Resistance:   Medium | Upfront Cost:  Medium | Ongoing Maintenance Cost:  Low

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

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

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

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

Требования ИБ также должны учитывать:

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

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

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

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

ИСО/МЭК 27005 [11] и ИСО 31000 [27] предоставляют руководство по применению процессов управления рисками для идентификации мер обеспечения ИБ и выполнения требований.