Far and away the top three problems facing wireless operators and Application Service Providers (ASPs) today are integration, integration and integration. Their worst fear is mucking up their service to customers in any way. How do you integrate new data services into a legacy system without compromising its stability and security? In this article I’m introducing a new solution that can prevent rogue application behaviour, such as uncontrolled SMS or MMS blasts or over-consumption of resources leading to an interruption in service.The Challenge to Mobile Operators and ASPs
To introduce this new solution, I am going to take a step back for one moment to briefly re-hash the environment operators work in and what they need to do to survive. Mobile operator ARPU (average revenue per user) is decreasing rapidly. Increased competition has prompted operators to bundle more attractive voice packages to both acquire new customers and retain their current customers. The holy grail that will save many mobile operators from completely going under is new mobile applications. So, I've stated the obvious.
Now for the technical side. In the past mobile operators have spent significant effort certifying new applications to ensure they would not distress the system. The result: high costs and long time to market. As mobile operators struggle with limited budgets to bring new applications into the network, they intend to streamline the process to require as little certification effort as possible.
At the risk of stating the obvious again, the streamlined process poses certain risks to both the mobile operator and the ASP. The potential problems are introduced (intentionally or unintentionally) by the third party applications, which may overconsume resources or in other ways interfere with other applications hosted in the same environment. Since the testing and certification effort is now limited, the potential risk increases dramatically:
- Applications may flood the operator network with spam text- or picture-messages, breaking the first rule of customer service: from minor annoyances to major ones as the network can be brought down.
- Applications may over-consume resources on the server (e.g. CPU seconds) and prevent proper operation of other applications.
- Applications may attempt a brute-force attack on the network elements within reach, such as a database.
- Applications may call functions that are out of the scope of the regular application operation (e.g. Trojans sending sensitive data to a 3rd party).
In the past, local solutions such as throttling within messaging gateways or using Virtual Machines to shield applications from each other have been used to address certain risk areas. However, these local solutions create significant administration and configuration overhead without fully solving the problem.
The Solution: an Application Sandbox
Now that we have the issues clarified, meet the solution: the Application Sandbox. Given that mobile operators and ASPs are streamlining the certification process, how about building a "sandbox" that is attached to, but separate from, the legacy system in which engineers can "play" with the new wireless applications? Some of you may say "Java Sandboxes have existed for years" - and I agree. However the solution I'm going to describe extends the Java security features and is also available for other languages, such as PHP.
The overall idea is that the sandbox keeps each application in its own fenced realm, whilst monitoring all potential areas of concern. The Application Sandbox functionality is split into three major components:
- Resource Management
- Functionality Management
- Application Management
- "Wireless Apps, Page 1/2"
- "Wireless Apps, Page 2/2"
