InfoSecPodcast.com

The class started tonight via their vLive platform. It looks like a very interesting course. I will post comments as I go.

https://www.sans.org/security-training/reverse-engineering-malware-malware-analysis-tools-techniques-54-mid

–Chris

I read an interesting analysis of the malware involved in the March RSA breach. The analysis was done by J. Oquendo and posted over at Infosec Island. After his analysis of the malware involved he believes that “its inconclusive but points more to RBN than APT.”. Read through his analysis and see what you think. Based on what information he has presented you may agree and he could be correct. I’m sure somebody knows definitively. Will we? Doubtful.

What I wanted to point out here is that you can’t have attribution with regards to an attack by only analyzing the tool used, no matter how through the analysis. We all know IP’s can be changed, compromised, rented out….so relying on that wont work. Code can be borrowed, stolen, reversed so that isn’t conclusive either. This especially true if we are talking about Nation State sponsored cyber attacks. The tool is only part of the bigger picture. Attribution requires taking a step back and looking at that this bigger picture.  Who received the email? What is their role at the company? Where did the adversary get their email address? What tools did they use once inside? What order did they use the tools? What time of day, week, month did the carry out the attack? How did they exfil the data? What did they do with the data once exfiltrated? These are just examples of data not directly tied to the code in the malware that needs to be analyzed. Threat actors have patterns that they follow just a criminals have M.O.’s. However these cannot be relied upon completely. Misdirection is your friend when you don’t want to be named.  A lot of data needs to be analyzed before you are in the position to claim attribution. I would argue that few organizations have the expertise and experience to do so and fewer still could say conclusively, outside of Defense and Intel circles.

Also remember that not all advanced intrusion are APT just as not all APT intrusions are advanced. What helps constitute the Advanced in APT is their ability to pick the right tool for the job. They are not going to pull out their 0-days unless they have to, in my opinion anyway.

–Chris

[TAGS] APT, RSA [\TAGS]

–Chris

Congrats to the team at, NitroSecurity. They were acquired by McAfee according to this press release today: http://www.mcafee.com/us/about/mcafee-nitrosecurity.aspx

Nice job guys and girls. It’s good to see a successful exit.

–Chris

For those Splunk users out there the 2011 Splunk Users Conference will be August 15 – 17 in San Francisco. http://www.splunk.com/view/SP-CAAAFCW

I’ve been a big fan of Splunk for a number of years. Somtimes you just want to search your logs and create / modify the queries on the fly. Splunk gives you the flexibility to do that. A SIEM is a great log tool but it is not always the right tool for the job. Incident Response is one of those processes that I think Splunk is ideally suited.

–Chris

Technorati Tags: Splunk

From a mobile device in the enterprise standpoint RIM’s Blackberry devices are extremely popular. Also in the government and military circles it’s a very common platform. There is even a STIG (Security Technical Implementation Guide) published by DISA (Defense Information Systems Agency) to secure the Blackberry Enterprise Server. So why then is the experience so poor when sending or receiving S/MIME signed or encrypted emails? Probably because a decade after “The year of PKI”, secure email still remains a niche technology. Now from a personal device standpoint I totally understand that. But why is that still the case on the enterprise side?

There was an article I read many years ago that was called something like “Why Johnny can’t encrypt”. The gist of the article was that email encryption (and the underlying technologies like PKI) were so poorly implemented that the average user couldn’t use them or understand them. In my opinion that is as relevant today as it was a decade ago. There seems to be 2 schools of thought as to why this is. The first is that the implementation and resulting user experience of these technologies frankly sucks so nobody wants to use them. The second is that the masses are not asking for secure email so what gets implemented is core functionality that is just enough to say it works, depending on your definition of “works”. Call it what you will but I believe if it was easy to use then more people would use it, even if they don’t fully understand the concepts.

So how far have we come? Let’s take a look at Blackberry 5.0 infrastructure and handheld OS to see how they well they have implemented S/MIME. Contrary to what you may think after this article I am a huge Blackberry fan. I think when it comes to enterprise grade handheld devices and infrastructure (i.e. the BES) they have got it right for the most part. Let’s take a look at some of the issues that we have found during our Blackberry secure email evaluation.

NOTE: It’s been a while since I was working on this. If I am mistaken on any of these feel free to correct me.

Not enough of email is downloaded to the device to verify the certificate
Blackberry devices download something like the first 2K of an email. In most cases this is not enough to verify the status of the signing certificate for digitally signed emails. You have to open the message and do a “more” or “more all” to get enough of the email to verify the signature. I am not sure why the BES cant verify the status on the server and just send the results of the signature verification.

Forwarding / replying S/MIME emails silently drops any attachments
When you forward or reply to a digitally signed or encrypted email with an attachment there is a problem. The recipient will not receive the attachment and you will not see an error. The email just shows up with no attachment or errors. This is apparently due to the architecture that RIM uses, specifically the Attachment Service on the BES.

Inconsistent certificate status messages
If you receive a digitally signed email that cannot be verified for one reason or another the colored line that indicates status will be Red. However the exact same email digitally signed and encrypted will have a Yellow line. Why does signed and encrypted = Yellow and signed only = Red????

