総務、人事の仕事・総務業務専門ポータルサイト SOS総務.com│コラム│情報セキュリティ

総務、人事の仕事・総務業務専門ポータルサイト SOS総務.com│コラム│情報セキュリティ http://www.sos-soumu.com/column/risk/security/ ja Copyright 2008 Tue, 19 Jun 2007 18:34:03 +0900 http://www.sixapart.com/movabletype/?v=3.2-ja-2 http://blogs.law.harvard.edu/tech/rss セキュリティを組織に根付かせる教育 ◆全従業員を意識したカリキュラムを作る企業が、社員に対して参加を義務付けて実施する教育としては、入社時の「新人研修」、昇進昇格時の「昇進昇格研修」、管理職への「管理職研修」、それから「人権啓発研修」などが一般的です。セキュリティ教育については、個別に実施するというのは現実的ではありませんので、これらの教育コースに組み込んで実施するのがよいでしょう。しかし、ISMSや個人情報保護の教育は、社員だけが対象ではありませんから、社員以外の役員、派遣社員、パート、アルバイトなどを対象とした教育カリキュラムが必要となります。下記の表は、その点を考慮して設定された「セキュリティ教育コース例」です。自社で実施している教育と比較し、ご活用ください。 ●教育コース一覧（例）　＊従業者：社員、派遣社員、パート、アルバイト

◆各教育コースの実施上の補足 ①「セキュリティ基礎知識」 これは新入社の従業者を対象としたもので、上記第一段階のセキュリティ教育に相当し、セキュリティの基本的な知識の取得および自社のセキュリティルールの周知などが主なねらいになります。 ②「問題解決ケーススタディ」 主任などの実務のリーダークラスを対象とし、他社のセキュリティ事故の記事を読んで、自社のセキュリティポリシーのどこを遵守していれば同じような事故を防ぐことができるのかを考えます。そして、もし、現状のセキュリティポリシーの遵守では防止し切れない場合には、セキュリティポリシーをどのように改定すればよいかなどについてもディスカッションします。自社のセキュリティポリシーとの関連付けを行うことで、“対岸の火事”でなく、自分たちの問題として意識させ、セキュリティポリシーを読みこなすことになりますので、理解が深まります。 ③「リスク評価ケーススタディ」 管理職を対象としており、②の問題解決ケーススタディと同じように他社のセキュリティ事故の記事を読んで、自社で同じ事件が起きたときに、どのように対応すべきかアクションプランを立案します。そして、当社が被る損害（金額的なもの、社会的信用等）はどのくらいかを試算するとともに、外部にどのように公表するかなど広報の視点からもディスカッションをします。実際に損害額を数値化してみることでリスクに対する認識が高まります。 ④「セキュリティ啓発」 全従業者を対象としたもので、セキュリティに関連する情報は日々更新されていきますので、最新情報のキャッチアップと自社ルールの周知徹底をはかることがねらいとなります。 ⑤役員（経営者）向け 上記①、④に加え、セキュリティ対策が経営陣である自分たちの問題であり、ファイアウォールや暗号など技術面だけでなく、運用管理面が重要であることを認識してもらうことが大切です。役員には、コストや利便性とのトレードオフなど、さまざまなセキュリティ課題に直面したとき、適切な経営判断が期待されているからです。また、事故が発生した場合、速やかに、適切な指示を出し、会社としての対処をしなければなりませんが、そのための効果的な役員への教育は難しいのが現実でしょう。ひとつの方法としては、上記③「リスク評価ケーススタディ」教育の実施内容をビデオに撮り、それを役員が視聴し、事故への対応についてシミュレーションしてみるという教育方法があります。これは一方で、「リスク評価ケーススタディ」の受講者が役員に見られることを意識し、真剣さが増すという効果も期待できるでしょう。 ]]> http://www.sos-soumu.com/column/risk/security/post_5.php http://www.sos-soumu.com/column/risk/security/post_5.php Tue, 19 Jun 2007 18:34:03 +0900 事件・事故の原因を掘り下げて実効性ある再発防止策を考える～セキュリティ事件・事故の本質的な原因の解明手法～　日々報道されるセキュリティに関する事件・事故。なぜこんなにも頻繁に起こるのでしょうか。小職は、もともとソフトウェア技術者でしが、その当時のソフトウェアのバグ（障害）管理の経験から得たことを用いて、実効性のある再発防止策を導きすための事件・事故の直接的な原因と本質的な原因をどのように捉え、掘り下げていくのかについて考えてみましょう。 本質的な原因を探る手順（図１、図２を参照） 　　ソフトウェアの「バグの原因を捉える」例をみながら考えてみましょう。基本的にソフトウェアにバグがないことを保証することは不可能です。バグが検出されたらその本質的な原因を早く突き止め、対策を立てて再発防止に努めることが基本です。　バグが検出されるとその管理票をもとにその現象、原因、対応策をまとめますが、大半の原因は“テストケース漏れ“です。そのケースについてテストしていれば、その結果を見落とさない限り確かにバグは検出されるはずです。したがって、この原因が直接的なもののひとつであるといえます。しかし、これは本質的な原因ではないので適切な再発防止策を打つことはできません。１．バグが発生した本質的な原因を突き止める場合には、まず「バグを埋め込んでしまった原因」とそれを「除去できなかった原因」の２つの側面から考える必要があります。（図１）　（１）バグを埋め込んでしまった主な原因を考えます。それらには、要求分析が曖昧であった（要求分析が曖昧）、要求が正しく設計されなかった（設計ミス）、設計どおり実装しなかった（実装ミス）ということなどがあり、さらにそれらをレビューで検出できなかったことも原因の１つといえます。（２）バグを除去できなかった主な原因を考えますが、前述の通りその大半は「テストケース漏れ」（そのケース未テスト）です。また、テストは実施したが結果を見過ごしてしまった（テスト結果見落とし）ということもありえます。２．ここでは、さらに「テストケース漏れ」（そのケース未テスト）についてさらに掘り下げて本質的原因を探ってみます。（図２）　この「テストケース漏れ」は、一見、ケアレスミス（テストケースの洗い出し漏れ）のように思われがちでが、それ以前にプロジェクト計画や設計の問題であったり、変更管理の問題（変更管理不十分）であったりすることもあります。しかしながら、「テスト技法スキル不足」であることも多いものです。原因をさらに掘り下げて、その根っこまで辿り着くとその原因の本質が具体的に見え、自ずとその対策も作ることができるとうことです。（図1）

