脆弱性診断結果を受けての対応/修正の判断はリスク評価、危険度評価が判断材料となります。
報告書としてはセキュリティベンダー毎の策定基準に合わせ１つの結果にまとまった状態で報告されますが、エンジニアと非エンジニアでは欲しい判断材料が異なります。ここで生じ得る認識解離を報告会にて相手に合わせた必要な判断材料を提供することで回避、緩和します。
具体例としては、非エンジニアであれば放置した場合のビジネスインパクト、風評(ブランディングインパクト)に重きを、エンジニア向けには技術的な観点で修正容易性、責任の度合い、影響範囲を重きを置くように報告するといった相手が重視しているであろう判断基準を相手の反応を見ながら報告会ではお話ししています。
自社完結したプロダクトであれば良いのですが、評価軸とお客様の責任のスコープがマッチしないと意図せずリスクが軽く見られたりと、セキュリティベンダーでは評価軸を組み合わせお客様企業での評価と齟齬を生まないように苦心しています。
一般に定量的な危険度評価のCVSS（Common Vulnerability Scoring System）が挙げられますが、昨年CERT/CCが公式に
CVSSは脆弱性の技術的な深刻度を特定するために設計されたものであり、セキュリティリスクの度合いを示すものではありません。
ではセキュリティリスクはどのように評価していくのが良いのでしょう。絶対的な答えがないのは理解できますが指標は欲しいですね。
今回はそんな指標の参考になるような情報を紹介させていただきます。
脅威分析の重要性
脆弱性診断の前の仕様・設計段階における脅威分析が大幅なコスト・リスク低減につながります。
仕様・設計段階の脅威分析
実装段階の静的解析
検証段階の動的診断（疑似攻撃による脆弱性診断）
https://www.asteriskresearch.com/wp-content/uploads/2016/01/ThreatModeling_requirements_and_design20160204.pdf
脅威分析は組織に帰属する資産の識別とセキュリティ目標の設定は事前にやっている前提では以下の流れとなります。
脅威の識別＝起きてほしくない事象の明確化：脅威事象が抽出される
リスク評価＝脅威事象が⽣じる条件の明確化：脅威事象の顕在化条件→攻撃成功条件が抽出される
対策の実施=攻撃成功条件に対する防御策の明確化：攻撃を失敗させる防御設計に繋がる施策が抽出される
資産の識別がまだの場合
情報資産がわからない、リスクアセスメントはやっとらんという企業は実は少なくありません。
何を守べきかわからないのではセキュリティ(リスク管理)のスタートラインにも立てないのでまずは以下を自問自答しましょう。
その情報は
意図せず第三者に読取・受信されたら困る人がいる
確実に読取・受信できないと困る人がいる
意図せず第三者に作成・変更・削除・送信されたら困る人がいる
確実に作成・変更・削除・送信できないと困る人がいる
その機能は
意図せず第三者にプログラムロジックを読取されたら困る
意図せず第三者にプログラムロジックを変更されたら困る
意図せず第三者にに実⾏されたら困る
確実に実⾏できないと困る
少しでも上記回答がYESなら資産として評価すべきです。
脅威の識別
設計段階のデータフローにおいて信頼境界線を設定し、アタッカーサーフェスでサーバ→ブラウザの方向では、nformation Disclosure：情報の漏洩（意図しない提供）、ブラウザ→サーバではTampering：改ざんやSpoofing：なりすましなど、その方向性とデータ内容に合わせた脅威を想定する必要があります。
STRIDEはマイクロソフトが提唱した脅威の分類手法です。STRIDEはセキュリティ７要素の観点で判断するためには重要な観点となります。
セキュリティ３大要素である機密性、完全性、可用性のみに目がいっているように見受けられます。
脆弱性は情報資産に対し、セキュリティ要素の侵害があるかどうか
Spoofing：なりすまし
真正性の侵害です。多要素認証の欠如、セッション管理の不備、暗号化通信の不備などが該当します。
Tampering：改ざん
完全性の侵害です。HTMLインジェクション、SQLインジェクションなどを含むステレスコマンドなどが該当します。
Repudiation：否認
否認防止を侵害します。CSRF、デジタル署名の設定不備
Information Disclosure：情報の漏洩（意図しない提供）
機密性を侵害します。
Denial of Service：DoS攻撃
可用性を侵害します。
Privilege elevation：権限昇格
機密性、完全性を侵害します。
MicrosoftのTreat ModelingでDFDの図を書くと脅威の識別ができるようになっています。
STIX(Structured Threat Information eXpression)→サイバー攻撃活動の記述様式
STIXは、サイバー攻撃活動(Campaigns)、攻撃者(Threat_Actors)、攻撃手口(TTPs)、検知指標(Indicators)、観測事象(Observables)、インシデント(Incidents)、対処措置(Courses_Of_Action)、攻撃対象(Exploit_Targets)の8つの情報群から構成されています。これにより攻撃者の行動や手口、狙っているシステムの脆弱性など、攻撃者側の側面から状況をまとめたり、サイバー攻撃を検知するための兆候、サイバー攻撃によって引き起こされる問題、サイバー攻撃に対処するために取るべき措置などを防護側の側面が俯瞰できるようになります。https://www.ipa.go.jp/security/vuln/STIX.html
リスク評価
CVSS以外となるとIoTやカーハッキングなどの脅威分析にも利用されているDREADスコアリングがありますが、
High(3), Med(2), Low(1)の評価が客観性を欠くとの指摘で、点数付けはBug Barが利用されています。
Bug BarはCritical (致命的)、Important (重要)、Moderate (中)、Low (低) という 4 段階の深刻度レベルを定義します。
Damage potential：潜在的な損害
Reproductivity：再現可能性
Exploitability：攻撃利用可能性
Affected users:影響ユーザー
Discoverability:発見可能性
評価軸によるリスク評価
アタッカースコープベース：攻撃者になりうる範囲に応じた評価
被害スコープベース：被害の範囲と限定性による評価
修正容易性：修正にかかるコストで重みづけを変える評価
被害の直接性：罠を踏む必要性のある間接的攻撃は、直接的攻撃よりリスクを下げるといった評価
発見容易性：PoCの公開、製品の利用範囲など発見機会と実行機会を併せて評価
対応の実施
脆弱性診断の危険度評価のあとはリスク対応を判断しなければなりません。リスク対応とは以下のいずれかのアクションです。
リスクの低減
リスクの保有
リスクの回避
リスクの移転
この判断で重要となるのはリスク・コストの見積もりです。この指標としてJNSAが以下のような指標を出しています。
JNSA想定損害賠償金額算定式⇒リスク・コストの見積もり
想定損害賠償額= 漏えい個人情報価値×情報漏えい元組織の社会的責任度×事後対応評価
・経済的損失レベル×精神的苦痛レベル
|
口座番号/暗証番号，クレジットカード番号，カード有効期限，銀行アカウント/パスワード |
遺言書 |
前科前歴，犯罪歴，与信ブラックリスト |
|
パスポート情報，購入記録，ISPのアカウント/パスワード |
年収，年収区分，資産，建物，土地，残高，借金，所得，借入れ記録 |
|
|
氏名，住所，生年月日，性別，金融機関名，住民票コード，メールアドレス，健康保険証番号，年金証書番号，免許証番号，社員番号，会員番号，電話番号，ハンドル名，健康保険証情報，年金証書情報，介護保険証情報，会社名，学校名，役職，職業，職種，身長，体重，血液型，身体特性，写真（肖像），音声，声紋，体力診断 |
健康診断，心理テスト，性別判断，妊娠経験，手術歴，看護記録，検査記録，身体障害者手帳，DNA，病歴，治療法，指紋，レセプト，スリーサイズ，人種，地方なまり，国籍，趣味，特技，嗜好，民族，日記，賞罰，職歴，学歴，成績，試験得点，メール内容，位置情報 |
加盟政党，政治的見解，加盟労働組合，信条，思想，宗教，信仰，本籍，病状，カルテ，痴呆症，身体障害，知的障害，精神的障害，保有感染症，性癖，性生活 |
以上です。参考になれば幸いです。