Ruminations on Architecture and Security

Yes, you read that right, I gave you my pin code, it’s … ****. Of course, unless you lack a brain, you know that **** is not even a valid pin code. It’s what you see on screen when you enter your code at any ATM. No need to protect that … or is there?

One bank in Belgium goes to great lengths to protect you from devious people trying to read that “****” while you enter your code. They have a special film on the display that makes it impossible to read the display unless you are standing perfectly in front of it. So, nobody can read that “****”, only you can. They even have a sticker on the machine telling you how they do their best to protect you.

They do not protect you in any way from someone looking at what you type on the key pad though. In fact, from the looks of it, they do their very best to make it as easy as possible for strangers to see what you are typing on the key pad.

I know many of their ATM locations are surrounded by excellent spots from which you can undisturbed see any pin code being entered on they key pad. Even when the ATM is indoors, it is conveniently located near a large bright window. A large bright window lacking any protecting measures for that matter. Someone living in the house opposite the street can easily farm many pin codes a day.

It’s good to see how smart people are doing their very best to protect me from fraud and theft. Thank you.

This post is about security, so if you are not into that, feel free to skip it.

Today I get a friendly email from the national railroad company of Belgium (NMBS) in which they announced a brand new site to order international train tickets. It also mentioned that instead of using my made up user name I could now use the email address I used while registering to log in.

That sounds great, another site that uses an email address to log in instead of something like “johnsmith342″.

Then they kind of messed up. For my convenience and to make sure I would be able to use their shiny new site to buy lots of international train tickets they included my password. Yes, you read that right, they mailed me my password. Without me asking for it.

They have no clue about processes and procedures for dealing with passwords. They are not helping the world in teaching people how to deal with authentication secrets, social engineer and phishing.

I can only hope the password is not stored clear text. Due to password policies it is often necessary to access the password in clear text, only storing a hash is not working any more. Common databases like Microsoft Active Directory, Novell eDirectory and probably many others use two way encryption to store passwords. They have many secure access layers between a public api and the encryption keys to access to the clear text version of the password.

Honestly, emailing me my own password without my consent doesn’t generate a lot of trust in how they deal with sensitive information. That includes my trust in how they store my password in their systems.

Some companies insist on letting you know that the mail you just received from them, has been properly scanned, dissected and cleansed before it reached your mailbox.

Sometimes it can go wrong however:

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.1/1517 – Release Date: 24/06/08 20:41

I wonder if I should delete the mail or not. As a juice extra, somewhere else in the mail they refer to their company as “Your IT Reference on the Web !“.

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.

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”.

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.

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.

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.

I have a couple of Tweet searches I follow. One of them tracks tweets with the keyword “infosec”. This morning I woke up with this tweet in the list:

now an excel 0day. woohoo. it’s always exciting in infosec.

This tweet is very typical: it’s always about hacks, attacks in the wild … I personally find that very disappointing, the above tweet even has something morbid.

Although talking about specific vulnerabilities is important, it is a lot more important to talk about avoiding those vulnerabilities in the first place. I see extended articles explaining in great detail how they hacked Adobe PDF documents, web applications or something commonly used. They do this with such pride and amusement that I get this feeling they are sorry they can’t use them in the wild. It almost looks like as if the only thing that differentiates the real authors of malware from these infosec people, is the sense of ethics the second group has. Ethics that stand in the way of making money with the vulnerability found.

As I said, a detailed knowledge of vulnerabilities is very important. But talking about how to do better and avoiding them in the first place, that gives a lot more return on investment in the long term. What could authors of (faulty) software have done to make a better product? What specific design patterns, code patterns … would have avoided the vulnerability? Wich steps in their quality control methods are missing that could have prevented the vulnerability? Every article on a vulnerability is useless for me if it doesn’t mention advice to avoid the vulnerability tomorrow. Luckily there are many authors that do, but sadly also many that don’t.

I don’t think we got this far in constructing buildings by detailing every single collapse of a building without doing any lessons learned. We also try to find out how we can avoid disasters for any future building: tools, methods, procedures and guidelines are  updated as a consequence. That is what makes us move forward. That is what allows us to do bigger while at the same time become better.

Acting on today’s vulnerabilities will not protect us tomorrow. Today we need to work so we can prevent tomorrow’s vulnerabilities and help us control the overall risks.

The recent turmoil on UAC seemed to be settled by Microsoft last week (my take on the issue). But now it’s time to question UAC again. This article explains that Microsoft is going in the wrong direction with UAC. From an annoying dialog that gives some security, it has degraded to just an annoying dialog.

Microsoft is now betting on what they call “trusted processes”: processes that are considered trusted so they don’t trigger a UAC dialog. A lot of those processes (like rundll32) are specifically designed to run external (untrusted) code:

In short, trusting executables is a poor policy, because so many executables can be encouraged to run arbitrary code. There is some irony in Microsoft’s behavior to use a trusted executable model; the company knows damn well that trusted executables aren’t safe, and uses this very argument to justify the UAC behavior in Vista. A system using trusted executables will only be secure if all of those executables are unable to run arbitrary code (either deliberately or through exploitation).

In other words (from the article mentioned above):

So, in spite of the most recent blog post, this remains a poorly-designed feature. UAC is now only as strong as the weakest auto-elevating program.

I wonder what happened to Microsoft’s security drive given these developments with Windows 7 security efforts.