RSA APT hack - blogger tells all

So an RSA employee released a blog post with some more details of the "Advanced Persistent Threat" attack that involved the theft of information related to SecurID. RSA should be praised for this, as I like many others, had been disappointed with them for less than responsible disclosure. Although this post does not provide details of what was stolen (maybe they don't know?) that would enable smaller organizations and individuals without direct contact with RSA to perform a risk assessment, it does at least provide opportunities for lessons learnt. It also raises questions on why a security company did not have appropriate controls to mitigate these risks.

"The number of enterprises hit by APTs grows by the month...  examples are in the press regularly, and some examples are [Arora attacks] and [HB Gary]"
Never a good sign when they start with: look it wasn't just us getting hacked. This was terrible for HB Gary and even worse when you release a deck a few days before stating how one of your flagship products is great for mitigating APT's or and a post titled "What we did to fight to APT's" written on February 18th 2011 (month before the attack was disclosed).
"These companies deploy any imaginable combination of state-of-the-art perimeter and end-point security controls, and use all imaginable combinations of security operations and security controls. Yet still the determined attackers find their way in. What does that tell you?"
Agreed that you can never get the risk to zero but without details on what mitigating controls RSA did have in place, there appears to be some basic security controls that have failed either in design or effectiveness.
"they then send that user a Spear Phishing email... The email was crafted well enough to trick one of the employees to retrieve it from their Junk mail folder, and open the attached excel file"
RSA really? So any training on email security including spear phishing? Was the false positive rate so bad in your email filtering service that such an email was put in junk mail for retrieval by the user, without further authorization, rather than being quarantined?

Lesson: you should be training users not to open emails from senders they do not recognize. Spear phishing training needs to be part of any user awareness program. Any email that triggers a junk rating, especially where it has an attachment, should be placed in quarantine for review.
"The spreadsheet contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (CVE-2011-0609)"

RSA really? Is there a good business reason why Joe from HR needs to have Flash? Is it necessary for his job or is it easier to roll it out to everyone rather than field the complaints for not being able to watch iPlayer? In fact did Joe need Internet access at all? Could he have a white list of allowed sites required for his job and a simple and automated way to apply for additional access with justification?

Lesson: basic advice many of us have been providing for years to small business and non techy Internet surfers: for things like browser's and browser extensions, really common software that has an attack surface you can drive a bus through such as Adobe Acrobat Reader and Flash, MS office; patching  is really good idea, using alternatives such as Open office, PDF creator, not flash and to eliminate them altogether is even better. Internet access to all sites should not be carte blanche for all, whitelist where you can and put effective approval processes in place to cut your attack surface significantly.
"Poison Ivy variant set in a reverse-connect mode that makes it more difficult to detect, as the PC reaches out to the command and control rather than the other way around."

RSA really? Now this is where the story gets really bad. Any IDS should be able to detect new outbound connections from desktops to addresses on the Internet. I have worked for organizations where Confika and plenty of other malware was detected in this way. Envision should have been configured to alert the security team of anything like this. A desktop firewall should have stopped outbound connections to anything other than authorized programs. 

Lesson: Configure a firewall and host based IDS on every end point, do not allow unlimited outbound connections, but rather whitelist a set of programs e.g. the browser. Everything else like AV should be updated via internal servers. Configure IDS on the Internet perimeter to specifically alert and ideally IPS to block suspicious outbound connections, even where they piggy back on a browser or other allowed programs.
"You can try building bigger and better radars, or, as someone I talked to said, you can try staring more closely at your existing radars"
Actually an attack, even if it is a zero day exploit being sent by email was caught by your existing radar, it just wasn't dealt with effectively. An endpoint connecting to an unknown address on the Internet, that is not a stealth fighter that is a 747 and your existing radar works perfectly
"Already we’re learning fast, and every organization hit by an APT is much more prepared against the next one... What we’re witnessing now are the early days. "
This really is not a new type of attack, in fact I would be surprised if RSA had not earned millions in for years scaring organizations into buying Envision for exactly this type of threat.
"by detecting what is happening early on, RSA was able to respond quickly and engage in immediate countermeasures"
RSA really? The key information left out is how quickly? Are we talking minutes, hours, days? He mentions other organizations taking "months" so more than a minute and less than 3 months? Doesn't Envision have real time alerts to your 24x7 monitoring team? No IPS to automatically block outbound Internet connections like this? No automated preventative action configured in Envision?

Lesson: Investing in SIEM software like Envision is pointless unless you spend the time to setup the alerts and have a robust and step by step procedure for your Security Operations Center (SOC) on what to do when an alert is detected. I wrote a bit about this in getting more ROI from your SIEM . Even better use an IPS and automate your response within acceptable false positives.
"They performed privilege escalation on non-administrative users in the targeted systems, and then moved on to gain access to key high value targets, which included process experts and IT and Non-IT specific server administrators."
RSA really? This provides some answer to the above question, the detection and response certainly was not immediate. Why do even administrators have permanent access to critical systems? Why is access not provided on an as needs basis with an incident or change ticket? Was Envision configured to monitor for administrator logins outside of these approved reasons for logging in? Finally the greatest irony, where was the two factor authentication to for administrative users? If this was in place at best the attacker is only able to capture a one time password with limited timeframe to use.

Lesson: More away from permanent privileged access to critical production systems. Establish a process for access to be enabled only with an approved change or support ticket. Configure monitoring for administrator logins outside without this rationale. Two factor authentication for administrator access even to internal systems should be mandatory.
"Then they went into the servers of interest, removed data and moved it to internal staging servers where the data was aggregated, compressed and encrypted for extraction.

The attacker then used FTP to transfer many password protected RAR files from the RSA file server to an outside staging server at an external, compromised machine at a hosting provider."

RSA really?
Data Loss Prevention (DLP) - What about securing the data not the infrastructure? Discover, educate, enforce and report? We know the information stolen was related to SecurID, surely this should have been indexed in your DLP tool and any outbound connection over the Internet blocked? Even if the files were encrypted and could not be read by a DLP tool, the ad-hoc transfer of a encrypted files from highly sensitive servers to internal staging servers and then external servers via FTP should have raised a flag in DLP to block and review.

Encryption in storage - Why was the SecurID information not encrypted? Even if the malware was able to exploit a zero day to get to the servers storing this information, finding a clear text version should have been next to impossible. Decryption keys should have been stored on a Hardware Security Module (HSM).

Lesson: It may be impossible to truly prevent malware getting to your endpoints in particular, so move your protections closer to what is really valuable by using tools like DLP and actually implementing them correctly.
Encryption should also be used to protect really sensitive data in storage.

RSA really?
Network segmentation - why can malware than infects an endpoint even reach the servers that hold information on SecurID? Don't tell me you had *shock* flat corporate network?

Lesson: Jericho failed for a good reason, don't believe the hype, firewalls are still useful security tools and getting better all the time with dynamic rules, coordinated systems linked to a central point and application layer analysis. Using them to segment your most valuable assets is a good idea.

RSA really?
Thin client endpoints - Malware on desktops using zero days is clearly a risk especially with business critical software like Flash installed, so how about a purely thin client infrastructure? It saves money, can provide better performance and provides better sandboxing capability for endpoints.

Lesson: Add improved security to your business case for thin or zero client endpoints that work anywhere

Summary and conclusions:

I admire RSA for writing this type of post providing at least a little bit more information on the attack but I reject their premise that this type of attack requires a "new defense doctrine". Good mitigations to this type of threat vector has existed for years and many organizations have them in place, clearly better than a premier security company.

Summary on the lessons learned from RSA getting hacked:
  • Email as a malware distribution mechanism is not dead. Dig out those user awareness presentations and add some training on spear phishing and trusting the junk filter a bit more
  • Internet access is a luxury not a default right. Do not provide it if it is not required for a clear business benefit. 
  • Consider white listing websites that need to be accessed based on the user role, being smart like rules that check referring URL to be Google can prevent the backlash and loss of productivity while significantly improving security 
  • Re-evaluate the business reason for software like Flash, Adobe reader, Office, browser extensions as part of the gold build for all desktops and laptops. Alternatives exist, users with a specific business reason can request it - cut your attack surface
  • Use IDS to detect and ideally IPS to prevent connections from endpoints to suspicious sites
  • Configure a desktop firewall and host based IDS to block any new outbound connections without approval
  • Monitor alerts from your IDS/IPS - have a team that is trained to react to these alerts with clear and rehearsed procedures
  • Implement two factor authentication for administrator access even to internal systems. Move away from permanent privileged access for critical systems and monitor for logins outside of approved changes and support tickets
  • Move your security controls closer to your most valuable data with tools, people and processes for DLP. Your monitoring strategy needs to consider encrypted files, either analysing a decrypted version or flagging any new encrypted transfers. Encrypting the data in storage to add further layer of protection even if is stolen is also a good idea
  • Network segmentation - create secure network zones even within your internal network for your crown jewels, control and monitor access to these
  • Think about thin or zero client endpoints
You may never reduce the risk of an "APT" to zero but you can certainly take a lot of measures to build defence in depth and mitigate the risks to an acceptable level without re-inventing the wheel. People maybe the weakest link but this hardly news and plenty can be done, perhaps some security companies should change to do as do rather than do as I say.

Like this post? Get updates via RSS or follow me on Twitter @rakkhis

Photo credits:  rickh710 Flikr

No comments:

Post a Comment


Written by