セキュリティ設計（リスク分析）入門具体的な被害を連想する 27...

セキュリティ設計（リスク分析）入門

ソニーデジタルネットワークアプリケーションズ株式会社

Chief Security Technology Officer

松並勝 <[email protected]>

Copyright 2016 Sony Digital Network Applications, Inc. 1

自己紹介

松並勝Chief Security Technology Officer

ソニーデジタルネットワークアプリケーションズ株式会社

踏み台攻撃の被害者2000年秋にレンタルサーバーが踏み台攻撃に遭い、2001年1月からセキュリティ技術を学ぶためにセキュリティ業界へ

セキュアなソフトウェア開発セキュアコーディング、セキュリティ設計といった、最初からセキュアにソフトウェアをつくる方法論の普及啓発活動に取り組む。主な成果物に以下のようなものがある

2002年 IPAセキュア・プログラミング講座http://www.ipa.go.jp/security/awareness/vendor/programmingv1/

2012年～ JSSEC Androidアプリのセキュア設計・セキュアコーディングガイドhttps://www.jssec.org/report/securecoding.html


ソフトウェア開発におけるセキュリティ施策


脆弱性診断（疑似攻撃）

仕様検証設計実装（コーディング）

ソースコード静的解析

セキュリティ設計（脅威分析）

設計文書ソースコード

実行バイナリ

分析対象

施策

開発工程

• 脆弱なコーディングを発見

• 広く実施されるようになってきている

• 脆弱な仕様や設計を発見

• システムが安全であることを説明

• まだまだ普及していない

・・・

・・・

セキュリティ設計（セキュリティを考慮した設計）の難しさ

• 扱う情報に様々なタイプがあり混乱する

• 漏れなく対策できているのかとても心配になる


どんな攻撃者がいるのか？

何が狙われるのか？

どんな脅威（攻撃）があるのか？

どのように防御するのか？

正しく暗号技術は使えているか？

鍵管理はどうするのか？

想定した攻撃に漏れはないのか？

防御に漏れはないのか？

セキュリティ設計技術（≒脅威分析技術）

• さまざまなタイプの情報を交通整理して、論理的に「システムがセキュアである」ことを説明する技術（＝セキュアなシステムを作る技術）


脅威分析は難しい・・・


https://www.amazon.co.jp/dp/4891004576http://as.wiley.com/WileyCDA/WileyTitle/productCd-1118809998.html

脅威モデルセキュアなアプリケーション構築

2005年Frank Swiderski, Window Snyder 著

●モデルによってセキュリティを可視化●STRIDEによる6種類の脅威の識別

関連書籍

Threat modelingDesigning for security

2014年Adam Shostack 著


脅威分析

もっと簡単にならんのか

投影のみ

投影のみ

投影のみ

投影のみ

投影のみ

投影のみ

10年以上「簡単にする」試行錯誤を重ねてきた


2006年 RSA Conference Japan 2010年 RSA Conference Japan 2015年 WOCS12th (JAXA/IPA)

今日の結論

• セキュリティ設計は実は難しくないので、みなさん始めましょう！

• この後は、セキュリティ設計が「簡単である」ことをご覧に入れます。


混沌の世界から明瞭な世界へ

けんこ

「賢庫」スマホ対応金庫。

設計文書

Ver. 20160615

10

カシコイキンコ

Copyright 2016 Sony Digital Network Applications, Inc.

商品概要

• スマホで開錠できる個人用途向け金庫

• 開錠されたら手動で扉を開けることができる

• 扉を閉めると施錠される

• 付属の物理鍵でも開錠できる

11Copyright 2016 Sony Digital Network Applications, Inc.

システム構成• スマホと金庫はBLEで通信。BLE搭載マイコンがスマホからの開錠要求を受信し、開錠メカを通じて金庫の鍵を開ける。

12

BLE


開錠メカ BLE搭載マイコン

通信プロトコル• スマホから要求パケットを送信すると、金

庫が応答パケットを返してくる

– パケットロストを想定しスマホは応答パケットを受信するまで再送を繰り返す

– 再送間隔は0.1秒、最大1秒間まで再送し、応答がなければアプリで通信エラー表示

– パケットデータエラーはBLEのCRCで担保されるので想定しない

• パケット形式

– 状態要求とその応答

– 開錠要求とその応答

– 応答の★は00H施錠状態、01H開錠状態

– シリアル番号はスマホがインクリメンタルに発番する値で、金庫が発する応答パケットのシリアル番号は対応する要求パケットのシリアル番号をそのまま使う

シリアル番号2bytes

01H1byte


★1byte


02H1byte


★1byte


金庫の物理構成

マイコン部

扉

保管領域

横から見た断面図

マイコン部は金庫の堅牢な筐体によって物理的に守られている

14

USBで電源供給


専用アプリ

• Androidアプリ

• Google Playで配信

• 開錠ボタンで金庫を開錠

• 金庫の施錠状態（開錠状態か施錠状態か）を表示

• BLE通信圏外のときは圏外と表示

15

開錠

賢庫アプリ状態表示

