本日のお話しの内容. IT 技術の進化とソフトウェアの役割の変化 組込みシステムの進化と複雑なシステム 2. 最近のソフトウェア信頼性の考え方 ディペンダビリティー DEOS ProcessとD-Case 3. D-Case D-Caseとは? D-Caseの事例紹介 4. DEOSプロジェクトにつ

Transcription

1 ソフトウェアの最新動向 203 年 8 月 3 日 科学技術振興機構 DEOSC 屋代眞 Copyright 203 Japan Science and Technology Agency

2 本日のお話しの内容. IT 技術の進化とソフトウェアの役割の変化 組込みシステムの進化と複雑なシステム 2. 最近のソフトウェア信頼性の考え方 ディペンダビリティー DEOS ProcessとD-Case 3. D-Case D-Caseとは? D-Caseの事例紹介 4. DEOSプロジェクトについて少し宣伝 5. まとめ 2

3 Transistor Count and Moore's Law x2 every 8 to 24 months 3 Wikipedia

4 組込みソフトウェア規模の拡大とネットワーク化 組込みソフトウェアオブジェクトサイズ i モード対応 00MB DVD カーナビ ITS 対応 音声誘導 CD-ROM VICS 対応カーナビ 蓄積型データ放送 3/4G 対応 0M カーナビ 単機能複合機能ネットワーク化 JAVA 対応 サービスポータル i モード対応 M テレビ 狭義の組込みシステム インターネット テレビ 専用端末ハイビジョンデジタル携帯電話携帯電話携帯電話テレビ 00K 車載システム航空 宇宙システム パケット通信対応 広義の組込みシステムユビキタスインフラ情報統合ネットワークを通じたITシステムと組込みシステムの一体化 2000 出展 : 日経エレクトロニクス (no.778) をベースに追加 修正 経済産業省 組込みソフト産業の課題と政策展開 平成 9 年 月 4 日より 4

5 近年のシステム障害事例 発生日時障害内容原因 202 年 8 月 3-5 日 年 8 月 7 日 年 8 月 2-3 日 年 6 月 20 日 年 2 月 2 日 6 20 年 6 月 6 日から 202 年 月 25 日まで (5 度に渡る ) 7 20 年 4 月 2 日 8 20 年 3 月 5 日から 22 日 NTT ドコモの携帯で 最大 220 か国 地域で 8 万人の携帯電話での音声通話やインターネット通信がしにくくなった ローミングサービスの障害 東京証券取引所で デリバティブ売買システムのネットワーク機器のハードウェア障害が発生 自動切替えを試みるも不具合により切替え処理が行われず取引が停止した NTT ドコモの携帯で 52 万人の携帯電話が通じにくくなった ファーストサーバを利用していた一部の顧客のサーバ設定情報やデータベースの情報等が消失した その復旧作業において 情報漏洩が起きた可能性もある 東京証券取引所で 株式売買システムの情報配信機能で障害が発生し 外部に情報が発信できなかったために 3 時間半にわたって一部銘柄の取引を停止した NTT ドコモの携帯で 通話やパケット通信がつながりにくい状況が繰り返し発生 関連してメールアドレスが他人のものに置き換わるという事故も発生 Amazon EC2 サービスなどがダウンした これにともなって Engine Yard Heroku など 数多くのサイトがダウンした みずほ銀行で夜間バッチ処理やオンラインの停止が起きた ATM が利用不可能になり 為替処理遅延や二重振り込みなどの問題が発生した 5 月の時点で 3 月に入れ替えた装置の設定ミスでローミングに関して能力の半分しか使えない状態になっていたことを発見していたが 修正によりロンドン五輪期間中に大規模障害が発生しては問題であるとして 修正を見送ったため 本番系である 号機にハードウェア障害が生じた場合は待機系である 2 号機に自動切替えされるが 号機では内部の部分的ハードウェア障害を正しく検知できなかったため 号機 2 号機とも本番系として稼働することとなりスイッチに接続されている装置がどちらに信号を送ればよいのか特定することが不可能となったため 2 台ある装置の 台が故障したため 信号経路を迂回すれば対応できるとして修正を見送ったため 脆弱性対策のための更新プログラムに ファイル削除コマンドを停止させるための記述漏れ 不具合があったことに加え 検証環境下で確認による防止機能が十分に働かず 意図しないファイル削除が発生したため 復旧作業の手順やプログラムに不備があり 別顧客の情報が混入するのを防げなかったため 三重化されたサーバの 台に障害が発生したが 残り 2 台への自動切り替えに成功したと判断して障害対応を完了したが 実際には切り替えに失敗していたため対応が遅れ 経営陣への報告も行わなかったため この期間に起こった 携帯端末の位置情報を管理するシステムの障害 中継ルータの故障に伴う機器の切り替えをきっかけにした認証サーバでの輻輳 新たに運用を始めたパケット交換機の設計における信号量の見積もりミスによる動作不安定などが原因と思われる 仮装マシンの外付けストレージサービス Amazon EBS でネットワーク設定を誤ったことが原因 義援金を受け付ける口座の振り込み件数の上限を大きく設定していなかったため 上限を超える振り込みがあったことを発端として 夜間バッチ処理の異常終了 それに伴う多重のオペレーションミスなどが関連していたためと思われる 年 5 月 22 日 2009 年 2 月 24 日 年 9 月 4 日 年 7 月 22 日 年 0 月 2 日 年 5 月 27 日 年 9 月 9 日 2006 年 0 月 23 日 2007 年 5 月 6 日 2007 年 5 月 23 日 年 3 月 日 NTT ドコモの携帯電話に内蔵されている JavaScript が任意のウェブサイトへの不正アクセスを許可していた ドコモは販売を停止した Google Apps の Gmail ユーザは自分のアカウントにアクセスできなかった 複数の空港の搭乗口の端末が非稼動となりフライトのキャンセルを発生させた JavaScript の実装に欠陥があり任意のウェブサイトへの不正アクセスを生じた Web ブラウザで使用される SOP(Same Origin ポリシー ) のセキュリティポリシーの実装に問題がある可能性がありドコモが携帯電話用の仕様で書いていなかったと疑われている データセンターでの定期的なメンテナンス中に予想外のサービス中断が発生した このよう場合 ユーザはメンテナンス作業の準備のために代替データセンターに振り分けられるが ユーザデータの場所を最適化する新しいソフトウェアに予期せぬ副作用があり Gmail のコード内の潜在的なバグを誘発した バグはユーザが送信先のデータセンターに振り分けられるとユーザのトラフィックが自動的に障害対応に移行してしまった これにより複数のダウンストリームの過負荷状態を引き起こし データセンターを過負荷状態にしたことが原因 ターミナルからサーバシステムへのアクセスを承認する証明書が 9 月 4 日の早朝に期限切れをむかえたことが原因 デリバティブ取引システムから情報一銘柄あたりのワーキングメモリーを予想されたサイの一部がユーザに配信できなかった ズよりもはるかに小さく定義していた これにより複数の銘柄に損失をもたらした 東京近郊の鉄道 IC カード用チケットゲートが機能しなくなった ANA の搭乗手続きシステムが停止した 30 便がキャンセル 306 便に遅延が生じた IP 電話の接続が困難になった NTT 西と NTT 東の接続が故障し不通となった フレッツが 7 時間非接続となった 航空計画データ処理システムがダウンした 25 便がキャンセル 500 便に遅延が生じた サーバから改札側に本質的な情報を送信する間の巨大データを小さなデータの塊に分割するロジックに原始的なエラーがあった 改札側にデータ受信の無限ループを発生させた ハードウェア障害によって引き起こされるネットワーク機器のトラブルがホストコンピュータと端末間の輻輳をもたらした ネットワーク機器のトラブルのイベントと輻輳の関係が知られていなかったため見過ごされていた キャパシティを越えた シグナリングサーバ内のバグが原因でシグナリング処理のオーバーフローが発生した キャパシティプランニングの推定ミスが原因で信号処理のオーバーフローが発生した 不良データが保守後に復元されてしまい これがシグナリングサーバを停止させた ひとつのルータ障害が他のルータへの不正なルーティング情報の伝播を引き起こした しかし ルータを再起動することが解決だという確信が持てなかった 原因は一つのバグにより生じた このバグは特定のメモリーをアドレスすると発生するがテストが十分に行われなかったため発見できなかった 年 8 月 0 日から 2 日 5 ユーザが mixi ( 日本最大の SNS サイト ) にアクセスできなかった 汎用の分散型メモリーキャッシュシステム memcached のバグ memcached デーモンが多数の接続 / 切断を持っているときに突然終了する事が原因 出展 : DEOS プロジェクト Project Update 202

