My RBAC Manifesto

No one component taken out of context makes the Personal Cloud.

No one component taken out of context makes the Personal Cloud.

I’ve been following the Role Based Access Control thread on the Personal Clouds List and just sort of biting my tongue so as not to sidetrack any productive discussion there.  However, I cringe every time a new email comes out comparing Clique Space to RBAC.  One is a model, one is an implementation.  To compare them is like saying “China is not capitalism.”

I have issues on several levels with the whole discussion.  First, I believe that Role Based Access Control will be essential to the Personal Cloud architecture.  With all of the different functions proposed for Personal Cloud, it doesn’t seem scalable with the other types of access control.  Furthermore, there is no “personal cloud” if all the parts of it are developed in a vacuum.  Even though your component of the Personal Cloud may be simple enough to not require RBAC, how will it fit into the greater architecture?  For example, a smart light switch may have one role – either you can access it or not.  That’s a use case that screams out for simple Access Control Lists right up until you try to integrate it into a larger home automation system.  It isn’t so much that the switch now needs roles, but rather that the ability to manipulate or inquire on the switch from within the home automation system is itself a role of that larger system.  So as a designer the question becomes: In a larger cloud context where the owner manages using RBAC, do you want your device or component to be the only thing that requires the homeowner to program specific Access Control Lists?  How user friendly is that?

My answer to this is that as designers we need to recognize up front that the complexity of the Personal Cloud requires something more manageable than individual access control lists and then design our components to live in that greater context.

[Read more…]

Escaping advertising’s uncanny valley

You can't get there from here!

You can’t get there from here!

One of the major themes that I see driving Internet of People and Things, and commerce in general, is ultra-personalization.   Although not recognized widely as such, one of the “killer apps” that has emerged beginning with graphical OS’s is “themes” or “skins.”  Simply put, the OS exposes not merely the knobs and dials, but the size, shape and texture of the knobs and dials.  Not just audible and visual event notifications, but the sound, look and behavior of those notifications.  This was never recognized for the significance it has had in shaping customer expectations about responsiveness of products.  In fact though, as things get smarter and computing recedes invisibly into the fabric of life, there is no single killer app.  Ultra-personalization is the killer app.

[Read more…]

Swedes: Closet VRM activists?

deadpeople560x288

A recent post by Mary Hodder on the VRM list discussed the news of the Swedish Data Inspection Board banning Google cloud services such as Docs, calendar and email over privacy concerns.  Mary writes:

It’s going to be a PR struggle to convince regular people that “personal” or personally directed services (VRM) style are different than general cloud services.. because I bet that Google would argue that Google apps are personally directed.. nothing happens unless the individual uses the services, from Google’s perspective. But the individual’s data  isn’t controlled by the individual, VRM style.

So I think this will be the pivot point.. convincing the public, as well as the companies and governments, that it’s not “personal” unless the individual controls their own data, not just the use of the product.

What is interesting to me about the privacy issues unfolding of late, especially in the wake of the PRISM revelations, is that VRM-y cloud apps already exist that address the issues raised by the Swedes and for privacy in general.  If Cole Sear were here he’d tell you the same thing:  “I see VRM apps. Floating around the cloud like regular apps.  They’re VRM except, they don’t see each other.  And they don’t say they are VRM.  They don’t even know they’re VRM.”

[Read more…]

Big Data? No. Big Signal!

One of the best ways to understand VRM (Vendor Relationship Management) is to look at it from a more familiar perspective.  When it comes to consumer data, one of the most familiar perspectives is that of Big Data so naturally many questions about VRM are couched in Big Data terms:

  • How big is VRM data anyway?
  • How much data is (or will be) in the personal cloud?
  • Who crunches VRM data to come up with something useful?

The answers to these questions lead to one inescapable conclusion: VRM isn’t a difference in scale.  It is a difference in kind.  This isn’t Big Data.  It’s Big Signal.

[Read more…]

Why break stuff?

