diniscruz / book_secdevops_risk_workflow Goto Github PK

http://blog.diniscruz.com/2012/04/security-evolution-into-engineering.html

• The key is to have Test APIs that know how to reach particular parts of the application (so that you can put the payloads)
• The tools to use depend on the level of maturity of your existing pipeline.
• You should be looking at static analysis (SAST), Dynamic testing (DAST) and Interactive Application Security Testing (IAST)
• DAST
  • Proxying traffic though OWASP ZAP
  • key is for existing e2e/integration tests to have enough coverage so that the ZAP tool can fuzz it (you need powerful Test API and DSLs)
  • see zaproxy/community-scripts
  • number of other commercial vendors in this space (Burp, Netparker, WebInspect, acunetix, Qualis, IBM AppSec) including pure SAAS offerings like WhiteHat Sentinel
  • for DAST it is key that complete test/QA environments (for each full test execution stute) can be spun up and destoyed (after some analsysis of it)
• SAST
  • Opensource: FindBugs, PMD,
  • Commercial
    • tools: Checkmarks, Fortify, IBM AppScan Source,
    • SAAS: Codiscope Jacks, Veracode (SAAS)
• (add other tools in this spaces)
• Start small and automate everything. The hard part of using the tools is getting the pipeline working (which is why it is good to start with Open Source tools, before sending £100k+ on commercial tools)
• See Achieving Secure Continuous Delivery presentation, done at OWASP London
• All tools (open source and commercial) will need to be customised in order to allow them to have enough visibility into the apps. There is no 'silver bullet' out there which will work really well with your apps.
  • The OWASP O2 Platform has a large number of PoCs and mini-tools that help with this kind of customisations
  • ThreadFix is a good tool to aggregate results created by multiple engines

"SecDDev - Security Driven Development" http://blog.diniscruz.com/2012/10/secddev-security-driven-development.html

for example this workflow:

from http://blog.diniscruz.com/2016/06/using-jira-to-manage-risks-v10-owasp.html

(from Microsoft SDLC )

Requirements & Analysis

• The driving force here is market/business goals
• CTO/CISO should be monitoring this phase. Early insights into what direction the business is moving can help to mitigate potential security implications of new products and features.
• Start reviewing resources needed for creating the AppSec team

High Level design

• AppSec team lead responsible for identifying Static analysis and other tools appropriate for the environment.
• Champion that Tools should be incorporated into the build environment
  • run as part of the build process
  • output goes to DB (later used to feed dashboards)
  • output should be filtered so previously found issues are not duplicated
  • tag should be added to identify when issue first found (can be used in dashboard for days to resolve)
  • Dashboard requirements initial planning
  • Security issues tracking system initial requirements defined
  • Issue tracking system identified (JIRA) and requirements defined
  • Issues/bugs found by static tools should auto generate tickets (filtering to prevent duplictes)
  • Issues/bug should feed to dashboard

CTO/CISO to identify skills for AppSec team (may change in next phase)

• Identify team lead
• Team lead main job is to:
• Evangelize AppSec to the PM/DEV/Test Team
• Identify Security Champs
• Assign tasks to Security Champs such as reviewing issues found, initiating threat modeling, which may be updating existing threat models or creating new
• Team lead works with Security champs, sets up weekly/bi-weekly meetings. Summarize finding and report to LT (leadership team)
  I am going to suggest an outline using the first on the left graph. There are many other processes which might be better suited to your approach, but it is a place to start.

Detailed Design

(to do)

Construction & Assembly

(to do)

Independent Verification

(to do)

Release & Maintenance

(to do)

Some general comments: (no particular order)

