Working With the Corporate Security Group

The group responsible for network management that provides the NNM tool to the user community rarely finds those users imposing special restraints on the NNM system. They manage the internal network and are trusted by the network managers, troubleshooters, and help desk staff alike. The configuration of the NNM system used to manage a DMZ is very likely to be heavily scrutinized by the security staff.

The security group can benefit greatly by using NNM to monitor the DMZ. What corporate network environment should be managed more closely? By setting thresholds on key metrics, out of the ordinary performance behavior can be spotted quickly. Is there a broadcast storm at the router interface on the untrusted network? Has the error rate gone up? Is utilization well above the norm? Has the connection gone down? Is that a newly discovered node on the DMZ? Why is it there? Why is the CPU utilization of the proxy server suddenly 100%. The inbound SMTP server just went down.

Any equipment located on the DMZ will normally have additional constraints placed on its configuration, administration, and usage. The NNM system administrators should don their UNIX administrator hats and pay special attention to locking down the operating system.

The security group will generally assume that the NNM system is insecure until proven otherwise. They will break out their auditing tools, load them on the system, and tell you what needs to be changed. They may even insist that a security auditing and monitoring daemon run on the NNM system continuously. Access to this NNM system will probably be limited to a few individual accounts only.

Sometimes the politics in the company might appear to give the security group outlandish powers of veto and control, but understand that security-minded professionals are paid to be paranoid. Perhaps the key to successfully working with a domineering security group is to reach a mutual understanding of each other’s goals and objectives.