Методы обнаружения угроз в Windows Server 2016 достаточно надёжны, но независимо от того, как вы пытаетесь защитить свою окружающую среду, вам все равно необходимо провести аудит и проверить, их эффективность.
Содержание:
Способы обнаружения угроз
Windows Server 2016 включает две новые, дающие вам более полное представление о событиях, подкатегории аудита:
- Audit Group Membership. Часть категории событий входа/выхода. События в этой подкатегории генерируются в момент определения или запроса на компьютере, где был создан сеанс сессии, членства в группе.
- Audit PNP Activity. Опирается на категорию подробного отслеживания (Detailed Tracking). Подкатегорию аудита активности PNP можно использовать для аудита обнаружения внешнего устройства plug-and-play. Аудит для этой категории, только успех.
В Windows Server 2016 были внесены важные изменения, предоставляющие дополнительную информацию, которая поможет вам быстро определить и устранить обнаруженные угрозы. В следующей таблице приведены дополнительные сведения:
| Область | Улучшения |
| Политика аудита ядра по умолчанию | В предыдущих версиях ядро, для извлечения сведений о некоторых из его событий, зависело от LSA. В сервере 2016, процесс создания события политики аудита включается автоматически, до фактического получения политики аудита от LSA. Это приводит к лучшему аудиту служб, которые могут стартовать до запуска LSA |
| По умолчанию процесс Security ACL (SACL) для LSASS.exe | Процесс по умолчанию, SACL был добавлен в LSASS.exe для регистрации процессов, пытающихся получить доступ к LSASS.exe. SACL является L"S:(AU;SAFA;0x0010;;;WD)". Вы можете изменить это в рамках Advanced Audit Policy Configuration|Object Access|Audit Kernel Object. |
| Новые поля в событие входа в систему | Идентификатор события входа 4624 был обновлён, чтобы включить более подробную информацию, облегчающую его анализ. К событию 4624 были добавлены следующие поля:
Если учётная запись, под которой вошли на ПК, является учётной записью компьютера, это поле будет да; в противном случае - нет.
Если учётная запись, под которой вошли в компьютер является административной, это поле будет да; в противном случае — нет. Кроме того, если это является частью сплит маркера, также будет показан связанный с логином идентификатор (LSAP_LOGON_SESSION).
Имя пользователя и идентификатор домена, который был создан для исходящего трафика с помощью метода LogonUser.
Если учётная запись, входа в компьютер виртуальная учётная запись, это поле будет да; в противном случае — нет.
Список всех групп в пользовательском маркере.
Если пользователь выполняет вход в компьютер в режиме ограниченного администрирования с удалённого рабочего стола, это поле будет - да. |
| Новые поля в процессе создания события | Идентификатор события входа 4688 был обновлён, чтобы включить более подробную облегчающую анализ информацию. К событию 4688 были добавлены следующие поля:
SID целевого принципала.
Имя учётной записи целевого пользователя.
Домен целевого пользователя.
Идентификатор входа целевого пользователя.
Имя процесса создателя.
Указывает на фактический родительский процесс, если он отличается от созданного. |
| События Security Account Manager (SAM) | Для защиты SAM API, выполняющих операции чтения/запроса, были добавлены новые SAM события. В предыдущих версиях Windows проверялись только операции записи. Новые события являются событиями ID 4798 и ID 4799. В настоящее время проверяются следующие API:
SamrEnumerateGroupsInDomain |
| События конфигурации загрузки базы данных/Boot Configuration Database (BCD) | Идентификатор события 4826 был добавлен для отслеживания следующих изменений в BCD:
Параметры DEP/NEX |
| События PNP | Идентификатор события 6416 был добавлен для отслеживания обнаружения внешнего устройства с помощью plug-and-play. Одним из важных сценариев является то, что, содержащее вредоносное ПО внешнее устройство вставляется в не ожидающую такого действия, например, контроллера домена, машину с высоким приоритетом. |
Обеспечение привилегированного доступа
В этой статье мы рассмотрим несколько, касающихся обеспечения привилегированного доступа, концепций. Начнём с концепции Just-in-Time и Just Enough Administration. Затем попробуем объяснить, как объединить все рассматриваемые ранее инструменты и технологии в осуществлении стратегии обнаружения угроз для вашей организации.
Just-in-Time и Just Enough Administration
Just-in-Time (JIT) Administration - это довольно простая концепция: главным является то, что мы эволюционируем в состояние, в котором нет штатных администраторов, или, более конкретно, нет учётных записей с полными правами администратора. С помощью простого процесса, требуемые привилегии запрашиваются непосредственно перед тем, как они действительно необходимы, затем утверждаются, а затем в течение определённого периода времени предоставляется учётная запись. Это гарантирует, что задача может быть успешно выполнена с правильным количеством привилегий в выделенное время. JIT, для обеспечения надлежащих привилегий, работает вместе с Just Enough Administration (JEA). В Windows Server 2016, эта технология объединяется с Privileged Access Management (PAM).
Подробнее. Дополнительные сведения о PAM, на https://technet.microsoft.com/library/dn903243.aspx.
Теперь давайте взглянем на JEA. JEA часть пакета Windows Management Framework 5.0 и поддерживается с Windows Server 2008 R2. Используя JEA, вы можете назначить для учётной записи пользователя определённые привилегии, которые необходимы для выполнения именно заданной функции. Это означает, что вам не нужно создавать учётную запись администратора и затем, позднее, не забыть этого человека удалить. JEA даёт контроль доступа на основе ролей (RBAC), который современные предприятия требуют для обеспечения более безопасной среды.
Чтобы реализовать JEA в системе, нужен файл Windows PowerShell Session Configuration. Для того, чтобы создать необходимый для управления доступом .pssc файл, используйте, запустив следующий синтаксис, командлет New-PSSessionConfigurationFile:
New-PSSessionConfigurationFile -Path "$env:Programdata\<JEAConfigDirectory>\<filename>.pssc"
Ниже приведён создаваемый этой командой пример файла конфигурации по умолчанию:
@{
# Version number of the schema used "for this document
SchemaVersion = '2.0.0.0'
# ID used to uniquely identify this document
GUID = '1da190ce-fc94-4f8b-98e0-7d70fd9154b1'
# Author of this document
Author = 'john'
# Description of the functionality provided by these settings
# Description = ''
# Session type defaults to apply for this session configuration. Can be 'RestrictedRemoteServer'
(recommended), 'Empty', or 'Default'
SessionType = 'Default'
# Directory to place session transcripts for this session configuration
# TranscriptDirectory = 'C:\Transcripts\'
# Whether to run this session configuration as the machine's (virtual) administrator account
# RunAsVirtualAccount = $true
# Groups associated with machine's (virtual) administrator account
# RunAsVirtualAccountGroups = 'Remote Desktop Users', 'Remote Management Users'
# Scripts to run when applied to a session
# ScriptsToProcess = 'C:\ConfigData\InitScript1.ps1', 'C:\ConfigData\InitScript2.ps1'
# User roles (security groups), and the role capabilities that should be applied to them when applied to a session
# RoleDefinitions = @{ 'CONTOSO\SqlAdmins' = @{ RoleCapabilities = 'SqlAdministration' }; 'CONTOSO\ServerMonitors' = @{ VisibleCmdlets = 'Get-Process' } }
}
Основной, представляющей интерес для изменения, областью являются SessionType, для которого установлено значение «По умолчанию». Чтобы JEA работал, вам необходимо сконфигурировать это как RestrictedRemoteServer. Далее, вам нужно раскомментировать # RunAsVirtualAccount = $True, который гарантирует, что сессия будет иметь «виртуальные» привилегии администратора. И наконец необходимо изменить раздел Roledefintions и раскомментировать его с учётом вашей среды.
После создания и настройки файла конфигурации, необходимо зарегистрировать его с помощью командлета Register-PSSessionConfiguration.
Register-PSSessionConfiguration -Name <Name> -Path "$env:Programdata\<JEAConfigDirectory>\<filename>.pssc"
Вы можете проверить это, подключившись к машине, как в обычном удалённом сеансе Windows PowerShell.
Enter-PSSession -ComputerName <ComputerName> -ConfigurationName <JEAConfigName> -Credential $cred
Вы можете создать другой файл с именем Role Capability с расширением .psrc. Вы можете использовать этот файл для определения, какие команды и приложения видны для созданных вами ролей. Для создания пустого шаблона используется командлет New-PSRoleCapabilityFile.
Этот файл содержит разделы, в которых вы можете определить импортируемые модули, открытые функции и командлеты.
# ModulesToImport = 'MyCustomModule',
@{ ModuleName = 'MyCustomModule2'; ModuleVersion = '1.0.0.0';
GUID = '4d30d5f0-cb16-4898-812d-f20a6c596bdf'
}
# VisibleFunctions = 'Invoke-Function1',
@{ Name = 'Invoke-Function2';
Parameters = @{ Name = 'Parameter1';
ValidateSet = 'Item1', 'Item2' },
@{ Name = 'Parameter2'; ValidatePattern = 'L*' } }
# VisibleCmdlets = 'Invoke-Cmdlet1',
@{ Name = 'Invoke-Cmdlet2'; Parameters = @{ Name = 'Parameter1'; ValidateSet = 'Item1', 'Item2' },
@{ Name = 'Parameter2'; ValidatePattern = 'L*' } }
Подробнее. JEA - сложный предмет, здесь только основы. Для изучения дальнейшего руководства и просмотра всех параметров конфигурации перейдите на http://aka.ms/JEA.