（図2）

セキュリティ事件・事故の本質的な原因を捉え、再発防止策を作る 　　事故が発生すると、まず事故調査委員会を立ち上げ、原因究明と再発防止策に取り組む例が多く見られます。2003年11月にACCS（（社）コンピュータソフトウェア著作権協会）で起きた個人情報流出事件でも同じで、小職は、この事故調査委員会のメンバーとして参加していたこともあり、その事件の「事故調査委員会調査報告書」から内容を一部抜粋補記したものを下記に掲載したので検証してみましょう。この事件は、“不正アクセス”と“善意による脆弱性の指摘行為”について、多方面から議論を呼びましたので記憶している方も多いかと思います。 １．本件が発覚した経緯等 　平成１５年１１月8日、ある方（以下「情報提供者」という）からACCSに「ホームページ上から個人情報を入手できる」とのメールが届いた。そこでACCS側で確認したところ、ホームページで使用されていたCGIプログラムに、セキュリティの脆弱な部分が存在しており、それを意図的に攻撃することでホームページに質問を寄せた約１２００人の送信日時・氏名・住所・電話番号・年齢・メールアドレス・相談内容等（以下「個人情報」という）を入手できる状態にあったことが確認された。ACCSは直ちに当該CGIプログラムの使用を中止し、サイトを閉鎖した。 ２．本件発生の原因 ＜技術的な原因（直接的原因）とは＞　技術的な原因は、セキュリティの脆弱性が認められるCGIプログラムを使用していたことにある。ホームページは、レンタルサーバー会社のサーバーで運営されており、ホームページ上の質問フォームで入力された情報は、担当者に送信されるとともにテキストファイル形式でサーバーに保存される仕組みになっていた。担当者は、この保存のためにレンタルサーバー会社からホームページの開設時に提供されていた標準CGIプログラムを利用していた。　　　しかし、このCGIプログラムには、ある特別な操作をする事で質問フォームに入力された情報をダウンロードできてしまうという脆弱性が存在していたため、ホームページ上の質問フォームで入力された情報を取得することが可能となっていた。＜本質的な原因とは＞　上記のとおり、本件の技術的な原因は、当該CGIプログラムに脆弱性があった点にあるが、本質的には、次のような問題があると判断した。（１）ACCSは、ホームページについて、セキュリティチェック等の充分な検証を実施していなかった。また、当該CGIプログラムを採用するに際しても、特にセキュリティ上の検証を行っていなかった。　ホームページで広く個人情報を収集・取得していたのであるから、そのセキュリティについては細心の注意を払うことが求められていたというべきである。第三者が作成したソフトウェアを利用する場合には、その選定に際して細心の注意を払う必要があると考えるし、採用した後においても、セキュリティ上の問題がないか否かを、継続的に自らの責任で検証する必要があると考える。　さらに、ACCSは、これまで情報の取り扱いに関する啓発活動を自ら行ってきていることからすれば、自ら運営するホームページのセキュリティについては、通常の企業等以上に、充分なスキル、体制で臨む必要があると考える。しかし、レンタルサーバー会社の提供するCGIプログラムを採用する際に、セキュリティ上の検証について入念な検査をしたとは認められなかった。（２）ホームページでは、必要と認められる以上の個人情報を入力させていたと考えられる。また、不特定の第三者から広く質問を受け付け、それに回答することを目的としていた以上、回答を送付するために必要な最低限の個人情報（メールアドレス等）の入力を求めることはやむを得ないと考える。　　　しかし、ホームページの質問フォームでは、さらに住所・氏名等の個人情報の入力まで要求していたが、そこまでの情報が必要であったとは認めがたい。個人情報を扱う際には、その管理に万全を尽くすことはもちろんであるが、それと同時に、そもそも不必要な個人情報は取得しないことも求められているというべきである。 ＜小　括＞ 　本件の技術的な原因（直接的な原因）は、ホームページで採用していたCGIプログラムの脆弱性にある。しかし、本質的な原因は、（1）ACCSが、当該CGIプログラムの採用にあたって、十分なセキュリティ等のチェックを行っていなかったこと、（2）必要以上に個人情報を取得したことの２点にある。 ※この件についてもっと詳細にお知りになりたい方は、Google等で「“ASKACCS” “個人情報流出事故調査委員会”」で検索してみてください。　以上が事故調査委員会の報告書の抜粋検証です。　最後にもし、原因として技術的な原因（直接的な原因）までしか捉えられなかったとすると、再発防止策は、「脆弱性のあるCGIプログラムを使用しない」といった短絡的なものになり、実効性のある再発防止策を作ることは出来ません。　これに対して、本質的な原因を認識すれば、以下のような具体策が導き出すことができます。 ①第三者が作成したプログラムを採用する際には特に十分なセキュリティ検証を行う ②セキュリティ検証チェックリストを作成し、十分検証の上でシステム運用を開始する ③個人情報の取得の際、目的に必要な最小限の情報のみを取得する　また、これらを遵守徹底できるように、 ④セキュリティ規定や運用マニュアルが整備　されれば、さらに実効性のある再発防止策となるでしょう。　これらのことに加え普段から、他で発生した事例についても直接的な原因にとどまらず、本質的な原因まで掘り下げて捉え、自社の状況を検証することもお薦めします。 ]]> http://www.sos-soumu.com/column/risk/security/post_4.php http://www.sos-soumu.com/column/risk/security/post_4.php Wed, 09 May 2007 11:48:12 +0900 セキュリティポリシーの見直し　～事故の教訓をセキュリティポリシーに活かす～１．セキュリティポリシーの見直しポイント　セキュリティポリシーは、その定着化と並行して、定期的かつ必要に応じて見直しをしなければなりません。セキュリティポリシーの見直しポイントは、下の表のように整理することができます。

