[Tfug] Lightweight IDS options/strategy/policy

[Bexley Hall]

Hi Kramer,

On 9/24/2013 11:27 PM, Kramer Lee wrote:
> "Think about it.  Would you tolerate something on your
> "personal" internet if it *couldn't* "dial out" -- but
> *could* interfere with the operation or integrity of
> your stuff?"
>
> That sounds like a virus/malware.  Is that part of intrusion detection?

If I plant a "plug" on your premises and it gathers data
and/or interferes with your operations -- then, I *reclaim*
the device some time later (i.e., *physically* carry the data
it has harvested off the premises), is that a virus?  It
hasn't "spread"... just monitored traffic and gathered up
the names of all email accounts, internal servers/services, etc.

> So, we can be intruded into directly, an event we might be able to see
> if an intrusion detection system worked and it wasn't a zero day
> exploit.  If the hackers get past the IDS you are in trouble.  That
> would be a bad event, especially if the critical internal computers
> with the valuable information are connected directly to the internet
> (not the best idea).  But even if that happens, and it isn't good, it
> would be made much worse of the intrusion program can dial back out,
> so you now suffer even more competitive loss from IP being taken, or
> also financial information, internal passwords, etc.  At least if the
> data can be kept inside the firewall, that part of the disaster can be
> mitigated. Many hackers are hacking for profit, less are hacking to
> damage.

I don't let any "network interface" talk to any other interface in
a manner that I don't tightly control.  E.g., the surveillance
camera on network drop #17 having the MAC of XX:XX:XX:XX:XX:XX
and IP of Y.Y.Y.Y/Y can only use service C provided by node W
using protocol Z...  If I see traffic originating on drop #17
that doesn't have that MAC, IP, protocol/destination, then I
know either:
- the surveillance camera has a bug in it that is causing it
   to have confused one or more of these details
- something *other* than the surveillance camera is attached
   to that network drop

If it's a bug, someone needs to know.  If it's "something else",
then, depending on which drop we're talking about, it is either
a mistake, casual probe or deliberate attack.

If, for example, network drop #17 was an "open" drop in the
guest bedroom, then I wouldn't know what the MAC/IP of a device
(laptop?) that happens to get plugged into that drop might be.
And, someone using that drop might ACCIDENTALLY try to access
some service on my internet.  Or, might be a bit persistent
about trying to get into such a service.  Or, might be VERY
AGGRESSIVE in trying to access that service (e.g., perhaps
wanting to monitor the live video from the camera mentioned
above).

In each case, it is blocked.  But, when do I "bother" the homeowner
with an "incident report"?  How do I avoid creating reports for those
"accidental" access attempts vs. the *deliberate* probes?  And, do
so "cheaply" (i.e., I don't want to have to track connection
attempts over the course of *hours* to see if there is a pattern
that fits some off-the-shelf probe/script).

What does that report look like:

    "At <time> on <day> an unexpected access was attempted from
    <IP> at <MAC> on network drop N located <somewhere>.  The
    access was blocked.  Just thought you should know..."

What does Joe AverageUser *do* with these?  Worry??  :-/

> Anyway, more emphasis should be put on keeping the valuable
> information from getting out.  The intrusion detection stuff is great,
> but not sufficient.