Copyright

(1)

情報セキュリティセミナー 2004

組織的取り組みと

情報セキュリティマネジメントシステム

1. リスクアセスメント

2. 情報セキュリティポリシー

3. 従業員の教育、委託先との関係

(2)

１．リスクアセスメント

- リスクアセスメントはなぜ必要か？

- リスクアセスメントとは

- リスク分析手法（リスクの識別と評価）

ベースラインアプローチ

詳細リスク分析

組み合わせアプローチ

(3)

リスクアセスメントはなぜ必要か？

リスクアセスメントをしないと…….

・事が起こってから慌てて対策する。

・場当たり的な対策に終止してしまう。

・組織のどこにリスクが潜み、

何を優先的に対策してよいかわからない。

・限られた対策予算を効果的に使えない

・全体を見通した対策ができない。

組織の危機管理に問題が生じる

(4)

リスクアセスメントの効果

リスクアセスメントを行うと…….

・組織のどこにどんな脅威が存在するか把握できる。

・組織の中に潜む脆弱性が把握できる。

・組織に対するリスクの全容が理解できる。

・組織にとって影響度の高い脅威が何かを把握でき、

何を優先的に対策してよいかわかる。

・限られた対策予算を効果的に使える。

・全体を見通した対策ができる。

(5)

リスクアセスメントとは

リスク分析からリスク評価までのプロセス

リスク因子＝脅威と脆弱性をリスク因子と呼ぶ

リスクは様々なリスク因子の関係により発生する

例：設定不備（脆弱性）を突かれて不正アクセス（脅威）される

リスクアセスメント

リスク分析

リスク因子を特定する

リスクを算定する

リスク評価

脅威

：システム又は組織に危害を与える事故の潜在的原因

脆弱性

：脅威によって影響を受ける内在する弱さ

(6)

リスク分析手法

(1)ベースラインアプローチ

ベースライン（自組織の対策基準）を策定し、適用する。

(2)非形式的アプローチ

コンサルタント又は組織や担当者の経験、判断により評価

(3)詳細リスク分析

詳細なリスクアセスメントを実施。情報資産に対し「資産価

値」「脅威」「脆弱性」「セキュリティ要件」を識別、評価

(4)組合せアプローチ

複数のアプローチの併用

(7)

ベースラインアプローチ

既存の標準や基準をもとにチェックしていく

・情報資産毎にリスクを評価しない。

・情報セキュリティに関する基準やガイドラインを

利用し、自組織で実現可能な管理策を採用する。

【参照する標準やガイドラインの例】

ISO/IEC17799の管理策（127項目より取捨選択）

セキュリティ対策セルフチェックシート

http://www.ipa.go.jp/security/ciadr/checksheet.html

ウイルス対策チェックシート

http://www.ipa.go.jp/security/virus/beginner/check/check.html

(8)

ベースラインアプローチ

ベースラインアプローチの手順

・ベースラインの決定

基準などを参照して自組織の管理策を決定

・ギャップ分析の実施

採用した管理策への準拠状況を把握する

【長所と短所】

長所：チェックリストやアンケートにより、手軽にリスク分析ができる

アンケート形式で進めると、手軽に規定を浸透させられる

(9)

詳細リスク分析

組織内の情報資産の綿密なリスク分析を行う

・情報資産を洗い出し、資産毎にリスクを評価する

・資産毎の脅威と脆弱性を識別し、リスクを定量化する

資産が攻撃者にとってどの程度魅力的か、資産が

失われた場合の被害額なども想定（重要度・発生確率）

【長所と短所】

長所：全ての情報資産に対し、適切な管理策を採用できる

リスク分析の精度も高く、数値化するためリスクを

定量的に量れる（但し、数値だけに頼るのは危険）

短所：リスク分析の結果を得るまで、手間と工数がかかる

(10)

詳細リスク分析のプロセス

リスクアセスメント

リスク分析

1.リスク因子を特定する

情報資産の洗い出し

脅威・脆弱性の明確化

2.リスクを算定する

事業上の損害の評価（ CIAの観点からの評価）

脅威・脆弱性の評価（高・中・低のレベル付け）

リスク値の算出

詳細リスク分析

(11)

(1)資産目録の作成

管理責任者、資産の形態、保管場所・期間、用途等

(2)情報資産の例（JIS X 5080:2000による）

–

情報資産（DBおよびデータファイル等）

–

ソフトウェア資産（業務用ソフト、システムソフト等）

–

物理的資産（コンピュータ、通信装置等）

–

サービス

(3)情報資産のグループ化

分析作業の負担軽減、効率化が目的

–

情報資産価値や属性が一致するものをまとめる等

情報資産の洗い出し

(12)

脅威・脆弱性の明確化

(1)脅威の識別

(a)人為的脅威

• 意図的脅威：盗難、盗聴、通信への侵入、ソフトの不正使用等

• 偶発的脅威：操作ミス、ソフトの故障、回線の損傷等

(b)環境的脅威：地震、洪水、落雷、停電、静電気等

(2)脆弱性の識別

分類例

(a)環境、施設：不安定な電源設備等、災害を受けやすい立地条件等

(b)ハードウェア：記録媒体のメンテナンス不足等

(13)

リスクアセスメントの実施

(1)事業上の損害の評価

情報資産の機密性、完全性、可用性が損なわれた時の事

業上の影響を評価

(2)脅威および脆弱性の評価

３段階評価が多い

(3)リスク値の算出（リスク算定）

計算例：リスク値＝情報資産の価値×脅威×脆弱性

(4)リスク評価

リスク値とリスク評価基準（受容可能なリスク水準）を比較

(14)

36

24

12

24

16

8

12

8

4

27

18

9

18

12

6

9

6

3

18

12

6

12

8

4

6

4

2

9

6

3

6

4

2

3

2

1

3

2

1

3

2

1

3

2

1 資産価値

ぜい弱性

3

2

1 脅威

リスク値の算出：リスク早見表例

(15)

GMITS（ISO/IEC TR13335）にあるプラ

イオリティ付けの方法論

8

7

6

7

6

5

6

5

4

7

6

5

6

5

4

5

4

3

6

5

4

5

4

3

4

3

2

5

4

3

4

3

2

3

2

1

4

3

2

3

2

1

2

1

0

