In our last blog post “Why you need NCCM as part of your Network Management Platform” I introduced the many reasons that growing networks should investigate and implement an NCCM solution. One of the reasons is that an NCCM system can help with automation in a key area which is related to network security as well as compliance and availability – Policy Checking.

So, in this post, I will be taking a deeper dive into Network Device Policy Checking which will (hopefully) shed some light onto what I believe is an underutilized component of NCCM.

The main goal of Policy Checking in general is to make sure that all network devices are adhering to pre-determined standards with regard to their configuration. These standards are typically put in place to address different but interrelated concerns. Broadly speaking these concerns are broken down into the following:

1. Device Authentication, Authorization and Accounting (AAA, ACL)
2. Specialized Regulatory Compliance Rules (PCI, FCAPS, SOX, HIPAA …)
3. Device Traffic Rules (QoS policies etc.)

Device Authentication, Authorization and Accounting (AAA)

AAA policies focus on access to devices - primarily by engineering staff- for the purposes of configuration, updating and so forth as well as how this access is authenticated, and tracked. Access to infrastructure devices are policed and controlled with the use of AAA TACACS+, RADIUS servers, and ACLs (Access Control Lists) so as to increase security access into device operating systems.

It is highly recommended to create security policies so that the configurations of security access can be policed for consistency and reported on if changed or vital elements of the configuration are missing.

Many organizations, including the very security conscious NSA, even publish guidelines for AAA policies they believe should be implemented.

They offer these guidelines for specific vendors such as Cisco and others which can be downloaded from their website http://www.nsa.gov these guidelines are useful to anyone that is interested in securing their network infrastructure, but become hard requirements if you need to interact in anyway with US government or military networks.

Some basic rules include:

1. Establishing a dedicated management network
2. Encrypt all traffic between the manager and the device
3. Establishing multiple levels or roles for administrators
4. Logging the devices activities

These rules, as well as many others, offer a first step toward maintain a secure infrastructure.

Specialized Regulatory Compliance Rules:

Many of these rules are similar to and overlap with the AAA rules mentioned above. However, these policies often have very specialized additional components designed for special restrictions due to regulatory laws, or certification requirements.

Some of the most common policies are designed to meet the requirements of devices that carry traffic with sensitive data like credit card numbers, or personal data like Social Security numbers or hospital patient records.

For example, according to PCI, public WAN link connections are considered untrusted public networks. A VPN is required to securely tunnel traffic between a store and the enterprise network. The Health Insurance Portability and Accountability Act (HIPAA) also provides guidelines around network segmentation (commonly implemented with VLAN’s) where traffic carrying sensitive patient data should be separated from “normal” traffic like Web and email.

If your company or organization has to adhere to these regulatory requirements, then it is imperative that such configuration policies are put in place and checked on a consistent basis to ensure compliance.

Device Traffic Rules:

These rule policies are generally concerned with the design of traffic flow and QoS policies. In large organizations and service providers (Telco’s, MSP’s, ISP’s) it is common to differentiate traffic based on pre-defined service types related to prioritization or other distinction.

Ensuring service design rules are being applied and policed is usually a manual process and therefore is susceptible to inaccuracies. Creating design policy rules provides greater control around the service offerings, i.e. QOS settings for Enhanced service offerings, or a complete End-2-End service type, and ensures compliancy with the service delivery SLAs (Service Level Agreements).

Summary:

Each of these rules and potentially others should be defined and policed on a continuous basis. Trying to accomplish this manually is very time consuming, inefficient, and fraught with potential errors (which can become really big problems).

The best way to keep up with these policy requirements is with an automated, electronic policy checking engine. These systems should be able to run on a schedule and detect whether the devices under its control are in or out of compliance. When a system is found to be out of compliance, then it should certainly have the ability to report this to a manager, and potentially even have the ability to auto-remediate the situation. Remediation may involve removing any known bad configurations or rolling back the configuration to a previously known “good” state.

Thanks to NMSaaS for the article.