コードの品質がセキュリティリスクに直結する背景
家電やスマホ、テレビなどの身の回りのものから、自動車や電車、スーパーのレジ、工場まで、あらゆるものにコンピューターが組み込まれる現代において、これらを制御するソフトウェア・コードの品質向上および管理は重要な課題だ。今や製品の基本動作から新しい機能やサービスの追加まで、ソフトウェア・コードで行う。不具合や欠陥が見過ごされたまま提供、利用されて重大な事故が発生すれば取り返しの付かないことになる。
例えば、「ソフトウェアの塊」の自動車では、昨年4月に国土交通省が発表したリコール対象台数において、最も多かった原因がコンピュータープログラムの不具合だったと松岡氏は紹介する。最もリコール対象台数が多かったのは、トヨタのプリウスとプリウスα、OEM供給先のダイハツ工業のメビウスで合計124万台以上。
原因は、異常判定の制御プログラムのバグで、走行不能になる恐れがあったと言う。飛行機も同様だ。2018年10月と2019年3月に発生したボーイング737MAXの墜落事故も、ソフトウェアの不具合が原因だった。こうした不具合は最悪の場合、乗客や乗務員、歩行者などの命に関わる事態に発展する可能性がある。
不具合や欠陥は、大きく2つに分類することができる。1つは、自社やサードパーティのソフトウェア・コードの脆弱性。もう1つは、ネットワーク設定やアクセス制御、サイバーセキュリティ対策など、システム上の誤設定だ。そして最近はこうした「欠陥」部分を狙ったサイバー攻撃が増えている。
「サイバー攻撃者は、ソフトウェアのバグや脆弱性を入念に調査し、コードや変数のふるまいや特性で問題があるところを特定し、そこを足がかりにシステムへ侵入したり、サービスを停止させたりする。攻撃者の目的が何であれ、ビジネスリスクであることは間違いない。こうした背景から、最近はセキュリティのコンテキストでソフトウェア・コードの品質が語られることが増えた」（松岡氏）
だが、どんなに脆弱性が指摘され、対策が公表されても、パッチをあてないまま放置されるシステムも少なくない。2014年4月に発覚したOpenSSLの脆弱性「Heartbleed」も、なかなか修正されないまま運用されるサーバーが数年後も多数存在したという報告もある。
「こうした情報を知りながら改修せずに運用し続ける判断をしたのであれば、それは道義的・倫理的に問題だ。もしも経営層が技術面で理解できずに修正できていないのであれば、開発者や運用者がリスクをきちんと伝える必要がある」（松岡氏）
しかし、セキュリティの視点に立ったソフトウェア・コードの品質向上は、言うほど簡単ではない。松岡氏はその理由として、「コード量」「複雑度」「開発速度」「リスク」の4つを挙げた。
コード量は、大規模なシステムやサービスになるほど増えていく。また、ML・AIやクラウド、IoTなどを活用して複数の異なるプラットフォームや言語、サービスを連携させながら1つのシステムを構築することが多い昨今、システム全体だけでなく、品質管理も複雑だ。そのような状況で、アジャイル開発やCI/CD、DevOpsで開発スピードを上げつつ、高度化するサイバー攻撃のリスク軽減に向けた施策も実施する必要がある。
セキュアなアプリケーションを開発するポイント
では、セキュアなサービスやシステムを開発することは可能なのか。1つは、システム全体を俯瞰しながら、解決すべき課題がどこに存在し、どう解決すべきかを整理することだと松岡氏は言う。
例えばWebアプリケーションであれば、外部と連携するためのWeb UIやAPI、Webアプリケーションのふるまいを決めるロジック、フレームワーク、コード、OSSコード、OSやシステムで構成される。Web UIやAPIなどのインターフェイスは、DAST（動的アプリケーション・セキュリティ・テスト）で実際の動きを見ながら脆弱性をチェックするテスト方法。ロジックは、ランタイム・テストやインタラクティブ・アプリケーション・セキュリティ・テストで、データやオブジェクトの生成、やり取りを可視化し、バグを洗い出す。フレームワークやコードについては、SAST（静的アプリケーション・セキュリティ・テスト）で静的解析し、脆弱性やバグを発見。OSSコードやOSなどは、脆弱性だけでなくライセンス違反のリスク管理も必要だ。
「特に、今どきはサードパーティのOSSコンポーネントを寄せ集めてシステム開発することが一般的で、そのコンポーネントに内在する脆弱性を見落としたまま実装してしまうケースは後を絶たない」と松岡氏は指摘する。
こうしたテストは、計画、コード作成、ビルド、テスト、デプロイといった開発の各工程で実施することが望ましい。「効率化の意味でも、CI/CDパイプラインにセキュリティテストを組み込み、自動化することをおすすめする」（松岡氏）
もう1つのポイントは、脅威モデルを構築することだ。脅威モデルでは、システム構成をベースにアセットの種類や場所、アセット間のデータ連係ややり取りを整理し、これらアセットに対してどのような攻撃が想定されるのかをマッピング。それぞれの管理策、さらには管理策を回避しうる攻撃や脆弱性を考える。
Webアプリケーションで考えてみる。アセットには、データベース、アプリケーションのデータ、セッションチケット、ユーザーのIDとパスワード、イベントテーブル、レポートデータ、ログファイルやイベントデータなどがある。これらの情報に対して不正にアクセスする場合、どのような脅威エージェントが存在するのか。
例えば、本来は正しい権限を持ったユーザーや通信のみがアクセスできなければならないところを、認証に不備があると、権限のないユーザーや通信がアクセスできる可能性がある。また、正規の認証情報が何らかの形で他人に漏れていれば、正規の承認済みユーザーとなり、外部および内部からアプリケーションのユーザーやシステム管理者、データベース管理者、開発者としてログインすることも可能だ。
脅威エージェントがリストアップできたら、次はそれぞれの管理策、管理策の回避方法と対策を考える。例えば、Webサーバー経由でアプリケーションサーバーにアクセスするには、認証情報のアセットを用いてユーザー認証や一方向のSSLを組み合わせ、アクセス制御で管理する。ここで困るのは、認証情報を窃取されてしまった場合だ。これは、サイバー攻撃と対策についてまとめたナレッジベース「MITRE ATT&CKフレームワーク」を参照するのがいいと松岡氏は言う。
例えば、認証情報を窃取するテクニックの1つに「クレデンシャルダンピング」が存在する。これは、カーネルの実装上の問題から権限昇格が実行可能な脆弱性を悪用するといった手法だ。防ぐには、ルート権限を取得できる脆弱性はつぶすことだと同フレームワークには記載されている。
「MITRE ATT&CKフレームワークでは、標的型攻撃などで使われたテクニックや既存の脆弱性の概要、対策が簡潔にまとめられているので、参考になる」（松岡氏）
脅威モデルは、マイクロソフトの「STRIDE」、OWASPの「Application Threat Modeling」、OpenID Foundationの「OAuth 2.0 Threat Model/IETF RFC6819」などがある。自社にとって運用しやすいモデルを選択するのがおすすめだそうだ。
シノプシスでは、静的解析でコードに含まれる既存の脆弱性を検知する「Coverity」や「Black Duck」などの製品群のほか、DASTやペネトレーションテストを実施するプロフェッショナルサービスを提供している。
最後に、松岡氏は「脆弱性は、ビジネスにおいて大きなリスクだ。脆弱性が組み込まれないように対策するには、まずはサービスやシステムにどのようなアセットが存在し、どのような脅威が想定されるかを整理して、自動化で工夫しながら開発のライフサイクルの各プロセスでセキュリティテストを組み込むこと。それがセキュアな製品・サービスの開発を実現し、ビジネスリスクを低減するためのカギだ」と強調した。
お問い合わせ
日本シノプシス合同会社