0 資産の

価値

高

中

低

高

中

低

高

中

低

脆弱性の程度

高

中

低

脅威の程度

リスクの程度

「資源の価値」とは、保護対象の資源に対するセキュリティ問題発生時の影響度合いであり、

言い換えるとビジネスインパクトとでも言うべきものである。数値が4になると顧客情報や企業

秘密情報などが対象となり、漏洩や破壊などされた場合には企業活動そのものに影響を及ぼ

すものである。

「脆弱性の程度」とは、資源に対するセキュリティ問題発生の可能性であり、どの程度保護対

策がなされている状態であるか評価する。

(16)

組合せアプローチ

ベースラインアプローチと詳細リスク分析を併用

・最初に上位レベルリスク分析（概要レベルの分析）を

行い、各資産についてどのアプローチを行うか決める。

・上位レベルリスク分析の結果、重要度・リスクが高いと

判断された情報資産にのみ詳細分析を適用する。

【長所と短所】

長所：作業や工数の適正化が行われる（詳細な分析が必要なもの

には工数・時間をかけ、それ以外はベースラインで行う）

(17)

リスク対応

(1)適切な管理策の採用

・リスクの発生の可能性を低減させる

・リスクが顕在化した場合の影響度を低減させる

例：ファイアウォールの設置、暗号化装置の採用、社員への教育等々

(2)リスクを保有する

・識別され受容されるリスク：リスク保有の対象となるリスク

→ リスクの度合いが低いため、対策をしなくてよいと判断したリスク

・識別されず組織内に内在するリスク（未知のため対象外）

(3)リスクを回避する

業務の廃止、情報資産の破棄等リスクを生じさせる原因を排除する

(4)リスクを移転する

契約等によりリスクを他者（他社）に移転

(18)

２．情報セキュリティポリシー

- 情報セキュリティポリシーのモデル

- 情報セキュリティポリシー文書構成例

- 情報セキュリティポリシー策定の留意点

-

「情報セキュリティ基本方針」項目例

-

「対策基準」の項目例

-

「実施手順」

(19)

組織が所有する情報資産の情報セキュリティ対策

について、

総合的

，

体系的

，

具体的

にまとめたもの。

組織としての

基本的考え方

や情報セキュリティを確

保するための

体制

，

組織

，

運用

を含めた規定。

◆情報セキュリティを守るためには、

・単なる技術的対策だけでは、不十分。

・

人の問題

、

環境の問題

など

管理面の対策

も重要

・

組織として意思統一

され、

明文化された文書

情報セキュリティポリシー

(20)

情報セキュリティポリシーのモデル

情報セキュリティを確保する

ために遵守すべき規定

基本方針

（基本ポリシー）

対策基準を実施するための

情報セキュリティ対策に対す

る基本的な考え方

（組織の情報セキュリティに

対する取り組み姿勢を示す）

セ

キ

ュ

リ

テ

ィ

ポ

リ

シ

ー

対策基準

（スタンダード）

(21)

情報セキュリティポリシー文書構成例

階層

規定文書

基本方針

情報セキュリティ基本方針

対策基準

情報セキュリティ組織運営基準

電子化情報管理基準

情報システム運用基準

情報システム開発基準

物理的セキュリティ基準

外部委託基準

情報セキュリティ監査及び点検基準

情報セキュリティ緊急時対応基準

情報セキュリティ倫理基準

実施手順

ファイアウォール設定

データベースアクセス設定

(22)

情報セキュリティポリシー策定の留意点

• リスク分析

–

情報資産の整理

–

想定される脅威の整理、重要度付け

–

保護対策の選定

• 策定チームの体制

◆何をどこまで守るのか（対象範囲の明確化）

◆誰が責任者か

(23)

情報セキュリティポリシー策定の留意点

• 文書化

–

網羅性

を確保する

–

既存

の管理

規約

、就業規則等

との整合

–

物理的な状況(組織の地理的な配置等)

• バランス

–

使いやすさとセキュリティ

(24)

• 総則

–

目的、定義、関連規約、経営者の声明(方針)

• 情報資産の管理

–

情報資産の分類及び管理、情報資産へのアクセス

• 組織内情報システム

–

基本方針の遵守、外部委託

• 運用管理体制

情報セキュリティポリシー策定の留意点

「

情報セキュリティ基本方針

」の項目例

(25)

• 目的

–

当該対策基準の目的

• 対象者、対象組織、体制

–

当該対策基準を遵守する対象者

–

当該対策基準を行うのに必要な体制

• 対象業務、対象システム

• 遵守事項、禁止事項、推奨事項

情報セキュリティポリシー策定の留意点

「

対策基準

」の項目例

(26)

• セキュリティポリシーの策定体制

• セキュリティポリシーの運用体制

• セキュリティポリシーの見直し

• セキュリティポリシーの啓発・教育

情報セキュリティポリシー策定の留意点

情報セキュリティ組織運営基準

(27)

• アクセス権限

• 保管、持ち出し

• 廃棄

–

委託の場合、特に注意

• 複製

–

必要以上の複製を禁止

–

消失対策としてのバックアップ作成は義務

• 紛失は起こりえるという前提での対策

–

暗号化

情報セキュリティポリシー策定の留意点

電子化情報管理基準

(28)

• ネットワーク接続機器（サーバー・端末）

• ユーザ管理、ユーザ認証（ログイン）

• 離席時対策（スクリーンセーバ）

• パソコン持ち出し

• ネットワーク構成管理

• 外部ネットワーク接続

情報セキュリティポリシー策定の留意点

情報システム運用基準

(29)

• 情報システムの企画・設計

–

セキュリティターゲット

• 開発、導入

• 調達

–

製品評価認証(ISO/IEC 15408)

• 検査

情報セキュリティポリシー策定の留意点

情報システム開発基準

(30)

• 地震、火災、水害など災害対策

• 停電対策

• 盗難防止のための入退室管理

• 無線LAN等のネットワーク接続

• 電磁波漏洩対策（テンペスト対策）

• データセンター等外部委託先も対象

情報セキュリティポリシー策定の留意点

物理的セキュリティ基準

(31)

• 業者選定

• 契約

• 再委託

• 監査・検査

情報セキュリティポリシー策定の留意点

外部委託基準

(32)

