Why Software Security is a part of any Business Model

19.05.2010 by Martin Kuppinger

During the last weeks, with all the discussions about security- and privacy-related issues in social networks like Facebook or SchülerVZ, I’ve had some talks with people. My position is that these issues are a result of bad software architecture. The counter argument sometimes has been that when building these networks the focus has been on functionality, not security – and that the business model of these networks is based on the functionality. What was meant by that is that you should first care about functionality and that security is somewhat irrelevant because it doesn’t help you in achieving your business goals.

However, that is fundamentally wrong. The current issues prove that the business model of these social networks is threatened by security weaknesses. They also prove (like any good software architect knows) that it is virtually impossible to add good security afterwards. You have to build it in from the very beginning. Trying to fix issues by blacklists or whitelists or by adding some URL obsfucation or something like that always will address symptoms, not the cause.

What we currently observe at many social networks and eCommerce sites is that there is more attention on security and privacy issues – and the providers are struggling with this because their software security architecture doesn’t allow to flexibly react on this. For sure some of these providers are somewhat reluctant in changing their privacy and security settings because their model relies on “openness”. Anyhow, even Facebook has had to make changes, and that will continue.

Good software security architecture would allow these providers to just change some settings by configuration. That would be easy and not very expensive if the software were well constructed, with security in mind from the beginning. That includes the ability to flexibly use different authentication mechanisms and a consistent authorization model which is configurable. For sure there is some more work to do in architecting and developing such a system – but it is significantly less work than trying to fix problems afterwards (and, besides this, doing it from the beginning is a solution and not a patch which leads to patchwork with security and privacy holes).

However, the most important lesson one can learn from that situation is that software security is relevant to any business model. If it inhibits growth, if it leads to a loss of trust and in consequence of users then it affects the business. The  argument that it is first about time-to-market isn’t really valid. It doesn’t take much more time and efforts to do software security right then to ignore this – especially because some security always has to be added before releasing a software. The real valid rule is: You always will pay for bad software architecture. And you will pay for bad software security architecture. That is like in real life architecture and construction – go back to the bible, even there it is told that you shouldn’t build your house on sand. Ignoring software security at the beginning is nothing else than building houses on sand. And a good business model which thinks strategic doesn’t ignore that fact.

Building software without a good software architecture is sort of building a car without breaks. You can argue that the car is for driving, not breaking. And you can argue that it is about functionality not security. But would you trust in a car without breaks?


European Identity Conference 2010

14.05.2010 by Martin Kuppinger

EIC 2010 has ended. And like each year, there are some interesting observations. I’ll take three of them:

  1. The “classical” IAM topics like provisioning or E-SSO are well understood now – and extended.
  2. Federation becomes reality.
  3. The cloud impacts IAM – and vice versa.

Topics like provisioning and E-SSO were discussed mainly in the many “Best Practice” sessions. There are many implementations out there. Several of them use MSSPs (Managed Security Service Providers) or other Saas-/Cloud style types of deployment. And they are increasingly integrated with other IT infrastructure elements like the ITIL tools or portals. There is an evolution towards more integrated approaches and thus more architecture options, and it is obvious that the cloud starts to impact this as well. In the area of E-SSO, trends towards more versatility and integration with for example strong authentication technologies as well as the emerging topic of convergence (physical/logical) were the most important ones discussed at EIC.

Federation is becoming reality. It isn’t hype anymore – which is a good sign. Interestingly, the federation sessions I’ve attended at EIC as a panelist or speaker were fully packed – a difference to last year. The value of federation is understood – now it is about implementation.

With the separate Cloud Computing track and the parallel Cloud 2010 Conference we had this year, there was as well a lot of attention on Cloud Computing topics. These sessions were as well crowded. The most important topic was the relationship between the Cloud and IAM/GRC. There were many interesting, though provocing sessions and many practical views, beyond the hype towards the real thing: How can we make the Cloud more secure? And how can we do IAM/GRC in the cloud for internal and external environments? And there were valid answers, not only questions. It was sort of “The Cloud brought down to Earth”…

I’ll blog about many of these aspects more in detail over the course of the next weeks.


Services
© 2014 Martin Kuppinger, KuppingerCole