Safe to say that these are extremely turbulent times. The mixture of wars, financial crisis and meta-crisis, election cycles, and a looming global recession have combined to form enough angst and fear that it makes emo seem like Elmo. And it is in these times that one could easly just pull the covers over your head and go back to bed. But in doing so, you’d miss some amazing opportunities.
They say that necessity is the mother of invention, but I think that the “oh crap” moments are far more inspiring and lead to better, more useful innovations.
- Oh crap! There’s more information about everything available in ways I cannot even begin to count. How do I get to the good stuff?
- Oh crap! To compete, I’ve got to get more out of the bright people working for me. How do can I take their creative efforts and merge them into our core business?
- Oh crap! I thought I knew how to start a company but between all of this web 2.0 mumbo-jumbo, VC scare tactics, and the financial crisis, I’m just not sure anymore. What can I do?
It is a real “ah ha” moment that can break you out of the paralysis that an “oh crap” world so easily create. These moments come from seemingly unrelated conversations and random thoughts. These moments come from things like Defrag.
Eric describes Defrag as:
Defrag is the first conference focused solely on the tools and technologies that are leveraging the “social” aspect of software to accelerate the “aha” moment. Defrag is not a version number. Rather it’s a gathering place for the growing community of implementers, users, builders and thinkers that are working on the next wave of software innovation.
What Eric is really doing at Defrag is to build a crucible into which is poured a combination of very smart people, innovative vendors, and curious attendees. Turn up the intellectual heat through meaningful keynotes, panels, and Q&A and “ah ha” moments are forged. These are moments not to be missed.
Having seen what Dick is cooking up at Sxipper and having just built my chi.mp site, bethu.mp, I am really excited to see what other fascinating stuff is waiting for all of us at Defrag 2008. Come join the fun and have an “ah ha” moment or two in the midst of this “oh crap” world.
I am headed to this year’s Defrag conference and I pumped to do so. I didn’t get to go last year which I really regretted, and Eric hasn’t let me forget that either.
I will be moderating a panel called: Can identity be a filter for information overload? Eric and I are in search of interesting people and points of view to include on this panel.
On first blush, to me, this sounds like a discussion of the current state of personalization. Eric isn’t sold yet on that angle. I’d be interested to learn if/how personalization is moving from explicit declarations, “I like cake,” to something more implicit, “From examining your read RSS feeds, Computer thinks you like cake.”
Putting on my enterprise identity hat, I start to wonder if my role and relationship to my employer has a hand in this. Again, this ought to be an interpretation of pattern and not an explicit assignment. I am a senior analyst at Burton Group focused on identity and privacy. I share interests with my team. Collectively this blob of information (feeds, groups, sites, etc) is likely to be of interest to us. Further, I am curious how my role and relationship combined with a Google Search Appliance or SharePoint can act as a filter.
Finally, I can’t help but think of the privacy implications here. Traffic analysis can and will start to reveal my preferences, and there definitely are privacy implications to this. Add extra data to the mix, like location, and the privacy concerns grow quickly. (I swear there are moments that my iPhone seems eerily like HAL.) How does industry handle my contradicting desires to filter based on my identity (and here I am including preferences as part of my identity) while not revealing too much about me? What is too much anyway? Who gets to decide?
At any rate, if you’ve got some ideas on the matter, please send them to Eric and me – operators are standing by.
I’m sure you’ve been following the Terry Childs case. Mr. Childs was a sysadmin in San Francisco who decided to change a few passwords and thus locked the city out of their new wide area network. Though it is still not clear why Mr. Childs did this, he had been recently written up for poor job performance.
Among others, Matt Pollicove wrote about this and the need for trust. Matt asserts that trust is a must and I completely agree. That being said, the last two points in his post are mistaken.
First he says:
This means, making sure there’s no orphan or rogue accounts in the systems.
While this is a generally accepted good practice, it would not have necessarily helped San Francisco keep from losing their network. Privileged account management would have been far more useful. Discipline and control around how sysadmins gain access to and use root-like accounts, the bread and butter of privileged account management, would have helped avert some of San Francisco’s problems.
Second Matt says:
GRC tools will be a must in this verification.
This first thing that springs to my mind is a question: what aspect of governance, risk management, and compliance would have helped the city of San Francisco in this case? A good governance and risk identification and management process would have helped a great deal. But we have to keep in mind there is no such thing as a GRC tool; there is no such animal. In fact, GRC is starting to sound like the wonderful magical bacon animal that Homer Simpson dreams of. If pork chops, ham and bacon all come from the magical animal in the Simpsons, then privileged account management, orphan account management and provisioning all come from the magical GRC animal. Where does it end? The reality is that the industry has confused the benefits of good governance processes and risk management capabilities with automation tools that aid, but never replaces, those processes and capabilities.
Privileged account management is not and should not be considered part of the marketing fog of GRC. Does the controlled management of root-like accounts constitute good operating procedure and help reduce risk? Absolutely. But that doesn’t make privileged account management a GRC technology. Is orphan account removal a critical process from a security and risk mitigation perspective? Of course. However, that doesn’t mean the technologies to do that are GRC technologies.
Specificity of language is crucial. Telling the city of San Francisco that the solution to their problems lay within “GRC” would have done little except lengthen the time to finding what their real problems were. Our industry cannot take the easy route and lump every possible technology and procedure under the sun onto the GRC heap or else we’ll find ourselves chasing Homer’s magical bacon animal.
My first post as a Burton Group analyst is now up over at the Identity and Privacy Strategies blog.
(Helps if I actually link correctly… doh!)