前回に続いて、アスタリスク・リサーチ社長の岡田良太郎氏とユービーセキュア社長の観堂剛太郎氏の対談をお届けします！

スピードを求められるDX時代、システム開発はどうあるべきか、セキュリティ確保のためには何が必要か、そしてセキュリティベンダーに求められるものは！？大真面目に？アツいトークを繰り広げていただきました！

株式会社アスタリスク・リサーチ　代表取締役社長　岡田良太郎氏

2006年、アスタリスク・リサーチ創業。同社では、アプリケーションセキュリティ・ガバナンスにかかわるリサーチとサービスを展開。また、公益的な活動としてOWASP Japanチャプターリーダやビジネスブレークスルー大学の非常勤講師を務め技術と人材の育成に携わる。

株式会社ユービーセキュア　代表取締役社長　観堂剛太郎氏

アプリケーション開発ベンダで開発に従事し、2000年のNRIセキュア創業年度に合流。セキュアプロダクトの開発を経て、脆弱性診断やインシデント対応等のテクニカルコンサルテーションを担当。2017年7月より、ユービーセキュアの代表取締役に就任。

これからは「DevSecOps」の仕組みを構築することが求められる

岡田：リリース前の最終テストはもちろんですが、Webアプリケーションの脆弱性は日々、発見されています。リリース後の運用の仕組みの中にVexを活用することもできますよね。

観堂：継続的にアップデートされていくシステムについては、日々、新しいセキュリティリスクが生まれていないかどうか確認することが望まれます。もちろん、そういう仕組みにもVexは活用できます。

岡田：DevSecOpsとも言われますが、継続的デリバリーを支援するために開発、セキュリティプロセス、運用を融合する取り組みがうまく回っているお客さまはいますか。

観堂：実際の現場でDevSecOpsが既にできあがっており、うまく機能しているというお客さまはまだまだ少ないと思います。一方、旧来のゲートウェイ型が主流だが、なんとか開発の枠組の中にセキュリティプロセスを組み込みたいという志向を持っているお客さまは増えていると感じますね。その背景にあるのが、やはり、開発の流れがどんどん速くなっていることだと思います。CI/CDツールと脆弱性検査ツールを連携する仕組みをつくる企業が増えているのもその一つ。そういった環境構築を目指してPOCをするので最適なツールを教えてほしい、という相談も増えてきています。

岡田：現状の開発スキームに検査ツールを組み込んで、簡単な脆弱性なら開発作業を行っている中で自動的に検出できる仕組みをつくる動きがあるのはすばらしいことだと思います。開発の人たちが助かります。

観堂：検査ツールによって特徴がありますので、それぞれを最適なタイミングで回せる仕組みを構築する。さらに一歩進んで、それら複数のツールから検出された脆弱性を1カ所に集めて相関的に分析したり、トリアージするような仕組みを検討しているお客様もいます。ツールで検出される脆弱性はグレーな状態なので、白か黒か、つまり過検知/誤検知の仕分けや、実際に致命的な影響を与える可能性があるのかを判別し、修正スキームに上げる必要があります。ここを現実的に運用できるようにしないと、グレーな脆弱性情報の蓄積だけになってしまう。

岡田：せっかく動いているんだから、「寝た子を起こすな」という思考になってしまい、継続的なセキュリティチェックが行われなくなることもありそうです。そういう現場では、セキュリティテストは開発工程でも、問題を指摘されるのは嫌でしょうね。手を出すのが怖いのかもしれない。しかし、今動いているシステムがどういう状況にあるのかを知るための手立てを持つことはすごく大事だと思うんですよ。

現状のシステムの情報に関するインプットがあれば、次の開発のフォーカスが決まります。そのための情報として、本番環境で動いているシステムのセキュリティチェックをする概念を持つことは非常に有効です。

つまり、システム開発のPDCAサイクルが回っている前提においては、最上流工程は要件定義ではなく運用中のシステムのモニタリングだと考えています。

アスタリスク・リサーチの考える「セキュアな開発・運用のためのフレームワーク」

設計ミスで起こった脆弱性は誰が見つけるのか

岡田：ところで、最近のホットなセキュリティトピックスについて、観堂さんはどのようなものを挙げられますか。

観堂：昨年夏に起こったペイメントサービスにおける事件ですね。これは診断サービスベンダーと、受診するユーザ企業の双方に課題を突きつけるものだったんじゃないかと思います。

具体的な詳細をつぶさに見て知っているわけではありませんので、報道などから推し量るしかありませんが、当時はキャッシュレス・ポイント還元のスタートが迫る中で新たなペイメントサービスが次々に立ち上がっていました。同時に、サービスの悪用も続いて、業界団体が順守すべき実装上のガイドラインを定めるなど、ダイナミックな時期でもあったと思います。新たに立ち上がるサービスは、キャッシュレス推進に水を差さないよう、セキュリティ実装状況には特に気をつかっていたはずです。

