My friend, I’m going to give you a hint.  If your firewall is “high risk” and your actual business applications are “low risk” - you might be doing it wrong.

1. DNS + Karma = Boom! Enuf said. Also, hear Pete Linstrom squeal.
2. Fun essay on "blocking" and risk. Is it our job to stop'em from using Facebook?
3. MS Exploitability Index. Smart ... or misguidedly focused on "vulnerability release" (and not creation)
4. Chip-n-PIN, a PCI killer? I don't think so!
5. Mike R revisits "good enough security" - read it, then review your IR plans (...for you will be 0wned)
6. Very fun RSA survey here; data leakage beats malware again, people still not report incidents (to whom???)
7. More and more and more people point at idiocies of academic security research... Read the whole w00t 08 thread here. Weep. Laugh.
8. Neosploit has a bad quarter... breaks support "contracts" ... shuts down? Ah, the economy :-)
9. Awesome stuff from  Richard Bejtlich: CAER.
10. "The Network Firewall is a Consensual Hallucination" :-)
11. More GRC-ball-kicking: here, here ("IT-GRC "vendors" are not IT-GRC vendors") - both are pretty insightful for GRC-lovers and GRC-haters)
12. More SIEM-ball-kicking: here ("underwhelming","ridiculous", "missing the point"), here ("dead ...unless","cripple")
13. Fun DLP portal launches.
14. Final word (?) on TerryChilds-gate here. "When management starts controlling the actions of admins, things start to fall apart." Huh? When management loses control of the business, it dies. Folks, IT vs IT security gap IS real. I never quite believed it, but this taught me a lesson. Some common security sense for a change (also here).

Enjoy.

Earlier this week in a joint press release, Microsoft and BearingPoint announced the new BearingPoint Enterprise Governance, Risk, and Compliance product offering. Ok... it will be a while before the more veteran enterprise GRC vendors start really losing sleep over this deal. But BearingPoint continues to be a top risk consulting firm, and Microsoft’s reach through the business user community will be an attractive benefit for compliance and risk professionals trying to get hundreds or thousands of staff members to contribute to the GRC program. There’s potential here for sure.

With software giants IBM, Oracle, SAP, and now Microsoft increasing their level of commitment in the enterprise GRC space, the 2-3 year market outlook continues to change. The risk and regulatory landscape is only going to get tougher to handle, and the more GRC programs can run seamlessly with existing business processes and applications, the better. The vendors focused solely on GRC still have the advantage for now, but market consolidation is on its way... and it’s coming maybe just a tiny bit faster than it was at the start of this week.

IT- GRC is just threat / vulnerability pairing when you consider external regulatory compliance pressures as the Threat Community.  If you think of it this way, you might be able to understand why I’m not keen on the value of GRC many current solutions.   As Shrdlu (or was it rybolov?) once said - GRC is (usually*) just a report. Turns out, it’s just a threat/vulnerability pairing report.

* “usually” is my addition.

“PCI Risk Management”

Now usually when I see a term like this, I can only imagine that such things are the byproduct of rapidly decaying brain cells.  In my mind I imagine there’s a conference room somewhere with some marketing types all hopped up on the vapors from industrial solvents spewing terms like “protectivity” or “advanced adaptive deep packet inspection” into the ether with all the acumen of an intoxicated long-horned bovine.

BUT

I thought about this, and it’s really not a bad idea - depending on how you define it.  Now I just couldn’t make the effort to read how the author used the term (I have a short pain threshold), but here’s my thoughts on what PCI Risk Management should be.  If we define Risk as the probable frequency and probable magnitude of future loss.

Then managing the risk inherent in PCI DSS compliance could mean:

1.)  The expected frequency of being out of compliance and how much that will cost us.

Because let’s face it - being in or out of PCI compliance is still a subjective judgment.  First, we have what our ever-qualified assessor says.  But in the case of an incident, it’s really someone else who has the final say in whether or not we were “compliant” at the time of incident.  So we can only know for certain if we’re in compliance after the fact - i.e. after there’s an incident.  So if we cannot really “know” if we’re compliant - we have a probability problem to solve!  Sounds like “risk” or “secure” doesn’t it?

