I was just reminded of this randomly just by reading this list of new tools released at the Defcon this year. Sounds like a busy conference, with a lot of hackers who love what they do. Good stuff.

It has become more like a global fair than what most people think of conferences; even the badge is highly unique. I say this because there are so many things to do at DEFCON, other than going to talks, that you could spend your whole weekend looking at the “World’s Largest Boar!” so to speak. One of the CTF (Capture the Flag) contest winners this year actually exclaimed that he only made it to 2 talks in 12 years! I am also one of those individuals who barely get a chance to go to talks and now that the speaker pool is so diverse it’s hard to find all of the “stuff” they release.

Read the list and full article here

“I have quite a few other concerns the with EPTS Member Agreement.   Basically, the agreement needs to be written with an eye toward a more flexible, open and inclusive process that puts the future of the EPTS square into the hands of the event processing community, not a small group of well intended folks who represent a small part of the overall event processing community and worldview.”

Opher’s reply was to just dismiss these comments, a bit surprising since I served the CEP/EP community on the EPTS steering committee; worked quite hard as a matter of fact, for a number of years.   Opher’s appreciation for the years of work is to just off-handly dismiss my comments.

Then in On faithfull representation and other comments and On Top Down and Bottom Up Opher does the same thing, he simply dismisses my comments, defensively, adding humor, sarcasm and fallacy.

I am sorry Opher is so defensive of his narrow society; however I will not yield, because I do not need to resort to sarcasm, fallacy and ad hominums; the facts obviously support my view.  For proof that Opher has a narrow view of event processing, go no further than look at the companies he hand-picked for his EPTS Steering Committee; most startups (or with startup products) in the event processing space, working on common messages to distinguish themselves in a market with much more mature players excluded - classic “not invented here,” isn’t it?

Opher’s claims the EPTS view on event processing is quite general, but the  majority of vendors on the EPTS Steering Committee members are selling similar platforms, a very narrow segment of the CEP/EP space.    Opher claims that he agrees that other domains (like sensor fusion) are significant to CEP/EP, but he simply dismisses my advice to create a true, general EPTS, inclusive of the prior-art and science of CEP/EP (before the marketing folks took over).  He insists on having the EPTS “reinvent the wheel” and develop their own vocabulary, as if event processing did not exist prior to one book on CEP.

Opher’s fun-to-read blog counterpoints to my concerns are evolving to a mixture of ad hominums and sarcasm, sometime wrapped in a defensive tone.   I think we can do better and we must be more inclusive of the other prior-art.  I say we, because I am also a founding member of the EPTS, althought I suspect Opher will banish my name from the membership for trying to diminish the “not invented here” attitude that seems to dominate the EPTS since inception.

The truth of the matter is that the EPTS has a relatively narrow view of event processing, evident by the makeup of the steering committee and the focus of their discussions.    It is not a technical society about event processing, per se; it is a marketing society with a narrowly focused membership that discounts most of the prior-art in the event processing space, it is really, an Event Processing Marketing Society (EPMS) for a narrow group of niche players.

The event processing domain is much, much larger.   The art-and-science of event processing is deep and mature, much more mature (and inclusive) than what we see in the EPTS. 

I think Opher (and the EPTS committee) should take these comments seriously and not discount them with sarcasm and subtle ad hominum replies.

• Certified Information Systems Auditor (CISA) : http://www.isaca.org/cisa/
• Certified Information Systems Security Professional : https://www.isc2.org/cissp

Are You Ready ?
A few basic questions to ask yourself to gauge how ready you are:

• Do I meet the spirit, and not just the letter, of the experience requirements ?
• Has there been sufficient diversity in my experience ?

Five Step Approach to CISA or CISSP Exam Preparation

1. Perform an initial benchmark and assessment of your readiness
2. Read a “survey” level preparation guide cover to cover
3. Perform a secondary benchmark, and compare your readiness
4. Review official, or “deep dive”, preparation materials on areas identified as your weaknesses
5. Re-benchmark, and repeat targeted reviews until ready

CISA and CISSP Preparation

“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.

