ロ情報リスクマネジメントではどういった事を実行するのか ? 職位・部門 経営者層 情報システム 部門管理職 システム管理者 やるべきこと げ統治 セキュリティ管理 セキュリティ対策 具体的な作業 げ投資事業戦略 システムの統合・合併 情報分析 システムの企画、設計 人員整理 バックアップ ウイルス対策 ライセンス管理 ③いざという事態が発生した時に、対外的な応対が素早くできる 避けられなかった脅威に対しては、企業はそれを受け入れた上で、顧客 や取引先といった社外の関係者の対応をしなければいけません。たとえば、 情報システムに関するトラブルが発生し、顧客から問い合わせが来た場合、 情報システム部門だけでは、企業の立場で判断できないことがあるかも知 トラブルを れません。情報リスクマネジメントを導入することで事前に 対処する、状況を収集する、分析する、そして判断を下す人の役割までを 確認しますので、いざという時にも、しつかりとした対外の応対が可能で す。 ④新規分野へ参入する時の下調査も情報リスクマネジメントが手助け 情報リスクマネジメントの対象は、既存の業務だけではありません。企 業が新規事業に着手する時、その分野にどのようなリスクが存在している のか、そのリスクを回避するにはどのような方法があるのか調べなければ なりませんが、そんな時にも情報リスクマネジメントは力を発揮します。 第 2 章◎情報リスクマネジメントの概要 55

ーーステップ 3 / 目標をし、 ュリテイボリシーを策定する 104 ュリティの管理体制をもっていない組織では、リスク分析報告書に膨大な 2 つ目は、セキュリティ管理体制の確立を優先させるケースです。セキ うが、当然のことながら時間的にも早く済みます。 全社を対象にしたポリシーを作るより、対象を絞ったポリシーの作成のほ ます 1 つは、セキュリティポリシーの策定時間を短縮させたい場合です。 対象を限定するケースについては、次の 3 つが考えられます。 しています。セキュリティポリシーを策定する上で、全社を対象とせす、 えば、右図では配送部門を除く東京本社をセキュリティポリシーの対象に 合によっては、特定の部署や地域を対象に策定することがあります。たと 本来セキュリティポリシーは全社レベルで定めるものですが、会社の都 内容を検討し、ますセキュリティポリシーの対象範囲を決めます。 システム面のどこに弱点があるか、などが指摘されています。企業は報告 リスク分析報告書には、企業のリスク管理がどのようになっているか、 ◆セキュリテイボリシーの対象範囲を決める 報資産のセキュリティに乖離カ昿がるからです。 は変化しています。時間が経てば経つほど、リスク分析報告書と現状の情 ら、すぐに着手するということです。というのも、企業を取り巻く IT 環境 セキュリティポリシー策定の第 1 のポイントは、リスク分析が終了した ーを記述していきます。 それを全社で統一するために明文化を、つまり実際にセキュリティポリシ ことができます。次はその脅威に対抗するセキュリティの目標を設定し、 リスク分析の結果から、企業は情報資産に対する脅威を明確に把握する ◆リスク分析が終わればすぐに、ボリシーを作成する いよいよセキュリティポリシーの記述が可能になる。 守るべき情報資産と、それに襲いかかる脅威がわかれば

ステップ 2 / リスクを分析する 守るべき資産に対してどのようなリスクカ定されるのか、 そのリスクについて把握することがリスク分析の目的た。 ◆情報リスクの脅威を分析する 企業にとって守る必要の高い情報資産が把握できたら、次はその情報資 産を脅かす情報リスクについて、どのようなモノが考えられるのか、どの 程度の被害をもたらすのかを考える必要があります。それがリスク分析で す。セキュリティポリシーを策定するにあたり、情報資産の分類を行なっ た後のこのリスク分析は、とても重要なステップです。 たとえば、あるデータの情報漏洩に対する脅威として、フロッピーにデ ータを複写する、プリンタに印刷した紙を持ち去る、ゴミ箱に捨てられた 情報から情報が漏洩する、などが考えられるでしよう。その結果、企業に とってどのような被害がもたらされるかも考えられるでしよう。こういっ たリスク分析の結果を用いて企業は、セキュリティポリシーの内容として、 情報資産に対する脅威の対象や範囲を定めたり、対処すべき方法を判断す るのです。 ◆リスク分析の 3 つのポイント リスク分析を行なうには、欠かせないポイントが 3 つあります。ます第 1 に、分析をする対象と範囲を明確にすることです。関連会社まで含めて リスクを分析するのか、特定部門に限定してリスクを分析するのかをハッ キリさせる必要があります。 次に、セキュリティポリシーを策定する目的に合わせてリスクを分析す ることも重要です。たとえば、 BS77 的 ( → 18P ) の認証取得を目指すなら、 リスク分析の際にも管理策を中心に考えるべきでしよう。 最後は、リスク分析の結果をセキュリティポリシーに反映させることで す。リスク分析の結果と策定したポリシーに関連性がなければ、情報資産 100

