Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to balance between Security and Agile Development

74 views

Published on

(Partially) translated version of the slide that are presented at Regional Scrum Gathering Tokyo 2021.

Original slide: https://www2.slideshare.net/makotoiguchi/ss-240891870

Published in: Software
  • Be the first to comment

  • Be the first to like this

How to balance between Security and Agile Development

  1. 1. How to balance between Security and Agile Development Regional Scrum Gathering Tokyo 2021 Makoto IGUCHI (Kii Corporation)
  2. 2. The relationship between security and agile development… It’s got to be good, right?
  3. 3. In reality… • Will security put the brakes on DevOps and agile development (2016.12.26) https://www.atmarkit.co.jp/ait/articles/1612/19/news128.html
  4. 4. Today’s talk 1. A small trick to achieve a good relationship between security and agile development  “Absolute” vs. “Relative” thinking 2. Experiment for building a good relationship @ my workplace  “Shift left” using a card game  Rethinking the “value” of security tasks
  5. 5. Self Introduction • Makoto Iguchi@ https://jp.kii.com/ • Scrum Master • Security Architect  Responsible for doing everything possible to improve the security of the product • Head of ISMS Internal auditors A company developing and operating a cloud service for IoT platform and solutions.
  6. 6. A small trick to achieve a good relationship between Security and Agile Development
  7. 7. How is it in your workplace? Relationship between security and development in your workplace is: 1. Excellent 2. Good 3. Fair 4. Poor
  8. 8. A developer’s tweet…
  9. 9. From Japan Information Security Audit Association Result of the survey released on 2020/1/6 https://www.jasa.jp/seminar/sec_trend2020/
  10. 10. Better Product Adding valuable features Improving security (reducing vulnerabilities)
  11. 11. What’s wrong here? Example) Checklists, such as Information Security Management/Audit Standards … all-too-common model of security as a team, which sits and snipes at the people who actually build things, telling them no and pointing fingers, is in fact fantastically counterproductive. --- Your Security team is probably an infuriating obstacle – but it doesn’t have to be this way (TechCrunch 2019/8/8) Make sure to pass all the checklist items! Pass all “high” priority items, or no release is allowed!
  12. 12. Is the checklist absolute?? The checklist should be followed blindly… It should be utilized relative to the current situation  対応を要する項目の発 見と取捨選択 of course not!
  13. 13. Actual example Information Security Management Standards (rev. 2016) by Ministry of Economy, Trade and Industry 「II 本管理基準の位置づけ」に以下の記載 本管理基準は、組織体における情報セキュリティマネジメントの円滑 で効果的な確立を目指して、マネジメントサイクル構築の出発点から 具体的な管理策に至るまで、包括的な適用範囲を有する基準となって いる。当然のことではあるが、組織体が属する業界又は事業活動の特 性等を考慮し、必要に応じて本管理基準の趣旨及び体系に則って、本 管理基準の項目等を取捨選択、追加又は統合することにより、該当す る関係機関において独自の管理基準を策定し活用することが望ましい。 https://www.meti.go.jp/policy/netsecurity/downloadfiles/IS_Management_Standard_H28.pdf
  14. 14. Trick to build a good relationship “Absolute” thinking “Relative“ thinking Man-month estimate Story point estimate Fixed spec and schedule Priority and schedule refinement per sprint
  15. 15. WHY DON’T YOU BECOME A DEMON? RELATIVE- THINKER?
  16. 16. Experiment for building a good relationship
  17. 17. Experiment @ my workplace Sprint backlog Product backlog 脅 威 Realizing “shift left” using a card game Properly loading security tasks onto the sprint backlog
  18. 18. スプリントバックログ プロダクトバックログ セキュリティタスクを正しく スプリントバックログに積む工夫 脅 威 Realizing “shift left” using a card game
  19. 19. Shift-left security Designing Implementing Operating/maintaining HERE
  20. 20. STRIDE Threat Analysis • Spoofing • Tampering • Repudiation • Information Disclosure • Denial of Service • Elevation of Privilege A good reference on threat analysis →
  21. 21. STRIDE card game (EoP card game) The Elevation of Privilege Threat Modeling Card Deck https://github.com/adamshostack/eop
  22. 22. Japanese version  EoP脅威モデリングカードゲーム https://bit.ly/eop-ja
  23. 23. プロダクトバックログ 脅 威 カードゲームを使った シフトレフトの実現 Sprint backlog Properly loading security tasks onto the sprint backlog
  24. 24. This is quite difficult… Security is difficult with agile methods (2018.12.13) https://japan.zdnet.com/article/35130079/ The problem of putting off security tasks
  25. 25. Piling up items to maximize values What is Agile? by Henrik Kniberg
  26. 26. 脅 威 Does it mean that security tasks do not contribute to adding values to the product?
  27. 27. Rethinking security tasks Security Task Tasks for fixing product weaknesses (vulnerabilities) that are found through threat analysis • Vulnerabilities continue to exist until the task is completed • Vulnerabilities disappear when the task is completed
  28. 28. Let’s think vulnerability as a bomb Even if there is a bomb in the product, it does not affect the value of the product as long as it does not explode. Once it explodes, the value of the product is brown away completely.
  29. 29. Security task and product value Task for dismantling bomb in the product • The task itself does not increase the product value • The task prevents bombs from exploding and destroying the product value
  30. 30. Sprint Planing Sprint backlog Product backlog 脅 威 Bomb dismantling backlog Load implementation tasks to efficiently increase product value Load dangerous items that are about to explode to avoid them from blowing up product value
  31. 31. 「ときメ○」モデル 女の子からの評価 スクラム アジャ子 インプリ セキュ実 好雄 「こんなとこだな。 爆発しない限り価値=好感度 に影響を及ぼさないが、爆発 すると今まで積んだ好感度が 吹っ飛んでしまう。  適宜爆弾処理が必要 価値=好感度を上げる ために効率よく実装 タスクをこなしていく
  32. 32. MVP (Minimum Viable Product) with MBP (Manageable Bomb Placement) What is Agile? by Henrik Kniberg
  33. 33. Spotting dangerous bombs relatively As with product backlog, the bomb dismantling backlog need to be refined on a regular basis to load the appropriate security tasks on time e.g., Vulnerability = “No Brake” Not dangerous Getting dangerous Completely out of control
  34. 34. “Too much bomb” case: Zoom A Message to Our Users (April 1, 2020) https://blog.zoom.us/a-message-to-our-users/ • Suspended new feature development for 90 days • Focused on solving security/privacy issues
  35. 35. Balancing security and agile development is possible! You can do it!

×