Why outsourcing firms will never deliver secure code to their clients without them paying extra...

At a 2008 OWASP Conference, Rohyt Belani, Principal of the Intrepidus Group described in elegant details, backdoor logic that was inserted into an internet-facing production enterprise application for one of their clients. Sadly, most enterprises don't have a process to catch this type of threat until after the fact. Anyway, Rohyt went on to explain that the enterprisey crowd will never be successful in getting an outsourcing vendor to write secure code without paying extra. Ever since this statement was made, I have been savage in attempting to prove him wrong...



After two years of hard work, he can still claim he is 99.99% right. I have made a small breakthrough with Cognizant in this regard where for a particular project I oversee, I have been able to change the game. Keep in mind that in our shop we have outsourced thousands of developer-level positions and I have had great success with a grand total of four people, so whatever I share in terms of my secret we must truthfully acknowledge the challenge of making it scale.

The first aspect of making this successful was to personally interview each developer for the team, something that most enterprises defer to their partner to handle. I wanted to understand the values of the developers working on my project and get a sense if they wanted to develop Rugged Software or simply wanted to punch the clock and solely deliver to whatever the requirements stated and not one single iota more.

The second aspect of making this successful was the fact that I didn't treat them as some unknown FTE where I throw specifications over the wall and immediately start talking about delivery dates. Instead, I treated them like humans and took interest in their well-being. We joked and laughed together where I got to know them as individuals. We even had sessions where we did pair programming together.

The third aspect of making this successful is that I let them develop the software outside of the usual bureaucracy of corporate controls. I didn't force them to be crippled in using tools that are enterprise approved but otherwise unproductive for them. They were able to develop wherever they wanted to develop. At times, even they worked from home.

The final and most important aspect of making this successful is that I didn't play head games when it comes to dates. There was one and only one date communicated. I didn't build in contingency where I tell the developers one date, the business the next and so on. Making oneself vulnerable isn't a weakness, its a strength that I leveraged to my advantage.

So, in conclusion it is possible for your outsourcing firm to deliver code written of high quality without paying extra for the privilege. The biggest challenge is in changing the mindsets of those within enterprises to break their own habits to allow those in India to be successful. If you want secure software, you have to treat others with respect and dignity, always remembering to be human and interacting with others in the same manner.

Since most enterprises have forgot the importance of humanity and humility, I guess at some level Royht is right that they have no other choice but to pay more...

A Privacy Manifesto

The notion of IT-oriented manifestos is growing by leaps and bounds. The first popular manifesto was created by the Agile community. Most recently, another group of fine individuals created the Rugged Software Manifesto. The one thing that is missing from many conversations is the notion of privacy and therefore I have harvested sage wisdom from many and propose the following as the start of a Privacy Manifesto.



Architects and Developers should consider their fidicuary duty to protect the privacy of their users, customers and business partners. With this thought in mind, we have come to value:

1. To minimize the data collection to that which is required to conduct business

2. To provide proper access control on all data collected that is personally identifiable by nature

3. To classify the data appropriately in terms of sensitivity and adhere to proper retention procedures

4. To dispose of data properly

5. To disclose in an ethical and timely manner whenever the trust others put in you is breached.

Are Information Cards and OpenID appropriate for B2B?

I previously asked the question if Microsoft truly wants Information Cards to be sucessful. Today, I will explore another B2B scenario that both Microsoft and the OpenID community should seriously consider...



The National Institute of Standards and Technology (NIST) has a publication (800-63) that defines four Levels of Assurance for electronic authentication. There are ways to incorporate this notion into SAML but not user-centric identity models.

Wouldnt it make since for the Microsoft do define an element in the WS-SecurityPolicy document where a Relying Party (RP) could define what level of assurance it requires?

The Identity Provider (IDP) should be able to interpret the required security policies of the relying party in this regard and then require the user to use a credential that has been proofed to this level.

By not reducing these types of concerns down to a single attribute, it requires the relying party to have complex logic to derive this type of concern. Even then, it still requires lots of interactions in terms of legal agreements with identity providers whom will all have their own take on the problem.

Kim Cameron, Mike Jones and others could put this one down quickly...