はじめに
少し前の私は、「セキュリティのリスクアセスメント」という言葉を、どこか自分とは遠い作業だと思っていました。専門家が難しい表をにらみながら、勘と経験で「ここが危ない」と当てていく——そんなイメージで、いざ自分が何かを作る側に回っても、どこから手をつければいいのか分からず、結局「動くもの」を優先して後回しにしていました。
でも実際に手順を追ってみると、リスクアセスメントは意外なほど機械的に回せる作業でした。決まった順番があり、埋めるべき表があり、参照すべきカタログもあります。勘で数えるのではなく、道具で洗い出すものだったのです。
この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログです。本シリーズの通し番号では #14 にあたります。
講義の回番号(第13回)とシリーズ通し番号(#14)が1つズレている点だけ、先に断っておきます。第1回だけ前後編の2記事に分けたためです。
想定読者は、少し前の私と同じく「何かを"作る"側にいるけれど、セキュリティのリスク評価を"専門家がやる特別な何か"だと思って手を出せずにいる」人です。題材は IoT ですが、出てくる手法はどれも「何かを作る」開発全般に効く汎用的なものなので、Web やアプリの開発者にも読んでほしい内容です。
この記事で伝えたい軸は1つだけです。
IoTのセキュリティ対策は「作って終わり」にはできません。開発時に脅威を洗い出し、運用時に脆弱性を追い続ける——その一連のプロセスは、既存の標準とツールの組み合わせで回せます。
TL;DR
- 開発時のリスク評価は TARA(脅威分析とリスク評価) という決まった流れで進む。対象把握(DFD)→脅威抽出(5W法)→スコアリング(CRSS)→対策(FT／Common Criteria)。
- 運用時は PSIRT が中心となり、CVE・SCAP・SBOM・MITRE ATT&CK を使って脆弱性を「監視し続ける」。
- これらの手法は IoT 専用ではなく、何かを「作る」開発一般に効く共通言語。既存の道具を組み合わせれば、作る側でもたどれる。
なお、本記事では、講義のあとに動いた部分(規格の版や制度)を執筆時点(2026年7月現在)の一次情報で補足しています。私自身まだ学習中の身なので、間違いがあれば指摘していただけると助かります。
リスクアセスメントの共通言語 ── 資産・脅威・脆弱性・リスク
具体的な手順に入る前に、共通言語を揃えておきます。リスクを考えるときの登場人物は、いつも同じ4つです。
- 資産(asset): 所有者が価値を認める実体。守りたいもの。
- 脅威(threat): 脅威エージェント(攻撃する人やモノ)が資産に悪影響を与える行為。
- 脆弱性(vulnerability): 脅威を成立させてしまう、システム側の欠陥。
- リスク(risk): 上記が組み合わさって生じる、負の影響の度合い。
ポイントは、リスクは「脅威」「脆弱性」「資産の価値」の3つが揃って初めて大きくなるということです。どれかが欠ければリスクは下がります。攻撃したい相手(脅威)がいても、悪用できる欠陥(脆弱性)がなければ通らないし、そもそも守る価値(資産価値)が低ければ守る必要も薄くなります。逆に言えば、セキュリティ対策とは、この3要素のどれかを削るために打つもの(脅威を防ぐ・脆弱性をふさぐ・資産の露出を減らす)、と考えると狙いが定まります。
守るべき資産に対しては、CIA が失われたときの影響を考えます。
- C(機密性): 漏えいしたらどうなるか。
- I(完全性): 改ざんされたらどうなるか。
- A(可用性): 動作不能になったらどうなるか。
そして、リスクをどう分析・評価するかには、大きく3つのアプローチがあります。
| アプローチ | やり方 | 向いている場面 |
|---|---|---|
| ベースラインアプローチ | 定義済みの基準(チェックリスト)と現状を突き合わせる | 一定水準を素早く担保したいとき |
| 非形式的アプローチ | 専門家・有識者の助言に基づいて評価する | 経験知に頼りたいとき |
| 詳細リスク分析 | 資産の価値と、攻撃を受ける可能性を個別に評価する | 精度が要るとき(本記事の主役) |
評価した結果、「これは許容できない」というリスクが出てきたら、対応方針を決めます。選択肢は次の4つです。
| 対応 | 内容 | 例 |
|---|---|---|
| 軽減 | 発生可能性を下げる／影響範囲を狭める | セキュリティ機能の導入 |
| 移転 | システムの外で対応する | 保険、運用委託 |
| 回避 | リスクの原因そのものを取り除く | 危険な機能を提供しない |
| 許容 | リスクを受け入れる | 影響もコストも小さい場合 |
ここまでが一般論です。この記事で追いかける「一本の線」を、先に一望しておきます。開発時に脅威を洗い出して対策を作り込み、出荷後は運用時に脆弱性を監視し続け、新しい脆弱性が見つかればまた開発へ戻る——このループが記事全体の背骨です。
次章からは、この線を前半(開発時)と後半(運用時)に分けて、共通言語を現場にどう落とし込むかを見ていきます。
開発時：脅威を「勘」で数えない ── TARAという地図
開発時のリスクアセスメントは、TARA(脅威分析とリスク評価) という枠組みで進めます。全体像はこうです。
大事なのは、この流れが上から順に埋めていけることです。いきなり「どんな対策をするか」から考えるのではなく、「何を作るのか」「その中の何が資産か」「誰がどこから狙えるか」を先に洗い出す。勘で「たぶんここが危ない」と当てにいかず、順番に道具であぶり出していきます。以下、各ステップを見ていきます。
何を作るのかを描く ── DFDで攻撃の入口を見える化
脅威は「対象を把握しないと」出せません。まず、作るものの構造を、攻撃の侵入経路が見える形でモデル化します。ここで使うのが DFD(Data Flow Diagram、データフロー図) です。DFDは、モジュール間をデータがどう流れるかを描く図で、エントリポイント(攻撃の入口) が一目で分かるのが利点です。
講義ではカーナビを例にしていました。カーナビは、センタサーバ・スマートフォン・SDカード・タッチパネル・ECU(車載の制御ユニット)・保守端末など多くの要素とつながり、それぞれに外部インタフェース(I/F)を持ちます。
携帯網・Bluetooth・SDカード・タッチパネル・UART が、それぞれ攻撃の入口(エントリポイント)になりうる
DFDに何もかも詰め込むと読めなくなるので、モジュールの中身は表に逃がします。モデルをもとに資産を洗い出し、それぞれに CIA のどの属性が重要かを整理します。
| モジュール | 資産 | 重要な属性 |
|---|---|---|
| ナビ | ルート案内機能 | I, A |
| ナビ | 現在地・行先・ルート | C, I |
| ナビ | 地図データ | C, I |
| Bluetooth接続 | Bluetooth認証情報 | C, I |
| ECU | 車両制御機能 | I, A |
| ECU | 診断データ | C, I |
こうして「DFD(構造と入口)」と「表(資産と属性)」の2枚を用意すると、対象物 → 資産 → セキュリティ属性が一気通貫で整理できます。
脅威を機械的に洗い出す ── 5W法と前提条件
資産が見えたら、脅威を網羅的に抽出します。ここで属人性を排除するために使うのが 5W法 です。5つの観点を機械的に組み合わせて脅威を作ります。
| 観点 | 意味 | 抽出元 |
|---|---|---|
| Where | どこから | DFDのエントリポイント |
| Who | 誰が | ライフサイクル一覧の関与者 |
| When | いつ | ライフサイクルのフェーズ |
| Why | なぜ | 故意／過失 |
| What | 何を | 情報の窃取／改ざん／機能の誤作動／機能の停止 |
ここで IoT ならではのポイントが2つあります。1つは、Who と When がライフサイクルから出てくること。企画→開発(設計・製造)→運用(初期設定・定常運用・アップデート・修理)→廃棄と進む各フェーズで、関わる人(社員・販売員・ユーザ・サービス事業者・廃棄業者・第三者)が変わります。フェーズを分けると、Who の候補が自然に洗い出せます。
もう1つは、What に「機能の誤作動・停止」が入ること。一般的な情報システムなら脅威は情報の窃取・改ざんが中心ですが、IoTは物理世界を動かすので、「機能を止められる」「誤作動させられる」ことそのものが重大な脅威になります。
5つを組み合わせると、たとえばこんな1本の脅威ができあがります。
ECUの制御機能を、Bluetooth I/F から、第三者が、定常運用時に、故意に、誤作動させる。
ただし、5W法は機械的なのであり得ない組み合わせも大量に生みます。そこで、検討不要なものを外すために 前提条件(Assumption) を置きます。
- 例1: 「UART I/F にはパスワードが正しく設定されている」→ UART を入口とする脅威を除外できる。
- 例2: 「販売員やサービス事業者は教育済みで、故意の悪意ある操作はしない」→ その関与者については過失のみを分析対象にする。
注意したいのは、前提条件を成立させること自体も、解決すべき課題だということです。「パスワードが正しく設定されている」を前提にするなら、それを本当に担保する運用が別途必要になります。前提を置いて脅威を減らすことと、その前提を守る仕組みはセットです。
リスクを数値にする ── CRSSでスコアリング
洗い出した脅威には優先順位をつけます。全部に同じ力で対策はできないので、発生可能性(攻撃のしやすさ) と 影響の大きさ を数値化します。講義で紹介されたのは CRSSリスク評価手法 です。
CRSS は日立が提案した評価手法で、脆弱性スコアリングの標準である CVSS v2 の"基本値"のパラメータを流用して作られています。CVSS そのものとは別物(公開規格ではなく提案手法)である点に注意してください。CVSS 本体は後半の「運用時」で改めて登場します。
CRSS は、脅威を「どれだけ攻撃しやすいか」と「当たったらどれだけ痛いか」の2軸で採点します。使うパラメータは次の6つです。
| 軸 | パラメータ | 見るもの |
|---|---|---|
| 攻撃容易性 | 攻撃元区分 | ローカルか、隣接(Bluetooth等)か、ネットワーク越しか |
| 攻撃容易性 | 攻撃条件の複雑さ | 攻撃が簡単なほど高い |
| 攻撃容易性 | 認証要否 | 突破すべき認証が多いほど低い |
| 影響 | C(機密性) | 漏えいの痛さ |
| 影響 | I(完全性) | 改ざんの痛さ |
| 影響 | A(可用性) | 停止の痛さ |
各パラメータには所定の数値が割り当てられ(例: 攻撃元区分はローカル0.395／隣接0.646／ネットワーク1.0、影響は なし0.0／部分的0.275／全面的0.660)、それらを掛け合わせた「攻撃容易性」と「影響度」から1つのリスク値を計算します。計算式は流用元の CVSS v2 基本値そのものなので、値も式も暗記する必要はありません(気になる方は「CVSS v2 基本評価基準」で追えます)。
要は「攻撃のしやすさ × 影響の大きさ」でリスク値が決まる、ということです。全世界からネットワーク越しに、認証なしで、可用性を甚大に損なえる脅威は高スコアになり、ローカルからしか届かず影響も軽微な脅威は低スコアになります。そして、このリスク値の高低に応じて、前章の軽減／移転／回避／許容を割り当てていきます。
対策を決める ── FT（なぜなぜ分析）で攻撃パスを分解
対策すべき脅威が決まったら、いきなり「暗号化しよう」「認証を付けよう」と手を動かす前に、その脅威はどんな手順で成立するのかを分解します。ここで使うのが FT(Fault Tree、フォールトツリー)手法 です。故障や事故の原因を木構造でたどる、いわゆる「なぜなぜ分析」に近い手法です。
一番上にトップ事象(対策対象の脅威)を置き、それが成立する条件を下へ下へと分解していきます。分解にはAND(下位がすべて成立して初めて上位が発生)とOR(下位のいずれかで上位が発生)を使い、最も細かいレベルの 基本事象 まで展開します。
(図は簡略化しています。実際は各段の分岐で AND／OR を明示します)
こうして展開すると、各基本事象を1つつぶせば、その上位の攻撃は成立しなくなることが見えてきます。つまり基本事象それぞれが「対策目標」になります。個人的にゾッとしたのは、成立条件に「攻撃される側が気づかない」が入ってくる点です。気づけない攻撃こそがまずいわけで、検知の仕組みがいかに大事かを逆側から教えてくれます。
対策方針は、大きく2種類に振り分けます。
- 開発対象自身に搭載するもの(IT): 暗号化、認証、改ざん検知など、機器そのものに実装する機能。
- 運用環境で実現するもの: 教育、運用規則、初期パスワードの変更ルールなど。前章の「前提条件」で挙げたものは、たいていこちら側で守ります。
開発側の現実的なコツとして、講義では「コストのかからない対策案を複数出して、その組み合わせで実現する」ことが強調されていました。1つの完璧な対策より、安く積める対策の重ね合わせ、という発想です。
機能に落とす ── ISO/IEC 15408（Common Criteria）のカタログ
「認証を付ける」と決めても、では具体的に何を実装すればいいのか。ここをゼロから考えると抜け漏れが出ます。そこで参照するのが、ISO/IEC 15408(通称 Common Criteria、CC) の「セキュリティ機能」カタログです。セキュリティ評価の国際標準で、実装すべき機能が体系的に整理されています。ゼロから考えず、カタログから選ぶわけです。
機能は11のクラスに分かれています。全部を実装するわけではなく、自分の対策方針に関係するクラスだけを引く「辞書」だと思ってください(まずは眺めるだけで大丈夫です)。
| クラス | 内容 |
|---|---|
| FAU | セキュリティ監査(アクティビティの記録・分析) |
| FCO | 通信(送受信の否認防止) |
| FCS | 暗号サポート(鍵管理・暗号操作) |
| FDP | 利用者データ保護 |
| FIA | 識別と認証 |
| FMT | セキュリティ管理 |
| FPR | プライバシー |
| FPT | TSF(セキュリティ機能そのもの)の保護 |
| FRU | 資源利用(処理能力・記憶容量などの可用性) |
| FTA | TOEアクセス(利用者セションの制御) |
| FTP | 高信頼パス／チャネル |
講義メモでは「DOS: 資源の利用」となっていましたが、資源利用のクラスは正しくは FRU です。また、セキュリティ機能自体を守るクラスが FPT(TSFの保護) で、TSF は「セキュリティ機能そのもの」を指します。
各クラスは、さらに機能クラス > 機能ファミリ > 機能コンポーネント > 機能エレメント(最小単位) の木構造になっています。要件は機能コンポーネント単位で選び、そのコンポーネントに含まれるエレメントをすべて実現します。たとえば暗号サポート(FCS)の下には、鍵のライフサイクルを扱う鍵管理ファミリ(FCS_CKM: 生成・配布・アクセス・破棄)と、暗号操作ファミリ(FCS_COP)がぶら下がっています。
一番具体的な 機能コンポーネントまで降りると、要件は「穴埋め問題」の形で書かれています。FCS_COP.1(暗号操作)の要件文はこうです。
【穴埋め前】
FCS_COP.1.1 TSFは、［標準のリスト］に合致する、
暗号アルゴリズム［割付］と暗号鍵長［割付］に従って、
［暗号操作のリスト］を実行しなければならない。
【穴埋め後（例）】
標準 = FIPS PUB 197 "AES"
アルゴリズム = AES CBCモード
鍵長 = 256bit
暗号操作 = 暗号化・復号
このように、カタログの型に沿って [割付] を埋めるだけで、抜けのないセキュリティ要件が完成します。FCS_COP.1 には依存性(暗号鍵を生成 or 導入する FCS_CKM.1 と、使い終わった鍵を破棄する FCS_CKM.4 が必要)も定義されていて、「鍵を作る／捨てる」まで含めて要件が揃う仕組みになっています。CC は ICカードなど一部の製品では利用が必須です。
最後に、決めた対策が本当に妥当かを仕様検証で確認します。観点は3つです。
- 課題(脅威・前提条件)は正しく抽出されているか。
- 課題と対策は対応しているか(リスク対応として妥当か)。
- 対策と機能要件は対応しているか(機能が揃っているか)。
ISO/IEC 15408 に沿ったプロセスを組むと、この検証を確実に回せる、というのが開発時パートの締めくくりでした。
運用時：脆弱性は「発見」ではなく「監視」し続けるもの
ここまでが「作るとき」の話です。しかし、しっかり作って出荷しても、そこで終わりにはできません。昨日まで安全だった製品が、今日報告された新しい脆弱性で危険になる——これがセキュリティの厄介なところです。だから運用時は、新しい脆弱性の報告や実際の攻撃を監視し続けて、リスクアセスメントを回し直します。
この監視を担うのが PSIRT(Product SIRT、製品のセキュリティインシデント対応チーム) です。世の中のサイバーセキュリティ情報を集めて分析し、自社製品に影響がありそうなら開発部門へ橋渡しします。開発時に作り込む「Secure by Design」と、運用で守り続ける「Secure by Operation」の両輪、という整理が講義でも示されていました。
監視の起点になるのが、脆弱性に振られる共通の識別子 CVE ID です。CVEは1999年から運用が始まり(初期は321件でした)、米NISTの NVD(National Vulnerability Database) に集約されています。1件のCVEには、ID・概要・参考URL・深刻度(CVSSスコア)・影響を受けるプラットフォームなどが載り、いまはJSON形式で機械処理できるようになっています。
そして、脆弱性は「作り方のミス」だけが原因ではありません。大きく3種類あります。
| 種類 | 例 | CVEに載るか |
|---|---|---|
| バグによるもの | バッファオーバーフロー | 載る(中心) |
| 仕様によるもの | 正しく実装されたパスワード機構への総当たり(ブルートフォース) | 載りにくい |
| ガイダンスが関係するもの | 初期パスワードの変更漏れ | 載りにくい |
講義メモの「Blute force」は ブルートフォース(Brute force、総当たり攻撃) の綴り誤りです。仕様どおり正しく作っても、総当たりで突破されうる——「バグがない＝安全」ではない好例です。
混入のしかたもさまざまで、設計段階なら暗号鍵のハードコード、実装段階なら入力確認の不足によるバッファオーバーフロー、設定段階なら不適切なデフォルト権限、といった具合です。特に脆弱性が入り込みやすいAPIのパターンは OWASP API Security Top 10 が整理してくれています(本記事で触れる内容は2023年版に基づきます。詳細は参考資料の注記参照)。
脆弱性を分析する共通の道具箱 ── SCAP
脆弱性を機械的に分析するための枠組みが SCAP(Security Content Automation Protocol、セキュリティ設定共通化手順、"エスキャップ") です。SCAPは単体の何かではなく、次の4つの規格の組み合わせでできています。
それぞれ役割が違います。
CVSS(Common Vulnerability Scoring System) は、脆弱性の深刻度を数値化する指標です。修復の優先順位づけや、組織間で危険度を共有するのに使います。実務では、このスコアを見て「システムを止めてでも今すぐ直すのか、次の定期メンテまで待てるのか」を判断します。v2からv3への改訂で、攻撃条件の複雑さや認証の扱いが再編され、v3では新たに スコープ(S) ——脆弱性の影響が対象コンポーネントの外(例: 利用者のPC)にまで及ぶか——が加わりました。v3の基本メトリクスは「攻撃元区分(AV)／複雑さ(AC)／必要な特権(PR)／ユーザ関与(UI)＋影響C/I/A＋スコープ(S)」です。
CWE(Common Weakness Enumeration) は、「設計・開発でやりがちな、脆弱性につながる弱点」の辞書です。たとえば「書き込んではいけないメモリ領域に書き込んでしまう」プログラムの弱点(CWE-787 Out-of-bounds Write)などが、概要・関係する言語・具体的なコード例つきで登録されています。CWEは抽象から具体への木構造で整理されています。
| 階層 | 抽象度 | 例 |
|---|---|---|
| Pillar | 最も抽象的なテーマのくくり | CWE-284 不適切なアクセス制御 |
| Class | 複数の観点を含むが抽象的 | CWE-287 不適切な認証 |
| Base | 検出・予防の具体策まで詳細化 | CWE-1392 デフォルト資格情報の利用 |
| Variant | 特定タイプの製品向けにさらに詳細 | CWE-258 設定ファイルの空パスワード |
CWEの正式名称は Common Weakness Enumeration です(講義メモの "Enumerition" は綴り誤り)。
CPE(Common Platform Enumeration) は、製品を識別するための共通名です。「どの製品のどのバージョンが影響を受けるか」を機械処理できるよう、決まった書式で表します。
cpe:/{種別}:{ベンダ名}:{製品名}:{バージョン}:{アップデート}:{エディション}:{言語}
（種別 h=ハードウェア / o=OS / a=アプリケーション）
(この cpe:/ は CPE 2.2 の URI 形式です。現行の CPE 2.3 は cpe:2.3:a:... という書式になっています。)
この4つがかみ合うことで、「この製品(CPE)の、この弱点(CWE)に起因する、この脆弱性(CVE)は、どれくらい危険か(CVSS)」を、人手を介さずに突き合わせられるようになります。
いま注目の2つ ── SBOMとMITRE ATT&CK
最後に、近年とくに注目されている2つの道具を紹介します。
SBOM(Software Bill of Materials、ソフトウェア部品表) は、製品が使っているソフトウェア部品を一覧化したものです。「どのライブラリのどのバージョンを使っているか」が分かるので、新しい脆弱性が出たときに「自社製品は影響を受けるか」を即座に照合できます。サプライチェーンリスクの管理にも効きます。2021年の米大統領令 EO14028 が、重要ソフトウェアへのSBOM整備を大きく後押ししました。代表的なフォーマットは3つです。
| フォーマット | 策定 | 特徴 |
|---|---|---|
| SWID | ISO/IEC 19770-2(NISTが普及を主導) | 導入済みソフトの追跡向け |
| CycloneDX | OWASP | 脆弱性管理が主。ライセンス管理も可 |
| SPDX | Linux Foundation | XML/JSON等で記述、Linux界隈で普及 |
講義スライドの「CycronDX」は CycloneDX の誤植です。
講義後の動きとして触れておくと、EUの CRA(Cyber Resilience Act、サイバーレジリエンス法) が2024年12月に発効し、対象となるデジタル製品に対してSBOMを含む技術文書の整備などが求められる方向になっています。国内でも、経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引き」は講義時点のVer1.0(2023年7月)から、現在はVer2.0(2024年8月)へと更新されています。SBOMは「あると便利」から「求められるもの」へ、確実に位置づけが変わりつつあります。
MITRE ATT&CK(マイターアタック) は、実際の攻撃者の行動を 戦術(Tactics) × 技術(Techniques) のマトリクスで分類・整理したナレッジベースです。「これまでの攻撃者が何をしてきたか」が体系化されているので、具体的な中身を眺めると、攻撃者がどう考え、どんな順で動くかが見えてきます。標準的な攻撃は、たとえばこんな流れをたどります。
こうした一連の攻撃連鎖という考え方は、ロッキード・マーティン社の Cyber Kill Chain としても知られています。ATT&CK には Enterprise だけでなくモバイルや制御システム向けのマトリクスもあり、IoTのような組み込み領域でも参照できます。
講義で出た現場の勘所
講義では、教科書には載らない現場の温度感がいくつも語られました。とくに印象に残ったものを3つ。
- CVEに載っている脆弱性は、あくまで「攻撃パスの一要因」にすぎません。 実際にそれを悪用できるかどうかは別問題で、FTのように攻撃手順を組み立ててみて初めて「使える／使えない」が判断できます。CVEの件数やスコアだけに振り回されない、という戒めです。
- PSIRTの現場には「どこまで深追いするか」の線引きがあります。 すべての脆弱性を奥の奥まで調べ尽くすのは現実的ではなく、限られたリソースの中で判断する必要があります。
- 脆弱性分析はまだ定型化の途上で、手順を作っている段階です。 ここで生成AIをうまく活用できると効率化できるのでは、という展望も語られていました。この記事のように「手順」を言語化しておくことは、その第一歩なのかもしれません。
まとめ
IoTのサイバーセキュリティリスクアセスメントを、開発時と運用時の一本の線として振り返ってきました。幹を3点で再掲します。
- リスクは「資産 × 脅威 × 脆弱性」で決まり、CIAの喪失影響で測る。 対応は軽減・移転・回避・許容の4択。これが全体の共通言語。
- 開発時は TARA という決まった流れで進む。 対象把握(DFD)→脅威抽出(5W法)→スコアリング(CRSS)→対策(FT／Common Criteria)。勘ではなく、道具で洗い出す。
- 運用時は PSIRT が脆弱性を「監視し続ける」。 CVE・SCAP(CVSS/CWE/CPE)・SBOM・MITRE ATT&CK という共通の道具箱で、報告される脆弱性を自社製品に照合し続ける。
一番伝えたかったのは、IoTのセキュリティは「作って終わり」にはできないということです。作るときに脅威を洗い出し、出荷したあとも脆弱性を追い続ける。開発と運用は切れておらず、一本の線でつながっています。
そして、その線をたどる道具はすでに世の中に用意されています。DFD、5W法、Common Criteriaのカタログ、SCAP、SBOM、ATT&CK——どれも「専門家だけの秘密の技」ではなく、公開された標準やナレッジベースです。少し前の私は、リスクアセスメントを遠い世界の話だと思っていました。でも本当は、既存の道具を決まった順で組み合わせれば、作る側の自分でもたどれる作業だったのです。題材はIoTでしたが、この考え方は何かを作るすべての場面に効くはずです。
ここまで読んでいただき、ありがとうございました。私自身まだ学習中の身なので、間違いがあれば指摘していただけると助かります。
参考資料
- IPA「IoT開発におけるセキュリティ設計の手引き」(2023年3月)
- IPA「開発者のためのセキュリティ解説書」(ガイダンス編／セキュリティアーキテクチャ編／脆弱性評価編)
- IPA「セキュリティ設定共通化手順SCAP概説」
- IPA「共通脆弱性評価システムCVSS概説」
- IPA「脆弱性対応におけるリスク評価手法のまとめ」 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/risk-assessment-methods.html
- NIST: NVD(National Vulnerability Database) https://nvd.nist.gov/
- MITRE: CVE https://www.cve.org/ ／ CWE https://cwe.mitre.org/ ／ ATT&CK https://attack.mitre.org/
- OWASP: API Security Top 10 https://owasp.org/API-Security/
- 経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引き」(講義時点 Ver1.0=2023年7月／現行 Ver2.0=2024年8月) https://www.meti.go.jp/press/2024/08/20240829001/20240829001.html
※ 用語について、講義メモ・スライドの転記由来の表記を本文では次のとおり正しい表記に直しています。
- CRSSリスク評価手法は日立の提案手法で、CVSS v2の基本値パラメータを流用したものです(公開規格ではありません)。
- CVEの正式名称は "Common Vulnerabilities and Exposures" です(講義スライドの "Common Vulnerability Enumeration" は正確ではありません)。CVEの採番機関は現在 CNA(CVE Numbering Authority) と呼びます(スライドの「CAN」は CNA の誤記と思われます)。
- 本文で触れた OWASP API Security Top 10 の内容は2023年版に基づきます(スライドは「2019年より」と記載していましたが、内容は2023年版に対応します)。
- CVSSは本記事執筆時点ではv4.0も公開されていますが、講義で扱われたv2/v3の範囲で解説しています。
- 記事中の内容は執筆時点(2026年7月現在)のものです。
あわせて読みたい
同じ「復習ログ」シリーズです。CySecの学びを1回ずつ記事にしています。
- 同シリーズ #1 前編: なぜ情報セキュリティは標準化されるのか【CySec復習ログ#1】
- 同シリーズ #2 後編: ISMSの歴史と2022年大改定【CySec復習ログ#2】
- 同シリーズ #3: 内部統制を「リスクに打つ実装戦略」として理解し直す【CySec復習ログ#3】
- 同シリーズ #4: 準拠性監査から有効性監査へ【CySec復習ログ#4】
- 同シリーズ #5: 暗号の歴史は「秘密を小さくする」歴史【CySec復習ログ#5】
- 同シリーズ #6: その多要素認証、どの攻撃に効いてますか？【CySec復習ログ#6】
- 同シリーズ #7: 数学的に安全な暗号が寿命を迎える2つの理由【CySec復習ログ#7】
- 同シリーズ #8: ランサム攻撃は「単発事件」ではなく「分業された産業」【CySec復習ログ#8】
- 同シリーズ #9: 「気をつけます」では止まらない ── インシデントレベルのトリアージとCSIRTの動き方【CySec復習ログ#9】
- 同シリーズ #10: 「組織図」では説明できない ── RFC2350というCSIRTの自己紹介状【CySec復習ログ#10】
- 同シリーズ #11: インシデント対応フローは「描いて終わり」じゃない ── 机上演習で作って・壊して・連絡手段まで決める【CySec復習ログ#11】
- 同シリーズ #12: インシデント報告が「技術の作文」になる人へ ── 経営者が判断できる型に翻訳する机上演習【CySec復習ログ#12】
- 同シリーズ #13: AIを組み込むと攻撃面が増える ── AIセキュリティを4象限で整理する【CySec復習ログ#13】
- 姉妹シリーズ「CCT復習ログ」: Day1 ／ Day2 ／ Day3