ロ災害の発生と業務継続 災害復旧 災害発生 コンティジェンシープラン 部門別・担当別・事業所別に業務継続 あらかじめ用意しておく 現状に復旧 被害コストの算出 / 投入した人件費の算出 コンティジェンシープランの見直し ◆どんな企業が、どの程度策定するべきなのか ? 災害復旧計画や業務継続計画の策定は、全ての企業にお勧めします。し かし現実の問題として、企業が直面していない脅威 ( 自然災害、治安の悪 化など ) に対する準備には、経営者のリスクに対する考え方が大きく左右 するのが事実です。そこで、いきなり全社レベルで取り入れるのではなく、 ますは企業の一部の部署 ( 外国の支社、特定の工場、運用部門 ) を対象に 絞って計画してみるのも一つの方法です。 海外に事務所がある場合は、赴任した国の政治状況にあわせて治安のレ ベルを設定し、「業務継続計画」を作成するべきです。赴任者の安全確認の 連絡体制、業務を円滑に他に移管する手続き、緊急時に備えて赴任者がと るべき対応や手続きを検討しておく必要があります。海外の赴任先では、 自宅だけでなく、勤務先でも一定期間の水や食料の備蓄、ラジオ、無線機 などの情報の確保が必要です。多少の現金も必要でしよう。 研究所や工場なら、火災や停電に対する災害復旧計画を作ることを勧め ます。災害復旧計画には災害発生時だけでなく、平常時に行なう訓練の手 順、消火器などの設備の確認、外部組織との連絡体制も含まれます。 またこのように、特定の部署を対象に選ぶ場合は、関係者にも役に立つ レベルまで明らかにする必要があります。 第 2 章◎情報リスクマネジメントの概要 77

います。それでも複合型 IDS 製品に対して指摘されている点もあります。そ れはⅢ S 同士でエージェントが情報交換する送受信のデータです。このデー タ交換が多ければ侵入者に対して逆にⅢ s の存在を気づかれる可能性があり ます。交換されるデータに着目してそのバケットのトラフィックを観察し、 中身を解析できれば、逆にⅢ s のセキュリティの問題となりかねません。 IDS を設置する場所は、ホスト型は各マシン、ネットワーク型は対象とな るネットワークに接続できる場所に設置します。複合型は各マシンと監視 対象のネットワークに設置します。 ◆ IDS の今後 IDS は、まだ技術的に発展途上にあることや、べンダー間での競争が展開 されていることから、問題点も起きています。その一つが、異なったべン ダー間で互換性がないという点です。ファイアウォールと連携できる製品 の人気が高いのですが、どのⅢ s 製品も特定のファイアウォールにしか対応 していないのが現状です。Ⅲ s を検知してもファイアウォールと連携が取れ す、侵入を回避できないというユーザーの声も増えてきています。 そこで最近では、 IDS が検知した情報に基づいてコントロールするよう、 べンダー間で共通のルール化が進んでいます。 IDS が他のネットワーク機器 と容易に連携が取れるようになれば、不正侵入、 Dos 攻撃などの攻撃から、 よりネットワークやマシンを守ることができるようになります。 また、Ⅲ S はファイアウォールほど知名度が高くなく、その存在をアピー ルすることも今後の課題かも知れません。そこで、現在はシステム管理者 向けのⅢ S を、より多くの利用者に知ってもらう努力も進んでいます。現在 日本では、 IDS のメニューの日本語化と GUI 化が試みられています。各家庭 にガスの検知器があるように、インターネットへの常時接続環境が家庭に 浸透すれば、Ⅲ s の重要性は今後ますます高まっていくことは間違いないで しよう。 138

