Thursday, November 29, 2012

Great study on spear-phishing from TrendMicro

Trend Micro has published a great study about spear-phishing email. It’s available here.

Although I would also like to know the overall numbers (i.e. amount of samples that were used during the research, to ensure the findings are really meaningful), there is good data in the paper that can feed into a well established SecOps practice. Some interesting pieces:

“Monitoring revealed that 94% of targeted emails use malicious file attachments while the rest use alternative methods like installing malware by luring victims to click malicious links and to download malicious files and using webmail exploits”

“Spear-phishing emails can have attachments of varying file types. We found that the most commonly used and shared file types in organizations (e.g., .XLS, .PDF, .DOC, .DOCX, and .HWP) accounted for 70% of the total number of spear-phishing email attachments during our monitoring.”

I’ve been spending a lot of time looking at numbers that affect the ability to look for potential compromises. For example, how many email messages an organization usually receives (of course it varies a lot according to size/business)? How many of those have attachments? How many of those attachments could be considered potentially dangerous? Is this information useful to help on narrowing the focus of detection/investigation practices?

I believe our industry has spent a lot of time working on detection systems without necessarily leveraging evidence based guidance about what to look for, where to look for. Reports like this one from TrendMicro are really useful to change that and help organizations to maximize the return of their SecOps resources.


Wednesday, November 14, 2012

The grain of salt

As a non-native English speaker, I always like to learn new idiomatic expressions that give color to the language. One of my favorites is to tell someone to take some information “with a grain of salt”. According to Wikipedia,

The phrase comes from Pliny the Elder's Naturalis Historia, regarding the discovery of a recipe for an antidote to a poison.[2] In the antidote, one of the ingredients was a grain of salt. Threats involving the poison were thus to be taken "with a grain of salt," and therefore less seriously.

An alternative account says that the Roman general Pompey believed he could make himself immune to poison by ingesting small amounts of various poisons, and he took this treatment with a grain of salt to help him swallow the poison. In this version, the salt is not the antidote. It was taken merely to assist in swallowing the poison.

The Latin word salis means both "salt" and "wit," so that the Latin phrase "cum grano salis" could be translated as both "with a grain of salt" and "with a grain (small amount) of wit."

The phrase cum grano salis is not what Pliny wrote. It is constructed according to the grammar of modern European languages rather than Classical Latin. Pliny's actual words were addito salis grano.[3]

But why am I talking about this in a Information Security blog? Because I want to say that all security advice should be taken with a grain of salt!

When I’m reading security blogs and listening to security podcasts I’m always impressed how some of my colleagues present some advice as the ultimate truth. There are a lot of “MUSTs” (in fact, a lot of “MUST NOTs”), as a magical set of rules that will allow us to easily do everything we want in a secure manner. However, all of them forget about one of the most important pieces of solution design exercises: CONSTRAINTS.

Of course we don’t want to use FTP or TELNET. Yes, 4 digit only passwords is stupid. Oh, how come you still have Java installed?

It’s not because people are stupid (well…ok, sometimes). It’s because they have, in most cases, valid constraints to be considered when security is being assessed or designed. Sometimes the only software available in the market for a specific business process is that crappy screen scraper based on TELNET. Or that hardcoded password crap is provided by the vendor of a multi-million dollars medical device that you can’t just throw away because of a security vulnerability. We should always try to apply pressure and make people aware of how security unwise those things are, but let’s be honest, if we were in the place of an executive, would you really consider a huge change to your business because of things like that? No, you would tell your security team to “be creative” or, most probably, call one of  those big brand consultants to tell you what you want to hear.

So, let’s pick our battles. We’ll never be able to work under ideal conditions. We’ll have to deal with “stupid” things like FTP, Telnet, unpatched Windows boxes and unsupported software.  We should keep evangelizing the IT world that security should be built-in, but we have to be prepared to bolt-on.

Next time a security curmudgeon comes with his canned “you MUST NOT” advice, ask him back: “and what if I have to?”. That’s a good way to see who is just playing to the crowd and who deals with real world, full of constraints conditions.