I was thinking today about the areas where security (and secure development) can add value to the SDL and hit on the concept of Security-Driven-Development (SecDDev)
SecDDev is security coding activities driven by security focused developers (which is much more productive than the current security as TAX model we have today)
The way I got into this idea was that I was thinking about one of the TeamMentor (TM) refactorings that I would like to see happening, namely the need to create a 'read-only' version of TeamMentor for sites like TeamMentor.net
This would be a version of TM that has no ability to change the Libraries and Article's content, which is a great way to achieve security, since it is harder to exploit a feature when the code is not there :)
What is interesting on this scenario ('Read-Only TM') is that the business requirement ('have a rock-solid version of TM hosted in TeamMentor.net that can be sold to customers') doesn't NEED this isolation! It possible (and easier) to deploy a version that has the full (very powerful) TM editing capabilities and hope that those features are not exploited, or that none of the editors and admin users delete anything (see missing iOS Library incident). This lack of business requirement, means that unless there is an additional driver to create this 'read-only' version, it won't happen (which explains why we end-up with the bloated 'security-vulns-rich' applications we have today).
Now there is a good business case for 'application isolation and robustness' but those tend to be fuzzy concepts which are hard to measure. For example, in this kind of activities, there is a massive lack of external recognisable metrics, where the site looks and behaves the same before and after the refactoring (until it is able to sustain an exploit/mistake or massive traffic spike). In fact these changes tend to introduce massive side effects (see 'About' page broken due to ClickJacking protection)
And this is where the idea of SecDDev occurred to me where I was thinking 'if only I had a security focused development guy/team that would help me in doing this refactoring'.
Since that person (the Security-Driven-Developer) would have has as part of his job spec the "improvement of TM's security" (where that is just one of the (many) roles and responsibilities that I have in TM's SDL) he/she would be much more focused into making it happen.
Creating a read-only version of TM, which in practice means the isolation of the read-code and the edit-code into separate sites/areas which can be easily removed, is a good example of an important-but-not-urgent activity that would make a massive difference in TM's overal security architecture.
To complicate matter worse, it is hard to make this type of code changes. Even after all my efforts to develop TM in a modular architecture, the technologies and frameworks used (Html, Javascript, jquery, .Net) promote/reward tight integration and inter-dependencies (for example it would be 'security by obscurity' to remove the edit-code from the front-end, but leave it all on the webservices back-end).
This is why when you look at most apps, the code is always in 'development activities blocks' instead of 'security focused blocks'
Another area that SecDDev would have to focus a lot is on UnitTests, since they would struggle to make/propose any meaningful change without the support and cushion of a solid Unit/Integration test suite. And anybody that gives me a working UnitTest for TM, is somebody that is adding value to me as a developer! (in fact, SI will even pay for those Unit Test :) )
Another interesting 'political' problem happens when the product managers/owners have a lot of power and want to 'lock-in the customer' into a product's technology. For example, a real secure way to create a 'read-only' version of TeamMentor, would be to remove 99% of its code (on both client and server sides) and built a flat-file version (i.e. pure HTML) protected by a simple OAuth-based authentication/authorisation layer (which could even be done as an external service). But this would mean that the 'TeamMentor' product would 'disappear' and all that would be left would be the Content. The good news (for TeamMentor) is that since SI's center of gravity is on the 'Content + Services side' there are no problems in following what is the best engineering route, but when you look at why some applications/websites are so bloated (and don't like to allow the exporting of its data), you will usually find that it happens due to political/strategic decisions instead of engineering ones)
Finally, where are we going to get those SecDDevs from? Well Mark has a good idea for that, see: Let's make this happen: "Investing in Developing Software Security Talent"
