Is the TeamMentor Development/SDL team as good as it gets? (from a security point of view)

As we're having another internal (which should be public but is a topic for another post) debate/email-thread at SI/TM about the 'best way to handle user passwords/hashes', I was thinking "is this (TM SDL) as good as it gets?"

Here is what we have today (regarding TeamMentor's SDL and Team):

• Decent skilled developers (like me :) )
• Developers and Power Users with good knowledge of security (its impact, exploitability and fixes)
• Big focus on the 'hard problem to solve'
• Responsive to customer's needs and requests
• Big push to be open and transparent with our SDL and TM Security (code in GitHub, past vulnerabilities disclosed in this blog, posts like this one, etc...)
• Direct access to high quality security expertise
• TeamMentor itself :)
• Amazing talented Security Experts (SI's Security Consulting arm)
• A product that has not been 'properly attacked' (the current threat/risk profile is still very low)
• No 'official' security touch points in the SDL
• No automated security tools that run on every build and check the code for security vulnerabilities (static and dynamic scanners)
• No dedicated 'Application Security Budget' that can be spend on regular security reviews
• No real 'security coding standard' that we can use, follow and be measured
• No AppSensor-like capabilities where TeamMentor can react-to and mitigate-from malicious behaviour/activities/traffic
• Very little documentation of the TeamMentor architecture, its security attack surface and how to code TeamMentor securely
• Big push for a fully automated CI environment (which will help to add Security Touchpoints)
• Very little QA Automation (which means that we have no 'easy' place to inject security tests, and the security tests/assessments struggle with getting enough state in order to perform real/thorough tests)
• Cases where we shipped versions with known (to us) vulnerabilities (hard to exploit and fixed on next minor release)
• There are vulns-by-design (like XSS in the articles) which exists on all CMS and most blogs (like blogger)
• Code-base that spawns three generations of refactoring with tons of legacy-code; mixed with solid code and new/experimental code 
• Yes we could spend more time 'hardening' TeamMentor but there is no real (and pressing) priority to do so, since we are still trying to solve fundamental issues with its workflow and technology
• The current security assessments done on TeamMentor (internal and external) have been OKish (at par with what happens in the industry). But I know TeamMentor's code-base inside out, and there are tons of 'potential security sensitive' areas that have not been touched at all
• all security issues reported so far have been done as PDFs (or emails) which show the level of immaturity of TeamMentor's QA UnitTests (since these issues should had been reported or converted into UnitTests)
• No assurance that TeamMentor is a real 'secure application':
• We can start by the fact that there is no accepted/common definition of what a 'secure application' actually is
• There is no pressure from the market to deliver a 'secure application'
• There are no standards or regulations that apply to TeamMentor (which would raise the bar of the whole software industry)
• No customers putting real 'secure coding' pressure on us
• where they are prepared to pay more for those 'security features' or 'secure code'
• where they are prepared to drop the purchase due to 'lack of security' or 'secure code'
• where they are buying competitor products because they are more 'secure'
• where they want to deploy a 'secure version of TeamMentor' (which we have plans and ideas for how to do it, but have not had a need/request to build/document it)
• ironically the hardest and most high-exposed user of TeamMentor is us, since we use TeamMentor ourselves in a number of places (live TM sites, TM docs, Tm4Tm, etc...). We do this by design so that we are dogfooding TM and are the first ones to suffer if the threat/risk profile increases

This means that the real/honest answer to "Is TeamMentor 'Secure'?" is "I don't know! TeamMentor is as secure as we are aware of" (which is what happens with 99.9% of the apps out there (but not all of them will admit to it)). 

Basically, TeamMentor a real world app :) 

Now don't get from this that we (and I) don't spend significant resources with TeamMentor's security. In a way, having security knowledge (like I/we do) is a curse, since it is much harder to just 'ship code' when we can see its security implications. 

In fact, I would argue that as a percentage of code and developers, SI/TM is far better than just about everybody out there (and at least we are talking about it).

 

The ones that are 'better', tend to be:

• companies in heavily-regulated industries (Healthcare, Banks, Military, AirSpace), 
• very large companies, 
• companies (of all sizes) that have been hit before by malicious attacks (either publicly or financially)
• products with strong 'engineering' requirements where there is very little margin for error and software errors can be fatal (this is usually 'security by good engineering') 
• products/webapps with strong/mature CI environments (the ones where all developers have a 'deploy button')

The usual response when more 'security is needed' is usually the creation of a dedicated security team, which is given a big budget and allocated to the high-profile projects. But even then cases where significant resources and 'out-of-the-box' tools are available, the percentage of 'Security Skills' vs 'Developer head-count and lines of code written everyday' is not very high. 

In order to change the world and help the creation of 'secure applications', I think it is important to understand why this happen.

Why does a company/product that has everything it would need to write the most secure application in the world can't do it?

And why doesn't the market demand it?

The key problem is that it doesn't make business sense for SI at the moment to spend the huge amount of resources that would be required to significantly raise the level of 'TeamMentor Security' (and to do it without having a big impact of its usability).

Remember that if the market was buying it, SI would be able to deliver super secure apps (look at the talent and skills available).

We need to make 'security simple'. To make the process of writing 'secure code' the most practical and cost-effective way of creating commercial applications (Open source or proprietary)

This problem is why I'm spending so much time and energy in TeamMentor.

TeamMentor can be a big piece of the puzzle in solving this problem. Not only TeamMentor needs TeamMentor to be more secure, so does the rest of the industry :)

Btw, the fact that I can write posts like this (and the ones linked bellow) speaks volumes for SI's openness and 'focus in doing the right thing'. Unfortunately most software/web companies (including vendors of security products/services/SaaS) are not confortable in publicly/honestly talking about their efforts, challenges, problems and solutions. 

Related TeamMentor Security posts:

•  TeamMentor Vulnerability Disclosures: CSRF , ClickJacking and Get Password Hash from Browser Memory
• Couple XSS issues and XSS-By-Design (in TeamMentor)
• Interesting Encoding problem with TeamMentor Japanese translation
• Creating an TeamMentor Security Bounty Program
• Test and Hack TeamMentor server with 3.2 RC5 code and SI library
• FLOSSHack TeamMentor and the 'sausage making process' that is software/application (tons of other links)

See also this (long) post on My focus, O2 as the Open Platform, why IBM needs open standards and O2+AppScan research project, for more ideas on how the ability to create 'secure apps' (or 'security appliances') could be dramatically improved if the current tools could talk with each other, with consolidated/correlated views delivered to developers (in their IDE).