そんな中で、細かいものから大きなものまで、外部からパッと見ただけで「これはまずいのでは？」といった指摘が多く寄せられていたように思います。軽くみただけでわかるセキュリティ上の問題が、脆弱性診断を実施しているにも関わらず、センシティブな時期であったにも関わらず、見過ごされてリリースされてしまった。これは何故なのか。

ペイメントサービス提供側の内部体制に様々な問題があった、といった面はその後の会見で述べられていましたので、ここでは脆弱性診断についてフォーカスしたいと思います。

外部から見ただけで容易にわかるような脆弱性が、脆弱性診断サービスで見つけられなかった。その診断サービスベンダーの「いつもの手順通りの診断」では見つけられない脆弱性だったのではないかと考えます。

岡田：外部から見ただけで容易にわかるのに、手順通りでは見つけられない脆弱性、ですか！脆弱性検査というか、システムの品質のあり方をさえ問いかける視点ですね。

観堂：二要素認証がない、端末とアプリのアカウントの紐づけがない、という重要な点もありますが、わかりやすい話としてはパスワードリマインダーの問題です。リマインダーの入力項目として生年月日とアカウントのIDとともに、送付先メールアドレスの入力欄があるというようなことです。パスワード再設定のためのワンタイムキーの送付先メールアドレスであり、このアドレスを任意に指定できるとすれば、悪意のある第三者から悪用されると考えるのは自明です。

意味を考えれば「いやいや、これはダメでしょ」と見ただけでわかるはずです。

ただし、脆弱性診断の手順に「リマインダーの確認メール送付先を、任意に指定できるのはNG」というようなレベルまで記載はしていない。まぁそんな実装例もなかなかありませんし、そこまで書かずとも、繰り返しになりますが意味を考えればダメなのは自明だから書く必要がない。とすると、手順にないので指摘されない。あくまで推測ですが、そんなことなんじゃないだろうか、と考えたりします。

岡田：それは脆弱性診断サービスを提供する側が劣化しているということですか？

観堂：うーん。劣化というかある意味進化なのか。今から15年～20年前の脆弱性診断サービスの黎明期は、凄腕のエースたちが自分の経験と知識で、広範囲をカバーする脆弱性診断をしていました。その頃は診断手順もある程度あいまいで裁量があった。

しかし、ニーズが増えて脆弱性診断を大量に行わなければならなくなり、多くの人員で対応するために手順を明確にしてあいまいさをなくしてゆく。また、時には診断の中でシステムが落ちる/大量のメールが飛んでしまうといった事故が起こるため、事故防止のための手続きが大量に増える。

こうやって診断サービスが成熟してゆく中で、平準化されてゆくことになり、カバー範囲が極端に下がることになっていないか。逆に手順に書かれている以外のことはしてはいけない、というような状況になっていないだろうか、と。

「見ただけでわかる脆弱性」という表現をしましたが、そのシステム特有の問題、論理的な問題というのは、元々手順化できるものではないため、そのような問題をリリース前のブラックボックスな脆弱性診断で見つける、ということに限界があるのかもしれません。

岡田：そのような問題とは設計上のミスのことになりますね。シンプルな脆弱性診断では設計ミスは指摘しづらいということですよね。

観堂：この手の設計ミスにおける脆弱性は、今後も出てくるでしょう。このような脆弱性も指摘できるようにするため、脆弱性診断ベンダーの方向性の一つとしては、基本の診断手順の拡張や評価項目を増やして要員トレーニングを強化し、カバレッジを拡げることがあります。しかし、そうなると診断時間が増え、料金もそれまでと同額では受けられなくなってきます。

岡田：おっしゃるように、システムのセキュリティ問題は機能の問題と実装の問題の2つに分かれます。機能仕様の欠陥は設計段階で混入する。一方、漏れや抜け、ムラによる欠陥は実装段階で入る問題、というわけです。通常、脆弱性検査は後者、つまり実装問題には確かに強い。ですが、設計の欠陥を発見するところまでサービスに含めるとなると、脆弱性診断をする人材のスキルセットも変わってきますよね。

観堂：そうなんですよ。OWASP Top 10 (Webアプリケーションに関する10大脆弱性) などに載っている脆弱性について詳しく知っており検出もできる。というだけでなく、論理的な問題「このシステムにおいてこのような動作は致命的ではないか？」といった、システム固有の脅威に準じた観点、目をもたなければなりません。

設計の問題は、早い段階で専門家やセキュリティチャンピオンに見てもらうのが得策なのはみな解っていますので、今後需要が高まってくると思います。

