情報セキュリティのシフトレフト

# 情報セキュリティのシフトレフト ## 定義情報セキュリティのシフトレフト(shift left on security)とは、情報セキュリティ関連の作業を独立したフェーズとして開発プロセスのダウンストリーム(下流)で実施するのではなく、最初からソフトウェアのデリバリのプロセスに組み込むことである。『LeanとDevOpsの科学［Accelerate］』第6章は、チームがこのシフトレフトを実践すると継続的デリバリを実現する能力が向上し、ひいてはデリバリのパフォーマンスも向上するという調査結果を報告する。背景には、情報セキュリティ担当チームが人員不足のまま(開発者100人当たり担当者1人程度)、変更追加が困難でコストもかさむ開発ライフサイクルの最終段階でしか関与しないのが一般的だという現状認識がある。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] ch.6 p.83, §6.1) ## シフトレフトが生む3つの状況第6章はシフトレフトが具体的に生む状況を3つに整理する。(1) 主要機能のすべてについて情報セキュリティのレビューが行われ、しかも開発プロセスの速度を落とさない方法で進められる。(2) 情報セキュリティが開発から運用までソフトウェアデリバリのライフサイクル全体に組み込まれる——専門家が設計プロセスに関与し、デモに参加してフィードバックを返し、自動化されたテストスイートの一環としてセキュリティ関連機能のテストが確実に行われるようにする。(3) 開発者が情報セキュリティに関してなすべきことを容易に行える——事前に承認された使い勝手の良いライブラリ・パッケージ・ツールチェーンあるいはプロセスを開発者とIT運用担当者が利用できるようにする。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] ch.6 §6.1) ## セキュリティチームの役割転換シフトレフトは、情報セキュリティ担当チームの役割を「セキュリティ関連のレビューを行う」という状況から「情報セキュリティを組み込むための手段を開発者に提供する」という状況へ転換させる。この転換の背景には2つの現実がある。第1に、ほぼ完成に近いシステムを検査してアーキテクチャがらみの大きな問題や欠陥を見つけるより、ソフトウェアを構築している開発者自身が情報セキュリティ関連の作業を担当するほうがはるかに簡単だという現実。第2に、デプロイの頻度が高くなると情報セキュリティ担当チームはいちいちレビューをしている余裕がなくなるという現実である。多くの組織では、情報関連のセキュリティとコンプライアンスが「開発完了」から「本番稼働」への移行作業で重大なボトルネックとなっており、開発プロセス全体を通してセキュリティの専門家を関与させることでコミュニケーションと情報の流れが改善するという効果も得られる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] ch.6 §6.1) ## 実証された効果デリバリのパフォーマンスが高い組織は低い組織よりもセキュリティ問題の修正の所要時間が有意に少ない。さらに、ハイパフォーマーが情報セキュリティに関わる問題の修正にかけた時間はローパフォーマーの2分の1という結果が出ている。情報セキュリティに関わる問題を開発の最終段階で修正するのではなく、セキュリティ対策を開発者の日常的な作業にすることで、セキュリティ関連の問題への対処に要した時間が有意に減少した。米国政府機関の事例(米国総務庁18Fが構築したcloud.gov)では、セキュリティ要件の大半(325項目中269項目)がプラットフォームレベルで満たされ、「開発完了」から「本番稼働」への移行が「月」ではなく「週」の単位で完了できるようになった。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] ch.6 p.86-87) ## DevSecOpsとRugged DevOps DevOpsを情報セキュリティ問題も包含するものに改めようと、新たな呼称がいくつか提案されている。Capital OneのTopoPalやIntuitのShannon Lietzをはじめとする業界関係者による「DevSecOps」、Josh CormanとJames Wickettによる「Rugged DevOps」である。後者はRugged Manifesto(自分のコードが頑強であることへのコミットメントを宣言する声明文)をDevOpsと組み合わせる形を取り、コードが物理的・経済的・国家的セキュリティを脅かす敵対者に攻撃されうることを認識したうえで、脆弱性や弱点の原因となることを拒否するがゆえに「頑強であること」を選択するとする。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] ch.6 §6.2) ## 横断的知見 - **第4章がシフトレフトを統計的に効果ありと結論づける一方、第6章はその内実(3つの状況・役割転換)を定性的に詳述しており、両者を合わせて初めて「なぜ効くのか」が見える**: [[継続的デリバリ]] concept が集約する第4章は、2014〜2016年調査で計測した7つのケイパビリティの1つとして「情報セキュリティのシフトレフト」を挙げ、これらがソフトウェアデリバリのパフォーマンスに強い好影響を与えると統計的に結論づけるが、シフトレフトが具体的に何を指すか、なぜ効果を持つのかには踏み込まない。第6章は同じ主題を、シフトレフトが生む3つの状況・セキュリティチームの役割転換という質的なメカニズムとして詳述する。同一書籍内の別章どうしの突き合わせであっても、定量的な効果測定(第4章)と質的な機序の説明(第6章)という異なる種類の情報が独立に提示されており、両者を合わせて初めて「シフトレフトというケイパビリティがなぜデリバリパフォーマンスに寄与するか」の全体像が得られる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]] §6.1) ## 未解決の問い - 第4章は7つのケイパビリティの1つとしてシフトレフトを統計的に測定するが、具体的にどの調査票の設問項目でシフトレフトの実践度を測ったかは第4章本文だけでは分からない。第6章の3つの状況(レビューの並走化・ライフサイクル全体への組み込み・開発者向けツール提供)のどれが調査票の設問に対応するかは未確認。 - Rugged DevOpsとDevSecOpsという2つの呼称は、第6章では並列に紹介されるのみで、両者の実践上の違い(誰が提唱し、どのような具体的プラクティスを伴うか)には踏み込まれていない。 - cloud.govの事例は米国政府機関という規制の強い文脈での効果を示すが、規制の緩い民間企業でも同程度の効果(月→週の短縮)が得られるかは第6章だけでは分からない。 - 「ハイパフォーマーの修正時間がローパフォーマーの2分の1」という結果の調査年度・母数は第6章本文には明記されていない。第2章のクラスター分析(2016・2017年調査)との対応関係は未確認。 ## 関連 - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 6 デリバリライフサイクルに情報セキュリティを組み込む]](本概念の主要出典) / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]](シフトレフトを7つのケイパビリティの1つとして統計的に計測) - 概念: [[継続的デリバリ]](シフトレフトを構成要素の1つとして含む上位ケイパビリティ群) / [[DORA]](デリバリパフォーマンスの4指標との関連) / [[セキュリティと信頼性の文化]](レビュー文化・意識の文化との接続) / [[セキュリティの責任分担]](セキュリティチームの役割転換と「全員責任」原則の接続) / [[セキュリティ設計原則]] - 書籍: [[LeanとDevOpsの科学［Accelerate］]] ## 出典 - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第6章. - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第4章.