5

Suppose you are managing a team of Intrusion Detection Experts:

...what are the functional areas of the IDS knowledge space would you group your team into?

...how would you structure your team?

...how would you measure success?

3
  • How many IDS experts? The structure of two people is different from that of twenty.
    – user185
    Nov 23, 2010 at 22:28
  • This doesn't directly apply to me. I read the following question and wanted to know the functional hats that would need to be filled. security.stackexchange.com/questions/142/… Nov 23, 2010 at 22:32
  • Let's go with twenty; that way we can combine the roles as needed to a smaller team, and disgard the less important tasks. Nov 23, 2010 at 22:32

2 Answers 2

1

It depends on what you want to do with that team. Sourcefire has a few people working on the core engine, a few on the plugins, and a vulnerability research team writing rules--some of whom had no prior experience with intrusion detection; just exploit writing and reversing.

The setup I'm most familiar with, in contrast, uses a simple tiered system like many service providers. Junior analysts monitor in realtime and review logs; and the senior analysts take care of ambiguous cases and write rules which are useful locally.

1

Its rather hard to say without knowing a lot more about your setup. I'd probably start by dividing the IDS team into the functional areas covered,

  • Network IDS, including firewall monitoring
  • host based IDS - integrating with Change Management
  • technical audit
  • data-integrity - monitoring your application data for anomalies

A lot depends on the scope of your remit - so the technical audit might include code reviews and development standards as well as architecture reviews and penetration-testing.

Measuring success is a more tricky one - ideally there are no issues to find. OTOH telling your bean-counters each month that you didn't find anything wrong is not conducive to maintaining your budget. But from a strategic viewpoint you need to think about quantifying the impact of vulnerabilities in order to do proper risk / benefit analysis. Following on from this, you can then start forming ad-hoc teams to look at specific areas of risk on a project type basis.

IME, and depending on the sclae of your organisation, this works well with a small core group of security experts and co-opting members from other areas (e.g. DBAs, developers, network engineers, users) rather than trying to maintian a high level of expertise within the core team.

HTH

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .