In this post, I'm going to go over host groups and why they're so critical to the StealthWatch system. Using host groups correctly in the StealthWatch system will ensure that you're alerted correctly on events and that the information given to you is more relevant to your enterprise.
StealthWatch views a host as an IP address that is generating traffic and either requires or provides services. Since StealthWatch is network-based anomaly system, it monitors all the network activity between any host server or application and creates a baseline based on that behavior. Other things, the StealthWatch system will alert on because the host behaves in a way that triggers a type of threshold.
Depending on the type of host, you may want different thresholds or to bypass alerts for certain behavior. This is where host groups come in. A host group is a "container" of hosts or IP addresses that share attributes and policies. Some of the different attributes you'd typically group together are the following:
- Shared functions
- Exhibits similar behavior
- Can be managed as a single object
- To which a single policy can be applied to
- To identify IP hosts that you "own"
StealthWatch will alert you if host behave outside baseline behavior and thresholds but using host groups will really trim down on any additional noise. For example, how does StealthWatch tell the difference between a rogue DHCP server or a legitimate one? By adding your existing DHCP servers to the DHCP host group, the legitimate DHCP will not trigger an alarm but let's say someone brings in their Linksys router from home, plugs it into the network and it starts handing out IPs, you'll quickly see it with StealthWatch.
StealthWatch has several built-in host groups you can utilize:
- Catch All - This contains all the RFC 1918 addresses, your private addresses and your public IP addresses. Once an IP address is added to another host group, it will be removed from the Catch All container. It's the host group of last resort whenever a private IP address is not already assigned to another host group.
- By Function - This host group has several subgroups that have a pre-defined role policy. Some of the sub-groups include the following:
- NAT Gateway
- Client IP Ranges (DHCP Ranges)
- nd User Devices
- Guest Wireless Networks
- Remote VPN IP Pool
- Trusted Wireless
- Network Scanners
- Antivirus servers
- Backup Servers
- Confidential Servers
- Database Servers
- DHCP Servers
- DNS Servers
- Domain Controllers
- File Servers
- Mail Servers
- NTP Servers
- SMS Servers
- Terminal Servers
- Web Servers
- oIP Endpoints
- VoIP Gateways
- By Location - There might be a situation where you will want to group the devices by location. Each location may have their own DNS server or similar device types.
- Outside Hosts - This contains all the host identified as NOT being part of your network. Basically, the internet
- Command & Control Servers - This is only if you have the StealthWatch Labs Intelligence Center (SLIC) licenses. What it does is contains known malicious hosts that should never be reached and if a host is found trying to connect to it, you will most certainly get an alert.
To view what hosts are in a given host group, highlight the host group, right-click and from the menu, navigate to Hosts>Active Hosts to view the active hosts in that Host Group:
Another good dashboard to go to is the Host Group Dashboard which you can go to by right-clicking the host group again:
You can look at this dashboard to see the top hosts, alarm summary, and security. From there, you can decide whether or not to move these hosts into a different host group. This can easily be done by highlighting an IP, right-clicking and navigating to Configuration>Manage Host Groups...
From this pop-up, you can easily move this host to another host group:
More than defining hosts one-by-one, you can easily define them in the host group by host, subnet, etc. Highlight the host group, right-click, and navigating to Configuration>Edit Host Group and here you can add hosts, enable baselining, etc:
You can also create a Host Locking policy. What that does is raises an alarm if the client sends certain traffic to another host group. To configure this, highlight a host group, right-click, and navigate to Configuration>Host Locking Configuration. From the pop-up window that comes up, click Add:
The practical use for this is if you have compliance rules you need to adhere to. An example of this would be that your Point-of-Sale equipment should never interact with your guest wireless. If you created a host locking policy that states that those two host groups should never communicate, this will alarm you if it ever happens. As you can see above, you can allow or disallow certain services or applications. This also provides you visibility and alarming to let you know if your existing security controls are working correctly and as they should be.
One last thing to look at is the Host Policy Manager. If you right-click on another host group and navigate to Configuration>Host Policy Manager, you can see the existing policies on the host group:
You can add new ones if you'd like but I'm going to click edit on an existing one to show you what it looks like:
For the default groups, a lot of these policies are pre-made but you do have the option to create new ones and specify the alarms and thresholds that are important to you.
Host groups are nested under other host groups branches and there is a hierarchy to how policy is applied. Configuration trickles downward so if a certain sub-group has a policy that does not trigger an alarm, the policy above it will be tested, and then the one above. It will keep moving up the tree to see if any other policies from a parent host group will trigger the alarm.