There are 2 primary sets of configuration that must be dealt with when configuring the IDSM2.
1) The switch configuration. The portion of the switch configuration that involves the IDSM2 is:
a) configuring the vlan for the command and control port for the IDSM2
b) configuring the vlans being trunked on the IDSM2 monitoring ports
c) configuring either span or VACL capture to send packets to the IDSM2
d) configuring the time on the switch (byt default the IDSM2 will sync it's time to the switch, but the IDSM2 can also be configured to sync to an NTP server instead)
e) automatic configuration of VACLs by NAC (NetworkAccessController) - this is optional and would actually be configuration of the switch combing from a process on the IDSM2
a,b,c, and d can often be done by the network group. These configurations are often static and do not require day to day changes.
e is optional, and would actually be done directly from the IDSM2
2) The IDSM2 configuration. The IDSM2 configuration is pretty much the same as on standalone appliances. You configure severity actions etc... in the IDSM2 configuration.
The network team rarely ever needs to modify any of the configuration directly on the IDSM2.
Besides the configurations the only other things would be switch commands that control the card.
- Reset, power down etc.. - these are done rarely (resets can be done from the IDSM2 or the switch cli)
- session to the IDSM2 - usually only required for first initialization of the card, after initialization the user can ssh directly to the IDSM2 cli and not have to go through the switch cli (Note: sessioning to the IDSM2 requires a username and password configured directly on the IDSM2 unrelated to any usernames and passwords on the switch)
- Re-imaging of the IDSM2 in case of disaster recovery - standard upgrades are done directly in the IDSM2 cli, but in the case of disaster recovery the IDSM2 must be booted to a maintenance partition by a switch cli commmand - so disaster recovery requires access to the switch cli.
Given the separation of the day to day configuration changes in the switch and IDSM2 configurations many groups elect to simply only allow the network group to have access to the switch cli, and the security group only has access to the IDSM2 cli.
FOr initialization of the IDSM2 configuration and for setting up the switch configuration specific to the IDSM2 the 2 teams simply work together for a day or two to get it all up and running.
Once the IDSM2 is up and running, then it is very infrequent that the security team needs direct access to the switch.
The other alternative is to only allow the security team access to the IDSM2 cli, and then use tacacs+ on the switch to limit the commands available to the security team on the switch cli.
I believe that can use the authentication, and authorization capabilities built into TACACS+ to accomplish this. I have never done it, and am not sure how easy it would be to setup.
For more information on authorization by switch command you can refer to:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_8_1/confg_gd/authent.htm#1021706
If you do this, then the security team needs the authorization to do the items I mentioned above.
