Monthly Archives: October 2013

The Core of a Secure Software Development Lifecycle Model (1)

There are various secure development lifecycle models. Some of them (like the Microsoft SDL – http://www.microsoft.com/security/sdl/default.aspx) are representing the development process as a timeline, others are representing it as a circle. I personally like the circle representation better, because it symbolizes the life “cycle” very well, and makes it pretty clear that the work does not end after the code has been released, but usually goes into the next round for the next release.

2013-10-18 - The Core of a Secure Software Development Lifecycle Model

The circle below shows a representation of the Secure Software Development Lifecycle (SSDLC) process similar to the one I created for various businesses in HP, and that I use when I am training teams on secure software development. It is rather generic, which allows it to tie in with existing business processes and development models.

The SSDLC process I usually use is (like many others) built around a custom security policy, security standards, and security best practices.

The security policy is commonly defined by the organization developing the product. The policy may include all kinds of assertions that the organization makes around software development. I have seen policies that are rather philosophical (“we will do our best to crate secure software and fix defects timely”), and policies that are very stringent and precise (“a medium security defect will be fixed in 5 days or less”).

From my experience, having a security policy is more important than the content of the security policy (at least while the content is somewhat useful), because it shows that an organization is committed to security. However, it is crucial that the security policy is known to everyone in the organization, and that everyone is following the policy on peril of losing their job or at least being removed from the project. The security policy must be absolutely binding for everyone, and “everyone” includes people managers, developers, architect, legal, marketing, and everyone else who is working on the project. Such a stringent policy helps to create awareness and gives the security person in charge for the project (for instance, the security architect) the instrument necessary to delay or even stop delivery of the project in case of major security flaws. This may sound very drastic, and it is by far better to rely on good arguments to convince the team members to address a major security issue instead of wielding the security policy club. However, experience shows that without such a powerful security policy, security goals may be quickly sacrificed to meet a release deadline. On a side note, HP has a very strong security policy, and everyone values it so highly that in all the years I have worked as a security architect for HP, I never had to cite it even once.

Steve Gibson’s SQRL is not really new

With a loud buzz, Steve Gibson has eventually announced a “comprehensive, easy-to-use, high security replacement for usernames, passwords, reminders, one-time-code authenticators … and everything else.”

Even his initial hints were quite over the top.

But what is this new SQRL really about? Basically, a website can display a QR code, which a user can scan with their mobile phone. The QR code contains a callback-URL, and a nonce. The user has some private information in his cell phone, and uses that to “sign” (in the broadest term) the nonce. Then the nonce is sent to the callback URL, and the website can be sure that the user was in possession of a (potentially shared) secret.

This is a classic out of band authentication scheme. However, although Gibson celebrates this idea (and himself) as if this was the best invention since sliced bread, it really is not.

When I was still working at Tubingen University, a fellow researcher group worked on a similar solution as what Gibson proposed. Their implementation has been in production for quite a while at http://www.ekaay.com.

The “eKaay” implementation requires pre-registration, but it could fully emulate Gibson’s SQRL by using dynamic provisioning, which is a well-established approach in identity management.

As a side note, I find it quite astonishing that the GUI in Gibson’s demo / prototype looks exactly like the eKaay login screen…

But this is not where the prior art ends: Gibson announces that the component techniques and technologies employed by this solution are all well known, well tested, well understood, unencumbered by patents, and exist in the public domain. This is, however, not true! There are several patents protecting this technology, one of them granted to Pedro Celis De La Hoz and Juan Jesus Leon Cobos.

Note that there is a lot more IP and related patents in this area!

Hence, although Gibson generously donates his re-invention of the wheel to the public domain, his “SQRL” scheme is covered by existing patents, and is neither free to use, nor generally available. It should not be used without potentially expecting legal trouble.

I recommend to do extensive prior art research before making such announcements that can get people who believe these announcements into serious trouble.