Sunday 21 October 2012

Let's make this happen: "Investing in Developing Software Security Talent"

Mark posted yesterday an 'draft' idea which I think is GREAT!

Please read it at Investing in Developing Software Security Talent 

Although I think that Mark is on a great path, one that is consistent with his views of bringing developers to security (not security to developers), I have a couple comments on is proposed model :)

Here are my key proposed changes:

  • Separate the 'creating security talent' from Seconauts (ie 'separate code from data', or using a git analogy 'fork the main repository')
  • Expand the concept to include current Developers and Security Professionals
  • Create a financial model that is easy to implement, transparent and morally effective


This is how I would slice it:

Master version (the 'code'): "Developing Software Security Talent" Programme:" - Improving the Software Security Talent of a  new Generation of Software developers and 'code fixers'.

 The focus of this program is to help Developers or Security Professionals who want to write secure code or fix security vulnerabilities. The model proposed is one based on Internships and Mentorships.

  • The key objective is to create the next generation of developers who will:
    • know how to write secure code, 
    • work with the multiple SDL parties in the multiple secure coding/architecture activities and 
    • fix security vulnerabilities
  • The program will measure its success by the number of 'conversions' made over a period of time:
    • # of students that are now focus on secure coding
    • # of real-world developers who have added 'secure coding' to their skill set
    • # of developers (and job applications) that have 'secure coding' on its job spec
    • # of Application Security professionals who have acquired 'secure coding' skills and can talk with developers (in the developer's language) and are able (when requested) to sit down and fix code
  • A desired site-effect is the creation of an open community and 'high-quality body of work', that supports the millions of developers who need to write secure code worldwide, and ask 'secure coding questions' everyday.
  • How these 'conversions' are made, is not an important detail:
    • The 'Seconauts model' (descibed below) is just one way to achieve this goal

 Fork #1 (the 'data) "Seconauts participation in "Developing Software Security Talent" Programme:

 Seconauts will:

  • Find the sponsors and mentors
  • Handle the logistics (from payments, to selections, to contacts, to introductions, to public reporting, etc..)
  • Define the selection criteria, select the candidates and allocated them to the mentors
  • Define the Seconauts projects that will be worked on (by the candidates) and ensure that there is enough high-quality reviewers at hand to help with task allocation and questions raised (by the candidates)
  • Help and brief the Mentors (with clear definitions of what are the expectations and responsibilities of each party)
  • ...see mark's post for a specific details (like the number of mentors, what each one should do, etc...)

 Fork #2: XYZ Company ....

 Fork #3: XYZ University ....

 Fork #4: UK Government ....

 Fork #5: OWASP ....

 etc...

 Remember that the objective is to develop Security Talent, so it doesn't really matter how it is done, as long as it happens.

It is also important to take into account that some companies or organisations have a 'Not invented here' syndrome, and it is important to present them with ideas that they can consume, re-brand and execute

 Rough/Draf notes

 Since Mark's original post was in a 'Draf' mode', here are a bunch of semi-related notes and ideas that I had when reading and thinking about this.

Starting with some comments on the proposed model, I'm going to use SI (Security Innovation) as an example of a company that could participate on the mentoring and hiring activities (note that I have not spoken with the SI guys about this, it is just easier to have a specific example in mind):

  • I think that the amount paid to the 'candidate' should 'be defined' by the 'contracting party', in this case SI. Since SI would want to get the best talent, it can chose to pay more (this will also depend on the geographical location of the candidate)
    • Although I'm a big believer of openness, in this case, the 'financial arrangement' should be a private matter between SI and the candiate
  • I like the ideas to give the candidate some money, but this should ONLY be used to cover expenses (computer equipment, travel, hosting services, software, etc). In a similar way that I wrote on Why OWASP can't pay OWASP Leaders the moment the sponsorship money is used as 'payment to the candidate' the social contract between the organisation, the mentors and its participants is broken:
    • See previous point on how I'm NOT saying that the candidate should NOT be paid
    • I'm saying that the candidate SHOULD be paid, just not by this program (whose funds should only be used for 'expenses')
      • With this in mind, the candidate should be given $4000, where HE/SHE decides where to spend that money (and in time there would be a good number of documented examples of where others spent it)
      • Like I wrote in the problem of paying OWASP leaders and in the OWASP GSD Project (GSD = Get Stuff Done) proposal, the concept is one where the candidate cannot NOT pay himself, or any company/individual he/she is associated with (this is a great self-regulated system, and it would dramatically reduce the management, monitoring and 'expense approval' requirements / overhead)
  • This can be easily executed on a worldwide basis as long as the pieces are in place
  • I don't think that the 'need for the candidate to go everyday' to an office is a critical one.
    • It raises the bar and complexity of the arrangement
    • It goes against the model of the 'distributed' development environment that we have today in the 'GitHub' generation
    • Development is sometimes better done in isolation than in groups
    • Again, not saying that it shouldn't happen, just that it shouldn't be a big criteria
    • For example I have no idea of where some of my good colleagues at SI are (even when I talk to them by voice, email, github, code everyday). They could be somewhere in Europe , in the Boston or Seattle offices or in the middle of the US)
    • So I would change this requirement to be 'the candidate must have a physical connection with the mentors every week, which could range from hours to 5 days'
  • If the cost allocated to each candidate is $4000, then the sponsorship packages should be multiples of that:
    • $4k pays for 1
    • $8k pays for 2
    • $12k pays for 3
    • $20k pays for 5 .... etc...
  • This could be set-up on a recurring basis so that the sponsoring companies could view it as a recurring subscriptions.
  • I think that there should be NO requirement on either party regarding the next contracts (i.e. namely no obligation for the candidate to work 18 months for the mentoring company).
    • For example I would expect that if a candidate did a successful internship at SI, and he liked SI that he wanted to join the company, and SI liked his/her work so much that it would offer a job:
      • there would be no need for a 'mandatory 18 months contract'
      • the contract offerend by SI should be competitive and fair , 
      • such '18 months requirement to work for SI' would dramatically change the negotiation dynamics (putting a lot of power in the hands of SI) and would most likely leave a bitter taste in everybody involved
  • The focus should be on writing secure code and fixing existing code at Open Source projects, BUT we shouldn't have very high hopes that the code created will be of a very high standard since by definition these are inexperience 'secure development' developers (which will take more than 6 months to change)

