Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

SecDevOps Risk Workflow - v0.6

1.874 Aufrufe

Veröffentlicht am

Slides from presentation delivered at InfoSecWeek in London (Oct 2016) about making developers more productive, embedding security practices into the SDL and ensuring that security risks are accepted and understood.

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

SecDevOps Risk Workflow - v0.6

  1. 1. SecDevOps Risk Workflow v0.6 InfoSecWeek, Oct 2016 @DinisCruz
  2. 2. Me • Developer for 25 years • AppSec for 13 years • Day jobs: • Leader OWASP O2 Platform project • Application Security Training • JBI Training, others • Part of AppSec team of: • The Hut Group • BBC • AppSec Consultant and Mentor • “I build AppSec teams….” • https://twitter.com/DinisCruz • http://blog.diniscruz.com • http://leanpub.com/u/DinisCruz
  3. 3. • Get it for free at https://leanpub.com/secdevops Based on “SecDevOps Risk Workflow” book
  5. 5. • (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 • RISK - Abuse the concept, found RISK to be best one for the wide range of issues covered by AppSec, while being understood by all players • 100% Code Coverage - not the summit, but base-camp (i.e. not the destination). And 100% code is not enough, we really need 500% or more Code Coverage) • AppSec ~= Non Functional requirements - AppSec is about understanding and controlling app’s unintended behaviours Disclaimers
  6. 6. • InfoSec is about: – Networks, Firewalls, Server security, Anti-virus, IDS, Logging, NOC, Policies, end-user security, mobile devices, AD/Ldap management, user provisioning, DevOps, …. • AppSec is about: – code, apps, CI, secure coding standards, threat models, frameworks, code dependencies, QA, testing, fuzzing, dev environments, DevOps, …. • If your ‘InfoSec’ team/person cannot code (and would not be hired by the Dev team), then that is NOT AppSec. • Both are equally important, but InfoSec is much more mature, has bigger budgets and is understood by the business AppSec vs InfoSec
  7. 7. The Pollution analogy
  8. 8. • The developers are the ones who pays the debt • Pollution is a much better analogy • The key is to make the business accept the risk (i.e the debt) – make sure it is your boss who gets fired (all the way to the board) • Which is done using the JIRA RISK Workflows Technical Debt is a bad analogy
  10. 10. RISK Workflow (using JIRA in Cloud)
  11. 11. Key for AppSec JIRA workflow is this button
  12. 12. CSO POINT VIEW
  13. 13. • Create an environment and workflow where Security (InfoSec and AppSec) is an enabler. • Allow the business to ship faster with quality, security and assurance • InfoSec protects the organisation and operations • AppSec protects the code created, used and bought • Developers code in environments where it is very hard to create security vulnerabilities • Applications run in environments where security exploits are contained and visible • Align business risk appetite with reality (using proposed Risk Workflow to allocate responsibility at the correct level) What type of security organisation to create
  14. 14. • Give security teams a mandate to focus on Quality, Testing and Engineering • Create a network of Security Champions • Become the ‘Department of Yes’ • Measure code pollution using Risk Workflow • Understand that developers are key players and need to be trusted • Testing and Quality are core business requirements (and what gives you speed) • Create an central AppSec team (usually there is only an InfoSec team) How to embed security into the culture
  15. 15. • Security policies are the foundation of decisions • They underpin the reason behind actions and risk accepted • But, if not based on reality, most policies will NOT be – read – followed – enforced • For policies to work they need to be customised to its target (for example Secure coding standards for App XYZ) • They also need to be delivered in the target’s environment (for example IDE) What about security policies?
  16. 16. • If you don’t – have an AppSec team – do Threat Models – do weekly code reviews and security assessments – have embedded security automation automation in your SDL pipeline – have secure coding standards, bug-bounties, dependency management – …. and many other other AppSec activities • Where is security going to come from? • without them … there will be massive security vulnerabilities in code and apps used • and your security model is based on the ‘skill level and business model’ of your attackers Security magic pixie dust
  18. 18. Cost of IT Failure https://www.youtube.com/watch?v=877OCQA_xzE
  19. 19. DevOps https://en.wikipedia.org/wiki/DevOps http://www.bogotobogo.com/DevOps/ DevOps_Jenkins_Chef_Puppet_Graphite_Logstash.php
  20. 20. What is DevOps http://www.slideshare.net/AmazonWebServices/securing-systems-at-cloud-scale-with-devsecops
  21. 21. Deploy, deploy, deploy https://github.com/blog/1241-deploying-at-github
  22. 22. It is all code http://www.enhops.com/devops
  23. 23. All this to manage code http://www.soa4u.co.uk/2015/04/a-word-about-microservice-architectures.html
  24. 24. SecDevOps https://www.linkedin.com/pulse/devsecops-secdevops-difference-kumar-mba-msc-cissp-mbcs-citp
  25. 25. Scrum process http://blog.xebia.com/wp-content/uploads/2013/08/scrum-process.jpg
  26. 26. DevSecOps http://www.slideshare.net/AmazonWebServices/sec405-enterprise-cloud-security-via-devsecops-aws-reinvent-2014
  27. 27. What is DevSecOps
  28. 28. What about the code? AppSec? http://www.slideshare.net/AmazonWebServices/sec320-leveraging-the-power-of-aws-to-automate-security-compliance
  29. 29. • Fixing and Securing the DevOps pipeline is not enough – In fact that is actually the ‘easy’ part • We also need to fix the developers workflow and secure the code they create – Threat Models – Security knowledge in the IDE – Security Champions – Risk Workflows that reward visibility and non-functional requirements Since everything is code, code is root cause
  30. 30. • Interesting debate at the moment in the industry • For me Sec-DevOps is about adding security to DevOps • Dev-SecOps is about adding development practices to Security operations • I like the idea that SecDevOps when done right – becomes just DevOps, which when the Ops are done right, – should become just Dev SecDevOps or DevSecOps
  32. 32. Security Champions (SC) http://blog.diniscruz.com/2015/10/what-are-security-champions-and-what-do.html
  33. 33. If you don’t have an SC, get a Mug
  35. 35. 1.Open JIRA issues for all AppSec issues 2.Write passing tests for issues reported 3.Manage using AppSec RISK workflow 1.Fix Path: Open, Allocated for Fix, Fix, Test Fix, Close 2.Accept Risk Path: Open, Accept Risk, Approve Risk, (Expire Risk) 4.Automatically report RISK’s status Proposed JIRA workflow
  36. 36. RISK Workflow (using JIRA in Cloud)
  37. 37. PATH #1 - Fix issue
  38. 38. PATH #2 - Accept and Approve RISK
  39. 39. PATH #2 - Variation when risk not approved
  40. 40. ‘FIX’ PATH
  41. 41. Issue: Data_Files.set_File_Data - Path Traversal
  42. 42. Status: OPEN
  43. 43. Status: IN PROGRESS
  44. 44. Status: ALLOCATED FOR FIX
  45. 45. Status: FIXING
  46. 46. Status: TEST FIX
  47. 47. Status: FIXED
  49. 49. RISK: Support for coffee allows RCE
  50. 50. Status: OPEN
  51. 51. Status: IN PROGRESS
  53. 53. Status: RISK ACCEPTED
  54. 54. Status: RISK APPROVED
  56. 56. All status changes are tracked
  58. 58. Key for AppSec JIRA workflow is this button
  59. 59. • This is a separate JIRA repo from the one used by devs – I like to call that project ‘RISK’ – This avoids project ‘issue creation’ politics and ‘safe harbour for: • known issues • ’shadow of a vulnerability’ issues • ‘this could be an problem…’ issues • ‘app is still in development’ issues – When deciding to fix an issue: • that is the moment to create an issue in the target project JIRA (or whatever bug tracking system they used) – When issue is fixed (and closed on target project JIRA): • AppSec confirms fix and closes RISK Separate JIRA project
  60. 60. • Key is to understand that issues need to be moving on one of two paths: – Fix – Risk Accepted (and approved) • Risks (i.e. issues) are never in ‘Backlog’ • If an issue is stuck in ‘allocated for fix’, then it will be moved into the ‘Awaiting Risk Acceptance’ stage Always moving until fix or acceptance
  61. 61. • If you don’t have 350+ issues on your JIRA RISK Project, you are not playing (and don’t have enough visibility into what is really going on) • Allow team A to see what team B had (and scale due due to issue description reuse) • Problem is not teams with 50 issues, prob is team with 5 issues • This is perfect for Gamification and to provide visibility into who to reward (and promote) You need volume
  62. 62. • All issues identified in Threat Models are added to the JIRA RISK project • Create Threat models by – layer – feature – bug • … that is a topic for another talk Threat model
  63. 63. Mapping to InfoSec risks
  64. 64. Mapping JIRA Tickets to Tests
  65. 65. JIRA AppSec Dashboards
  66. 66. Weekly emails with Risk status
  67. 67. • Components (one per team or project) • Labels (to add metadata to issues, for OWASP Top 10) • Links – connect with internal/external issues and – external resources • Auto emails • Copy and paste of images into description • Markdown • Security restrictions (use with care) • Security lock certain actions • Extra workflow actions for example when moving state) • Create APPSEC JIRA project for AppSec related tasks (like ‘Create Threat Model for app XYZ’) Other powerful JIRA features
  69. 69. Using GitHub (instead of JIRA)
  70. 70. Example with DoS issue
  71. 71. TDD
  72. 72. • For TDD to be productive you need – Real time unit test execution (when hands lift) – Real time code coverage • TDD focus needs to be on – making developers more productive – preventing developers from switching context • If 99% code coverage doesn’t happen ‘by default’ TDD workflow is not working TDD
  73. 73. TDD in WebStorm with WallabyJS
  74. 74. What happens when you increase attack surface
  75. 75. You want a test to fail
  76. 76. TDD in WebStorm with WallabyJS • … but is a topic for another talk :)
  77. 77. OWASP
  78. 78. • Best AppSec conferences of the year • 100s of chapters around the world • 100s of research projects on AppSec • All released under OpenSource and Creative Common licenses • Best concentration of AppSec talent in the world • Please join, collaborate, participate Epicentre of Application Security
  79. 79. Conferences
  80. 80. Chapters
  81. 81. Chapters - Europe
  82. 82. Projects - Flagship
  83. 83. Projects - Labs
  84. 84. Projects - Incubator
  85. 85. Summit - 2008
  86. 86. Summit 2011
  87. 87. Corporate Members
  88. 88. Thanks, any questions @diniscruz dinis.cruz@owasp.org