Hi everyone,

I have started working on producing a guide for developers which focuses on a small set of principles for secure development.

I have completed some of the groundwork which can be seen here: http://securityninja.co.uk/blog/?p=132 that blog post details my reasoning behind the guide and more specifically how I feel current approaches such as the "top x" lists aren't working.

I have an article being publish in (in)secure magazine next month which expands on my reasoning and also defines exactly what each of the principles mean to developers.

If anyone wants to contribute to the development of the guide then please get in touch.

SN

I believe this is too high level for developers. If your target is security guy that want to learn what to teach about secure dev principles, I think it's okay.
For a developer, I would rather use extensive examples (this is how ppl develop nowadays), talk about frameworks, etc. If you say "output encoding" they will say WTF is that? Will they do it right? I'm sure than most of devs won't do it correctly since they won't get what it actually means.


And also, for reference, *FOR DEVELOPERS*, I would rather use MITRE/SANS Top 25 than the OWASP Top Ten and Whitehat stuff... at least, Top 25 target developers.

nEUrOO -- http://rgaucher.info -- http://twitter.com/rgaucher



Edited 1 time(s). Last edit at 04/22/2009 10:57AM by nEUrOO.

I appreciate your point but as I said in the original post in this thread what I have in that blog post is the very first steps. So I agree, the blog post is too high level but it was never actually intended to be an in depth discussion about each principle.

Based on the work I'm publishing next month the developers I have spoken with (23 in total, including attendees of the local owasp chapter meeting) have agreed that a small set of secure development principles is actually more useful than a list of vulnerabilities if they are explained correctly. My article will be much more in depth for each principle including examples of code written insecurely and then followed by a secured example.

I want to develop the guide to keep secure development simple, we are given more and more lists such as the three I mentioned in the blog yet we see more and more vulnerabilities such as SQL Injection being exploited.

Something isn't working and I'm trying to do something about this which is more than most people are doing.

SN



Edited 1 time(s). Last edit at 04/22/2009 12:20PM by securityninja.

PMO, compliance, internal audit, and executives all want the same thing for risk management: to identify risks and get proper security classifications around them.

developers don't matter; they just naturally make mistakes. the best way to train them is to demo the exploits before they start coding, or better -- iteratively (so that they know what to think about). the best way to help them is with boundary objects -- http://blogs.msdn.com/sdl/archive/2009/03/19/why-the-new-sdl-threat-modeling-approach-works.aspx
a good boundary besides DFD review could be secure code review
http://www.owasp.org/index.php/Man_vs._Code
although i would argue that there are many others, but vary from project to project (defect tracking systems are fairly universal though). i am a fan of continuous integration, but i don't think you need a build server or complex repo setup to do CI extremely cost/resource-effectively.

modern platforms have a rich set of security protections in the base-class libraries. however, third-party components are very popular and often not only contain security vulnerabilities, but also introduce new classes of software weaknesses. i think it would be helpful to show developers where operators can add value and where they can't -- operators can protect against XSS, CSRF, HRS, PT, PRL after-the-fact, but operators can't really protect against Auth[N|Z], SQLi, or domain logic problems using blacklist-whitelist technology or hardened application configurations.

there's a few missing pieces in the common platforms (JEE, C# ASP.NET); moreso for Struts/Struts2/JSTL/JSF/Hibernate/Spring than for ASP.NET 3.x+. ASP.NET can easily fix encoding issues by using the Anti-XSS library, but JEE requires tons of work as it only includes URL encoding out-of-the-box (although OWASP ESAPI can do wonders to a JEE project). JEE has a few other issues such as leakage of business tier unhandled exceptions into the client-tier (which would rarely ever happen in modern ASP.NET and IIS scenarios). JEE can be super bad at transforms (XSLT, XPath, enveloped signature), and neither ASP.NET or JEE includes XML encoding. also missing is LDAP parameterizations, and JEE even misses syscall and XPath.

it's simple for operators to run through the CIS benchmarks and SANS SCORE checklists ... but most can't even seem to implement SSL/TLS correctly and remember to upkeep their certs. i say that people like securityninja should be helping out operators, not developers -- and people like neuroo should be helping out developers and not operators. we need both to be working on these problems and there is still much to teach and learn.

I just reading this book: http://www.microsoft.com/learning/en/us/books/8753.aspx and I think that can help ...

http://www.security-net.biz/