How to set event log security locally or by using Group Policy

You can customize security access rights to their event logs in Windows Server 2012. These settings can be configured locally or through Group Policy. This article describes how to use both of these methods.

Original product version: В Windows Server 2012 Standard, Windows Server 2012 Datacenter
Original KB number: В 323076

Summary

You can grant users one or more of the following access rights to event logs:

You can configure the security log in the same way. However, you can change only Read and Clear access permissions. Write access to the security log is reserved only for the Windows Local Security Authority (LSA).

You can use an Administrative Template Policy for the purpose. The path for the System Eventlog, for example, is:

Computer Configuration\Administrative Templates\Windows Components\Event log Service\System

The setting is configure log access and it takes the same Security Descriptor Definition Language (SDDL) string.

Microsoft suggests moving to this method once you are on Windows Server 2012.

Configure event log security locally

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

The security of each log is configured locally through the values in the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog .

For example, the Application log Security Descriptor is configured through the following registry value: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD

And the System log Security Descriptor is configured through HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD .

The Security Descriptor for each log is specified by using SDDL syntax. For more information about SDDL syntax, see the Platform SDK, or see the article mentioned in the References section of this article.

To construct an SDDL string, note that there are three distinct rights that pertain to event logs: Read, Write, and Clear. These rights correspond to the following bits in the access rights field of the ACE string:

The following is a sample SDDL that shows the default SDDL string for the Application log. The access rights (in hexadecimal) are bold-faced for illustration:

O:BAG:SYD:(D;; 0xf0007 ;;;AN)(D;; 0xf0007 ;;;BG)(A;; 0xf0007 ;;;SY)(A;; 0x5 ;;;BA)(A;; 0x7 ;;;SO)(A;; 0x3 ;;;IU)(A;; 0x2 ;;;BA)(A;; 0x2 ;;;LS)(A;; 0x2 ;;;NS)

For example, the first ACE denies Anonymous Users read, write, and clear access to the log. The sixth ACE permits Interactive Users to read and write to the log.

Modify your local policy to permit customization of the security of your event logs

Back up the %WinDir%\Inf\Sceregvl.inf file to a known location.

Open %WinDir%\Inf\Sceregvl.inf in Notepad.

Scroll to the middle of file, and then put the pointer immediately before [Strings].

Insert the following lines:

Scroll to the end of the file, and then insert the following lines:

AppLogSD=»Event log: Specify the security of the application log in Security Descriptor Definition Language (SDDL) syntax»
SysLogSD=»Event log: Specify the security of the System log in Security Descriptor Definition Language (SDDL) syntax»

Save and then close the file.

Select Start, select Run, type regsvr32 scecli.dll in the Open box, and then press ENTER.

In the DllRegisterServer in scecli.dll succeeded dialog box, select OK.

Use the computer’s local group policy to set your application and system log security

1. Select Start, select Run, type gpedit.msc, and then select OK.
2. In the Group Policy editor, expand Windows Setting, expand Security Settings, expand Local Policies, and then expand Security Options.
3. Double-click Event log: Application log SDDL, type the SDDL string that you want for the log security, and then select OK.
4. Double-click Event log: System log SDDL, type the SDDL string that you want for the log security, and then select OK.

Use group policy to set your application and system log security for a domain, site, or organizational unit in Active Directory

To view the group policy settings that are described in this article in the Group Policy editor, first complete the following steps, and then continue to the Use group policy to set your application and system log security section:

Use a text editor such as Notepad to open the Sceregvl.inf in the %Windir%\Inf folder.

Add the following lines to the [Register Registry Values] section:

MACHINE\System\CurrentControlSet\Services\Eventlog\Application\CustomSD,1,%AppCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Security\CustomSD,1,%SecCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\System\CustomSD,1,%SysCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\Directory Service\CustomSD,1,%DSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\DNS Server\CustomSD,1,%DNSCustomSD%,2
MACHINE\System\CurrentControlSet\Services\Eventlog\File Replication Service\CustomSD,1,%FRSCustomSD%,2

Add the following lines to the [Strings] section:

AppCustomSD=»Eventlog: Security descriptor for Application event log»
SecCustomSD=»Eventlog: Security descriptor for Security event log»
SysCustomSD=»Eventlog: Security descriptor for System event log»
DSCustomSD=»Eventlog: Security descriptor for Directory Service event log»
DNSCustomSD=»Eventlog: Security descriptor for DNS Server event log»
FRSCustomSD=»Eventlog: Security descriptor for File Replication Service event log»

Save the changes you made to the Sceregvl.inf file, and then run the regsvr32 scecli.dll command.

Start Gpedit.msc, and then double-click the following branches to expand them:

Computer Configuration
Windows Settings
Security Settings
Local Policies
Security Options

View the right panel to find the new Eventlog settings.

Use group policy to set your application and system log security

In the Active Directory Sites and Services snap-in or the Active Directory Users and Computers snap-in, right-click the object for which you want to set the policy, and then select Properties.

Select the Group Policy tab.

If you must create a new policy, select New, and then define the policy’s name. Otherwise, go to step 5.

Select the policy that you want, and then select Edit.

The Local Group Policy MMC snap-in appears.

Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then select Security Options.

Double-click Event log: Application log SDDL, type the SDDL string that you want for the log security, and then select OK.

Double-click Event log: System log SDDL, type the SDDL string that you want for the log security, and then select OK.

References

For more information about SDDL syntax and about how to construct an SDDL string, see Security Descriptor String Format.

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

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

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

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

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

Account Management

• User Account Management;
• Security Group Management.

Policy Change

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

Обратите внимание, что после настройки инструмента сбора и анализа этих событий потребуется дополнительное время на отладку для снижения количества ложных срабатываний.

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.