Challenge Questions … a tale from reality

Posted on by

Last weekend I was in a shop buying a new subscription for my mobile phone. As usual I was hit by an avalanche of questions asking for my name, address, shoe size … One question in particular caught my attention …

The shop attendant asked me “for a password”, a password I could use if I couldn’t go to one of their shops and had to call their call center. By supplying the password to the call center they could verify it was really me.

I don’t know about anyone else but I personally call my mobile subscription provider about once every 5 years. The service they offer just works, rarely needs change and if it does need change, they often have a website to help you out. Chances are high I would have completely forgotten the password by the time I had to call them.

The conversation with the shop attendant went like this:

  • Attendant: “You have to choose a password, a password you can use when calling our call center“
  • Me: “Oh … hmm … how many times can I guess when I am calling in?“
  • Attendant (realizing I was afraid of forgetting the password): “We will give you hints if you forgot it“
  • Attendant (still aiming to give excellent customer service): “People often choose the PIN code of their credit or debit card ...”
  • Attendant (now realizing not everyone liked this idea): “… but of course you don’t have to, you can pick any word“

At that moment I tried not to, at least not obviously, show my emotions about this conversation.

This method to verify who is calling is flawed to say the least. Due to the very low frequency people have to call in, most people will have forgotten their password. Unless of course they used their PIN code, which they hopefully still remember. Since call center employees can obviously read the password (they need to verify it) they have clear text, and probably unnoticed, access to a lot of PIN numbers. Do I need to add that call centers employees are not the most loyal employees you can find?

The fact they give hints when you call in, is stupid as well. Not only do they admit their system is flawed by design, they also help in under mining it themselves. Imagine this conversation when a hacker calls in:

  • Hacker: “Hi, I am John and I need to change my subscription plan“
  • Call Center: “Hi John, could you give us your password please“
  • Hacker: “Oh, I forgot it … could you give a hint?“
  • Call Center: “It looks like your birth year or perhaps your PIN code“
  • Hacker (after a quick look on Facebook): “My year of birth? That should be 1975.“
  • Call Center: “Sorry John, that is not correct, perhaps it’s your PIN code?“
  • Hacker: “No, I would never give my PIN code to you, could you give me the first number? Perhaps I recognize it“
  • Call Center (re-assured it could not be his PIN code): “It starts with 5 John“
  • …

I am sure someone much more experienced in social engineering (I have virtually none) can get someone’s PIN code this way.

The state of TOGAF

Posted on by

It began with an article about the recent TOGAF conference written by Tom Graves. That article contained a quote I twittered:

We’re actually quite close to the point where a TOGAF certification is an indication that someone is not capable of doing enterprise architecture.

Twitter is a medium not really suitable for intelligent conversation. You only have 140 characters, there is no room for nuances or context. I did include a short url to the original article so people could get the whole picture. Nevertheless, the quote is out of context and that scared Tom.

In his follow up article Tom tries to explain where his statement came from. I hope that anyone understands that neither Tom nor I ever tried to say that people with a TOGAF certification are not capable of Enterprise Architecture. The TOGAF certification doesn’t differ from most other certifications out there. Having the certification does not guarantee knowledge and expertise. Not having the certification doesn’t mean you are inexperienced either.

The reason for me to twitter the quote was because I found it to be representative for what my generally feeling about TOGAF is. TOGAF needs a reality check, and soon.

In fact, Tom sums it up perfectly in his follow up post (and I urge you to read it instead of just depending on the cut and pastes I make):

  • he reference-architectures (Part VI of the TOGAF spec: ‘Technical Reference Model’ and ‘Integrated Information Infrastructure Reference Model’) are way out of date, and at the least need a complete overhaul, if not dumped altogether [that was from the Open Group’s lead Allen Brown, in one of the plenary sessions]
  • “almost no-one” uses the ADM in the form described in the TOGAF specification [in my last post I said I thought that was one of the guys from Deloitte, but my notes indicate it was Mike Lambert from Architecting the Enterprise, one of the lead TOGAF training groups]

These are two major shortcomings of TOGAF and Tom is not the only one mentioning them. Combine that with these two fundamental characteristics of Enterprise Architecture:

  • enterprise architecture is much broader than IT, and must now encompass the whole of the enterprise [that theme came up at least a dozen times, in plenary sessions and elsewhere]
  • enterprise architecture needs to be understood as a professional discipline, comparable to other professional disciplines such as medicine and building-architecture [again, many people, but particularly Len Fehskens, Open Group VP on Skills and Capabilities]

