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

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации

ГОСТ Р № 57580.1-2017 от 01.01.2018

РЗИ.5

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

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

Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 6.5.1
6.5.1
Defined Approach Requirements: 
Changes to all system components in the production environment are made according to established procedures that include: 
  • Reason for, and description of, the change.
  • Documentation of security impact.
  • Documented change approval by authorized parties. 
  • Testing to verify that the change does not adversely impact system security. 
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. 
  • Procedures to address failures and return to a secure state. 
Customized Approach Objective:
All changes are tracked, authorized, and evaluated for impact and security, and changes are managed to avoid unintended effects to the security of system components. 

Defined Approach Testing Procedures:
  • 6.5.1.a Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement. 
  • 6.5.1.b Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement. 
Purpose:
Change management procedures must be applied to all changes—including the addition, removal, or modification of any system component—in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. 

Good Practice:
Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. 
Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.
For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.5.1
6.5.1
Определенные Требования к Подходу:
Изменения во всех компонентах системы в производственной среде вносятся в соответствии с установленными процедурами, которые включают:
  • Причина и описание изменения. 
  • Документирование воздействия на безопасность.
  • Документально подтвержденное одобрение изменений уполномоченными сторонами.
  • Тестирование, чтобы убедиться, что изменение не оказывает негативного влияния на безопасность системы.
  • При внесении изменений в программное обеспечение по индивидуальному заказу все обновления проверяются на соответствие требованиям 6.2.4 перед внедрением в производство.
  • Процедуры устранения сбоев и возврата в безопасное состояние.
Цель Индивидуального подхода:
Все изменения отслеживаются, санкционируются и оцениваются на предмет воздействия и безопасности, а также управляются изменениями, чтобы избежать непреднамеренных последствий для безопасности компонентов системы.

Определенные Процедуры Тестирования Подхода:
  • 6.5.1.a Изучите документированные процедуры контроля изменений, чтобы убедиться, что процедуры определены для изменений всех компонентов системы в производственной среде, чтобы включить все элементы, указанные в этом требовании.
  • 6.5.1.b Изучите последние изменения в компонентах системы и проследите эти изменения до соответствующей документации по управлению изменениями. Для каждого проверенного изменения убедитесь, что изменение реализовано в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Процедуры управления изменениями должны применяться ко всем изменениям — включая добавление, удаление или модификацию любого компонента системы — в производственной среде. Важно задокументировать причину изменения и описание изменения, чтобы соответствующие стороны поняли и согласились с необходимостью изменения. Аналогичным образом, документирование последствий изменений позволяет всем затронутым сторонам надлежащим образом планировать любые изменения в обработке.

Надлежащая практика:
Одобрение уполномоченными сторонами подтверждает, что изменение является законным и что изменение санкционировано организацией. Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы понять влияние изменений.
Тщательное тестирование организацией подтверждает, что безопасность среды не снижается при внедрении изменений и что все существующие средства контроля безопасности либо остаются на месте, либо заменяются равными или более сильными средствами контроля безопасности после изменения. Конкретное тестирование, которое необходимо выполнить, будет варьироваться в зависимости от типа изменения и затронутого(ых) компонента(ов) системы.
Для каждого изменения важно иметь документированные процедуры, которые устраняют любые сбои и предоставляют инструкции о том, как вернуться в безопасное состояние в случае сбоя изменения или отрицательного влияния на безопасность приложения или системы. Эти процедуры позволят восстановить приложение или систему в прежнее безопасное состояние.
SWIFT Customer Security Controls Framework v2022:
2 - 2.3 System Hardening
2.3 System Hardening
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.0 УКФ.0 Разработка политики управления конфигурацией информационной (автоматизированной) системы
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.0 УКФ.0 Регламентация правил и процедур управления конфигурацией информационной (автоматизированной) системы

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

3
Название Дата Влияние
Community
18 10 / 86
Настройка безопасной конфигурации для серверов ОС Linux
Разово Вручную Техническая Превентивная
16.05.2022
16.05.2022 18 10 / 86
Цель: сокращение поверхности атаки.
Часть общего процесса управления безопасностью конфигураций (Hardening).

Общий алгоритм:
  1. Определить, задокументировать требования к безопасности конфигурации.
  2. Применить безопасную конфигурацию на существующих хостах.
  3. Применять безопасную конфигурацию на новых хостах в рамках процесса их ввода в эксплуатацию.
  4. Регулярно проверять конфигурацию хостов на соответствие установленным требованиям.
