ホーム >  要求工学 >  2008年3月号 >  第41回：セキュリティ要求工学 

今回は、セキュリティ要求工学の実践的な取組み事例を紹介しよう。

セキュリティ要求工学とは

昨年８月に私が実行委員長を務めて日本科学未来館で開催されたソフトウェア工学シンポジウムSES2007では、The OpenUniversityのBashar Nuseibeh氏に「Valuing Security: on risky requirements and expensive design」と題して基調講演をしていただいた[1]。

Nuseibeh氏は、システムの全体的なセキュリティを達成しようとするのは非現実的であり、トレードオフを考慮した脅威と攻撃のリスクに対するセキュリティ保証技術が必要であると述べた。とくに適切なコストで資産を十分に保護する意志決定の仕組みとして、セキュリティ価値評価技法「セキュリティ要求工学」が必要であると強調した。システムのセキュリティの価値は、良いときは見えず、悪いときに顕在化するため、セキュリティに対する投資効果を明確に説明することは困難である。しかし、だからこそ、システム資産を適切に保護するセキュリティを実現するためには、たとえ定性的であっても客観的な意志決定手法が求められる。このような極めて実践的な観点から、Nuseibeh氏は次のような手法を提案した。

１.境界（スコーピング）段階では、CIAA（Confidentiality,Integrity, Availability,Authentication）からなるセキュリティ・ゴールを明確にする。

２.表現段階では、セキュリティ問題の背景として、否定要求（望ましくない要求）を明確にする。

３.分析段階では、セキュリティ要求が適切であり、満足されることを確認する。

４.統合段階では、要求と設計との一貫性を持つことを確認する。

また講演の最後には、次のようなセキュリティ要求工学の課題を指摘した。

• セキュリティのスコーピング、パターン化、問題分割などの境界問題
• 防止や禁止などのセキュリティ表現
• セキュリティ問題の組合せ手法
• システム・アーキテクチャとセキュリティ・アーキテクチャの統合

たとえばセキュリティ要求の表現手法にはどんなものがあるだろうか？

セキュリティ生産物の表現

システムにとって望ましくないユースケースを表現するように、ユースケース図を拡張した図をミスユースケース図という。ミスユースケース図では、ユースケースによるミスユースケースの緩和関係とミスユースケースによるユースケースの脅威関係を持つ。ミスユースケースについては、本連載の第５回「要求抽出」でも紹介した。ユースケースをそのまま用いた手法に、悪用ケース（abuse case）やセキュリティ機能を記述するセキュリティ・ユースケースなどがある。

また、ソフトゴールグラフでもセキュリティを非機能要求に対するソフトゴールで記述できる。これについても本連載第14回「ゴール分析」で紹介している。

ゴール木と類似する攻撃木（attack tree）では、システムに対する攻撃を木構造で表現する。木の根節点が攻撃のゴールで葉節点はゴール達成手段を記述する。脅威木（threat tree）では攻撃木に脅威に対する緩和条件を補足することができる。

セキュリティ要求の基本要素は何か

IEEEソフトウェア誌の2008年January/February号にTondelらによるセキュリティ要求のサーベイ記事がある[2]。この記事では、これまでのソフトウェア開発では、セキュリティを要求段階では必ずしも重要ではないと考えてきていたが、最近になってソフトウェアセキュリティの欠陥に起因する経済的な損失が表面化してきたため、徐々にセキュリティ要求の抽出手法の必要性が認識されるようになったと述べている。しかし、ソフトウェア開発の現場には、セキュリティ専門家とソフトウェア開発者の間に壁があるので、この壁を乗り越えるための手法が必要であるとしている。

この記事の中から代表的なセキュリティ要求に関連する手法を表1にまとめた。SQUAREだけが要求段階の手法である。CLASPとセキュリティ開発ライフサイクル手法は、設計段階でセキュリティ要求を抽出している。そういう意味でも、要求定義段階でセキュリティ要求を抽出する共通的な手法はまだできていないようである。またTondelらは、形式手法を用いたセキュリティ要求についての研究事例は対象外としている。この理由は、現場ですぐに使えるまでに形式的なセキュリティ要求手法が成熟していないためだとしている。

以下では、表１の手法を簡単に説明しよう。

◆SQUARE[3]

米国SEIが開発したSQUAREでは要求エンジニアが主導して関係者との相互交流に基づきセキュリティ要求を定義する。

セキュリティ目標としてセキュリティ・ゴールを識別する。また生産物の定義に基づいてリスク分析し、セキュリティ要求を抽出・優先順位付け・レビュするために、以下のような手順を示している。

• 定義について合意する
• セキュリティ目標を識別する
• 生産物を作成する
• リスク分析を実施する
• 抽出手法を選択する
• セキュリティ要求を抽出する
• 要求を分類する
• 要求の優先順位を決定する
• 要求をレビュする

◆CLASP（Comprehensive Lightweight Application Security Process）[4]

米国のFortify社が開発したCLASPでは、ソフトウェア開発サイクルを安全にするための一般的なプロセス要素を定義している。ビジネス要求と関連付けて、リスクを緩和し不足や矛盾のないセキュリティ要求を抽出することによりセキュリティ目標を定義する。ネットワーク設計やデータ設計の段階で資産と信頼境界を識別することにより、保護すべき資産を抽出する。

◆セキュリティ開発ライフサイクル（Trustworthy Computing Security Development Lifecycle）[5]

Microsoft社が開発したセキュリティ開発サイクルでは、要求段階ではなく主として設計段階でセキュリティ機能をモデル化する。顧客要望とセキュリティ標準へのコンプライアンスに基づくセキュリティ機能要求を識別することにより、セキュリティ目標を定義する。脅威モデルを設計することにより、セキュリティ機能と保護対象とする資産を識別する。

