アプリケーションセキュリティの課題が今ほど重要性を増したことは過去にありません。企業はどのようにAppSec に取り組んでいるのでしょうか？また、AppSecが十分に注目を集めるために、企業は何をすべきなのでしょうか？サイバーセキュリティサウナのEpisode 61では、日本で勤務するAntti Tuomi（アンティ・トゥオミ）と、フィンランドからAntti Vaha-Sipila（アンティ・ヴァハ・シピラ ニックネーム：AVS）に登場いただき、アプリケーションセキュリティの変遷、シフトレフト、開発者への支援、「レベルボステスト」などについて意見を交換しました。
Janne：二人はこれまでのキャリアを通じて、アプリケーション・セキュリティが組織の中でどのように捉えられ、組織としてどのようにアプローチする傾向なのかについて、どんな変化がありましたか？
Antti Vaha-Sipila (AVS): 私にとって興味深い傾向は、脅威モデリングの台頭です。10年前、企業のセキュリティ対策を調べた際、脅威モデルを活用していると答えた企業はほとんどありませんでした。しかし、今日では決して珍しいことではなくなりました。たとえば、私たちは脅威モデリングを行う大勢の人々を支援していますが、順調に推移しており、もはや稀なことではないのです。
プリンシパルセキュリティコンサルタントのAntti Vaha-Sipila（AVS)（左）とAntti Tuomi（右）
Antti Tuomi: AVSとこの話をしていて面白いと思ったことは、彼が開発組織の一員として、セキュリティと開発を両立させてきた経験を持っている点です。一方、私はこれまでセキュリティの分野では、主にセキュリティ監査やセキュリティテストを担当してきましたが、両者には大きな変化がありました。
2000年代後半、私がアプリケーション・セキュリティ業界に入ったばかりの頃、通常、お客様からのリクエストに応じてセキュリティ・テストを実施し、いくつかの脆弱性を発見しました。当時はこれが当たり前でした。もちろん、クロスサイトスクリプティングやSQLインジェクションなどは、すべて新しいものでした。
「これが結果です」という会議を開くと、たいていの場合、最初に「これは本当に問題なのですか」という意見が出ます。つまり、「SSLを導入しているので、このようなスクリプティングやインジェクションがあっても問題ないのでは？」、「データベースサーバーはイントラネットにあり、アクセスできないから悪用できないのではないか？」などと聞かれたのです。そのため、私たちは、セキュリティスタックのどの部分が、どの層のセキュリティをカバーしているのかを明確にしなければなりませんでした。
幸いなことに、この10年間、このような議論をした記憶はありません。この点については非常に満足しています。
私も「SQLインジェクションが問題だとしたら、なぜ人々はまだSQLを使っているのか？」と尋ねられたことがありましたが、きっと同じ頃だったに違いありません。このような会話が少なくなった今、企業はセキュリティの基本的な意味をより深く意識するようになったと感じますか？
Antti Tuomi: はい。そう感じています。ウイルス対策やファイアウォールだけでなく、アプリケーションの構築方法も含めた全体的なセキュリティ意識は、今では常識の一部になっており、ネットワークやエンドポイントに限らず、アプリケーションも保護すべきという認識が高まっていると思います。
Antti Vaha-Sipila (AVS): そのとおりですね。Anttiは最近そのような議論がなくなったと言っていましたが、その根本原因は単にセキュリティ意識の向上にあると考えていますか？それとも、フレームワークやアーキテクチャがより安全になってきたからでしょうか？
Antti Tuomi: それはとても良い指摘ですね。フレームワークやさまざまなものが大きな役割を果たしているという示唆は正しいと思います。たとえば、2000年代後半から2010年代初頭にかけてのWebアプリケーション開発言語やフレームワークを考えてみると、いまだにPHPで書かれたアプリケーションがたくさんあります。ただのバニラ（改変・改修・カスタマイズなどが一切行われていない ）PHPでです。もしSQLインジェクションが問題であることを知らなかったら、どうやってそれらを防ぐのでしょうか？
近頃は、最新のMVCフレームワークの上にORM層があるので、インジェクションの脆弱性を書いてしまうことは、通常の安全なクエリを書くことよりも実は難しいです。ですから、AVSの言うとおりだと思います。
Antti Vaha-Sipila (AVS):
私がこの質問をした理由は、今見ている大きなトレンドや変化として、特にまったく新しいことをする時のグリーンフィールド開発において、クラウドネイティブアーキテクチャになる傾向があり、マイクロサービスアーキテクチャでさえも多くのAPIを目にしているからです。
APIは受け入れられるものがはるかに制限されているため、セキュリティ上のメリットが大きいと思います。たとえば、もはやサーバー側でページを構築する必要がなくなりました。私の見方では、それが現状に大きく貢献していると思います。
では、このようなフレームワークや新しい作業方法によって、ソフトウェアの設計段階からセキュリティを組み込むことが以前よりも容易になっているのでしょうか？
Antti Tuomi: 必ずしもセキュア・バイ・デザインであるとは限りませんが、セキュリティの基本層やプレミスが抽象化されていることが多いです。平均的な開発者は、2021年のMVCフレームワークとORMフレームワークを使ってSQLクエリをどのように書けばよいのか、どのような結合をすればよいのか、といったことは考える必要がありません。その代わりに、コード内のオブジェクトをクエリするだけで済みます。
つまり内部に触れる必要はまったくないのです。これは内部を間違った方法で触らないようにすることにも大変役立ちます。
Antti Vaha-Sipila (AVS): マイクロサービスの手法でアーキテクチャを展開している場合、たとえばデータベースは、単一のマイクロサービスが所有してその機能を実行するだけになります。データベースは、形式の整ったクエリやHTTP、JSONに応答するだけで、それ以上の複雑なことは何もしません。たとえ誰かがアプリケーションを侵害したとしても、同じ筐体にあるデータベースへのアクセスをエスカレートさせることはできないでしょう。
ある意味、設計を通したセキュリティのようなものですが、セキュリティは新しい設計による多くの副産物の1つだと思います。つまり、必ずしもそれが主目的で設計されていたわけではないのです。
わかりました。では、企業がセキュア・バイ・デザインを実現するのは、まだ先のことだとお考えですか？
Antti Tuomi:
そのとおりだと思います。
Antti Vaha-Sipila (AVS):
堅牢なアーキテクチャができたからといって、それをセキュア・バイ・デザインと呼ぶとしたら、言ったもの勝ちのようなものでしょう。
（笑）そうでしょうね。
Antti Tuomi: 2000年代の後半、当時OWASP Top 10はかなり新しいプロジェクトでした。私の記憶が正しければ、初版は2004年、次の版は2007年に発行されていたと思います。当時から変化したことや、変化しなかったことを考えると、興味深いことにOWASP Top 10は今でもまったく時代遅れではないということです。特に日本やヨーロッパでは、「当社のアプリケーションにOWASP Top 10の脆弱性があるかどうかをテストして欲しい」という依頼が今でもよく舞い込んできます。
このように、OWASP Top 10という基準は生きていて、少しずつ変化しています。しかし、基本的な前提は依然として存在しており、非常に似通った、あるいは同じ脆弱性カテゴリが数多くあります。それはまだ基本リソースの1つなのです。したがって、OWASP Top 10の脆弱性があるかどうかは、今でも私たちが知りたいことなのです。
数年前、ブラックハットのプレゼンテーションで、開発者の5人に1人がOWASP Top 10を知らないという調査データが紹介されました。あなた方の経験からは、妥当なデータだと思われますか？最近の開発者のセキュリティ知識レベルはどうでしょうか？
Antti Tuomi: 私のヨーロッパでの経験から言うと、2010年代以降、ほとんどの開発者はすでにOWASP Top 10に精通していたと思います。ここ10年ほどは、OWASP Top 10を誰かに説明したことは記憶に有りませんが、日本では、今でもアプリケーション・セキュリティの基礎としてよく知られているようです。
しかし一方で、お客様がOWASP Top 10のことを気にし過ぎるあまり、それ以上のことを忘れてしまうケースが多いこともわかっています。たとえば、XML外部エンティティは、必ずしも直接OWASPカテゴリの一部に含まれていたわけではありません。そして多くの場合、それが本当に探すべきものであることを忘れているようです。ですから、OWASP Top 10以外のものがもっとあるのです。
Antti Vaha-Sipila (AVS): OWASP Top 10は広範囲に一般化されています。つまり、もし、それぞれの企業が持つ脆弱性の種類に着目すると、すべての企業がそれぞれ若干違ったTop 10を持っていることがわかります。
私が2011年に、某ソフトウェア企業のAppSecの一員として勤務し始めたとき、最初にしたことは、過去3年間のすべてのセキュリティレポートを入手して目を通すことでした。そして、見つけたことをすべて分類し、その会社で見られる欠陥やバグの種類を把握しました。その結果、OWASP Top 10に入るようなものはなかったと言わざるを得ません。たとえば、データベースインジェクションはまったくありませんでした。ほとんどはその会社が採用したアーキテクチャに起因していました。
Antti Tuomi: つまり、銀行のTop 10は、ITサービスプロバイダのTop 10とは違うということですね?
Antti Vaha-Sipila (AVS): そのとおりです。さらに、たとえ同じ業界内であっても、企業や選択したアーキテクチャ、ソフトウェアスタックの種類によって異なります。昔ながらのPHPを使えば、非常に成熟したフレームワークを使う場合よりも、さまざまな種類の攻撃に対して脆弱になります。
ですから、その重要性はともかく、開発者がOWASP Top 10を知っていなければならないことは確かです。開発者は、自身のアーキテクチャやスタックの種類に特有のリスクが何であるかを知る必要があります。
なるほど。自分の組織の状況を正確に把握していれば、それに越したことはないでしょう。しかし、出発点がまったくないのであれば、OWASP Top 10は何もないよりはましだと思います。その会社固有の情報がない場合は、OWASP Top 10から始めるとよいでしょうね。
Antti Tuomi: OWASPはよく知られているとは思いますが…、AVSは、最近特にセキュリティ意識の高い企業が参照しているような、他の類似した資料をヨーロッパで見聞きしたことがありますか?
Antti Vaha-Sipila (AVS): トラック開発プロセスを辿る早い段階でセキュリティを統合しようとしている企業の多くは、ソフトウェア成熟度モデルについて話しています。OWASP SAMMがその一例です。現在のバージョンは以前ほど悪くはありません。おそらく、Synopsys（旧Cigital）のBSIMMモデルのほうがよく知られています。最近、ソフトウェア成熟度モデルの話をすると、企業が実際に言及するのはこれらのモデルだと思います。
Antti Tuomi: それは興味深いですね。最近、AWSクラウドインフラストラクチャなどを利用して、完全なDevOpsサイクルを実行しているモダンアプリケーション開発者と話をすると、「DevOpsパイプラインを安全にするためには、何をすべきなのでしょうか?」とよく聞かれます。だから私は、OWASP Top 10ではなく, DevOps Top 10のような、やるべきこととやってはいけないことのリストが出るのはいつ頃だろうかと思っています。
Antti Vaha-Sipila (AVS): 実は、少なくとも3社の企業のマーケティング資料には、すでにそのリストがあると思います。それはツールがあればできることのように聞こえます。
（笑）なるほど。しかし、OWASPは依然として最も広く知られていますし、今年発表された新しいTop 10リストには、いくつかの変更が加えられています。そのリストの新しい項目について、お二人はどう思いますか？私が特に気に入っているのは、安全でない設計という項目です。
Antti Vaha-Sipila (AVS): そうですね、ツールについて言えば、OWASP Top 10は、自動化ツールによって発見されたことを分類する目的で使用されてきたのです。だから自動化ツールには頑張って欲しいですね。
（笑）そうですね。
Antti Tuomi: そのとおりです。しかし、私はこのカテゴリこそ、安全でない設計に分類されると思います。たとえば、AWSクラウドインフラストラクチャで内部のVPCを露出したり、S3バケットを外部のユーザに露出することは、安全でない設計や、安全でない構成に該当する可能性があります。これがリストに載っていることは間違いないのですが、それをどうやってチェックするのでしょう？どのように評価するのでしょう？どうやって修復するのでしょう？もっと良い設計をするべきです。
はい。包括的なカテゴリとして、セキュリティ上の失敗の主な理由は人為的なミスですね。
Antti Tuomi: 確かに。
Antti Vaha-Sipila (AVS): それを運用でカバーするのは非常に難しいです。プライバシーやデータ保護の面では、チェックリストが数多くあります。個人データを安全に処理するには、あれをやって、これをやって、それから最後に、規制に準拠して、というようなことです。
よくわかりました。アプリケーションに関して、最も多く観測される問題は何ですか？個人的なトップ10は何でしょうか?
Antti Tuomi: ここ5年ほど、つまり2015年以来続いている傾向として感じるのは、技術的な脆弱性を見つけることがますます難しくなっているということです。特に、従来のクロスサイトスクリプティングやSQLインジェクションなどの脆弱性に関してはそれが当てはまっています。これには、そこで使われているフレームワークが原因である可能性が高いです。
しかし、私が個人的に考えている傾向の1つは、アクセス制御に関連する問題です。たとえば、他のユーザのデータを見ることができたり、APIリクエストのパラメータを変更できたり、本来はアクセスできないはずの機能やデータにアクセスできてしまう問題です。この問題は依然として普通に見かけます。
そして、もちろん、いわゆるビジネスロジックの脆弱性もあります。つまり、決済ステップをスキップして商品を入手するようなことです。このように、予想もしない方法でアプリケーションフローを利用することも、まだかなり一般的に行われています。
その一方で興味深いのは、アプリケーションインフラストラクチャに関して、開発組織はどのような問題に悩んでいるか、ということです。AVS、開発者やプロダクトオーナーが不意を突かれるような脅威にはどのような種類があるのでしょうか？
Antti Vaha-Sipila (AVS): サプライチェーンの問題は本当に深刻だと思います。脅威モデリングを行っていると、実装レベルの問題ではなく、アーキテクチャや設計レベルの問題が多く見つかる傾向があります。ユースケースの脅威モデリングを過去にさかのぼって行わない限り、バグが見つかる事態になります。
バグが見つかる典型的なパターンとしては、あるコンポーネントが特定の方法で動作すると思っていたり、信頼できるソースから提供されていると思っていたのに、実際にはそうではないことがあります。それが少なくともセキュリティ上の問題、あるいは潜在的な弱点を生む原因になります。
Antti Tuomi: それは、例えば、「依存関係かく乱攻撃」のことですか？
Antti Vaha-Sipila (AVS): それも1つの攻撃タイプです。また、APIを呼び出すときには、そのAPIが入力に対してどのような前提条件を設定しているのか、そのAPIが送り返すデータは本当に信用できるのか、といったこともあります。たとえば、内部のAPIからの応答であっても、それを検証しなければならないのは、あなたが最初かもしれません。これまでに誰もデータを検証していない可能性があるからです。
OWASP Top 10にリストされているような技術的な脆弱性に触れる必要はほとんどありませんでした。しかし、今ではOWASP Top 10に設計レベルの問題も含まれていることから、私たちがOWASP Top 10にも取り組んでいると言えるのは明らかです。
先ほど、OWASP Top 10テストの自動化について触れましたが、これは確かに業界で見られるトレンドで、人がソリューションごとにテストを作成するのではなく、アプリケーションテストのコモディティ化と自動化に向かっていると思います。その点についてお二人はどう思いますか？また、機械は人間ほど適応力がないという懸念もあるかと思います。その点は問題になるでしょうか?
Antti Tuomi: それについては、とても興味深い文化的あるいは地域的な逸話がいくつかあります。日本の文化について言えば、品質やセキュリティテストを含むテストに期待されることは、事前に明確に定義され再現可能であるということです。実際、私たちのようなセキュリティテスターにも期待されていることがあるのです。
テストを定義できて、最終目標と明確に定義されたテストケースがあれば、テストを自動化できます。自動化できるテストはすべて自動化すべきという意味で、これは非常に良い目標だと思います。なぜなら、自動化は繰り返しが可能で、実行時にミスを犯す可能性が低いからです。
しかし同時に、セキュリティは例外を扱うものだと思います。ルールの例外に関して言えば、すべてのテストケースを網羅するためには、数え切れないほどのテストケースを実行しなければなりません。そのためにはまず、安全でない設計をどうやってテストするのかを定義する必要があります。そのための一連のテストケースをどうやって明確に定義すればよいのでしょうか？しかし、それはできないでしょう。
その意味で、自動化に向けて努力することは非常に良いことですが、それでもこのような探索的テストや、専門家によるレビューといった作業も必要になると思います。
Antti Vaha-Sipila (AVS): Antti、私たちは先日文化の違いについて議論しましたが、企業が探索的セキュリティテストを行うべきだと考えている点は興味深いことですね。
Antti Tuomi: まったくそのとおりです。日本で企業からセキュリティテストの見積もりを求められた場合、「私たちは通常、ビジネスロジックの脆弱性やアクセス率などのテストも行いますと答えています」。すると、中には驚かれるお客様もいらっしゃいます。なぜならば、それ自体をセキュリティの一部だとは考えていないからです。それは探索的テストの一部であり、品質保証チームが責任を持って検証すべきものだと考えているのです。
Antti Vaha-Sipila (AVS): しかし、その考えはある種の理想的な世界だと思います。
Antti Tuomi: そうですね。AVSの言うとおりだと思います。一部のお客様は、セキュリティとは技術的なセキュリティ問題や技術的な構成に関することであって、アクセス権や機能、探索的テストはすべて品質保証の範囲であると考えています。
AVSが言ったように、理想的な世界ではそうであるべきです。しかし、それは私がこの5年間、日本に住んでいて発見した、非常に興味深い文化の違いなのです。
Antti Vaha-Sipila (AVS): そうですね。その話を聞きたかったのは、将来が見通せないからですが、セキュリティテストは、CI/CDパイプラインで行う必要があるような自動化された高速テストへ、そして探索的ビジネスロジックタイプのテストへと、少し方向転換しなければならないような気がしています。
そのようなテストを実際に行うことができるQA組織があれば、それは素晴らしいことだと思います。なぜなら、彼らはソフトウェアのビジネスロジックを最もよく理解しているからです。たとえば、脅威モデリングにおいて探索的QAを行っている企業では、システムの難解なリスクを発見するためにはQAの人材が適任です。
Antti Tuomi: 私も大歓迎です。私たちセキュリティテスターが自分で脅威モデリングを行って、攻撃シナリオを作成する状況と比較したとしましょう。その一部はロジックに関連し、一部はテクノロジーに関連しています。
そして、もし私がアプリケーションのテストを始めることができ、QAチームとセッションを行うと、「脅威モデリングでは、決済プロセスでこのステップをスキップできたり、この情報にアクセスできる問題があることがわかりました。私たちは、既にこれらの仕組みをすべて試しました」とQAチームから言われることでしょう。
それは私にとっても非常に貴重な情報になります。私は彼らの結果を裏付けるだけで済みますし、彼らが考え出した探索的テストケースを試してもらえるように、技術的な方法を加えることができるでしょう。それができれば本当に嬉しいですね。
Antti Vaha-Sipila (AVS): 通常、QA担当者は規制要件についてよく知っています。開発者は一般的な要件については知っていますが、特定のタイプの企業においては、QAチームの方が、何かに準拠するために実際に必要なことについて、より正確な知識を持っているでしょう。
Antti Tuomi: 確かに。
Antti Vaha-Sipila (AVS): 彼らは、セキュリティバグの連鎖的な影響や、それがコンプライアンスの状況へどのように影響するかを知ることができます。
Antti Tuomi: AVSと同じように、私も開発組織向けに脅威モデリングのワークショップを何回か実施しました。開発チームの皆さんは、技術的に非常に良い意見を言ってくれることが多いと思います。たとえば、このAPIメッセージやコンテンツが変更されたらどうなるか？この実装が間違っていたらどうなるのか？などと言ってくれます。
しかし、開発チームがいくつかの例を挙げて脅威モデリングを始めたときに、年配のQA担当者が、「問題が起こるとしたらどのような問題か考えてください。」と促してくれることがよくあります。このような人たちは、発言するチャンスさえ与えられたら、他の誰も思いつかないような素晴らしい脅威のシナリオを教えてくれることが多いのです。技術者さえも考えつかなかったことをです。それが脅威モデリングの最中であろうと、トレーニングや実際のセッション中であろうと、そのような考えが披露されるのは常に素晴らしい瞬間です。
Antti Vaha-Sipila (AVS): そうですね。それではテスト自動化に関するJanneの最初の質問に戻りましょう。
ありがとうございます。
Antti Vaha-Sipila (AVS): 現在のトレンドとして、継続的デリバリー、つまり本質的にはコードが完了した後に自動的に本番環境にデプロイされているのであれば、継続的テストというものも必要になると思います。
少し前から、ガードレールという言葉が流行っています。ファネルの両側にガードレールを設置します。パイプラインの中を非常に高速で進んでいるため、まっすぐ進むためにはガードレールを設置する必要があるというアイデアです。開発のスピードが非常に速く、継続的に本番環境にデプロイする必要がある場合、ミスをしても本番環境を壊さないように、自動化でカバーするという考え方です。
たとえば、クラウド環境はTerraformコードで定義されます。基本的にはたった1つのコミットで本番環境全体を壊すことができてしまいます。そのため、健全性チェックやセキュリティチェックが欠かせません。
自動テストの焦点は、中期的にはそちらに移っていくと思いますので、健全性チェックを行い、簡単な作業は削減するツールが求められます。
Antti Tuomi: そうですね。純粋なアプリケーションレベルの脆弱性を除いて、私が最近目撃した2番目に大きな脆弱性のカテゴリは、Infrastructure as a Serviceクラウドプラットフォームの設定ミスによって引き起こされた脆弱性です。つまりこれらはすべて露出したバケットやその他のタイプの問題です。
最近、Infrastructure-as-Codeのデプロイでも、このような構成上の問題や脆弱性を自動的に検出するツールについての記事を目にしました。
このように、新しいセキュリティ対策が登場しているだけでなく、セキュリティとソフトウェアで以前から行ってきた対策が、ライフサイクルの中でこれまでとは異なる場所で行われるようになっています。
Antti Tuomi: そのとおりだと思います。特に、アンチウイルスやファイアウォールはなくなったわけではなく、今も存在していますが、私たちはそれらに慣れすぎていますが、もっと注意を払うべきです。
また、他の多くのアプリケーションセキュリティのタスクも、一般的な知識となり、実行することに慣れてしまっています。間違いなくそれらはまだ存在しますが、リリースサイクルの最後にテストするのではなく、今では少し前の段階でテストしている可能性があります。AVSは、この最後のテストのことをうまい言葉で表現していましたね。
Antti Vaha-Sipila (AVS): サイクルの最後に行うテストのことを、私は「レベルボステスト」と呼んでいました。昔のシューティングゲームを思い出してみてください。各レベルの最後に強敵がいて、それをクリアしないと先に進めませんでした。
Antti Tuomi: そうでした。「レイドボス」や「レベルボス」ですね。もしセキュリティテストで失敗したら、開発段階に立ち戻ることになりますね。
Antti Vaha-Sipila (AVS): そのとおりです。
お二人は、一般的にセキュリティのレフトシフトと呼ばれているトレンドについて話していますね。それはどのような意味なのですか？
Antti Vaha-Sipila (AVS): 企業によって、その意味合いは異なるでしょう。特にDevSecOpsを目指している企業であれば、デプロイ前にちょっとしたツールを追加することかもしれません。つまり、デプロイするたびに、いわばレベルボスの牙城に到達する前にテストを行うということです。
言い忘れましたが、レフトとは時間軸での左側を意味しています。さらに左に行くこともできます。たとえば、設計をする前に脅威モデリングを行う場合、それはさらに一歩左に向かうことになりますし、プロダクトマネジメントの前にすれば、もっと左に移ったことになります。もし、製品企画やビジネス価値の拡大について検討している時点でセキュリティの取組みをすれば、時間軸的には限りなく左に向かうことになります。
組織には左翼的な部分があるように思います。
(笑）そうきましたか。要するに、セキュリティをソフトウェアの設計や開発のライフサイクルの初期段階に移すということですね。
Antti Vaha-Sipila (AVS): そうです。
Antti Tuomi: 自動化を追加したり、テストにセキュリティ関連のテストケースを追加したり、あるいは脅威モデリングを追加することでしたら、多くの人がよく知っていることだと思います。一方で、AVS、製品設計やビジネス上の意思決定の段階となると、どのようにセキュリティに影響を与えることができるのか、いくつか例を挙げてもらえますか？
Antti Vaha-Sipila (AVS): プライバシーやデータ保護については、早い段階で重要なことを実行できるので、良い例になると思います。つまり、アプリケーションが従うべき規制や法律に準拠しているかどうかを判断する必要がある場合、その議論は早い段階で行われるに越したことはないでしょう。なぜなら、時間をかけて開発したものが、実は違法なアプリケーションだったことが分ったとしたら、議論する時期を誤ったことになりますよね？
そうですね。
Antti Vaha-Sipila (AVS): その議論をする時期を広げればよいのです。たとえば、GDPRで義務付けられているプライバシーやデータ保護への影響の評価を行う場合は、最初の設計に関する議論にこの話題を追加します。
私が実際に目にしたことですが、個人データを保存するレガシーバックエンドがありました。そして、そのデータベースに登録されている人々を何らかの方法でインデックス化する必要があります。ここフィンランドでは、社会保障番号、あるいは個人ID番号と呼ばれる番号を使ってインデックスを作成するのが一般的です。しかし、これは固有の識別子であり、ランダムではありません。もしそれが漏洩すると困ったことになります。なぜなら、それを使用して、他のさまざまなサービスでも同じ人物をインデックスできるからです。
たとえば、設計上の判断として、レガシーバックエンドを変更して、アプリケーション固有のユニークでランダムな識別子を導入し、この文脈で使用できるようにします。こうすればインデックス作成のために個人ID番号を使用する必要がなくなります。しかし、そのためには、新しいアプリケーションだけでなく、レガシーアプリケーションにも変更を加えなければなりません。
これにはリードタイムがかかるので、このような方法論は、ビジネスの議論の中ですでに提起されている方がはるかに良いでしょう。
Antti Tuomi: セキュリティアーキテクチャに若干の先見性があれば、今後の多くのトラブルを回避することができるということですね。
Antti Vaha-Sipila (AVS): そのとおりです。このケースでは、ほとんどが情報アーキテクチャレベルでの決断になります。
それは理にかなっていると思います。しかし、セキュリティをレフトシフトするのは、言うは易く行うは難しでは？それとも組織はうまく対処しているのでしょうか?
Antti Vaha-Sipila (AVS): それは企業文化に依存します。セキュリティ部門だけがセキュリティを時間軸の左端に移したいと考えるのではなく、製品開発組織も協力したいと思う必要があります。
まだ多くの企業では、セキュリティ部門は製品開発組織とは分離されています。通常、セキュリティ部門はITセキュリティ部門から発展し独立したものであり、そもそもITはサポート部門としてスタートしています。ですから、製品管理組織の賛同を得られなければ、レフトシフトを効果的に進めることはできません。
多くの企業では、デプロイメントパイプラインの一番最後から始めて、自動化などを導入することでレフトシフト的な活動を始めています。それなら開発チーム自身が行うことも、皆に共通ツールを提供するプラットフォームサポートチームが行うこともできるからです。また、組織を大幅に刷新する必要もありません。
Antti Tuomi: そう言われてみれば、ここにも非常に興味深い文化的側面がいくつかあります。私が個人的に見てきたことの1つは、アプリケーションセキュリティに関して、レフトシフトの最大の牽引力は、良い意味でも悪い意味でも、アプリケーションをデプロイしたり公開したりする際のタイムラインです。
レベルボスに敗退することを避けるには、振り出しに戻って脆弱なアプリケーションを公開するか、タイムラインを先延ばしするかの決断をしなければなりません。ビジネスにとっての悪影響は免れません。地平線に出現するレベルボスを見ると、どこが安全な場所か様子が掴めますね。そこから何かを始めるべきでしょう。
このように、セキュリティがビジネスに悪影響を与えることに対する恐怖感は、それが健全か不健全かに関わらず、できるだけ早期にセキュリティに取り組もうとする原動力になります。多くの組織が気づいていると思いますが、予定通りにデプロイする準備が確実にできるようにするために、早い段階で実行できるセキュリティタスクはありますか？
まったく同感です。しかし、私たちは、開発者が安全なソフトウェアを構築できるようにするために、十分な支援をしていると思いますか？それとも、他の機能と同じように、安全にした方が良いですよ、と言っているだけなのでしょうか？
Antti Vaha-Sipila (AVS):
そうですね。これは私が強く感じていることなのですが、絶対にしてはいけないことは、開発者に「あなたはこうすべきだ」と言いうことです。組織が物事を適切に行うためには、インセンティブと、特にそのための時間を配分することが必要だと思います。
したがって、私が注目しているのは開発者ではなく、プロダクトマネジメントやプロダクトオーナーなど、リソースを所有するすべての人々です。
Antti Tuomi: それは企業文化とも密接に関係しています。私が指摘したかったもう1つの文化的な違いは、残念なことに多くの日本の企業には、未だに専任のCISOや、セキュリティオフィサー、あるいはITセキュリティやセキュリティチームのような専任組織がないということです。一般的なのは、ログを監視したり、IDSデバイスやエンドポイントプロテクションなどからのアラートを監視するセキュリティオペレーションセンターが存在していることです。
しかし、アプリケーションセキュリティについてアドバイスできるような包括的なチームが、多くの組織に存在するとは限りません。むしろ、セキュリティ要件や対応は、実際には開発組織の責任になっていることが多いのです。
頼りになるセキュリティ部門がないことは、決して良いことではありません。しかし同時に、開発組織は、いつどのようにしてセキュリティをタスクに組み込むかについて、より多くの意見を持っている可能性があります。これは興味深い文化の違いです。
その結果、面白いことに、セキュリティが開発組織に委ねられている場合、セキュリティに情熱を持っていたり、才能があったり、あるいはセキュリティについて学んで興味を惹かれた人がいれば、これらの人々が開発プロセスのセキュリティ部分を前進させることができるのです。そして、それが非常に良い結果を生むことが多いと思います。
Antti Vaha-Sipila (AVS): 私が知っている多くの企業では、セキュリティチャンピオンプログラムのようなものがあります。そこでは、ボランティア、開発者、時にはスクラムマスターのようなタイプの人がいて、セキュリティに真剣に取り組み、その炎を燃やし続けたいと思っています。
興味深いことに、あるシニアQA担当者に話を聞いたところ、彼は通常のQAと同様にセキュリティテストを行えるよう任務を拡大することに興味があると語っていました。セキュリティに興味があるからという理由でなく、たまにはいつもと違うことをしてみたいと思っているようです。数年間も同じ職務のことばかり考えていると、たまには敵対的な見方で物事を考えることで、とても心が解放されるのです。
Antti Tuomi: これは組織にとっても非常に有益です。社外のセキュリティテスターに任せると、決まった時間にやって来て料金を請求するからです。その代わりに、社内の従業員にこの活動に参加してもらい、セキュリティに興味を持たせることができれば、才能を持ったチャンピオンを輩出することができるのです。それは関係者全員にとってメリットがあると思います。
Antti Vaha-Sipila (AVS): そうですね。組織内の人たちをもう少し広範に見てみましょう。開発者である必要はありません。Janneのポッドキャストを聞くのが好きなスクラムマスターなら、必要としている信頼できる人材かもしれませんよ。
私たちはそういう人たちが好きですね。
Antti Vaha-Sipila (AVS): 社内のセキュリティ担当者として、ソフトウェアが満たすべきセキュリティ以外の品質を十分に理解しているとすれば、とても健全だと思います。たとえば、パフォーマンス、コスト、実装にかかる時間などです。
商用ソフトウェアの開発経験がないセキュリティ担当者は、小さな変更を加えることがどれほど難しいかをすぐには理解できないかもしれません。つまり、15分でできる仕事であっても、煩雑で余計な手続きやテスト、その他すべてのことが複合的に影響してくるのです。
ですから、社内のセキュリティ部門には、何らかの形でソフトウェア開発の経験がある人材を配置すべきだと思います。
Antti Tuomi: そうですね。また、技術的なセキュリティに情熱を持った人や専門家が最初に脆弱性を発見したとき、「これは単純なミスだ。なぜこんなミスをしたのだろう。」と感じてしまうこともよくあると思います。
しかし、実際の理由は、開発チームに時間やリソースが不足していたり、脆弱性があることを知っていたにもかかわらず、アプリケーションが公開されてしまうことだってあるのです。
実際にはあってはならないことですが、敵対的な感情やアプローチを生みやすいことがたくさんあります。
Antti Vaha-Sipila (AVS): そうですね。私の考えでは、ほとんどの場合、最初からすべてを稼働させることよりも、セキュリティバグを見つける方がはるかに簡単だということを常に念頭に置いておく必要があります。ソフトウェア開発者が行っている仕事は、私が現在行っている仕事よりもずっと難しいと思います。
私がクライアントにいつも言っていることですが、私たちはセキュリティだけを考えていればよいのですが、開発者は機能性や使いやすさなど、二次的なことや、些細なことにも気を配らなければなりません。
Antti Tuomi: そうなのです。たとえば、最新バージョンのChromeで動作するのか？最新バージョンのInternet Explorerでも動作するのか？LGやSamsungのスマートテレビではどうか？今ではXboxのブラウザーでWebゲームをプレイできるか？など配慮すべきことは多数あります。
さて、今回の議論を締めくくるにあたり、お二人にお聞きしたいのですが、組織との仕事の中で、何度も繰り返しアドバイスしていることがありますか？たとえば、アプリケーションセキュリティについて人々に覚えておいて欲しいことは何ですか?
Antti Vaha-Sipila (AVS): その質問に答えるのは簡単です。私が話をしているほとんどすべての組織で、最後はいつも同じことを説いています。それは、時間が与えられなければ、セキュリティの仕事はできないということです。
Antti Tuomi: それはとても良い指摘です。
Antti Vaha-Sipila (AVS): つまり明確に時間を割り当てることが必要なのです。終わらせることにこだわって、着地点をうろついているだけではいけません。
Antti Tuomi: たとえば、アーキテクチャのダイアグラムがあって、そこにはたくさんの線が描かれていますが、その中で完全に切り離された「セキュリティ」というボックスがあるようなものです。
セキュリティも仲間に入れてあげてください。
Antti Tuomi: そうですね。
Antti Vaha-Sipila (AVS): PCのモニターに「セキュリティを忘れずに」と書いた付箋を貼っておいても意味はありません。明確に時間を割り当てることが必要なのです。ほとんどの組織に求められることは、他の開発活動と同じように、セキュリティもバックログに記録する必要があると言うことです。それを実行する方法は、必ずしも簡単ではありません。なぜなら。。。
Antti Tuomi: それが私の次の質問でした。
Antti Vaha-Sipila (AVS): なぜなら、そのためには、プロダクトマネジメントや、直属のプロダクトオーナーよりもさらに上のレベルで賛同を得る必要があるからです。たとえば、CI/CDパイプラインを超えて、レフトシフトのステップを踏み出すことになります。これが時間の割り当ての問題なのです。
Antti Tuomi: セキュリティは取締役会で企画されるべきものでしょうか? それとも、セキュリティは個々のタスクに組み込むべきものでしょうか？
Antti、その話だけでエピソードが1つできるので、また別の日にしましょう。組織へのアドバイスはありますか?
Antti Tuomi: それは本当に難しい質問で、私には良い答えはありません。組織や悩んでいる部分に依存しますからね。私の経験から言えることは、セキュリティを単なるコンプライアンスの問題として捉えるのではなく、設計や実装の段階でセキュリティを積極的に支持してくれる社内の人材を見つけた企業や組織は、最終的に修正すべき問題が最も少なく、修正するための時間と予算を確保できているのだと思います。
なるほど。それでは、今日のポッドキャストに出演していただき、AppSecというジャングルの中を案内してくれたお二人に感謝したいと思います。
Antti Vaha-Sipila (AVS): ありがとうございました。とても楽しかったです。
Antti Tuomi: Janne、AVS、ありがとうございました。
カテゴリ