What has certainly come as more of a surprise, though, is...]]> Mon, 21 Jul 2008 20:00:00 +0000 security controls information risk management security steady increase deep view incredibly broad adopt iso pci dss types The Long Road Towards an ISO 27001 "Tipping Point" (and a true Reader's Poll!) http://securityratty.com/article/6fd3bf9d14bdda91770c10083f0f74d3 http://securityratty.com/article/6fd3bf9d14bdda91770c10083f0f74d3 For a long time Symantec has enjoyed a great reputation as a the VARs best friend.  They were the ultimate channel friendly company with a large and deep channel.  As a result there is always a Symantec channel partner near by almost every customer.  In a case of biting the hand that feeds it this maybe changing. According to this article in Channel Web, Symantec is taking its largest 900 customers direct and moving all SMB renewals direct as well. 

The renewal business is viewed as a built in annuity by many of VARs and losing these follow on deals is not going to sit well.  Also by taking the largest 900 customers direct they are taking the top end or largest deals out of the channel.  The channel market is way to sensitive to this type of thing without repercussions taking place.  It just remains to be seen what they will be, but they will come.

Had a great time Sunday with Rob Newby. We solved the world’s problems over deep fried whitefish and french fries (fish & chips to him).  It was a very good time, even if my driving did make him a bit uneasy.  If I may quote myself (said in an attempt to soothe Rob’s uneasyness about being lost in the car of a complete stranger in a strange country):

If your life doesn’t imitate the surreal aspects of a Douglas Adams book at least once a day, you’re just not living right.

Aside:  Bruce Scheier already has too many awards and too much recognition, so go vote for Rob instead :)   :  http://robnewby.blogspot.com/2008/07/award-up-for-grabs.html

SEPARATION OF CHURCH AND (CURRENT) STATE

Rob and I spent some time discussing risk and security,  and our conversation circled around the (now) recurring blogo-topic concerning the State of the Practice.  It’s a favorite topic of mine, so I’ve been delighted that it has reappeared in blogodom.

Rob writes about it some here in PCI the Priest.  LonerVamp’s and Richard Bejtlich’s blogs talk about Galileo, his confrontation with his church, and lessons we can learn from history (there’s nothing wrong with them recycling the meme, IMHO - because I, for one, never got closure the first time). Jon added a nice quote from Feynman today that’s also inline with the meme.

I’m not going to belabor the analogy, the “art vs. science” misnomer, nor discuss the problems with our various canon (PCI, ISO, CoBTI, COSO, blah, blah, blah).  Rather I’d like to talk about some essential things I think our industry needs to “sort out”  before it can move on towards a more scientific view of the world.  And by “sort out” of course, I mean agree with me on

CAN’T WE ALL JUST GET ALONG?

1 - Can we agree that risk is a probability issue?
Now obviously, you can retreat in probability theory a century or so and claim that risk is a Knightian uncertainty and that we just can’t “know” it.  Have fun.  But you should know that there’s the catch - “security” is also a probability issue.  So I’m betting that you can’t know “secure” for much of the same reasons Frank Knight would argue we can’t know “risky”.

But if risk (and security) is a probability issue, however, then we’re going to have to do better than “A’s in three college courses in statistics” to address the problem.  We will have to do as Curphey (and others) suggest and bring elements of other disciplines to bear on our problem space.  Let me suggest probability theory and economics as fine, fine places to start.

2 - Can we agree to stop measuring stupidly?
We have to agree that Ordinal Scales are not measurements, and Interval Scales are not useful measurements?

I had a post titled “More Ways To Confuse Your Auditor/Assessor” but it turned out to be a pretty cruel discussion about how we tend to try to act like our calculations based on ordinal or interval scales are useful (hint:  insist that your auditor/assessor/consultant replace the label “one” with the label “zero”).

Note that if risk is a probability issue, then we’re going to have to throw out the concepts of measuring in any scale other than a ratio anyhow.

3 - Can we agree on a (good) taxonomy?
We’re going to have to do (much) better than ISO 27005 (nudge, nudge).

4 - Can we agree we need to do a better job with our data?
We’re going to have to do better with measurements, metrics, models and testing.

It’s a shame that honeypots tend to be under appreciated.

5 - Can we agree to test that data and share it with each other?
We may not need to share specific data, but we will need to share when a model falls down.

I’d like to be as idealistic as some of my fellow ‘New Schoolers’ and suggest we’ll someday all be sharing data together, but I’m skeptical.  But that doesn’t mean we can’t demonstrate where results from the models we use are not repeatable, consistent or logical.   One thing Rob and I talked about at length yesterday was the ability to disprove a model using realistic but “substitute” or sanitized data.  There’s gonna be a TON of work to be done here, and that work will take not years but careers.  Which begs a great question:

Is it the sharing of data that we need, or the sharing of models?

HELP ME OUT, HERE
That’s my list of 5 fundamental concepts I wish we could move past.  Let me ask you - what else am I missing?  What’s it going to take to get past our current malaise?  How does the New School reach critical mass?  Who is going to help us agree in a centralized manner?

Your comments or own blog posts are most welcome (please include a trackback or post here)