「シフトレフト」のポスターのご紹介

 数多くの攻撃はインフラストラクチャのセキュリティソリューションが有効でないアプリケーション層で発生する。残念ながらアプリケーション開発では設計によるセキュリティ(Security by Design)と「DevSecOps」のようなハードニングはまだ一般的ではない。

 それを抜本的に変えようとすると、色んな理由で明治維新のように大きな革命的な努力が必要になる。アプリケーションセキュリティ強化の普及促進のために、現在のセキュリティに対する数多くの人のマインドセットチェンジとビジネスの常識を変えていくこと、まるで改革のような普及促進運動が必要となる!

Shift-Left, Security by Design and DevSecOps
「シフトレフト」のポスター:アプリケーションセキュリティを様々な角度と背景から議論するためのポスター。「Shift Left」、「Design by Security」と「DevSecOps」はアプリケーションセキュリティの普及促進のために便利な概念である。

日本語版A3サイズポスターのダウンロード(小)
日本語版A2サイズポスターのダウンロード(中)
日本語版A1サイズポスターのダウンロード(大)

このポスターは製品中立であり、より良い共有のためにクリエイティブコモンズのライセンスの下で公開されている。

なぜ「アプリケーションセキュリティ」に「維新の三傑」なのか?

 変なタイトルだと思う人が多くいるだろうか。だが、これは、大切な概念を説明するためにあらわしたとても便利な言葉である。アプリケーションセキュリティと維新の三傑のご参考のページはこちらへどうぞ。

アプリケーションセキュリティ強化のための方程式

 残念ながらアプリケーションセキュリティの品質向上は自動的に行われない。アプリケーションセキュリティ強化を導入するのはある程度のコストと時間的な努力が必要になくてはならない。それを維持するために、ある程度のモチベーションがないと、意味がある対策は何も始まらない。これは方程式のように次のように表わすことができる:

AppSecの実装(X)= AppSecのモチベーション(Y)

この方程式を基にすると、ポスターの内容は一言で次のように説明できる:

AppSecの実装(「Security by Design」+「DevSecOps」)= AppSecのモチベーション(「シフトレフト」)

不十分なセキュリティは善悪の問題ではない

 アプリケーションセキュリティの問題は不十分なセキュリティ知識に原因があるが、実は、大概はビジネスの組織文化の問題でもある。任せ主義の中でよく観られる現象「あなたがやると思ったけど・・・」という根拠なしの無言の要求は、ITセキュリティにおいて無意味だし最悪の文化だ。アプリケーションセキュリティの要求を真剣に取り扱う必要がある。暗黙の了解に責任を委任してしまうとセキュリティは機能しない。

セキュリティの要求を他の非機能要求と混ぜるな!

 当然だが、普通のスポンサー(ビジネス側)にはセキュリティに興味がない。開発プロジェクトの際、最優先なのはビジネス機能の実現なので、IT側にIT専属の問題を任せるのは当たり前である。確かに、パフォーマンスとキャパシティ計画などのような非機能の要求はIT側の専門家に任した方が効率的である。

 しかし、セキュリティにおいて非機能の要求に留まってしまうと良い結果がもたらされない。自分のキャリアに悪い影響を及ぼす恐れがあるために、プロジェクトマネージャーはビジネスの要求と無関係な要求を意図的に開発対象として実装させない。という選択肢をするプロジェクトが遅れる、コストが増加する、というリスクが高過ぎるので行わない。同じ理由で、開発者は必要不可欠以外なことを追加開発しない。

 また、組織の業務と文化においてアプリケーション側とインフラ側の連携と情報交換は少ない。ITインフラを管理する運用側のIT部署は進んだアプリケーションセキュリティレベルの機能を提供しない。お互いの閉ざされた世界に入ってしまうと、可用性を害する事件を起こす恐れがあるので、部署間にはサイロ化した厚い壁がある。お互いの責任の依存度を少なくするのはIT業界の常識である。

 セキュリティにおいてインフラレベルのセキュリティ機能もある。それはネットワークセキュリティとシステムセキュリティの基礎をユーザーとアプリケーションにサービスとして提供することだ。最近のサイバーセキュリティブームの影響で、ITの運用側及びインフラ側はセキュリティのインフラのために独自のセキュリティ予算を持つようになった。

