iso27diy-corp/Corpus/Information Security/(ISC)² meeting on Secure Software Development.md

2.3 KiB
Raw Permalink Blame History

February 2, 2022

Relevant ISO 27001 clauses/controls:

R.vanderveer@sig.eu @robvanderveer www.sig.eu/security Contributor to ISO standards

Maturity

  • Level 2 = Testing
    • late in the process, rework creates stress, separate from the primary development process allows it to be postponed
  • Level 3 = Treat Modelling
    • Hygiene Approach = List of Dos and Donts - requirements , guidelines, training
  • Level 4 = Scanning tools (code scanning, dependencies)
  • Level 5 =
    • Tool integration and dashboard, expert tool config, expert code/design/privacy review, organization guidance, team coaching, culture change

OWASP SAMM is a good process framework. Also has self assessment tools to establish base level. owaspsamm.org owaspsamm.org/guidance/agile Recommended: OWASP ASVS and MASVS OWASP security wayfinder

OpenCRE.org provides an interactive content linking platform for uniting security standards!

Key building blocks of successful secure software development:

  • Everybody should own the problem (product owners, management, teams)
  • Collaboration between security experts and developer
  • Tailored training, based on principles
  • Provide standard software bv uil ding blocks and frameworks
  • Threat modeling and situational Testing against these threats
  • Automated testing
  • Manual verification against checklists
  • Privacy and Maintainability
  • Integrate (single glass pane of findings)
  • Cross-team knowledge exchange (Security Guild)
  • Legacy code Basically all the code that was driven when you had a lower security maturity level.

Changing responsibilities in Software Development

Martin Knobloch @knoblochmartin Martinknobloch@owasp.org

Everything you can put in a repository can be considered source code.

From cascaded development to extreme programming meant moving away from a linear process to a chaotic process

Security is everybodys responsibility. Shared responsibility means having a common/shared view (unified dashboard) on vulnerabilities. Monitor for trends, and correlations between business events (process and tools changes, new functionality, etc.) and changes in the security posture