セキュリティ要求工学の留意点

Tondelらは、これらのセキュリティ要求手法に共通する最も基本的な要素として、セキュリティ目標、資産抽出、脅威分析が共通するとして、表２のようなセキュリティ要求工学の留意点をまとめている。

セキュリティ目標では、次のような条件を満足するような上位レベルのセキュリティ・ゴールを識別する

1. 顧客が望む要求であること。
2. 法制度、標準、ポリシーに適合すること。

資産抽出では、顧客、システム所有者、攻撃者の視点から資産の価値とリスクを判断するために資産ごとに機密性、一貫性、可用性について視点ごとに優先度を判断する。このときリスクを発生確率と影響度で定義することができる。しかしリスクを完全に定量化できないので、高、中、低のような簡易な影響度の評価値も有効であるという。

脅威分析では、最も重要な資産に注力することと脅威カタログを事前に準備することが重要である。脅威カタログの例としてMicrosoft社でも用いられているSTRIDE（なりすましSpoofing、改変Tampering、否認Repudiation、情報暴露Information disclosure、サービス拒否Denial of service、特権昇格Elevation of privilege）がある。

最も重要な脅威については攻撃木を用いて識別する。

またセキュリティ要求の文書化の留意点として、次の３点を挙げている。

1. セキュリティ要求を「how」ではなく「what」で記述する。
2. セキュリティ目標や資産をポリシーとして記述する。ここでポリシーというのは「サービス利用者のプライバシーを保護する」というような記述のことである。
3. セキュリティ要求を1箇所にまとめる。ソフトウェア要求の一部として明確にセキュリティ要求を位置づけることで開発者のリテラシイを向上できるとのことである。

ところで、この記事の著者らが所属するノルウェーのSINTEF ICT[6]では、ソフトウェア工学部門の中にセキュリティグループが置かれている点が注目すべきところである。なおSINTEF（スカンジナビア産業科学技術研究所）は、オスロ大学を中心とするオスロ・サイエンス・パークの中にあり、官民一体でアイデアの製品化を目的とする技術開発機関である。

次にSINTEFが参加するEUのShieldsプロジェクトを紹介しよう。

Shields
（http://er-projects.gf.liu.se/~shields）

Shieldsの目的は、セキュリティ技術者とソフトウェア開発者の壁を越えることにより、セキュリティの脆弱性を解消することである。このため、次のような技術を開発するようである。

●セキュリティ専門家がセキュリティの脆弱性を容易かつ迅速に識別して開発者のコミュニティと開発支援ツールを通じて情報共有できるように支援する

●開発者が日常的に使用する開発支援ツールでセキュリティの脆弱性を検出し除去することを支援する

●ソフトウェア製品がセキュリティの脆弱性を解消していることを開発組織が検証することを支援する

ShieldsはEU-FP7のICT-プロジェクトでスウェーデンLinkoping UniversityのNahid Shahmehri教授がリーダである。この国際的な産官学連携プロジェクトには、スウェーデンのLinkoping Universityの他、ノルウェーのSINTEF、スペインのEuropean Software Institute、ドイツのFraunhofer IESE、フランスのInstitut National des Tele communicationsとMontimage、ハンガリーのSEARCH-LABとイタリアのTXT e-Solutionが参画する。

このプロジェクトは2008年１月１日から2010年の６月30日までの予定で始まったばかりのところだが、ここにも技術開発に対するEUの高い戦略性を見ることができる。セキュリティとソフトウェア開発を統合的に捉えるこのような取り組みがわが国でも必要ではないだろうか？日本でも企業内で見ても、セキュリティ専門家とソフトウェア開発技術者との間でなかなか情報共有が進んでいないのは同様である。この問題を認識しながら手を打つか打たないか、その差が数年後に大きくなっていないことを願う。

EUでは、セキュリティ技術とソフトウェア工学技術の融合を目指した研究開発が国際的、かつ産学連携で進んでいるのである。特定の国、特定の企業、特定の大学によって開発されるのではないということが、グローバルに通用する技術を育てるためには必要である。そうはいっても、逆に欧州の成果を待つという考えもなくはないが、その場合には、この分野において我々は何をなすべきかを深く自問すべきである。

まとめ

今回はセキュリティ要求工学について、昨年のNuseibeh氏の講演とIEEEソフトウェア誌の記事から実践的な話題、さらに今年から始まったEUの研究プロジェクトを紹介した。Nuseibeh氏の講演では、システム・セキュリティを実現するためには、守るべき資産は何か、その優先順位は何かを常に認識することの重要性が指摘されている。これらの点はTondelらも指摘している。また現場のソフトウェア開発者とセキュリティ専門家の間にある壁を解消しようとするShieldsプロジェクトも注目される。今後も、現場指向のセキュリティ要求工学手法が活発に研究開発されることを期待したい。

---

■参考文献

• [1] ソフトウェア工学シンポジウム2007、 ses2007.cs.shinshu-u.ac.jp/
• [2] Inger Anne Tondel, Martin Gilje Jaatun, and Per Hakon Meland, “Security Requirements for the Rest of Us: A Survey,” IEEE Software, pp.20-27, January/ February, 2008.
• [3] SQUARE, www.sei.cmu.edu/publi-cations/documents/05.reports/05tr009.html
• [4] CLASP, http://www.fortifysoftware.com/security-resources/clasp.jsp
• [5] Trustworthy Computing Security Development Lifecycle, msdn2.microsoft.com/en-us/library/ms995349.aspx
• [6] SINTEF ICT,http://www.sintef.no/content/page2____334.aspx