Skip to content

Latest commit

 

History

History
96 lines (63 loc) · 6.72 KB

1.Introduction.md

File metadata and controls

96 lines (63 loc) · 6.72 KB
Raw

Introduction

This is a book about making developers more productive, embedding security practices into the SDL and ensuring that security risks are accepted and understood.

The focus is on the Dev part of SecDevOps, and on the challenges of creating Security Champions for all DevOps stages.

All content is released under an Creative Commons license (CC BY 3.0) and the GitHub repository Book_SecDevOps_Risk_Workflow contains all text and ideas.

This book is based on successful and unsuccessful real world applications of these ideas. Any feedback, suggestions or comments will be highly appreciated (please open an issue for them)

Book under construction

There are multiple sections of this book that are still on 'draft' mode (as you can see by the rest of this introduction, which still needs a serious rewrite)

Here are some ideas that I feel will be good on this intro section.

  • aimed at: Developers, Security Professionals, Risk Practitioners, Software architects, Security Champions
  • presented Risk Workflow
    • is key make security decisions explicit
    • based on JIRA, but it can also be made to work on GitHub
    • provides a framework to make development/security decisions accountable, visible and understood
    • the 'Accept Risk' button changes the dynamics & makes the risks/information real
  • big focus on the role of Security Champions and the automation of Security Knowledge and Workflows
  • practical examples of SecDevOps and DevOps workflows/tools will be shown (git workflows, docker, travis, Jenkins, others...)
  • objective is to make SecDevOps into DevOps of just Dev (with SECurity and OPerationS happening behind the scenes, automatically in the CI pipeline)
  • based on real world application of these ideas
    • objective to scale this ideas and ask for feedback
  • The JIRA Risk workflow fits as the way to implement SecDevOps
  • Lots of good thinking on SecDevOps
  • See this issue for more details on this decision Issue 15
  • Book is positioned on adding security to DevOps with a focus on Risk acceptance and Code Analysis workflows

Here is good definition of SecDevOps is:

SecDevOps (Securing DevOps) The scenario here is an organisation is embarking on a DevOps and agile ways of working adoption journey. There is concern about security and we are asked to advise on how to embed security into the DevOps style of operation. And this means embedding and ensuring "secure by design" discipline in the software delivery methodology using techniques such as automated security review of code, automated application security testing, educating and empowering developers to use secure design patterns etc.

(previous) Introduction

This book will give you a solution for the following common problems inside AppSec and Development teams:

  • "How do I get my manager to take security issues in my app seriously"
  • "How do I get time to spend on non-functional requirements and refactoring"
  • "We are product-driven development team and don't have time for anything that is not customer-driven"
  • "We know our current development, testing and deployment environment is highly inefficient, but how can we prove that to management"
  • "We constantly do hacks and compromises before deadlines, but we can't measure its real impact, and how they always tend to be a false economy"

I find that collectively developer teams know what needs to be done, but they are not usually listened to or empowered to make important decisions about their development priorities and environment. There are always side effects of rushed code and hacks.

This book contains the materials created while using JIRA to manage RISK and measure those side effects

All information presented is based on real work experience in creating, implementing and deploying multiple JIRA RISK Projects.

There are 2 main target audiences is AppSec and Developers.

Why AppSec

AppSec (Application Security) has massive problem of how modern developers work and therefor how to communicate with developers

I created this workflow in order to solve this problem

Why Developers

Because developers can use this workflow to control their development workflow, and handle the 'backlog pit of despair' problem.

Why JIRA

  • It's market penetration (most companies I work for use JIRA)
  • JIRA and GitHub are the only Issue tracking system that I have seen that have the kind of features that are required for the kind of complex workflows that are needed
  • JIRA can be integrated with various other tools used in Agile/DevOps/CI allowing for further integration. (ie future ready)
  • comment that this is very different from the JIRA Risk plugins that exist current in the JIRA marketplace

Why not infoSec

InfoSec tickets don't tend to work that well with JIRA tickets. InfoSec usually has their tools and dashboards to manage (for example Firewalls, Anti-Virus detections, Active Directory issues)

Could these same techniques be used to manage other types of Risk. Yes but since I don't have that much experience with it, I will leave it to the reader.

A> AppSec is about: code, apps, CI, secure coding standards, threat models, frameworks, code dependencies, QA, testing, fuzzing, dev environments, DevOps, ….

A> InfoSec is about: Networks, Firewalls, Server security, Anti-virus, IDS, Logging, NOC, Policies, end-user security, mobile devices, AD/Ldap management, user provisioning, DevOps, ….

Note that if your ‘InfoSec’ team/person cannot code (and would not be hired by the Dev team), then that is NOT AppSec. InfoSec is very important, but it is key to understand its limitations when there are no coding skills in that department (there are a number of conversions and activities that can only be done by professionals that understand development)

Is this view too restrictive? Can someone be a valuable AppSec specialist without actually being able to code. Would these qualities compensate for lack of coding skills:

  • understanding modern development,
  • being able to explain and discuss issues with developers,
  • being able to explain, configure, and use tools

Why I'm writing this book

  • my struggle to communicate with developers
  • explain how I arrived at the JIRA Risk project workflow
  • brief O2 Platform history, and how I used to communicate with developers in a common language (in O2 it was via O2 scripts and mini-tools)
  • O2 Platform REPL and how it changed how I code
    • what IDEs should be doing for developers and AppSec professionals