操作



セキュリティ設計

セキュリティ設計の全体像

• 大きく分けて３つの作業から構成される

17

作業の名称作業の内容

セキュリティ要件定義

対象システムのセキュリティが十分であるとはどういうことかを明らかにする

セキュリティ設計分析

その通りに対象システムが作られているかどうかを確認する

セキュリティ設計変更

その通りに対象システムが作られていないとき、必要な設計変更を行う




要件を満たすまで繰り返す


ユースケース図を使った要件定義

• ユースケース図がなければ作図する

19

スマホ対応金庫システム

ユーザー

開錠する

扉を閉め施錠する

ユースケース図

施錠確認する

扉を開ける


アクター

• セキュリティを考えるので第三者の存在もアクターに含める

20

アクター説明

ユーザー当該金庫の所有者

第三者他のアクターに含まれない人物

アクター一覧

第三者


ユーザー

開錠する



施錠確認する

扉を開ける


（アクター, 資産, 操作）→デキゴト

• システムで生じるデキゴトはアクター、資産、操作の組合せで表現できる

21

アクター資産操作

ユーザー（が）

スマホ対応金庫システム（で）

開錠する

扉を開ける


施錠確認する

第三者（が）

開錠する

扉を開ける


施錠確認する

デキゴト一覧

第三者


ユーザー

開錠する



施錠確認する

扉を開ける

資産

操作





開錠する

扉を開ける


施錠確認する

第三者（が）

開錠する

扉を開ける


施錠確認する

良いデキゴト

• アクターとユースケースの接続線は良いデキゴトを表現

22

デキゴト一覧

第三者


ユーザー

開錠する



施錠確認する

扉を開ける





開錠する

扉を開ける


施錠確認する

第三者（が）

開錠する

扉を開ける


施錠確認する

第三者


ユーザー

開錠する



施錠確認する

扉を開ける

悪いデキゴト

• 接続のないアクターとユースケースの組合せは悪いデキゴトになる

23

デキゴト一覧


悪いデキゴト（妨害）

• 良いデキゴトを邪魔する妨害があると、それも悪いデキゴトになる

24

デキゴト一覧（妨害観点）


ユーザー（が）スマホ

対応金庫システム（で）

開錠を妨害する

扉を開けることを妨害する

扉を閉め施錠することを妨害する

施錠確認を妨害する

第三者（が）





第三者


ユーザー

開錠する



施錠確認する

扉を開ける

妨害

妨害

妨害

妨害



ユーザー（が）スマホ

対応金庫システム（で）





第三者（が）





悪いデキゴト（妨害）

• ユーザーが（ユーザー自身を）妨害するのは自業自得なので削除

25

デキゴト一覧（妨害観点）

削除第三者


ユーザー

開錠する



施錠確認する

扉を開ける

妨害

妨害

妨害

妨害


悪いデキゴト＝脅威事象

悪いデキゴト一覧アクター資産操作

第三者スマホ対応金庫システム

開錠する

扉を開ける


施錠確認する





脅威事象一覧脅威事象一覧

第三者がスマホ対応金庫システムを開錠する

第三者がスマホ対応金庫システムの扉を開ける

第三者がスマホ対応金庫システムの扉を閉め施錠する

第三者がスマホ対応金庫システムを施錠確認する

第三者がスマホ対応金庫システムの開錠を妨害する

第三者がスマホ対応金庫システムの扉を開けることを妨害する

第三者がスマホ対応金庫システムの扉を閉め施錠を妨害する

第三者がスマホ対応金庫システムの施錠確認を妨害する

26

文にする


具体的な被害を連想する

27

脅威事象一覧被害の有無想定される被害内容

第三者がスマホ対応金庫システムを開錠するあり第三者に金庫の扉を開けられ、中身（金塊など）を盗まれる

第三者がスマホ対応金庫システムの扉を開けるあり第三者に金庫の中身（金塊など）を盗まれる


なし第三者が金庫の扉を閉め施錠すること自体は特に問題となることはない（むしろ第三者は扉を開けて金庫の中身を盗むだろう）

第三者がスマホ対応金庫システムを施錠確認するあり

第三者に金庫の開錠タイミングを知られてしまい、ユーザーより先に扉を開けられ、金庫の中身（金塊など）を盗まれる

第三者がスマホ対応金庫システムの開錠を妨害するあり

金庫の中身（金塊など）が盗まれることはないが、金庫の中身を取り出せないという不便がある


あり金庫の中身（金塊など）が盗まれることはないが、金庫の中身を取り出せないという不便がある

第三者がスマホ対応金庫システムの施錠を妨害するあり

施錠したはずなのに実は開錠状態であると、第三者に金庫の中身（金塊など）が盗まれる


あり金庫の中身（金塊など）が盗まれることはないが、施錠確認できないという不便がある

連想する

機械的に生成したデキゴト↑を人間の感覚で点検し、被害にならないものを除去。Copyright 2016 Sony Digital Network Applications, Inc.

被害の大きさから対策の要否を判断する

