Configuring Standard Sensor Profiles

Whether you add or edit a standard sensor profile you have the same options, except you cannot edit the profile name. Standard sensor profiles can only be applied to standard sensors. To add a standard sensor profile:

1. Click System | Sensor Profiles. The Sensor Profile Configuration page appears, with the Sensor Profile tab displayed by default.

   

2. Click Create and select Add Standard Sensor Profile. The ADD SENSOR PROFILE screen appears.

   

3. Enter the Profile Name. We recommend that you establish a naming convention, so you can understand the intent of each profile by looking at the name. This field can only contain alphanumeric characters, underscores, spaces, and dashes.

4. Choose at least one Receiver. Each sensor profile must have at least one receiver, which is the destination of the data it collects. You can add one receiver of each type: packet and JSON.

   See the Receiver configuration page for more information on creating and maintaining receivers.

5. Use the Set to template button to apply an available template to some of your profile settings. Currently, templates are available for settings in the Windows tab. Separate templates let you apply Low, Medium, and High volume settings for Windows server sensors, depending on your deployment needs. Refer to Windows Customizations for details on the available settings.

6. Customize your profile settings. The available settings are explained below.

7. Click Submit. The profile is immediately active.

Customizing Standard Sensor Profile Features

The available customizations are grouped into tabs under Feature Customization, providing control over:

• Network – Network traffic analysis settings for device sensors and Linux Server Sensors

• Sensor – Malware, IDS, log forwarder, and buffering settings

• Agent – Settings for Linux Server Sensors

• Windows – Settings specific to Windows Server Sensors

To enable or disable an option or group of options within the tab, click on the toggle for that option. To open a group of options to fine-tune your customization, click on the name of the group (or anywhere else away from the toggle).

Network Customizations

These settings apply to network sensors and Linux Server sensors.

Network Traffic

You can toggle the analysis of Network Traffic on and off as a whole in the Network tab:

With Network Traffic disabled, the sensor operates as a Log Forwarder. None of the other features in the Network tab are available for selection or configuration. In addition:

• Malware Sandbox is disabled in the Sensor tab.

• IDPS is disabled in the Sensor tab.

You can see the differences in the system processes running on a sensor before and after disabling Network Traffic in a sensor's Sensor Details page, as shown in the illustration below:

You can see similar information with the show system command in the sensor CLI. For example, the show system processes at left are for a sensor with all main sensor features enabled (Network Traffic, Malware Sandbox, IDPS, and Log Forwarder). By contrast, the show system output at right shows a sensor after Network Traffic has been toggled off:

When you disable Network Traffic, Stellar Cyber ask you to confirm your decision and provides you with the option of saving or clearing buffered data for affected sensors.

Application Identification

Enable this option for the sensor to identify applications associated with events.

Application Session

Enable this for the sensor to identify the length of individual network sessions. The parameters specify how often to report the session information, and what length of time to apply when determining that a session has ended.

If you disable Application Session, network and agent sensors stop sending data to the DP, but data sensors continue to process traffic.

If you enable Session Combine, UDP sessions from the specified port to the same destination are combined into a single session.

Application Metadata

Enable this to control how application information is collected and which applications are included.

You can disable the collection of application metadata to increase sensor performance and save storage space, but that limits collected data to:

• Basic session information

• Packet and byte counts

• IP address

• Port

You can set the Metadata Collection Level to Limited Evidence, Minimum, Standard, or Maximum. This controls how many of the information fields are collected.

Minimum collects everything in Limited Evidence. There is currently no difference between Minimum and Limited Evidence.

Collection Scope allows you to filter specific metadata that is sent to the Data Processor.

• Select All applications for no traffic filtering

• Select Exclude certain applications to collect metadata for all content except the applications and application groups you specify in the selector box. .

• Select Only collect certain applications to exclude all metadata except that for the applications and application groups you specify in the selector box.

When you select an option other than All applications, the selector box accordingly updates for you to then Exclude or Include the following applications or application groups. Begin typing in the selector box to display a list of configured Application Groups and Applications. Applications Groups are listed first; scroll through the list to get to the set of Applications. When you select an Application Group, the label for it is has a prefix (Group: ) to distinguish it from Applications. In the above image, all the selections are applications except analytics.

In previous releases, Application Groups were referred to as Tags.

Metadata Summarization allows you to reduce traffic to the DP. If you enable this, the sensor groups similar metadata from chatty applications into a single JSON file before sending to the DP.

