Configuring Windows Event Controller & Cybersecurity on a Budget

1 Jan

In our last blog we covered creating more visibility in an environment by utilisation of Power Shell logging and forwarding to a centralised repository. This blog will be covering the use of built-in tools to configure that centralised repository with Windows Event Forwarder and some discussion at the end about tech-debt.

With so many organisations now pursuing stronger security, it is a market awash with commercial products, so we will be focusing on utilising tools that either come free or are already part of your Windows Server environment.

Windows Event Forwarding (WEF) is a built-in Windows Server feature that centralises event logs from workstations and servers onto a Windows Event Collector (WEC). It can partly fill the role of a SIEM in a Windows environment, and since it is built-in, only requires your existing infrastructure and a server to host the WEC. It’s an established piece of infrastructure that is supported by Microsoft and can provide a lot of functionality when set up correctly.

Below are instructions on how to configure a basic WEC server in a push design and configure the necessary GPOs for both WEC and WEF clients. We are setting this up as a push design (client machines push logs to a centralised server, as opposed to a centralised server pulling) as it’s a simple design for scalability, though always consider the best implementation for your environment. This does not assume you have read the previous blog and will show you how to configure for your source workstations and servers as well.

Step 1: Prerequisites

Requirements

Active Directory domain

One server to act as Event Collector with WinRM enabled.

Domain-joined source computers

Network access on:

TCP 5985 (HTTP WinRM)

TCP 5986 (HTTPS – optional but recommended)

Step 2: Configure the Event Collector Service

Run ‘wecutil qc’ in an elevated PowerShell prompt on your collector server. This will:

Set Windows Event Collector service to Automatic

Start the service

Configure firewall rules

Step 3: Configure Group Policy for Source Computers

Create a New GPO Link it to the OU containing source computers, with the following configuration:

Allow WinRM

Computer Configuration

└─ Policies

└─ Administrative Templates

└─ Windows Components

└─ Windows Remote Management (WinRM)

└─ WinRM Service

Set:

Allow remote server management through WinRM

Enabled

IPv4 filter: *

IPv6 filter: *

It is highly recommended that you set your filters to be restricted to the IP address of your WEC server, or if already using WinRM for other services, that it is included within your allowlist.

Configure WEC Target

Computer Configuration

└─ Policies

└─ Administrative Templates

└─ Windows Components

└─ Event Forwarding

Enable:

Configure target Subscription Manager

Value:

Server=http://COLLECTOR-SERVER:5985/wsman/SubscriptionManager/WEC,Refresh=60

Replace COLLECTOR-SERVER with the hostname of your collector and port with your use of protocol (5985 for HTTP, 5986 for HTTPS).

Step 4: Create an Event Subscription on the Collector

Now on our WEC, navigate to Event Viewer and right-click Subscriptions then Create Subscription.

If a dialogue opens saying it needs the Windows Event Collector service running then it was not configured correctly earlier. Hit yes, though double-check that the service is starting correctly on reboots.

Subscription Settings

Destination Log: Forwarded Events

Subscription type: Source computer initiated

Select Computer Groups: (Group containing computers for log collection)

Configure Events to Collect

Here we will need to filter which logs to collect. This is the most important part, as if we want to improve visibility over the environment, we will need to ensure we are collecting the correct logs; collect too few and we can’t see what is happening in the environment, collect too many and the important information gets lost.

Microsoft provides a baseline query list here, though please take careful consideration for what logs require visibility in your environment.

Click Select Events

Under the XML tab you can manually input a query list, below is an example of Security log – logon activity

*[System[(EventID=4624 or EventID=4625)]]

</Select>

</Query>

</QueryList>

Input your query list and be sure to test it is collecting those logs once you save the subscription.

Advanced Settings

Click Advanced.

Here you can configure for HTTP or HTTPS as the transport protocol – HTTPS is ideal if possible. Delivery optimisation is not entirely necessary, although utilise as required if the bandwidth or latency becomes a problem.

Save the subscription.

At this stage, you can begin testing to see if logs are being collected correctly. If so, then congrats! Your WEF implementation is complete. Be sure to monitor the logs and adjust which logs get forwarded as new additions are made to your environment.

Cybersecurity on a Budget

At the moment, the rapidly changing and expanding field of cybersecurity is particularly daunting to engage with. Organisations are now more concerned about security in their environments more than ever, while it simultaneously is becoming a rapidly shifting field. Organisations need to implement new systems, new policies, and adopt new concepts; with limited timeframes, organisations are needing to hit a lot of moving targets.

Plenty of applications and services are on offer for organisations to purchase, however for the small business and not for profit sectors it is not always feasible to spend large amount of money and commit resources, especially when it is unclear exactly what you are spending for. Further to that, even larger organisations, can hit the pitfall of accruing too much technical debt by offloading labour in exchange for a quick purchase. Buying a SIEM and then inadequately filtering logs or even failing to maintain the procedure to monitor it, is of no value to the organisation and only serves to provide a false sense of security. Implementation of in-built systems in a steady, controlled manner, is an affordable and robust solution that is available to almost all organisations.

There are few shortcuts to implementing a well-thought out and deliberate system, so I would encourage any organisation to carefully consider their resources and implement something that does the job, is affordable, and is going to be maintained. In future blogs, we will cover more examples of in-built, open-source, and affordable systems for organisations to consider when improving the security of their environment.

GlassHouse Technologies