Always exciting in infosec?

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.

Share

10 Obstacles and Opportunities for Cloud Computing

My friends at Slashdot pointed me towards this reference of a good paper on cloud computing. This is probably one of the first decent articles I read about cloud computer. It covers real topics, real questions .. instead of the usual marketing gibberish. I am especially pleased they mention obstacles like “data lock-in” and “data confidentiality and auditability”. I wrote about some of these topics before: here and here.

Direct link to the PDF “Above the Clouds: A Berkeley View of Cloud Computing.

Share

Hotel locations for the European Identity Conference 2009

For the upcoming European Identity Conference 2009 (a conference I can recommend) organized by Kuppinger-Cole, I was looking for the nearest hotel that had special conference rates. The list on the conference site only lists names and addresses. Since I have no clue what is where in Munich, it’s not easy to see where they are located in relation to the conference center.

To make this task easier, I created a Google Map that shows marks for the conference location and all listed hotels. I hope this is useful to others as well.

If you encounter any errors don’t hesitate to contact me!

Share

UAC seems almost useless in Windows 7

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.

Share

Common sense for UAC in Windows 7

There was some talk about the behavior of UAC in Windows 7. To make a long story short:

  1. access to UAC is protected by … UAC: UAC is marked as a “Windows Setting” and those are protected using UAC
  2. by default UAC is not triggered when changes are done to a “Windows Setting” (according to MS due to popular demand for not showing the UAC dialog too often)
  3. therefore changing UAC to “Don’t show up ever” (= disabling it) can be done without invoking UAC itself for confirmation (for systems that haven’t changed the default setting)
  4. world domination!! (but for hackers, not for you)

At first Microsoft considered this not an issue and said this behavior is “by design”. Now they seem to have seen the light over there in Redmond.

It is always dangerous if you protect a system using the system itself. I am not saying it is bad design if you do, I am just saying that bad things can happen if you don’t think this through. The original idea for UAC in Windows 7 was obviously not thought through.

Share

Authorization Management and Attestation

A good read on authorization management from Kuppinger Cole (author is the Kuppinger part, Martin). One paragraph that I could relate to:

There is another interesting aspect of Authorization Management: Dynamic Authorization Management. Most of today’s approaches are static, e.g. they use provisioning tools or own interfaces to statically change mappings of users to groups, profiles, or roles in target systems. But there are many business rules which can’t be enforced statically. Someone might be allowed to do things up to a defined limit. Some data – for example some financial reports – have access restrictions during a quiet period. And so on. That requires authorization engines which are used as part of an externalization strategy (externalizing authentication, authorization, auditing and so on from applications) which provide the results of a dynamic authorization decision, according to defined rules, on the fly.

Most organizations I know are kind of stuck in static authorization management. It’s all about groups (and roles) that need to be populated by IAM tools. Even when the rules to do so are leaning towards dynamic authorization management. Sometimes they just have to, platforms like Microsoft Sharepoint depend largely on groups to perform authorization.

Also note the “European Identity Conference” organized by Kuppinger Cole. I was lucky to attend the first edition (as speaker) and can warmly recommend this conference to anyone interested. Atmosphere is great, content in-depth and a high concentration of (identity) brains. Now, do I qualify for free registration as a blogger ? 🙂

Share

LDAP Referential Integrity

An old issue with LDAP servers has found the spot light again: referential integrity. This time it’s a call for attention made by James:

I also asked the question on How come there is no innovation in LDAP and was curious why no one is working towards standards that will allow for integration with XACML and SPML. I would be happy if OpenDS or OpenLDAP communitities figured out more basic things like incorporating referential integrity.

Pat pointed James to what he thinks is prove of support for referential integrity in LDAP (OpenDS, OpenLDAP and any Sun derivative):

For some reason, James has a bee in his bonnet over referential integrity and LDAP. I’m really not sure where he’s coming from here – both OpenDS and OpenLDAP offer referential integrity (OpenDS ref int doc, OpenLDAP ref int doc), and Sun Directory Server has offered it for years (Sun Directory Server ref int doc). Does this answer your question, James, or am I missing something?

I can’t answer for James of course, but if I had been asking that question … no Pat, it does not answer my question. Well, it kind of does, since it confirms that those LDAP incarnations have limited to no support for decent referential integrity. Let’s follow one of Pat’s links and see what it says (Sun Directory Server ref int doc):

When the referential integrity plug-in is enabled it performs integrity updates on specified attributes immediately after a delete, rename, or move operation. By default, the referential integrity plug-in is disabled.

Whenever you delete, rename, or move a user or group entry in the directory, the operation is logged to the referential integrity log file:

instance-path/logs/referint

After a specified time, known as the update interval, the server performs a search on all attributes for which referential integrity is enabled, and matches the entries resulting from that search with the DNs of deleted or modified entries present in the log file. If the log file shows that the entry was deleted, the corresponding attribute is deleted. If the log file shows that the entry was changed, the corresponding attribute value is modified accordingly.

So it seems that Sun Directory Service let’s you delete a user but it promises to make sure that it will do it’s very best to delete any references to this user within a “update interval”. It does not mention what a read after the deletion but before the plug-in kicks in will see. Will it still see the user as a member in a group although the user is deleted? I am pretty sure it does. This is of course, at least for me, enough prove that this functionality does not offer referential integrity. At best it offers some kind of deferred cascading deletes (or updates) with no semantics for reads done during the time interval between the original operation and this cascaded deletes and updates.

Does this mean an LDAP server is something to avoid in any production environment? Absolutely not! In fact, I am not even sure if an LDAP server should offer “real” referential integrity at all. If you need that kind of guarantees, you are not far from full transaction support either, so why not upgrade to a relational database? Just my 2 cents of course.

To Sun (and any other LDAP implementator): what would the impact be on read/write performance in LDAP if they would implement full referential integrity?

Share