DX時代のシステム開発とセキュリティ：Vol.3「セキュリティベンダに求められるスキルやサービスとは？」

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

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

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

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

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

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

プロダクトオーナー、プロダクトマネージャー向けのセキュリティサービスが必要になる

岡田：前回、システムの正当性を検査することと脆弱性診断とは違うんだということをお話しました。脆弱性診断の主眼は実装の問題を発見することです。つまり修正するのは開発チームということになります。一方、システムが想定通り実装されているかどうかよりも、実現されたシステムの正当性の評価を必要とするのは、プロダクトオーナーはもとより、現場ではプロダクトマネージャーでしょう。最近では、PdMと略して書かれることもあります。

このプロダクトマネージャーは、プロダクトに責任を持ちます。ですから、形になっていないアイデアや目標を実現するために、マイルストーンを描き、開発方針を決定するなど、さまざまな角度から実行可能な施策を打ち出して、目標を達成していく役割を担います。

プロダクトのライフサイクル全般に関わるため、例えば見込みのない製品を捨てるという判断も行います。開発シーンにおいてプロダクトマネージャーはアジャイルを回すスクラムマスターよりも大事な存在です。ちなみに日本では、現状ではプロダクトマネージャーはプロダクトオーナーが兼務することが多いと言われています。こうしたことから、僕たちはプロダクトオーナーやプロダクトマネージャー向けのセキュリティサービスを充実すべきだと思うのです

観堂：Webシステムへの攻撃も、以前は特定の脆弱なオープンソースプロダクトを利用していないか、といった広範囲な偵察行為をして、ひっかかったシステムから順番に攻撃を試す、という流れが多かったと思います。最近では、標的にしたシステムに攻撃につながる穴がないかを徹底的に調査した上で、そのシステム固有の穴を突いてくる流れになっていますね。システム固有の穴とは、仕様上の欠陥、つまり設計ミスであることが多い。

岡田：以前、設計ミスを避けるための10箇条というドキュメントを作ったことがあるのですが、システムが多様化している今、汎用性を高めようと思うと、抽象度が上がってしまいます。例えば「need to knowの原則（情報は知る必要のある人のみに伝え、知る必要のない人には伝えない）」と記述しても、具体的なコンポーネントとか設定パラメータ例がわからないとリアルに感じられないせいか、自分事にならないので、それなに？ということになってしまう。

観堂：古典的なものでは「Least privilage (最小特権の原則) 」や「Fail safe、Fail secure (失敗時に安全な状態を維持すること) 」もそうですよね。それを出しても「概念だよね」という一言で終わってしまうと。

岡田：そうなんです。ですから、製品とサービスに寄り添い、「これはできるようにすべきではない」「この機能はこちらに持たせた方が安全だ」というような判断ができる仕組みを、製品やサービス開発のライフサイクルの中につくることが重要だと思います。これをシンプルにスケールさせる方法はなかなか思いつきませんが、製品のライフサイクルに寄り添うセキュリティチームモデルの一つとして考えられるのが「PSIRT」すなわちProduct Security Incident Response Teamの設置です。

観堂：製品の欠陥を認識したら、自分たちの開発サイクルの中で迅速に検出、修正できる仕組みを作るということですね。PSIRTでは、他社の事故事例を教訓として取り込めるよう、リスクシナリオ分析を積極的にやることをおすすめしたいです。それによって目利きも育める。

例えば、自社のシステムが未だにパスワードを平文で保存していることに気づいたとき、他社の事故事例を知っていれば、「このままだといつかとんでもないことになります！」と強く進言できるはずです。

岡田：確かに、情報収集とその適用は、PSIRTの要となる仕事ですね。Vexをはじめ、ユービーセキュアさんが提供しているツールは、自分たちで脆弱性を見つけることをコンセプトにしていますよね。自分で使えるツールの活用はシステム開発において、必要不可欠だと思います。ただ、設計の問題を自分たちで見つけて解決できるソリューションはまだなかなか見ないですね。今後はそういうソリューションが求められてくると思います。

セキュリティベンダーに求められるスキルが変わる

観堂：そういう時代になったときに、求められるセキュリティの知識は変わってくるので、社員教育も再考していかねばなりません。

岡田：しばらく開発の現場に送り込んでみるとかどうでしょうか。

観堂：そうですね。脅威の変遷を俯瞰しながら、自身のシステムについて「あそこはこのままだとまずいんじゃないか？」と、気づける視点を育まないといけない。攻撃側の知識と守る側の経験の両方が求められると思いますので、必要な要素を分解して育成ストーリーに定められると良いのでしょう。

岡田：OWASP関係でつながりがある方で、今はセキュリティベンダのCTOに就いていらっしゃいますが、彼は「今の開発エンジニアの技術はすごい。セキュリティの視点とか問題回避の細かいテクニックは知らないけど、システムの技術を考える力は僕らより全然上だよ」と言うんです。

彼が「こんなリスクがあるからそういう実装は辞めた方がよい」と何か指摘すると、すぐに「じゃあ、ここはこうします」と改善案をいくつも出してくる。技術で解決する力に感嘆していました。問題を指摘するサイドと作るサイドは土俵が違う。

観堂：それは解る気がします。最先端のクラウドサービスを生み出している開発者の、圧倒的な吸収力はすごいですよね。

岡田：セキュリティ業界に長くいて、セキュリティに長けている人が、そういう状況をちゃんと認識していることはすごいことだなと僕は思います。ややもすると、セキュリティエンジニアは情報技術の中でも上位だと思いこみがちかもしれない。もっとも、セキュリティ分野の高い専門性を維持するのは大変だし、大事なんですけど、それでもその価値はモノづくりに活かされて初めて意味があるものだという視点を持ち続けたいです。

注目は設計段階でのセキュリティ

観堂：岡田さんがセキュリティ分野で今、注目しているものは何でしょうか。

岡田：やはり設計段階のセキュリティです。最近、一番引き合いが伸びているのがThreat Modeling (スレットモデリング) 、脅威分析という視点での設計レビューのコースです。

観堂：スレットモデリングを構造化するフレームワークもリリースされていますよね。

岡田：設計レビューを強化すると、クロス機能つまり、認証認可の期限設定やロギングなど、通常の機能要件ではないトピックで、かつ、多くの人が使うがあまり機能テストでは見えてこない要件を早く洗い出すことができます。このシステムの悪用可能性を下げ、発生を検知し、対応し、損害から復旧する、という仕組みを考えることができるようになります。スレットモデリングによって発見できることは、他の工程における脆弱性検査で検知できることと性質が異なります。

観堂：スレットモデリングは脅威の洗い出しに設計段階から真剣に取り組むためのツールということですね。

岡田：そうですね。脅威の洗い出しをし、こういう脅威があるとこんな結果になるというイメージをはっきり描けるようになることはメリットが大きいと思います。枠組みがないと、想像できる範囲でしかセキュリティ対策を妄想するしかない。そうなると、検討できる脅威の範囲の限界は、想像力の限界、ということになってしまいます。

それで、セキュアな設計の手法はまだまだ普及しなければいけない。実装上の問題と解決策、例えばSQLインジェクションが発生しやすいコードはこうだとか、クロスサイトスクリプティングはこれこれで起こる、などの情報は世の中に結構十分流布しています。しかし、設計者に対してはそういう情報はそれほど多くありません。

プロダクトオーナーやプロダクトマネージャーの設置で設計力を向上

観堂：ユーザー企業も設計力を鍛えていかなければならないということでしょうか。これまでのシステム開発では、ユーザー企業は自社で実現したいことを考えて、設計の段階から情報子会社やSIerにある意味丸投げせざるを得ない状況があった。それらを自分たちでできるようになれるのか、そこが一つの課題ですね。

岡田：まともなものを一緒に小さく作って継続的に育てていく。それを可能にするのが「アジャイル」であり、プロダクトオーナーやプロダクトマネージャーが継続して開発のサイクルにかかわるほうが、丸投げするより成功確率が高い。だからこそ、プロダクトマネージャーというポジションを設ける企業が増えているんだと思います。

観堂：日本がDXで欧米に遅れを取っている理由もプロダクトオーナーやプロダクトマネージャーがいないことが背景にありますよね。欧米の企業はプロダクトオーナーがビジネスも開発も指揮する。一方、日本はビジネスと開発が分離しているので、どうしても時間がかかってしまってしまう。しかし、プロダクトオーナーやプロダクトマネージャーが開発のサイクルに入るようになることで、その差が縮まります。

岡田：そうなるといいですよね。設計段階からセキュリティを考える。プロダクトマネージャーと共にセキュアなシステムやサービスの開発がスピーディーにでき、情報センサーとしてのPSIRTとも一体となって継続的に改善していく。良いプロダクトが増えていけばユーザーにとっても安心です。こういうことを実現したいですね。

おわり (次回の対談をお楽しみに！！)

【DX時代のシステム開発とセキュリティ：対談シリーズ】

▸ Vol.1「クラウドに移行できないシステムはいったいどうすれば良いのか？」

▸ Vol.2「設計ミスで起こった脆弱性は誰が見つけるのか」