[Tfug] Lightweight IDS options/strategy/policy

[Bexley Hall]

Hi Tyler,

On 9/24/2013 10:18 PM, vaca at grazeland.com wrote:
> Tuning of an IDS can be very time consuming for some of the reasons
> mentioned here.  When is it innocent?  When is it a virus or a hacker?
> That doesn't mean, however, that in a secure environment you just omit it.
>
> IDS is a basic building block for secure networks.  It is part of any
> comprehensive defense-in-depth strategy...as would be a documented and
> rehearsed security incident response plan.

This makes sense in an enterprise environment.  But, not so much
in, e.g., "home automation" -- how does Joe AverageUser even
*relate* to these sorts of issues?

It's akin to the "check engine" light in your (their) vehicle.
They (probably) aren't capable of understanding much less
*resolving* the problem if the car could convey it to them.
Rather, it is a (strong) "suggestion" that they should consult
an expert to resolve the problem (that the car has detected in
itself).

In my case, an adversary can't really *do* anything -- other than
tying up *one* network interface with a DoS attack.  If that is
an internal interface, then all he does is deny *himself* service.
If it is an external interface, he can conceivably interfere with
other traffic that would *like* to avail itself of that interface
(so, any services that rely on that traffic would be impaired;
i.e., don't rely on an external interface being functional nor
the integrity of any data obtained via that interface!)

E.g., if he could interrupt the "Internet" interface, then he
could conceivably masquerade as Google, Weather Underground,
etc.  So, any information that I relied on from those sources
would potentially be compromised.

Even if he doesn't masquerade, he could busy out that interface
with a ping flood and prevent legitimate traffic from getting
through.

Moral of story:  I don't rely on anything that I can't control.

But, deciding what criteria to use to *signal* the user that
"something is fishy" gets to be troublesome.

I.e., if an unauthorized host tries to access a service inside
the "perimeter" (e.g., a guest in the spare bedroom tinkering
with his laptop), when does the BLOCKED attempt go from an
honest mistake to a casual probe to a deliberate attack?
And, what does the system report besides "Unauthorized traffic
detected originating from network drop in northeast corner of
guest bedroom"?

"Hey, Bob, cut it out!"