本記事では、セキュリティ関連の非営利団体JPCERT/CCが、基本的におさえておくべきセキュリティ技術やコンピュータセキュリティ・インシデント(不正アクセス)に関する情報を紹介する。(編集局)
近年のインターネットの普及、特に「ブロードバンド」と呼ばれる高速通信網の一般家庭への普及には目を見張るものがある。
しかし、それに伴い、「コンピュータセキュリティ・インシデント」 の発生件数も増大の一途をたどっている。特に昨年のCodeRedやNimdaといったワームによる被害は広範囲にわたり、これまで「セキュリティ」といったものをほとんど意識することのなかった一般のユーザーにも「セキュリティ」の重要性が認知されだしたことは記憶に新しいところだろう。
そのような中で、
インシデントレスポンス(Incident Response)
||
コンピュータセキュリティ・インシデントに対応すること
の重要性も認知されつつある。
しかしながら「インシデントレスポンス」として一体何を、どのようになすべきなのか? といった根本的な部分での理解はまだまだ十分に広まっていない状態であると思われる。
そこで今回から数回にわたり、「インシデントレスポンス」をテーマに、具体的な例を挙げながら管理者である読者に向けた解説をしていく。
今回は「インシデントレスポンス」の概要を簡単に説明する。
「コンピュータセキュリティ・インシデント」とは、具体的にどのような事象を指すのだろうか? 「Computer Security Incident」を直訳すれば、「コンピュータセキュリティに関連した事件、出来事」といった意味になるが、JPCERT/CCのFAQでは、
コンピュータセキュリティに関係する人為的事象で、意図的および偶発的なもの(その疑いがある場合)を含む。
例えば、リソースの不正使用、サービス妨害行為、データの破壊、意図しない情報の開示や、さらにそれらに至るための行為(事象)などがある。
と説明している。
このような事象を表す用語として、一般的には「不正アクセス」という言葉が使われている。しかし「不正アクセス」には、スキャンやプローブ(探針)といった弱点探索は含まれないことが「不正アクセス禁止法」によって定義されている。
また「不正」という言葉は、「悪意のある」や「正常でない」といったさまざまな意味を含んで使われることがある。そこで本連載では、あいまいな意味で使われることのある「不正アクセス」ではなく、「コンピュータセキュリティ・インシデント」(以下インシデント)という用語を用いる。この用語はRFC(Request For Comments)の文書に用いられるなど、世界的に広く使われている用語だ。
インシデントにはさまざまな種類がある。それらのインシデントをJPCERT/CCでは以下の6つのタイプに分類している。
一般に「セキュリティ」について語られる場合は、事前の「防御」に主眼が置かれている。一方、「インシデントレスポンス」には、「事前の対応」という意味での「防御」も含まれるが、それ以上に「事後の対応」が重要な位置を占めている。
例えば、発生したインシデントの原因の追究や分析、被害を受けたシステムの復旧、再発の防止などが含まれる。
しかしここで1つの疑問を投げ掛ける人もいるだろう。
防御を完璧にしていれば、事後のことなど考える必要はないのでは?
近年のセキュリティ技術の進歩、そしてその普及の度合いは、インターネットの普及同様に目覚しいものがあることは事実だ。例えば、ウイルス検知ソフトやIDS(Intrusion Detection System:侵入検知システム)の導入は(まだまだ十分とはいえないものの)数年前とは比較にならないほど浸透してきている。また、重要なデータを暗号化して保存したり、通信路を暗号化するなどの方法はすでに広く一般に使われている。
しかし本当にそれで十分なのだろうか?
現在、一般に用いられているソフトウェアの多くはとても複雑に作られている。従って、開発者ですら気が付かないようなセキュリティ上の弱点(脆弱性)が何かのきっかけで新たに見つかる可能性もあるのだ。つまり、使用しているソフトウェアのセキュリティ関連情報を注意深く収集して既知の脆弱性に対する防御策を「完璧」に講じていても、公になっていない未知の脆弱性を使ったインシデントが「絶対に発生しない」とはいえない。
大事なポイントは、
各サイトのセキュリティポリシーに応じた適切なセキュリティ技術や製品を導入して、それらを適切に運用するとともに、近い将来発生し得るインシデントに備えて、事前に対応手順を明確にし、その手順に従った運用を行う
ということだ。
例えば、「事後の対応」として「事前に」検討および確認すべき項目には、以下のようなものがある。
なお、これらの項目はあくまで一例なので、各企業のサイトのポリシーなどに合わせて適宜読み替えてほしい。
これらの手順やポリシーを明確化することにより、インシデントによる被害を受けても、より短い時間でシステムを復旧することが可能となる。また、同様のインシデントの再発を防ぐことにもつながるのだ。
今回は「インシデントレスポンス」のうち、特に「事後の対応」のために「事前に」検討すべき項目を紹介した。次回はこれらのうち、「インシデントを発見する方法」について具体的に解説していく。
JPCERT/CCは日本の代表的なCSIRTだが、それではCSIRTとはどういった組織なのだろうか? ここでは、世界最初のCSIRTである米国CERT/CCによるCSIRTについてのFAQを基に簡単に解説する。
Computer Security Incident Response Team(CSIRT)Frequently Asked Questions(FAQ)
CSIRTの活動、特にJPCERT/CCが具体的にどのようにインシデント対応業務を行っているかについては次回以降のコラムで紹介する。
JPCERT/CCとは、Japan Computer Emergency Response Team/Coordination Center(コンピュータ緊急対応センター)の略称。非営利団体で、特定の政府機関や企業からは独立し、中立の組織として活動している。JPCERT/CCは、インターネットを介して発生する、侵入やサービス妨害などのコンピュータセキュリティ・インシデントについて、日本国内のサイトに関する報告の受け付け、対応の支援、発生状況の把握、手口の分析、再発防止のための対策の検討と助言などを、技術的な立場から行っている。FIRSTに加盟している日本唯一のCSIRTである。
Copyright © ITmedia, Inc. All Rights Reserved.