ボトムアップ:焦点はIT現場

セキュリティにおけるIT現場の悲劇

 残念ながらアプリケーションセキュリティにおいて、普通の組織の中における開発業務のプロセスとそれに関わる決定のメカニズムは不十分なセキュリティ品質をもたらしてしまっている。プロジェクト側に対し、ビジネス側(スポンサー)はセキュリティを完全にIT側に任せる。その結果、プロジェクト側は十分なアプリケーションセキュリティを開発せず、既に実装されている運用側のセキュリティのインフラに頼る傾向が強い。しかし、運用側のセキュリティのインフラはアプリケーションセキュリティの細かいニーズに対応できないため、ネットワークとシステムのセキュリティを中心した一般的なセキュリティを提供するしか方法がない。

 これはで『IT現場のセキュリティ悲劇』だ。お互いの認識不足と意識不足はその根本原因でもあるが、丸投げの連鎖反応の基に多数のセキュリティ問題が発生する恐れがある。

図1:多数の開発プロジェクトでよく見られる現場の状況(IT現場のセキュリティ悲劇)。それは開発手法の問題ではなく、セキュリティに対する認識・意識とコミットは広い範囲に渡って欠けている。

 IT現場のセキュリティ悲劇の図には二つの極端な開発手法が表示されている。左は「ウォーターフォール」という伝統的な開発手法である。厳格な剛性と透明化を目標にしていることにより全てが細かく文書化され、ITプロジェクトとビジネス側との接点が少ない。このような「しっかり主義」がコストアップにつながり、リリースのスピードは数ヶ月単位で極めて遅いという悪い印象をスポンサー側に与えられてしまう。

 右はいわゆる「アジャイル型」の開発手法と「DevOps」という開発専用のパイプラインの組み合わせを示している。アジャイルは開発手法としてよく取り扱っている。だが、実はデリバリのスピードを速めるためにプロジェクトコストを減少させるプロジェクトマネジメント手法である。開発側は開発中、ビジネス側と密な連携でスポンサーが求めている機能のみを実装する。そこで、アジャイルと「DevOps」の組み合わせは、リリースのスピードを更に速め、コストも大幅削減するので、ビジネス側及びスポンサーが大歓迎する。

 しかし、この現場の悲劇をもたらした根本原因は特定の開発手法のせいではない。このような結果はどんな開発手法でも起こり得ることなのだ。

開発手法はIT関係者の基礎知識

 こちらは開発手法を紹介するところではないが、話を理解する上でIT関係のプロフェショナルにとって基礎知識とも言えるべき内容を把握しておいていただきたいので、その部分がポスターに含まれている。

 特にITセキュリティ、ITリスクとITガバナンスに関係がある部署に不可欠な知識は、プロジェクト側にいつ、どのようなセキュリティ要求をするべきか、いつその要求とその後の実装を承認するべきかというものだ。この程度の開発手法の進め方が分からないと、ガバナンス的な機能と監督の役割を失ってしまう恐れがある。

マインドセットチェンジは必要

 セキュリティの根本原因の問題は開発手法ではない。大事なのは組織の中におけるセキュリティに対するマインドセットとそのプロセスの適切さである。ビジネス側及びスポンサーが積極的なセキュリティを明確に求めれば、プロジェクトマネージャーがその要求に対応するハズだ。

 このようなセキュリティ要求をプロジェクトに正式に受け入れるのはプロジェクトマネージャーの責任だ。更に、適切なセキュリティデザインとその実装のために必要な予算までを案件に追加する。これはあくまでスポンサーの要求なので、開発手法とは関係ないのだた、そうすることでスポンサーが恐れている脅威のリスクに十分対応する積極的なセキュリティ対策が実装された製品がデリバリされる。

言うのは簡単だが、組織の文化におけるマインドセットチェンジは難しい

 脆弱性のないアプリケーションは存在するのだろうか。脆弱性が明らかになった場合、一般的な組織の中では次に挙がるのは批判の声であろう。しかし、セキュリティの品質においてICT業界で明らかにシステミックな問題が起きた際に開発者を批判するのはあまりにも無意味だ。

 十分な予算とリソースがないまま責任を丸投げすれば本格的なアプリケーションセキュリティは成り立たないということだ。ITセキュリティを品質改善のように捉えるべきで、セキュリティを品質改善のような要求にする必要がある。

 開発における三つの段階での理想的なアプローチの導入は次の通りである:

  • 「Security by Design」:コーディング作業開始前にセキュリティの設計を考慮!
  • 「DevSecOps」:コーディング中のハードニングの基礎を実装!
  • 「DevSecOps」:コーディング後(リリース後)の継続的なハードニングを確実に!

「Security by Design」の要求で導入する

 コーディングを始める前にセキュリティ設計を考えるのは当たり前のように聞こえる。だが、それを開発プロセスで適応させると小さなかつ決定的な変更が必要になる。ビジネス側かITガバナンスか、又はその両方がその極めて小さな変更に注意する必要がある。実際は、プロジェクト側が積極的なセキュリティを公式に要求することなる。

 この要求を受けて、プロジェクト側はビジネス機能の要求とセキュリティの要求を同時に設計できるようになる。

図2:「Security by Design」と「DevSecOps」の継続ハードニングの導入によって積極的かつプロアクティブなアプリケーションセキュリティ強化は可能になる。

 この小さな変更は簡単のように聞こえるが、本格的な実現には十分な予算とマネジメントのトップのサポートが不可欠だ。このような経営層の強いコミットがなければプロジェクト側がキチンとしたアプリケーションセキュリティを実現ができない。

 セキュリティ品質の実現のためのコミットや組織レベルのマインドセットチェンジはハードルの高い最初のステップなので、これこそはマネジメントのトップの責任である。

「DevSecOps」の要求で継続ハードニング(CH)の導入

 「Security by Design」でも考慮すべきなのはアプリケーションセキュリティの効率性だ。セキュリティには終わりがないし、セキュリティ対応に銀の弾丸も存在しない。開発中でもリリース後でも、製品の全ライフサイクルにおいてアプリケーションの継続ハードニングは不可欠だ。アプリケーションセキュリティは容易ではないので、それを効率的に実現するのが「DevSecOps」の大事な役割だ。

 なぜ大事なのか?現状開発者がセキュリティにおいての知識と経験が少ないとよく言われている。しかし、仮の話だが、全ての開発者がセキュリティプロフェショナルの優れた知識と経験を持っているとしよう。全ての業務時間をセキュリティのために使用することを想像しよう。

 アプリケーションセキュリティの中には複雑な部分もあるし、実装するのはいくらプロフェショナルでも簡単ではない。セキュリティ知識が十分であっても、様々な理由(技術、フレームワーク、セキュリティ要件の解釈、プロジェクトの目的が異なる等)でセキュリティの実装レベルとその品質は異なる。大規模な事業体のITではそれにまして、各プロジェクトに異なるプロジェクトマネージャー、異なる開発者、異なるセキュリティ意識、異なるセキュリティ知識、異なるセキュリティ実装が存在するので、事業体全体を考えたセキュリティは成り立たない。そこで「エンタープライズセキュリティアーキテクチャ」という考え方は適切な選択肢のなめに必要になる。

 事業体のレベルで開発者をサポートする仕組みとツールも必要になる。セキュリティツール(SAST、DAST、IAST等)、調整するプロセス(DevOpsのオートメーション化、QA、エンタープライズアーキテクチャーの計画、ペンテスト等)、インフラにおける再利用できるセキュリティ機能(サービスプラットフォーム、WAF、RASP等)でアプリケーションセキュリティを包括的かつ効率的に実現できる。

理想的なアプローチとしてポスターには以下のステップをまとめた:

  1. ビジネス(スポンサー)側はアプリケーションセキュリティの予防的なアプローチを明確に要求する(適切な予算を含む)。
  2. 開発側はアプリケーションのための適切なセキュリティ設計を計画し、開発する。
  3. 運用側と開発側は共に、a)セキュリティハードニングを効率的に実装し、b)意図されたセキュリティ品質を維持するために継続的に協力する。

トップダウン:焦点は経営層のトップ

 なぜビジネス側はITセキュリティの現場に耳を傾けないのだろうか。セキュリティ強化はコストが掛かるし、プロジェクトの遅れも恐れられる。脅威が実現しない限り、無駄のように思われる。しかも、インシデントによるインパクトにかかるコストはセキュリティ強化の際に負担するコストより低いかもしれない。

 アカデミックな世間話に終わらせてしまわないために、ステークホルダーの中心人物を納得させる努力は必要だ。最初のステップはビジネス側の立場を理解し、ビジネスと具体的な脅威を議論するべきだ。確かにビジネスのトップはITの専門家ではないかもしれない。だが、ビジネス継続とその将来のための責任者なので、リスクとコストのバランスの舵取りをするのはプロフェショナルな立場としての経営層トップである。この立場と役割を果たしてもらうために適切で説得力のあるストーリーが必要である。

ビジネス側に「シフトレフト」の意味を納得してもらう

 製品の全ライフサイクルを意識するには経営層の長期的なアプローチが必要だ。「シフトレフト」というストーリーはそこにある。製品のリリース後、時間が経つと脆弱性によるリスクとその欠陥の修正コストの、両方が高くなる傾向がある。対策が遅れれば遅くれるほど大変になる。

図3:リアクティブなアプローチで、対策が遅れれば遅くれるほど大変になる。

 原因は様々な依存性にある(コード内の依存性、コード外の依存性、外部サービス、プロセスやステークホルダー等)。簡単なパッチで修正できるというラッキーな問題解決の場合もあるが、全アーキテクチャーを修正するための大規模なプロジェクト、ビジネスの継続のための問題解決が必要になる場合もある。

 アプリケーション・ライフサイクル全体においてデザインとテストの強化で運用効率をアップさせる思想が「シフトレフト」として知られている。左にシフトする作戦は、開発の時は修正コストが安いので、製品の品質向上とセキュリティの強化は開発中一番適切なステップである。積極的なテストで問題を速やかに捉えて修正することが大事である。

図4:スポンサーの「シフトレフト!」がプロアクティブなセキュリティ対策の出発点になる。

こちらのメッセージ:「シフトレフト」、「Security by Design」や「DevSecOps」を通してIT現場の状況を把握して機能させること!

 セキュリティデザインの問題を設計の時に解決し、コードの品質問題をコーディング中のハードニングに解決するのは言うまでもなく当たり前のことだ。リリース後の修正解決は遅くなれば遅くなるほどリスクとコストが増すばかりである。こういうことは物理の世界で製品の安全と品質改善においてよく理解されているのに、ソフトウエアの仮想の世界では逆になっている。

 デミング氏が提案したような品質改善の考え方ではなく、現在のICT業界ではタイム・トゥ・マケット(TTM)の方が評価されている。リアクティブなセキュリティ対策を中心としたICT業界に依存してきた他の業界の製品(IoT、自動車等)においても、顧客の安全と信頼を害する結果をもとらす恐れがある。

 経営層のトップへのメッセージは簡単だ。強力なサポートがなければ、積極的及び効率的なアプリケーションセキュリティ対策は不可能だ。「シフトレフト」、「Security by Design」や「DevSecOps」において現場の状況を十分把握するのが第一である。セキュリティに対する現場のモチベーションとセキュリティの実装が効果的であるかの確認、そして力強いコミットとサポートこそがトップ経営層のセキュリティへの貢献である。

ディパオロ・ロベルト (Author: Roberto Di Paolo)
Version 1.0 2018/5/3, last update 2018/5/4, ©ACROSEC Inc., All Rights Reserved.