Monitoring access to Operational Technology environments outside business hours

Stage 1: Ingest Windows security events indicating login activity 

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

To verify that you are receiving these events, run the following search. 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 search in stage 4 uses a lookup table named work_hours_by_asset. The lookup file should contain 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 search. 

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 means you can specify certain accounts or exclude certain accounts from this report. In the example below, the lookup file name exclude_users_from_reports is used. The lookup file should contain 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 search for activity 

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

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"