If you are a project manager in charge of building your company’s new, strategic, bet-the-business application, you are probably going to look for people exceptionally skilled in designing and building complex architectures. We all know people like this. They have an almost magical ability to conceptualize an idea, lay out a precise roadmap from here to there, and then deliver the most amazing products. The ability to build something from nothing, and to so do with exceptional skill, is a rare gift. It requires a certain mindset which we all have to varying degrees, but that for a very few seems inborn and as natural as breathing. It is an orientation toward synergistic processes. And if you need security, that’s the problem.

Developing a security architecture or finding weaknesses in existing systems requires an orientation toward entropic processes. For the best security architects, this mindset seems inborn and as natural as breathing. While it is possible to have deep skill in both the synergistic and entropic domains, people are primary in one or the other. It is very similar to right or left handedness. Application people are comparable to the right-handed crowd, security people to the left-handers. Each group has varying degrees of dexterity in the non-dominant domain but true ambidexterity is extremely rare. The difference is that when you are staffing a project you don’t go out of your way to make sure there are few left-handers on the team. You may go out of your way to hire a security specialist or two but how do you identify the best candidates? Sure, you look at their track record of successful security work. But do you look for their primary orientation as synergistic or entropic? Now that you know, will you ever not look for that trait in a security specialist again?

My name is T.Rob, and I break stuff.

WebSphere MQ Security

HostileNetwork_590x215

Organizations tend to progress through several maturity levels with respect to security.  The first of these is a perception of security as a very difficult discipline.  One indicator of this maturity level is that the organization knows it is weak in this area, and the expectation of possible security exposure fosters an attitude of vigilance and a willingness to engage specialists.  It pays at this level to hire the best practitioners available and then focus on skills transfer as a large component of the engagement.

Despite the myths, security controls are really not difficult to master.  Most of the work is simple configuration and a few command-line scripts.  As the organization gains some familiarity with security, the perception swings to the other extreme.  Security is now easy.  Once the configurations and command syntax are understood, the organization designs a set of controls and then implements them across the messaging network.  Once the security issues have been addressed, the organization becomes resistant to further changes.  Nobody wants to be the one to raise the security flag again.  Due to that inertia, most organizations do not proceed past this maturity level.  The primary indicators of this maturity level is confidence and a reluctance to engage specialists.  The organizations that believe most strongly in their own security are the ones most likely to under-invest and fall behind over time.

The next higher maturity level comes from a deep understanding of the many security controls and the interdependencies between them.  Although the configuration and commands are easily mastered, subtle interactions between them determine whether the resulting system is effectively secured … or not.  The complexity of the systems involved and the variety of security controls available means that the possible interactions are endless.  The result is that organizations with the deepest skills doubt the effectiveness of their security controls.  They invest more heavily in detection and recovery aspects of the system, they continuously test and probe the security, and they train their in-house staff well.  They also understand the one thing a consultant brings to the table that their permanent in-house staff cannot provide: a perspective not bound by the organization’s culture and expectations.  Organizations at this maturity level engage a particular type of specialists.  They need someone who will challenge their own highly skilled people.  They need the best.  They need IoPT Consulting.

Your certified and experienced IoPT Consulting professional provides a full range of expert WebSphere MQ security services for organizations of any size and at any maturity level.  Pick from one of the offerings below or contact us to discuss your specific requirements.

  • Free Security Health Check
    IoPT will, at no charge to you, review the configuration of selected queue managers and provide a written report noting any issues found, including recommendations for next steps as needed.
  • Regulatory Compliance
    Avoid surprises.  Get a heads-up on critical security issues before the auditor arrives.  Frank Dodd, PCI, HIPAA, FIPS, all regulatory regimes have a few things in common: authentication, authorization, accountability, and availability.  When it comes to WebSphere MQ, AMS, FTE Broker, and MQTT, these are our core competencies.
  • Security Architecture
    The best time to design security is to bake it into the application design and enable it from Unit Test all the way through to Production.