TOGAF has become enormously mal-aligned with Enterprise Architecture. It started in the wrong camp (IT) and even after a couple of versions (7.x, 8.x and now 9) it does not succeed in taking the right path. That is kind of ironic for a framework that is supposed to align business with IT.

Only in the last couple of months people start talking about some of the shortcomings of TOGAF. Everyone else is still covering up the shortcomings while making money from the “big TOGAF standard”. Each time you ask about some unclear element of TOGAF, the answer you’ll get will sound like “oh, but you don’t have to take that so literal, you have to adapt it”.

I sincerely hope we will get more people to speak up about TOGAF and get a significant better and mostly leaner version of the standard.

Encryption … no, we don’t need that

Posted on by

Kim Cameron recently went to a conference where he heard a cloud computing vendor utter these, and judging on the blogosphere almost legendary, words:

One of the vendors shook me to the core when he said, “If you have the right physical access controls and the right background checks on employees, then you don’t need encryption”.

Kim admitted he almost choked. I can understand him. We are in for some rough times if there are cloud computing vendors out there who think like that.

On the other hand I would like to take this opportunity to make sure you know that encryption in itself does not mean security. You can apply encryption all over the place, using keys that have a gazillion bits, and still have a unsecure, dumb solution.

Any vendor who replies “We use 256 bit AES encryption” when answering the question “How do you secure transmission of data?” is as dumb as the vendor who says “physical access controls and the right background checks on employees make encryption not necessary”.

OpenID to avoid Phriend Phishing on Twitter?

Posted on by

Johannes Ernst suggests that using OpenID might be a good way to avoid phriend phishing on Twitter:

Should have guessed that Phriend Phishing was first going to happen to somebody famous.

Now, how could that have been prevented?

What if:

  • Twitter adopted OpenID as the only way of authenticating.
  • Twitter showed the authenticated OpenID identifier instead of a (possibly made up) user handle on all tweets.
  • Kanye West would have used his official website URL as his OpenID.
  • Ergo, everybody could follow the OpenID to determine whether any phriend phishing is going on or not.

I admit that scenario is not entirely viable yet. For example, users are not familiar and comfortable enough yet with OpenID that a major-volume site like Twitter could switch to OpenID-only. But it’s close, and that’s the kind of adoption barriers that we need to work on over the next 12-18 months in the OpenID community.

I don’t know how OpenID can help solve this issue. Changing someone’s Twitter ID to his authenticated OpenID is not helping us forward. These are the reasons.

First, OpenID’s are assigned on a first-come first-served basis. I can pick any OpenID provider and register “http://BradPitt.<openidprovider>.com”. Even when some OpenID providers are going to validate your request, others won’t so users have no clue what to assume about an OpenID.

Second, even when you pick your homepage as your OpenID (using some mechanism of OpenID delegation), the user has no way to know which one of these is the right one:

http://www.bradpitt.com/
http://www.brad-pitt.com/
http://www.brad-pitt.org/
http://www.BradAndAngelina.com/
…

And last, what happens if someone is also named “Brad Pitt”? Is he not allowed to claim the OpenID “http://www.bradpitt.com/”?

I think OpenID has many added values, especially in the world of social media, but for the moment I don’t think owner assurance is one of them. With OpenID I can be fairly sure the Tweet came from someone owning that particular OpenID. But OpenID does not guarantee me that the names used in the OpenID URL itself are pointing to the owner.

(EIC-2009) Claims is what we have, claims is wat it will be

Posted on by

[Blogged from the 2009 edition of the European Identity Conference]

Slowly I am getting the impression that Microsoft is going to use claims for everything even remotely related to identity. During discussions at EIC 2009 I understood that Microsoft is also positioning claims for authorization. This is not entirely new, in their Azure Cloud Services offering they positioned claims this way: for authorization.

