ソフトウェアの最新動向 - jst.go.jp · 1....

ソフトウェアの最新動向

2013年8月31日

科学技術振興機構

DEOSC 屋代眞

http://www.dependable-os.net/

Copyright © 2013 Japan Science and Technology Agency

1. ＩＴ技術の進化とソフトウェアの役割の変化

組込みシステムの進化と複雑なシステム

2. 最近のソフトウェア信頼性の考え方

ディペンダビリティー

DEOS ProcessとD-Case

3. D-Case

D-Caseとは？

D-Caseの事例紹介

4. DEOSプロジェクトについて少し宣伝

5. まとめ

2

本日のお話しの内容

Transistor Count and Moore's Law

Wikipedia http://en.wikipedia.org/wiki/File:Transistor_Count_and_Moore%27s_Law_-_2008.svg

x2 every 18 to 24 months

3

オブジェクトサイズ

出展：日経エレクトロニクス2009.9-11（no.778）をベースに追加、修正。経済産業省「組込みソフト産業の課題と政策展開」平成19年11月14日より

2000

100MB

10M

1M

100K

1990 1995

ＩＴＳ対応

蓄積型データ放送

3/4G対応

i モード対応

DVDカーナビ

VICS対応カーナビ

音声誘導CD-ROM

テレビ

携帯電話

カーナビ JAVA対応

i モード対応

パケット通信対応インターネット・テレビ

デジタル携帯電話ハイビジョン

テレビ

単機能複合機能ネットワーク化サービスポータル

組込みソフトウェア規模の拡大とネットワーク化

4

狭義の組込みシステム専用端末携帯電話車載システム航空・宇宙システム

広義の組込みシステムユビキタスインフラ情報統合

ネットワークを通じたITシステムと組込みシステムの一体化

組込みソフトウェア

5

近年のシステム障害事例

発生日時障害内容原因

1 2012年8月13-15日

NTTドコモの携帯で、最大220か国・地域で8万人の携帯電話での音声通話やインターネット通信がしにくくなった。ローミングサービスの障害。

5月の時点で、3月に入れ替えた装置の設定ミスでローミングに関して能力の半分しか使えない状態になっていたことを発見していたが、修正によりロンドン五輪期間中に大規模障害が発生しては問題であるとして、修正を見送ったため。

2 2012年8月7日

東京証券取引所で、デリバティブ売買システムのネットワーク機器のハードウェア障害が発生。自動切替えを試みるも不具合により切替え処理が行われず取引が停止した。

本番系である1号機にハードウェア障害が生じた場合は待機系である2号機に自動切替えされるが、1号機では内部の部分的ハードウェア障害を正しく検知できなかったため、1号機、2号機とも本番系として稼働することとなりスイッチに接続されている装置がどちらに信号を送ればよいのか特定することが不可能となったため。

3 2012年8月2-3日

NTTドコモの携帯で、152万人の携帯電話が通じにくくなった。

2台ある装置の1台が故障したため。信号経路を迂回すれば対応できるとして修正を見送ったため。

4 2012年6月20日

ファーストサーバを利用していた一部の顧客のサーバ設定情報やデータベースの情報等が消失した。

その復旧作業において、情報漏洩が起きた可能性もある。

脆弱性対策のための更新プログラムに「ファイル削除コマンドを停止させるための記述漏れ」不具合があったことに加え、検証環境下で確認による防止機能が十分に働かず、意図しないファイル削除が発生したため。

復旧作業の手順やプログラムに不備があり、別顧客の情報が混入するのを防げなかったため。

5 2012年2月2日

東京証券取引所で、株式売買システムの情報配信機能で障害が発生し、外部に情報が発信できなかったために、3時間半にわたって一部銘柄の取引を停止した。

三重化されたサーバの1台に障害が発生したが、残り2台への自動切り替えに成功したと判断して障害対応を完了したが、実際には切り替えに失敗していたため対応が遅れ、経営陣への報告も行わなかったため。

6 2011年6月6日から2012年1月25日まで（５度に渡る）

NTTドコモの携帯で、通話やパケット通信がつながりにくい状況が繰り返し発生。関連してメールアドレスが他人のものに置き換わるという事故も発生。

この期間に起こった、携帯端末の位置情報を管理するシステムの障害、中継ルータの故障に伴う機器の切り替えをきっかけにした認証サーバでの輻輳、新たに運用を始めたパケット交換機の設計における信号量の見積もりミスによる動作不安定などが原因と思われる。

7 2011年4月21日

Amazon EC2サービスなどがダウンした。これにともなってEngine Yard、Heroku、など、数多くのサイトがダウンした。

仮装マシンの外付けストレージサービスAmazon EBSでネットワーク設定を誤ったことが原因。

8 2011年3月15日から22日

みずほ銀行で夜間バッチ処理やオンラインの停止が起きた。

ATMが利用不可能になり、為替処理遅延や二重振り込みなどの問題が発生した。

義援金を受け付ける口座の振り込み件数の上限を大きく設定していなかったため、上限を超える振り込みがあったことを発端として、夜間バッチ処理の異常終了、それに伴う多重のオペレーションミスなどが関連していたためと思われる。

9 2010年8月10日から12日

ユーザがmixi（日本最大のSNSサイト）にアクセスできなかった。

汎用の分散型メモリーキャッシュシステムmemcachedのバグ。memcachedデーモンが多数の接続/切断を持っているときに突然終了する事が原因。

10 2009年5月22日

NTTドコモの携帯電話に内蔵されているJavaScriptが任意のウェブサイトへの不正アクセスを許可していた。ドコモは販売を停止した。

JavaScriptの実装に欠陥があり任意のウェブサイトへの不正アクセスを生じた。Webブラウザで使用されるSOP（Same Originポリシー）のセキュリティポリシーの実装に問題がある可能性がありドコモが携帯電話用の仕様で書いていなかったと疑われている。

11 2009年2月24日

Google AppsのGmailユーザは自分のアカウントにアクセスできなかった。