Finally, you can enable SMB Reduction to reduce the amount of metadata collected for SMB commands. This is especially helpful in increasing your compression ratio if your network has a great deal of SMB traffic. If you enable this, metadata is only collected for:

• session setup
• logoff
• read
• write

Process Correlation

Enable this to build correlations between processes running on the sensor and host, and the IP address/port visible in traffic. The processes monitored include:

• log forwarder
• IDS
• maltrace
• aella_flow
• SSHD
• HTTP

You can set the sampling time interval.

Packet Deduplication

Enable this for the sensor to perform packet deduplication. This reduces storage by removing duplicate data. However, it uses processing power on the sensor to analyze the data, and can significantly slow system performance. When you enable it, you can set the deduplication window time.

Enable with caution.

If you have no need for this (for example, if you have a sensor for every network segment), disable it.

Stream Slicing

Enable this to perform stream slicing, which truncates sessions at the specified length. This can reduce the bandwidth used.

This has no effect if you use local file assembly.

Handshake Failure

Enable this to detect handshake failures and allocate resources for that effort:

• Time(s)—amount of time the sensor collects failures to get to the threshold

• Threshold—the number of failures over the specified time before an alert on this is triggered

• Report Interval(s)—interval between reports to the DP if there are multiple failures

• Memory Limit (%)—maximum percentage of memory used by aella_flow for this detection

Flood Attack

Enable this to report flood attacks:

• Flood Threshold (Source)—the number of new session requests per second from a single source before an attack is reported

• Flood Threshold (Destination)—the number of new session requests per second from any source before an attack is reported

• Flood Expire Time(s)—the number of seconds without new session requests after which we stop considering it an attack, and the sensor sends a session_end message to the DP

