Monitoring access to Operational Technology environments

Stage 1: Ingest Windows security events for login activity 

In this stage, you need ensure that you are collecting Windows Security Events for specific event codes. Specifically you want to ensure you are receiving events for event codes 4624 (528 for legacy systems) for successful login attempts and event codes 4625 (529 for legacy systems) for failed login attempts. If you want to limit this only to remote login activity you can add Login_Type=10 to the query used in the query below. 

To verify that you are receiving events for this, run the following query. You can optimize this by specifying an index and adjusting the time range. 

source=WinEventLog:Security  
((EventCode=4624 OR EventCode=528) OR (EventCode=4625 OR EventCode=529))  
| eval action=CASE(EventCode=4624 OR EventCode=528, "Success", EventCode=4625 OR EventCode=529, "Failure") 

Stage 2: Identify regular working hours for each asset

A lookup file for regular working hours by asset will be needed to reflect normal working hours per location. The example queries below use a lookup table named works_hours_by_asset. The lookup contains the following columns: 

• dest: the asset name, or wildcard match for the asset name 
• day_start_hour: the local hour the work day starts 
• day_start_minute: the minute the work day starts 
• day_end_hour: the local hour the work day ends 
• day_end_minute: the minute the day ends 
• gm_offset: time offset from UTC time (for localization) 

As noted, the day start and end hours are in local time. So for instance if the normal working day is 8am to 5pm, you would use 8 as the day_start_hour and 5 as the day_end_hour. You then specify the offset from UTC so that any queries adjust for the time when performing the query. 

Asset names could also be used to accept a wildcard for matching. For instance, if you have a set of assets that all start with GCC_ and also are located in the same time zone, you can use GCC_* to set the normal working hours for those assets.

Stage 3: Identify accounts to be monitored

Next, we will create the lookup file that shows accounts that should be excluded or included for monitoring. This allows you to specify specific accounts or entirely exclude certain accounts from this report. In the example below, the lookup file name exclude_users_from_reports is used. The lookup file contains the following fields: 

• user: the user name, or wildcard match for the user name 
• is_excluded: TRUE to exclude the user from reports and FALSE to include them 

This lookup file can be modified to take an explicit include (allowlist) or exclude (denylist). For example, by default, all accounts could be included as a last entry in the lookup file for all users with a false exclusion. Changing this to TRUE excludes all users not explicitly listed above.

Stage 4: Verify the query for activity 

In this stage, we will verify the base query runs and returns results. To verify this, run the following query: 

source=WinEventLog:Security ((EventCode=4624 OR EventCode=528) OR (EventCode=4625 OR EventCode=529)) user="*" dest="*" 
| eval action=CASE(EventCode=4624 OR EventCode=528, "Success", EventCode=4625 OR EventCode=529, "Failure") 
| lookup work_hours_by_asset dest OUTPUTNEW gm_offset,day_start_hour,day_end_hour 
| lookup exclude_users_from_reports user OUTPUTNEW is_excluded 
| eval timeInTimeZone=_time - (gm_offset * 60 * 60) 
| eval hourInTimeZone=strftime(timeInTimeZone,"%H") 
| where (hourInTimeZone < day_start_hour OR hourInTimeZone >= day_end_hour) AND is_excluded="FALSE"