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?

  • How many IDS experts? The structure of two people is different from that of twenty. – user185 Nov 23 '10 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/… – goodguys_activate Nov 23 '10 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. – goodguys_activate Nov 23 '10 at 22:32

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.

| improve this answer | |

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.


| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.