AlienVault saying I can't use it in a DHCP environment. Help!

We perform a lot of AlienVault implementations (both USM Appliance and USM Anywhere) for AlienVault/AT&T Cybersecurity as well as see a lot of other SIEM technologies on the market. With the exception of more specialized UEBA technologies (as well as some very specialized asset discovery tools) most (if not all), SIEMs on the market have difficulty accurately accounting for all assets/devices in an infrastructure. The explanation for why this is the case isn’t particularly short, but we can sum it up to several things.

Assets must be discovered, with various technologies this is done by the following means:

1- Active ping scan:
Pros:
Very fast
The most common way for most SIEMs to discover all assets on the network
Cons:
If a device is blocking ping (as is default in Windows) then the device won’t register on the scan
Relies 100% on accurate DNS to do a reverse lookup for the PTR record to get the name (we often see Windows infrastructures that aren’t set up correctly to register the DNS name with DHCP)

2- Active port scan:
Pros:
Discovers many devices which are blocking ping, but have some other port open
Cons:
It's slow.
It can have accuracy issues depending on the time of day when the scan is run and how large the subnet being scanned is (goes back to the problem with being slow).

3- Agent-based:
Pros:
The agent can associate the IP address/hostname/MAC/etc to ensure you have an accurate host entry on the device
The most popular way to accurately identify a device
Cons:
It’s another agent that must be installed on the endpoint
Doesn’t work for IoT devices
If the agent isn’t installed then it obviously cannot accurately identify the device

4- WMI or Windows DNS/DHCP Logs:
Pros:
Great for Windows infrastructures
Cons:
You have the same problem as the Active Ping Scan: You *must* ensure that the device registers it’s DNS entry once it obtains a DHCP lease. Most IoT devices *cannot* do this, aka your cameras, printers, door locks, smart thermostats, iPads, etc

5- Passive Discovery:
Pros:
It sees all traffic flowing across the SPAN port
Cons:
Must be tied to asset hostnames via other methods (Agent, DNS lookup, etc)
SNMP: If you’re considering this route you’re already contemplating more in-depth means for asset discovery than most SIEMs on the market can understand.

After the asset discovery, the SIEM must accurately track the asset across different IP addresses in a DHCP environment. Without the means of a standard identifier (MAC address, unique hostname that’s checkable via reverse DNS lookup) “unique” devices (which really are the same devices simply with different IP addresses) simply keeping adding to the list of previously discovered addresses (I have a 100 devices in my infrastructure, why does my SIEM think I have 4,000!?!?!). This problem plagues almost every SIEM on the market (depending on the honesty of the Sales Engineer for the vendor). However, some vendors do a better job of mitigating the obnoxiousness than others. In the case of AlienVault, we recommend employing a strategy that can allow you to accurately discover/assess current and previous threats but also enable you to utilize DHCP.

To be clear, the official stance of AlienVault is that everyone in an enterprise company should utilize static IP addresses internally. Realistically, the official stance isn’t something that has been feasible since the ’90s. Furthermore, with AT&T recently acquiring them I expect that we’ll see some dramatic changes to their position on DHCP as AT&T is now officially utilizing AlienVault to monitor AT&T operations in their Security Operation Centers. We have already seen multiple direction changes in the product that have long been asked for but only recently added since the acquisition. And, you better believe that AT&T *extensively* utilizes DHCP – trust me, it’ll be coming.

To be clear, if you’re looking for an automated asset discovery and analysis platform, you should look at something such as Great Bay Software’s “Network Intelligence Platform.” On the other hand, if you’re looking to secure your infrastructure then you absolutely need to utilize a *real* SIEM and AlienVault is an excellent security platform.

Here are my recommendations for making your AlienVault asset lists more accurate:

-Ensure that Asset Scans are running on a daily basis during work hours (this will *not* cause performance problems for your endpoints as it’s not a vuln scan).

-Ensure that DHCP is set to enable DNS dynamic updates for *both* A records and PTR records. I’d recommend simply using Windows DHCP for your DHCP management along with Windows DNS, and not use your firewall, switch, etc for DNS/DHCP functionality. This will ensure all subnets have a centralized point for updates and will provide the crucial DNS PTR data that AlienVault requires to accurately name a device.

-Utilize Agents across your devices across your infrastructure.

-Ensure all logs across your infrastructure are piping into the AlienVault. For example, by default Windows does not log DNS or DHCP entries (by default Windows only logs event changes to the service via the Windows Event Log). Similarly, many people forget to send their firewall, switch, access point logs, etc to AlienVault for correlation. For the Windows logs, you’ll need to utilize NXLog and modify the configuration to read the file-based logs for DNS/DHCP; AlienVault has very good documentation on how to do this.
-Ensure you are utilizing the NIDs functionality from AlienVault and that you are SPANing all VLANS to the monitor/SPAN port that AlienVault is watching.

-Regularly clean out devices in your asset lists.

As you can guess, these steps should be performed for any SIEM you utilize, and by doing so you will be significantly enriching any security/threat data being sent to the SIEM. The end result should be a worthwhile tune-up that will make the product much more enjoyable to use.

I use it in a DHCP environment. I don’t really care about the IP address; I care about the machine name instead.

In general, you will have the same problems with any software for log analysis in DHCP environments. But you can use FQDN and can also install agents on assets with dynamic IP.

But really, you will have some difficulties with asset and vulnerability management. Try to use 0.0.0.0/24 as IP address and correct FQDN on assets it may help.

The inventory management of USM seems to be not only based on the IP but on the MAC address. At least this is what I can see from the UI. At the same time, I'm not a big fan of the old OSSEC version used in USM as HIDS, so we decided to replace it with the OSSEC-Wazuh fork (documentation.wazuh.com). Wazuh gives much better and more detailed information here but does also not replace a full-blown inventory management solution. The same is valid for the vulnerability scanner. USM's built-in OpenVAS looks outdated, so we replaced it with a stand-alone OpenVAS which is now called Greenbone Community Edition. The beauty here is that you can access the underlying DB directly (SQLite or PostgreSQL), so grabbing vulnerabilities and related context information per asset works like a charm and is very flexible. The only caveat in the end: One will be drifting away from the "all-in-one" approach towards using the USM "modules" in a new self-managed approach, but with more flexibility and more possibilities. Despite the fact, the most time-consuming work is spent with looking and analyzing the events, this is only a small trade-off.

We use it in a DHCP environment. The trouble you will have is that you may get duplicate assets if you do not use reservations or fixed IPs. An asset is an IP address. If you use DHCP, you will get multiple assets for the same device. It's very frustrating to manage without using reservations or fixed IPs. We are going the route of using agents and reservations for as many devices as possible. The trouble we have is with roaming devices like laptops. Another reviewer recommended using FQDNs. That works to a certain degree, but you still have problems with duplicate assets. You will see the same FQDN appear two or more times with a different IP.

The easiest solution is for the client to obtain a static IP address from AV which are really cheap.

With USM Anywhere we have made changes and improvements to environments with DHCP. The suggestion is always to go with fixed IP’s but we
understand this is not always possible.

So some workarounds are:

• Extend the life of a lease as long as possible.
• Install agents on the critical devices and they will help with the DHCP changes.