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

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

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

ポスターの最新バーション（2021/9)のダウンロードページはこちらにクリックしてください。

このポスターは製品に対して中立的立場に立ったものであり、よりたくさんの方に共有していただくためにクリエイティブコモンズのライセンスの下で公開されています。

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

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

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

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

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」を追求した場合、リリーススピードが更に速められ、コストも更に削減するので、ビジネス側及びスポンサーが「DevOps」を大歓迎するというわけです。

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

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

こちらは開発手法を紹介するところではありませんが、話を理解する上で必要から、IT関係のプロフェショナルにとっては基礎知識とも言えるべき内容もポスターに記載しました。

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

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

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

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

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

脆弱性のないアプリケーションは存在するのでしょうか。脆弱性が明らかになった場合、一般的な組織で次におきることは批判の声が挙がることでしょう。しかしながら、セキュリティ品質において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等）です。これらによってアプリケーションセキュリティを包括的かつ効率的に実現できるようになります。

ポスターは理想的なアプローチとして以下のステップをまとめてあります：

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

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

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

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

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

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

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

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

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

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

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

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

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