Stale Certificate status
Blackberry devices have significant issues checking certificate status properly. One of the main issues is that the device is apparently trying to check the status of all certificates in the chain, either via extensions in the certificates or CRL / OCSP servers specified in the configuration. This includes the Root certificate. The Root certificate does not publish a CRL on itself nor will anyone else. There is no certificate status when it comes to the root certificate. This causes Blackberry to show a Stale Status since it cannot obtain the status of the root certificate.

Handheld devices require additional software
The Blackberry devices require that the S/MIME support package be installed. This is accomplished through the Desktop Manager application. Basically you install the Desktop Manager on your workstation, connect your Blackberry to your workstation then install the software. Sounds simple enough and it is for a user. That model breaks down quickly when you are talking about an enterprise that has dozens or hundreds of these devices. Pushing this as an over the air update would make it much simpler.

User’s private keys need to be imported manually
To get the user’s private keys installed on the Blackberry device you must again connect to the Desktop Manager. As noted above this is something that a few users can handle but becomes a huge support burden as the number of devices grow. This is a hard one to solve given that you need to be careful when dealing with a user’s private key. You shouldn’t (in my opinion) give the users private keys to the Help Desk and let them install them on the users’ device. I may be a bit more cautious when it comes to this than most but non-repudiation goes out the window as you lose control of your private keys. Many organizations stand up a Microsoft CA as part of the domain infrastructure. A link from BES to the CA that generates a new signing key and recovers any encryption keys then pulls them down over the air might be an interesting solution.

One thing I haven’t looked at is how many encryption certificates the device can hold. When my current certificate expires I’ll get a new one. Will the handheld be able to store both so I can read encrypted email that was encrypted with either certificate?

What has your experience been like?

–Chris

Technorati Tags: Blackberry, S/MIME, PKI

Starting Monday July 11th I will be working with a newly formed group at RSA / EMC that is focused on APT and SMT. For 3 years I have been on the front lines of this fight as the IT Security Manager for MIT Lincoln Laboratory, a Federally Funded Research and Development Center. Constantly being in the cross-hairs of state sponsored cyber attackers has been quite a challenge but also an incredible learning opportunity. Those of us who regularly deal with true APT and state sponsored attacks definitely gain a new perception and appreciation for what motivated, experienced and funded attackers can do.

It was definitely a difficult decision to leave the Laboratory. Working at the Lab was the second most personally rewarding position I have held, the NSA being first on that list. I will miss the many talented co-workers and friends I’ve made there. Those who know me well know that I seldom stay anywhere more than 3 or 4 years. I enjoy new challenges too much to stay in one place. I am really excited about my new role.

And before you ask…no I am not giving you any details on the breach

–Chris

 
The RSA SecurID token has arguably been the defacto second factor authenticator for many years. Despite the recent breach at RSA I do not see many organizations moving to alternate vendors or other second factor technologies, like PKI / SmartCards or telephone based solutions. In the wake of the RSA breach most companies seem to be replacing tokens and hardening their SecurID & Authentication Manager infrastructures and reviewing relevant security processes. I have seen a couple organizations look to add additional authentication methods to supplement existing SecurID implementations for remote access, like requiring PKI certs in addition to SecurID for Remote Access. Obviously this capability is dependent on your Remote Access vendor. If you are staying with SecurID for your Remote Access authentication you should be taking a hard look at your access logs. Below are some searches that you may find useful if your logging environment can perform them. The ability to perform GeoIP lookups and calculate temporal data is required for some of the searches. Many of these searches will require you to baseline this activity in your environment to reduce the false positives.

• Top 20 Remote Access source IP addresses for the last 30 days
• Top 20 Remote Access users for the last 30 days
• Remote Access attempt from non-US IP address
• Remote Access attempts at “odd” hours
• Remote Access failures from multiple
• Remote Access attempts from one IP address for two or more usernames
• Remote Access attempts for one username from at least two different IP addresses in XX minutes
• Remote Access attempts for one username from at least two different countries in an X hour period
• Remote Access sessions of longer than usual duration
• SecurID authentication attempt involving Invalid / Revoked / Expired tokens
• SecurID authentication attempts involving one username and multiple token serial numbers
• SecurID authentication attempts involving one token serial number and multiple usernames
• SecurID “Right Token code, wrong PIN” messages

There are probably others that can be added to the list.  Your RSA sales rep can provide you with a copy of their Security best practices guide for Authentication Manager as well as their Log Monitoring Guidelines. The NSA’s Information Assurance Directorate has also published an unclassified advisory on securing your SecurID infrastructure. If you Google it you should be able to find a copy.

–Chris

For those so inclined The sixth annual APWG eCrime Researchers Summit call for papers is out, as part of eCrime ’11.

eCRS 2011 will bring together academic researchers, security practitioners, and law enforcement to discuss all aspects of electronic crime and ways to combat it, Topics of interests include (but are not limited to):

Papers need to be in the IEE format: Submissions should be in English, in PDF format with all fonts embedded, formatted using the the IEEE conference template, found here: http://www.ieee.org/publications_standards/publications/authors/authors_journals.html.

–Chris