「セキュア開発」はなぜ浸透しないのか？――DevSecOpsを妨げる“4つの敵”：＠ITセキュリティセミナー 東京・大阪・福岡ロードショー 2017 レポート（2）（4/4 ページ）

“4つの敵”に対処し、企業は「シフトレフト」せよ――アスタリスク・リサーチ 岡田良太郎氏

OWASP Japan Chapter Leader／アスタリスク・リサーチ 岡田良太郎氏

　「この“裏番組”に来てくれた方々は同じことに悩む仲間」、名和利男氏の講演やセキュリティリサーチャーの面々によるパネルディスカッションの真裏で開催された、OWASP Japan Chapter Leaderでありアスタリスク・リサーチ代表の岡田良太郎氏のセッション「システムセキュリティ確保の眠れない夜――DevSecOpsの4つの敵」は、「DevSecOps」をキーワードに、あるべきセキュリティ対策を妨げる“4つの敵”を紹介するものだった。

　はじめに岡田氏は、セキュリティの定義である「CIA」、すなわち機密性、完全性、可用性について、企業から見たときのプライオリティが変化していることを指摘した。特に最近はDoS攻撃などの影響で可用性に対する注目が高まっており、「CIAが“AIC”になっている」（同氏）そうだ。

　そんな状況の中、岡田氏はある“シフト”が起きつつあるのを感じるという。セキュリティ対策の中で、ネットワークセキュリティとともに「アプリケーションセキュリティ」の重要性が注目され始めているというのだ。「『ソフトウェアが脆弱だからやられる』と、インシデントの“原因”にフォーカスが移りつつある。アプリケーションセキュリティを何とかしなくてはならないという考えが広がってきている」（同氏）。最近は海外でも、いかにアプリケーションを安全に構築し、実装するかが議論になっているという。

　これはセキュリティの世界だけで完結する話ではない。例えば開発やインフラの世界では、Dockerに代表されるコンテナ技術などの発展により、サーバアーキテクチャが用意に入れ替え可能となり、スケーラブルな環境を簡単に、確実に作ることができるようになっている。岡田氏は、こうした技術などを追い風に国内でも進展しているDevOpsの中に「セキュリティ」を組み込む「DevSecOps」という考え方が今後は重要になると述べる。

ソフトウェアセキュリティ保証の価値は、「開発プロセス」「セキュリティテスト」「実行環境」で決まる

　ここで、岡田氏はある関数を紹介する。NIST（米国商務省標準技術研究所）によって2016年11月末に発表された、「ソフトウェアセキュリティ保証は開発プロセス、セキュリティテスト、実行環境という3つの変数によって決まる」というものだ。 同氏によれば、これらのファクターに対しては「4つの阻害要因」が存在するという。

NISTIR 8151「Dramatically Reducing Software Vulnerabilities」より

阻害要因その1：投資すべきポイントの「思い込み」

　1つ目の阻害要因は投資ポイントに対する誤解だ。岡田氏はNRIセキュアの調査結果を引き合いに出し、「自社が公開しているWebサイトの一覧を完全に把握している企業は意外と少ない」と指摘した上で、企業がWebサイトを管理できていない理由は、「管理リソースがない」「把握する必要性が認識できていない」「そもそも把握が困難」などさまざまだとした。しかしその一方で、サイバーセキュリティを課題と捉え、CSIRTを設置する企業は増えている。これはどういうことだろうか？

　「CSIRTを作っても、守るべき資産が管理できていない、把握できていないというのは、『ネットワークセキュリティがあれば何とかなるだろう』という“メンタルブロック”があるからだ。『ハニーポット観察記録』という書籍を読めば分かるが、攻撃はむしろアプリケーションを狙っている。このままでは、火の手ばかりが上がり、社員が全員消防団にならざるを得ない。その前に“火の元”を断つ必要がある」（岡田氏）

　岡田氏は、「こうした思い込みを打破し、リスクのミスマッチがないよう、投資のポートフォリオを組み立て直すことから始めるべきだ」と訴える。

阻害要因その2：「OSS」をブラックボックスとして便利に使うリスク

