STRIDE の Trust Boundry 内の脅威（攻撃）？
Matsunami, Masaru
SIGSTAのみなさま
DNVGLの松並です。STRIDEをちゃんと理解しようと思いまして、
MSのThreat Modeling Toolを使ってみているのですが理解ができないところがありまして、
ご存知の方がいらっしゃるかと思いましてPOSTしてみます。
（https://docs.microsoft.com/ja-jp/azure/security/azure-security-threat-modeling-tool）
添付の図のように、Trust Boundary（PC）の中にProcess（API）とData Store（DATABASE）を
設置しまして、Data Flow（USERDATA）でつないでみました。
これらの要素はTrust Boundary（PC）内に閉じているので、脅威（攻撃）は想定しないものだと
（Trust BoundaryをまたぐData Flowのところに脅威（攻撃）があると考えるものだと）思って
いたのですが★、Threat Modeling Toolは添付の図のように2つの脅威（攻撃）を生成します。
ID11: Spoofing of Destination Data Store Generic Data Store
DATABASE may be spoofed by an attacker and this may lead to data being written to the attacker's
target instead of DATABASE. Consider using a standard authentication mechanism to identify the
destination data store.
[ご参考：Google翻訳] データベースが攻撃者によって偽装されている可能性があり、データベース
の代わりに攻撃者の標的にデータが書き込まれる可能性があります。 宛先データストアを識別する
ために標準の認証メカニズムを使用することを検討してください。
ID12: Potential Excessive Resource Consumption for Generic Process or Generic Data Store
Does API or DATABASE take explicit steps to control resource consumption? Resource consumption
attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job.
Be careful that your resource requests don't deadlock, and that they do timeout.
[ご参考：Google翻訳] APIまたはデータベースは、リソース消費を制御する明示的な手順を講じますか？
リソース消費の攻撃は扱いにくい場合があり、OSにその仕事をさせることが理にかなっていることも
あります。 リソース要求がデッドロックしないように注意し、タイムアウトが発生するようにして
ください。
知りたいことは、なぜTrust Boundary内に閉じているData Flow（USERDATA）において、
脅威（攻撃）が導出されているのか？ということです。★部分の認識が誤っているのかもしれない
と思ったりしていますが、それならばTrust Boundaryは何のために必要なのかが不明になります。
何かしらご存知のかたはいらっしゃますか？
----
松並 勝 <masaru.m...@dnvgl.com>
機能安全部 / サイバーセキュリティグループ
DNV GL - Business Assurance Japan
https://www.dnvgl.jp/assurance/
**************************************************************************************
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.
**************************************************************************************
Kiyotaka ATSUMI
# このメールのsignature.ascはPGPによる電子署名です。
松波様
株式会社ラック IoT技研の渥美です。
先日は簡単な挨拶しかできず失礼しました。
私の理解ですが、USERとAPIの境界に生じる脅威の列挙を試みている状況下で、APIとDATABASE(USERDATA)の脅威を導くことは直接的にはできないと思っています。実際には私がデータフロー図から脅威分析する業務を行ったときは、
その１
+------+ REQUEST | +--------------------------+
| USER +---------|---------+ System handling USERDATA |
-------+ | +--------------------------+
Trust
Boundary
そに２ +-------------------|---------------------+
+------+ REQUEST | +-----+ USERDATA | +----------+ |
| USER +---------+--+ API +----------|--------+ DATABASE | |
-------+ | +-----+ | +----------+ |
+-------------------|---------------------+
Trust
Boundary
の２回に分けで、分析します。こうすると、USERDATAにかかる脅威分析を直接的に取り扱えます。
その後、２つの結果を組み合わせた脅威が具体化するかどうかについては、AttackTreeを用いて評価しました。
--
Kiyotaka ATSUMI, Ph.D.
Director of IoT Technical Laboratory,
CYBER GRID JAPAN, LAC Co., Ltd.
>
> *松並 勝*<masaru.m...@dnvgl.com>**
>
> *機能安全部**/ **サイバーセキュリティグループ***
>
> *DNV GL - Business Assurance Japan*
>
> https://www.dnvgl.jp/assurance/
> dnvgl
>
>
>
>
> **************************************************************************************
> 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」に登録し
> ているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには
> sigsta+un...@googlegroups.com
> <mailto:sigsta+un...@googlegroups.com> にメールを送信してください。
> その他のオプションについては https://groups.google.com/d/optout にアクセ
> スしてください。
Matsunami, Masaru
松並です。会話に参加していただいてありがとうございます。
まず最初に、渥美さんの分析方法はあっていると思います。渥美さんのASCIIアートをMSのTMT（Threat Modeling Tool）で書いてみたものを添付します※。わたしが最初に添付した図との違いは、「Database Service」というTrust Boundary（薄い赤色の破線の矩形領域）を追加していることです。この追加によりID14~19の脅威が導出されています。Trust Boundaryをどのように設置するかは分析者がシステムをどのように捉えているのかに依存しますから、それによって導出される脅威に差ができるのは自然です。
※Trust BoundaryはLineで表現する方法とBoxで表現する方法がありますが（その違いもまだ分かっていないですが）、セキュリティのZoneの概念みたいに見えるBoxが好きなので、Boxで表現してみました。
もともとの質問で興味があったのは、（Trust Boundaryの設置の仕方はおいといて）STRIDE分析という脅威を識別（発見）する方法論についてでした。ちょうど渥美さんのASCIIアートから作りましたTMTの結果と、わたした最初のメールで添付したTMTの結果があるので比較しますと、Trust Boundary「Database Service」の有り無しによって脅威ID14~19の有り無しが生じていて、この動作には納得できます。一方、ID11、ID12の脅威はTrust Boundary「Database Service」の有り無しに関わらず導出されていることが（Trust BoundaryをまたがないData Flowから脅威が導出されていることが）STRIDE分析のやり方（Trust BoundaryをまたぐData Flowに着目し、STRIDEの観点で脅威を連想・導出するという方法）として納得できないなぁと思っておりますところです。
松並＠DNVGL
Kiyotaka ATSUMI
# このメールのsignature.ascはPGPによる電子署名です。
松波様
おっしゃっていることが分かりました。
Title: Spoofing of Destination Data Store Generic Data Store
は中身が見えているからそう言えなくもありませんが、カーハッカーズハンドブックの例示で考える場合は、APIとDBは一つの箱になっていてデータが保存されるかどうかすら分からない状況で調査を始めるようにとの記述があります。その作法に従えばデータをストアするという言葉すら出てこないはずです。
1. UNDERSTANDING THREAT MODELS
http://opengarages.org/handbook/ebook/#calibre_link-443
脅威導出がどういう実装になっているのか興味があります。
# カーハッカーズハンドブック（日本語版）絶賛発売中！！！
https://www.oreilly.co.jp/books/9784873118239/
--
Kiyotaka ATSUMI, Ph.D.
Director of IoT Technical Laboratory,
CYBER GRID JAPAN, LAC Co., Ltd.
Matsunami, Masaru
渥美様、みなさま
松並＠DNVGLです。図を見やすくするためにHTMLメールにしました。HTMLメールが嫌いな方、すみません。
カーハッカーズハンドブックの例示で考える場合は、APIとDBは一つの箱になっていてデータが保存されるかどうかすら分からない状況で調査を始めるようにとの記述があります。
STRIDE分析する前にDFDを作成しますが、そのDFD作成においてまず最初にContext diagramと呼ばれる最も抽象度の高いDFDを書くべきとのことですね。↓のMS本p.110にContext diagramのことが書いてありますね。
THE SECURITY DEVELOPMENT LIFECYCLE
Context diagramの中心となるプロセスを次の段階にブレークダウンすると、下図のようにこれまで添付していたDFD（Level-0 DFD）になります。（この図ではBoundaryをLineにしてみました。カーハッカーズ・ハンドブックでは↑のMS本でいうContext diagramをLevel-0と表現しているようですね。）ただこれも分析手順の話ですし、疑問点はSTRIDEによる脅威の導出方法なので、これはちょっと別の話です。
> 脅威導出がどういう実装になっているのか興味があります。
ですよね。ここがわたしの知りたいところでこのPOSTの起点になっている疑問です。一応、↑の本p.119には次のような記載があります。DFD内の個々の要素のそれぞれに、要素タイプに応じて検討すべき脅威をXで示してありまして、機械的手順により脅威を導出できるというものです。
ただTable 9-5の使い方について、本書のこの後を読みましてもtrust boundaryにより脅威の導出をどのように制御するかといった記載はありません。ですがTMTはtrust boundaryの有無により導出する脅威に差があります。。。
SIGSTAのTM本勉強会で勉強した↓には、↑のTable 9-5をSTRIDE-per-Elementと呼んでいまして、さらに別のSTRIDE-per-Interactionというのがありまして、もしかするとTMTはこっちのほうを実装しているのかなと想像したり。。。
http://as.wiley.com/WileyCDA/WileyTitle/productCd-1118809998.html
買いました！カーハッカーズ・ハンドブック1章 脅威モデルの理解に書かれた脅威分析の手法では、DFDやDREADは使っているもののSTRIDEは使っていませんね。Expertなハッカーならシステム構成をDFDで見れば、湧き水のように脅威を思いつくでしょうからSTRIDEは要らないんでしょうJ
松並＠DNVGL
-----Original Message-----
From: sig...@googlegroups.com [mailto:sig...@googlegroups.com] On Behalf Of Kiyotaka ATSUMI
Sent: Monday, July 2, 2018 1:03 PM
To: Matsunami, Masaru <Masaru.M...@dnvgl.com>; sig...@googlegroups.com
Cc: kiyotak...@lac.co.jp
Subject: Re: [sigsta] STRIDE の Trust Boundry 内の脅威（攻撃）？
# This mail may have signature.asc as a PGP e-signature.
# このメールのsignature.ascはPGPによる電子署名です。
松波様
株式会社ラックの渥美です。
--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。
Hitoki Matsuda
松並様、みなさま
松田＠アルパインです。HTMLメールは歓迎します（文字化けしないので）。
TMT2016を試用してみました。
Trust Boundaryを定義しない場合、識別される脅威は４つ。
そのうちID34、ID35は松並さんが疑問に思われたものです（DATABASEのなりすまし、API/DATABASEに対する負荷攻撃）。
つまりこの2つはTrust Boundaryに関係なく、Elementとその相互の関係から識別される脅威のようですね。
Trust Boundaryがないと、信用できるものがないのですべての脅威が識別されるかというとそうではないようです。
ということは、TMTの脅威識別はSTRIDE per-ElementやSTRIDE per-Interactionのようなテーブル、Element間の相互作用（Data Flow）に加えてTrust BoundaryとElementの関係も使っていることは間違いなさそうですね。でも、ID34のDATABASEのなりすまし（Spoofing）はSTRIDE per-ElementでもSTRIDE per-Interactionでも導出できなさそう（Data StoreはSに☓がついていない）なので、何か秘密のロジックがありそうです。
==========================================
Hitoki Matsuda
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
============================================
rom: sig...@googlegroups.com [mailto:sig...@googlegroups.com]
On Behalf Of Matsunami, Masaru
Sent: Monday, July 2, 2018 6:42 PM
To: Kiyotaka ATSUMI <kiyotak...@lac.co.jp>; sig...@googlegroups.com
Subject: RE: [sigsta] STRIDE の Trust Boundry
内の脅威（攻撃）？
渥美様、みなさま
松並＠DNVGLです。図を見やすくするためにHTMLメールにしました。HTMLメールが嫌いな方、すみません。
カーハッカーズハンドブックの例示で考える場合は、APIとDBは一つの箱になっていてデータが保存されるかどうかすら分からない状況で調査を始めるようにとの記述があります。
STRIDE分析する前にDFDを作成しますが、そのDFD作成においてまず最初にContext diagramと呼ばれる最も抽象度の高いDFDを書くべきとのことですね。↓のMS本p.110にContext diagramのことが書いてありますね。
THE SECURITY DEVELOPMENT LIFECYCLE
Context diagramの中心となるプロセスを次の段階にブレークダウンすると、下図のようにこれまで添付していたDFD（Level-0 DFD）になります。（この図ではBoundaryをLineにしてみました。カーハッカーズ・ハンドブックでは↑のMS本でいうContext diagramをLevel-0と表現しているようですね。）ただこれも分析手順の話ですし、疑問点はSTRIDEによる脅威の導出方法なので、これはちょっと別の話です。
> 脅威導出がどういう実装になっているのか興味があります。
ですよね。ここがわたしの知りたいところでこのPOSTの起点になっている疑問です。一応、↑の本p.119には次のような記載があります。DFD内の個々の要素のそれぞれに、要素タイプに応じて検討すべき脅威をXで示してありまして、機械的手順により脅威を導出できるというものです。
--
このメールは Google
グループのグループ「脅威分析研究会 SIGSTA」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com
にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout
にアクセスしてください。
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
松田様、みなさま
松並＠DNVGLです。ご反応いただいてありがとうございます！（なんか変な日本語ですが。）
つまりこの2つはTrust Boundaryに関係なく、Elementとその相互の関係から識別される脅威のようですね。
そのような動きですよね。Templateにthreat generation rule(includeとかexcludeとか)が記述されているようなのですが、Templateの記述を覗いてみたら結構複雑でして、もしかすると単にTemplateの記述ミスの可能性もゼロではありません。ということで↓のようにMSのThreat Modeling ToolのTeamに問い合わせメールしてみております。T2（ターミネータ？）という方が調査してくれるそうです。返事がありましたら共有いたします。
Hello Matsunami,
Thank you for contacting Threat Modeling Tool Support Team. We have created the VSTS Task# 2669155 to track this issue. Your issue is escalated with standard urgency. T2 will begin investigation as soon as possible, but no later than 2-3 business days.
(FILTERED)
Security Services Operations Center
From: Matsunami, Masaru <Masaru.M...@dnvgl.com>
Sent: Monday, July 2, 2018 3:56 AM
To: Threat Modeling Tool External Support <tmtext...@microsoft.com>
Subject: Why does the threat modeling tool generates threats inside of a trust boundary?
Dear Threat Modeling Tool team,
I tried to post the following question to the https://social.msdn.microsoft.com/Forums/en-US/home?forum=sdlprocess, but an error ‘Body text cannot contain images or links until we are able to verify your account.’ occurred. So I am sending this email to you.
I'm interested in a threat generating rule of the Microsoft Threat Modeling Tool(TMT). I'm using it with version 7.0.40724.1.
I drawed very simple diagram, an attached PNG file, in order to understand the role of a trust boundary in TMT’s threat generation. In this diagram, PROC and DB are placed inside of the same trust boundary, as a machine perimeter, and both have no connection to outside the boundary. So I think both are safe, and the TMT doesn't generate any threats. But it generates two threats as shown in the PNG.
Of course If I put another trust boundary between the PROC and the DB, TMT generates more threats. It makes sense because new trust boundary means the gap of the privilege level between them.
What I want to know is the reason why TMT generates threats on the DATAFLOW, although the PROC and the DB are placed in same privilege level.
Best regards,
Masaru Matsunami
DNV GL - Business Assurance Japan
Matsunami, Masaru
みなさま
続報です。MSからお返事がないので催促してみたら、窓口の人が「T2チームに催促する」とお返事をもらいました。つまり進展は1か月ありませんでした。面倒な質問をしてしまったのでしょうか。。。以上、報告でした。
松並＠DNVGL
Matsunami, Masaru
みなさま
DNVGLの松並です。Microsoftから3か月前の質問に回答がありましたのでご報告します。7月にこんな質問をMicrosoftにしていました。
I'm interested in a threat generating rule of the Microsoft Threat Modeling Tool(TMT). I'm using it with version 7.0.40724.1.
I drawed very simple diagram, an attached PNG file, in order to understand the role of a trust boundary in TMT’s threat generation. In this diagram, PROC and DB are placed inside of the same trust boundary, as a machine perimeter, and both have no connection to outside the boundary. So I think both are safe, and the TMT doesn't generate any threats. But it generates two threats as shown in the PNG.
Of course If I put another trust boundary between the PROC and the DB, TMT generates more threats. It makes sense because new trust boundary means the gap of the privilege level between them.
What I want to know is the reason why TMT generates threats on the DATAFLOW, although the PROC and the DB are placed in same privilege level.
そして今朝帰ってきた回答はこちら。That’s a great question! That’s one of the current limitations of… というあたりから、Threat Modeling Toolの動きが変では？という指摘は正しかったようです。ツールのルールエンジンとルール記述文法に制約があるというのが原因らしいのですが、、、このツールの動きはよく分かりません。このツールはとても有名ですが、気を付けて使う必要があるということですね。
Hello Matsunami,
Apologies for the delay on this.
That’s a great question! That’s one of the current limitations of the rules engine and grammar in that we cannot write a rule that is triggered due to the presence (or absence) of a specific stencil type within (or outside) of a trust boundary box. The rules engine and grammar support data flow centric rules (e.g. source/ target being a specific stencil type, or flow crossing a boundary). You can see examples of rules in the template that is published in our public GitHub repo at: https://github.com/Microsoft/threat-modeling-templates/blob/master/Azure%20Cloud%20Services.tb7.
For example, on line 2070:
<GenerationFilters>
<Include>flow crosses 'SE.TB.TMCore.AzureTrustBoundary'</Include>
<Exclude>flow.23e2b6f4-fcd8-4e76-a04a-c9ff9aff4f59 is 'No'</Exclude>
</GenerationFilters>
Hope this helps,
以上、ご報告まで。
追伸：drawの過去形はdrewですね。。。
