ソフトウェアのセキュリティ要件と設計 の監査を簡略化する3つの手法

Auditing Software
Author: Rohit Sethi, CISSP, CSSLP, and Ehsan Foroughi, CISM, CISSP
Date Published: 30 June 2015
English

ソフトウェアにセキュリティ対策を構築することは、情報保証の上で重要な前提条件であることは一般に知られた知識です。また、設計段階の不具合の修正は、事後の修正と比較して費用は1/30になることから1、複数のITコントロールのフレームワークや規制において、セキュリティ要件と設計の使用を提案または要求しています。大部分の監査人にとって、入手可能な成果物ベースの証跡がなく、これらの証跡の作成方法を開発チームに指導することもできないため、これらのコントロールを評価するのは困難です。監査人は通常、インタビューの技術と現行で使用されているポリシーの内容に依拠して、アセスメントを行います。このアプローチは、セキュリティ要件と設計が複数のコンプライアンスフレームワーク2の部分を保証するクリティカルなコントロールであるにもかかわらず、開発チームに軽視またはまったく無視されることにつながります。2

より詳細な一例を挙げると、ペイメントカードインダストリーデータセキュリティスタンダード(PCI DSS)の6.3 項で、以下のように述べています。「社内外のソフトウェアアプリケーション(Web ベースのアプリケーションへの管理者アクセスを含む)は、セキュアに開発すること…ソフトウェア開発ライフサイクルのすべての工程で情報セキュリティを実装する」。テスト手順は、書面によるプロセスの調査と開発チームのメンバーへのインタビューなどにより、手順どおり実際に運用されていることを確認します。6.5項では次のように述べています、「ソフトウェア開発プロセスで、以下のような一般的に脆弱とされるコーディングは行わないこと…セキュアなコーディングガイドラインに基づいてアプリケーションを開発すること」。テスト手順には、再度ポリシーと手順書の確認への言及、インタビュー、および追加として、トレーニング記録の確認に言及しています。監査人は、各アプリケーションのシステム要件と設計の中にセキュリティが実装されていることを証明するため、書類や成果物など、よりよい証跡を求めることが絶対に必要です。「システムをセキュアに構築する」や「十分な認証とアクセス・コントロールを実装する」などの概要レベルの要求事項の記述では不十分です。OWASP(Open Web Application Security Project) 上位10項目3 にある抽象的な一般要求 事項では、アプリケーション設計に十分なコントロールが実装されていることの確認はほとんどできません。

幸い、技術とツールの進歩によって、監査には、ポリシーの確認とインタビューを基にした手法を超えた、アセスメントを簡単に行うためのいくつかの選択肢が提供されています。これらのアプローチは必ずしも相互に排他的なわけではありません。多くの組織ではこれらのアプローチを組み合わせて利用しています。ただし、監査人はこれらの技術の少なくとも1つからは証跡を探すべきです。

脅威モデリングアプローチ

脅威モデリングは、体系化された反復可能なプロセスを基に潜在的な脅威を発見するためのアプリケーション設計のモデリング技術です。開発者とセキュリティチームは、想定される脅威のリストと対応する対策とを紐付けて優先順位をつけ、これらを利用して、セキュリティをソフトウェア設計に組み込みます。マイクロソフトは、脅威モデリングの最大の推進者であり、加えて、自由に入手可能な幅広い分野のドキュメント4を提供しています。4

