Managed Security Monitoring Services vs In House Monitoring

[alvin at maggie.linux-consulting.com]

hi ya jeff

fun stuff !! ... thanx for your post ...

again, if we're using my dumb rules ... i run on the
following assumptions/requirements
	- i assume that the cracker will do a 'rm -rf /"
	of the hacked system and probably attack other 
	servers too either inside or others on the internet

	- i assume that the cracker can get in and hide
	themself temporarily within a couple of minutes
	of a successful exploit or stolen/simple passwd

	- i assume that 80% - 90% of the attacks/false
	positives will be internally generated "errors"

	- i assume all errors are real .. and try to eliminate
	any and all "false positives"  -- no time to chase
	"false positives"

	- for the next 5-10% will be successful script kiddie
	"testing/auditing your servers" ... 
	once they are in .. what damage can they do ??
		- have had a few script kiddie get in
		but there was nothing they could do in terms
		of additional damages

	- i will plead "why me" to dedicated crackers/hackers that
	want in no matter what i do

	- issue is do you report that foo at ip w.x.y.z 
	tried or did attack your server... ( specifically port scanners ) 
	that too takes too much energy/effort and most law enforcement
	wont do anything either .. unless it was a govt servers

--- with those simple/silly assumptions ...

a.  Make a "security policy" for your hosts
    Make a "security policy" for your network and network topology

b.  i minimize damage by having backups ( live or hidden )
	- and minimize damage by having different networks

c.  minimize damage by assuming that all incoming connections
    are from insecure (home) networks 
	( [cr/h]acker follow them into their work pcs )
	- direct certain people only to certain networks
	and keep other servers away from that network

	- major network topology issue and what data is sensitive

d.  i minimize what other machines they can attack
	- each machine has different root passwd
	- no passwdless login ( must be typed )

	- if they used an exploit to get access, than we have
	a more serious "patch is too old process" to be fixed/changed

		-- this is where "brains" is needed ...
		what sequence and when to "thoroughly check patches"

e.  if the machine goes down... it will stay down till some looks at it

f.  how often do you want to run your ids checks ??
	- is it cron based ??
	- is it constantly runnning ??

	- if it's post proceessing the log files .. it's too late in my
	book .. you've already been [cr/h]acked ...

	- if you changed your monitoring rules to ignore
	certain activity to prevent the "false positives", tha
	they [h/cr]acker tooo can come in thru that ignored set of
	monitoring rules

i get tons of attacks on some of the servers i babysit
( but not a single false positive... they're in by the time
( i know about it ... and i can usually watch them try this and try that
( and i do not have the time to chase false positives ...

--- for servers... 
	i want to do a md5 across /home/httpd/* for webservers
	-- anytime anybody updates the website, it is to be
	followed by a "md5 udpate"

	-- similarly for mail servers, fw, loghosts, etc

--- for binaries... 
	- its md5'd and saved off 
	( tripwire and similar is too too big and too cumbersome

	- only useful if you think your binaries been trojaned
	( again too late if its been changed ...

--- for patches..
	- have a duplicate set of servers, apply the patches
	and test that everything still works
		== not a trivial task --
		== miss something and you wont hear the end of it
		==

-- ie... all that stuff is not "monitoring" yet....

	==
	== lots of stuff to do .. before "monitoring" is an issue
	==

just my rules... 

c ya
alvin


On Tue, 25 Feb 2003, Jeff with The Big Yellow Suit wrote:

> Alvin wrote:
> > On Tue, 25 Feb 2003, Jeff with The Big Yellow Suit wrote:
> >
> > by my definition,  an outsourced "security and ids" is already
> > a breach of security ... period ..
> 
> Not "security and IDS", just IDS.
> 
> I'm not considering outsourcing management or response handling.
> I'm not considering letting outsiders poke around on the internal
> network.  I don't want to give away the keys.
> 
> I do however want the logs monitored intelligently.  I do
> want this done 24 hours a day.  I do want intelligent people
> putting effort into identifying false positives.
> 
> > 	- unless that outfit carries e/o insurance for say
> > 	enough to cover damages and losses from a breach
> > 	from hackers and other un-permitted activities
> 
> I do not expect, and do not anticipate, that the IDS service
> will be able to _prevent_ intrusions.  The insurance issue
> isn't at question.  I expect them to be _better_ at detecting
> intrusions than any system which the in house staff can
> maintain and correctly interpret.
> 
> Nobody is ever going to be able to prevent all intrusions.
> The key is to detect and respond quickly.
> 
> >> The primary limitation in doing this is likeley to be brain
> >> cycles.  Quite simply the staff is stretched far too thinly,
> >
> > you really do not want "brain cycles" to do montioring ( very bad idea )
> >
> > -- everything should be automated ... not brain cycles ..
> 
> Correct, but at this point no IDS system that I've ever
> heard of can do enough recognition to eliminate the need
> for a skilled and knowledgable security person to analyze
> the copious false positives in a prompt manner.
> 
> Any more than four or five false positives in a day at
> this company and the staff is going to turn off the alarms
> and the IDS will fade into obscurity.
> 
> > but you really do want brain cycles to define the security policy  and
> > how people and machines get to do certain tasks
> 
> Exactly.  And no matter what it takes a shitload of brains and
> skill to manage and correctly interpret the results from an
> IDS system in a timely manner.  This is real expertise that
> just isn't available from the folks in house, or if it is
> available then it is going to take time from other things
> (such as keeping up with patches and automating painful tasks.)
> 
> > - a good hacker/cracker just needs a few seconds/minutes
> >   to do what they need ... ( but depends on what it is that
> >   we're trying to prevent too vs receover from said activities )
> 
> Which is exactly why you need more than one person to
> distinguish between false positives and real events, and
> why you need them to be doing this pretty much constantly
> 24x7.  That is already more than three headcount, and
> expensive headcount at that.  Which this company doesn't
> have, and which it is probably not going to get.
> 
> > fairly easy to install host ids and network ids
> > 	- lots of tools out there
> >
> > 	http://www.Linux-Sec.net/IDS
> > 	( similarly for auditing tools and monitoring tools )
> 
> I am doing an analysis of what it takes to set up and _maintain_
> the an internal IDS.  I've got an understanding and a set of
> directions to head.  That's not the part that I really need
> help with.
> 
> An IDS infrastructure is much easier to install than it is
> to feed, bath, and groom.  Lots of signatures to keep up
> with.  Lots of false positives to go through.  Lots of
> rapid response.  Doable, but it still requires lots of
> brain cycles that are possibly better applied elsewhere.
> 
> > counterpane carries e/o for encryption technology etc
> > and not sure if they also have the same for ids type of security
> 
> These days Counterpane is primarily an IDS outsourcing
> company.  They give you a box.  You drop the box in your
> site.  You point logs and such to the box.  The box does
> data reduction and preliminary analysis.  From their
> it pipes positives to their NOC.  They sort through it.
> They call you if they find something.  They handle updating
> signatures on the box multiple times per week.
> 
> -jeff
> 
> 
>