Shape Created with Sketch.
SecDevOps Risk Workflow
SecDevOps Risk Workflow
Free!
Minimum price
$5.00
Suggested price
  • 502

    Readers

  • 196

    Pages

  • 38,425

    Words

  • English

  • PDF

  • EPUB

  • MOBI

  • APP

SecDevOps Risk Workflow

This book is 64% complete

Last updated on 2016-12-11

About the Book

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, ideas and issues.

Based on real world applications of these ideas.

Table of Contents

  •  
    • Introduction
      • Book under construction
    • Change log
    • Contributions
    • Disclaimers
    • License
    • Printed version
    • This Book has a Dual Focus
    • Why GitHub and JIRA?
  • 1. Sec-DevOps
    • 1.1 Concepts
      • 1.1.1 SecDevOps or DevSecOps
      • 1.1.2 Don’t blame the developers
      • 1.1.3 Good resources on DevSecOps and SecDevOps
      • 1.1.4 History of Sec-DevOps
      • 1.1.5 Making the Sec part invisble
      • 1.1.6 Rugged Software
      • 1.1.7 Using Artificial Intelligence for proactive defense
      • 1.1.8 When Failed Tests are Good
      • 1.1.9 Why SecDevOps?
      • 1.1.10 Draft notes - DevOps
    • 1.2 Dev-Ops
      • 1.2.1 Disposable IT infrastructure
      • 1.2.2 Don’t kill the Ops
      • 1.2.3 Everything is code
      • 1.2.4 History of DevOps
      • 1.2.5 Horizontal DevOps
      • 1.2.6 In DevOps Everything is Code
      • 1.2.7 Infrastructure as code
      • 1.2.8 Patch speed as a quality metric
      • 1.2.9 Performing root-cause analysis
      • 1.2.10 Run Apps Offline
      • 1.2.11 When devs are cloud admins
    • 1.3 Sec DevOps patterns
  • 2. Risk Workflow
    • 2.1 Concepts
      • 2.1.1 Abusing the concept of RISK
      • 2.1.2 Accepting risk
      • 2.1.3 Can’t do Security Analysis when doing Code Review
      • 2.1.4 Creating Small Tests
      • 2.1.5 Creating Abuse Cases
      • 2.1.6 Deliver PenTest reports using JIRA
      • 2.1.7 Email is not an Official Communication Medium
      • 2.1.8 Good Managers are not the Solution
      • 2.1.9 Hyperlink Everything you do
      • 2.1.10 Linking source code to Risks
      • 2.1.11 Mitigating Risk
      • 2.1.12 Passive aggressive strategy
      • 2.1.13 Reducing complexity
      • 2.1.14 Start with passing tests
      • 2.1.15 Ten minute hack vs one day work
      • 2.1.16 The Pollution Analogy
      • 2.1.17 Triage issues before developers see them
      • 2.1.18 Using AppSec to measure quality
      • 2.1.19 Employ Graduates to Manage JIRA
      • 2.1.20 Risk Dashboards and emails
    • 2.2 For Developers
      • 2.2.1 5000% code coverage
      • 2.2.2 Backlog Pit of Despair
      • 2.2.3 Developer Teams Need Budgets
      • 2.2.4 Developers should be able to fire their managers
      • 2.2.5 Every Bug is an Opportunity
      • 2.2.6 Every project starts with 100% code coverage
      • 2.2.7 Feedback Loops
      • 2.2.8 Make managers accountable
      • 2.2.9 Risk lifecycle
      • 2.2.10 Risk profile of Frameworks
      • 2.2.11 Security makes you a Better Developer
      • 2.2.12 Test lifecycle
      • 2.2.13 The Authentication micro-service cache incident
      • 2.2.14 Using Git as a Backup Strategy
      • 2.2.15 Creating better briefs
    • 2.3 For management
      • 2.3.1 Annual Reports should contain a section on InfoSec
      • 2.3.2 Cloud Security
      • 2.3.3 Code Confidence Index
      • 2.3.4 Feedback loops are key
      • 2.3.5 Getting Assurance and Trust from Application Security Tests
      • 2.3.6 I don’t know the security status of a website
      • 2.3.7 Inaction is a risk
      • 2.3.8 Insurance Driven Security
      • 2.3.9 Is the Decision Hyperlinked?
      • 2.3.10 Measuring companies’ AppSec
      • 2.3.11 OWASP Top 10 Risk methodology
      • 2.3.12 Relationship with existing standards
      • 2.3.13 Responsible disclosure
      • 2.3.14 Third party components and outsourcing
      • 2.3.15 Understand Every Project’s Risks
      • 2.3.16 Using logs to detect risks exploitation
      • 2.3.17 Using Tests to Communicate
      • 2.3.18 Who is actually making decisions?
    • 2.4 For security Teams
      • 2.4.1 Defensible findings
      • 2.4.2 Do security reviews every sprint
      • 2.4.3 Risk Workflow for Software Vendors
      • 2.4.4 Create an Technology Advisory Board
    • 2.5 JIRA RISK Workflow
      • 2.5.1 Capture knowledge when developers look at code
      • 2.5.2 Describe Risks as Features rather than as Wishes
      • 2.5.3 Git for security
      • 2.5.4 Issue tracking solution
      • 2.5.5 Risk accepting threat model
      • 2.5.6 Storing risk issues on JIRA
      • 2.5.7 The smaller the ticket scope the better
      • 2.5.8 Key concepts
    • 2.6 JIRA Technologies
      • 2.6.1 Confluence
      • 2.6.2 JQL Query Language
      • 2.6.3 Jira components
      • 2.6.4 Copy and paste of images
      • 2.6.5 JIRA dashboards
      • 2.6.6 JIRA Filters
      • 2.6.7 JIRA Kanban boards
      • 2.6.8 JIRA Labels
      • 2.6.9 JIRA workflows
    • 2.7 Security Champions
      • 2.7.1 AppSec memo from God
      • 2.7.2 AppSec Technologies and tools
      • 2.7.3 Collaboration Technologies
      • 2.7.4 Conference for Security Champions
      • 2.7.5 If you have a heartbeat, you qualify!
      • 2.7.6 How to review Applications as a Security Champion
      • 2.7.7 Involvement in senior technical discussions
      • 2.7.8 Learning-resources
      • 2.7.9 Make sure your Security Champions are given time
      • 2.7.10 Making Security Champions AppSec Specialists
      • 2.7.11 Regular Hackathons
      • 2.7.12 Rewarding Security Champions
      • 2.7.13 Security Champions activities
      • 2.7.14 Security Champions Don’t Take it Personally
      • 2.7.15 Involve Security Champions in Decision-making
      • 2.7.16 Supported by central AppSec
      • 2.7.17 The Security Champions Concept
      • 2.7.18 Threat Modeling workshops
      • 2.7.19 Training Security Champions
      • 2.7.20 Weekly meetings
      • 2.7.21 What is a Security Champion and what do they do?
      • 2.7.22 What it takes to be a Security Champion
      • 2.7.23 To Add
      • 2.7.24 Security Champions
      • 2.7.25 Becoming a Security Champion
      • 2.7.26 Hack anything that moves
      • 2.7.27 BugBounties
      • 2.7.28 Developers we need YOU in AppSec
      • 2.7.29 Big market demand for AppSec Professionals
      • 2.7.30 If you don’t have a Security Champion, get a mug
      • 2.7.31 Public references to Security Champions teams
      • 2.7.32 Draft notes - Threat Models
      • 2.7.33 Capture the success stories of your threat models
      • 2.7.34 Chained threat models
      • 2.7.35 Developers need data classification
      • 2.7.36 Threat Models as better briefs
      • 2.7.37 Threat Model Case Studies
      • 2.7.38 Threat Model Community
      • 2.7.39 Threat Model Confirms Pentest
      • 2.7.40 Threat Model per Feature
      • 2.7.41 Threat Models mapped to Risks
      • 2.7.42 Draft notes - Threat Models
      • 2.7.43 When to do a threat Model
  • 3. Appendix
    • 3.1 Appendix A: Creating Workflow in JIRA
      • 3.1.1 Creating-a-Jira-project
      • 3.1.2 Step-by-step instructions
    • 3.2 Appendix B: GitHub book workflow
      • 3.2.1 Book creation workflow
      • 3.2.2 GitHub Leanpub hook
      • 3.2.3 GitHub online editing
      • 3.2.4 GitHub repos used
      • 3.2.5 Tool leanpub-book-site
      • 3.2.6 Atom, Markdown, Graphiz, DOT
    • 3.3 Appendix C: Security Tests Examples
    • 3.4 Appendix D: Case Studies
      • 3.4.1 File Upload
      • 3.4.2 HTML editing
    • 3.5 Appendix E: GitHub Issue worklfow
      • 3.5.1 GitHub Labels
      • 3.5.2 Reporting issues
    • 3.6 Draft Notes
      • 3.6.1 Draft notes - AppSec Tools
      • 3.6.2 Draft notes - Code Quality
      • 3.6.3 Draft notes - DevOps
      • 3.6.4 Draft notes - Developers
      • 3.6.5 Draft notes - Government
      • 3.6.6 Draft notes - PoCs
      • 3.6.7 Draft notes - Threat Models
    • 3.7 Audio Transcriptions
  • Notes

About the Author

Dinis Cruz
Dinis Cruz

Dinis Cruz is the CISO of the Photobox Group and an active OWASP contributor (Owasp Summits and O2 Platform Project)

Reader Testimonials

Elizabeth Lawler
Elizabeth Lawler

CEO @ConjurInc

So good to see security issues represented a) in plain language and b) as feature which is non-confrontational!

Daniel Cuthbert
Daniel Cuthbert

Co-author of the @OWASP ASVS standard

SecDevwhat? A great book on SecDevOps and why you should care.

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub

Leanpub is copyright © 2010-2018 Ruboss Technology Corp. All rights reserved.