しかしモバイル端末の普及によって、小さなモバイル機器でも数ギガバ イトの容量を保存する機能を有する現在、たとえ携帯電話ーっからでも、 そのメモリーからデータを複写されるリスクがあるのです。結局、複写の 取り扱いは、それぞれのデータの管理方針に大きく左右されるのが現状で す 〇去的整備の遅れ 第 3 の「法的整備の遅れ」とは、不正アクセスやオンラインデータの盗 難などに対する法的な整備が遅れていることです。先に例を挙げた字治市 の住民基本台帳のデータが漏洩した事件では、その時点で電子データが財 物として認められていないことが問題になりました。また、 2 ( 脚年 1 月末に 起きた省庁ウエプサイトの連続改ざん事件 ( → 22P ) では、不正アクセス禁 止法が施行されていなかったために、システムへの不正侵入を法的に処罰 することができませんでした。不正アクセス禁止法 ( → 1 p ) が翌月に施 行されたものの、情報技術の発展するスピードに対して、法的対応が遅れ ています。 こうした法整備の遅れに待ちきれない業界団体は、現在、独自の対応を 模索しているところです。 ◆過失の漏洩と、故意の漏洩 実際に発生した事件を調べると、情報漏洩には過失と故意の 2 つのパター ンがあることがわかります。情報漏洩における過失の行為とは、本人が意 哉せすに情報漏洩してしまったことです。たとえば、ノートパソコンの盗 難や記録媒体の置き忘れによって情報が漏洩するケースです。この場合は、 過失として厳重注意、当事者の始末書提出で済まされる事が多いようです。 日本ではこのケースが故意より多く見られます。 一方の故意による漏洩は、意図的に行なった確信的な行為であり、懲戒 解雇の対象となり懲罰は重くなります。 19 的年 7 月に起きた電話会社の会社 員が顧客の情報を漏洩した事件では、故意によるものであったため、その 会社員は解雇となっています。 38

ロベネトレーションテストの流れ 顧客の合意 ( 対象マシン、実施期間、対象サービス ) 企業側の準備 ・物理的なネッ トワークマッ プの作成 ・ソフトウェア の管理状況の 把握 ・アクセス権限 の把握 情報収集 ( 会社案内、新聞、雑誌記事、インターネット ) 提供外サービスのチェック 既存サービスのテスト 例 : 電子メール、 正常処理 ファイル転送など 異常処理 疑似攻撃 報告書作成 ( 発見された脆弱性・想定される脅威 ) 確 内 セキュリティ対策の選択 ③アクセス権限の確認 第 3 点は、マシン上に保管されているデータとアクセス権限との関係を 明らかにしておくことです。システムの脆弱性とデータとの関係を直接結 びつけることができなければ、企業のデータへの脅威を把握することはで きません。このため、ベネトレーションテストを行なう時には、対象マシ ンにおける顧客データベースのアクセスユーザー ID 、データベース管理者 ユーザー ID の一覧を作成しておくことを勧めます。 第 2 章◎情報リスクマネジメントの概要 69

ロ 1999 年に起きた代表的なクレーム事件 クレームの 対象企業 家電メーカー 某外食企業 某学校 ホームページのアクセス数・収束方法 ・家電の修理にかかわるトラブルからクレーム騒きへと発展 し、その顛末を掲載したホームページのアクセス数は 300 万件を超えた。 ・副社長が顧客まで出向いて謝罪することになった。 ・食品に異物が混入していたことから、クレームへと発展。 ホームページのアクセス数は ] O 万件を超えた。 ・双方合意により、ホームページは閉鎖された。 ・いじめ対策の不満について、ホームページ上にクレームを 掲載。アクセスは数万件を突破した。 ・学校側と両親との相談により解決された。 クレーマーに対しては、クレーマーがマスコミや総会屋のような組織で はなく個人である点に注意する必要があります。個人が企業と裁判で争え ば、個人の経済力に限界があります。そこで企業が経済的な圧力をもって 法的措置をちらっかせ、ホームページの削減を迫る方法をとるケースがあ りますが、先の家電メーカーのケースでは、これを逆手にとられ、大企業 の交渉のやり方、経緯までをインターネットで公開されてしまいました。 相手に「企業の落ち度を指摘される内容であるなら、それを率直に認め企 業自体が自浄するよう勤めるべき」と展開されてしまったのです。 このように泥沼になって他の商品やサービスに影響が出る前に、企業は 間題を解決する努力をすべきだったのです。企業が総会屋対策担当者とし て警察関係者を雇用することは、大企業に見られる傾向です。しかしクレ ーマーに対して総会屋担当者が対応すると逆効果になることもあります。 IT の知識が求められるのは経営者だけではありません。顧客サポート部 門、法務担当者、総務部門など全ての部門に求められているのです。評判 を下げる相手の目的、相手、相手の希望する解決方法を見極め、 IT を良く 知り、誠意をもって対応することが、評判リスクや法務リスクを解決する 第一歩なのです。 第 1 章◎事例で見る「情報リスク」の脅威ーー 47

ロモニタリングの主な対象と目的 モニタリング対象 ・配信元 ・宛先 ・日時 ・データサイズ ・データの書式 〇テキスト 〇圧縮 〇日音号化 モニタリングの目的 ・情報漏えい ・私的利用 電子メール ・私的利用 ・著作権違反 ・ URL ・ドメイン ・アクセス時刻 ・ダウンロードした ファイルの属性 ブラウザ 0 ・ス二フィング ( ネットワークの盗聴 ) ・不正プログラムの発見 ・丿レータの性能管理 イズ率 ・トラフィック 荷 ク負 一の器 ワ一機 トバタ ネサル 第 3 章◎セキュリテイボリシーの策定 1 1 1

ロアウトソーシング先の段階別評価 ーズ フェーズ 第 ] フェーズ 第 2 フェーズ 第 4 フェ 第 3 フェーズ 第 5 フェーズ 名目 ( 書類 ) 移行 ( 移行計画書 ) 環境整備 ( システム設計書 ) 移行テスト ( 移行報告書 ) 本格的な運用 ( 運用実績報告書 ) 撤収 ( 撤収作業完了報告 ) 対象、作業内容 ・委託対象 ・スケジュール ・契約 など ・システム環境構築 ・運用に関する訓練 など ・サービス移行手順 ・動作の確認 ・本格的運用開始 ・運用 ・保守 ・運用の停止 ・サービスの撤収 ・破棄手続き 0 第 2 章◎情報リスクマネジメントの概要 81