• 内部監査

–

組織の独立性

–

権限

• 外部監査

• 計画、実施、報告、改善

情報セキュリティポリシー策定の留意点

情報セキュリティ監査及び点検基準

(33)

• 組織・体制

–

インシデント対応組織

–

責任者

–

連絡体制

• 被害の拡大防止

• 原因究明と再発防止

情報セキュリティポリシー策定の留意点

情報セキュリティ緊急時対応基準

(34)

• 守秘義務

• パスワード管理

• ID共用

• 私的利用（メール、ｗｗｗなど）

• 著作権侵害

• 法令等の遵守

情報セキュリティポリシー策定の留意点

情報セキュリティ倫理基準

(35)

• 不要な個人情報収集の禁止

• 目的外使用の禁止

• 保有個人情報の把握

• 漏洩対策

• 廃棄

• 開示要求・訂正要求

• 委託先も対象

情報セキュリティポリシー策定の留意点

個人情報保護基準

(36)

• 部署毎に作成

• 具体的な手続き、用紙

• 承認権限

• チェックリスト活用

• 業務やシステム変更時の見直し

情報セキュリティポリシー策定の留意点

「

実施手順

」

(37)

• 運用の体制

–

周知徹底

–

実施状況について情報収集

• 情報収集の自動化

• 例えば、パスワード定期更新状況

• ソフト更新の集中管理

• 定期的な見直し

–

実施状況や監査結果により検討

情報セキュリティポリシー運用の留意点

(38)

情報セキュリティポリシー運用体制例

監査部門

・運用状況の評価

・見直しの提言

監査部門

・運用状況の評価

・見直しの提言

セキュリティ管理部門

・全社セキュリティ管理の統括

・セキュリティポリシーの運用・管理

セキュリティ

管理部門

・全社セキュリティ管理の統括

・セキュリティポリシーの運用・管理

経営者(セキュリティ担当役員)

・ポリシーの承認

経営者

(セキュリティ担当役員)

・ポリシーの承認

システム部

部長

AAAシステム課

システム部

部長

AAAシステム課

XYZ部

部長

セキュリティ

XYZ部

部長

セキュリティ

ABC部(ユーザ部門)

部長

セキュリティ担当者

ABC部(ユーザ部門)

部長

セキュリティ担当者

(39)

監査

• 内部監査

–

組織内部の監査部門

–

被監査部門との独立性

• 外部監査

–

専門の監査会社

–

情報セキュリティ監査

• どのレベルか評価

–

ISMS認証

• セキュリティポリシーが遵守されているか

• ヒアリング、システムログ調査

• 脆弱性検査

• 指摘、改善、報告

• 委託先企業の監査

(40)

３．従業員の教育、委託先との関係

-

従業員の教育

-

委託先との関係

(41)

従業員の教育

• 全ての従業員が対象

–

派遣社員、アルバイト、管理職、役員も対象

• 教育のタイミング

–

新人研修（中途採用も）、OJT

–

異動時研修（業務が変わった場合）

–

再教育（守ってないことが発覚時）

–

ルールの変更時

• セキュリティポリシーと実施手順は、いつでも

(42)

従業員の教育

• 意識改革

が難しい

• 守らなくても大したことはないと考える人

–

過失：自分は大丈夫

–

故意：不正をしても、見つからない

• 守らなかった場合の最悪の結果を示す

–

組織の被害（信用失墜、売上減少、損害賠償）

–

従業員の給料カット、個人の評定ダウン

(43)

従業員の教育

• 守る風土つくり

–

互いに注意し合う

–

上司が率先して守る

–

軽微な不正／小さなルール違反でも注意

–

管理部門からではなく、上司から注意

• 守らない人が多いと上司の監督不足

• 守らない原因を分析する

–

(例)守ると成果が出ず自分の評価が悪くなる？

• ⇒ルールの見直しまたは成果目標の見直し

(44)

従業員の教育

• 守らせるには、

意識の向上

と共に、関連する

知識の向上

も重要

–

「情報セキュリティ読本」を活用

–

資格制度の活用

• ウイルス情報や脆弱性情報などのうち、緊急

に対処すべき事項をメールなどで周知徹底

• 繰り返すことで、当たり前になる

(45)

委託先との関係

• 脅威の整理

–

アウトソーシング業務のリスクアセスメント

–

セキュリティターゲット

• 委託先業者の選定基準

–

プライバシーマーク取得

–

技術水準

–

経営状況

–

管理体制

(46)

委託先との関係

• 委託契約に盛り込む内容

–

セキュリティポリシーの準用

–

守秘義務

–

運用状況の検査に応ずる義務

–

損害賠償責任

–

情報セキュリティの意識の啓発および教育

–

個人情報保護の意識の啓発および教育

–

再委託の禁止又は制限

(47)

委託先との関係

• 連絡体制（特に障害時や緊急時）

• 情報管理責任者

• 内部統制

–

ルール

–

教育

–

体制

• 報告

(48)

委託先との関係

• 派遣者への権限を必要最小限に

• 開示／提供する情報資産は必要最小限に