And here is a brain dump of 'stuff' that needs some more thinking: 

  • it is going to be hard to find a significant number of mentors (which is a catch 22 ,since once the model is proven, they will be easier to find)
    • I would say that this is the hard part. At OWASP's Projects (see links below) we had a simpler workflow (which was project leader working with 2 reviewers) and it was REALLY hard to get good reviews created (it does take a lot of time to review something properly). I don't think it should be underestimated how much effort it will take from the mentors and helpers 
    • There is usually a great difference between the amount of people who will put their hand up and say 'I can do it, I can review that or mentor him/her' to the ones who will actually be able to do it (and sometimes it is not that the reviewer/mentor are not good enough, it is just that it takes a lot of time and effort to do it properly)
  • Creating a selection criteria and executing it will be hard, and the best way is to do it 100% in the open (learn from the OWASP seasons of code experience (see links below))
  • Expand the target audience (it should also be focused on current professional developers that want to get into application security). We need this NOW for developers that are coding today:
    • In fact most companies that write a lot of software need this TODAY for a number of their current dev teams
    • I don't like the word 'intern' is sounds like it is for a somebody leaving school (or university). This is why I used the word 'candidate' on this post. 
      • ex-students should be only one of the target audiences
  • The work created by the 'candidates' is most likely NOT going to be production quality (since by default they will be amateurs at it). Only experienced developers (with security awareness/knowledge) are able to create that. So let's not raise the expectations bar too high
  • Mark's maths are wrong:
    • $4000 will be barely enough to buy: a decent laptop, airfare expenses, hotels, hosting, software,etc... (over a period of 6 months). It will help if outside the US/UK, but we are talking about 800 USD per month (which is less than you get flipping burgers)
    • It also doesn't take into account all the back-office admin costs that it will take to make this happen (which I agree that shouldn't be paid from the $4000 sponsorship money)
  • I like this idea as a good way to get talent to work on Seconauts (but i can see some critics saying that this is just a cheap way to kickstart a community)
  • This is very similar to what happens on a number of companies, and it is called 'Interns' :)
    • in fact a number of OWASP members have such programs at their companies (which could be leveraged to kickstart this idea)
  • This will not work without operational support/staff, in fact the first thing to do should be to hire / appoint a project manager to run this (Mark is currently doing that role, but he will soon run out of time/energy)
  • There is already lot of mentoring happening at OWASP and I am personally involved in a couple of mentoring cases (not within an explicit framework, but achieving the same goals). So some of those efforts could be recycled to kickstart this idea
    • There are already a good number of targets for mentorship at OWASP, namely some newer OWASP leaders who are still getting their heads around WebAppSec
    • The irony is that OWASP would be the perfect place to do this, since it has the infrastructure, the funds, the community, the brand, etc...
    • That said, I think the concept is great, and since Mark is focused on it (and nobody is at OWASP), I will ask the Owasp community to support it and commit to at least 10k. I also will raise this idea at SI and see if they would like to participate


Bottom line: Good luck Mark

 More Secure Coding talent is something we desperately need, so I hope that this idea really comes into life and I'm happy to help as much as I can.



Why I have experience in making this comments 

(originally I had this at the beginning of the post, but I figured out, that this will only be relevant to the readers that are reading it all the way to the end):

-----------------------------------------------------------------------------


I'm going to comment on this as somebody who as already implemented a similar program at OWASP namely the OWASPs Seasons of code who had a similar number of moving parts and activities:



I was also very involved with Paulo Coimbra and the GPC on the management of OWASP projects, where we did a lot of thinking about this:

For reference, before Paulo Coimbra left OWASP, we were really close to implementing a similar program at OWASP (the idea was to start with getting reviewers involved into projects (in a 'Season of Quality') and then evolve it into mentorships).

And has Paulo's departure showed, without such back-office support it is impossible to do this. 

Btw, to give you an idea of the amazing work Paulo was doing on OWASP projects, take a look at https://www.owasp.org/index.php/OWASP_Projects_Dashboard_2.0 (you will be amazed). The good news is that we now have Samantha (Owasp new project manager) who is going to bring things back on track



Posted by at
Labels: