(Partially) translated version of the slide that are presented at Regional Scrum Gathering Tokyo 2021.
Original slide: https://www2.slideshare.net/makotoiguchi/ss-240891870
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. 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. 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. A small trick to achieve a good
relationship between Security
and Agile Development
7. How is it in your workplace?
Relationship between security and development in
your workplace is:
1. Excellent
2. Good
3. Fair
4. Poor
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. Is the checklist absolute??
The checklist should
be followed blindly…
It should be utilized relative
to the current situation
対応を要する項目の発
見と取捨選択
of course not!
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. 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
20. STRIDE Threat Analysis
• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege
A good reference on threat analysis →
21. STRIDE card game (EoP card game)
The Elevation of Privilege Threat Modeling Card Deck
https://github.com/adamshostack/eop
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. Piling up items to maximize values
What is Agile? by Henrik Kniberg
26. 脅
威
Does it mean that security tasks
do not contribute to adding values
to the product?
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. 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. 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. 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
32. MVP (Minimum Viable Product)
with MBP (Manageable Bomb Placement)
What is Agile? by Henrik Kniberg
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. “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