Reviewing Your Security After Sony, RSA and IMF Breache

Perhaps it is worthwhile to review your security systems after Sony, RSA and IMF are all breached through either direct penetrations or phishing attacks.

The various publicised data and network breaches (or “hacks”) this year seem to fall into two camps. The first camp includes the more straightforward direct penetrations into networks and websites, such as the various Sony attacks. The second camp consists of targeted phishing attacks such as RSA and the IMF.

Let’s look at some examples from the first camp, the direct attacks on websites:
Sony stated that the PlayStation Network breach in April was an intrusion by “attackers exploited vulnerability in the server system which manages data”, so likely a direct external attack.
The Sony Pictures website was breached in June through SQL injection.
The Nintendo attack in June exposed a configuration file (httpd.conf), which usually resides in the internal file system, not in the webroot, so this may have been a directory traversal attack. This would nominally give read only access to all files on the web server with global read privileges, however some of those files could contain more information such as passwords to allow an attacker to get further in.

It is likely that these examples could have been prevented by these organisations having a regular penetration testing programme for their external networks and websites. Old and vulnerable versions of web servers such as Apache, SQL injection, and directory traversal should all be picked up in a penetration test. It’s surprising that Sony and Nintendo had these vulnerabilities, as it indicates that they haven’t had effective penetration testing carried out on these networks and websites. Given the cost of exposure of personal data and the obvious impact to the reputation of companies, especially those with big brands and dependent on Internet services, penetration testing is now common practice.

Penetration testing is a point-in-time test, and will not prevent breaches by itself. For example, it looks as if the Citibank breach in June (exposing 200,000 customers’ details) was a direct external attack, as Citibank said “during routine monitoring, we recently discovered unauthorized access to Citi’s Account Online”. It is very likely that Citibank get regular external penetration testing, so either they don’t do much with the issues found during the tests, or someone made a configuration change after a test that opened the door. Either way, it brings us on to the second camp of breaches, and how to limit them too.

Here are some examples from the second camp, using phishing:
The IMF hack in June was reportedly designed to install malicious software that would create a digital insider presence. This is likely to be attackers trying to get Trojans onto IMF desktops or laptops through spear phishing emails.
The Oak Ridge National Laboratory breach in April occurred through a phishing email exploiting an Internet Explorer vulnerability.
RSA stated “our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat”. This may have been a combination of phishing, external attacks and zero day exploits for specific systems in use at RSA.

Client-side penetration testing could help mitigate the risk of a successful breach in these cases, however a higher level information security management system (such as one based on ISO 27001) could have reduced the risk of a breach. The key is the risk assessment. The likelihood of these organisations being targeted in this way must be considered as very probable. With that in mind, should controls have been implemented that all but prevent phishing attacks, such as severely restricting Internet access or a browser virtual machine. Other related controls such as technical vulnerability management and staff training should be considered specifically around the threat of phishing in order to reduce the risk further. Technical vulnerability management can help in the case of a zero-day on a browser with no patch yet: if you know of the vulnerability and what it can do, and you know you’re running the browser and that you are likely to be a target, would it be worth the effort of switching to another browser for external websites until it’s fixed?

In summary, first look to see if your websites have had a penetration test. Then incorporate penetration testing into your website release schedule. Finally, review your risk assessment to determine if your information security policies and procedures come up to scratch with regards to these types of attack. Using examples of how other companies 


Find out how we can help with your cyber challenge

Please enter your contact details using the form below for a free, no obligation, quote and we will get back to you as soon as possible. Alternatively, you can email us directly at [email protected]