ネタ投下：入門的な脅威分析のプレゼン資料

[Matsunami, Masaru (SDNA)]

みなさま

松並＠ソニーDNAです。たまにはネタ投下をと思いまして。

ETWest2016(7/7, 7/8)で入門的な脅威分析の講演させていただきました。
公開資料がWebに掲載されておりますので下記に共有いたします。
質問やツッコミなどございましたら是非MLにお願いします。
夏休みボケ解消に効く頭の体操になると思いますよ。

SEC先端技術入門ゼミ【第8部】 セキュリティ設計（リスク分析）入門
http://www.ipa.go.jp/sec/events/20160707.html
http://www.ipa.go.jp/files/000053950.pdf

--
松並　勝 <masaru.m...@sony.com>
Chief Security Technology Officer
ソニーデジタルネットワークアプリケーションズ株式会社

[e-sh...@ipa.go.jp]

ソニーDNA　松並さんへ

まだお会いもできていないのに質問のメールですみません。

①BLE通信の仕様が読み解け切れいないのですが、偽装ができる可能性は
まったくないということで良かったでしょうか？

あと現状通常使用のユースケースなので比較的単純な仕様になっていると
感じました。でも確かに確認は単純にできることはわかります。

②不便で対象外となっているもので、開けられないは単純に外せない気が
しました。これは物理鍵があるから大丈夫という前提ではないでしょうか
入れたものが自身も取り出せなくなってしまうはやはり考慮が必要なので
はないでしょうか？　金庫内の装置が壊れる・壊される場合は？
かなりズレルけど開錠するように壊される可能性は？

③設定等の管理機能を加えるといろいろ面白くなりそうな気がしました。
1台のみではなく複数台でも可能にするのかどうかとか
設定した端末を紛失した場合の失効手続きはとか
紛失はしていないけど別のに変える機能がある場合、それが本当の持ち主で
あることの確認は？とかいろいろありそうな感じがしました。

といろいろ考えてみたけど通信の偽装以外は結局物理鍵で対応する話みたい
ですね。


IPA　技術本部　セキュリティセンター　情報セキュリティラボラトリー
〒113-6591　東京都文京区本駒込2-28-8
（文京グリーンコートセンターオフィス16階）
TEL：03-5978-7527　FAX：03-5978-7518
塩田　英二　E-mail：e-sh...@ipa.go.jp

--
このメールは Google グループのグループ「脅威分析研究会 SIGSTA」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには sigsta+un...@googlegroups.com にメールを送信してください。
その他のオプションについては、https://groups.google.com/d/optout にアクセスしてください。

[Matsunami, Masaru (SDNA)]

IPA塩田さん、みなさま

松並です。反応ありがとうございます！そういえば書いてませんでしたけど、
この資料は脅威分析のやり方を説明する資料なので、
この例題はわざと脆弱な作りになっています。

> ①BLE通信の仕様が読み解け切れいないのですが、偽装ができる可能性は
> まったくないということで良かったでしょうか？

はい、ご指摘の通り、①このサンプルでのBLE通信の偽装はできます。
わたしもBTやBLEは不勉強でちゃんと勉強していないので間違えているかも
しれませんけど、このサンプルでは次のように考えています。

このサンプルはBTのペアリングが不要な（つまり便利な :-）システムでして、
BTのセキュリティは一切使用しておらず、
アプリ層（通信プロトコル、p.13）でも暗号化や署名/MACを使用していません。

添付PDFは公開資料に含めることができなかったグラフ(若干版が異なります)ですが、
[95]のノードにご指摘の偽装できることについて記載しています。
公開資料では通信プロトコルまで分析しなくても、
p.39で同等の脆弱性を発見したことになっています。

> ②不便で対象外となっているもので、開けられないは単純に外せない気が
> しました。

p.28のリスク値→セキュリティ対応要否の定義の善し悪しに関する違和感ですよね。
ご指摘のように物理鍵で開けることができることから被害は（ユーザーにとって）
受容可能という判断を、この金庫の設計者/会社がしたというサンプルになっています。

こうしたセキュリティのさじ加減は、製品分野や組織によっても適切なものは異なり
ますので、p.28のようなリスク評価基準を「それぞれの組織で用意してね」として、
脅威分析技術そのものからは切り離して考えるようになっています。

適切だと感じるセキュリティのさじ加減はやはり人により異なってしまうものなので、
大切なのは「一貫した基準でセキュリティを作りこんでいます」と説明できることだと
思います。

> 金庫内の装置が壊れる・壊される場合は？
> かなりズレルけど開錠するように壊される可能性は？

物理鍵の解錠メカニズムについては、金庫の歴史があるということで、
添付PDFでは[56]のように「安全性は信頼し得る十分な実績がある。」としています。
このように脅威分析を進めると末端ノードに必ずこのような「信頼する」という部分が
出てきまして、所謂「前提条件」や「ポリシー」と呼ばれるような内容記述になります。

もし物理鍵の解錠メカニズム自体の実績を根拠とする場合に説明力に欠けるならば、
その開錠メカニズムの脅威分析が必要ということになります。
メカニカルな話になりそうなので私は分析できませんけど。。。

＞ ③設定等の管理機能を加えるといろいろ面白くなりそうな気がしました。

それはそうですけど、脅威分析の入門用の例題としてはヘビーになってしまいますね。

＞ 通信の偽装以外は結局物理鍵で対応する話みたい

はい。入門用のサンプルなので、意図して物理鍵の「逃げ」を入れています。

松並