データセンターでの定期的なメンテナンス中に予想外のサービス中断が発生した。このよう場合、ユーザはメンテナンス作業の準備のために代替データセンターに振り分けられるが、ユーザデータの場所を最適化する新しいソフトウェアに予期せぬ副作用がありGmailのコード内の潜在的なバグを誘発した。バグはユーザが送信先のデータセンターに振り分けられるとユーザのトラフィックが自動的に障害対応に移行してしまった。これにより複数のダウンストリームの過負荷状態を引き起こし、データセンターを過負荷状態にしたことが原因。

12 2008年9月14日

複数の空港の搭乗口の端末が非稼動となりフライトのキャンセルを発生させた。

ターミナルからサーバシステムへのアクセスを承認する証明書が9月14日の早朝に期限切れをむかえたことが原因。

13 2008年7月22日

デリバティブ取引システムから情報の一部がユーザに配信できなかった。

一銘柄あたりのワーキングメモリーを予想されたサイズよりもはるかに小さく定義していた。これにより複数の銘柄に損失をもたらした。

14 2007年10月12日

東京近郊の鉄道ICカード用チケットゲートが機能しなくなった。

サーバから改札側に本質的な情報を送信する間の巨大データを小さなデータの塊に分割するロジックに原始的なエラーがあった。改札側にデータ受信の無限ループを発生させた。

15 2007年5月27日

ANAの搭乗手続きシステムが停止した。130便がキャンセル、306便に遅延が生じた。

ハードウェア障害によって引き起こされるネットワーク機器のトラブルがホストコンピュータと端末間の輻輳をもたらした。ネットワーク機器のトラブルのイベントと輻輳の関係が知られていなかったため見過ごされていた。

16 2006年9月19日、2006年10月23日、2007年5月16日、2007年5月23日

IP電話の接続が困難になった。

NTT西とNTT東の接続が故障し不通となった。

フレッツが7時間非接続となった。

キャパシティを越えた。シグナリングサーバ内のバグが原因でシグナリング処理のオーバーフローが発生した。

キャパシティプランニングの推定ミスが原因で信号処理のオーバーフローが発生した。

不良データが保守後に復元されてしまい、これがシグナリングサーバを停止させた。

ひとつのルータ障害が他のルータへの不正なルーティング情報の伝播を引き起こした。しかし、ルータを再起動することが解決だという確信が持てなかった。

17 2003年3月1日

航空計画データ処理システムがダウンした。215便がキャンセル、1500便に遅延が生じた。

原因は一つのバグにより生じた。このバグは特定のメモリーをアドレスすると発生するがテストが十分に行われなかったため発見できなかった。

出展： DEOS プロジェクト Project Update 2012http://www.dependable-os.net/osddeos/data/DEOS-FY2012-PU-01J.pdf

6

システムの大規模化プログラムサイズ多機能化、複雑化ブラックボックス化したコンポーネント

環境の変化技術進化のスピード接続システムの変更

利害関係者の変化要求の頻繁な変更要求や合意に対する考え方

大規模なシステム障害

6

7

組込みシステムの現状

①組込みソフトウェアの規模と領域の拡大

②ネットワークへの組込み

③サーバー・クライアント・組込み機器の一体化

④常に要求・環境が変化する

• 組込みシステム開発にもＩＴシステム開発の手法の適用が必要

• 開発プロセス・要件定義手法など従来技術の必要性

• 従来技術だけでは解決できない障害の解決の重要性

1960年代後半

フォールトトレラント計算機－実時間かつミッションクリティカルな利用

1970年代

RAS (Reliability, Availability, Serviceability) －システムのエラー検出と回復

1970年代後半

RASIS (RAS, Integrity, Security) － RASの拡張

2000年代

自立型コンピューティング(Autonomic Computing) －ネットワークで結合された複雑なシステム

8

信頼性等に関する考え方の変遷

参考資料•A. Avizienis, ” Design of fault-tolerant computers”, In Proc. 1967 Fall Joint Computer Conf., AFIPS Conf. Proc.Vol.31, pages 733-743, 1967•M. Y. Hsiao, W. C. Carter, J. W. Thomas, and W. R. Stringfellow, “Reliability, Availability, and Serviceability of IBM Computer Systems: A QuarterCentury of Progress”, IBM J. Res. Develop., Vol. 25, No. 5, 1981, pages 453-465• “An architectural blueprint for autonomic computing, 4th edition”, IBM Autonomic Computing White Paper, June 2006

国際安全規格 ISO 13849-1 (EN954-1) 1996年

電気安全規格 IEC 60204-1 1997年（第４版）

単純な部品や機器に関する規格

機能安全規格 IEC 61508 2000年

ソフトウェアの考慮

不規則なハードウェア故障・系統的障害

原子力関連 IEC 61513 2001年

鉄道関連 IEC 62278 2002年

プロセス関連 IEC61511 2003年

電動モータ IEC61800 2003年

機械類関連 IEC 62061 2005年

自動車関連 IEC 26262 （ガイドラインを除く） 2011年

9

信頼性・安全性に関する国際標準

何故Dependabilityが必要か？人間の社会・生活の情報システム依存が高まってきた

→ たとえエラーや障害がおこってもできる限り良質で信頼できるサービスが継続できることが重要

予測できないエラーや障害に対処する必要が増えてきた

→ ＩＴの手法に新しい考え方が必要

どのようにDependabilityの基礎を築いていくか？ Dependabilityはデバイス技術、ハードウェア技術、ソフトウェア技術、

ネットワーク技術、プロセス、さらに社会の仕組みまで含んだ問題としてとらえる

→ なかでもソフトウェアの占める重要性の増加

→ 開発・運用を一体化したプロセスの重要性

システムの持つ不完全さ・不確実さを考慮する

→ ビジネスの継続性の重視と説明責任に基づいた考え方

→ 変化への対応

10

Dependability

利用者が期待する便益をできる限り安全にかつ継続

的に提供する

システムの障害要因を顕在化する前にできる限り取り除く

障害が顕在化した後に迅速かつ適切に対応する

障害が起こった時の影響を最小とするようにマネージする

同様の障害を繰り返さない