• Title may need some work, needs to have a bit more “eye Candy”
• AppSec road map using JIRA
• No mention of mobile (un-necessary access to mobile features, (GPS, contacts, camera, etc) or IoT security (transport security, tampering, etc) issues.
• There is little reference to privacy/data protection which has a significant security component (encrypting data, access controls, etc.

While doing the review sessions and adding my comments I can't help to notice that the contents are more about 'how to set up a SecDevOps' organisation and not only about 'Jira Risk Flow'.

Should we consider this a scope creep and refocus or do you want this to be the natural flow of the book and maybe change the title to be more in line?

Specially for the Fix state since it is based on kanban

https://help.github.com/articles/creating-a-project/

"ability to write Tests in TTD (with CI workflow) is more important than the language"

see thread https://twitter.com/zeroXten/status/786356626060087296

https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-developers/5000-percent-code-coverage.md

@Ambg05 can you review this file?

I made some changes but I'm sure the working can be improved

thx

• key part of the SDL
• how to automate
• start to have good commercial support http://www.marketwired.com/press-release/sourceclear-brings-secure-continuous-delivery-to-the-developer-workflow-2166001.htm

• start by describing what JIRA is, adoption rate, where to find more information (Links) and why you chose JIRA."

as per this thread https://twitter.com/koehntopp/status/788346842111246336

Add content to https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/tree/master/content/2.Risk-workflow/Security-champions

Ideas to cover:

• idea of 'Adopt an OpenSource project'
• work with Universities and OWASP chapters
• understand that this is a massive problem, since we need 10k+ of these AppSec professionals (ASAP)

for https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Concepts/Abusing-the-concept-of-risk.md

• add something regarding privacy, if an app is compromised how do you protect the data since that is the reason for needing security. Perimeter security only goes so far, bottom line is to protect the data.
• mention methods such as STRIDE, CIA, etc. to help with defining the risks
• make a reference to the appendix where the concepts of RISK and behaviors is expanded

Mario Robles mentioned:

it’s very nice to see your Jira workflow very similar to the one I’ve been working on, one thing that I would suggest is including custom “resolutions” consistent to the status in the kanban so you can add the Resolution field in the Screen used for closing the issues:

Here are the Resolutions I have configured in the JIRA RISK Workflow:

• not for the faint of heart, but can be a really good defence in depth for really hostile (and under attack) execution environments

here is a description from the https://jscrambler.com tool (which is a lead player in this field)

JavaScript protection. Jscrambler is all about JavaScript enabled environments protection. With Jscrambler's first layer of protection, using Obfuscation techniques, we provide you polymorphic JavaScript: each time you request a protection, you will get a different source code.

You can go even further applying Control Flow Flattening which will create also different application flows. Just with this layer you will prevent any attacker to keep knowledge of your application internals.

On top of this first layer you can get RASP (Runtime Application Self-defending Protection) features which right now only applies to JavaScript, but soon will also enable you to get notified about DOM tampering and JavaScript poisoning (browser global objects and event handlers) or even remove DOM injections on client-side.

When we say

It is really time for application developers to stop believing that they are protected by perimeter defenses and fix the real issue, which is “Stop writing broken code”

is this really fair of developers?

I don't think developers want to write broken code (i.e. code with security issues). I think the problem is more to do with the developer's workflow than with a desire to write vulnerabilities.

related posts:

• Secure coding (and Application Security) must be invisible to developers
• A comment on "Making Security Invisible by Becoming the Developer's Best Friends"
• Thoughts on Security Authentication and on adding security into an SDL

(related to #53)

the idea is to create the graphs for this diagrams as png (which are what leanpub supports)

Need to talk about why developers avoid appsec people

"Absolutely, DevOps is full of code (most don't realise it). Every script/config exists in git and needs SDL"

https://twitter.com/zeroXten/status/786341430964912129

This quote is a good representation of the position of the book

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

(from https://twitter.com/ElizabethLawler/status/789495925861384192)

• commercial product more focused on Threat Modeling, but since it now has an 'Accept Risk' button, it could be used for the Risk Workflow
  • integrates with JIRA (can be used to create and manage issues)
  • very active development and lead by known AppSec security experts
  • would be interesting in seeing it's cost when compared with JIRA (in an environment that doesn't have JIRA)
• there is an community edition: https://community.iriusrisk.com/

from #59

• Line 27: JIRA & RISK. Note: Acronyms need to be defined on first use
• Line 31: There are 2 main target audiences is AppSec and Developers. Note: Need to state clearly what #1 & #2 are.
• Line 31 “AppSec”. Note: Maybe add ‘team’
• Line 35: “AppSec (Application Security) has massive problem of how modern developers work and therefor how to communicate with developers” Note: Needs better structure.
• Line 41: “Because developers can use this workflow to control their development workflow, and handle the 'backlog pit of despair' problem”. Note: Poorly structured sentence.
• Line 46: “features” Note: What are the key features maybe add two or three bullets
• Line 47: “tools”. Note: Provide a few example names of the tools
• Line 50: “InfoSec”. Note: Needs to be defined
• Line 52: “InfoSec tickets don't tend to work that well with JIRA tickets”. Note: Few bullets as to why they don’t work
• Line 54: “Yes but since I don't have that much experience with it, I will leave it to the reader”. Note: Too subjective, what are the drawbacks what types of risks could InfoSec tickets be used for, a few bullets.
• Line 57: “code, apps, CI, secure coding standards, threat models, frameworks, code dependencies, QA, testing, fuzzing, dev environments,” Note: Use bullets.
  Line 57: “DevOps”. Note: What is this?
• Line 61: “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)”. Note: Very unclear what point you are trying to make, consider re-writing
• Line 63: “Is this view too restrictive?” Note: If you ask a question provide an answer.
• Line 63: “Can someone be a valuable AppSec specialist without actually being able to code.”
  Note: Answer here is a qualified yes.
• Line 71-73: Define 02, REPL, & IDE

related to 'Expand on 'The 5÷ of code that needs to be secure' #188

• No new plugins to install
• already exists out of the box

from Paul Santapau

include the Security Shepherd https://www.owasp.org/index.php/OWASP_Security_Shepherd training platform for the Security Champions chapter. I was using it on the last company I was working for with very good results.

You can even organise a private Capture The Flag (CTF) contest to reward the top 10 players with some; 1- recognition, 2- reward (going a conf or similar).

http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to

Looks like an interesting product http://riskgap.com

Anybody has experience using it?

http://blog.diniscruz.com/2016/06/using-jira-to-manage-risks-v10-owasp.html

Andre Gironda asked:

_I liked the parts about making Risk a separate project but what if appsec requirements/documentation are listed in its own Epic instead? _

My answer:

That can work, the prob is that it is easy for those Epics to fall into the 'backlog pit of despair' and start to be ignored (i.e. unless you have that 'Risk Accepted' button, it is 'cheap and easy' to just keep prioritising other 'really important' features required by the business/users).

Another issue is that I like to use the JIRA Risk project to describe 'reality' (i.e. the Risks/Issues/features that exists or will exist soon) and then let the dev's use their JIRA project (or whatever bug tracking system they use) to describe what needs to be done (i.e. how they would address those RISK issues)

For example a RISK issue (in the separate RISK or APPSEC Jira project) would be "Xyz app - There is no Authentication on exposed Web Service's methods" , who would (when in the 'Allocated for Fix' stage) be linked into another ticket (or multiple tickets) in the application's JIRA project that would be called "Use Spring Security to authenticate users of service"

Why should a developer care about security training? http://blog.diniscruz.com/2012/04/why-should-developer-care-about.html

• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Concepts/Ten-minute-hack-vs-one-day-work.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Concepts/Start-with-passsing-tests.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Concepts/Using-appsec-to-measure-quality.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-developers/Risk-profile-of-frameworks.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-developers/Test-lifecycle.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-management/For-management.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-management/Insurance-driven-security.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-management/OWASP-top-10-risk-methodology.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-management/Responsible-disclosure.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-management/Third-party-components-and-outsourcing.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-security-teams/For-security-teams.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Jira-risk-workflow/Git-for-security.md
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Jira-risk-workflow/Storing-risk-issues-on-jira.md
• All the files in https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/tree/master/content/2.Risk-workflow/Jira-technologies
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Security-champions/Public-references-to-Security-Champions-teams/Public-references-to-Security-Champions-teams.md (note at end to add more content)
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/edit/master/content/2.Risk-workflow/Security-champions/Conference-for-security-champions.md (edited but note at end:"find other examples")
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/edit/master/content/2.Risk-workflow/Security-champions/How-to-review-applications-as-an-sc.md (edited but note on end to add more info).
• https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Security-champions/Making-Security-Champions-AppSec-Specialists.md

See

• On Fuzzing WebServices
• Roadmap for Testing an WebService's Authorization Model
• What is the formula for the WebServices Authentication mappings?
• First you create Tests for WebServices, then you add the abuse/security cases
• If you not blowing up the database, you're not testing the whole app
• A journey into testing WebServices in a developer friendly way

How many 'easy-to-fix' XSS have we fixed in the last 12 months

on https://github.com/DinisCruz/Book_Jira_Risk_Workflow/pull/7/files#diff-d81580da3b8096a9abb99b1e6e1c6ef2R48 @davevs asks:

I thinks this is too restrictive. Yes, understanding code is critical, but I believe you can be a (valuable) AppSec specialist without actually being able to code. More important qualities are: understanding modern development, being able to explain and discuss issues with developers, being able to explain, configure, and use tools, etc.

from #58

• Line 3: "bug tracking project". Note: If you introduce multiple bug/issue tracking systems no one will do it. Using a single system flexible enough to track issues and is searchable/filterable will make adoption easier. Having to train on multiple systems will be a blocker in most environments
• Line 19: " I also find that fixing these kind of easy tests are a good warm up for more complex Development tasks." Note: Not getting the point across consider rephrasing.

from #17 (comment)

"Continuous Application Risk Management" - And how to foster security as part of a DevOps culture.

This would allow setting the stage by talking about the history of Agile, DevOps and how traditional security approaches are not working in environments where software is released frequently. Then introduces the concept of embedding security into an Agile + DevOps environment and what the key aspects are in terms of culture and responsibilities. Which then leads to the main topic of the book which is how application risk can be managed seamlessly in an ongoing and integrated fashion.

This deserves a good set of chapters and maybe event its own section

see https://twitter.com/Dave_von_S/status/786062211231940608 for context

• Every API is (at some level) vulnerable http://blog.diniscruz.com/2010/01/every-api-is-at-some-level-vulnerable.html
• http://blog.diniscruz.com/2012/04/light-table-amazing-poc-of-ide.html
• http://blog.diniscruz.com/2012/05/brilliant-visualisation-circa-2008.html
• http://blog.diniscruz.com/2012/05/creating-spreadsheet-with-webservices.html
• http://blog.diniscruz.com/2012/09/trillions-from-maya-see-video-buy-book.html
• http://blog.diniscruz.com/2012/09/when-i-think-of-trillions-i-think-of.html
• http://blog.diniscruz.com/2012/10/measure-anything-measure-everything.html
• http://blog.diniscruz.com/2012/11/flosshack-teammentor-and-sausage-making.html
• http://blog.diniscruz.com/2013/06/a-constant-source-of-confusion.html
• http://blog.diniscruz.com/2013/12/blogging-is-like-speaking-to-my-future.html
• http://blog.diniscruz.com/2014/01/lockharts-mathmaticians-lament-maths.html
• http://blog.diniscruz.com/2009/08/why-i-want-to-live-in-insecure-world.html
• http://blog.diniscruz.com/2012/06/good-books-which-actually-focus-on.html
• http://blog.diniscruz.com/2012/11/the-complexity-will-still-exists-even.html
• http://blog.diniscruz.com/2013/09/physical-books-are-best-technology-for.html
• http://blog.diniscruz.com/2016/03/jira-risk-workflow-handling-of-risk.html
• http://blog.diniscruz.com/2012/10/lets-make-this-happen-investing-in.html

Mr Security Consultant: 'Are You Doing A Good Job' for your clients? http://blog.diniscruz.com/2009/11/mr-security-consultant-are-you-doing.html

• What is Owasp? #127
• OWASP community
• Why OWASP is great!
• Why you should be involved in OWASP
• OWASP projects to be involved
• Speak at OWASP conferences or local chapters
• Start an OWASP Chapter or project

Pull Request #72

A few questions on meaning:

On line 9:

• I couldn't find a relevant meaning for 'jerkins'
• "you create pristine built"--I'm not sure what this means
• "It should be modifying stuff"--What does 'it' refer to?

On line 19, I just want to be sure I have made sense of the text. If you want me to make further changes let me know.

Following from @davevs question on scope creep? , rename book to 'SecDevOps Risk Workflow'

• Rename book name in Leanpub - https://leanpub.com/secdevops
• Rename GitHub repos - main repo , build repo
• Update cover
• Update book intro (kinda-ish done)
• Update README.md text and Image
• Create new release - See v0.57

James just asked me this

Add more detail on where to start

from https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/pull/57/files

• Line 7: "the short term". Note: is this 1 month 3 months or other
• Line 9: "the cost of fixing operational issues". Note: needs more context, such as it is not an externally exploitable and does not process sensitive data.
• Line 11: "live". Note: Off line or test systems are not at risk, issues need to be addressed but that is part of the process, consider deleting
• Line 12: "not that important". Note: Need to define 'not important'.
• Line 13: "change it". Note: Mitigations are in place to reduce the impact a threat may be exploited.
• Line 24: "properly, or publicly". Note: Think that this may not be the best way to say this
• Line 28: “As one staff member or manager accepts risk on behalf of his boss, and this action is replicated throughout a company, all the way to the CTO,” Note: Replace with "Accepting risk is the responsibility of the business owner".
• Line 28: “risks are accumulated”. Note: needs clarity.

• namely the use of tables which contain real-time lists of issues
• every issue in the threat models has a JIRA Risk ticket

A variation of this

Not 100% about the titles of the 4 circles (maybe add JIRA workflow or secure code to it )

Image found at https://www.linkedin.com/pulse/devsecops-secdevops-difference-kumar-mba-msc-cissp-mbcs-citp

Book cover to be designed at https://www.canva.com/

http://blog.diniscruz.com/2013/12/trying-to-add-evil-bit-to.html (find more up-to-date content)

As a great example of the kind of 'advanced research' that should be done by AppSec teams + Security Champions (across multiple companies)

I think a number of readers will be interested in my current workflow and CI.

Here are the tools/technologies used:

• Github: holds content and issues
• Atom (with [markdown-preview-enhanced extension)](http://atom.io/packages/markdown-preview-enhanced extension): edit content locally and offline
• SourceTree: used to manage git workflow and branches
• GitHub Service: Used to send an notification to Leanpub when new content is available
• Leanpub: Creates book from markdown (with a preview being created every-time there is a service request web-hook received from GitHub)
• leanpub-book-site: NodeJs app that handles the workflow of creating the book content from source files (which have a different file structure), creating extra commits and pushing them into build repo Book_SecDevOps_Risk_Workflow_Build
• Dropbox: Leanpub pushes previews and final versions to a shared folder
• Twitter and blogs: repost book's content

here is my workflow to push some content changes:

1. Make content changes in Atom (locally)
2. Save them
3. run ./commit_and_build.sh script from command line
4. wait for dropbox notification that preview has been created (or open Leanpub site and see status of the preview generation)
5. if want to publish version, go to Leanpub site for the book and manually publish it to readers (for bigger changes I chose the option to write release notes and email all readers)