Источником для формирования требований к безопасности конфигурации служат:
Документирование требований осуществляется в зависимости от принятых подходов в организации.
Вариант реализации: описать требования в карточке защитной меры. Пример документа

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

Минимальные требования к безопасной конфигурации:
  • Изменить пароли по умолчанию.
  • Настроить SSH 
  • Настроить сложность паролей
  • Настроить смену (жизненный цикл) паролей 
  • Настроить политику аутентификации
  • Отключить или удалить ненужные учетные записи пользователей
  • Отключить или ограничить ненужные службы, порты и протоколы
  • Удалить ненужное программное обеспечение
  • При необходимости ограничить физические порты
  • Настроить баннеры при входе
В зависимости от выстроенной в компании инфраструктуры к требованиям безопасности конфигурации могут быть отнесены:
  • Подключение хоста к корпоративной системе мониторинга
  • Настройка передачи логов на централизованный сервер (nxlog, SEM / SIEM) 
  • Конфигурация NTP и часового пояса
Настройка может осуществляться вручную, скриптами или с использованием централизованных систем управления конфигурацией (например, Ansible).

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

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

Рекомендации к заполнению карточки:
  • Каждый из этапов процесса (определение требований, первичная настройка, ввод в эксплуатацию новых хостов, контроль соответствия) может быть описан отдельной защитной мерой.
  • Описать принятый в компании перечень требований к безопасности конфигурации.
  • Если для приведения в соответствие и/или контроля конфигураций используется ПО - зарегистрировать его в реестре активов и привязать к мере как инструмент
  • Если ведется учет (реестр) скриптов - привязать использующиеся скрипты как инструмент 
  • Добавить шаблон регулярной задачи по проверке конфигураций.
  • Добавить шаблон регулярной задачи на пересмотр/актуализацию набора требований безопасности
Community
2 17 / 100
Настройка контроля учетных записей (UAC) в ОС Windows
Постоянно Автоматически Техническая Превентивная
24.02.2022
24.02.2022 2 17 / 100
Цель: полноценная настройка контроля учетных записей (User Access Control, UAC) для защиты от несанкционированного повышения привилегий пользователем (злоумышленником).
Реализуется через настройку групповой политики домена, на уровне серверов и рабочих станций.
Возможна реализация через наложенные средства защиты от НСД, типа Secret Net и Dallas Lock.

1. Повышение прав только для подписанных и проверенных исполняемых файлов
Следует отключить проверку цепочки сертификатов PKI до разрешения запуска заданного исполняемого файла.
ОС Windows обеспечивает проверку подписи для инфраструктуры общедоступных ключей (PKI) для любого интерактивного приложения, которое запрашивает повышение привилегий. Вы можете управлять приложениями, которые разрешены для работы с населением сертификатов в хранилище доверенных издателей локального компьютера.
Доверенный издатель — это эмитент сертификатов, которому пользователь компьютера доверяет, и у него есть сведения о сертификате, добавленные в хранилище доверенных издателей.
Пользователи и администраторы по своей сути доверяют приложениям, используемым с этими источниками информации, и предоставляют свои учетные данные. Если одно из этих приложений будет заменено приложением-изгоем, которое кажется идентичным надежному приложению, конфиденциальные данные могут быть скомпрометированы, а административные учетные данные пользователя также будут скомпрометированы.

Настройка с помощью групповой политики: 
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
Параметр: Контроль учетных записей: Повышение прав только для подписанных и проверенных исполняемых файлов.
Значение: Отключен

2. Повышать права для UIAccess-приложений только при установке в безопасных местах
Microsoft UI Automation — это текущая модель для поддержки требований к доступности в Windows операционных системах.
Приложения, запрашивающие работу с уровнем целостности UIAccess, помеченные UIAccess=true в манифесте приложения, должны находиться в безопасном расположении в файловой системе.
Относительно безопасные расположения ограничены следующими каталогами:
  • \Program Files\ включая подтеки
  • \Windows\system32\
  • \Program Files (x86)\ включая подтеки для 64-битных версий Windows
Примечание. Windows принудительно проводит обязательную проверку подписей PKI для любого интерактивного приложения, запрашивающего выполнение на уровне целостности UIAccess, вне зависимости от состояния данного параметра безопасности.

Настройка с помощью групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
 Параметр: Контроль учетных записей: Повышать права для UIAccess-приложений только при установке в безопасных местах.
 Значение: Включен

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

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

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

Настройка с помощью групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
Параметр: Контроль учетных записей: Поведение запроса на повышение прав для администраторов в режиме одобрения администратором.
Значение: Запрос учетных данных

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

