Grey bar Blue bar
Share this:

Thu, 12 Mar 2009

Attack Vector based Risk Management?

Interesting post by Michael Dahn at pcianswers.com discussed (again) the difference between compliance and security. Do you know the joke about the difference between a canary? Apparently, its one leg is the same. Well, according to the post, the difference between compliance and security is... there is no spoon. I'm sounding facetious, but the post is actually not bad. Read more…

But actually, there was another part of the post that caught my eye. Its the comments about 'Attack Vector based Risk Management' or 'AVRM'. Not much is said about this except:

This means simply that you cannot economically defend your home until you better understand the evolving threat landscape. For example, if you know that attackers are breaking into cars in your neighborhood and stealing the 8-track players then putting another lock on your front door will not solve the problem. You need to start parking your car in your garage or putting a better surveillance system outside your house. Sure you could build a fortress to keep all your systems inside but that’s not economically feasible (especially these days.)
And later:
Try to imagine a world where there are not QSAs making point-in-time assessments but an internal and ongoing process of review and maintenance. It is only then that you will realise the truth, which is to say that it’s not compliance you dislike but the attackers, and only by understanding their motivations and patterns can you better protect against them.
There's not much more on the topic (anywhere on the net), but it resonates quite a bit with our own thinking about 'Corporate Threat Modeling' (Slides on CTM from CSi NetSec 07). I'd be interested to see more on how this works...

/charl

Mon, 9 Feb 2009

Vanilla SQL Injection is oh-so-90's...wait...is it? (Jackin the K)

aka.. Someone put the hurtski on Kaspersky..

The Twitters (via XSSniper and others) and the Interwebs were ablaze with news on a SQL Injection vulnerability that was exploited on AV vendor Kaspersky's site. Detail of the attack can be found here.

It's interesting that SQL Injection (though as old as the proverbial hills) is still such a major issue. In fact, I have it on good authority that the bulk of PCI-related compromises are still as a result of SQL Injection...

In our own work, we see this all over the show.

Also interesting is the fact that the DB in use by Kaspersky is MySQL - so much for the "I don't use MSSQL, I have x database with magical pixie dust SQL Injection protection - what me worry?" argument...

Once again, security one-oh-one...if you aren't *effectively* validating user input, you're going to get bitten some time...

/nick

ED* From the shameless self promotion department:

haroon and Marco have just finished their chapters in an upcoming book dedicated to SQL Injection. We will post more details here when its available. (the book aims to give SQL Injection thorough coverage from OR 1=1 to some of the insanity demo'd at BlackHat last year..)

Thu, 18 Dec 2008

More Conn News - PCI Johannesburg

I got contacted the other day (via LinkedIn actually, which is a 1st for me) about a PCI conference some folks are trying to organize here in Johannesburg in January next year. I don't really know the people (or the conference) but it seems like something that's sorely needed here and maybe worth making a small investment in.

Here's where you can get the lowdown -  http://www.pci-portal.com/events/event-info/event/pci-johannesburg