Meeting notes, March 2002 BayLISA meeting

[Rick Moen]

BayLISA March 2002 Meeting
Thursday, 2002-03-21
John S. Flowers <jflowers at well.com>
nCircle Network Security

These are some meeting casual meetings I took during the meeting.  John
says he'll post his slides to http://www.johnflowers.com/ .  (Not there,
yet.)


Security: Our networks are under attack, with more attack tools applied
to the job all the time.  Unfortunately, the security industry
concentrates on attacks, having seemingly given up on identification,
discovery, risk management, business consequences of exposures, and
quantifying the skill required to exploit vulnerabilities. 

Security "experts" tend to understand the technology but not the
network, e.g., recommendation from large accounting firm with initials
"AA" to a large database firm with name starting with "O" that the
latter turn off its RealVideo streaming server as "dangerous". Real need
is for prevention, not alarms:  Need relevant data.  Know your devices:
In a survey of firms' sysadmins, no firm studied could report its number
of IP-address-bearing devices in current service to closer than 300%
wrong.  

Understand your exposures, and then map your policy to the exposures:
Have to understand the threat environment.  [At this point, John showed
a Cartesian-style graph for plotting threats on two axes:  directed vs.
random, benign vs. lethal.]  Denial of service is classified as
relatively benign:  The measure for determining lethality is
accountability.  In a DoS, you don't lose anything (much, at least not
long-term).  By contrast, an escalation of privilege is on the
benign/lethal border.

IDSes are focussed on random threats, not directed ones, despite the
fact that directed threats are much more serious.  Threats classifiable
as both lethal and directed (the most dire) include information theft
and reputation loss.  

Numbers of exploits tend to rise exponentially over time against any
fixed target (e.g., a software system), even though exposure by
contrast grows only linearly.  (For every exposure, there are many
possible exploits.)  

IDSes can't keep up with the rate of traffic going across the wire.
|DSes produce ridiculous amounts of false positives.  They're incapable
of judging the validity of an attack.  They are vulnerable to
data-obfuscation techniques (polymorphise the code, stream reassembly,
unicode exploits).  Consequently, the reality of their operation is
notification _after_ the fact, endless false alarms, and the reported 
origin address of genuine attacks are almost never valid -- only those
of false alarms.  The process is exhausting to the sysadmin, who spends 
his time sifting through logs and responding to alerts.

Three categories of intrusion can be detected: information gathering,
DoS, escalation of privilege.  Latter is the one most keenly of
interest (having the greatest chance of being fatal).  IDS needs to
detect all escalations, as a minimal requirement.

John conducted a test of IDSes -- RealSecure from ISS, Dragon from
Enterasys, and others that had to be omitted after their producers
raised a fuss.  Generated test data using, at first, the "Stick"
codebase, which turned out to be too buggy and unusable, and then "Snot"
(http://www.sec33.com/sniph/).  Snot is a utility designed using the 
Snort IDS's pattern-matching set, and grinds out network traffic
designed to trigger Snort and similar IDS software.  John used Snot to
generate 60 seconds of "attack" data, running through 986 Snort rules
against a Class C IP netblock, running on a stock FreeBSD 4.4 machine --
80,400 attack signatures sent.  Results:  RealSecure went deaf and dumb
for 17 minutes, and turned out to have logged 28,400 events, and claimed
to have "missed" (tried to catch, but dropped) 7,219 events.  Slowing
down the attack did _not_ result in 100% detection, but only reached
maybe 40,000.  

The concept of tracking state of network connections as a way to catch
attack probes is not necessarily useful:  Is tracking SYN flood "state" 
useful?  Is there state to track from a probe that installs a backdoor
without returning anything?  How about a probe that does "rm -rf /"?
More fundamentally, looking at inbound patterns is the wrong side of the
problem:  The monitoring software should look at the resources at risk,
instead.  Maybe in a future test, we'll connect "snot" with nmap or amap.
(Note that IDSes should have reported zero real attacks from "snot" on 
the wire.)  

Network security _is_ security.  Use a physical security model:  
Establish security, assess all exposures, eliminate unnecessary 
exposures, put alarms on everything else.  (Banks spend more on safes
than on alarms.)  The earlier a problem is caught, the less expensive
the results.  You cannot protect what you don't understand.

Design of current IDSes -- detect intrusion, provide an alarm when
you've been attacked -- mean current examples are broken.  Future
ones must meet those criteria better.  

Premises:  

o  Reconnaissance is not an attack.  Information should be treated 
   as information, attacks as attacks.
o  Propose "scruffy thinking" shift for IDSes:  It's the actual 
   attack that's of concern, not the pattern.
o  Attacks happen at the _application_ layer; people don't attack OSes.
o  Every application, no matter how obfuscated, should produce a 
   one-to-one response to attacks.  (How do you measure attacks, as 
   opposed to anomalous junk on the wire?)  E.g., try to buffer-overflow
   a bunch of apps, note down what happens, write signature files based
   on observations.

 Summary:  Security should be based on _policy_.  (Know network, know
 assets, know exposures.)  Every network has commonalities (servers,
 apps, exposures).  Every network is unique, though.

 Attacks against non-existent, non-vulnerable services (e.g., honeypots)
 are b.s.  (Story of $16,000 PacBell bill for pager bills run up during 
 the first 18 minutes of one IDS's operation.)  Enforcing _network policy_
 is the most important consideration.  Not all servers should be patched
 (dependencies).  An attack does not equal an "attack".  

 Traditional IDSes do not work:  Today's IDS doesn't understand the
 network, and no single IDS metaphor works for everything.  Think about
 security in the real world!  Thus:  IDSes as we know them are dead.
 New, more-active solutions will emerge.  Outsourcing network security
 should go away:  Security is a business problem.  Security is about
 policy.  Security gurus, unfortunately, understand only security holes,
 not the network:  "You can't run that; it's insecure."  Traditional IT
 (i.e., sysadmins) will take back security when companies grab the clue
 stick.

---




Announcements on the whiteboard:

Linuxcare, seeking usability/user interface person
Contact: Christopher Mann
r3cgm at linuxcare.com

DOSSIER documentation series:
http://www.ptf.com/dossier

Incyte Genomics, job opportunities
Sun Cluster Admin
Veritas: Volume Manager Cluster for (ASM?)
Contact: bl at incyte.com

-- 
Cheers,     Founding member of the Hyphenation Society, a grassroots-based, 
Rick Moen   not-for-profit, locally-owned-and-operated, cooperatively-managed,
rick at linuxmafia.com     modern-American-English-usage-improvement association.