(My) OWASP BeNeLux Days 2017 Notes – Training Day

These are my notes from the OWASP BeneLux Days 2017 on “Secure Development: Models and best practices” by Bart De Win.

The goal of the training was about how to improve the structure of an organization in order to enhance the security of (IT) applications.

The talk was around the following topics:

  • Software assurance maturity models
  • Introduction to SAMM and hands-on exercise/s
  • Secure Development in agile development
  • Tip and tricks for practical SDLC
  • Sneak preview of SAMM 2.0

Software assurance maturity models

Today we build more and more complex software:

  • multi platform;
  • mobile version; cloud
  • same application using different technological stacks

75% of vulnerabilities are application related

The state of the Secure Development LifeCycle (SDLC) today:

  • on focus on bugs not an (architectural) flows
  • (very often) do pen test just before going in live

The goal of  the SDLC is to develop and maintain software in a consisted and efficient way with  standards-compliance security quality.

SDLC Cornerstones:

  • peoples
  • process
    • activities
    • control gates
    • deliverables
  • knowledge
    • standards&guidelines
    • compliance
  • tools&component
    • development support
    • assessment tools
    • management tools

Introduction to SAMM and hands-on exercise

SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks faced by an organization.

Other standards/frameworks that are in the same space as SAMM:

SAMM consists in 4 business functions each one containing 3 security practices. Each security practice have 4 maturity levels (from 0 to 3):

Each (SAMM) maturity level defines the following attributes:

  • objectives
  • activities
  • results
  • success metrics
  • cost
  • personnel
  • related levels

How do we start with SAMM: It is possible to start with the SAMM Toolbox Excel file in order to do an initial assessment for each of the  security processes (the Excel file will compute the maturity level). This initial assessment will help you to plan the improvements.

Secure Development in agile development

There are a mismatch between the agile development goal/s and the security goal/s

agile dev security
  • speed and flexibility
  • short cycles
  • limited documentation
  • functionality driven
  • stable and rigorous
  • extra activities
  • extensive analysis
  • non functional

Introducing security into agile development is not easy task and especially there is not a standardized way of doing it.

Some ideas and hints:

  • make security a natural part of the process
  • capture security requirements, policies and regulations in user stories

Sneak preview of SAMM 2.0

  • planned for end of next year.
  • model revision
  • more metrics
  • application to agile
  • benchmarking