【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案

STAMP/STPAはシステムにおけるリスクの洗い出しを行うことを可能にする優れた手法である。
しかし、対策の立案方法については、そのプロセスが特には示されていないため、これについては分析者の力量に委ねられている。そこで、対策立案をするために、４STEP/Mを用いてリスクの回避/軽減策を導き出すことを試みた。
本発表では、一般的なWebシステムを題材としたSTAMP/STPA分析により導き出された各UCAに対し、対策立案を試行した事例をもとに、４STEP/Mを使い戦略的にリスク削減案を導きだすアプローチ、およびその有用性について説明する。

STAMP/STPA analysis is an excellent way to find the risk of the systems. However, the STAMP/STPA method doesn't include how to design to prevent/mitigate the risk. The quality of the analysis depends on the analyst's skill. Therefore, I considered how to avoid/reduce the risk using the 4STEP/M method. This presentation reports how to prevent/mitigate the risk using the 4STEP/M method which I analyzed to identify the UCA using the STAMP/STPA analysis for typical web system's development, and this way's usefulness.

Transcript

1. Propose to use the 4STEP/M method to prevent/mitigate the STAMP/STPA analyzed risk. STAMP/STPAで導き出した課題に対す る対策立案手法の提案 Hiroyuki.Anraku（安樂 啓之） 2024/12/5
2. アジェンダ • はじめに • 今回の取り組みのきっかけ • 4STEP/Mとは • 取り組み内容 • 結果 • 考察 • 結論 2
3. Agenda • Introduction • Inspiration for This Initiative • What is 4STEP/M? • Approach • Result • Consideration • Conclusion 3
4. はじめに • 今日の発表は、2023年度SQiP研究会の中で発表した内容を元 にしています。 • 2023年度のSQiP研究会の中で、学習の一環として、 STAMP/STPAを使った分析に取り組みました。今日はその中で、 分析の中で導き出された問題の対策立案に4STEP/Mという手 法を適用したことについて報告、提案をしたいと思います。 4
5. Introduction • Today's presentation is based on the report from the SQiP Studying Group(*1) • Our studying group member and I tried security analysis using STAMP/STPA method. • I'll explain the attempt how to resolve the problem using 4STEP/M Method that I was analyzed using the STAMP/STPA. (*1) Abbreviation of Software Quality Profession Studying Group 5
6. 自己紹介 6 インフォテック（株）で28年勤務 官公庁系、金融機関などのインフラ、運用開発や、社内教育部門での教育などを経て最近ではクラウドベース のセキュリティに関する業務に従事している。 興味のあるトピック (1) 情報セキュリティに関して 開発におけるSecurity by Design、DeｖSecOpsといったことや、 リスクの定量化などに興味があり、業務の中での取り組みを行ってます。 (2) 要求開発、ビジネス企画のデザインについて ビジネス企画のデザインなどで、匠Methodの活用について取り組んで います。こちらについても業務や外部での発表などに取り組んでいます。 (3) ソフトウェア開発関連 ソフトウェア欠陥についての分析などについて取り組んでいます。 (4) その他 最近では趣味として、英会話や、筋トレ、料理等をしています。
7. Introduction 7 I have worked at Infotec Inc. for 28 years. My experience includes infrastructure and operational development for government agencies and financial institutions, as well as internal training within the company. Areas of Interest (1) Information Security I am interested in Security by Design and DevSecOps in development, as well as the quantification of risks. I am actively working on these areas in my job. (2) Requirements Development and Business Planning Design I am engaged in utilizing the Takumi Method for business planning design. I also work on this topic in my job and present it externally. （3） Software Development I am involved in analyzing software defects. (4) Others Recently, my hobbies include learning English conversation, weight training, and cooking.
8. STPAによる分析の進め方 今回の取り組みのきっかけ アクシデント、ハザード 安全制約の識別 CS図の作成 UCAの識別 UCAの発生要因の識別 コンポ―ネント A コンポ―ネントA コンポ―ネン トB CA(Control Action) Feedback システム ｱｸｼﾃﾞﾝﾄ ﾊｻﾞｰﾄﾞ 安全制約 UCA UCA UCA UCA UCA UCA UCA 発生要因 発生要因 発生要因 発生要因 Control Structure Diagram Step0(準備1) Step0(準備2) Step1 Step2 発生要因の洗 い出し後に対 策を立てる 方法を体系的 に行いたい。 8
9. How to analyze using the STAMP/STPA Inspiration for This Initiative Identify accidents, hazards, and Safety constraints. Developing the Control Structure Diagram Identify Unsafe Control Actions. Identify the causes of Unsafe Control Actions. コンポ―ネント A コンポ―ネントA コンポ―ネン トB CA(Control Action) Feedback システム ｱｸｼﾃﾞﾝﾄ ﾊｻﾞｰﾄﾞ 安全制約 UCA UCA UCA UCA UCA UCA UCA Cause Cause Cause Cause Control Structure Diagram Step0(Prepare 1) Step0(Prepare2) Step1 Step2 What's the effective solution? Is solution well defined process? 9
10. 方針 ｴﾗｰ着想 対策 STPAによる分析の進め方 今回の取り組みのきっかけ アクシデント、ハザード 安全制約の識別 CS図の作成 UCAの識別 UCAの発生要因の識別 コンポ―ネント A コンポ―ネントA コンポ―ネン トB CA(Control Action) Feedback システム ｱｸｼﾃﾞﾝﾄ ﾊｻﾞｰﾄﾞ 安全制約 UCA UCA UCA UCA UCA UCA UCA 発生要因 発生要因 発生要因 発生要因 Control Structure Diagram Step0(準備1) Step0(準備2) Step1 Step2 発生要因 発生要因 発生要因 発生要因 ４STEP/Mによる エラー対策 10
11. How to analyze using the STAMP/STPA Inspiration for This Initiative Identify accidents, hazards, and Safety constraints. Developing the Control Structure Diagram Identify Unsafe Control Actions. Identify the causes of Unsafe Control Actions. コンポ―ネント A コンポ―ネントA コンポ―ネン トB CA(Control Action) Feedback システム ｱｸｼﾃﾞﾝﾄ ﾊｻﾞｰﾄﾞ 安全制約 UCA UCA UCA UCA UCA UCA UCA Cause Cause Cause Cause Control Structure Diagram Step0(Prepare1) Step0(Prepare2) Step1 Step2 11 Cause Cause Cause Cause The solution developed using the 4STEP/M method 方針 ｴﾗｰ着想 対策
12. ４Step/Mとは • 戦略的に問題への対策を行い、軽減を図るための手法。以下の4 つのStepに基づいて問題への対応を立案する方法 • 機会最小（Minimum Encounter） • 最小確率（Minimum Probablity） • 多重検出（Multiple Detection） • 被害局限（Minimum Damage） • 想定される問題に対して、戦略的に対策を考える方法が STAMP/STPAとは相性がいいと思い利用しようと考えた。 (※１）Strategic approach To Error Prevention & Mitigation by 4Ms の略 12
13. What is 4STEP/M(*1)? • The 4STEP/M method provides a straightforward approach to developing solutions using a strategic framework. It includes the followed four processes. • Minimum Encounter • Minimum Probablity • Multiple Detection • Minimum Damage • I want to use this approach. Since that is suitable to resolve the problems analyzed using STAMP/STPA method. (*1) Abbreviation of Strategic approach To Error Prevention & Mitigation by 4Ms. 13
14. ４Step/Mとは No ステップ 対策 説明 1 (1) 機会最小 やめる（なくす） 作業を見直してやめることを検討。 2 (2) 最小確率 出来ないようにする 仕組み、制約を変えてできない形にする 3 分かりやすくする 色や表示等を工夫しわかりやすくする 4 やりやすくする 操作性を見直すなどしてやりやすくする 5 知覚能力を持たせる 知覚能力を維持する（睡眠、健康、加齢等を認識し、パフォーマン スを維持するように心がける） 6 認知・予測させる 危険、間違え探しなどのトレーニング 7 安全を優先させる 安全を優先する価値観づくり、実践など 8 できる能力を持たせる 機械等の品質保証、人間の品質保証（操作者の健康、心身状態 のチェック、訓練など） 9 (3) 多重検出 自分で気づかせる リチェック、指差呼称などの実施 10 検出する チェックリストなどにより間違いを検出する 11 (4) 被害局限 備える 問題発生に備えておく（失敗の影響を減らす対策や、コンティ ジェンシープランの準備、保険、リスクマネジメント等） ４STEP/M（※1)による問題への対策の着想 14
15. What is 4STEP/M? No Step Solution Details 1 (1) Minimum Encounter drop/stop To consider stopping the procedure. 2 (2) Minimum Probablity unable Changing the procedure, structure, or regulation for incident prevention. 3 identify easier Optimizing colors or indicators for easy recognition. 4 process/way easier Improving the process or way. 5 keep perception skill well Keeping perception skill well (Keeping capability well considering my wellness, sleepiness, or age) 6 cognition/expectation Training to expect the possibility of hazards and their causes( dangerous points, mistakes, etc). 7 keep safe To keep awareness for prioritizing safety and security. 8 keep possibility well Quality assurance for machine or human factors (manipulators' wellness, training, etc.) 9 (3)Multiple Detection check by myself Re-check, pointing and calling (occupational safety method),etc 10 detection Detect mistakes using the checklist. 11 (4) Minimum Damage prepare for accidents Prepare for the incident (planning for mitigate the failure, contingency plan, insurance, risk management, etc.) Figure: how to resolve the problems using 4STEP/M method. 15
16. 取り組み内容 • 以下の例の分析について取り組んだ • クラウドベースのWebアプリケーションに対する分析 • 一般的なクラウドベースのWebアプリケーションをサンプルとして、 STAMP/STPA分析を行い、リスクを洗い出した。 • サンプルはAWSのリファレンスアーキテクチャから一般的なWebアプリ ケーションを選定 • 実際に対策立案までの進め方について試行し、結果を取得した。 16
17. Approach • Analysis appｒoach • Analyze the web-based application on the cloud. • Consider the problems typical web-based application on clouds using the STAMP/STPA method analysis. • I analyzed a generic web-based application based on the AWS reference architecture. • I analyzed using the way referred p.5. • Examined to try the consider using way of the 4STEP/M method. 17
18. 分析対象とした一般的な2層のWebシステムの構成 DNSサーバ WAF ロード バランサ Web/AP サーバ DB サーバ バックアップ系サービス 管理系サービス サーバ証明書 管理サービス 利用者クライアント 運用管理 クライアント 【クラウドベースのWebアプリケーションに対する分析】 以下のシステムを開発することを想定し、分析を行った。 18
19. Typical 2-tiered web application system structure as the target for this analysis. DNS WAF Load balancer Web Application Server Database Server Backup Services Management Services Certificates Manager ClientPC for Users ClientPC for Operators 【Analyze the web-based application on the cloud】 To analyze for developing a following diagram system. 19
20. アクシ デント ID アクシデント ハザード ID ハザード 安全制約ID 安全制約 A1 システムが異常をきたし運用不可能な状態となる H1 システムを構成するサーバが暗号化される SC1 サーバ上では不正なアプリケーションが動作してはなら ない A1 システムが異常をきたし運用不可能な状態となる H2 システムの環境の変更について、誰が、いつ、何をし たかについて検知できない SC2 システムの環境の変更について、誰が、いつ、何をした か、検知出来る必要がある A1 システムが異常をきたし運用不可能な状態となる H3 システムを構成するサーバが不正に削除・変更され る SC3 システムを構成するサーバは正規の手順で削除、変更で きる必要がある A2 アプリケーションが保有するデータが利用できなくなり、 運用不可能になる H4 アプリケーションの稼働に必要なマスタが不正に削 除、変更される SC4 アプリケーションマスタの変更は許可されたものによる 操作によって行われること A3 システムを取り巻く環境に問題があり、運用不可能にな る H5 システムがインターネットを利用できなくなる SC5 システムは運用時間はインターネットとのアクセスが利用 できること A3 システムを取り巻く環境に問題があり、運用不可能にな る H6 クラウドサービスが利用不可能になる SC6 システムは運用時間の間、サービス利用が出来ること A4 システム上で管理する情報が漏えいする H7 アプリケーションのユーザからの不正操作により データが漏えいする SC7 アプリケーションは許可されたもの以外は利用しないこ と A4 システム上で管理する情報が漏えいする H8 クラウドサービスのストレージ上のデータの盗難によ りシステム上のデータが漏えいする SC8 クラウド上のストレージ上のデータは許可されたもの以 外は利用できないこと A4 システム上で管理する情報が漏えいする H9 バックアップデータの盗難により、システム上の管理 データが漏えいする SC9 バックアップデータへのアクセスは、許可されたもの以外 は利用できないこと A5 システム運用に必要なアカウント情報が漏えいする H10 AWS利用のためのルート、およびIAMアカウントの ID、パスワードが漏えいする SC10 ルートユーザ、およびIAMユーザのアカウントのパスワー ドは盗難や類推などにより漏えいすることがないこと A5 システム運用に必要なアカウント情報が漏えいする H11 AWS利用のためのルート、およびIAMアカウントの ID、パスワードを解読、利用される SC11 ルートユーザ、おおびIAMユーザは、多要素認証にて認 証を行うこと A6 情報漏えい事故によりエンドユーザからの信用が失墜す る H12 攻撃者が盗んだ個人情報を不正に利用される SC12 システムが保持する個人情報が外部に漏えいしないこと A6 情報漏えい事故によりエンドユーザからの信用が失墜す る H13 システムが保持する個人情報へのアクセスの検知が 出来ない SC13 システムが保持する個人情報へのアクセスは監視され、 問題発生時は異常検知できること 【クラウドベースのWebアプリケーションに対する分析】 アクシデント・ハザード・安全制約の着眼点は大きく２つ、「運用不能からの復旧」と「情 報漏えい」を中心に分析を実施 20
21. 21 【Analyze the web-based application on the cloud】 The main purpose of Analyse is to recover from failure service and prevent exfiltration. Accident ID accident Hazard ID hazard Safety Constraint ID Safety Constraints A1 The system becomes abnormal and inoperable. H1 The servers that make up the system are encrypted. SC1 No unauthorized applications can run on the server A1 The system becomes abnormal and inoperable. H2 Inability to detect who did what, when, and changes in the system's environment SC2 It is necessary to be able to detect who did what, when, and changes in the system environment A1 The system becomes abnormal and inoperable. H3 The servers that make up the system are deleted or changed illegally. SC3 The servers that make up the system must be able to be deleted and modified in a regular manner. A2 The data held by the application becomes unavailable and inoperable H4 The master required to run the application is illegally deleted or changed. SC4 Changes to the application master must be made by authorized operations. A3 There is a problem with the environment surrounding the system, making it inoperable H5 The system will not be able to use the Internet SC5 The system must be able to access the Internet during operating hours. A3 There is a problem with the environment surrounding the system, making it inoperable H6 Cloud services become unavailable SC6 The system must be able to use the service during the operating time. A4 Information managed on the system is leaked. H7 Data leakage due to unauthorized manipulation by the user of the application SC7 Do not use applications other than those authorized A4 Information managed on the system is leaked. H8 Data on the system is leaked due to data theft on the storage of the cloud service SC8 Data on cloud storage is only available to authorized users A4 Information managed on the system is leaked. H9 Theft of backup data leads to leakage of management data on the system SC9 Access to backup data is only available to authorized ones. A5 Account information required for system operation is leaked. H10 The root for using AWS, and the ID and password of the IAM account are leaked. SC10 The passwords of the root user and IAM user accounts will not be leaked due to theft or analogy. A5 Account information required for system operation is leaked. H11 Decrypt and use the root for AWS usage and the ID and password of the IAM account SC11 The root user, general IAM user, and IAM user must be authenticated by multi-factor authentication. A6 Loss of trust from end users due to information leakage accidents H12 Attackers can take advantage of stolen personal information SC12 Personal information held by the system will not be leaked to the outside. A6 Loss of trust from end users due to information leakage accidents H13 Unable to detect access to personal information held by the system SC13 Access to personal information held by the system can be monitored and anomalies can be detected in the event of a problem.
22. アクシ デント ID アクシデント ハザード ID ハザード 安全制約ID 安全制約 A1 システムが異常をきたし運用不可能な状態となる H1 システムを構成するサーバが暗号化される SC1 サーバ上では不正なアプリケーションが動作してはなら ない A1 システムが異常をきたし運用不可能な状態となる H2 システムの環境の変更について、誰が、いつ、何をし たかについて検知できない SC2 システムの環境の変更について、誰が、いつ、何をした か、検知出来る必要がある A1 システムが異常をきたし運用不可能な状態となる H3 システムを構成するサーバが不正に削除・変更され る SC3 システムを構成するサーバは正規の手順で削除、変更で きる必要がある A2 アプリケーションが保有するデータが利用できなくなり、 運用不可能になる H4 アプリケーションの稼働に必要なマスタが不正に削 除、変更される SC4 アプリケーションマスタの変更は許可されたものによる 操作によって行われること A3 システムを取り巻く環境に問題があり、運用不可能にな る H5 システムがインターネットを利用できなくなる SC5 システムは運用時間はインターネットとのアクセスが利用 できること A3 システムを取り巻く環境に問題があり、運用不可能にな る H6 クラウドサービスが利用不可能になる SC6 システムは運用時間の間、サービス利用が出来ること A4 システム上で管理する情報が漏えいする H7 アプリケーションのユーザからの不正操作により データが漏えいする SC7 アプリケーションは許可されたもの以外は利用しないこ と A4 システム上で管理する情報が漏えいする H8 クラウドサービスのストレージ上のデータの盗難によ りシステム上のデータが漏えいする SC8 クラウド上のストレージ上のデータは許可されたもの以 外は利用できないこと A4 システム上で管理する情報が漏えいする H9 バックアップデータの盗難により、システム上の管理 データが漏えいする SC9 バックアップデータへのアクセスは、許可されたもの以外 は利用できないこと A5 システム運用に必要なアカウント情報が漏えいする H10 AWS利用のためのルート、およびIAMアカウントの ID、パスワードが漏えいする SC10 ルートユーザ、およびIAMユーザのアカウントのパスワー ドは盗難や類推などにより漏えいすることがないこと A5 システム運用に必要なアカウント情報が漏えいする H11 AWS利用のためのルート、およびIAMアカウントの ID、パスワードを解読、利用される SC11 ルートユーザ、おおびIAMユーザは、多要素認証にて認 証を行うこと A6 情報漏えい事故によりエンドユーザからの信用が失墜す る H12 攻撃者が盗んだ個人情報を不正に利用される SC12 システムが保持する個人情報が外部に漏えいしないこと A6 情報漏えい事故によりエンドユーザからの信用が失墜す る H13 システムが保持する個人情報へのアクセスの検知が 出来ない SC13 システムが保持する個人情報へのアクセスは監視され、 問題発生時は異常検知できること 運用不能になり、復旧が必要な事象 情報漏えいが発生し、対応が必要な事象 【クラウドベースのWebアプリケーションに対する分析】 アクシデント・ハザード・安全制約の着眼点は大きく２つ、「運用不能からの復旧」と「情 報漏えい」を中心に分析を実施 22
23. Accident ID accident Hazard ID hazard Safety Constraint ID Safety Constraints A1 The system becomes abnormal and inoperable. H1 The servers that make up the system are encrypted. SC1 No unauthorized applications can run on the server A1 The system becomes abnormal and inoperable. H2 Inability to detect who did what, when, and changes in the system's environment SC2 It is necessary to be able to detect who did what, when, and changes in the system environment A1 The system becomes abnormal and inoperable. H3 The servers that make up the system are deleted or changed illegally. SC3 The servers that make up the system must be able to be deleted and modified in a regular manner. A2 The data held by the application becomes unavailable and inoperable H4 The master required to run the application is illegally deleted or changed. SC4 Changes to the application master must be made by authorized operations. A3 There is a problem with the environment surrounding the system, making it inoperable H5 The system will not be able to use the Internet SC5 The system must be able to access the Internet during operating hours. A3 There is a problem with the environment surrounding the system, making it inoperable H6 Cloud services become unavailable SC6 The system must be able to use the service during the operating time. A4 Information managed on the system is leaked. H7 Data leakage due to unauthorized manipulation by the user of the application SC7 Do not use applications other than those authorized A4 Information managed on the system is leaked. H8 Data on the system is leaked due to data theft on the storage of the cloud service SC8 Data on cloud storage is only available to authorized users A4 Information managed on the system is leaked. H9 Theft of backup data leads to leakage of management data on the system SC9 Access to backup data is only available to authorized ones. A5 Account information required for system operation is leaked. H10 The root for using AWS, and the ID and password of the IAM account are leaked. SC10 The passwords of the root user and IAM user accounts will not be leaked due to theft or analogy. A5 Account information required for system operation is leaked. H11 Decrypt and use the root for AWS usage and the ID and password of the IAM account SC11 The root user, general IAM user, and IAM user must be authenticated by multi-factor authentication. A6 Loss of trust from end users due to information leakage accidents H12 Attackers can take advantage of stolen personal information SC12 Personal information held by the system will not be leaked to the outside. A6 Loss of trust from end users due to information leakage accidents H13 Unable to detect access to personal information held by the system SC13 Access to personal information held by the system can be monitored and anomalies can be detected in the event of a problem. Need to recover stopped service Need to countermeasure for the data exfiltration. 23 【Analyze the web-based application on the cloud】 The main purpose of Analyse is to recover from failure service and prevent exfiltration.
24. 利用者/管理者など （ステークホルダー） 【クラウドベースのWebアプリケーションに対する分析】 CA図は下記の通り、左側に運用系のステークホルダーを追記している システム系のコンポーネント 24
25. User, Operators, etc. （Stakeholder） Components the system contained. 25 【Analyze the web-based application on the cloud】 Controll Structure diagrams
26. UCA 対策対象コンポーネント HCF/SCF 方針 エラー着想手順 対策 (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] システムオーナー 外部委託業者 IAMユーザのパスワード を忘れてしまう等によっ て、AWS Management Consoleにログインする ことが出来ない 回避 ④ やりやすくする IDaaSやパスワードマネージャの利 用によって、パスワードの管理をす る システムオーナー 外部委託業者 軽減 ⑪ 被害に備える （IAMユーザの場合）MFAトークン 紛失時のリセット、および再設定の 手順をあらかじめ用意しておき、保 守ユーザ内へ周知する。 システムオーナー 軽減 ⑪ 被害に備える （ルートユーザの場合）MFAトーク ンを２つ登録し、１つが紛失、あるい は破損した場合は予備によるログイ ンができるようにする。 システムオーナー 外部委託業者 軽減 ③ わかりやすくす る ユーザアカウント発行の手順をツー ル化し、必要な権限をプリセットす るようにCLIにて設定する。 システムオーナー 外部委託業者 軽減 ⑨ 自分で気づかせ る ユーザ登録手順のチェックリストを 作成し、確実な登録を確認する手順 とする システムオーナー 外部委託業者 軽減 ⑩ エラーを検出す る ルートユーザのパスワード変更を監 視対象とし、何かの操作が行われた 場合は、運用担当者へメールで通 知がいくように設定をする。 システムオーナー 外部委託業者 軽減 ⑪ 被害に備える ルートユーザのパスワード紛失時に 備えて、アカウント回復手順のため の秘密の質問を設定し、問題発生 時の復旧手順を用意する。 AWS Management Consoleにログインする ために必要なトークンを紛 失、あるいは破損してしま い、ログインすることが出 来ない 初回ログイン時にパスワー ドの変更を求められるが、 パスワード変更権限の割当 がないことから、パスワー ドの変更が出来ず、ログイ ンすることが出来ない ルートユーザでログインし ようとしたところ、別の ユーザがパスワードを変更 してしまいログインが出来 ない (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] HCF/SCFに対する方針を (回避,軽減,共有/転嫁,受容)から選択 【クラウドベースのWebアプリケーションに対する分析】 HCF/SCFを抽出し、リスク対処方針を決め、４STEP/Mによる対策検討 26 ４STEP/Mからリスクへの対策方針を選択 選択した方針に従い、具体化した内容を記 述
27. UCA 対策対象コンポーネント HCF/SCF 方針 エラー着想手順 対策 (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] システムオーナー 外部委託業者 IAMユーザのパスワード を忘れてしまう等によっ て、AWS Management Consoleにログインする ことが出来ない 回避 ④ やりやすくする IDaaSやパスワードマネージャの利 用によって、パスワードの管理をす る システムオーナー 外部委託業者 軽減 ⑪ 被害に備える （IAMユーザの場合）MFAトークン 紛失時のリセット、および再設定の 手順をあらかじめ用意しておき、保 守ユーザ内へ周知する。 システムオーナー 軽減 ⑪ 被害に備える （ルートユーザの場合）MFAトーク ンを２つ登録し、１つが紛失、あるい は破損した場合は予備によるログイ ンができるようにする。 システムオーナー 外部委託業者 軽減 ③ わかりやすくす る ユーザアカウント発行の手順をツー ル化し、必要な権限をプリセットす るようにCLIにて設定する。 システムオーナー 外部委託業者 軽減 ⑨ 自分で気づかせ る ユーザ登録手順のチェックリストを 作成し、確実な登録を確認する手順 とする システムオーナー 外部委託業者 軽減 ⑩ エラーを検出す る ルートユーザのパスワード変更を監 視対象とし、何かの操作が行われた 場合は、運用担当者へメールで通 知がいくように設定をする。 システムオーナー 外部委託業者 軽減 ⑪ 被害に備える ルートユーザのパスワード紛失時に 備えて、アカウント回復手順のため の秘密の質問を設定し、問題発生 時の復旧手順を用意する。 AWS Management Consoleにログインする ために必要なトークンを紛 失、あるいは破損してしま い、ログインすることが出 来ない 初回ログイン時にパスワー ドの変更を求められるが、 パスワード変更権限の割当 がないことから、パスワー ドの変更が出来ず、ログイ ンすることが出来ない ルートユーザでログインし ようとしたところ、別の ユーザがパスワードを変更 してしまいログインが出来 ない (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] (UCA5-N-1) システムのメン テナンスに関する機能を操作す ることが出来ないため適切な 保守が実施出来ない [SC11][SC3][SC6][SC8] [SC9] Select risk prevention principle from avoid, mitigate, share / transfer, or accept. 27 【Analyze the web-based application on the cloud】 Finding the HCF/SCF, choosing the countermeasure of risk, and considering how to prevent/mitigate using the 4STEP/M method. Select proper solution from 4STEP/M method's options. Consider the countermeasure concretely.
28. 【クラウドベースのWebアプリケーションに対する分析】 検討した対策についての実施評価（かなり簡易な方法） 対策 残存リスク 効果 コスト 時間 労力 実行 可能性 採用 備考 IDaaSやパスワードマネージャの利 用によって、パスワードの管理をす る IDaaSやパスワードマネージャのア カウントが乗っ取られた場合には進 入される可能性がある。 〇 〇 〇 〇 〇 採用 パスワードマネージャは個 別導入も容易。 （IAMユーザの場合）MFAトークン 紛失時のリセット、および再設定の 手順をあらかじめ用意しておき、保 守ユーザ内へ周知する。 MFA紛失時から運用担当による トークンのリセットまでの時間が短 縮される。 △ 〇 〇 〇 △ 採用 発生する可能性が低いが、 導入にあたってのデメリッ トなし。 （ルートユーザの場合）MFAトーク ンを２つ登録し、１つが紛失、あるい は破損した場合は予備によるログイ ンができるようにする。 同時に２つが紛失、あるいは破損す る場合（今回は想定しない） △ 〇 〇 〇 △ 採用 ハードウェアトークンを使う 場合は、必須と考え採用 ユーザアカウント発行の手順をツー ル化し、必要な権限をプリセットす るようにCLIにて設定する。 手順を守らないでアカウント発行を 行うケースには対応できない。 △ 〇 △ △ 〇 採用 ユーザ登録手順のチェックリストを 作成し、確実な登録を確認する手順 とする チェック漏れ、チェック時のヒューマ ンエラー △ 〇 〇 △ 〇 採用 ルートユーザのパスワード変更を監 視対象とし、何かの操作が行われた 場合は、運用担当者へメールで通 知がいくように設定をする。 通知自体は発見のリードタイムを縮 めるが、発生可能性を防止するわけ ではない。 × 〇 〇 ◎ 〇 採用 ルートユーザのパスワード紛失時に 備えて、アカウント回復手順のため の秘密の質問を設定し、問題発生 時の復旧手順を用意する。 AWS（クラウドサービス）の障害 で、秘密の質問を使ってもアカウン トが復旧できない可能性（今回は想 定しない） × ◎ 〇 ◎ 〇 採用 パスワードマネージャは個 別導入を行うと限りなく発 生確率は低いが、労力を要 さないため実施。 28
29. 29 【Analyze the web-based application on the cloud】 Estimate the countermeasure effects. countermeasure estimated residual risk effect cost time effort Feasibilit y adoption remarks Manage passwords by using IDaaS or a password manager If an IDaaS or password manager account is compromised, it can be compromised. 〇 〇 〇 〇 〇 Yes Password managers are easy to implement individually. (In the case of IAM users) Prepare a procedure for resetting and resetting MFA tokens in case of loss in advance and disseminate them to maintenance users. The time between the loss of MFA and the time between token reset by the operation manager is shortened. △ 〇 〇 〇 △ Yes It is unlikely to occur, but there are no disadvantages to introducing it. Register two MFA tokens (for root users) so that you can log in with a backup if one is lost or damaged. If two are lost or damaged at the same time (not assumed this time) △ 〇 〇 〇 △ Yes If you want to use a hardware token, consider it essential and adopt it. The procedure for issuing a user account is made into a tool, and the CLI is set to preset the necessary permissions. We are unable to respond to cases where an account is issued without following the procedure. △ 〇 △ △ 〇 Yes Create a checklist of user registration procedures to ensure that registration is secure Missing checks, human error during checks △ 〇 〇 △ 〇 Yes Set the password change of the root user to be monitored, and if any operation is performed, the person in charge of operation is notified by e-mail. The notification itself shortens the lead time for discovery, but it does not prevent it from occurring. × 〇 〇 ◎ 〇 Yes Set up a security question for the account recovery procedure in case the root user loses the password, and have a recovery procedure in place in case of a problem. Due to the failure of AWS (cloud service), the account may not be recovered even if you use a security question (not assumed this time) × ◎ 〇 ◎ 〇 Yes Password managers are implemented because they do not require effort, although the probability of occurrence is infinitely low when introduced individually.
30. 対策 残存リスク 効果 コスト 時間 労力 実行 可能性 採用 備考 IDaaSやパスワードマネージャの利 用によって、パスワードの管理をす る IDaaSやパスワードマネージャのア カウントが乗っ取られた場合には進 入される可能性がある。 〇 〇 〇 〇 〇 採用 パスワードマネージャは個 別導入も容易。 （IAMユーザの場合）MFAトークン 紛失時のリセット、および再設定の 手順をあらかじめ用意しておき、保 守ユーザ内へ周知する。 MFA紛失時から運用担当による トークンのリセットまでの時間が短 縮される。 △ 〇 〇 〇 △ 採用 発生する可能性が低いが、 導入にあたってのデメリッ トなし。 （ルートユーザの場合）MFAトーク ンを２つ登録し、１つが紛失、あるい は破損した場合は予備によるログイ ンができるようにする。 同時に２つが紛失、あるいは破損す る場合（今回は想定しない） △ 〇 〇 〇 △ 採用 ハードウェアトークンを使う 場合は、必須と考え採用 ユーザアカウント発行の手順をツー ル化し、必要な権限をプリセットす るようにCLIにて設定する。 手順を守らないでアカウント発行を 行うケースには対応できない。 △ 〇 △ △ 〇 採用 ユーザ登録手順のチェックリストを 作成し、確実な登録を確認する手順 とする チェック漏れ、チェック時のヒューマ ンエラー △ 〇 〇 △ 〇 採用 ルートユーザのパスワード変更を監 視対象とし、何かの操作が行われた 場合は、運用担当者へメールで通 知がいくように設定をする。 通知自体は発見のリードタイムを縮 めるが、発生可能性を防止するわけ ではない。 × 〇 〇 ◎ 〇 採用 ルートユーザのパスワード紛失時に 備えて、アカウント回復手順のため の秘密の質問を設定し、問題発生 時の復旧手順を用意する。 AWS（クラウドサービス）の障害 で、秘密の質問を使ってもアカウン トが復旧できない可能性（今回は想 定しない） × ◎ 〇 ◎ 〇 採用 パスワードマネージャは個 別導入を行うと限りなく発 生確率は低いが、労力を要 さないため実施。 残存リスク （言葉で説明） 対策に必要なコスト、 手間、実現性等 30 実 施 有 無 の 判 断 【クラウドベースのWebアプリケーションに対する分析】 検討した対策についての実施評価（かなり簡易な方法）
31. countermeasure estimated residual risk effect cost time effort Feasibilit y adoption remarks Manage passwords by using IDaaS or a password manager If an IDaaS or password manager account is compromised, it can be compromised. 〇 〇 〇 〇 〇 Yes Password managers are easy to implement individually. (In the case of IAM users) Prepare a procedure for resetting and resetting MFA tokens in case of loss in advance and disseminate them to maintenance users. The time between the loss of MFA and the time between token reset by the operation manager is shortened. △ 〇 〇 〇 △ Yes It is unlikely to occur, but there are no disadvantages to introducing it. Register two MFA tokens (for root users) so that you can log in with a backup if one is lost or damaged. If two are lost or damaged at the same time (not assumed this time) △ 〇 〇 〇 △ Yes If you want to use a hardware token, consider it essential and adopt it. The procedure for issuing a user account is made into a tool, and the CLI is set to preset the necessary permissions. We are unable to respond to cases where an account is issued without following the procedure. △ 〇 △ △ 〇 Yes Create a checklist of user registration procedures to ensure that registration is secure Missing checks, human error during checks △ 〇 〇 △ 〇 Yes Set the password change of the root user to be monitored, and if any operation is performed, the person in charge of operation is notified by e-mail. The notification itself shortens the lead time for discovery, but it does not prevent it from occurring. × 〇 〇 ◎ 〇 Yes Set up a security question for the account recovery procedure in case the root user loses the password, and have a recovery procedure in place in case of a problem. Due to the failure of AWS (cloud service), the account may not be recovered even if you use a security question (not assumed this time) × ◎ 〇 ◎ 〇 Yes Password managers are implemented because they do not require effort, although the probability of occurrence is infinitely low when introduced individually. Estimated residual Risk (description) Evaluate needs of cost, procedure, feasibility, etc. 31 【Analyze the web-based application on the cloud】 Estimate the countermeasure effects. countermeasure adoption or no
32. 結果 ・4STEP/Mの効果 対策立案の観点の網羅性が高い ・本質安全の視点 / 機能安全の視点 / 再発防止 / 被害の軽減等 →アドホックな分析と比較すると、満遍ない視点での対策検討が出来ることを体験 ・STAMP/STPA、STAMP/CASTとの相性の良さ →分析時に着眼点、ヒントワードなどを利用する点が似ているので、違和感がない 32
33. Result ・The 4STEP/M Method’ｓ effect. It helps in considering countermeasures from a broad perspective. intrinsic safety / functional safety / prevention of recurrence/ damage mitigation, etc. →Compared to ad hoc analysis, its method helps to think of perspective countermeasures. ・ The 4STEP/M method is suitable for STAMP/STPA, and STAMP/CAST → Thinking solution using hint-word is similar. Hence the 4STEP/M method, the STAMP/STPA, and the STAMP/CAST feel like similar usability. 33
34. アクシデ ントID アクシデント ハザード ID ハザード 安全制約 ID 安全制約 A1 情報発信によってご当地のブランドイメージを損な う H1 ゆるきゃらSNSアカウントから外部発信される情報 が熊本県のブランドイメージを損なう発言である。 SC1 ゆるきゃらSNSアカウントから外部発信される情報 がご当地のブランドイメージ向上に貢献すること A2 ゆるキャラのファンに対して公式運営から連絡がと れない H2 ゆるキャラSNSサービスが利用できないことによっ て、通知を受け付けない。 SC2 ゆるキャラのSNSサービスが利用可能で、情報の投 稿が可能であること。 A2 ゆるキャラのファンに対して公式運営から連絡がと れない H3 ゆるキャラファンはSNSサービルが利用出来ず、投 稿された情報が参照できない SC3 ゆるキャラファンはSNSサービルが利用可能であ り、投稿された情報が参照できること。 A2 ゆるキャラのファンに対して公式運営から連絡がと れない H4 SNSサービスが動作しない事によって、サービスそ のものが利用できない。 SC4 SNSサービスが利用できること 考察 追加で下記事例（STAMP/CASTによる分析）を行いました。 （参考事例）：【ゆるキャラSNSのアカウント乗っ取り事例の分析】 事件自体は以下の通り ① ゆるキャラのSNSアカウントが乗っ取られた ② 乗っ取られたアカウントから不正なメッセージが投稿され始めた ③ 運営は新しいアカウントを作成し、そちらに変更することを案内する ④ 一時的に旧アカウント、新アカウント、偽アカウントの3つのアカウントが存在し、 利用者（約20,000人）に混乱を招いた 34
35. Accide nt ID accident Hazard ID hazard Safety Constr aint ID Safety Constraints A1 Damage to the local brand image by disseminating information H1 The information transmitted externally from the Yurukyara SNS account is a statement that damages the brand image of Kumamoto Prefecture. SC1 Information transmitted externally from Yurukyara SNS accounts contributes to improving the brand image of the local area. A2 Fans of Yuru Chara cannot be contacted by the official management. H2 Notifications will not be accepted due to the unavailability of the Yuru Chara SNS service. SC2 Yuru Chara's SNS service must be available and information must be posted. A2 Fans of Yuru Chara cannot be contacted by the official management. H3 Yuru Chara fans cannot use SNS services, and they cannot refer to the posted information. SC3 Yuru Chara fans can use SNS services, and the posted information can be referenced. A2 Fans of Yuru Chara cannot be contacted by the official management. H4 If the SNS service does not work, the service itself cannot be used. SC4 SNS services must be available Reference I added analyse followings case（Using STAMP/CAST analysys） （example）：【Local mascot characters' SNS pages were takeover】 incident's overview ① Local mascot characters' SNS pages were takeover ② The SNS account started to post illegal articles ③ The SNS operator made a new SNS account and asked for the user to switch to the new SNS account. ④ Many people were confused because they didn't know which account could trust. 35
36. 考察：（参考事例）【ゆるキャラSNSのアカウント乗っ取り事例の分析】 情報漏えい～SNSアカウント乗っ取り事例をベースにCS図作成 36
37. Consideration： （example）：【Local mascot characters' SNS pages were takeover】 followings: Control Structure diagram. 37
38. 考察 【クラウドベースのWebアプリケーションに対する分析】 コンポーネント数：１２ アクシデントの数：６、ハザード/制約条件の数：13 UCAの数：９2 【ゆるキャラSNSのアカウント乗っ取り事例の分析】 コンポーネント数：６ アクシデントの数：４ UCAの数：２８ SCFの数：２9 ※本分析については、事件そのものがセキュリティに起因する問題であったので、STRIDEによるSCF抽出のみ実施 ・モデルが大きくなると、UCAの抽出、SCF、HCFいずれの分析作業についても、作 業が増大し、それに伴う集中力の低下、精度の問題があるように思える。 ・コンポーネント数が多いモデルでは、UCA、SCF、HCFなどが増えるので、対策の実 施に当たっては、優先順位をつけた方がよいと感じた。 38
39. Consideration 【Analyze the web-based application on the cloud】 Components：１２ Accidents：６、Hazards/Safety constraints：13 UCA：９2 【Local mascot characters' SNS pages were takeover】 Components ：６ (1 exceptional component exclude) Accidents：４ Hazards/Safety constraints:4 UCA：２８ SCF：２9 ※This security incident analyzed only SCF using STRIDE method. ・The workload of UCA and SCF/HCF analysis increases with model size, and accuracy is affected by the analyzer's fatigue or subjective bias. ・It's better to decide on a priority for countermeasures since in models with many components, UCA, SCF, and HCF increase. 39
40. 40 考察 対策の実施にあたり、類似の役割をもったステークホルダーには類似のUCAが出て くるため、数も多いように感じた。 これらをもとに考えるとUCA以降の分析前に分析作業を減らすためには以下のよう な検討が今後有効になると考える。 ① パターン分類の実施 ② 分析の支援や自動化 ③ リスク評価によるABC分析のようなことを実施し、分析対象を絞り込む また、4STEP/Mでのリスク評価は、言葉での表現のため、定量的に効果を表現しに くいので、これについても今後検討が必要と考える。
41. 41 Consideration When implementing measures, we noticed that stakeholders with similar roles often encounter similar UCAs, resulting in a higher number of UCAs. To reduce the analysis workload before proceeding with UCA and beyond, the following considerations could be effective: ① Implementing pattern classification ② Supporting or automating the analysis ③ Conducting ABC analysis based on risk evaluation to narrow down the analysis targets Additionally, risk evaluation in 4STEP/M is expressed verbally, making it difficult to quantify the effects. Therefore, further consideration is needed in this area.
42. 42 考察： 対策の実施にあたり、類似の役割をもったステークホルダーには類似のUCAが出て くるため、数も多いように感じた。 これらをもとに考えるとUCA以降の分析前に分析作業を減らすためには以下のよう な検討が今後有効になると考える。 ① パターン分類の実施 ② 分析の支援や自動化 ③ リスク評価によるABC分析のようなことを実施し、分析対象を絞り込む また、4STEP/Mでのリスク評価は、言葉での表現のため、定量的に効果を表現しに くいので、これについても今後検討が必要と考える。
43. 結論 • STAMP/STPA、およびSTAMP/CASTの分析後の対策の検討 に4STEP/Mを利用した結果、より戦略的に対策の検討を進める ことができた。一方でモデルのステークホルダーが増えると飛躍 的にUCA以降の分析作業が増加することから今後考察に示すよ うな何らかの方法で、対応が必要と考える。 • また、リスク評価についても、今回の方法では言語表現なので、何 らかの方法により、定量化できるようにしたい。 43
44. Conclusion • Using the 4STEP/M method to consider measures after analyzing with STAMP/STPA and STAMP/CAST allowed us to develop countermeasures more effectively. However, as the number of stakeholders in the model increases, the workload for UCA and subsequent analyses grows exponentially. Therefore, we must explore methods to address this, as discussed in the following considerations. • Additionally, the current risk evaluation method relies on verbal expressions, making it difficult to quantify the effects. We aim to develop a method for quantification in the future. 44
45. ありがとうございました。 45
46. Thank you. 46
47. 参考資料 / Reference • IPA(Information technology Promotion Agency, Japan),STAMP ガイドブック ～システム思考による安全分析～ 2019年3月公開, https://www.ipa.go.jp/digital/stamp/about.html,2024/02/12参 照 • 金子 朋子(Tomoko Kaneko)ら,セーフティ＆セキュリティ入門 AI、IoT時代の システム安全,日科技連(Nikka-giren), 2021 • 河野龍太郎(Ryutaro.Kono)，医療におけるヒューマンエラー 第2版 なぜ間違 える どう防ぐ，医学書院(Igaku-shoin).p.72，2004 47