マネーフォワードのセキュアソフトウェア開発ライフサイクルの今 / Secure Software Development Life Cycle in Money Forward

Money Forward Developers' Storiesの登壇資料です。
This is a presentation material for Money Forward Developers' Stories.

https://moneyforward.connpass.com/event/140296/

https://note.com/akiko_pusu/n/n2ec7437269b7#XDD04

Transcript

1. マネーフォワードの セキュアソフトウェア開発 ライフサイクルの今 2019-08-23 Money Forward Developers' Stories #1 第⼀部: これまで(過去から現在までの話を中⼼に) 1
2. ⾃⼰紹介 • ⽊村 直樹 • CISO室 セキュリティ推進グループ 所属 • プロダクト・セキュリティ 担当 • セキュリティ・エンジニア • 2018年5⽉⼊社 2
3. マネーフォワードは インターネット企業 3 この写真 の作成者 不明な作成者 は CC BY のライセンスを許諾されています
4. インターネットは脅威で溢れている 4
5. セキュリティ事故が起これば… 5
6. 信頼性失墜 6
7. 「お⾦」=「信頼」 7
8. マネーフォワードにとっ てセキュリティは⽣命線 マネーフォワードのVisionは… すべての⼈の、「お⾦のプラットフォーム」にな る。 8
9. セキュリティを念頭に置いた モノづくりが重要 9 この写真 の作成者 不明な作成者 は CC BY-NC-ND のライセンスを許諾されています
10. ということで、セキュリティの話をします 10 この写真 の作成者 不明な作成者 は CC BY-ND のライセンスを許諾されています
11. マネーフォワードの プロダクト開発の今 11
12. サービスは 15以上 1 2
13. エンジニア は およそ200⼈ 13 この写真 の作成者 不明な作成者 は CC BY-SA のライセンスを許諾されています
14. リポジトリーは およそ400 1 4 この写真 の作成者 不明な作成者 は CC BY-SA のライセンスを許諾されています
15. 開発⼿法はDevOps 15
16. この状況にどうセ キュリティ活動を 融合するか? 16
17. セキュアソフトウェア 開発ライフサイクルに ついて どうやって安全で堅牢なプロダクトを開発しているのか 17
18. ソフトウェア開発ライフサイクル SDLC (Software Development Life Cycle) 要件 (requirem ents) 設計 (design) 実装 (implemen tation) 検証 (verificatio n) 運⽤・保守 (maintena nce) 18
19. セキュアソフトウェア開発ライフサイクル S-SDLC (Secure Software Development Life Cycle) 19 要件 セキュリティ 要件の定義 設計 Security by Design 脅威分析 実装 Secure Coding / Build / Deployment バグ管理 検証 セキュリティ 要件の検証 セキュリティ 検査 運⽤ Security Issue Management 環境の堅牢化
20. 「今」を⾒つめるため に「過去」を振り返る 「今」は「過去」の積み重ねでできている 20
21. ⼊社当初は… 21 ⾃分はRuby初⼼者 プロダクト・セキュ リティ担当が空席 引き継ぎは、CISOが 直々に 残されていたのは、 ⼤量のドキュメント 試⾏錯誤の痕跡
22. 空洞化が起ころうとしていた 22 この写真 の作成者 不明な作成者 は CC BY-SA のライセンスを許諾されています
23. まず、⾏ったのは… プロダクト開発チームへの参加 • 実際にRuby on Railsでプロダクト開発 • コードが読めて直せないと、エンジニア と対等に話できないと思っていたから • 上から⽬線の⼀⽅的な指摘では、抵抗さ れてうまく受け⼊れてもらえない • マネーフォワードのSDLCを実感するこ とで課題が⾒えてきた 23
24. そのとき⾒えてき た課題 • プロダクト個別に積み重ねてきたセ キュリティ対策をどう発展させていく か • 共通してやっておくべき対策は広めたい • プロダクトが急拡⼤・急成⻑する中で セキュリティ品質をどう追従させてい くのか • 形骸化・陳腐化させないためにはどうする 24
25. セキュリティ活動 をどう継続するか 25
26. やってきたこと 26
27. Slackに #product_securityを 作成 • 専⽤チャンネルを設けて、プ ロダクト・セキュリティに関 する情報を集約 • 各プロダクトチームのキーマ ンを招待 • 情報共有と協議の場 • あえてパブリックチャンネル にした 27 この写真 の作成者 不明な作成者 は CC BY-SA のライセンスを許諾されています
28. SAST(Static Application Security Testing) の導⼊ • ソースコードを解析してセキュリ ティの⽋陥を発⾒する • 設定がほぼ不要なので導⼊が容易 • 誤検知が多い傾向にある • Ruby on RailsならBrakeman 28
29. どうやってSASTを ⼊れる? 2 9 • いつ誰がSASTを実⾏するか • SASTのレポートをどう伝えるか • CIジョブに組み込むのも⼿間 • ⾯倒なことは受け⼊れがたい
30. Sider × Brakeman • コードレビュー⽀ 援のSaaS • GitHubと連携して PRチェック • 差分のみを解析 • PRにインラインコ メント • Brakeman以外の 静的解析もワンク リックで設定 30
31. SCA (Software Component Analysis) • OWASP Top 10 • A9:2017-Using Components with Known Vulnerabilities • 依存ライブラリーの把握と脆弱性情 報の収集 • 依存ライブラリーのライセンスも 31
32. SCA、 めっちゃ⾟い 3 2 • OSSは数多ある • ⽇々やってくる脆弱性情報の精査 • システムは複雑になっていく • リポジトリーは増えていく • プログラミング⾔語が違えばパッ ケージ管理も変わってくる • GitHubの Security alertsもあるが、 組織全体の状況を把握できない この写真 の作成者 不明な作成者 は CC BY-SA のライセンスを許諾されています
33. Snyk • SCAのSaaS • GitHub連携 • PRチェック • 多くのプログラミ ング⾔語に対応 • サマリーレポート • Slack通知も 33
34. Snyk × Slack 34 SnykでIssueを検知 #product_securityに通知 CISO室を中⼼にトリアージ #product_securityで注意喚起 各プロダクト担当が対処
35. トリアージの観点 35 その脆弱性が現実的に脅威となりえるか? CWEやCVSSは どうか? 機密性/完全性/可⽤性がどのくらい脅かされるか? その脆弱性がプロダクトで顕在化しそうか? ライブラリー の使い⽅が脆弱性となるパターンに⼀致するか? そのライブラリーがプロダクションにバンドルされるもの か? 開発⼯程でしか使わないものか? すでにパッチは出ているか? 回避策はないか?
36. 脆弱性診断 • ⾃動では検査できない脆弱性は多い • ⼿動での検査は必要 • 健康診断のようなもの • リリース/リニューアル時に加え、 年に1度はやりたい 36
37. 脆弱性診断は、 いつ誰がやるの 3 7 • DevOpsだとタイミングが難しい • ⼩さなリリースは常にある • 診断チームを内製してやりたいが、 要員が⾜りない • セキュリティ・エンジニアはどこも ⼈⼿不⾜
38. 脆弱性診断は アウトソーシ ング 38 餅は餅屋 検査項⽬はASVS基準にして明確化 チケット制の年間契約 SlackとBoxでコミュニケーション・コス ト削減 将来は、Bug bounty programもやりたい
39. DAST(Dynamic Application Security Testing)の導⼊ • アプリケーションに擬似攻撃を仕掛 けてセキュリティの⽋陥を発⾒する • XSS / SQLi / CMDi / パストラバー サルなど • 個⼈的にはOWASP ZAP派 39
40. DASTは⾃動化が難 しい 4 0 • スキャンまでの準備が⼤変 • アプリの実⾏環境 • アプリのクロール • クロールのシナリオをメンテ • スキャン結果の精査が⼤変 • False Positive / False Negative の⾒極め • 脆弱性診断スキルが求められる • 要員が必要
41. VAddy • DASTのSaaS • まずは標準化 • DASTで検査する項 ⽬を絞る • QA担当がクロール • CISO室がトリアー ジ • アウトソースも できる体制に 41
42. まとめ 42
43. マネーフォワードのS-SDLCの今 43 要件 • 情報セ キュリ ティ対策 スタン ダード 設計 • セキュリ ティ・エ ンジニア や有識者 による⽀ 援 実装 • SASTの⾃ 動化 • GitHub Issues / Jira / Asana 検証 • DAST • 脆弱性診 断 運⽤ • SCA • WAF
44. ⼤切にしていること 44
45. マネーフォワードのCulture 45 Speed 意思決定のスピード を上げ、最速で⾏動 に移し、最速でやり 遂げよう。 Pride 絶えず成⻑し、最⾼ の結果を出すために、 プロとして⾼い意識 をもってやり抜こう。 Teamwork One for all, All for one.の精神を⼤切に、 ひとつのチームと なって⽬標を成し遂 げよう。 Respect 感謝と尊敬を忘れず に、誰に対しても誠 実であり続けよう。 Fun 仕事を楽しみ、成⻑ を楽しみ、⼈⽣を楽 しもう。
46. Cultureになぞらえると… 46 セキュリティがプロダクト開発のブレーキにならない 「お⾦のプラットフォーム」⾜る安全で堅牢なプロダクト 属⼈化や空洞化しない仕組み・体制をつくる プロダクトの事業判断を尊重する セキュリティも愉しもう!
47. スピートと堅牢性はバランスが⼤事 47 この写真 の作成者 不明な作成者 は CC BY-SA のライセンスを許諾されています
48. セキュリティも⼀定レベルは標準化・⾃動化して属⼈性を排除 48
49. Cultureに馴染むようセキュリティ活動を仕⽴てる 49
50. おしまい 50