Настройка с помощью групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
Параметр: Контроль учетных записей: Поведение запроса на повышение прав для обычных пользователей.
Значение: Автоматически отклонять запросы на повышение прав

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

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

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

Настройка с помощью групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
Параметр: Контроль учетных записей: Переключение к безопасному рабочему столу при выполнении запроса на повышение прав.
Значение: Включен

8. Виртуализация сбоев записи в файл или реестр на основании расположений пользователя
Следует управлять перенаправлением сбоев записи приложений в определенные расположения в реестре и файловой системе. Эта мера позволяет уменьшить опасность приложений, которые выполняются от имени администратора и во время выполнения записывают данные в папку %ProgramFiles%, %Windir%, %Windir%\system32 или HKEY_LOCAL_MACHINE\Software\
Сбои записи приложений должны перенаправляться во время выполнения в определенные пользователем расположения в файловой системе и реестре.

Настройка с помощью групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
Параметр: Контроль учетных записей: При сбоях записи в файл или реестр виртуализация в место размещения пользователя.
Значение: Включен

9. Запретить UIAccess-приложениям запрашивать повышение прав, не используя безопасный рабочий стол
Необходимо контролировать, могут ли программы доступности пользовательского интерфейса (UIAccess или UIA) автоматически отключать безопасный рабочий стол для повышения прав, у стандартных пользователей. По умолчанию в ОС Windows отключено данное поведение. Защищенный рабочий стол может быть отключен только пользователем интерактивного рабочего стола или путем отключения параметра политики 'Контроль учетных записей: переключение к безопасному рабочему столу при выполнении запроса на повышение прав'.

Настройка с помощью групповой политики:
Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности.
Параметр: Контроль учетных записей: Разрешить UIAccess-приложениям запрашивать повышение прав, не используя безопасный рабочий стол.
Значение: Отключен

Рекомендации к заполнению карточки:
Community
2 21 / 118
Ограничение запуска неизвестного ПО с помощью Windows SmartScreen
Постоянно Автоматически Техническая Превентивная
16.02.2022
16.02.2022 2 21 / 118
Цель: запрет выполнения неизвестного ПО на ПК и серверах под управлением ОС Windows. 
Windows SmartScreen повышает безопасность ПК, предупреждая пользователей перед запуском неопознанных программ, загруженных из Интернета. При этом в Майкрософт отправляются сведения о файлах и программах, выполняемых на ПК с включенной функцией SmartScreen.
Если этот параметр политики включен, поведением Windows SmartScreen можно управлять путем установки одного из следующих параметров:
  • Требовать подтверждения администратора, прежде чем запускать загруженное неизвестное ПО
  • Предупреждать пользователя, прежде чем выполнять загруженное неизвестное ПО
  • Выключить SmartScreen
Настройка с помощью групповой политики: 
Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Проводник.
Параметр: Настроить Windows SmartScreen.
Значение: Включено, требовать подтверждения администратора, прежде чем запускать загруженное неизвестное ПО

Подробнее: Фильтр SmartScreen в Microsoft Defender

Рекомендации к заполнению карточки:
Community
1 9 / 53
Резервное копирование и архивирование конфигураций сетевого оборудования
Еженедельно Автоматически Восстановительная
26.07.2021
26.07.2021 1 9 / 53
Цель: сохранение возможности быстрого восстановления конфигурации сетевого оборудования (при сбросе, сбое или замене оборудования).

С заданной периодичностью со всего сетевого оборудования (коммутаторов и маршрутизаторов) собирается текущая конфигурация.
Пример реализации для оборудования Cisco - в заметке.
Собираются:
  1. Конфигурация (show running-config view full)
  2. Таблицы соединений с другим коммутационным оборудованием (show cdp neighbors detail)
  3. Таблицы розданных IP по DHCP (show ip dhcp binding)
  4. Таблицы подключенных MAC адресов (show mac address-table)
Глубина хранения архивных версий: N лет.
Место хранения резервных копий: XXX.
Примечание: доступ к месту хранения скрипта и резервных копий должен быть ограничен.

Проверка работоспособности защитной меры:
  1. Проверить, что список проверяемых коммутаторов соответствует актуальному
  2. Проверить, что подключения проходят успешно (смотреть логи отработки скрипта);
  3. Проверить, что конфигурации собираются успешно (проверить каталог с результатами).