6 大規模なシステム障害 システムの大規模化プログラムサイズ多機能化 複雑化ブラックボックス化したコンポーネント 環境の変化技術進化のスピード接続システムの変更 利害関係者の変化要求の頻繁な変更要求や合意に対する考え方 6 6

7 組込みシステムの現状 組込みソフトウェアの規模と領域の拡大 2ネットワークへの組込み 3サーバー クライアント 組込み機器の一体化 4 常に要求 環境が変化する 組込みシステム開発にも IT システム開発の手法の適用が必要 開発プロセス 要件定義手法など従来技術の必要性 従来技術だけでは解決できない障害の解決の重要性 7

8 信頼性等に関する考え方の変遷 960 年代後半 970 年代 フォールトトレラント計算機 - 実時間かつミッションクリティカルな利用 RAS (Reliability, Availability, Serviceability) - システムのエラー検出と回復 970 年代後半 2000 年代 RASIS (RAS, Integrity, Security) - RAS の拡張 自立型コンピューティング (Autonomic Computing) - ネットワークで結合された複雑なシステム 8 参考資料 A. Avizienis, Design of fault-tolerant computers, In Proc. 967 Fall Joint Computer Conf., AFIPS Conf. Proc.Vol.3, pages , 967 M. Y. Hsiao, W. C. Carter, J. W. Thomas, and W. R. Stringfellow, Reliability, Availability, and Serviceability of IBM Computer Systems: A Quarter Century of Progress, IBM J. Res. Develop., Vol. 25, No. 5, 98, pages An architectural blueprint for autonomic computing, 4th edition, IBM Autonomic Computing White Paper, June 2006

9 信頼性 安全性に関する国際標準 国際安全規格 ISO (EN954-) 996 年 電気安全規格 IEC 年 ( 第 4 版 ) 単純な部品や機器に関する規格 機能安全規格 IEC 年 ソフトウェアの考慮 不規則なハードウェア故障 系統的障害 原子力関連 IEC 年 鉄道関連 IEC 年 プロセス関連 IEC 年 電動モータ IEC 年 機械類関連 IEC 年 自動車関連 IEC ( ガイドラインを除く ) 20 年 9