社会への説明責任を全うする

上記を継続的に行う能力をもつ

11

新たなシステム・ディペンダビリティーの考え方

注2： DEOSプロジェクトでは上記のディペンダビリティーの考え方をOpen SystemsDependabilityと名付けました。

注1： DEOSプロジェクトとは、（独）科学技術振興機構のCRESTの研究領域「実用

化を目指した組込みシステム用ディペンダブル・オペレーティングシステム」の略称 DEOS: Dependable Engineering for Open Systems。

12

DEOS ビデオ

DEOS紹介ビデオ： http://www.dependable-os.net/osddeos/index.html

反復的アプローチ目的や環境の変化に対してシステムを継続的に変更して行くためのサイクル

障害に対して迅速に対応するためのサイクル

D-Caseを含む合意記述データベースにより合意形成および開発・運用フェーズの統合を支援

13

DEOSプロセス

システムの開発・運用における不完全さ

システムの持つ不完全さ－複雑さ

システムの持つ不確実さ－変化

システム構築・運用で目指すもの

ビジネスの継続性

説明責任

ビジネスの継続性・説明責任実現のために

ステークホルダーの合意

開発と運用の一体化

実現を支える技術

プロセス

アーキテクチャ・ツール

14

DEOSの考え方のまとめ

私たちを取り巻くシステム環境の変化

システムの大規模化

プログラムサイズ、多機能化、ブラックボックス化したコンポーネント、

複雑化、…

環境の変化

技術進化のスピード、接続システム、…

利害関係者の変化

要求の頻繁な変更、要求や合意に対する考え方の変化、…

15

http://www.dcase.jp/pdf/tamaru20130419.pdf参考）田丸喜一郎、DEOS, D-Caseへの期待第３回D-Case実証評価研究会２０１３．４．１９

なぜD-Case が必要なのか？

出展 D-Case超入門、2013 D-Case委員会（http://www.dcase.jp）

安全性をどのように保証しますか？

1988年の北海油田事故(167名死亡)などを契機に、欧米で

規格認証の際に Assurance Case の提出が義務づけられる

手順のみでなく、なぜ安全性が保たれるのか、明示された議論で、エ

ビデンスをもとに保証する

導入により北海油田における事故が減少

Prescriptive(宣言的) と Goal Based（ゴール指向）

Prescriptive:認証者から与えられたチェックリストをチェックする

Goal Based: 要求される安全ゴールを満たしていることの議論を構築

する

ISO26262などGoal Basedな認証を要求している

16 出展 D-Case超入門、2013 D-Case委員会（http://www.dcase.jp）

Assurance Caseとは

システムが与えられた適用先と環境で、十分にディペンダブル（安全）であることを提供する証拠ドキュメント（他にも定義あり）

ゴール

エビデンス

エビデンス

エビデンス

議論の構造

例: システムは安全である

例: FTA(Fault Tree Analysis)の結果など


Assurance Caseの呼び方

Assurance Caseは日本語だと保証ケース

Caseは法廷用語で、証拠書類などの意味

Assurance Caseは、安全性を議論する場合は

Safety Case, ディペンダビリティを議論する場合は

Dependability Caseと呼ばれる

Assurance Case

Safety CaseDependability CaseSecurity Case…


Assurance Case から D-Case へ

これからのディペンダビリティのためには

従来手法をより高め

変化に対応し

利害関係者間でディペンダビリティを議論し、

共有する必要がある

Assurance Caseをベースに、ディペンダビリティの課題

を解くための手法とツール

D-Case


D-Caseの定義

ライフサイクルを通じて、システムの

ディペンダビリティをステークホルダが合意し、社会に

説明責任を果たすための手法と

ツール。主としてAssurance Caseを記述するための手法

とツールを提供する。ドキュメント自体もD-Caseと呼ぶ

20


松野、山本著｢実践 D-Case｣を

（株）アセットマネジメントより出版（ISBN: 978-4-862930-91-0 ）

21

要求に対するステークホルダー合意の形成

ステークホルダーサービス・製品の利用者（潜在的

ステークホルダー）サービス・製品の提供者（事業主）システム提供者

• 設計開発者• 保守運用者• ハードウェア供給者

サービス・製品認可者（規制監督官庁）

合意の形成合意の形成はステークホルダーそれぞれがAssuredness（確信）を得る

ことによりなされる Assurednessを得るためのツールとしてD-Caseを開発した

D-Caseの読み方

22

システムは安全で

ある

ハザードごとに議論する

ハザードAに対処できる

ハザードリスト

A,B

ハザードBに対処できる

テスト結果

テスト結果

前提

ゴール

戦略

証拠(エビデンス)

きちんと前提（仮定）を共有した上で

議論すべき命題を設定し

議論の流れ（ゴールからサブゴール）を確認し

議論を展開し

確かな証拠によって最終的にゴールを支える

当たり前の科学的思考を実践する論理式のように完全に形式化するのではなく（できない）、議論の不完全さを確認し、合意していく


23

GSNのノードと関係

名称図式要素説明

ゴールシステムが達成すべき性質を示す．戦略に基づいて下位ゴールに分解される

戦略ゴールの達成を導くために必要となる論証を示す．下位ゴールや下位戦略に分解される

前提ゴールや戦略が必要となる理由としての外部情報を示す

未達成まだ具体化できていないゴールや戦略を示す

証拠ゴールや戦略が達成できることを示す証拠

前提関係ゴールや戦略と前提との関係

ゴール関係ゴールと戦略，ゴールと証拠の関係

システムはディペンダブルである

ハザードリスト

ハザードごとに議論する

テスト結果

Solved by

in context of


GSN: Goal Structuring Notation

24

D-Case Editor

http://www.dependable-os.net/tech/D-CaseEditor/index.html

25

D-Case Weaver http://www.dependable-os.net/tech/DCaseWeaver/index.html

26

D-Case Stencil for PowerPoint

http://www.dependable-os.net/tech/D-CaseStencil/index.html

Goal: G_1

システムはディペンダブルである

Context: C_1

