Which networks get an IDS
-
Design question.
If a business has several wireless networks, say one for STAFF, Guest, Contractors. IoT.
Does it make sense to run IPS for each VLAN?
Which networks would get an IDS sensor on them? -
Depends on the rules between the networks, and to some degree what your legal eagles might suggest (if the business is large enough to have in-house lawyers).
For example, generally a Guest network would have zero access to anything internal to the company and only be able to go straight out to the Internet. In that case, no real value in running IDS there in my opinion. However, if your legal eagles were worried about some kind of liability should someone use your Guest network for a nefarious purpose, then they might want an IDS/IPS there.
A Contractor network would have similar concerns, but perhaps it is more likely a Contractor network might have some kind of access into your other business networks. In that case an IDS/IPS might be useful.
IoT in business can be an issue if not properly isolated. There have been a number of instances in the past where corporate networks were breached via remote access of some sort by a vendor into IoT devices (HVAC systems controls being the most favorite problem child area).
But all of this assumes the IDS/IPS has a clear unobstructed view into the traffic. As mentioned several times over the last few months, nearly 100% of network traffic today is encrypted. That severely limits the usefulness of IDS/IPS unless you use MITM to break the encryption and allow cleartext inspection. Doing that gets really hard with a BYOD (bring your own device) environment. It's much easier with company-issued and controlled devices (but still a pain to configure and maintain).
-
@bmeeks Agreed on the traffic flows being encrypted. Suricata has a good rule set , ET POLICY, which i find useful in hunting or just to see if there are any "violations".
The ineffectiveness of IPS assumes that threat actors are using TLS to obfusicate the movements but at least in the ET rules sets that are being updated there still seems to be lots of cleartext nefarious traffic still operating.So would your rule of thumb be, if traffic flows cross into sensitive areas than to place an IPS sensor otherwise you can forgo threat prevention?
Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
@michmoor said in Which networks get an IDS:
So would your rule of thumb be, if traffic flows cross into sensitive areas than to place an IPS sensor otherwise you can forgo threat prevention?
Yes, that's my view. The exception would be if you just have tons of spare capacity (CPU and RAM) on a firewall and want to scan the traffic. Just be prepared to see and filter through a lot of junk and likely false positives.
Another exception might be if you are a big, fat corporate target (meaning you have lots of cash flow that looks enticing to greedy plaintiff's lawyers
), then you might want to scan all traffic in order to have a decent chance of defending a lawsuit by falling back on a "reasonable and best effort" defense strategy. What I mean here is say someone establishes a semi-permanent presence on your Guest network and then proceeds to host or conduct illegal activities from there. If it existed for a long time, and you showed no effort at policing it, and someone suffered harm because of the activity, then some ambulance-chaser attorney might sue. This would usually be with the expectation of getting a "go away and shut-up" cash settlement offer from the defendant (your company). -
@michmoor said in Which networks get an IDS:
there still seems to be lots of cleartext nefarious traffic still operating.
Not necessarily. The rules are written assuming the traffic is being scanned in the clear. This is especially true for payload scans. So, some ET rule might fire as designed when used with a MITM setup, but yet fail totally when scanning encrypted traffic (traffic which has not been decrypted using MITM).
The rule authors assume the payloads they are looking for are unencrypted. On the other hand, rules which are primarily looking for source or destination IP addresses, and in some limited cases domain lookups, can certainly still work with encrypted traffic.
-
@bmeeks said in Which networks get an IDS:
Not necessarily. The rules are written assuming the traffic is being scanned in the clear.
Good point. I didnt consider that aspect. When looked at it that way then without a Suricata/TLS Decryption process flow then yes...Suricatra would be all but useless to defend.
Suricata can at least read DNS or TLS headers to determine a possible threat but in the coming years that will be ineffective once the TLS handshake process is fully encrypted. That just leaves DNS which any publicly available list can be used.....
I think i see your point here Bill.
For now, its better to have it then to not (defense in depth) so Suricata as deployed will remain.
I did find this in their documentation to do TLS decrypt with Suricata link
There doesnt seem to be a lot of projects i can find that does TLS decryption and then packet forwarding to Suricata.