10 Dependability 何故 Dependability が必要か? 人間の社会 生活の情報システム依存が高まってきた たとえエラーや障害がおこってもできる限り良質で信頼できるサービスが継続できることが重要 予測できないエラーや障害に対処する必要が増えてきた ITの手法に新しい考え方が必要 どのように Dependability の基礎を築いていくか? Dependability はデバイス技術 ハードウェア技術 ソフトウェア技術 ネットワーク技術 プロセス さらに社会の仕組みまで含んだ問題とし てとらえる なかでもソフトウェアの占める重要性の増加 開発 運用を一体化したプロセスの重要性 システムの持つ不完全さ 不確実さを考慮する ビジネスの継続性の重視と説明責任に基づいた考え方 変化への対応 0

11 新たなシステム ディペンダビリティーの考え方 利用者が期待する便益をできる限り安全にかつ継続的に提供する システムの障害要因を顕在化する前にできる限り取り除く 障害が顕在化した後に迅速かつ適切に対応する 障害が起こった時の影響を最小とするようにマネージする 同様の障害を繰り返さない 社会への説明責任を全うする 上記を継続的に行う能力をもつ 注 : DEOS プロジェクトとは ( 独 ) 科学技術振興機構の CREST の研究領域 実用化を目指した組込みシステム用ディペンダブル オペレーティングシステム の略称 DEOS: Dependable Engineering for Open Systems 注 2: DEOS プロジェクトでは上記のディペンダビリティーの考え方を Open Systems Dependability と名付けました

12 DEOS ビデオ DEOS 紹介ビデオ : 2

13 DEOS プロセス 反復的アプローチ 目的や環境の変化に対してシステムを継続的に変更して行くためのサイクル 障害に対して迅速に対応するためのサイクル D-Case を含む合意記述データベースにより合意形成および開発 運用フェーズの統合を支援 3

14 DEOS の考え方のまとめ システムの開発 運用における不完全さ システムの持つ不完全さ - 複雑さ システムの持つ不確実さ - 変化 システム構築 運用で目指すもの ビジネスの継続性 説明責任 ビジネスの継続性 説明責任実現のために ステークホルダーの合意 開発と運用の一体化 実現を支える技術 プロセス アーキテクチャ ツール 4