ディペンダビリティ阻害要因リスト

Strategy: S_1

阻害要因ごとに議論する

D-Case事例 M銀行システム障害（2011年）の概要

2011年3月11日（金）に発生した東日本大震災発生に伴い、14日（月）におけるA社の義援金口座a、及び、15日（火）におけるB社の義援金口座bという特定の口座にそれぞれ大量

の振込が集中したことにより、夜間バッチが異常終了したことに端を発し、以下の障害が発生した

障害内容（顧客へのサービスやビジネスに対し多大な影響を与えた）1. 給与振込等の為替送信の遅延(のべ250万件、3/14～3/24)

2. 営業店業務の取引開始遅延及び取引停止(3/15～3/25)

取引開始時刻の遅延（3/15（火）、16（水）、17（木））

融資、ローン及び外国為替の取引停止（3/15（火）～3/22（火））

ローンの条件変更及び全額回収に係る取引停止（3/15（火）～3/25（金））

3. ATMの利用停止及び利用制限（3/16（水）～3/23（水））

4. ダイレクトチャネルの利用制限

みずほダイレクト（3/16（水）14:30～3/17（木）10:30、 3/17（木）14:30～3/22（火）12:00 ）

e-ビジネスサイト及び法人向けEB（ 3/16（水）、 3/17（木）8:00 ～11:30、 3/17（木）19:00～3/22（火）12:00 ）

5. 営業店窓口での特定支払対応（3/19（土）～3/21（月・祝））

6. その他

取引明細の欠落

口座振替における処理不能、誤った結果のデータ還元及び処理漏れ

その他夜間バッチの中段に伴う取引内容の不具合

特例支払対応の未回収

27

システム障害の原因分析

1. 夜間バッチ異常終了と為替送信の遅延の原因（システム機能）大量取引が集中した場合のシステム処理単位

大量明細がある場合の後続の夜間バッチへのデータ振り分け処理量がリミット値を超越した

夜間バッチが長期化した際のシステム運用機能

夜間バッチの長期化への対処である夜間バッチ中断することにより、その後の処理が膨大な手数を要することや為替送信が遅延する仕組みに対する対応策をあらかじめ検討していなかった

2. 復旧時の不手際の原因（復旧対応における緊急時態勢）緊急時における態勢が実効性を伴っていなかった

システムコンティンジェンシープランとして想定すべき事象が不足していた

復旧対応の手順書が実効性を伴っていなかった

チェックプロセス及び訓練が上記の実効性を検証する役割を果たせていなかった

3. 通常運用時の点検不備の原因

（未然防止に向けたシステムリスク管理）

定期的システムリスク評価及び新商品・サービス導入時のシステムリスク評価の点検項目の見通しが不十分であった

（経営管理及び監査）人材の計画育成および適所配置の視点が希薄であった

監査体制の不備や外部監査の活用の遺漏

28

大量振込などの変化する要件への対応には、異常発生時にもサービスが継続するような仕組みが必要である

29

システム障害原因に対応するD-Case適用のポイント

システム機能へのD-Caseの適用

障害原因

復旧時の不手際の原因（復旧対応における緊急時態勢）

緊急時における態勢が実効性を伴っていなかった

システムコンティジェンシープランとして想定すべき事象が不足していた

復旧対応の手順書が実効性を伴っていなかった

チェックプロセス及び訓練が上記の実効性を検証する役割を果たせていなかった

夜間バッチ異常終了と為替送信の遅延の原因（システム機能）

大量取引が集中した場合のシステム処理単位

夜間バッチへのリミット値を超越した

夜間バッチが長期化した際のシステム運用機能

夜間バッチ中断することにより、その後の処理が膨大な手数を要することや為替送信が遅延する仕組みに対する対応策をあらかじめ検討していなかった

通常運用時の点検不備の原因

（未然防止に向けたシステムリスク管理）

定期的システムリスク評価及び新商品・サービス導入時のシステムリスク評価の点検項目の見通しが不十分であった

（経営管理及び監査）

人材の計画育成および適所配置の視点が希薄であった

監査体制の不備や外部監査の活用の遺漏

D-Case適用ポイント

システム機能以外へのD-Caseの適用

1. サービス継続のための緊急時態勢の可視化

① リミット値の超越や夜間バッチ処理の中断などの異

常時でもサービスを継続するための運用を含む

ケースを明確化

② ステークホルダーとの合意

③ 実施担当者の明確化

2. 通常運転時のモニタリング

D-Caseのエビデンスやモニタを用いて、システムリス

ク評価の点検結果や人材のスキルや人材配置の点

検結果、監査結果や外部監査結果などの可視化

＜適用にあたっての基本的な考え方＞• 異常時のケースを全て明らかにするのではなく、異常発生時でも影響の最小化やサービス

継続を進めるためのケースを明らかにする

30

• トップゴールの展開：集中記帳処理（夜間バッチ処理）のケース（抜粋）

• 経営上、システムにリミット値を持たせる選択の元、G_2：リミット値内での処理のケース、G_4：リミット値の見直しのケース、G_3:リミット値超過や時限超過が発生するケース、とすべての条件を網羅したゴール設定を行い、分析を実施

１-① サービス継続のための緊急時態勢の可視化

システム障害事例へのD-Case適用時の有効性 (1/3)

31

• 人的展開が必要なリミット値越えの展開：集中記帳処理（夜間バッチ処理）のケース（抜粋）

• ゴールと戦略の合意を行うべきステークホルダや合意のポイント、それを行う実施担当者の明確化を実施

１-② ステークホルダー（経営層）との合意ポイント

１-③ 実施担当者の明確化


32


• D-Case記述内容が信頼できるエビデンスで終端：集中記帳処理（夜間バッチ処理）のケース（抜粋）

• リミット値超過や時限超過が発生するケースでも、訓練実施結果や参加者リストなど、通常運転時に確認できるビジネスコンティンジェンシープランのエビデンスで終端し、実効性のモニタリング

２．通常運転時のモニタリング

網羅性の可視化：システム機能の分析だけではカバーできない、人的対応部分も含め、サービス継続のための緊急時体制を可視化できる

