Blog Date: 8/30/2013
Author: Ray Coulombe
SNMP ... today, this could mean â€œSecurity - Not My Protocolâ€ for all the use weâ€™re getting out of it. What SMP officially stands for is Simple Network Management Protocol. You may have seen it on a configuration screen for an IP camera or other security device and wondered what it was used for. It really is a pretty useful protocol, and itâ€™s time we did something with it.
SNMP is based on a model consisting of a manager, an agent, a database of management information, managed objects and the network protocol. The manager provides the interface between the human network manager and the management system. The agent provides the interface between the manager and the physical device(s) being managed. The information to be accessed is stored in a specified format in the device database, known as a MIB (Management Information Base), used by both the manager and the agent.
MIBâ€™s contain the parameters to be collected for reporting, captured for notifications, or configured by the corresponding management software. Basic commands are â€œgetsâ€ to retrieve desired information, â€œtrapsâ€ to trigger alarm or condition notifications, and â€œsetsâ€ for configuration and control. There are three common revision levels, or versions, of SNMP - v1, v2c, and v3. Each succeeding version provided more functionality and, importantly, more security. Version 2c uses log in information known as Community Read and Write strings, analogous to passwords and requiring change from default values. Information, including configuration commands, are sent in the clear. Version 3 provides for far better security and privacy through authentication (using MD5 or SHA hash) and DES or AES encryption. This becomes particularly important if the managed device has been configured to allow system variables to be remotely set. Imagine another avenue for a hacker to gain control IP camera settings.
While there are a number of standard MIBâ€™s that have been established though the RFC process, these deal primarily with network functions and protocols. Companies may develop their own MIBâ€™s, usually after obtaining an enterprise number form the IETF. In our industry, there are tens or hundreds of vendors, each with their own unique set of MIBâ€™s and only discoverable by software packages that have been configured to look for them. Predictably, their usage is sparse.
So whatâ€™s an industry to do? Enter the Standards Committee of the Security Industry Association (SIA). This committee has just recently approved an effort to develop an industry set of standard MIBâ€™s. What this means is that vendors from across the industry will get together to decide those conditions which merit monitoring, capturing, or configuring. What kinds of conditions? They could include such things as loss of video, intensity of video compression, excessively high access card retries, over-current, under voltage, hard disk drive utilization, excessive temperature, loss of pressure, etc. By having a solid set of conditions for which MIBâ€™s are defined, it is far more likely that be third part monitoring software will supervise the network and attached security devices. Such software may have the ability to discover devices, identify linkages between them, name devices, examine their status and history, provision IP addresses and reconfigure them.
Link to Complete Article as it appeared in Security Technology Executive Magazine