[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ids
Subject:    Re: Manpower requirements for IDS deployments (was high-speed NIDS
From:       roy lo <roylo () sr2c ! com>
Date:       2002-07-17 20:51:00
[Download RAW message or body]

Your sysadmin is suppose to handle those things, at free of charge. ^_^ 
*grin*

write scripts to trigger events, security planing, network structure, 
write firewall rules..(etc) they all are part of sysadmin's job.

And write a script to extracting common and noticeable alarms from IDS 
sensors (logs) is just a common thing to do (and a common skill for 
sysadmins). The script should even have warming levels and it ought to 
decide if it important (send e-mail to admin's pager) or mild (send logs 
to admin's e-mail address).
Ofcourse the complex ones will be look over by the admin, him/herself.
Since the script is rather limited.

Those are thing *suppose* to be done by your sysadmin. but who knows? 
some of the sysadmin I know can't even write scripts. :P








Bennett Todd wrote:
> 2002-07-17-11:11:19 Mike Poor:
> 
>>Bennett Todd:
>>
>>>Given that, I've favoured two IDS deployment strategies (which
>>>can of course be implemented concurrently, they don't overlap),
>>>both of which are near-zero-manpower. I deploy IDS sensors with
>>>minimal signature tuning on the _inside_ of security perimeters,
>>>to generate alarms that set off pagers and open trouble tickets
>>>and whatnot.
>>
>>See this to me seems like a contradiction in terms:               
>>"near-zero-manpower" vs. "generate alarms that set off pagers and 
>>open trouble tickets and whatnot".                                
> 
> 
> Of course there's a contradiction there, actually fielding the
> alarms and addressing the incidents they reflect is a time burden,
> but that's one with a real, identifiable business benefit,
> ameliorating real identified threats to the business. The manpower
> costs that the business begrudges are "overhead" costs for which
> it's hard to identify a definite financial benefit.
> 
> 
>>Unless you have your "thousand robots" separating false positives 
>>from actual attack traffic, from attack traffic that actually     
>>impacts your systems... then Im not sure you can do that with     
>>Zero Man Power.                                                   
> 
> 
> Ahh, perhaps I failed to elaborate enough in my first explanation.
> When I want to get alarms for incidents, and I don't have the
> manpower to do the winnowing you very accurately describe, I deploy
> the IDS sensors inside the security perimeter. They are just inside
> the firewall plant. Their sniffing connection is arranged so they
> see only inbound traffic that is coming from the firewall plant, and
> outbound traffic directed at the firewall plant.
> 
> In the financial services industry, internet firewall plants are
> built with somewhat different cost/functionality/security tradeoffs
> than in some other settings; it's extraordinarily rare for an attack
> to make it through. This is the place where you see plants with _no_
> packet filtering/forwarding from the outside all the way through
> to the inside; packet filtering is used at multiple levels ---
> ingress and egress filtering on outermost and innermost screening
> routers, perhaps one or more stateful packet filtering firewalls as
> intermediate protective layers, and host packet filtering installed
> to reinforce bastion host hardening --- but to fully transit the
> plant you must pass through application-level proxies on hardened
> bastions. These bastions are chosen to offer only services for which
> the benefit/risk tradeoff is sufficiently favourable to provide a
> strong business justification, and wherever possible they implement
> validity checking and content scanning and so forth. So if there's
> an incoming attack, it's a major incident.
> 
> As for outbound traffic, some minimal tuning is required if a
> signature set includes some signatures that false-positive on
> legitimate traffic, but inasmuch as normal LAN traffic is not
> visible here, only a very restricted protocol set that's accepted
> by proxies in the bastion plant, even outbound traffic is pretty
> clean. If an alarm goes off here, it might not reflect a
> successfully completed attack, that firewall plant is partly there
> to prevent insiders from being able to mount such, but even if not,
> an attempt is a real incident that must be addressed.
> 
> There are two downsides to this interior placement. The first one in
> my mind is that located inside, an IDS won't be able to set off an
> alarm for an inbound attack until after it is complete and the
> firewall plant has been defeated. If this were not so rare as to be
> almost unheard-of, I'd be more concerned about this one. The other
> is of course that an IDS placed inside the firewall won't be
> gathering the valuable intelligence data about all the failed
> attempts; that's the role for which I use the other approach, IDS
> placed outside the firewall and used for intelligence gathering
> only.
> 
> Extracting alarms from external IDS sensors is expensive in
> manpower.
> 
> -Bennett



-- 
Roy Lo
Freelance Consultant
E-mail -  roylo@sr2c.com


Sun Certified Network Administrator (SCNA)
Sun Certified System Administrator (SCSA)
Cisco Certified Network Associate (CCNA)

[prev in list] [next in list] [prev in thread] [next in thread]