岡田：設計段階でのミスはクリティカルな信用問題へと発展します。例えばユーザ認証の仕組みを設計する場合、クレデンシャルをどう保存するのか、有効期限をどうするか、シングルサインオン対応など他のIdPとの連携をどうするのか、有効化・無効化のプロセスなど、さまざまな設計もあわせて対応する必要があるでしょう。これらは、実装の抜け漏れでSQLインジェクションのような脆弱性が残っているかどうかとも、別の問題です。もっと言えば、そのシステムが本当の意味で個人情報を守ることとはPマークを取るかどうかとすら関係がありません。あ、余計なこと言っちゃったかな。

観堂：笑。いずれにしても設計段階で、ユーザが当然期待する運用イメージをちゃんと持てているかどうかが大事になるということでしょうね。

岡田：そう考えると、設計における欠陥の発見を脆弱性診断に委ねるというのは、過剰な要求のように思えます。脆弱性診断はあくまでも実装ミスと悪用可能性を調べるためのものだと割り切ることも必要なのではないかと思います。もちろん、その過程で設計ミスによるシステムの欠陥に気付いた場合、その問題をはっきりと伝え、顧客の解決すべき問題として提起することは親切だとは思いますし、まともな検査会社ではそうしていると思います。

つまり設計の欠陥による問題が起きることについては、開発チームによる実装の問題ではなく、そのような決定したこと時点で問題があり、そのプロセスに責任があるということです。

観堂：顧客自らが設計の誤りを気づくような仕組みが大事だと。

岡田：この部分はとても大事なので、DevSecOpsを実現する視点では、どうすれば設計の妥当性を高めたり、チェックしたりする仕組みを実現できるのか、脆弱性検査の視点ではないものをお客さまに提案していくことも私たちの重要な仕事だと思います。

設計者と実装者がチームを組み、アジャイル開発することで解決

岡田：この問題の背景には、設計への軽視があるのではと僕は考えています。ちゃんと設計できる人だけではありませんので。

観堂：手戻りをなくすためにも設計段階で適切にセキュリティレビューを入れるべきですよね。ただし、脆弱性診断はやるとしても、設計段階でのチェック・レビューはしないと。確かに設計の軽視なのかもしれません。そうなる理由には何が考えられるでしょうか？

岡田：実装する側は、先に既に誰かによって設計されたものをそのまま作るのが仕事。あれ？と思っても、指摘することなく実装してしまうんです。詳細設計した人と実装する人がチームを組んでアジャイル開発する体制になっていれば、問題に気がついたらすぐフィードバックできるので、心理的安全性はかなり担保できると思うんですよ。

観堂：設計でのミスがあればすぐ指摘できるようなチームを作るということでしょうか。

岡田：そうです。ただ、SIでは構造的に実装する側から設計への「文句」は言えないようになっているように思えます。封建的な力関係とは言いすぎでしょうが、たとえばRFPが出されて、それをみて見積もり含め提案しろと言われても、「なんだこの設計要件は？あれもこれも足りないじゃないか」、とは、言えないでしょう。だから、要求がいささかおかしいと気づいていても、言えずに最後まで実装しちゃう。そこで、最終的にシステムが動作した時点とかで設計ミスが露呈してしまう。運良くリリースする前に脆弱性検査で指摘されることもあるかもしれない。そこで、実装を担当した会社にクレームがいくわけですが、肝心の実装した人たちも「俺たちに言われても」ということになってしまう。

観堂：日本特有のレガシーな構造上の問題が、ある意味無責任の連鎖を生み出している、という指摘は興味深いです。ともかく、最後の脆弱性診断で、設計ミスにおける脆弱性の検出を期待されてしまう現状を、適切な状態にアジャストしていかなければならない。システムオーナーの中には、そういうことも含めて見るのが、セキュリティベンダーだと思っている人もいるかもしれませんね。

岡田：そういうことであれば、脆弱性診断を引き受ける際に確認として、「設計の正当性もチェックしてほしいですか」という項目を追加しておくことが必要なんでしょうね。しかし、そこまで見ることができますということは、診断ベンダー側はコミットしづらいのではないでしょうか。

観堂：なるほど。設計の問題は設計の段階で、実装の問題は開発時点で見つけられるようにする。一般的なリリース前の脆弱性診断の中でセキュリティベンダーがそれを見つけるのではそもそも遅いですし、限界がある、そういうことですね。

セキュリティベンダーが設計段階でのセキュリティ設計レビューを請け負うのもよいし、脆弱性診断の中で設計的な誤りを指摘するメニューを提供するのもよい。ただし、セキュリティベンダーが脆弱性診断の中で設計上の問題から実装上の問題まで何でも見つけてくれるはずだと期待して企業側では何ら対策しなくてよい、というような誤った認識が定着すると、前述のような事故はまた発生してしまうのでしょう。

岡田：おっしゃるとおりです！そこで、そのサイクルを小さく速く回す、というコンセプトが大事になってくるわけですよね。

Vol.3につづく (お楽しみに！！)