Cap My iPhone? Try This Instead, Mobile QoS Vendors

You have probably read about AT&T’s problems dealing with the perpetually clogged 3G networks in San Francisco and New York:
http://www.wired.com/epicenter/2009/12/iphone-caps/. To solve the problem, AT&T is considering one or all of the following: 1) convincing heavy iPhone users to stop using so much data (despite paying for unlimited plans), 2) introducing caps on data usage, 3) stop selling iPhones, 4) investing heavily in the network, 5) shut down streaming of live baseball games…

How can Qosmos Network Intelligence Technology help?

First, we can help mobile service assurance and QoS vendors. Not all solutions are not designed to support the huge throughputs generated by unlimited wireless data plans, which means that KPIs can no longer be computed on the entire traffic (as in the past). Instead, service assurance vendors must now select a panel of mobile users and analyze a representative sample to deduce QoS.  They can use Qosmos probes to analyze only a portion of the traffic on mobile users IDs (IMSIs) and create a panel of representative users. For video, they don’t need to keep any of the content, but just identify that it is video traffic. The filtered traffic is then forwarded at bandwidths which are manageable for existing solutions. This means that mobile QoS vendors benefit from instant scalability and can remain operational even if traffic throughputs increase dramatically. In this case, AT&T can better optimize subscriber experience and iPhone users are happier!

Second, we can help suppliers of network optimization solutions. They can use Qosmos ixEngine to get full visibility of iPhone traffic and applications. This allows them to work with AT&T to optimize networks, prioritize applications and make many iPhone users happier. Bandwidth could be allocated in a more fair manner, so that heavy users don’t hog all the resources, and AT&T can optimize their investments in 3G network equipment.

Conclusion: you don’t need to cap my iPhone!

Jerome

Could you have used Qosmos to detect the Operation Aurora cyber attack?

The short answer is: yes!

Let me explain.

A lot has been written about Operation Aurora, so as a reminder, let me just point you to the summary posted on Wikipedia: “Operation Aurora was a cyber attack, conducted in mid-December 2009 and originating in China, against Google and more than 20 other companies, including Adobe Systems, Juniper Networks, Rackspace, Yahoo, Symantec, Northrop Grumman and Dow Chemical”

How to protect sensitive assets against cyber threats

Governments and companies who have sensitive assets all use commercial off-the-shelf (COTS) solutions such as for anti-virus, anti-spyware, and intrusion detection systems. These systems provide effective protection against known vulnerabilities, but are not so good at protecting against new, unknown threats: so-called zero-day attacks. And Operation Aurora is a perfect illustration of this.

My experience shows that organizations who need advanced cyber protection must use two layers of defense:
-    The first layer is built by COTS products and its main purpose is to filter out known threats
-    The second layer of defense is a custom-built solution, developed by trusted cyber security teams to identify advanced, Aurora-type of threats. Qosmos technology plays a key role by feeding this solution with full visibility over network traffic.


How Qosmos technology could have been used to detect and mitigate Aurora

On the McAfee Labs Blog, I found a good description of the custom backdoor protocol used during Operation Aurora. Technically, the principle of the attack was simple: 1) a malware was installed on a PC by a Trojan exploiting a vulnerability in Internet Explorer, and 2) a covert connection was made on port 443 using a custom encrypted protocol, instead of the standard the HTTPS protocol encrypted with SSL.

In this case, a custom development based on Qosmos could have detected that abnormal traffic was flowing through port 443 and the system could have instructed to block the traffic, which would have stopped the attack.


Jerome