Comments
Description
Transcript
発表資料 - 金融庁
金融機関における 金融機関における 情報セキュリティ トラブル 情報セキュリティトラブル ２００５年１２ 月０７日 ２００５年１２月 ０７日 「金融機関と情報セキュリティ」 金融庁 金融研究研修センター 情報セキュリティ大学院大学 1 兼 中央大学 研究開発機構 内田 勝也（ [email protected] ） 金融機関における 情報セキュリティトラブル 過去の事件・事故から学ぶ情報セキュリティ １．キャッシュカードを考える １．キャッシュカードを考える スキミング z ２００５年４月 衆議院 財務金融委員会 全国銀行協会長は暗証番号管理の注意喚起「生年月日、電話番号、 住所地番、車のナンバーなどを避けて欲しい」 １９９９年９月： 東京新聞 「こちら特報部」キャッシュレス時代の落とし穴 データ盗みカード偽造 「スキミン グ」被害急増 被害に気づかず、使われ放題？ 「秋葉原で読み取り機１万円」 クレジットカードでのスキミング。 逮捕者の報道あり 多くの利用者の安心、信頼を確保するためにも、 多くの利用者の安心、信頼を確保するためにも、 銀行協会、協会長行はこの程度の情報を持って欲しい！ 銀行協会、協会長行はこの程度の情報を持って欲しい！ ２５年前の環境と今は同じだろうか？ ２５年前の環境と今は同じだろうか？ 生年月日とは？ ・ ・ ・使っていけない暗証番号 z ¾ ¾ ¾ ¾ ¾ ¾ ¾ ¾ 月＋日 玄関の鍵： 玄関の鍵： シリンダー錠利用は激減 シリンダー錠利用は激減 生年月日として左の全てを 想定できるだろうか？ 和暦＋月＋日 和暦＋月 和暦＋日 西暦年 多くの金融機関のＷｅｂ上の情報 西暦下２桁＋月（１桁）＋日（１桁） ¾ 生年月日・電話番号・住所の番地・単純な数字の組み合わせなど、他 西暦下２桁＋月 人に推測されやすい番号はお避けください 西暦下２桁＋日 ¾ このような番号を利用されている方は、今すぐ暗証番号変更手続きを Institute of Information Security 2 ページ シリンダー錠の機能は今と昔で変化ない シリンダー錠の機能は今と昔で変化ない 金融機関における 情報セキュリティトラブル Katsuya Uchida [email protected] 過去の事件・事故から学ぶ情報セキュリティ １．キャッシュカードを考える １．キャッシュカードを考える ＩＣカード化 z 偽造は難しいので、当面の解決にはなりそう 利用場所限定 ⇒ 磁気カード併用 ⇒ 従前と同じ？ 生体認証 z キャッシュカードとして利用するのに適当だろうか？ ¾ 経年変化、攻撃などはどの程度検討したのか？ ¾ ７万人テストして、全くエラーはなかった！ ⇒ 完璧なサイコロで、７ 回連続 １ がでた。 次も１ だろうか？ （参考： 右表） 2005年３月： マレーシアで指紋でエンジンを始動する車の所有者が、強盗に指を切られた BBC News 「Malaysia car thieves steal finger」 http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm ＩＣカード化の理由 z ページ ¾ キャッシュカードで、このような事件が発生しないといえるのか？ 生体認証は、有人（他人がいる所）で利用すればそれなりの問題はない？ ¾ 入国審査、定期預金など ¾ 最近、指紋認証を利用したＰＣ が多くなってきたが、ＢＩＯＳの認証に利用している人は少ない 個人顧客へのマーケティング ⇒ One To One Maketing 手段 ¾ なぜ、金額限度設定だけなのか？ ¾ Ａ支店とＢ支店でしか利用したくない ¾ コンビニ、デビットカードとしての利用は不要な人もいる ¾ 時間限定だってあってもいい （8:30∼17:00） 犯罪対応にもなる！ スキミングの多くは提携銀行、 遠隔支店、コンビニが利用さ れている？ Institute of Information Security 3 2 Katsuya Uchida [email protected] 金融機関における 情報セキュリティトラブル 過去の事件・事故から学ぶ情報セキュリティ ２．クレジットカード問題 国際化 z カード利用が国際化すれば、犯罪も国際化する 「情報は高い所から低い所に流れない」 ⇒ 情報が必要であれば、海外企業と同等以上の契約を！ アウトソーシングへの警鐘 z アウトソースと「丸投げ」は異なる ¾ 業務は委託しても、責任は委託できない！ ¾ そして、誰もいなくなった 監査方式、監査頻度 ¾ 直接（個別、共同） ¾ 間接１： 認証制度 ¾ 間接２： セルフチェック ¾ 間接３： 当該企業監査を利用 等々 z z z z z リスクコミュニケーションの失敗！？ z ４,０００万トランザクションと言わず、４０万顧客と言ったら、監督官庁、マスコミは動いただろうか！？ ¾ Ｊ＆Ｊ タイレノール事件： 1982年シカゴで７名死亡。対応はＭＢＡのケーススタディにもなっている ¾ 舌禍で子会社を解散、業界トップからも陥落 ¾ 東京商工会議所 編 「危機管理対応マニュアル」 サンマーク文庫 Institute of Information Security 4 ページ 年 半年 四半期 毎月 システム変更時 金融機関における 情報セキュリティトラブル Katsuya Uchida [email protected] 過去の事件・事故から学ぶ情報セキュリティ ２．暗号化 ＦＤ振込データ z 非暗号化データ（ＦＤ）作成の不安 ¾ そのようなことはできません！ ⇒ システム部門に依頼をしたが・・・ ¾ ＦＤの紛失、不正コピーが発生しないだろうか？ ¾ 紛失しても暗号化されていれば、リスクはないのだが センター 金融機関の暗号化 z Internet デビットカード利用小売店内ネットワーク デビットカード利用小売店・データセンター間ネットワーク SSL コンビニＡＴＭネットワーク 街角（汎用）ＡＴＭコーナー 利用者 ＳＳＬへの過信？ 購買担当者 ¾ 当行は１２８ビットの暗号を利用したＳＳＬを使っていますので安全です！ ¾ ハワード・シュミット： R&H Security Consulting のCEO（元米国大統領重要基盤保護委員会委員長） SSLを利用してバックエンドのデータベースとデータ送受信を行うウェブアプリケーションを構築した開 発者達は強力な認証の仕組みや、強固なパスワード、暗号化された通信路を用意していた。また、格 納されるデータの暗号化を行っていた。 しかし、そのデータが購買担当者のオフィスに送信される際 には、ただのテキストファイルとして送信されていた。これではエンドツーエンドのソリューションとはい えない。開発者のもとに行き、『これでセキュリティは完璧なのか？』と問えるよう、個々の開発者に対 してエンドツーエンドのソリューションに関する説明を求められるようにしなければならない http://japan.zdnet.com/news/itm/story/0,2000052525,20088820,00.htm ページ Institute of Information Security 5 3 Katsuya Uchida [email protected] 金融機関における 情報セキュリティトラブル 過去の事件・事故から学ぶ情報セキュリティ ３．システム開発・運用 インターネットワーム（モーリスワーム）事件 z １９８８年１１月２日 当時、コーネル大学の大学院生であったロバート・タッパン・モーリス・ジュニア（Robert T. Morris Jr.）は、SUN-3とVAXコンピュータのBSD 4.2及び4.3版の脆弱性を利用したプログラム（ワーム）を作り、 インターネットに流した UNIXのユーザID／パスワードファイル（/etc/passwd）を利用してパスワード解読した。当時のUNIXでは、 当時、パスワードファイルは誰でも見る（読み出す）ことができた。 パスワードファイルは暗号化されていたため、パスワードを推測できないと言われていた。 パスワードの暗号化は、一方向関数（ハッシュ関数）が使われており、暗号化されたパスワードから元のパ スワードを復元（解読）できない（これは現在でも事実） ハッカーの常識（セキュリティ専門家の非常識？） ハッシュ関数では、ハッシュ化後のパスワードを元のパスワードに戻せないが、 適当にパスワード決め、それをハッシュ化し、ハッシュ化後のパスワードを元のパスワードと比較し、同 じであれば、両方のパスワードは同じ！ パスワードＡ パスワードＢ ハッシュ関数 ハッシュ関数 ハッシュ化パスワードＡ ハッシュ化パスワードＢ パスワードＡ とパスワードＢ は同じ Institute of Information Security 6 ページ ハッシュ化パスワードＡ と ハッシュ化パスワードＢ が 同じならば 金融機関における 情報セキュリティトラブル Katsuya Uchida [email protected] 過去の事件・事故から学ぶ情報セキュリティ ３．システム開発・運用 パスワード攻撃に対する考察： Morris Jr.のパスワード攻撃からの教訓 z 金融機関のキャッシュカードは、盗難カードを利用してＡＴＭ等でパスワードを類推しても、数回誤った暗証番号 を入力するとカードが利用できなくなる。 この方法はＡＴＭ等の機器を利用する場合、非常に有効だが、ネット ワーク上では常に有効だろうか。 ネットワーク上では、口座番号等とパスワードを入力し、口座番号とパスワードが正しくなければログイン等がで きません。 この方法では、同一口座番号に対して、ＡＴＭと同様パスワードを数回誤って入力した場合、ログイ ンをロックする方法を採用している場合がある。 しかし、ログインをロックと、ロック解除のため、コールセンター 等で対応する必要があるため、時間・費用の問題から金融機関・利用者とも避ける傾向がある。 口座番号とパスワードを間違えたら、一定時間ログインをできない方法で安全を確保していると反論される方も おります。 しかしながら、もし、金融機関の口座番号の仕組みがある程度推測できた場合、口座番号を変化さ せ、同一のパスワードを入力する方法で、口座番号とパスワードを推測する攻撃者がいたらどうだろうか。 一 定時間ログインできない仕組みが適用できるだろうか？ ＦＢ不正送金事件 （１９９４年１２月） z ¾ ¾ ¾ z z ページ 某銀行のファームバンキング（ＦＢ）用のパソコン端末を用いて、同行行員らが他行の指定口座に１６億円 余りの虚偽振込をし、１億４,０００万円が引出された。 犯行には、内部者がおり、ＦＢに熟知しており、都度 振込では、毎回暗証番号を変える仕組みであったが、初期値に戻すと、同じ暗証番号を再現できた 内部者が犯行に及ぶことを想定していなかったようだが、ある程度システムに熟知している者であれば、簡 単に不正ができであろう なお、事件は被仕向先金融機関からの連絡で事件が発覚した 動的なパスワード、暗号等が循環するシステムを構築すると、パスワードの推測をしたり、暗号を解読し てしまう可能性が高い 二者が結託してもセキュリティが破られない仕組みを考えることも大切。 Institute of Information Security 7 4 Katsuya Uchida [email protected] 金融機関における 情報セキュリティトラブル 過去の事件・事故から学ぶ情報セキュリティ ソーシャルエンジニアリング 国内金融機関におけるソーシャルエンジニアリング例 z 昭和５６年（1981年）10月 Ｈ相互銀行事件 犯人は、Ｈ相互銀行の某支店に「コムセンの者だが機械のテストをするからＳ支店の口座へ ３,５０ ０万円の入金操作をして欲しい」と指示し、預金係主任が本店からの指示と信じて操作を行った。 共犯の女性が事前に開設してあった口座に入金がされた時間頃に別のＳ支店で３,０００万円を引 出し、騙し取った。 典型的な「ソーシャルエンジニアリング」手法で、犯人の男は電話で行内で使われる言葉（行内用 行内用 語）で指示をしたため、支店の預金主任は完全に騙された。 z 昭和６０年（1985年） 某郵便局 郵便局の窓口の係員に「すぐにお金を持ってくるので、この通帳の口座に入金しておいて欲しい」と 頼み、それを信じて入金手続きを端末機で行わせ、他の郵便局のATM端末から現金1100万円余り を引き出した。 忙しかったり、顧客が忙しそうにしていると、つい親切に対応することが良いと錯覚 してしまう。どんなに切迫している状況の場合でも、どこまでは対応してもよいかを判断できる教育・ 訓練が必要になる。 ページ Institute of Information Security 8 金融機関における 情報セキュリティトラブル Katsuya Uchida [email protected] 過去の事件・事故から学ぶ情報セキュリティ ソーシャルエンジニアリング z 「シークレット・オブ・スーパーハッカー」 ・・・ システム部門の管理者必読本！？ １９９４年に初版（翻訳は１９９５年）が発行されているが、今後とも利用されそうなものが多い z ケビン・ミトニックのソーシャルエンジニアリングの技術は右にでるものがいないと言われる程、有名で技術よ り、ソーシャルエンジニアリングによって、多くのネットワークへの侵入を果たしたと言われている z ケビンは、２００２年１０月に「The Art of Deception」（欺術） を出版。ソーシャルエンジニアリング例が数多く掲 載されている z 正門からシステムへ侵入を果たすことができる方法の１つが、「ソーシャルエンジニアリング」であり、脆弱性が 見つからなくなれば、この方法は非常に有望（？）な侵入経路である z 日本では、「振り込め詐欺」（オレオレ詐欺）等、ソーシャルエンジニアリング犯罪の素地がある！？ z 人間は情報セキュリティ上で、最大のセキュリティホールである 心理的な攻撃に対して、どこまで対応できるだろうか？ 心理的な攻撃に対して、どこまで対応できるだろうか？ そのための対応ができているだろうか？ そのための対応ができているだろうか？ コールセンター等の対応は十分だろうか？ コールセンター等の対応は十分だろうか？ ページ Institute of Information Security 9 5 Katsuya Uchida [email protected] 金融機関における 情報セキュリティトラブル 過去の事件・事故から学ぶ情報セキュリティ リスクの考え方 リスクは時間、環境で変化する。 ２０年前は良くても、現在は良いとは限らない。 内部統制体制の確立 検査と監査 z 検査： 決まったルールに基づいて事務手続きが行われているかどうかをチェックする。 z 監査： ルール自体がリスクを防ぎ、内部統制上、望ましい内容かどうかチェックする。 銀行の支店の金庫室は、二重になっており、外側の扉と、現金・有価証券等を保管する重要品を保管する金 庫の２つになっている。 このため、鍵は外側の鍵と重要品保管庫の鍵の２つがあるが、支店長と支店次長 がこれらの２つの鍵を使う権限があるため、開けることができるとすると、検査では、「問題なし」になるが、監 査では、「問題あり」になる。 先端内部監査研究会 著 「これが金融機関の内部監査だ」 金融財政事情研究会 より 金庫 入口 金庫室 ページ Institute of Information Security 10 金融機関における 情報セキュリティトラブル Katsuya Uchida [email protected] 過去の事件・事故から学ぶ情報セキュリティ アウトソースについて z 理解不能な回答（東証で事故） 以下のシステムダウンが発生した原因を特定できるでしょうか？ システム不良が生じた原因は、以下のとおりであることが判明いたしました。 ¾ ¾ ¾ ¾ ページ 今般実施した売買システムの注文処理能力の増強対応において、当該対応に係る作業中、参加者 データファイルに関するプログラムに以前から潜在していた不良（バグ）を発見したため、富士通にお いて、１０月９日、当取引所が確認のうえ、当該箇所の修正を行いました。 この後、１０月１３日に、修正後のプログラムを売買システム中に正規登録する作業に際し、富士通か ら作業担当である株式会社東証コンピュータシステムへ送付した当該作業に係る資料において、必要 な項目の一部について記載漏れがありました。 この結果、正規登録後のシステム構成が正規プログラムと旧プログラムが混在する誤った構成となり、 １０月３１日のディスク圧縮整理処理において、当該システム不良が発現することとなりました。 １０月１４日から３１日までの間不良が発生しなかったのは、旧プログラムがそのまま存在し稼動した ためであります。また、１１月１日に不良が発現しましたのは、圧縮整理処理の過程で、旧プログラム の所在（属性）をシステムが自動感知し、正規プログラムとの関係を切除したためであります。 Institute of Information Security 11 6 Katsuya Uchida [email protected] 金融機関における 情報セキュリティトラブル 過去の事件・事故から学ぶ情報セキュリティ アウトソースについて 参考： 米国での情報セキュリティのアウトソース割合 z アウトソースしているセキュリティ機能の割合 80% ( Percentage of Security Function Outsourced ) 70% ６３％ 60% 50% 40% ２６％ 30% 20% ６％ 10% 0% ２％ なし 1-20% 21-40% 41-60% ２％ 61-80% ０％ 81-100% 2005 CSI/FBI Computer Crime and Security Survey http://www.gocsi.com/ Institute of Information Security 12 ページ 金融機関における 情報セキュリティトラブル Katsuya Uchida [email protected] 過去の事件・事故から学ぶ情報セキュリティ 情報セキュリティ を考える 情報セキュリティを考える z 金融機関は、最大の情報処理産業であるが、その認識が低いのではないか？ z 情報セキュリティは、性悪説的ツールなんだろうか？ ＩＳＰ情報漏洩事件（2003年）： 社長は「いままで性善説でやってきたが、従業員を疑う性悪説に変わらざる を得ない」と感想を述べた。 性善説 はマネジメント不在と同等か？ なお、性悪説＝従業員を信じない！ コンビニ情報漏洩（2003年）： 個人情報にアクセスできるのは、社内と委託会社の特定のコンピューター約 １０台だけで、パスワードを知っているのは社内と委託会社で計２０人 この企業の役員は、２０人の中の犯人でない人の気持ちを考えたことがあるだろうか？ ⇒ ユーザＩＤ を個人に配布する仕組みを考える必要がある z 情報が金融機関の商品であり、現金ではない。 商品の瑕疵を金融機関が見逃していれば、顧客は どう対応するだろうか？ z 画一的なサービスが、サービスではないはず。 個別サービスを行うためには、情報セキュリティは欠 かせないもの z 安全・安心、信頼を得るには、顧客に納得した形で見せることが大切。 金融機関だから安心して任 せられる環境が崩壊しているのではないか。 ページ Institute of Information Security 13 7 Katsuya Uchida [email protected] 金融機関における 情報セキュリティトラブル ありがとうございました 過去の事件・事故から学ぶ情報セキュリティ 学長 教授 辻井 重男 副学長 教授 林 紘一郎 http://www.iisec.ac.jp/ 情報セキュリティ大学院大学 兼 中央大学 研究開発機構 助教授 内田 勝也 [email protected] http://www2.gol.com/users/uchidak/ ページ Institute of Information Security 14 8 Katsuya Uchida [email protected]