I am not feeling a 100% comfortable with this. Without more and detailed information on how Microsoft will realize it, I can hardly judge their strategy but here are some of my worries:

  • Is the claims request/response protocol capable of supporting authorization? XACML obviously has a more rich model that allows for fine grained context descriptions and nuanced responses (e.g. obligations). With claims it’s more simple.
  • Using claims for authorization makes the solution attribute driven. That opens the door for a heavy dependency on roles: roles are easy to represent in a claim. As far as I know Microsoft doesn’t have a solution to manage roles. Perhaps they have something on the horizon?
  • Microsoft already indicated that roles as we use them today are incomplete. They are looking for a standard way to accompany roles with predicates. For instance “The user has the role ABC but only between 9AM and 5PM”. I can agree with the usefulnes and semantics of this roles-predicates marriage but I smell a box of pandora: so many ways to mess this up.
  • Claims are a powerful concept and we can thank Kim Cameron and Microsoft for defining and pushing this. But there is this saying in Flanders “if the only tool you have is a hammer, everything looks like a nail”. This is a real trap for Microsoft: using claims to solve every IAM problem. I see the first signs of claims semantics being stretched too far.
  • Lastly, informally I heard some ideas on how they will align Sharepoint with the claims world (specifically in terms of authorization). Policies would not evaluate to authorization responses but might evaluate to query-like structures that can be used by Sharepoint to select the resources you have access rights for. I am not sure if I understood this correctly so I am going to hold back on commenting.

It will be interesting to see how all this will be evolving in 2009 and 2010. I assume more on this during EIC 2010.

Day two @ EIC 2009

Posted on by

I haven’t blogged about the European Identity Conference since it started. Although I have to say that I made up by using Twitter (@bderidder) during most of the keynotes and presentations. I was present at the very first EIC in 2007, skipped the 2008 edition and joined the 2009 edition again. That gives me a nice opportunity to see how this conference has evolved during it’s 3 first editions.

It has evolved … and mostly in a (very) positive way. Kuppinger Cole succeeded in creating a strong conference agenda with all important IAM and GRC topics covered. Even the catering is perfect! That was not really the case in 2007 during the first edition 😉

I do see a difference though. In 2007 there was this “grassroots” atmosphere. We had a lot of people working on emerging standards like Bandit, Higgins, OpenID, VRM … There was this constant buzz during the presentations, breaks and evening visits to Munich. Everyone felt as if they were part of this new thing called “Identity”.

The 2009 edition is different. It’s definitely a lot more mainstream. There is less of a buzz (if at all). I think that can mean two things. One, EIC is scheduling more “serious” presentations and, two, Identity has matured into something … well … mainstream. As always in these cases, it’s a little of both.

Heavily scheduling presentations about GRC (Governance, Risk and Compliance) is bound to create a more professional (dare I say boring) atmosphere. But, and that is a good thing, Identity is also a lot more mature. Most of the bleeding edge topics in 2007 are now being presented as commercial products and consultancy offerings. The best example would be all the offerings you can see around claims and XACML.  Topics like OpenID or SAML are not exotic anymore. They have become well accepted in the industry. One topic didn’t seem to make it though. “User centric identity” was lost somewhere in the last 2 years. It’s being recycled in the VRM (vendor relationship management) community but with less fanaticism.

Relating to my remark on GRC, hinting at it being a boring subject, I have to make a correction. It’s definitely not a boring subject. I would also say that Kuppinger Cole is absolutely right in scheduling it on the agenda. But you have to admit, it’s a more specialized subject with little to none “sexy” technical aspects.

The conference is not finished, it’s not even half way, yet I think I can make a couple of preliminary conclusions on what I will be taking home on Friday evening:

  1. Identity has matured, most of the exotic topics two years ago are now mainstream and being turned into products by Oracle, Sun, Microsoft, IBM … and numerous other larger and smaller players in the market. Clients also notice these offerings and buy them.
  2. It’s not clear if the current level of maturity of Identity is sufficient. There haven’t been any presentations on this and Kuppinger Cole is not making statements on this. Unless it’s about GRC of course, but what about other aspects? There are bound missing gaps in Identity right now and they are being forgotten in all the happiness surrounding claims, federation …
  3. There is a lot of talk about GRC, both in presentations and during breaks. Nevertheless, I personally still perceive it as something at a conceptual (hype?) level. That is at least the overall impression I got at this conference. Topics like these, high level business concepts, always carry a risk of remaining empty. It’s very easy to talk an entire day about GRC without knowing a thing about it, it’s a lot harder to do that with topics that have a direct technical link.
  4. Authorization is massively misunderstood and apparently has yet to reach the maturity level Identity currently has. Whenever the word “authorization” is dropped, people either go RBAC or think it’s about claims. It will probably take more then one year (and conference) to get this right.

I forgot some conclusions but since the conference is not over yet, I will get another chance to write about those.