• 判定基準の単純な例（本入門用）

• 一般にはもう少し複雑なものが、業界・組織の状況に合わせて用意される– 被害1回の被害度合い × 被害が発生する頻度 → リスク値

– リスク値 → セキュリティ対策の頑張り度合い、など

28

リスク評価基準の例

リスク値評価基準セキュリティ対策の要否

財産被害ユーザーの財産に被害が及ぶ必要

不便ユーザーの利便性が損なわれる不要

被害なし何ら被害が生じない不要


リスク評価に基づき対策の要否を判断する

29

脅威事象一覧有無想定される被害内容リスク値対策要否


あり第三者に金庫の扉を開けられ、中身（金塊など）を盗まれる

財産被害必要


あり第三者に金庫の中身（金塊など）を盗まれる

財産被害必要


なし第三者が金庫の扉を閉め施錠すること自体は特に問題となることはない・・・

被害なし不要


あり第三者に金庫の開錠タイミングを知られてしまい・・・、金庫の中身（金塊など）を盗まれる

財産被害必要

第三者がスマホ対応金庫システムの開錠を妨害する


不便不要



不便不要

第三者がスマホ対応金庫システムの施錠を妨害する

あり施錠したはずなのに実は開錠状態であると、第三者に金庫の中身（金塊など）が盗まれる

財産被害必要


あり金庫の中身（金塊など）が盗まれることはないが、施錠確認できないという不便がある

不便不要

評価する



脅威事象一覧想定される被害内容セキュリティ要件備考


第三者に金庫の扉を開けられ、中身（金塊など）を盗まれる

第三者はスマホ対応金庫システムを開錠できないこと


第三者に金庫の中身（金塊など）を盗まれる

スマホ対応金庫システムが開錠状態であることをユーザーが認識できること

開錠状態の金庫は誰でも扉を開けることができてしまうので、第三者が扉を開けること自体を防ぐことはできない。ユーザーの不注意により開錠状態のまま金庫が放置されることがないように対策。


第三者に金庫の開錠タイミングを知られてしまい、ユーザーより先に扉を開けられ、金庫の中身（金塊など）を盗まれる

第三者はスマホ対応金庫システムを施錠確認できないこと

第三者がスマホ対応金庫システムの施錠を妨害する

施錠したはずなのに実は開錠状態であると、第三者に金庫の中身（金塊など）が盗まれる

第三者がスマホ対応金庫システムの施錠を妨害できないこと

30

要件としてまとめる



• ４つのセキュリティ要件が定義できた













セキュリティ要件





セキュリティ設計分析（と設計変更）














• それぞれのセキュリティ要件が達成されるようにシステムを設計／変更すること

1. まず現状設計で達成できているか確認する

2. もし未達である箇所があれば、設計を変更する


セキュリティ要件





• ルートノードが成立する根拠をツリー状に表現

• ノード分解（左ノードを右ノード群でより具体的に表現すること）を繰り返す。これが難しい



実はパターンでノード分解できる

• パターンがあれば悩まずサクサク分解できる


パターン「攻防切り替え」パターン「IFと構成要素で分解」

ブラックボックス

表面IFへの攻撃

構成要素への攻撃攻撃できないことを説明しようとする

攻撃できちゃうことを説明しようとする

NOT


• 機械的にパターンを適用してノード分解できる


パターン「攻撃方法ごとに分解」

パターン「攻撃成立条件で分解」



パターン「資産の存在場所で分解」

末端ノードにはTRUEまたはFALSEの根拠を記載


• ライフサイクルを通して、物理鍵は第三者の手に渡ることがないことが判明

脆弱性も発見できる

• 一方、第三者はスマホを使って金庫を開錠できることが判明

• スマホアプリを認証していないことが原因


原因追跡

TRUEになってはいけない

設計変更して認証の仕組みを導入

まだまだある、パターンによるノード分解


パターン「構成要素の悪用」

なんのこれしき、パターンによるノード分解


パターン「マイコン攻撃の分解パターン」

パターン「API攻撃の分解パターン」














セキュリティ要件１の設計分析図要件２の・・・

要件３の・・・要件４の・・・

すべてのセキュリティ要件を達成している説明になる

まとめ

• ユースケース図を使ったセキュリティ要件定義の例を紹介した– 他にもRWX法やSTRIDE法などがある

• パターンを使ったセキュリティ設計分析の例を紹介した– パターンを充実させれば分析者のセキュリティの

知識不足を補うことができる

• いずれも単純な手順で実施できるため、みなさんもセキュリティ設計を始められる






今日説明した分析方法を解説した文書


https://www.ipa.go.jp/sec/reports/20151118.html

脅威分析研究会 SIGSTA https://sites.google.com/site/sigstaweb/

• 脅威分析に興味を持つ組織・企業を集め、脅威分析を普及させる活動

• 未開拓である「設計」領域のセキュリティ市場を創造するのが狙い


情セ大大久保隆夫

産総研田口研治

ソニーDNA松並勝

セキュリティ設計（リスク分析）入門具体的な被害を連想する 27...

Documents