• 開示／提供の事前承認、記録(日時、担当

者）、返却時の記録

• 監査

(49)

Do

PDCA

サイクルによる

スパイラルアップ

継続的改善

Plan

Check

Act

ポリシー

作成

計画

実装及び

運用

監視・監査

代表者によ

る見直し

ISMS：情報セキュリティマネジメントシステム

出典：(財)日本情報処理開発協会

(50)

まとめ

• 情報セキュリティマネージメントは、

リスクアセ

スメント

で、

何をどこまで守るか決め

、

• セキュリティポリシー

で

対策を明文化

し、

• それを

教育

で

従業員に周知徹底

し、

• 委託先

にも

契約で準用を義務づけ

、

• 監査・点検

し、

(51)

情報セキュリティセミナー 2004

企業の体験談から学ぶ：

対策の現状や被害事例など

注：会場により、「企業の体験談」もしくは

「情報漏洩事件・事例検証」のいずれかの講演を行います。

本資料は、会場配布資料のみに含まれます

(52)

情報セキュリティセミナー 2004

情報漏洩事件・事例検証

注：会場により、「企業の体験談」もしくは

「情報漏洩事件・事例検証」のいずれかの講演を行います。

(53)

情報セキュリティセミナー 2004

コンプライアンス：個人情報保護法等の

法令・標準・制度への対応

1. 個人情報保護法

2. 不正アクセス禁止法

3. 不正競争防止法

4. ISO/IEC17799とISMS適合性評価制度

5. ISO/IEC15408と情報セキュリティ評価・認証制度

(54)

法的なリスク

• 負けるとお金を払わなければならないことが

ある（民事訴訟）

• 警察に逮捕されることがある（刑事事件）

–

不起訴になったりもしますが

• 罰金になることもある（刑事事件）

(55)

法的なリスクも変化している

• 能動的な犯罪行為が処罰される対象だった

が・・・

• 管理責任を怠っていると処罰されてしまう

–

個人情報保護法

• 管理責任を怠っていると助けてもらえない

–

不正アクセス禁止法

• 管理責任のハードルがけっこう高い

–

不正競争防止法

(56)

個人情報保護法

• 個人情報取扱事業者の管理責任範囲を規定した法律

• 2005年4月から本格施行

• 個人情報取扱事業者は個人情報を5000件以上持っている

と誰でもそうみなされる可能性がある（6ヶ月保有）

• 「個人情報データベース等を事業の用に供しているもの」

（第2条）

• ここで言う個人情報とは、「氏名、住所、電話番号、画像や

音声データ、メールアドレス」を最小限とするもの

• 「事業の用」というのは社会的事業に反復して使っている、と

いうことを指す

• メーリングリスト管理者も個人情報取扱事業者とみなされる

(57)

個人情報保護法の要求

• 適切な取得方法

–

利用目的を偽るのはダメ

–

情報の持ち主が知らないうちに勝手に取得してはダメ

• 利用範囲の明示

–

違う目的で利用してはダメ（上と同じ）

• 第三者利用についての方針明示

–

勝手に誰かに渡してはダメ

• 持ち主要望への対応方針の明示

–

持ち主の開示、利用停止の要求には応じなければダメ

–

手数料を法外にしてもダメ

(58)

個人情報保護法の要求2

• 安全管理措置

–

いわゆる情報セキュリティ対策

–

データベースサーバの保護

–

紙の書類の保護

• スタッフの管理

–

セキュリティポリシーなどの整備

• 委託先の管理

(59)

関係条文

• (1)利用目的の特定、利用目的による制限（15条、16条）

• (2)適正な取得、取得に際しての利用目的の通知等（17条、

18条）

• (3)データ内容の正確性の確保（19条）

• (4)安全管理措置、従業者・委託先の監督（20条∼22条）

• (5)第三者提供の制限（23条）

• (6)公表等、開示、訂正等、利用停止等（24条∼27条）

• (7)苦情の処理（31条）

• 漏洩させたら責任を問われる

(60)

情報を管理する側とのかかわり

• 個人情報取扱事業者として、要求されるス

ペックに応える管理を行う責任が生じる

–

個人情報取扱事業者に、管理を委託される側と

しても同様

• 個人情報取扱事業者として、運用委託先を

管理する責任が生じる

(61)

法律の要求に応える

• オーソドックスなセキュリティ対策（技術的な

もの）

–

情報が存在するコンピュータ、通信路の防護

–

情報の操作記録を取る

• 人の管理

–

セキュリティポリシー、ルール、ワークフロー

–

契約

(62)

オーソドックスなものが最も難しい

• 社員はいろいろな仕事場所で、いろいろな立

場のスタッフと協力して、いろいろなコン

ピュータ、装置を使いながら仕事をする

• 管理者は多様化するリスクを管理しなければ

ならない

–

これはもはや「セキュリティの管理者」だけの問

題ではありえない

(63)

委託先の管理

• 委託先の業務にどこまで干渉するのか？

–

契約（秘密保持契約、一般的な業務委託契約）

–

監査（業務の監査、成果物の監査など）

• 認証制度の利用による監査の省略（ISMSなど）

–

口頭試問？

(64)

情報の持ち主の要求に応える

• 情報の持ち主は、個人情報取扱事業者に対して以

下の要求をすることができる

–

開示

–

誤りの訂正

–

使用停止

–

利用形態、範囲の訂正

• システム上、こうした要求に応じる「機能」が必要

• 持ち主は外部の利用者にとどまらない。社員も個

(65)

不正アクセス禁止法

• 2000年2月から施行

• 不正アクセスを禁じている

• 不正アクセスの幇助も禁じている

• 基本はIDとパスワード、バッファオーバーフロー攻

撃

• 条文：

http://www.ipa.go.jp/security/ciadr/law199908.html

• 逐条解説：

http://www.tohoku.ac.jp/TAINS/news/st-news-21/2640.html

(66)

「不正アクセス」とはどういうものか？

• アクセス制御機能のあるコンピュータに対し，他人の識別符

号を入力して，制限されている利用を可能にする行為（３条

２項１号）。

• アクセス制御機能のあるコンピュータに対し，特殊な情報又

は指令を入力して，制限されている利用を可能にする行為

（３条２項２号）。

• ネットワークで接続された他のコンピュータのアクセス制御

機能によって利用が制限されているコンピュータに対し，特

殊な情報又は指令を入力して，制限されている利用を可能

にする行為（３条２項３号）。

•

(67)

http://www.tohoku.ac.jp/TAINS/news/st-news-不正アクセス禁止法に

保護してもらうためには

• アクセス制御機能で防護されている必要がある

–

ネットワークに接続されていて、IDとパスワードで防護さ

れている状態のこと（2条3項）

–

しかし、IDとパスワードがあまりにも簡単だと、保護しても

らえない可能性もある

• 管理者アカウントIDとパスワードがしっかり付与さ

れたWebサーバーに置かれた特定のファイルを見

ることは、不正アクセスにあたるのか？

–

見方に拠るが・・・。CGI経由のアクセスなどは、「アクセ

ス制御機能を回避した」と言えるのか？

(68)

不正アクセス禁止法に

保護してもらうためには２

• そもそも不正アクセスされたのかどうか、検

知できなければ話にならない

• 不正アクセスを検知するには

–

複数のログ取得が基本

• 侵入検知システム（IDS）、ファイアウォールなど、シス

テムのログに頼らない仕組みが不可欠

–

細工できないログ取得

–

ハニーポット系技術、セキュアOS系技術の援用

(69)

不正アクセス禁止法違反に

ならないためには

• 不正アクセス禁止法違反というのは「形式犯」

–

形式が成立した時点で違反となる

• 違反とされる可能性が高い事例

–

他人のIDとパスワードを管理者以外から聞いてログイン

–

他人のIDとパスワードを探ろうとした、探り当てた

–

バッファオーバーフロー攻撃

• 違反とされるかどうか微妙な事例

–

WebサーバーCGIの弱点の利用

–

WebのURLに出てくるパラメタの操作

(70)

不正競争防止法

• 平成１５年５月２３日に交付、平成１６年１月１日から施行さ

れた改正部分で、不正アクセス行為による情報窃盗がカ

バーされた

• 第14条次の各号のいずれかに該当する者は、３年以下の

懲役又は300万円以下の罰金に処する。

• 3．詐欺等行為（人を欺き、人に暴行を加え、又は人を脅迫

する行為をいう。以下同じ。）により、又は管理侵害行為（営

業秘密が記載され、又は記録された書面又は記録媒体（以

下「営業秘密記録媒体等」という。）の窃取、営業秘密が管

理されている施設への侵入、不正アクセス行為（不正アクセ

ス行為の禁止等に関する法律（平成11年法律第128号）第

３条に規定する不正アクセス行為をいう。）その他の保有者

(71)

不正競争防止法に

保護してもらうためには

• 「営業秘密」の要件

–

①秘密管理性（秘密として管理されていること）

• 当該情報にアクセスできる者を制限する（アクセス制限）とともに、

同情報にアクセスした者にそれが秘密であることが認識できるこ

とが必要である（客観的認識可能性）。

–

②有用性（事業活動に有用な情報であること）

• 例えば、保有することにより経済活動の中で優位な地位を占め

ることができるような情報であること。（なお、失敗に関する情報

など潜在的な価値のある情報や、将来の事業に活用できる情報

も含む。）

–

③非公知性（公然と知られていないこと）

• 既存の書物・学会発表等から容易に引き出せない情報であるこ

と。

(72)

不正競争防止法の「営業秘密」と

認められるためには

• （１）アクセス制限

–

①アクセス権者の限定

• 情報毎の秘密レベルに応じて

アクセス権者を限定。

–

②アクセス権者の使用・開示の

範囲の限定

• 特定の場所からの持出禁止等。

–

③アクセスの履歴の記録

• 電磁的記録へのアクセス記録

のモニター等。

• （２）情報の形態ごとの管理

–

①記録媒体の管理

• 【保管時】特定の管理者が施

錠等をして保管。

–

②情報自体（無体物）の管理

• 【保管時】パスワード管理

の徹底等。

• 【廃棄時】コンピュータ廃

棄時に電磁的記録を消去。

• （３）施設等の管理

–

①建物・事務所・研究所のセ

キュリティ

• 警備員の配置、ICカードや

指紋による本人確認等。

–

②部門の設置等

• 社内に独立した営業秘密管

(73)

情報セキュリティに関する標準化動向

• BS7799(1995 英国)

• ISO/IEC 17799(2000/11)

• JIS X 5080(2002/2)

• 情報セキュリティポリシーに関するガイドライン(2000/7)

• ISMS認証基準（2002/4

日本情報処理開発協会

）

• 情報セキュリティ監査基準(2003/4)

• ISO/IEC 15408(1999/12)

ISO/IEC17799とISMS適合性評価制度

(74)

BS7799:1995

1998年に２部構成化

（第１部：規範、第２部：仕様)

