Archive for September, 2012

Network World has a good summary of the latest zero-day vulnerability in Internet Explorer. The article states that:

Exploiting the flaw allows hackers to execute code — in other words, plant malware on a machine — and opens Windows XP, Vista and Windows 7 to drive-by attacks that only require getting victims to visit a malicious or compromised website.

That means that:

  1. if you use an unpatched version of Internet Explorer (and at the time of this writing that would be all versions since the patch hasn’t been issued) and
  2. if you visit a web site designed to exploit this vulnerability …

you could end up with malware being downloaded to your system without your knowledge.

Clearly, when the patch comes out, you should apply it. Better still, turn on Windows Update and let it do the dirty work automatically.

In the meantime you can either choose to use another web browser such as Firefox or Chrome or just be really careful which web sites you visit.

In fact, you should do that last bit every day anyway. The problem, of course, with that is that you can’t really know for sure which sites might infect you but you can, however, lower the odds considerably by not visiting unknown or dodgy sites.

Just as in the physical world, sticking to the well traveled streets rather than veering off into the alleyways in bad neighborhoods and you will be safer but, crime can happen anywhere.

That advice holds for any web browser, for that matter too. So, while this particular attack won’t affect you if you use Firefox, there’s no guarantee that the next similar attack won’t. Still, at the end of the day, one argument for using Firefox rather than IE is NoScript plug-in that allows you to turn off Java and JavaScript by default for web sites you don’t know whether you should trust or not. That’s one of the best defenses against drive by attacks.

It can be a pain at times as some sites won’t render correctly without these features turned on but at least it puts you more in control of the situation and that can me the difference between dodging or taking a direct hit on the next drive-by browser attack.




With so many bad guys “out there” it’s often easy to overlook the threat on “this side of the firewall.” A recent study by the US Dept of Homeland Security and the Computer Emergency Response Team (CERT) at Carnegie Mellon University entitled “Insider Threat Study: Illicit Cyber Activity Involving Fraud in the U.S. Financial Services Sector” shines the spotlight on this important area that should be of concern for us all. One of the more interesting findings was that:

“Criminals who executed a ‘low and slow’ approach accomplished

more damage and escaped detection for longer.”

This shouldn’t be a surprise yet most organizations are ill prepared to deal with precisely this scenario. The reason? It’s easier to simply look for the big break-ins than it is for the slow siphoning of resources. It is the “death by a thousand cuts” where no single laceration is significant enough to trip the alarm but when taken together the damage is quite costly. Clearly, we have to expand our field of view if we are going to catch these stealthy attacks. The report goes on to say that:

“Transaction logs, database logs, and access logs were known to be used

in the ensuing incident response for only 20 percent of the cases.

Therein lies some of the problem. The records of illicit activity are probably there but they are lost in a sea of unrelated data. Picking the needle from a field of a thousand haystacks is a hard problem. In fact, it’s exactly the sort of problem that necessarily requires a computer with some pretty sophisticated detection algorithms to detect.

Sort of like the kind of problems that the field of business analytics and big data are focused on, right? So why not apply some of those same techniques to log analysis to find security incidents across a variety of platforms?

That’s exactly the sort of security intelligence that could help catch some of these attacks faster than the 32 month average that this study reports it takes on average. It won’t be easy but it begins with a change in thinking about the nature of the threat and this report seems a good starting point to inform that thinking.

For more information on some of what IBM is doing in this space take a look at:


I’m back from a few weeks in China where, unfortunately, it seems that this blog and many others are blocked. One of the hot topics there, and everywhere for that matter, is the subject of how to secure mobile devices — especially those that employees buy on their own and then expect to connect into the enterprise.

It’s a reasonable expectation, after all, as the line between work life and personal life continue to blur and the need to have instant access to corporate as well as personal email, calendar and contacts increases. If I need to travel over the weekend to be in Beijing by Monday then I also need to make sure that I don’t have a personal commitment with my family for some important event during that same interval. Having a single, portable device to let me juggle the demands of both the personal and professional realms makes the job a lot easier.

Not only is this a benefit for the employee but also for the business. According to one study this BYOD (Bring Your Own Device) trend resulting in an additional 20 hours of work per week as summarized below:

“Employees have become even more tethered to technology in their daily lives and report they work as many as 20 additional hours a week online due to their flexible schedules. One-third of mobile workers said they never fully disconnect from technology, even during family and personal time. In some ways BYOD is enabling and supporting employees, allowing them to work more hours – and these hours help the bottom line of their companies.”

But with this added flexibility come some really tough security issues that must be navigated. My colleague, Dave Merrill, has written a nice summary of some of the key differences that the mobile arena brings to the table, which I recommend taking a look at. Here’s a link to the posting on the IBM Institute for Advanced Security web site: