Update November 24: New EU directive to feature cloud ‘bridge’. The Binding Safe Processor Rules (BSPR) will ask cloud service providers to prove their security and agree to become legally liable for any data offences.
In my humble opinion there is strange misconception regarding cloud security. For sure cloud security is one of the main trends for 2011 a trend, likely destined to be confirmed during 2012 in parallel with the growing diffusion of cloud based services, nevertheless, I cannot help but notice that when talking about cloud security, the attention is focused solely on attacks towards cloud resources. Although this is an important side of the problem, it is not the only.
If you were on a cybercrook’s shoes eager to spread havoc on the Internet (unfortunately this hobby seems to be very common recent times), would you choose static discrete
resources weapons to carry on your attacks or rather would you prefer dynamic, continuous, always-on and practically unlimited resources to reach your malicious goals?
An unlimited cyberwarfare ready to fire at simple click of your fingers? The answer seems pretty obvious!
Swap your perspective, move on the other side of the cloud, and you will discover that Security from the cloud is a multidimensional issue, which embraces legal and technological aspects: not only for cloud service providers but also for cloud service subscribers eager to move there platforms, infrastructures and applications.
In fact, if a cloud service provider must grant the needed security to all of its customers (but what does it means the adjective “needed” if there is not a related Service Level Agreement on the contract?) in terms of (logical) separation, analogously cloud service subscribers must also ensure that their applications do not offer welcomed doors to cybercrooks because of vulnerabilities due to weak patching or code flaws.
In this scenario in which way the two parties are responsible each other? Simply said, could a cloud service provider be charged in case an attacker is able to illegitimately enter the cloud and carry on attack exploiting infrastructure vulnerabilities and leveraging resources of the other cloud service subscribers? Or also could an organization be charged in case an attacker, exploiting an application vulnerability, is capable to (once again) illegitimately enter the cloud and use its resources to carry on malicious attacks, eventually leveraging (and compromising) also resources from other customers? And again, in this latter case, could a cloud service provider be somehow responsible since it did not perform enough controls or also he was not able to detect the malicious activity from its resources? And how should he behave in case of events such as seizures.
Unfortunately it looks like these answers are waiting for a resolutive answer from Cloud Service Providers. As far as I know there are no clauses covering this kind of events in cloud service contracts, creating a dangerous gap between technology and regulations: on the other hands several examples show that similar events are not so far from reality:
- On June 2, 2011, during the peak of the LulzSec saga, CloudFlare, the (network and cloud) service provider hosting the web server of the infamous hacking group, was targeted with DDoS attacks, after the group decided to publish information obtained from the Sony Pictures’ website;
- On June 22, 2011, FBI seized some servers from DigitalOne as Ryan Cleary, a 19-year-old suspected of involvement in LulzSec, was arrested. In this circumstance several popular, legitimate websites including Pinboard, a bookmarking service, and Instapaper, a tool for saving web articles, were affected. Moreover the CEO of tje Company declared that, although interested in one of the company’s clients, F.B.I. took servers used by tens of clients;
- On August, the 29th 2011, an Italian security penetration tester discovered some flaws in Google’s servers allowing malicious attackers to launch a distributed denial-of-service attack on a server of their choosing;
- On October, the 12nd 2011, Defence Contractor Raytheon revealed it was the victim of a spear phishing cloud-based attack;
- On October, the 28th 2011, Indian authorities seized computer equipment from a data center in Mumbai as part of an investigation into the Duqu malicious software that some security experts warned could be the next big cyber threat.
Is it a coincidence the fact that today TOR turned to Amazon’s EC2 cloud service to make it easier for volunteers to donate bandwidth to the anonymity network (and, according to Imperva, to make easier to create more places and better places to hide.)
I do believe that cloud security perspective will need to be moved on the other side of the cloud during 2012.
Advanced Persistent Threats are probably the most remarkable events for Information Security in 2011 since they are redefining the infosec landscape from both technology and market perspective.
I consider the recent shopping in the SIEM arena made by IBM and McAfee a sign of the times and a demonstration of this trend. This is not a coincidence: as a matter of fact the only way to stop an APT before it reaches its goal (the Organization data), is an accurate analysis and correlation of data collected by security devices. An APT attack deploys different stages with different tactics, different techniques and different timeframes, which moreover affect different portion of the infrastructure. As a consequence an holistic view and an holistic information management are needed in order to correlate pieces of information spread in different pieces of the networks and collected by different, somewhat heterogeneous and apparently unrelated, security devices.
Consider for instance the typical cycle of an attack carried on by an APT:
Of course the picture does not take into consideration the user, which is the greatest vulnerability (but unfortunately an user does not generate logs except in a verbal format not so easy to analyze for a SIEM). Moreover the model should be multiplied for the numbers of victims since it is “unlikely” that such a similar attack could be performed on a single user at a time.
At the end, however, it is clear that an APT affects different components of the information security infrastructure at different times with different threat vectors:
- Usually stage 1 of an APT attack involves a spear phishing E-mail containing appealing subject and argument, and a malicious payload in form of an attachment or a link. In both cases the Email AV or Antispam are impacted in the ingress stream (and should be supposed to detect the attack, am I naive if I suggest that a DNS lookup could have avoided attacks like this?). The impacted security device produce some logs (even if they are not straightforward to detect if the malicious E-mail has not been detected as a possible threat or also has been detected with a low confidence threshold). In this stage of the attack the time interval between the receipt of the e-mail and its reading can take from few minutes up to several hours.
- The following stage involves user interaction. Unfortunately there is no human firewall so far (it is something we are working on) but user education (a very rare gift). As a consequence the victim is lured to follow the malicious link or click on the malicious attachment. In the first scenario the user is directed to a compromised (or crafted) web site where he downloads and installs a malware (or also insert some credentials which are used to steal his identity for instance for a remote access login). In the second scenario the user clicks on the attached file that exploits a 0-day vulnerability to install a Remote Administration Tool. The interval between reading the malicious email and installing the RAT takes likely several seconds. In any case Endpoint Security Tools may help to avoid surfing to malicious site or, if leveraging behavioral analysis, to detect anomalous pattern from an application (a 0-day is always a 0-day and often they are released after making reasonably sure not to be detected by traditional AV). Hopefully In both cases some suspicious logs are generated by the endpoint.
- RAT Control is the following stage: after installation the malware uses the HTTP protocol to fetch commands from a remote C&C Server. Of course the malicious traffic is forged so that it may be hidden inside legitimate traffic. In any case the traffic pass through Firewalls and NIDS at the perimeter (matching allowed rules on the traffic). In this case both kind of devices should be supposed to produce related logs;
- Once in full control of the Attacker, the compromised machine is used as a hop for the attacker to reach other hosts (now he is inside) or also to sweep the internal network looking for the target data. In this case a NIDS/anomaly detector should be able to detect the attack, monitoring, for instance, the number of attempted authentications or wrong logins: that is the way in which Lockheed Martin prevented an attack perpetrated by mean of compromised RSA seeds, and also, during the infamous breach, RSA detected the attack using a technology of anomaly detection Netwitness, acquired by EMC, its parent company immediately after the event.
At this point should be clear that this lethal blend of threats is pushing the security firms to redefine their product strategies, since they face the double crucial challenge to dramatically improve not only their 0-day detection ability, but also to dramatically improve the capability to manage and correlate the data collected from their security solutions.
As far as 0-day detection ability is concerned, next-gen technologies will include processor assisted endpoint security or also a new class of network devices such as DNS Firewalls (thanks to @nientenomi for reporting the article).
As far data management and correlation are concerned, yes of course a SIEM is beautiful concept… until one needs to face the issue of correlation, which definitively mean that often SIEM projects become useless because of correlation patterns, which are too complex and not straightforward. This is the reason why the leading vendors are rushing to include an integrated SIEM technology in their product portfolio in order to provide an out-of-the-box correlation engine optimized for their products. The price to pay will probably be a segmentation and verticalization of SIEM Market in which lead vendors will have their own solution (not so optimized for competitor technologies) at the expense of generalist SIEM vendors.
On the other hand APT are alive and kicking, keep on targeting US Defense contractors (Raytheon is the latest) and are also learning to fly though the clouds. Moreover they are also well hidden considered that, according to the Security Intelligence Report Volume 11 issued by Microsoft, less than one per cent of exploits in the first half of 2011 were against zero-day vulnerabilities. The 1% makes the difference! And it is a big difference!
- Information, The Next Battlefield (paulsparrows.wordpress.com)
With the alleged Northrop Grumman Cyber-attack, we have experienced three attempts, unleashed in few days, to leverage the compromised RSA seeds in order to steal data from U.S. Contractors.
Albeit the above mentioned events are characterized by two evident points in common: all the targeted companies are U.S. Defense Contractors, and all of them use RSA tokens; there is a point that seems confusing, and it is the timeline with which the attacks were carried out and subsequently unleashed (we will see that the two are very different and somehow confusing).
Analyzing the timeline: the first attack unleashed was the one led against Martin Lockheed. According to the sources, remote access to internal resources was disabled late on Sunday, May, the 22nd, just immediately after the attack was detected. The first details, although the target was not immediately revealed, were given few days after, on May, the 26th.
The second cyber-attack targeted L-3 and was unleashed few days after , on May, the 31st. According to the information revealed, the event occurred at the beginning of April (more exactly on April, the 6th, that is more than a month and a half before) and described into an e-mail sent by an executive to the 5000 group’s employees belonging to the division affected. Nothing strange apparently: the late disclosure was unintended for the target company and probably a consequence of the huge echo raised after the Lockheed Martin affair which led an anonymous source to reveal details to Wired.
On June, the 2nd, an alleged third attempt to attack a U.S. Defense Contractor using compromised seeds was unleashed, this time against Northrop Grumman. According to the revealed timeline, this attack was held on May, the 26th, that is nearly in contemporary (4 days after) the event of Lockheed Martin.
So definitively although the three attacks were revealed nearly in contemporary, only two of them were (i.e. the ones towards Lockheed Martin and Northrop Grumman), while the second one, to L-3 happened a couple of weeks after the RSA Breach and almost one month and half before the others. This sounds not clear to me.
If I had been in the attackers’ shoes, I would have attacked all at once in order to prevent the spreading of the information, and definitively to avoid the possibility for the others victims to organize themselves, for instance immediately replacing the tokens as made by Raytheon immediately after the RSA Breach.
Let us suppose (as it seems clear) that the alleged theft of the seeds was only the first step of the “perfect plan” to attack the U.S. Defense contractors, let us also suppose that the attackers took some time to obtain the missing pieces of the puzzle, that is to link the tokens to users, and eventually to obtain the PINs, by mean of keylogger trojans or phishing e-mails as suggested by by Rick Moy, president of NSS Labs. Do you really think that they would have left one month and a half between one attack and the other? Honestly speaking I do not think so. Of course I can imagine that obtaining all the PINs or user to token mappings at once was simply impossible, for reasons of time because it is impossible that all the victims to a specific targeted phishing campaign could reply simultaneously, but also because a massive “vertical” campaign of phishing targeting all the U.S. Contractors (and aimed to obtain information about RSA tokens) would have probably raised too much attention, so that I do not exclude that the necessary information to perform the attack had to be obtained with “evasion” techniques.
Nevertheless, provided the above depicted scenario is real, even if it is unlikely the attackers could attack all the target simultaneously, one month and half between one wave and the other seems actually too much: I doubt they already knew that the information concerning the first alleged attack to L-3 would have been revealed only many days after, of course it is easy to predict that L-3 and the eventual other victims would not have been happy to do it immediately after; but if they really had the perfect plan, relying on a similar occurrence would have been a huge hazard capable to put at risk the entire operation.
I seriously fear the truth is different. Of course this is a mere personal speculation, but I am more and more considering the hypothesis that a first wave of attacks was really held at the beginning of April (more or less in contemporary with L-3), that is after a short interval the original breach, short enough to catch the most part of the victims unprepared, most of all in case of very big companies. The consequence could be that many others attacks have not been revealed or simply were not detected at all, since, as I said a couple of days ago:
I wonder if military contractors are really the only targets or if they have been the only ones capable to detect the attempts because of their strict security protocols and policies.
How to explain the alleged second wave of May? It might be that the attackers have tried once, since the result was successful (it is not clear if they were able to steal sensitive data, but for sure the information was not immediately revealed) so they decided to try a second and a third chance (and who knows how many others). Otherwise, it might be that after the first wave they decided to sell the seeds on the black market (probably at a lower price since at that point the seeds would have been considered a good of second choice), and this could explain the late attack to Lockheed Martin and Northrop Grumman (and who knows who else). In this case I am afraid we will see many other attacks, unless other potential targets (that so far refused to comment the events) will not decide to follow the example of Raytheon and replace the tokens.
I just finished reading this interesting article that seems to offer a different view for the attack at Lockheed Martin (actually, a lone voice which does not consider the attack related to compromised seeds), that here it is another bolt from the Blue. As a matter of fact Wired reports that a second Defense Contractor, L-3, has been targeted with penetration attacks leveraging information stolen from the infamous RSA Breach. This information was contained into an E-mail, dated April 6, sent to the 5000 group’s employees. t’s not clear from the e-mail whether the hackers were successful in their attack, or how L-3 determined SecurID was involved.
Protecting our network is a top priority and we have a robust set of protocols in place to ensure sensitive information is safeguarded. We have gotten to the bottom of the issue.
Is the only comment of the company.
This revelation occurs few days after the explosive news pertaining the attack led with similar methods to another Defense Contractor, Lockeed Martin.
Maybe all the defense contractors should have followed the wise example of Raytheon (another Defense Contractor) which declared to have taken immediate companywide actions in March when incident information was initially provided to RSA customers, to prevent a widespread disruption of their network.
If confirmed, this event is a further corroboration of the fact the real target of the Hackers was not RSA but their customers, event if at this point I wonder if military contractors are the only targets or if they have been the only ones capable to detect the attempts because of their strict security protocols and policies.
- Second Defense Contractor L-3 ‘Actively Targeted’ With RSA SecurID Hacks (wired.com)
- More Random Thoughts on the RSA Breach (paulsparrows.wordpress.com)
- Some Random Thoughts On RSA Breach (paulsparrows.wordpress.com)