ISO/IEC 17799

1995年英国規格

BS7799-2:1998

BS7799-1:1998

2000年に国際規格化

2002年に改訂

ISO/IECの規格として

現在標準化作業中

現在改訂作業中

BS7799-2:2002

BS7799、JIS X 5080、ISMS認証基準

ISO/IEC17799とISMS適合性評価制度

(75)

相互承認（CCRA)

CCの成立ち

1999：6月に国際規格(IS)として承認。

12月発行。

ISO/IEC 15408

V1.0：1994

V2.0：1998／V2.1：1999

CC

(Common Criteria)

米加英仏独蘭

国際的な市場

↓

評価基準統一の

必要性

商用への適用の広がり

(ISO/IEC JTC 1／SC 27／WG 3へ提案)

TCSEC

(Orange Book)

1985

ITSEC

1991

欧州各国ごと

の評価基準

CTCPEC

(Canada)

1988

ISO/IEC15408と情報セキュリティ評価・認証制度

(76)

独立行政法人情報処理推進機構

認証書

（Ｃｅｒｔｉｆｉｃａｔｉｏｎ）

申請者

ベンダー、

システム・インテグレーター

申請者

ベンダー、

システム・インテグレーター

ＮＩＴＥ

独立行政法人製品評価技術基盤機構

ＮＩＴＥ

独立行政法人製品評価技術基盤機構

② 評価依頼

③ 評価

評価機関の認定

（Ａｃｃｒｅｄｉｔａｔｉｏｎ）

（Ｅｖａｌｕａｔｉｏｎ）

評価基準 ＩＳＯ/ＩＥＣ15408 ＣＣＲＡ

評価機関

情報セキュリティ評価・認証制度(JISEC)

認証機関

*

認定機関

評価報告

④ 認証

① 認証申請

ハードウェア

ソフトウェア

(77)

¾ CCRA(Common Criteria Recognition Arrangement)とは、各国の政策実施機関が IT製品等の安全性を客観的に

評価した結果を国際的に相互承認するための枠組み。1998年にISO/IEC15408(別名：Common Criteria)に基づく

評価を開始して、米英仏独加5か国の政策実施機関により設立された。

¾ 我が国は19番目の加盟国。

¾ 現時点(2004年9月)での認証取得済製品は約180品目（うち20品目が我が国の製品）。

CCRA

加盟国（

2004

年

9

9 月現在）

月現在）

カナダカナダフランスフランスドイツドイツイギリスイギリス米国米国オーストラリアオーストラリアニュージーランドニュージーランド

認証

(

Validation

／

Certification)

評価

(Evaluation)

認定

(Accreditation)

CCRA

