Ver. 1 - ipa.go.jp · Ver. 1.0 情報処理振興事業協会セキュリティセンター ... 5.3.1 経営サイドから見た必要性、プライオリティの設定.....23

13 情経第 1425 号

情報セキュリティインシデントに関わる調査

調査報告書

Ver. 1.0

情報処理振興事業協会

セキュリティセンター

履歴

公開（Ver. 1.0） 2002 年 6 月 7 日

Copyright (c) 2002 Information-technology Promotion Agency, Japan. All rights reserved.

i

目次

1. はじめに ...............................................................................................................................................1

2. 目的 ......................................................................................................................................................2

3. 調査の概要............................................................................................................................................3

3.1 調査対象.......................................................................................................................................3

3.2 調査期間.......................................................................................................................................3

3.3 調査方法.......................................................................................................................................3

3.4 調査の結果 ...................................................................................................................................3

3.4.1 ヒヤリング調査の結果 .........................................................................................................3

3.4.2 アンケート調査の結果(集計表) ............................................................................................3

3.4.3 アンケート回収率とヒアリング引受率 ................................................................................3

3.4.4 アンケート拒否の主な理由 ..................................................................................................4

3.5 調査結果の分析と特徴 .................................................................................................................5

3.5.1 対象企業の概要....................................................................................................................5

3.5.2 被害状況の概要.................................................................................................................. 11

3.6 調査の総括 .................................................................................................................................15

4. 情報セキュリティインシデント被害額算出モデルに関する検討 .......................................................17

4.1 表面化被害 .................................................................................................................................17

4.1.1 １次的な被害額..................................................................................................................17

4.1.2 ２次的な被害額..................................................................................................................18

4.2 潜在化被害 .................................................................................................................................18

4.2.1 潜在化被害額 .....................................................................................................................18

4.3 インシデント被害額算出モデル .................................................................................................19

5. 情報セキュリティインシデント対策費用額の算出モデルについての検討 .........................................21

5.1 情報セキュリティ関連予算の実際と算出モデル ........................................................................21

5.2 具体的な情報セキュリティ対策項目の提示 ...............................................................................22

5.3 各対策項目への必要性・プライオリティの設定 ........................................................................23

5.3.1 経営サイドから見た必要性、プライオリティの設定.........................................................23

5.3.2 システム（セキュリティ）管理者サイドから見た必要性、プライオリティの設定 ..........23

5.4 物理的費用、従業員数などの実数値の適用と、必要対策費の算出............................................24

5.5 情報セキュリティ対策費用把握の必要性について.....................................................................24

6. 想定企業および被害への情報セキュリティ被害算出モデルの適用と考察 .........................................25

6.1 被害額算出モデルを使用したシミュレーション ........................................................................25

6.1.1 会社のプロファイル...........................................................................................................25


ii

6.1.2 社内システムの構成...........................................................................................................25

6.1.3 現在のセキュリティ施策 ...................................................................................................26

6.1.4 事前に判明しているパラメータ.........................................................................................27

6.1.5 被害のシナリオ..................................................................................................................28

6.1.6 シナリオに沿った被害額の算出（被害額算出モデルの利用） ..........................................31

6.2 シミュレーションの評価・考察 .................................................................................................33

6.2.1 経験的に想定される被害額と算出された被害額の差異 .....................................................33

6.2.2 パラメータに関する検証 ...................................................................................................33

6.2.3 算出モデルを利用するためのポイント ..............................................................................37

6.2.4 実例とモデル式の結果の比較 ............................................................................................37

7. 今後の課題..........................................................................................................................................38

7.1 モデルの課題..............................................................................................................................38

7.1.1 情報セキュリティインシデント被害額算出モデルの課題 .................................................38

7.1.2 情報セキュリティ対策費用算出モデルの課題 ...................................................................39

8. 後に.................................................................................................................................................39

8.1 参考資料１：ヒヤリング集約.....................................................................................................42

8.1.1 ウィルス対策の状況...........................................................................................................42

8.1.2 不正アクセス対策の状況 ...................................................................................................49

8.1.3 情報セキュリティ管理への取組状況..................................................................................52

8.1.4 その他 ................................................................................................................................54

8.2 参考資料２：アンケート結果一覧表 ..........................................................................................55

8.3 参考資料３：アンケート用紙.....................................................................................................79


iii

1. はじめに情報処理振興事業協会は平成13年度セキュリティ対策研究開発等事業の一環としてNPO 日本ネッ

トワークセキュリティ協会（JNSA）に「情報セキュリティインシデントに関する調査」を委託しました。

NPO 日本ネットワークセキュリティ協会(JNSA)では、現在 10 を超えるワーキンググループが活動を

行なっており、本調査をプロジェクトとして行いました。

本調査は、JNSA 政策部会「情報セキュリティ被害調査 WG」によって、日本の基幹産業を構成する代

表企業および、IT 関連企業における情報セキュリティインシデントに係る被害額・投資額などの実態

把握と、この調査結果を基にしたインシデントによる被害額および対策額の算出モデル策定を検討し、

現時点で考えられるモデルの一案を提示しています。

本調査はセキュリティインシデントに係る被害額・投資額の調査の第一歩として行われたものであり

若干精度に欠ける部分もありますが今後の調査によりその精度を高めていく予定です。

しかしながら、リスクマネジメント実施において「被害規模と対策規模」が重要であるにも関わらず、こ

れらの情報関連の被害額や対策額を企業や組織で十分に把握できていない現状を鑑みると、今回の

「情報セキュリティ被害額および対策額の算出モデル」によって、これらのコスト算出に指標を与える意

義は大きいと考えます。

本報告書が被害額や対策額の算出を通じ、情報関連のリスクマネジメントの一助となることを願いま

す。


1

2. 目的 2001 年 9 月 11 日に発生した米同時テロ以降、サイバーテロや重要インフラセキュリティに対する関

心が官民問わず集まっている。このような状況の下、サイバーテロや重要インフラセキュリティインシデ

ントに関する過去の事例や現状についても同様に関心が高まっていきている。

しかし、これらセキュリティインシデントに関する具体的な事例や被害額についてのまとまった情報は

殆ど無いのが現状である。これは、インシデントの性質上、一般に公表されることが稀であるということに

加え、そもそも被害の定義も曖昧であることも、まとまった情報が得られない大きな原因となっていると

考えられる。

また、同様なことは、対策の面でも生じており、対策定義の曖昧さにより、対策コストの情報は不足し

ている。

本調査では、アンケートやヒヤリングによって、国内におけるサイバーテロや重要インフラセキュリティ

インシデントに関する現状を把握するための情報収集を行った。この情報から得られる結果を基に、セ

キュリティインシデントの被害額や情報セキュリティの対策投資額を推計するモデルを提案し、情報セ

キュリティマネジメントにおける「リスクの大きさ(被害規模)」と「対策規模」の把握と効果の計測、効率的

なマネジメントの実現を目的としている。

主な項目は以下の通りである。

(1)「情報セキュリティインシデントに係る被害額・投資費用に関する調査」

アンケートやヒヤリングにて調査すべき項目を設定し、実際の企業においてインシデント発生や発生で

要した費用(被害額)を調査する。

また、情報セキュリティインシデントの対策として実施されている取り組みへの投資額についても調査す

る。

(2)「被害額算出モデルに関する調査」

「(1)情報セキュリティインシデントに係る被害額・投資費用に関する調査」の結果を考察し、情報セキュ

リティインシデントに関する被害額の算出モデルを作成する。

具体的には、システム対応者の労務費用だけでなく、損害賠償に要した費用、復旧等に要した人件費、

ハードウェア等物理的被害、イメージダウンによる被害、業務の停止による逸失利益などを想定し、被害

額を算出するモデル検討と提案を行う。


2

3. 調査の概要 3.1 調査対象・セキュリティ被害調査ＷＧメンバーにて調査を依頼し、了解頂いた日本のインフラや基幹産業を構

成する企業や組織。

・ JNSA メンバー企業を中心とする IT 関連企業。(一部に非 IT 企業含む)

3.2 調査期間・調査の対象期間は 2001 年 1 月～12 月である。

・調査（アンケート、ヒアリング）を実施した期間は 2002 年 1 月～2 月である。

3.3 調査方法・対象企業に対して、アンケート及びヒアリングにより調査を行う。

・アンケートは、IPA にて実施した調査用紙をベースとし、被害項目毎に詳細な回答ができるように修正

したアンケート用紙を策定。(アンケート用紙については、9.3 参考資料３を参照)

・ JNSA メンバーへのアンケートは、JNSA 事務局長の依頼文章と共に送付し、記入後、事務局へ返送、

集約を行った。

・ JNSA メンバー以外へのアンケートは、ヒヤリング担当者より先方へ個別依頼にて収集。

3.4 調査の結果 3.4.1 ヒヤリング調査の結果

9.1 参考資料 1 参照。

3.4.2 アンケート調査の結果(集計表) 9.2 参考資料 2 参照。

3.4.3 アンケート回収率とヒアリング引受率

以下にアンケートの送付数と回答数、及びヒアリングの打診数と承諾数を示す。

アンケートヒアリング

送付回答回答率打診承諾承諾率

会員 121 50 41.32% 20 11 55.00%

非会員 5 4 80.00% 14 5 35.71%

合計 126 54 42.86% 34 16 47.06%

アンケートの回答率、42%強というのは、母数が少ないことを割り引いても、かなり良い成績だったといってよ


3

い。JNSA 会員が主体だったこともあると思われるが、インシデント被害及び被害額の算定について感心が

高いことが伺える。また、ヒアリングの承諾率 47%程度も、被害を情報公開して透明な企業姿勢を示したいと

いう真摯さを感じることができた。確かにヒアリング先では、このような調査がほぼ毎日依頼があるというところ

もあり、全て対応はできないという声も聞いたが、今回の被害調査に経済産業省も関与していただいたことも

あり、真剣に取り組んでいただけたと感じている。

3.4.4 アンケート拒否の主な理由アンケート拒否理由として、下記のような理由があげれれていた。

・外資系企業のため、本社の承認が必要、それが得られなかった

・社内ポリシーは外部に公開しないため

・情報セキュリティに対する取り組み方の詳細が把握できることになり、

そのことが会社のセキュリティ強度をイメージすることが可能になる。

それはおおきな脅威（リスク）になりうる。

・アンケートの問いによっては、セキュリティスタンダードの内容そのものに

該当するものもある。それを公開することはできない。

・事故や事件への対策についても、それを開示することは、自らの守り方

を開示するに等しいため、回答できない。被害状況についても同様

このようなご意見を頂いた。ここでこれらを細かく考察するだけの情報を聞いていないので、コメントは控える

が、セキュリティを実現することは、金庫に鍵を掛けてしまいこむことではなく、情報公開を行ったうえでシス

テムとしてどのように守るかが重要であるという議論もあるので、このような反応はもう少し慎重に分析してい

くことが大切であろう。今後の同様な調査でも意識してトレースしていきたい。


4

3.5 調査結果の分析と特徴今回の調査内容について、情報セキュリティに関連が大きい部分を中心に分析を行った。

3.5.1 対象企業の概要 ①業種について(「A-4 貴社が属する主要業種」より)

業種回答数割合

金融（銀行、保険、証券等） 3 6%

医療・製薬 0 0%

運輸 1 0%

エネルギー 1 2%

情報・通信 33 63%

教育・マスコミ 1 2%

建設 0 0%

飲食・小売 0 0%

その他サービス 7 13%

その他 6 12%

総合計

52

(未回答２件除

く) 100%


5

情報・通信

63%

教育・マスコミ

2%

その他サービス

13%

その他

12%

金融（銀行、保険、証券

等）

6%運輸

2%

エネルギー

2%

今回のアンケート対象が、JNSA（日本ネットワークセキュリティ協会）所属企業であることから、

情報・通信、およびサービス業が主体であり、約８６％となっている。