Рекомендации к заполнению карточки:
  • Описать методологию выполнения, хранения и проверки резервных копий конфигураций;
  • Добавить шаблон регулярной задачи на выполнение и проверку резервных копий конфигураций;
  • Если ведется реестр скриптов - привязать соответствующий скрипт к карточке как инструмент.
Community
1 3 / 34
Блокировка возможности удаленного подключения к ПК через RDP Shadow
Разово Автоматически Техническая Превентивная
22.06.2021
22.06.2021 1 3 / 34
Цель: защита от бокового перемещения злоумышленника с использованием функционала RDP Shadow.

Протокол RDP позволяет осуществлять удаленное подключение к сессии пользователя. По умолчанию в ОС Windows возможность включена с запросом на подтверждение от пользователя. В случае корректировки параметра на уровне ПК возможно последующее незаметное подключение к сессии пользователя. Необходимо принудительно отключить данную возможность.

Настройка с помощью групповой политики:
Конфигурация компьютера / Административные шаблоны /Компоненты Windows / Службы удаленных рабочих столов / Узел сеансов удаленных рабочих столов / Подключения
Параметр Устанавливает правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов
Значение Включено с опцией Удаленное управление не разрешено.

Рекомендации к заполнению карточки:
Community
2 2 / 24
Включение подписи SMB пакетов
Разово Вручную Техническая Превентивная
15.06.2021
15.06.2021 2 2 / 24
Цель: уменьшение поверхности для сетевых атак.

Подписание SMB (server message block signing, SMB signing) это механизм безопасности в протоколе SMB, который также известен как подписи безопасности. Подписание SMB предназначено для повышения безопасности протокола SMB.
По умолчанию в современных ОС Windows подписание пакетов включено. Но с целью повышения скорости работы сети или для обеспечения совместимости с устаревшим ПО подписание SMB может быть отключено.
Необходимо принудительно через GPO включить подписание SMB пакетов на всех ПК и серверов. Так же необходимо включить подписание как входящих так и исходящих пакетов.
Внимание: подписание SMB требует значительных системных ресурсов и может оказать негативное влияние на работоспособность инфраструктуры.
Подробнее

Настройка с помощью групповой политики:
Конфигурация компьютера \ Политики \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \ Параметры безопасности
Параметр:    Сетевой сервер Майкрософт: использовать цифровую подпись (всегда) 
Значение:  Включено
Параметр:    Сетевой клиент Майкрософт: использовать цифровую подпись (всегда)
Значение:  Включено

Рекомендации к заполнению карточки:
Community
2 2 / 24
Перевод доменной аутентификации на Kerberos (отключение NTLM)
Разово Вручную Техническая Превентивная
15.06.2021
15.06.2021 2 2 / 24
Цель: уменьшение поверхности атаки.

Протоколы аутентификации NTLM v1 и NTLMv2 уязвимы к ряду атак.
Необходимо отключить протоколы NTLM в доменной инфраструктуре перейдя на аутентификацию через протокол Kerberos.
Частичной реализацией меры может являться отключение только протокола NTLMv1.
Управление используемыми протоколами реализация через GPO. Групповые политики позволяют так же гибко осуществить переход с NTLM на Kerberos используя инструменты аудита и белых списков, разрешая протокол NTLM только для части серверов и клиентов.
Подробнее о процессе отключения NTLM

Рекомендации к заполнению карточки:
Community
1 1 / 19
Отключение протокола NBT-NS на ПК и серверах Windows
Разово Автоматически Техническая Превентивная
15.06.2021
15.06.2021 1 1 / 19
Цель: уменьшение поверхности для сетевых атак.

Протокол NetBIOS over TCP/IP или NBT-NS (UDP/137,138; TCP/139)  является широковещательным протоколом-предшественником LLMNR.
Поддержка NetBIOS over TCP/IP по умолчанию включена для всех интерфейсов во всех ОС Windows и нужна чтобы компьютеры в локальной сети могли найти друг друга в случае недоступности DNS сервера.
Протокол уязвим к атакам NBNS-спуфинга, позволяющим получить хеши паролей пользователей.
Для исключения возможности атаки протокол необходимо отключать.
Отключение осуществляется через запуск скрипта на всех ПК и серверах инфраструктуры.

Реализация на PowerShell:
//PowerShell
$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