　2つ目の阻害要因は、「OSS（オープンソースソフトウェア）」だ。もはやOSSの恩恵を受けていない企業は皆無と言ってもいいほど、さまざまなところでOSSが活用されているが、そのソフトウェアが“100％安全”であるとは限らない。

　OWASPが定期的に発表している、アプリケーション脆弱性についてまとめた「OWASP Top 10」においても、既知の脆弱性のあるコンポーネントの使用への対策として、まずは「どんなOSSを利用しているかというカタログを持つこと」が提案されている。

　現在では、CVE情報などの脆弱性情報を集約し、関連するOSSに脆弱性情報が登録された場合にメールやSlackに通知する「Vuls」のようなツールもある。Vulsを活用すれば、OWASPのツールが提供する情報も取り込むことができる。

　「人気のあるOSSだから大丈夫と思いがちだが、人気があるからこそ、同じ攻撃コードで丸ごとやられてしまう。ブラックボックスとしてOSSを安易に使うのではなく、自社の責任としてよく選び、またアップデートを欠かさず実施してほしい」（岡田氏）

阻害要因その3：「脆弱性対応は出荷前テストで」という大きな過ち

　3つ目は、「脆弱性対応をどの時点で行うか」という問題だ。製品出荷前にセキュリティテストを行うと、問題が見つかっても「隠すか無視するしかない」という事態が起き得る。岡田氏は、先日急逝した内閣官房初代情報セキュリティ補佐官、山口英氏の言葉を引用する――「一般教養としてのセキュリティで今最も情報が足りないのは、“セキュアプログラミング”だ」。

　「セキュリティテストを運用前ではなく、構築段階でもしっかりやっていこう。脆弱性の原因がビルトインされるのは構築段階だからだ。これまでのコストを“シフトレフト”し、未然に防ぐことが重要だ」（岡田氏）

　このための資料も用意されている。例えばOWASPでは、「OWASP Proactive Controls 2016」を用意しており、早期に、繰り返しセキュリティを検証する方法をまとめている。これには有志による翻訳版もある（下記参照）。またIPA（情報処理推進機構）が公開している「IoT開発におけるセキュリティ設計の手引き」では「IoTはセキュア開発が必要で、後付けは無理」と解説されている。岡田氏は、こちらも併せて参照することを勧めた。

　「従来型の、年4回のセキュリティチェックで守るといったメンタルは捨てるべきだ。やり方、ツール、トレーニングを整備して、シフトレフトしよう」（岡田氏）

阻害要因その4：「コンプライアンスのためのセキュリティ」という間違い

　最後の要因は、「コンプライアンス」に関連するものだ。これまでコンプライアンスは具体的なセキュリティ対策を指示するものではなかったが、金融業界のPCI DSSなどには具体的に「コーディング実践」「繰り返しテスト」といった文言がちりばめられており、まさにシフトレフトを推奨している。だが、「PCI DSSに準拠している企業がいっぱいあるのに、シフトレフトしているようには見えない」（岡田氏）。

　また、日本においては「Pマーク」なども存在しているが、開発現場にはほとんど反映されていない。サイバーセキュリティ戦略の閣議決定の中で、「セキュリティ・バイ・デザイン」という言葉が出てきてはいるが、「日本においてはまだコンプライアンスがセキュリティ確保のけん引者とはなっていない」というのが、岡田氏の考えだ。

思い込みこそが最大の敵

　岡田氏はこれらの阻害要因を打破すべく、「ネットワークセキュリティにおいては境界線はネットワークではなく、ID／データであると考えること。脆弱性対応は出荷前に診断するだけでなく、構築時からセキュリティを作り込み、繰り返し検証すること。OSSは安く早くと考えるのではなく、疎結合で利用し、運用性に注視すること。コンプライアンスは気にする“フリ”ではなく、競争力として捉え、変化に強いチーム作りをすること」とまとめた。

　「セキュリティは、ITの“総合格闘技”。良いものを作り込み、その良さを継続的に保持する仕組み、すなわち『DevSecOps』が2017年は重要になる」（岡田氏）