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.
Integration plays a very important role for the success of an OSS/BSS project. Lots of parties(sw houses, neps, integrators) offer integration services however few of them are able to deliver within scope, on time or within budget. Knowing the importance of integration in an OSS/BSS project, customers began to be more selective.
In this post, I will mention some steps that needs to be considered by the Integrator , who aims to sell services to Telcos. OSS/BSS(especially OSS) services, are hard to sell as they require know-how, footprint in the target customer and enough money in budget to cope with long sales cycles.
Here are my proposed 10-steps to success;
Step 1: Offer multiple solution offerings.
Pre-pack your solution offerings based on;
- Best of breed products
- Implementation experience
- Local existence
- Best practices expertise (TMForum, ITIL, TOGAF)
This will improve your flexibility.
Step 2: Add consultancy in your integration project
You cannot sell OSS/BSS consultancy alone! Add consultancy in several phases of the integration project delivery cycle to feed your consultancy. Good consultants will also improve customer trust.
Step 3: Run POCs
Run POCs and finance them from your presales budget. You may limit the scope to decrease costs however, customer should never be involved in these calculations. POC’s are effective strategy to;
- develop long term relationships
- sneak inside
- getting rid of the RFP
- fit for purpose (technical, cultural, financial)
Step 4: Train your customer
OSS/BSS is too complex that it cannot be understood by the senior executives. Talk in their language!
OSS/BSS should be positioned strategically. Train the customer and create awareness on different levels;
- Strategic/Revenue focused (time and dollar)
- Technology focused (tools and processes)
Define your metrics!
Step 5: Invest in Knowledge Management
The goal is to reduce the engagement cycle by reuse.
Create an RFP KB should include:
- Solution description
- Pricing !!!
- Lessons learned
Cross-business knowledge share should be improved. Business critical data and know-how that resides on other lines of businesses should be available for re-use. Share your data!
Step 6: Score your Vendors
Maintain Vendor Scoring based on;
- Financial figure
- Way of working (flexibility)
- Local existence (country list)
- Promising Strategy
Step 7: Score your Customers
Maintain Customer Scoring based on;
- Should we invest in them?
- Are they interested?
- Short term, long term strategies.
- Previous interactions.
- Way of working
Step 8: Score your Product Catalog
Maintain Product Scoring based on;
- Integration costs
- Vendor’s score
- Feature set (by domains)
- Typical implementation period
Product Scoring should be done both for 3PP and company owned products.
Step 9: Follow New Trends
- Expand to IT! (Exp. Datacenter management)
- Expand to CEM!
- Watch the consolidations(Fix-mobile, NW-IT)
Step 10: Marketing
Your role as an Integrator should be marketed. For this purpose, you can;
- Run a separate web site just focusing on integration.
- Issue TM Forum business cases.
- Hire globally known consultants.
- Create micro-blogs.
- Create public communities.
As the name implies, common data model or CIM, is a business (and technical) model of entities that are used during a telecommunication operator’s activities. As the businesses and the operational functions become complex, integrations between tools that are handling those also become complex. Telecommunications, probably the most complex business among the others has been suffering this since it’s beginnings.
In Telco, there are hundreds of entities that can be involved in a business process. And most of the time, these entities are managed by different OSS or BSS components. In order for the process to flow, two or more entities should be shared as information carriers.
The multi-vendor structure of the Telco sector introduces problems in here. The OSS/BSS vendors use entities that are conceptually same but technically different. A customer entity has a customerName attribute in one tool, the same attribute is called “cName” in the other tool. Following the same example, the first tool holds a customer type attribute in Integer type, while the other holds the same in a String type. Obviously, there should be some conversions between these two systems.
To put the understanding of these entities to a common ground, common data model studies have been around since the beginning of the sector. The aim is to simplify the inter-tool integrations. The last concrete effort on hand is the TMForum Shared Information Data Model (SID).
A common understanding requires, abstraction and abstraction means the loss of the details. We can see the loss of the details in the attributes level in the SID model for example. SID, tries to avoid common attribute names rather it tries to spread them to atomic entities. This approach makes the model involve lots of new entities.
TMForum says, SID is an informational model , not a data model , so it rather should be customized to be aligned with the organization. This alignment is done via class extensions or attribute additions. (which different vendors may decide to implement separately)
When I am designing(and developing) a brand new OSS tool, I can use this common model for sure. If the tool I will communicate in the business process uses the same entities(not customized ones), they can communicate (slightly) seamless. But is this the case? Look at the off-the-shelf tools around the Telco business. None of them implements a common information model. Some vendors offering multiple tools in the OSS domain, however implement their own propriety models to improve integration between their components but these are propriety.
Look at the big OSS vendors. Most of these vendors are not interested in this common world. They don’t have OSS/J adapters natively supported for example. They rely on small partners to provide and sell the adapters separately.
Common information model, will dramatically reduce the system integration costs which are not welcomed by these vendors. And this CIM thing will kill an argument like “Buy also TT from us, not from another vendor. Because our TT has seamless integration with our PM tool which we cannot guarantee with the other tool”.
In today’s environment, If I wrote that CIM based brand new tool, I still need to write an adapter that will do the necessary conversions and mappings on the “legacy” tool’s side. (The conversions and mappings can be implemented on the bus if I use an ESB). Even in SID-SID communications, if one side has done some “custom” things such as addition of new classes, the other side should be aligned to that change on the adapter or bus level.
In any case you will write adapters, you will do mappings, you will add validation rules. There will always be some integration effort and if you are not living in the ideal “all SID” world, your additional efforts to aligning to a CIM (SID etc.) will multiply the costs and risks.