It's Monday again, and it's absolutely brain-numbingly cold here in Chicago... but I wanted to get these thoughts down before they fell out of my brain to make room for new stuff.

  Last week I had the pleasure of meeting with a group of guys that are running the Information Security practice within one of the largest and most respected retailers to the "hip" crowd... these folks live sales volume and press... good or bad.  I think they've got some extremely unique challenges so I wanted to present the angle I proposed in case it's useful to anyone else.

  First off, they have a very small "security" team, mainly consistent of compliance activities and common "operational security" tasks such as identity provisioning, anti-virus, firewall, you get the picture.  They also have a relatively well-established QA team which is critical to the success of their online retail component - so the established value of that team is there.  This is unlike the value of the security team - which unfortunately doesn't have a good foot-hold... not for lack of trying from what I heard.  Their problem?  No one cares about security.  (Sound familiar yet?)

  To overcome some of these challenges we focused on what was important to the business from an IT perspective - Software Quality.  More specifically the quality of the online application(s) was important to this customer.  Having their eCommerce site(s) up, and available for business is top-priority.  Given that information we can quickly re-tool our approach and make *security* a component of the overall quality cycle.  I know, some of you security purists are probably mad at me right now, but this is the harsh reality of life in a downturn.  Why not though, use the business-critical areas to get the job done?  The Security guys know they need tighter security but maybe the business doesn't care so much - except to check the box of compliance (PCI-DSS) - so I think taking a modified approach is the only way to fly in cases like this.

  Making security a sub-component of overall software quality works like this.  Security, amongst other things, aims to keep a site/application "up and running" and resistant to hacking.  Now, hacking often-times causes Denial-of-Service conditions so there we have link #1 to quality and uptime.  The second link comes in a little more vague.  Hacking an application means loss of data, potentially - and that can lead to downtime and disrupt the consumer's ability to purchase or buy - basically data corruption.  I know these aren't ideal links, and you'll like the PCI "compliance" link even less I'm sure - but there you have it.

  Those 3 links into application quality may be the difference between *zero* security budget and getting *some* security budget.  Now, the question of TTH (from Jeremiah Grossman, Time-To-Hack) may come into play again... we have to ask ourselves if what we're doing makes any difference in the time that it takes to take the app down, and steal the data.  Maybe yes, maybe no right?  The main point here for these guys is to demonstrate due-dilligence for PCI comliance.  While this is a bit of a sad commentary on the way of the world and how much security *really* matters... at least they're doing something.

   Keep pushing guys, you're on the right track!