(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

5 (software) security books that every (software) developer should read

I must admit that the title is a little bit catchy; a better title would have been “5 software security books that every developer should be aware of“. Depending on your interest you might want to read entirely these books or you could just know that they exists. There must be tons of software security books on the market but this is my short list of books about software security that I think that each developer that is interested in software security should be aware of.

Hacking – the art of exploitation This book explains the basics of different hacking techniques, especially the non-web hacking techniques: how to find vulnerabilities (and defend against)  like buffer overflow or stack-based buffer overflow , how to write shellcodes, some basic concepts on cryptography and attacks linked to the cryptography like the man-in-the-middle attack of an SSL connection. The author tried to make the text easy for non-technical peoples but some programming experience is required (ideally C/C++) in order to get the best of this book. You can see my full review of the book here.

Iron-Clad Java: Building secure web applications This book presents the hacking techniques and the countermeasures for the web applications; you can see this books as complementary of the previous one; the first one contains the non-web hacking techniques, this one contains (only) web hacking techniques; XSS, CSRF, how to protect data at rest, SQL injection and other types of injections attacks. In order to get the most of the book some Java knowledge is required. You can see my full review of the book here.

Software Security-Building security in  This books explains how to introduce the security into the SDLC; how to introduce abuse cases and security requirements in the requirements phase, how to introduce risk analysis (also known as Threat Modeling) in the design phase and software qualification phase. I really think that each software developer should at least read the first chapter of the book where the authors explains why the old way of securing application (seeing the software applications as “black boxes” than can be protected using firewalls and IDS/IPS) it cannot work anymore in the today software landscape. You can see my full review of the book here: Part 1, Part 2 and Part 3.

The Tangled Web: A Guide to Securing Modern Web Applications This is another technical book about security on which you will not see a single line of code (the Software Security-Building security in is another one) but it highly instructive especially if you are a web developer. The book presents all the “bricks” of the today Internet: HTTP, WWW, HTML, Cookies, Scripting languages, how these bricks are implemented in different browsers and especially how the browsers are implementing the security mechanism against rogue applications. You can see my full review of the book here.

Threat modeling – designing for security Threat modeling techniques (also known as Architectural Risk Analysis) were around for some time but what it has changed in the last years is the accessibility of these technique for the software developers.  This book is one of the reasons for which the threat modeling is accessible to the developers. The book is very dense but it  suppose that you have no knowledge about the subject. If you are interested in the threat modeling topic you can check this ticket: threat modeling for mere mortals.

Book review: Software Security: Building Security in – Part III: Software Security Grows Up

This is a review of the third part of the Software Security: Building Security in book. This part is dedicated to how to introduce a software security program in your company; it’s something that I’m much less interested than the previous topics, so the review will be quite short.

Chapter 10: An Enterprise Software Security ProgramSecuritySoftwareBookCover

The chapter contains some ideas about how to ignite a software security program in a company. The first and most important idea is the software security practices must have a clear and explicit connection with the with the business mission; the goal of (any) software is to fulfill the business needs.

In order to adopt a SDL (Secure Development Lifeycle) the author propose a roadmap of five steps:

  1. Build a plan that is tailored for you. Starting from how the software is done in present, then plan the building blocks for the future change.
  2. Roll out individual best practice initiatives carefully. Establish champions to take ownership of each initiative.
  3. Train your people. Train the developers and (IT) architects to be aware of security and the central role that they play in the SDL (Secure Development Lifeycle).
  4. Establish a metric program. In order to measure the progress some metrics a are needed.
  5. Establish and sustain a continuous improvement capability. Create a situation in which continuous improvement can be sustained by measuring results and refocusing on the weakest aspect of the SDC.

Chapter 11: Knowledge for Software Security

For the author there is a clear difference between the knowledge and the information; the knowledge is information in context, information put to work using processes and procedures. Because the knowledge is so important, the author prose a way to structure the software security knowledge called “Software Security Unified Knowledge Architecture” :

Software Security Unified Knowledge Architecture
Software Security Unified Knowledge Architecture

The Software Security Unified Knowledge Architecture has seven catalogs in three categories:

  • category prescriptive knowledge includes three knowledge catalogs: principles, guidelines and rules. The principles represent high-level architectural principles, the rules can contains tactical low-level rules; the guidelines are in the middle of the two categories.
  • category diagnostic knowledge includes three knowledge catalogs: attack patterns, exploits and vulnerabilities. Vulnerabilities includes descriptions of software vulnerabilities, the exploits describe how instances of vulnerabilities are exploited and the attack patterns describe common sets of exploits in a form that can be applied acc
  • category historical knowledge includes the catalog historical risk.

Another initiative that is with mentioning is the Build Security In which is an initiative of Department of Homeland Security’s National Cyber Security Division.