Home > Articles > Security > Network Security

Security and the Management Plane, Part 2

📄 Contents

  1. Management Plane Security Elements
  2. Network Device Security
  3. Conclusions
  4. References
  • Print
  • + Share This
Concluding his two-part series, network management specialist Stephen Morris discusses some of the more important and popular techniques for securing the management plane.
From the author of

Management Plane Security Elements

Figure 1 illustrates the managed network described in part 1 of this series.

Figure 1Figure 1 The main management plane elements.

As the network manager goes about her work, the following workflows can typically occur with respect to the management plane (MP):

  • Log in/log out.

  • Configure network managed objects (the process of provisioning).

  • Monitor the status of provisioned services: virtual connections, layer 2/3 VPNs, and so on.

  • Verify that the network is meeting contracted service-level agreements.

  • Perform what-if analysis. ("What happens if I reduce bandwidth on link X-Y?")

  • Upload/download new software/configuration to/from selected network devices.

  • Generate billing details for a corporate VPN user.

  • Verify that security details are correct across the network.

As with software systems in general, these workflows are usually facilitated by the network management system (NMS) via software wizards (similar to the wizards used for installing software). From here on in this article, we'll look at the world from the NMS point of view. In other words, we don't expect the network manager to directly communicate with any of the network devices—in effect, the NMS acts as a type of proxy. Figure 2 illustrates one possible security scheme in which the network manager uses a remote client PC and secure HTTP to interact with the NMS across the web.

Figure 2Figure 2 NMS in a dual role: web server and security proxy.

The NMS in Figure 2 is typically a powerful server hosting advanced FCAPS software. [1] [2] However, from the perspective of the network device, the NMS is just another user. This is why the router in Figure 2 has to authenticate the NMS, either autonomously or via the security server. Once security is being considered, nothing is ever simple! In like fashion, if a user attempts to connect to the same router—for example, by using Telnet—the user must also be authenticated. The network manager normally must explicitly configure the security infrastructure; this setup may include external servers and/or the network devices. Typically, the setup can involve the following steps:

  • Creating user accounts (sets of username/password pairs)

  • Assigning accounts to security profiles; for example, profile 1 allows only reads, profile 2 allows reads and limited writes, etc.

  • Assigning authentication and privacy protocols to profiles

  • Enabling the accounts for use

Some vendors provide very fine levels of granularity in the rights assigned to given users. In addition, vendors often provide default user sets that can be used to speed up network configuration. The SNMPv3 protocol provides a standard mechanism for limiting access to managed objects—this is called view-based access control. In many ways, network operators are spoiled for choice when selecting security schemes! This may account for why many networks are not properly secured.

  • + Share This
  • 🔖 Save To Your Account