Реализация на BAT/CMD:
//CMD
@echo off
:checkpermissions
net.exe session >nul 2>&1 || (echo Ошибка! Запустите скрипт от имени администратора. & exit /b 1)
set "hive=HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces"
set "regv=NetbiosOptions"
setlocal EnableDelayedExpansion
set "iface=" & set "nbopt="
for /f "tokens=*" %%a in ('reg.exe query "%hive%" /s /v "%regv%" 2^>nul') do (
	set "regd=%%~a"
	if not "!regd!" == "!regd:%hive%=!" (set "iface=!regd!") else if not "!regd!" == "!regd:%regv%=!" (set "nbopt=!regd!")
	if defined iface if defined nbopt (
		for /f "tokens=3" %%b in ("!nbopt!") do if not "%%~b" == "0x2" (
			echo ^> !iface!\%regv% = 2
			reg.exe add "!iface!" /v "%regv%" /t REG_DWORD /d 2 /f
		)
		set "iface=" & set "nbopt="
	)
)
endlocal

Реализация на VBScript:
//VBS 
cscript.exe /nologo "%vbs%" > "%tmplog%" 2>&1
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colNetCards = objWMIService.ExecQuery _
	("Select * From Win32_NetworkAdapterConfiguration Where IPEnabled = True And TcpipNetbiosOptions != 2")

For Each objNetCard in colNetCards
	objNetCard.SetTCPIPNetBIOS(2)
	WScript.Echo objNetCard.Caption & " -- Ok"
Next

Рекомендации к заполнению карточки:
  • Описать выбранный способ реализации меры
  • Если ведется реестр групповых политик (GPO) - привязать соответствующую политику к карточке как инструмент 
Community
1 1 / 19
Отключение протокола LLMNR на ПК и серверах Windows
Разово Автоматически Техническая Превентивная
15.06.2021
15.06.2021 1 1 / 19
Цель: уменьшение поверхности для сетевых атак 

Протокол LLMNR (Link-Local Multicast Name Resolution) (UDP/5355) это механизм многоадресного разрешения локальных имен.
Протокол присутствует во всех версиях Windows, начиная с Vista и позволяет IPv6 и IPv4 клиентам за счет широковещательных запросов в локальном сегменте сети L2 разрешать имена соседних компьютеров без использования DNS сервера. Этот протокол также автоматически используется при недоступности DNS.
Протокол уязвим к атаке LLMNR/NBNS-спуфинга через которую возможна компрометация хешей паролей пользователей.
Для исключения возможности атаки протокол необходимо отключить и на уровне рабочих станций и на уровне серверов.

Настройка с помощью групповой политики:
Computer Configuration\Administrative Templates\Network\DNS Client 
Параметр: Turn Off Multicast Name Resolution 
Значение: Enabled
Конфигурация компьютера\Политики\Административные шаблоны\Сеть\DNS-клиент
Параметр: Отключить  многоадресное разрешение имен 
Значение: Включено

Статья на тему

Рекомендации к заполнению карточки:
Community
2 1 / 19
Контроль целостности файла hosts
Ежедневно Автоматически Техническая Детективная
20.05.2021
20.05.2021 2 1 / 19
Цель: предотвращение подделки злоумышленником доменных имен.

hosts - файл в OС, содержащий базу данных доменных имен и используемый при их трансляции в сетевые адреса узлов. Запрос к этому файлу имеет приоритет перед обращением к DNS-серверам. Подробнее о файле hosts
Расположение для ОС Windows: %WinDir%\System32\Drivers\Etc
Возможно несанкционированное изменение содержимого файла, что может привести к подделке IP адресов для локальных и публичных узлов (фарминг).
Необходимо контролировать целостность файлов hosts в инфраструктуре. Для этого осуществлять их регулярный аудит на всех ПК/Серверах и автоматически уведомлять подразделение по информационной безопасности об изменениях в файлах hosts.
Возможны следующие варианты реализации защитной меры:
  1. С использованием сканера уязвимостей
  2. С использованием ПО для контроля целостности
  3. Скриптом (пример реализации в комментариях)
    В заметке приведен пример скрипта для контроля файлов hosts
Инструкция
При поступлении уведомления об изменениях в файле hosts необходимо:
  1. Проанализировать изменения
  2. Если изменения носят вредоносный характер:
    1. Провести антивирусную проверку хоста
    2. Выявить источник изменений
    3. Удалить изменения или заменить файл hosts на типовой
  3. Если изменения сделаны для обеспечения рабочего процесса - добавить изменение в исключения чтобы убрать ложные сработки в будущем.
Рекомендации к заполнению карточки:
  • Создать шаблон регулярной задачи по контролю изменений файла hosts;
  • Создать эталонный файл и прикрепить его в заметке к защитной мере.