Posts RSS
Subscribe via Email
More on the Rybolov Information Security Management Model
Posted December 1st, 2009 by rybolov
OK, so it’s been a couple of months of thinking about this thing. I threw together a rainbow-looking beast that now occupies my spare brain cycles.
Rybolov’s Information Security Management Model
And some peculiarities of the model that I’ve noticed:
Regulation, Compliance, and Governance flows from the top to the bottom. Technical solutions flow from the bottom to the top.
The Enterprise (Layer 4) gets the squeeze. But you CISOs out there knew that already, right? It makes much sense in the typical information security world to focus on layers 3, 4, and 5 because you don’t usually own the top and the bottom of the management stack.
The security game is changing because of legislation at layers 5 and 6. Think national data breach law. It seems like the trend lately is to throw legislation at the problems with information security. The scary part to me is that they’re trying to take concepts that work at layers 3 and 4 and scale them up the model with very mixed results because there isn’t anybody doing studies at what happens above the Enterprise. Seriously here, we’re making legislation based on analogies.
Typically each layer only knows about the layer above and below it. This is a serious problem when you have people at layers 5 and 6 trying to create solutions that carry down to layers 1 through 4.
At layers 1 and 2, you have the greatest chance to solve the root causes of security problems. The big question here is “How do we get the people working at these layers the support that they need?”
Similar Posts:
Posted in Public Policy | 
7 Comments »
Tags: government • infosec • legislation • management • publicpolicy • scalability • security
December 1st, 2009 at 11:14 am
What’s terrible is that you need to build a chart like that just to straighten out what’s going on.
But I think it’s really great.
December 1st, 2009 at 8:41 pm
[…] like the model that the Guerrilla CISO has come up with. Really puts some things in perspective. More on the Rybolov Information Security Management Model | The Guerilla CISO Tags: ( general […]
December 3rd, 2009 at 4:36 pm
Nice visualization!
December 4th, 2009 at 11:59 am
The bottom is where actual root causes are fixed. But often a problem is when the top layers try to be specific and prescriptive. It really ties the hands of the layers below and ends up forcing layer 1-3 into avenues of work that may or may not be useful.
I bet you could apply a vague-to-specific arrow from top to bottom as well. Then again, that may be implied with the regulation and technical arrows heading in opposite directions.
December 4th, 2009 at 9:46 pm
Hey LonerVamp, that’s the point of my DojoCon presentation and I allude to it here: how do I get what the people at the bottom of the stack need so that they don’t have to live by decisions made at the top of the stack?
Or stated differently: when will you guys quit having stupidity handed to you on a silver platter and become self-governing? =)
December 8th, 2009 at 8:38 am
Code can solve all problems. Left alone, coders will solve the problems which interest them. More importantly, if left alone, coders will solve the problems which interest them individually.
Small problems will be solved by ordinary coders. Large problems will take either geniuses (of which there are short supply), or teams. Teams involve coordinating the interest of coders – persuading them that the team problem is more interesting than the problem that they’re working on now. (insert obligatory herding cats comment here.) This is true not just of coders, but of all individuals. If I cook for myself, I prepare the dish to my preferences. If I cook for my g/f I prepare it differently, and if I cook for her family, there is a wider set of requirements that results in food I’d never prepare if I weren’t constrained.
Each layer is a constraint on the problems that the coder should focus on. With all due respect to LonerVamp, I must disagree with the statement work that may or may not be useful. Every individual has a different opinion about what is useful. The upper layers make choices about what is and is not useful. In some other forum we can discuss the problem of the commons and the difficulty of writing a global DNSSEC implementation without coordination.
The trick is, as Rybolov says, to express the coordination intelligently – even elegantly. We need to specify the objectives & goals in a minimalist way so that they constrain the code to the minimum.
In the idealistic world, we change the Blue layers to make them more intelligent and more able to speak to the lower layers. We get the coders & trigger pullers to speak up, to be involved in the regulatory process.
In the pragmatic world, we just load the whole problem on the back of the project manager. PM is responsible for finding creative ways to interpret words. For representing the various constituencies to one another. And we accept failure from both ends. The stupid regulation. The grotesque code that will only solve the problem in one particular way.
I’m going to go caffeinate my innner cynic now.
December 8th, 2009 at 9:48 am
Just after I shot my mouth off above, I found the following,
“We can’t just let the business make poor decisions anymore, we need to learn their language and engage them in more meaningful dialogue. We’re yelling in the wrong language. We just need to put that effort into learning their language and communicating more effectively. How is it that we can read HEX in real time but can’t converse with a MBA at any time? http://securosis.com/blog/changing-the-game/”
The discussion in which that comment takes place is relevant to the model above, but it requires a bit more exploration. How often do you need to change your password?
How would you answer that question at the code level?
At the project manager level?
At the national level?
More importantly, what information would you need to make that decision?