認証書認証書認証書認証書認証書認証書認証書認証書ギリシャギリシャフィンランドフィンランドイタリアイタリアオランダオランダノルウェーノルウェースペインスペイン認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書認証書イスラエルイスラエル

認証発行国

※注１トルコトルコ

認証受入国

※注２

CCRA

(Common Criteria Recognition Arrangement)

(78)

各省庁は、セキュリティに関する信頼度の高い情報システムの構

築を図る観点から、今後の情報システムの構築に当たっては、可

能な限り、次のような方法等により、ISO/IEC15408に基づいて評

価又は認証された製品等の利用を推進するものとする。

各省庁は、セキュリティに関する信頼度の高い情報システムの構

築を図る観点から、今後の情報システムの構築に当たっては、可

能な限り、次のような方法等により、

ISO/IEC15408

に基づいて評

価又は認証された製品等の利用を推進するものとする。

政府調達の際には、可能な限り認証された製品を調達するか、

システムに関するＳＴの評価を受けることと

す

る。

平成

₁₃

年

₃

月

₂₉

日

行政情報化推進各省庁連絡会議了承

ISO/IEC15408と情報セキュリティ評価・認証制度

政府調達における位置づけ

ISO15408に関する問合せ先

(独）情報処理推進機構セキュリティセンター

(79)

情報セキュリティセミナー 2004

インシデント対応

１．インシデント対応とは

２．平時におけるインシデント対応の準備

３．情報セキュリティ侵害を検出する

４．インシデントに対応する

５．インシデント後

(80)

インシデント対応とは

• インシデント

情報セキュリティ分野においては(Security incident)、情報

セキュリティリスクが発現，現実化した事象

• サービス妨害（DoS)攻撃

• システムへの侵入

• サーバの不正中継

等

• インシデント対応

インシデントの発生に際して、それを

検知

し、関係組織と

連

絡

をとり、被害の拡大を防ぐと共に、

再発を防止する

ための

(81)

• セキュリティポリシー等の中で手順を明記

インシデント発生時の体制、責任者、連絡先等

• 平時に行われていなければならないこと

–

定期的バックアップ

–

システムの通常状態の把握

–

外部情報収集と修正プログラムの適用

–

予行演習

• 技術的手段の準備

–

情報セキュリティ侵害の検知を支援するツール

–

バックアップ資源

平時におけるインシデント対応の準備

(82)

情報セキュリティ侵害を検出する(1)

• 検出・認識の方法

–

既知の侵害（パターン）を検出する：シグネチャ認識

–

異常な状態を認識する

–

他者からの連絡

• ツールの利用

• 次に何をすべきか？

(83)

情報セキュリティ侵害を検出する(2)

ｰ異常な状態を認識する

システム異常の例

(1)

レスポンスの異常な低下

(2)

システムエラーの発生

(3)

システムの異常停止

(4)

ファイルの改ざん

(5)

存在すべきファイルの抹消や不明なファイルの存在

(6)

ファイル利用量の急激な増減

(7)

本来稼動しているはずのサービスの停止

(8)

不明なプロセスの実行

(9)

本来利用できないはずのシステムユーザの利用

(84)

情報セキュリティ侵害を検出する(3)

ｰツールの利用

異常検出を極力自動化

例：Tripwireによる各種設定ファイルの改ざんチェック

当該ファイルのハッシュ値の比較（正常時と異常時)

平時の準備が必要

(85)

情報セキュリティ侵害を検出する(4)

ｰ次に何をすべきか？

• インシデントの状態の保存

–

各種設定ファイル

–

ネットワークの接続状況

–

ログインユーザ

–

すべてのプロセス等

• 該当インシデントの公開情報の調査

IPA/ISEC、JPCERT/CC等の利用

• 本当にインシデントかどうかの確認

• 時系列の記録の開始

(86)

インシデントに対応する

• インシデント対応手順の確認

• 報告する

–

組織体内部のコミュニケーション

あらかじめ定められた手順

–

参考資料：JPCERT/CC 技術メモ関係サイトとの情報交換

http://www.jpcert.or.jp/ed/2002/ed020001.txt

(87)

インシデントに対応する(2)

• 暫定的対応と本格的対応

–

暫定的対応（

被害の拡大防止

）：

• ネットワークの遮断／システムの停止

–

本格的対応（

再発防止

）：

• 原因の特定

• クリーンなシステムの再構築

(

攻撃者にシステム特権を奪われたとき)

• 修正プログラムの適用

• データの復旧

(88)

インシデント後

• 報告書

–

時系列記録の整理・報告

–

今回対応のよかった点／悪かった点

• 改善する

–

改善点をセキュリティポリシーや手順書に反映・

集約

–

技術的な改善

–

組織間コミュニケーションの改善

(89)

インシデント対応の作業手順

• １．

手順の確認

• ２．作業記録の作成

• ３．責任者、担当者への連絡

• ４．事実の確認

• ５．スナップショットの保存

• ６．ネットワーク接続やシステムの遮断もしくは停止

• ７．影響範囲の特定

• ８．渉外、関係サイトへの連絡

• ９．要因の特定

• １０．システムの復旧

• １１．再発防止策の実施

• １２．監視体制の強化

• １３．作業結果の報告

(90)

補足：不審なアクセスを検出した場合の対応

• 可能性

(a)攻撃対象の探索を意図したアクセス、または、アタックその

もの

(b)設定ミス、操作ミスによるアクセス

(c)システムの予想外の挙動によるアクセス

• 対応

(a)すべてのアタックについて防御に成功したと判断できない場

合には、念のためシステムの稼働状況を調査し、不審な点

がないか確認

(91)

補足：外部からインシデントについての連絡を

受けた場合

(1)サイト内での調整

広報、渉外、法務などからの対応が望まれる場合は、該当部署と調整

(2)事実関係の確認

・連絡元の主張する内容を

落ち付いて

確認

（対象サイト、アクセスの内容、日時等)

・自サイトの場合システムログ等による事実関係の確認

（事実の場合、影響度によってはネットワーク接続やシステムの遮断、

停止を優先するほうがよい場合も）

(3)連絡元への対応

・善意の連絡：事情説明、謝罪など礼を逸しない対応

・悪意の連絡：回答を避ける等の特別の対応も検討要

(92)

補足：侵入への対応

(1)

ネットワークの遮断、システムの停止