For what it is worth, some advice for a 2010 conference:

  • Try to create some of that 2007 “grassroots” atmosphere, there are plenty of topics that can do this, both in Identity, Authorization and hopefully GRC as well.
  • Turn the GRC topics into something with real and tangiable content. It’s so easy to talk about GRC without actually saying anything.
  • GRC brings IAM to the world of “Business ICT Alignment”, that means to the world of Enterprise Architecture. So … where are the IAM and Enterprise Architecture topics?
  • Authorization definitely should come back and hopefully with the message that it is not about RBAC and not about claims. Those are merely tools and technologies that will have a much shorter lifespan then authorization itself. We have to dig deeper and unravel more of what authorization is really all about.
  • And last, an Identity Award for the longest blog post about day 2 of EIC 2009. Thank you.

Fake SOA

Posted on by

I came across this article from Anne Thomas Manes. She is probably best known for her article on the death of SOA. The article has an interesting quote (emphasis added by myself):

Most organizations that I’ve spoken with are using service-oriented middleware to do integration (SOI rather than SOA). Very few companies are actually rearchitecting their systems, i.e., simplifying their applications and data architectures in order to increase agility.

Most if not all “SOA efforts” I have came across in the last couple of years suffer from the above. The prime focus is on integration technologies: use a service bus as integration middleware. It is no surprise that most ESB products have a EAI background and just reinvented themselves as an ESB.

The second interesting item in the article (emphasis added by myself):

Instead they are using WS-* or something similar to implement open interfaces to their existing applications (i.e., JABOWS). Over time, JABOWS typically results in increased architectural complexity and systems that are more fragile and more expensive than ever before. Although initially the initiative appears to be successful, the long term effect is actually a failure.

In a previous job I regularly questioned the abundant use of SOAP and WS-* to create a Service Oriented Architecture. JABOWS (Just A Bunch of Web Services) is definetely not the same as SOA and indeed often results in a far worse architecture. SOA is not so much about the technology realizing the interfaces, it’s about the services you define as part of an overall architecture.

Microsoft on ‘Building Security In Maturity Model’

Posted on by

Last week I went to a presentation on the Building Security In Maturity Model by Gary McGraw. They interviewed about ten organisations who did have a software security team and asked them what they actually do today to make software more secure. They specifically went for a data-driven apporach, no “what could we do” but a 100% focus on “what do they do”. Piling all that information together, some magic processing (read: spreadsheet magic) and you have the Building Security In Maturity Model.

Microsoft was one of the organizatons participating in this effort. Steve Lipner himself wrote about how he experienced this effort and what he thinks from the outcome. One part of his article I would like to emphasise:

I’ve historically not been a fan of “maturity models” because many of them are so abstract and paper-oriented that you can rate “high” on the maturity model and still fail at whatever attribute of your products and processes (quality, timeliness, security) the model purports to measure.  In contrast, I like the BSIMM because

·         It’s specific.  The measures in the BSIMM are things that an development organization actually does to produce secure software.

·         It’s real-world.  Gary, Sammy, and Brian made a rule that no activity would be included in the BSIMM unless at least one of the organizations they interviewed actually performed that activity.

I have about the same idea on maturity models as Steve has. But then, I am mostly sceptical about any model and framework that abstracts away reality so vigorously that I wonder how any organization can successfully use them to achieve improvement.

TOGAF, Zachman … obsolete?

Posted on by

I stumbled accross this tweet from Danny Lagrouw:

Dion Hinchcliffe #qcon: “Architecture frameworks like Zachman, TOGAF, DODAF etc. aren’t keeping up with today’s web technologies.”

I found it interesting since it aligns with my own mixed feelings about these frameworks. On one hand they seem to do a good job on formalizing (enterprise) architecture but on the other hand I wonder if any organization can successfully realize their architecture, using those methods, in today’s rapid and agile environments.

Design Secure Software

Posted on by

Repeating an article by Bruce Schneier is kind of useless. I assume everyone even remotely related to information security has his blog as the first thing to read every morning. Nevertheless I’ll give it a go for those not yet aware of this excellent source of insight.

From his article titled IT Security: Blaming the Victim, I was happy to see these two quotes:

The solution is to better design security systems that assume uneducated users: to prevent them from changing security settings that would leave them exposed to undue risk, or—even better—to take security out of their hands entirely.

and (emphasis added by me)

The legal system needs to fix the business problems, but system designers need to work on the technical problems. They must accept that security systems that require the user to do the right thing are doomed to fail. And then they must design resilient security nevertheless.

There is absolutely not enough effort going into designing secure software and solutions. As I said before, too much energy is spend on dissecting vulnerabilities without even hinting at improvement. At the other end of the spectrum, organisations are spending large amounts of money on information security plans, risk analysis and governance but neglect to address securing the software that manipulates the assets they want to protect in the first place.