So we could view the PCI as a threat community to deal with.  This gives us the first angle of what we could call PCIRM (this sort of term begs to be it’s own acronym, doesn’t it?) - the simple creation of a probability statement that says there is some belief that we could be found out of compliance - regardless of our efforts - and the calculation of what the impact would be to our organization (like defending frivolous 90 bajillion $ law suits from tiny financial institutions whose lawyers smell blood in the water).  Note that you may or may not want to add the value of the money and time spent on PCI compliance into your loss magnitude calculations.  It’s a sunk cost at that point.

However, there’s another side of the coin.  We can find out the risk of being out of compliance, but is there risk in being *in* compliance?  I think there is.  So our second aspect of PCI Risk Management might be:

2.)  The expected frequency of being in compliance and how much that will cost us.

An alternate view of how we could view the Payment Card Industry as a threat community would involve trying to figure out the probable frequency with which they will make onerous demands of our security budget, and the impact of those demands.

Now note that we would have a “secondary risk” to measure here.  I’m thinking that it’s not improbable that our PCI efforts may not be the most efficient use of or time and money.  So if we’re spending money on what PCI says we must, and neglecting areas of our IRM landscape that would actually reduce organizational risk more than those PCI efforts - then PCI compliance is costing us some real value by reducing our capability to manage real risk.  However,  and it’s quite a long tail event but, imagine that we’re unlucky and an incident happens!  This incident may become, in no small probability, the byproduct of PCI requirements.  Being diligent in risk management, we might want to study this likelihood, too.

So there you have it.  In both cases PCI Risk Management involves looking at the Payment Card Industry as a threat community, and determining the probable impact of having to deal with PCI DSS.

Now if you’ll excuse me, I have a white paper to write and I’m fresh out of acetone-based paint remover.

POST SCRIPT

I should make it clear that Risk Management should (and is) obviously being performed by those with PCI concerns.  PCI, if you will, is simply a sort of ISMS.  And the development of an ISMS can assist IT management with the process of developing metrics and analysis concerning the organizations capability to manage risk.  There’s nothing wrong with PCI in this regard.

But I figured I should make the effort to read what the author was advocating, and the document this “PCI Risk Management” term was drawn from was really a set of “best practices” for PCI and “best practices” above and beyond what PCI requires.  This is not risk management (and no, adding “risk assessment” - in quotes because the author is really referring to vulnerability management - to the list of best practices doesn’t make it risk management, either).  It is more witch-doctory.

• Implement a framework for risk assessment and mapping.
• Establish the responsibilities of risk managers with their areas of responsibility.
• Identify and define the risks to which the business is exposed and what constitutes a risk event or "near miss" so that incidents can be mapped to specific risks.
• Determine the threat level, and focus on those risks with the highest impact on performance.
• Establish levels of controls for processes commensurate with the perceived threat.
• Record and retain risk incident and near-miss information.
• Conduct periodic risk assessments to determine changes in the operations risk profile and assess control performance.

1. Another fun (and horrible) laptop theft story, to be shown to those naive souls who say "ah, just stolen for hardware"
2. Very fun dailydave thread on security future (sad, of course :-)) - here is an excerpt: "The complexity in security is not from any complexity in technology but the complexity in motivating people to truly care about security and act accordingly."
3. Prediction markets for security? Fun idea!
4. "Elevator pitch for explaining security risks to executives" by Lenny Zeltser @ SANS.
5. "In Praise of the Information Security Checklist."
6. A great WAF battle rages on (here and in many other places). PCI + June 30 + 6.6 + WAF = BOOM!
7. How do you protect from IT admins "going bad?" Separate data and infrastructure (easier said than done, for sure). Another related one is "Staff more dangerous than hackers."
8. Curious about PCI DSS compliance outside the US? Read this and this. Yes, it is pretty bad.
9. "Terminating an employee with privileged access" from SANS (scroll to bottom)
10. An interesting view on sad state of academic research in information security.
11. Useful reminder to many people pushing silly/useless security solutions: while you are doing this, your organization is losing 6% of revenue to fraud. Today. Every day. Fraud checklist is linked there as well.
12. Rich on "consumerization" of IT. Good stuff. You are ready for it, aren't you? More on this subject.
13. Obviously, you are reading Mike R mid-year grades for his predictions.  One that failed in the most spectacular fashion (grade "D") is also an instructive read.
14. Really good post on security vs risk management. Just read it.
15. Matasano launches a GRC solution :-)
16. After "security idiot" became "an official meme", it didn't take long for SecurityIdiot.com to launch with much fanfare! If you are still wondering how to misspell "SOX" go there... the mystery is answered.

See you next time!