15 なぜ D-Case が必要なのか? 私たちを取り巻くシステム環境の変化 システムの大規模化 プログラムサイズ 多機能化 ブラックボックス化したコンポーネント 複雑化 環境の変化 技術進化のスピード 接続システム 利害関係者の変化 要求の頻繁な変更 要求や合意に対する考え方の変化 参考 ) 田丸喜一郎 DEOS, D-Case への期待第 3 回 D-Case 実証評価研究会 出展 D-Case 超入門 203 D-Case 委員会 (

16 安全性をどのように保証しますか? 988 年の北海油田事故 (67 名死亡 ) などを契機に 欧米で規格認証の際に Assurance Case の提出が義務づけられる 手順のみでなく なぜ安全性が保たれるのか 明示された議論で エ ビデンスをもとに保証する 導入により北海油田における事故が減少 Prescriptive( 宣言的 ) と Goal Based( ゴール指向 ) Prescriptive: 認証者から与えられたチェックリストをチェックする Goal Based: 要求される安全ゴールを満たしていることの議論を構築 する ISO26262 など Goal Based な認証を要求している 6 出展 D-Case 超入門 203 D-Case 委員会 (

17 Assurance Case とは システムが与えられた適用先と環境で 十分にディペンダブル ( 安全 ) であることを提供する証拠ドキュメント ( 他にも定義あり ) エビデンス ゴール 例 : FTA(Fault Tree Analysis) の結果など エビデンス 例 : システムは安全である エビデンス 議論の構造 7 出展 D-Case 超入門 203 D-Case 委員会 (

18 Assurance Case の呼び方 Assurance Case は日本語だと保証ケース Case は法廷用語で 証拠書類などの意味 Assurance Case は 安全性を議論する場合は Safety Case, ディペンダビリティを議論する場合は Dependability Case と呼ばれる Assurance Case Safety Case Dependability Case Security Case 8 出展 D-Case 超入門 203 D-Case 委員会 (

19 Assurance Case から D-Case へ これからのディペンダビリティのためには 従来手法をより高め 変化に対応し 利害関係者間でディペンダビリティを議論し 共有する必要がある Assurance Case をベースに ディペンダビリティの課題を解くための手法とツール D-Case 9 出展 D-Case 超入門 203 D-Case 委員会 (

20 D-Case の定義 ライフサイクルを通じて システムのディペンダビリティをステークホルダが合意し 社会に説明責任を果たすための手法とツール 主として Assurance Case を記述するための手法とツールを提供する ドキュメント自体も D-Case と呼ぶ 出展 D-Case 超入門 203 D-Case 委員会 ( 20 松野 山本著 実践 D-Case を ( 株 ) アセットマネジメントより出版 (ISBN: )

21 要求に対するステークホルダー合意の形成 ステークホルダー サービス 製品の利用者 ( 潜在的ステークホルダー ) サービス 製品の提供者 ( 事業主 ) システム提供者 設計開発者 保守運用者 ハードウェア供給者 サービス 製品認可者 ( 規制監督官庁 ) 合意の形成 合意の形成はステークホルダーそれぞれが Assuredness( 確信 ) を得ることによりなされる Assuredness を得るためのツールとして D-Case を開発した 2

22 D-Case の読み方 議論すべき命題を設定し ゴール 戦略 当たり前の科学的思考を実践する論理式のように完全に形式化するのではなく ( できない ) 議論の不完全さを確認し 合意していく ハザード A に対処できる テスト結果 システムは安全である ハザードごとに議論する ハザード B に対処できる テスト結果 ハザードリスト A,B 前提 証拠 ( エビデンス ) きちんと前提 ( 仮定 ) を共有した上で 議論の流れ ( ゴールからサブゴール ) を確認し 議論を展開し 確かな証拠によって最終的にゴールを支える 22 出展 D-Case 超入門 203 D-Case 委員会 (

23 GSN のノードと関係 GSN: Goal Structuring Notation 名称図式要素説明 ゴール システムはディペンダブルである システムが達成すべき性質を示す. 戦略に基づいて下位ゴールに分解される 戦略 前提 未達成 ハザードごとに議論する ハザードリスト ゴールの達成を導くために必要となる論証を示す. 下位ゴールや下位戦略に分解される ゴールや戦略が必要となる理由としての外部情報を示す まだ具体化できていないゴールや戦略を示す 証拠 前提関係 ゴール関係 テスト結果 in context of Solved by ゴールや戦略が達成できることを示す証拠 ゴールや戦略と前提との関係 ゴールと戦略, ゴールと証拠の関係 23 出展 D-Case 超入門 203 D-Case 委員会 (

24 D-Case Editor 24

25 D-Case Weaver 25

26 D-Case Stencil for PowerPoint Context: C_ ディペンダビリティ阻害要因リスト Goal: G_ システムはディペンダブルである Strategy: S_ 阻害要因ごとに議論する 26

27 D-Case 事例 M 銀行システム障害 (20 年 ) の概要 20 年 3 月 日 ( 金 ) に発生した東日本大震災発生に伴い 4 日 ( 月 ) における A 社の義援金口座 a 及び 5 日 ( 火 ) における B 社の義援金口座 b という特定の口座にそれぞれ大量の振込が集中したことにより 夜間バッチが異常終了したことに端を発し 以下の障害が発生した 障害内容 ( 顧客へのサービスやビジネスに対し多大な影響を与えた ). 給与振込等の為替送信の遅延 ( のべ 250 万件 3/4~3/24) 2. 営業店業務の取引開始遅延及び取引停止 (3/5~3/25) 取引開始時刻の遅延 (3/5( 火 ) 6( 水 ) 7( 木 )) 融資 ローン及び外国為替の取引停止 (3/5( 火 )~3/22( 火 )) ローンの条件変更及び全額回収に係る取引停止 (3/5( 火 )~3/25( 金 )) 3. ATM の利用停止及び利用制限 (3/6( 水 )~3/23( 水 )) 4. ダイレクトチャネルの利用制限 みずほダイレクト (3/6( 水 )4:30~3/7( 木 )0:30 3/7( 木 )4:30~3/22( 火 )2:00 ) e- ビジネスサイト及び法人向け EB( 3/6( 水 ) 3/7( 木 )8:00 ~:30 3/7( 木 )9:00~3/22( 火 ) 2:00 ) 5. 営業店窓口での特定支払対応 (3/9( 土 )~3/2( 月 祝 )) 6. その他 取引明細の欠落 口座振替における処理不能 誤った結果のデータ還元及び処理漏れ その他夜間バッチの中段に伴う取引内容の不具合 特例支払対応の未回収 27

28 システム障害の原因分析. 夜間バッチ異常終了と為替送信の遅延の原因 ( システム機能 ) 大量取引が集中した場合のシステム処理単位 大量明細がある場合の後続の夜間バッチへのデータ振り分け処理量がリミット値を超越した 夜間バッチが長期化した際のシステム運用機能 夜間バッチの長期化への対処である夜間バッチ中断することにより その後の処理が膨大な手数を要することや為替送信が遅延する仕組みに対する対応策をあらかじめ検討していなかった 2. 復旧時の不手際の原因 ( 復旧対応における緊急時態勢 ) 緊急時における態勢が実効性を伴っていなかった システムコンティンジェンシープランとして想定すべき事象が不足していた 復旧対応の手順書が実効性を伴っていなかった チェックプロセス及び訓練が上記の実効性を検証する役割を果たせていなかった 3. 通常運用時の点検不備の原因 ( 未然防止に向けたシステムリスク管理 ) 定期的システムリスク評価及び新商品 サービス導入時のシステムリスク評価の点検項目の見通しが不十分であった ( 経営管理及び監査 ) 人材の計画育成および適所配置の視点が希薄であった 監査体制の不備や外部監査の活用の遺漏 大量振込などの変化する要件への対応には 異常発生時にもサービスが継続するような仕組みが必要である 28

29 システム障害原因に対応する D-Case 適用のポイント < 適用にあたっての基本的な考え方 > 異常時のケースを全て明らかにするのではなく 異常発生時でも影響の最小化やサービス継続を進めるためのケースを明らかにする 障害原因 復旧時の不手際の原因 ( 復旧対応における緊急時態勢 ) 緊急時における態勢が実効性を伴っていなかった システムコンティジェンシープランとして想定すべき事象が不足していた 復旧対応の手順書が実効性を伴っていなかった チェックプロセス及び訓練が上記の実効性を検証する役割を果たせていなかった 夜間バッチ異常終了と為替送信の遅延の原因 ( システム機能 ) 大量取引が集中した場合のシステム処理単位 夜間バッチへのリミット値を超越した 夜間バッチが長期化した際のシステム運用機能 夜間バッチ中断することにより その後の処理が膨大な手数を要することや為替送信が遅延する仕組みに対する対応策をあらかじめ検討していなかった 通常運用時の点検不備の原因 ( 未然防止に向けたシステムリスク管理 ) 定期的システムリスク評価及び新商品 サービス導入時のシステムリスク評価の点検項目の見通しが不十分であった ( 経営管理及び監査 ) 人材の計画育成および適所配置の視点が希薄であった 監査体制の不備や外部監査の活用の遺漏 D-Case 適用ポイント システム機能への D-Case の適用 システム機能以外への D-Case の適用. サービス継続のための緊急時態勢の可視化 2 3 リミット値の超越や夜間バッチ処理の中断などの異常時でもサービスを継続するための運用を含むケースを明確化 ステークホルダーとの合意 実施担当者の明確化 2. 通常運転時のモニタリング D-Case のエビデンスやモニタを用いて システムリスク評価の点検結果や人材のスキルや人材配置の点検結果 監査結果や外部監査結果などの可視化 29

30 システム障害事例への D-Case 適用時の有効性 (/3) トップゴールの展開 : 集中記帳処理 ( 夜間バッチ処理 ) のケース ( 抜粋 ) 経営上 システムにリミット値を持たせる選択の元 G_2: リミット値内での処理のケース G_4: リミット値の見直しのケース G_3: リミット値超過や時限超過が発生するケース とすべての条件を網羅したゴール設定を行い 分析を実施 - サービス継続のための緊急時態勢の可視化 30

31 システム障害事例への D-Case 適用時の有効性 (2/3) 人的展開が必要なリミット値越えの展開 : 集中記帳処理 ( 夜間バッチ処理 ) のケース ( 抜粋 ) ゴールと戦略の合意を行うべきステークホルダや合意のポイント それを行う実施担当者の明確化を実施 -3 実施担当者の明確化 -2 ステークホルダー ( 経営層 ) との合意ポイント 3

32 システム障害事例への D-Case 適用時の有効性 (3/3) D-Case 記述内容が信頼できるエビデンスで終端 : 集中記帳処理 ( 夜間バッチ処理 ) のケース ( 抜粋 ) リミット値超過や時限超過が発生するケースでも 訓練実施結果や参加者リストなど 通常運転時に確認できるビジネスコンティンジェンシープランのエビデンスで終端し 実効性のモニタリング 2. 通常運転時のモニタリング 32

33 システム障害事例への D-Case 適用のまとめ D-Case 適用により 網羅性の可視化 : システム機能の分析だけではカバーできない 人的対応部分も含め サービス継続のための緊急時体制を可視化できる ( 適用事例での例 ) リミット値超過や時限超過が発生するケースを分析責任者の総覧化 可視化 : D-Case の ドキュメント上に ゴール毎に 経営層を含む実施担当者 合意したステークホルダーを明確化できる ( 適用事例での例 ) 実施担当者 : 経営判断 : 経営者 復旧態勢や顧客対応 : 各実施責任者 合意ポイント : 合意ステークホルダ 緊急時や事業継続性の態勢 ビジネスコンティンジェンシープラン 通常運転時確認可能なエビデンスで終端 : D-Caseの最終ゴールのエビデンスは通常運転時にモニタリングできる内容として明確化することができる ( 適用事例での例 ) ビジネスコンティンジェンシープランの実効性のモニタリング その結果 33 異常 ( 障害 ) 発生時の迅速な対応と顧客サービスへの影響の最小化の実現 経営層を含むステークホルダーとの合意形成の容易化と可視化の実現 障害発生時の説明内容の可視化と説明責任の容易化の実現

34 D-Case 事例 PC 遠隔操作による誤認逮捕 ( 202 年 ) の概要. 遠隔ウィルスによるトラブル発生概要 202 年 ( 平成 24 年 ) の初夏から秋にかけて 日本において 犯人がネットの掲示板を介して他者のパソコンを遠隔操作し これを踏み台としてウェブサイト インターネット掲示板 メールを通じて襲撃予告や爆破予告などの犯罪予告を行ったサイバー犯罪 その犯人として 4 人が誤認逮捕された 2. 誤認逮捕が発生した原因 書き込みに使用された PC の IP アドレスと犯人として誤認逮捕された人の PC の IP アドレスが一致した 複数のウィルス対策ソフトの検査では遠隔操作ウィルス ( 新種のトロイの木馬 ) の痕跡の発見は不可能であった 3. 誤認逮捕であることが判明した根拠 逮捕後の押収した PC の解析で 犯人とされていた PC から遠隔操作ウィルスの つである新種のトロイの木馬を検出した ( このトロイの木馬は自分自身を削除する機能を備えているが ある 人の PC はトロイの木馬が残っていた ) 真犯人を名乗る者からの犯行声明文 34 ( 出典 ) Wikipedia パソコン遠隔操作事件 8B%E4%BB%B6

35 誤認逮捕事案の分析 利用者が PC を安全に利用 ( 継続利用 ) する観点から本事案の IT 系技術に関連する原因を以下に示す ( 誘導 ) ウイルスが仕掛けられた不正プログラムをダウンロードするように誘導された ( 検知 ) 新しいウィルス ( トロイプログラム ) のため ウイルス対策ソフトウェアの最新の定義ファイルでもこのウイルスを検知できなかった ウイルスが自動で動作するため ウイルスの挙動を利用者が認識することができなかった ( 三重県の事案を除く ) ( 痕跡 ) ウイルスの動作による掲示板への書き込みに関する痕跡が残ったままとなった ウイルス自体が削除されたため ウイルス自体の痕跡が残らなかった 35

36 誤認逮捕事案の原因に対応する D-Case 適用のポイント < 適用にあたっての基本的な考え方 > PC 利用にあたって 自身 および 対外的に影響を与えないための継続的な安全利用 ( 注意義務の履行 ) のケースを明確化する 原因 ( 誘導 ) ( 検知 ) ( 痕跡 ) ウイルスが仕掛けられた不正プログラムをダウンロードするように誘導された 新しいウィルス ( トロイプログラム ) のため ウイルス対策ソフトウェアの最新の定義ファイルでもこのウイルスを検知できなかった ウイルスが自動で動作するため ウイルスの挙動を利用者が認識することができなかった ( 三重県の事案を除く ) ウイルスの動作による掲示板への書き込みに関する痕跡が残ったままとなった ウイルス自体が削除されたため ウイルス自体の痕跡 が残らなかった D-Case 適用ポイント PC の安全利用に関する D-Case の適用. 安全利用を示す PC 利用 ( 動作 ) のモニタリング 利用者 訪問した URL の履歴 キータイプ情報 ネットワーク上の通信記録などの可視化 PC 利用に関する説明責任 2. PC の不審な挙動に対して外部との遮断 ( ネットワーク遮断 ) などの対応策の実施 脅威による影響の最小化 3. PC の安全利用のための対策の明確化 システムによる自動防御 ) ウイルス対策ソフトウェアの最新化と実行 - ウイルス対策ソフトウェアの実行履歴 - ウイルス定義ファイルの最新化の履歴 など ( 実行記録も含めた記録 ) 2) ソフトウェアのセキュリティ対策のための最新化 - セキュリティパッチの実施履歴 2 利用者による利用ルールの遵守 メール添付ファイルの安全確認 など 36

37 誤認逮捕事案への D-Case 適用時の有効性 PC の予想外の振る舞いへの対応ケース展開 防ぎきれない脅威への対応や日頃守るべき利用ルールの設定と遵守 システム機能としての自動防御の明確化と脅威の最小化 3- システムによる自動防御による対応 3-2 利用者による利用ルールの遵守 ( 防ぎきれない脅威への対応 ) PC 利用のモニタリング 2 PC の不審な挙動に関する対応策の実施 37

38 誤認逮捕事案 D-Case 適用時の有効性 防ぎきれない脅威に対する説明責任と脅威の最小化 PC 操作と PC の状態の記録によるエビデンスや PC の不審な挙動に関する対応策の実施と影響の最小化 2 PC の不審な挙動に関する対応策の実施 ( 影響の最小化 ) PC 利用のモニタリング ( 説明責任 ) 38

39 誤認逮捕事案への D-Case 適用のまとめ D-Case 適用により 網羅性の可視化 : システムによる自動防御だけでは対応することができない脅威を含めて 説明責任を果たすためのケースを可視化できる ( 適用事例での例 ) PC 利用者は自分の意図しない PC の振る舞いを証明できる説明責任の明確化 : PC 利用のモニタリングによる説明責任の明確化 ( 適用事例での例 )PC 利用者は PC の安全利用を示すためにモニタリングによって日頃の PC 操作と PC の状態をすべて記録する 防ぎきれない脅威に対する影響の最小化行動 : PC の不審な挙動に対する対応策の実施 ( 適用事例での例 )PC の状態を監視して PC の不審な挙動を検知して 外部とのネットワーク接続を切断する その結果 39 自分の意図しない振る舞いに対する説明責任の実現 (PC 安全利用支援ツール ( 説明責任支援 ) の利用 ) システムによる自動防御では防ぎきれない脅威に対する影響の最小化の実現

40 bdd [ パッケージ ] AnalysisPkg [BDD_car] < < bl o ck > > < <b l o ck > > ブレーキ CC S コントローラ Values Values Operations Operations re q [ パッケージ ] A na ly s is Pk g [R E Q_ CC S] CC S 起動 ( Cr ui se ) ID = FY_CCS_0 CCS 停止中に運転者が Cruise ボタンを押すと CCS が起動する << d er iv e> > < < de ri ve >> CC S 起動条件操作性 ID = RY_CCS_24 ID = RY_CCS_2 CCS は現在速度が運転者は直感的 50km/h 以上かつに操作できる 00km/h 以下の場合のみ起動する < < bl o ck > > 車速センサー Values Operations < <b l oc k >> PI 制御 Values Operations C C S 車両は運転者を支援する走行制御機能を搭載する < <d er iv e> > < < de ri ve >> < <d er iv e >> << de ri v e> > < <d e ri ve >> < <d er iv e> > << de ri ve > > C C S 停止 (C r ui se ) 目標車速の設定 (Se t ) 目標車速の減速 (De c el ) 目標車速の加速 (Ac c el ) CC S 一時休止 (Br e ak ) ID = FY_CCS_02 ID = FY_CCS_03 ID = FY_CCS_04 ID = FY_CCS_05 ID = FY_CCS_06 CCS 起動中に運転者 CCS 起動中に運転者 CCS 起動中に運転者 CCS 起動中に運転 CCS 起動中に運転が Cruise ボタンが Set ボタンをが Decel ボタン者が Accel ボ者がブレーキを踏を押すと CCS を停押すと 現在の速を押すと 設定値のタンを押すと 設むと CCS を一時止する度を設定値として速度が下がる定値の速度が上が休止する保持するる < <b l oc k >> 車両 Values 車重投射面積 Cd 値空気抵抗トルク Operations << b l oc k >> 加速度センサー Values Operations < < bl o ck > > 車両力学制御 Values Ope rat io ns << de r iv e> > < <d er i ve >> < < de ri ve >> << de ri v e> > << < de er ri iv v ve e> >> > << de ri v e> > < <d er iv e >> 応答性加減速性能加速度の測定頻度 ID = RY_CCS_23 ID = ID = RY_CCS_33 RY_CCS_32 運転者が操作盤で操最低 0.080g の加速度を毎秒 0 回測定作をすると CCS は加速度で加減する ms 以内に動作モード速するを切り替える < < bl o ck > > 電子制御スロットル Values Operations < <b l oc k >> スロットルアクチュエータ Values Operations << b lo c k> > ユーザー I /F Va lue s Op era ti ons C C S 再開 (R e su me ) ID = FY_CCS_07 CCS 一時休止中に運転者が Resume ボタンを押すと 一時休止前の設定で CCS を再開する 車両の限界加速性能 0.5g 未満の加速度で加減速 D-Case と SysML 開発環境の連携 - 概要 D-Case D-Case による要求 機能の関連付け 管理 MBD (SysML) Goal Context 要望獲得 商品企画 SubGoal Strategy SubGoal Context Context 要件定義 安全要求 信頼性要求 要求図 システム設計 要求の実現方法 検証仕様 要件の実現の可否 安全要求の確認 信頼性要求の確認 モデルシミュレーション D-Case とモデル要素の関連付け システム検証 機能検証 Evidence Evidence パラメトリック図 ブロック定義図 ソフト設計 モデルシミュレーションによる開発上流での検証 一致性検証 実現方法や検証仕様 (=D-Case( 下位 )) 40

41 req [ パッケージ ] AnalysisPkg [REQ_CCS] CCS 起動 ( Cruise ) ID = FY_CCS _0 CCS 停止中に運転者が C ruise ボタンを押すと CCS が起動する <<derive>> CCS 起動条件 I D = RY _CCS_2 4 C CS は現在速度が 5 0km/h 以上かつ 00km/h 以下の場合のみ起動する b dd [ パッケージ ] Analy sispkg < <b l o ck > > ブレーキ Values Operations [BDD_ car] < < bl o c k> > C CS コントローラ Values Operations <<derive>> <<derive>> <<derive>> CCS 停止 ( Cruise ) 目標車速の設定 (Set) I D = FY _CCS_0 2 ID = FY_C CS_03 C CS 起動中に運転者 CCS 起動中に運転者が Cru ise ボタンが Set ボタンをを押すと CCS を停押すと 現在の速止する度を設定値として保持する <<derive>> 操作性 I D = RY_ CCS_2 運転者は直感的に操作できる < <b l o c k> > 車速センサー < < bl o c k >> PI 制御 Values Operations Values Operations < < b lo c k >> 車両 Values 車重投射面積 C d 値空気抵抗トルク Operations 加速度センサー < < b lo c k >> 車両力学制御 Values < < b lo c k >> Values Operations Op er at io ns CCS 車両は運転者を支援する走行制御機能を搭載する <<derive>> <<derive>> <<derive>> <<derive>> 目標車速の減速 (Decel) 目標車速の加速 (Accel) CCS 一時休止 ( Break) ID = FY_CC S_04 ID = FY_C CS_05 ID = FY_C CS_06 CCS 起動中に運転者 CCS 起動中に運転 CCS 起動中に運転が Decel ボタン者が Acc el ボ者がブレーキを踏を押すと 設定値のタンを押すと 設むと CCS を一時速度が下がる定値の速度が上が休止するる <<derive>> <<derive>> <<derive>> <<derive>> <<derive>> <<derive>> <<derive>> 加速度の測定頻度応答性加減速性能 ID = RY_CCS _23 I D = ID = RY_C CS_33 R Y_CCS_ 32 運転者が操作盤で操最低 g の加速度を毎秒 0 回測定作をすると CCS は加速度で加減する ms 以内に動作モード速するを切り替える < <b l o c k> > 電子制御スロットル Values Operations < < b lo c k >> スロットルアクチュエータ Values Operat ions < < bl o c k> > ユーザー I /F V al ue s O pe ra ti on s CCS 再開 (Resume ) I D = FY _CCS_0 7 C CS 一時休止中に運転者が R esume ボタンを押すと 一時休止前の設定で C CS を再開する 車両の限界加速性能 0.5g 未満の加速度で加減速 D-Case と SysML 開発環境の連携 - 開発プロセスへの D-Case 適用 合意形成の達成 システムのディペンダビリティを利 者などの利害関係者に説明し納得してもらう 説明責任の達成 システムの開発 運 に当たって利 者などの利害関係者に説明すべきことを正しく説明するする 開発の上流で要求の妥当性を検証 ゴールの達成に必要な要件 機能の関係を継続的に明確化 D-Case D-Case~ モデルの関連付け シミュレーションによる早期の検証 要求 ~ 機能の関連付け 管理 MBD (SysML) Goal Context 要件定義 要望獲得 商品企画要件の実現の可否 Strategy 要求図システム設計 モデルシミュレーションシステム検証 SubGoal SubGoal Context Evidence Evidence Context パラメトリック図ソフト設計一致性検証ブロック定義図実現方法や検証仕様 (=D-Case( 下位 )) 4

42 D-Case と SysML 開発環境の連携 - 開発環境システム構成 D-Case Editor の OSLC 連携アドオン SW 開発環境の D-Case データ連携機能 OSLC 連携アドオン D-Case Editor OSLC に準拠した I/F による連携 OSLC (Open Services for Lifecycle Collaboration) 異なる ALM ツール間でのデータ連携を可能とする仕様を策定 要求管理 テスト管理品質管理 Import Export タスク管理構成管理 42 D-Case データ連携 SysML SW 開発環境 SysML モデル管理 既存の開発環境の連携

43 D-Case と SysML 開発環境の連携 - デモ クルーズコントロールシステムの開発 自動車のクルーズコントロールシステム開発へD-Case を適用. Dependability 合意形成の手法 ツール D-Case 2. D-Case 作成環境 D-Case Editor 3. モデリング言語 SysML 4. モデリング & シミュレーション環境 IBM Rational Rhapsody 43

44 D-Case と SysML 開発環境の連携 - まとめ D-Case と SysML 開発環境の連携のメリット 開発の上流で要求の妥当性を検証できる ゴールの達成に必要な要件 機能の関係を明確化できる 連携機能の開発 D-Case Editor の OSLC 連携アドオンの開発 SW 開発環境の D-Case データ連携機能の開発 44

45 45 DEOS Homepage:

46 主な DEOS 要素技術 ツール群 ステークホルダ合意形成支援ツール -> D-Case Editor Web ブラウザ版 D-Case Editor -> D-Case Weaver パワーポイント用 D-Case ステンシル -> D-Case Stencil D-Case Verifier ( D-Case/Agda Extension for D-Case Verification ) -> 準備中 D-Script ( D-Case の記述を基にアプリケーションプログラムを動的に制御 ) -> 準備中 D-ADD ( DEOS Process/D-Case を支えるりポジトリー ) -> 準備中 ソフトウェア検証ツール -> モデル検査器 テスト支援ツール -> DS-Bench/Test-Env ( DS-Bench/D-Cloud ) シングル IP アドレスクラスタ -> Dependable Single IP Address Cluster ( SIAC ) 仮想マシンモニタと OS 監視ツール -> D-Visor + D-System Monitor DEOS を実現するサービスを提供するための実行環境 -> DEOS Runtime Environment ( D-RE ) DEOS HP DEOS を支える技術 : 46

47 標準化活動 - IEC, ISO/IEC JTC, OMG, & The Open Group IEC TC56 (Dependability) NWIP 提案 : Open Systems Dependability 202 年 9 月提出 エキスパートとして改定作業に参加 IEC60300-: Dependability management ( 最上位規格 :Open System の概念 ) IEC 6274: Dependability case IEC 62628: Guidance on software aspect of Dependability ISO/IEC JTC/SC7 (System and software engineering) ISO/IEC5026: System and software assurance (co-editor) OMG (SysA: Systems Assurance Task Force で活動 ) Machine Checkable Assurance Language の提案 RFI (Requests for Information: 審議の後 Requests for Proposals, 投票を経て策定 Dependability Assurance Framework for Safety-Sensitive Consumer Devices の提案 IPA/SECコンシューマデバイスWG( 委員長電通大新誠一教授 ) トヨタ大畠氏らが中心となって提出 DEOSチームは標準化に協力 RFI (Requests for Information): White Paper: RFP(Request for Proposal): 発行 203. Initial Submission The Open Group RTES 部会における標準化活動 Open Dependability Through Assuredness (*) 標準 V.0 発表 (203 年 7 月 5 日 ) 公開ビデオ (9 分くらいから ) (*): Dependability Through Assuredness is a trademark of The Open Group 47

48 今後の主なイベント パシフィコ横浜 ( ) DEOS 技術展示 : 月 20 日 ( 水 )-22 日 ( 金 ) DEOS セッション : 月 22 日 ( 金 ) 0:00-4:00 WOSD203@Pasadena, CA, USA( ) ISSRE203: 月 4 日 -7 日 WOSD203: 月 4 日 ( 予定 ) OSD コンソーシアム設立 ( 予定 ) 設立日 203 年 2 月 0 日 目的 事業継続 説明責任遂行の手法の確立 オープンシステムディペンダビリティー技術の標準化 DEOS に関連した産業の育成 オープンシステムディペンダビリティー技術の研修 会員間での非競争領域の共有 ( 情報 事例 基盤プラットフォームの構築 等 ) 名称 一般社団法人ディペンダビリティ技術推進協会 英語名 : The Association of Dependability Engineering for Open Systems (DEOS Association) 48

49 まとめ 組込みシステムと IT そステムが一体となった巨大 複雑な IT C システムのディペンダビリティー向上は今後の最重要課題の一つ 組込みシステムと IT システムの開発 運用手法も一体化してきている 有効な概念 方法として DEOS プロジェクトの成果をご紹介 D-Case の活用方法や事例の一端のご紹介 DEOS の考え方は ICT のみならず 多くの長期運用システムに応用可能 是非 DEOS プロジェクト及び DEOS コンソーシアムの活動をご支援ください JST/DEOS Center JST/DEOS Project