（この記事は、開発元Parasoft社 Blog 「Using Static Analysis to Achieve “Secure-by-Design” for GDPR」2018年5月10日の翻訳記事です。）
GDPRは巨大で困難な課題であり、その期限は近づいています。私の心の片隅には、5月25日の期限までにみな準備ができていると信じたい気持ちがありますが、現実的には、GDPR準拠に向けた動きが本格化するのは、この日以降になるだろうと考えています。GDPRとは何なのか、自分にとって重要かどうか分からないという場合は、どうぞ私の前回のブログをご覧ください。簡単に言えば、収集しているデータおよび使用方法をユーザーに通知し、データの保護に最善の努力を尽くし、データ漏えいが発生したときは透明性をもって対処し、ユーザーからの請求があればユーザーデータを完全に削除する必要があります。そして、もちろん、もしコンプライアンスに違反すれば、莫大な罰金が科されることになります。
理屈としては、GDPRはEU市民だけに適用されますが、今日のほとんどの商取引はグローバルな広がりを持っているため、世界のどこにいても、努めてこの規制に従う必要があります。可能な選択肢は、すべてのユーザーをセキュアでプライベートな方法で扱うか、あるいはEUの顧客とEU外の顧客でデータフローを完全に分けるかです（おそらくこちらの案のほうがコストは高くなるでしょう）。このブログでは、静的コード解析を活用してデータ保護とプライバシーを改善する方法について説明します。
セキュリティ・バイ・デザインおよびプライバシー・バイ・デザイン
GDPR、データ保護、さらにPCI-DSS（Payment Card Industry-Data Security Standard）やHIPAA（Health Insurance Portability and Accountability Act）などの関連するデータ規制について考えた場合、真っ先に思いつくのは、テスト、動的解析、および侵入テストを増やさなければならないということではないでしょうか。これらのテスト技術は必要かつ重要ではありますが、最初からソフトウェアの安全性を高めたり、プライバシーを確保するというよりは、安全でないソフトウェアが出荷される機会を減らすものです。しかし、セキュリティとプライバシーは、品質や性能と同様に「テストで作り込む」ことはできません。したがって、GDPRは「セキュリティ・バイ・デザイン」および「プライバシー・バイ・デザイン」（PbD）という概念を要求します。これは、最初からソフトウェアをよりよく構築することを意味します。
「プライバシー・バイ・デザインの特徴は、事後対応的というより事前予防的であることです。プライバシー侵害イベントが実際に発生する前に予期し、防止します。PbDはプライバシーリスクが顕在化するのを待つことはなく、発生したプライバシー侵害を解決するための救済策も提供しません。プライバシー侵害の発生を防ぐことを目的としています。要するに、プライバシー・バイ・デザインは、事後ではなく事前にあるものなのです。」
A. Cavoukian. Privacy by Design – The 7 Foundational Principles, January 2011.
私がこれら2つの概念を取り上げるのは、これらが通常のアプリケーションセキュリティ対策（ファイアウォール、侵入テスト、疑似セキュリティ攻撃を行うレッド・チーム、DASTなど）が行われた後の次のステップであるからです。「バイ・デザイン」（設計による）の部分は、「ビルト・イット・イン」（組み込まれた）と読むこともできます。これは、アプリケーションをつついてみて穴が見つかった場所を修正するのではなく、最初から穴のないアプリケーションを（設計によって）構築するというアイデアです。たとえば、SQLインジェクション（SQLi）は依然として非常によくある脆弱性攻撃の1つです。
多くのツールは、UIからインジェクションを試行する（侵入テスト）か、プログラムを実行せずにデータフローをシミュレートして、汚染されたデータがデータベースクエリに到達するかどうかを確認する（フロー解析）ものです。「バイ・デザイン」手法とは、入力が取得された時点で、検証関数によって入力（データベース、ユーザー、その他あらゆるところからの）をラップすることを意味します。これにより、データが検証をバイパスする可能性があるパスをゼロにします。ソフトウェアが正しく構築されたかどうかを確認するために、依然として侵入テストを実行する必要はありますが、侵入テストが侵入に成功した場合、見つかった1つの弱点を修正するだけではないという違いがあります。見直しを行って、侵入がなぜ成功したのかを解明し、侵入が成功しないようにソフトウェアを構築する必要があります。
もし侵入テストで多くのセキュリティ上の欠陥が見つかった場合、安全なソフトウェアを「バイ・デザイン」で構築しているとは言えません。プライバシー・バイ・デザインの場合も同様に、誰が/何を/どこで共有しているかを監視し、特に断りがないかぎり、すべてのデータが重要であると見なします。さらに、一般的にプログラマは、特別なフラグが立てられていないかぎり、データは重要ではないという仮定するものです。データをプレーン形式で保存するか、暗号化するかといった決定においては、この傾向が顕著に表れます。すべてを暗号化することは、設計によってプライバシーを確保する方法の1つです。ほかにも方法はありますが、これは基本的なアイデアです。すべてを暗号化すれば、暗号化するべきものをしていないのではないかと心配する必要はありません。
静的解析の役割
静的解析の役割は、ソフトウェアが脆弱であると知らせることではありません（それはテストの役目です）。最初からソフトウェアが堅固であると「設計によって」保証することです。フロー解析は過去10年間でセキュリティテストの技術として普及してきました。しかしやはりソフトウェアをテストする方法であって、ソフトウェアを強化したり、セキュリティを作り込んだりする方法ではなく、「バイ・デザイン」手法でもありません。
適切に実施された静的解析は、真に予防的に機能するただ1つの手法であると言えます。Parasoft製品では、汚染されたデータを探すフロー解析セキュリティルールのほかに、ソフトウェアが安全な方法で構築されることを保証するルールも利用可能です。上で挙げた2つのケースで考えると、プライバシー・バイ・デザインを実現するには、データを最初に暗号化せずに保存しているときに違反を検出する静的解析ルールや、強力な暗号化メソッドではなくハッキング可能であり不適切な古い暗号化メソッドを使用していたり、想定されたアクセス権限では不適切なデータにアクセスしているケースを指摘するルールを使用できます。
サンプルとして、注意を要するメソッドが呼び出されたときにログの記録を強制するルールの簡単な説明を紹介します。この静的解析ルールではバグは見つかりませんが、実行中の処理を記録することで、運用環境でソフトウェアをより安全にするのに役立ちます。このルールは、PCI-DSSやGDPRに最適です。
すべてのセキュリティ関連メソッドの呼び出しを必ずログに記録する[SECURITY.BV.ENFL]
説明：このルールは、セキュリティ上注意が必要なメソッドの呼び出しを記録していないコードを検出します。たとえば、 ‘javax.security.auth.login.LoginContext’ の ‘login’ および ‘logout’のような重要なメソッドの呼び出しがログに記録されていない場合、違反が報告されます。
プライバシー・バイ・デザインのもう1つの例は、ソフトウェアでエラーが発生したときに意図せず個人情報や重要な情報を漏らさないようにするためのルールです。
機密情報のリークを防ぐため、例外メッセージを出力に渡してはならない[SECURITY.ESD.PEO]
説明： このルールは、例外メッセージを出力に渡しているコードを検出します。catch節で出力メソッドを呼び出し、catch節でキャッチされた例外がパラメーターの1つとして使用されているか、または呼び出し元オブジェクトとして使用されている場合、違反が報告されます。
このルールは、OWASPトップ10、CWE、PCI-DSS、およびGDPRをカバーしています。つまり、何を目的としてセキュリティ対策をする場合でも、非常におすすめです。
最初の一歩
GDPRはコーディング標準ではないため、単独でGDPRをカバーするような静的解析コンフィギュレーションはありません。多くの場合、取り掛かりとして最適なのは、XSSやSQLiの問題など、現在テスト中に見つかっている問題に直接的に関連する静的解析ルールを見つけることです。通常、このような問題には、バグの発見に使える静的解析ルールがあるため、テストに入る前に問題を早期に検出することができます。さらに重要なのは、上で述べたように、問題を見つけるのではなく、初めからSQLiが起こらないようにするのに役立つ関連ルール（この場合は入力検証に関するルール）があることです。
ユーザーの入力からストレージに保存されるまでデータを追跡するのは困難です。データが必ず検証されるようにプログラミングするのは簡単です。常に暗号化されるようにプログラミングするのは簡単で、テストも簡単にできます。それなのに、あえて難しいほうを選ぶ理由があるでしょうか？
他の利用可能な静的解析ルール
テスト中に見つかった問題に対処するルールを見つけて有効にしたら、さらに先へ進みます。ここでは、データのプライバシーと保護をカバーしている既存のコーディング標準をヒントにすることをおすすめします。いくつか候補を挙げるなら、OWASP、HIPAA、PCI-DSSです。静的解析ツールでこれらの標準に関連するルールをオンにすると、GDPRに対処するのにも役立ちます。実際、すでにPCI-DSSに準拠している場合は、少なくともGDPRのその部分には、比較的容易に対応できるはずです。
CWEやCERTのような他のセキュリティ要件がすでにある場合は、それに従っていることを確認してから、必要に応じてOWASP等の他の標準の中から、データプライバシー、データ保護、暗号化に関するルールを見つけ、特定のGDPRデータ保護をカバーするようにルールコンフィギュレーションを拡張することができます。
その他のParasoftの利点
Parasoft製品は、いくつかの点でコードのセキュリティ・バイ・デザインおよびプライバシー・バイ・デザインに役立ちます。まず、すべての静的解析エンジンに、OWASP、CWE、CERT、PCI-DSS、HIPPAなどのルールコンフィギュレーションがあります。組織に最適なセキュリティルールを有効にして、自動的に適用することができます。
さらに、Parasoft DTPと静的解析ツールを統合すると、完全な監査機能が得られ、どのルールがどのコードでいつ実行されたかを文書化するプロセスが自動化されます。選択したルールに基づいて、テストを行っていること、場合によってはセキュリティ・バイ・デザインを行っていることも証明できます。
Parasoft DTPには特別なレポートがいくつかあります。CWEに基づいてセキュリティ対策を行うことを選択した場合、Parasoft CWEダッシュボードを利用すると、重要度、場所、種類、履歴などの問題のような優れたSASTレポートが提供されます。さらに、CWEにはテクニカルインパクトデータも実装されています。テクニカルインパクト（TI）は、Common Weakness Risk Analysis Framework（CWRAF）の一環としてMitreで行われた研究であり、発生する可能性のある問題に基づいてSASTの結果を分類するのに役立ちます。そのため、「バッファーオーバーフローがある」という、セキュリティ上の問題として認識されないおそれがあるメッセージの代わりに、TIはバッファーオーバーフローがサービス拒否につながる可能性があることを伝えます。
個々のCWEの指摘事項は、どのような種類の問題が起こるかを示しています。重大度だけでなく、ユーザーにとって最も重要な領域を考慮して静的解析の問題をナビゲートするのに役立つ特別なグラフがあります。この革新的な技術は、特にレガシーコードベースで作業している場合など、脆弱性の数が圧倒的に多くなる可能性のあるケースに対処するのに役立ちます。まず、一番懸念が大きい問題に集中することです。
今回の記事では、セキュリティ・バイ・デザインを実現する手段として、特に静的解析に焦点を当てて紹介しましたが、もちろん、Parasoftには侵入テストツール、APIテストツール、サービス仮想化ツールなどもあります。これらのツールはすべて、包括的なセキュアソフトウェア開発戦略の重要な一部です。
まとめ
GDPRは難しく大変というイメージがあり、確かにそのとおりである場合もありますが、適切なツールと適切なルールを使用して適切に静的解析をセットアップすると、ソフトウェアを安全にし、開発が適切に行われていることを監査官に証明し、セキュア・バイ・デザインおよびプライバシー・バイ・デザインの原則に従っていることを示すのに役立ちます。これは侵入テストだけでは不可能です。さらなる利点として、QAフェーズからリリースまでの期間でテストによってソフトウェアの安全性を確保するよりも、「バイ・デザイン」の観点からセキュリティにアプローチするほうがはるかに効果的だという点が挙げられます。詳細については、ホワイトペーパー『 Using Static Analysis for Secure-By-Design GDPR Data Security and Privacy』を参照してください。
Parasoft Jtestについて
Java対応静的解析・単体テストツール Parasoft Jtest
Jtestは、テスト工数の大幅削減とセキュアで高品質なJavaシステムの開発を強力にサポートするJava対応テストツールです。1,000個以上のコーディング規約をもとにソースコードを静的に解析し、プログラムの問題点や処理フローに潜む検出困難なエラーを検出します。さらに、JUnitを用いた単体テストについて、作成、実行、テストカバレッジ分析、テスト資産の管理といった単体テストに係る作業をサポートし、単体テストの効率化を促進します。