As I was talking to a colleague yesterday about the Jericho Forum, someone who didn’t know about them, it occured to me how “European” this approach is. I guess it might be more accurate to say it is not terribly compatible with typical American approaches. In the US, we hold capitalism and competition very dear. So dear, that we typically choose competition over cooperation. The attitude is “I can do it better and make money,” as opposed to “what is best?” The Jericho Forum suggestions greatly smack of the latter. For this reason, I’m not sure the US will ever adopt this early, if ever. Great at innovating! Poor at maturing those innovations.
Moving on to the actual Commandments from the Jericho Forum, I first see they are bookended by some textspeak. This occurs at the beginning:
The Jericho Forum commandments define both the areas and the principles that must be observed when planning for a de-perimeterized future.
Whilst building on “good security”, the commandments specifically address those areas of
security that are necessary to deliver a de-perimeterized vision.
The commandments serve as a benchmark by which concepts, solutions, standards and systems can be assessed and measured.
And this occurs at the end:
Conclusion
De-perimeterization has happened, is happening and is inevitable; central
protection is decreasing in effectiveness– It will happen in your corporate lifetime
– Therefore you need to plan for it and should have a roadmap of how to get there
– The Jericho Forum has generic roadmap to assist in the planning
First, the Jericho Forum hasn’t led me to conclude these things. Second, I understand this is not a wholistic roadmap to security, but rather a security framework intended to address de-perimeterization. That’s a slight cop-out, but ok, I’m willing to accept this.
So, here are the first three commandments, grouped as the Fundamentals.
The scope and level of protection should be specific & appropriate
to the asset at risk– Business demands that security enables business agility and is cost effective
– Whereas boundary firewalls may continue to provide basic network protection, individual systems and data will need to be capable of protecting themselves
– In general, it’s easier to protect an asset the closer protection is provided
The commandment itself is sound, and an extremely common business theme. Same as the first bullet point. I can agree with these outright. The second bullet point, however, gets back to my current non-acceptance of their hypothesis, and as such I’m predictably cautious. I don’t know that data should be capable of protecting itself. Since this is tied to the hypothesis, I’ll skip it for now. The last bullet point is also dubious. I counter that it is easier to protect assets close when you have a) few assets or b) strong centralized administration of those security controls. But wait…that appears counter to de-centralization everything. Oops! I’d rather not manage 4000 laptops individually like so many isolate islands. This bullet point is a big step back.
Security mechanisms must be pervasive, simple, scalable & easy to
manage– Unnecessary complexity is a threat to good security
– Coherent security principles are required which span all tiers of the architecture
– Security mechanisms must scale; from small objects to large objects
– To be both simple and scalable, interoperable security “building blocks” need to be
capable of being combined to provide the required security mechanisms
This second commandment is another no-brainer, although sometimes non-scalable solutions are fine for a company that is not intending to grow out of the solution scale in the lifetime of that solution. Enterprise-level solutions don’t necessarily apply to small companies. The other three descriptors are obvious and I do like the commandment itself.
The first bullet point is something that is not mentioned enough, and too often is mentioned as a baseball bat to get your way of doing things. It’s a largely non-actionable topic, but it really does matter. Complexity means less people understand what is going on, flaws can occur in the middle of all that complexity, it is not agile, often not scalable, and so on. Sadly, “complex” is a relative term which no one agrees upon except in general principle. The second bullet point says the same thing only inversely: keep things easy to understand. Well, yeah, hopefully!
The third bullet point is part of my minor quibble on this commandment. I don’t think everything must scale. This is determined by the company. If this is meant as a framework for the whole world, then yes, I sure would hope solutions are scalable.
The fourth bullet is one I’d love to hear more about as I think I can read it many different ways. Building blocks…like simple components which together form a secure puzzle? Does that affect complexity? Does each building block need to not only be functional but also secure as part of the inherently secure protocols and such? This almost sounds like a “feel good” bullet point that really means nothing and therefore cannot be addressed at all.
Assume context at your peril
– Security solutions designed for one environment may not be transferable to work in another. Thus it is important to understand the limitations of any security solution
– Problems, limitations and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc.
– Surviving in a hostile world
The first bullet point on this third commandment seems to address my concern above, about solutions being different for different organizations. Likewise, homegrown apps or ways of putting things together in one environment, may not be transferable directly to some other network. That’s fine, but doesn’t that undercut needing scalability and simplicity? I guess this gets down to, “Is security a commodity product or a customized service?” By having a framework for everyone, I would also follow that with this describing a commodity product. The second bullet supports the first.
The third bullet…eh? I think someone needs to reword that. This commandment and the third bullet mean little alone.
Of note, I really like what “Assume context at your own risk,” says to me. It reminds me of things I see on mailing lists repeatedly. A vague security questions answered by 10 people 10 different ways, all of which make assumptions or contextual decisions without really properly asking questions or answering the actual question. Things are different everyone, and we must not assume it is all the same, but instead interrogate stakeholders. Oddly, I don’t get the bullet points for this.
jericho 1 – de-perimeterization and the jericho forum commandments
jericho 2 – the jericho forum and the de-perimeterization solution
jericho 3 – the first three commandments: the fundamentals
jericho 4 – commandments 4 – 8
jericho 5 – commandments 9-11
jericho 6 – my conclusions