マイクロソフトの脅威モデリングの推進は、Trustworthy Computing5 構想の拡大の一環が始まりであり、その後、他の組織がOWASP脅威モデリング方法(図16 など独自のモデリングを提唱しました。

当然のことながら、マイクロソフトも脅威モデリングの実装に役立つ無料ツール7 をリリースしています。MyAppSecurity8 もまた脅威モデリング用のツールを提供しています。両者のツールとも、開発チームがセキュリティをソフトウェア設計に実装した証跡を提供することができます。

脅威モデリングは3つのアプローチの中で最も包括的なものです。適切に行った場合、脅威モデリングはアプリケーション内のすべての潜在的なセキュリティ課題の完全なリストを明らかにし、総合的な防御アプローチを推進することができます。組み込まれているデータフローダイアグラムを利用すると、開発チームはセキュリティの懸念部分を理解できるだけでなく、システムコンポーネントに関して、どの場所に防御コントロールを置くべきか理解することができます。反対に、包括的な脅威モデリングは、多くの組織にとって短所の部分も存在し ます。大部分のツールは情報セキュリティの専門知識がなくても使用することができますが、脅威モデリングを適切に行うには、多くの場合、総合的な脅威を判断するためにセキュリティの経験を有する人物が必要です。このことは、世界的に情報セキュリティの専門家が不足しているため、難題となっています。9 また、アーキテクチャ図などの特定のドキュメントが必要になりますが、一方では、アジャイルチームは包括的な文書化よりも、ソフトウェア作業を好むという心理が拡大しています。10

監査人の観点からは、ドキュメント化された脅威モデルは、アプリケーションセキュリティがソフトウェア設計に実装されていることを示す明確な証跡となります。脅威モデリングを採用している組織に対しては、特定のアプリケーション用の脅威モデルから、標準のアウトプットをレビューする方法を探すべきです。以下に例を示します。

  • 適切な対策と紐付いた脅威リストの文書
  • プロセスと信頼境界線が記述されているデータフロー図包括監査では、これらのドキュメントの詳細について確認を

すべきですが、一部の監査人は、詳細なレビューを実施するための技術的な経験を持ってない可能性があります。このような場合、監査人は以下ようなインタビューと標準的な成果物を通して、確認を行うことを望むかもしれません。

  • ・対象の期間中、脅威モデルは文書化されていたか(現会計年度など)。
  • 対象の特定アプリケーションに対して、脅威モデルが個別に生成されていたか。各アプリケーションの脅威はそれぞれに固有のものであり、複数のアプリケーションに適用される脅威モデルはほとんど価値がない。
  • 識別された対策がアプリケーション設計に採用されていたか、その場合、その事実を裏付ける証跡はあったか(バグ追跡ツールの記録票、電子メールの履歴、会議の議事録など)。
  • 脅威についてリスク保有と考えられるものはあったか、またはすべての脅威がリスク低減されていたか。脅威がリスク受容されている場合、リスクを受容したのは誰か。また、その事実を裏付ける監査証跡はあるか。

コントロールライブラリアプローチ

国際標準化機構(ISO)から新たにリリースされたISO 2703411、アプリケーションセキュリティ標準では、組織全体に体系的にアプリケーションセキュリティコントロールを定義するプロセスについて概説しています。簡単な言葉で言うと、組織は共通のソフトウェアセキュリティコントロールのライブラリを定義することが求められています(図2)。次に、各アプリケーションチームは、ビジネスのタイプ、法的要因、および技術要因を基にコントロールのサブセットを選択することが求められています。開発者は開発時に該当のコントロールに準拠して実施したことを宣言し、別のグループ(しばしばセキュリティ部門や品質保証(QA)部門など)がそのコントロールが実際に適用されていることを検証します。一部の組織ではISO27034への準拠計画はないかもしれないですが、この標準は、アプリケーションセキュリティプログラムの作成を計画している人にとって参考として役立ちます。ISO27034は業界の多くの利害関係者の参加によって発展 してきました。アプリケーションセキュリティの成熟度の高い一部の組織では、長い時間をかけて類似のアプローチを自ずから構築してきました。

コントロールライブラリアプローチは、ソフトウェア開発プロセスの場面に容易に導入することができ、自動化ツールを利用した場合、全プロセスへの導入にかかる時間は通常、2時間~4 時間です。適切に導入した場合、確かな要件のセットが生成され、予防が可能で、よく知られたソフトウェアセキュリティ課題に 対応することができます。つまり、包括版と軽量版の中間に位置するものです。このアプローチは、脅威モデリングほど、包括的かつ潜在的に正確なものではありません。また、アプリケーションアーキテクチャ内のどの場所にセキュリティコントロールを置くべきかを開発者に提示することはできません。一般的に、セキュリティチェックリストのような軽量なものと比較して、先行導入と維持に、より多くの時間が必要になります。

コントロールライブラリアプローチを取り入れるためのツールを導入している組織は、開発と検証について該当するすべての要件とステータスが記録された監査報告を生成することができなければなりません。監査人は、以下について確認し記録する必要があります。

  • セキュリティコントロールの決定に使われた一連のビジネス、技術的要因、法的要因は文書化されているか。
  • 各コントロールが導入され、検証されていたか。いずれかのコントロールが未導入または未検証の場合、そのコントロールが将来導入される/検証されることを示す監査証跡はあるか、またはそのリスク要因は受容されているか。
  • 該当する場合、アプリケーションライフサイクル管理(ALM)のツール(JIRAなど)へのリンクなど、コントロールが開発に組み込まれていることを示す証跡はあるか。組織は、コントロールライブラリツール内で、完了済ステータスのドキュメントの作成を選択するか、代わりにALMツールの利用を選択するするかもしれません。

セキュリティチェックリストアプローチ

アプリケーションセキュリティを向上するための別の一般的なアプローチは、既知の脅威と対応する対策すべてをリストアップした、包括的なチェックリストを利用することです。最も基本的な形式は、組織が、これを達成するために、静的かつセキュアなプログラミングガイドを作成するというものです。しかし、静的なチェックリストやガイドは、次のようにいくつかの問題があります。

  • 時間的プレッシャー- 機能の実装、反復作業、リリースの時間的プレッシャーに追われている開発者は、40ページ以上のドキュメントを終わりまで読んで、ベストプラクティスのガイダンスを探す時間はありません。
  • 経験年数- ベテランの開発者は、セキュリティについてすでに十分な専門知識を有していると考えており、セキュリティ問題を経験年数の浅い開発者の責任にする場合があります。彼らとって、一般的なベストプラクティスのガイダンスが本当に彼らのアプリケーションにとって利点になるのかと懐疑的に感じるのは自然なことです。
  • 静的なコンテンツ- 攻撃技術と防御技術が進化する中、単一のドキュメントはすぐに時代遅れになります。開発者は最新の脅威についての実用的な情報が必要です。
  • 状況の転換- 開発者は、自身の開発ツールの状況が変化するたびに生産性が低下することが研究で示されています。12 開発者に通常のツールと静的ドキュメントとの切り替えを要求することは、生産性の低下を意味します。つまり逆に、ドキュメントが読まれる可能性が低下するのです。

幸い、開発環境に組み込まれた自動化ツールにより、膨大なドキュメントに目を通すという負担を軽減することができます。Security Innovation社のTeamMentor13 の製品を使用すると、動的でツールベースな手法で、セキュアなプログラミングを行うことができます。この製品は、標準のチェックリストと比較して非常に多くの機能がありますが、使いやすく実装しやすい製品です。

セキュリティチェックリストは3つの中で最も軽量な手法です。一方、脅威モデリングやアプリケーションセキュリティコントロールのアプローチのように、個別のアプリケーションに適応させていない場合が多いです。

監査人は、質問して、以下についてレビューする必要があります。

  • 開発チームが使用した記入済みのチェックリストのコピー
  • チェックリストの記入者がわかる監査証跡
  • チェックリストの項目が開発に組み込まれていることを示す監査証跡
  • チェックリスト内の実装されていない項目の把握、そしてそれらが単に該当しなかったのか、それともリスクを受容したのか

全般的に、組織は自由に使えるツールや技術を複数保有し、セキュリティを要件と設計に組み込んでいます。3つのアプローチは必ずしも両立しないというわけではありません(図3)。一部の組織では、2つまたは説明した3つすべてのアプローチを利用しています。これらのコントロールの評価をプロセスのドキュメントとインタビューのみで行っても、アプリケーションの開発中にプロセスが運用されたことを示す実際の証跡の代わりにはなりません。多くの組織では、主に監査の要求事項への対応を目的として情報セキュリティプログラムを構築しているため、監査の要求事項が厳しくなければ、結果として、多くのソフトウェア開発チームはソフトウェアセキュリティの要件と設計についてあまり重要視しないことを意味します。自動化技術の進歩により監査人は信頼関係を築くことはできますが、開発チームがセキュリティを構築していることを保証するためには、従来どおり実際の成果物のレビューを通した検証が必要です。

後注

1 IBM, Minimizing Code Defects to Improve Software Quality and Lower Development Costs, Development Solutions white paper, 2008, ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf
2 A nonexhaustive list includes: ISO 27001:2013 sections A.14.1.1 and A.14.2.5; PCI DSS sections 6.3 and 6.5; FFIEC IT Handbooks, Security Controls Implementation Systems Development, Acquisition, and Maintenance Software Development and Acquisition; COBIT 4.1: AI2 Acquire and Maintain Application Software; COBIT 5: BAI02 and BAI03.09; NIST 800-37: Common Control Identification Task 2-1 and Security Control Selection Task 2-2; and NIST 800- 53: SA-15, SA-17
3 Sethi, R.; “Why You Shouldn’t Use the OWASP Top 10 as a List of Software Security Requirements,” Infosec Island, 21 February 2013
4 Meir, J. D., et al.; Improving Web Application Security: Threats and Countermeasures, Microsoft Corp., USA, 2003, chapter 3, http://msdn.microsoft.com/en-us/library/ff648644.aspx
5 Microsoft, Trustworthy Computing, www.microsoft.com/en-us/twc/
6 OWASP, Application Threat Modeling, http://www.owasp.org/index.php/Application_Threat_Modeling
7 Microsoft, Threat Modeling Tool 2014, www.microsoft.com/en-ca/download/details.aspx?id=42518
8 My App Security, Enterprise Threat Modeler,
9 Olstik, Jon; “New Research Indicates Cybersecurity Skills Shortage Will Be a Big Problem in 2015,” NetworkWorld, 8 January 2015, www.networkworld.com/article/2866913/it-skill-straining/new-research-data-indicates-that-the-cybersecurity-skills-shortage-will-be-a-big-problems-in-2015.html
10 Beck, K., et al.; Manifesto for Agile Software Development
11 International Organization for Standardization, ISO/IEC 27034-1:2011, www.iso.org/iso/catalogue_detail.htm?csnumber=44378
12 Kerseten, M.; Focusing Knowledge Work With Task Context, University of British Columbia, Vancouver, Canada, 2007, http://tasktop.com/docs/publications/2007-01-mik-thesis.pdf
13 Security Innovation, Team Mentor

Rohit Sethi は、CISSPとCSSLP と言うソフトウェアセキュリティにおける資格を持つ専門家です。彼の現在の職務は、セキュリティコンパス社のSDエレメントチームのマネージャーで、ソフトウェアセキュリティに関して世界でも最もセキュリティに影響を受ける組織を相手に仕事をしています。Sethi はCNBC、Bloombergなど複数のテレビネットワークでセキュリティのエキスパートとして出演しています。また、RSAやOWASPなど業界の多数の会議で発言しています。

Ehsan Foroughi は、CISM、 CISSP の資格を持ち、セキュリティの分野で10年以上の経験を持つアプリケーションセキュリティのエキスパートです。彼はセキュリティコンパス社でプロダクトマネジメントを指揮しています。彼は以前TELUSセキュリティ研究所社において脆弱性調査のサブスクリプションサービスを指揮していました。