（適用事例での例）リミット値超過や時限超過が発生するケースを分析

責任者の総覧化・可視化： D-Caseの１ドキュメント上に、ゴール毎に、経営層を含む実施担当者、合意したステークホルダーを明確化できる

（適用事例での例）

実施担当者：経営判断：経営者、復旧態勢や顧客対応：各実施責任者

合意ポイント：合意ステークホルダ、緊急時や事業継続性の態勢、ビジネスコンティンジェンシープラン

通常運転時確認可能なエビデンスで終端： D-Caseの最終ゴールのエビデンスは通常運転時にモニタリングできる内容として明確化することができる

（適用事例での例）ビジネスコンティンジェンシープランの実効性のモニタリング

33

• 異常（障害）発生時の迅速な対応と顧客サービスへの影響の最小化の実現• 経営層を含むステークホルダーとの合意形成の容易化と可視化の実現• 障害発生時の説明内容の可視化と説明責任の容易化の実現

その結果

D-Case適用により

システム障害事例へのD-Case適用のまとめ

D-Case事例 PC遠隔操作による誤認逮捕（ 2012年）の概要

1. 遠隔ウィルスによるトラブル発生概要

2012年（平成24年）の初夏から秋にかけて、日本において、犯人がネットの掲示

板を介して他者のパソコンを遠隔操作し、これを踏み台としてウェブサイト、イン

ターネット掲示板、メールを通じて襲撃予告や爆破予告などの犯罪予告を行った

サイバー犯罪。その犯人として４人が誤認逮捕された

2. 誤認逮捕が発生した原因

書き込みに使用されたPCのIPアドレスと犯人として誤認逮捕された人のPCのIPア

ドレスが一致した

複数のウィルス対策ソフトの検査では遠隔操作ウィルス（新種のトロイの木馬）の

痕跡の発見は不可能であった

3. 誤認逮捕であることが判明した根拠

逮捕後の押収したPCの解析で、犯人とされていたPCから遠隔操作ウィルスの１つ

である新種のトロイの木馬を検出した（このトロイの木馬は自分自身を削除する

機能を備えているが、ある1人のPCはトロイの木馬が残っていた）

真犯人を名乗る者からの犯行声明文

34

(出典） Wikipedia 「パソコン遠隔操作事件」http://ja.wikipedia.org/wiki/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3%E9%81%A0%E9%9A%94%E6%93%8D%E4%BD%9C%E4%BA%8B%E4%BB%B6

誤認逮捕事案の分析

利用者がPCを安全に利用（継続利用）する観点から本事案のIT

系技術に関連する原因を以下に示す

（誘導）

ウイルスが仕掛けられた不正プログラムをダウンロードするように誘導された

（検知）

新しいウィルス（トロイプログラム）のため、ウイルス対策ソフトウェアの最新の定

義ファイルでもこのウイルスを検知できなかった

ウイルスが自動で動作するため、ウイルスの挙動を利用者が認識することができ

なかった（三重県の事案を除く）

（痕跡）

ウイルスの動作による掲示板への書き込みに関する痕跡が残ったままとなった

ウイルス自体が削除されたため、ウイルス自体の痕跡が残らなかった

35

誤認逮捕事案の原因に対応するD-Case適用のポイント

原因

（誘導）

ウイルスが仕掛けられた不正プログラムをダウンロード

するように誘導された

（検知）

新しいウィルス（トロイプログラム）のため、ウイルス対

策ソフトウェアの最新の定義ファイルでもこのウイルス

を検知できなかった

ウイルスが自動で動作するため、ウイルスの挙動を利

用者が認識することができなかった（三重県の事案を

除く）

（痕跡）

ウイルスの動作による掲示板への書き込みに関する痕

跡が残ったままとなった

ウイルス自体が削除されたため、ウイルス自体の痕跡

が残らなかった

D-Case適用ポイント

PCの安全利用に関するD-Caseの適用

1. 安全利用を示すPC利用(動作）のモニタリング・利用者、訪問したURLの履歴、キータイプ情報、ネットワーク上の通信記録などの可視化

⇒ PC利用に関する説明責任

2. PCの不審な挙動に対して外部との遮断（ネットワーク遮断）などの対応策の実施

⇒ 脅威による影響の最小化

3. PCの安全利用のための対策の明確化①システムによる自動防御

1) ウイルス対策ソフトウェアの最新化と実行- ウイルス対策ソフトウェアの実行履歴- ウイルス定義ファイルの最新化の履歴、など（実行記録も含めた記録）

2) ソフトウェアのセキュリティ対策のための最新化- セキュリティパッチの実施履歴

②利用者による利用ルールの遵守・メール添付ファイルの安全確認、など

36

＜適用にあたっての基本的な考え方＞• PC利用にあたって、自身、および、対外的に影響を与えないための継続的な安全利用（注

意義務の履行）のケースを明確化する

PCの予想外の振る舞いへの対応ケース展開

防ぎきれない脅威への対応や日頃守るべき利用ルールの設定と遵守、システム機能としての自動防御の明確化と脅威の最小化

誤認逮捕事案へのD-Case適用時の有効性

37

３-①システムによる自動防御による対応

（防ぎきれない脅威への対応）1 PC利用のモニタリング2 PCの不審な挙動に関する対応策の実施

3-② 利用者による利用ルールの遵守

防ぎきれない脅威に対する説明責任と脅威の最小化

PC操作とPCの状態の記録によるエビデンスや、PCの不審な挙動に関する対応策の実施と影響の最小化

誤認逮捕事案D-Case適用時の有効性

38

2 PCの不審な挙動に関する対応策の実施（影響の最小化）

1 PC利用のモニタリング（説明責任）

網羅性の可視化：システムによる自動防御だけでは対応することができない脅威を含めて、説明責任を果たすためのケースを可視化できる

（適用事例での例） PC利用者は自分の意図しないＰＣの振る舞いを証明できる

説明責任の明確化： PC利用のモニタリングによる説明責任の明確化（適用事例での例）PC利用者は、PCの安全利用を示すためにモニタリングによって日頃

のPC操作とPCの状態をすべて記録する

防ぎきれない脅威に対する影響の最小化行動： PCの不審な挙動に対する対応策の実施

（適用事例での例）PCの状態を監視して、ＰＣの不審な挙動を検知して、外部とのネットワーク接続を切断する

39

• 自分の意図しない振る舞いに対する説明責任の実現（PC安全利用支援ツール（説明責任支援）の利用）

• システムによる自動防御では防ぎきれない脅威に対する影響の最小化の実現

その結果

D-Case適用により

誤認逮捕事案へのD-Case適用のまとめ

D-CaseとSysML開発環境の連携－概要

DD--CaseCaseDD--CaseCase

• 安全要求• 信頼性要求

要望獲得・商品企画

要件定義

ソフト設計一致性検証

• 要求の実現方法• 検証仕様

実現方法や検証仕様 (=D-Case(下位))

システム検証

• 機能検証

• 安全要求の確認• 信頼性要求の確認

要件の実現の可否

システム設計

req [パッケージ] AnalysisPkg [REQ_CCS]

加減速性能<<Requirement>>

ID =RY_CCS_32

最低0.080gの加速度で加減速する

CCS<<Requirement>>

車両は運転者を支援する走行制御機能を搭載する

<<derive>> <<derive>> <<derive>><<derive>> <<derive>> <<derive>>

CCS起動（ Cruise）<<Requirement>>

ID = FY_CCS_01

CCS停止中に運転者が「Cruise」ボタンを押すと、CCSが起動する

<<derive>>

CCS停止（Cruise）<<Requirement>>

ID = FY_CCS_02

CCS起動中に運転者が「Cruise」ボタンを押すと、CCSを停止する

<<derive>>

目標車速の設定（Set）<<Requirement>>

ID = FY_CCS_03

CCS起動中に運転者が「Set」ボタンを押すと、現在の速度を設定値として保持する

<<derive>> <<derive>>

目標車速の減速（Decel）<<Requirement>>

ID = FY_CCS_04

CCS起動中に運転者が「Decel」ボタンを押すと、設定値の速度が下がる

<<derive>><<derive>>

<<derive>>

目標車速の加速（Accel）<<Requirement>>

ID = FY_CCS_05

CCS起動中に運転者が「Accel」ボタンを押すと、設定値の速度が上がる


CCS一時休止（Break）<<Requirement>>

ID = FY_CCS_06

CCS起動中に運転者がブレーキを踏むと、CCSを一時休止する


CCS再開（Resume）<<Requirement>>

ID = FY_CCS_07

CCS一時休止中に運転者が「Resume」ボタンを押すと、一時休止前の設定でCCSを再開する

<<derive>>

<<derive>>

応答性<<Requirement>>

ID = RY_CCS_23

運転者が操作盤で操作をすると、CCSは1ms以内に動作モードを切り替える

<<derive>>

<<derive>><<derive>> <<derive>> <<derive>>

<<derive>><<derive>><<derive>>

操作性<<Requirement>>

ID = RY_CCS_21

運転者は直感的に操作できる

<<derive>>

<<derive>>

CCS起動条件<<Requirement>>

ID = RY_CCS_24

CCSは現在速度が50km/h以上かつ100km/h以下の場合のみ起動する


加速度の測定頻度<<Requirement>>

ID = RY_CCS_33

加速度を毎秒10回測定する


車両の限界加速性能<<Requirement>>

0.5g未満の加速度で加減速

<<derive>> <<derive>><<derive>>

req [パッケージ] AnalysisPkg [REQ_CCS]

加減速性能<<Requirement>>

ID =RY_CCS_32

最低0.080gの加速度で加減速する

CCS<<Requirement>>



CCS起動（ Cruise）<<Requirement>>

ID = FY_CCS_01


<<derive>>

CCS停止（Cruise）<<Requirement>>

ID = FY_CCS_02

CCS起動中に運転者が「Cruise」ボタンを押すと、CCSを停止する

<<derive>>

目標車速の設定（Set）<<Requirement>>

ID = FY_CCS_03




ID = FY_CCS_04



<<derive>>


ID = FY_CCS_05

CCS起動中に運転者が「Accel」ボタンを押すと、設定値の速度が上がる


CCS一時休止（Break）<<Requirement>>

ID = FY_CCS_06



CCS再開（Resume）<<Requirement>>

ID = FY_CCS_07

CCS一時休止中に運転者が「Resume」ボタンを押すと、一時休止前の設定でCCSを再開する

<<derive>>

<<derive>>

応答性<<Requirement>>

ID = RY_CCS_23


<<derive>>



操作性<<Requirement>>

ID = RY_CCS_21


<<derive>>

<<derive>>


ID = RY_CCS_24

CCSは現在速度が50km/h以上かつ100km/h以下の場合のみ起動する



ID = RY_CCS_33




0.5g未満の加速度で加減速


要求図要求図

MBD (SysML)MBD (SysML)MBD (SysML)MBD (SysML)

パラメトリック図パラメトリック図

Goal

Strategy

Context

SubGoal

Evidence

SubGoal Context

Evidencebdd [パッケージ] AnalysisPkg

[BDD_car] 車両< >

Values

車重投射面積

Cd値

空気抵抗トルク

Operations

1

CC Sコントローラ< >

Values

Operations

11

ブレーキ< < bl o ck > >

Values

Operations

11

ユーザーI /F< >

Va lue s

Op era ti ons

1

1

車速センサー< < bl o ck > >

Values

Operations

1

1

1

1

1

PI制御< >

Values

Operations

1

1

1

1

1

1

1

1

1

1

車両力学制御< < bl o ck > >

Values

Ope rat io ns

1

1

1

1

1

1

1

1

1

1

電子制御スロットル< < bl o ck > >

Values

Operations

1

1

1

1

1

1

1

1

1

1

加速度センサー<>

Values

Operations

111

スロットルアクチュエータ< >

Values

Operations

1

bdd [パッケージ] AnalysisPkg[BDD_car] 車両

< >

Values

車重投射面積

Cd値

空気抵抗トルク

Operations

1

CC Sコントローラ< >

Values

Operations

11

ブレーキ< < bl o ck > >

Values

Operations

11

ユーザーI /F< >

Va lue s

Op era ti ons

1

1

車速センサー< < bl o ck > >

Values

Operations

1

1

1

1

1

PI制御< >

Values

Operations

1

1

1

1

1

1

1

1

1

1

車両力学制御< < bl o ck > >

Values

Ope rat io ns

1

1

1

1

1

1

1

1

1

1

電子制御スロットル< < bl o ck > >

Values

Operations

1

1

1

1

1

1

1

1

1

1

加速度センサー<>

Values

Operations

111

スロットルアクチュエータ< >

Values

Operations

1

ブロック定義図ブロック定義図

Context

による要求〜機能の関連付け・管理D-Caseによる要求〜機能の関連付け・管理

DD-Caseとモデル要素の関連付け

モデルシミュレーションによる開発上流での検証モデルシミュレーションによる開発上流での検証

モデルシミュレーション

40

D-CaseとSysML開発環境の連携－開発プロセスへのD-Case適用

•開発の上流で要求の妥当性を検証•ゴールの達成に必要な要件・機能の関係を継続的に明確化

システムのディペンダビリティを利⽤者などのシステムのディペンダビリティを利⽤者などの利害関係者に説明し納得してもらう

システムの開発・運⽤に当たって利⽤者などの利害関係者に説明すべきことを正しく説明するシステムの開発・運⽤に当たって利⽤者などの利害関係者に説明すべきことを正しく説明する

DD--CaseCase～モデル～モデルの関連付けの関連付け

合意形成の達成合意形成の達成説明責任の達成説明責任の達成

シミュレーションシミュレーションによる早期の検証による早期の検証要求～機能要求～機能

の関連付け・管理の関連付け・管理

Goal

Strategy

Context

SubGoal

Evidence

SubGoal Context

Evidence

Context

要望獲得・商品企画

要件定義

ソフト設計一致性検証

実現方法や検証仕様 (=D-Case(下位))

システム検証

要件の実現の可否

システム設計

req [パッケージ ] AnalysisPkg [REQ_CCS]

加減速性能

<<Requirement>>

I D =R Y_CCS_ 32

最低0.0 80gの加速度で加減速する

CCS

<<Requirement>>



CCS起動（ Cruise）

<<Requirement>>

ID = FY_CCS _01


<<derive>>

CCS停止（ Cruise）<<Requirement>>

I D = FY _CCS_0 2

C CS起動中に運転者が「Cru ise」ボタンを押すと、CCSを停止する

<<derive>>

目標車速の設定（Set）

<<Requirement>>

ID = FY_C CS_03




ID = FY_CC S_04



<<derive>>


ID = FY_C CS_05

CCS起動中に運転者が「Acc el」ボタンを押すと、設定値の速度が上がる


CCS一時休止（ Break）

<<Requirement>>

ID = FY_C CS_06



CCS再開（Resume）

<<Requirement>>

I D = FY _CCS_0 7

C CS一時休止中に運転者が「Resume」ボタンを押すと、一時休止前の設定でCCSを再開する

<<derive>>

<<derive>>

応答性

<<Requirement>>

ID = RY_CCS _23


<<derive>>



操作性

<<Requirement>>

I D = RY_ CCS_21


<<derive>>

<<derive>>


I D = RY _CCS_2 4

C CSは現在速度が50km/h以上かつ100km/h 以下の場合のみ起動する



ID = RY_C CS_33




0 .5g未満の加速度で加減速


req [パッケージ ] AnalysisPkg [REQ_CCS]

加減速性能

<<Requirement>>

I D =R Y_CCS_ 32

最低0.0 80gの加速度で加減速する

CCS

<<Requirement>>



CCS起動（ Cruise）

<<Requirement>>

ID = FY_CCS _01


<<derive>>

CCS停止（ Cruise）<<Requirement>>

I D = FY _CCS_0 2

C CS起動中に運転者が「Cru ise」ボタンを押すと、CCSを停止する

<<derive>>

目標車速の設定（Set）

<<Requirement>>

ID = FY_C CS_03




ID = FY_CC S_04



<<derive>>


ID = FY_C CS_05

CCS起動中に運転者が「Acc el」ボタンを押すと、設定値の速度が上がる


CCS一時休止（ Break）

<<Requirement>>

ID = FY_C CS_06



CCS再開（Resume）

<<Requirement>>

I D = FY _CCS_0 7

C CS一時休止中に運転者が「Resume」ボタンを押すと、一時休止前の設定でCCSを再開する

<<derive>>

<<derive>>

応答性

<<Requirement>>

ID = RY_CCS _23


<<derive>>



操作性

<<Requirement>>

I D = RY_ CCS_21


<<derive>>

<<derive>>


I D = RY _CCS_2 4

C CSは現在速度が50km/h以上かつ100km/h 以下の場合のみ起動する



ID = RY_C CS_33




0 .5g未満の加速度で加減速


要求図要求図

パラメトリック図パラメトリック図b dd [パッケージ ] Analy sisPkg

[BDD_ car] 車両<<block>>

Values

車重投射面積

Cd値空気抵抗

トルク

Operations

1

C CS コントローラ<<block>>

Values

Operations

11

ブレーキ<<block>>

Values

Operations

11

ユーザーI /F<<block>>

Values

Operations

1

1

車速センサー<<block>>

Values

Operations

1

1

1

1

1

PI 制御<<block>>

Values

Operations

1

1

1

1

1

1

1

1

1

1

車両力学制御<<block>>

Values

Operations

1

1

1

1

1

1

1

1

1

1

電子制御スロットル

<<block>>

Values

Operations

1

1

1

1

1

1

1

1

1

1

加速度センサー

<<block>>

Values

Operations

111

スロットルアクチュエータ<<block>>

Values

Operat ions

1

b dd [パッケージ ] Analy sisPkg

[BDD_ car] 車両<<block>>

Values

車重投射面積

Cd値空気抵抗

トルク

Operations

1

C CS コントローラ<<block>>

Values

Operations

11

ブレーキ<<block>>

Values

Operations

11

ユーザーI /F<<block>>

Values

Operations

1

1

車速センサー<<block>>

Values

Operations

1

1

1

1

1

PI 制御<<block>>

Values

Operations

1

1

1

1

1

1

1

1

1

1

車両力学制御<<block>>

Values

Operations

1

1

1

1

1

1

1

1

1

1

電子制御スロットル

<<block>>

Values

Operations

1

1

1

1

1

1

1

1

1

1

加速度センサー

<<block>>

Values

Operations

111

スロットルアクチュエータ<<block>>

Values

Operat ions

1

ブロック定義図ブロック定義図

モデルシミュレーション

DD--CaseCaseDD--CaseCase MBD (SysML)MBD (SysML)

41

D-CaseとSysML開発環境の連携－開発環境システム構成

テスト管理品質管理

タスク管理構成管理

SysMLモデル管理

D-Case EditorD-Case Editor

SysMLＳＷ開発環境

SysMLＳＷ開発環境

要求管理OSLC連携アドオンOSLC連携アドオン

D-Caseデータ連携D-Caseデータ連携

既存の開発環境の連携

Import Export

•D-Case Editor の OSLC連携アドオン•SW開発環境の D-Case データ連携機能

OSLCに準拠したI/Fによる連携

OSLC (Open Services for Lifecycle Collaboration)異なるALMツール間でのデータ連携を可能と

する仕様を策定

42

D-CaseとSysML開発環境の連携－デモ

1.1. DependabilityDependability合意形成の手法・ツール合意形成の手法・ツールDD--CaseCase

2.2. DD--CaseCase作成環境作成環境DD--Case EditorCase Editor

3.3. モデリング言語モデリング言語SysMLSysML

4.4. モデリング＆シミュレーション環境モデリング＆シミュレーション環境IBM Rational RhapsodyIBM Rational Rhapsody

自動車のクルーズコントロールシステム開発へ自動車のクルーズコントロールシステム開発へDD--CaseCaseを適用を適用

クルーズコントロールシステムの開発

43

D-CaseとSysML開発環境の連携－まとめ

D-CaseとSysML開発環境の連携のメリット

•D-Case Editor の OSLC連携アドオンの開発•SW開発環境の D-Case データ連携機能の開発

•開発の上流で要求の妥当性を検証できる•ゴールの達成に必要な要件・機能の関係を明確化できる

連携機能の開発

44

45

DEOS Homepage: http://www.dependable-os.net/

ステークホルダ合意形成支援ツール-> 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 )

46

主なDEOS要素技術・ツール群

DEOS HP DEOSを支える技術:http://www.dependable-os.net/osddeos/tech.html

IEC TC56 (Dependability) NWIP提案： Open Systems Dependability 2012年9月提出

エキスパートとして改定作業に参加

IEC60300-1： Dependability management （最上位規格：Open Systemの概念）

IEC 62741: Dependability case

IEC 62628: Guidance on software aspect of Dependability

ISO/IEC JTC1/SC7 (System and software engineering) ISO/IEC15026: System and software assurance (co-editor)

OMG (SysA: Systems Assurance Task Forceで活動) “Machine Checkable Assurance Language”の提案

RFI (Requests for Information: 2012-09-04

審議の後、Requests for Proposals, 投票を経て策定

“Dependability Assurance Framework for Safety-Sensitive Consumer Devices”の提案 IPA/SECコンシューマデバイスWG(委員長電通大新誠一教授)、トヨタ大畠氏らが中心となって提出

DEOSチームは標準化に協力

RFI (Requests for Information): 2011-12-02

White Paper: 2012-9-12

RFP(Request for Proposal): 2013.3発行、2013.11 Initial Submission

The Open Group RTES部会における標準化活動

Open Dependability Through Assuredness™(*) 標準V1.0発表（2013年7月15日）

公開ビデオ http://new.livestream.com/opengroup/allen-philly13/videos/24698802 （9分くらいから）

47

(*): Dependability Through Assuredness is a trademark of The Open Group

標準化活動－ IEC, ISO/IEC JTC1, OMG, & The Open Group

ET2013＠パシフィコ横浜（ http://www1.jasa.or.jp/et/ET2013/index.html ） DEOS技術展示： 11月20日（水）－22日（金）

DEOSセッション： 11月22日（金） 10：00－14：00

WOSD2013@Pasadena, CA, USA（ http://www.ubicg.ynu.ac.jp/wosd/wosd2013/ ） ISSRE2013: 11月4日－7日

WOSD2013: 11月4日（予定）

OSDコンソーシアム設立（予定）設立日

2013年12月01日

目的

事業継続・説明責任遂行の手法の確立

オープンシステムディペンダビリティー技術の標準化

DEOSに関連した産業の育成

オープンシステムディペンダビリティー技術の研修

会員間での非競争領域の共有（情報、事例、基盤プラットフォームの構築、等）

名称

一般社団法人ディペンダビリティ技術推進協会

英語名： The Association of Dependability Engineering for Open Systems (DEOS Association)

48

今後の主なイベント

組込みシステムとITそステムが一体となった巨大・複雑なＩＴＣシステムのディペンダビリティー向上は今後の最重要課題の一つ

組込みシステムとITシステムの開発・運用手法も一体化してきている

有効な概念・方法としてDEOSプロジェクトの成果をご紹介 D-Caseの活用方法や事例の一端のご紹介 DEOSの考え方はＩＣＴのみならず、多くの長期運用システム

に応用可能是非、DEOSプロジェクト及びDEOSコンソーシアムの活動を

ご支援ください

49

まとめ

JST/DEOS Centerhttp://www.dependable-os.net/index.html

JST/DEOS Projecthttp://www.crest-os.jst.go.jp/

http://www.jst.go.jp/kisoken/crest/research_area/ongoing/bunya04-4.html

ソフトウェアの最新動向 - jst.go.jp · 1....

Documents