(2)

スナップショットの保存

(3)

被侵入システムにおける調査

(4)

他のシステムに対する影響の調査

(5)

侵入経路の特定

(93)

補足：侵入への対応

_-(1)

(1)

ネットワークの遮断、システムの停止

システム侵入

→・ログ改ざんのおそれ

・他システムへの攻撃元として悪用

・パケット盗聴プログラムの設置

・情報の持ち出しなど

ネットワークの遮断やシステムの停止について

優先的に

検討要

出典技術メモ - コンピュータセキュリティインシデントへの対応

http://www.jpcert.or.jp/ed/2002/ed020002.txt

(94)

補足：侵入への対応-(2)

(2)スナップショットの保存

・プロセスの稼働状況

・ネットワークの利用状況

・ファイルシステムの状況

（ファイルの最終参照時刻、最終更新時刻、所有者、

アクセス権など)

(95)

補足：侵入への対応-(3)

(3)被侵入システムにおける調査

正常な状態と比較し、相違の有無を確認

改ざんの例：

・アカウント情報の追加、変更

・ユーザ認証機構の改ざん

・プログラムのインストール、起動

・セキュリティ上の弱点を含むソフトウェアへのダウングレード

・侵入者に関する情報を出力から除外するコマンドへの置換

改ざんされていないコマンドによる調査が重要

(96)

補足：侵入への対応-(4)

(4)他のシステムに対する影響の調査

・攻撃用ツールの出力を保存したファイル

・侵入者による他システムへのTCP接続の痕跡

・ルータやファイアウォールのログ

(97)

補足：侵入への対応

_-(5)

(5)侵入経路の特定

弱点のチェック

・放置していたセキュリティ上の問題、弱点はなかったか

・パスワードファイルや設定ファイル類が盗まれた形跡はないか

・見破られやすいパスワードがなかったか

・HTTP や FTP など、公開しているサービスに設定の誤りが

なかったかなどをチェック

(98)

補足：証拠保全-(1)

• 刑事事件を視野に入れる場合は「証拠保全」

–

「証拠」となるデータを、可能な限りそのままの状態で捜

査機関にわたす

–

証拠保全＝現場保全であり、不用意なログインを含め

てできるだけ操作をしないことが重要

–

ただし、被害拡大を防ぐための最低限の処置は行う

• ルーティング変更

• DNS変更、ファイアウォールのフィルタ等による通信遮断

–

物理的に遮断するのは得策ではない

(99)

補足：証拠保全-(2)

標的だけを隔離する例

• 標的サーバーへの通

信、標的サーバーから

の通信だけを遮断し、

標的の状態を保全する

• ただし、標的ではない

サーバーも注意が必要

–

踏み台（標的サーバー）

からの２次攻撃の可能

性有り

ルーター、

ファイアウォール

標的

サーバー

標的ではない

サーバー

(100)

補足：証拠保全-(3)

刑事と民事

• 刑事事件は捜査機関に任せる

–

不正アクセス禁止法などは刑事なので、捜査機関が起

訴可能と判断すれば逮捕等に発展することが可能

–

捜査主体は当然捜査機関であり、被害者といえども口出

しできない

–

刑事事件の証拠は「原本（オリジナル）」である必要があ

るため、データが必要ならば手元に自分でコピーして置

いておく必要がある

• 民事は自分で証拠を集めて立証する

–

損害賠償を求める場合などは、損害程度、損害をうけた

証拠、相手を特定できる証拠などを集める必要がある

(101)

参考：侵入検知に関する資料

[1] Intruder Detection Checklist

http://www.cert.org/tech_tips/intruder_detection_checklist.html

[2] Steps for Recovering from a UNIX or NT System Compromise

http://www.cert.org/tech_tips/win-UNIX-system_compromise.html

http://www.auscert.org.au/Information/Auscert_info/Papers/win-UNIX-system_compromise.html

[3] CIAC-2305 Unix Incident Guide: How to Detect an Intrusion

ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2305.pdf

ftp://ciac.llnl.gov/pub/ciac/ciacdocs/ciac2305.txt

[4] Windows NT Intruder Detection Checklist

http://www.auscert.org.au/Information/Auscert_info/Papers/win_intruder_

detection_checklist.html

(102)

情報セキュリティセミナー 2004

(103)

セキュリティ情報収集

(1)メールによる情報収集 [1/2]

• 企業内で利用しているハードウェアや市販のソフト

ウェアについては、ユーザ登録を行うことで、脆弱

性やパッチ（アップデート）の情報がメール配信され

る場合があります。このようなユーザ登録は行って

おくべきでしょう。

• また、これから紹介するようなメーリングリストに登

録しておくことで、最新のセキュリティ情報をいち早

く得ることが出来ます。

(104)

セキュリティ情報収集

(1)メールによる情報収集 [2/2]

• Microsoftのメーリングリスト

マイクロソフトプロダクトセキュリティ警告サービス

http://www.microsoft.com/japan/technet/security/bulletin/

notify.asp

• IPAのメーリングリスト

情報処理推進機構新着情報メール配信

http://www.ipa.go.jp/about/mail/index.html

• JPCERT/CCのメーリングリスト

http://www.jpcert.or.jp/announce.html

(105)

セキュリティ情報収集

(2)Webからの脆弱性やパッチの情報収集 [1/4]

• 脆弱性情報を提供するサイトを定期的に参照するこ

とで、それらの最新情報を収集することが出来ます。

• また、ハードウェアやソフトウェアのメーカーサイトを

定期的に参照することで、それらの最新情報を収集

することが出来ます。

• 経済産業省告示「ソフトウエア等脆弱性関連情報取

扱基準(*)」を受けて、日本国内の製品開発者の脆弱

性対応状況を公開するサイトとして、JVNがあります。

(106)

セキュリティ情報収集

(2)Webからの脆弱性やパッチの情報収集 [2/4]

• IPA/ISEC

http://www.ipa.go.jp/security/

• JPCERT/CC

http://www.jpcert.or.jp

• @police (警察庁/NPA)

http://www.cyberpolice.go.jp/

• CIAC

http://www.ciac.org/ciac/index.html

• CERT/CC

(107)

セキュリティ情報収集

(2)Webからの脆弱性やパッチの情報収集 [3/4]

