Security Considerations: How to Ensure Data Authenticity and Integrity
Two terms are significant for metering and processing data records:
Data authenticity— Another term for the genuineness of data. In the case of metering accounting and performance records, this means that the data received at the collection server is original and was received exactly as it was sent by the meter's export process.
Data integrity— The data records are real and were not faked or modified.
Accounting and performance management strongly depend on the integrity of the collected data records. Accounting management provides the foundation for billing services and is directly related to revenue. Performance management supplies business-critical information for network monitoring and planning, which is indirectly related to revenue as well.
Therefore, accounting and performance management are potential subjects for fraud in the areas of device configuration and transmission of data records. If an unauthorized person has access to the meter, he can easily modify the meter configuration. Enterprises as well as service providers may suffer financially and lose reputation if intruders modify accounting and performance data records. Distorted accounting records can result in erroneous customer invoices and potentially legal implications. Even if the devices are protected against unauthorized access and the data transfer is encrypted, network elements and servers are targets for denial-of-service attacks. Although an attack does not modify the collected data records, it has an impact on the service quality, which in the end helps the attackers achieve their goals. The objective for each operator is to protect the accounting and performance management infrastructure from security threats.
Source Authentication
In contrast to network element discovery, in which new devices show up after a discovery run, new meters should not pop up by surprise. Instead, the operator needs to identify the right location in the network for placing meters and then enable the required functionality. From this perspective, new or unknown meters can be considered suspicious. The real authentication challenge relates to device authentication. Does the mediation device receive data records generated by the original device or a faked device? Digital signature solutions offer authentication of the sender.
Another security aspect is the connection mode between the source and destination: connection-oriented or connectionless. Connectionless sessions introduce potential risk, because no authentication is executed before data is transmitted. Connection-oriented sessions are established between the two parties before any data records are sent, so there is usually no authentication problem. Examples are the security add-ons of SNMPv3, which provide three security modes:
noAuthNoPriv— No security model is used besides the community string.
authNoPriv— Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms.
authPriv— Adds Data Encryption Standard (DES) 56-bit encryption in addition to authentication based on DES-56, and the Advanced Encryption Standard (AES) 128-bit encryption.
Another example of sender authentication is the Cisco IP SLA feature. Optionally, IP SLA uses a control message protocol to secure communication between two Cisco routers, executing IP SLA operations, by providing Message Digest 5 (MD5) authentication. This authentication requires MD5 key definitions on the source and target IP SLA routers.
Ensuring Data and Device Integrity
Assuming that the device identity has been authenticated, the next step is to inspect the content of the data records. Is the data genuine? Was it modified during the transmission from the device to the management station? To prepare for these questions, you should first secure the access to the device. Configure access control lists (ACL) that restrict management traffic to the NMS stations, but do not forget to include an entry for your backup servers at each network element! Instead of authenticating users at the device level, deploy a central AAA server and change administrative passwords regularly, at least if NOC staff leave your company. Disable all device services that you do not need, such as open ports. Then verify the results by running a network security scanner, which reports potential vulnerabilities that you should deal with immediately.
Next, secure the communication between a meter and a collection server. Unauthorized people or devices must not be able to read or modify data records. While read access (eavesdropping) does not have an immediate impact on the performance or billing applications, the information provided by data records can be an excellent source for an intruder to learn many details about the network infrastructure and prepare an attack against sensitive areas. Forgery of flow records is another concern. With the push model (such as NetFlow), someone might send spurious data records that contain negative values. Even though no instance between the meter and the application should expect negative values, and therefore process only positive integer fields, without a clear verification, this idea remains possible. Certainly, a hacker could send horribly oversized volume values in the data records (for example, a total volume that is above the available link bandwidth). This would prove that the ISP's billing system works incorrectly and therefore that the invoice is incorrect.
The best solution for transmission confidentiality is to use IPsec encryption between the meter and the collection server. Unfortunately, this can have a severe performance impact on the device. Here is an example: Activating NetFlow services introduces a performance impact at the device, which becomes even bigger if all exported flow records need to be encrypted. This might lead to situations in which the performance impact of metering is higher than the benefit. An alternative to data encryption is out-of-band communication, as provided by a DCN. Even when using a DCN, digital signatures should be applied to ensure that data was not modified on the way from the sender to the receiver.
A compromise between IPsec encryption and a separate network (DCN) would be to use a VPN for management traffic. The VPN concept is to transport data from different user groups over the same physical network infrastructure with a strict separation of the groups. In this case, a management VPN would be set up, consisting of all devices that should be managed.
In addition to data and device integrity, the privacy of users needs to be protected. Meters collect live user traffic, but the details of how individual customers use the network is part of their privacy and cannot be used for inspection, except for legal intercept circumstances. The proposed solution is to anonymize data records whenever possible. Except for billing systems, most applications can get as much value from anonymized data sets as from the original ones.
Denial-of-Service (DoS) Attacks
After securing device access and data transmission, the remaining task is protecting the collection infrastructure from attacks from inside and outside your network. A hacked AAA server cannot provide proper authentication and authorization and might open access to all devices in the network. A successful attack against the performance management server can seem like a well running network to the operator while the attacker invisibly modifies the infrastructure. A hacked billing system results in lost revenue. Forgery of data records for a security analysis application can trick the application by generating false alarms, with the result that security personnel consider the system untrustworthy and do not accept alarms, even when they are correct.
Dealing with these challenges is a general task for every network operator and is not limited to accounting and performance management. However, these two areas can help significantly increase network security. As described in Chapter 1, accounting and performance records can help identify traffic abnormalities, such as DoS attacks. Combining billing and security analysis is a good example of collecting network usage records once and leveraging it for multiple applications. Another approach to identifying attacks is implementing a firewall between the network and the central servers, such as the AAA server, collection server, mediation device, and application servers. An easy but often forgotten method is monitoring the violation of ACL statements with the Cisco accounting feature called IP Accounting for Access-List. Additionally, deploy intrusion detection servers or virus scanners, or even hire a hacker to identify vulnerabilities in the network.
