├── .gitmodules ├── LICENSE ├── README.md ├── commit_and_build.sh └── content ├── 0.Frontmatter ├── 1.Introduction.md ├── 2.Change-log.md ├── 3.Contributors.md ├── Disclamers.md ├── License.md ├── Printed-version.md ├── Two-focus-for-the-book.md └── Why-git-hub-and-jira.md ├── 1.Sec-DevOps ├── 1.Sec-DevOps.md ├── Concepts │ ├── Dev-sec-ops-or-sec-dev-ops.md │ ├── Dont-blame-the-developers.md │ ├── Good-resources-on-dev-sec-ops.md │ ├── History-of-Sec-Devops.md │ ├── Making-the-sec-part-invisible.md │ ├── Rugged-sofware.md │ ├── Using-ai-for-proactive-defense.md │ ├── When Failed Tests Are Good.md │ └── Why-secdevops.md ├── DevOps │ ├── Dev-ops.md │ ├── Disposable-it-infrastructure.md │ ├── Dont-kill-the-ops.md │ ├── Everything-is-code.md │ ├── History-of-Devops.md │ ├── Horizontal-dev-ops.md │ ├── In-devops-everything-is-code.md │ ├── Infrastucture-as-code.md │ ├── Patch-speed-as-an-quality-metric.md │ ├── Performing-root-cause-analysis.md │ ├── Run-apps-offline.md │ └── When-devs-are-admins.md └── Sec-devops-patterns │ └── Sec-devops-patterns.md ├── 2.Risk-workflow ├── 2.Risk-workflow.md ├── Concepts │ ├── Abusing-the-concept-of-risk.md │ ├── Accepting-risk.md │ ├── Cant-do-security-review-when-doing-code-review.md │ ├── Concepts.md │ ├── Creating-Small-Tests.md │ ├── Creating-abuse-cases.md │ ├── Deliver-pentest-reports-using-jira.md │ ├── Email-is-not-an-official-communication-medium.md │ ├── Good-managers-are-not-the-solution.md │ ├── Hyperlink-everything-you-do.md │ ├── Linking-source-code-to-risks.md │ ├── Mitigating-risk.md │ ├── Passive-aggressive-strategy.md │ ├── Reducing-complexity.md │ ├── Risk-dashboards-and-emails │ │ ├── Risk-dashboards-and-emails.md │ │ └── images │ │ │ ├── jira-dashboard-1.png │ │ │ └── jira-dashboard-email-1.png │ ├── Start-with-passsing-tests.md │ ├── Ten-minute-hack-vs-one-day-work.md │ ├── The-pollution-analogy.md │ ├── Triage-issues-before-devs-see-them.md │ ├── Using-appsec-to-measure-quality.md │ └── Using-graduates-to-manage-JIRA.md ├── For-developers │ ├── 5000-percent-code-coverage.md │ ├── Backlog Pit of Despair.md │ ├── Developer-teams-need-budgets.md │ ├── Developers-should-be-able-to-fire-their-managers.md │ ├── Every-bug-is-an-opportunity.md │ ├── Every-project-starts-with-100-code-coverage.md │ ├── Feedback-loops.md │ ├── For-developers.md │ ├── Make-managers-accountable.md │ ├── Risk-lifecycle.md │ ├── Risk-profile-of-frameworks.md │ ├── Security Makes You A Better Developer.md │ ├── Test-lifecycle.md │ ├── The-authentication-micro-service-cache-incident.md │ ├── Using-git-as-a-backup-strategy.md │ └── x.Creating-better-briefs.md ├── For-management │ ├── Annual-reports-should-contain-infosec-[art.md │ ├── Cloud-security.md │ ├── Code-confidence-index.md │ ├── Feedback-loops-are-key.md │ ├── For-management.md │ ├── Getting-assurance-and-trust-from-appsec-tests.md │ ├── I-dont-know-the-security-status-of-a-website.md │ ├── Inaction-is-a-risk.md │ ├── Insurance-driven-security.md │ ├── Is-the-decision-hyper-linked.md │ ├── Measuring-companies-application-security.md │ ├── OWASP-top-10-risk-methodology.md │ ├── Relationship-with-existing-standards.md │ ├── Responsible-disclosure.md │ ├── Third-party-components-and-outsourcing.md │ ├── Understant-projects-risks.md │ ├── Using-logs-to-detect-risks-exploitation.md │ ├── Using-tests-to-communicate.md │ └── Who-is-actually-making-decisions.md ├── For-security-teams │ ├── Defensible-findings.md │ ├── Do-security-reviews-every-sprint.md │ ├── For-security-teams.md │ ├── Risk-workflow-for-software-vendors.md │ └── create-a-technology-advisory-board.md ├── Jira-risk-workflow │ ├── Capture-knowledge-when-devs-look-at-code.md │ ├── Describe-risks-as-features.md │ ├── Git-for-security.md │ ├── Issue-tracking-solution.md │ ├── Jira-risk-workflow.md │ ├── Key-concepts │ │ ├── Key-concepts.md │ │ └── images │ │ │ └── Screen Shot 2016-03-02 at 16.32.58.png │ ├── Risk-accepting-threat-model.md │ ├── Storing-risk-issues-on-jira.md │ └── The-smaller-the-better.md ├── Jira-technologies │ ├── Confluence.md │ ├── JQL-query-language.md │ ├── Jira-components.md │ ├── Jira-copy-and-paste-of-images.md │ ├── Jira-dashboards.md │ ├── Jira-filters.md │ ├── Jira-kanban-boards.md │ ├── Jira-labels.md │ ├── Jira-technologies.md │ └── Jira-workflows.md ├── Security-champions │ ├── AppSec-memo-from-God.md │ ├── AppSec-technologies-and-tools.md │ ├── Collaboration-technologies.md │ ├── Conference-for-security-champions.md │ ├── Do-you-have-an-heartbeat-you-qualify.md │ ├── How-to-review-applications-as-an-sc.md │ ├── If-you-dont-have-an-sc-get-a-mug │ │ ├── If-you-dont-have-an-sc-get-a-mug.md │ │ └── images │ │ │ └── Security-champion-mug.jpg │ ├── Involvement-in-senior-technical-discussions.md │ ├── Learning-resources.md │ ├── Make-sure-your-Security-Champions-are-given-time.md │ ├── Making-Security-Champions-AppSec-Specialists.md │ ├── Public-references-to-Security-Champions-teams │ │ ├── Public-references-to-Security-Champions-teams.md │ │ └── images │ │ │ ├── mozilla-security-champions-page.png │ │ │ └── owaspSAMM-team-champions.png │ ├── Regular-hackathons.md │ ├── Rewarding-security-champions.md │ ├── Security-champions-activities.md │ ├── Security-champions-dont-take-it-personally.md │ ├── Security-champions-involved-in-decisions.md │ ├── Security-champions.md │ ├── Supported-by-central-appsec.md │ ├── The-security-champions-concept.md │ ├── Threat-modeling-workshops.md │ ├── Training-security-champions.md │ ├── Weekly-meetings.md │ ├── What-is-a-security-champion.md │ ├── What-it-takes-to-be-a-Security-Champion.md │ └── _to_add.md └── Threat-Models │ ├── Capture-the-success-stories-of-your-threat-models.md │ ├── Chained-threat-models.md │ ├── Developers-need-data-classification.md │ ├── Threat-Models-as-better-briefs.md │ ├── Threat-model-case-studies.md │ ├── Threat-model-community.md │ ├── Threat-model-confirms-pentest.md │ ├── Threat-model-per-feature.md │ ├── Threat-models-mapped-to-Risks.md │ ├── Threat-models.md │ └── When-to-do-a-Threat-Model.md ├── Appendix ├── A.Creating-workflow-in-jira │ ├── A.Creating-workflow-in-jira.md │ ├── x.Creating-a-jira-project │ │ ├── images │ │ │ ├── 381996b4-3dca-11e6-8ee7-c66e81868e8a.png │ │ │ ├── 3f66f00c-3dc9-11e6-8020-adc9d1ff0dba.png │ │ │ ├── 54a13770-3dc9-11e6-8204-8e589d858acc.png │ │ │ ├── 5e38eff8-3dc9-11e6-9220-3939d86c936c.png │ │ │ ├── 5e6864ac-3dcb-11e6-9f6d-c9dbb19295ee.png │ │ │ ├── 8a73cbea-3dcb-11e6-876f-b28e07bad7cb.png │ │ │ ├── 91abc63e-3dca-11e6-822e-6781143f7c51.png │ │ │ ├── a6ba4366-3dca-11e6-814f-7f1d189701fa.png │ │ │ └── ca80ff2e-3dca-11e6-9340-7dd576cfabb3.png │ │ └── x.Creating-a-Jira-project.md │ └── x.step-by-step │ │ ├── images │ │ ├── 02d9969c-3dd5-11e6-8d03-c1bcc9f1aef2.png │ │ ├── 07e7f288-3dcf-11e6-82b2-96487b78e130.png │ │ ├── 0b94ab8c-3dd5-11e6-9255-edb93334f424.png │ │ ├── 10a5c61e-3dcc-11e6-88fc-d87a77f5ef0e.png │ │ ├── 189871ce-3dd5-11e6-8297-92e037054900.png │ │ ├── 1ae147f6-3dcd-11e6-9ff0-47cfdcf069ce.png │ │ ├── 2279cc92-3dd5-11e6-8ab3-9cd0a7092e2d.png │ │ ├── 290ef1ee-3dd6-11e6-83c3-de50cf0045d0.png │ │ ├── 3953bbc0-3dd6-11e6-8574-95bad360819c.png │ │ ├── 4d64417a-3dd6-11e6-91ab-0fb4f102f771.png │ │ ├── 566f75e6-3dd6-11e6-8735-4c6fdd36fb01.png │ │ ├── 5acfc2e2-3dce-11e6-88a5-f7dd104edea8.png │ │ ├── 6377d62a-3dcc-11e6-99e5-5483017ee580.png │ │ ├── 6677a814-3dd6-11e6-86d8-8b4a37e3f4aa.png │ │ ├── 6a8619b0-3dcf-11e6-8e04-22a36ceea5b9.png │ │ ├── 7816a2ae-3dcd-11e6-9a29-3b6b0f7e5c0a.png │ │ ├── 8b7a21e0-3dcd-11e6-8dfe-d2dc54af6441.png │ │ ├── 8d566ed2-3dce-11e6-80d1-f7526e43dd67.png │ │ ├── 8f986b30-3dd5-11e6-8101-58807a9cc582.png │ │ ├── 93fc50bc-3dd3-11e6-8646-ae20cc8262b3.png │ │ ├── 9cfe0c30-3dd0-11e6-9b93-8df66d82e0c9.png │ │ ├── a06fa9bc-3dcd-11e6-82e9-a42cb425f162.png │ │ ├── a1feba3e-3dd2-11e6-8a5b-28a8224b4d7d.png │ │ ├── a87773a2-3dcc-11e6-9c7d-1688d84b3ecf.png │ │ ├── ac037160-3dd6-11e6-8283-72bcf317c62d.png │ │ ├── b25a55e2-3dd6-11e6-94a5-06ea7a132635.png │ │ ├── b447ada8-3dce-11e6-887e-0ebb216149ce.png │ │ ├── b55a56ee-3dcb-11e6-941d-c6f6b6ab9dc9.png │ │ ├── b6b3138c-3dd5-11e6-85a5-e5d4d3822d22.png │ │ ├── bca1c3b4-3dd6-11e6-8670-48607c345c38.png │ │ ├── be8a59e8-3dd1-11e6-8075-46ce6c5e252c.png │ │ ├── c2fc5198-3dd6-11e6-9b5a-03da9bfe529a.png │ │ ├── cc65c53c-3dce-11e6-8b8e-8573d0746824.png │ │ ├── cc8ef602-3dd1-11e6-8b15-ec88e5a83c5c.png │ │ ├── d1a36520-3dd5-11e6-8630-a0cfa9ed1c9e.png │ │ ├── d5031a2a-3dd1-11e6-9188-aec6a472968d.png │ │ ├── d7602a48-3dd0-11e6-990b-890168824ebd.png │ │ ├── d8408fd0-3dd4-11e6-9f1f-d57ce4a11ed8.png │ │ ├── dd575028-3dcd-11e6-8b0a-c83b8966d5ea.png │ │ ├── e0dc43aa-3dd4-11e6-841e-61e8e9b0d485.png │ │ ├── e232415e-3dd5-11e6-93f0-8ab67da3de18.png │ │ ├── e522266c-3dcc-11e6-9aca-0f74d539b78c.png │ │ ├── e6d89302-3dd5-11e6-9f97-56850cb52c99.png │ │ ├── ecf41f8a-3dcc-11e6-8531-93c371463acd.png │ │ ├── f35b0678-3dcb-11e6-92c5-9e7d1cf78d16.png │ │ ├── f3c14f5a-3dd5-11e6-8568-0ec71265df26.png │ │ ├── fb52ee16-3dcd-11e6-850c-7dbe99753a4c.png │ │ └── fdf2155e-3dd5-11e6-91bc-b9643324e9bd.png │ │ └── x.step-by-step.md ├── Appendix.md ├── B.GitHub-book-workflow │ ├── Atom-Markdown-graphwiz-dot │ │ ├── Atom-Markdown-graphwiz-dot.md │ │ └── images │ │ │ └── Atom-editor-ui.png │ ├── B.GitHub-book-workflow.md │ ├── Book-creation-workflow.md │ ├── GitHub-leanpub-hook.md │ ├── GitHub-online-editing.md │ ├── GitHub-repos-used.md │ └── Tool-leanpub-book-site.md ├── C.Security-tests-examples │ └── C.Security-tests-examples.md ├── D.Case-studies │ ├── D.Case-studies.md │ ├── File-upload.md │ └── Html-editing.md └── E.Github-issue-workflow │ ├── E.Github-issue-workflow.md │ ├── Github-labels │ ├── Github-labels.md │ └── images │ │ ├── labels-on-book-generation.png │ │ ├── labels-on-complex-software-dev-1.png │ │ └── labels-on-complex-software-dev-2.png │ └── Reporting-issues │ ├── Reporting-issues.md │ └── images │ ├── labels-on-issue-reporting.png │ └── reporting-leanpub-issues.png ├── Draft-Notes ├── Draft-notes.md └── To-fix │ ├── AppSec-Tools.md │ ├── Code-Quality.md │ ├── DevOps.md │ ├── Developers.md │ ├── Government.md │ ├── PoCs.md │ └── Threat-Models.md ├── From-audio ├── From-audio.md ├── Misc-Concepts │ ├── Business Model For Training Workshops.md │ └── Why OWASP Needs Summits.md └── To-Fix │ ├── Capturing Re-factoring Requirements.md │ ├── Create-risks-for-code-hacks.md │ ├── Developers Need To Document Quality Of Their Code.md │ ├── How To Deal With Problematic Teams.md │ ├── How To Make Business Owners Accountable.md │ ├── Insurance-premiums-for-software-risks-must-be-public.md │ ├── Keynote "Code Made in Portugal" Brand.md │ ├── Keynote Be Proactive.md │ ├── Keynote For the Developers in the Room.md │ ├── Keynote Great Source of Talent.md │ ├── Keynote Leader in Cyber and Application Security.md │ ├── Keynote Let's do the same for hacking.md │ ├── Keynote Military │ ├── Keynote Portugal Hackathon League.md │ ├── Keynote Portuguese Hacking Service.md │ ├── Keynote Portuguese Innovations.md │ ├── Keynote Real Time Unit Test Execution and CC.md │ ├── Keynote Sane Defense Model │ ├── Keynote Secure Coding Activities.md │ ├── Keynote Where Is The AppSec Industry.md │ ├── Keynote Why is Portugal so Good at Football.md │ ├── Keynote Working Together.md │ ├── One Number To Define Risk.md │ ├── Pentest Aren't Secure Reassessment .md │ ├── Reinvent Media.md │ ├── Security Champions To Provide Evidence.md │ ├── The Hack Done At Presentation.md │ ├── Use-code-coverage-as-an-analysis-tool.md │ ├── Using Tokens To Access Data.md │ └── Using-git-tomanage-documents.md ├── creative-commons-license.png └── title_page.jpg /.gitmodules: -------------------------------------------------------------------------------- 1 | [submodule "leanpub-book-site"] 2 | path = leanpub-book-site 3 | url = git@github.com:o2platform/leanpub-book-site.git 4 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Book SecDevOps Risk Workflow 2 | Content for _'SecDevOps Risk Workflow'_ book published at https://leanpub.com/secdevops 3 | 4 | The book is still under development, so if you spot any issues or have recommendations please fork this repository and submit a [Pull Request](https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/pulls) :) 5 | 6 | ## JIRA Workflow as described in book 7 | 8 | ![image](https://cloud.githubusercontent.com/assets/656739/19224067/987fe05c-8e75-11e6-99c5-b43ed0d42218.png) 9 | 10 | ## Issues and Discussion group 11 | 12 | If you have questions please create a new [Issue](https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/issues) here at gitHub. 13 | 14 | ##Buy eBook## 15 | 16 | If you can, please buy the book since it will help with production, design, editing and layout costs. 17 | 18 | Leanpub provide a nice shopping card solution which allows you to chose which price to pay: [Buy SecDevOps Risk Workflow](https://leanpub.com/secdevops/overview) 19 | 20 | [![](https://cloud.githubusercontent.com/assets/656739/19657926/e1593cc0-9a1d-11e6-8fd7-f5ab14df8734.png)](![https://leanpub.com/secdevops) 21 | 22 | 23 | 24 | **Dev Setup** 25 | 26 | ```bash 27 | git clone https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow 28 | cd Book_SecDevOps_Risk_Workflow 29 | git submodule init 30 | cd leanpub-book-site 31 | git checkout for_Book_Jira_Risk_Workflow 32 | npm install 33 | ./set-up.sh 34 | cd ../.. 35 | 36 | 37 | ``` 38 | **Build command** 39 | 40 | Build and publish to GitHub (which will trigger a leanpub build) 41 | 42 | ```bash 43 | ./commit_and_build.sh 44 | ``` 45 | -------------------------------------------------------------------------------- /commit_and_build.sh: -------------------------------------------------------------------------------- 1 | git add -A 2 | git commit -m 'updating content' 3 | git push origin 4 | cd ./leanpub-book-site 5 | ./build-book.sh 6 | -------------------------------------------------------------------------------- /content/0.Frontmatter/3.Contributors.md: -------------------------------------------------------------------------------- 1 | ## Contributions 2 | 3 | The following individuals helped in the creation of this book with suggestions, comments, and Pull Requests: 4 | 5 | * Dave van Stein - https://github.com/davevs 6 | * Ann-Marie Grace - https://github.com/Ambg05 7 | * Stephen Porell - s.porell@comcast.net 8 | * Erlend Oftedal - https://github.com/eoftedal 9 | * Henrik Rossen Jakobsen - https://github.com/henrikrossen 10 | * James Wharton - https://github.com/JamesWharton 11 | -------------------------------------------------------------------------------- /content/0.Frontmatter/Disclamers.md: -------------------------------------------------------------------------------- 1 | ## Disclaimers 2 | 3 | * **(unit) Test** - For me a test is anything that can be executed with one of these Unit Test Frameworks: https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks 4 | * **RISK** - Abuse the concept, found RISK to be the best one for the wide range of issues covered by AppSec, while being understood by all players 5 | * **100% Code Coverage** - not the summit, but base-camp (i.e. not the destination). 100% code is not enough, we really need 500% or more Code Coverage 6 | * **AppSec** - Non Functional requirements - AppSec is about understanding and controlling the unintended behaviors of applications 7 | -------------------------------------------------------------------------------- /content/0.Frontmatter/License.md: -------------------------------------------------------------------------------- 1 | ## License 2 | 3 | All original content in this book is released under the **Creative Commons Attribution 4.0 International (CC BY 4.0)** license (see https://creativecommons.org/licenses/by/4.0/) 4 | 5 | For reference this is what it means: 6 | 7 | ![](images/creative-commons-license.png) 8 | -------------------------------------------------------------------------------- /content/0.Frontmatter/Printed-version.md: -------------------------------------------------------------------------------- 1 | ## Printed version 2 | 3 | If you are reading this on a digital device, here are some reasons why you might want to consider buying the printed book [^printed-book]: 4 | 5 | * Better way to learn the concepts in this book (see ["Physical Books are the best technology for reading"](http://blog.diniscruz.com/2013/09/physical-books-are-best-technology-for.html)) 6 | * better graphs and diagrams (which are easier to understand and cross reference on paper) 7 | * helps funding the development of this and other books (that I'm working on) 8 | 9 | 10 | 11 | [^printed-book]: the printed version of this book will be created after the first v1.0 release, and will be released at lulu.com and Amazon. 12 | -------------------------------------------------------------------------------- /content/0.Frontmatter/Two-focus-for-the-book.md: -------------------------------------------------------------------------------- 1 | ## This Book has a Dual Focus 2 | 3 | This book has a dual focus. First, it looks at how application security (AppSec) fits within the security, development and operations (SecDevOps) world. Secondly, the book demonstrates how a risk workflow is the key to making the SecDevOps world work. 4 | 5 | The first part of the book considers the actions and the activities that AppSec introduces into SecDevOps. These actions include testing, insurance, and using the techniques that are part of AppSec to improve SecDevOps. 6 | 7 | The second part of the book details a powerful technique that gives meaning to the work of SecDevOps in an organization. The technique is a risk workflow, based on JIRA or GitHub, that captures and tracks every action and idea, and their implications, that are raised by SecDevOps. These ideas, actions, and implications must be considered, addressed, and accepted by the organization. 8 | 9 | This book presents ideas, concepts, and suggestions to make the risk workflow work in the real world. The subject matter is entirely based on real-world experiences, real-world experiments, and real-world projects across small and large organizations. 10 | -------------------------------------------------------------------------------- /content/0.Frontmatter/Why-git-hub-and-jira.md: -------------------------------------------------------------------------------- 1 | ## Why GitHub and JIRA? 2 | 3 | My current experience is that only GitHub and JIRA have the workflows and the speed that allow these risk workflows to be used properly in the real world. 4 | 5 | I know there are other tools available that try to map this and create some UIs for risk workflows, but I believe that you need something very close to the way developers work. GitHub and JIRA meet this essential requirement, as they are both connected to the source code. 6 | 7 | JIRA is more powerful from the point of view of workflows. JIRA allows you to have more complex workflows, which is quite interesting, and JIRA gives you a risk acceptance button, which is very powerful. 8 | 9 | GitHub is simpler than JIRA, and can be easier and faster to use, although its reporting capabilities aren't as built as JIRA's. 10 | 11 | These two tools are the only ones I have seen that can make this workflow perform in the real world. 12 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/1.Sec-DevOps.md: -------------------------------------------------------------------------------- 1 | # Sec-DevOps 2 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/Dev-sec-ops-or-sec-dev-ops.md: -------------------------------------------------------------------------------- 1 | ### SecDevOps or DevSecOps 2 | 3 | * Which one is better 4 | * Which one sends the better message 5 | * DevSecOps seems to be getting a couple more google queries : https://www.google.co.uk/trends/explore?q=secdevops,devsecops 6 | * DevSecOps has the advantage that puts Dev (Development) first (which is good since that is most important part) 7 | * SecDevOps is a good extension of DevOps which is already a known practice 8 | * I also like the idea that when Security becomes embedded in the SDL and Sec-DevOps just becomes DevOps 9 | * I really like the definitions here 10 | * DevSecOps & SecDevOps - Is there a difference? https://www.linkedin.com/pulse/devsecops-secdevops-difference-kumar-mba-msc-cissp-mbcs-citp 11 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/Dont-blame-the-developers.md: -------------------------------------------------------------------------------- 1 | ### Don't blame the developers 2 | 3 | A very common and dangerous misconception in the security world is that developers are responsible for any security vulnerabilities, or even security mistakes. 4 | 5 | The developers wrote the code, but it is essential to understand the ecosystem and the environment that produced that code. 6 | 7 | Most developers don't control their schedule, their learning, or how much time they get to visualize and understand what they do. Therefore, to make them responsible for the code they are writing is a very dangerous and short-sighted analysis of their role. 8 | 9 | The key influencers of code are the development and the business managers, and the business owner, who controls what gets done and is responsible for what gets created. 10 | 11 | The other challenge is that the current development frameworks and IDEs (Integrated Development Environments) don't reward the visualization and understanding of the side effects of code. 12 | 13 | This means that when you are programming, it is very hard to understand the side effects of changing or adding a feature, or making a particular kind of implementation. 14 | 15 | In such circumstances, how can we expect developers to be accountable and responsible for those code changes when they aren't aware of the bigger picture? 16 | 17 | There might be some cases where the developers should know better, but in my experience, those cases are very rare. My experience is that developers want to do the right thing but they don't get the tools or even the allocation to do so. 18 | 19 | Blaming developers creates a negative dynamic between security people and developers in an already adversarial blame culture. What we need to do before blaming the developers, is understand the ecosystem, and look at the reward system and the workflow. This is a much more positive way of looking at things. 20 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/History-of-Sec-Devops.md: -------------------------------------------------------------------------------- 1 | ### History of Sec-DevOps 2 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/Making-the-sec-part-invisible.md: -------------------------------------------------------------------------------- 1 | ### Making the Sec part invisble 2 | 3 | * concept that a lot of the work done today (2016) in AppSec and SecDevOps is part of a transition into just DevOps 4 | * when security in embedded into the Dev SDL 5 | * when security is invisible 6 | 7 | * Case-Study: The biggest advantages of Microsoft's Security push has been the quality and robustness of their products, and big improvement on their SDL 8 | Story: IE body count from _Renegades of the Empire_ book) 9 | 10 | 11 | * add reference (and some content from) _[Secure coding (and Application Security) must be invisible to developers](blog.diniscruz.com/2012/04/secure-coding-and-application-security.html)_ 12 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/Rugged-sofware.md: -------------------------------------------------------------------------------- 1 | ### Rugged Software 2 | 3 | 4 | * https://www.ruggedsoftware.org/ 5 | * Rugged Manifesto 6 | * add explanation of what it is (and its history) 7 | * why it didn't really work (as least according to the original expectations) 8 | * lack of community adoption 9 | * 'Security Driven' vs 'Developer driver' 10 | 11 | * The Docker case study 12 | * why Docker was so successful (as an idea and adoption) 13 | 14 | * lessons learned 15 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/Using-ai-for-proactive-defense.md: -------------------------------------------------------------------------------- 1 | ### Using Artificial Intelligence for proactive defense 2 | 3 | We need AI to understand code and applications. Our code complexity is getting to a level that we need to start to use artificial intelligence capabilities to understand it, and to get a grasp of what is going on, so we can create secure applications that have no unintended side effects. 4 | 5 | As AI becomes much more commonplace, we should start to use it more to source code analysis and application analysis. Kevin Kelly has some very interesting analysis on the use of AI, where he discusses the idea that one of the next major revolutions will be where we start adding AI to everything, because the cost of AI will become so low that we will be able to add AI to many devices. 6 | 7 | When you analyse an app, you should use everything you have. You should use static, dynamic, interactive, human, and increasingly you should use artificial intelligence to optimise your analysis. 8 | 9 | When you are doing security analysis, you are dealing with a vast amount of data, displayed on a multi-dimensional graph. What you have is a graph of the relationships, of what is happening. You are looking for the connections, for the paths within the graph, that are made of what is really going on and what is possible. 10 | 11 | Artificial intelligence technology can assist the human who will put context on those connections. I think we are a long way from being able to do this kind of analysis automatically, but if we can make the human's job of reviewing the results easier, or even possible, that is a major step forward. 12 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/When Failed Tests Are Good.md: -------------------------------------------------------------------------------- 1 | ### When Failed Tests are Good 2 | 3 | When you make a code change, it is fundamental that every change you make breaks a test, or breaks something. You are testing for that behaviour; you are testing for the particular action that you are changing. 4 | 5 | This means you should be happy when you make a change and the test fails, because you can draw confidence from knowing the side effects of the change. If you make a test change in one place and a couple of tests break, and you make another test change in a different place and fifty tests break, you get a far better sense of the impact of the changes that you made. 6 | 7 | A more worrying prospect is when you make code changes but you don't see any test failing, and nothing breaks. This means you don't understand the side effects of the change that you just made. And tests should be teaching you the side effects of changes. 8 | 9 | Broken tests are great when the test that you expect to break is the one that fails. The changes that you were expecting to make are the ones that happen, and that makes sense. 10 | 11 | When a test breaks, and you review that code, you understand why the break happened, and you understand the side effect. If the test fix is fast, you have a very quick and effective loop of TDD. 12 | 13 | Sometimes, I will write something and it passes, so I know the code is working the way it is supposed to work. But I will have a couple of other cases where the test fails, and this allows me to confirm that it is failing in a predictable and expected way. 14 | 15 | Sometimes, I will codify those failures in tests, to have and to give the assurance that a break happened in a particular place, so I should change this place, or this is the fix that happened the way that I expected it to happen. 16 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Concepts/Why-secdevops.md: -------------------------------------------------------------------------------- 1 | ### Why SecDevOps? 2 | 3 | I like SecDevOps because it reinforces the idea that is an extension of DevOps. SecDevOps points to the objective that eventually we want the Sec part to disappear and leave us with DevOps. 4 | 5 | Ultimately, we want an environment where 99% of the time, DevOps don't care about security. They program in an environment where they either cannot create security vulnerabilities, or it is hard to create them, or it is easy to detect security issues when they occur. 6 | 7 | This doesn't mean you don't need security teams, or AppSec experts. It doesn't mean you don't need a huge amount of work behind the scenes, and a huge amount of technology to create those environments. 8 | 9 | You don't make security invisible by getting rid of it. You make security invisible by automating the security checks, and by increasing visibility into what is going on. 10 | 11 | At the moment, when we look at security activities, we often see security doing things that are the proper responsibility of development, or testing, or infrastructure, or documentation, or even management. 12 | 13 | Anybody who works in AppSec for a while always finds themselves asking difficult questions. They interrogate the system rigorously, but the information they seek should already be known and available to them. 14 | 15 | AppSec will often create tools to attack an application to visualize what is going on. I have had many experiences of spending time creating technology to understand the attack surface. Once that task is complete, I find a huge number of vulnerabilities, simply because a significant part of the application hadn't been tested. The system owners, and the various players didn't fully understand the application or how it behaved. 16 | 17 | So, I think SecDevOps represents an interesting point in history, where we are trying to merge all the activities that have been going on in security with the activities that have been going on in DevOps so we can build an environment where we can create and deploy secure applications. 18 | 19 | This relates closely to my ideas about using AppSec to measure quality. Ultimately, the quality of the application is paramount when we are trying to eliminate the unintended consequences of software. 20 | 21 | DevSecOps initially sounds better because development goes first. But I agree with the view of DevSecOps as being more about applying development to security operations (SecOps). 22 | 23 | This all ties together with the risk workflows that make things more connected and accountable. 24 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Dev-ops.md: -------------------------------------------------------------------------------- 1 | ## Dev-Ops 2 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Disposable-it-infrastructure.md: -------------------------------------------------------------------------------- 1 | ### Disposable IT infrastructure 2 | 3 | Following the 'everything is code' concept, what you really want is an environment where your IT infrastructure is disposable. By this I mean that it should be very easy to rebuild, or recreate. Consider the developer's environment, and how long it takes to create infrastructure. Then consider what happens to that infrastructure when the company hires more developers or the development team expands. 4 | 5 | This is also an issue from a security point of view because it means that the developers, and even normal IT users, have a lot of black magic in their infrastructure. And if there is any Malware or malicious code installed in an application, then it means that it is in there for a certain period of time. 6 | 7 | So, what you want is a situation where most of your infrastructure is automatically rebuilt. You want environments where developers' laptops reboot every Monday, where you overhaul the infrastructure from the bottom up, and where business owners use Chromebooks so that every install is fresh. 8 | 9 | Your infrastructure should be disposable, you shouldn't care about it, and you should be able to easily rebuild, delete, or destroy, because that means all your data is backed up, and all your data is safe. 10 | 11 | It also promotes the idea that in most scenarios, you shouldn't be able to access all the data or assets that your current user role has access to (i.e. you should only have access to that you need to do the job at hand). 12 | 13 | It would be great if we had a Git-based operating system, with native support for version control, even at the operating system level. This would provide full control of what is going on and what is changed (on install and over time), by using git diffs and branches. 14 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Dont-kill-the-ops.md: -------------------------------------------------------------------------------- 1 | ### Don't kill the Ops 2 | 3 | 4 | * be careful that DevOps is not a cost saving exercise, where it is seen as a way to kill/reduce Ops. 5 | * Dev + Ops -> DevOps -> Dev 6 | * seen cases where there is an crazy idea that the 'Ops' team will be made redundant 7 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Everything-is-code.md: -------------------------------------------------------------------------------- 1 | ### Everything is code 2 | 3 | It is critical to understand that everything that happens in an organisation, from the development, to the deployment, to the configuration, to the retirement of an app, is code. 4 | 5 | This is tied to the concept of disposable infrastructure, where it is possible to rebuild everything from scratch automatically. 6 | 7 | Since everything is code, everything should be versioned, stored in a Git repository, and tested. 8 | 9 | Git is a very important component, since it allows the use of branches for managing multiple versions and deployments. The Git repo also captures all the configurations, settings, and mappings. 10 | 11 | This is a big change, because a lot of what happens in any organisation is not documented, but instead is stored in somebody's head, or in a script. The movement to use continuous integration workflows and embrace DevOps practices, represents a good opportunity to capture existing reality. 12 | 13 | Basically, there should be no black-magic or non-versioned configuration, anywhere in the development and deployment pipeline. 14 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/History-of-Devops.md: -------------------------------------------------------------------------------- 1 | ### History of DevOps 2 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Horizontal-dev-ops.md: -------------------------------------------------------------------------------- 1 | ### Horizontal DevOps 2 | 3 | The best model I have seen for integrating DevOps in a company is where teams are created that span multiple groups. Instead of having a top-down approach to the deployment of operations, where you create the central teams, the standards, the bills, etc., and then push it down, the central DevOps team hires or trains DevOps engineers and then allocates them to each team. 4 | 5 | The logic is that each team spends a certain amount of time with a DevOp engineer, who trains the teams in DevOp activities and best practices, and thereby embeds the best practices in the development life cycle. 6 | 7 | The result is horizontal teams, which have several advantages. They have two masters: they answer to DevOps but they also answer to the team lead, and they share best practice. The creation of horizontal teams is a much better way to scale, and it encourages teams to collaborate. The teams know they aren't required to spend all their time working in DevOps, and they know there is someone who can help them. 8 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Infrastucture-as-code.md: -------------------------------------------------------------------------------- 1 | ### Infrastructure as code 2 | 3 | * all changes and scripts and clicks: 4 | * are code 5 | * need to be stored in git 6 | * need tests (can run locally and in production) 7 | 8 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Patch-speed-as-an-quality-metric.md: -------------------------------------------------------------------------------- 1 | ### Patch speed as a quality metric 2 | 3 | Making small changes to an application (i.e. Patching) should be an easy and smooth event. 4 | 5 | However, if it is a problem, it means that there are issues either in deploying the app, or in rebuilding the required infrastructure. 6 | 7 | These issues need to be addressed sooner rather than later, specially since they affect the risk appetite for management and business owners to allow changes and refactoring to occur. 8 | 9 | For patching, you really want to seen an [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) workflow with a healthy fast, smooth flow and an low WIP (Work In Progress) 10 | 11 | **What happens when rollbacks are required?** 12 | 13 | Before an incident even happens, open a JIRA ticket on 'lack of patching'. This way, when a lack of patching causes problems, you are ready to capture the incidents that occur. 14 | 15 | History, and any experience of Murphy's Law, should provide evidence on the cost of non-patching. 16 | A lack of patching acts as a canary in a coal mine, in so far as it points to bigger problems up ahead. You should think of patching as a type of fire drill. 17 | 18 | **When is patching easy** 19 | 20 | Patching is easy in the following circumstances: 21 | 22 | * when it is easy to run the new version in an isolated environment (with and without production data) 23 | * when there is a good understanding of what is going to change (files, ports, behavior, inter-dependencies, schema's changes) 24 | * i.e. a diff with the current version of everything 25 | * when there are Tests (e2e and integration) that run though the affected systems' success criteria and confirm any changes (i.e. the side effects) 26 | * when it easy to rollback to previous version(s) 27 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Performing-root-cause-analysis.md: -------------------------------------------------------------------------------- 1 | ### Performing root-cause analysis 2 | 3 | * some environments make it hard to perform root-cause analysis, because it is seen as a blame exercise, instead of a learning opportunity 4 | * Root-cause analysis are key for any bug (namely one the ones with Security implications) 5 | * lack of 'Root-cause analysis' is a risk (which needs to be accepted) 6 | * means business owners doesn't want to spend the time to find other (similar issues) 7 | * add story of project manager that asked "please don't find more security issues during the retest (they are out of scope)" 8 | * in an DevOps world, it is key for the root-cause analysis that there is a way replicate the issue (in an simulated environment). 9 | * the end-result of a root-cause analysis should be a Test (very close to a script) (that passes when the issue can be replicated correctly and reliably) 10 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/Run-apps-offline.md: -------------------------------------------------------------------------------- 1 | ### Run Apps Offline 2 | 3 | The ability to run applications offline, i.e. without live dependencies of QA servers, or even live servers, is critical in the development process. That capability allows the developers to code at enormous speed, because usually the big delays and expensive calls are to those services that allow all sorts of versioning, and all sorts of development techniques to occur. The ability to run your apps offline also signifies that the application development environment has matured to a level where you now have, or have created, mocked versions of your dependencies. 4 | 5 | Ideally, the faster you can run the dependencies, even running them as real code, the better. The important thing is to be sure you are running them locally, without a network connection, and without an umbilical code to another system. 6 | 7 | Of course you will always test against those other systems. The test that you are going to run locally against that mocked version should also pass against the live system. If the dependencies don't pass, you have a problem and you have to fix it. 8 | 9 | When you are developing, you should have all the required dependencies at that moment in time. This makes a huge difference when you are developing a new version, or a new feature, where you can already simulate how those dependencies behave. This allows for much better demos, a much faster interaction and development loop, and, ultimately, it accelerates developers' productivity. 10 | 11 | The answers to the following simple questions are also very important: Can you run your app offline? Can you run your service offline? Can you run your application that you are coding offline? These are things that management can use to measure the pulse, and the quality, of the current development environment, and the continuous integration of particular teams. 12 | 13 | So, if you have three teams that code in the way described above, and one team that doesn't, you can guess which team is probably not shipping regularly. This same team will be unable to develop things very quickly, and it will be unable to respond quickly to customer and business requirements. More importantly, the team that doesn't run apps offline will be the team that has to deal with a whole number of bugs and QAs every time it releases. The teams that run their apps offline, with QA cycles, won't encounter these kinds of obstacles. 14 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/DevOps/When-devs-are-admins.md: -------------------------------------------------------------------------------- 1 | ### When devs are cloud admins 2 | 3 | * When moving to the cloud, Devs are becoming SysAdmins 4 | * which is a massive issue and is creating a large number of security issues 5 | * in some cases this move is literally _'throwing the baby with the bath water'_ where lack of innovation, speed and features from the local admin/IT teams, pushed the developers to have free reign in the cloud (like AWS) where they can create servers and VMs in seconds (vs days, weeks or months) 6 | -------------------------------------------------------------------------------- /content/1.Sec-DevOps/Sec-devops-patterns/Sec-devops-patterns.md: -------------------------------------------------------------------------------- 1 | ## Sec DevOps patterns 2 | 3 | * provide examples 4 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/2.Risk-workflow.md: -------------------------------------------------------------------------------- 1 | # Risk Workflow 2 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Abusing-the-concept-of-risk.md: -------------------------------------------------------------------------------- 1 | ### Abusing the concept of RISK 2 | 3 | As you read this book you will notice liberal references to the concept of RISK, especially when I discuss anything that has security or quality implications. 4 | 5 | The reason is I find that RISK is a sufficiently broad concept that can encompass issues of security or quality in a way that makes sense. 6 | 7 | I know that there are many, more formal definitions of RISK and all its sub-categories that could be used, but it is most important that in the real world we keep things simple, and avoid a proliferation of unnecessary terms. 8 | 9 | Fundamentally, my definition of RISK is based on the concept of 'behaviors' and 'side-effects of code' (whether intentional or not). The key is to map reality and what is possible. 10 | 11 | RISKs can also be used in multi-dimensional analysis, where multiple paths can be analyzed, each with a specific set of RISKs (depending on the chosen implementation). 12 | 13 | For example, every threat (or RISK) in a threat model needs to have a corresponding RISK ticket, so that it can be tracked, managed and reported. 14 | 15 | **Making it expensive to do dangerous actions** 16 | 17 | A key concept is that we must make it harder for development teams to add features that have security, privacy, and quality implications. 18 | 19 | On the other hand, we can't really say 'No' to business owners, since they are responsible for the success of any current project. Business owners have very legitimate reasons to ask for those features. Business wishes are driven by (end)user wishes, (possibly defined by the market research department and documented in a MRD (Market requirement Document). Saying no to the business means saying no to the customer. The goal, therefore, is to enable users to do what they want, with an acceptable level of risk. 20 | 21 | By providing multiple paths (with and without additional or new RISKs) we make the implications of specific decisions very clear. 22 | 23 | What usually happens is that initially, Path A might look easier and faster than either of Paths B or C, but, after creating a threat model, and mapping out Path A's RISK, in many cases Path B or C might be better options due to their reduced number of RISKs. 24 | 25 | It is important to have these discussions before any code is written and while there is still the opportunity to propose changes. I've been involved in many projects where the security/risk review only occurs before the project goes live, which means there is zero opportunity to make any significant architectural changes. 26 | 27 | Release Management (RM) should be the gating factor. RM should establish quality gates based on business and security team minimum bar. 28 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Concepts.md: -------------------------------------------------------------------------------- 1 | ## Concepts 2 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Creating-Small-Tests.md: -------------------------------------------------------------------------------- 1 | ### Creating Small Tests 2 | 3 | When opening issues focused on quality or security best practices (for example, a security assessment or a code review), it's better to keep them as small as possible. Ideally, these issues are placed on a separate bug-tracking project (like the Security RISK one), since they can cause problems for project managers who like to keep their bug count small. 4 | 5 | Since this type of information only exists while AppSec developers are looking at code, if the information isn't captured, it will be lost, either forever, or until that bug or issue becomes active. It is very important that you have a place to put all those small issues, examples, and changes. 6 | 7 | Capturing the small issues also helps to capture the high-level and critical security issues that are made of multiple low or medium issues. Their capture also helps to visualize the patterns that occur across the organization, for example, in an issue that effects dozens of teams or products. 8 | 9 | This approach also provides a way to measure exactly what will occur during a quality pass or sprint, for example, when focusing on cleaning and improving the quality of the application. 10 | 11 | The smaller the issue, the smaller the commit, the smaller the tests will be. As a result, the whole process will be smoother and easier to review. 12 | 13 | It also creates a great two-way communication system between Development and AppSec, since it provides a great place for the team to collaborate. 14 | 15 | When a new developer joins the team, they should start with fixing bugs and creating tests for them. This can be a great way for the new team member to understand what is going on, and how the application works. 16 | 17 | Fixing these easy tests is also a good preparation for tackling more complex development tasks. 18 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Creating-abuse-cases.md: -------------------------------------------------------------------------------- 1 | ### Creating Abuse Cases 2 | 3 | Developer teams tend to focus on the 'Happy Paths', where everything works out exactly as expected. However, in agile environments, creating evil user stories linked to a user story can be a powerful technique to convey higher level threats. 4 | 5 | **Evil user stories (Abuse cases)** 6 | 7 | Evil user stories have a dependency with threat modeling and can be an effective way of translating higher level threats and mitigations. They can be imagined as a kind of malicious Murphy's law [^Murphy-law]. 8 | 9 | Take for example a login flow. After doing a threat model on this flow one should have identified the following information: 10 | 11 | Attackers: 12 | * registered users 13 | * unregistered users 14 | 15 | Assets: 16 | * credentials 17 | * customer information 18 | 19 | With this information, the following threats can be constructed: 20 | 21 | * unregistered users bypassing the login functionality 22 | * unregistered users enumerating accounts 23 | * unregistered users brute-forcing passwords 24 | * registered users accessing other users' information 25 | 26 | At the same time the team has constructed the following user stories that should be implemented: 27 | * _"as a registered user I want to be able to login with my credentials so I can access my information"_ 28 | 29 | Combined with the outcome of the threat model, the following evil user stories can be constructed: 30 | * _"as an unregistered user I should not be able to login without credentials, and access customer information"_ 31 | * _"as an unregistered user I should not be able to identify existing accounts and use them to attempt to login"_ 32 | * _"as a user I should not be able to have unlimited attempts to log in and hijack someone's account"_ 33 | * _"as an authenticated user I should not be able to access other users' information"_ 34 | 35 | [^Murphy-law]: Murphy's law: _'Anything that can go wrong, will go wrong'_, https://en.wikipedia.org/wiki/Murphy%27s_law 36 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Deliver-pentest-reports-using-jira.md: -------------------------------------------------------------------------------- 1 | ### Deliver PenTest reports using JIRA 2 | 3 | Using JIRA to deliver PenTest reports is much more efficient than creating a PDF to do so. Using JIRA allows for both a quick validation of findings, and direct communication between the developers and the AppSec team. 4 | 5 | If customized properly, there are a number of tools that can act as triage tools between PenTest results and JIRA: 6 | 7 | * 'defect dojo' 8 | * 'bag of holding' 9 | * ThreadFix 10 | * Other... 11 | 12 | Threat Modeling tools could also work well between PenTest results and JIRA. 13 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Good-managers-are-not-the-solution.md: -------------------------------------------------------------------------------- 1 | ### Good Managers are not the Solution 2 | 3 | When we talk about risk, workflows, business owners making decisions about development, and QA teams that don't write tests, we often hear the comment, "If we had good managers, we wouldn't have this problem". 4 | 5 | That statement implies that if you had good managers, you wouldn't have the problem, because good managers would solve the problem. That is the wrong approach to the statement. Rather, if you had good managers, you wouldn't have the problem, because good managers would ask the right questions before the problem even developed. 6 | 7 | These workflows aren't designed for when you have a good manager, a manager who pushes testing, who demands good releases, who demands releases every day, or who demands changes to be made immediately. 8 | 9 | These workflows are designed for bad managers (I use the term reluctantly). Bad managers are not knowledgeable, or they are exclusively focused on the short-term benefits of business decisions, without taking to account the medium-term consequences of the same decisions. This goes back to the idea of pollution, where the manager says "Just ship it now, and we will deal with the pollution later". With start-ups, sometimes managers will even say, "Push it out or we won't have a company". 10 | 11 | The risk workflow, and the whole idea of making people accountable is exactly because of these kinds of situations, where poor decisions by management can cause huge problems. 12 | 13 | We want to empower developers, the technical guys who are writing code and have a very good grasp of reality and potential side effects. They are the ones who should make technical decisions, because they are the ones who spend their time coding, and they understand what is going on. 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Linking-source-code-to-risks.md: -------------------------------------------------------------------------------- 1 | ### Linking source code to Risks 2 | 3 | If you add links to risk as source code comments, you deploy a powerful and very useful technique with many benefits. 4 | 5 | When you add links to the root cause location, and all the places where the risk exists, you make the risk visible. This reinforces the concept of cost (i.e. pollution) when insecure, or poor quality, code is written. Linking the source code to risk becomes a positive model when fixes delete the comments. When the comments are removed, the AppSec team is alerted to the need for a security review. Finally, tools can be built that will scan for these comments and provide a 'risk pollution' indicator. 6 | 7 | 8 | * _add coffee-script example from 'Start with tests' presentation_ 9 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Mitigating-risk.md: -------------------------------------------------------------------------------- 1 | ### Mitigating Risk 2 | 3 | One strategy to handle risk is to mitigate it. 4 | 5 | Sometimes, external solutions, such as a WAF, provide a more effective solution. 6 | 7 | If a WAF fixed the issue, and there are tests that prove it, then it is a valid fix. In this case, it is important to create a new RISK which says _"Number of security vulnerabilities are currently being mitigated using a WAF. If that WAF is disabled, or if there is a WAF bypass exploit, then the vulnerabilities will become exploitable"_ 8 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Passive-aggressive-strategy.md: -------------------------------------------------------------------------------- 1 | ### Passive aggressive strategy 2 | 3 | Keep zooming in on the answers to refine the scope and focus of the issue. 4 | 5 | Not finding something is a risk, and not having time to research something is a risk. 6 | 7 | Sometimes, it is necessary to open tickets that state the obvious: 8 | * when we are not using SSL (or have an HTTP to HTTPS transition), then we should open a risk to be accepted with: _"Our current **SSL** protection **only works when the attacker** we are trying to protect against (via man-in-the-middle) **is not there**"_ 9 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Reducing-complexity.md: -------------------------------------------------------------------------------- 1 | ### Reducing complexity 2 | 3 | The name of the game is to reduce the moving parts of a particular solution, its interactions, inputs, and behaviours. 4 | 5 | Essentially, the aim is to reduce the complexity of what is being done. 6 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Risk-dashboards-and-emails/Risk-dashboards-and-emails.md: -------------------------------------------------------------------------------- 1 | ### Risk Dashboards and emails 2 | 3 | It is critical that you create a suite of management dashboards that map the existing security metrics and the status of RISK tickets: 4 | 5 | {width=50%, float=right} 6 | ![Jira Dashboard](images/jira-dashboard-1.png) 7 | 8 | * _Open, In Progress_ 9 | * _Awaiting Risk Acceptance, Risk Accepted_ 10 | * _Risk Approved, Risk not Approved, Risk Expired_ 11 | * _Allocated for Fix, Fixing, Test Fix_ 12 | * _Fixed_ 13 | 14 | Visualizing this data makes it real and creates powerful dashboards. The dashboards need to be provided to all players in the software development lifecycle. 15 | 16 | You should create a sequence of dashboards that starts with the developer (who maps the issues that he is responsible for), then his technical architect, then the business owner, the product owner ... all the way to the CTO and CISO. 17 | 18 | Each dashboard clarifies which risks they are responsible for, and the status of application security for those applications/projects. 19 | 20 | {width=50%, float=right} 21 | ![Emails to management](images/jira-dashboard-email-1.png) 22 | 23 | To reinforce ownership and make sure the issues/risks don't 'disappear', use either the full dashboard, or specific tables/graphs, to create emails that are sent regularly to their respective owners. 24 | 25 | The power of risk acceptance is that each layer accepts risk on behalf of the layer above. This means that the higher one is in the company structure, the more risks are allocated and accepted (all the way to the CISO and CTO). 26 | 27 | The CISO plays a big part in this workflow, since it is his job to approve all 'Risk Accepted' issues (or raise exceptions that need to be approved by higher management). 28 | 29 | This workflow drives many security activities because it motivates each player to act in his own best interests (which is to reduce the number of allocated Risk Accepted items). 30 | 31 | The idea is to social-engineer the management layer into asking the developers to do the non-function-requirements tasks that the developers know are important, but seldom get the time to do. 32 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Risk-dashboards-and-emails/images/jira-dashboard-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/2.Risk-workflow/Concepts/Risk-dashboards-and-emails/images/jira-dashboard-1.png -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Risk-dashboards-and-emails/images/jira-dashboard-email-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/2.Risk-workflow/Concepts/Risk-dashboards-and-emails/images/jira-dashboard-email-1.png -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Start-with-passsing-tests.md: -------------------------------------------------------------------------------- 1 | ### Start with passing tests 2 | 3 | - add content from presentation 4 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Ten-minute-hack-vs-one-day-work.md: -------------------------------------------------------------------------------- 1 | ### Ten minute hack vs one day work 2 | 3 | * 10m hacks vs 1 day proper coding will create more RISK tickets and source comments 4 | * I get asked this a lot from developers 5 | * There has to be a quantitive difference, which needs to be measured 6 | 7 | **That code sucks** 8 | 9 | * Ok can you prove it? 10 | * Code analysers in IDE can help identify known bad patterns and provide awareness 11 | * Why is it bad? 12 | 13 | **In new code legacy** 14 | - if it also hard to refactor and change, then yes 15 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Triage-issues-before-devs-see-them.md: -------------------------------------------------------------------------------- 1 | ### Triage issues before developers see them 2 | Issues identified in vulnerability scans, code analysers, and penetration tests, must be triaged by the AppSec team to prevent overloading developers with duplicate issues or false positives. Once triaged, these issues can be pushed to issue trackers, and exposed to the developers. 3 | 4 | Unfortunately, this is still an underdeveloped part of the AppSec pipeline. Even commercial vendors' UI don't really support the customisation and routing of the issues they 'discover'. 5 | 6 | The following tools are attempting to do just that: 7 | 8 | * Bag of Holding https://github.com/aparsons/bag-of-holding 9 | * Defect Dojo https://github.com/OWASP/django-DefectDojo 10 | * ThreadFix 11 | 12 | With these triage tools, AppSec specialists can identify false positives, accepted risks, or theoretical vulnerabilities that are not relevant in the context of the system. This ensures that developers should only have to deal with the things that need fixing. 13 | 14 | **Create JIRA workflow to triage raw issues** 15 | 16 | The creation of a security JIRA workflow for the raw issues to act as a triage tool, and push them to team boards after reviewing, would be another good example of the power of JIRA for workflows. 17 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Using-appsec-to-measure-quality.md: -------------------------------------------------------------------------------- 1 | ### Using AppSec to measure quality 2 | 3 | * add content from presentation [AppSec and Software Quality]( http://blog.diniscruz.com/2016/05/appsec-and-software-quality.html) 4 | 5 | * academic research 6 | * [https://insights.sei.cmu.edu/sei_blog/2016/06/using-quality-metrics-and-security-methods-to-predict-software-assurance.html](Using Quality Metrics and Security Methods to Predict Software Assurance) 7 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Concepts/Using-graduates-to-manage-JIRA.md: -------------------------------------------------------------------------------- 1 | ### Employ Graduates to Manage JIRA 2 | 3 | One of the challenges of the JIRA RISK workflow is managing the open issues. This can be a considerable amount of work, especially when there are 200 or more issues to deal with. 4 | 5 | In large organizations, the number of risks opened and managed should be above 500, which is not a large quantity. In fact, visibility into existing risks starts to increase, and improve, when there are more than 500 open issues. 6 | 7 | The solution to the challenge of managing issues isn't to have fewer issues. 8 | 9 | The solution is to allocate resources, for example to graduates, or recently hired staff. 10 | 11 | These are inexpensive professionals who want to develop their careers in AppSec, or they want to get a foot in the company's door. Employing them to manage the open issues is a win-win situation, as they will learn a great deal on the job, and they will meet a lot of key people. 12 | 13 | By directing graduate employees or new hires to manage the open issues, developers' time is then free to fix the issues instead of maintaining JIRA. 14 | 15 | The maintenance of issues is critical for the JIRA RISK workflow to work, because one of its key properties is that it is always up-to-date and it behaves as a 'source of truth'. 16 | 17 | It is vital that risks are accepted and followed up on and that issues are never moved into the developer's backlog where they will be lost forever. 18 | 19 | We can't have security RISKs in backlog; issues must either be fixed or accepted. 20 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Backlog Pit of Despair.md: -------------------------------------------------------------------------------- 1 | ### Backlog Pit of Despair 2 | 3 | In lots of development teams, especially in agile teams, the backlog has become a huge black hole of issues and features that get thrown into it and disappear. It is a mixed bag of things we might want to do in the future, so we store them in the backlog. 4 | 5 | The job of the product backlog is to represent all the ideas that anyone in the application food chain has had about the product, the customer, and the sales team. The fact that these ideas are in the backlog means they aren't priority tasks, but are still important enough that they are captured. Moving something into the backlog in this way, and identifying it as a future task, is a business decision. 6 | 7 | However, you cannot use the backlog for non-functional requirements, especially the ones that have security implications. You have to have a separate project to hold and track those tickets, such as a Jira or a GitHub project. 8 | 9 | Security issues or refactoring needs, still exist, regardless of whether the product owner wants to pursue them, whether they are a priority, or whether customers are asking for them. 10 | 11 | Security and quality issues should either be in a fixed state, or in a risk acceptance state. 12 | 13 | The difference is that quality and security tickets represents reality, whereas the backlog represents the ideas that could be developed in the future. That is why they have very different properties, and why you shouldn't have quality and security tickets in the backlog _Pit of Despair_ [^pit-of-despair]. 14 | 15 | [^pit-of-despair]: Princess Bride - Pit of Despair, https://www.youtube.com/watch?v=mBaDcOBoHFk 16 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Developer-teams-need-budgets.md: -------------------------------------------------------------------------------- 1 | ### Developer Teams Need Budgets 2 | 3 | Business needs to trust developer teams. 4 | 5 | Business needs to trust that developers want to do their best for their projects, and for their company. 6 | 7 | If business doesn't learn to trust its developer teams, problems will emerge, productivity will be affected and quality/security will suffer. 8 | 9 | A great way to show trust is to **give the developer team a budget**, and with it the power to spend money on things that will benefit the team. 10 | 11 | This could include perks for developers such as conference attendance, buying books, or buying things which are normally a struggle to obtain. It is often the case that companies will purchase items for a team when requested, but first the team must struggle to overcome the company's apathy to investing in the developer team. The balance of power never lies with the team, and that imbalance makes it hard to ask for items to be purchased. Inconsistencies are also a problem: sometimes it can be easier to ask for £5,000, or for £50,000, than it is to ask for £50 . 12 | 13 | Companies need to treat developer teams as the adults they are, and they need to trust them. My experience in all aspects of organizations is that it is difficult to spend money. 14 | 15 | When you spend money, especially in an open-ended way, your expenditure is recorded and it becomes official. If your investment doesn't yield good results for the company, you will be held accountable. 16 | 17 | Therefore, allocating a budget to the developer teams will keep the teams honest, and will direct their focus to productive investments. Purchases could range from buying some tools for the developers, to buying a trip, or even to outsourcing some work to a freelancer. 18 | 19 | Spending on the operational expenses for the team will yield benefits both to developer teams and to business. 20 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Developers-should-be-able-to-fire-their-managers.md: -------------------------------------------------------------------------------- 1 | ### Developers should be able to fire their managers 2 | 3 | Many problems developer teams deal with arise from the inverted power structure of their working environment. The idea persists that the person managing the developers is the one who is ultimately in charge, responsible, and accountable. 4 | 5 | That idea is wrong, because sometimes the person best-equipped to make the key technological decisions, and the difficult decisions, is the developer, who works hands-on, writing and reading the code to make sure that everything is correct. 6 | 7 | A benefit of the 'Accept Risk' workflow, is that it pushes the responsibility to the ones that really matter. I've seen cases when upper-layers of management realise that they are not the ones that should be accepting that particular risk, since they are not the ones deciding on it. In theses cases usualy the decision comes down to the developers, who should use the opportunity to gain a bigger mandate to make the best decisions for the project. 8 | 9 | Sometimes, a perverse situation occurs where the managers are no longer coding. They may have been promoted in the past because they used to be great programmers, or for other reasons, but now they are out of touch with programming and they no longer understand how it works. 10 | 11 | Their job is to make the developers more productive. They work in customer liaison, they manage the team and its results, they organise, review, handle business requirements and expectations, and make sure everything runs smoothly. That is the job of the manager, and that manager also acts as the voice of the developer team. 12 | 13 | This situation promotes inefficiencies and makes the managers more difficult to work with. They don't want to share information, but they do want to take ownership of developers' work or ideas that they didn't have themselves. This environment gets very political very fast, and productivity is effected. 14 | 15 | The manager I describe above should ideally be defending the developer team, and should act like an agent for that team. Logically, a developer, or a group of developers, should therefore have the power to nominate, appoint, and sack the manager if necessary. 16 | 17 | The developers should hold the balance of power. 18 | 19 | Developers should also be able to take decisions on pay, perks, and budgets. Business should treat the developer teams as the grownups they are, because the developer teams are ultimately accountable for what is created within the company. 20 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Every-bug-is-an-opportunity.md: -------------------------------------------------------------------------------- 1 | ### Every Bug is an Opportunity 2 | 3 | The power of having a very high degree of code coverage (97%+) is that you have a system where making changes is easy. 4 | 5 | The tests are easy to fix, and you don't have an asymmetric code fixing problem, where a small change of code gives you a nightmare of test changes, or vice versa. 6 | 7 | Instead, you get a very interesting flow where every bug, every security issue, or every code change is an opportunity to check the validity of your tests. **Every time you make a code change, you want the tests to break**. In fact you should worry if the tests don't break when you make code changes. 8 | 9 | You should also worry if the tests break at a different location than expected. This means that the change you made is not having the desired effect. Either your tests are wrong, or you don't have the right coverage, because you expected the test to break in one location but it broke somewhere else, maybe even on a completely different test that happened to pass that particular path. 10 | 11 | To enforce the quality of your test, especially when you have a high degree of coverage, use every single bug fix, and every single code change as opportunities to confirm that your tests are still effective. 12 | 13 | Every code change gives the opportunity to make sure that the understanding of what should change is what did change. Every bug allows you to ask the questions, _"Can I replicate this bug? Can I correctly identify all that is needed to replicate the creation, or the expectation of this bug?"_ 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Every-project-starts-with-100-code-coverage.md: -------------------------------------------------------------------------------- 1 | ### Every project starts with 100% code coverage 2 | 3 | Every application starts with 100% code coverage because by definition, when you start coding, you cover all the code. 4 | 5 | You must ensure that you have a very high degree of code coverage right from the beginning. Because if you don't, as you add code, it is easier to let code coverage slip, and then you realise that large chunks of your code base are not tested (any code that is changed without being tested, is just a random change). 6 | 7 | Reasons why code coverage slips: 8 | 9 | * code changes are not executed using tests 10 | * code coverage is not being used as a debug tool 11 | * code coverage is not shown in the IDE in real-time 12 | * demo or go-live deadline 13 | * mocks and interfaces are used to isolate changes (ironic side effect) 14 | * certain parts of the application are hard to test 15 | * weak testing technology and workflows 16 | * tests are written by separate teams (for example separate dev and QA teams) 17 | * lack of experience by developers, testers and management on the value and power of 100% code coverage 18 | 19 | All of these are symptoms of insecure development practices, and will have negative side effects in the medium term. 20 | 21 | It is very important to get back to 100% code coverage as soon as possible. This usually will require significant efforts in improving the testing technology, which is usually where the problems start (i.e. lack of management support for this effort) 22 | 23 | Some of unmanaged languages, or even managed languages (like Java with the way exceptions are handled), have difficulties in measuring certain code paths. There is nothing wrong in changing coding patterns or conventions to improve an tool's capabilities, in this case the code coverage technology's ability to detect code execution paths. 24 | 25 | It is very important that the development team has the discipline and habit of always keeping the application on 100% code coverage. Having the right tools and worlflows will make a massive difference (for example Wallaby for Javascript or NCunch for .NET) 26 | 27 | For the teams that are really heavy into visualisation and measuring everything, it is very powerful to use dashboards like the ones created by Kibana to track code coverage in real-time (i.e. see test's execution as they occur in multiple target environments: dev, qa, pre-prod and prod). 28 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Feedback-loops.md: -------------------------------------------------------------------------------- 1 | ### Feedback Loops 2 | 3 | The key to DevOps is feedback loops. The most effective and powerful DevOps environments are environments where feedback loops, monitoring, and visualizations are not second-class citizens. The faster you release, the more you need to understand what is happening. 4 | 5 | DevOps is not a silver bullet, and in fact anyone saying so is not to be trusted. DevOps are a profound transformation of how you build and develop software. 6 | 7 | DevOps are all about small interactions, small development cycles, and making sure that you never make big changes at any given moment. The feedback loop is crucial to this because it enhances your understanding and allows you to react to situations very quickly. 8 | 9 | The only way you can react quickly is if you have programmatically codified your infrastructure, your deployment, and your tests. What you want is automation of your understanding, and of your tests. The feedback loops you get make this possible. 10 | 11 | The success stories of DevOps are all about the companies who moved from waterfall style, top-down development, to a more agile way of doing things. The success of DevOps has also allowed teams that were agile but weren't working very well, to ship faster. 12 | 13 | I like the idea of pushing as fast as possible to production. It is essential to have the two pipelines I mention elsewhere in the book, where, if you codify with specific patterns that you know, you go as fast as possible. If you add changes that introduce new patterns or change the attack surface, you must have a separate pipeline that triggers manual or automated reviews. 14 | 15 | The feedback loops allow you to understand this. The feedback loops allow you to understand how to modify your attack surface, how to change how your application behaves, and how to change key parts of how everything works. 16 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/For-developers.md: -------------------------------------------------------------------------------- 1 | ## For Developers 2 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Make-managers-accountable.md: -------------------------------------------------------------------------------- 1 | ### Make managers accountable 2 | 3 | Managers need to be held accountable for the decisions they make, especially when those decisions have implications for quality and security. There are several benefits to increased accountability. Organisations will be encouraged to accept risk, and, before they click on the 'Accept Risk' button, managers will be compelled to 'read' the ticket information. However, the introduction and development of a more accountable management structure is a long game, to be played out over many months, or even years. Sometimes, it requires a change in management to create the right dynamic environment. 4 | 5 | Usually, a new manager will not be too enthusiastic when he sees the risks that are currently accepted by a business and are now his responsibility. He knows he has a limited window, of a few months perhaps, where he can blame his predecessor for any problems. After that time has passed, he 'owns' the risk, and has accepted it himself. 6 | 7 | This workflow creates historical records of decisions, which supports and reinforces a culture of accountability. 8 | 9 | In agile environments, the Product Owner is responsible for making the right decisions. 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Risk-lifecycle.md: -------------------------------------------------------------------------------- 1 | ### Risk lifecycle 2 | 3 | Here are the multiple stages of Risks: 4 | 5 | ```viz 6 | digraph { 7 | size ="3.4" 8 | node [shape=underline] 9 | 10 | "Risk" -> "Test (reproduces issue)" [label = "write test"] 11 | "Test (reproduces issue)" -> "Risk Accepted" [label = "accepts risk"] 12 | "Test (reproduces issue)" -> "Fixing" [label = "allocated for fix"] 13 | "Test (reproduces issue)" -> "Regression Tests" [label = "fixed"] 14 | } 15 | ``` 16 | 17 | ---- 18 | 19 | It is key that a test that replicates the issue reported is created. 20 | 21 | The tests result for each of the bottom layers mean different things: 22 | 23 | * **Risk Accepted** : Issues that will NOT be fixed and represent the current accepted Risk profile of the target application or company 24 | * **Fixing**: Issues that are currently being actively addressed (still real Risks) 25 | * **Regression Tests**: Past issues that are now being tested to confirm that they no longer exist. Some of these tests should run against production. 26 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Risk-profile-of-frameworks.md: -------------------------------------------------------------------------------- 1 | ### Risk profile of Frameworks 2 | 3 | Many frameworks work as a wrapper around a 'raw' language and have built in mechanisms to prevent vulnerabilities. 4 | 5 | Examples are: 6 | 7 | - Rails for Ruby 8 | - Django for Python 9 | - AngularJS, Ember, ReactJS for javascript 10 | - Razor for .Net 11 | 12 | Using these frameworks can help less experienced developers and act as a 'secure by default' mechanism. 13 | 14 | This means that when using the 'secure defaults' of these frameworks, there will be less Risk tickets created. Ideally Frameworks will make it really easy to write secure code, and really hard (and visible) to write dangerous/insecure code (for example how AngularJS handles raw HTML injection from controllers to views). 15 | 16 | This can backfire when Frameworks perform complex and dangerous operations 'automagically'. In those cases it is common for the developers to not really understand what is going on under the hood, and high risk vulnerabilities will be created (sometimes even using the code based on the Framework's own code samples) 17 | 18 | * Add case-studies on issues created by 'normal' framework usage: 19 | * SpringMVC Auto-Binding (also called over-posting) 20 | * Razor controls vulnerable to XSS on un-expected locations (like label) 21 | * Ember SafeHtml 22 | * OpenAM SQL Query Injection on code sample (and see in live app) 23 | * Android query SQL Injection (on some parameters) 24 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Test-lifecycle.md: -------------------------------------------------------------------------------- 1 | ### Test lifecycle 2 | 3 | - explain test flow from replicating the bug all the way to regression tests 4 | 5 | ```viz 6 | digraph { 7 | size ="3.4" 8 | node [shape=box] 9 | "Bug"-> "Test Reproduces Bug" 10 | -> "Root cause analysis" 11 | -> "Fix" 12 | -> "Test is now Regression test" 13 | -> "Release" 14 | } 15 | ``` 16 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/Using-git-as-a-backup-strategy.md: -------------------------------------------------------------------------------- 1 | ### Using Git as a Backup Strategy 2 | 3 | When you code, you inevitably go on different tangents. Git allows you to keep track of all those tangents, and it allows you to record and save your progress. 4 | 5 | In the past, we used to code for long periods of time and commit everything at the end. The problem with this approach is that sometimes you follow a path to which you might want to return, or you might follow a path that turns out to be inefficient. If you commit both early and often, you can keep track of all such changes. This is a more efficient way of programming. 6 | 7 | Of course, before you make the final commit, and before you send the push to the main repository, you should clean up and ensure the code has a certain degree of quality and testing. 8 | 9 | I find that every time I code, even for a short while, my instinct is to write a commit, and keep track of my work. Even if I add only a part of the code, or use the staging capabilities to do some selective commits, I find that Git gives me a much cleaner workflow. I can be confident in my changes from start to end, and I rarely lose any code or any snippet with which I was happy. 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-developers/x.Creating-better-briefs.md: -------------------------------------------------------------------------------- 1 | ### Creating better briefs 2 | 3 | Developers should use the JIRA workflow to get better briefs and project plans from management. Threat Models are also a key part of this strategy. 4 | 5 | Developers seldom find the time to fulfil the non-functional requirements of their briefs. The JIRA workflow gives developers this time. 6 | 7 | The JIRA workflow can help developers to solve many problems they have in their own development workflow (and SDL). 8 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Annual-reports-should-contain-infosec-[art.md: -------------------------------------------------------------------------------- 1 | ### Annual Reports should contain a section on InfoSec 2 | 3 | Annual reports should include sections on InfoSec and AppSec, which should list their respective activities, and provide very detailed information on what is going on. 4 | 5 | Most companies have Intel dashboards of vulnerabilities, which measure and map risk within the company. Companies should publish that data, because only when it is visible can you make the market work and reward companies. Obliging companies to publish security data will make them understand the need to invest, and the consequences of the pollution that happens when you have rented projects with crazy deadlines and inadequate resources, but somehow manage to deliver. 6 | 7 | The ability to deliver in such chaotic circumstances is often due to the heroic efforts of developers, who work extremely hard to deliver high quality projects, but get rewarded only by being pushed even more by management. This results in extraordinary vulnerabilities and risks being created and bought by the company. Of course, the company doesn't realize this until the vulnerabilities are exploited. 8 | 9 | In agile environments, it's important to provide relative numbers such as: 10 | 11 | * Risk issues vs velocity 12 | * Risk issues vs story points 13 | 14 | By analyzing these numbers over time, the tipping point, where quality and security are no longer in focus, can become painfully clear. 15 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Code-confidence-index.md: -------------------------------------------------------------------------------- 1 | ### Code Confidence Index 2 | 3 | Most teams don't have confidence in their own code, in the code that they use, in the third parties, or the soup of dependencies that they have on the application. This is a problem, because the less confidence you have in your code, the less likely you are to want to make changes to that code. The more you hesitate to touch it, the slower your changes, your re-factoring, and your securing of the code will be. 4 | 5 | To address this issue, we need to find ways to measure the confidence of code, in a kind of **Code Confidence Index** (COI). 6 | 7 | If we can identify the factors that allow us to measure code confidence, we would be able to see which teams are confident in their own or other code, and which teams aren't. 8 | 9 | Ultimately, the logic should be that the teams with high levels of _Code Confidence_ are the teams who make will be making better software. Their re-factoring is better, and they ship faster. 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Feedback-loops-are-key.md: -------------------------------------------------------------------------------- 1 | ### Feedback loops are key 2 | 3 | A common error occurs when the root cause of newly discovered issues or exploits receives insufficient energy and attention from the right people. 4 | 5 | Initially, operational monitoring or incident response teams identify new incidents. They send the incidents are to the security department, and after some analysis the development teams receive them as tickets. The development teams receive no information about the original incident, and are therefore unable to frame the request in the right perspective. This can lead to suboptimal fixes with undesired side effects. 6 | 7 | It is beneficial to include development teams in the root cause analysis from the start, to ensure the best solutions can be identified. 8 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/For-management.md: -------------------------------------------------------------------------------- 1 | ## For management 2 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Getting-assurance-and-trust-from-appsec-tests.md: -------------------------------------------------------------------------------- 1 | ### Getting Assurance and Trust from Application Security Tests 2 | 3 | When you write an application security test, you ask a question. Sometimes the tests you do don't work, but the tests that fail are as important as the tests that succeed. Firstly, they tell you that something isn't there today so you can check it for the future. Secondly, they tell you the coverage of what you do. 4 | 5 | These tests must pass, because they confirm that something is impossible. If you do a SQL injection test, in a particular page or field, or if you do an authorization test, and it doesn't work, you must capture that. 6 | 7 | If you try something, and a particular vulnerability or exploit isn't working, the fact that it doesn't work is a feature. The fact that it isn't exploitable today is something that you want to keep testing. Your test confirms that you are not vulnerable to that and that is a powerful piece of information. 8 | 9 | You should have tests for both the things you know are problems, and the things you know are not problems. Such tests give you confidence that you have tested your application for certain things. 10 | 11 | Be sure that you have enough coverage of those tests. You also want to relate this to code coverage and to functionality, because you want to make sure that there is direct alignment between what is possible on the application and what is invoked by the test they should match. 12 | 13 | The objective is to have much a stronger assurance of what is happening in the application, and to detect future vulnerabilities (created in locations that were not vulnerable at the time of the last security assessment). 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Inaction-is-a-risk.md: -------------------------------------------------------------------------------- 1 | ### Inaction is a risk 2 | 3 | Lacking the time to perform 'root cause analysis', or not understanding what caused a problem, are valid risks in themselves. 4 | 5 | It is key that these risk are accepted 6 | 7 | This is what makes them 'real', and what will motivate the business owner to allocate resources in the future. Specially when a similar problem occur. 8 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Insurance-driven-security.md: -------------------------------------------------------------------------------- 1 | ### Insurance Driven Security 2 | 3 | * insurance companies are starting to operate in the AppSec work 4 | * they will need objective way to measure RISK 5 | * workflows like this one could provide that 6 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Is-the-decision-hyper-linked.md: -------------------------------------------------------------------------------- 1 | ### Is the Decision Hyperlinked? 2 | 3 | I regularly hear the following statements: "The manager knows about it", "I told you about this in the meeting", "Everyone is aware of this", and so on. However, if a decision is not in a hyperlinkable location, then the decision doesn't exist. It is vital that you capture decisions, because without a very clear track of them, you cannot learn from experience. 4 | 5 | Capturing decisions is most important for the longer term. When you deal with your second and third situations, you start building the credibility to say, "We did this in the past, it didn't work then, and here are the consequences. Here is the real cost of that particular decision, so let's not repeat this mistake". 6 | 7 | It is essential to do postmortems and understand the real cost of decisions. If a comment is made along the lines of, "Oh, we don't have time to do this now because we have a deadline", after a huge amount of manpower and time has been spent fixing the problem, you need to be able to say, "Was that decision the correct one? Let's now learn from that, and really quantify what we are talking about". 8 | 9 | Completing this exercise will give you the knowledge to say the next time, "We need a week, or two weeks, or a month to do this". Or you could say, "Last time we didn't do this and we lost six months". So, it is key not only to capture the decisions, but also to ensure you do a very good postmortem analysis of what happens after risks are accepted. 10 | 11 | When there are negative consequences because of a bad decision, such as security issues or problems of technical debt, it is important that the consequences are hyperlinked back to the original issue for future reference. 12 | 13 | In a way, the original issues are the foundations of the business case for why a problem occurred, and why you don't want to repeat the problem in the future. 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/OWASP-top-10-risk-methodology.md: -------------------------------------------------------------------------------- 1 | ### OWASP Top 10 Risk methodology 2 | 3 | * add details about Risk methodology that in included with the OWASP Top 10 4 | * mention other Risks methodologies 5 | * applying OWASP ASVS allows for a more risk based approach 6 | * OwaspSAMM and BSIMM can measure the maturity level of an organisation 7 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Relationship-with-existing-standards.md: -------------------------------------------------------------------------------- 1 | ### Relationship with existing standards 2 | 3 | It is important have a good understanding of how a company's Risk profile maps to existing security standards alike PCI DSS, HIPAA, and others. 4 | 5 | Most companies will fail these standards when their existing 'real' RISKs are correctly identified and mapped. This explains the difference between being 'compliant' and being 'secure'. 6 | 7 | Increasingly, external regulatory bodies and laws require some level of proof that companies are implementing security controls. 8 | 9 | To prevent unnecessary delays or fines, these requirements should be embedded in the process in the form of regular scans, embedded controls (e.g. in the default infrastructure), or in user stories. 10 | 11 | For example, in DevOps environments all requirements related to OS hardening should be present in the default container. Development teams should not have to think about them. 12 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Responsible-disclosure.md: -------------------------------------------------------------------------------- 1 | ### Responsible disclosure 2 | 3 | Having a responsible disclosure process and/or participating in programs like HackerOne or Bugcrowd have several advantages: 4 | 5 | * it shows a level of confidence to the customers 6 | * it provides additional testing cycles 7 | * it sends a message that they have an AppSec program 8 | 9 | 10 | #### JIRA workflow for bug bounty's submissions 11 | 12 | * add diagram (from XYZ) 13 | * real world example of using an JIRA workflow to manage submissions received 14 | 15 | #### Bug bounties can backfire 16 | 17 | http://www.forbes.com/sites/thomasbrewster/2016/07/13/fiat-chrysler-small-bug-bounty-for-hackers/#58cc01f4606f -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Third-party-components-and-outsourcing.md: -------------------------------------------------------------------------------- 1 | ### Third party components and outsourcing 2 | 3 | * these dependencies need to be managed 4 | * lots of control lost to 3rd parties 5 | * open source and close source are very similar 6 | * at least with open source there is the chance to look at the code (doesn't mean that somebody will) 7 | * companies need developers that are core contributors of FOSS 8 | * outsource code tends to have lots of 'pollution' and RISKs that are not mapped (until it is too late) 9 | * liability and accountability of issues is a big problem 10 | * see OWASP Legal project for an idea of AppSec clauses to include in outsourcing contracts. 11 | * copyright infringes will become more of a problem in the future; this can be hard to identify in 3rd party components 12 | 13 | #### Tools to help manage dependencies 14 | 15 | * OWASP Dependency checker can identify vulnerable components in use 16 | * several commercial tools exist that can identify copyright infringements in components 17 | * Veracode has it 18 | * Sourceclear 19 | * Sonar (check which version) 20 | * nsp node security 21 | * ... add more (see [13 tools for checking the security risk of open-source dependencies](http://techbeacon.com/13-tools-checking-security-risk-open-source-dependencies-0)) 22 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Understant-projects-risks.md: -------------------------------------------------------------------------------- 1 | ### Understand Every Project's Risks 2 | 3 | It is essential that every developer and manager know what risk game they are playing. To fully know the risks, you must learn the answers to the following questions: 4 | 5 | * what is the worst-case scenario for the application? 6 | * what are you defending, and from whom? 7 | * what is your incident response plan? 8 | 9 | Always take advantage of cases when you are not under attack, and you have some time to address these issues. 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Using-logs-to-detect-risks-exploitation.md: -------------------------------------------------------------------------------- 1 | ### Using logs to detect risks exploitation 2 | 3 | Are your logs and dashboards good enough to tell you what is going on? 4 | You should know when new and existing vulnerabilities are discovered or exploited. However, this is a difficult problem that requires serious resources and technology. 5 | 6 | It is crucial that you can at least detect known risks without difficulty. Being able to detect known risks is one reason to create a suite of tests that can run against live servers. Not only will those tests confirm the status of those issues across the multiple environment, they will provide the NOC (Network Operations Centre) with case studies of what they should be detecting. 7 | 8 | #### Beware of the security myth 9 | 10 | Often, no special software or expertise is needed to identify basic, potential, bad behavior. 11 | Usually, companies already have all the tools and technology they need in-house. The problem is making those tools work in the company's reality. 12 | For example, if someone accesses 20 non-existing pages per second for several minutes, it is most likely they are brute-forcing the application. 13 | You can easily identify this by monitoring for 404 and 403 errors per IP address over time. 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Using-tests-to-communicate.md: -------------------------------------------------------------------------------- 1 | ### Using Tests to Communicate 2 | 3 | Teams should talk to each other using tests. Teams usually have real problems communicating efficiently with each other. You might find an email, a half-baked bug-tracking issue opened, a few paragraphs, a screen shot, and if you are lucky, a recorded screencast movie. 4 | 5 | This is a horrible way to communicate. The information isn't reusable, the context isn't immediately clear, you can't scale, you can't expand on the topic, and you can't run it automatically to know if the problem is still there or not. This is a highly inefficient way to communicate. 6 | 7 | The best way for teams to communicate is by using Tests. 8 | 9 | Both within and across teams; top-down and bottom-up, from managers and testers to teams. 10 | 11 | Tests should become the lingua franca of companies. Their main means of communication. 12 | 13 | This has tremendous advantages, since in order for it to work, it requires really very good test APIs, and very good execution environments. 14 | 15 | One must have an easy-to-develop, easy-to-install, and easy-to-access development environment in place, something that very rarely occurs. 16 | 17 | By making tests the principal way teams communicate, you create an environment that not only rewards good APIs, it rewards good solutions for testing the application. Another advantage is that you can measure how many tests have been written across teams and you can review the quality of the tests. 18 | 19 | Not only is this a major advantage to a company, it is also a spectacular way to review changes. If you send a test that says, _"Hey! I would like XYZ to occur"_, or _"Here is a problem"_, then the best way to review the quality of the change is to review the test that was modified in order to solve the problem. 20 | 21 | In this scenario, you have a test that reflects the fixed state of a behaviour, and you have a test that communicates the changes you want to make. A review of both tests is often the best way to evaluate if the requested changes have been made and are working as desired. 22 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-management/Who-is-actually-making-decisions.md: -------------------------------------------------------------------------------- 1 | ### Who is actually making decisions? 2 | 3 | One of the interesting situations that occurs when we play the risk acceptance game at large organisations, is how we are able to find out exactly who is making business and technical decisions. 4 | 5 | Initially, when a 'Risk Accepted' request is made, what tends to happen is that the risk is pushed up the management chain, where each player pushes to their boss to accept risk. After all, what is at stake is who will take responsibility for that risk, and in some cases, who might be fired for it. 6 | 7 | Eventually there is a moment when a senior director (or even the CTO) resists accepting the risk and pushes it down. What he is saying at that moment in time, is that the decision to accept that particular risk, has to be made by someone else, who has been delegated (officially or implicitly) that responsibility. 8 | 9 | In some cases this can now go all the way down to the actual developer/team doing the coding. Paradoxically, usually the developer didn't realise until that moment, that he is one that is actually deciding how and when to fix it (or not). 10 | 11 | Developers often hold a huge amount of power, but they just don't know it. 12 | 13 | Playing the risk acceptance game, and identifying who is deciding on risk, is a way of empowering the actual decision-maker. Once the person realises their role and power, they can make sure they have realistic time-scales to fix the issue accordingly, and when required, make the case for more time, more resources, or even a more defined role as a decision-maker. 14 | 15 | This exercise is very important because, until you discover who clicks on the 'Accept Risk' button, there is little knowledge about who (if anybody at all) is making important decisions. 16 | 17 | Risk issues can only be on one of two moving paths: _'Fixing path'_ and _'Risk Acceptance path'_. Since deciding not to act on a particular issue is a decision in itself, the Risk workflow makes sure that issues don't 'disappear' in informal conversions, emails or documents. 18 | 19 | This is also a good example why _Pollution_ is a better analogy than _Technical Debt_. Features that are pushed with un-realistic deadlines or bad briefs will create a higher number of Risk tickets (i.e. pollution) which will have to be accepted by the business owners (who agreed on the development brief and time-scales) 20 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-security-teams/Do-security-reviews-every-sprint.md: -------------------------------------------------------------------------------- 1 | ### Do security reviews every sprint 2 | 3 | If you have an agile development environment, you need to implement security procedures and security reviews at the end of every sprint. In the period between the sprint finishing and going live, you need to do a push to get a sense of whether the original threats and issues, that were highlighted in the threat model, were done, or exist, in a verifiable way. 4 | 5 | The central AppSec team shouldn't do this test. 6 | 7 | The target application security champion(s) should do this 'smaller' review, in their one-day-a-week allocated to AppSec activities. They should only ask the central AppSec team for help if they need it. 8 | 9 | When you create a threat model before the application or feature is built, you know in advance which apps will need a more in-depth security review or analysis. This will depend on the size of the changes, what is being changed, or the assets being handled. This allows scheduling of the more experienced and knowledgeable AppSec professionals, who can be internal or external entities. 10 | 11 | Note that these 'sprint reviews' are not meant to replace a final security push, or, when required, pentests (i.e. Application Security assessments). 12 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-security-teams/For-security-teams.md: -------------------------------------------------------------------------------- 1 | ## For security Teams 2 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/For-security-teams/create-a-technology-advisory-board.md: -------------------------------------------------------------------------------- 1 | ### Create an Technology Advisory Board 2 | 3 | One of the biggest challenges in Agile and DevOps environments is the adoption rate of new technologies. In order to be as agile as possible there is a tendency to adopt new technology whenever it appears to have an advantage. 4 | 5 | Common examples are cloud technology, analytic tools, continuous integration tools, container technology, web platforms and frameworks, and client-side frameworks. 6 | 7 | To prevent the adoption of immature, insecure, or privacy violating components it is important to review desires and proposed solutions. The technology advisory board should take up this role. It should consist of people with security, privacy, and (some) legal knowledge. 8 | 9 | It is important to not make this a new _'Change advisory board'_ with monthly review sessions doing a complete business impact analysis. Rather it should be in the form of a guild that is able to identify the maturity of the technology and possible impact on the ecosystem when things go wrong. 10 | 11 | It can also guard for implementing multiple tools with the same purpose. 12 | 13 | In this way the total ecosystem can be as lean and secure as possible. 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Capture-knowledge-when-devs-look-at-code.md: -------------------------------------------------------------------------------- 1 | ### Capture knowledge when developers look at code 2 | 3 | It is vital that when a developer is looking at code, he can create tickets for 'things noticed' without difficulty. 4 | For example, 'things noticed' include methods that need refactoring, complex logic, weird code, hard-to-visualize architecture, etc. 5 | If this knowledge is not captured, it will be lost. 6 | 7 | The developer who notices an issue, and opens a ticket for the issue, will be unable to do anything about it at that moment in time, since he will already be focused on resolving another bug. 8 | 9 | Instead, more junior developers, graduate employees or interns could take responsibility for opening and managing these tickets. 10 | 11 | They could even try to address the issues in the first instance, because the developer is responsible for merging the PRs. 12 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Describe-risks-as-features.md: -------------------------------------------------------------------------------- 1 | ### Describe Risks as Features rather than as Wishes 2 | 3 | When opening a risk JIRA ticket, it is essential to describe the exact behavior of that issue **as a feature**, rather than describing what you would like to see happening (i.e. your wish list). 4 | 5 | For example: 6 | 7 | - instead of saying _'application should encode XYZ value'_, you should say _'XYZ value is not encoded'_ 8 | - instead of saying _'application shouldn't be vulnerable to XSS or SQL injection'_, you should say _'application is vulnerable to SQL injection'_. In this case, SQL Injection is a **feature** of the application, and while the application allows SQL Injection, the application is working as designed (whether that is intended or not is a different story). 9 | 10 | When we describe vulnerabilities, we describe features, because vulnerability is a feature of an application. 11 | 12 | If an application has a direct object reference vulnerability (OWASP Top 10), then that is a feature that allows _User A to access user B data_ (by design, using the capabilities of the application). 13 | 14 | For each of these cases, you should open risk tickets, since those risks represent existing features. Sometimes you open multiple risks for the same issue, allowing technical and business audiences to understand what is going on (SQL Injection doesn't mean a lot to management, but _'Access and modify all customer data'_ does). 15 | 16 | I remember a funny story where we found SQL injection in a pentest, and when we presented the findings, the business responded: _'... well, that is not a critical issue, we have good backups, so that SQL injection is not dangerous'_. When we asked _'what if we can drop all tables?'_ , they said _'We can recover from that very fast, no problem.'_ 17 | 18 | We argued _'well ... we can modify data'_ and they came back with, _'We have read-only access and we can protect it from there.'_. But finally, when we stated _'we can log in as any user with a typical SQL Injection payload of: or 1=1_' that connected the dots, and the business said _'we will fix that ASAP'_ 19 | 20 | The reason that example clicked was because we showed them how to bypass the business logic of the application using the SQL Injection **'feature'**. They could tolerate, to a degree, data corruption or content changes. However, they reacted when they saw that the SQL Injection could bypass the application's business logic and break their [non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation) capabilities (i.e. they would lose the ability to understand what a user did on the site). 21 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Git-for-security.md: -------------------------------------------------------------------------------- 1 | ### Git for security 2 | 3 | * Why Git and DVCS (Distributed Version Control Systems (check name)) are so important for Quality and Security 4 | * Why migrating to git is a good idea 5 | * Analogy with Docker 6 | 7 | **How git workflows can be used for security** 8 | 9 | * add explation 10 | 11 | **git and svn** 12 | 13 | * The Git Svn story 14 | * 'Kinda' the same workflows, just different 15 | * Git developers to decision to make the opposite decision of Svn 16 | * why? ... not just a dig at Svn. concept represents different approaches and focus 17 | * speed of git checkouts 18 | * virtual file systems 19 | * nightmare of moving files in svn () 20 | * the power of one .git folder 21 | 22 | 23 | I> Note: find better chapter for this content ('git and svn') 24 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Issue-tracking-solution.md: -------------------------------------------------------------------------------- 1 | ### Issue tracking solution 2 | 3 | The issue tracking solution you choose is highly important. 4 | 5 | To ensure maximum productivity always perform the following tasks: 6 | 7 | * copy and paste your screenshots 8 | * hyperlink your issues 9 | * use markdown or wikitext 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Jira-risk-workflow.md: -------------------------------------------------------------------------------- 1 | ## JIRA RISK Workflow 2 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Key-concepts/Key-concepts.md: -------------------------------------------------------------------------------- 1 | ### Key concepts 2 | 3 | ![](images/Screen Shot 2016-03-02 at 16.32.58.png) 4 | 5 | The following are the key concepts of this workflow: 6 | 7 | * All tests should pass all the time 8 | * Tests that check or confirm vulnerabilities should also pass 9 | * Business owners must understand the risks of their decisions, and they must click on the 'accept risk' button 10 | 11 | This workflow is about empowerment and assigning responsibility; it is not about apportioning blame. 12 | 13 | Although I use JIRA for these examples, these concepts also apply to any bug-tracking system. 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Key-concepts/images/Screen Shot 2016-03-02 at 16.32.58.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/2.Risk-workflow/Jira-risk-workflow/Key-concepts/images/Screen Shot 2016-03-02 at 16.32.58.png -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Risk-accepting-threat-model.md: -------------------------------------------------------------------------------- 1 | ### Risk accepting threat model 2 | 3 | If you have trouble getting developer teams to create threat models, or to spend time on those threat models, then the solution is to make them accept the risk incurred from not having a threat model for the application. 4 | 5 | The idea is not to be confrontational. Instead, stating that a feature has no threat model is a very pragmatic, focused, and objective statement. 6 | 7 | The idea is that the developer team must accept that they don't have a threat model. The logic is to create a ticket that says there is no threat model, and the ticket will be closed when the threat model is created. Alternatively, if the developers and their management team don't want to spend the time creating a threat model, they must accept the risk of not having one. 8 | 9 | This can be difficult to accept, but it's an important part of the exercise. 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/Storing-risk-issues-on-jira.md: -------------------------------------------------------------------------------- 1 | ### Storing risk issues on JIRA 2 | 3 | Is a JIRA ticket system a security risk 4 | 5 | - Are they zero days? 6 | - Is it increasing the attack surface 7 | - 'If it is on fire, fix it and document it later, if not on fire, document it' 8 | - ... better to know about it and to make it explicit that it will be exposed 9 | - ... in reality that info already exists on JIRA (maybe not so obvious) 10 | - Monitoring the JIRA access could provide info about an attacker 11 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-risk-workflow/The-smaller-the-better.md: -------------------------------------------------------------------------------- 1 | ### The smaller the ticket scope the better 2 | 3 | For bugs and tasks, the smaller the bug the better. 4 | 5 | Having many small bugs and issues can be an advantage for the following reasons: 6 | 7 | - easier to code 8 | - easier to delegate (between developers) 9 | - easier to outsource 10 | - easier to test 11 | - easier to roll back 12 | - easier to merge into upstream or legacy branches 13 | - easier to deploy 14 | 15 | It is better to put them in a special JIRA project(s) which can be focused on quality or non-functional requirements. 16 | 17 | Of course, this needs to be rational and kept in context. 18 | You should only create a couple of each instance/pattern, particularly when they are not being fixed. In such cases, create a 'holding ticket' that will store references to all the individual issues, which is good for systemic vulnerabilities. 19 | 20 | You should also aggregate issues in Stories. 21 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Confluence.md: -------------------------------------------------------------------------------- 1 | ### Confluence 2 | 3 | - Atlassian wiki solution 4 | - Tight integration with JIRA 5 | - useful for reporting and Threat modeling 6 | - used to create the materials used in weekly/monthly reports to owners of RISKs (i.e. the ones that have accepted the Risk) 7 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/JQL-query-language.md: -------------------------------------------------------------------------------- 1 | ### JQL Query Language 2 | 3 | - how it works 4 | - security implications 5 | - power examples of queries 6 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-components.md: -------------------------------------------------------------------------------- 1 | ### Jira components 2 | 3 | - used to map issues to specific projects 4 | - allow easy filer per project 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-copy-and-paste-of-images.md: -------------------------------------------------------------------------------- 1 | ### Copy and paste of images 2 | 3 | - only available in the most recent version of JIRA but a feature that makes a massive difference 4 | - the file attachment of images also works quite well 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-dashboards.md: -------------------------------------------------------------------------------- 1 | ### JIRA dashboards 2 | 3 | - how to create them 4 | - pie chart and issues list 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-filters.md: -------------------------------------------------------------------------------- 1 | ### JIRA Filters 2 | 3 | - how to use them 4 | - saving them 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-kanban-boards.md: -------------------------------------------------------------------------------- 1 | ### JIRA Kanban boards 2 | 3 | - really good to track specific projects 4 | - show couple examples 5 | - add how to create on 6 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-labels.md: -------------------------------------------------------------------------------- 1 | ### JIRA Labels 2 | 3 | - show examples 4 | - how to use them 5 | - common workflow 6 | - using them to map OWASP Top 10 issues 7 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-technologies.md: -------------------------------------------------------------------------------- 1 | ## JIRA Technologies 2 | 3 | This section covers the multiple technologies used 4 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Jira-technologies/Jira-workflows.md: -------------------------------------------------------------------------------- 1 | ### JIRA workflows 2 | 3 | - explain what they are what makes them powerful 4 | - key components of it 5 | 6 | - a good workflow tells a story and guides the user down specific paths 7 | 8 | **Tidy up your diagrams** 9 | 10 | It is important that your diagrams have layouts that look good and make sense. 11 | 12 | The Diagram UI allows a bit of flexibility on where the Stages appear, so make use it and create nice diagrams 13 | 14 | - show where they can be seen in the UI 15 | - makes big difference when they are easy to read and understand 16 | - I hide the labels since I find that they are harder to position and don't provide that much more information 17 | 18 | - add example of two diagrams diagrams. Same content: one messy and one clean 19 | * note how the clean one is much easier to read 20 | 21 | **Naming of states** 22 | 23 | - This is very important since they need to convey the desired action 24 | - names have to be short or they don't look good in the UI 25 | 26 | **Other workflows** 27 | 28 | Add screenshots for: 29 | - bug bounty 30 | - development 31 | - other ... 32 | 33 | **A simple workflow** 34 | 35 | - add example of a simple workflow 36 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/AppSec-technologies-and-tools.md: -------------------------------------------------------------------------------- 1 | ### AppSec Technologies and tools 2 | 3 | The AppSec community and industry has some really powerful technologies and tools that not only help to find security issues, but can also be spectacular developer productivity tools. 4 | 5 | (todo: expand on each technology, mention best players (open Source and proprietary) and provide examples of how they can be used very effectively) 6 | 7 | * **DAST** - Dynamic scanning (Blackbox) 8 | * **SAST** - Static scanning (WhiteBox) 9 | * **IAST** - Interactive scanning 10 | * **WAF** - Web Application Firewall 11 | * **Reporting** 12 | * **Consolidation** 13 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Collaboration-technologies.md: -------------------------------------------------------------------------------- 1 | ### Collaboration Technologies 2 | 3 | The following technologies are crucial for Security Champions and JIRA workflows to work efficiently: 4 | 5 | * **Email** - good when used in moderation, especially when emails contain links to online resources 6 | * **Mailing lists** - still the best collaboration tool, as they scale a lot, are easy to filter, they reach a wide audience, are a great way to motivate new Security Champions when they see their name on the list, and they allow interested parties (and older non-active Security Champions) to stay connected to what is going on 7 | * **JIRA issues** - discussion threads provide a lot of information and details about specific topics 8 | * **Wiki** - key to capture knowledge in a more structured and long-term environment. Remember that wikis require maintenance and should be curated so that they remain relevant and don't fall for the 'tragedy of the commons' problem. Wiki's should use JIRA issues as evidence of what is said. 9 | * **Confluence** - when integrated with JIRA, it creates a powerful way to create dashboards that present the data stored in the JIRA tickets 10 | * **Video conferences** - tools like Join.me, BlueJeans, Google Hangouts, and Skype are great ways to make remote working and participation possible 11 | * **Slack** - real-time collaboration tools are key to allow questions to be easily asked, and to allow for asynchronous collaboration, and catching up on specific topics 12 | * **Slack integrations** - very powerful workflows can occur when SDL tools (and CI pipelines) feed data into specific channels. This is not only a good way to get a sense of what is going on, but also a good way to alert for possible issues or attacks. It gets even better when these integrations are interactive: 13 | * **Hubot(s)** - is a great example of this (where it can listen to messages posted and respond to them) 14 | * **Log visualization** - tools like Splunk, ELK or Graphite, when supported by strong dashboards and visualizations, are one of the best ways to present information and collaborate 15 | * **Diagram technologies** - Visio has been the gold standard for a long time (draw.io is a recent new player), but the problem is their lack of non-human readable data storage format. To promote collaboration and allow for 'revision of what changed since last analysis' (i.e. Diffs), diagramming technologies, created from textual descriptions, are much more powerful and useful, for example PlantUML or DOT (Graphwiz), which are easier to read (in source format) and can be stored in git (i.e. versioned controlled) 16 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Conference-for-security-champions.md: -------------------------------------------------------------------------------- 1 | ### Conference for Security Champions 2 | 3 | Every 6 to 12 months, it is a good idea to hold a conference exclusively dedicated to security champions, particularly for companies that have multiple locations, where its security champions don't meet regularly in person. 4 | 5 | 6 | At the conference, external speakers should present on specific topics. 7 | 8 | If there are already several external AppSec consulting companies under contract to the hosting company, the consultants involved in existing projects are perfect candidates to present to the conference. They can use their own examples and stories, and it is easier to present internal materials if all participants are signed-up to the same NDA (Non-Disclosure Agreement). 9 | 10 | Never underestimate the power of team collaboration, or of team members getting to know each other. Social events are important, and the model of the OWASP Summit is also a good example of a conference for security champions, as is the Microsoft Blue Hat security conference. 11 | 12 | (find other examples) 13 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Do-you-have-an-heartbeat-you-qualify.md: -------------------------------------------------------------------------------- 1 | ### If you have a heartbeat, you qualify! 2 | 3 | It is important to understand that AppSec skills are not a key requirement to become a security champion. The essential quality is to want to become one. 4 | 5 | I can make a good developer, who is interested and dedicated, into a good AppSec specialist in 6 months. 6 | If the developer is an expert in AppSec, then he should join the central AppSec team. 7 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/How-to-review-applications-as-an-sc.md: -------------------------------------------------------------------------------- 1 | ### How to review Applications as a Security Champion 2 | 3 | When you review applications as a security champion, you need to start by looking at the application from the point of view of an attacker. In the beginning, this is the best way to learn. 4 | 5 | You should start thinking about data inputs, about everything that goes into the database, the application, all the entry points of the application. In short, think about everything an attacker could control, which could be anything from headers, to cookies, to sockets, to anything that enters the application. 6 | 7 | Authorization is also a great way to look at the application. Just looking at how you handle data, and how you authorize things, is a great way to understand how the application works. 8 | 9 | * add info about how this is best done using Threat Models and asking the STRIDE questions 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/If-you-dont-have-an-sc-get-a-mug/If-you-dont-have-an-sc-get-a-mug.md: -------------------------------------------------------------------------------- 1 | ### If you don't have a Security Champion, get a mug 2 | 3 | If your developer team doesn't have an assigned security team champion, get one of these mugs. 4 | 5 | ![](images/Security-champion-mug.jpg) 6 | 7 | That 'Security Expert' mug represents the fact that, without a security champion, when a developer has an application security question, he might as well ask the dude on that mug for help. 8 | 9 | I also like the fact that the mug reinforces the idea that for most developer teams, **just having somebody assigned to application security is already a massive step forward!!** 10 | 11 | Basically, we have such a skill shortage in our industry for application security developers that **'if you have a heartbeat you qualify'** 12 | 13 | #### How to create the SC Mug 14 | 15 | * Get a mug with lots of white space on the front and back 16 | * write **_Security Champion_** at the front in large letters (but not so big that the text can't be read from a distance) 17 | * Alternatively, at the back write: **_It's me, or Google, or Stack Overflow_** 18 | * Or, if you have a small company stuffed animal or object, put it inside the mug 19 | 20 | Put the mug in a central location, visible place to the team. It is important that the mug is in a neutral place, and not 'assigned' to anybody. 21 | 22 | In some teams, I've observed a ritual when a Security Champion is appointed, presented with the mug, and expected to keep it on his/her desk. 23 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/If-you-dont-have-an-sc-get-a-mug/images/Security-champion-mug.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/2.Risk-workflow/Security-champions/If-you-dont-have-an-sc-get-a-mug/images/Security-champion-mug.jpg -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Involvement-in-senior-technical-discussions.md: -------------------------------------------------------------------------------- 1 | ### Involvement in senior technical discussions 2 | 3 | Involvement in senior technical discussions provides a great opportunity, and a perk, to security champions. 4 | Once a SC program is established, if the SCs should be involved in senior technical discussions. If they aren't, it means that security is not being taken into consideration, and this is a problem. 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Make-sure-your-Security-Champions-are-given-time.md: -------------------------------------------------------------------------------- 1 | ### Make sure your Security Champions are given time 2 | 3 | It is very important that security champions get the time, the space, the mandate, and the information required to do their jobs. 4 | 5 | The good news is, now that you have security champions (at least one per team), their work will allow you to see the differences between the teams and the parts of the company who can make it work, and those who struggle to make it happen. 6 | 7 | To participate successfully in the security of their projects, security champions must execute the following tasks: 8 | 9 | * review code 10 | * fix code 11 | * write tests 12 | * know what is going on 13 | * maintain the JIRA tickets 14 | * create Threat Models 15 | * be involved in the security practices of the teams 16 | 17 | Adherence to these tasks leads to better code, better project briefs, up-to-date documentation and tests for the application. 18 | 19 | Security champions should spend at least one day a week on these activities. Although allocating this time is easy for management to accept in theory, it is much harder to put into practice. 20 | 21 | In the beginning, security champions will barely be able to spend a couple of hours a week at this work. 22 | 23 | One of the things you should know from a central point of view is who is doing this kind of work, and who can spend the time doing it. 24 | 25 | Fortunately, these things can be measured and tracked from the point of view of all the teams (using dashboards and graphs from the JIRA Risk Project). 26 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Making-Security-Champions-AppSec-Specialists.md: -------------------------------------------------------------------------------- 1 | ### Making Security Champions AppSec Specialists 2 | 3 | * once you have SCs you need to grown them 4 | * training is very important 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Public-references-to-Security-Champions-teams/images/mozilla-security-champions-page.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/2.Risk-workflow/Security-champions/Public-references-to-Security-Champions-teams/images/mozilla-security-champions-page.png -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Public-references-to-Security-Champions-teams/images/owaspSAMM-team-champions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/2.Risk-workflow/Security-champions/Public-references-to-Security-Champions-teams/images/owaspSAMM-team-champions.png -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Regular-hackathons.md: -------------------------------------------------------------------------------- 1 | ### Regular Hackathons 2 | 3 | Regular hackathons have many benefits for security champions, teams and companies. 4 | 5 | Security Champions should organize the hackathons, as hackathons are the next level of SCs applications. SCs can use them to find issues and learn new features. 6 | 7 | They should be held every Friday or Monday afternoon, preferably with some drinks and pizza. 8 | 9 | Ideally, a hackathon would happen every week, but if not it should be held every two, three, or four weeks. The important thing is to have movement. 10 | 11 | The hackathon model fits well into the 10% of time developers need for research. 12 | 13 | Inviting external experts, such as pentesters that regularly test the applications, has the benefit of providing new insights. Trying to do something, and then watching a more experienced and knowledgeable person do the same task, is one of the best ways to learn your job. You benefit from observing the workflow and strategies they employ to discover and exploit an issue. 14 | 15 | Organizing teams into red (attackers) and blue (defenders) can also be very effective. However, planning your hackathon around teams makes it harder to organize, and needs a lot more preparation. 16 | 17 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Rewarding-security-champions.md: -------------------------------------------------------------------------------- 1 | ### Rewarding Security Champions 2 | 3 | * budget to sponsor the best one in last month (or week, if there is a lot of activity) 4 | * Participation in conferences (ticket + travel expenses) 5 | * Books 6 | * Bonus (some companies prefer old fashioned cash prices) 7 | * How to measure who is the best of the month 8 | * Number of JIRA tickets: opened, fixed, tested 9 | * Number of Threat Models 10 | * Highest improvement 11 | * Innovative research 12 | * Shipped code (of an module used by multiple teams) 13 | * Above average documentation (Secure coding standards) 14 | * provide presentation opportunities (for example at the company wide Security Champions conference, or to senior directors (a couple levels above the current developer's position in the org chart)) 15 | * basically anything that you can do to a developer that he/she can put on the CV is a good reward 16 | * It is very important to create explicit and open rules about these rewards, since the worse situation is when a particular Security Champions receives an award not because of his achievements but due to other (political or friendship based) decision. 17 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Security-champions-activities.md: -------------------------------------------------------------------------------- 1 | ### Security Champions activities 2 | 3 | What do Security Champions do in they allocated day-to-day time (4h to 8th) 4 | 5 | * it is very important that JIRA tickets are use to map, track and allocate these tasks 6 | * the number of these tickets is what justifies the work the SC does 7 | * it also provides movement and management information about what is being done 8 | * it is important to have a good number of actionable (in the 'Allocated for Fix') stage (30 to 50 are a good number, as long as they are realistic and real) 9 | * you know the model is working when the managers start asking: "Do you have enough time of those SC activities?", "Do you need help from other team members (i.e. more resources)" 10 | * eventually the SC should also be managing the AppSec tasks that are performed by other team members 11 | * the time allocation is better if done in blocks of 4h (over two days), or 2h every day (at the same time) 12 | 13 | #### Other AppSec projects to be involved in 14 | 15 | * Map Attack Surface tool 16 | * Web Services Visualisation tool 17 | * Standard Schemas across the company 18 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Security-champions-dont-take-it-personally.md: -------------------------------------------------------------------------------- 1 | ### Security Champions Don't Take it Personally 2 | 3 | If you are a Security Champion, don't take it personally if teams aren't listening to you. Don't think that you are the problem, that you aren't good enough or that you are failing to communicate in some way. 4 | 5 | In most cases, the problem isn't you. The problem is actually the system; the company isn't structured in a way that allows the security champion's questions to be prioritised and answered. In other cases the Security Champion is not included in security-relevant architectural meetings and decisions. 6 | 7 | So, if you find that you are struggling to get traction from a team, the team isn't responding, or it fights you, then drop those requests (as long as the Risk as been accepted). If they treat you as a TAX, as somebody who is giving them work they don't want to do, then also drop it. 8 | 9 | In the Risk ticket, explain that you tried to persuade the team to accept the risks of not doing security, and that they are now responsible for their security, because you cannot help them. 10 | 11 | In such cases, the problem lies not with the Security Champion, but with the company and the organisation, maybe even sometimes with the team itself. This is why it is important to have success stories you can point to and say, _"Hey! It worked with that team, and it worked with that team. If it doesn't work with this team, then I am not the problem"_. 12 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Security-champions-involved-in-decisions.md: -------------------------------------------------------------------------------- 1 | ### Involve Security Champions in Decision-making 2 | 3 | Once a program starts being placed, security champions will often give feedback that they are not involved in the workflows and decisions. The job of the security champion is to ask, "What is this? Do I trust this? What happens with this?", but they often don't get the opportunity to ask these questions, because decisions are made without their input. 4 | 5 | To illustrate this problem, a situation occurred recently where the security champion started to create threat models across a product, and thereby managed to retroactively involve himself in some of the decision-making. 6 | 7 | He created a threat model with a lot of the developers and the other systems owners, and they found a couple of end points that were problematic. Once the teams were aware of the problems, realizing that data wasn't trustworthy, and identifying vulnerabilities, then the developers themselves started to question the methods. 8 | 9 | They found a nasty, exposed method that nobody knew about. It was a powerful and toxic method, that allowed a lot of data to be erased with very little accountability. 10 | 11 | That method should never have got there; it wasn't even validated, and there were other components missing. 12 | 13 | This is exactly the kind of exercise you want security champions to be involved in, because you want them to question those things before they hit development, before they go live. You want to catch those problems as early as possible. 14 | 15 | This is not to say "No" to functionality. It is rather to say, "If you want to do this, here are the side effects, here are the compromises, and here is how we should protect it". At the very least you should say, "If you do this, you do it without due regard being given to the security implications. You must accept the fact that this feature has no security thinking behind it". 16 | 17 | It is very hard for a project owner to accept that the feature being pushed has not benefitted from the consideration of security implications and side effects. This leaves him accountable for how it works, and this makes project owners uncomfortable. 18 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Security-champions.md: -------------------------------------------------------------------------------- 1 | ## Security Champions 2 | 3 | * [The Security Champions concept](The-security-champions-concept.md) 4 | * [What is an Security Champion and what do they do?](What-is-an-security-champion.md) 5 | * [Becoming A Security Champion](Becoming-a-security-champion.md) 6 | * [Do you have an heartbeat, you qualify!](Do-you-have-an-heartbeat-you-qualify.md) 7 | * [If you don't have an Security Champion, get a mug](If-you-dont-have-an-sc-get-a-mug/If-you-dont-have-an-sc-get-a-mug.md) 8 | * [Make sure your Security Champions are given time](Make-sure-your-Security-Champions-are-given-time.md) 9 | * [Making Security Champions AppSec Specialists](Making-Security-Champions-AppSec-Specialists.md) 10 | * [Involvement in senior technical discussions](Involvement-in-senior-technical-discussions.md) 11 | * [Security Champions Don't Take it Personally](Security-champions-dont-take-it-personally.md) 12 | * [Supported by central AppSec](Security-champions.md) 13 | * [Public references to Security Champions teams](Public-references-to-Security-Champions-teams/Public-references-to-Security-Champions-teams.md) 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Supported-by-central-appsec.md: -------------------------------------------------------------------------------- 1 | ### Supported by central AppSec 2 | 3 | They need to be supported by a central AppSec team, but it is key that each team has one. If there are not enough champions they can create a guild or chapter and rotate over teams. It is also important that they are backed in their decisions by corporate security like e.g. the CISO. 4 | 5 | Tasks (expand) 6 | * Code Reviews and Pen-tests (internally or via external managed services) 7 | * AppSec Automation (SAST and other tools) 8 | * Secure coding standards 9 | * Incident Response 10 | * Recruitment and Training 11 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/The-security-champions-concept.md: -------------------------------------------------------------------------------- 1 | ### The Security Champions Concept 2 | 3 | > _"If everyone is responsible for security, then nobody is"_ [^Patrick_Lencioni] 4 | 5 | * What are Security Champions? 6 | * Why Security Champions 7 | * challenges to scale and propagate AppSec Knowledge 8 | * Keep AppSec focus and energy 9 | * have somebody responsible for AppSec 10 | * What is the target audience of this section 11 | * _... you want to become an SC ..._ 12 | * _... you want to set you a SC network ..._ 13 | * There is an heavy AppSec focus, but this is applicable to all of IT, Dev and Risk management practices 14 | * explain how JIRA Risk Workflow is connected to the Security champions 15 | 16 | 17 | [^Patrick_Lencioni]: a variation of the quote: 18 | “If everything is important, then nothing is.” from Patrick Lencioni 19 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Threat-modeling-workshops.md: -------------------------------------------------------------------------------- 1 | ### Threat Modeling workshops 2 | 3 | * to happen every week 4 | * or every other week, alternating with a Security Champions meeting (this way there is always an SC activity happening every week at the same time and place) 5 | * good place to ask questions and to present Threat Models created during the previous week 6 | * If there are not a lot of materials to present or show, that indicates that the quantify of Threat models being created is quite low (note that the objective is to create Threat Models for new features, which are happening all the time) 7 | * another great learning resource, specially for new SCs (who are still getting their head around the workflow) 8 | * see Threat Models section for more details 9 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Training-security-champions.md: -------------------------------------------------------------------------------- 1 | ### Training Security Champions 2 | 3 | * Training is key to improve SC skills 4 | * Best training is done on top of languages and frameworks they use 5 | * Wiki pages with links to actual issues and relevant resources make a massive difference 6 | * Using vulnerable by design apps (or older versions of current main apps with known vulnerabilities) are a great way to learn (by exploiting them) 7 | * Writing exploits and finding vulnerabilities is a key step of the required accelerated learning curve 8 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/Weekly-meetings.md: -------------------------------------------------------------------------------- 1 | ### Weekly meetings 2 | 3 | * explain why these meetings are so important 4 | * what happens at one of these meetings 5 | * what is the normal agenda 6 | * who turns up 7 | * should happen every week, but a good compromise is for them to occur every other week 8 | * everything shown and discussed at the Security Champions meeting needs to be done via one or more slides (to be added to that week's slide deck) 9 | * these slides are VERY important when creating learning materials 10 | * create wiki pages with a full list of all past SC meetings (each entry is categorised by labels) 11 | * there are a great way to teach Security Champions and to call their attention to areas to research in their own apps 12 | * I've seen many cases where Security Champions will see a presentation on a topic/technology relevant to their current domain and think/say "Humm... I think we might be vulnerable to THAT vulnerability" 13 | 14 | Initially, it will take considerable effort to generate content for these meetings; to find presenters; and to keep it engaging / interesting. 15 | 16 | * think of the money that it costs the company to have all those resources in there. Make it count and don't waste participants time 17 | * the developers are very busy and if the meetings are not relevant or not interesting they will just don't turn up 18 | * central AppSec team (to help kickstarting the meetings) and to keep the energy level up) must always be looking for topics to present at the next SC meeting. For example: 19 | * Threat Models 20 | * AppSec Questions 21 | * AppSec ideas 22 | * events from a point of view on an attacker 23 | * attacks 24 | * AppSec news, 25 | * basically any AppSec related topic that has not been presented recently) 26 | 27 | #### Contents for weekly meetings 28 | 29 | Here are some examples of what to present at these meetings: 30 | 31 | * Latest news on AppSec (DDos, exploits, etc..) 32 | * Latest bug-bounty findings and payments (a really good source of real-world examples) 33 | * Issues found and issues fixed (on the SC's application or service) 34 | * Secure coding techniques 35 | * Security tools and technologies (e.g. OWASP ZAP Project, OWASP dependency checker) 36 | * Tools/techniques to improve the Developer's Productivity (e.g. WallabyJS, NCrunch) 37 | * Hack challenges 38 | * Security reviews current in place 39 | * Other OWASP tools and documents (ASVS, OwaspSAMM, AppSensor, Testing Guide) 40 | * Testing techniques, workflows and technologies used (which might be different from the current development stack) 41 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/What-is-a-security-champion.md: -------------------------------------------------------------------------------- 1 | ### What is a Security Champion and what do they do? 2 | 3 | Security Champions are a key element of an AppSec team, since they create an cross-functional team focused on Application Security 4 | 5 | **What is a Security Champion?** 6 | 7 | * Security Champions are active members of a team that may help to make decisions about when to engage the Security Team 8 | * Act as the "voice" of security for the given product or team 9 | * Aim to bridge the gap between security and dev teams 10 | * Assist in the triage of security bugs for their team or area 11 | 12 | **What do they do?** 13 | 14 | * Actively participate in the AppSec JIRA and WIKI 15 | * Collaborate with other security champions 16 | * Review impact of 'breaking changes' made in other projects 17 | * Attend weekly meetings 18 | * Are the single point of contact for their assigned team 19 | * Ensure that security is not a blocker on active development or reviews 20 | * Assist in making security decisions for their team 21 | * Low-Moderate security impact 22 | * Empowered to make decisions 23 | * Document decisions made in bugs or wiki 24 | * High-Critical security impact 25 | * Work with AppSec team on mitigations strategies 26 | * Help with QA and Testing 27 | * Write Tests (from Unit Tests to Integration tests) 28 | * Help with development of CI (Continuous Integration) environments 29 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Security-champions/What-it-takes-to-be-a-Security-Champion.md: -------------------------------------------------------------------------------- 1 | ### What it takes to be a Security Champion 2 | 3 | To become a security champion, it is essential that you want to be one. 4 | 5 | You need a mandate from the business that will give you at least half a day, if not one full day per week, to learn the role. The business should also provide the means to educate and train you and others who wish to become security champions. Increasing and spreading knowledge will increase awareness and control. 6 | 7 | You need to be a programmer, and understand code, because your job is to start looking at your application and understand its security properties. You should also know 'the tools of the trade', and how to implement them, in the most efficient way. Lastly, you must be able to identify useful metrics and instruct on how to obtain them. 8 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Capture-the-success-stories-of-your-threat-models.md: -------------------------------------------------------------------------------- 1 | ### Capture the success stories of your threat models 2 | 3 | One of the key elements of threat modeling is it's ability to highlight a variety of interesting issues and blind spots, in particular within the architecture of the threat model. One of my favorite moments occurs when the developers and the architects working on a threat model realize something that they hadn't noticed before. 4 | 5 | In such cases, sometimes it is the developer who says, "Oh, I never realized that is how it worked!". Other times when the architect says, "Well, this is how app was designed", and the developer responds "Yeah, but that didn't work, so we did it like this." 6 | 7 | What is actually happening when such exchanges take place is the mapping of reality, and the creation of a much better understanding of what that reality actually means within the company. Truth is being mapped, and the threat model becomes a single source of truth for the company. 8 | 9 | It is very important not only to capture these success stories, but also to advertise and promote them. Promoting them allows you to explain one of the reasons why you want to work in threat modeling; because you want to understand what is going on, and you want to make sure that everybody working on a threat model is on the same page in terms of development, QA, testing, and so on. 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Chained-threat-models.md: -------------------------------------------------------------------------------- 1 | ### Chained threat models 2 | 3 | When you create threat models per feature or per component, a key element is to start to chain them, i.e. create the connections between them. If you chain them in a sequence you will get a much better understanding of reality. You will be able to identify uber-vulnerabilities, or uber-threats, that are created by paths that exist from threat model, A to threat model B, to threat model C. 4 | 5 | For example, I have seen threat models where one will say, _"Oh, we get data from that over there. We trust their system, and they are supposed to have DOS protections, and they rate limit their requests"_. 6 | 7 | However, after doing a threat model of that system, we find that it does not have any DOS protections, even worse, it doesn't do any data validation/sanitisation. This means that the upstream service (which is 'trusted') is just glorified proxy, meaning that for all practices purposes, the 'internal' APIs and endpoints are directly connected to the upstream service callers (which is usually the internet, or other 'glorified proxies' services). 8 | 9 | This example illustrates how, when you start chaining threat models, you can identify data that shouldn't be trusted, or data that is controlled by the attacker. Usually the reverse also applies, where when you go downstream and check their threat models, you will find that they also trust your data and actions far too much. 10 | 11 | Of course, the opposite of this scenario could also be true. One of the threat models might say, _"...we have a huge number of issues at this layer"_. However, when you look at the layers above, you find they are doing a good job at validating, authorising and queuing the requests; they are all working to protect the more vulnerable layer, so the risk is low overall. 12 | 13 | When you chain a number of threat models, you track them, document them, and you greatly increase your understanding of the threats. You can use this new knowledge in the future to ensure that you don't expose that particular threat into new systems or new features. 14 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Developers-need-data-classification.md: -------------------------------------------------------------------------------- 1 | ### Developers need data classification 2 | 3 | Every type of data that exists in an organisation, especially the data that is consumed by applications, needs to have a Data Classification mapping. 4 | 5 | Developers need to know if a particular piece of data is sensitive, and what value it holds for the business. 6 | 7 | A good way to determine the expected level of confidentiality and integrity, is to ask what would happen _'If a particular set of data were to be fully disclosed?'_ (for example uploaded to PasteBin) or _'If some of the data was being maliciously modified over a period of months?'_. 8 | 9 | These are really hard questions, and only by answering them, the developers (and business owners) can start to understand the value of an particular data set (given-to or generated-by their application). 10 | 11 | Developers need to understand what they are dealing with, what is valuable to the business, and what needs to be protected. 12 | 13 | See [Microsoft's Data Classification Wizard](https://www.microsoft.com/security/data) for a good list of data types that exist on large organisations (this will need to be tweaked per application) 14 | 15 | > todo: add references to Threat Modeling 16 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Threat-Models-as-better-briefs.md: -------------------------------------------------------------------------------- 1 | ### Threat Models as better briefs 2 | 3 | * diagrams created (DfDs for example) will represent reality much better than existing documentation 4 | * It is key that Threat Models are used as 'sources of truth' (which are then maintained as code/architecture changes) 5 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Threat-model-case-studies.md: -------------------------------------------------------------------------------- 1 | ### Threat Model Case Studies 2 | 3 | * for each case study, add list of Risks that need to be added 4 | 5 | * Examples of Case Studies to add: 6 | * Source code, Keys and passwords stored in Developer's laptop 7 | * HTTP to HTTPS transition, lack of HSTS header, insecure cookies 8 | * Homeopathic Apigee127 web service 9 | * Smart-carts that control door access in buildings 10 | * Login brute of accounts 11 | * 4 version of HTML editing and Rendering 12 | * raw HTML 13 | * raw HTML with CSP 14 | * using Markdown 15 | * using Markdown with CSP 16 | * File upload solution vs GitHub fork 17 | * QA team with bad test environment 18 | * Insecure APIs with vulnerable by design methods 19 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Threat-model-confirms-pentest.md: -------------------------------------------------------------------------------- 1 | ### Threat Model Confirms Pentest 2 | 3 | A key objective of pentest should be to validate the threat model. Pentests should confirm whether the expectations and the logic defined in the threat model are true. Any variation identified is itself an important finding because it means there is a gap in the company's understanding of how the application behaves. 4 | 5 | There are three important steps to follow: 6 | 7 | 1. Take the threat models per feature, per layer and confirm that there is no blind spots or variations on the expectation 8 | 2. Check the code path to improve the understanding of the code path and what is happening in the threat model 9 | 3. Confirm that there are no extra behaviors 10 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Threat-model-per-feature.md: -------------------------------------------------------------------------------- 1 | ### Threat Model per Feature 2 | 3 | Creating and following a threat model for a feature is a great way to understand a threat model journey. 4 | 5 | First, take a very specific path, a very specific new feature that you are adding, or take a property, such as a new field, or a new functionality. 6 | 7 | Next, you want to create a full flow of that feature. Look at the entry point and the assets, and look at what is being used in that feature. 8 | 9 | Now, you can map the inputs of the feature; you can map the data paths given by the data schema, and then you follow the data. 10 | 11 | You can see for example how the data go into the application, what it ends up with, who calls who. This means you have a much tighter brief, and a much better view of the situation. 12 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Threat-models-mapped-to-Risks.md: -------------------------------------------------------------------------------- 1 | ### Threat Models mapped to Risks 2 | 3 | * every risk identified in the Threat Model needs to be opened and tracked in the JIRA Risk project 4 | * using Confluence to host the Threat Model content and have 'live' queries with the relevant risks (makes a massive difference in the maintainability of these Threat Models) 5 | * When special views are needed, Jira's JQL Queries can be used to create some of the queries 6 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/Threat-models.md: -------------------------------------------------------------------------------- 1 | ## Threat Models 2 | 3 | - generates risks 4 | - good way to create highly accurate technical documentation 5 | - source of truth 6 | - easier to get management to support 7 | -------------------------------------------------------------------------------- /content/2.Risk-workflow/Threat-Models/When-to-do-a-Threat-Model.md: -------------------------------------------------------------------------------- 1 | ### When to do a threat Model 2 | 3 | **normal development flow** 4 | 5 | ```viz 6 | digraph G { 7 | size= "3.0" 8 | node [shape=box] 9 | Idea -> "Project brief" 10 | -> "Scheduling" 11 | -> "Development" 12 | -> "QA" 13 | -> "Release" 14 | } 15 | ``` 16 | 17 | **Proposed development flow** 18 | 19 | ```viz 20 | digraph G { 21 | size= "4.5" 22 | node [shape=box] 23 | Idea -> "Project brief" 24 | -> "Scheduling" 25 | -> "Development" 26 | -> "QA" 27 | -> "Release" 28 | 29 | "Project brief" -> "Threat Model" 30 | 31 | "Threat Model" -> "Option A" -> "Risks" 32 | "Threat Model" -> "Option B" -> "Risks" 33 | "Threat Model" -> "Option C" -> "Risks" 34 | "Risks" -> "To be accepted" 35 | -> "Scheduling" 36 | "Risks" -> "To check implementation" 37 | -> "QA" 38 | 39 | "To check implementation" -> "Pen-test" 40 | -> "Release" 41 | 42 | } 43 | ``` 44 | -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/A.Creating-workflow-in-jira.md: -------------------------------------------------------------------------------- 1 | ## Appendix A: Creating Workflow in JIRA 2 | 3 | This section shows how to create the JIRA workflows without using any JIRA plugins 4 | 5 | Key concepts of this workflow 6 | 7 | - All tests should pass all the time 8 | - Tests that check/confirm vulnerabilities should also pass 9 | - The key to make this work is to:

 10 | - Make business owners understand the risks of their decisions (and click on the ‘accept risk' button) 11 | -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/381996b4-3dca-11e6-8ee7-c66e81868e8a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/381996b4-3dca-11e6-8ee7-c66e81868e8a.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/3f66f00c-3dc9-11e6-8020-adc9d1ff0dba.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/3f66f00c-3dc9-11e6-8020-adc9d1ff0dba.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/54a13770-3dc9-11e6-8204-8e589d858acc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/54a13770-3dc9-11e6-8204-8e589d858acc.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/5e38eff8-3dc9-11e6-9220-3939d86c936c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/5e38eff8-3dc9-11e6-9220-3939d86c936c.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/5e6864ac-3dcb-11e6-9f6d-c9dbb19295ee.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/5e6864ac-3dcb-11e6-9f6d-c9dbb19295ee.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/8a73cbea-3dcb-11e6-876f-b28e07bad7cb.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/8a73cbea-3dcb-11e6-876f-b28e07bad7cb.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/91abc63e-3dca-11e6-822e-6781143f7c51.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/91abc63e-3dca-11e6-822e-6781143f7c51.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/a6ba4366-3dca-11e6-814f-7f1d189701fa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/a6ba4366-3dca-11e6-814f-7f1d189701fa.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/ca80ff2e-3dca-11e6-9340-7dd576cfabb3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/images/ca80ff2e-3dca-11e6-9340-7dd576cfabb3.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.Creating-a-jira-project/x.Creating-a-Jira-project.md: -------------------------------------------------------------------------------- 1 | ### Creating-a-Jira-project 2 | 3 | For these examples we will use the version hosted JIRA cloud called (in Oct 2016) JIRA Software. 4 | 5 | Note that the same workflow can be created on the on-premise versions of JIRA (including the older versions) 6 | 7 | If you don't have a JIRA server you can use, then use can create on using the [Jira evaluation page]( https://www.atlassian.com/software/jira/try) and choosing the _JIRA Software_ option. I would also add in the _Documentation_ (aka Confluence) module since it is a very powerful wiki (which is called _Confluence_) 8 | 9 | {width=50%} 10 | ![](images/3f66f00c-3dc9-11e6-8020-adc9d1ff0dba.png) 11 | 12 | If you don't have an account you will need to create one. 13 | 14 | {width=50%} 15 | ![](images/54a13770-3dc9-11e6-8204-8e589d858acc.png) 16 | 17 | After clicking on _Start now_ your cloud instance of JIRA will be created (my bet is that this is a docker container with a dedicated data store for each customer/trial) 18 | 19 | {width=50%} 20 | ![](images/5e38eff8-3dc9-11e6-9220-3939d86c936c.png) 21 | 22 | 3) login 23 | 24 | {width=25%} 25 | ![](images/381996b4-3dca-11e6-8ee7-c66e81868e8a.png) 26 | 27 | 4) create new project 28 | 29 | {width=25%} 30 | ![](images/91abc63e-3dca-11e6-822e-6781143f7c51.png) 31 | 32 | 33 | 5) choose Kanban Software Development 34 | 35 | {width=50%} 36 | ![](images/a6ba4366-3dca-11e6-814f-7f1d189701fa.png) 37 | 38 | {width=50%} 39 | ![](images/ca80ff2e-3dca-11e6-9340-7dd576cfabb3.png) 40 | 41 | 6) Name it 'RISK - AppSec' with the key 'RISK', 42 | 43 | {width=50%} 44 | ![](images/8a73cbea-3dcb-11e6-876f-b28e07bad7cb.png) 45 | 46 | 7) Your new JIRA Project dashboard should open and look something like this 47 | 48 | {width=100%} 49 | ![](images/5e6864ac-3dcb-11e6-9f6d-c9dbb19295ee.png) 50 | -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/02d9969c-3dd5-11e6-8d03-c1bcc9f1aef2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/02d9969c-3dd5-11e6-8d03-c1bcc9f1aef2.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/07e7f288-3dcf-11e6-82b2-96487b78e130.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/07e7f288-3dcf-11e6-82b2-96487b78e130.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/0b94ab8c-3dd5-11e6-9255-edb93334f424.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/0b94ab8c-3dd5-11e6-9255-edb93334f424.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/10a5c61e-3dcc-11e6-88fc-d87a77f5ef0e.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/10a5c61e-3dcc-11e6-88fc-d87a77f5ef0e.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/189871ce-3dd5-11e6-8297-92e037054900.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/189871ce-3dd5-11e6-8297-92e037054900.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/1ae147f6-3dcd-11e6-9ff0-47cfdcf069ce.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/1ae147f6-3dcd-11e6-9ff0-47cfdcf069ce.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/2279cc92-3dd5-11e6-8ab3-9cd0a7092e2d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/2279cc92-3dd5-11e6-8ab3-9cd0a7092e2d.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/290ef1ee-3dd6-11e6-83c3-de50cf0045d0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/290ef1ee-3dd6-11e6-83c3-de50cf0045d0.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/3953bbc0-3dd6-11e6-8574-95bad360819c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/3953bbc0-3dd6-11e6-8574-95bad360819c.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/4d64417a-3dd6-11e6-91ab-0fb4f102f771.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/4d64417a-3dd6-11e6-91ab-0fb4f102f771.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/566f75e6-3dd6-11e6-8735-4c6fdd36fb01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/566f75e6-3dd6-11e6-8735-4c6fdd36fb01.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/5acfc2e2-3dce-11e6-88a5-f7dd104edea8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/5acfc2e2-3dce-11e6-88a5-f7dd104edea8.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/6377d62a-3dcc-11e6-99e5-5483017ee580.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/6377d62a-3dcc-11e6-99e5-5483017ee580.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/6677a814-3dd6-11e6-86d8-8b4a37e3f4aa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/6677a814-3dd6-11e6-86d8-8b4a37e3f4aa.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/6a8619b0-3dcf-11e6-8e04-22a36ceea5b9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/6a8619b0-3dcf-11e6-8e04-22a36ceea5b9.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/7816a2ae-3dcd-11e6-9a29-3b6b0f7e5c0a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/7816a2ae-3dcd-11e6-9a29-3b6b0f7e5c0a.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/8b7a21e0-3dcd-11e6-8dfe-d2dc54af6441.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/8b7a21e0-3dcd-11e6-8dfe-d2dc54af6441.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/8d566ed2-3dce-11e6-80d1-f7526e43dd67.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/8d566ed2-3dce-11e6-80d1-f7526e43dd67.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/8f986b30-3dd5-11e6-8101-58807a9cc582.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/8f986b30-3dd5-11e6-8101-58807a9cc582.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/93fc50bc-3dd3-11e6-8646-ae20cc8262b3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/93fc50bc-3dd3-11e6-8646-ae20cc8262b3.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/9cfe0c30-3dd0-11e6-9b93-8df66d82e0c9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/9cfe0c30-3dd0-11e6-9b93-8df66d82e0c9.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/a06fa9bc-3dcd-11e6-82e9-a42cb425f162.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/a06fa9bc-3dcd-11e6-82e9-a42cb425f162.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/a1feba3e-3dd2-11e6-8a5b-28a8224b4d7d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/a1feba3e-3dd2-11e6-8a5b-28a8224b4d7d.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/a87773a2-3dcc-11e6-9c7d-1688d84b3ecf.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/a87773a2-3dcc-11e6-9c7d-1688d84b3ecf.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/ac037160-3dd6-11e6-8283-72bcf317c62d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/ac037160-3dd6-11e6-8283-72bcf317c62d.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b25a55e2-3dd6-11e6-94a5-06ea7a132635.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b25a55e2-3dd6-11e6-94a5-06ea7a132635.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b447ada8-3dce-11e6-887e-0ebb216149ce.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b447ada8-3dce-11e6-887e-0ebb216149ce.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b55a56ee-3dcb-11e6-941d-c6f6b6ab9dc9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b55a56ee-3dcb-11e6-941d-c6f6b6ab9dc9.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b6b3138c-3dd5-11e6-85a5-e5d4d3822d22.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/b6b3138c-3dd5-11e6-85a5-e5d4d3822d22.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/bca1c3b4-3dd6-11e6-8670-48607c345c38.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/bca1c3b4-3dd6-11e6-8670-48607c345c38.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/be8a59e8-3dd1-11e6-8075-46ce6c5e252c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/be8a59e8-3dd1-11e6-8075-46ce6c5e252c.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/c2fc5198-3dd6-11e6-9b5a-03da9bfe529a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/c2fc5198-3dd6-11e6-9b5a-03da9bfe529a.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/cc65c53c-3dce-11e6-8b8e-8573d0746824.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/cc65c53c-3dce-11e6-8b8e-8573d0746824.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/cc8ef602-3dd1-11e6-8b15-ec88e5a83c5c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/cc8ef602-3dd1-11e6-8b15-ec88e5a83c5c.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d1a36520-3dd5-11e6-8630-a0cfa9ed1c9e.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d1a36520-3dd5-11e6-8630-a0cfa9ed1c9e.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d5031a2a-3dd1-11e6-9188-aec6a472968d.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d5031a2a-3dd1-11e6-9188-aec6a472968d.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d7602a48-3dd0-11e6-990b-890168824ebd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d7602a48-3dd0-11e6-990b-890168824ebd.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d8408fd0-3dd4-11e6-9f1f-d57ce4a11ed8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/d8408fd0-3dd4-11e6-9f1f-d57ce4a11ed8.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/dd575028-3dcd-11e6-8b0a-c83b8966d5ea.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/dd575028-3dcd-11e6-8b0a-c83b8966d5ea.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e0dc43aa-3dd4-11e6-841e-61e8e9b0d485.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e0dc43aa-3dd4-11e6-841e-61e8e9b0d485.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e232415e-3dd5-11e6-93f0-8ab67da3de18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e232415e-3dd5-11e6-93f0-8ab67da3de18.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e522266c-3dcc-11e6-9aca-0f74d539b78c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e522266c-3dcc-11e6-9aca-0f74d539b78c.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e6d89302-3dd5-11e6-9f97-56850cb52c99.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/e6d89302-3dd5-11e6-9f97-56850cb52c99.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/ecf41f8a-3dcc-11e6-8531-93c371463acd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/ecf41f8a-3dcc-11e6-8531-93c371463acd.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/f35b0678-3dcb-11e6-92c5-9e7d1cf78d16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/f35b0678-3dcb-11e6-92c5-9e7d1cf78d16.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/f3c14f5a-3dd5-11e6-8568-0ec71265df26.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/f3c14f5a-3dd5-11e6-8568-0ec71265df26.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/fb52ee16-3dcd-11e6-850c-7dbe99753a4c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/fb52ee16-3dcd-11e6-850c-7dbe99753a4c.png -------------------------------------------------------------------------------- /content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/fdf2155e-3dd5-11e6-91bc-b9643324e9bd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/A.Creating-workflow-in-jira/x.step-by-step/images/fdf2155e-3dd5-11e6-91bc-b9643324e9bd.png -------------------------------------------------------------------------------- /content/Appendix/Appendix.md: -------------------------------------------------------------------------------- 1 | # Appendix 2 | 3 | - Appendix A: Creating Workflow in JIRA 4 | - Appendix B: GitHub book workflow 5 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/Atom-Markdown-graphwiz-dot/Atom-Markdown-graphwiz-dot.md: -------------------------------------------------------------------------------- 1 | ### Atom, Markdown, Graphiz, DOT 2 | 3 | Editing and diagram creation was done on [Atom editor](https://atom.io/) with the [markdown-preview-enhanced](https://atom.io/packages/markdown-preview-enhanced) plugin 4 | 5 | Text was written in [markdown](https://leanpub.com/help/manual) 6 | 7 | Diagrams where created using [DOT Language](http://www.graphviz.org/doc/info/lang.html) , rendered by [GraphWiz](http://www.graphviz.org/) and [Viz.js](https://github.com/mdaines/viz.js) 8 | 9 | This is what the IDE looks like: 10 | 11 | ![](images/Atom-editor-ui.png) 12 | 13 | **References:** 14 | 15 | * GraphWiz and Dot: 16 | * [Polygon-based Nodes](http://www.graphviz.org/doc/info/shapes.html) 17 | * [Node, Edge and Graph Attributes](http://www.graphviz.org/doc/info/attrs.html) 18 | * [Viz.js online demo](http://mdaines.github.io/viz.js/) 19 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/Atom-Markdown-graphwiz-dot/images/Atom-editor-ui.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/B.GitHub-book-workflow/Atom-Markdown-graphwiz-dot/images/Atom-editor-ui.png -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/B.GitHub-book-workflow.md: -------------------------------------------------------------------------------- 1 | ## Appendix B: GitHub book workflow 2 | 3 | - explain the workflow used to create this book 4 | - audio transcripts and copy editing (and upwork) 5 | - Pull requests for copy editing 6 | - Labels for managing tasks and issues 7 | 8 | - show how to report a problem with the book or suggest ideas 9 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/Book-creation-workflow.md: -------------------------------------------------------------------------------- 1 | ### Book creation workflow 2 | 3 | - what are all the actions that occur, from making a code change to having a preview done 4 | - explain two modes (Github online editing and offline editing using Atom editor) 5 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/GitHub-leanpub-hook.md: -------------------------------------------------------------------------------- 1 | ### GitHub Leanpub hook 2 | 3 | - how it works 4 | - what it does 5 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/GitHub-online-editing.md: -------------------------------------------------------------------------------- 1 | ### GitHub online editing 2 | 3 | - explain how it works and the workflow used 4 | - mention leanpub service hook and how every content change will eventually result in a new preview 5 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/GitHub-repos-used.md: -------------------------------------------------------------------------------- 1 | ### GitHub repos used 2 | 3 | - https://github.com/DinisCruz/Book_Jira_Risk_Workflow 4 | - hold content and raw files 5 | - better searching since the manuscript files are not there 6 | - used to create the stand-alone version of the book 7 | - https://github.com/DinisCruz/Book_Jira_Risk_Workflow_Build 8 | - holds files in Leanpub friendly format 9 | - hooks into leanpub via GitHub service 10 | - every commit to this repo will trigger a build 11 | -------------------------------------------------------------------------------- /content/Appendix/B.GitHub-book-workflow/Tool-leanpub-book-site.md: -------------------------------------------------------------------------------- 1 | ### Tool leanpub-book-site 2 | 3 | - explain what it is and how it works 4 | - rules of engagement 5 | - folders and file structure 6 | - auto-generation of book.txt file 7 | - consolidation of images 8 | 9 | - reason for doing it was : 10 | 1) solve problem of massive image folder (now each chapter is directly mapped to it's images, which is ok as long as the image's name are not repeated) 11 | 2) solve problem of having to maintain the Book.txt file 12 | 3) allow splitting of manuscript folder into separate repo 13 | -------------------------------------------------------------------------------- /content/Appendix/C.Security-tests-examples/C.Security-tests-examples.md: -------------------------------------------------------------------------------- 1 | ## Appendix C: Security Tests Examples 2 | 3 | * add multiple examples of security tests 4 | * in node/coffee script 5 | * HSTS header check 6 | * detecting attack surface changes 7 | * performance tests 8 | * in Javascript 9 | * emberjs safehtml issue 10 | * in java 11 | * random() lack of randomness 12 | * detecting methods calls 13 | * in .net 14 | * email regex issue 15 | * using reflection to check api usage 16 | * testing XSS on HTML Elements 17 | * android 18 | * query SQL Injection 19 | -------------------------------------------------------------------------------- /content/Appendix/D.Case-studies/D.Case-studies.md: -------------------------------------------------------------------------------- 1 | ## Appendix D: Case Studies 2 | -------------------------------------------------------------------------------- /content/Appendix/D.Case-studies/File-upload.md: -------------------------------------------------------------------------------- 1 | ### File Upload 2 | 3 | - public competition where external users where supposed to upload their work (this was aimed at University grads) 4 | - lots of moving parts in original design 5 | - better solution was to use GitHub for file submissions 6 | - massive difference in the risk and complexity of each solution 7 | -------------------------------------------------------------------------------- /content/Appendix/D.Case-studies/Html-editing.md: -------------------------------------------------------------------------------- 1 | ### HTML editing 2 | 3 | - common request/feature in web-apps 4 | - massive attack surface and security issues (equivalent to XSS) i 5 | - prevents clients to protecting themselves (unless they can use CSP) 6 | - good example of not answering the real business need 7 | - which tends to be _'edit text, with images, some formatting (bold, italics), links and tables'_ 8 | - all these can be meet if using Markdown (which can be even better for the user, due to its easy of use, ease of diff and readability) 9 | - lots of un-intended side-effects, for example with copy-and-paste 10 | - trying to create 'safe html' is very dangerous due to the crazy stuff that HTML allows and the 'cleverness of some browsers' (which are able to fix broken HTML and Javascript) 11 | -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/E.Github-issue-workflow.md: -------------------------------------------------------------------------------- 1 | ## Appendix E: GitHub Issue worklfow 2 | -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Github-labels/Github-labels.md: -------------------------------------------------------------------------------- 1 | ### GitHub Labels 2 | 3 | * Below are some examples of the use Labels 4 | 5 | **Labels on book generation** 6 | 7 | ![](images/labels-on-book-generation.png) 8 | 9 | **Labels on complex software development** 10 | 11 | ![](images/labels-on-complex-software-dev-1.png) 12 | 13 | ![](images/labels-on-complex-software-dev-2.png) 14 | -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Github-labels/images/labels-on-book-generation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/E.Github-issue-workflow/Github-labels/images/labels-on-book-generation.png -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Github-labels/images/labels-on-complex-software-dev-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/E.Github-issue-workflow/Github-labels/images/labels-on-complex-software-dev-1.png -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Github-labels/images/labels-on-complex-software-dev-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/E.Github-issue-workflow/Github-labels/images/labels-on-complex-software-dev-2.png -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Reporting-issues/Reporting-issues.md: -------------------------------------------------------------------------------- 1 | ### Reporting issues 2 | 3 | * GitHub can also be used to create similar risk (and other) workflows 4 | 5 | * [Leanpub Issues](https://github.com/DinisCruz/leanpub-issues/issues) 6 | * [Veracode Issues]( https://github.com/DinisCruz/veracode-api/issues) 7 | 8 | 9 | ![](images/reporting-leanpub-issues.png) 10 | -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Reporting-issues/images/labels-on-issue-reporting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/E.Github-issue-workflow/Reporting-issues/images/labels-on-issue-reporting.png -------------------------------------------------------------------------------- /content/Appendix/E.Github-issue-workflow/Reporting-issues/images/reporting-leanpub-issues.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/Appendix/E.Github-issue-workflow/Reporting-issues/images/reporting-leanpub-issues.png -------------------------------------------------------------------------------- /content/Draft-Notes/Draft-notes.md: -------------------------------------------------------------------------------- 1 | ## Draft Notes 2 | 3 | These are a mix bag of notes made on real notebooks which need to be normalized, converted into paragraphs and placed in the right location 4 | 5 | There might be some repeated content which has already been covered in the book 6 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/AppSec-Tools.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - AppSec Tools 2 | 3 | * The false positive and false negative problem in tools and in code review 4 | * when doing code reviews, for me the issue (and vulnerability) starts in a line of code or in a method (even if it not being used at the moment, or exposed to an malicious source) 5 | * desired SAST workflow 6 | * scan every app and component in the company 7 | * for each app scan all their versions 8 | * find versions with vulnerabilities (which should be banned from being used) 9 | * mode where they sell concurrent scans (change more for speed, performance) not number of apps 10 | * apps get created and deleted with every scan 11 | * results are stored in git 12 | * for some apps it might make sense to have apps live longer (specially if the ui helps with remediation) 13 | * allow custom rules 14 | * expose internal objects and graphs 15 | 16 | * personalize and timing of the delivery of SAST (or other) tools knowledge (i.e. findings) 17 | * this can be as important as the content since the recipient must be in a position to consume/understand that guidance 18 | * this will need to customized to the developer's skills, appsec experience, status of mind and stage of SDL (planing, architecture, development, testing, qa, bug fixing) 19 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/Code-Quality.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - Code Quality 2 | 3 | * Bad code and lack of testing has to be measured, since it has to have side effects. 4 | * If code has not tests but always works, all releases are smooth and there are no major incidents, then it is OK not to have tests, 5 | * ... now back in the real world ... lack of tests and weak CI will always have side effects: 6 | * problematic releases 7 | * customers finding bugs 8 | * long time to create features requested by business 9 | * quality issues on deliverables 10 | * weak and ever-changing briefs 11 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/DevOps.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - DevOps 2 | 3 | 4 | 5 | 6 | **Stages of AppSec automation** 7 | 8 | Start with static analysis which don't need a live environment to deploy the application 9 | 10 | 1. Have a CI that builds code automatically for every commit of every branch 11 | 2. Ran 'a' tool after build (doesn't really matter which one what matters is that it uses the materials created on step 1) 12 | * use for example FindBugs with FindSecBugs [^FindSecBugs] 13 | 3. Find tune scan targets (i.e. exactly what needs to be scanned) 14 | 4. Filter results, customize rules to reduce noise 15 | 5. Gather reports and scans and put them on git repo 16 | 6. create a consolidated dashboard (for management and business owners) 17 | 7. add more tools 18 | 8. loop from 5 19 | 20 | after this is mature, add a step to deploy the app to a live environment (or simulator) 21 | 22 | [^FindSecBugs]: FindSecBugs (https://github.com/find-sec-bugs/find-sec-bugs) has better security rules than FindBugs and is under current active development/maintenance 23 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/Developers.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - Developers 2 | 3 | * developers can be disconnected from their future-self 4 | * why are they accept and make decisions that will hurt them in the future 5 | * idea of showing the real cost of technological & coding decisions 6 | * Positive & Negative impact 7 | * one-off vs recurring cost/benefit analysis 8 | * we need developers to act more inline with their (and the apps) long-term interests 9 | * usually business owners are not made accountable for their technological decisions (they get the bonus for 'delivering' and move on to another project or company ) 10 | * developers need to start picking fights on what is better for the business in the long run. 11 | * when they overruled, that needs to be 'on the record', which is better done with the JIRA Risk Workflow 12 | * best strategy to do this is to align yourself with the values and direction of the organization or company you are working for 13 | 14 | 15 | * We should be able to predict when a developers is about to create a security vulnerability 16 | * based on similar patterns/code-graphs of other developers/code-changes in the past 17 | * Google and StackOverflow queries 18 | * detect bad results (maybe with even security vulnerabilities) and provide better recommendations 19 | * detect what questions they will ask next and suggest better results (proactive code-complete like, AI technology will help) 20 | * Detect when code is one degree away from and exploit/vulnerability 21 | * Defense concept: always be or three degrees of separation from an serious vulnerably/exploits 22 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/Government.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - Government 2 | 3 | * In the 'open letter to president' (find link) there is no mention of secure coding or secure apps 4 | * but all our technology runs on code and until we control it, we will not really be solving the root causes 5 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/PoCs.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - PoCs 2 | 3 | * related to 'why exploits are important' 4 | * example for demos to perform 'management and C-level execs' 5 | * When XSS/JS-injection is possible 6 | * Replace website logo with their competitor's logo , or 7 | * Add the competitor logo after an '... a division of company Y...' tag (Y are their competitor) 8 | * capture session tokens via insecure cookies and use session tokens to perform visible action (change user details, make transactions, delete user assets) 9 | * logout the user (continuously) via CSRF, so that the legit user is not able to login 10 | * Clickjacking that performs action on target website 11 | * DoS/DDoS the site (for a little bit) using small amounts of traffic (discovered after profiling the app via integration tests, which identified a number of expensive calls) 12 | -------------------------------------------------------------------------------- /content/Draft-Notes/To-fix/Threat-Models.md: -------------------------------------------------------------------------------- 1 | ### Draft notes - Threat Models 2 | 3 | * Do Threat Models in layers 4 | * identify each STRIDE issue per layer 5 | * each layer it built on top of the previous one 6 | * connect the threats 7 | * map the Urls and Data objects and connect them across layers 8 | * created 'refactored' and 'collapsed' views of the diagrams (specially when there are 'web services that act like proxies' in the middle) 9 | 10 | * Introduce the concept of Sinks in Threat Modeling 11 | * how to connect the multiple threats (one for each layer) so that they are chained 12 | * map this concept with the concept of Attack Trees 13 | 14 | * Idea to create a Book focused on "Threat Modeling examples and patterns" 15 | -------------------------------------------------------------------------------- /content/From-audio/From-audio.md: -------------------------------------------------------------------------------- 1 | ## Audio Transcriptions 2 | 3 | These files are a first pass at a particular topic, done as audio files, recorded on my mobile, and transcribed verbatim. 4 | -------------------------------------------------------------------------------- /content/From-audio/Misc-Concepts/Why OWASP Needs Summits.md: -------------------------------------------------------------------------------- 1 | We need these summits because we need as a community and industry a place where we can come together and work on ideas and on solutions. 2 | 3 | We need places where we can have independent non-vendor focus discussions about hard problems that we have. 4 | 5 | OWASP is one of the few organizations in the world that is able to achieve that. 6 | 7 | The problem we have with conferences is that they are very uni-directional, they are people presenting their research and in fact there is some interesting comment about the current lack of innovation on conferences where we basically keep going around and around with the same kind of topics and ideas. 8 | 9 | So, the best part of conferences is the lobby part, is the people that we meet and we talk there. 10 | 11 | The problem is that those conversations are very ad hoc, they aren't planned, there is no work before, there is no preparation for those conversations. 12 | 13 | The summit allows you to have that, the summit allows you in a way to be prepared for those exchanges where you know you are going to meet people that are interested about this topic, where you know there is going to be a critical mass of knowledge about a specific topic that we/you want to talk about. 14 | 15 | And that is the power of the summit, is the fact that the people that matter and care about a particular topic are there. More importantly they are there to work, they are there focused in workment and that is what makes the summits so special is these places where we can come and create amazing and important deliverables. 16 | 17 | What are those deliverables? I don't know, it depends on the participants, it depends on the people, in a way it depends on who is going to go there and how much they believed on it, and how much effort they put into it. 18 | 19 | All that we can do for an OWASP and as a community is to set the stage, it is up to the participants to actually create magic and to create something quite amazing. 20 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Create-risks-for-code-hacks.md: -------------------------------------------------------------------------------- 1 | Some say that you know the vulnerability where user and account ID was received from the outer world that was basically passed into the back end and user and he was able to just use easy to be data. 2 | 3 | The root cause of those problems tend to be the fact that the controller is actually able to access and make those calls. So you need to open a risk for that. Then you also need to open another risk for the fact that your need to create an account ID from the front end from user data. 4 | 5 | So there is already implication of that dangerous operation. And the third one is that actually step of actually using that you know the one that creates a vulnerability, passing the risk directly to the back end with the violation. 6 | 7 | Now when you fix this a lot of times to fix is done at the control level so you add the method there to say, "hey this user has access to this, this user has access to this account". 8 | 9 | The problem that is the wrong fix, it is a hack so you need to create a risk to that. Because the real fix should be done at the back end servers the real fix should be you should pass for example the user token or the back end and then use that to make a decision whether the user can access that information or not. 10 | 11 | So that is a good example situation though the fix was formed, you actually the hack and also need to review other cases where that occurred. So you need to create a new ticket to be accepted to saying hey although we solved the problem it is actually not, we didn't fix the root cause of the problem and then add that as code references. 12 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Developers Need To Document Quality Of Their Code.md: -------------------------------------------------------------------------------- 1 | Very often developers will slag off and complain about their code and be really offensive about its quality and the fact that sometimes they don't get enough time or much of that to understand the quality of those problems. 2 | 3 | This is very natural because they are the ones who pay the technical debt for it and they suffer with lack of understanding. 4 | 5 | The problem is that you need evidence, you need to have hundreds and hundreds of tickets either on a risk register because ultimately those things have security implications or on their own way where that is proven. 6 | 7 | Because it is only by looking at the type of tickets and what is in there that you get a sense for the problem. So if those tickets are for very small little things then clear that is okay. 8 | 9 | But if those things are major problems, I don't understand this method, or the application has this side effects, or the application crashed you don't know why or tests are really hard to maintain or I spent five hours fixing a test when I make a code change or I spent hours and hours understanding the root cause of the application and new developers join in and they aren't able to write production code within weeks or months. 10 | 11 | Those are problems and that needs to be acknowledged and methods that are very large you know all sorts of problems, all of these needs to be acknowledged. And it is only then that you could say something about the quality of the code. 12 | 13 | Now the good news of this is that the developers can do this, in fact the security guys can help the developers do this. Because all you are doing is describing reality, especially when you inherit a new system, you know if people don't understand the side effects of it, document a way, capture everything because there is nothing stopping you from doing that. 14 | 15 | And more importantly, those 200, 300 issues are basically the road map for fixing it. So when you say I want to fix X, you need to basically provide that list of things to do that is what your road map is. And the more you do it, the more things you create eventually you will just state flags and then you start to fix a lot of issues. 16 | 17 | And then the amount of time that it takes you to fix those issues is a good metric. 18 | 19 | So that is why sometimes the smaller the ticket, the smaller the change the better. Because ultimately a big change is made of small little changes. 20 | 21 | So it is better to push lots and lots of small little changes than bigger changes. And that means that every change you have to do has to be documented in the ticket, and those tickets have to exist before you do the work. 22 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/How To Deal With Problematic Teams.md: -------------------------------------------------------------------------------- 1 | How to deal with teams that say they are already secure and don't have time for security. 2 | 3 | So, every now and then you will find a team that has a lot of power to live with the level of applications. 4 | 5 | And it is able to push back even at the very senior levels of the company to say we don't need these security stuff, we don't need these threat models, we don't need all these security tasks, all these activities that you guys are asking us to do. 6 | 7 | Assuming that the security isn't really in attack space reading dragged by a team that is actually trying to do the right thing and is trying to push good practices and is actually trying to add value then the way to deal with these guys is to basically call their bluff. 8 | 9 | The way to deal with that is to basically play them at their own game and to basically say well if you don't do that it means that you are better reproducing really high secure code, you better have no security vulnerabilities, you better have no security exploits, you better fully understand your attack surface, you better have no side effects, very clean deployments all that jazz because those are all side effects of bad security practices. 10 | 11 | So, basically what we then need to do is to document them, make them accept all those parts of risks, and then wait for Murphy's Law to come along and to do that. 12 | 13 | The other thing that is very important is that you also need to challenge the assumptions. So for example if they have pen tests, make sure they understand pen tests aren't worth unless they are full white box. 14 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/How To Make Business Owners Accountable.md: -------------------------------------------------------------------------------- 1 | The solution is to make them click on that accept to be supported. What is important to understand is that that isn't the moment that they will accept the risk that is the moment where they will actually read it. 2 | 3 | So that is very interesting long term gain that you play where it is all about changing the culture, it is all about finding ways to create a positive work flow. 4 | 5 | So, sometimes you have to be aggressive, sometimes you have to be harsh and make teams accountable, because remember this game has already been played the question is whether you control instruments over the rules of the game or not. 6 | 7 | And the thing to understand is that most people will only actually read it, and only actually pay attention the moment they have to be accountable. 8 | 9 | So take that into account, don't be frustrated when you have had [inaudible 00:01:13] about a topic and then only at that moment they actually realize what you are saying, realize that everybody is very busy, everybody has parts of stuff to do so actually the fact they aren't paying attention isn't really bad than what you were before. 10 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Insurance-premiums-for-software-risks-must-be-public.md: -------------------------------------------------------------------------------- 1 | As the insurance industry matures, and there are more and more companies that will choose to insure their risks instead of actually writing secure code and fix the applications is key that those values and those insurance premiums are made public. Because, those contracts will be a great measurement of how secure a company is. 2 | 3 | The problem is we need ways to measure company's security. We need ways to measure what they are doing so that we reward the client, so that the entity making a purchasing decision can choose A, B, and C. 4 | 5 | So, we can't have a situation where the only measuring sticks are features, reputation, cost and maybe some performance. We need security to be in there, we need companies to have in a way to pay a cost for not doing security. 6 | 7 | Now, if the customer chooses to go with a particular vendor that clearly doesn't have application security practices, clear is not doing the right thing that is fine that is okay that is market economics at work. 8 | 9 | But my experience is that won't happen, my experience is these days more and more the clients are getting way more savvy. And if they can make sure the multiple products that they are consuming, then they will put pressure and in a way they will vote with their decisions which is really what you want to see happening. 10 | 11 | And a great way this will occur is as the insurance company gets along which will push a much better validation of the issues which will bring a huge amount of rationality and data points and data analysis into what is at risk, how you can measure, how you name it, how you define it, we need to make sure that those mappings and that information is all public. 12 | 13 | And this is something that can easily not happen, but I feel that because the industry is still immature and is so young, we can actually point it in the right direction from now on. 14 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote "Code Made in Portugal" Brand.md: -------------------------------------------------------------------------------- 1 | So I think "Code Made in Portugal" is very important, we need to create all this supply chains that exist in Portugal because that is where you add value and they create reality so basically they control our lives. 2 | 3 | So it is key for our economy and it is key to actually encourage what is going on here. 4 | 5 | And we are living on this age of sustainability, I don't know how much you guys have been following this kind of stuff but we are moving to all the factories that are coming locally, the whole dynamic of work is actually changing. 6 | 7 | Uber is a warm up for the social and financial changes that are happening in our society, the question is do we want to lead it or again do we want to be caught by the cross fire? 8 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Be Proactive.md: -------------------------------------------------------------------------------- 1 | We want to be proactive about this stuff and it is actually very mature. And again, like do you want to be like the rest of Europe be caught in a cross fire or do you want to be actually proactive and create an industry that will be very powerful but also very profitable? 2 | 3 | So this is quite cool, what I am defending here can actually be really, really powerful and productive, and profitable for Portugal. 4 | 5 | So, it gives us jobs, it gives all sorts of stuff and drive industry. 6 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote For the Developers in the Room.md: -------------------------------------------------------------------------------- 1 | And again if you are a developer today and you aren't thinking in terms of CI automation everything is code, 100% code coverage, graphs, containers, version control, AI, cloud etc. You are already writing legacy code, you would like to slack off the other project over there because the legacy gets what, if you aren't doing this, you are a legacy in your own world. 2 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Great Source of Talent.md: -------------------------------------------------------------------------------- 1 | So a great source of talent for example and this again is a bit controversial is that we should actually teach the convicted criminals how to hack. 2 | 3 | Because there are a lot of people that end up in prison for all sorts of reasons and probably you would do the same thing if you had those circumstance. 4 | 5 | But there is a path to there that we lose a lot of talent to go into these guys, they are already kind of 'creative' because to be fair when you rob something or criminal you actually get your head to be different so we just need to give those guys a little interesting path to good use of their skills. 6 | 7 | So give them a career, show them the way to make money legally, teach them ethics, and most criminals are due to bad choices. 8 | 9 | So let's use that. 10 | 11 | Even More Talent. 12 | 13 | A great source of talent is retired people, again we lose them by not using their experience. In the past they were the wise ones, we now ignore them and remember you will be old soon so it would be nice if we can do this so that by the time we get there, it would be nice if we were respected and our ideas were still valued versus kicked out of society. 14 | 15 | And the engineers, doctors, teachers, accountants, architects, parents etc. So there is a lot of talent there. 16 | 17 | And remember you grow old not because of your age but because you stop being mentally active. 18 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Leader in Cyber and Application Security.md: -------------------------------------------------------------------------------- 1 | So that is what we want to do, we want to be a leader on application, we want to be the best in the world. 2 | 3 | Just like football, we want to be the best in the world in coding and Cyber Security and Application Security that is what we want to be. 4 | 5 | Portugal as a Leader in AppSec 6 | 7 | And to be in AppSec we also have a little bit history of providing this kind of stuff. So basically the same way that we navigated the seas in the past, we now should be leaders in the code. 8 | 9 | If you compare to our forefathers in 15th century, I think it would be more scary when you thought that on the other side there was like all sorts of really dangerous and crazy stuff you even don't know if the earth was false on the other side. 10 | 11 | So I think we are a bit more cozy in our little problems today. 12 | 13 | So that is the thing and also we have a great tradition of innovation and all this kind of stuff. 14 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Let's do the same for hacking.md: -------------------------------------------------------------------------------- 1 | So, let's do the same thing for hacking, everybody can hack, the kids should be hacking all the time, they will love it because they are in the 'zone' we should support this activity like capture the school flag, like if you can freaking own the school network, you should be celebrated because you can change your grades, great you get another 10% just for that that is cool because that is how you learn. 2 | 3 | But you should be rewarded, you shouldn't be seen as criminals, doing that generates the view hacking is bad, you should be celebrating those stuff. 4 | 5 | And of course there is massive reward system. These days, if you are into security AppSec, we have 0% unemployment rate in AppSec, it is just you can't hire them. 6 | 7 | And in fact if you guys are good in AppSec, I have companies in the UK that will hire you today, you just need to know how to program, be good AppSec guy and that is it. 8 | 9 | There is really a massive shortage, so let's do the same thing for this. 10 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Military: -------------------------------------------------------------------------------- 1 | So the military, I brought this thing up, I was looking at it say at the moment we would probably say that our cyber and code defense are as good as the Portuguese military. 2 | 3 | The problem is the attackers are sophisticated as the best out there. 4 | 5 | So, you have to imagine that again Portugal will be attacked by the equivalent of US and China or France in terms of the UK. 6 | 7 | Why do we have F16s? 8 | 9 | And here is my question, why do we need the F16s? So I went to the Portuguese Armed Forces trying to figure out the thing and I found out that we have a nice F16, fleet of stuff and all these giants. 10 | 11 | We have $2.1 Billion turnover, like why does Portugal need an offensive force? Can you guys tell me one scenario that F16s will actually come into play? 12 | 13 | Give me a war scenario where we have somebody attacking Portugal, where our freaking F16s will actually do any value. 14 | 15 | And I understand to have a civil air force because we have fires, border controls, but F16s? 16 | 17 | And by the way, the way you fight these F16s these days is you hack into them that is the way you defend yourself. 18 | 19 | So, if you haven't read this book Ghost Fleet, I highly recommend because it shows how China theoretically took over the US because it kind of compromised the whole thing. 20 | 21 | So, if you use 10% of that budget, we can start a lot of things. 22 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Portugal Hackathon League.md: -------------------------------------------------------------------------------- 1 | We should also have Portugal Hackathon League where we should organize hackathon. Just like we did for football we should bring our PT Hacking teams to DefCon, it should be a source of pride. 2 | 3 | The same way that we run the football which is cool, we should be celebrating when our guys go to DefCon and become first or second over there. 4 | 5 | We should be a source of pride to actually have the best and most elite hackers because there is a connection to Portugal, there is a connection to your country, and that is what you really want to be. 6 | 7 | So this is a source of pride. And then it is also a great way to learn. 8 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Portuguese Hacking Service.md: -------------------------------------------------------------------------------- 1 | Here is the first idea for you, we should have the Portuguese Hacking Service. 2 | 3 | So this is like we had this thing called 'Servico Militar Obrigatorio' you guys probably remember some of these things, we need to do the same thing for hacking. 4 | 5 | We need to have this service where 15 to 21 year old go and freaking hack the country. Everything that is moving, hack companies, code review open source, code review markets as 'strategic interest for Portugal' contribute to open source projects. 6 | 7 | This will be a spectacular learning opportunity, this will be a great use of talent, of users create a new generation that understands those things. 8 | 9 | It doesn't cost any money, it is just political, it is just a decision, it is just a direction. 10 | 11 | But this will give us a lot of fuel, a lot of new things. And it also, I like this because it is almost like if you can't even stomach this idea then that is fine but this conversation will continue two years from now. 12 | 13 | Because it is not even that radical but it feels radical because not a lot of people have done it before. But it is easy, we have the tradition, and we should do it. 14 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Portuguese Innovations.md: -------------------------------------------------------------------------------- 1 | So, we have a great tradition of innovations, even things that maybe you don't realize, things like Multibanco, prepaid mobile phones, all the way to these great little paths, we have a great tradition of being innovators. 2 | 3 | This is a great success story, I don't know how much you guys realize this but this was one of the cases I read about Portugal in a very positive way. This is Portugal leading the way, why is because we had the balls to make a really good decision, to treat drugs as a public health problem not a criminal problem. 4 | 5 | This means that we are 10,000 more clever than companies in the world that declare war on drugs which clearly doesn't work. And UK it doesn't have a good drug record, so Portugal is a leader when we are able to make good decisions. 6 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Real Time Unit Test Execution and CC.md: -------------------------------------------------------------------------------- 1 | And also if you are doing Java script, and you aren't using Wallaby JS, and you don't have real time code coverage, you are living in the dark ages. And you can't code TDD until you have those things. 2 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Sane Defense Model: -------------------------------------------------------------------------------- 1 | And I also like this for a point, the best security model and I call this 'sane security model', isn't a security model based on having no vulnerabilities, no insecurities, no API dependencies, or no zero-days. 2 | 3 | That doesn't exist in the real world. The security model is based on the attacker making a mistake because all attackers make mistakes, even guys like the NSA or whoever created the stock net which is still not officially acknowledged, they made a mistake, they crushed one odd little box that was running an odd anti-virus and that unraveled the whole thing. 4 | 5 | And not just security model, now the question is can you detect it, do you understand your code, do you understand your applications, do you understand how everything works? 6 | 7 | That is why that is so critical, and not just security model not for Portugal but for any company. 8 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Secure Coding Activities.md: -------------------------------------------------------------------------------- 1 | For the guys that develop stuff I had to put some geek stuff on this. So, this is kind of what I call secure activities, security champions, that is the mug if you don't have a security champion in your team get a mug because it is better the mug as stack overflow. You need to code review, security coding standards, AppSec pipelines, do these pipelines, do threat models for app sec, feature, and layer that is the kind of stuff you guys should be doing. 2 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Where Is The AppSec Industry.md: -------------------------------------------------------------------------------- 1 | So, where is our AppSec industry? I don't think we have one really, issue is very small. I think it is a problem because we have a lot of talent and you could see this because you see every time you see an attack you see an AppSec team, it is one to one. 2 | 3 | So, I know it doesn't exist, in fact I know a lot of Portuguese in UK we are exporting AppSec talent to the UK, I actually work in London with a whole bunch of Portuguese guys. 4 | 5 | I am not going to name where I work right now because I don't want to get into trouble but there is a huge Portuguese community in the UK. 6 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Why is Portugal so Good at Football.md: -------------------------------------------------------------------------------- 1 | So, why is Portugal so good at football? I think it is a very interesting question because we are one of the best in the world, we are literally pushing above your way. 2 | 3 | So why is that? And I think one of the reasons is because everybody plays football, because our kids play it all the time, they love it. So they are in the 'zone' because when you are in the zone is when you learn. In a way we go to school to learn how to learn, we don't go to school to freaking remember all the historic facts and memorize formulas, and the stuff that we did in university, it is ridiculous my 13 year old does more math that are more complex than most of the stuff I program, never mind the stuff we had to do in university. 4 | 5 | So that is when you learn, and also it is supported by school activities, there is a social reward in community, there is a support system to find out talent, there is massive financial reward for that stuff. 6 | 7 | So that is what we need to do. 8 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Keynote Working Together.md: -------------------------------------------------------------------------------- 1 | The great thing in technology you can put everybody like this working together including the dog and it doesn't matter, as long as you work together, it is good. This is again a great vision for our society. 2 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/One Number To Define Risk.md: -------------------------------------------------------------------------------- 1 | Reducing risk to a number, a very interesting idea given to me by a CISO friend is to reduce all of AppSec and InfoSec activities into one number, which gets presented to the board, which then can be used to measure what is the current risk profile. 2 | 3 | In a way the number is a collation of multiple numbers which are then easy to understand and easy to map. And this actually is very tightly connected to the idea of maturity models where you use different...you measure the maturity of the multiple teams or multiple systems or multiple products and then understand better who is doing what. 4 | 5 | What I really like about the maturity models is that it allows the temperature to be defined in the actual model, so it allows the temperature much more objective and much more pragmatic way of actually looking at the problem and looking at the issues and that is basically a really nice way of controlling the temperature and applying pressure on the right places. 6 | 7 | And also knowing where to act because when you look at the multiple patterns and the multiple activities in the maturity model, you see which activities are working or it isn't working or is being done or not being done and that is a great way of analyzing the organization. 8 | 9 | In fact even the individual items of the maturity model needs sometimes maturity models because when you say you have a security champion, the whole security champion world has in a way its own maturity model where in the beginning it is the binary, do you have one or not? 10 | 11 | Then you start to look at how effective they are, how knowledgeable they are, how actually able they are to perform their duties same thing with code reviews, same thing with path chain, same thing with management of dependencies, same thing with threat analysis, all sorts of stuff. 12 | 13 | All of those are basically things that you should measure the maturity model eventually leading to a higher one which eventually leads to a number. 14 | 15 | So it is quite a nice work flow to do across the enterprise, it also scales really, really well. 16 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Security Champions To Provide Evidence.md: -------------------------------------------------------------------------------- 1 | An interesting thread that I have been having recently with security champions is that they really need to provide evidence for the tickets they open. 2 | 3 | So it is quite nice when you have this work flow with the security champion opening up issues and they have been pract about it. In a way the next step is to start to provide very strong evidence about it and if they can that is an issue in itself. 4 | 5 | And a good exercise for example for hackathons or for get togethers is actually come to the table. So for the security champions to come to the table and say, "hey, I think there is a problem, I think there is an issue can we prove it?" 6 | 7 | Because that is the key of the game, you have to build a proof, you have to be able to provide evidence for the findings you are actually opening up. And you need to basically be able to allow the person who will actually accept the risk or make a decision to really understand what is going on. 8 | 9 | Which is why the exploits these are critical, see the power of exploits there because that is so critical, you really need to have evidence and sometimes you need an exploit to really show this is how it could happen, this is how the problem is and sometimes you do in production, sometimes you do in QA it depends on the impact. The key of all this is evidence and proof. 10 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/The Hack Done At Presentation.md: -------------------------------------------------------------------------------- 1 | On the topic of hacking and solving little problems, when I was in Lisbon on the 'C' days, 2016 Conference, about to present, literally five minutes before it was about to start, we realized that for some weird reason, the projector was getting off 30% of my slides to the right. 2 | 3 | That was in a way is a deal breaker because I couldn't, my presentation is mainly text. I was reading from the screen, so it would totally not work if you couldn't get that. 4 | 5 | So I tried to change resolution of my laptop, I had never seen that problem before, didn't solve it and basically we were stuck and then Nunu a good friend suggested the idea of "Oh, actually why don't you export PDF and present it there?" And then I clocked it and I realized okay that might work. 6 | 7 | So, I then actually was able to export it with all the slides, with all the transitions, which is important because I had literally one transition per paragraph. And I did it and I exported it and I got a PDF with actually 500 slides, and then I was actually able to re-size it just to the size of what was happening on the screen basically with that 20% off adjusted. 8 | 9 | And then actually I had a little mouse which I was going to flick the slides over and then that didn't work because it wasn't in full screen. So I actually asked Nunu to literally flick the slides one by one with his finger and I was giving him the clues and that actually worked. 10 | 11 | And that is the hack, this is what hacks look like is when you have a problem, you have to think creatively, you have to solve something and you just make it work and then maybe another time the solution will get more solid but that is what is important is about to creatively find solutions for problems. 12 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Use-code-coverage-as-an-analysis-tool.md: -------------------------------------------------------------------------------- 1 | Once you get high degree of code coverage, a really powerful technique that you can start to use is to start to run specific suite of tests and specific slices of the application and see what gets covered and what doesn't get covered. 2 | 3 | It is very important especially on things like APIs where you are able to understand what actually is tabled from the outside world and now you argue that especially from an API that is maintained as exposed, you want to make sure that you have no functionality in the application that actually doesn't exist. 4 | 5 | And this could be a problem with some of the code coverage techniques, code coverage practices where it is easier to leave code there that doesn't get used any more but because it is tested, it is still in the application. 6 | 7 | Basically you want to have almost zero tolerance for code that is currently not being used, any code that instead has no code paths or not being evoked should be eliminated from the application because you really want to make sure that the app is really in sync with its current capability and expectations and extra code be maintained, be reviewed and get rid if you don't want it there. 8 | -------------------------------------------------------------------------------- /content/From-audio/To-Fix/Using Tokens To Access Data.md: -------------------------------------------------------------------------------- 1 | The problem with users having all access all the time. One legacy that we still have from our days of running everything with admin and everything with a couple of users is this lack of segmentation of user access and especially user data access and in this case it can be a database access from a real application is what we really want is a situation where whenever somebody needs a particular asset, needs a particular resource, they ask for it and then they get unit token which are given use to access the resource. 2 | 3 | The power of this is not only it enforces some of those access more explicit, it allows you place to control abuses. 4 | 5 | So at the moment, the reason why there are sometimes so many data leaks and data dump is because it is possible for an application to dump all the data in one go or to just keep asking for it and nobody will probably notice it. 6 | 7 | Where if that particular application or user had to generate tones or hundreds of tones or millions of tokens to access that that will be easy to monitor. 8 | 9 | Because this is key, you cannot generate good visualization or good understanding of what is going on at the edges because there is too much there that is not easy. 10 | 11 | What you can do is to visualize the patterns in a way the web services call the sequence of events or specific things which then will allow you to much better understand what is going on. 12 | 13 | So if we did that for assets and accessing assets, we would be in a much better situation to understand when abuses occur. 14 | -------------------------------------------------------------------------------- /content/creative-commons-license.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/creative-commons-license.png -------------------------------------------------------------------------------- /content/title_page.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DinisCruz/Book_SecDevOps_Risk_Workflow/647427ddafbf2cff8eefadcaf02013ee7bf5bb7b/content/title_page.jpg --------------------------------------------------------------------------------