• Microsoft

http://www.microsoft.com/japan/technet/security/

（日本語版）

• SUN

http://sunsolve.sun.com/search/search.do?Search=pageNa

me&search=type&language=ja&collection=SUNALERT

• Cisco

http://www.cisco.com/en/US/products/products_security_ad

visories_listing.html

(108)

セキュリティ情報収集

(2)Webからの脆弱性やパッチの情報収集 [4/4]

• CheckPoint

http://www.checkpoint.co.jp/securitycenter/advisories/index.html

（日本語版）

• Oracle

http://otn.oracle.co.jp/security/

（日本語版）

• IBM

http://www-6.ibm.com/jp/domino07/lotus/home.nsf/Content/support

• Apache

http://www.apache.jp/

（日本語版）

• HP

(109)

セキュリティ情報収集

(2)Webからの脆弱性やパッチの情報収集

• JVN

JVN は、"JP Vendor Status Notes" の略です。経済産

業省告示「ソフトウエア等脆弱性関連情報取扱基準(*)」

を受けて、日本国内の製品開発者の脆弱性対応状況を

公開するサイトとして、有限責任中間法人 JPCERT コー

ディネーションセンター (JPCERT/CC) と独立行政法人

情報処理推進機構 (IPA) が共同で運営しています。

JVN では、JPCERT/CC が取り扱った脆弱性情報を公

開しています。これらの脆弱性情報には、この枠組みに

参加している日本国内の製品開発者の対応状況も含ま

れております。対応状況には、脆弱性に該当する製品の

有無、回避策(ワークアラウンド) や対策情報(パッチなど)

も含まれます。

(110)

(111)

セキュリティ情報収集

(3)

Webからのコンピュータウイルス関連の情報収集 [1/2]

• 通常は、ウイルス対策ソフトを導入してあり、

かつ常に最新版のウイルス定義ファイルに

更新されていれば、かなりの確率でウイルス

を防ぐことが出来ますが、万が一感染してし

まった場合あるいは詳細の情報が必要な場

合には、ワクチンベンダーのサイトを参照す

ることで、それらの最新情報を収集すること

が出来ます。

(112)

セキュリティ情報収集

(3)

Webからのコンピュータウイルス関連の情報収集 [2/2]

• トレンドマイクロ

http://www.trendmicro.co.jp/vinfo/

(日本語)

http://www.trendmicro.com/map/（Virus Map）

• シマンテック

http://securityresponse.symantec.com/

http://www.symantec.com/region/jp/sarcj/index.html

(日本語)

• McAfee

http://vil.nai.com/VIL/newly-discovered-viruses.asp

http://www.nai.com/japan/security/latest.asp

(日本語)

• Sophos

http://www.sophos.co.jp/

(日本語)

(113)

セキュリティ情報収集

(4)Webからの新種ワーム発生状況やインターネット事情の情報収集 [1/2]

Copyright

情報セキュリティセミナー 2004

組織的取り組みと

情報セキュリティマネジメントシステム

1. リスクアセスメント

2. 情報セキュリティポリシー

3. 従業員の教育、委託先との関係

１．リスクアセスメント

- リスクアセスメントはなぜ必要か？

- リスクアセスメントとは

- リスク分析手法（リスクの識別と評価）

ベースラインアプローチ

詳細リスク分析

組み合わせアプローチ

リスクアセスメントはなぜ必要か？

リスクアセスメントをしないと…….

・事が起こってから慌てて対策する。

・場当たり的な対策に終止してしまう。

・組織のどこにリスクが潜み、

何を優先的に対策してよいかわからない。

・限られた対策予算を効果的に使えない

・全体を見通した対策ができない。

組織の危機管理に問題が生じる

リスクアセスメントの効果

リスクアセスメントを行うと…….

・組織のどこにどんな脅威が存在するか把握できる。

・組織の中に潜む脆弱性が把握できる。

・組織に対するリスクの全容が理解できる。

・組織にとって影響度の高い脅威が何かを把握でき、

何を優先的に対策してよいかわかる。

・限られた対策予算を効果的に使える。

・全体を見通した対策ができる。

リスクアセスメントとは

リスク分析からリスク評価までのプロセス

リスク因子＝脅威と脆弱性をリスク因子と呼ぶ

リスクは様々なリスク因子の関係により発生する

例：設定不備（脆弱性）を突かれて不正アクセス（脅威）される

リスクアセスメント

リスク分析

リスク因子を特定する

リスクを算定する

リスク評価

脅威

： システム又は組織に危害を与える事故の潜在的原因

脆弱性

：脅威によって影響を受ける内在する弱さ

リスク分析手法

(1)ベースラインアプローチ

ベースライン（自組織の対策基準）を策定し、適用する。

(2)非形式的アプローチ

コンサルタント又は組織や担当者の経験、判断により評価

(3)詳細リスク分析

詳細なリスクアセスメントを実施。情報資産に対し「資産価

値」「脅威」「脆弱性」「セキュリティ要件」を識別、評価

(4)組合せアプローチ

複数のアプローチの併用

ベースラインアプローチ

既存の標準や基準をもとにチェックしていく

・情報資産毎にリスクを評価しない。

・情報セキュリティに関する基準やガイドラインを

利用し、自組織で実現可能な管理策を採用する。

【参照する標準やガイドラインの例】

ISO/IEC17799の管理策（127項目より取捨選択）

セキュリティ対策セルフチェックシート

http://www.ipa.go.jp/security/ciadr/checksheet.html

ウイルス対策チェックシート

http://www.ipa.go.jp/security/virus/beginner/check/check.html

ベースラインアプローチ

ベースラインアプローチの手順

・ベースラインの決定

基準などを参照して自組織の管理策を決定

・ギャップ分析の実施

採用した管理策への準拠状況を把握する

【長所と短所】

長所：チェックリストやアンケートにより、手軽にリスク分析ができる

アンケート形式で進めると、手軽に規定を浸透させられる

詳細リスク分析

組織内の情報資産の綿密なリスク分析を行う

・情報資産を洗い出し、資産毎にリスクを評価する

・資産毎の脅威と脆弱性を識別し、リスクを定量化する

：システム又は組織に危害を与える事故の潜在的原因

脅威・脆弱性の評価（高・中・低のレベル付け）