２．セキュリティポリシーの日常点検 　セキュリティ対策にこれで万全ということはありません。しかし、他社で起きた事故を自社で繰り返す（上記⑤）ことだけは避けたいものです。そのために、他社で起きたセキュリティ事件・事故を手本として、発生時には自社で同じことが起きないか、速やかにチェックを行い、的確な対策を打つことが大切です。具体的なチェックの仕方としては、毎日のように新聞、インターネット等で掲載されているさまざまなセキュリティ事件・事故の記事を元に、次の事項などを確認、チェックすると良いでしょう。 ①自社のセキュリティポリシーにそれを防ぐ管理策が規定されているか ②その管理策がきちんと遵守されているかどうか ③万が一、同種の事件・事故が自社で起きた場合のインシデント対応は明確か　例えば、「2007/02/02(金)　社員の個人情報約400などを含むパソコン紛失」（ http://jtrustc.co.jp/html/pnews/readnews.php?logno=200702）に対しては、次の点検を行うとよいでしょう。 ①ノートPCを社外に持ち出すことを許可しているか ②ノートPCに機密情報（個人情報も含む）が保存されているか ③ノートPCを社外に持ち出すときの取扱いについて規定されているか ④ノートPCの認証及びアクセス制御機構は強固か ⑤機密情報は、個別のパスワードや暗号化などしているか ⑥自社で同じ事故が起きた場合の対応はどうなっているか ３．セキュリティポリシー見直し手順 　日常の点検結果で、不十分な点が判明すれば、次の手順で速やかに見直し、改善を行い、社内に周知徹底することが必要です。 ①見直し要因の理解 ②リスク再評価 ③影響範囲の特定と反映　・セキュリティポリシーの改定内容　・セキュリティポリシー定着化計画への反映　・セキュリティ教育への反映　・緊急時対応計画への反映　・セキュリティ監査への反映 ④見直し後のアクション　・キュリティポリシーの周知　・影響度に応じて緊急時対応計画の事前訓練 ⑤上記活動の記録 ]]> http://www.sos-soumu.com/column/risk/security/post_3.php http://www.sos-soumu.com/column/risk/security/post_3.php Mon, 05 Mar 2007 12:20:38 +0900 セキュリティポリシーの定着化　～セキュリティポリシー策定後の活動～１．セキュリティポリシーの定着化とは　セキュリティポリシーの定着化とは次のような状態のことをいいます。 ①セキュリティポリシーに規定されていることがすべて実現している ②セキュリティポリシー遵守において、すべての業務が無理なく遂行できている ③セキュリティポリシーが適用されるすべての者（従業員等）が、セキュリティの重要性を認識し、責任ある行動がとれている ④セキュリティ活動においてPlan-Do-Check-Actのマネジメントサイクルが確立され、継続的改善が図られている ⑤万が一の事故時の対応手順が確立しており、被害を最小限に抑えることができる２．定着化計画（１）まず、定着化計画は、現在の状況を踏まえ、次の各事項に関する記述を含めて全社レベルで立てることが大切です。 ①推進体制の役割及びタスク ②セキュリティポリシー周知の時期及び方法 ③定着化の度合いの測定時期及び方法、並びに段階的な目標値設定 ④教育の実施計画 ⑤内部監査の実施計画 ⑥緊急時対応の事前訓練実施計画 ⑦定着化までの経過的措置の取扱い（例外の取扱い）（２）次に、個別の管理策ごとに具体的な作業内容と実施責任者、実施期限を明確にします。事業規模や事業内容によっては、事業部ごとの個別計画を作成するとよいでしょう。＜個別管理策ごとの定着化計画の例＞