• Flood Report Interval(s)—during an attack, the interval at which the sensor reports the attack to the DP (so that the DP isn't flooded with reports of the flood attack)

• TCP Syn Flag Check—only counts session requests if the SYN flag in the packet is set

Sensor Customizations

The settings in the Sensor tab let you configure:

• Malware Sandbox

• ML-IDS

• Log Forwarder

• Buffering

Buffering

If you enable buffering, the sensor buffers the logs sent to Stellar Cyber. If the logs are received successfully, the sensor deletes the buffered logs. If the buffer is full, the sensor stops buffering logs. The following parameters allow you to configure that buffering:

• Sum Size (MB)—The total of all Traffic, Log Forwarder, and Maltrace logs buffered

• Traffic—The amount, in MB, of traffic logs buffered

• Log Forwarder—The amount, in MB, of log forwarder logs buffered

• Maltrace—The amount, in MB, of maltrace logs buffered

When you disable buffering, any data in the buffer is immediately deleted. Ensure that the sensor has had a stable connection to the DP for long enough to transmit all data in the buffer.

Agent Customizations

The settings in the Agent tab let you specify settings for Linux Server Sensors:

• Linux Auditing—When selected the sensor checks its files for signs of alteration and monitors command executions.

  This option is separate from the dedicated FIM Linux options for file integrity monitoring below.

  • Force Linux Auditd to Stop—Stellar Cyber uses the aella_audit process to collect audit logs. Linux uses the auditd process. In most scenarios, the two processes coexist with each collecting data successfully. However, on older systems with pre-3.16 kernels, the processes can conflict, causing aella_audit to stop. If aella_audit is enabled, but you see no data on the DP, use this to stop the auditd process on older Linux systems.

    In some situations, the auditd configuration may be locked by the Linux kernel (audit configuration is locked in the kernel (enabled=2)), preventing this option from working. In these situations, if you are running 4.3.7 sensor software, you must remove immutable flag (-e 2) from the auditd config, followed by a reboot of the host system. You do not need to do this in 5.1.1 – the Force Linux Auditd to Stop option works correctly, even if the auditd configuration is locked.

• Control CPU Affinity—Choose which CPU in a multi-core system the sensor uses for the control thread.

• Data CPU Affinity—Choose which CPU in a multi-core system the sensor uses for the data processing thread.

• CPU Limit (%)—Specify the amount of CPU per core that the sensor can use. To get the total for the sensor, multiply this percent by the number of cores. For example, if you set this at 5% and you have 8 cores, the sensor could use up to 40% of the CPU, as reported by the top and htop utility (distributed). If you have 32 cores, the sensor could use up to 160%. A total above 100% might seem impossible, but it’s the sum of the usage percent on all the cores, each of which can have a maximum limit up to 100%.

  Note that the aella_flow process uses multiple threads. When using the top or htop utility with thread-mode enabled (top H or htop H), the output will show the percent that both the aella_flow process and its children threads use. At first, this might look like the CPU is processing twice as much as is configured because the individual threads add up to the same amount as their parent process and they’re all shown. To see the output displayed hierarchically so you can visually distinguish data for the parent process from data for its children threads, enable tree view mode (top V or htop F5).

  The commands to use:

  • In top, press H to show threads and V to enable tree view.

  • In htop, press H to show threads and F5 to enable tree view.

  By enabling the thread display along with tree view, you can clearly see which threads are associated with which parent processes, providing a detailed and organized view of CPU usage.

  The Server Sensor uses a minimum of 300 MHz, even if the value specified for CPU Limit (%) results in a smaller value based on the host's CPUs. For example, if the Server Sensor is installed in a host with 2 CPUs running at 2.2 GHz and you specify a value of 5% for CPU Limit (%), the arithmetic of 5% * 2 CPUs * 2.2 GHz would indicate an assignment of 220 MHz for the Server Sensor. However, in a situation such as this, the Server Sensor uses its minimum assignment of 300 MHz, even though it is greater than the specified value.

• Memory Usage Limit (%)—Specify the amount of memory the sensor can use.

• Buffering—Enabling this allows you to set the size of the Traffic, Linux Event, and Windows Event buffers.

  This option is deprecated but is still present to provide backwards compatibility with legacy Server Sensors that have it enabled in their profiles. It can no longer be enabled. However, legacy profiles that still have this feature enabled can use this option to disable it.

• FIM Linux–Enable this feature to monitor specified files and directories for changes, creations, and deletions. See the next section for details.

Configuring File Integrity Monitoring (FIM Linux)

Enabling the FIM Linux feature in a Sensor Profile lets you keep track of changes to specified files and directories, including file changes, file creations, and file deletions.

When you enable the FIM Linuxfeature, a new table appears in the Sensor Profile dialog box that lets you specify both the files and directories you want to monitor for changes, as well as the types of changes for which you want to monitor. As you can see in the image below, the table is preconfigured with a set of paths recommended for monitoring.

Click the + Add Row button to add new files/directories to the FIM feature. For each entry in the table, you can configure the following:

• Enabled – Specifies whether the indicated files/directories are enabled for monitoring. This lets you toggle a given file/directory on or off for monitoring without needing to delete it from the profile entirely.

• Path – Specifies the directory to monitor.

• Inclusions – Specifies the files within the directory to monitor. You can use the asterisk (*) character for standard wildcarding. For example, *.sh. If you leave this field blank, it is implicitly set to *, meaning that all files in the specified path are included for monitoring.

• Exclusions – Specifies the files within the directory to exclude from monitoring. You may want to use this feature to exclude certain file types that are trusted and change often. Standard wildcarding is supported here, too. By default, this field is set empty and no files are excluded from monitoring.

• Depth – Specifies how many directories below the specified directory to monitor.

  A depth of 0 means that you are monitoring only the specified directory and nothing below it.

• Change/Create/Delete – Use these checkboxes to specify the types of changes to track in the specified path.

In general, it's a good idea to optimize performance by focusing your FIM settings on specific files rather than large directories with many files and subdirectories. Refer to Best Practices for File Integrity Monitoring (FIM) for performance guidelines and a set of system files recommended for integrity monitoring.

The FIM feature works by recording a file hash for all files configured for monitoring in the Sensor Profile. Once the initial hash is recorded, the FIM feature regularly monitors for changes to the file hash and sends events to the DP if changes are seen.

You can keep track of events generated by the FIM feature in the following ways:

• Use the predefined Visualize | File Integrity Monitoring dashboard.

• Use the Threat Hunting feature to search the Linux Events index for events with msg_origin.source set to linux_agent and msg_origin.processor.type set to FIM (or agent.type set to auditbeat). Once you find such an event, you can add it to the Threat Hunting Documents table by using the Toggle add column to table button adjacent to its entry and sort to see all such events.

• Similarly, you can create ATH rules with queries based on the msg_origin.processor.type field set to FIM.

The JSON for a FIM event indicates the type of change that took place. If the event indicates either a change or a deletion, the JSON includes both old and current values. For example, the illustration below shows a change in a file's hash between the old and current sections, indicating that its contents changed. If the event indicates a file creation, only the current section appears in the JSON.

Linux Server Sensor Installation Directories Excluded from FIM

Note that the following installation directories for the Linux Server Sensor are automatically excluded from FIM monitoring. The user interface does not prevent you from adding these directories; however, they are still automatically excluded from FIM monitoring:

• /var/aella/

• /var/log/aella

• /opt/aella

• /opt/aelladata

Keep in mind that the FIM Linux feature can only monitor files and folders that exist when the aella_audit service restarts. If you add a non-existent file or folder for monitoring in the Sensor Profile and then create the folder later, it won't be monitored until aella_audit restarts.

Windows Customizations

You can configure Windows Server Sensors to collect specific logs. Logs are organized into different predefined channels in the Windows tab, each with its own maximum log size. You can toggle collection of the available logs and event types in each of the different individual channels, or opt for the simple route and use one of the predefined templates for Windows Server Sensors provided by Stellar Cyber. You can also apply filters configured in the System | Log Filters page as Event Filters, excluding or including matching events.

Start with a Windows Server Sensor Template!

Stellar Cyber recommends that you start configuration of a Windows Server Sensor's profile by using one of the predefined templates included with the system. These templates have been carefully configured to match common deployment scenarios. Once you have reviewed the settings in a template and seen how it operates in your environment, you can tailor the settings in individual channels to fit your needs.

The following templates are available for options in the Windows tab of the ADD/EDIT SENSOR PROFILE window:

• Windows Detect Profile (Low Volume). The selection covers the minimal events required for all native detections in Stellar Cyber.

• Windows Context Profile (Medium Volume). Adds events commonly used by third-party detection rules.

• Windows Compliance Profile (High Volume). Covers all Windows events.

Each of these profiles collects a different set of logs/events and results in a progressively higher volume of data ingestion from Low to Medium to High.

If you find that you are ingesting a higher volume of data than you would like relative to your license limits, you may want to reconfigure these settings, keeping in mind that the Low Volume profile provides enough coverage for all native Stellar Cyber detections.

How to Apply a Windows Server Sensor Template

You apply a profile for settings in the Windows tab as follows:

1. Navigate to System | Sensor Profiles, click the Create button, and select the Add Standard Sensor Profile option.

2. Click the Set to Template button and use the context menu that appears to select one of the available Windows Server Sensor profiles from the Restore Windows Profile to Template menu, as illustrated below:

   

   Note the following:

   • The Set to Template button is available regardless of which tab is displayed in the Add/Edit Sensor Profile window.

   • The only templates available in this release are for the options in the Windows tab and are organized under Set to Template | Restore Windows Profile to Template.

   • When you select one of the templates in the Restore Windows Profile to Template menu, all options in the Windows tab are reset according to the selected template. All other profile options are left unchanged. For example, if you have made customizations to the options in the Network tab, those options remain at their current settings after applying a Windows template to reset the options in the Windows tab.

   • You can reset the options in the Windows tab using a template as often as you like, keeping in mind that all the options in the tab are reset to match the template each time you do so. You can also start with a template and then tweak individual settings as you see fit.

Applying Event Filters

You can use the Add Event Filters fields to Exclude or Include events matching the listed filters, giving you fine-grained control on which events are processed. You can apply any of the filters configured in the System | Log Filters page as Event Filters; when you click in the panels, a list of the available filters appears. Check the boxes of any filters you want to apply as Exclude or Include filters.

Keep in mind the following notes when using filters configured in the System | Log Filters page as Event Filters for a Windows Sensor Profile:

• Event Filters apply to events in all of the other channels, except FIM (Security, System, Application, Forwarded Events, Microsoft Windows DHCP Client, Microsoft Windows Firewall with Advanced Security Firewall, Microsoft Windows Defender, Microsoft Windows Sysmon, Microsoft Windows PowerShell Operational, and Other Channels).

• Event Filters are joined with the Specify Event IDs entries in the other channels using a logical AND. This means that a given event must match both the Event Filters and the Specify Event IDs entries to pass the filter.

  For example, consider the following configuration:

  • Event Filter is set to Exclude field process-id=100

  • Specify Event IDs is set to Include ID 1

  In this situation the overall filter will ingest logs with an ID of 1 that do not have field process-id=100.

• Exclude filters are always applied before Include filters, in the order they are specified.

• If you specify Include filters, only those logs matching the specified Include filters are ingested. All logs that do not match the specified Include filters are dropped.

• Only use Log Filters configured without the optional Log Source specified, as demonstrated in the figure below. Log Filters with a Log Source configured won't match any event logs on the Windows Server Sensor when used as Event Filters.

  

  Refer to Managing Log Filters for detailed instructions on configuring Log Filters.

• You can apply a maximum of 100 Event Filters each in the Exclude and Include panels.

• The Windows Server Sensor templates do not set any Event Filters.

Keeping Tabs on Log Filter Statistics

You can keep tabs on statistics related to log filters using the show logfilter and show logfilter < filter-id> commands in the sensor CLI. The show logfilter-id command shows the details of the last matching event during filtering and can be useful when evaluating filter performance.

In addition, log filter statistics are sent to the Sensor Monitoring index (aella-ade-*) on the DP using msgtype:41 and can be viewed in the Threat Hunting page with Indices set to Sensor Monitoring. See below for the schema.

About the Predefined Channels in the Windows Tab

The predefined channels allow you to collect events in the following categories:

• Security

• System

• Application

• Forwarded Events

• Microsoft Windows DHCP Client

• Microsoft Windows Firewall with Advanced Security Firewall

• Microsoft Windows Defender

• Microsoft Windows Sysmon

• Microsoft Windows PowerShell

• FIM (File Integrity Monitoring)

All of the channels are enabled by default, with the exception of FIM. Events for each channel are stored in their own file. When a given file is full, older events are overwritten. If the sensor is receiving events faster than it can send them to the DP, you can increase the log file size to store more events or opt to exclude certain events.

Including or Excluding Specific Event IDs

Each of the preset channels in the Windows tab includes a Specify Event IDs option that lets you either Exclude or Include specific Event IDs. Use the following procedure:

1. Navigate to the channel from which you want to include or exclude specific Event IDs and cascade its entry open.

2. Scroll to the bottom of the channel's available options until you locate its Specify Event IDs entry. For example, the illustration below shows the Specify Event IDs entry for the System channel.

   

   Some of the channels have the Specify Event IDs option enabled automatically with IDs supplied for you if you have selected one of the available templates for the Windows tab options. Refer to Templates for Windows Server Sensors for a list of the options and Event IDs included in each of the available profiles.

3. Toggle the Specify Event IDs option on and choose whether you want to Exclude or Include specific IDs.

4. Supply the IDs you want to Exclude or Include by typing them into the Event IDs field, as illustrated below.

   

   Note that the IDs you enter here are not validated. You can use the Event table in the Threat Hunting display (enable the column for Event IDs) to identify noisy/low value IDs, or refer to external resources, such as https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/event-id-explanations .

5. Click Submit when you are finished with all settings for the Sensor Profile.

Configuring the Log Size for a Channel

To configure the log size for a channel:

1. Click on the name of the channel for which you want to customize log size.

   

2. Click on the Log Size Control toggle to enable it and to display size information.

   

3. Click Custom to enable a custom log size.

4. Enter the custom size.

5. Click Submit after you finish all configurations.

Adding Other Channels

To add other channels:

1. Click Other Channels. The section expands.

   

   You can either select from the available preset channels or type in your own.

2. To select from the preset channels, you choose one or more channels from the Types drop-down and click Add. The channel appears in the Added box.

   

   The available preset channels are extensive and are best reviewed in the user interface. In addition to many others, they include the following:

   • Microsoft-Windows-AppLocker/EXE and DLL

   • Microsoft-Windows-AppLocker/MSI and Script

   • Microsoft-Windows-AppLocker/Packaged app-Deployment

   • Microsoft-Windows-AppLocker/Packaged app-Execution

   • Microsoft-Windows-DNS-Server/Analytical

   • Microsoft-Windows-GroupPolicy/Operational

   • Microsoft-Windows-Kernel-Boot/Operational

   • Microsoft-Windows-NetworkProvider/Operational

   • Microsoft-Windows-PowerShell/Admin

   • Microsoft-Windows-TCPIP/Operational

   • OpenSSH/Admin

   • OpenSSH/Operational

   • Windows Networking VPN Plugin Platform/Operational

3. You can also type in your own Windows event channel. The user interface checks to make sure the channel exists and reports an error message if it does not.

4. Click Submit after you finish all settings for the profile.

Limiting the Age of Collected Logs

To limit the age of the logs collected when you first enable:

1. Click Collect logs no older than specified time (Hours). The section expands.

2. Enter the number of hours.

3. Click Submit after you finish all settings for the profile.

Configuring File Integrity Monitoring (FIM Windows)

Enabling the FIM Windowsfeature in a Sensor Profile lets you keep track of changes to specified files and directories, including file changes, file creations, and file deletions.

When you enable the FIM Windows feature, a new table appears in the Sensor Profile dialog box that lets you specify both the files and directories you want to monitor for changes, as well as the types of changes for which you want to monitor.

As you can see in the image below, the table is preconfigured with a set of files and directories recommended for monitoring by industry-standard best practices.

Click the + Add Row button to add new files/directories to the FIM feature. For each entry in the table, you can configure the following:

• Enabled – Specifies whether the indicated files/directories are enabled for monitoring. This lets you toggle a given file/directory on or off for monitoring without needing to delete it from the profile entirely.

• Path – Specifies the directory to monitor.

  A given path can only have one entry in the table. In addition, keep in mind that Windows paths are case-insensitive. Because of this, Stellar Cyber prevents you from adding, for example, both C:\Program Files and C:\program files. Because paths are not case-sensitive, these two paths are treated as the same by Stellar Cyber.

• Inclusions – Specifies the files within the directory to monitor. You can use the asterisk (*) character for standard wildcarding. For example, *.bat, *.cfg, and so on. If you leave this field blank, it is implicitly set to *, meaning that all files in the specified path are included for monitoring.

• Exclusions – Specifies the files within the directory to exclude from monitoring. You may want to use this feature to exclude certain file types that are trusted and change often. Standard wildcarding is supported here, too. By default, this field is set empty and no files are excluded from monitoring.

• Depth – Specifies how many directories below the specified directory to monitor.

  A depth of 0 means that you are monitoring only the specified directory and nothing below it.

• Change/Create/Delete – Use these checkboxes to specify the types of changes to track in the specified path.

In general, it's a good idea to optimize performance by focusing your FIM settings on specific files rather than large directories with many files and subdirectories (C:\, for example). Refer to Best Practices for File Integrity Monitoring (FIM) for performance guidelines and a set of system files recommended for integrity monitoring by Microsoft.

The FIM feature works by recording a file hash for all files configured for monitoring in the Sensor Profile. Once the initial hash is recorded, the FIM feature regularly monitors for changes to the file hash and sends events to the DP if changes are seen.

You can keep track of events generated by the FIM Windows feature in the following ways:

• Use the predefined Visualize | File Integrity Monitoring dashboard.

• Use the Threat Hunting feature to search the Windows Events index for events with msg_origin.source set to windows_agent and msg_origin.processor.type set to FIM. Once you find such an event, you can add it to the Threat Hunting Documents table by using the Toggle add column to table button adjacent to its entry and sort to see all such events.

• Similarly, you can create ATH rules with queries based on the msg_origin.processor.type field set to FIM.

The JSON for a FIM event indicates the type of change that took place. If the event indicates either a change or a deletion, the JSON includes both old and current values. For example, the illustration below shows a change in a file's hash between the old and current sections, indicating that its contents changed. If the event indicates a file creation, only the current section appears in the JSON.

Note that when the FIM Windows feature is enabled on a Windows Server Sensor, a new windows agent sensor fim process is spawned on the host machine and can be viewed with other running processes.

Windows Server Sensor Installation Directories Excluded from FIM

Note that the following installation directories for the Windows Server Sensor are automatically excluded from FIM monitoring. The user interface does not prevent you from adding these directories; however, they are still automatically excluded from FIM monitoring:

• C:\ProgramData\StellarCyber\Windows Agent Sensor\config

• C:\ProgramData\StellarCyber\Windows Agent Sensor\log

• C:\ProgramData\StellarCyber\Windows Agent Sensor\run

Keep in mind that the FIM Windows feature can only monitor files and folders that exist when the windows agent sensor fim service restarts. If you add a non-existent file or folder for monitoring in the Sensor Profile and then create the folder later, it won't be monitored until windows agent sensor fim restarts.

Memory Usage and Windows Server Sensor Profiles

When applying a sensor profile to a Windows Server Sensor, the system compares the amount of memory required by the profile to the amount of memory available on the target system and reports success or failure in the Sensors list as follows:

• Systems with ≥ 100 GB Total Memory: Profile is applied successfully if the amount of free memory on the target system minus the memory required by the profile is ≥ 25 GB. If less, the failure is reported in the Sensors list.

• Systems with < 100 GB Total Memory: Profile is applied successfully if the amount of free memory on the target system minus the memory required by the profile is ≥ 25% of the total memory. If less, the failure is reported in the Sensors list.

  If you receive a memory warning in the Sensors list, you can either reduce the memory footprint of the sensor profile (for example, by reducing the size of the Log Size Control options) or provision additional memory for the Windows Server Sensor host.