②従業員数とコンピュータ(ＰＣ)の導入台数業種について(「A-1 従業員数」および「C-1 保有 PC 台数」よ

り）

a b c d e

PC 保有台数

従業員数 1 台 2～10 台

11～

100 台

101～

1,000 台

1,000 台

以上合計

A 1 人 0

B 2～49 人 9 9

C 50～99 人 4 4 8

D 100～499 人 7 7

E 500～999 人 1 3 4

F 1,000～9,999 人 15 15

G 10,000 人以上 1 8 9

合計 0 0 14 12 26

52

(未回答２

件を除く)

調査対象が、情報・通信、サービス業が主体であことから、ほとんどの企業が、一人 1 台以上の

PC を保有していると考えられる。


6

③インターネット接続状況(「C-2 インターネットへの主たる接続方法」より）

接続形態企業数割合

a 接続なし 0 0%

b

ダイヤルアップ接続

（モデム、ISDN） 0 0%

c ISDN 1 2%

d ADSL、CATV 6 12%

e 専用線～1Mbps 2 4%

f 専用線 1～5Mbps 27 51%

g

常時接続

専用線 5Mbps～ 16 31%

h その他 0 0%

合計

52

(未回答 2 件

を除く) 100%

専用線

（LAN 等）がある。(「C-3 社内の情報システムネットワーク」より)

調査対象が、情報・通信、サービス業が主体であことから、回答のあったすべての企業にインターネッ

トへの常時接続環境があり、かつ、回答のあったすべての企業（５２社）に情報システムネットワーク


7

ISDN

2%

5Mbps～

31%

専用線 1～5Mbps

51%

ADSL、CATV

12%

専用線～1Mbps

4%

④情報セキュリティに関する規定の制定状況(「1-1 情報セキュリティに関する規定」より）

情報セキュリティの規定状況企業数割合

1 ない 7 8%

2 情報セキュリティポリシーとして規定している 30 34%

3

就業規則の一部に情報セキュリティ関連の規定が

ある 13 15%

4

個人情報保護規定の一部として情報セキュリティ関

連の規定がある 10 11%

5

その他規定の一部として情報セキュリティを規定し

ている 12 13%

6 情報セキュリティ関連の作業手順を規定している 14 16%

7 分からない 1 1%

8 その他 2 2%

該当項目数の合計 89 100%

１．回答のあったすべての企業にインターネットへの常時接続環境があるが、セキュリティポリシ

ーが規定されていない企業が、「分からない」、「その他」という企業を含めると約１１％ある。

２．また、情報セキュリティポリシーとして規定されている企業が３４％しかない点も、調査対象が

JNSA に所属する企業であることを考えると想定したよりもかなり低い数値であった。


8

⑤情報セキュリティの管理部門や管理者について(「1-6 情報セキュリティ管理部門」および「1-9 情報セキュ

リティ管理者」より)

情報セキュリティ管理部門の設置状況企業数割合

1 ない 7 13%

2

全社の情報セキュリティ業務を担当する専

門部門がある 14 27%

3

全社の情報セキュリティ業務を兼任する部

門がある 20 39%

4

全社の情報セキュリティ業務を担当する委

員会がある 7 13%

5

各事業部や部単位で独自に情報セキュリ

ティに対する取組をしている 2 4%


7 その他 1 2%

合計

52

(未回答 2

件有り) 100%

情報セキュリティ管理者企業数割合

1 責任者は決まっていない 8 15%

2 責任者が任命されている 35 65%

3 責任者は任命されていないが担当者はいる 7 13%

4 わからない 4 7%

合計 54 100%

セキュリティポリシーの保有状況と同様に、「分からない」、「その他」を含めると、約１７％の企

業が「情報セキュリティ管理部門」を設置しておらず、また、約２０％の企業が「情報セキュリティ

管理者」を決めていない。

調査対象が JNSA に所属する企業であることを考えると想定したよりもかなり低い数値であっ

た。


9

⑥情報セキュリティに関する教育の実施状況について(「1-26 実施中の情報セキュリティに関する教育」より）

セキュリティ教育の実施状況企業数割合

1 未実施 20 29%

2 経営者・役員クラスを対象とした情報セキュリティ管理教育 4 6%

3 全管理職を対象とした情報セキュリティ管理教育 11 15%

4 全管理職を対象とした情報セキュリティ関連技術教育 2 3%

5 一部の管理職を対象とした情報セキュリティ管理教育 2 3%

6 一部の管理職を対象とした情報セキュリティ関連技術教育 1 1%

7 情報セキュリティ管理者を対象とした情報セキュリティ関連技術教育 6 8%

8 希望者を対象とした情報セキュリティ関連教育 3 4%

9 全社員を対象とした情報セキュリティ関連教育 19 27%

10 分からない 3 4%

合計 71 100%

⑥情報セキュリティ関連予算について(「1-45 情報セキュリティ関連予算」より）

情報セキュリティ関連予算企業数割合

1 ない 4 8%

2 情報セキュリティ対策費として計上される 7 13%

3 情報システム関連予算の一部として計上される 29 55%

4 その他予算の一部として計上される 5 9%


6 その他 3 6%

合計

53

(未回答

1 件有り) 100%

セキュリティに関する教育は、その必要性をみとめながらも、その実施率はかなり低いことがうかが

える結果となっている。

情報セキュリティ対策に関する予算は、独立した科目として計上されている企業が約１３％しかな

く、一般的に情報システム関連予算やその他の予算の一部として計上されていることが分かる。


10

3.5.2 被害状況の概要 ① 被害の状況(インシデント毎の被害額、１企業大３インシデントまで発生していた。)

（単位：円）

インシデント毎の被害額企業

No. コスト／日 ① ② ③ 年間合計

1 40,000 60,000,000 60,000,000

2 40,000 200,000 20,000,000 60,000 20,260,000

3 40,000 1,860,000 15,000,000 16,860,000

4 150,000 15,750,000 15,750,000

5 30,000 1,500,000 4,500,000 6,000,000

6 45,000 3,915,000 549,000 450,000 4,914,000

7 150,000 1,500,000 3,000,000 20,000 4,520,000

8 40,000 2,004,000 40,000 2,400,000 4,444,000

9 40,000 416,000 800,000 800,000 2,016,000

10 40,000 220,000 1,620,000 80,000 1,920,000

11 40,000 800,000 800,000 1,600,000

12 50,000 300,000 1,000,000 1,300,000

13 32,000 320,000 12,800 332,800

14 30,000 90,000 150,000 240,000

15 25,000 ? 200,000 200,000

16 30,000 180,000 180,000

17 15,000 60,000 50,000 50,000 160,000

18 160,000 120,000 120,000

19 18,000 9,000 99,000 108,000

20 25,000 100,000 100,000

21 40,000 80,000 80,000

22 40,000 80,000 80,000

23 30,000 30,000 30,000 60,000

24 40,000 60,000 60,000

25 40,000 16,000 30,000 46,000

26 40,000 40,000 40,000

27 60,000 30,000 30,000

28 32,000 8,000 16,000 24,000

29 40,000 20,000 20,000

30 30,000 15,000 15,000

＊１．被害額はアンケート調査対象企業の報告をベースにしているが、コストが不明な部分（波線

部）は、固定額（4 万円）を設定し計算している。

＊２．被害額の算定に当たっては、「復旧に要した作業量」

ｎ名×ｍ日×1 日あたりの人件費により算出している。


11

・約６１％(３３/５４社)の企業が何らかの形で被害にあっている。今回の調査対象が、主に JNSA

所属企業であることを考えると、一般企業ではさらに広範な被害が想定される。（被害額の不

明な 3 社は、一覧表上から除外）

・点線の数値はウィルス以外のインシデントによる被害であり、ほとんどがウィルス／ワームによ

る被害となっている。


12

②インシデント別被害の状況

コード No 被害項目件数件数比率金額金額比率

8 Nimda

ニムダ 18 31% 73,730,000 52.1%

11 CodeRed

コードレッド 13 22% 45,949,000 32.5%

10 Navidad

ナビダッド 3 5% 15,778,800 11.2%

5 Magistr

マジストラ 1 2% 1,620,000 1.1%

3 Sircam

サーカム 3 5% 757,000 0.5%

7 Laroux

ラルー 3 5% 516,000 0.4%

2 Badtrans

バッドトランス 5 8% 345,000 0.2%

6 Aliz

アリズ 1 2% 30,000 0.0%

12 風評被害 1 2% 80,000 0.1%

13 誤操作 2 3% 280,000 0.2%

17 ﾎｰﾑﾍﾟｰｼﾞ改ざん 1 2% 20,000 0.0%

19 その他 8 14% 2,374,000 1.7%

合計 59 100% 141,479,800 100.0%

＊１．ウィルス／ワームについては、被害金額が多いものから並べ替えてある。

１．ウィルス／ワームによる被害が、件数ベースで約８０％、金額ベースでは約９８％となって

いる。


13

③被害のあった企業の特徴

今回のアンケートおよび、ヒヤリングを実施した企業の特徴として挙げられる以下の項目をもとに、

被害のあった企業とない企業との間で何らかの違いがあるかについて検証を行ったが、結論として

は、有意な違いは見られなかった。

① 所属する主要業種

② 従業員数と保有しているパーソナルコンピュータの台数の関係

③ インターネットへの接続および、情報システムネットワークの有無

④ 情報セキュリティに関する規定の有無

⑤ 情報セキュリティに関する、管理部門、管理者の状況

⑥情報セキュリティに関する教育

⑦情報セキュリティ関連予算の状況

④インシデントが発生した大の原因

No 大の原因回答数割合

1 セキュリティ関連予算の不足 0 0%

2 セキュリティ管理体制が不十分 24 45%

3 セキュリティ対策技術が不十分 3 6%

4 セキュリティ関連情報の不足 11 21%


6 その他 15 28%

合計 53 100%

今回の被害の主因がウィルスであり、「新のウィルス定義ファイル適用の有無」が被害の大きさ

を区別する主たる要因であり、サーバー管理によるウィルス定義ファイルの更新などの技術的な対

策により対処可能なものであったことから、それ以外の項目による特徴的な差異が見られなかった

ものと考えられる。

「予算の不足」や、「対策技術が不十分」と回答する企業が少なく、「管理体制が不十分」、「関連情

報の不足」と回答する企業の合計が、約６６％となることから、ＩＳＭＳ制度などのマネジメント体制の確

立をおこない、素早く正しい情報をもとに対策を行うことで、同様のインシデントは防げるものと考えて

いることが伺える。


14

3.6 調査の総括今回の情報セキュリティインシデントに関する調査では、ウェブページ改ざんや、外部・内部を問わない不

正アクセスや情報漏洩といった被害に関しては警察庁等が行っている不正アクセス被害調査報告とは様相

が異なり、被害報告件数はそれほど多くなかった。

これは、調査対象となった JNSA メンバー企業を中心とする IT 関連企業では、既に基本的な不正アクセス

対策が一巡していることが考えられる。

一方、多くの企業では、2001 年に猛威を振るったウイスル・ワームによる局地的な被害を経験している。昨

今のウイルスやワームはメールなどの媒体を通じて感染する特徴を持っており、インターネットに接続するホ

スト数とユーザーの増加にともなって爆発的に増加する危険性を持っている。

これに対し、そもそもインターネットとは接続されていない基幹システムや業務システムには影響を及ぼさ

ないから、自社の業務やサービスに対しては金額に換算できる直接的な被害を及ぼすには至っていない。

重要な業務システムないし基幹システムは、事務系の LAN とは完全に独立したネットワークを構成してい

る場合がほとんどで、インターネットやイントラネット上に事務系の LAN と混在する場合でも、ファイヤーウオ

ールや DMZ を適切に配置し、万が一インシデントが発生した場合にでも被害を極小化できるシステム・ネッ

トワーク構成にしておくことが、インシデントに対する耐性を持ったネットワークであるといえる。

今回の調査結果によると、メール経由で感染する BADTRANS などのウイルスの感染に対して企業がとっ

た行動様式は、次のようなものであった。

・感染したシステムをネットワークから切断し、検疫を試みる。可能であれば感染経路の特定と、ウイルス

を他のシステムに伝播していないかどうか調査する。

・感染した可能性のあるその他のシステムも一時的にネットワークから切断し、検疫を行う。感染範囲を

特定し、感染したシステムについて検疫を行う。

感染したシステムが少数の場合には、代替機を用意して業務を継続したり、システムを使用しない業務フ

ローに切り替えて業務を継続している。

感染が広範囲に及んだ場合でも、システムを使用しないで業務を継続し、その間に情報システム部員や

ボランティアのパワーユーザー達が感染したシステムの復旧を行っている。

インシデントによりシステムないしネットワークを長時間に渡って停止した場合でも、業務効率は落ちるかも

しれないが、システムを使用しない業務フロー（発注業務の場合は、電話や FAX を利用する、等）に切り替

えて業務を継続したり、システムの復旧後に残業などにより、システムないしネットワークの停止による金銭

的な被害の発生を抑止している。


15

万が一の場合を考え、システムないしネットワークが使用できない場合の業務フローを検討し準備しておく

ことが、業務継続性の観点から重要であろう。

特に新興のドットコム企業などの場合でスタート時点からシステムとネットワークによる業務フローを前提と

しているケースの場合には注意が必要と考える。


16

4. 情報セキュリティインシデント被害額算出モデルに関する検討ここでは、情報セキュリティインシデントに関する被害額の算出モデルの作成を検討する。

システムやネットワークに対する情報セキュリティインシデントに関する被害の構成要素には、損害賠償に

要した費用、復旧などに要した人件費、ハードウエアなど物理的被害、イメージダウンによる被害、業務の

停止による逸失利益など、様々な要素がある。

これらの様々なインシデント被害を、２つに分類する。

まず、一つ目は、比較的算出が容易で一般的な「直接的な被害：逸失利益モデル」「間接的な被害：補

償・補填・損害賠償モデル」で構成される「表面化被害」とする。２つ目として、業務効率の低下などによる通

常表面化しない「潜在化被害」とに分ける。

これら２つの被害の合計によって、インシデントによる被害額算出モデルを検討する。

4.1 表面化被害インシデント被害の結果として生じる逸失利益や企業が実際に支払う金額については、企業が被害額とし

て認識しやすい。被害が金額として認識できるものを、「表面化被害」と呼び、この表面化被害について、１

次的なものと、２次的なものを考える。

4.1.1 １次的な被害額電子商取引サイトなどのように業務、またはサービスの 100%がネットワークシステムに依存している場合に

は、インシデントによってシステム、またはネットワークの停止した期間を逸失利益の被害額として、比較的

容易に算定できる。

この場合、インシデントによりシステムないしネットワークが停止していた期間の売上はゼロであり、当該期

間に利益が挙げられなかった見なす。

被害額は逸失利益の考え方により下記式により算出される。

逸失利益=時間あたりの売上による利益×システムないしネットワークの停止していた時間

「時間あたりの売上による利益」は、システムないしネットワークがインシデントにより停止していなければ得

られていたであろう利益金額を設定する。電子商取引サイトの場合であれば、一日あたりの利益金額から算

出することが考えられる。

また、直接的な被害としては、復旧に要したコストも算入する必要がある。電子商取引サイトが不正アクセ

スを受け、ウエブページの改ざんを受けた場合には、復旧するまでの期間の逸失利益と、復旧に要したコス

ト（ハードウエア、ソフトウエア、人件費）を下式のように加算し、１次的な被害で生じる被害額を算出する。

１次的な被害額=逸失利益+復旧に要したコスト


17

4.1.2 ２次的な被害額業務またはサービスがインシデントにより停止したことにより、２次的に金銭的な被害が発生している場合

には、その対価を被害額に計上する必要がある。

各種の補償・補填や損害賠償請求・謝罪広告費用などが挙げられる。被害額の算定は難しいが風評被

害による利益の減少もこれにあたる。

２次的な被害額=補償、補填、損害賠償利益など、２次的に生じた被害

4.2 潜在化被害前述の表面化被害の算出モデルでは、いずれもインシデント被害が具体的な金額として表出するため、

被害額を把握する事ができる。

これに対し、インシデントが対外的な業務やサービスに影響を明確な影響を及ぼさない場合には、潜在

化してしまい、被害額が表出しにくい。このため、この部分のインシデント被害額についてはこれまであまり

論じられることがなかった。

ここでは、これらの潜在化している被害を「潜在化被害」と捉え、被害額の算出モデルを考える。

4.2.1 潜在化被害額インシデントによりシステムないしネットワークが停止した場合でも、業務遂行におけるシステム依存度が

大きいほど、業務効率が大きく落ちる。

業務自身は、システムを使用しない業務フロー（発注業務の場合は、電話や FAX を利用する、等）に切り

替えて業務を継続したり、システムの復旧後の残業などにより、処理能力低下をカバーし、金銭的な被害の

発生を抑止している。

このケースの場合、業務自体はシステムを使用しないで継続してしまっているので金額的な被害は発生し

ていない。しかし、業務効率がダウンしたり、システムの復旧後にデータを再投入したり、あるいは残業でリカ

バリーしたりなど、目に見えないコストが発生しているのである。

今回の調査で我々は、業務効率の低下自体もインシデントによる被害と考え算出する事を検討した。

また、このような「業務に関わる潜在化被害」に対し、風評被害など企業イメージのダウンなど「業務外の潜

在化被害」も潜在化する被害の一つと考えられる。

しかし、企業イメージのダウンなどを金額に置き換えることは非常に難しく、業種業態、被害発生の理由な

どによっても、発露する影響が大きく異なる。

このため、「業務外の潜在化被害」は、今回のモデルの項目に組み込んでいるが、具体的な金額算出の

モデル化については、ここでは特に言及しないこととする。


18

これらの議論を踏まえると、潜在化被害額は下式で算出できる。

潜在化被害額＝業務にかかわる潜在化被害＋業務外の潜在化被害

＝（固定費（人件費）×インシデントによる影響を受けた人数

×IT 感応度（業務依存度）×停止時間）

＋業務外の潜在化被害

4.3 インシデント被害額算出モデル前述の議論をふまえ、下記のように「表面化被害」と「潜在化被害」を統合した「インシデント被害額算出モ

デル」を提案する。

インシデント被害額

＝潜在化被害＋表面化被害

＝（（固定費（人件費）×インシデントによる影響を受けた人数

×IT 感応度（業務依存度）×停止時間）

＋業務外の潜在化被害）

＋復旧に要したコスト（ハードウエア、ソフトウエア、工数）

＋逸失利益（直接的な被害）

＋補償・補填・損害賠償（間接的な被害）

＜各項目補足＞

・固定費（人件費）

インシデントにより影響を受けた従業員の時間あたり人件費単価を設定する。

・インシデントによる影響を受けた人数

インシデントを受けたのがクライアント PC であれば、その台数を設定する。

インンシデントを受けたのがメールサーバやファイルサーバなどのサーバの場合には、そのサービ

スを利用している人数を設定する。

・IT 感応度（業務依存度）

インシデントを受けたシステムないしネットワークの業務に対する影響度を

０～１の範囲で設定する。システムやネットワークへの業務依存度が高いほど、この係数は高くな

る。業務に全くの影響を及ぼさなかった場合にはゼロを設定することになり、コストベースの損害は

発生しなかったことになるが、通常は前述のように被害は実効効率の低下となって現れる。システム

ないしネットワークを利用した場合に１時間で１００件処理できたものが、利用しなかった時に８０件し

か処理できなかった場合には、業務依存度は０．２となる。

また、システム停止時の代替え手段を充実させることで、万一の実行効率の低下を抑制すること


19

ができる。実際の適用では、このような代替え手段も考慮して、業務依存度を決定する事が必要で

ある。

・停止時間

インシデントによりシステムないしネットワークが停止していた時間と、システ

ムないしネットワークの復旧後に業務効率が通常レベルに戻るまでにかかった時

間を設定する。復旧後にデータの再入力や残業を行ってリカバリーした場合に

は、そのリカバリー処置が完了するまでの間は、実効効率は IT 感応度で設定した

実効効率が有効であると考える。

以上の４項目を掛け合わせたものに、業務外の潜在化被害額、ハードウエア・ソフトウエア・工数などの復

旧に要したコストと、発生しているのであれば逸失利益（直接的な被害）と補償・補填・損害賠償（間接的な

被害）を加えたものがインシデント被害額算出モデルとなる。

このモデルの特徴は、インシデントによる業務の実効効率の低下に着目している点にある。

インシデントによる金銭的な被害が具体的に発生していない場合でも潜在している被害額を算定することが

可能である。

被害額を極小化するには、システムとネットワークを、被害を極小化できるように構成し配置すること（影響

範囲の極小化）と、業務継続性の高い水準で維持すること（業務依存度の極小化）にある。

インシデント被害額の算定に対するこのアプローチは、企業の情報システムにリスク分析にも有効であろ

う。


20

5. 情報セキュリティインシデント対策費用額の算出モデルについての検討実施した情報リスクマネジメントの費用対効果を検証するためには、被害額の把握と共に、対策費用の把

握が必要である。

今回の調査、特にヒヤリング調査では、被害額と共に情報セキュリティ予算などの対策費用の調査にも力

を入れた。

しかしながら、調査の結果、一般的な共通認識としての対策費用の指標が存在しないため、情報システム

担当者といえども対策に費やしている金額を十分に把握できていない現実が判明した。

本章では、情報セキュリティ関連の予算として、認識すべき項目を明確にすることを検討する。

5.1 情報セキュリティ関連予算の実際と算出モデルｅ－メールや EC などに代表されるインターネットの活用が、企業の事業活動にとって必要不可欠となって

いる現状を踏まえると、各企業は少なからず、情報セキュリティに関する対策費用の支出を行っているはず

だが、今回の調査結果からは「情報セキュリティ対策費」という科目で予算計上されている企業は約１７％と

低い数値となっている。

これらの原因をアンケートの結果から想定すると、

① 情報セキュリティ対策費用を情報システム関連費用から分離することが困難

② 情報セキュリティ対策に関する必要性の認識不足

③ 企業の事業活動に与えるリスク分析の不十分さ

④ 情報システム全体のアウトソーシング比率が高いことから、その中のセキュリティ対策費を分離

して把握することができない

などが考えられる。

そこで、企業が事業継続に必要とされる低限の対策費用を試算するための、情報セキュリティインシデ

ント対策費用額の算出モデルを以下の手順で検討する。


21

各対策項目への必要性・

プライオリティの設定

物理的費用、従業員数、

などの実数値の適用

必要対策費の算出

具体的な情報セキュリティ

対策項目の提示

5.2 具体的な情報セキュリティ対策項目の提示企業が対策を講じなければならない攻撃や被害は、大きくは 3 つに分類される。1 つめはコンピュータウイ

ルスによる被害、2 つめはクラッカーや第 3 者による不正アクセス・不正侵入、3 つめは内部犯罪等による機

密情報漏洩である。その各々についての現時点で実現可能な対策例と、そこで必要とされる資産を物的リ

ソース（ハードウエアやソフトウエアなど）と、人的リソースに分け一覧とした。

対象資産インシデントの

種類

対策例

物的ﾘｿｰｽ人的ﾘｿｰ

ｽ

ウィルス対策ソフトの導入 ○ ◎ ウィルス

新のセキュリティパッチの適用 ◎

サーバーの要塞化 ○ ○

サーバーへの新セキュリティパッチの適用 ○

システムのセキュリティ監査（検査） ○ ○

24 時間監視 ○ ○

データ／ソフトウエアのバックアップ ○ ○

ハードウエアの増長性確保 ○ ○

ファイアウォール ○ ○

IDS 導入 ○ ○

暗号化技術の適用 ○ ◎

不正アクセス

認証システムの導入 ○ ◎

廃棄物処理 ○ ◎

建物（施設）のセキュリティ強化 ○

機密情報

漏えい

ソーシャルエンジニ

アリング対策

ネットワーク管理ツール ○

ポリシーの策定 ○

ポリシーの運用と見直し ○

セキュリティポリシー

の徹底

従業員教育 ◎

プランの策定 ○

物理的なリソースの確保 ○

定期的な訓練 ◎

全般

コンティジェンシー

プランの策定

プランの見直し ○

＊人的リソースの“◎”は従業員全員が関与するもの、“○”は主にセキュリティ管理部門（者）が関与するも

の


22

5.3 各対策項目への必要性・プライオリティの設定 5.3.1 経営サイドから見た必要性、プライオリティの設定

企業は営利を目的として、インターネットの活用を行うことから、以下の基本的には下式のような大

小関係が存在する。

事業予算＞情報システム関連予算＞セキュリティ対策予算

ここで、情報システム関連予算のうちどの程度のセキュリティ対策予算が必要であるか

についての事業判断を行う事となるが、インターネットの利用を前提としたシステムの場

合には、低限、その安全対策のために従来の情報システム保守費用と同程度の予算が必

要と考えられる。

5.3.2 システム（セキュリティ）管理者サイドから見た必要性、プライオリティの設定本来、セキュリティポリシーの策定、コンティジェンシープランの策定の段階で、対象

となる資産の洗い出しは完了しているはずであり、 ① 対象となるコンピュータシステム ② 当該コンピュータシステムで提供される業務

が明確になっているはずです。そこで、以下の分類に従いその業務のコンピュータシステムへの依存度と情報システム

関連予算を設定し、必要とされるセキュリティ対策予算を求める。具体的には、重要度 Sの業務については、現時点で可能な高レベルのセキュリティ対策を施すべきと考えられ

る。一方、重要度が A、B の業務については、要求されるサービスレベルが維持できる低

限のセキュリティ対策を施すべきと考えられる。ただし、ウィルス感染や、踏み台などにより、意識せずに加害者となることを考えると、

重要度 C だとはいえ、低限のセキュリティ対策は必須である。重要度サービスレベルＳ業務が停止することは許されない。Ａ 24 時間以内に復旧する必要がある。Ｂ 3 日以内に復旧する必要がある。Ｃ緊急事態の際には停止してもよい。


23

5.4 物理的費用、従業員数などの実数値の適用と、必要対策費の算出前述の、「5.2 具体的な情報セキュリティ対策項目の提示」で示した表、および「5.3 各対策項目

への必要性・プライオリティの設定」に従い、以下の 2 点を設定することで、全社的な情報セキュ

リティインシデント対策費用の算出が可能と考えられる。 ① 物的リソースに関しては、実際に発生する、ハードウエア費用、ソフトウエア費用（初期導

入費用、保守費用）の設定 ② 人的リソースに関しては、対象業務に関与する人数×人件費×時間により求められる金額

を設定

5.5 情報セキュリティ対策費用把握の必要性について一般的に、情報システムの導入は、定量的なメリットが分かりづらく、定性的なメリット

を元にした戦略的な投資対象として扱われる傾向にありますが、その中でも特にセキュリテ

ィ関連対策費用については、いわゆる保険的な意味合いが強いため、予算枠に組み込むこと

が困難な費目と考えられる。しかし、グローバル化の流れの中で、今後インターネットを利用した国際的な競争社会の

中で優位性を確保していくには、従来考えられているシステム関連予算だけではなく、情報

セキュリティインシデント対策費用の必要性を認識し、その正確な把握と効率的な投資を実

現することが急務と考えられる。


24

6. 想定企業および被害への情報セキュリティ被害算出モデルの適用と考察先に提示した“被害額算出モデル”が現実的にどの程度機能するものかを検証するために、架空の会社

を想定しそこでのインシデントをあてはめて算出した。

そこで得られた結果に基づき、算出モデルの実用性を検証するとともに算出モデルを利用するためにユ

ーザが事前に知っておくべきパラメータ（人件費や売上規模、ＩＴ依存度など）を確認する。

6.1 被害額算出モデルを使用したシミュレーション

まず、被害額算出モデルを検証するための架空の会社のプロファイルを以下に記す。現実の多くの企業

はセキュリティ対策が未整備であることから、この架空企業のセキュリティに対する施策も弱く設定し、被害が

広い範囲におよぶようにした。

6.1.1 会社のプロファイル業種： SI ベンダー

業務内容：コンピュータ・ネットワーク関連ハード・ソフトの販売とシステムインテグレーション

従業員数：社員 95 名派遣 8 名

・社長 1 名

・社長室 3 名

・営業部 22 名（物販 7 名、SI 営業 13 名、オンラインショップ 2 名）

・マーケティング・企画部 11 名

・業務部 5 名

・技術部 24 名（SE 8 名、サポート 13 名、情報システム 3 名）

・開発部 8 名

・広報 3 名

・管理部 5 名（経理 3 名、人事・総務 2 名）

・大阪支店 7 名（営業 4 名、SE 兼サポート 3 名）

・名古屋支店 6 名（営業 4 名、SE 兼サポート 2 名

・派遣 8 名（営業 4 名、業務 2 名、技術 1 名、総務 1 名）

年商： 30 億円

・内 8 千万円がオンラインショップの売上

6.1.2 社内システムの構成

端末：全 120 台

・一般端末 Windows 115 台

・開発者端末 UNIX 5 台


25

サーバ：全 10 台

・内部ゲートウェイ Windows NT 1 台（DNS サーバ、メールサーバ）

・業務系サーバ Windows NT 4 台（営業、業務、経理、技術）

・開発用サーバ UNIX 3 台

・公開サーバ： UNIX 1 台

（DNS、メールサーバ、Web サーバ、オンラインショップ）

・その他： Firewall 1 台

6.1.3 現在のセキュリティ施策

・インターネットアクセス（メール、Web 閲覧）に規制なし。

・ユーザ端末間のファイル共有に規制なし。

・ゲートウェイ型ウィルスチェックサーバなし。

・ウィルス対策は各ユーザ端末で実施。ただしウィルスパターン更新はユーザまかせ。

・障害発生時の手順は未整備（セキュリティポリシーなし）。

・セキュリティ管理者不在（情報システム担当が兼務）

・公開サーバは新パッチを施すように情報システム部門が管理。

・派遣社員の端末も情報システム部門が管理。

・社内サーバや各端末のパッチなどメンテナンスは各部署および各ユーザまかせ。


26

6.1.4 事前に判明しているパラメータ

被害額算出モデルを使用する際に必要なパラメータをリストアップする。これらパラメータは部署・役

職・時期など様々な要因により変動するが、経験的な判断でおおよその平均値を導き出した。これらの

妥当性については「6.2.2 パラメータに関する検証」にて評価する。

平均人件費：時間単価 6,000 円

1 日の平均売上：通常売上＝13,000,000 円オンラインショップ＝360,000 円

・年間営業日 220 日と想定

・決算期など季節変動は無視

各部署別の社員 1 名あたりの 1 時間毎のコストベース平均被害額（固定費×IT 感応度）

→算出方法は後述（6.2.2）。

・営業部： 2,700 円/1h

・技術部 4,500 円/1h

・マーケティング部 3,200 円/1h（代替手段加味）

・業務部 3,000 円/1h（代替手段加味）

・開発部 1,200 円/1h（メールのみ被害）

・広報部 5,100 円/1h

・その他 2,100 円/1h（代替手段加味）

各サーバの停止が及ぼす被害の範囲

・公開サーバ：全社員のメールなど、オンラインショップ

・内部ゲートウェイ：全社員のメールなど

・営業サーバ：営業部員の資料作成など

・業務サーバ：受発注業務など、オンラインショップ

・経理サーバ：経理処理

・技術サーバ：顧客サポート、出荷準備、製品評価など

・開発用サーバ：開発業務


27

6.1.5 被害のシナリオ日時事象アクションメモ

日時間

1日目 13:00

～

13:30

ある取引先から営業部員 Aに

対し、「あなたからのメールに

ウィルスがついていた」とメー

ルによる通知があった。

営業部員 Aは、新のウィルスパターン

をダウロードした後、ウィルスチェックを

実施。Nimdaを検出。

他の顧客にもウィルスを送った可能性があ

る。対応手順やお詫び文などを事前に

決めておく。

14:00

～

15:00

営業部員 Aはワクチンソフトメーカのサ

イトから駆除ツールをダウンロードし、一

旦社内LANから端末（Windows 2000）を

外し駆除を実施。その後ウィルスチェッ

クを行い駆除を確認し、再度社内LAN

に接続。

ウィルス検出後、すぐに社内LANから切り

離さなかったのは被害の拡大につながっ

た可能性有り。

2日目 9:00

～

10:00

昨日の件もあったため、出勤と

同時に営業部員 Aは念のた

めウィルスチェックを実施。再

度Nimdaを検出。

再度の感染により、感染元が社内LAN

上のどこかに存在すると判断し、情報シ

ステム担当を通じて全社に警告。

このような事態にも早急に対応できるよう事

前に社内体制を決めておく必要がある。

LANが使えなくなることも想定した上で、電

話・FAXによる連絡方法も事前に決めてお

く。

LANが使えない、画面が小さいなどの理由

からコンピュータの利用が制限される場合

は、対策進捗表などは紙による運用の方

が適している。

10:00

～

10:30

体制作り。情報システム担当の指示により、各部の部門長を責任者として各サーバの感染およ

び各部署の感染状況を把握し、情報システム担当が集計し復旧対策を指導する体

制とした。

10:30

～

12:00

在席している社員から順次ウィ

ルスチェックを始める。

数部署から感染の状況が入り

始める。

想像以上に被害の範囲が広いことが分

かったため、すべてのサーバと端末を社

内LANから一時的に切り離すように情報

システム担当から各部門長に指示。

被害が確認された場合のアクション（LAN

から切り離す、電源を切るorきらない、

etc.）は手順書にしておく、また定期的に

社内教育をするなど、事前準備は重要。

公開サーバは感染していない

ことが確認された。

公開サーバはネットワークから切り離さず、そのまま運用を継続。


28

11:00

～

被害状況の確認と並行して復

旧作業開始。

すべての端末のウィルスパターンが新

のものとは限らないので、情報システム

担当が新パターンファイルと駆除ツー

ルを各部署分CD-ROMに焼き、配布。

ウィルスパターンが古かった場合、未感

染と通知された端末・サーバも再度チェ

ック。

支店についてもCD-ROM配送。

ウィルスパターンの更新はユーザ任せにし

ない仕組みを検討。

Windows NTサーバ全て（営

業、業務、経理、技術、内向け

GW）に感染確認。

紙の伝票処理で受発注業務継続。出

荷などは遅れる可能性があり、顧客への

案内をする。

コンピュータが使えない場合の業務遂行

手段は事前に検討しておく。過去のデー

タも含め重要なものは紙で残しておくことも

検討。

各サーバで数百～数千のファイルに感

染を確認。駆除を断念、フォーマットか

ら行い再構築。業務・経理サーバは前

日のバックアップデータから復旧。優

先度の高いサーバから復旧する。

速やかな普及を目指し、日常的なデータ

バックアップも手順化しておく。

日時事象アクションメモ

日時間

顧客から数件のクレームが入

る。

公開サーバは立ち上がっているためメ

ールは受信、しかし社員へは届かない

ため回答ができない。各担当の判断で

顧客にその旨通知。

メールがビジネスツールとして日常化して

いる現在、それが利用できない場合の対

応を検討しておく。特に顧客に対しての

通知について、通知先リスト作成、通知方

法、オペレーション担当などを決めておく。

公開サーバは感染していない

が、オンラインショップは業務

サーバと連動しているため運

用が停止。

サービスが出来ないこと、いつ復旧する

か、販売の代替方法をホームページで

告知。

メールと同様にホームページによる通知の

方法も検討しておく。

～

20:00

外出していた社員の帰社を待

って、全端末の検査が完了。

＜被害状況＞

・UNIXマシンは未感染。

・感染は以下の通り。

・Windows NTサーバ全て（営業、業務、経理、技術、内向けGW）端末の被害が小さくても、サーバが被害を

受けることで、利用者全員に影響が出る。


29

・営業端末 10台

・業務端末１台

・技術端末 5台

・大阪支店 2台

・名古屋支店 2台

～

24:00

重要サーバの復旧完了。業務サーバ、経理サーバを優先的に復

旧。

3日目 9:00

～

引き続き復旧作業。

・各端末の復旧。

アプリケーションインストールの

CD-ROMは効率良く利用できるように情

報システム担当がスケジュールを決定

し、どこに貸し出ししているかなども把

握。データの復元は各担当にまかせ

る。

アプリケーションのCD-ROMは奪い合いに

なるので要管理。支店にアプリケーション

のCD-ROMが無い場合のフォローも検

討。日常的にバックアップするよう、手順

も含め社員教育しておく。

・サーバの復旧業務サーバ、経理サーバへ昨日までの差分データ入力。内向けGWの復旧。営

業サーバ、技術サーバは情報システム担当が支援するが、データの復元は各部門

が担当。

10:30

～

全システム再構築完了。動

作確認開始。

復旧した個所から動作確認していく。動作確認の内容・方法も事前に決めてお

く。

オンラインショップサービス再

開。

昨日の注文者へのお詫びなど。

12:00

～

メール再開。昨日のメールへ回答など。

～

13:00

ウィルスを配信した可能性の

有るユーザのリストアップ。

詫び状作成および通知方法は経営者

交え検討。各担当が通知先をリストア

ップ。

メールで感染させた可能性があるので、マ

ナーとして通知はメール以外にする方が

良いのでは（電話、FAX、ホームページな

ど）。 FAXで通知する場合、全顧客への

送信完了まで数時間かかることを考慮して

おく。

13:30

～

17:00

顧客への通知（お詫び）。顧客へはFAXで通知。急を要する重

要な先には電話で通知。

信用の回復のため事後処理は重要。後

日お詫びに訪問するも検討しておく。


30

6.1.6 シナリオに沿った被害額の算出（被害額算出モデルの利用）

今まで挙げた条件を実際に4.3で提示した算出モデルにあてはめる。

・各サーバの停止時間

・内部ゲートウェイ： 23時間30分（2日目 11:00～3日目 12:00）

・営業サーバ： 23時間30分（2日目 11:00～3日目 12:00）

・技術サーバ： 23時間30分（2日目 11:00～3日目 12:00）

・業務サーバ： 11時間（2日目 11:00～24:00）

・経理サーバ： 11時間（2日目 11:00～24:00）

a. 固定費×影響を受けた人数×IT感応度×停止時間

・各部署毎に算出し、後に合計する。

・同じ部署でも担当によってまた日によって、業務の内訳は異なるが、ここでは6．1.4に挙げた

平均被害額を使用。

・停止時間は各サーバと各端末の停止時間を考慮するが、本シナリオではサーバの復旧より

以前に端末の復旧は完了していると想定しサーバの停止時間のみを考慮。

・サーバの停止時間については業務時間のみを対象とし、20:00～翌9:00は差し引く。

・業務と経理を除いた他の部署は内向けサーバが停止していた時間を入力値とする。

・業務と経理サーバの停止時間： 11時間

・内部ゲートウェイの停止時間： 12時間

＜各部署の被害額の算出＞

・営業部： 2,700円×22人×12時間＝712,800円

・技術部： 4,500円×24人×12時間＝1,296,000円

・マーケティング部： 3,200円×11人×12時間＝422,400円

・業務部： 3,000円×5人×11時間＝165,000円

・開発部： 1,200円×8人×12時間＝115,200円

・広報部： 5,100円×3人×12時間＝183,600円

・その他： 2,100円×27人×12時間＝680,400円

・合計： 3,575,400円

b. 業務外の潜在化被害

・本シナリオでは被害なし： 0円


31

c. 復旧に要したコスト

・社員がウィルスチェックに関わった時間： 10分/1人（スキャンが終わるまでの時間ではない）

・6,000円×120台×0.17時間＝122,400円

・端末からウィルスを駆除しシステム再構築に要した時間： 4時間/台

・6,000円×20台×5時間＝600,000円

・業務・経理からウィルスを駆除しシステム再構築に要した時間： 11時間/台

・6,000円×2台×11時間＝132,000円

・その他サーバからウィルスを駆除しシステム再構築に要した時間： 24時間/台

・6,000円×3台×24時間＝432,000円

・ウィルスパターン更新用CD-ROM作成および支店配布費用

・約20,000円

・FAXによる詫び状送付：対象1,200個所、3時間と想定

・6,000円×3時間+1,500円（通信費）＝19,500円

・合計： 1,325,900円

d. 逸失利益（直接的な被害）

・通常の営業利益は残業や代替手段で業務を継続することで損失がなかった。

・業務サーバが11時間停止することでその間オンラインショップの売上が止まった。

・360,000円×11時間/24時間＝165,000円

e. 補償・補填・損害賠償（間接的な被害）

・該当なし： 0円

f. 総合計

・上記a.～e.の合計

3,575,400円＋0円＋1,325,900円＋165,000円＋0円

＝5,066,300円


32

6.2 シミュレーションの評価・考察

6.2.1 経験的に想定される被害額と算出された被害額の差異

この被害額算出モデルの実用性を検証するため、過去に経験値として導き出された被害額と比較

をする。

まず、復旧に要した費用を検証してみたい。

今回の調査において、復旧金額を60,000,000円と報告しているクライアント数4300台規模のユーザ

がいる(9.1ヒヤリング集計参照)。クライアント数に着眼すると、このユーザの規模や被害範囲は本想定

企業の約40倍と考えることができる。

このユーザ事例と想定事例で得られた費用と比較すると以下のようになる。

・ヒヤリング調査のユーザ事例： 60,000,000円

・6.1.6 c.の復旧費用の40倍： 1,316,900円×40＝53,036,000円

両者には約 7,000,000円の差があるが、規模が大きくなれば復元するデータ量も増加し、拠点への

サポートや顧客へのフォローの規模も大きくなるということを加味すると近い値が得られたといえる。

１つの事例で単純な比較は難しいものの、本算出モデルで導き出したコストが、従来からコ

スト管理しているユーザが算出したコストと近い結果となったことは、この算出モデルがある

程度実用的であると予想できる。次に、潜在化被害額についても検証を試みたのだが、残念ながら今回の調査ではその部分に関す

る明確な回答が得られなかった。おそらく的確に算出する手法が確立されていないのが原因と思わ

れるが、まさしく今回紹介する被害額算出モデルがそのためのツールとなるはずである。

このような訳で、想定企業を対象にしたシミュレーションで得られた潜在化被害額の3,575,400円が

どれほど現実的なのかは検証が難しく議論の余地がある。

6.2.2 パラメータに関する検証

被害額算出モデルの精度は、入力するパラメータによって大きく左右される。本算出モデルを利用

するにあたりユーザが頭を悩ませるのが“IT 感応度”と“停止時間”の設定方法ではないかと思う。両

パラメータは算出モデルの精度に大きく影響を与えるが、多分に経験値的なものであるために誤差が

生じやすい。したがって、ここではこの 2 つのパラメータの設定方法を重点的に検証する。

a. 人件費

役職などにより時間単価が異なる。また、たずさわっている業務によっても重要度が変わるため、精


33

度を上げるなら何段階かに分類する必要があるが、全社員数の内該当者の占める割合は少なく、

終的な算出結果に与える影響は少ないと予想されるため、無視しても良いと思われる。基本的には今

回の想定企業によるシミュレーションのように全社員の平均人件費を使用し、突出した例だけ別途算

出するようにすれば良いだろう。

b. IT 感応度

コンピュータやネットワークに依存する割合を意味するが、考慮すべき項目は以下の通りである。

・職種：営業、技術、業務・・・。

・役職：社長、部長、課長、一般社員・・・。

・作業内容： Web 閲覧、メール、各種文書作成、開発、受発注、伝票処理・・・。

・代替手段：紙ベースの受発注処理、手書きの見積、FAX による提案書送付・・・。

・季節係数：決算期、年末年始・・・。

算出結果に精度を求めるのであればすべてを検討する必要があるが、一般的には職種と作業内容

および代替手段を考慮して導き出せば良いだろう。

今回の想定企業では、次のように各部署・各作業内容想定した。

営業

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール・Web：　2時間　　見積：　1時間　　伝票処理：　30分　　提案書：　1時間

メール

・Web閲覧顧客廻り（外出先）顧客廻り（外出先）

メール

（外出先）

メール

（外出先）顧客廻り（外出先）見積作成提案書作成

受注伝票

処理

技術

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール：　1時間　　製品評価：　3時間　　提案書：　3時間30分

メール

作業

準備製品評価製品評価提案書作成メール打ち合わせ提案書作成

作業

準備

マーケティング

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール・Web：　2時間30分　　　資料作成：　3時間30分　　提案書：　2時間

メールメール打ち合わせ提案書作成資料作成Webによる

情報収集資料作成資料作成打ち合

わせ


34

業務

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール：　1時間30分　　受発注業務：　4時間　　伝票処理：　2時間　　データ入力：　1時間30分

メール伝票処理受発注業務伝票処理受発注業務

受発注

業務メールメールデータ入力

開発

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール：　2時間　　開発：　5時間　　資料作成：　1時間30分

メール開発メール資料作成メール打ち合わせ開発

広報

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール・Web：　2時間30分　　製作：　5時間　　入稿：　1時間

メール製作メール入稿製作打ち合わせWeｂによる

情報収集

管理

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール：　1時間30分　　伝票処理：　5時間　　集計：　1時間

メール伝票処理メール伝票処理電話対応メール集計

その他

9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00

メール：　1時間30分　　資料作成：　5時間30分

メール資料作成メール電話対応や

打ち合わせ資料作成メール電話対応や

打ち合わせ資料作成

実際には各担当のその日のスケジュールによって異なるが、職種によって傾向は同じであろうとの

予測のもと、部署別に検討した。また、同じ部署でも担当によって作業のタイミングは異なるはずであ

る。

例えば朝一番にメールを見る者もいれば先に資料作成を済ます者もいるはずである。したがって、

上記では各部署の代表的な作業進行を示したが、各作業の比率を求める目安にすること以外に目的

はない。

前述した通り担当によって進行が異なるので、その部署では 1 日の内何時間どの作業に費やして

いるかという割合を導き出すのに利用する。この過程で出てきた比率はそのまま 1 時間単位に置き換

えることができる。

記述が重複するが、整理すると今回の IT 感応度は以下の要素を吟味することで導き出した。

ア．職種：部署毎（営業、技術、業務・・・）に検討。


35

イ．作業内容：各作業（メール、各種文書作成、伝票処理・・・）の時間単位の比率。

ウ．代替手段： IT 依存を代替手段で補える割合。ここは感覚で割り出す。

＜サンプル＞

ア～ウを参考に営業部を例に取り IT 感応度を検討してみる。

・各作業が 1 日に占める割合から IT 依存度を算出。

・メール・Web 閲覧： 2 時間＝0.2 （2 時間/10 時間以下同様に）

・見積作成： 1 時間＝0.1

・受注伝票処理： 30 分＝0.05

・提案書作成： 1 時間＝0.1

・代替手段

見積書作成などは手書きでしのぐことができるので、上記割合を 0.1 から 0.03 程度に引き下げられ

る可能性あり。

「6.1.6 a.各部署の被害額の算出」で使用した費用は以下のように導き出した。

・6,000 円×1 人×（0.2+0.1+0.05+0.1）＝2,700 円

c. 停止時間

被害発生時の計測は一般的には 30 分単位で十分と思われる。

各サーバの停止が及ぼす被害の範囲は 6.1.4 で述べた通りだが、実際には以下のようにそれらの

停止時間は重複する。

営業サーバ

業務サーバ

経理サーバ

技術サーバ

内向けGW

2日目 3日目11:00 24 :00 12 :00

これに加え各端末の停止時間も考慮する必要があるが、いずれにしろ重複する部分は被害をダブ

ルカウントしないようにし、各業務に長く影響を与える方を停止時間として採用する。

6.1.6 における想定企業のシミュレーションでは業務と経理を除いた他の部署は内部ゲートウェイが

停止していた時間を採用した。もし精度を上げるなら、作業別にその作業に影響を与えるサーバの停

止時間と IT 感応度を用いて算出する。

d. その他パラメータ


36

業務外の潜在化被害、復旧に要したコスト、逸失利益、補償など検討する。この中で業務外の潜

在化被害は感覚的なものになる。

復旧に要したコストは、実際のアクションに伴って発生するため、被害が発生した際の記録が重要

になる。特に人件費、ハード・ソフト費用以外に通信費や運送費などにも注目する。

逸失利益について、オンラインショップなどは実態が掴みやすいが、通常の営業活動による利益の

損失は分かりにくい、特に日本の企業は残業などでリカバーするため実質の被害ではなく、潜在化被

害額や復旧コストとなって現れやすい。逸失利益については、季節係数についても考慮する。

補償などは事後に発生するもので、実際の金額はその時判明する。

6.2.3 算出モデルを利用するためのポイント被害額算出モデルを利用する場合、主に以下の点がポイントになる。

・目的

・事前に用意するパラメータ

・精度

目的とは被害額算出モデルで何を証明するのかということだ。例えば被害を予測し対策費を計上

するための根拠にするのか、事後に実質の被害額を調査するためなのかといったことで、それにより

求められる精度も異なってくる。精度を上げるためには事前に調査する項目・パラメータも多くなり手

間も増える。

今回の想定企業の事例では、当初シナリオに沿って精査する予定であったが、多くの選択肢が有

り一般のユーザがある程度手軽に算出するというものに程遠くなってしまうことが分かった。したがって

シナリオを参考にしながらも実際の算出は平均値的なものを多く使用した。

ユーザが利用する場合には、今回の検証過程を参考に、自社や自組織に適した内容に修正する

事で確度を高められると考える。

6.2.4 実例とモデル式の結果の比較今回作成したモデル式を、実際に報告された事例にもとづいて検証してみた。


37

A B C D企業規模（社員数） 30000 3000001 インシデント被害額(=11+12) \77,434,000 \2,220,000 \18,600,000 \2,816,000

11 潜在化被害(=21+22) \74,304,000 \360,000 \3,600,000 \2,400,00021 業務に関わる潜在化被害(=31*32*33*34) \74,304,000 \360,000 \3,600,000 \2,400,000

31 人件費（/時間） 6,000 6,000 6,000 6,00032 影響を受けた人数 2,580 150 1,500 50033 IT感応度（1～0）34 停止時間（時間） 24 2 2 4

22 業務外の潜在化被害(=41) \0 \0 \0 \041 業務外の潜在化被害 \0 \0 \0 \0

12 表面化被害(=51+52+53) \3,130,000 \1,860,000 \15,000,000 \416,00051 復旧に要したコスト（ハードウェア、ソフトウェア、工数） \3,130,000 \1,860,000 \15,000,000 \416,00052 遺失利益（直接的な被害） \0 \0 \0 \053 補償・補填・損害賠償（間接的な被害） \0 \0 \0 \0

01 インシデント被害額 \77,434,000 \2,220,000 \18,600,000 \2,816,000実被害額 \60,000,000 \2,310,000 \19,500,000 \3,116,000

潜在化被害 \56,870,000 \450,000 \4,500,000 \2,700,000表面化被害 \3,130,000 \1,860,000 \15,000,000 \416,000

モデルと実申請被害額との差 \17,434,000率 1.29 0.96 0.95 0.90

IT 感応度を 0.2 と仮定してみた場合、モデル式と報告された実被害額はほぼ一致した。IT 感応度の 0.2

という数値は、ヒアリングでインシデントによって被害を受けた業務が、全業務に占める割合を聞いたところ、

大体 20%前後であろう、という回答が多かったこととも符合する。平均値で見ると、一般的な業務でのネットワ

ーク依存度は約 20%程度ということなのであろう。

0.2 0.2 0.2 0.2

\-90,000 \-900,000 \-300,000

ここでひとつ注意をしなければならない点がある。それは、今回 IT 感応度として設定した数値は、実は少

なくとも 2 つのパートからなっている可能性が指摘される。

IT 感応度＝ (IT 化による業務効率化係数:α) × (IT 化の危険度対策係数:β)

αは、IT 化により手作業を減らし、作業効率を向上させることを意味し、1.0 に近いほど進んでいると認めら

れる。一般的に IT 革命といわれるような部分も、このαを大きくすることを意味している。しかし、αが大きく

なると、インシデントが発生した場合の被害金額が大きくなる。これが IT 化を推進するための懸念材料として

取りざたされるものではないかと思われるが、この懸念を取り除くために、βを小さくすることが必要になる。

βもαと同様、0~1 の間の数値を取るが、IT 化のリスクを避けるための対策が適切にとられていれば、値は

小さくなる。これらの関係は、IT 化によるリスクを避ける対策をとりつつ、IT 化による業務効率を向上させる、

という直感的な感覚とも一致している。このαとβを決定するガイドラインは、次回の調査でもう少し定量的

に決定できるように調査することが必要であろう。

7. 今後の課題 7.1 モデルの課題今回、被害額および予算額についてそれぞれ算出方法のモデル化を試みた。モデルをより精緻なものと

するため、今後克服すべき課題を検討する。

7.1.1 情報セキュリティインシデント被害額算出モデルの課題「4.3 インシデント被害額算出モデル」でモデルを提示し、各項目について補足を記述

した。しかしながら、実際の算出業務を行う場合、現実に数値を算出しにくいものが少な


38

く無い。特に、「IT 感応度」は、今回提案した新しい概念であり、システムの導入状況や業種に

よって企業毎に大きく異なる。システムの停止によって、業務量の減少が目に見える場合

には、容易に IT 感応度を把握できるが、メールやデータ作成などの一般事務処理を行う社

内 LAN などでは、減少した業務量の把握は非常に難しいと考える。このようなシステムの「IT 感応度」は、業務内容を踏まえ社内で見当付けた数値を使用

せざるおえない。被害が生じた場合、見当をつける方法としては、業務に精通した担当者

や業務上障害を受けた従業員へのヒヤリングが考えられるが、数値の算出には、担当者の

主観が入りやすいのが現実である。今後は、被害発生時に可能な限り調査を行い、システムダウンの状況だけでなく、現実

の業務に対して生じた障害情報をできる限り収集し、業種や業態、システム導入状況など

によって、ある数段階程度に分けた「IT 感応度」を容易に算出できる仕組みを作ることが

必要と考える。また、実行効率の低下を抑制する代替え手段の効果についての評価も同様となる。

7.1.2 情報セキュリティ対策費用算出モデルの課題「5 情報セキュリティインシデント対策費用額の算出モデルについての検討」にて、対

策費用として捉えるべき範囲を今回提示した。これら項目は、現時点で考えられる対策を

できるだけ盛り込んでいるが、新しい対策技術によって、項目が追加される事が予想され、

そのときの状況によって、項目を追加する事が必要である。また、これらの項目は、それぞれの部門で予算化されている。例えば、ファイアウォー

ル導入などは、システム予算となりやすいが、ソーシャルエンジニアリング対策などは、

施設部門や教育部門で実施するものも考えられる。対策費全体の捉えるには、これらの関

連部署との横の連絡や連携も重要である。今後は、対策予算の調査などを通じ、システム部門の対策予算だけでなく、他部署で実

施している部分についても、状況を把握することが望まれる。現実的には、システム部門担当者が他部署にヒヤリングするためのツール作成とそのツ

ールへの記入などが必要な状況である。

8. 最後に

今回、JNSA 会員を中心に主要企業を含んだ形で、ネットワークインシデントに関する調査を行った。インタ

ーネット関係の被害調査や脆弱性に関する調査は、日本でも多く実行されている。「被害」を調査するという

意味では、警察庁の公開資料にはかなり力の入ったものがある (http://www.npa.go.jp/police_j.htm

→ハイテク犯罪対策→重要インフラにおけるサイバーテロ対策状況に関する調査結果 [H13.1.27 掲載])。


39

金額などの統計情報が無いのと、定期的に調査していない点が残念であるが、かなり細かく調査されており、

回答率が 42%以上(844 社)という数字はこの手の調査としては驚異的であるといえる。

他には、財団法人金融情報システムセンター（FISC）も「コンピュータシステムの安全対策状況調査」を

ほゞ隔年毎に実施しており、2001 年 3 月が直近の調査となっている。この調査は金融機関における安全対

策が主眼であり、被害額や投資額などの統計情報は無い。

日本政府も 2001 年 10 月に電子政府の情報セキュリティのためのアクションプランを発表している

(http://www.kantei.go.jp/jp/it/security/suisinkaigi/dai4/4siryou2-2.html)。内容については

いろいろ議論があるだろうが、意思決定の背景となった理由や議論された内容があまり述べられていないよ

うに感じるのと、特に定量的なデータが無いので単なる作文の域を出ず、説得力に欠ける感じがしてしまう

のが残念なところである。

一方米国では、アシュクロフト司法長官がプライスウォーターハウスクーパーズの報告書を引用して、昨年

のクラッキングやウィルスに対する犯罪対策に、3000 億ドル(約 40 兆円)にものぼる投資をしていると発表し

ている(http://kyl.senate.gov/072501/open.htm)。また、実際の被害額もコンピュータセキュリティ学会

(CSI)と FBI による 2001 年の報告書(http://www.gocsi.com/forms/fbi/pdf.html) によると、2001 年の

回答社の内、約 35%の 186 社が被害額を回答していて、この総額が約 3.8 億ドル(約 500 億円)にのぼるそ

うである。

本調査は NPO 日本ネットワークセキュリティ協会(JNSA)による、経済産業省の情報セキュリティ政策室や

IPA/セキュリティセンターなどと連携を取った、被害額や対策費用を含んだ調査である。これは、経済産業

省の業界動向を把握するという目的にも適い、JNSAが作業主体ではあるが、経済産業省やIPAが全面協力

を行い、JNSA 会員企業を中心に日本の基幹産業をも調査対象としている。

この調査の目的は、国内におけるサイバーテロや重要インフラのセキュリティインシデントに関する現状を

把握するための第一歩として、セキュリティインシデントの被害額や情報セキュリティの投資額を推計する手

法を開発するとともに、この手法に基づいた情報セキュリティインシデント被害について基礎的な情報を収

集することである。

本調査は、アンケート調査だけではなく直接ヒアリングも行い精度の高い結果を得るとともに、被害額や投

資額を推計するモデルの叩き台を作り上げることを目標にした。また、アンケート、ヒアリングともに、回答で

きないと答えられることも想定しており、このような調査に対してどの程度情報公開ができると考えているかを

探ることもできた。とはいえ、3.4.3 項にもあるように、母数が少ないとはいえ、かなり高い回答率を得ることが

できた。ヒアリングも思いの外協力的な反応が多かったのが印象的だった。現状ではたまたまご回答いただ

いた担当者の考え方に依存してしまった面は否めないが、積極的に情報公開を行い、自分たちの経験をイ

ンシデント克服に役立てたいと考えている組織があるのも事実である。

回答できないと答えられたところには、外資系で本社の支持で回答できないという場合や、ポリシーを作っ

ているので、情報公開できないという回答が多かったようである。後者の方は、セキュリティポリシーを盾にし

た情報公開を回避する動きにもなりかねない心配がある。今後はセキュリティポリシーなどを盾にして非公開

とするのか、情報公開と絡めて積極的に公開していく方針の組織が好印象を得られるのかは、見守っていく


40

必要があるだろう。

後に今回ヒアリングにご協力いただいた企業の方々には、率直なご意見をいただき、大変感謝しており

ます。ここで提示できたネットワークインシデント被害額算定モデルは、実際の被害額を算定する他、何も対

策を行わないとどの程度の被害が想定されるか、といった大期待値を算出することにも使用できると考え

ます。

このような数値を考えて対応策への投資を行うことが重要であり、組織や国家の施策を考える時のよりどこ

ろになるのだろうと考えております。


41

参考資料

8.1 参考資料１：ヒヤリング集約 8.1.1 ウィルス対策の状況 ①過去の被害について

補足＜被害金額については、以下の被害モデルを推定しながら算定しています。＞

被害額＝固定費(人件費)×被害人数（クライアント：サーバ依存数）×IT感応度（＝業務依存度、）×停止時間（ｺｽﾄ）

＋復旧費（＝直接費、間接費）＋利益損害(＝１日利益×停止日数)

Larux、Code Red、Sircamは小規模に感染。Nimdaは全社的に感染。

Nimda時はクライアント4300台中413台感染、サーバは700台中123台感染。

全サーバ・クライアントの感染チェックから復旧までに実働3日間（木、金、土、

日、月（祝）、火）かかった。

6,000×（4300×0.6）×0.7×（8×3）＋（6000×20×24）＋（５００×５００）＋0＝263,194,000

※本ユーザが試算した復旧費用は60,000,000円（人件費以外にも各拠点向けバック

アップCD-ROM 500枚を社員20名が徹夜で焼き、それを宅配便で配布した運送費なども

含む）。

※本ユーザは自社社員の人件費を1時間あたり6,000円と想定。

・XM/Laroux(ラルー) 、W32/Nimda(ニムダ) 、W32.CodeRed（コードレッド）で被害発生

・ウィルス駆除ツールのインストールとチェックを全社に要請。全体でバスターをチェックする作

業量 500台×１０分

・全機器でパッチ対策、ネットワーク構成の変更等、資産洗い出し、ウィルス調査・報告等、情

シス部門のみ、4人×5日×5000円×８ｈ＝８０万円他(全社PCとサーバの対策費)

・調査、対策、再インストール等、他全社員の作業、4人×5日×５，０００円×８ｈ＝８０万＋全

社員の作業時間

・Sircamが1部門（1セグメント）で感染。

・1人の端末で感染を確認 -> 駆除 -> 翌日社内LANに接続したところ再度感染 -> 社内に

感染元があると判断 -> 5台の端末で感染が確認された。

・復旧に1日かかった。

社内は特にない。顧客の方は完全に把握していない。


42

ＣｏｄｅＲｅｄ

被害人数：150

ＩＴ感応度：不明

停止時間：不明、復旧時間は２時間程度

Ｎｉｍｄａ

被害人数：1500

ＩＴ感応度：不明

停止時間：不明、復旧時間は２時間程度

・システム管理者は、３名が３日程度復旧に時間をかけた。

・復旧用に１000枚のＣＤを作成した

2001年12月18日、BadTransにクライアントが感染したが、

そのとき使っていたメールクライアントのVeckyのファイル保管方法とアンチウイルスがファイ

ルを消去して駆除する方法があわず、メール消失が発生した。

→Veckyは複数のメールをまとめて1ファイルで保存するが、このうちの1メールが感染すると、

それを含むファイルが削除され、感染していないメールも消えてしまう。

→Vecky 2．00.08移行は、添付ファイルつきのメールは1ファイルで保存する。

１．サーカム（感染あり）

復旧所要日数：９日（01.10.23発生）

社内作業：状況把握・監視に0.3人×９日＝２．７人日

社外作業：状況把握・監視0.5人×９日＝４．５人日および復旧作業0.5人×10日＝５人日

復旧費用：社外分のみで、４．５万円×９．５人日＝約５０万円

２．コードレット（感染はないが予防対策を実施）

対策所要日数２日

社内作業：状況把握、対策１０人×１日＝１０人日

社外対策費用はかからなかった

３．ニムダ（感染はないが予防対策を実施）

対策所要日数：３日

社内作業：状況把握、対応協議：３人×３日＝９人日。社内調査：0.2人×140台分=２８人日

社外作業：対策１人×５０台分＝５０日人

社外対策費用：４．５万×５０日人＝２２５万円

・ウィルスによる被害はない

・ NotePCによりマクロウィルスが持ち込まれたことはある。ただし、伝染はしていない。


43

バッドトランスの被害が一回

ウイルスチェックは入っていたがDBファイルの更新が遅れたため、外から受け取ったメールで

感染した。社内システムには影響なし、個人ＰＣとメールサーバにウイルスチェックソフトを入

れた。それ以外の被害は無し

＜被害モデル式＞

作業に要した日数としては、1.5人/日

・FD経由で感染する古いタイプのウイルスへの感染事例あり。インターネットへの接続ができ

ない状態なので、近主流のメール経由で感染するタイプのウイルスの被害にはあっていな

い。


44

②対策の現状について

・ Nimda以降、危機管理室設置。以下の部門からメンバーを収集。

・人事、総務、業務、技術、営業

・ウィルスチェックをインターネットゲートウェイと各クライアントで実施。

・コーポレートエディションとし、自動的にウィルス定義ファイルの更新が可能なようにした。

・感染を確認したら、通信ケーブルを抜くという手順を確立し、社内に徹底した。

ポリシー作成

セキュリティ監査委員会(10数人だが実質３～４人)

IT委員会(各部署1名程度) [人事が出せという。新人が多い]

定期的にソーシャルエンジニアリングのチェックを行う。

CodeRed, Nimdaなどは社内の無関心との戦いである

・リスク移転のため、メールサーバはアウトソーシングしている。

・ウィルスパターンは、サーバの場合1日3回チェック、端末は1日1回チェック。

・ネットワーク上のウィルスチェックは“インターネットとの接続点”と“E-mailをNotes”に変換す

るところの2箇所でチェック。

・電源off/onがトリガになりウィルスパターンの更新がされる。

社内、サービス用ともパッチは新をすぐに当てている。

NICの2枚ざしを禁止。

クライアントPCにアンチウイルスを全数導入している。

・メールサーバ及び全クライアントにアンチウィルスソフトをインストールしている。

予防は監視が重要。即座に対応できる体制を作っている。

インシデントと思われる現象が発生した場合は、フロントルータを停止する。

アンチウィルスソフト導入（ゲート、クライアント）

ファイルサーバの対策は未実施

eﾒｰﾙはグループウェア方式にしている。ウイルスチェックサーバーを導入している。ﾊﾟﾀｰﾝﾌｧｲ

ﾙは自動更新に切り替えた。ＬＡＮに接続する端末はすべてウイルスチェックソフトをインストー

ルしなければ認めていない。ウイルス情報を早く掴み素早くパターンファイルを更新する運用

である。

・危険なソフトは使用しない

ブラウザ；ＩＥ禁止

メーラー；Ｏｕｔｌｏｏｋ禁止

・ノートPCの持ち込み、持ち出しは、上長の許可が必要

・全クライアントにアンチウィルスを導入し、毎週パターンファイルの更新をする

・部外者によるPCのﾈｯﾄﾜｰｸ接続は原則的に禁止


45

・クライアントにアンチウィルスソフトをインストール。

・サーバー用アンチウィルスソフトをインストール。１回／１Hパターンファイルを確認し、更新す

る。

・クライアント管理ツール導入済み

・IIS使用していない

ウイルスチェックソフトをネットワーク及びクライアント全端末に導入、営業部員はiKeyを利用し

データを保護

全クライアントにアンチウイルスソフトを導入済み。


46

③今後の対策・希望

・社員のウィルスについての認識は高まったがファイアウォール、IDSについてはまだ認識薄

い。今後は不正アクセスについて強化する。

ウイルス情報の社内公開ポリシーを属人的でなくして欲しい。

(例)ある機種の情報は社内に流すな。

危機感をあおるような書き方はするな。

長いとだめ、オリジナル(CERTなど)の書き直しを迫られる。

全社的な温度を聞くと良い？(例えばあの部署は70℃前後とか)

・現行はIT予算として一括されている予算を、セキュリティ予算は単独で取りたい。

IPA/JPCERT以外に、システム的、物理的、アーカイブなどに関する情報交換ができるセンタ

ーがあると良い。

ネットワークセキュリティの動向情報が欲しい。

メールサーバが飛んだときの被害額の想定などが選出できると良い。

一番の脅威は、外に攻撃してしまうこと、ウイルスなどをばら撒いてしまうこと。

自社がやられるのはあまり気にならないが、客先への攻撃は厳しく監視している。

ファイルサーバなどへのアンチウィルスソフトの導入

パソコンの持ち出し時の対応が今後の課題。情報漏洩対策でも必要。

特に現状で問題はない

今後、事務系ネットワークからインターネットを利用できるように設定した場合の対策に不安。

現在は使用できない状態のためウイルスに対するユーザーの意識レベルも低いと思われる。

セキュリティポリシーの策定と教育などの対策が望まれる。


47

④担当者のあげる問題点

・すべてのサーバ・クライアントのチェックに時間がかかった。

・各現場での責任者を決め、手順などを通達するなどの体制作りに手間取った。

・FAXで全社通達すると160箇所で3.5時間かかる。

・コンピュータ画面で各地の復旧作業進行状況などを管理試みたが画面が小さく、またスクロ

ールなど必要ななため、情報共有に難有り。結果的に進行管理などは壁に模造紙を貼りそこ

にスケジュールを書き込み管理。状況が一望できるなどの理由でコンピュータ画面より効率が

高いことが分かった。

・ PCの導入時期がまちまちで古いものはパッチない。

ボランティアベースなので社内評価が不足している(特に営業)

組織ピラミッドの上部と底辺が問題

開発中心の上層部の意識が古く、人間的な相性が問題になっている。

社内ボランティア作業の業務としての認知をして欲しい

内部不正アクセスは強化の必要性はあるが、現在は特に対策していない。

OUTLOOKなどは止めたいが代替が無いのと、移行コストの対策が必要。

・モバイル（ノートＰＣ）による社外からのウィルスの持込

・リモートアクセス環境による感染

・許可されていない外部接続による感染

・インターネットサーバのパッチ当てを忘れたことによる感染

・管理されていないインターネットサーバ（ホスティングなど）による感染

意識レベルは高いがバラつきがある(各々の事情があるのは確かだが…)

ノートPC、PDA、携帯などの対策を強化したい(落とす、盗まれる)

セキュリティ対策全体の提案をしてくれる会社があると良いが、今のところそうした会社がまだ

ない。

外部の人間（コンサルタントなど）が端末を接続した場合に、ウイルスを持ち込んでしまうこと

がある。

要員が３人と少なく、セキュリティの専任ではないため多忙である。

悪意のない従業員による事故は、事前に発見しにくい

個々のクライアントパソコンの管理については個人任せになっているので、クライアントPCのソ

フトウエアの構成管理がとれていないため、何か問題があった場合に原因の把握に問題ある

可能性あり。


48

8.1.2 不正アクセス対策の状況 ①過去の被害

＜着眼点＞・スパムメールの発信元対策、・踏み台、DoS、etc…

・以前、社員が社内からスパムメール（ねずみ講）を発信した。

・社内不正アクセスは営業部長がターゲットになりやすい。

現場の意見がうまく吸い上げられていない面がある。

金額を誤魔化して首になったものがいた。普段から不審な行動があったので、LOGなどをモ

ニターしていて発覚した。出勤簿を出たことにしていたなど、割に単純なものだった。

社員の女性のアドレスを出会い系サイトなどに無断で掲載し流出したことがあった。

・DoSが韓国からあった。3秒に1回メールが届き負荷が増大した。

・ある拠点がスパムメールの踏み台になった。

スパムメールの被害あり。

CodeRedでは、夕方監視していて発見。IPから該当者を割り出したが、DHCPを使っていたた

め、調べたときにはノートPCが外れていて特定に手間取った。

発信源を特定して後、全サーバ、PCに対してペネトレーションテストを実行し、更に過去LOG

をチェックし見逃しを防いだ。

Nimdaは日本時間の夜間に発生し、翌朝アクセス禁止するまで半日くらい掛かった。

重点監視を行っていたので、被害はない。

Sircamは、直接SMTPで相手IPアドレスへメール発信するが、メールを直接社外へ転送する

アラートを検出していて発見した。

直接SMTPでメールを出すと、メールサーバのウイルス検出をすり抜けてしまうので、決めら

れたルート以外は禁止している。

当初は転送のたびに問題がないかどうかを確認していた。

スパムメールにドメインを不正利用された。

ＩＤＳにリポートはあがってくるので何らかのアクセスがある模様。

ポートスキャンは頻繁に行われている。実害はまだ無い。

スパムメールの被害あり。

・スパムメール（Fromの改ざん）あり

・Ｗｅｂ改ざんのアタック形跡あり

・スパムメールの踏み台にされたことがある。（一万通）

特になし、Web改ざんもなし、社内犯罪も無し


49

②対策の現状

・スパムメールを行なった社員について、現行の社員規定に則り懲戒処分に。全社に名前

の公表と行為の内容を公表。

・この後、Webとメールはフィルタし制限をかけるようにした。ただし、外部のMLに参加するこ

とは規制なし。”２ちゃんねる”も閲覧はOK、投稿はNG。社内のMLは制限付きで管理。

・社員の使用するメールソフトは規定なし。

・ツール（LAN管理監視システム）を使用した全PCの資産管理を実施。

・IPアドレス、MACアドレスの管理。

・OS、アプリケーションのシリアル、バージョンの管理。

定期的にソーシャルエンジニアリングを行ってチェックしている。

社内不正アクセスは、発覚してから調査する。

・DoSについては、そのアドレスをフィルタ。

・スパムメール対策として、現在POP before SMTPを実施。

・帰りには各自端末の電源はoffにする。（ISO1400で規定されているため）

ポリシーの文書化(一般ポリシーも含めている。

ネットワークセキュリティに特化していない。)

・ペネトレーションテストを実施している

BadTrans、Nimda以降、ネットワークセキュリティに関する投資に着いての理解が進んだ。

ＩＤＳなど

インターネット公開サーバは、unix系でIISは使っていない。

２４時間監視を専門会社に依頼している。セキュリティホールへのパッチ当ても専門会社に

委託している。

・管理者への教育を実施

・管理者へのアンケートやヒアリングを行い、セキュリティ対策の実施を確認

・監査部門にて、システム監査を実施

・インターネット接続は上長への許可を得てから閲覧

特に問題となるようなことは起こっていない。

被害が起きにくい理由としては、Windows機種が少ない、IISが無い、Macintoshが多いことが

考えられると思う。


50

③今後の対策・希望

・ネットワーク障害に備え、紙ベースでの業務運用も検討。

社員の入換に対応できる体制を作りたい

PCの数(対処機器数)、OS、資産管理、専任の有無、スキル(LOG,経路変更など)、の正当な

評価管理

・アウトソーシング部分は事業者が監視。ログを定期的に報告受けている。

今後は、ＩＣカードなどて個人認証を行ないたい。

内部不正アクセスは、事故か故意かが難しい。

どちらにせよ社内ネットワークの監視が重要である。

今後はセキュリティの社員教育も行いたい。

常に従業員のセキュリティに対する意識の向上を行う

・システム監査の実施を検討中

・容量計画（ネットワーク的な問題）

④担当者のあげる問題点

・社員のアクセスを監視することの、社員の理解。

・組織の上層部（経営層）と下位層（一般社員）が問題。

・社員の無知、無理解が問題。社員急増すると特に顕著。

・開発関連の上層部の意識が古い。

対外的な風評も重要（my partyが全社MLに流れた。)

・アウトソーシング委託先事業者のログは、専門用語が多くわかりにくい。不信なパケットが

あっても問い合わせしないとソースアドレス・ディスティネーションアドレスを知らせてくれな

い。

・DHCPなのでアドレス管理ができていない。

MLに社内向けメールが流れるのは大きな問題である。

全社的にセキュリティレベルを向上させる方法がわからないのが心配である。

常時監視をしているためポートスキャンはすぐ分かる。気持ちが悪い。これを排除するいい

手段は無いか

悪意のない従業員による事故は、事前に発見しにくい

社内教育訓練の実施（社内ネットワーク知識レベルの差がある）


51

8.1.3 情報セキュリティ管理への取組状況


52

・ポリシーは実情に沿った内容で作成。

・ポリシーは作成しただけで安心してしまう傾向にある。

・前述の通り、派遣社員もLDAPで管理だが、終的にはモラルの問題である。

・ポリシーを作っている。(実情に沿った良いものになっている)

・アンチウイルスはコーポレート契約している。

・クライアント配信は自動配信を使っている。

・昨年全社的なポリシー策定を検討。（予算の関係で延期。、トップダウンを目指し、来年度に

再検討。）

・現在は外部からのアクセスに関する部分のみポリシーを策定。（ウィルス対策はモバイルに

も適用。モバイルはVPNを使用するが、規定としてはVPNは記述されていない。仕組みとして

盛り込まれているので必然的にモバイル環境では必須条件となっている。

ノートPC対策。

全クライアントにアンチウイルスソフトを入れている

ポリシーを明文化している

ISPとして技術者のレベルアップに努めている

・認証を取得している

・セキュリティ教育をWBTで実施している。

・人材派遣や外注の人には、個人で守秘義務契約書を書いてもらっている

入隊室管理は、全社でそこそこやるよりは、必要なところは徹底的に行うのが良い。

セキュリティポリシーについては方針のみをうたっている。基準書はＩＴ企画室の内規になって

いるが、年度内に基準書としてリリース予定。

派遣社員の基準もある程度はある。

セキュリティの認証を取るつもりはない。なぜなら、認証取得を公表するとかえって、外部から

狙われやすくなると考えるため。

ポリシーは策定済み。規約はできているが全員それを守っているかが今後の課題。

・規定や手順書など完備している

・セキュリティ委員など組織的対策も実施

・セキュリティ委員は、各事業所にて管理職向けの教育を実施。

その後もフォローアップを続けている。

・ＵＲＬのフィルタリングを行っているが、業務上必要な場合もあってきびしくはやっていない。

・ノートＰＣの持ち出し、持ち込みは上長の許可が必要である。

セキュリティポリシーなどセキュリティ関連ドキュメントなどはない。

また、組織的な対策も未実施。

担当者レベルでのセキュリティポリシーの策定準備中。現在はノートPCの持込や持ち出しは

原則禁止している派遣社員はいない

原則禁止している。派遣社員はいない。


53

8.1.4 その他

無線LANの問題が大きいが、現状では製品依存の対策になってしまう。

運用サービス(監視)などの継続は、セキュリティ業界自体の問題かもしれない。

セキュリティ管理者のまだ明確にいないが、社内人材を組織化している。

Webの直接の改ざんではないが、キャンペーン用などで使ったドメイン名を使用後継続してい

なかったために、第３者に使われてしまい。それを当社のＷｅｂとかん違いした人が当社のＷｅ

ｂが改ざんされたと思ってしまった。

セキュリティ管理費という運用コストを考えるのが良い。

Windowsの２K,XPなどでユーザによるアクセス制御ができるようになったが、administratorの設

定や利用方法が中途半端で、UNIXのroot程の効果が上がっていない。

子会社、ハウジングを委託した会社でコードレッドに１台づつ感染した。自社のみでなく委託先

のセキュリティも同様に高める必要がある。

セキュリティの保持で、一番重要なのは、社員の意識付けだと考えている。

セキュリティに関する情報については、社外に公開しない方針である。よって、セキュリティ対

策は、万全を期すが、BS7799などの認証は考えていない。

・24時間稼動できるよう、データの保全性を維持することに注力している。

・社風としてルールを守るという意識の社員が多いと思われる。

アンケートへの意見

問題の関連性がわからない（0から積み上げ式の統計であり真ん中がない、全ｂに○がつけら

れるような問題ではない）

被害がウイルスに偏っている

おおざっぱである（改ざんならば、内部から？外部から？社内情報でも社内の「何の情報

化？」などの区分けが必要


54

8.2 参考資料２：アンケート結果一覧表

a b c d e f h I j

A-1 貴社の従業員数をご回答下さい。（1つ選択） 0 9 8 7 4 15

A-2 貴社の拠点数をご回答下さい。（1つ選択） 11 3 10 2 26

A-3 貴社の年間売上をご回答下さい。（1つ選択） 2 1 8 40

A-4 貴社が属する主要業種をご回答下さい。（1つ選

択）

3 0 1 1 33 1 0 7 6

B-1 貴殿の所属部門をご回答下さい。（1つ選択） 1 0 0 5 21 9 8

B-2 貴殿の役職をご回答下さい。（1つ選択） 1 8 28 7 3 4

B-3 a総務 2

b人事 3

c経理 1

d企画 14

e情報システム管理 35

f情報システム開発 37

g営業 11

B-4 a経験なし 3

bデータ入力 5

cソフトウェア開発 39

dハードウェア開発 5

eシステム構築 36

fシステム運用 29

g開発プロジェクトマネジメント 21

h運用チームマネジメント 25

iその他情報システム関連業務 18

a b c d e f g h I j

C-1 貴社が保有しているパーソナルコンピュータ（PC)の

台数をご回答下さい。（1つ選択）

0 0 14 12 26

C-2 貴社のインターネットへの主たる接続方法をご回答

下さい。（1つ選択）

0 0 1 6 2 27 16 0

C-3 社内に情報システムネットワーク（LAN等）がありま 52 0

g

9

0

7


55

すか。（1つ選択）

1-1 1ない 7

2情報セキュリティポリシーとして規定している 30

3就業規則の一部に情報セキュリティ関連の規定

がある

13

4個人情報保護規定の一部として情報セキュリティ

関連の規定がある

10

5その他規定の一部として情報セキュリティを規定

している

12

6情報セキュリティ関連の作業手順を規定している 14

7分からない 1

8その他 2

1-2 1情報セキュリティ規定の目的 33

2規定の適用対象・範囲 29

3セキュリティ管理者の職制・任命方法 26

4情報分類方法 20

5個人情報保護 30

6規定の遵守義務と罰則 25

7知的財産権保護 21

8システム企画・開発 16

9システム運用 21

10事故・事件・障害時の対応手順 24

11リスク評価・見積方法 8

12守秘義務 29

13外部委託 12

14業務継続計画 12

15監査 20

16機器・設備管理 28


56

17情報システムの構成変更管理 20

18ネットワークの接続変更管理 26

19アクセス管理 32

20磁気テープ等の媒体管理 19

21電子メール管理 33

22コンピュータウイルス対策 37

23不正アクセス防止 33

24情報発信規制 14

25情報収集・利用・再利用規制 11

1 2 3 4 5 6 7

1-3 情報セキュリティに関する規定を制定した大の理

由をご回答下さい。（1つ選択）

8 1 8 4 11 2 13

1-4 情報セキュリティに関する規定の運用状況をご回

答下さい。（1つ選択）

15 5 13 7 3 3

1-5 情報セキュリティに関する規定を制定していない

大の理由をご回答下さい。（1つ選択）

2 0 0 2 1 1

1-6 情報セキュリティ管理部門がありますか。（1つ選

択）

7 14 20 7 2 1 1

1-7 1情報セキュリティの部門は未設置 7

2相談窓口のみで実行部隊は別部門に所属 2

3情報技術に秀でた人材を配置 35

4部門横断マネジメントに秀でた人材を配置 14

5法務関連知識に秀でた人材を配置 7

6その他専門知識に秀でた人材を配置 5

7分からない 5

1 2 3 4 5 6 7


57

1-8 情報セキュリティ管理部門には、十分なリソース（人

材・予算）が投入されていますか。（1つ選択）

8 6 2 5 25 7 0

1-9 貴社全体の情報セキュリティ管理者は明確になっ

ていますか。（1つ選択）

8 35 7 4

1-10 1-9で、2または3と回答した方にお聞きします。貴社

全体の情報セキュリティ管理者の役職をご回答下

さい。（1つ選択）

11 9 18 4 0

1-11 1情報システム技術 27

2情報セキュリティ技術 29

3法務 8

4プロジェクトマネジメント 14

5監査 7

6社員教育 7

7専門職職員のマネジメント 5

8非専門職職員のマネジメント 1

9認証取得 2

10海外赴任 0

11社内事情に詳しく社内人脈が豊富 6

12特定の技術・経験は要求しない 2

1 2 3 4 5 6 7 8 9

1-12 情報セキュリティ管理者の育成や教育をしています

か。（1つ選択）

24 9 7 1 3 5 5 0 0

1-13 情報セキュリティ管理部門はどこに所属しています

か。（1つ選択）

7 4 7 0 22 8 0 2 3

1-14 1管理部門は未設置 7

2社内報・イントラネットで告知 30

3情報セキュリティ教育で告知 14

4正社員全員に情報セキュリティのハンドブックを配

布

5


58

5全従業員（派遣、アルバイト、パート含）に情報セ

キュリティのハンドブックを配布

3

6オフィスの壁、掲示板等の目につきやすい場所に

管理体制を掲示

1

7分からない 3

8その他 13

1 2 3 4 5 6 7

1-15 情報セキュリティ関連の事故や事件が発生した場

合の連絡体制をご回答下さい。（1つ選択）

1 5 8 15 19 3 2

1-16 1特に意識していない 14

2経営状況やサービスレベルの分かる取引先を優

先

12

3 情報セキュリティに関する認証取得企業

（BS7799、プライバシーマーク等）を優先

3

4情報セキュリティポリシーの制定企業を優先 2

5システム監査を受けている企業を優先 1

6機密保持契約を締結 35

7個人情報保護契約を締結 8

8サービスレベルを規定した契約書や覚書を締結 12

9取引先からの監査の受け入れ 1

10取引先の監査を実施 2

11分からない 6

12その他 3

1-17 1特に対策はしていない 5

2情報の取扱いに関する契約（機密保持契約等）締

結

37

3情報システム教育の実施 11

4情報セキュリティ教育の実施 11

5分からない 3

6その他 7

1-18 1対策は行っていない 1


59

2利用機器やソフトの標準化 27

3代替機器の確保 32

4代替オフィスや代替サーバルームの確保 3

5バックアップデータの遠隔地保管 20

6データのバックアップ 46

7分からない 1

8その他 3

1-19 1明文化したルールはない 16

2利用機器やソフトの標準化 17

3代替機器の確保 10

4代替オフィスや代替サーバルームの確保 3

5バックアップデータの遠隔地保管 13

6データのバックアップ 29

7分からない 2

8その他 4

1 2 3 4 5 6

1-20 業務継続計画という言葉を知っていますか。（1つ選

択）

18 9 7 9 7 3

1-21 1定めていない 12

2発生事象別の被害状況の確認事項 8

3被害状況の確認責任者 12

4被害発生時の社内連絡体制 13

5被害別の社外連絡先（ベンダー、業界団体､コン

サルタント等）

8

6従業員への情報開示方法と情報開示レベル 2

7第三者への情報開示方法と情報開示レベル 1

8復旧時の確認事項 9

9分からない 0

10その他 3

1-22 1行っていない 3

2定期的にOS・基幹ソフトベンダーのHPを確認する 29

3セキュリティ情報を提供する組織（IPA/ISEC等）の 40


60

HPを確認する

4セキュリティ情報提供サービスを受けている 25

5分からない 2

1 2 3 4 5 6 7

1-23 情報システムの利用者は情報セキュリティ確保の

ため生じる不便さ*にどのように対処していますか。

*パスワードの定期的変更、ウイルス定義更新等（1

つ選択）

7 34 0 5 1 5 2

1-24 1情報セキュリティポリシーの制定、メンテナンス 24

2システム開発 27

3ネットワーク構築 29

4システム・ネットワーク管理 33

5品質検査（QC、QA） 6

6システム監査 4

7分からない 4

8その他 8

1 2 3 4 5

1-25 情報セキュリティ事故や事件に対する罰則や評価

についてご回答下さい。（1つ選択）

18 8 11 6 7

1-26 1未実施 20

2経営者・役員クラスを対象とした情報セキュリティ

管理教育

4

3全管理職を対象とした情報セキュリティ管理教育 11

4全管理職を対象とした情報セキュリティ関連技術

教育

2

5一部の管理職を対象とした情報セキュリティ管理 2


61

教育

6一部の管理職を対象とした情報セキュリティ関連

技術教育

1

7情報セキュリティ管理者を対象とした情報セキュリ

ティ関連技術教育

6

8希望者を対象とした情報セキュリティ関連教育 3

9全社員を対象とした情報セキュリティ関連教育 19

10分からない 3

1 2 3 4 5

1-27 情報の重要度に応じた分類規定はありますか。（1

つ選択）

16 21 10 4 2

1-28 1第三者がオフィスに入退室するための手続きが定

められている

25

2第三者がオフィスに入退室する時には入退室記

録を取り記録を保管している

16

3第三者が情報システム設置室(サーバルーム等）

に入退室するための手続きが定められている

31

4第三者が情報システム設置室に入退室する時に

は入退室記録を取り記録を保管している

20

5入退室の規定はない 12

1 2 3 4 5 6

1-29 従業員や情報の安全性を確保するための建築上

の配慮をご回答下さい。（1つ選択）

11 7 17 12 4 3

1-30 重要データやインターネット接続サーバのアクセス

ログを定期的に解析していますか。（1つ選択）

1 7 19 19 5 3

1-31 1ユーザID・パスワードを利用していない 0

2ユーザIDやパスワードの管理はしていない 1

3ユーザID別に重要資源に対するアクセス制御を行 34


62

っている

4パスワードの入力ミスが続いたユーザIDを使用停

止にしている

14

5使用停止となっているユーザIDの有無を定期的に

確認している

18

6ユーザIDの発行・再発行ルールがある 30

7パスワードの発行・再発行ルールがある 26

8全ユーザが定期的にパスワード変更を実施してい

る

17

9分からない 1

10その他 4

1-32 1社外からは社内にアクセスできない 9

2社内接続のID・パスワードと異なる社外接続のID・

パスワードを利用して接続する（ワンタイムパスワ

ード含む）

37

3ユーザID・パスワードをハードディスクに保存でき

ない設定にしてある

1

4社外からアクセスできる情報・システムに制限をつ

けている

23

5分からない 2

6その他 4

1 2 3 4 5 6 7 8

1-33 PCの構成変更＊にはどのような手続きが必要です

か。＊ソフトウェアのインストール、アンインストー

ル、メモリ、ハードディスクの追加、交換（1つ選択）

18 14 3 1 8 6 1 2

1-34 ネットワークの構成変更にはどのような手続きが必

要ですか。（1つ選択）

5 3 14 2 15 13 2 0

1-35 サーバの構成や設定の変更にはどのような手続き

が必要ですか。（1つ選択）

5 8 6 3 14 16 2 0

1-36 サーバのセキュリティを確保するためにどのように

して各種パッチを適用していますか。（1つ選択）

0 20 23 2 3 6


63

1-37 ソフトウェアのライセンス管理を実施していますか。

（1つ選択）

2 18 3 28 2 1

◎ ○

1-38 1ハードウェア 10 19

2ウイルスチェックソフト 36 12

3オペレーションシステム 16 15

4ワープロソフト 20 19

5表計算ソフト 20 19

6電子メールソフト 22 15

7インターネット閲覧ソフト 21 11

8社内ビジネスアプリケーション開発言語 3 7

9システム開発メソドロジー 2 8

10分からない 0 5

11その他 0 0

1-39 1個々人で独自に情報収集をしている 37

2法令変更・業界動向の確認部門・担当者等が決ま

っている

16

3収集すべき関連法規、関連業界がリスト化されて

いる

3

4定期的にチェックすべきインターネットサイトや雑

誌等の情報源がリスト化されている

7

5定期的に業界団体やベンダー等から担当者に情

報が来る

14

6分からない 4

7その他 4

1-40 1個々人で独自に情報収集をしているので会社とし

て告知をする体制はない

12


64

2社内掲示板や社内報など紙媒体で定期的に告知

している

5

3電子メールや電子掲示板等で新規情報が判明次

第告知している

34

4分からない 5

5その他 1

◎ ○

1-41 1安全対策事業所認定 6 0

2ISMS（BS7799） 3 14

3ISO 9000シリーズ 18 5

4ISO 14000シリーズ 14 4

5ISO/IEC 15408 0 5

6プライバシーマーク 9 4

7CMM（Capability Maturity Model） 1 8

8その他情報セキュリティ関連認証 1 2

9分からない 0 13

1-42 1未実施 14

2インターネット接続システム 16

3勘定系システム 7

4人事系システム 3

5全業務システム 9

6一部業務システム 11

7分からない 9

8その他 5

1-43 1未実施 19

2インターネット接続システム 21

3勘定系システム 2

4人事系システム 3

5全業務システム 1

6一部業務システム 5

7分からない 7


65

8その他 3

1 2 3 4 5 6

1-44 システム監査やペネトレーションテストの結果にど

のように対処していますか。（１つ選択）

15 6 4 8 18

1-45 情報セキュリティ関連予算はありますか。（１つ選

択）

4 7 29 5 5 3

1-46 1予算はない 4

2セキュリティ対策ハードウェア購入費用 36

3セキュリティ対策ソフトウェア購入費用 37

4セキュリティ対策ハードウェア保守費用 36

5セキュリティ対策ソフトウェア保守費用 38

6セキュリティ管理者教育費 10

7従業員教育・啓発活動費 6

8セキュリティ関連認証取得費 6

9セキュリティ関連認証維持費 4

10分からない 6

48

2VPN 35

3侵入検知システム（IDS） 24

40

5テスト環境 19

6社内LAN上でのサブネット構成の工夫 24

39

37

9全クライアントPCにウイルスチェックソフトを導入 46

10暗号化ツールの使用（S/MIME、PGP） 20

11ウイルスチェックを実施するインターネットサービ

スプロバイダの利用

5

12分からない 3

13その他 6

11その他 6

1-47 1ファイアウォール

4DMZセグメントの設置

7メールサーバでのウイルスチェック

8リモートアクセス用サーバ


66

1 2 3 4 5 6 7

2-1 情報セキュリティ関連の事故や事件が発生した

大の原因をご記入下さい。（1つ選択）

19 17 3 1 3 6

2-2 1事故・事件情報を記録していない 0

2風評被害 1

3誤操作によるデータの消失やシステムダウン 1

4コンピュータウイルス感染 24

5社外へのウイルスの流布（電子メール・FD等） 5

6社内外からの不正アクセス 0

7DoS攻撃等によるサービス停止 2

8社外公開ホームページの改ざん 3

9社内情報の漏洩や改ざん（インターネット掲示板

への書き込みなど）

1

11その他 0

2-5 1情報セキュリティ管理者は決まっていない 4

4情報システム部員がログ監視をしていて気がつい

た

27

5システム的な検査（Tripwire等）で警告が出た 18

6外部のネットワーク監視会社からの通報 8

7分からない 3

8その他 4

2-6 1社内の担当者の裁量で復旧作業を進めた 33

2業務継続計画等の規定に従い復旧作業を進めた 8

3ベンダーやコンサルティング会社の専門家主導で

復旧作業を進めた

5

4復旧作業に先立ち、作業に必要なコストの負担部

門が明確になっていた

2

5分からない 3

6その他 4

0

10分からない 4

2社員からの連絡 38

3社外の第三者（顧客・取引先等）からの通報 24


67

1 2 3 4

5 6

2-7 大規模な情報セキュリティ事故や事件の復旧を実

施できる人材が社内にいますか。（1つ選択）

23 6 1 4 1

2-8 情報セキュリティ事故や事件の発生後、従業員に

告知をしましたか。事故や事件が発生していない場

合には告知予定をご回答下さい。（1つ選択）

3 32 7 5 3

2-9 情報セキュリティ事故や事件の結果、社外に影響

が出た場合、社外に告知をしましたか。事故や事件

が発生していない場合には告知予定をご回答下さ

い。（1つ選択）

11 12 10

2-10 1実施していない 10

2社内担当者によるペネトレーションテストの実施 18

3外部の専門家によるペネトレーションテストの実施 7

4社内品質管理、監査部門によるシステム監査の

実施

3

5外部の専門家によるシステム監査の実施 2

6分からない 12

7その他 5

1セキュリティ関連文書の整理 33

2情報セキュリティを考慮した社内制度の制定 24

3情報システム部員のセキュリティ教育強化 23

4一般従業員のセキュリティ教育強化 38

5セキュリティ関連の認証取得 23

6セキュリティ関連認証取得システムの導入 15

7セキュリティ情報の収集

8システム監査の実施 26

9全従業員へのセキュリティ情報の提供 22

10事故・事件対応訓練 25

17

8 8

3-1

29


68

11サーバでのウイルスチェック 19

12クライアントでのウイルスチェック 14

13情報セキュリティのスキルを有する人材の採用 13

14ASP (Application Service Provider) や IDC

(Internet Data Center)の利用

7

15人材派遣の利用 0

16その他 4

3-2 1セキュリティ関連文書の整理 30

2情報セキュリティを考慮した社内制度の制定


4一般従業員のセキュリティ教育強化

5セキュリティ関連の認証取得 20

6セキュリティ関連認証取得システムの導入 12

7セキュリティ情報の収集 28


9全従業員へのセキュリティ情報の提供 23





14ASP やIDCの利用 8

2経営者の理解不足 5

3予算管理者の理解不足

5従業員の理解不足 20

6予算不足 20

7情報システム部員のスキル不足 14

8その他 10

22

36


16その他 5

3-3 1阻害要因はない 9

3

4クライアントの理解不足 4


69

3-4 1セキュリティに関する文書フォーマット（標準文書

形式）の制定

13

2業界・グループ共通の情報セキュリティ関連制度

の制定・改定

18

3情報システム部員向けセキュリティ教育の実施 14

4一般従業員向けセキュリティ教育の実施 17

5セキュリティ関連の認証取得の奨励活動 13

6セキュリティ関連認証取得システムの導入の奨励 10

7各社情報システム部門向けにセキュリティ情報を

発信

23

8システム監査の実施義務付け・奨励 15

9事故・事件対応訓練の制度化・奨励 13

10コンピュータウイルスチェック手順の制度化・標

準化

9

11情報セキュリティに関する情報を共有する仕組

みの整備

18

12システム関連業者（ASP やIDC）の選定基準の

制定

5

13その他 5


2経営者層の理解不足 11

3企業間の対立 9

4企業間での連絡体制の不備 17

5問題に対する共通意識の欠落 17


7予算管理者の理解不足 10

8予算不足 16

6

10情報セキュリティ管轄機関のスキル不足 9

11情報システム部門のスキル不足

12その他 10

9従業員の理解不足

11


70

1情報セキュリティ関連の文書整理の実施

3-6 16

2情報セキュリティを考慮した社内制度の制定 8


4一般従業員のセキュリティ教育強化 8

5情報セキュリティ関連の認証取得 10

6情報セキュリティに関する情報提供 22


8全従業員への情報提供 2





13ASPやIDCの利用 4


15その他 6


2経営者の理解不足 6

3予算管理者の理解不足 3


5従業員の理解不足 3

6予算不足 16

7情報システム部員のスキル不足 6

8受託先のスキル不足 6

12

9その他


71

3-8 1安価な情報セキュリティ教育の提供 24

2情報セキュリティ教育コンテンツの整備 23

3情報セキュリティの公共広告等啓発活動 18

4情報セキュリティ違反者の罰則強化 16

5システム監査の義務化 7

6政府調達を情報セキュリティ関連認証取得業者に

限定等、認証取得企業利用の奨励

8

7情報セキュリティに関する業界団体設立の推奨 5

8情報セキュリティに関する教育の義務化 9

9その他 1

3-9 1具体的な取組内容を知らない 17

2サイバーテロ、コンピュータウイルス等の犯罪対

策について積極的に対処している

7

3情報セキュリティ教育について積極的に対処して

いる

1

4欧米に比較して対処が遅れている 25

5一部のアジア諸国に比較して対処が遅れている 5

6その他

有

4-0 1W32/Hybris(ハイブリス) 0

2W32/Badtrans(バッドトランス) 5

3W32/Sircam(サーカム) 4

4W32/MTX(エムティエックス) 1

5W32/Magistr(マジストラ) 0

6W32/Aliz(アリズ) 2

8W32/Nimda(ニムダ) 16

9X97M/Divi(ディビ) 0

10W32/Navidad(ナビダッド) 3

3

7XM/Laroux(ラルー) 5


72

11W32.CodeRed（コードレッド） 13

13誤操作によるデータの消失やシステムダウン 7

15社内外からの不正アクセス 0

16DoS攻撃等によるサービス停止 2

17社外公開ホームページの改ざん 2

18社内情報の漏洩や改ざん 0

19その他 7

12風評被害 2


73

(４－ａ項目以降)

被害

コード

番号

発生

月日

復旧

原因復旧員へ所要

日数

社内・復旧に要した作

業量

社外・復旧に要した

作業量

社内・復旧に要した

費用の概算

発生事故

実施

の人

材

従業

の告

知

社外

への

告知

2 1 1人 0.5人工 2万円程 4 1 2 1

2 12/1 0.5 0.5人日０．５日×３万円＝

１．５万円

2 1 1 5

2 12/14 1 １名×４時間、40名×

1時間

40名×1時間×

5000円＝200000円

1名×0.5日×４００

００＝20000円、計

22万円程度

4 2 1 5

2 11/29 2 2 5 1 感染したPCを再ｲﾝｽﾄ

ｰﾙ。１日程度。１人

×1.5日

2

11/26 1 再インストール。１日

×１名。OutLook経

由。他と同じPC(外部

委託者)

３万程度

7/24 1 感染の有無調査及び

感染ＰＣの対策５名

×１日５人日

2 1 2

3 10/6 2時間（PCの初期化と

再ｲﾝｽﾄｰﾙ）

人件費として8000

円程

2 1 2 5

3 10/23 9 状況把握・監視：０．３

人日×９日＝２．７人

日

3 2 状況把握・監視：

０．５人日×９日＝

４．５人日、復旧作

業：０．５人日×１０

日＝５人日

(社外：４．５万×９．

５人日＝５０万円)

2

5 10/1 1 4 3人×1日（復旧）＋

300名×1時間＝324

時間

324時間×5000円

＝162万円

2 2

6 11/21 1 念のため、再インスト 2 2 5 １日×１名。３万円 4

2 4

3 なし５人日×４万＝２０

万円

1


74

ール。1日×１名。

WinMe。OutLook経

由。他と同じPC(外部

委託者)

程度

7 全体でバスターを

チェックする作業量

500台×10分

1 5 ウィルス駆除ツール

のインストールとチェ

ックを全社に要請

500台×１０分

6 2

１人 5

3 なし 4 1 2 5

10人越える人数で、

感染PCの対処、２H、

セグメント落とさなか

った。手順も決めてい

なかった。

10人×２H×2/8×

15万＝７５万～１５

０万位

3 5

8 9/19 2 2 ６２０名、対策本部設

置し全国１６０ヶ所の

復旧

約6千万円(人件

費、他は会計シス

テムのﾊﾞｯｸｱｯﾌﾟ)

6 2

8 9/26 0.5 ネットワークから切り

離し、ＯＳの再インス

トールを実施。１名×

0.5日程度の作業量

0.5人日程度の作業

量であり、人件費と

しては９千円程度。

6 1 2 5

8 9/17 0.5 復旧対象マシンのネ

ットワークからの切離

し、再インストール作

業（50名×1日程度の

作業量）

無し 1 150万円程度 2 2 5

2 社員より被害の確認・

処置 20名×0.5

20名×0.5日程度の

作業があり、人件

費としては32万円

4 2 5

7 6 1 2

7 EXCELでのﾏｸﾛ使用

禁止連絡、ﾗﾙｰｳｨﾙｽ

専用ﾁｪｯｸﾂｰﾙの組込

手順作成と全店への

導入連絡（２名×２

日）

６万円

8 7/1 0.08 2 1

8 9/19 1


75

程度

社内3名で2時間で対

応

無人件費12万程度 6 2 5

8 11/6 2 2名×2日／感染ﾌｧｲ

ﾙの除去

2名×2日／人件費

として10万円程度

2 1 2 5

8 150台×２h、３名×３

日

6 1 2 5

8 9/19 2 2 1 2 5

8 9/1 7 ２０人×１日不明 6 1 2 2

8 9/19 3 状況把握・対応協議：

３日人×３日＝９日人

調査：０．２日人×140

台＝２８日人

対策：１日人×５０

台＝５０日人

(社外：４．５万×５０

日人＝２２５万円)

3 3 2

8 9/19 2 ﾈｯﾄﾜｸ管理者２～３

名が、２日間かけて

再ｲﾝｽﾄｰﾙ。

実動費として２０～

３０万円。

4 1 2 5

8 9/1 3 全機器でパッチ対

策、ネットワーク構成

の変更等、資産洗い

出し、ウィルス調査・

報告等、情シス部門

のみ４名×5日

4人×5日×5000円

×８ｈ＝８０万円

他

2

全社PCとサーバの

対策費

2 2 5

8 12/21 人件費1万5千円ほ

ど

1 PCの初期化、再イン

ストール

2 1 2 5

8 9/19 6 発生から復旧まで６

時間の作業量

2 2 3

8 10/1 IT側・６名＊１０日程

度

ユーザー側不明

無不明 5 2 2 2

8 9/2 0.5 ３名×０．５日＝１．５

人日

１．５人日×４万＝

６万円

4 1 2 5

1/15 1 原因調査、ウィルス

駆除、取引先連絡

等、５名×１日程度

2 2 2 4

8 10/1 1 2

10 ウィルス駆除１００

名×１日程度、アド

レス帳での駆除の

手間

人件費１５万円程

度


76

10 8/29 1 2 1 2 5 夕刻に発生。３時間

で復旧

10 1/9 社員によるウイルス

駆除 2名×0.2程度

1 0.5 2名×0.2程度の作

業人件費は1.5万

円程度

3 2 5

２～３万円 6 2 2

11 8/23 1 ３名×１ 1 2 ９万円 6 2

9/20

11 8/1 0.5 １０人ぐらいで、感染

PCに対処、半日(数

台はOS入れ替えなど

でも復旧できなかっ

た。)

10人×４H×4/8×

１５万＝300万

本社、甲府等でネッ

トワークを停止した

1 5 3

8/6 0.5 2

0.5 ネットワークから切り

離し、ウイルス対策ソ

フトでウイルスを駆

除。１１名×0.5日程

度の作業量

2

対策マシンをネットワ

ークから切離し、再イ

ンストール作業を実

施（50名×3日の作業

量）

450万円程度 2 2 5

1500台×２h 6 1 2

11 8/6 2 2 2 1 5

11 9/1 7 ２０人×１日 2 2 不明 6 1

11 8/19 2 ﾈｯﾄﾜｰｸ管理者＋

数人が２日間で再設

定。

１００万円前後の稼

動費

4 1 2 5

9/1 3 調査、対策、再インス 4人×5日×５，００ 2 2 2 5

11 7/1 0.5 再インストール 1/2

日

5

11 2 社員による復旧。３名

×２日

３名×２日の作業

量。１８万程度

2

11 感染ﾏｼﾝの調査・対

策５００人×１日

５００人日

なし５００人日×４万＝

２０００万円

4 2 5

11 8/28 １１名×0.5日程度

の作業量であり、人

件費としては９万９

千円程度。

6 1 5

11 8/6 3 無 1

11 5

11


77

トール等 4人×5日

他全社員の作業

０円×８ｈ＝８０万

＋全社員の作業時

間

7/31 2 状況把握・対策：１人

日×１０日＝１０人日

3 1

12 1 ２人×１日 2 1 2 1

13 12/26 徹夜作業にて再イン

ストール。翌日早朝に

復旧。４名×１日程度

なし人件費として２０万

円程度

6 1 3 5

13 1 2人×1日＝16j間１６×@5000円＝

80000円

6 2 2 5

10/1 0.04 １人で１H、IISがやら

れた、代理店向け

Webサイトが中国語

になっていた。

１H×1/8×１５＝2

万円

1 1 5

11

17 2


78


79

8.3 参考資料３：アンケート用紙

別紙

Ver. 1 - ipa.go.jp · Ver. 1.0 情報処理振興事業協会 セキュリティセンター ... 5.3.1 経営サイドから見た必要性、プライオリティの設定.....23

Documents

Ver. 1 - ipa.go.jp · Ver. 1.0 情報処理振興事業協会セキュリティセンター ... 5.3.1 経営サイドから見た必要性、プライオリティの設定.....23