３．定着化度合いの測定　多くの企業では成果主義を取り入れ、単年度で明確な成果を出すことが期待されています。しかし、セキュリティポリシーの定着化は単年度で実現できるものではありません。定着化の度合いを客観的に数値化することは大変難しいものです。そのため、自ら指標（具体的な作業に対する実施完了率）を設けて定着化の度合いを測定するとよいでしょう。定着化の度合いを測定することにより次の効果があります。 ①確実に定着化が進んでいることを知らしめることでモチベーションが維持できる ②定着化に向けては、かなりのコストを要することから、経営層の理解を得るための説得材料となる ③ギャップを確実に埋めていっていることで、役員、監査人等に対して管理責任力のアピールとなる　定着化の度合いの測定の際には、作業を阻害する要因（例えば、業務効率との衝突、取引先の理解が得られないなど）や成功要因等を各部門から吸い上げ、それを全社で共有化し、活動に取り入れたいものです。部門共通の阻害要因については、全社レベルで一括対処したり、成功要因については、他の部門に適用したりするとよいでしょう。４．定着化計画実施中の考慮点　定着化を進めているなかで、セキュリティポリシーを見直さなければならない事態が発生した場合には、必ず定着化計画の見直しも行い、柔軟に対応することが必要です。　　次回は、セキュリティポリシーの見直しについて考えてみます。 ]]> http://www.sos-soumu.com/column/risk/security/post_2.php http://www.sos-soumu.com/column/risk/security/post_2.php Tue, 13 Feb 2007 12:40:01 +0900 セキュリティ意識の向上策１．基本的な心構え　（１）「セキュリティの鎖」という認識を持つ　セキュリティの強度は、よく鎖の強度に例えられます。それは１番弱い輪の強度が鎖全体の強度になるということです。 ①社員ひとりひとりがそれぞれ輪とすると、たった一人の無理解や出来心によって、それまで長い年月をかけて蓄積された企業の信用が、一瞬のうちに失われることになります。 ②物理面、技術面、運用管理面の対策ひとつひとつがそれぞれ輪とすると、無防備な面からセキュリティ事故・事件につながります。（２）「セキュリティ意識の改革」は持続的に粘り強く　社員のセキュリティ意識を改革することは、簡単なことではありません。手を変え、品を変え、粘り強く実施していくことが大切です。 ２．向上施策例 （１）「セキュリティ教育」の継続的実施　運用管理面の重要な対策のひとつとして社員へのセキュリティ教育があります。　セキュリティ教育は、もっとも重要な社員のセキュリティ意識を向上させる機会です。単に知識として知らしめるだけでなく、他人事でなく自分達の問題として認識させるために、すべての社員に、その職務に応じたセキュリティ教育を、セキュリティポリシーの改定状況や環境変化に応じて、継続的に実施することが大切です。（２）罰則規定の明確化と人事評価との連動　セキュリティポリシーを遵守させるには、明確な罰則規定、人事評価とのリンクが必要です。罰則については、一般的には就業規則の罰則規定を適用することになりますが、これだけでは、大事件になるまで適用されず、あまり抑止効果がありません。軽微なセキュリティポリシー違反でも繰り返せば罰則されるような規定によって、内部犯行を未然に防ぎます。また、セキュリティは、一般的にマイナス評価しかされない傾向にあります。完璧な対策など不可能ですから、結果だけを評価するのでなく取組みのプロセス、遵守度などプラス評価を行うことにより、社員が積極的にセキュリティポリシーを遵守するような文化にしていくことが大切です。（３）セキュリティ事故情報のトレースと継続的発信　他社でセキュリティ事故が起こっても、”自分のところは大丈夫だろう”と他人事として済ましてしまいがちです。完璧な対策など不可能ですから、少なくとも他社で起きたことを自分のところで繰り返すことがないようセキュリティポリシーを確認し、セキュリティポリシーのここを守っていれば大丈夫（不足があれば直ちにセキュリティポリシーを改定する）など、“他人の振り見て我が振り直せ“で適切に対処していかなければなりません。　　　他社の悲惨なセキュリティ事故について、セキュリティポリシーと関連付けて、社内向けにニュースレターを配信したり、セキュリティに関するイントラネットサイトの開設したり、セキュリティ管理者が継続的に情報発信することは、組織のセキュリティに対する関心を喚起する効果があります。（４）「セキュリティテスト」による意識レベルの底上げ　セキュリティに関するテストを行うことは、セキュリティ意識を維持するとともにセキュリティポリシーの遵守度を測定するよい機会です。遵守度を測定する際、遵守できない理由をすいあげ、測定結果を部門別、分野別に分析することで、次回のテスト実施までの強化策を絞るとよいでしょう。　また、平均点ではなく最低点で捉えることも大切です。最低点を底上げするための強化策を実施するとよいでしょう。（５）「レッドカード」制度の導入　抜き打ちで社内点検し、クリアデスクができていない人の机上にレッドカードを置くなどするのもセキュリティ意識の向上に役立ちます。（６）社員参画型「セキュリティグッズ」の制作　セキュリティ対策のスローガンなどを印刷したポスターを掲示したり、マウスパッドやコースターといった小物を配布したりするのも効果があります。　できれば、スローガンは社員から公募し、優秀作品をセキュリティグッズに採用すれば、管理者から社員への一方通行ではなく、社員参加型でより効果が上がるのではないでしょうか。セキュリティ対策というと、とかく押し付けられるという先入観がありますが、これであれば社員みんなで取り組んでいこうという雰囲気が生まれ、セキュリティ文化醸成しましょう。 ３．最後に 　小職が所属している日本セキュリティ・マネジメント学会では、6月の全国大会でセキュリティ標語を募集し、優秀作品を選定し、セキュリティ啓発に役立ていただこうと学会のホームページ（http://www.jssm.net/）で公開しています。また、2007年セキュリティ標語カレンダーもPDFでダウンロードできますので、貴社のセキュリティ啓発に活用いただければ幸いです。 ]]> http://www.sos-soumu.com/column/risk/security/post.php http://www.sos-soumu.com/column/risk/security/post.php Wed, 20 Dec 2006 14:36:38 +0900 「事故は起こりうるもの」を前提としたセキュリティ－失敗を繰り返さない努力がセキュリティ推進の基本－ １．ハインリッヒの法則

