脅威分析と脆弱性分析の違い
Matsunami, Masaru
松並です。最近J3061を勉強しているのですが、
脅威分析（threat analysis）と脆弱性分析（vulnerability analysis）の違いがよく分かりません。
何かしら指針などご存知の方がいらっしゃいましたら教えてください。
---
セキュリティ用語の定義は人それぞれバラバラであることが多いのですが、
J3061で区別して書かれていることを鑑みますと、
最近ではある程度「脅威分析」や「脆弱性分析」の定義が整理されてきているのかなと思いまして、
SIGSTAのMLで聞いてみようと思いました次第です。
なんとなく「目的」については次のような区別があるのかなと想像しているところですが・・・
脅威分析 脅威（起きてほしくない事象）を導出すること
脆弱性分析 脆弱性（脅威を顕在化できるシステムの特性/欠陥）を発見すること
「作業」をやり始めるとその違いがあいまいな感じがします。
ある設計に対して脆弱性分析を始めると、
1段階詳細化した設計において脆弱性を探すことが攻撃方法を探すことになって、
これって脅威分析？とか。。。
----
松並 勝 <masaru.m...@dnvgl.com>
機能安全部 / サイバーセキュリティグループ
DNV GL - Business Assurance Japan
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
t-ka...@ipa.go.jp
JIS TR Q 0008:2003による定義では、
脅威
システム又は組織に危害を与える事故の潜在的原因
脆弱性
脅威によって影響を受ける内在する弱さ
リスク
ある脅威が脆弱性を利用して損害を与える可能性
です。
どんな弱みがあるかと、弱みをつくどんな脅威があるかを調べるのは質的に異なる作業であると
大久保先生もおっしゃています。
詳細は2/27のセミナーで脅威分析と脆弱性分析について、大久保先生に講演していただくので
ぜひ、お越しください。
https://sec.ipa.go.jp/seminar/20180227.html
（ただいま、満席ですが、明後日リマインダメールで来られなくなった方には
キャンセルをお願いするので、空きが出るかもしれません）
金子朋子
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Riotaro OKADA
Kenji Taguchi
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Toshiyuki Fujikura
田口様
御世話になっています。dSPACEの藤倉です。
システム分析では脅威分析は要らないと言うのはJ3061を完全に読み間違っているのだろうと思います。
J3061では構成上コンセプトフェーズで守るべき資産が分かるので脅威分析が可能になって、システムフェーズでシステム構成やコンポーネント特性が明確になるので脅威分析が可能になる。
と言うことだと私は理解しております。
藤倉
2018年2月19日月曜日 12時08分27秒 UTC+9
t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com
にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout
にアクセスしてください。
Kenji Taguchi
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
Toshiyuki Fujikura
田口様
御世話になっています。
> 藤倉さんの文末は「脅威分析」では無く、「脆弱性分析」のことだと思われます
その通りです、失礼しました。
> J3061 を読むと、 vulnerability analysis はプロセスとして system level 以降でしか使われていない。 threat analysis
>という用語は concept phase でしか使われていない、というのは正しいと思いますが、その点は如何でしょうか？
これで正しいと思っています。
> ただし、それ以外には何も書いてありません。TARA（リスクアセスメントを含めて）をやるのか、そうすると、
>コンセプトフェーズの分析結果との関係はどうなるのか、といった疑問が出てきますが、何も記述されていません。
この部分は、繰り返し開発になるのだと思って読んでました。新たな脅威が見つかったら、コンセプトフェーズに戻っての見直しが必要なのだと思います。
以上、よろしくお願いします。
藤倉
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com
にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout
にアクセスしてください。
Kenji Taguchi
2018年2月19日月曜日 16時55分14秒 UTC+9 tfujikura:
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
Toshiyuki Fujikura
田口様
> そうすると、システムレベルの分析ではなく、コンセプトフェーズでの脅威分析を再度、実施するということであり、
> システムレベル（の記述）での脅威分析ではない、ということで宜しかったでしょうか？
そう思います。
脅威分析はあくまでも資産を対象とした分析で、脆弱性分析は実装メカニズムに対する分析であると認識しています。
システムレベル（の記述）での脅威分析と言うのがあまりイメージできません。
以上、よろしくお願いします。
藤倉
From: sig...@googlegroups.com [mailto:sig...@googlegroups.com]
On Behalf Of Kenji Taguchi
Sent: Monday, February 19, 2018 5:17 PM
To: 脅威分析研究会 SIGSTA <sig...@googlegroups.com>
Subject: Re: [sigsta] Re: 脅威分析と脆弱性分析の違い
藤倉様、
> この部分は、繰り返し開発になるのだと思って読んでました。新たな脅威が見つかったら、コンセプトフェーズに戻っての見直しが必要なのだと思いま
2018年2月19日月曜日 16時55分14秒 UTC+9 tfujikura:
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com
にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout
にアクセスしてください。
Matsunami, Masaru
金子さん、岡田さん、みなさん
松並です。ありがとうございます。
図をちゃんと書いて質問したほうがよかったです。ということでPDFを添付します。
セキュリティ分析を開始する抽象度の違いによって、
同じ分析行為（図中で緑枠内）が脅威分析に現れたり脆弱性分析に現れたりするわけです。
一応↓のつもりで、脅威分析と脆弱性分析の違いを意識してやってはいるのですが。
脅威分析 脅威（起きてほしくない事象）を導出すること
脆弱性分析 脆弱性（脅威を顕在化できるシステムの特性/欠陥）を発見すること
面白いですねー。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com
にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout
にアクセスしてください。
Matsunami, Masaru
藤倉様、田口様、みなさま
DNVGL松並です。面白い議論です！あえて思考実験として反例っぽいものを投下します。
> システムレベル（の記述）での脅威分析と言うのがあまりイメージできません。
とあるオンラインバンキングシステムがあったとします。
コンセプトフェーズにて「送金時にはユーザーにその旨を通知することで不正送金時の被害を低減する」と決めたとします。ただし通知手段についてはシステムレベルの都合で判断してもらうために自由度を持たせてあります。
その後システムレベルにて通知手段としてEメールを選択します。メール送信機能を実現するためにSendmailサーバーを導入することにしました。
Sendmailサーバーを導入するときに注意しないといけないことがあります。SPAM発射台として悪用されるオープンリレーにならない（踏み台にならない）ような設計が求められます。ここで面白いのが、たとえシステムがSPAM発射台になってしまっても、コンセプトフェーズで定めたセキュリティゴールは達成できてしまうことです。オンラインバンキングシステムがビジネスロジックで扱う資産を保護することとSPAM発射台になってしまうことはまったく独立なわけです。
脅威分析技術的にはどういうことになっているかといいますと、Sendmailサーバー（もしくはEメール送信機能）をシステムに導入するという決定をしたタイミングで、「Eメール送信機能」という新しい資産（守る必要があるもの、勝手に使われては困るもの）が導入されているわけです。「Eメール送信機能を第三者に利用されてはならない」というトップレベルの要求（つまりセキュリティ目標）が生まれるわけです。システムレベルの設計選択によって。
コンセプトフェーズでは通知手段の選択はシステムレベルの都合で自由に選択してよいことにしていました。ゆえにコンセプトフェーズに戻って「Eメール送信機能を第三者に利用されてはならない」と要求を定めることはちょっと具合が悪いです。システムレベルでも「新しい資産が導入されていないか？」という観点で脅威分析するほうがしっくりくるように思います。同様にHWレベルにおいても、SWレベルにおいても、そこで設計選択がなされる以上、新しい資産が導入されていないかを確認（つまり脅威分析を）する必要があると思います。
なお、SPAM踏み台の件はSIGSTA第1回会合＠京都で越島先生から突っ込みを頂いた件です！
Takao Okubo
大久保です。
家でインフルの子供を見ながら書いています:-)
既存のSendmailサーバのどれかを使うことになっている場合、そのできあがっているサーバには「脆弱性」がある可能性があります。これは脆弱性の使い方としては普通の使い方ですね。
ただ、「Sendmailサーバは実装のやり方に関わらず、プロトコル上踏み台になることが避けえない」場合は、これはプロトコルの脆弱性と言ってもいいと思います。(本当にそうかは知りません:-)
したがって、コンセプトフェーズでも脆弱性という言葉を使っていい場合もあると思います。
個人的には、脆弱性分析とは脅威が実現できる可能性を測るために使うので、リスク分析を含む脅威分析に脆弱性分析は含まれると思います。
>
> *松並 勝*<masaru.m...@dnvgl.com>**
>
> *機能安全部**/ **サイバーセキュリティグループ***
>
> *DNV GL - Business Assurance Japan*
>
> https://www.dnvgl.jp/assurance/
>
> dnvgl
>
> *From:*sig...@googlegroups.com [mailto:sig...@googlegroups.com] *On
> Behalf Of *Toshiyuki Fujikura
> *Sent:* Monday, February 19, 2018 5:31 PM
> *To:* Kenji Taguchi <kenji....@gmail.com>; 脅威分析研究会SIGSTA
> <sig...@googlegroups.com>
> *Subject:* RE: [sigsta] Re: 脅威分析と脆弱性分析の違い
> 田口様
>
>> そうすると、システムレベルの分析ではなく、コンセプトフェーズでの脅威分
> 析を再度、実施するということであり、
>
>> システムレベル（の記述）での脅威分析ではない、ということで宜しかったで
> しょうか？
>
> そう思います。
>
> 脅威分析はあくまでも資産を対象とした分析で、脆弱性分析は実装メカニズムに
> 対する分析であると認識しています。
>
> システムレベル（の記述）での脅威分析と言うのがあまりイメージできません。
>
> 以上、よろしくお願いします。
>
> 藤倉
>
> [mailto:sig...@googlegroups.com] *On Behalf Of *Kenji Taguchi
> *Sent:* Monday, February 19, 2018 5:17 PM
> *To:* 脅威分析研究会SIGSTA <sig...@googlegroups.com
> <mailto:sig...@googlegroups.com>>
> *Subject:* Re: [sigsta] Re: 脅威分析と脆弱性分析の違い
> 藤倉様、
>
>> この部分は、繰り返し開発になるのだと思って読んでました。新たな脅威が見つ
> かったら、コンセプトフェーズに戻っての見直しが必要なのだと思いま
>
>>す。
>
> そうすると、システムレベルの分析ではなく、コンセプトフェーズでの脅威分
> 析を再度、実施するということであり、システムレベル（の記述）での脅威分析
> ではない、ということで宜しかったでしょうか？
>
> 以下の藤倉さんのコメントとの整合性はどうなりますか？混乱してきました。。。
>
>> システム分析では脅威分析は要らないと言うのはJ3061を完全に読み間違って
> いるのだろうと思います。
>
> 田口
>
>
>
>
>
> 田口様
>
> 御世話になっています。
>
> > 藤倉さんの文末は「脅威分析」では無く、「脆弱性分析」のことだと思わ
> れます
>
> その通りです、失礼しました。
>
> > J3061 を読むと、 vulnerability analysis はプロセスとしてsystem
> level 以降でしか使われていない。threat analysis
>
> >という用語はconcept phase でしか使われていない、というのは正しいと思
>
> これで正しいと思っています。
>
> > ただし、それ以外には何も書いてありません。TARA（リスクアセスメント
> を含めて）をやるのか、そうすると、
>
> >コンセプトフェーズの分析結果との関係はどうなるのか、といった疑問が出
> てきますが、何も記述されていません。
>
> 見つかったら、コンセプトフェーズに戻っての見直しが必要なのだと思います。
>
> 以上、よろしくお願いします。
>
> 藤倉
>
> *From:*sig...@googlegroups.com <mailto:sig...@googlegroups.com>
> [mailto:sig...@googlegroups.com <mailto:sig...@googlegroups.com>]
> *On Behalf Of *Kenji Taguchi
> *Sent:* Monday, February 19, 2018 4:40 PM
> *To:* Toshiyuki Fujikura <TFuj...@dspace.jp
> <mailto:TFuj...@dspace.jp>>
> *Cc:* 脅威分析研究会SIGSTA <sig...@googlegroups.com
> <mailto:sig...@googlegroups.com>>
> *Subject:* Re: [sigsta] Re: 脅威分析と脆弱性分析の違い
> 3.99 VULNERABILITY ANALYSIS
>
> Vulnerability analysis techniques attempt to identify and classify
> potential Cybersecurity vulnerabilities or holes in the software and
> hardware of the feature being developed that may be exploited by an
> attacker.
>
> ちなみに、J3061 には、threat analysis の定義は乗っていません。
>
> まずは、この辺りについてはご意見は如何ですか？
>
> 田口
>
> 2018-02-19 13:34 GMT+09:00 Toshiyuki Fujikura <TFuj...@dspace.jp
>
> 田口様
>
> 御世話になっています。dSPACEの藤倉です。
>
> システム分析では脅威分析は要らないと言うのはJ3061を完全に読み間
> 違っているのだろうと思います。
>
> J3061では構成上コンセプトフェーズで守るべき資産が分かるので脅威
> 分析が可能になって、システムフェーズでシステム構成やコンポーネン
> ト特性が明確になるので脅威分析が可能になる。
>
> と言うことだと私は理解しております。
>
> 藤倉
>
> *From:*sig...@googlegroups.com <mailto:sig...@googlegroups.com>
> [mailto:sig...@googlegroups.com
> <mailto:sig...@googlegroups.com>] *On Behalf Of *Kenji Taguchi
> *Sent:* Monday, February 19, 2018 12:32 PM
> *To:* 脅威分析研究会SIGSTA <sig...@googlegroups.com
> <mailto:sig...@googlegroups.com>>
> *Subject:* [sigsta] Re: 脅威分析と脆弱性分析の違い
> 松並様、
>
> この議論は、自動車業界では最近、良く聞きますが注意すべき点が
> 多々あります。
>
> 【J3061】
>
> コンセプトフェース（Cybersecurity concept phase）-- 脅威分析
>
> システムレベル-- 脆弱性分析
>
> となっており、まるでシステムレベルでは脅威分析がいらないような
> かれているので、脅威分析は要らない、という極論を言われる方もいます。
> 基本的な理解としては、「脆弱性」をexploit するのが「攻撃」なの
> えば、
> 脆弱性： サーバはリソースを消費させられるとシステムが落ちる
>
> 攻撃：DDoS (例：TCP Sync Flood）
>
> 対抗策：SYN cookies
>
> といった具合に、
>
> 脆弱性-攻撃-対抗策
>
> という三位一体の関係になっているとしています。ちなみに、このよ
> うに、３者をアタックツリーに書く、流儀もあります。
>
> 田口
>
>
>
>
>
>
>
> 2018年2月19日月曜日12時08分27秒UTC+9 t-ka...@ipa.go.jp
> 機能安全部/ サイバーセキュリティグループ
>
> **************************************************************************************
>
> This e-mail and any attachments thereto may contain
> confidential information and/or information protected by
> intellectual property rights for the exclusive attention of
> the intended addressees named above. If you have received
> this transmission in error, please immediately notify the
> sender by return e-mail and delete this message and its
> attachments. Unauthorized use, copying or further full or
> partial distribution of this e-mail or its contents is
> prohibited.
> **************************************************************************************
>
>
> --
> <mailto:sigsta%2Bunsu...@googlegroups.com> にメールを送
> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に
> 登録しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信して
> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に登録
> しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信してくだ
> さい。
> その他のオプションについては https://groups.google.com/d/optout にア
> クセスしてください。
>
> --
> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に登録して
> いるユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信してください。
> その他のオプションについては https://groups.google.com/d/optout にアクセ
> スしてください。
>
> --
> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に登録して
> いるユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信してください。
> This e-mail and any attachments thereto may contain confidential
> information and/or information protected by intellectual property rights
> for the exclusive attention of the intended addressees named above. If
> you have received this transmission in error, please immediately notify
> the sender by return e-mail and delete this message and its attachments.
> Unauthorized use, copying or further full or partial distribution of
> this e-mail or its contents is prohibited.
> **************************************************************************************
>
> --
> ているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信してください。
大久保 隆夫 (OKUBO Takao, Ph.D.)
情報セキュリティ大学院大学 情報セキュリティ研究科
ok...@iisec.ac.jp
Toshiyuki Fujikura
松波様
はじめまして、藤倉と申します。
時々、学会等でお姿は拝見しております。
興味深い事例をありがとうございます。
実現手段として「Eメール送信機能」を選択したことで、発生したのは悪用されて社会に迷惑を掛ける、このことで社会的信用を落とすことが脅威なのだと思います。社会に迷惑を掛けても気にしない会社の場合は、悪用されることでサーバー負荷が増えて本来機能に支障が出るとか電気代が勿体ないとかが脅威になるのではないかと思います。
社会に迷惑を掛けないことがすでに要求としてコンセプトフェーズで定義してあれば、メールサーバを選択した段階でメールサーバーの脆弱性を評価できるのではないかと思います。
個人的には、「Eメール送信機能を第三者に利用されてはならない」はシステムあるいはサーバーレベルの要求だと思います。「機能を第三者に利用されてはならない」であればトップレベル要求だと思います。
以上、よろしくお願いします。
---------------------------------------------------
藤倉 俊幸 (Toshiyuki Fujikura)
ソリューション技術部 テクニカルフェロー
dSPACE Japan 株式会社
〒140-0001
東京都 品川区北品川4-7-35 御殿山トラストタワー10階
Mail: tfuj...@dspace.jp
Web: http://www.dspace.jp
TEL(代表): 03-5798-5460
TEL(技術部)：03-5798-5471
FAX: 03-5798-5464
---------------------------------------------------
Kenji Taguchi
2018年2月19日月曜日 16時55分14秒 UTC+9 tfujikura:
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
Matsunami, Masaru
田口先生
松並です。おっしゃる通りです！SWレベルの設計選択で資産が導入される例でしたね。
とはいえISO26262もJ3061もテーラリング前提ですから、SYSレベルでできるだけ詳細に設計をする（HW、SWの設計段階でSYSの狙い通りに設計できないときはSYSに戻って再設計することもよくあるので、あらかじめSYSでHW、SW的な内容にまで踏み込んで設計しておく）流派もあるそうで、その場合はSYSレベルでSW要素の決定まで行うこともありそうです。
松並
From: Kenji Taguchi [mailto:kenji....@gmail.com]
Sent: Tuesday, February 20, 2018 10:57 AM
To: Toshiyuki Fujikura <TFuj...@dspace.jp>
Cc: Matsunami, Masaru <Masaru.M...@dnvgl.com>; 脅威分析研究会 SIGSTA <sig...@googlegroups.com>
Subject: Re: [sigsta] Re: 脅威分析と脆弱性分析の違い
松並様、
2018年2月19日月曜日 16時55分14秒 UTC+9 tfujikura:
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
Kenji Taguchi
2018年2月19日月曜日 16時55分14秒 UTC+9 tfujikura:
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+unsubscribe@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
Matsunami, Masaru
田口先生、みなさま
はい。突っ込みによってさらなる情報がやり取りされることがMLの価値になります！
※現実逃避したい人たち大歓迎です！
松並＠DNVGL
From: Kenji Taguchi [mailto:kenji....@gmail.com]
Sent: Tuesday, February 20, 2018 11:23 AM
To: Matsunami, Masaru <Masaru.M...@dnvgl.com>
Cc: Toshiyuki Fujikura <TFuj...@dspace.jp>; 脅威分析研究会 SIGSTA <sig...@googlegroups.com>
Subject: Re: [sigsta] Re: 脅威分析と脆弱性分析の違い
松並様、
（現実逃避モード オン！）
2018年2月19日月曜日 16時55分14秒 UTC+9 tfujikura:
2018年2月19日月曜日 12時08分27秒 UTC+9 t-ka...@ipa.go.jp:
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
Matsunami, Masaru
松並です。ご自宅からありがとうございます！以下、ちょっと整理してました（つもりです）。
■脆弱性分析を実施するフェーズのはなし
> コンセプトフェーズでも脆弱性という言葉を使っていい場合もあると思います。
はい。その通りですね。コンセプトフェーズの抽象度においても見える脆弱性があれば対抗策（管理策？）または対抗方針を設計に盛り込む必要がありますね。今までの議論によりますと、脅威分析や脆弱性分析（と呼ばれる行為）はコンセプトフェーズ（Part3）、システムレベル（Part4）、HWレベル（Part5）、SWレベル（Part6）のどこででも必要性を確認し、必要であれば実施するということですね。
J3061 8.3 Concept PhaseではTARA(Threat Analysis and Risk Analysis) は明示的に書いてありますが、Vulnerability Analysisは書いてありません。けれども必要と判断すればVulnerability Analysisも実施すればよいわけですね。そもそもJ3061は自組織に合わせてテーラリングすることが前提ですし。
■脅威分析と脆弱性分析の違いのはなし
>脆弱性分析とは脅威が実現できる可能性を測るために使うので、
「脅威が実現できる可能性」には2通りある（脆弱性、攻撃方法）ように思います。ちょっと長くなりますが。。。
用語の関係を次のように整理してみます。
(a) 脅威 ＝ システムにおいて発生しうる事象のうち、それが発生すると被害が生じると位置づける事象
(b) 脅威分析 ＝ 脅威を「発見する行為」
(c) 脆弱性 ＝ 脅威を実現できる「システムの特性/欠陥」
(d) 脆弱性分析 ＝ 脆弱性を「発見する行為」
ここで(c)や(d)は、設計の詳細度において、「ここが脆弱性である」と指摘できる程度にシステムの設計ができていることを前提としているように思います。もし設計の抽象度が高い段階で (d) 脆弱性分析を実施しようとすると、「ここが脆弱性である」と指摘できる詳細度の設計がまだ存在しないため、脆弱性を見つけることができないと思いました。例えば設計で「BLE通信する」ことは決まっているがその「ペアリング方式」は決まっていないなどですね。すると「ペアリング方式にどの方式を選択するかによるが、認証がなければ第三者はBLE接続してコマンド送信できるかもね」というように脆弱性ではなくて「攻撃手法」を見つけることになります。こうした攻撃手法の成立を阻止するために、「BLEペアリングはPasskey Entryにする。」「Passkeyの生成は・・・」といったセキュリティ要求を導出することにつながります。
設計の抽象度が高いときに脆弱性分析をしようとすると、見つかるのは脆弱性ではなくて攻撃手法と、それに対抗するセキュリティ要求が導出されるわけです。まだ脆弱性が作りこまれる前ですから。
で、この一連の流れを「脆弱性分析」と呼ぶのはちょっと違和感があるんですよね。脆弱性を見つけているわけではありませんから。
■「脆弱性分析」の別の使われ方
上では「脆弱性分析」を(d)のように定義していますが、ほかにも「脆弱性分析」という用語を
(d') 脆弱性分析 ＝ システムが持つ特定の脆弱性について、その脆弱性を攻撃する場合の、
攻撃成功するための諸条件を明らかにすること及び、
攻撃成功したときの被害内容を明らかにする行為
のように使っている例も見ます。この場合、「脆弱性解析」と呼ばれることもあるようです。
J3061では(d)の意味合いで使われていると思います。
> リスク分析を含む脅威分析に脆弱性分析は含まれると思います。
わたしも概ねそんな感じに思います。
松並＠DNVGL
-----Original Message-----
From: sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Takao Okubo
Sent: Tuesday, February 20, 2018 8:56 AM
To: sig...@googlegroups.com
Subject: Re: [sigsta] Re: 脅威分析と脆弱性分析の違い
> ****************
>
>
> --
> confidential information and/or information protected by intellectual
> property rights for the exclusive attention of the intended addressees
> named above. If you have received this transmission in error, please
> immediately notify the sender by return e-mail and delete this message
> and its attachments.
> Unauthorized use, copying or further full or partial distribution of
> this e-mail or its contents is prohibited.
> **********************************************************************
> ****************
>
> このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録し
> ているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信してください。
> その他のオプションについては https://groups.google.com/d/optout にアクセ
> スしてください。
--
大久保 隆夫 (OKUBO Takao, Ph.D.)
情報セキュリティ大学院大学 情報セキュリティ研究科
ok...@iisec.ac.jp
--
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Seiji Munetoh
多分、(b) 脅威分析の結果、認証機能は必須となると思いますので、
設計で通信方式でBLEを選んだ場合に、BLEのペアリングについてどうすべきかの議論がなされると思います。
実装レベルになると、SpoofingやMITMやReplayなどの攻撃に対して、BLE周りの実装に脆弱性がないか心配することになります。
松並さんの例で話が前後する感じの原因は「認証」という機能要求が最初にきちんと明示されないからのような気がします。
設計レベルの脆弱性を潰す有効な手法が脅威分析だと思います。
実際は設計を初めて気がつく脅威もあると思いますので、その辺はAgileに回せればよいかと
どうでしょうね？
Matsunami, Masaru
藤倉様、みなさま
松並です。藤倉様の並行処理に関する文書を確か2000年頃に拝見したことがあります！
（しかし並行処理の勉強は十分できないうちに、セキュリティ面の墜ちてしまいました。）
実現手段として「Eメール送信機能」を選択したことで、発生したのは悪用されて社会に迷惑を掛ける、このことで社会的信用を落とすことが脅威なのだと思います。社会に迷惑を掛けても気にしない会社の場合は、悪用されることでサーバー負荷が増えて本来機能に支障が出るとか電気代が勿体ないとかが脅威になるのではないかと思います。
はい。同意です。社会的な迷惑となることを「被害と感じるかどうか」は人次第（心や価値観の問題？）なので、組織のセキュリティポリシーで定めて、セキュリティポリシーに基き判断する流れが目指すべき姿になるのだと思います。
社会に迷惑を掛けないことがすでに要求としてコンセプトフェーズで定義してあれば、メールサーバを選択した段階でメールサーバーの脆弱性を評価できるのではないかと思います。個人的には、「Eメール送信機能を第三者に利用されてはならない」はシステムあるいはサーバーレベルの要求だと思います。「機能を第三者に利用されてはならない」であればトップレベル要求だと思います。
これも同意です。コンセプトフェーズから要求を捉えることができればそれが一番ですし、それができない場合に備えて後続のフェーズでも要求を拾えるようにしてある（各フェーズで脅威分析も一応実施する）のがよいと思います。例えば次のような感じでしょうか。
「セキュリティポリシー：他に迷惑をかけるシステムはつくらない」を定めている組織においては、コンセプトフェーズの開発アイテム定義あたりで、トップレベルのセキュリティ要求として「セキュリティ要求：他に迷惑をかけるシステムはつくらない」をあらかじめ定めると思います。そしてシステムレベル（やSWレベル）の設計において設計者が「Eメール送信機能」を見たときに、「セキュリティ要求：他に迷惑をかけるシステムはつくらない」を侵害する「攻撃方法：第三者がEメール送信機能を利用する」を思い付き、もしオープンリレーできてしまうEメール送信機能の設計がなされた後であるならば「脆弱性：Eメール送信機能がオープンリレーできてしまう」を発見することになります。
逆に、こうしたセキュリティポリシーを定めていない組織においては、システムレベル（SWレベル）で「脅威分析」することで「脅威（候補）：第三者がEメール送信機能を利用する」を発見することができます。ただしこの段階では「セキュリティポリシー：他に迷惑をかけるシステムはつくらない」はまだ存在していないため、この脅威（候補）が被害に位置づける・しないを設計者が判断することになります。被害に位置づけた場合、「脅威：第三者がEメール送信機能を利用する」を発見したことになります。その後の「脆弱性分析」により同脅威を実現できるシステムの特性/欠陥として「脆弱性：Eメール送信機能がオープンリレーできてしまう」を発見することになります。
※ MLのやり取りによって理解が深まった気がします！
松並＠DNVGL
Matsunami, Masaru
松並です。ありがとうございます！
> 設計で通信方式でBLEを選んだ場合に、BLEのペアリングについてどうすべきかの議論がなされると思います。
> 実装レベルになると、SpoofingやMITMやReplayなどの攻撃に対して、BLE周りの実装に脆弱性がないか心配することになります。
■設計レベルの脆弱性を潰す
> 設計レベルの脆弱性を潰す有効な手法が脅威分析だと思います。
「脅威分析」もそうですが「脆弱性分析」も含まれると考えてよいでしょうか？用語定義的には↓のように考えています。
(b) 脅威分析 ＝ 脅威を「発見する行為」
(c) 脆弱性 ＝ 脅威を実現できる「システムの特性/欠陥」
(d) 脆弱性分析 ＝ 脆弱性を「発見する行為」
> 松並さんの例で話が前後する感じ・・・
「前後する感じ」というのは↓のケース１とケース２の緑色枠のところが関係しますでしょうか？
https://docs.google.com/viewer?a=v&pid=forums&srcid=MTY0NjgxODIyNzM5MzE0ODE1NTQBMDk1NDY3NzU0ODY1MjM4MDkzNDEBTjZ6Z0pKbXpCQUFKATAuMQEBdjI
ケース２で「攻撃方法」と書いている行為がケース１では「脅威」として表現されています。同じ行為なのに。
ケース１とケース２は最初に着目する設計の抽象度が異なるだけです。このことから「攻撃方法」は抽象度を落とすと「脅威」として見えてくるだけなのかなと思いました。
ケース２で登場する要素の因果関係は次の通りです。
脅威：第三者が金庫を解錠する
↑ 上位の脅威を実現させる
攻撃方法：第三者がスマホアプリになりすまし、解錠コマンドをBLE送信する
↑ 脅威を実現させる
脆弱性：Just WorksでBLEペアリング可能な設計である
これを着目する設計の抽象度でレイヤーを分けてとらえると次のような構造として見えます。レイヤー高からみると「攻撃方法」だったものがレイヤー中の中では「脅威」として見えるだけなのかなと。
────────────────────────────────────────
レイヤー高 脅威：第三者が金庫を解錠する
───────↑ 脅威を実現させる────────────────────────
レイヤー低 脅威：第三者がスマホアプリになりすまし、解錠コマンドをBLE送信する
↑ 脅威を実現させる
脆弱性：Just WorksでBLEペアリング可能な設計である
────────────────────────────────────────
話が前後する感じとは「さっき脅威の話をしていたのにまた脅威の話をしている」ことから前後したように感じるのかと思いました。でもさっきの脅威といまの脅威は異なるレイヤーの脅威だったというのがその原因であるとか。。。
脅威を次のように定義すると、上記2つの脅威をうまく定義できると思いました。
(a) 脅威 ＝ 着目した抽象度の中で表現した、システムにおいて発生しうる事象のうち、
(b) 脅威分析 ＝ 脅威を「発見する行為」
(c) 脆弱性 ＝ 脅威を実現できる「システムの特性/欠陥」
(d) 脆弱性分析 ＝ 脆弱性を「発見する行為」
松並＠DNVGL
-----Original Message-----
From: Seiji Munetoh [mailto:seiji....@gmail.com]
Sent: Tuesday, February 20, 2018 12:57 PM
To: Matsunami, Masaru <Masaru.M...@dnvgl.com>
>> *
>> ****************
>>
>>
>> --
>> confidential information and/or information protected by intellectual
>> property rights for the exclusive attention of the intended
>> addressees named above. If you have received this transmission in
>> error, please immediately notify the sender by return e-mail and
>> delete this message and its attachments.
>> Unauthorized use, copying or further full or partial distribution of
>> this e-mail or its contents is prohibited.
>> *********************************************************************
>> *
Matsunami, Masaru
■その１（2か所）
誤： ↑ 脅威を実現させる
正： ↑ 攻撃方法を実現させる
■その２
誤：レイヤー高からみると「攻撃方法」だったものがレイヤー中の中では「脅威」として
正：レイヤー高からみると「攻撃方法」だったものがレイヤー低の中では「脅威」として
松並＠DNVGL
-----Original Message-----
From: sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Matsunami, Masaru
Sent: Tuesday, February 20, 2018 2:31 PM
To: Seiji Munetoh <seiji....@gmail.com>
Cc: Takao Okubo <ok...@iisec.ac.jp>; sig...@googlegroups.com
[This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
Hitoki Matsuda
アルパインの松田です。
皆さんの議論、興味深く拝見させていただきました。ROMだけでは申し訳ないので私見ですがコメントさせていただきます。
脅威と脆弱性の関係について、私は以下のように捉えています。
脅威：資産に対して起きる望ましくない事象（改竄、盗聴、不正操作、サービス停止などの事象、5W法などで識別）
脆弱性：脅威を顕在化させるためのある攻撃手法に対する弱点 → 裏返すと攻撃が成功するための条件（アタックツリーなどで分析）
脅威に攻撃手法を混ぜてしまうと脅威分析と脆弱性分析の境界が怪しくなります。
そこで脅威を「資産＋望ましくない事象」（What）＋「エントリーポイント」（Where）として識別（脅威分析）し、識別された脅威事象を顕在化させる手段（How）をアタックツリーなどで脆弱性分析することで、どのレベルであっても両者を明確に分離することができると考えています。
松並さんの仰る通り、コンセプトフェーズの脆弱性分析では攻撃手段の分析までしかできないため、分析結果から導出できるのは攻撃に対抗するための機能要求になります。この要求をもとに、システム設計に対して具体的な対策手段を検討し、それらをソフトウェア、ハードウェアをどう組み合わせて実現するか、を設計する（技術要求の導出）ことになると考えています。
私は脅威分析をする際に重要なことは、資産とエントリーポイントを定義して脅威を表現するということと考えています。
「第三者が金庫を解錠する」
この脅威の表現では何が資産なのかよくわかりません。
そこでユースケース図を見ると、金庫に対する操作として
１．解錠する
２．扉を開ける
３．扉を締め施錠する
４．施錠確認する
があります。これらの１－４を実現するために必要な機能を考えると、
１．解錠機能
２．施錠機能
３．施錠確認機能
が考えられます（扉の開け閉めも自動でやるならそれらも扉開閉機能として定義できそう）。
これらの機能を資産として資産に対して起こる望ましくない事象を考えると、
（第三者が）「解錠機能」を「解錠機能インターフェース（仮）」から「不正操作」される
という脅威が考えられます。解錠機能が不正操作されると「第三者が金庫を解錠する」という結果が生じますのでこの望ましくない事象は「第三者が金庫を解錠する」という脅威と同義と考えることができます。
さて、このレベルでは解錠機能の技術仕様などは決まっていませんので、ここで導出されるセキュリティ要求は
「解錠機能は解錠機能インターフェースから不正操作されないこと」
となり、このセキュリティ要求は解錠機能」に割り当てられます。
そしてシステム設計で解除制御をマイコンに割り当て、解除機能インターフェースにBLEを採用した段階でこのセキュリティ要求を読み替えると、
「解除制御機能はBLEから不正制御されないこと」
となり、この要求をさらに詳細化すると、
「第三者がBLEに接続できないようにすること」
「第三者が解除制御機能を不正操作できないこと、解除制御コマンドを第三者に知られないこと」
などが導出され、この要求を満足するためのシステム要求仕様として、
「ペアリングにはSSPを採用すること」
などの対策を導出することができます。
もしシステム設計がすでに完成していてJust Workが採用されていた場合は
「（第三者が）解錠機能を解錠機能インターフェース（仮）から不正操作する」
の脅威に対してシステム設計上の脆弱性を攻撃ツリーなどで分析します。解除機能インタフェースはBLEなので
攻撃成功の条件としては、
・攻撃者が解除インターフェースのBLEに接続できる：Just Workなので接続可能
・攻撃者が解除コマンドを送信できる/攻撃者が解除コマンドを知る：Just Workなのでパケットスニファで盗聴可能
となり、攻撃が成立してしまいます。
そこで、この条件成立に対抗する策としてSSPを採用すると、接続、盗聴ともに対策できることがわかります。
私はこのような具体設計（SYS、HW、SW）に対して攻撃ツリーなどを使う分析が（設計フェーズでの）脆弱性分析と捉えています。
コンセプトフェーズでは、まだ設計が十分にされておらず、実際に出来上がるものが脆弱かどうかすらわからない状態です。なので、脅威に対して考えられる攻撃手法を分析し、その攻撃に対して脆弱にならないようにセキュリティ要求を定義するのですが、これを脆弱性分析と呼ぶのはちょっと違うような気がしています。
いかがでしょうか？
長文、失礼いたしました。
============================================
Hitoki Matsuda
Senior Engineer
Advanced Development DEPT.
ALPINE ELECTRONICS, INC.
20-1, Yoshima Industrial Park
Iwaki, Fukushima, Japan
970-1144
email hit-m...@apn.alpine.co.jp
Phone 0246-36-4111 ext:3770
============================================
-----Original Message-----
From: sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Matsunami, Masaru
Sent: Tuesday, February 20, 2018 2:31 PM
To: Seiji Munetoh <seiji....@gmail.com>
ATTENTION:This e-mail and any files transmitted with it are the property of Alpine Electronics,Inc and/or its affiliates, may be privileged and/or confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited.
注意:このＥメールおよび添付ファイルはアルパイン株式会社および関連子会社の資産であり、法的特権を持つ情報および秘密情報を含んでいる可能性があります。また、宛先とした特定の個人もしくは団体、あるいは、それらが指定する人によってのみ、読まれることを意図しています。もし、あなたがこのＥメールの意図された受信者でないなら、または、誤って送信されたものを受領したと思われる場合は、速やかに送信者へ通知の上、このＥメールを削除してください。また、他の目的への利用、配布、転送、印刷、コピーは固く禁止されています。
________________________________
Matsunami, Masaru
松並です。ご無沙汰しております。ご反応ありがとうございます！
> なので、脅威に対して考えられる攻撃手法を分析し、
> その攻撃に対して脆弱にならないようにセキュリティ要求を定義するのですが、
> これを脆弱性分析と呼ぶのはちょっと違うような気がしています。
同感です。これは「脅威分析 →（攻撃方法導出）→ セキュリティ要求定義」
といった流れであると説明した方が分かりやすいですかね。
結論としては、J3061はあまり脅威分析（Threat Analysis）と脆弱性分析
（Vulnerability Analysis）を意識して区別してなさそうですね。
たとえば 8.4.2 を見ますと・・・
8.4.2 System Level Vulnerability Analysis
The Cybersecurity team … will conduct a vulnerability analysis of the System
to identify potential threats.
なんて書いてありまして、threatsを見つけるためにvulnerability analysisをする
という言い回しになっています。8.4.2の内容を見る限り、これまでの議論でいえば
脅威分析（Threat Analysis）に近い話がvulnerability analysisやvulnerability
assessmentの内容として書かれているようにも見えます。
J3061も（他の脅威分析系の文書と同様に）字面通りに読んではダメですね。
■松田さんの分析の流れについて
違和感まったくありません。以下、ちょっと面白いことを見つけたので補足です。
> 「第三者が金庫を解錠する」
> この脅威の表現では何が資産なのかよくわかりません。
ユースケース図の脅威分析例では「金庫」を資産と捉えています。
そして資産には以下4つの操作が存在するので・・・
２．扉を開ける
３．扉を締め施錠する
４．施錠確認する
被害であると判定したものが「脅威」の事象となります。
松田さんの例では、この資産の抽象度を一段階ブレークダウンしたものに相当すると思います。
金庫という資産は３つの機能資産（解錠機能、施錠機能、施錠確認機能）で構成されている。
ゆえにこの3つの機能資産を保護することが、すなわち金庫を保護することになる。
ここで「２．扉を開ける」に対応する機能資産はありませんけど、これを起点として、
https://sites.google.com/site/sigstaweb/20161020
脅威分析超入門_20161020.pdf のp.49
では、以下のセキュリティ要求を導出しています。
スマホ対応金庫システムが解錠状態であるとき、ユーザーがそれを認識できること
（たとえばスマホと金庫から警報音が鳴るなど）
「資産は情報と機能の2種類」とわたしもよく言いますが、
このケースは拾えないですね。。。
「資産は情報と機能の2種類」というのはコンピュータの中の話であって、
コンピュータの外で起こる脅威を導出するためには別の着眼点が必要ですね。。。
松並@DNVGL
Hitoki Matsuda
＞同感です。これは「脅威分析 →（攻撃方法導出）→ セキュリティ要求定義」
＞といった流れであると説明した方が分かりやすいですかね。
まあ、この作業も「脆弱性分析」と呼ぶとしてしまえばそれで済むのかもしれませんが、完成した製品に脆弱性がないかを欠陥想定から分析するのも「脆弱性分析」と呼ばれますので混乱しやすいですね。
＞ 8.4.2 System Level Vulnerability Analysis
＞ to identify potential threats.
脅威がまず存在し、脅威に対してシステムが持つ弱点が脆弱性なのにこれでは順番が逆です。
＞ユースケース図の脅威分析例では「金庫」を資産と捉えています。
はい、そう理解しています。「金庫」の中身も資産であることには間違いありません。が、「金庫」は情報資産でしょうか？
＞松田さんの例では、この資産の抽象度を一段階ブレークダウンしたものに相当すると思います。
私は、サイバーセキュリティの「脅威」とは「情報資産」に対する攻撃と捉えています。「脅威分析」を実施するにはまず「情報資産」を識別し定義することが必要であり、その作業も「脅威分析」の範疇と考えています。したがって、私の例は「資産の抽象度を一段階ブレークダウンしたもの」に対して「脅威分析」を実施したのではなく、「脅威分析」の一部である「資産識別」の作業によって資産の抽象度が一段階ブレークダウンされた（情報資産が識別された）、と理解しています。
＞ スマホ対応金庫システムが解錠状態であるとき、ユーザーがそれを認識できること
これは極論を言うとスマホ金庫に限らず、普通の金庫でも鍵の閉め忘れはありますのでサイバーセキュリティの脅威とも言えないのかもしれませんね。なので脅威分析で引っかからないのかも。
Matsunami, Masaru
＞＞ユースケース図の脅威分析例では「金庫」を資産と捉えています。
情報資産も資産に含まれますが、次のような性質がある資産に限り情報資産と呼ぶのだと思います。
・その資産は「情報」である
・その資産には Read や Write という Operation が存在する
・その資産に対し、許可しないEntityがReadすると被害発生（Confidentialityが損なわれた）と人間が考える
・その資産に対し、許可しないEntityがWriteすると被害発生（Integrityが損なわれた）と人間が考える
＞＞ スマホ対応金庫システムが解錠状態であるとき、ユーザーがそれを認識できること
＞これは極論を言うとスマホ金庫に限らず、普通の金庫でも鍵の閉め忘れはありますので
なるほどそうですね。これはスコープ定義の問題ですね。
対処したい攻撃の範囲をいわゆるサイバーの範囲だけでOKとするのか、
商品としてみたときのリスクも範囲に含めたいとするのか。
もしサイバー以外も考え出すと、
金庫をチェーンソーでぶった切ることまで考えるのか？という話にも発展しますね。
Matsunami, Masaru
松並です。ご反応ありがとうございます！
確かに！そのようにも捉えることができます。2つの抽象度をまたいだときにそうなりますね。
下図の例でいえば、
レイヤー高の設計情報にて「脅威分析」して見つけた「脅威A」について、
レイヤー低の設計情報にて「脆弱性分析」すると「脅威B」を「攻撃方法」見つけることになりますね。
────────────────────────────────────────
レイヤー高 脅威A：第三者が金庫を解錠する
───────↑ 脅威を実現させる──────────────────────────────────────
レイヤー低 脅威B：第三者がスマホアプリになりすまし、解錠コマンドをBLE送信する
↑ 脅威を実現させる
脆弱性：Just WorksでBLEペアリング可能な設計である
────────────────────────────────────────
またレイヤー高の位置からレイヤー低を見下ろすと、
脅威Bは「第三者が・・・BLE送信できちゃう設計になっている」という「脆弱性」
であると捉えることもできそうです。
なんだか「脅威」「攻撃方法」「脆弱性」についても、
下記のようにSafetyの安全要求の階層構造と同じように見えますね。攻撃者側の要求構造。。。
Safety Goals
↑上位の要求を達成する
Functional Safety Requirements
↑上位の要求を達成する
Technical Safety Requirements
↑上位の要求を達成する
Hardware Safety Requirements + Software Safety Requirements
----
松並 勝 <masaru.m...@dnvgl.com>
機能安全部 / サイバーセキュリティグループ
From: Akira...@sony.com [mailto:Akira...@sony.com]
Sent: Wednesday, February 21, 2018 4:19 PM
To: Matsunami, Masaru <Masaru.M...@dnvgl.com>; hit-m...@apn.alpine.co.jp
Cc: ok...@iisec.ac.jp; sig...@googlegroups.com; seiji....@gmail.com
Subject: RE: [sigsta] Re: 脅威分析と脆弱性分析の違い
安藤@ソニーDNAです。
お疲れ様です。
気になったので、初めてMLに投稿します。
※色々内容の濃い話が読めてとても勉強になります。ありがとうございます。
お二人が挙げた下記のJ3061の記述についての私見です。
前後を読んでいないので正確ではありませんが、脅威分析した時点で洗い出した脅威が実現性を考慮しない(もちろん
分かる範囲で予め考慮すればいいけど十分ではない)ものだとすると、脆弱性分析をすることによって、「より実現
しそうな脅威(potential threats)を特定する(identify)」と読み解けば意味が通る気がするのですが、如何でしょうか？
> ＞ 8.4.2 System Level Vulnerability Analysis
> ＞ The Cybersecurity team … will conduct a vulnerability analysis of
> the System
> ＞ to identify potential threats.
>
> J3061のこの箇所は私も違和感を持ちました。
> 脅威がまず存在し、脅威に対してシステムが持つ弱点が脆弱性なのにこれでは順番が逆です。
-----Original Message-----
From: mailto:sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Matsunami, Masaru
Sent: Wednesday, February 21, 2018 12:45 PM
To: Hitoki Matsuda; Seiji Munetoh
Cc: Takao Okubo; mailto:sig...@googlegroups.com
Subject: RE: [sigsta] Re: 脅威分析と脆弱性分析の違い
松田さん
>> *機能安全部**/ **サイバーセキュリティグループ***
>>
>> *DNV GL - Business Assurance Japan*
>>
>> https://www.dnvgl.jp/assurance/
>>
>> dnvgl
>>
>> *From:*sig...@googlegroups.com [mailto:sig...@googlegroups.com] *On
>> Behalf Of *Toshiyuki Fujikura
>> *Sent:* Monday, February 19, 2018 5:31 PM
>> <mailto:sig...@googlegroups.com>
>> 信してください。
>> その他のオプションについては、https://groups.google.com/d
>> /optout にアクセスしてください。
>>
>> --
>> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に
>> 登録しているユーザーに送られています。
>> このグループから退会し、グループからのメールの配信を停止するには
>> ください。
>> その他のオプションについては https://groups.google.com/d/optout
>> にアクセスしてください。
>>
>> --
>> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に登録
>> しているユーザーに送られています。
>> このグループから退会し、グループからのメールの配信を停止するには
>> さい。
>> その他のオプションについては https://groups.google.com/d/optout にア
>> クセスしてください。
>>
>> --
>> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に登録して
>> いるユーザーに送られています。
>> このグループから退会し、グループからのメールの配信を停止するには
>> その他のオプションについては https://groups.google.com/d/optout にアクセ
>> スしてください。
>>
>> --
>> このメールはGoogle グループのグループ「脅威分析研究会SIGSTA」に登録して
>> いるユーザーに送られています。
>> このグループから退会し、グループからのメールの配信を停止するには
>> その他のオプションについては https://groups.google.com/d/optout にアクセ
>> スしてください。
>>
>>
>> *********************************************************************
>> *
>> **************** This e-mail and any attachments thereto may contain
>> confidential information and/or information protected by intellectual
>> property rights for the exclusive attention of the intended
>> addressees named above. If you have received this transmission in
>> error, please immediately notify the sender by return e-mail and
>> delete this message and its attachments.
>> Unauthorized use, copying or further full or partial distribution of
>> this e-mail or its contents is prohibited.
>> *********************************************************************
>> *
>> ****************
>>
>> --
>> このメールは Google グループのグループ「脅威分析研究会 SIGSTA」に登録し
>> ているユーザーに送られています。
>> このグループから退会し、グループからのメールの配信を停止するには
>> その他のオプションについては https://groups.google.com/d/optout にアクセ
>> スしてください。
>
>
> --
> 大久保 隆夫 (OKUBO Takao, Ph.D.)
> 情報セキュリティ大学院大学 情報セキュリティ研究科
> --
> このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
> にメールを送信してください。
>
> **********************************************************************
> **************** This e-mail and any attachments thereto may contain
> confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
> **********************************************************************
> ****************
>
> --
> このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
> にメールを送信してください。
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
________________________________
ATTENTION:This e-mail and any files transmitted with it are the property of Alpine Electronics,Inc and/or its affiliates, may be privileged and/or confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited.
注意:このＥメールおよび添付ファイルはアルパイン株式会社および関連子会社の資産であり、法的特権を持つ情報および秘密情報を含んでいる可能性があります。また、宛先とした特定の個人もしくは団体、あるいは、それらが指定する人によってのみ、読まれることを意図しています。もし、あなたがこのＥメールの意図された受信者でないなら、または、誤って送信されたものを受領したと思われる場合は、速やかに送信者へ通知の上、このＥメールを削除してください。また、他の目的への利用、配布、転送、印刷、コピーは固く禁止されています。
________________________________
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
________________________________
ATTENTION:This e-mail and any files transmitted with it are the property of Alpine Electronics,Inc and/or its affiliates, may be privileged and/or confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited.
注意:このＥメールおよび添付ファイルはアルパイン株式会社および関連子会社の資産であり、法的特権を持つ情報および秘密情報を含んでいる可能性があります。また、宛先とした特定の個人もしくは団体、あるいは、それらが指定する人によってのみ、読まれることを意図しています。もし、あなたがこのＥメールの意図された受信者でないなら、または、誤って送信されたものを受領したと思われる場合は、速やかに送信者へ通知の上、このＥメールを削除してください。また、他の目的への利用、配布、転送、印刷、コピーは固く禁止されています。
________________________________
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
Hitoki Matsuda
松田＠アルパインです。
コメントありがとうございます。
”to identify potential threats.”
確かに、英語の読み方の問題なのだとは思います。Identifyの意味、使われ方が肝ですね。
【Idenfity】
to recognize something or discover exactly what it is, what its nature or origin is etc
日本語だと「識別する、特定する、それが何であるか知る」なのですが、問題は”Potential threats”がどこから来たかです。
すでに実施された脅威分析では識別されなかった脅威が脆弱性分析で新たに識別されるのか、それとも脅威分析で識別された脅威のうちどれがPotential Threatsなのかが脆弱性分析で識別されるのか。後者であればこの文章は間違いではありません。
”Identify”が、「すでにそこに存在することが明確に判明しているもの」に対してそれが何であるかを識別する、という使われ方であればこの文章は正しいのでしょうね。ただ、絶対にあることは間違いない（存在する）がまだ見つかっていない脅威を識別する、という使われ方だとしたら「順番が逆」と感じます。違いは識別される側の母集合です。更に”Potential”の意味も、脅威分析をするときと脆弱性分析をするときで微妙に変わってきますし…。
英語（日本語も含め？）の意味の捉え方をこねくり回すのは不毛かもしれません。
安藤さんのように素直に読めば問題ないのでしょうね…。
============================================
Hitoki Matsuda
Senior Engineer
Advanced Development DEPT.
ALPINE ELECTRONICS, INC.
20-1, Yoshima Industrial Park
Iwaki, Fukushima, Japan
970-1144
email hit-m...@apn.alpine.co.jp
Phone 0246-36-4111 ext:3770
============================================
-----Original Message-----
From: Akira...@sony.com [mailto:Akira...@sony.com]
Sent: Wednesday, February 21, 2018 4:19 PM
To: Masaru.M...@dnvgl.com; 松田 一樹 Hitoki Matsuda <hit-m...@apn.alpine.co.jp>
Cc: ok...@iisec.ac.jp; sig...@googlegroups.com; seiji....@gmail.com
Subject: RE: [sigsta] Re: 脅威分析と脆弱性分析の違い
安藤@ソニーDNAです。
お疲れ様です。
気になったので、初めてMLに投稿します。
※色々内容の濃い話が読めてとても勉強になります。ありがとうございます。
お二人が挙げた下記のJ3061の記述についての私見です。
前後を読んでいないので正確ではありませんが、脅威分析した時点で洗い出した脅威が実現性を考慮しない(もちろん
分かる範囲で予め考慮すればいいけど十分ではない)ものだとすると、脆弱性分析をすることによって、「より実現
しそうな脅威(potential threats)を特定する(identify)」と読み解けば意味が通る気がするのですが、如何でしょうか？
> ＞ The Cybersecurity team … will conduct a vulnerability analysis of
> the System
> ＞ to identify potential threats.
>
> J3061のこの箇所は私も違和感を持ちました。
> 脅威がまず存在し、脅威に対してシステムが持つ弱点が脆弱性なのにこれでは順番が逆です。
-----Original Message-----
From: sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Matsunami, Masaru
To: Hitoki Matsuda; Seiji Munetoh