The period between November and December is particularly interesting for the Infosec community, since nearly all the main security vendors use to unveil their predictions for the next year, trying to anticipate the trends and the issues that will trouble the system administrators’ sleeps.
Exactly as I did last year, I analyzed the predictions of 7 vendors, choosing the ones that I consider particularly meaningful for the presence of the vendor in the market and for the coverage of their respective solution portfolio. In comparison with the last year, I was not able to find any prediction from Cisco (at least so far). However I was able to include the ones issued by Symantec, that were missing from my initial version. Hence the list of the vendors taken into consideration is the following:
Nearly all the analyzed vendors went through deep transformations during the past year, reflecting the changing trends in the market. Fortinet is considered a vendor focused on UTM Technologies, although it offers a wide portfolio of solutions ranging from endpoint to WAFs. After the acquisition of Astaro, Sophos is expanding its offering from the endpoints to the UTM segment. McAfee covers a wide area: historically focused on the endpoints, the long trail of acquisitions allows the company to be present in all the segments of the security market. Websense went through its historical flagship, the URL filtering, moving its security model to the endpoint. Symantec and Trend Micro have their foundation on the endpoints, but are more and more concentrated on securing the cloud. Kaspersky is still concentrated on the endpoints, although the company has been very active in the last year in the analysis of the cyberwar events, most of all in Middle East.
Yes, the rise of the malware on mobile platforms seems unstoppable, not only it reached unprecedented levels in 2012, but apparently it will be the protagonist even for 2013, at least for 5 vendors on 7. Indeed the vendors are 6 if one considers also the cross-platform malware which is equally a threat for mobile platforms. Furthermore one vendor (Fortinet), considers the role of mobile threats also as a threat vector for APTs in 2013.
Politically motivated attacks rank at number 2, even if with different connotations: Kaspersky and Websense mention explicitly state-sponsored attacks, while Symantec and Trend Micro include also attacks motivated by hacktivism in this category. It is not a coincidence that Kaspersky and Websense include Hacktivism into an explicit prediction.
It is also interesting to notice the ransomware at number 3 with just 3 preferences. Particularly interesting the indication of Sophos that speaks of “Irreversible” malware, since this class of threats is increasingly using encryption to make the compromised content unrecoverable.
The trend is even more visible from the distribution chart, that also emphasizes the role of the cloud, in the double shape of source and target of the cyber attacks.
Two vendors (McAfee and Trend Micro) include the proliferation of embedded systems (for instance Smart TV equipped with Android) as one of the main security issues for 2013. Honestly speaking I would have expected a major impact for this threat.
Last but not least, two vendors (Kaspersky and McAfee) believe that Targeted Attacks and Signed Malware will experience a major rise in 2013.
One of the most visionary information security predictions for 2012, was the one issued by Fortinet which defined the term Crime As A Service: “Crime as a Service (CaaS), [...] is just like Software as a Service (SaaS), but instead of offering legal and helpful services though the Internet, criminal syndicates are offering illegal and detrimental services, such as infecting large quantities of computers, sending spam and even launching direct denial of service (DDoS) attacks“. At first glance I marked this prediction as exaggerated but then I could not imagine that I should have witnessed a huge demonstration only few days after. Of course I am referring to the #OpMegaUpload when, immediately after the FBI takedown, the Anonymous redirected users towards a website when they could DDoS a large group of targets with a simple web click and most of all, without the need to install the Infamous LOIC.
Even if this has been, so far, the most noticeable example, is not the only one of a malicious tool used as a service for criminal (in this case one shot) campaigns. More in general, using very familiar terms (borrowed and adapted from Cloud Terminology) I believe the CaaS is assuming three shapes:
- Software As a (Crime) Service or Saa(C)S, in which the criminals offer malicious software (and the needed support) as a service. An example? The latest Zeus Variant dubbed Citadel, recently spotted by Brian Kerbs, which provides the purchaser with help desk and even a dedicated Social Network;
- Infrastructure As (Crime) Service or Iaa(C)S, in which the criminals offer malicious services (or infrastructures) to attack specified targets, services may include complex “traditional” infrastructures such as botnets, but also “innovative” large scale fashioned services such as DDoS or also sharper services such as password cracking. Try to surf the web and you will discover how easy it is to purchase such a criminal kind of services.
- Platform As a (Crime) Service or Paa(C)S: in which the criminals offer malicious platforms that users may adapt to fit their needs. An example? The brand new HOIC (High Orbit Ion Cannon) the new DDoS tool, evoluti0n of the infamous LOIC, that may be assimilated to a real malicious service platform that users may tailor to fits their needs thanks to the booster scripts. I believe we are not so far from criminal organizations selling customized booster scripts for every kind of need and, why not, offering support services as well.
Last but not least this services are self provisioned, and this is the reason why I used the term “Crime as a Self Service”: in every scenario, be the malicious service a Saa(C)S, Iaa(C)S or Paa(C)S, the user selects directly the target (or the victim), and that’s it!
Update May 12: TCP Split Handshake: Why Cisco ASA is not susceptible
On May, the 9th 2011, nearly in contemporary, Cisco Systems and Fortinet, the last two security vendors involved in the TCP Split Handshake affair, which had not yet released a fix for the encountered issue, released two separate posts indicating the result of a second session of tests performed with NSS Labs.
As you will probably know, Cisco Systems was not able to reproduce the issue on its labs and decided to perform a second joint session with NSS Labs on April, the 21st 2011 promising a definitive, resolutive post for the same day. I must confess I have been waiting for a while for the promised post, eager to know the outcome and the likely happy ending of the story. I still did not know I would have had to curb my hunger for knowledge for nearly 20 days (much more than initially expected), and (unfortunately) I would also have had to renounce to the happy ending as well (at least for Cisco).
Analyzing singularly (and in alphabetical order) the two vendors:
In an update to its initial post, dated May, the 9th 2001, Cisco stated that after a thorough investigation of the TCP Split Handshake issue raised by NSS Labs, the company has confirmed that the Cisco ASA firewall is not susceptible to this issue. In all test cases examined, the ASA operates as expected, providing protection in its default configuration against the Split-Handshake as defined in the original TCP Split Handshake paper. As a result, the Cisco PSIRT (Product Security Incident Response Team) closed this investigation on May 4th.
Moreover, during the two recent visits to NSS Labs, Cisco was presented with a number of scenarios, including new test cases that deviated from the original Split-Handshake scenario. The Cisco PSIRT collected traces and provided feedback to NSS Labs on all scenarios. In each case, Cisco demonstrated successful network protection through the default ASA configuration or the implementation of firewall policies that are fully supported, documented and used pervasively in enterprise deployments.
Similarly, in a nearly contemporary update to its initial post, Fortinet announced the release, on April the 20th 2011, of an update for their FortiGate platform to correctly handle and block the TCP split handshake attack technique. This fix was subsequently tested by NSS Labs, which recognized its effectiveness on permanently addressing the TCP split handshake issue with just the FortiGate firewall function enabled. The patch applies to FortiOS 4.0 MR2 and is available for download, for customers with a forticare contract, on the Company FortiCare support portal. An update to FortiOS 4.0 MR3 is scheduled in the near future.
All’s well that ends well?
Not really! NSS labs has released an update to their remediation guidance freely available, upon registration, at this link. If the document states that, after the update, the Fortinet platform is no more vulnerable to the TCP Split Handshake:
Update: On April 21, 2011 Fortinet provided NSS Labs FortiOS 4.0 MR2 Patch 6. NSS Labs has confirmed that with the patch applied, Fortinet provides protection against the TCP Split Handshake.
In case of Cisco the situation is not so univocally resolved:
Update on May 6: Over the past several weeks, NSS Labs has worked with Cisco, providing numerous configurations, PCAPs and live demonstrations of the TCP Split Handshake getting past a Cisco ASA. Our original results are unchanged, and ultimately Cisco did offer some mitigation steps. Unlike every other tested vendor, Cisco’s approach to defend against the TCP Split Handshake is based upon Access Control Lists (ACLs). An ACL centric approach is suboptimal since it requires firewall administrators to follow best practices as well as have a low-level understanding of how the TCP Split Handshake works in order to avoid an accidental “misconfiguration” that enables the attack. And there are some firewall configurations in which using an ACL will not be possible.
In practice, according to NSS Labs, it looks like (but this is my personal interpretation since the above phrase does not provide enough details), Cisco devices block the TCP Split Handshake if a proper Access Control List is in place. Unfortunately it is not specified if the ACL must permit the traffic (that is an allowed connection showing the TCP Split Handshake pattern is blocked) or must deny it (that is a blocked connection showing the TCP Split Handshake pattern is blocked as it should be). In any case the ACL-based approach is not considered optimal since it requires direct intervention (and configuration) from the Administrators (and a good knowledge of how TCP Split Handshake).
I must confess, if both assumptions are correct, that in any caseI do not completely agree with NSS Labs conclusions. Firstly in my ideal world firewall should be managed by skilled administrators knowing what they do and moreover which could be the impact of configuration changes on possible attack vectors (ok I did not know the occurrence of TCP Split Handshake before the NSS Labs affair, but nobody’s perfect!). Secondly if a critical resource should lack an ACL (or should be the unintended victim of an accidental “misconfiguration”), this could potentially be more dangerous than a “simple” TCP Split Handshake attack since in that case the target resource could be exposed to a pretty much wider range of threats…
Meanwhile I was too curious and I kindly asked to Cisco to provide more details… I will update the post as soon as I will have any…
The intention by UK-headquartered company Sophos to acquire Astaro, the privately-held security company co-headquartered in Karlsruhe, Germany and Wilmington, Massachusetts (USA) is simply the last effect of the process of vendor consolidation acting in the information security market. It is also the trigger for some random thoughts…
In the last two years a profound transformation of the market is in place, which has seen the birth (and subsequent growth) of several giants security vendors, which has been capable of gathering under their protective wings the different areas of information security.
The security model is rapidly converging toward a framework which tends to collect under a unified management function, the different domains of information security, which according to my personal end-to-end model, mat be summarized as follows: Endpoint Security, Network Security, Application Security, Identity & Access Management.
- Endpoint Security including the functions of Antivirus, Personal Firewall/Network Access Control, Host IPS, DLP, Encryption. This component of the model is rapidly converging toward a single concept of endpoint including alle the types of devices: server, desktop, laptop & mobile;
- Network & Contente Security including the functions of Firewall, IPS, Web and Email Protection;
- Application Security including areas of WEB/XML/Database Firewall and (why not) proactive code analysis;
- Compliance: including the functions of assessment e verification of devce and applications security posture;
- Identity & Access Management including the functions of authentication and secure data access;
- Management including the capability to manage from a single location, with an RBAC model, all the above quoted domains.
All the major players are moving quickly toward such a unified model, starting from their traditional battlefield: some vendors, such as McAfee and Symantec, initiallty moved from the endpoint domain which is their traditional strong point. Other vendors, such as Checkpoint, Fortinet, Cisco and Juniper moved from the network filling directly with their technology, or also by mean of dedicated acquisitions or tailored strategic alliances, all the domains of the model. A further third category is composed by the “generalist” vendors which were not initially focused on Information Security, but became focused by mean of specific acquisition. This is the case of HP, IBM and Microsoft (in rigorous alphabetical order) which come from a different technological culture but are trying to become key players by mean of strategic acquisitions.
It is clear that in similar complicated market the position and the role of the smaller, vertical, players is becoming harder and harder. They may “hope” to become prey of “bigger fishes” or just to make themselves acquisitions in order to reach the “critical mass” necessary to survive.
In this scenario should be viewed the acquisition of Astaro by Sophos: from a strategical perspective Sophos resides permanently among the leaders inside the Gartner Magic quadrant but two of three companions (Symantec and Mcafee, the third is Trend Micro) are rapidly expanding toward the other domains (meanwhile McAfee has been acquired by Intel). In any case all the competitors have a significant major size if compared with Sophos, which reflects in revenues, which in FY 2010 were respectively 6.05, 2.06 and 1.04 B$, pretty much bigger than Sophos, whose revenues in FY 2010 were approximately 260 M$, about one fourth of the smaller between the three above (Trend Micro which is, like Sophos, a privately-owned company).
In perspective the acquisition may be also more appealing and interesting for Astaro, which is considered one of the most visionary players in the UTM arena with a primary role in the European market. Its position with respect to the competition is also more complicated since the main competitors are firms such as Fortinet, Check Point and Sonicwall which all have much greater size (as an example Checkpoint revenues were about 1.13 B $ in FY 2010 which sound impressive if compared with the 56 M $ made by Astaro in the Same Fiscal Year).
In this scenario, the combined company aims to head for $500 million in 2012.
Last but not least both companies are based in Europe (respectively in England and Germany) and could rely on an US Headquarter in Massachusetts.
From a technological perspective, the two vendors are complementary, and the strategy of the acquisition is well summarized by the following phrase contained in the Acquisition FAQ:
Our strategy is to provide complete data and threat protection for IT, regardless of device type, user location, or network boundaries. Today, we [Sophos] offer solutions for endpoint security, data protection, and email and web security gateways. The combination of Sophos and Astaro can deliver a next generation set of endpoint and network security solutions to better meet growing customer needs […]. With the addition of Astaro’s network security, we will be the first provider to deliver truly coordinated threat protection, data protection and policy from any endpoint to any network boundary.
Sophos lacks of a network security solution in its portfolio, and the technology from Astaro could easily fill the gap. On the other hand, Astaro does not own an home-built antivirus technology for its products (so far it uses ClamAV and Avira engines to offer a double layer of protection), and the adoption of Sophos technologies (considered one of the best OEM Antivirus engine) could be ideal for its portfolio of UTM solutsions.
Moreover the two technologies fit well among themselves to build an end-to-end security model: as a matter of fact Information security is breaking the boundary between endpoint and network (as the threats already did). Being obliged to adapt themselves to the new blended threats, which often uses old traditional methods to exploit 0-day vulnerabilities on the Endpoint, some technologies like Intrusion prevention, DLP and Network Access Control, are typically cross among different elements of the infrastructure, and this explains the rush of several players (as Sophos did in this circumstance) to enrich their security portfolio with solutions capable of covering all the information Security Domains.
Just to have an idea, try to have a look to some acquisitions made by the main security players in the last years (sorry for the Italian comments). Meanwghile the other lonely dancers (that is the companies currently facing the market on their own), are advised…
- Sophos to acquire Astaro – some reactions (nakedsecurity.sophos.com)
- Sophos Acquires Internet Security Appliance Maker Astaro (techcrunch.com)
- Application Security: What’s Next? (paulsparrows.wordpress.com)
During these days I enjoyed speaking with many colleagues about the results of the tests and definitively, I must confess that firewalls were not the only entities unaware the TCP Split Handshake, as a matter of fact, none of the professionals I discussed with (of course including me the first time I read about it) were familiar with this method of establishing TCP connections.
Nevertheless the show must go on: professionals must study to stay up-to-date (and learn what TCP Split Handshake is), firewalls (if susceptible to attack) must be fixed in order to learn how TCP Split handshake is correctly handled.
After the surprising findings of the test vendor are running for cover, so I spent half an hour to check the state-of-the-art after some communications from NSS Labs (unfortunately I was not able to attend the webinar of today) and some rumors on the Infosec arena.
Among the manufacturers found susceptible to TCP Split handshake attack during the first round, Palo Alto Networks has released an update (4.0.2) to fix the TCP Split Handshake Evasion, after the fix the manufacturer was able to pass the TCP handshake attack test.
As far as Juniper Networks is concerned, today a communication sent by E-mail by NSS Labs has indicated that this vendor is working on a fix as well: a configuration setting which will be enabled by default for new customers.
But probably the most interesting piece of news is the fact that today some Cisco representatives today went to NSS Labs to participate in the vulnerability-assessment on site and sort out any issues directly. Cisco refused to accept the results of the tests since was not able to reproduce the issue on any tested platform (ASA, IOS Firewall, IPS Appliances). An updated blog post about the findings is expected later today. NSS Labs also expects to publish updated findings related to what firewalls it tested have completed remediation to protect against the TCP Split Handshake attack.
Just for fun…
(But not only!), I gave a look individually to other vendors not involved in the tests to see if they had analyzed the behavior of their technologies on this issue.
Some McAfee representatives indicated me that their Enterprise Firewall platform is not prone to TCP Split Handshake attack. I looked for some information and I found this post from the vendor. Would be interesting if the security manufacturer from Santa Clara could release a more detailed documentation (maybe they already released but I did not find it J).
Stonesoft issued a blog post with the result of the test performed individually on its Stonegate Devices with the same BreakingPoint method pointed out in the original document describing the attack. The finding is that with the only firewall function the security device is not vulnerable if the “strict mode” is enabled in the advanced properties of the node. In normal or loose mode the traffic is permitted (even if Stonesoft indicates that the firewall does not get spoofed, that is correctly recognizes the origin of the session). With the antivirus function enabled the firewall is not vulnerable in any mode.
Astaro except some tweets indicating that the technology is not vulnerable. Would be interesting, also in this case, if the vendor could release some detailed document on the necessary configurations to be implemented to avoid the spoof (or if they are enabled by default).
At this point I look forward to read the result of Cisco/NSS joint tests…
Update May 12: TCP Split Handshake: Why Cisco ASA is not susceptible
Update May 11: The Never Ending Story
Update April 21: Other Considerations on TCP Split Handshake
Few days ago, independent security research and testing NSS Labs, issued a comparative report among six network security technologies. The controversial results created a comprehensible turmoil among the security vendors involved in the tests, and more in general inside the infosec landscape. As a matter of fact it turned out that that five of the six tested platforms were susceptible to TCP Split handshake attack.
As a security professional, I am pretty much involved with at least five of the six tested technologies, consequently, although I never heard about TCP Split Handshake before, I must confess I was really curious to learn which was the only platform capable of surviving the test (the answer is indirectly provided by the vendor – Checkpoint – missing from the list contained on the remediation report subsequently released). Fortunately the scientific side of me took over and instead of making judgments and drawing conclusions about the results, I decided to learn more about TCP Split Handshake and the reasons why a security equipment may be vulnerable.
TCP Split Handshake in RFC 793
Since TCP is a connection-oriented protocol, every connection begins with a “handshake” defined in RFC 793. The handshake defines three well defined steps and for this reason it is called “TCP Three Way Handshake.”
The host initiating the connection, referred as the client, send to its peer, referred as the server, a synchronization packet, or SYN. In order to correctly identify the beginning (and the subsequent “state” of the session, the SYN packet contains an initial Sequence Number (ISN) which corresponds to a pseudo-random number.
Upon reception of the SYN packet, the server acknowledges that, and generates its own SYN. This “SYN/ACK” packet contains both the server’s Initial Sequence Number, as well as an acknowledgment number equal to the client’s Sequence Number plus 1. The fact that the server sends a single packet to initiate the connection on its side and to acknowledge the initial SYN sent from the client is known as piggy-backing and, as explained later, is the fundamental aspect in which TCP Split Handshake differs from Three Way Handshake.
At this point, in order to establish the session, the client concludes the Three Way Handshake and acknowledges the server’s SYN/ACK, sending a packet with its own ISN incremented by one, as well as its acknowledgement number equal to the server’s ISN plus 1.
As mentioned above, in the second phase of the handshake, the piggy-backing allows the server to use a single packet to send its own SYN and to acknowledge the SYN packet received from the client (ACK). However, let us assume that the server could decide to split the second phase of the handshake and send a dedicated ACK packet to acknowledge the client SYN, and a further dedicated packet with its own SYN. This is exactly what is stated at section 3.3, page 27, of RFC 793, which introduces an intriguing four-step process:
1) A --> B SYN my sequence number is X 2) A <-- B ACK your sequence number is X 3) A <-- B SYN my sequence number is Y 4) A --> B ACK your sequence number is Y
As a consequence, one might expect that an RFC 793 perfectly compliant client be capable to silently accept packet two, explicitly ACK packet 3, and hence complete the handshake more-or-less normally. At least in theory…
In reality, in such similar circumstances, NSS test have shown that some network security devices, with the sole firewall function enabled, get confused and behaves in a stateless manner. In few words, if even the client behaves as stated in the RFC, that is it is able to correctly establish the session even if it accepts separated ACK and SYN packets from the server, the network security device, on receiving the SYN from the server (packet 2), loses the awareness of the session and lets the traffic flow without enforcing any security control as if it belongs to an uncontrolled session (in theory an unknown or out-of-state session should be blocked). This means that a malicious payload conveyed through a TCP Split Handshake intiated session could go through the firewall and as a consequence, an attack scenario is quite straightforward: an attacker could think to use a server-side malicious script to establish the session by mean of a TCP Split Handshake and consequently install an executable on the client (a very fashionable event in the last days), for instance, by mean of an ActiveX Buffer Overflow on the target client browser.
The bad news is that this kind of attack is not new, and a similar attack scenario was reported for the first time approximately one year ago (with different behaviours reported for clients and security devices). The strange side of the story relies on the fact that this behaviour may not be considered a real vulnerability, but rather an occurrence covered by RFC not correctly implemented or not enabled on the default configuration by security vendors (please consider that RFC 793 also includes a further method for establishing a TCP connection dubbed “TCP Simultaneous Open” in which two TCP hosts simultaneously attempt to open a connection to each other via a SYN packet).
Last but not least…
For the record, as previously stated, NSS Labs released a remediation report containing the indications needed to mitigate (where necessary) the occurrence of the TCP Split Handshake for the affected technologies. Moreover two vendors (Cisco and Fortinet) added some indications as reported in the following:
- According to an official blog post, Cisco was not able to reproduce the issue occurred in NSS Labs Test and is further investigating the TCP Split Handshake attack on its devices.
- According to an official response in a blog post, Fortinet is not susceptible to TCP Split Handshake attack if IPS and Antivirus protections are enabled. A special IPS signature has been developed and a firmware update is scheduled for May in order to block TCP Split Handshake attack with only firewall enabled:
- For Juniper devices the line “set security flow tcp-session strict-syn-check” must be inserted into configuration (this option affects all the traffic, so it must be set with caution);
- Palo Alto is working to release an official fix between mid-April and early May;
- For Sonicwall devices, the option “Enforce Strict TCP Compliance” must be enabled (also in this case this option affects all the traffic and must be set with caution).
- Other Considerations On TCP Split Handshake (paulsparrows.wordpress.com)
In the wake of the infamous LizaMoon which has flooded an impressive number of databases all over the world with SQL Injection, infecting more than 1,500,000 URLs according to Google Search, the next frontier of Information Security to which security vendors are likely to move, is the branch of application security. The last vendor in order of time to make an acquisition (just a couple of days before LizaMoon was detected) was
Intel McAfee, which decided to enter the database security market (estimated more than $ 600 million in 2012) acquiring Sentrigo, a Santa Clara based company focused on database security, former member of the SIA Technology Partnership Program (McAfee Security Innovation Alliance) and currently linked to McAfee by an OEM partnerships.
The red Infosec Colossus of Santa Clara is just the latest player to enter this market, following the example of IBM, which offers a complete Application Security solution since 2009, thanks to the acquisitions (in rigorous chronological order) of DataPower (Web Application/XML Security), Ounce Labs (Code Analysis) and Guardium (Database Security). A set of solutions which form respectively the Websphere, Rational and InfoSphere Guardium Security Solutions.
McAfee and IBM are accompanied by Fortinet, another important security player which has been active in this field for some years. Fortinet has been investing in database and application security since 2006, and even if it lacks a code analysis solution, it offers a portfolio which extends up to the database (scanning and monitoring) level, through the acquisition of IP-Locks, and up to XML /Application Firewall, thanks to its offer of FortiWeb appliances.
As you may notice the three examples above are particularly meaningful of how the security is now converging towards application security. Although McAfee, Fortinet and IBM have very different backgrounds, they are converging to a comparable application security offer: McAfee approached the problem from the endpoint security, which is its historical strength, IBM from the content security, since its adventure in security has started from the acquisition of ISS, and finally Fortinet from the network security, well represented by its Fortigate appliances.
According to my personal model, the complete cycle of application security moves on four levels: training of developers is the first level and the necessary foundation upon which an application security project is built. Where the ability (and security awareness) of developers does not arrive, Vulnerability Assessment/Penetration Test (second level) may be enforced to check the level of security of the applications. If we move to a more “technological” plane there are two more levels: they consist respectively in Code Analysis (a preventive measure) and XML/Application/Database security solutions implemented with dedicated software or appliances (an infrastructural measure). Please consider that (an aspect which is not secondary) these kindw of solutions are also driven by increasingly stringent regulations, such as PCI-DSS, and emerging “De Facto” standards such as OWASP (Open Web Application Security Program).
If IBM is currently the only vendor to cover the three areas of application security (code analysis, XML/Web application security and database security), in addition to McAfee and Fortinet, there are other vendors at the door, looking at this market with great interest starting from Cisco Systems, provided with a great ability to execute, but currently focused primarily on its network-centric approach by mean of its ACE family of XML Firewalls, and HP, which, even if currently leaks an XML/WAF or Database Security solution) is approaching the world of Application Security starting from code analysis thanks to the acquisition of Fortify, considered by many observers the market leader in this field.
Actually, alongside these vendors there are more players which, even if more focused on network security, however, look carefully in this market by offering niche solutions, as is the case, for instance, with Checkpoint, which combines its traditional firewall modules (or software blades according to the current terminology) with Web Security functions specifically tailored for application threat, or also Citrix which approaches the problem from the Application Acceleration/Distribution perspective.
It is likely that the market value and the emotional drive of LizaMoon will soon bring furher earthquakes in this market. In my honest opinion, the next to fall will be two more important partners in the McAfee SIA focused in Application Security: Imperva (Web Application/XML Firewall) and VeraCode (Code Analysis) are well advised…
The title of this post recalls a science fiction novel, but actually summarizes well a couple of news concerning the Android, which bounced in these days. Even if they seem apparently disjoined I decided to insert them in the same post: there is a logical link which connects the commercial success of a platform and the attention it attracts by malicious, and this seems to be the destiny of Android, to which the market share reserves a bright future, which become much less bright if one considers the information security consequences.
Part 1: Smartphone Market Share
This seems to be the right time for predictions as far as the smartphone market is concerned, that is the reason why I really was enjoyed in comparing the projections of ABI Research (released today), with the ones released from IDC a couple of days ago. The results are summarized in the following tables. Even if they are targeted at different years in the near future (respectively 2016 for ABI Research and 2015 for IDC), comparing the two reports is interesting for imaging what the future of the smartphone Operating System will be.
|Operating System||2010||2016||Operating System||2011||2015|
|Windows Phone 7/Windows Mobile||0,60%||7,50%||Windows Phone 7/Windows Mobile||5,50%||20,90%|
Often the providers of market intelligence do not agree on anything, but in this case, if there is one thing that seems to have no doubt, is the scepter of the Android, which seems to be destined, for both reports, to rule the market with nearly one half of the total smartphones shipped after 2015. The data also confirm a stable position for RIM (around 13%-14%), while do not completely agree as far as Apple is concerned, for which ABI research estimates a market share of 19% in 2016 and IDC a market share of 15% in 2015. But were the data are surprisingly different, is on the Windows Phone Market Share. According to ABI Research, Windows Phone will reach the 7% of the market (which become 7.5 adding the market share of its predecessor Windows Mobile). Unfortunately I do not think that, according to Microsoft’s hopes, the number 7 which identifies the mobile operating system series, pertains to the market share in 2016. Last and (unfortunately) least? IDC is more optimistic and foresees a bright future for Redmond in the mobile arena, with its creature ranking immediately behind the Android with the 20% of the market. Will be very amusing to see (in 5 years if we will remember) who was right.
Last and (unfortunately) least, the poor Symbian, sacrificial victim of Nokia and Microsoft agreement, which, in 5 years will remain little more than a romantic remembrance for mobile lovers, while, surprisingly, ABI research foresees a surprising 10% market share for Samsung Bada in 2016.
Part 2: Mobile Malware Market Share
Of course I am an infosec guy so I wonder if also the mobile malware will follow the same trend. This consideration arises from an interesting article I found in the Fortinet blog. Of course data must be taken with caution, but I could not help noticing that when one switches from smartphone market share to mobile malware market share, the ranking positions are reversed: over 50% of mobile malware families detected by the security firm concern Symbian, approximately 15% are Java ME midlets, while the Android approximately suffers only of the 5% of the infections. Of course, as correctly stated on the article, this does not means that Symbian is the less secure. In my opinion the bigger percentage of mobile malware is a simple consequence of the fact that Symbian is still the Operating System with the greater spread. Of course malware writers deserve bigger attention to those platforms which offer the wider attack surface (that is the wider possibility to spread infections). And in this moment, Symbian is an attractive prey from this point of view. My sixth sense (and one half as we say in Italy) says that the Android will not take a long time in order to achieve also the unenviable first position also in the mobile malware market share, not only because it is spreading at an incredible speed, but also because it is becoming an enterprise platform (so the value of the data stored are much more attractive for Cyber Crooks.
As if on purpose, today Symantec discovered yet another malware for Android (Android.Walkinwat), which, at least for this time, tries to discipline users that download files illegally from unauthorized sites. Analogously to some of its noble malware predecessors (Geinimi, HongTouTou, Android.Pjapps), the malware is hidden inside a non-existent version of a true application (in this case Walk and Text) and downloaded from parallel markets from Asia and United States, but instead of stealing private data, simply floods of SMS the contacts.
Hey, just downloaded a pirated App off the Internet, Walk and Text for Android. I am stupid and cheap, it costed only 1 buck. Don’t steal like I did.
At the hand, after sending the SMS (affecting the user’s phone bill) it warns the user with the following message.
Unfortunately downloading malware from Asian parallel market is not new, and it is not a coincidence that the same report from Fortinet indicates that most mobile malware families are implemented by Russian or Chinese coders. This is undoubtely an increasing trend, and I am afraid that Chinese coders will soon shift their Cyber Espionage Operations to mobile devices…