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?
Tell me more
×
IT Security Stack Exchange is a question and answer site for
IT security professionals. It's 100% free, no registration required.
|
|
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. |
|||
|
|
|
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,
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 |
|||
|
|
