Today, I’d like to talk a little bit about security and it’s implications on our OSS systems. As OSS are seen mostly “internal” to our organization, most of the time, an OSS system is not security hardened, before going into production. We open up the ports SNMP 161,162 in our firewalls(if any) from the devices to management systems, we open up http:80 or https:443 between our OSS systems for different kinds of API Access.
In the OSS/J article, I mentioned about different kinds of information that can be fetched from an OSS/J enabled platform. Think of an inventory system for example. If I have the correct credentials, I can have the whole network inventory from this system including the customer information. Or I can trigger a service activation within the service activation platform without notifying the order management platform, excluding the Billing system involvement.
As you can see, the access to OSS platforms and their APIs can have the risk to expose your intellectual assets to the outside world and also allows internal fraud to occur.
If a malware, running on an admin PC has some kind of access to these sensitive APIs, it can easily transfer this information to the Internet (to the bot manager) to be used in further attacks or information trading.
The communication between device and the EMS is also important. Most of the times, this communication is done within the management network which is also reused by administrator PC’s for telnet/shh to the devices. The only protection at the end devices side is the password protection. The passwords should be complex enough to have alphanumeric, special characters and numbers. The password selection process is usually done based of best practices for the telnet/ssh side, however this is not the case for SNMP. Most of the time we will face “easy to guess” SNMP community strings that can be cracked in a brute force attack. We also face SNMP SET enabled on devices where there is no reason for it, creating another serious vulnerability.
Another thing to consider is the management networks. In especially big organizations, management activities are outsourced to different 3PP entities. The admin PC’s in these entities VPN to the management network to set-up/manage end devices. Since these PC’s are not subject to the companies end user security policy rules, this could be a possible backdoor for bots or hackers to the internal information.
We should always keep in mind the security implications of changes in our OSS infrastructure. We should apply security policies for accessing these systems and keep scheduled security scans for new or possible vulnerabilities. We should protect our management networks, especially it is shared by multiple companies. The management networks should be logically segmented by Service Activation/Resource Provisioning tools. The Access logs should always be collected, and correlated in a central location and reviewed by security personnel.
The OSS security is becoming more important as we utilize more “open” interfaces for management and reporting. Since they are “open”, everybody including the hackers will know how to reach the information. As long as we apply the necessary security controls, we can continue enjoying the interoperability and flexibility that has been delivered by standard OSS interfaces.