Recently in infosec Category

In Brief: InfoSec Island may not post what you submit, but instead grab text from your blog (whether authorized or not). When I filed a complaint, their first response was to threaten to delete the post, and they ultimately deleted my account (and then posted the entire email exchange to pastebin). If you post to their site, then don't be surprised if you and your post are abused. If you complain, expect to be told that you don't matter. In the end, despite being urged to reach out to me, they have not taken steps to resolve the matter.

Strong Recommendation: If you're a writer, I cannot urge you strongly enough to avoid or flee InfoSec Island. If you're a reader, then I strongly recommend that you not use their site any further. A business that profits from and exists because of the free contributions from people like me do not deserve continued patronage when they clearly disrespect the people who provide the content upon which they base their business.

This post is derived from an interesting twitter exchange that I had with Branden Williams last week, and that resulted in his writing-up a couple related blog posts. You can read those posts here:
* "Myth Busting With Ben Tomhave"
* "Corporate Responsibility with Ben Tomhave"

The first issue was a simple question I asked about whether or not a QSA was still required if a business had an ISA. To my great surprise, Branden responded that not only was a QSA not required, but it never had been! His response even surprised a couple other QSAs. I'll go into this more below, but suffice to say that when you dig into each card brand's requirements, it turns out that self-certification is allowed with the signature of a company officer.

The second thread that came out of the original discussion revolved around the topics of businesses needing to become competent on PCI requirements (or, what's reasonable to expect), as well as a side-bar about whose risk is actually being managed. We'll discuss these topics as well.

Unless you've been living under a rock for the past month, you've undoubtedly heard about the STRATFOR hack by some anonymous or another. Who did it really isn't all that important to me, nor do I even care all that much about the purported, assumed, inferred, or otherwise construed ideology behind it. The important thing is to hold this up as a squalid, revolting example of IT mismanagement and outright legally indefensible negligence.

This is a follow-up to my last post ("3 Common Ways Security Fails People"). After posting it, someone on twitter quickly asked if I had any ideas for fixing these common problems. Well, of course I have ideas! :)

Soooo... rather than be one of those non-constructive criticizers of all things infosec, here are three solutions to the three problems:

"If you think a weakness can be turned into a strength, I hate to tell you this, but that's another weakness."
Deep Thoughts by Jack Handy

This post has been percolating for a few weeks now. Part of it was triggered as I read Taleb's The Black Swan, part of it was triggered by attending the ISSA International Conference a few weeks ago and hearing the same old quips, and part of it was triggered this morning by reading stories about yesterday's DARPA cybersecurity conference.

The challenge to this whole post is going to be keeping a coherent thread, so let me spell it out up-front: If "securing networks" is your goal, then I hate to tell you, but you've already failed. A strictly threat-centric approach to infosec is the failed approach we've been using for decades, and it's not going to solve any problems. The real problem is that we've lost sight of what is really important (assets!), and are not constructing our environments, defenses, etc., in a manner that is optimized toward protecting those things. More on this later.

A quick little semi-rant... I've reached the point where my tolerance has been exceeded. It's very simple, really.

There, I said it. No, seriously, if you listen to all the "risk" haters out there these days, you'd swear that the failings or limitations of a risk assessment or risk analysis methodology was equivalent to "proof" that risk management as a whole is faulty and a failure. Nothing could be farther from the truth.

Case-in-point: Many people, who don't have any training of or understanding about quantitative methods like FAIR, love to hate on those methods because of the "imperfect data" argument (newsflash: all data is imperfect). "We don't know what we don't know, therefore it's all wrong." The response to that quip is a separate post (coming soon!), but suffice to say, limitations of a specific method DO NOT prove that an overall management process is somehow inadequate, wrong, or a failure.

The 2008 credit crisis is not the result of poor risk management. Rather, it demonstrates the failure of traditional ORM risk assessment / risk analysis methods, which failed to properly account for a number of key risk factors, and which also overlooked major exposures (for more on this, see the "Modern ORM" paper).

So, the next time someone tells you that "risk management is a failure," please ask them not to throw out the RM baby with the bathwater, and instead prod them into explaining their quip, which will inevitably lead to complaints about risk assessment or risk analysis, which is not equivalent to RM.

That is all.

As a rule, I try not to toot my own horn too much. There are far smarter people out there. That said, I thought you might find the following articles of interest:

Big Fat Finance Blog: "Risk Chat: Is Your GRC in the Cloud?"

CRN: "How to Manage Cloud Risk"

The ISSA Journal (November 2011, Volume 9 - Issue 11)
"Scaling Risk Management"

Also, I highly recommend joining the ISSA!

My attention was drawn this morning to an ISC Diary "guest post" by Dr. Eric Cole ("What are the 20 Critical Controls?"). In it, he points to the SANS "20 Critical Security Controls - Version 3.0," which was released in August. In the ISC Diary post, Cole talks about using these controls for "quick wins" and in the controls list itself SANS says "These controls allow those responsible for compliance and those responsible for security to agree, for the first time, on what needs to be done to make systems safer."

Unfortunately, while the list isn't technically inaccurate in terms of capabilities available, there are a few problems. And, contrary to their assertion that compliance and security people can finally agree on something, I don't think these controls are actually controls, let alone a source of true consensus.

I recently gave a talk based on my "Scaling Risk Management" blog post (and an upcoming article). The talk was generally well received, but there was a particular question that I didn't get a chance to answer, and thus thought I'd elaborate on it a bit here.

During the talk I cover some "fundamentals" in order to baseline the conversation. I go through common terms and what their generally accepted definitions are, highlighting discrepancies between a few industry definitions of common terms (including "risk"). Part of that discussion covers risk tolerance vs risk capacity vs risk appetite. Oftentimes these terms get used interchangeably, but they are in fact distinctly different.

Everybody's doing it, in some way, shape, or form. It's inherent in just about every decision in life. Yet, when you try to deconstruct it and look at how it works, as well as try to make it "better," you end up with some very interesting challenges. I'm talking, of course, about "risk management."

I don't think that anybody would argue that risk management is important. However, that's about where the consensus ends. How you go about doing risk management takes us down a lot of different roads, which diverge based on numerous variables such as the industry you're in, the size of your organization, the types of risk factors you're weighing, and your overall interest and willingness to formalize certain "things" (methods, metrics, etc.).