Difference between revisions of "SAMM - Education & Guidance - 2"

From OWASP
Jump to: navigation, search
m
m
Line 9: Line 9:
  
 
<div style="width:100%; float:left;">
 
<div style="width:100%; float:left;">
'''Objective: Educate all personnel in the software life-cycle with role-specific guidance on secure development'''
+
{{SAMM-ObjectiveG2|name=Education & Guidance|obj=Educate all personnel in the software life-cycle with role-specific guidance on secure development}}
 
   <div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
 
   <div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
 
====Results====
 
====Results====

Revision as of 19:10, 2 May 2009

250px-OpenSAMM_logo.png For the latest project news and information,
join the mailing list and visit the OpenSAMM website.

EG1.png EG2.png EG3.png

BackButton.png

Education & Guidance - 2

Objective: Educate all personnel in the software life-cycle with role-specific guidance on secure development

Results

  • End-to-end awareness of the issues that leads to security vulnerabilities at the product, design, and code levels
  • Build plans to remediate vulnerabilities and design flaws in ongoing projects
  • Enable qualitative security checkpoints at requirements, design, and development stages
  • Deeper understanding of security issues encourages more proactive security planning

Add’l Success Metrics

  • >60% development staff trained within past 1 year
  • >50% management/analyst staff trained within past 1 year
  • >80% senior development/architect staff trained within past 1 year
  • >3.0 Likert on usefulness of training courses

Add’l Costs

  • Training library build-out or license
  • Security-savvy staff for hands-on coaching

Add’l Personnel

  • Developers (2 days/yr)
  • Architects (2 days/yr)
  • Managers (1-2 days/yr)
  • Business Owners (1-2 days/yr)
  • QA Testers (1-2 days/yr)
  • Security Auditors (1-2 days/yr)

Related Levels

  • Vulnerability Management - 1
  • Design Review - 2
  • Secure Architecture - 2

Activities

A. Conduct role-specific application security training

Conduct security training for staff that highlights application security in the context of each role’s job function. Generally, this can be accomplished via instructor-led training in 1-2 days or via computer-based training with modules taking about the same amount of time per person.

For managers and requirements specifiers, course content should feature security requirements planning, vulnerability and incident management, threat modeling, and misuse/abuse case design.

Tester and auditor training should focus on training staff to understand and more effectively analyze software for security-relevant issues. As such, it should feature techniques for code review, architecture and design analysis, runtime analysis, and effective security test planning.

Expand technical training targeting developers and architects to include other relevant topics such as security design patterns, tool-specific training, threat modeling and software assessment techniques.

To rollout such training, it is recommended to mandate annual security awareness training and periodic specialized topics training. Course should be available (either instructor-led or computer-based) as often as required based on head-count per role.

B. Utilize security coaches to enhance project teams

Using either internal or external experts, make security-savvy staff available to project teams for consultation. Further, this coaching resource should be advertised internally to ensure that staff are aware of its availability.

The coaching staff can be created by recruiting experienced individuals within the organization to spend some percentage of their time, around 10% maximum, performing coaching activities. The coaches should communicate between one another to ensure they are aware of each other’s area of expertise and route questions accordingly for efficiency.

While coaches can be used at any point in the software life-cycle, appropriate times to use the coaches include during initial product conception, before completion of functional or detailed design specification(s), when issues arise during development, test planning, and when operational security incidents occur.

Over time, the internal network of coaching resources can be used as points-of-contact for communicating security-relevant information throughout the organization as well as being local resources that have greater familiarity with the ongoing project teams than a purely centralized security team might.






Additional Resources