　最近、飲酒運転、いじめ、そして個人情報の漏えいなど同じような事件・事故が連続して起きています。なぜ、同じことが繰り返されるのでしょうか。　危機管理、安全管理、セキュリティなど様々なところで、「ハインリッヒの法則」を当てはめることができます。この法則は、アメリカの損害保険会社社員であるハインリッヒが、労働災害事例を分析し、導いた理論で、１件の重大な事故の背景には、29件の同種の軽微な事故、300件のヒヤリとしたり、ハットしたりした小さなミスが存在するというものです。　このことは反対に、ひとりひとりのちょっとしたセキュリティへの違反や作業などでのミス（底辺の300）をできるだけ減らすことが、重大な事故を起させにくくすることに繋がることを意味しています。しかしながら底辺の300をゼロにすることは不可能です。完璧な人などいません。どんな人でもミスすることがあります。その前提に立って、セキュリティ対策を事前に検討し、策定しておくことが重要です。また、セキュリティ事故は起こりうるものとして対応策を定期的に訓練しておくことも重要なセキュリティ対策です。 ２．事件・事故に学ぶ 日本のことわざに ①「喉もと過ぎれば熱さを忘れる」 ②「対岸の火事」というのがあります。 ①のような目先のことにとらわれ、その場限りでどうにかし、本質的な解決をしないでいると、失敗などの痛い経験が活きず再発防止することなどできません。また、②のように「自分のところは大丈夫」と思い、「自分のところでも起こりうる」と考えないでいるといずれ自分のところで同じような事件・事故が起きることにつながります。「ハインリッヒの法則」の比率は、自分のところだけでなく、もっと広い視野にたって（日本全体として）捉えてみてください。　自分のところで起きた事件・事故はもちろんのこと、他者で起きた事件・事故から学ぶことも大切です。リスク管理では“発生頻度”が問われますが、実際にどのリスクがどのくらいの発生頻度があるか判断することは難しいのが現状です。そこで最も基本的で大切なことは、実際に起きてしまった事件・事故を繰り返さないようにしていくことです。既に起きた事件・事故を繰り返さないためには、セキュリティ施策におけるPDCAサイクル（Plan－計画、Do－実施・実行、Check－点検・評価、Act－処置・改善）を確立し、それに基づいて継続的に改善していくことが重要なのです。 ]]> http://www.sos-soumu.com/column/risk/security/post_1.php http://www.sos-soumu.com/column/risk/security/post_1.php Tue, 21 Nov 2006 11:23:12 +0900