IP電話

タイトル	対象	目的別カテゴリ	掲載号
IP電話のセキュリティ		インシデント発生前の予防	2005-11-16号

IP 電話はインターネットの技術を使用しているため、PC などと同様に、ウィルスやワームに感染したり、サービス運用妨害 (DoS) 攻撃を受けたりするなどのセキュリティ上の脅威にさらされていることを認識する必要があります。

使用している IP 電話のソフトウェアやモデムなどのネットワーク機器のファームウェアを常に最新のバージョンにしておくなど、PC と同様の運用形態を取ることを強くお勧めします。

参考文書（日本語）

1. US-CERT Cyber Security Tip ST05-018
2. Understanding Voice over Internet Protocol (VoIP)
3. http://www.us-cert.gov/cas/tips/ST05-018.html

Topへ

Java

タイトル	対象	目的別カテゴリ	掲載号
インストールされた Java のバージョンの確認		インシデント発生前の予防	2009-02-25号

Sun は java.com のサイトで、PC にインストールされている Java のバージョンを確認できる Web ページを公開しています。java.com の Web ページでは、アクセスしている PC に最新のソフトウエアがインストールされているかを確認し、Sun の推奨する Java をインストールすることが可能になっています。

なお、このページでは複数のバージョンがインストールされている場合、最新のバージョンのみが表示されます。古いバージョンを必要としない場合は、アンインストールすることを推奨します。

参考文書（日本語）

1. Java
2. Java ソフトウェアのインストール状況の確認
3. http://java.com/ja/download/installed.jsp

Topへ

NTP サービス

タイトル	対象	目的別カテゴリ	掲載号
時刻合わせ		保守・管理について	2004-07-28号

ホストの時刻情報が不正確では、ログ等からインシデント発生に関わる事実関係を確認することが困難になります。そこで NTP (Network Time Protocol) を使って時刻を正確に合わせることが推奨されます。

なお、インターネット接続プロバイダ (ISP) によっては、顧客に対して NTP サービスを提供している場合があります。利用している ISP が NTP サービスを提供しているか否かを確認してみることをお勧めします。

参考文書（日本語）

1. 独立行政法人 情報通信研究機構 日本標準時グループ
2. http://jjy.nict.go.jp/

参考文書（英語）

1. ntp.org: Home of the Network Time Protocol
2. http://www.ntp.org/
3. OpenNTPD
4. http://www.openntpd.org/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
NTPサーバの選択		保守・管理について	2005-01-26号

ホストの時刻合わせに NTP (Network Time Protocol) を使用する場合、NTP サービスを提供しているサーバの選択には注意が必要です。広く一般に公開されている NTP サーバは、アクセスが集中することが多く、正確な時刻に同期できない場合があります。利用している ISP が顧客向けに提供している NTP サービスを使ったり、または各組織で NTP サービスを組織内向けに中継する NTP サーバを立ち上げたりするなどの対応が推奨されます。

参考文書（日本語）

1. JPCERT/CC REPORT 2004-07-28号 の [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2004/wr042901.txt

Topへ

SCADA

タイトル	対象	目的別カテゴリ	掲載号
SCADA		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-09-27号

SCADA (Supervisory Control And Data Acquisition) は、監視・制御データ収集を目的としたシステム全般を指し、小規模システムから大規模プラントまで産業分野に広く用いられています。

製造、生産を行う設備の動作状況などを収集し、プロセス制御システムとともに、製造、生産工程を遠隔から監視・制御するシステムの一部となります。

かつては、独自のシステムが多く利用されていましたが、最近では、オープン系の技術が取り入れられており、脆弱性管理などのオープン系の技術に関するセキュリティ対策の考慮が重要になってきています。

参考文書（日本語）

1. JPCERT Coordination Center
2. グッド・プラクティス・ガイド　プロセス・制御と SCADA セキュリティ
3. http://www.jpcert.or.jp/research/index.html#scada

参考文書（英語）

1. CPNI: Centre for the Protection of National Infrasructure
2. SCADA
3. http://www.cpni.gov.uk/ProtectingYourAssets/scada.aspx
4. US-CERT
5. Control Systems
6. http://www.us-cert.gov/control_systems/

Topへ

SPAMメール

タイトル	対象	目的別カテゴリ	掲載号
メール送信元の詐称		インシデント発生前の予防	2005-06-15号

電子メールは仕組み上、送信元を詐称することが容易にできてしまいます。最近の迷惑メールの中には、送信元そのもの (From: 欄) を詐称するだけでなく、Received: ヘッダなどのヘッダ情報を偽造して送信元 (送信経路) を詐称しているものがあります。

迷惑メールなどの電子メールの送信元に連絡する場合は、上記のような可能性があることを充分に考慮した上で、自組織のポリシーに照らして適切と判断される対応をとることを強くお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ソフトウェアベンダを騙った不審なメールに注意		インシデント発生前の予防	2006-08-02号

知名度の高いソフトウェアベンダなどを騙り、注意や警告を装ったメールが送信されることがあります。これらのメールは、スパイウェアやウィルス、トロイの木馬といった、不審なソフトウェアをインストールさせることを目的としていることが知られています。

受けとったメールについては、電子署名の有無や正当性、送信者や内容などをよく確認するなどして、むやみにメールに記載されたリンクを辿ったり、メールに添付されたファイルを開いたりしないよう注意しましょう。

参考文書（日本語）

1. JPCERT/CC REPORT 2004-06-16号の「一口メモ」
2. 電子署名
3. http://www.jpcert.or.jp/wr/2004/wr042301.txt
4. JPCERT/CC REPORT 2005-06-15号の「一口メモ」
5. メール送信元の詐称
6. http://www.jpcert.or.jp/wr/2005/wr052301.txt

Topへ

Web

タイトル	対象	目的別カテゴリ	掲載号
Referer リクエストヘッダの削除		インシデント発生前の予防	2005-03-24号

ある Web ページにアクセスする際に、どのページのリンクをたどって、そのページにアクセスしたかを Web ブラウザがサーバに伝えるためのヘッダ情報である「Referer リクエストヘッダ」によって LAN 内の情報が外部に漏れてしまうことがあります。Web ブラウザによっては、この「Referer リクエストヘッダ」を一切送信しないように設定できるものがありますが、Web サイトによっては Web ブラウザが「Referer リクエストヘッダ」を送信しないと正常に表示/動作しない場合があります。

そこで LAN 内の情報だけを削除し、それ以外の「Referer リクエストヘッダ」だけを送信するように proxy サーバに設定することが推奨されます。例えば、Squid では、acl (Access Control List) で以下のような設定をすることで、特定の文字列で構成される「Referer リクエストヘッダ」のみを送信しないようにすることができます。

1. acl internal referer_regex -i ^http://[^/]+\.example\.jp ^http://192\.168\. ^[a-z]:\\
2. ^file:header_access Referer deny internal
3. 「Referer リクエストヘッダ」の詳細については、以下の参考文献をご参照ください。

参考文書（英語）

1. Hypertext Transfer Protocol -- HTTP/1.1
2. http://www.ietf.org/rfc/rfc2616.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web ブラウザの選択		インシデント発生前の予防	2004-11-25号

Web ページや HTML ファイルなどを閲覧するためのソフトウェアである Web ブラウザには様々な種類が存在します。例えば代表的なものとして以下のようなソフトウェアがあります。

1. - Microsoft Internet Explorer
2. - Mozilla
3. - Firefox
4. - Opera
5. - Safari
6. - Lynx
7. - w3m

Web ブラウザの選択にあたっては、以下のような点に注意することが推奨されます。

1. -自分が使用している OS で動作するか?
2. -自分が必要とするセキュリティレベルを提供できるか?
3. -自分にとって使いやすいか? - 自分が必要とする機能を有しているか? プラグインで対応可能か?
4. -自分にとって視覚的な面などインタフェースが魅力的か?

また Web ブラウザの中には、既存のブラウザを内部で使用し、インタフェースだけを変えているものもあるという点に留意してください。このような Web ブラウザは、内部で使用しているブラウザの特性 (脆弱性など) による影響をそのまま受ける可能性があるので注意が必要です。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-022
2. Understanding Your Computer: Web Browsers
3. http://www.us-cert.gov/cas/tips/ST04-022.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Firefox 拡張機能 その1 NoScript		インシデント発生前の予防	2007-12-05号

Mozilla Firefox は Mozilla Foundation が開発しているオープンソースの Web ブラウザです。現在、Windows、Mac OS X 及び Linux をはじめとする Unix 系 OS 上で使用することが可能です。

Mozilla Firefox はユーザが拡張機能をインストールすることで、標準では備わっていない様々な機能を使用することができます。ここでは、セキュリティ強化に役立つ拡張機能をご紹介します。

NoScript は信頼するサイトに置かれている JavaScript のみを実行するための拡張機能です。ユーザの操作によりドメイン名のホワイトリストを作り、リストに記載されたサイトにある場合のみ JavaScript の実行を許可します。ホワイトリストへの追加削除は Firefox の GUI で簡単に行うことが可能です。

また JavaScript 以外にも Java, Flash, Microsoft Silverlight などの実行を JavaScript と同様の原理で制限することが可能です。

例えば Mpack などのように、JavaScript を使った攻撃に対して有効です。

参考文書（日本語）

1. Mozilla Firefox Add-ons
2. NoScript
3. https://addons.mozilla.org/ja/firefox/addon/722
4. JPCERT/CC Alert 2007-06-28
5. 複数の脆弱性を使用する攻撃ツール MPack に関する注意喚起
6. http://www.jpcert.or.jp/at/2007/at070016.txt

参考文書（英語）

1. NoScript
2. JavaScript/Java/Flash blocker for a safer Firefox experience! - what is it? - InformAction
3. http://noscript.net/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web ブラウザ tips: Opera/Safari 編		インシデント発生前の予防	2008-05-28号

安全が確認できていない Web サイトを閲覧する際には Javascript 機能を無効にすることが推奨されます。

Windows 版 Opera の場合、「ツール」→「クイック設定」と辿ったメニューに「Javascript を有効にする」チェックがあり、デフォルトで ON になっています。この項目を選択することで Javascript 機能の ON/OFF を行なうことができます。

Windows 版 Safari の場合、「編集」→「設定」→「セキュリティ」と辿ったメニューに「Javascript を有効にする」チェックがあり、デフォルトで ON になっています。

Safari において、より簡単に Javascript 機能の ON/OFF をするためには、メニューバーに[開発]メニューを表示させると便利です。「編集」 →「設定」→「詳細」と辿ったメニューで「メニューバーに[開発]メニューを表示」にチェックを入れることにより「開発」メニューを表示させることができます。「開発」メニューのなかに「Javascript を無効にする」という項目があり、この項目を選択することで Javascript 機能の ON/OFF を行なうことができます。

参考文書（英語）

1. CERT/CC Tech Tips
2. Securing Your Web Browser
3. http://www.cert.org/tech_tips/securing_browser/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web ブラウザのプラグイン更新に関する注意		インシデント発生前の予防	2008-01-17号

Firefox や Opera など複数の Web ブラウザをインストールしている場合には、Web ブラウザ向けのプラグインの更新に注意が必要です。

ある機能のプラグインが複数の Web ブラウザ向けに別々に提供されている場合、普段使っている Web ブラウザ向けのプラグインを更新しても、他の Web ブラウザ向けのプラグインは更新されていない可能性があります。

このようなプラグインの例として、Adobe が提供する Flash Player や Shockwave Player などがあります。

脆弱性のある古いバージョンのプラグインが残っていると、他の脆弱性やソーシャルエンジニアリングなどの手法を組み合せることで、攻撃に使用される可能性があります。普段は使わない Web ブラウザであっても更新作業を適切に行なうか、不要であれば削除するなどの対策を行なうことが重要です。

参考文書（日本語）

1. Mozilla Japan ナレッジベース
2. Flash Player の更新に関する注意喚起
3. http://www.mozilla-japan.org/kb/solution/2092
4. Microsoft Windows XP 活用ガイド
5. Internet Explorer アドオンの管理機能を使用したアドオンの管理
6. http://www.microsoft.com/japan/windowsxp/using/web/
   sp2_addonmanager.mspx
7. Microsoft Windows Vista ヘルプ
8. Internet Explorer のアドオン : よく寄せられる質問起
9. http://windowshelp.microsoft.com/Windows/ja-JP/Help/e85a03aa-c7c6-428e-9891-67ea76df9b7e1041.mspx
10. Apple - サポート
11. Safari 3.0 Help: プラグインについて
12. http://docs.info.apple.com/jarticle.html?path=Safari/3.0/jp/9289.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web を利用する場合の注意事項		インシデント発生前の予防	2005-01-06号

Web ブラウザを使って Web ページにアクセスする場合には以下の点に注意することが推奨されます。

1. - 最新のセキュリティ修正を施されたブラウザを使用する。
2. - リアルタイムにウィルスやスパイウェアを検索するアンチウィルスソフトウェアを導入する。
3. - 安全であることが確認できないページにはアクセスしない。
4. - 安全であることが確認できないページにアクセスする場合は、ブラウザのセキュリティ設定を確認し、可能な限り安全な設定でアクセスする。

※「セキュリティ設定」には以下のような項目があります。

1. - JavaScript、Java や ActiveX などの無効化
2. - ポップアップウィンドウの抑制
3. - 画像の自動読み込み抑制
4. - クッキーの無効化
5. など

参考文書（日本語）

1. JPCERT/CC REPORT 2004-08-11号 の [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2004/wr043101.txt
3. JPCERT/CC REPORT 2004-11-25号 の [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2004/wr044601.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web サイトの信頼性		インシデント発生前の予防	2005-06-01号

技術的な手段で Web サイトの真偽を確認できた、ということは、Web サイトを運営している組織 (または個人) の信頼性が保証されたということにはなりません。これらの項目は、技術的な手段によらず、別途確認する必要があります。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-05-18号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr051901.txt
3. JPCERT/CC REPORT 2005-05-25号 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2005/wr052001.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-010
2. Understanding Web Site Certificates
3. http://www.us-cert.gov/cas/tips/ST05-010.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
アドオン機能なしで Internet Explorer 7 を起動する		インシデント発生時の対処	2008-08-13号

Internet Explorer では、ActiveX コントロールやブラウザヘルパーオブジェクトなどのアドオンによって様々な機能を追加することができます。一方で、マルウェアの中にはアドオン機能を使用したものも存在しており、注意が必要です。

導入したアドオンに問題があった場合、一時的にアドオンを読み込まない状態で Internet Explorer を立ち上げて、問題のあるアドオンを削除することができます。

スタート -> すべてのプログラム -> アクセサリ -> システムツール -> Internet Explorer (アドオンなし)

この状態では、ツール -> アドオンの管理 が使えなくなっていますが、

ツール -> インターネットオプション -> プログラム -> アドオンの管理

と辿ると、アドオンの管理機能を使うことができ、問題となるアドオンを無効にすることができます。

なお、これらの設定はアドオンだけを無効化し、JavaScript など他の動的コンテンツの機能については無効にはなりません。信頼できないサイトを閲覧する際にはこの方法だけでは不十分ですので、注意してください。

参考文書（日本語）

1. Windows Vista ヘルプ
2. Internet Explorer のアドオン : よく寄せられる質問
3. http://windowshelp.microsoft.com/Windows/ja-JP/help/e85a03aa-c7c6-428e-9891-67ea76df9b7e1041.mspx

Topへ

タイトル	対象	目的別カテゴリ	掲載号
不特定ユーザ向けのプロキシサーバに注意		インシデント発生前の予防	2007-01-24号

プロキシサーバは通常、企業や組織の管理者によって、自組織内や自社の顧客といった特定のユーザ向けに提供されています。一方で、信頼性の不明なサービス提供元によって、不特定のユーザに向けて提供されているプロキシサーバも存在します。

このようなプロキシサーバの使用は、Web サーバとの通信を傍受されたり、本来意図していないサイトにアクセスさせられたりする可能性があるため、使用の際には慎重を期す必要があります。

なお、プロキシサーバの中には、特定の URL を入力するだけでプロキシとして機能し、ブラウザへの設定の必要がないものもあります。Web サイトの閲覧中は、アクセスしている URL に常に注意するようお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
マイクロソフトが SQL インジェクション対策ツールを公開		インシデント発生前の予防	2008-07-02号

SQL インジェクションによる Web サイト改ざんが増加していることを受けて、マイクロソフトは、これらの影響を受ける可能性のある Web アプリケーションの特定および修正を支援するセキュリティアドバイザリを公開しています。

また、あわせて ASP コード中に含まれる SQL インジェクションの脆弱性を検知するツール Microsoft Source Code Analyzer for SQL Injection を公開しています。

参考文書（日本語）

1. マイクロソフト セキュリティ アドバイザリ (954462)
2. ユーザー データ入力の未検証を悪用した SQL インジェクション攻撃の増加
3. http://www.microsoft.com/japan/technet/security/
   advisory/954462.mspx
4. Microsoft サポートオンライン
5. ASP コードに存在する SQL インジェクションに対する脆弱性を検出する Microsoft Source Code Analyzer for SQL Injection ツールについて
6. http://support.microsoft.com/kb/954476
7. JPCERT/CC Alert 2008-03-14
8. SQL インジェクションによる Web サイト改ざんに関する注意喚起
9. http://www.jpcert.or.jp/at/2008/at080005.txt

Topへ

アクセス制御

タイトル	対象	目的別カテゴリ	掲載号
任意アクセス制御と強制アクセス制御		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-03-14号

ファイルなどのリソースに対するアクセス制御方式には、大きく分けて任意アクセス制御 (DAC: Discretionary Access Control) と強制アクセス制御 (MAC: Mandatory Access Control) とがあります。

任意アクセス制御は、リソースの所有者にアクセス制御を任せる方式です。任意アクセス制御の代表的な例としては、Unix 系 OS などで実装されているファイルパーミッションが挙げられます。また、一部の OS におけるファイルシステムには拡張機能として POSIX 準拠の ACL (Access Control List) が実装され、ファイルパーミッションより細かな制御を実現していますが、これも任意アクセス制御の一種です。

一方、強制アクセス制御は、リソース所有者の意図に関らず、システムの管理者により一定のアクセス制御を強制する方式です。この場合のアクセス制御ルールはいわゆる管理者権限を持ったユーザに対しても適用されること、リソース所有者の権限では変更できないことなどが特徴として挙げられます。例としては SELinux、TOMOYO Linux、Trusted BSD や Trusted Solaris などが挙げられます。

参考文書（日本語）

1. 日本SELinuxユーザー会
2. http://www.selinux.gr.jp/
3. TOMOYO Linux
4. http://tomoyo.sourceforge.jp/
5. Sun Microsystems
6. Trusted Solaris オペレーティングシステム
7. http://jp.sun.com/products/software/solaris/trustedsolaris/

参考文書（英語）

1. National Security Agency/Central Security Service (NSA/CSS)
2. Security-Enhanced Linux
3. http://www.nsa.gov/research/selinux/index.shtml
4. TrustedBSD Project
5. TrustedBSD
6. http://www.trustedbsd.org/

Topへ

新しいコンピュータの接続

タイトル	対象	目的別カテゴリ	掲載号
新しいコンピュータをインターネットに接続する前に		インシデント発生前の予防	2004-05-26号

新しいコンピュータ (クライアント PC およびサーバ) を導入した場合、または OS を更新した場合には、標準の状態のままインターネットに接続することは避けるべきと考えられています。理由として以下のような点が挙げられます。

1. - 標準設定が安全でない場合が多い。
2. - 製品やソフトウェアのメディアが作成されてから現在までの間にセキュリティ上の問題が発見・公開されている場合がある。
3. - 上記のセキュリティ上の問題を使った攻撃手法が既に公開されていたり、それを使って感染するワームが発生していたりする場合がある。

新規導入後または更新後は、できるだけ速やかに、まず以下の作業を行なうことが推奨されます。

1. - 不要なサービスの停止。
2. - 最新のセキュリティパッチの適用。

なお、パッチの適用時にインターネットに接続する必要がある場合は、必ずファイアウォールなどで外部からのアクセスが制限された状態で行なってください。

参考文書（英語）

1. CERT/CC Tech Tip
2. Before You Connect a New Computer to the Internet
3. http://www.cert.org/tech_tips/before_you_plug_in.html

Topへ

暗号/電子署名

タイトル	対象	目的別カテゴリ	掲載号
DNSSEC (Domain Name System Security Extensions)		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-09-03号

DNSSEC とは、公開鍵暗号技術を利用して DNS データに署名を行い、DNS データ提供元の正当性を確認したり DNS データの改竄を検知できるようにする仕組みです。もともとの DNS プロトコルにはこのような仕組みがなく、キャッシュポイズニングなどの危険性が指摘されています。今年 7月には効率的にキャッシュポイズニングを行なう手法が公開されて大きな話題になりました。

近年、DNSSEC に対応した実装は増えていますが、実環境における普及はまだ進んでいません。実運用における問題点もいくつか指摘されており、プロトコルレベルでの改良も進められています。

参考文書（日本語）

1. JPNIC
2. インターネット用語1分解説～DNSSECとは～
3. http://www.nic.ad.jp/ja/basics/terms/dnssec.html

参考文書（英語）

1. DNSSEC: DNS Security Extensions
2. http://www.dnssec.net/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
DNSSEC Lookaside Validation (DLV)		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-09-10号

DNSSEC では、各ゾーンの権威 (authoritative) サーバが使う鍵は上位ゾーンの権威サーバによって署名され保証されます。

DNS ツリーのルート以下全てのゾーンが DNSSEC に対応していれば、リゾルバが持つべき鍵はルートゾーンの署名に使われる鍵ひとつとなります。しかし DNSSEC が普及していない現状では、DNSSEC に対応している個々のゾーンの鍵を各リゾルバが持っておく必要があり、DNSSEC に対応したゾーンが増えればそれだけ鍵の管理の手間も大きくなります。

このような状況に対応するための暫定的な仕組みとして、ISC (Internet Systems Consortium) では DNSSEC Lookaside Validation(DLV) という技術を提唱しています。

DLV に対応したリゾルバは、上位のゾーンで提供されるべき DS (Delegation Signer) レコードが見つからない場合に、あらかじめ設定しておいたドメインから DLV レコードを参照して DS レコードの代わりに使います。このようにして、トップレベルドメインまで DNSSEC 対応が完了していない状態でも、リゾルバ側ではごく少数の鍵を持つだけで署名を検証できるようにする仕組みを実現しています。

ISC では、BIND のバージョン 9.3.3 以降で DLV に対応するとともに、DLV Registry を運用しています。

参考文書（日本語）

1. JPCERT/CC REPORT 2008-09-03
2. 【今週のひとくちメモ】DNSSEC (Domain Name System Security Extensions)
3. http://www.jpcert.or.jp/wr/2008/wr083401.html#Memo

参考文書（英語）

1. ISC
2. ISC's DLV registry
3. https://secure.isc.org/ops/dlv/
4. RFC4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record
5. http://tools.ietf.org/html/rfc4431
6. RFC5074: DNSSEC Lookaside Validation (DLV)
7. http://tools.ietf.org/html/rfc5074

Topへ

タイトル	対象	目的別カテゴリ	掲載号
DNSSEC の導入に向けた動き		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-09-18号

SE (スウェーデン) をはじめ、いくつかの ccTLD (Country Code Top Level Domain) ではすでに DNSSEC 対応が行われています。また、GOV、ORG、および ARPA ドメインにおいても対応が表明されています。

前回紹介した ISC の DLV registry のように、DNS ツリーの外から署名鍵を提供するための仕組みを、一般に TAR (Trust Anchor Registry) と呼びます。ISC 以外に RIPE や SecSpider project、IKS といった組織による活動があり、現在は IANA で TAR を立ち上げる計画が進んでいます。

今年6月にパリで開催された ICANN 第32回会議では DNSSEC に関するトピックを集めた DNSSEC Public Meeting が開催されました。

参考文書（日本語）

1. JPCERT/CC REPORT 2008-09-03
2. 【今週のひとくちメモ】DNSSEC (Domain Name System Security Extensions)
3. http://www.jpcert.or.jp/wr/2008/wr083401.html#Memo
4. JPCERT/CC REPORT 2008-09-10
5. 【今週のひとくちメモ】DNSSEC Lookaside Validation (DLV)
6. http://www.jpcert.or.jp/wr/2008/wr083501.html#Memo

参考文書（英語）

1. DNSSEC Deployment Initiative
2. http://www.dnssec-deployment.org/
3. DNSSEC Deployment Initiative
4. STATEMENT OF NEEDED INTERNET CAPABILITY: Trust Anchor Repositories
5. http://www.dnssec-deployment.org/tar/tarpaper.pdf
6. IANA
7. (DEMO) DNSSEC STATUS
8. https://ns.iana.org/dnssec/status.html
9. ICANN
10. DNSSEC Public Meeting
11. http://par.icann.org/en/node/77
12. ccNSO IANA WG:
13. DNSSEC BRIEFING and Root Zone Signing (Part I)
14. http://ccnso.icann.org/workinggroups/ccnso-iana-wg-dnssec-paper-04feb08.pdf

Topへ

タイトル	対象	目的別カテゴリ	掲載号
OpenSSH の実験的機能 VisualHostKey		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-12-25号

OpenSSH v5.1 から、SSH サーバホスト鍵のフィンガープリントをより人間が判別しやすいアスキーアートとして表示される機能が実験的に加えられました。

初めて SSH サーバに接続する際には、SSH サーバホスト鍵のフィンガープリントを確認し、自分が接続すべきサーバと通信を行っていることを確認することが重要です。

VisualHostKey=yes というオプションを利用してホストに接続すると以下のようなアスキーアートが表示されます。

user[~]: ssh -o VisualHostKey=yes host1
Host key fingerprint is df:f1:91:2d:fb:7e:f3:0a:38:71:20:91:e9:3c:ee:60
+--[ RSA 1024]----+
|        ... .    |
|       . +.B   . |
|        . O.X o  |
|         + B.O   |
|        S o.=    |
|         .E      |
|         .       |
|                 |
|                 |
+-----------------+

本機能はランダムな文字列を可視化し、人間にとって覚えやすい形で提示することを目指したユニークな機能です。

参考文書（英語）

1. OpenSSH
2. OpenSSH 5.1/5.1p1
3. http://www.openssh.com/txt/release-5.1

Topへ

タイトル	対象	目的別カテゴリ	掲載号
PDF (Portable Document Format) における電子署名		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-10-16号

文書形式としての PDF は 1993年にバージョン 1.0 が発表されました。出力文書形式として普及が進むとともに機能追加が行われ、現在はバージョン 1.7 が最新版となっています。2008年7月には PDF バージョン 1.7 が ISO 規格 ISO32000-1 として承認されました。

1999年6月に発表された PDF バージョン 1.3 からは、電子署名機能が取り入れられています。PDF ファイルに電子署名を施しておくことで、閲覧時に内容の改竄が行われていることを検出できるようになります。

電子署名により、署名者に関する情報やタイムスタンプ (文書作成時刻) 情報を記録することも可能です。PDF ファイルのような「電磁的記録」に対する電子署名は、多くの国において、手書き署名と同等の効力を持つものとして扱われるようになっています。

参考文書（日本語）

1. Adobe と PDF
2. http://www.adobe.com/jp/products/acrobat/adobepdf.html
3. 総務省の情報通信政策に関するポータルサイト
4. 電子署名・電子認証ホームページ
5. http://www.soumu.go.jp/joho_tsusin/top/ninshou-law/law-index.html
6. 【今週のひとくちメモ】インターネットセキュリティの歴史
7. 第15回 「『電子認証』関連法制度－電子署名・認証業法」
8. https://www.jpcert.or.jp/wr/2008/wr081403.html#Memo
9. 【今週のひとくちメモ】インターネットセキュリティの歴史
10. 第16回 「『電子認証』関連法制度－IT 書面一括法、e-文書法」
11. https://www.jpcert.or.jp/wr/2008/wr081601.html#Memo

参考文書（英語）

1. Adobe - PDF Developer Center: PDF reference
2. http://www.adobe.com/devnet/pdf/pdf_reference.html
3. ISO32000-1:2008
4. http://www.iso.org/iso/iso_catalogue/catalogue_tc/
   catalogue_detail.htm?csnumber=51502

Topへ

タイトル	対象	目的別カテゴリ	掲載号
PDF に電子署名を行う/検証する		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-10-22号

1. 電子署名を行う

PDF ファイルに電子署名を行うためには、署名に使う証明書/秘密鍵を用意する必要があります。Adobe Acrobat では、認証局から発行された証明書/秘密鍵を使用する方法と、独自に自己署名証明書を生成して使用する方法があります。

Adobe Acrobat では電子署名として「承認用署名」と「証明用署名」の2種類があります。これは、ISO32000-1 仕様における document signature (承認用署名) と MDP signature (証明用署名) に対応するものです。

2. 電子署名を検証する

Adobe Acrobat や Adobe Reader では証明書リポジトリを独自に持っており、電子署名の検証に使う証明書については、Windows の証明書ストアや LDAP サーバなどを参照することもできます。

適切な証明書を取り込んであり、取り込んだ証明書に対する信頼度の設定も適切に行われているにも関わらず検証結果が無効と出る場合には、PDF ファイルが改竄されている可能性が高いと判断することができます。

参考文書（日本語）

1. JPCERT/CC REPORT 2008-10-16
2. 【今週のひとくちメモ】PDF (Portable Document Format) における電子署名
3. http://www.jpcert.or.jp/wr/2008/wr084001.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
TCP MD5 Signature Option		インシデント発生前の予防	2004-05-26号

経路情報の交換において、IP アドレス詐称やデータ偽造などに影響されずに安全に運用するために、MD5 チェックサムの検証機能を有効にすることが推奨されています。特に BGP (Border Gateway Protocol) での使用を強くお勧めします。

参考文書（英語）

1. Protection of BGP Sessions via the TCP MD5 Signature Option
2. http://www.ietf.org/rfc/rfc2385.txt
3. Technically Speaking: Why Authenticate BGP Routes?
4. http://www.cisco.com/en/US/about/ac123/ac114/
   ac173/ac170/about_cisco_packet_
   department09186a008010176a.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
暗号関連技術の第三者評価を活用する		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-01-11号

暗号関連技術を用いてセキュリティを確保する機器やソフトウェアには、様々な暗号の要素技術 (アルゴリズム) が用いられています。これらの機器やソフトウェアを安全に使用するためには、機器やソフトウェアで使用されている暗号の要素技術が客観的に評価され、実務上安全であることを確認する必要があります。しかし、このような評価は、暗号の専門家以外にとっては困難な作業となります。

暗号関連技術を用いた機器やソフトウェアを導入・運用する際は、アメリカや日本などの政府機関等によって提供されている暗号関連技術の第三者評価を参考に検討することをお勧めします。詳しくは、下記参考文献などを参照してください。

参考文書（日本語）

1. CRYPTREC
2. 技術報告書
3. http://www.cryptrec.jp/estimation.html
4. CRYPTREC
5. 電子政府推奨暗号の仕様書
6. http://www.cryptrec.jp/method.html
7. 独立行政法人 情報処理推進機構 セキュリティセンター
8. 暗号技術
9. http://www.ipa.go.jp/security/ipg/crypt.html

参考文書（英語）

1. National Institute of Standards and Technology
2. Cryptographic Standards and Validation Programs at NIST
3. http://csrc.nist.gov/cryptval/
4. National Institute of Standards and Technology
5. Recommendation on Key Management
6. http://csrc.nist.gov/publications/nistpubs/index.html#sp800-57

Topへ

タイトル	対象	目的別カテゴリ	掲載号
電子メールは必要に応じて暗号化する		インシデント発生前の予防	2007-02-07号

電子メールは、送受信の途中で第三者により内容を盗み見される可能性があります。重要な情報を電子メールでやりとりする場合には、必要に応じて暗号化して送信するようにしましょう。

電子メールで用いられる暗号化の手段としては、PGP や S/MIME が広く知られています。PGP や S/MIME は公開鍵暗号を使用しているため、電子メール 1通ごとに暗号鍵を伝達することで発生する煩雑さや危険性を避けることができます。

参考文書（日本語）

1. JPCERT/CC イラストでわかるセキュリティ
2. 情報セキュリティの脅威に対する対策 11．電子メールは必要に応じて暗号化する
3. http://www.jpcert.or.jp/magazine/security/illust/
   part1.html#11

Topへ

一時ファイル

タイトル	対象	目的別カテゴリ	掲載号
一時ファイルの取り扱いに注意		インシデント発生前の予防	2006-09-13号

アプリケーションの処理過程で作成された一時ファイル (テンポラリファイル) の中には、作業終了後、自動的に消去されない場合があります。例えば、暗号化されたメールを復号した際に生成された平文のテキストや、インストーラが展開したファイルなどが蓄積されている可能性があります。そのため、情報管理やディスク容量に関して注意が必要です。

一時ファイルが作成されるディレクトリを把握しておくとともに、一時ファイルを定期的に確認し、不要なファイルは削除することをお勧めします。

なお、一時ファイルが作成されるディレクトリに存在するファイルを定期的に削除するプログラムやタスクが OS によって予め備えられていることもありますので、そのようなプログラムやタスクを有効にすることも併せてご検討ください。

Topへ

インシデント報告

タイトル	対象	目的別カテゴリ	掲載号
インシデント報告を受けつけるメールアドレス		インシデント発生時の対処	2006-04-05号

組織としてインシデント報告を受けつけるためのメールアドレスを用意する場合、担当者個人のメールアドレスを直接公開するのではなく、担当者への転送アドレスとして役割別のメールアドレスを設定し、それを外部に公開することを推奨します。このようにすることで、担当者の異動または退職があった場合でも転送先の設定変更を行うだけでよく、公開メールアドレスの変更作業が不要となります。

インシデント報告を受けつけるためのメールアドレスは、組織のウェブページに掲載するだけではなく、whois データベースの技術連絡担当者(Technical Contact) として登録することが推奨されます。

なお、役割別のメールアドレスを設定する際には、RFC 2142 を参考にすることをお勧めします。

参考文書（日本語）

1. RFC 2142
2. 一般的なサービス、役割、機能に対するメールボックス名
3. http://rfc-jp.nic.ad.jp/rfc-jp/RFC2142-JP.txt
4. whois.jp
5. http://whois.jp/
6. 技術メモ - 関係サイトとの情報交換
7. http://www.jpcert.or.jp/ed/2002/ed020001.txt
8. JPCERT/CC REPORT 2006-03-29号 [今週の一口メモ]
9. http://www.jpcert.or.jp/wr/2006/wr061201.txt

参考文書（英語）

1. RFC 2142
2. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS
3. http://www.ietf.org/rfc/rfc2142.txt

Topへ

インスタントメッセンジャー

タイトル	対象	目的別カテゴリ	掲載号
インスタントメッセンジャーのセキュリティ		インシデント発生前の予防	2007-09-12号

インスタントメッセンジャーは、即時性、利便性が高い有用なコミュニケーションツールですが、使用する際には、以下のような事項に注意してください。

多くのインスタントメッセンジャーソフトウェアでは、メッセージは暗号化されず、サーバが中継を行います。このため、第三者にメッセージを盗み見られている可能性を考慮して、重要な機密情報などを含んだやりとりは避けましょう。

また、インスタントメッセンジャーを使用した SPAM やフィッシングなども多く報告されています。メンバーリストなどを使用して、許可していないメンバーからのメッセージをブロックするなど不要なメッセージは受けとらないように設定することをおすすめします。

参考文書（日本語）

1. マイクロソフト
2. インスタント メッセージを安全に使用するための 10 のヒント
3. http://www.microsoft.com/japan/athome/security/
   online/imsafety.mspx
4. Yahoo!メッセンジャー ヘルプ
5. 特定の相手からのメッセージを拒否する（受信拒否）
6. http://help.yahoo.co.jp/help/jp/messenger/win7/im/im-11.html

参考文書（英語）

1. Microsoft Security Bulletin Advance Notification for September 2007
2. Affected Software MSN Messenger, Windows Live Messenger.
3. http://www.microsoft.com/technet/security/bulletin/ms07-sep.mspx

Topへ

タイトル	対象	目的別カテゴリ	掲載号
メッセージングソフトウェアに関するネットワーク管理上の注意点		インシデント発生前の予防	2004-07-07号

メッセージングソフトウェア (Windows メッセンジャー、ICQ など) の中には、ファイアウォールを越えて使用できるものがあります。したがって、ファイアウォールによる情報のフィルタリングを過信することなく、メッセージングソフトウェアを使用するユーザに対して、使用上の注意や基準、規則を明確にしておくことが推奨されます。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-011
2. Using Instant Messaging and Chat Rooms Safely
3. http://www.us-cert.gov/cas/tips/ST04-011.html

Topへ

インターネットと実社会

タイトル	対象	目的別カテゴリ	掲載号
インターネットセキュリティと実社会での注意事項		インシデント発生前の予防	2005-09-14号

多くの人々にとってインターネットセキュリティとは何か特別で、また難しいものであるかのように捉えられる傾向があります。しかし実際には、実社会で暮らして行く上で当然のこととして理解されている、以下のような注意事項がそのまま当てはまることを認識することが推奨されます。

1. - 知らない人からもらったお菓子を食べてはいけません
2. = 知らない人から送られて来た電子メールおよび添付されたデータ等を信用してはいけません
3. - 旨すぎる話を信用してはいけません
4. - 留守にしていることを言いふらしてはいけません
5. = 不在時の自動応答メール等で必要以上の情報を必要以上の不特定多数に教えてはいけません
6. - 貴重品は鍵をかけて保管しましょう
7. - 大事な資料は写しを取って安全な場所に保管しておきましょう

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-014
2. Real-World Warnings Keep You Safe Online
3. http://www.us-cert.gov/cas/tips/ST05-014.html

Topへ

ウィルス/ワーム

タイトル	対象	目的別カテゴリ	掲載号
ウィルス/ワームに感染したら		インシデント発生時の対処	2004-12-01号

感染したウィルス/ワームを除去する方法として、ワクチンソフトウェアを用いる方法があります。しかしながら、使用しているワクチンソフトが対応しているウィルス/ワームに似てはいるが、別種 (亜種) のものである場合もあります。その場合は、ワクチンソフトウェアを用いても完全には復旧できない可能性があります。例えば、最近のウィルス/ワームの中には、特定サイトからプログラムをダウンロードすることで、自らを日々バージョンアップするものがあり、それらに対応するワクチンソフトの作成が間に合わないケースも実際に発生しています。

このような場合も考慮して、何らかのウィルス/ワームに感染した場合には、OS の再インストールなどの抜本的な復旧方法を用いることが推奨されます。

参考文書（日本語）

1. 技術メモ - コンピュータセキュリティインシデントへの対応
2. http://www.jpcert.or.jp/ed/2002/ed020002.txt
3. キーボード入力などを記録し外部に送信するプログラムに関する注意喚起
4. http://www.jpcert.or.jp/at/2004/at040008.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
電子メールの添付ファイルに注意		インシデント発生時の対処	2004-06-09号

コンピュータウィルスの多くは、電子メールに添付されたファイルを開く (実行する) ことによって感染を拡大します。見知らぬ人から送付された電子メールに添付されたファイルについては開くことなく、破棄することが推奨されます。しかし電子メールの仕組みは送信元の詐称が極めて容易であるため、たとえ送信元が信頼できる相手であっても、電子メール自体を信用することはできません。

したがって、電子メールの添付ファイルを開く場合には、誰から送付された電子メールであっても、必ず以下のような手順を踏むことを強くお勧めします。

1. 1. ウィルス検知ソフトのパターンファイルが最新であることを確認する。
2. 2. 添付ファイルをディスク上に保存する。
3. 3. 添付ファイルをウィルス検知ソフトで検査する。
4. 4. ウィルスが検知できなかった場合は開く。検知された場合は破棄する。

また、使用している電子メールクライアントの設定が、添付ファイルを自動的に開く設定になっていないことを確認してください。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-010
2. Using Caution with Email Attachments
3. http://www.us-cert.gov/cas/tips/ST04-010.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
グリーティングメッセージに要注意		インシデント発生時の対処	2005-12-21号

クリスマスや年末年始には、挨拶状 (グリーティングメッセージ) に偽装したウィルスメールや攻撃を目的とした Web ページへの誘導メールが数多く送付されてくることが予想されます。添付ファイルを不用意に開かないようにすると共に、メール内の URL で示された Web ページにむやみにアクセスしないなど、日常的にも注意しなくてはいけない点に対して一層の注意が必要です。

参考文書（日本語）

1. 長期休暇を控えて
2. http://www.jpcert.or.jp/pr/2004/pr040006.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ウィルス検知ソフトを過信しない		インシデント発生前の予防	2006-01-25号

最近のコンピュータウィルスなどの「不審なプログラム」は、かつての比ではないスピードで日々更新されています。そのためウィルス検知ソフトのパターンファイルを最新の状態にしていても検知ができない場合が増えてきています。もちろんウィルス検知ソフトのパターンファイルを最新の状態にしておくことで「感染」を防ぐことができる場合も多いのですが、それだけでは充分でないことに注意しましょう。

ウィルスなどの不審なプログラムに感染していないかどうか、ウィルス検知ソフト以外の方法でも定期的に確認することをお勧めします。例えば、感染している PC はユーザの意図しない通信を行なうことが多いため、PC と外部 (インターネット) との間にあるネットワーク機器の通信記録を確認することで感染の有無を確認できる場合があります。その際には、それぞれの通信が意図したものであるか否かを慎重に確認してください。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
拡張子の偽装に注意		インシデント発生前の予防	2006-06-07号

PC 上でデータファイルを取り扱う際、ファイルの拡張子には注意が必要です。ファイルの拡張子は簡単に編集できるため、第三者が拡張子を偽装することで、ユーザが意図しないフォーマットのファイルを実行してしまう可能性があります。

ネットワーク上には、ユーザが実行することでウィルスやワームに感染させるファイルや、特定の脆弱性を使って、PC を乗っ取るファイルが散在しています。誤ってこれらのファイルを実行してしまわないためにも、OS の設定で拡張子を表示するようにしたり、親しい人から入手したファイルであっても実行する前にはウィルス検知ソフトでファイルを検証したりするといった習慣を身につけることが望まれます。

参考文書（日本語）

1. JPCERT/CC Alert 2006-05-20
2. Microsoft Word の脆弱性に関する注意喚起
3. http://www.jpcert.or.jp/at/2006/at060006.txt
4. Microsoft TechNet セキュリティ ニュースレター
5. ファイル名拡張子に関する懸念と対策について (前編)
6. http://www.microsoft.com/japan/technet/security/
   secnews/columns/column060125.mspx
7. M独立行政法人 情報処理推進機構 セキュリティセンター
8. コンピュータウイルス・不正アクセスの届出状況[11月分]について
9. http://www.ipa.go.jp/security/txt/2005/12outline.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ワクチンソフトを過信しない		インシデント発生前の予防	2006-02-01号

コンピュータウィルスに感染した (不審なプログラムがインストールされた) 場合、復旧するにはワクチンソフト (駆除ツール) を使用することが一般的に推奨されています。しかしながら、ワクチンソフトはあくまで対応するウィルスなどを除去することができるだけであり、「似ているが異なる」亜種には対応できない場合があります。したがって、ワクチンソフトで必ずしも完全に復旧できるとは限らないことに注意してください。

不審なプログラムがインストールされたことが確認された場合は、OS を再インストールすることをお勧めします。その際の復旧作業を円滑に進められるように、日常的に必要なデータのバックアップを取っておくことを強くお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2006-01-25号 [今週の一口メモ]
2. ウィルス検知ソフトを過信しない
3. http://www.jpcert.or.jp/wr/2006/wr060301.txt

Topへ

キーロガー

タイトル	対象	目的別カテゴリ	掲載号
ゲーム関連サイトに注意		インシデント発生前の予防	2005-12-28号

ゲームの裏技などを紹介した Web サイトに、キーロガーなどの不審なプログラムが置かれ、ブラウザでアクセスするだけで、使用している PC にその不審なプログラムがインストールされてしまう事例があります。

使用している Web ブラウザを最新の状態に保ち、且つウィルス検知ソフトのパターンファイルを最新に更新するだけでなく、不用意に不審なサイトにアクセスすることがないように注意することをお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
キーロガーによる情報の盗用に注意		インシデント発生前の予防	2005-12-28号

ユーザのキーボードやマウスなどの操作全てを記録する、いわゆるキーロガーと呼ばれる技術があり、情報の盗用に使われることがあります。キーロガーには、ソフトウェアによるものの他にハードウェアによるものも存在します。

キーロガーによって重要な情報を盗用されることを防ぐために、お使いの PC にキーロガーが組み込まれていないかどうかを定期的に確認することをお勧めします。特に、インターネットカフェなど公共の場に置かれている PC を利用する際は、キーロガーが組み込まれている可能性を考慮するよう強くお勧めします。

参考文書（日本語）

1. JPCERT/CC Alert 2004-06-17
2. キーボード入力などを記録し外部に送信するプログラムに関する注意喚起
3. http://www.jpcert.or.jp/at/2004/at040008.txt

Topへ

クレジットカード

タイトル	対象	目的別カテゴリ	掲載号
オンライン専用クレジットカード		インシデント発生前の予防	2005-12-28号

ネットワークを通じた買い物などでクレジットカードを使う場合には、普段使うクレジットカードとは別のカードを用い、利用限度額を必要最低限に設定することをお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2004-07-22号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2004/wr042801.txt

Topへ

携帯電話/PDA

タイトル	対象	目的別カテゴリ	掲載号
Bluetooth 使用上の注意		インシデント発生前の予防	2005-08-24号

PDA や携帯電話同士の通信などに広く使われ始めている Bluetooth の技術は、そもそも比較的安全に設計されているのですが、実際には多くの Bluetooth 製品が、PIN ナンバーと呼ばれる短い数字の並びを基本に認証をしています。そのため、外部の第三者によって通信を妨害されたり、データを盗まれたりするなどの被害を受ける可能性があります。そこで Bluetooth を使用する際には以下のような点に注意することが推奨されます。

1. -使わないときには Bluetooth 機能を無効に
2. -Bluetooth を hidden モードに
3. -Bluetooth を使用する「場所」に注意
4. -現在のセキュリティ設定の確認 (不要な機能は無効に)
5. -セキュリティ機能の内容確認 (必要な機能を有効に)

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-015
2. Understanding Bluetooth Technology
3. http://www.us-cert.gov/cas/tips/ST05-015.html

参考文書（日本語）

1. bluetooth サポート
2. 無線セキュリティ
3. http://japanese.bluetooth.com/help/security.htm

Topへ

攻撃

タイトル	対象	目的別カテゴリ	掲載号
0 day attack が発生したら		インシデント発生前の予防	2005-11-30号

未公開 (未修正) の脆弱性を使った攻撃、いわゆる「0 day attack」が発生する場合があります。この場合は、まず以下のような手順で対応することをお勧めします。

- 情報収集

JPCERT/CC などの CSIRT (Computer Security Incident ResponseTeam) が提供する情報など、複数の情報源から情報を収集し、以下のようなポイントで内容を確認しましょう。

- 対象となるソフトウェアとそのバージョンを確認

対象となっているソフトウェアを使用している場合、当該ソフトウェアの使用停止やサービス停止を検討することをお勧めします。

- 攻撃手法を確認

例えば特定のポートが狙われている場合、当該ポートへの外部からのアクセスの遮断または制限を検討することをお勧めします。

- 監視体制の強化

外部からのアクセス状況だけでなく、内部のシステムから外部のシステムへのアクセスも併せて監視しましょう。

- 情報収集体制の強化

対象となるソフトウェアやバージョンなどが、検証の結果、追加されることがあるので、最新の情報を収集するよう努めましょう。また修正プログラムの提供 (公開) に関する情報にも注意しましょう。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-07-06号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr052601.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ARP Spoofing による Web 改ざん		インシデント発生前の予防	2008-06-11号

国内外で ARP Spoofing を使用した Web 改ざんの被害が幾つか確認されています。以下のようなシナリオで Web 改ざんが発生しています。

1. 1. 攻撃者は、対象となるサーバ A と同一ネットワーク (ブロードキャストドメイン) 上の脆弱なサーバ B に侵入します。
2. 2. 攻撃者は、サーバ B 上で ARP Spoofing を行い、外部とサーバ A 間の HTTP の通信を仲介し改ざんを行うことで、不正なスクリプトを挿入します。
3. 3. ユーザがサーバ A の Web サイトを閲覧するとユーザのブラウザ上で不正なスクリプトを実行され、ユーザの PC がマルウェアに感染するなどの被害が発生します。

サーバ A の管理者がセキュリティ対策を行っていても、他のサーバへの侵入からサーバ A のユーザに被害がおよぶという点で、発見や対処が困難になります。

この問題に対する解決方法としては、ネットワークの機器全てでスタティックに ARP テーブルを設定する方法があります。ただし、全ての機器の MAC アドレスを管理し、全ての機器に設定が必要となるため、大規模なネットワークでは運用が困難になるでしょう。

その他の対策としては、Arpwatch などの ARP テーブル変更を監視するツールを用いて ARP Spoofing を検知する、ネットワークを構成するスイッチで DHCP Snooping 機能を用いるなどの対策が考えられます。

参考文書（日本語）

1. Trend Micro Security Blog
2. ネットワーク機器がホームページ改ざん幇助：ARPスプーフィングの脅威
3. http://blog.trendmicro.co.jp/archives/1388

参考文書（英語）

1. McAfee Avert Labs Blog
2. ARP Spoofing: Is Your Web Hosting Service Protected?
3. http://www.avertlabs.com/research/blog/index.php/2007/
   10/04/arp-spoofing-is-your-web-hosting-service-protected/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Fast Flux 手法とは		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-10-29号

Fast Flux 手法とは、マルウェアを配布するサイトやフィッシングサイトをより長い時間インターネット上で活動させるために攻撃者が用いる技術の一つです。攻撃者は特定のホスト名について数多くの IP アドレスを短い有効期限で設定します。これにより、たとえばその中の一つの IP アドレスが到達不能になっても、残る多くのホストでサイトの稼働を続けることができます。

関連組織が連携し、このような有害サイトを停止 (テイクダウン) させる努力をしていますが、Fast Flux 手法を使った有害サイトでは、IP アドレスがめまぐるしく変更されることで、対応が困難な状況になっています。JPCERT/CC によせられるフィッシングサイトの報告の中にも Fast Flux 手法を用いられたケースが確認されています。

Fast Flux 手法が様々な有害サイトの停止を難しくしている状況から ICANN が対応の検討を始めています。

参考文書（英語）

1. ICANN
2. Fast Flux PDP WG
3. https://st.icann.org/pdp-wg-ff/index.cgi
4. ICANN Generic Names Supporting Organization
5. GNSO Issues Report on Fast Flux Hosting
6. http://gnso.icann.org/issues/fast-flux-hosting/gnso-issues-report-fast-flux-25mar08.pdf

Topへ

タイトル	対象	目的別カテゴリ	掲載号
SQL インジェクション攻撃による被害増加について		インシデント発生前の予防	2008-03-26号

データベースと連携するアプリケーションの不備を悪用して、アプリケーションへの入力データに SQL 文を挿入し、データベースを不正に操作する試みを SQL インジェクション攻撃といいます。

昨年の夏から SQL インジェクション攻撃によってデータベースの書き換えを行い、Web サーバのコンテンツを改ざんする事例が複数確認されています。この攻撃によって改ざんされた Web サイトを閲覧することで、ユーザのコンピュータ上にマルウェアがインストールされる危険性があります。

今後も継続的に、ツールなどを使用した大規模な SQL インジェクション攻撃が発生する可能性があります。外部に Web アプリケーションを公開する際には、適切な対策がとられていることを確認してください。

参考文書（日本語）

1. JPCERT/CC Alert 2008-03-14
2. SQL インジェクションによる Web サイト改ざんに関する注意喚起
3. http://www.jpcert.or.jp/at/2008/at080005.txt
4. 注意喚起　【LAC|ラック】
5. 日本をターゲットとしたSQLインジェクションによるホームページ改ざん行為と、同行為により改ざんされたページへのアクセスによるマルウェア感染について
6. http://www.lac.co.jp/news/press20080312.html
7. 独立行政法人 情報処理推進機構セキュリティセンター
8. 「安全なウェブサイトの作り方　改訂第3版」
9. http://www.ipa.go.jp/security/vuln/websecurity.html

参考文書（英語）

1. US-CERT Current Activity Archive
2. Websites Compromised Through SQL Injection
3. http://www.us-cert.gov/current/archive/2008/03/14/archive.html#
   website_compromises_facilitating_exploitation_of

Topへ

タイトル	対象	目的別カテゴリ	掲載号
サービス運用妨害 (DoS) 攻撃に加担しないために		インシデント発生前の予防	2004-09-22号

サービス運用妨害 (DoS: Denial-of-Service) 攻撃や分散型サービス運用妨害 (DDoS: Distributed Denial-of-Service) 攻撃から完全に守る方法はありません。しかし、自分のコンピュータを他者への攻撃に使われない (攻撃用のツールをインストールされない、インストールされても他者を攻撃しない、など) ようにするために以下のような点に常に注意を払うことが推奨されます。

- ウィルス検知ソフトをインストールし、パターンファイルを最新に保つ

- ファイアウォールをインストールし、コンピュータに入ってくる、または出て行くパケットを必要なものだけに制限する

- むやみに自分の電子メールアドレスを他者に知らせないように注意をして、必要に応じてメールフィルタなどを導入する

※ これにより、攻撃用ツールのインストールを意図したメールを受信する可能性が減ると考えられます。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-015
2. Understanding Denial-of-Service Attacks
3. http://www.us-cert.gov/cas/tips/ST04-015.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
アクセス元への連絡方法		インシデント発生前の予防	2004-09-22号

不審なアクセスがあった場合に、そのアクセス元に連絡を取ることでインシデントへの対応が円滑に進む場合があります。発信元 IP アドレスが割り当てられている組織に連絡する際には、以下の手順で行う方法があります。

(1) 以下の URL で示される IANA の情報を使って該当する IP アドレスを割り当てているレジストリを調べる

1. IANA
2. http://ftp.apnic.net/stats/iana/delegated-iana-latest

(2) 以下の各レジストリの情報から該当する IP アドレスを割り当てている国名を調べる

1. APNIC
2. ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest
3. RIPE
4. ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest
5. LACNIC
6. ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest
7. ARIN
8. ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest

(3) 各国を代表するセキュリティチーム (National CSIRT) に対し、該当 IP アドレスが割り当てられている組織への連絡を依頼する

参考文書（日本語）

1. 技術メモ - 関係サイトとの情報交換
2. http://www.jpcert.or.jp/ed/2002/ed020001.txt

参考文書（英語）

1. APNIC
2. http://www.apnic.net/
3. RIPE
4. http://www.ripe.net/
5. LACNIC
6. http://lacnic.net/
7. ARIN
8. http://www.arin.net/
9. FIRST Member Teams
10. http://www.first.org/about/organization/teams/
11. APCERT Members
12. http://www.apcert.org/member.html
13. Computer Security Incident Response Team (CSIRT)
14. Frequently Asked Questions (FAQ)
15. http://www.cert.org/csirts/csirt_faq.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
システムを守るために		インシデント発生前の予防	2006-07-28号

いわゆるクラッカーは、セキュリティ上の弱点を探索する目的で、インターネット上のホストに無差別的にアクセスすることがあります。しかし、アクセス自体を止めることは技術的に難しいため、これらの不審なアクセスを受けたとしてもシステムに影響がでないように下記のような対策を施すことが望まれます。

1. - 不要なサービスを停止する
2. 不要なサービスを提供しているプロセスを停止します。あるいは、実行できないように設定します。
3. - サービスを提供する範囲を制限する
4. アクセス制御プログラムや、ルータのフィルタリング機能を利用して、サービスを提供する対象 (クライアントホスト) を制限します。
5. - システムの運用状態を監視する
6. 提供しているサービスにおける稼働状況、接続している / 接続したクライアントマシンの情報等を定期的に (可能であれば常時)監視します。
7. - 安全なソフトウェアを使用する
8. 最新のバージョンを使用する、セキュリティパッチを当てるなどして、セキュリティ上の弱点が含まれるソフトウェアを使用しないようにします。
9. - ユーザアカウントを適切に管理する
10. パスワードのないユーザアカウントがないか、脆弱なパスワードが設定されていないか、また、不要になったユーザアカウントが残っていないかどうかなどを定期的にチェックします。併せて、ユーザに対して、パスワードの定期的な変更も促します。

参考文書（日本語）

1. JPCERT/CC Alert 2005-02-21
2. Web 偽装詐欺 (phishing) の踏み台サーバに関する注意喚起
3. http://www.jpcert.or.jp/at/2005/at050002.txt
4. コンピュータセキュリティインシデントへの対応
5. http://www.jpcert.or.jp/ed/2002/ed020002.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ソフトウエア難読化 (Software Obfuscation)		セキュリティ関連の機関や団体、用語や技術に関する説明	2009-01-28号

ソフトウエアの本来の機能を保持したまま、そのソフトウエアを解析されることを防ぐためにソフトウエア難読化が行われることがあります。不要なコードを紛れ込ませたり、コードの順番を入れかえたり、ソースコード自身に特殊なエンコードを行ったりしてソフトウエアの挙動を隠ぺいします。

ソフトウエアのアイデアやノウハウなどを保護する目的で研究されていましたが、現在では攻撃者が難読化された JavaScript やマルウエアを使用する例が増えています。これにはパターンマッチによる検知を防いだり、マルウエア作者の意図を秘匿する狙いがあると考えられています。

参考文書（日本語）

1. msdn Visual Studio 2008 Developer Center
2. Dotfuscator Community Edition 4.0
3. http://msdn.microsoft.com/ja-jp/library/ms227240.aspx

Topへ

サーバ

タイトル	対象	目的別カテゴリ	掲載号
chroot		インシデント発生前の予防	2005-02-16号

UNIX 系の OS には、一般的に標準で chroot という機能があります。chroot は指定したディレクトリをルートディレクトリとしてプログラムを実行する機能です。この機能を使ってサーバプログラムを実行すれば、万が一、そのサーバプログラムの脆弱性によって侵入行為を受けても、侵入者は chroot で指定されたルートディレクトリ以下の領域以外にはアクセスできないため、侵入による被害を軽減させることができます。

サーバプログラムの中には、サーバプログラム自体に標準で chroot を行なう機能を有しているものもあります。

参考文書（日本語）

1. Chroot-BIND HOWTO
2. http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html

参考文書（英語）

1. Secure BIND Template Version 4.6 27 JAN 2005
2. http://www.cymru.com/Documents/secure-bind-template.html
3. OpenBSD Documentation and Frequently Asked Questions
4. 10.16 - Tell me about this chroot(2) Apache?
5. http://www.openbsd.org/faq/faq10.html#httpdchroot

Topへ

タイトル	対象	目的別カテゴリ	掲載号
SSH 運用上の注意		インシデント発生前の予防	2005-11-09号

SSH サーバに対して、辞書を用いてユーザ名とパスワードを総当り的に試してログインを試みるブルートフォース攻撃に関する報告が JPCERT/CC に多数寄せられています。最近では、攻撃に用いられる辞書に日本人が使うようなユーザ名 (日本人の苗字をローマ字表記したものなど) やパスワードなどが含まれるようになり、日本において SSH サーバが攻撃の対象にされやすくなってきています。

SSH を運用する場合、任意のクライアントからアクセスできてしまう UNIX パスワード認証を無効にし、公開鍵認証のみを有効にすることで、秘密鍵を持っているクライアントのみからアクセス可能な設定にすることが推奨されます。

参考文書（日本語）

1. JPCERT/CC プレス発表資料
2. インターネットセキュリティに対する JPCERT/CC 2005年第3四半期活動報告
3. http://www.jpcert.or.jp/press/2005/1107.pdf

Topへ

サポート期限

タイトル	対象	目的別カテゴリ	掲載号
Apache Tomcat のバージョンについて		インシデント発生時の対処	2009-03-04号

Apache Tomcat の開発は、複数のバージョンで並行して進められています。現在、安定版としてセキュリティ修正がなされるバージョンは以下の通りです。

1. 4.1.x, 5.5.x, 6.0.x

また、新しい機能を取り込んだリリースとして以下のバージョンの開発が進められています。

1. 6.2.x, 7.0.x

以下のバージョンはサポートが終了しています。

1. 3.0.x, 3.1.x, 3.2.x, 4.0.x, 5.0.x

Tomcat を使用する Web アプリケーションの開発者および管理者の方は、今後の脆弱性対応をスムーズに進めるためにも、現在サポートされている最新バージョンへの移行を検討することをおすすめします。

参考文書（英語）

1. Tomcat Wiki
2. TomcatVersions
3. http://wiki.apache.org/tomcat/TomcatVersions

Topへ

タイトル	対象	目的別カテゴリ	掲載号
BIND 8 のサポート終了		インシデント発生時の対処	2007-08-22号

2007年8月9日、BIND 8 のサポート終了宣言が BIND Announce メーリングリストに配信されました。BIND 8 を使用している DNS サーバ管理者は、最新版の BIND 9 への移行を検討することをおすすめします。なお、BIND 9.2 系列についても、2007年8月でサポートが終了しますので、ご注意ください。

BIND 9 は、BIND 8 に含まれていたいくつかの問題が解決されています。また、BIND 9 の最初のリリースから 8年経過しており、安定性やパフォーマンスも向上しています。

BIND 9 への移行については、BIND 9 のソースコードパッケージに含まれる "BIND 8 to BIND 9 Migration Notes" などを参照してください。

参考文書（英語）

1. Internet Systems Consortium
2. A Brief History of The DNS and BIND
3. https://www.isc.org/software/bind/documentation/
   arm95#historical_dns_information
4. MARC: Mailing list ARChives bind-announce
5. BIND8 entering end of life; changes to ftp.isc.org (affects mirrors)
6. http://marc.info/?l=bind-announce&m=118670081707688&w=2

Topへ

タイトル	対象	目的別カテゴリ	掲載号
J2SE 1.4.2 のサポート終了		インシデント発生時の対処	2007-10-24号

J2SE 1.4.2 のサポート終了が告知されています。Sun によれば、2008年夏に予定されている Java SE 7 の提供開始をもって J2SE 1.4.2 のサポートは終了する予定とのことです。

J2SE 1.4.2 を使用したサービス提供者や開発者は、Java SE 6 への移行を検討することをおすすめします。

なお、J2SE 1.3.1 は 2006年12月11日の Java SE 6 の提供開始とともにサポートを終了しています。

参考文書（日本語）

1. Sun Developer Network
2. Java 2 Platform, Standard Edition (J2SE) 1.4.2
3. http://java.sun.com/j2se/1.4.2/ja/
4. Sun Developer Network
5. Java 2 Platform, Standard Edition v 1.3
6. http://java.sun.com/j2se/1.3/ja/

参考文書（英語）

1. Sun Developer Network
2. Java Technology EOL Policy
3. http://java.sun.com/products/archive/eol.policy.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
JDK/JRE のサポート状況		インシデント発生前の予防	2009-03-11号

現在サポートされている JDK/JRE の最新バージョンは以下の通りです。

1. - JDK/JRE 6 Update 12 (1.6.0 update 12)

1. - JDK/JRE 5.0 Update 17 (1.5.0 update 17)
   2009年10月30日まで EOL transition 期間中です。
   その後 EOSL (End Of Service Life) となる予定です。

Java AutoUpdate では、セキュリティ対策が含まれていない場合などには、最新のバージョンが配布されるわけではありません。実際に update 12 をインストールする場合にはマニュアルでダウンロードとインストールを行う必要があります。

Sun によると 2009年第一四半期に予定されているアップデートではセキュリティ対策を取り込んだリリースとなる予定です。

参考文書（英語）

1. JDK 6 Project
2. jdk6: Java SE 6
3. https://jdk6.dev.java.net/
4. Sun Developer Network (SDN)
5. Java SE 6 Update 12 Release Notes
6. http://java.sun.com/javase/6/webnotes/6u12.html
7. Sun Developer Network (SDN)
8. Java SE & Java SE for Business Support Road Map
9. http://java.sun.com/products/archive/eol.policy.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
PHP 5 への移行		保守・管理について	2008-08-20号

8月7日に PHP 4.4.9 がリリースされました。PHP 4 系では PHP 4.4.9 が最後のリリースとなります。以前からアナウンスされていたとおり、今後 PHP 4 のセキュリティ対応は行われなくなります。

現在 PHP 4 系を使っているユーザは速やかに PHP 4.4.9 にアップデートするとともに、PHP 5 系への移行をすすめてください。

参考文書（日本語）

1. JPCERT/CC REPORT 2007-07-25
2. 【今週のひとくちメモ】PHP 4 のサポート終了
3. http://www.jpcert.or.jp/wr/2007/wr072801.html#Memo

参考文書（英語）

1. PHP: News Archive - 2008
2. PHP 4.4.9 released!
3. http://www.php.net/archive/2008.php#id2008-08-07-1

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ソフトウェアのサポート期限に注意する		保守・管理について	2006-11-01号

ソフトウェアのベンダによっては、配布しているソフトウェアのバージョンごとにサポート期限を予め定めています。サポート期限の過ぎたソフトウェアを使用し続ける場合、期限が過ぎた後に脆弱性が発見されてもセキュリティパッチ等が提供されないため、脆弱性への直接的な対策が取れずインシデントが発生する可能性が高くなります。

そのため使用しているソフトウェアにサポート期限があるかどうかを確認するようお勧めします。もし、サポート期限が近づいていたり過ぎていたりした場合は、最新版への置き換えを検討してください。

何らかの理由により最新版のソフトウェアへの置き換えが困難な場合は、当該ソフトウェアの脆弱性に関する情報を収集し、使用しているシステムがどのような状況であるか、また、発見された脆弱性がシステムに対してどのような影響を及ぼすかを把握し、インシデントを防ぐための回避策を検討することが必要となります。

参考文書（日本語）

1. Microsoft サポート オンライン
2. Windows XP SP1 および SP1a のセキュリティ更新プログラムのサポートを 2006年 10月 11日に終了しました
3. http://support.microsoft.com/gp/lifean19
4. Microsoft サポート オンライン
5. マイクロソフト プロダクト サポート ライフサイクル FAQ
6. http://support.microsoft.com/gp/lifepolicy
7. サン・マイクロシステムズ
8. Solaris オペレーティングシステムに対するサンのライフサイクルモデル
9. http://jp.sun.com/products/software/solaris/fcc/lifecycle.html
10. レッドハット
11. Red Hat Enterprise Linuxのサポートポリシー
12. http://www.jp.redhat.com/software/rhel/support_policy_jp.html

Topへ

システムの設定更新/変更

タイトル	対象	目的別カテゴリ	掲載号
Windows SteadyState		セキュリティ関連の機関や団体、用語や技術に関する説	2007-11-21号

マイクロソフトは、学校、インターネットカフェ、図書館などで使用される共有コンピュータの安全な運用管理を行うために Windows SteadyState というツールを公開しています。

Windows SteadyState では、共有コンピュータの設定変更を防止する機能や、各ユーザの操作を制限するユーザ管理機能などが提供されています。共有コンピュータのユーザが行った設定変更やダウンロードしたファイルを、再起動することによって管理者が設定した初期状態に復元することが可能になります。

参考文書（日本語）

1. Microsoft
2. Microsoft Windows SteadyState
3. http://www.microsoft.com/japan/windows/products/winfamily
   /sharedaccess/default.mspx

Topへ

タイトル	対象	目的別カテゴリ	掲載号
設定更新作業時の作業漏れに注意		保守・管理について	2005-10-19号

システムの設定更新/変更後に、その設定の保存し忘れやバックアップ漏れのために、次の再起動時や復旧作業後に、新しい設定が反映されない場合があります。

例えば、新しいサーバプログラムを有効にした場合に、OS 起動時に自動的にそのサーバプログラムも起動するように設定しなければならないのを忘れてしまうケースは多々見受けられます。

特にセキュリティにかかわる設定の場合は、次の起動時に前の設定に戻ってしまうことで、外部からの攻撃に対して無防備になり、侵入などのインシデントによる被害が発生する危険性があります。またこのような場合は、設定を更新したという認識があるため、かえってインシデントの発見やインシデントの原因究明に時間を要してしまう可能性もあります。

設定変更時の作業内容については、あらかじめ手順を整理しておき、保存のし忘れやバックアップ漏れがないように充分に注意することが推奨されます。

Topへ

システムの選定

タイトル	対象	目的別カテゴリ	掲載号
汎用品をベースとしたシステムを選定する場合の注意		インシデント発生前の予防	2007-01-17号

従来、特別に設計され、インターネットから独立して運用されていたシステムが、技術や業務の集約、標準化、低コスト化への要求によって、汎用品をベースとしたシステムに置き換えられ、ネットワークに接続した状態で運用される事例が増えています。

このようなシステムでは、ベースとなっているソフトウェアやハードウェアに存在する脅威や脆弱性の影響をそのまま受ける可能性が高くなります。そのため、システムを選定する際には、選定候補の製品がどのような汎用品をベースにしているかを事前に確かめてください。そのうえで、関連する脆弱性が運用中に発見される可能性を考慮して脆弱性への対応を運用手順に組み込み、コストやリスクを見積ることを推奨します。

Topへ

実験用環境

タイトル	対象	目的別カテゴリ	掲載号
実験用のサーバやアカウントに注意		インシデント発生前の予防	2006-05-24号

実験目的でサーバやアカウントを作成・構築することがあります。 このような実験用のサーバやアカウントは一時的な環境として構築・作成されることが多く、セキュリティ上施して然るべき対策が省略されがちであり、更に実験終了後は放置されることがあります。その結果として、侵入などのインシデントが発生し、サービス運用妨害 (DoS) 攻撃の踏み台や phishing サイトとして使用される可能性があります。

実験用のサーバやアカウントについては以下のような点に注意を払って運用することが求められます。

- 実験用の環境にアクセス可能なホストおよびユーザを必要最小限に制限する

- 実運用環境に反映することを目的とした環境の場合、実運用環境で用いられているデータをそのまま使用せず、実験用のデータを別途用意する

- 実験用の環境の存在を組織内に周知させる

- 実験用の環境が必要がなくなった場合はその環境を放置せず、速やかに撤去・削除する

- 可能な限りインターネットから切り離された実験用の環境を用意する

Topへ

習慣

タイトル	対象	目的別カテゴリ	掲載号
警告画面を確認する		インシデント発生前の予防	2004-04-11号

ウェブ上のファイルをダウンロードする際や、ダウンロードしたプログラムを実行する際などに、画面に警告が表示される場合があります。

そうした警告画面が表示された場合、以下の点などを確認することをお勧めします。

1. - 警告画面が表示された操作が意図した操作であるか
2. - 実行またはダウンロードする必要があるか
3. - 実行しようとしているプログラムまたはダウンロードしようとしているファイルが、意図したものであるか
4. - 実行しようとしているプログラムまたはダウンロードしようとしているファイルの発行元が信頼できるか

参考文書（日本語）

1. 独立行政法人 情報処理推進機構 セキュリティセンター
2. コンピュータウイルス・不正アクセスの届出状況[3月分および第1四半期]について
3. http://www.ipa.go.jp/security/txt/2007/04outline.html#5
4. Microsoft サポート オンライン
5. インターネットからダウンロードしたファイルを実行したときに表示されるセキュリティの警告画面と、警告の解除方法
6. http://support.microsoft.com/kb/884237/ja
7. Microsoft サポート オンライン
8. [Windows セキュリティの 重要な警告] 画面について
9. http://support.microsoft.com/kb/875399/ja

Topへ

タイトル	対象	目的別カテゴリ	掲載号
セキュリティを常に意識する習慣を身につける		インシデント発生前の予防	2006-04-12号

個々のユーザが簡単な習慣を身につけるだけで、「セキュリティ」を向上させることができます。例えば以下のような習慣を身につけることが推奨されています。

- PC の前を離れるときには必ずスクリーンをロックする、もしくはログアウトする。

※ 例えば Microsoft Windows XP の場合は [Windows キー] + Lでスクリーンをロックすることが可能。

- ネットワークを使用しない場合は、PC をネットワークから切り離す。

※ 例えば、ブロードバンドルータの PPPoE セッションを切ったり、電源を切ったりする方法があります。または、PC のネットワークケーブルを外すといった方法もあります。

参考文書（日本語）

1. 独立行政法人 情報処理推進機構 セキュリティセンター
2. マイクロソフト プロダクト サポート ライフサイクル FAQ
3. 情報セキュリティ対策実践情報 エンドユーザ・ホームユーザ向けのページ
4. http://www.ipa.go.jp/security/awareness/end-users/end-users.html
5. マイクロソフト
6. 個人ユーザー向けセキュリティ
7. http://www.microsoft.com/japan/athome/security/
   default.mspx
8. JPCERT/CC REPORT 2004-05-19号 [今週の一口メモ]
9. http://www.jpcert.or.jp/wr/2004/wr041901.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-003
2. Good Security Habits
3. http://www.us-cert.gov/cas/tips/ST04-003.html

Topへ

仕様/規格

タイトル	対象	目的別カテゴリ	掲載号
SMTP の新しい RFC が公開		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-10-08号

SMTP を規定する RFC 5321 と Internet Message Format を規定する RFC 5322 が新しく公開されています。これにより、RFC 2821、RFC 2822 は obsolete となりました。

RFC 5321 では IPv6 への対応や、spam への対応に関する記述が追加されています。例えば、MUA からのメール送信に Submission ポートの使用を推奨しています。またその他、フォーマットやプロトコルに関してより厳格に記述するなどの変更がなされています。

参考文書（英語）

1. IETF RFC 5321
2. Simple Mail Transfer Protocol
3. http://tools.ietf.org/html/rfc5321
4. IETF RFC 5322
5. Internet Message Format
6. http://tools.ietf.org/html/rfc5322

Topへ

情報漏えい

タイトル	対象	目的別カテゴリ	掲載号
掲示板やメーリングリストなどでの質疑応答と情報漏洩		インシデント発生前の予防	2006-09-21号

インターネットの普及に伴い、誰でも投稿・閲覧可能な掲示板やメーリングリストが増加し、質疑応答が容易になりました。しかしながら、このような掲示板やメーリングリストが誰でも閲覧可能であることを失念すると、所属組織に関する機密情報を投稿してしまい、結果として情報漏洩をひきおこす可能性があります。

掲示板やメーリングリストへの投稿を考えている場合、所属組織の情報取り扱いポリシーに照らして問題がないことを確認するようお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ノートパソコンや PDA を守るために		インシデント発生前の予防	2004-09-15号

出張等の際にオフィス外で使用するノートパソコンや PDA が盗難され、その結果として、そこに保存された情報が漏洩するなどの問題が発生しています。このような被害を防ぐ、または被害を最低限に抑える、もしくは迅速な対応を促すために、以下の点に注意することが推奨されます。

1. - ログオン (ログイン) パスワードを設定する
2. - 常に肌身離さず携帯する
3. - 所持していることを (必要以上に) 公に見せない (知らしめない)
4. - 鞄に盗難防止の鍵やアラームなどを付ける
5. - 盗難されたデータが何であるか後で確認できるように保存データを (定期的に) バックアップしておく
6. - 機密情報を必要以上に保存しておかない

また機器をなくしたり、盗難されたりした場合には、警察やホテルの従業員または会議スタッフなどに届け出るとともに、機密情報が含まれている場合には、自組織の適切な部署に速やかに報告することが重要です。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-017
2. Protecting Portable Devices: Physical Security
3. http://www.us-cert.gov/cas/tips/ST04-017.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ノートパソコンや PDA を守るために その2		インシデント発生前の予防	2004-11-17号

出張等の際にオフィス外で使用するノートパソコンや PDA については、物理的な「盗難」による情報漏洩だけでなく、様々なネットワークに接続する機会が多いことから、ネットワーク経由での情報の「盗難」の被害を受ける危険性が高いと考えられます。このような被害を防ぐ、または被害を最低限に抑えるために、以下の点に注意することが推奨されます。

1. - パスワードを適切に運用する
2. - パスワードをコンピュータに (可能な限り) 記憶させない
3. - 他人が容易に推測可能なパスワードを使用しない
4. - 異なるプログラム (システム) に対しては異なるパスワードを設定する
5. - 重要なデータは安全且つ物理的に離れた場所に保管する
6. - ファイルまたはファイルシステムを暗号化する
7. - ウィルス検知ソフトをインストールし、パターンファイルを最新に保つ
8. - ファイアウォール (パケットフィルタ) ソフトウェアをインストールし、コンピュータを出入りするパケットを制限する
9. - 盗難された (漏洩した) データが何であるか後で確認できるようにデータを (定期的に) バックアップしておく

参考文書（日本語）

1. JPCERT/CC REPORT 2004-09-15号「今週の一口メモ」
2. http://www.jpcert.or.jp/wr/2004/wr043601.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-020
2. Protecting Portable Devices: Data Security
3. http://www.us-cert.gov/cas/tips/ST04-020.html
4. US-CERT Cyber Security Tip ST04-017
5. Protecting Portable Devices: Physical Security
6. http://www.us-cert.gov/cas/tips/ST04-017.html

Topへ

証明書

タイトル	対象	目的別カテゴリ	掲載号
Web サイトの証明書		インシデント発生前の予防	2005-05-18号

閲覧している Web ページが「信頼できる」「本当の」サイトのページであることを証明するために用いられる証明書を検証する際には以下の点を確認してください。

1. - 証明書発行機関
2. - 証明されている (証明書発行対象の) 組織名または個人名
3. - 有効期限

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-010
2. Understanding Web Site Certificates
3. http://www.us-cert.gov/cas/tips/ST05-010.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
"正規" のサーバ証明書にも注意		インシデント発生前の予防	2006-02-22号

特定の組織のサイトに見せかけたサイトが、正規の証明書発行機関から発行されているサーバ証明書 (Web ブラウザが警告を発しない) を使っている事例の報告を、JPCERT/CC では複数受領しています。

証明書が使われている Web ページを閲覧する場合であっても、接続先のサイトが目的のサイトであるかどうかを、ドメイン名などを手掛りに確認するよう推奨します。また、接続先サイトのサーバ証明書が、目的のサイトに対して発行されているサーバ証明書であることも併せて確認しましょう。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-05-18号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr051901.txt
3. JPCERT/CC REPORT 2005-05-25号 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2005/wr052001.txt
5. JPCERT/CC REPORT 2005-06-01号 [今週の一口メモ]
6. http://www.jpcert.or.jp/wr/2005/wr052101.txt

Topへ

スパイウェア

タイトル	対象	目的別カテゴリ	掲載号
スパイウェア		インシデント発生前の予防	2004-09-01号

スパイウェア (Spyware) またはアドウェア (Adware) と呼ばれるソフトウェアが勝手にインストールされ、個人情報などが盗み取られる被害が発生しています。これらのソフトウェアのインストールを防ぐために、(主に Web を利用している場合には) 以下のような点に注意してください。

- ポップアップウィンドウ内のリンクを辿らない。

※ ポップアップウィンドウ自体がスパイウェアによるものであることがあります。不用意にリンクを辿ることでスパイウェアがインストールされてしまう可能性があります。また、このようなウィンドウを閉じる場合は、ウィンドウ内にある close (閉じる) ボタンではなく、タイトルバーにある x ボタンなどを使って閉じてください。

- 予期せぬ質問に対しては、ダイアログボックスのタイトルバーにある x ボタンを使ってダイアログボックスを閉じるなどして、不用意に yes (はい) を選択しない。

- 信用できないサイトから無償のソフトウェアなどをダウンロードしない。

- 「アンチスパイウェアソフトウェアを提供」などと主張する電子メール内にあるリンクを辿らない。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-016
2. Recognizing and Avoiding Spyware
3. http://www.us-cert.gov/cas/tips/ST04-016.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
スパイウェア その2		インシデント発生前の予防	2004-09-08号

スパイウェアをインストールされていないかどうかを調べる方法として、ウィルス検知ソフトウェアを使う方法があります。しかしながら、一般的にウィルス検知ソフトウェアではスパイウェアのインストール自体を未然に防ぐことは困難です。スパイウェアの存在の有無を調べるために、ウィルス検知ソフトウェアによるコンピュータ内の全スキャンを、定期的に行なうように設定することをお勧めします。

スパイウェアがインストールされている場合は、意図しない通信が行なわれている可能性があります。このような場合、Microsoft Windows では、以下の参考文献で紹介している Port Reporter ツールを使って通信の状態を確認することができます。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-016
2. Recognizing and Avoiding Spyware
3. http://www.us-cert.gov/cas/tips/ST04-016.html

参考文書（日本語）

1. JPCERT/CC REPORT 2004-09-01号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2004/wr043401.txt

Topへ

セキュリティ情報の収集と対応

タイトル	対象	目的別カテゴリ	掲載号
ソフトウェアの脆弱性情報の収集と対応		インシデント発生前の予防	2008-02-27号

本号【1】で紹介した「AWStats の既知の脆弱性を狙った攻撃」は、今から3年以上前に修正された脆弱性を狙うものです。

ソフトウェアベンダからアップデート情報が公開されると、そこで修正された脆弱性情報の悪用を試みる不正なアクセスが増加することが知られています。またそれらの攻撃手法はマルウェアなどに取り込まれ、その後も攻撃に使われ続けます。

使用しているソフトウェアについて、脆弱性情報や攻撃情報が出ていないか常に注意を払い、迅速に対応を行なうことが重要です。

JPCERT/CC では JPCERT/CC REPORT の発行や注意喚起、また JVN の活動を通じてこのような情報の提供に努めています。また、有料のセキュリティ情報提供サービスも様々な形態のものが存在します。業務環境に合せて適切な情報収集とシステムへの対応体制の整備を検討してください。

参考文書（日本語）

1. JPCERT Coordination Center
2. http://www.jpcert.or.jp/
3. Japan Vulnerability Notes
4. http://jvn.jp/

参考文書（英語）

1. US-CERT Vulnerability Notes
2. http://www.kb.cert.org/vuls/

Topへ

セキュリティ設定ガイド

タイトル	対象	目的別カテゴリ	掲載号
Mac OS X 向けセキュリティ設定ガイド		インシデント発生前の予防	2008-06-18号

Apple は、Mac OS X のセキュリティを強化するための設定ガイド「Mac OS X Security Configuration Guides」を公開しています。

このガイドは Mac OS X の様々なセキュリティ設定について網羅的に記述しており、Mac OS X 10.5 (Leopard)、Mac OS X 10.4 (Tiger)、Mac OS X 10.3 (Panther)、それぞれのサーバ、クライアント向けに PDF で文書が提供されています。

ただし、このガイドは上級 Mac OS X ユーザを対象としており、設定ミスによって、深刻な影響が出る可能性があります。Apple は、設定の際には十分にテストを行うことを推奨しています。

参考文書（英語）

1. Apple - Support
2. Mac OS X Security Configuration Guides
3. http://www.apple.com/support/security/guides/

Topへ

ソフトウェアのインストール/アップデート

タイトル	対象	目的別カテゴリ	掲載号
Microsoft Windows における制限付きユーザアカウント使用時の注意		インシデント発生時の対処	2008-05-14号

Windows 向けアプリケーションのインストーラの中には、インストール完了後にインストールしたアプリケーションを起動するものがあります。制限付きユーザアカウントから runas コマンドを使うなど一時的に管理者権限を使ってインストーラを実行した場合、インストーラから起動されたアプリケーションが管理者権限で動作している場合があります。

例えば Windows XP で Firefox や Opera をインストールする場合などがこれにあたります。

このような場合には、アプリケーションを制限付きユーザの権限で動作させるために、一度アプリケーションを終了し、改めてスタートメニューから起動して使うことをおすすめします。

参考文書（日本語）

1. JPCERT/CC REPORT 2008-05-01
2. 【今週のひとくちメモ】Microsoft Windows における制限付きユーザアカウント (標準ユーザアカウント) の使用
3. http://www.jpcert.or.jp/wr/2008/wr081701.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ソフトウェア使用許諾への同意		インシデント発生前の予防	2005-03-30号

ソフトウェアをインストール後に初めて使用する際に、「使用許諾」への同意を求められる場合がありますが、その内容には注意が必要です。一般的には「再配布」や「保証」に関する内容が中心になりますが、以下のような内容が含まれている場合があります。

- モニタリング

同意すると、そのソフトウェアのベンダがコンピュータ内の情報やコンピュータが通信した内容を取得することを許可したことになる場合があります。

- ソフトウェアのインストール

同意すると、上記「モニタリング」を行なうソフトウェアのインストールを許可することになる場合があります。

「使用許諾」に「同意」する場合は、記載されている内容に充分に注意することを強くお勧めします。

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-005
2. Reviewing End-User License Agreements
3. http://www.us-cert.gov/cas/tips/ST05-005.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
インターネット上で公開されているソフトウェアに注意		インシデント発生前の予防	2006-03-23号

多くの有用な有償/無償のソフトウェアがインターネット上で公開されています。パッケージ販売されている商用ソフトウェアだけでは要求を満たせない場合、必要に応じてこのようなソフトウェアを探してインストールすることで、コンピュータ上での作業効率を高めることができます。

しかしながら、インターネット上で公開されているソフトウェアの一部には、ユーザには分からないような形で不審な動作をするようプログラムされているものがあり、そのようなソフトウェアをインストールすることで、予期せぬインシデント (情報漏えいなど) が発生する場合があります。

インターネット上で公開されているソフトウェアをインストールする際には、そのソフトウェアが自分にとって本当に必要なものかどうかを慎重に検討し、そのソフトウェア自体の信頼性や配布元の信頼性についても充分に調査・確認することをお勧めします。

また、業務で使用する PC にインストールする場合には、PC の管理者などに必ず相談することを強くお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ソフトウェアアップデート時の確認作業について		インシデント発生前の予防	2006-06-14号

ソフトウェアのアップデートを行う際には、アップデートの仕組による制限やソフトウェア相互の依存性などにより、複数回アップデートが必要な場合があります。

アップデートを実行する際には、アップデートが正常に終了していることの確認や追加アップデートがないかどうかをチェックするなど注意深く確認することをお勧めします。

参考文書（日本語）

1. アップル コンピュータ
2. Mac OS X: ソフトウェアをアップデートする方法
3. http://docs.info.apple.com/article.html?artnum=106704-ja
4. JPCERT/CC REPORT 2004-05-26 号 [今週の一口メモ]
5. http://www.jpcert.or.jp/wr/2004/wr042001.txt

Topへ

担当ノート

タイトル	対象	目的別カテゴリ	掲載号
担当ノート: CanSecWest 2009		セキュリティ関連の機関や団体、用語や技術に関する説明	2009-03-25号

普段の JPCERT/CC REPORT ではとりあげてこなかったセキュリティ関連のコミュニティの活動やちょっとした豆知識についても今後は範囲をひろげ、「担当ノート」と称して不定期にお送りしていきます。今回は、当レポート担当者が参加したセキュリティカンファレンス CanSecWest 2009 についての報告をお送りします。

◇　　　　　　　　　◇　　　　　　　　　◇

昨年に続き、先週カナダのバンクーバーで行われた CanSecWest というカンファレンスに参加してきました。海外のセキュリティカンファレンスというと規模と歴史から米国の BlackHat や DEFCON が有名ですが、CanSecWest も今年で 10回目を迎える人気のカンファレンスです。

通常大規模なカンファレンスでは並行して幾つかの発表が行われ、参加者は自分の聞きたいセッションを選びますが、CanSecWest では発表がひとつの部屋で行われます。全ての参加者が全日程同じ発表を聞くためでしょうか、アットホームな雰囲気で参加者同士の交流もさかんです。

ここ数年 CanSecWest では PWN2OWN というコンテストを行っています。PWN2OWN は最新のセキュリティパッチをあてたブラウザやスマートフォンの脆弱性を最初に見つけた参加者に、そのノートパソコンやスマートフォンを贈るというコンテストです。有名セキュリティベンダーがスポンサーし、脆弱性の内容によって賞金も与えられます。脆弱性に値段が付けられ、高額で取引される時代を象徴するコンテストといえます。

今年の PWN2OWN では、昨年 MacBook を獲得した研究者がわずか数秒で Safari への攻撃を成功させたことと、別の研究者が Windows 7 上の IE8 と Firefox と Safari の全てを攻略したことが会場での話題となりました。

また Twitter での CanSecWest に関する発言は常時会場横のスクリーンに表示されており、発表中に参加者から Twitter を使って鋭く指摘がされるなど、発表者と参加者の新しいコミュニケーションの形がみられました。

参考文書（英語）

1. CanSecWest Applied Security Conference
2. http://cansecwest.com/

Topへ

長期休暇時の注意

タイトル	対象	目的別カテゴリ	掲載号
夏期休暇を前に		定期的なお知らせ	2005-04-27号

職場外のネットワークに接続した PC などを夏期休暇のような長期休暇明けに、職場内 LAN に接続する際には注意が必要です。例えば、ウィルスやワームに感染し、LAN に接続することで、LAN 全体に被害を及ぼす事があります。

休暇中であってもセキュリティ関連情報の収集や、ウィルス検知ソフトの定義ファイルの更新など、通常と変わらぬセキュリティ対策を講じることをお勧めします。

また、自組織のセキュリティポリシーを、改めて管理者から各ユーザへ周知徹底することを強くお勧めします。

参考文書（日本語）

1. 長期休暇を控えて
2. http://www.jpcert.or.jp/pr/2005/pr050003.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
長期休暇明けの注意		定期的なお知らせ	2005-08-10号

職場外のネットワークに接続した PC などを職場内のネットワークに接続する際には注意が必要です。例えば、ウィルスやワームなどに感染した PC をネットワークに接続することで、被害を拡げることがあります。特にゴールデンウィークのような長期休暇の後には、より一層の注意が必要です。

休暇中であってもセキュリティ関連情報の収集や、ウィルス等検知ソフトの定義ファイルの更新など、通常と変わらぬセキュリティ対策を講じることをお勧めします。

また、自組織のセキュリティポリシーを、改めて管理者から各ユーザへ周知徹底することを強くお勧めします。

参考文書（日本語）

1. 長期休暇を控えて
2. http://www.jpcert.or.jp/pr/2006/pr060003.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
長期休暇明けの注意		インシデント発生前の予防	2007-04-25号

ゴールデンウィークのような長期休暇の後には、セキュリティ対策に関して一層の注意が必要です。長期休暇中に使用していなかった PC については、早急に下記のようなセキュリティ対策を行うことをおすすめします。また、休暇中外部に持ち出した PC については、内部ネットワークに接続する前に同様の対策を行うことをおすすめします。

1. - OS などのソフトウェアのセキュリティアップデートを適用する
2. - ウイルス対策ソフトなどの定義ファイルを更新する
3. - ハードディスクのウイルスチェックを行う
4. - 使用している機器やソフトウェアのセキュリティ関連情報の収集を行う

参考文書（日本語）

1. 長期休暇を控えて
2. http://www.jpcert.or.jp/pr/2007/pr070005.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
長期休暇明けの注意		インシデント発生前の予防	2007-12-27号

ゴールデンウィークのような長期休暇の後には、セキュリティ対策に関して一層の注意が必要です。長期休暇中に使用していなかった PC については、早急に下記のようなセキュリティ対策を行うことをおすすめします。また、休暇中外部に持ち出した PC については、内部ネットワークに接続する前に同様の対策を行うことをおすすめします。

1. - OS などのソフトウェアのセキュリティアップデートを適用する
2. - ウイルス対策ソフトなどの定義ファイルを更新する
3. - ハードディスクのウイルスチェックを行う
4. - 使用している機器やソフトウェアのセキュリティ関連情報の収集を行う

参考文書（日本語）

1. JPCERT/CC
2. 冬期の長期休暇を控えて
3. http://www.jpcert.or.jp/pr/2007/pr070009.txt

Topへ

データの消去

タイトル	対象	目的別カテゴリ	掲載号
記憶媒体からのデータ消去		インシデント発生前の予防	2005-02-02号

使用済みのパソコンやサーバ、または記憶媒体などを返却/破棄する際には、そこに保存されているデータを確実に消去することが推奨されます。一般的に、通常の「ファイル消去」の処理だけではデジタルデータは記憶媒体上に残されたままになっています。

確実にデータを消去するためには、記憶媒体上のデジタルデータを完全に別の (無意味な) 情報で上書きする方法があります。また、このような処理を容易に実現するための専用のソフトウェアも存在します。

参考文書（日本語）

1. 社団法人　電子情報技術産業協会 (JEITA)
2. パソコンの廃棄・譲渡時におけるハードディスク上のデータ消去に関するガイドライン
3. http://it.jeita.or.jp/perinfo/committee/pc/HDDdata/
4. 社団法人 電子情報技術産業協会 (JEITA)
5. パソコンの廃棄・譲渡時のハードディスク上のデータ消去に関するご注意
6. http://it.jeita.or.jp/perinfo/release/020411.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
データの消去方法について		保守・管理について	2006-11-15号

データ復旧用ソフトウェアなどを使用することで、削除されたファイルを再び読み取ることが可能になる場合があるため、保存してある内容の重要度や状況に応じてデータの消去方法を検討することが望まれます。

重要なデータを確実に消去する場合の例として、下記のような方法があります。

- 無意味なデータで上書きする

消去したいデータや記憶装置全体に無意味なデータを複数回にわたって上書きするなどの方法でデータの復旧・読み取りを困難にする方法があります。

- 電気的もしくは磁気的に破壊する

専用装置にて電気的もしくは磁気的に記憶領域を破壊する方法があります。

- 物理的に破壊する

記憶装置を物理的に破壊することで第三者がデータを読み取る事が難しくなります。

なお、上記の方法については、専用のツールや専門の業者も存在します。

参考文書（日本語）

1. 社団法人　電子情報技術産業協会 (JEITA)
2. パソコンの廃棄・譲渡時におけるハードディスク上のデータ消去に関するガイドライン
3. http://it.jeita.or.jp/perinfo/committee/pc/HDDdata/
4. 社団法人 電子情報技術産業協会 (JEITA)
5. パソコンの廃棄・譲渡時のハードディスク上のデータ消去に関するご注意
6. http://it.jeita.or.jp/perinfo/release/020411.html
7. JPCERT/CC REPORT 2005-02-02号 [今週の一口メモ]
8. 記憶媒体からのデータ消去
9. http://www.jpcert.or.jp/wr/2005/wr050501.txt
10. JPCERT/CC REPORT 2006-11-08号 [今週の一口メモ]
11. リムーバブルメディアの適切な運用方法を決める
12. http://www.jpcert.or.jp/wr/2006/wr064302.txt

Topへ

ドメイン/IP アドレス

タイトル	対象	目的別カテゴリ	掲載号
whois データベースの更新		保守・管理について	2006-03-29号

何らかのインシデントが発生した際に、関係するサイト (アクセス元など) の管理者に連絡を取って情報交換を行なうことが望ましい場合があります。その場合、一般的にはレジストリが公開している whois データベースに登録されている連絡先アドレスに連絡します。

しかし、この公開データベースの登録内容が更新されないまま放置されているために適切な担当者に連絡できず、結果としてインシデントによる被害を拡大させてしまったり、インシデントに関する情報が無関係の第三者に漏れてしまったりする場合があります。改めて自サイトで使用していていたりサブアロケートしていたりするアドレスブロックやドメイン名に対する登録内容に、更新漏れがないかどうかを確認するよう強くお願いします。

参考文書（日本語）

1. whois.jp
2. http://whois.jp/
3. 技術メモ - 関係サイトとの情報交換
4. http://www.jpcert.or.jp/ed/2002/ed020001.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
DNS の recursive query に対するアクセス制御		インシデント発生前の予防	2005-03-02号

外部から参照可能なドメインネームサーバに対して recursive query をかけることができるホストを制限することが推奨されます。BIND では、allow-recursion オプションで設定できます。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
送信ドメイン認証 その1		インシデント発生前の予防	2007-07-11号

メール配送プロトコル SMTP には、送信元メールアドレス詐称を防止する手段がなく、迷惑メールやフィッシングメールの多くは送信元を詐称して送信されています。

組織のドメインが詐称されて悪意あるメールが送信されると、その組織の信用が失われたり、フィッシングなどによって金銭的な被害が発生したりする可能性もあり、社会的に大きな問題になっています。

送信ドメイン認証とは、メール送信元のドメインが正当かどうかを認証するため仕組みで、以下の二つの認証方式について標準化が進められています。

1. - IP アドレスにもとづく認証
   SPF、Sender ID
2. - 電子署名を用いた認証
   DKIM

この二つは、互いの欠点を補完する認証方式であり、競合するものではありません。また PGP や S/MIME などのメッセージ署名と違いエンドユーザの手を煩わせることなく、メールサーバ上でメールを認証できるという利点があります。現在は、導入が比較的容易なこともあり SPF の普及が進んでいます。

メールサーバ管理者は、迷惑メール対策やフィッシングメール対策のために、また、組織の信用を失わないためにも、送信ドメイン認証の技術を導入することをおすすめします。

参考文書（日本語）

1. Japan Email Anti-Abuse Group
2. Sub Working Group: 送信ドメイン認証
3. http://jeag.jp/swg/senderauth/index.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
送信ドメイン認証 その2 (SPF: Sender Policy Framework)		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-07-19号

SPF は IP アドレスにもとづく送信ドメイン認証の技術のひとつであり、現在最も普及が進んでいます。

SPF では、メール送信側が送信サーバの情報を宣言します。一方、メール受信側は SMTP の MAIL FROM (envelope From) または HELO/EHLO コマンドから送信ドメインを特定し、そのドメインで宣言されたサーバからの通信かどうかを判定して認証を行います。

送信サーバの情報は DNS を使用して公開します。以下は一例です。

1. example.com. IN TXT "v=spf1 ip4:192.168.0.0/26 ~all"

この例では、example.com ドメインは 192.168.0.0/26 の IP アドレス範囲のサーバからメールを送信し、それ以外全ての IP アドレスからはメールを送信しない という宣言をしています。(「~all」の「~」は SoftFail を意味します。)

送信サーバの宣言に漏れがあると、正しく認証されるべきメールが認証されなくなる可能性があります。このため、組織のメール配送経路を正確に把握し、組織内でメール送信についてのポリシーを徹底することが重要です。

参考文書（日本語）

1. WIDE antispam WG
2. ドメイン認証の普及率に対する測定結果
3. http://member.wide.ad.jp/wg/antispam/stats/index.html.ja
4. 財団法人インターネット協会 有害情報対策ポータルサイト
5. RFC翻訳 RFC4408
6. http://www.iajapan.org/anti_spam/portal/Tech/
   RFC/RFC4408_01.html
7. JPCERT/CC REPORT 2007-07-11
8. 【今週のひとくちメモ】送信ドメイン認証 その1
9. http://www.jpcert.or.jp/wr/2007/wr072601.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
送信ドメイン認証 その3 (DKIM: DomainKeys Identified Mail)		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-08-01号

DKIM は、電子署名にもとづく送信ドメイン認証の技術のひとつです。

DKIM では、送信側は公開鍵と秘密鍵を作成し、公開鍵を DNS で公開します。秘密鍵は送信サーバにインストールしてメールを送信する際に署名を行います。署名した情報は DKIM-Signature ヘッダを追加して表記します。

以下は DKIM-Signature ヘッダの一例です。

1. DKIM-Signature: a=rsa-sha1; s=sel; d=example.com;
2.           c=simple/simple; q=dns/txt;
3.           h=From:To:Subject:Date:Message-ID;
4.           b=AuUo...

受信側は DNS を使用して公開鍵を取得し署名を検証します。上記の例では、d= タグで指定されたドメイン名と s= タグで指定されたセレクタ名を取りだし、以下の TXT レコードから公開鍵を取得します。

1. sel._domainkey.example.com. TXT "v=DKIM1; t=y;
2. k=rsa; p=MIG..."

DKIM は、メールのヘッダや本文に対して行われた署名を検証するため、メーリングリストなどで署名したヘッダや本文が変更された場合は検証に失敗することに注意してください。

DKIM は 2007年5月に IETF で RFC4871 として承認されました。今後の普及が期待されています。

参考文書（日本語）

1. JPCERT/CC REPORT 2007-07-11
2. 【今週のひとくちメモ】送信ドメイン認証 その1
3. http://www.jpcert.or.jp/wr/2007/wr072601.html#Memo
4. JPCERT/CC REPORT 2007-07-19
5. 【今週のひとくちメモ】送信ドメイン認証 その2 (SPF: Sender Policy Framework)
6. http://www.jpcert.or.jp/wr/2007/wr072701.html#Memo

参考文書（英語）

1. IETF
2. RFC4871 DomainKeys Identified Mail (DKIM) Signatures
3. http://www.ietf.org/rfc/rfc4871.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ドメインテイスティングとは		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-02-20号

ドメインテイスティング (Domain Tasting) とは、「ドメイン名登録後5日以内に登録を取り消せば登録料がかからない」というルールを逆手にとり、大量のドメイン名を登録・利用する行為です。ドメインテイスティング実行者は、ドメイン名を登録してから 5日間の期間内に、フィッシングサイトを公開したりクリック報酬型広告で不正に報酬を得たりします。

ICANN によると、2007年1月に登録取り消しされた 4800万近くの .com と .net ドメイン名のうち、およそ 95% が大規模なドメインテイスティングを行っている業者によるものでした。

ICANN の理事会はこういった状況を受けて、ドメイン名の登録時に年会費という形で一定額の支払いを求める予防策の導入を検討しています。

参考文書（日本語）

1. JPRS
2. ドメインテイスティング - 用語辞典 / JPRS
3. http://jpinfo.jp/glossary/index.php?ID=0123
4. JPNIC
5. インターネット用語1分解説～Add Grace Period(登録猶予期間)とは～
6. http://www.nic.ad.jp/ja/basics/terms/Add-Grace-Period.html

参考文書（英語）

1. ICANN
2. ICANN | Unsponsored TLD Agreement: Appendix C, Section 10 (.biz)
3. http://www.icann.org/tlds/agreements/biz/registry-agmt-appc-10-11may01.htm
4. ICANN
5. ICANN | ICANN Board Recommends Action on Domain Tasting
6. http://www.icann.org/announcements/announcement-29jan08.htm

Topへ

タイトル	対象	目的別カテゴリ	掲載号
名前解決に注意		インシデント発生前の予防	2005-07-13号

最近のコンピュータウィルスの中には、使用している PC 上にユーザの意図しない形で、ホスト名と IP アドレスの対応表を作成するものがあり、結果として、偽装サイトに誘導されてしまう可能性があります。

※ ホスト名を IP アドレスに変換する (いわゆる「名前解決」) には、通常 DNS (Domain Name Service) が用いられます。しかし、組織内のサーバや頻繁にアクセスするサーバなどについては、DNS を使わず、使用しているPC 自身にホスト名と IP アドレスの対応表を保持することで、名前解決を効率化できます。

使用している PC 上に意図しない内容の対応表が作成されていないか確認することをお勧めします。対応表の詳細については、使用している OS のマニュアル等を参照してください。

※ Windows の場合は C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS

UNIX 系の OS の場合は /etc/hosts など

Topへ

タイトル	対象	目的別カテゴリ	掲載号
名前解決に注意 その2		インシデント発生前の予防	2005-07-21号

LAN 内に、ホスト名と IP アドレスの対応表を配布するサーバが、LAN 管理者の意図しない形で勝手に設置され、且つ個々の PC などがそのようなサーバからの情報を受け入れるように設定されている場合、結果として、ユーザが偽装サイトに誘導されてしまう可能性があります。

※ JPCERT/CC REPORT 2005-07-13号の「今週の一口メモ」でも紹介した「名前解決」の方法として、NIS (Network Information Service) や NetInfo のような (主に LAN 内で) ネットワークを介してホスト名と IP アドレスの対応表を共有する方法があります。

LAN 内に管理者の意図しないサーバが設置されていないか、また個々の PC などがそのようなサーバからの情報を不用意に受け付けてしまう設定になっていないか定期的に確認することをお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-07-13 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr052701.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
名前解決に注意 その3		インシデント発生前の予防	2005-07-27号

ユーザを偽装サイトに誘導する目的で、LAN 管理者の意図しない形で LAN 内に DHCP (Dynamic Host Configuration Protocol) サーバが勝手に設置される場合があります。

※ この場合、偽の情報を提供する DNS サーバが、その DHCP サービスによって名前解決の参照先として設定されてしまいます。

LAN 内に管理者の意図しない DHCP サーバが設置されていないか、定期的に確認することをお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-07-13 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr052701.txt
3. JPCERT/CC REPORT 2005-07-21 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2005/wr052801.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
名前解決に注意 その4		インシデント発生前の予防	2005-08-03号

先週号まで 3回に渡って紹介した「名前解決に注意」において指摘した危険性が最も高まると考えられるのは、イベントや国際会議等の参加者向けに用意されたインターネット接続環境のような、不特定多数が利用可能なネットワーク環境です。

このような環境では、管理者の意図しないサーバが設置されても、そのことに気が付きにくいだけでなく、また気付いてもそのサーバが物理的にどこに設置されているのかを掴みにくい等の問題があります。

このようなネットワーク環境においては、名前解決を用いずに (あらかじめ記録していた) IP アドレスを直接使ってサーバにアクセスする、または IP アドレスで (IPSec などで相互認証された) VPN 接続を行ない、その VPN 環境でインターネットを利用する等の方法が推奨されます。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-07-13 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr052701.txt
3. JPCERT/CC REPORT 2005-07-21 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2005/wr052801.txt
5. JPCERT/CC REPORT 2005-07-27 [今週の一口メモ]
6. http://www.jpcert.or.jp/wr/2005/wr052901.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
国際化ドメイン名 (IDN) に注意		インシデント発生前の予防	2005-10-05号

国際化ドメイン名に対応したブラウザなどを使用する場合には注意が必要です。例えば、アルファベット (ASCII 文字) に似た文字 (例えばキリル文字の a など) を含んだドメイン名によって URL が詐称されていることに気付かず、正規の Web サイトになりすました phishing サイトなどに誘導される可能性があります。このような危険性を回避する方法としては、以下のような方法があります。

- リンクをたどらずに直接 URL を入力

- ブラウザを最新版に

表示されているページの URL に国際化ドメイン名が含まれている場合、最近の多くのブラウザでは、当該文字列を xn-- で始まる文字列に変換してアドレスバーに表示します。

- ステータスバーを確認

リンクをたどる前にステータスバーに表示された URL を確認します。xn-- で始まる文字列が含まれている場合は、国際化ドメイン名が使われています。Mozilla や Firefox など一部のブラウザには、非 ASCII 文字のまま表示する機能を持っているものがありますが、この機能が有効になっていないことをあらかじめ確認しておいてください。

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-016
2. Understanding Internationalized Domain Names
3. http://www.us-cert.gov/cas/tips/ST05-016.html

参考文書（日本語）

1. 社団法人日本ネットワークインフォメーションセンター
2. 国際化ドメイン名とは
3. http://www.nic.ad.jp/ja/dom/idn.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
公開電子メールアドレス		保守・管理について	2004-11-10号

インシデントに関連するサイトに連絡する場合の連絡先を探すには、一般的にレジストリが公開している Whois データベースを使用することが推奨されます。しかし、当該サイトが Web などを通じて公開している、webmaster@ドメイン名や info@ドメイン名といったアドレスに対して連絡が送られてくる場合も多々あります。したがって、そのような公開アドレスに届いたメールを処理する担当者と手順をあらかじめ明確にしておくことが強く推奨されます。

参考文書（日本語）

1. JPNIC WHOIS
2. http://www.nic.ad.jp/ja/whois/

Topへ

物理セキュリティ

タイトル	対象	目的別カテゴリ	掲載号
事務所移転時などの注意		インシデント発生前の予防	2005-10-13号

事務所の移転時や設備工事のような外部の人間が頻繁に出入りするような場合には、注意が必要です。普段は厳重に入退室が管理されている場所であっても、一般的にこのような場合には比較的出入りが容易にできるように一時的に設定が変更されてしまう傾向があります。そこで、情報管理ポリシーに反しないように、入退室の管理方法 (実装) が変更される前に管理すべき (機密) 情報を別の場所に移動し、基本的に同じポリシーの下で管理されるようにしておく必要があります。

Topへ

認証

タイトル	対象	目的別カテゴリ	掲載号
生体認証 (バイオメトリクス認証) その1		セキュリティ関連の機関や団体、用語や技術に関する説明	2005-05-23号

生体認証は、従来の ID/パスワードを利用した「その人のみが知る情報に基づく認証(知識認証)」や、スマートカードや USB トークンを利用した「その人のみが持つ物に基づく認証(所有物認証)」とは異なり、本人自身の生体的特徴を利用する認証方式です。そのため、認証情報を無くしたり盗まれたりする可能性が低く、利用者にとって利便性の高い認証方式とされています。

携帯電話や PC などを始め、金融機関の ATM などでも生体認証技術の利用が広がっています。

参考文書（日本語）

1. 独立行政法人 情報処理推進機構 セキュリティセンター
2. バイオメトリクス評価に関する調査
3. http://www.ipa.go.jp/security/fy16/reports/biometrics/
   index.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
生体認証 (バイオメトリクス認証) その2		セキュリティ関連の機関や団体、用語や技術に関する説明	2005-05-30号

生体認証で利用する生体情報の種類には、指紋、虹彩、静脈、声紋、筆跡のように多くの種類があります。また、これらを利用する生体認証デバイスも数多く市場に普及しています。

生体認証デバイスの精度/性能は、以下のような数値で評価できます。

1. - 正しい利用者本人を拒否する確率: 本人拒否率 (FRR: False Reject Rate)
2. - 他人を本人と認識してしまう確率: 他人受入率 (FAR: False Accept Rate)

これらの精度評価は、国際的な標準化も進められていますが、現時点では各メーカが独自に発表しています。生体認証デバイスを採用する際には、実際に使用して評価検討することが重要です。また、採用するデバイスで認証できない利用者に対する代替手段の検討も行っておくことをおすすめします。

参考文書（英語）

1. 社団法人日本自動認識システム協会
2. BIOMETRICS
3. http://www.jaisa.or.jp/action/group/bio/shoukai.html
4. JPCERT/CC REPORT 2007-05-23
5. 【今週のひとくちメモ】生体認証 (バイオメトリクス認証) その1
6. http://www.jpcert.or.jp/wr/2007/wr071901.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
生体認証 (バイオメトリクス認証) その3		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-06-06号

生体認証の技術は他の認証方式と比較して歴史が浅く、現在も評価と改良が続けられています。

生体認証では本人の身体的特徴や行動的特徴を利用するため、基本的に認証情報の変更は困難です。このため、一度認証情報が漏えいすると、その人は生涯リスクを負うことになります。他のシステムで同じ生体情報を使用している場合、それらのシステムに影響が波及する可能性があります。

生体認証システムを構築運用する場合には、生体認証だけでなく、パスワードやスマートカードなど他の認証方式と併用し(多要素認証)、認証に利用する生体情報を適切に管理して、その管理方法をユーザに説明することを推奨します。

参考文書（日本語）

1. 金融庁: 偽造キャッシュカード問題に関するスタディグループ
2. 金融取引における生体認証について
3. http://www.fsa.go.jp/singi/singi_fccsg/gaiyou/f-20050415-singi_fccsg/02.pdf
4. JPCERT/CC REPORT 2006-07-12
5. 【今週の一口メモ】複数の認証を併用する
6. http://www.jpcert.or.jp/wr/2006/wr062601.txt
7. JPCERT/CC REPORT 2007-05-23
8. 【今週のひとくちメモ】生体認証 (バイオメトリクス認証) その1
9. http://www.jpcert.or.jp/wr/2007/wr071901.html#Memo
10. JPCERT/CC REPORT 2007-05-30
11. 【今週のひとくちメモ】生体認証 (バイオメトリクス認証) その2
12. http://www.jpcert.or.jp/wr/2007/wr072001.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
複数の認証を併用する		インシデント発生前の予防	2006-07-12号

複数の認証を併用することで、各認証方式の短所をカバーして強いセキュリティを確保することが可能です。例えば、パスワード認証とスマートカード認証を組み合わせることで、パスワード漏洩によるリスクやカード紛失によるリスクの双方が軽減されます。

参考文書（英語）

1. US-CERT National Cyber Alert System
2. ST05-012-Supplementing Passwords
3. http://www.us-cert.gov/cas/tips/ST05-012pr.html

Topへ

パケットフィルタリング/ファイアウォール

タイトル	対象	目的別カテゴリ	掲載号
ブラックリスト参照機能に注意		インシデント発生前の予防	2007-01-31号

メールサーバや Web プロキシとして動作するアプライアンスやソフトウェア製品の中には、メール受信制限や Web フィルタリングを実現するために外部のブラックリスト (ブロックリスト、ブロッキングリスト) を参照する機能を持つものがあります。

1. 使用している製品にこのような機能が組み込まれている場合、機能が有効になっていることに気付かないまま使用してしまうことがあります。結果として、意図に反した形でメールの受信や Web の閲覧が制限されてしまい、業務に支障をきたすことがあります。特に、外部からのメールがブラックリストによって削除されるような設定になっていた場合、必要なメールが届いていないことに気付かなかったり、気付くのが遅れたりすると、トラブルのもととなります。
2. そこで、お使いの製品について、以下の点を確認することをお勧めします。
3. 外部のブラックリストを参照する機能の有無
   1. 機能が存在する場合は、その設定方法および設定状況
4. 参照先のブラックリストの信頼性
   2. ブラックリストの運用ポリシー

Topへ

タイトル	対象	目的別カテゴリ	掲載号
修正プログラム適用時の注意		インシデント発生前の予防	2004-05-12号

修正プログラムやパッチが未適用のシステムはネットワークから切り離しておくことが推奨されます。しかし、もし修正プログラム適用のためにネットワークへの接続が必要な場合は、パケットフィルタリング機能によってから当該システムへのアクセスおよび当該システムから外部へのアクセスが適切に制限されていることを確認してからネットワークに接続することを強くお勧めします。

パケットフィルタリング機能は、ルータやファイアウォールで実現できますが、Microsoft Windows XP などのように OS 自体がその機能を有している場合もあります。詳細についてはマニュアルをご参照ください。

参考文書（日本語）

1. マイクロソフト セキュリティスクエア
2. Windows XP のパーソナルファイアウォール
3. http://www.microsoft.com/japan/security/square/guard/
   a04g5.asp

Topへ

タイトル	対象	目的別カテゴリ	掲載号
外部の 25/tcp 宛パケットのフィルタリング		インシデント発生前の予防	2004-07-14号

最近のウィルスやワームには、感染後に SPAM メールを送信するための踏み台として機能するものがあります。そこで、自サイト内から外部に対して SPAM メールを送信しないようにするための対策として、外部のメールサーバに対して SMTP セッションを開始できるのは特定のメールサーバのみとし、それ以外のホストから外部への 25/tcp 宛てパケットはファイアウォールなどでフィルタリングする方法があります。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Directed Broadcast パケット		インシデント発生前の予防	2005-04-06号

第三者によって、いわゆる「Smurf Amplifier」攻撃などに使われないために、ルータにおいて、外部からの directed broadcast パケットを受け取らないように設定しておくことが推奨されます。

参考文書（英語）

1. Request for Comments: 2644
2. Changing the Default for Directed Broadcasts in Routers
3. http://www.ietf.org/rfc/rfc2644.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ブロードキャストアドレス宛の icmp echo パケット		インシデント発生前の予防	2005-04-13号

ルータだけでなく、ホスト側においても、ブロードキャストアドレス宛の icmp echo パケットに反応しないように設定することが推奨されます。設定方法としては、UNIX 系の OS ならばカーネル変数を、Windows ならばパーソナルファイアウォールを用いるなどの方法があります。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
送信元 IP アドレスを詐称したパケットのフィルタリング		インシデント発生前の予防	2005-08-17号

ルータやファイアウォールにおいて、送信元 IP アドレスが詐称されているパケットをフィルタリングすることが推奨されます。 例えば、本来内部で保持していない IP アドレスを送信元とするパケットが外部に送信される場合、送信元 IP アドレスが詐称されていると判断してフィルタします。 送信元 IP アドレスの詐称は、サービス運用妨害 (DoS) 攻撃など様々な攻撃で使われる基本的な手法のひとつです。自サイトから他のサイトに対する攻撃を防ぐためにも、このようなフィルタリングを設定することを強くお勧めします。なお、設定を一行追加するだけで実現できる装置もありますので、改めてマニュアルなどをご確認ください。

参考文書（英語）

1. Network Ingress Filtering:
2. Defeating Denial of Service Attacks which employ IP Source Address Spoofing
3. http://www.ietf.org/rfc/rfc2827.txt
4. http://www.ipa.go.jp/security/rfc/RFC2827JA.html(日本語訳)
5. Ingress Filtering for Multihomed Networks
6. http://www.ietf.org/rfc/rfc3704.txt
7. http://www.ipa.go.jp/security/rfc/RFC3704JA.html(日本語訳)
8. Global Incident Analysis Center - Special Notice
9. Egress Filtering v 0.2
10. http://www.sans.org/y2k/egress.htm

Topへ

タイトル	対象	目的別カテゴリ	掲載号
家庭内におけるルータ利用の推奨		インシデント発生前の予防	2005-11-02号

家庭の PC をインターネットに接続する場合、モデムなどに PC を直結して使用するよりも、いわゆる「ブロードバンドルータ」を間に挟むことが推奨されます。一般的に「ブロードバンドルータ」には標準でファイアウォール機能が組み込まれているので、これにより外部から PC への不要なアクセス (の一部) を防ぐことができます。結果として、PC への侵入やワームによる感染の危険性を低減することができると考えられます。

Topへ

パッチの適用

タイトル	対象	目的別カテゴリ	掲載号
独自パッケージのバージョン管理について把握する		保守・管理について	2008-07-09号

ソフトウェア製品は開発元が公開している他に各種 OS ベンダなどが独自にパッケージ化して提供していることがあります。

このようなソフトウェア製品について脆弱性対応が行われたとき、開発元からの対策版提供とは別に、独自パッケージ配布元において、対策版パッケージが提供されることがあります。

配布元の開発・提供ポリシーに関係しますが、ソフトウェア製品はバージョンによって機能の違いもありうるため、旧版に対して脆弱性対応を行なって提供している例が多くあります。このような場合、パッケージのバージョンには脆弱性を指摘された旧バージョン番号が使われていることとなります。

例えば、OpenSSH に関する CVE-2008-1483 という問題では、OpenSSH チームからは対策版として OpenSSH-5.0 が提供されています。これに対し OS 配布元における対応例として Debian GNU/Linux が OpenSSH 1.4.3 を元にした openssh-client 1.4.3p2-9etch1 を独自パッケージとして提供しています。

このように独自パッケージにおいては、開発元が提供している対策バージョンよりも前のバージョンに対して対策がなされていることがあり、システム管理者は配布元のこのような提供ポリシーについて把握しておくことが必要です。

JPCERT/CC REPORT では開発元が提供している対策済みバージョンを記載する代わりに「使用している OS のベンダや配布元が提供する修正済みのバージョンに更新することで解決します。」といった記述を多く用いています。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
パッチ適用時の注意事項		インシデント発生前の予防	2005-10-26号

パッチなどのセキュリティ修正プログラムの中には、適用時に設定内容を初期化したり、上書きしたりしてしまうものがあります。そこで、パッチなどを適用する前に可能な限り設定内容のバックアップを取り、適用後に設定内容が変更されていないか確認することを強くお勧めします。

またパッチの適用によって、別の部分に不具合 (性能の著しい低下など) が発生する場合もあります。万が一の場合に備えて、パッチ適用前の状態に速やかに戻せるようにバックアップを取っておくことも併せて推奨されます。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
検証用環境を用意する		インシデント発生前の予防	2006-08-16号

実際の業務に使用するシステムに対してセキュリティパッチを適用した場合、必要なソフトウェアが動作しなくなるなど、業務に支障をきたす可能性があります。そこで、システムの重要性に応じて実際に使用するシステムに近い検証用環境を用意し、パッチの適用による影響を確認するようお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
検証用環境についての注意		インシデント発生前の予防	2006-08-23号

パッチ適用などによるシステムへの仕様変更は以下のような影響を及ぼす可能性があります。

1. - ライブラリのバージョンアップによるプログラムの互換性の問題
2. - ネットワークトラフィックの急増
3. - システムにログインできなくなるなどの認証に関連する不具合
4. - 設定ファイルの消失、パスの変更などで設定していたパラメータが無効になる
5. - システムの予期せぬリブート
6. したがって実運用環境に変更を加える際には、事前に同じ構成の検証用環境を使用してテストを行うことが望ましいといえます。

実運用環境と同じ検証用環境を持つことが困難な場合、二つの環境の違いを事前に把握しておくことが必要です。これにより不具合が発生した場合に、原因が特定しやすくなります。実際の業務に使用するシステムに対してセキュリティパッチを適用した場合、必要なソフトウェアが動作しなくなるなど、業務に支障をきたす可能性があります。そこで、システムの重要性に応じて実際に使用するシステムに近い検証用環境を用意し、パッチの適用による影響を確認するようお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2006-08-16 号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2006/wr063101.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
アップデートパッケージの検証		インシデント発生前の予防	2005-06-22号

セキュリティ上の問題を修正するためのパッチを適用したり、修正済みのパッケージに更新したりする際には、可能な限り、入手したパッチや修正済みパッケージが正規の配布元が提供しているものであることを検証することをお勧めします。

具体的には、パッチや修正済みパッケージを SSL などによる電子署名を用いたサイトからダウンロードし、(検証された) サイトに掲示されている MD5 や SHA-1 などのチェックサム (ハッシュ値) と照らし合わせて検証するなどの方法があります。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-05-18号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr051901.txt
3. JPCERT/CC REPORT 2005-05-25号 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2005/wr052001.txt
5. JPCERT/CC REPORT 2005-06-01号 [今週の一口メモ]
6. http://www.jpcert.or.jp/wr/2005/wr052101.txt

Topへ

非常時の連絡先

タイトル	対象	目的別カテゴリ	掲載号
非常時の連絡先の確認		保守・管理について	2004-06-23号

何らかのインシデントが発生した場合、ネットワーク自体が使用できなくなることが多々あります。そのような場合に備え、例えば接続プロバイダの連絡窓口などの非常時の連絡先をあらかじめメモして保管しておくなどの準備をしておくことが推奨されます。

Topへ

ファームウェア

タイトル	対象	目的別カテゴリ	掲載号
ファームウェアを更新する		インシデント発生前の予防	2006-03-15号

近年ネットワークに接続する機器として PC 以外のもの (ルータ、インターネット家電など) が増えてきています。これらの機器は、その利用方法からファームウェア更新の必要があった場合も、そのことを見逃しがちです。結果として、これらの機器の脆弱性が放置され、インシデントにつながる恐れがあります。

ネットワークに接続されている PC 以外の機器であっても、各メーカーのページを定期的に参照するなどして、必要に応じてファームウェアを更新することをお勧めします。

Topへ

ファイル交換ソフト

タイトル	対象	目的別カテゴリ	掲載号
ファイル交換ソフトの使用に注意		インシデント発生前の予防	2005-12-28号

ファイル交換ソフトには、ウィルスに感染することで PC 上の任意のファイルをネットワーク上に送信するものがあります。長期休暇などで業務に用いている PC を自宅に持ち帰った時にこのようなウィルスに感染すると、重要なファイルが予期せず外部に流出する可能性があります。重要なデータが保存されている PC ではファイル交換ソフトを使用しないことを強くお勧めします。

Topへ

フィッシング/詐欺

タイトル	対象	目的別カテゴリ	掲載号
phishing (Web 偽装詐欺) サイトにされてしまったら		インシデント発生時の対処	2005-04-20号

第三者によって自サイトが phishing サイトに用いられた場合、そのコンテンツを削除するだけでは充分な対応とは言えません。充分な対策を取らないままシステムを使用した場合、再度 phishing サイトとして使用されてしまう可能性があります。JPCERT/CC にも、事例が既に数件報告されています。

再度 phishing サイトとして使用されてしまう原因としては、システムが侵入行為によって何らかの改ざんを受けていることが挙げられます。侵入の結果として、phishing 目的のコンテンツが置かれるだけでなく、いわゆるバックドアなどが設置される場合があります。また、侵入行為の原因となったシステムの脆弱性を放置しておくと、再び侵入されて様々な改ざんを受ける可能性があります。

以上を鑑みて、充分な対策を施すことが求められます。システムのどのような脆弱性が侵入に使用されたのかといった原因を究明し、再発防止策を講じた上でシステムを初期化し、OS を再インストールすることを強くお勧めします。

参考文書（日本語）

1. 技術メモ - コンピュータセキュリティインシデントへの対応
2. http://www.jpcert.or.jp/ed/2002/ed020002.txt
3. 技術メモ - Web ページの改竄に対する防衛
4. http://www.jpcert.or.jp/ed/2001/ed010006.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
phishing サイトとして使われる脆弱なホストの放置に伴う危険性		インシデント発生時の対処	2006-06-21号

金融機関などを装った phishing サイトが立ちあげられているにも関わらず、当該ホストの管理者がその事実に気がつかず、もしくは気がついているにも関わらず放置されているケースがあります。phishing サイトを放置し続けていると、インターネットユーザ側に生じる被害が拡大するだけでなく、当該ホスト自体が情報漏えい等の危険にさらされ続けていることにもなるので、早急な対応が必要です。

考えられる危険性には以下のようなものがあります。

1. - 当該ホスト上で管理している非公開ファイルを閲覧される (情報漏洩)
2. - サービス運用妨害 (DoS) 攻撃の踏み台にされる
3. - スパムメール送信の踏み台にされる
4. - ボットやウイルス感染ファイルなどの設置、公開

参考文書（日本語）

1. JPCERT/CC REPORT 2005-04-20号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2005/wr051601.txt
3. Web 偽装詐欺 (phishing) の踏み台サーバに関する注意喚起
4. http://www.jpcert.or.jp/at/2005/at050002.txt
5. 技術メモ - Web ページの改竄に対する防衛
6. http://www.jpcert.or.jp/ed/2001/ed010006.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
phishing サイトとして使われる脆弱なホストの放置に伴う危険性 その2		インシデント発生時の対処	2006-06-30号

自身の管理するホストが phishing サイトを公開しているという事実が判明した場合、システムが侵入を受けている可能性があるため、可能な限り早急な対応 (特にネットワークからの隔離) が必要です。

phishing サイトであることが確認された URL 上で公開されている不審なファイルだけでなく、他にも phishing に関連するファイルが置かれていたり、rootkit によってバックドアなどが仕掛けられていたりする可能性があるため、当該ホストをネットワークから切り離す (LAN ケーブルを抜く) ことを強くお勧めします。

また、インシデントからの復旧や再発防止ならびに調査・分析のため、当該ホストを隔離した上で、不審なファイルやログ情報などを保全する作業も重要です。

参考文書（日本語）

1. JPCERT/CC REPORT 2006-06-21号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2006/wr062301.txt
3. JPCERT/CC REPORT 2005-04-20号の「一口メモ」
4. http://www.jpcert.or.jp/wr/2005/wr051601.txt
5. Web 偽装詐欺 (phishing) の踏み台サーバに関する注意喚起
6. http://www.jpcert.or.jp/at/2005/at050002.txt
7. 技術メモ - Web ページの改竄に対する防衛
8. http://www.jpcert.or.jp/ed/2001/ed010006.txt
9. ITmedia エンタープライズ
10. 自社サーバがフィッシングサイトに「踏み台化」されたら？
11. http://www.itmedia.co.jp/enterprise/articles/0603/17/
    news004.html
12. 関連サイト
13. フィッシング対策協議会
14. http://www.antiphishing.jp/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
phishing サイトとして使われる脆弱なホストの放置に伴う危険性 その3		インシデント発生時の対処	2006-07-05号

phishing サイトとして使用されてしまったホストには、把握しきれない不審なファイルが残っており、全てのファイルを削除しきれない可能性があります。このため、ホストの再起動後に、phishing サイトが再び公開されるケースも複数報告されています。

自身の管理するホストが phishing サイトとして使用されてしまっていた場合、復旧作業として、HDD を初期化した上で OS の再インストール、既知の脆弱性に対応済みのパッチを適用するなどの措置をとるよう強く推奨します。

なお、再インストール作業でデータを復元する際、バックアップテープ等を使用する場合は、バックアップされた情報自体に置き換えられたファイルやインストールされた不審なサーバプログラム等が記録されてしまっていないか、十分注意してください。

参考文書（日本語）

1. JPCERT/CC REPORT 2006-06-28号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2006/wr062402.txt
3. JPCERT/CC REPORT 2006-06-21号の「一口メモ」
4. http://www.jpcert.or.jp/wr/2006/wr062301.txt
5. JPCERT/CC REPORT 2005-04-20号の「一口メモ」
6. http://www.jpcert.or.jp/wr/2005/wr051601.txt
7. Web 偽装詐欺 (phishing) の踏み台サーバに関する注意喚起
8. http://www.jpcert.or.jp/at/2005/at050002.txt
9. 技術メモ - Web ページの改竄に対する防衛
10. http://www.jpcert.or.jp/ed/2001/ed010006.txt
11. 技術メモ - コンピュータセキュリティインシデントへの対応
12. 「V. 侵入への対応」
13. http://www.jpcert.or.jp/ed/2002/ed020002.txt
14. ITmedia エンタープライズ
15. 自社サーバがフィッシングサイトに「踏み台化」されたら？
16. http://www.itmedia.co.jp/enterprise/articles/0603/
    17/news004.html
17. 関連サイト
18. フィッシング対策協議会
19. http://www.antiphishing.jp/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
慈善団体を装った phishing に注意		インシデント発生時の対処	2006-05-31号

大きな自然災害が発生した際には、赤十字社や慈善団体などを装って寄付を募る phishing 詐欺 (およびそれにつながる行為) の発生が予想されます。このような phishing 詐欺に注意するとともに、このような詐欺にあってしまった場合には、速やかに自分の使用している銀行やカード会社などに自分の登録情報が盗まれてしまった可能性があることを伝えてください。

参考文書（日本語）

1. フィッシング対策協議会
2. インターネット詐欺に使われる手口の紹介 (第2回)
3. 「救援募金する人を標的にしたフィッシング詐欺」について
4. http://www.antiphishing.jp/news/000016.html
5. JPCERT/CC REPORT 2005-09-07号 [今週の一口メモ]
6. http://www.jpcert.or.jp/wr/2005/wr053501.txt

参考文書（英語）

1. CERT/CC Current Activity Archive
2. Hurricane Katrina Spawns Phishing Sites
3. http://www.us-cert.gov/current/archive/2005/09/01/archive.html#kat
4. Anti-Phishing Working Group
5. http://www.antiphishing.org/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web phishing (Web 偽装詐欺)		インシデント発生前の予防	2004-08-11号

Web phishing の被害が急増しています。これは銀行などのサイトであると詐称して、Web のフォームなどから入力された口座番号やキャッシュカードの暗証番号といった個人情報を盗み取るものです。既に国内での被害も報告されており、注意が必要です。

Web phishing の被害を受けないためには、ある特定の Web サイトにアクセスするように促してきたメールが本当に送信元とされる組織から送られてきたものなのかを、送信元とされる組織に直接確認することが必要です。その場合、連絡先の情報として、送られてきた電子メールや Web サイトに掲載された情報を用いてはいけません。契約時に取り交わした書類など、確実に対象となる組織から送付されたものであることが確認できる資料に掲載された情報を用いてください。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-014
2. Avoiding Social Engineering and Phishing Attacks
3. http://www.us-cert.gov/cas/tips/ST04-014.html

参考文書（日本語）

1. JPCERT/CC REPORT 2004-07-22号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2004/wr042801.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web phishing (Web 偽装詐欺) その2		インシデント発生前の予防	2004-08-18号

Web phishing の被害を受けないためには、対象となる Web サイトのドメイン名が本当にその組織のものであるかをインターネット以外の方法で入手した情報を元に確認する必要があります。しかし、たとえドメイン名 (の文字列) が正しいものであったとしても、Web ブラウザの脆弱性のために、詐称された URL が表示されてしまう場合があります。使用している Web ブラウザにそのような脆弱性が存在していないかどうかを確認し、脆弱性が存在する場合は、パッチを適用したり、回避策を講じたりすることを強くお勧めします。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-014
2. Avoiding Social Engineering and Phishing Attacks
3. http://www.us-cert.gov/cas/tips/ST04-014.html

参考文書（日本語）

1. JPCERT/CC REPORT 2004-08-11号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2004/wr043101.txt
3. JPCERT/CC REPORT 2004-07-22号の「一口メモ」
4. http://www.jpcert.or.jp/wr/2004/wr042801.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web phishing (Web 偽装詐欺) その3		インシデント発生前の予防	2004-08-25号

Web phishing の実例として、電子メールなどで誘導された URL にアクセスすると、ブラウザ本体に表示された画面は確かに正規のサイトのものであるにもかかわらず、同時に表示されたポップアップウィンドウだけが偽装されたものであるという事例が報告されています。このケースでは、ポップアップウィンドウに暗証番号などの機密情報を入力するように促すフォームがあり、そのフォームに入力した情報が全く関係のない別のサイトに送信されていました。

ポップアップウィンドウは、それがどのサイトのものであるかを判別することが極めて難しい場合が多いので、このようなウィンドウに対して機密情報を入力することは避けることが推奨されます。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-014
2. Avoiding Social Engineering and Phishing Attacks
3. http://www.us-cert.gov/cas/tips/ST04-014.html

参考文書（日本語）

1. JPCERT/CC REPORT 2004-08-18号の「一口メモ」
2. http://www.jpcert.or.jp/wr/2004/wr043201.txt
3. JPCERT/CC REPORT 2004-08-11号の「一口メモ」
4. http://www.jpcert.or.jp/wr/2004/wr043101.txt
5. JPCERT/CC REPORT 2004-07-22号の「一口メモ」
6. http://www.jpcert.or.jp/wr/2004/wr042801.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web サイトの偽装を見破るには		インシデント発生前の予防	2005-01-13号

Web ブラウザでアクセスしたサイトが正規のサイトであるか否かを確認するには、アクセスしているページの URL をアドレスバーなどで確認する方法が最も簡単です。ただし、正規のサイトに似た紛らわしいドメイン名が使用されている場合もありますので、URL の文字列は注意深く確認する必要があります。

しかしながらこの方法は、以下のような偽装が行なわれた場合には有効でないことに注意する必要があります。

1. - DNS (正引き) の偽装
2. - Web ブラウザの脆弱性を使った URL の偽装

特に後者の Web ブラウザの脆弱性は様々なブラウザに発見されているため、使用しているブラウザのセキュリティ情報を参照し、必要なパッチの適用やソフトウェアの更新などの対策を施すことを強くお勧めします。

なお、確実に正規のサイトであるか否かを確認するには、SSL (https) を用いた署名がなされているページに対して証明書を確認する方法が最も有効です。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web サイトの偽装を見破るには その2		インシデント発生前の予防	2005-01-19号

Web ブラウザでアクセスしたサイトが正規のサイトであるか否かを確実に確認するには、SSL (https) を用いた署名がなされているページに対して証明書を確認する方法が最も有効です。

具体的な確認方法はブラウザによって異なりますが、多くのブラウザでは、署名されたページを表示している場合にブラウザの右下に鍵のアイコンが表示されます。そのアイコンをクリックすることで署名の内容を確認することができます。

ただし、通信経路の暗号化のみの目的で SSL を使うために、ブラウザ提供元によって認証されていない機関 (例えば自サイト) から発行された証明書を使用しているサイトがありますが、このような証明書による「署名」は一般的に署名としては意味をなさないことに注意してください。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ソーシャルエンジニアリング		インシデント発生前の予防	2007-06-20号

ソーシャルエンジニアリングとは、コンピュータに侵入するためなどに、人の心理的・社会的な弱点や盲点を使用する手法です。

電話やメールで、企業の従業員に対して同僚や情報システム管理者などの関係者を名乗り、ID やパスワードを詐取する「なりすまし」や、事務所の廃棄物から情報を詐取する「ごみあさり」などが代表的です。

ソーシャルエンジニアリングは古くからある手法ですが、最近でも、特定の企業に対して社内の関係者を装ったウイルス付きメールを送信するなどのソーシャルエンジニアリングを用いた攻撃が発生しています。引き続き、このような攻撃には注意が必要です。

参考文書（日本語）

1. JPCERT/CC Alert 2007-06-14
2. ID やパスワードを聞き出そうとする電話に関する注意喚起
3. http://www.jpcert.or.jp/at/2007/at070015.txt
4. 総務省 社員・職員全般のための情報セキュリティ対策
5. ソーシャルエンジニアリングの対策
6. http://www.soumu.go.jp/joho_tsusin/security/
   business/work05.htm
7. 独立行政法人 情報処理推進機構
8. 国内におけるソーシャル・エンジニアリングの実態調査 (PDF)
9. http://www.ipa.go.jp/security/fy11/report/contents/
   intrusion/socialeng/socialeng.pdf

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ドメイン登録会社を装ったフィッシングメールに注意		インシデント発生前の予防	2008-11-12号

ドメイン登録会社 (レジストラ) を装ってドメインの期限切れのお知らせや登録情報更新を促すメールを送付するフィッシングが増加しています。このフィッシングは、攻撃者の用意した偽のドメイン管理 Web サイトへ誘導し、管理アカウントを詐取して、ドメインを乗っ取ることを目的にしています。

ドメイン管理者は、このような手口にだまされないためにも、ドメイン登録更新に関するメールには特に注意し、記載されたリンクをむやみにたどらないようにしましょう。

参考文書（日本語）

1. フィッシング対策協議会
2. NetworkSolutionsをかたるフィッシング
3. http://www.antiphishing.jp/database/database312.html
4. JPCERT/CC
5. フィッシングに関する FAQ
6. http://www.jpcert.or.jp/ir/faq.html

参考文書（英語）

1. ICANN: SSAC Reports and Advisories
2. [SAC028] SSAC Advisory on Registrar Impersonation Phishing Attacks (PDF)
3. http://www.icann.org/committees/security/sac028.pdf
4. SANS Internet Storm Center
5. Handler's Diary: Enom Phishing - Caution Enom Registrars
6. http://isc.sans.org/diary.html?storyid=5252

Topへ

タイトル	対象	目的別カテゴリ	掲載号
偽オンラインショッピングサイトに注意		インシデント発生前の予防	2005-12-14号

Wオンラインショッピングサイトやオークションサイトを装ったサイトによって、商品代金が騙し取られたり、クレジットカード番号などの機密情報が盗まれたりする被害が発生しています。オンラインショッピングサイトやオークションサイトを利用する場合には以下の点に注意してください。

- SSL (https) による電子署名および経路の暗号化が行なわれているか確認

機密情報を送信するページにおいて、署名がない、また経路の暗号化が行なわれていないサイトは利用しないことをお勧めします。

- SSL サーバ証明書の内容に問題がないか確認

証明書自体は適切な認証局から発行されていても、本来のサイトを運営している会社とは全く無関係の会社の証明書である場合があります。このように、サイトを運営している会社と証明書に記載された会社との関係が明確でない場合は、そのサイトを利用しないことをお勧めします。

- オンラインで使用する専用クレジットカードを準備

普段使用するクレジットカードとオンラインショッピングなどで使用するカードを別にし、後者で使用するカードの上限金額を低めに設定することをお勧めします。また、請求書の明細をこまめに確認することを強くお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-01-19号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2005/wr050301.txt
3. JPCERT/CC REPORT 2005-05-18号 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2005/wr051901.txt
5. JPCERT/CC REPORT 2005-05-25号 [今週の一口メモ]
6. http://www.jpcert.or.jp/wr/2005/wr052001.txt
7. JPCERT/CC REPORT 2005-06-01号 [今週の一口メモ]
8. http://www.jpcert.or.jp/wr/2005/wr052101.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
銀行合併に伴うフィッシングに注意		インシデント発生前の予防	2005-12-28号

銀行の合併に伴い、「登録情報の更新」を依頼するようなフィッシングメールが送信されたり、偽装ソフトウェアが入った CD-ROM が送付される可能性があります。その際には、

- 送信されてきたメールに掲載された URL などは、アクセスするだけでウィルスに感染する可能性があるので、不用意にアクセスしない

- 送付されてきた CD-ROM は、パソコンに読み込ませるだけでウイルスやキーロガーに感染する可能性があるので、不用意にパソコンに読み込ませない

- 偽装された可能性のあるソフトウェアを実行しない

など、細心の注意が必要です。

なお、送信/送付元の信頼性についてはインターネット以外の方法 (契約書などの書類に記載された問合せ先への電話など) を用いて確認することを強くお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
キャンペーン目的の検索キーワード		インシデント発生前の予防	2006-07-20号

キャンペーン等の目的で、検索キーワードが新聞やテレビの広告等で紹介されることがあります。しかし、紹介されたキーワードで検索したときに、広告側が意図したサイトではなく、キャンペーン等に便乗することを目的としたサイトが上位に表示されることがあります。

キャンペーン等に便乗することを目的としたサイトの中には、ソフトウェアの強制的なインストールやフィッシングなどを目的としたサイトが存在することも考えられます。したがって、検索の結果表示されたサイトにアクセスする際には十分な注意が必要です。

参考文書（日本語）

1. JPCERT/CC REPORT 2005-01-13号の「一口メモ」
2. Web サイトの偽装を見破るには
3. http://www.jpcert.or.jp/wr/2005/wr050201.txt
4. JPCERT/CC REPORT 2005-01-19号 [今週の一口メモ]
5. Web サイトの偽装を見破るには その2
6. http://www.jpcert.or.jp/wr/2005/wr050301.txt
7. JPCERT/CC REPORT 2005-05-18号 [今週の一口メモ]
8. Web サイトの証明書
9. http://www.jpcert.or.jp/wr/2005/wr051901.txt
10. JPCERT/CC REPORT 2005-05-25号 [今週の一口メモ]
11. Web サイトの検証
12. http://www.jpcert.or.jp/wr/2005/wr052001.txt

参考文書（日本語）

1. US-CERT Cyber Security Tip ST05-010
2. Understanding Web Site Certificates
3. http://www.us-cert.gov/cas/tips/ST05-010.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
虚偽の警告メッセージに注意		インシデント発生前の予防	2006-08-30号

ブラウザ上に虚偽の警告メッセージを表示するなどして、セキュリティ対策ソフトを装った不審なソフトウェアのダウンロードもしくは購入手続きをさせようとする行為があるため、注意が必要です。

不審な警告やソフトウエアの導入を求められた際には、むやみに操作せず、内容をよく確認するなど、冷静に行動することが大切です。

虚偽の警告メッセージとしては、例えば以下のようなものがあります。

1. - 「ウイルスに感染しています!」
2. - 「エラーが発生しました!」
3. - 「レジストリが壊れています!」
4. - 「公的機関に監視されています!」

急な警告などで不安になった場合、まずは、意図しない通信が行われないようにするために、LAN ケーブルを抜いたり、無線 LAN を無効にしたりするなどして PC をネットワークから隔離してください。その上で、信頼できるウイルス等検知ソフトウェアを使用して、不審なソフトウェアの有無を確認することをお勧めします。

参考文書（日本語）

1. 独立行政法人 情報処理推進機構 (IPA)
2. コンピュータウイルス・不正アクセスの届出状況[7月分]について
3. http://www.ipa.go.jp/security/txt/2006/08outline.html
4. 独立行政法人 情報処理推進機構 (IPA)
5. コンピュータウイルス・不正アクセスの届出状況[4月分]について
6. http://www.ipa.go.jp/security/txt/2006/05outline.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
偽セキュリティ対策ソフトに注意		インシデント発生前の予防	2007-06-13号

セキュリティ対策ソフトを装い、ユーザに代金を支払わせようとしたり、悪意あるプログラムをインストールさせたりする、いわゆる「偽セキュリティ対策ソフト」には注意が必要です。

偽セキュリティ対策ソフトは、ベンダが運営しているように見せかけた Web サイトで配布され、Web 広告などを用いてユーザを誘導し導入を促します。また、実際にはセキュリティ対策機能が備わっていないソフトウェアがほとんどで、悪意あるプログラムをインストールさせる場合があります。

初めて導入するソフトウェアについては、信頼できるセキュリティ対策組織の Web サイトやニュースサイトなどに危険を警告する情報が記載されていないか、導入前に調べることをお勧めします。

Topへ

ポート

タイトル	対象	目的別カテゴリ	掲載号
ポート番号の確認		インシデント発生前の予防	2005-07-06号

一般的に侵入などのインシデントの予兆として、(脆弱性のある) サーバプログラムなどが使用するポートへのアクセスが急増する場合があります。そこで現在使用しているシステムがどのポート番号で待ち受けをしているのかを把握しておくことで、JPCERT/CC の定点観測システムのようなポートごとのアクセス頻度の公開情報などを参考に対策を事前に施すことができる場合があります。

実際に待ち受けしているポート番号の詳細については、マニュアルを参照する、または netstat コマンドを使用することでご確認ください。

参考文書（日本語）

1. JPCERT/CC インターネット定点観測システム
2. http://www.jpcert.or.jp/isdas/

参考文書（英語）

1. PORT NUMBERS
2. http://www.iana.org/assignments/port-numbers

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Microsoft Windows のセキュリティ設定		インシデント発生前の予防	2005-08-31号

Microsoft Windows のセキュリティ設定として、使用していないポートをファイアウォールソフトウェアなどで塞ぐ設定をしていても、その後、様々なアプリケーションをインストールする際にインストーラがユーザの意思とは無関係にポートを開けてしまう場合があります。 そのため、セキュリティ設定は最初に一回行なうだけでなく、適宜、設定内容を確認することをお勧めします。

Topへ

ボット

タイトル	対象	目的別カテゴリ	掲載号
Microsoft Network Monitor 3.2 がリリース		インシデント発生前の予防	2008-09-25号

Microsoft より Network Monitor 3.2 がリリースされました。Network Monitor は通信を解析するためのパケットキャプチャツールです。同様のツールでは例えば tcpdump や Wireshark などが有名です。

Network Monitor 3.2 では Process Tracking という機能が追加されています。これにより PC 上でネットワークトラフィックを送信しているプロセスが一覧され、それぞれのプロセスがどのようなパケットを送信しているかを確認できます。

近年、ボットは管理サーバとの通信に HTTP を用いたり、暗号化したりと通信トラフィックを偽装する傾向にあります。既存のネットワークの監視だけでは PC のボット感染に気づくことが難しいため、個々の PC 上で Network Monitor 3.2 を使い、通信を行っているプロセスを確認することは有効です。

参考文書（英語）

1. Microsoft
2. Download details: Microsoft Network Monitor 3.2
3. http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&displaylang=en

Topへ

タイトル	対象	目的別カテゴリ	掲載号
英 BBC の情報番組がボットネットを特集		インシデント発生前の予防	2009-03-18号

英 BBC の "Click" という情報番組がボットネットに関する特集を行い話題になりました。

この番組ではスタッフが実際に数万台規模のボットネットを購入し、ボットネットから予め用意した実験用のメールアドレスにスパムを送信したり、DDoS 攻撃を行うデモンストレーションをしたりしました。番組ではボットネット管理者とのチャットの様子や、複数のボットを管理し命令を実行するための管理 GUI が紹介されています。最後にスタッフは購入したボットネットに対して自己消去の命令を出して番組は終了します。

アンダーグラウンドな世界で起こっている事象を正確に理解するためには、この番組のように実際の攻撃者と同じことをしてみることが有効です。しかし、アンチウイルスベンダの研究者からは、ユーザへの啓発を目的としているにしても、このような形でボットネットを利用することは、社会的に許されないことではないか、との問題提起がなされています。

セキュリティ研究者は「どこまで許されるのか?」を自問自答しながら今日も調査研究を続けています。

参考文書（英語）

1. BBC World News
2. Click - Buying a botnet
3. http://www.bbcworldnews.com/Pages/ProgrammeFeature.aspx?id=18&FeatureID=1075
4. SOPHOS: Graham Cluley’s blog
5. Did BBC break the law by using a botnet to send spam?
6. http://www.sophos.com/blogs/gc/g/2009/03/12/
   bbc-break-law-botnet-send-spam/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
rootkit と bot		インシデント発生前の予防	2006-02-08号

rootkit や bot などは、ユーザにほとんど気付かれることなくコンピュータに侵入/感染し、機密情報を盗んだり、データを改ざんしたり、更に第三者を攻撃したりします。最近では、このようなソフトウェアによる被害が拡大しており、注意が必要です。

このような被害を完全に防ぐ方法はありませんが、一般的に以下のような方法でリスクを軽減することができると考えられます。

1. - ウィルス検知ソフトのパターンファイルを最新に維持する
2. - ファイアウォールを導入/有効化する
3. - 「良い」パスワードを設定する
4. - 使用しているソフトウェアを最新版に更新する
5. - セキュリティ上「良い」とされる習慣に従う

参考文書（日本語）

1. JPCERT/CC REPORT 2006-02-01号 [今週の一口メモ]
2. ワクチンソフトを過信しない
3. http://www.jpcert.or.jp/wr/2006/wr060401.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST06-001
2. Understanding Hidden Threats: Rootkits and Botnets
3. http://www.us-cert.gov/cas/tips/ST06-001.html

Topへ

マルウェア

タイトル	対象	目的別カテゴリ	掲載号
USB メモリを経由して感染するマルウェア		インシデント発生前の予防	2008-01-30号

USB メモリを経由して感染するマルウェアが存在します。

感染した PC に USB メモリが接続されると、autorun.inf というファイルと共にマルウェアがコピーされます。こうしてマルウェアが保存された USB メモリを別の Windows PC に接続すると、autorun.inf による自動実行が有効になっている場合には、当該マルウェアが実行されてしまいます。

他人が管理する PC へ一度接続した USB メモリを自分の PC へ接続する場合、特に注意が必要です。また市販されている USB メモリに製造過程でマルウェアが混入した事例もあったことから、購入時にはウイルス検知ソフトでスキャンをかけることを心がけてください。

対策としては、Windows の自動実行 (autorun.inf) を無効にする方法があります。

参考文書（日本語）

1. Microsoft サポートオンライン
2. CD-ROM の自動実行機能を有効または無効にする方法
3. http://support.microsoft.com/kb/155217/ja
4. 独立行政法人 情報処理推進機構セキュリティセンター
5. コンピュータウイルス・不正アクセスの届出状況[6月分および上半期]について
6. http://www.ipa.go.jp/security/txt/2007/07outline.html

Topへ

無線LAN

タイトル	対象	目的別カテゴリ	掲載号
「公衆無線 LAN」を利用する場合の注意		インシデント発生前の予防	2005-06-29号

空港や駅などで利用可能な「公衆無線 LAN」サービスを使用する場合には、正規のアクセスポイントになりすましたアクセスポイントに接続してしまうことで通信を傍受される可能性があることに注意する必要があります。通信内容が傍受されてしまう危険性は、通常の無線 LAN や有線 LAN においても存在しますが、公衆無線 LAN の場合はその危険性がより高いと考えられます。

このような「なりすまし」アクセスポイントの使用を防ぐことは極めて困難であるため、誤って使用してしまった場合に備えて、通信経路を暗号化するなどの一層の注意が必要です。推奨される手法としては IPsec、SSH や HTTPS などの end-to-end (エンドシステム間) での暗号化手法が挙げられます。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
無線 LAN へのうっかり接続に注意		インシデント発生前の予防	2006-02-15号

パソコン (特に無線 LAN 機能を内蔵したもの) を使用している際に、無線LAN 機能を有効にしたままにしていたために意図しない接続を許してしまうことがあります。結果として、気付かないうちに、攻撃の標的にされたり、第三者に対する攻撃の踏み台にされたりしてしまう可能性があります。無線 LAN を使用しない場合は常に当該機能を無効にしておくことを強くお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
無線 LAN のセキュリティ		インシデント発生前の予防	2008-11-19号

WPA と WPA2 はそれぞれ暗号化と認証の機能を有しています。WPA 対応機器では TKIP (RC4) が使用可能であること、WPA2 対応機器では、より暗号強度の高い CCMP (AES) が使用可能であることとされています。

ただし、WPA2 対応機器であってもほとんどの場合、既存の機器との後方互換性のため、TKIP (RC4) にも対応しています。

例えば、WPA 対応機器と WPA2 対応機器が混在している場合、WPA2 対応機器を使用しているからといって、必ずしも CCMP (AES) を使っているとは限りません。WPA2 対応機器のみで構成されるネットワークでは CCMP (AES) のみを使う設定にする事を推奨します。

参考文書（日本語）

1. JPCERT/CC REPORT 2007-08-29
2. 【今週のひとくちメモ】無線 LAN のセキュリティ (WEP、WPA、WPA2)
3. http://www.jpcert.or.jp/wr/2007/wr073301.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
無線 LAN のセキュリティ (WEP、WPA、WPA2)		インシデント発生前の予防	2007-08-29号

無線 LAN のセキュリティ機能には、WEP、WPA、WPA2 などがあります。

WEP (Wired Equivalent Privacy) は、無線 LAN パケットを暗号化する機能ですが、暗号鍵が比較的簡単に解読される脆弱性が知られています。

Wi-Fi Alliance が策定した WPA (Wi-Fi Protected Access) では、IEEE 802.1X による認証と TKIP による定期的に暗号鍵を更新する機能が追加されており WEP の問題を解決しています。ただし、WPA-PSK モードには、事前共有鍵が辞書攻撃で解読されるという脆弱性が報告されています。

WPA2 は AES による暗号化が追加されており、より安全性は高くなっています。新しい機器では WPA2 の普及は進んでいますが、古い機器ではファームウェアの更新などでは対応できないという問題があります。

これらを踏まえて、無線 LAN を使用する際は、WEP の使用は避け、WPA または WPA2 を使用してください。

WPA を使用する場合は、なるべく IEEE 802.1X 認証を使用し、WPA-PSK を使用する場合は、乱数を使用した十分に長い事前共有鍵を設定することを強く推奨します。

参考文書（日本語）

1. 日本ネットワークインフォメーションセンター セキュリティ関連情報
2. ここまできた！　無線LANセキュリティー
3. http://www.nic.ad.jp/ja/materials/iw/2006/
   proceedings/T12.pdf
4. 総務省総合通信基盤局
5. 安心して無線LANを利用するために
6. http://www.soumu.go.jp/joho_tsusin/lan/index.html

Topへ

メール

タイトル	対象	目的別カテゴリ	掲載号
ORDB.org の DNSBL による広域メールブロックについて		インシデント発生時の対処	2008-04-02号

2008年3月25日頃から、ORDB.org 提供の DNSBL (DNS Block List) を参照する設定になっている MTA で広範囲の IP アドレスからのメール受信を拒否してしまう現象が起きています。

非営利組織 ORDB.org は 2006年12月18日を以って、活動を停止しています。メールサーバ管理者は ORDB.org 提供の DNSBL 参照を解除するように MTA の設定を更新することを推奨します。

参考文書（日本語）

1. JPCERT/CC からのお知らせ
2. ORDB.org の DNSBL による広域メールブロックについて
3. http://www.jpcert.or.jp/pr/2008/pr080002.txt

参考文書（英語）

1. Allan Willems Joergensen - OnDemand
2. ORDB.org is dead and gone
3. http://www.nowhere.dk/articles/ordb_org_is_dead_and_gone
   

Topへ

タイトル	対象	目的別カテゴリ	掲載号
電子メールクライアントの選択		セキュリティ関連の機関や団体、用語や技術に関する説明	2004-12-08号

電子メールを読み書きするためのソフトウェアやサービスである「電子メールクライアント」には様々な種類が存在します。例えば代表的なものとして以下のようなものがあります。

1. ソフトウェア
2. - Outlook/Outlook Express
3. - Becky!
4. - Winbiff
5. - Eudora
6. - Thunderbird
7. - Mew

1. Web メール
2. - Hotmail
3. - Yahoo! Mail

電子メールクライアントの選択にあたっては、自分が必要とするセキュリティレベルを提供できるかといった点に注意する必要があります。具体的には以下のような点があります。

1. - HTML 形式のメールの処理方法
2. - 添付ファイルの処理方法
3. - 暗号化機能
4. - 署名機能
5. - ヘッダの表示方法
6. など

特に HTML 形式の電子メールの処理に Web ブラウザを内部で用いている場合には、どのブラウザが使用されているのかにも注意する必要があります。

また Web メールのサービスの場合には、上記項目に加えて、そのサービスのプライバシーポリシーを確認する必要があります。具体的には以下のような点を確認してください。

1. - サービス提供者がユーザのどのような情報を収集しているか?
2. - 収集した情報にアクセスできるのは誰か?
3. など

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-023
2. Understanding Your Computer: Email Clients
3. http://www.us-cert.gov/cas/tips/ST04-023.html

参考文書（日本語）

1. JPCERT/CC REPORT 2004-11-25号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2004/wr044601.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
メールサーバの構成について		インシデント発生前の予防	2005-03-09号

メールを外部へ送信するためのメールサーバと外部からのメールを受信するメールサーバを物理的に分けることが推奨されます。これには、大量の (迷惑) メールを送りつけられるなどの攻撃に際しても送信だけは行なえるようにしておくなどの対策の意味があります。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
メールサーバの転送設定		インシデント発生前の予防	2005-03-16号

メールサーバにおいて、% を含んだ送信先アドレスの指定に従ってメールを転送する機能を無効に設定することが推奨されます。機能を無効にできない場合は、任意に利用されないような制限をかけることをご検討ください。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
電子メールの転送に関する注意事項		インシデント発生前の予防	2004-12-15号

1. 電子メールの転送機能を使う場合には以下の点に注意する必要があります。
2. - 多段に渡る転送設定をしている場合の転送の順番
3. - 転送先アドレスを (他人のものと) 間違えていないか?
4. - 転送先アドレスが無効 (スプール溢れを含む) になっていないか?

電子メールの転送に失敗し、誤って他人に送ってしまったり、配送エラーになってしまったりすることで情報が漏洩する危険性があります。

またメーリングリストに登録しているアドレスから他のアドレスに転送する設定にしている場合、実際に登録しているアドレスが分からなくなり、登録の削除やアドレスの変更ができなくなる場合もあります。どのメーリングリストにどのアドレスで登録しているか、整理しておくことをお勧めします。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
フリーメールサービス		インシデント発生前の予防	2005-05-11号

「フリーメールサービス」を使用するにあたって以下の点に注意することが推奨されます。

- 通信経路

ログイン名、パスワードおよびメールデータの通信が平文で行われると、第三者に中身を読み取られる可能性があります。可能な場合には SSL などを用いた暗号化通信を利用することを推奨します。

- プライバシー

サービスプロバイダによっては利用者に関する「情報」を売ることで収入を得ている場合があります。利用する前には必ずプロバイダの提供するプライバシポリシーや契約内容などを確認してください。

- 可用性

利用環境に対する制限に関して、自分が必要としているサービスが受けられることを確認してください。

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-009
2. Benefits and Risks of Free Email Services
3. http://www.us-cert.gov/cas/tips/ST05-009.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
個人契約のメールサービスを業務に使用しない		インシデント発生前の予防	2006-09-06号

個人で契約したメールサービスを業務上の機密情報の取り扱いに使用することは、情報管理の面で非常に大きなリスクがあります。情報管理責任者等から特別に許可を得ていない限りは、個人で契約したメールサービスを業務で使用しないことをお勧めします。

1. - 使用するサービスによっては、「情報」を第三者に提供する場合がある。
2. → 機密情報や個人情報の漏洩につながる可能性がある。
3. - 企業と契約関係にない第三者の管理するサーバ上で機密情報や個人情報を管理することになる。
4. → 情報漏洩の際、責任の所在が不明瞭になり、組織としての対応が遅れる可能性がある。

参考文書（日本語）

1. JPCERT/CC REPORT 2004-12-08号の「一口メモ」
2. 電子メールクライアントの選択
3. http://www.jpcert.or.jp/wr/2004/wr044801.txt
4. JPCERT/CC REPORT 2005-05-11号の「一口メモ」
5. フリーメールサービス
6. http://www.jpcert.or.jp/wr/2005/wr051801.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
メールの送信先に注意		インシデント発生前の予防	2008-11-27号

メールを送る際には、送信先に注意しましょう。例えば、ニュースを知らせるメールを受け取り他の関係者に転送する際、意図せず元のメールの送信元を一緒に含めてしまうケースがあります。JPCERT/CC REPORT においても、組織内関係者への転送と思われるものが返信されてくるケースが散見されます。

内容によっては、情報漏曳にもつながりかねない危険があります。メールを送信する直前にはもういちど送信先を確認するステップを入れること、また、メーラに誤送信を防ぐための機能がある場合には活用するなど、誤送信を防ぐための習慣をつけましょう。

参考文書（日本語）

1. Microsoft Office Outlook Tips
2. メール作成途中の送信を防ぐ方法
3. http://www.microsoft.com/japan/exchange/campaign/ov/
   tips/default.mspx#09
4. Thunderbird Add-ons
5. Confirm-Address 1.2.1
6. https://addons.mozilla.org/ja/thunderbird/addon/5582

Topへ

アカウント管理

タイトル	対象	目的別カテゴリ	掲載号
Microsoft Windows における制限付きユーザアカウント (標準ユーザアカウント) の使用		保守・管理について	2008-05-01号

Microsoft Windows では、制限付きユーザアカウントで使用することが推奨されます。アプリケーションがどの権限で動作しているかについては、タスクマネージャを使って確認することができます。

例えば、新規にアプリケーションをインストールするなど管理者権限を必要とする作業は以下のように行うことで、ログオフとログオンを繰り返すことなく実行可能です。

1. - 実行ファイルを右クリックして「別のユーザとして実行...」から
   管理者アカウントのパスワードを入力する
   (Windows Vistaでは「管理者として実行」)
2. - コマンドプロンプトを開き"runas"コマンドを使用する。

参考文書（日本語）

1. Microsoft セキュリティ At Home
2. 正しいユーザー アカウントの使用でコンピュータのセキュリティを強化する方法
3. http://www.microsoft.com/japan/protect/computer/
   advanced/useraccount.mspx
4. Microsoft TechNet
5. Runas
6. http://technet2.microsoft.com/WindowsServer/ja/library/
   0a688988-b5d1-494a-be98-61e3434c57151041.mspx?mfr=true
7. Microsoft TechNet
8. ユーザー アカウント制御の概要
9. http://www.microsoft.com/japan/technet/windowsvista/
   security/uacppr.mspx

Topへ

タイトル	対象	目的別カテゴリ	掲載号
Web アプリケーションのパスワード管理		インシデント発生前の予防	2007-09-20号

Web アプリケーションなどの脆弱性を悪用して、ユーザ ID やパスワードなどの認証情報を窃取しようとする攻撃が発生しています。

ユーザ認証を伴う Web アプリケーションのサービス提供者は、パスワードをそのまま保存せず、ハッシュ値のみで保存管理することを強く推奨します。

なんらかの事故や盗難などでユーザの認証情報が漏えいした場合、パスワードを平文で保存管理していると、そのまま認証情報を悪用される可能性があります。

一方、パスワードのハッシュ値で保存管理していれば、漏えいした情報からパスワードを推測することは困難であり、不正に入手した第三者がそのまま使用することはできません。

万一に備えて、上記対策を実施するとともに、認証情報は厳格に管理してください。

参考文書（日本語）

1. 独立行政法人 情報処理推進機構 セキュリティセンター
2. セキュア・プログラミング講座 パスワードの取扱い
3. http://www.ipa.go.jp/security/awareness/vendor/
   programming/b09_01.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
予め設定されているアカウントやパスワードに注意		インシデント発生前の予防	2007-02-21号

アプライアンス製品の中にはアカウントやパスワードが予め設定されているものがありますが、これらをそのままにしておくことは大変危険です。予め設定されているアカウントやパスワードは、製品のマニュアルに記載されているため、誰でも容易に知ることができます。

そこで、お使いの製品にアカウントやパスワードが予め設定されている場合には、製品使用開始前にそれらのアカウントを無効にする、もしくはパスワードを変更するなどの措置をとるよう強く推奨します。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
最小特権の原則		インシデント発生前の予防	2007-03-07号

場面に応じて必要最小限の権限だけを与えるようにする原則を「最小特権の原則」といいます。この原則を守ることで、実際にインシデントが発生した場合の被害を最小限に抑えることができます。

最小特権の原則を適用したシステム運用の例を以下に示します。

1. - 通常業務を遂行する際には一般ユーザアカウントを使用する
2. - 遠隔からの管理者アカウントによるログインは拒否する
3. - 管理作業を行うユーザのアカウントに対して、実行可能なコマンドを限定する

システムやネットワークを設計・運用する際に、ポリシーや実装などにて最小特権の原則が守られているかどうかを確認し、定期的に見直すことをお勧めします。

なお、最小特権の原則を遵守するため、OS によっては権限の昇格を一時的にする仕組みや役割ベースのアクセス制御が実装されていることがあります。Windows では Runas コマンド、Unix 系の OS では、sudo コマンドなどがよく知られています。

参考文書（日本語）

1. Microsoft TechNet Resources for IT Professionals
2. ユーザー アカウント制御の概要
3. http://www.microsoft.com/japan/technet/windowsvista/
   security/uacppr.mspx
4. Apple
5. Mac OS X のアクセス権に関する問題のトラブルシューティング
6. http://docs.info.apple.com/jarticle.html?artnum=106712
7. Solaris 10 System Administrator Collection - Japanese
8. 第 8 章 役割と特権の使用 (概要)
9. http://docs.sun.com/app/docs/doc/819-0383/6n2qieikj?a=view
10. Red Hat Enterprise Linux 4: セキュリティガイド
11. 4章. ワークステーションセキュリティ 4.4. 管理制御
12. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ja/security-guide/s1-wstation-privileges.html
13. Kevin Fenzi, & Dave Wreski, The Linux Japanese FAQ Project
14. Linux Security HOWTO 4. ローカルのセキュリティ
15. http://www.linux.or.jp/JF/JFdocs/Security-HOWTO-4.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ユーザアカウントの整理		インシデント発生前の予防	2005-02-23号

年度末を控え、ユーザアカウント管理ポリシーや実際の作業手順等を再確認することを強くお勧めします。その際、アカウントの廃止・発給などの管理作業が大量に発生することや担当者の異動なども考慮して、整理に際して不備がないよう確認することが重要です。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ユーザアカウントとメールアドレスの整理		インシデント発生前の予防	2006-04-19号

年度が改まって 3週間が経とうとしています。不要になったユーザアカウントやメールアドレスが残っていないか、改めて確認することを強くお勧めします。また、不要になったメールアドレスが whois データベースや自組織のウェブサイトを通して外部に公開されていないかどうか併せて確認し、必要に応じてそれらの情報を更新しましょう。 さらに、この機会に各ユーザおよび管理者のパスワードの一斉変更、アカウント管理ポリシーの見直しなども検討することをお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2004-04-21号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2004/wr041601.txt
3. JPCERT/CC REPORT 2006-03-29号 [今週の一口メモ]
4. http://www.jpcert.or.jp/wr/2006/wr061201.txt
5. JPCERT/CC REPORT 2006-04-05号 [今週の一口メモ]
6. http://www.jpcert.or.jp/wr/2006/wr061301.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ユーザアカウントとメールアドレスの整理		インシデント発生前の予防	2007-03-22号

まもなく年度が変わろうとしています。この時期には人事異動等の影響で、不要になるユーザアカウントやメールアドレスが多数発生することが予想されます。そこで、システム管理者の方は不要になるアカウントやアドレスを予めリスト化するなどの準備をしておき、できるだけ速やかに適切な措置を取ることを推奨します。

また、無効なメールアドレスが whois データベースや自組織のウェブサイトを通して外部に公開されていないかどうか併せて確認し、必要に応じてそれらの情報を更新しましょう。

さらに、この機会に各ユーザおよび管理者のパスワードの一斉変更、ネットワーク機器の設定変更、アカウント管理ポリシーの見直しなども検討することをお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2004-04-21号 [今週の一口メモ]
2. ユーザアカウントとパスワードの整理
3. http://www.jpcert.or.jp/wr/2004/wr041601.txt
4. JPCERT/CC REPORT 2006-03-29号 [今週の一口メモ]
5. whois データベースの更新
6. http://www.jpcert.or.jp/wr/2006/wr061201.txt
7. JPCERT/CC REPORT 2006-04-05号 [今週の一口メモ]
8. インシデント報告を受けつけるメールアドレス
9. http://www.jpcert.or.jp/wr/2006/wr061301.txt
10. JPCERT/CC REPORT 2006-04-19号 [今週の一口メモ]
11. ユーザアカウントとメールアドレスの整理
12. http://www.jpcert.or.jp/wr/2006/wr061501.txt
13. JPCERT/CC REPORT 2007-02-21号 [今週の一口メモ]
14. 予め設定されているアカウントやパスワードに注意
15. http://www.jpcert.or.jp/wr/2007/wr070701.html#Memo

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ユーザアカウントとメールアドレスの整理		インシデント発生前の予防	2008-03-19号

年度がまもなく終わろうとしています。システム管理者の方は、新年度の人事異動などに備えて、アカウントやメールアドレスをリスト化するなどの準備を行っておくことをおすすめします。同時にアカウントの権限についても、この機会に棚卸しを行い、不要な権限が付与されていないか確認しましょう。

また、無効なメールアドレスが whois データベースや自組織のウェブサイトで外部に公開されていないか確認し、必要に応じてそれらの情報を更新することをおすすめします。

参考文書（日本語）

1. JPCERT/CC REPORT 2007-03-22号 [今週の一口メモ]
2. ユーザアカウントとパスワードの整理
3. http://www.jpcert.or.jp/wr/2007/wr071101.html#Memo
4. JPCERT/CC REPORT 2006-03-29号 [今週の一口メモ]
5. whois データベースの更新
6. http://www.jpcert.or.jp/wr/2006/wr061201.txt

Topへ

タイトル	対象	目的別カテゴリ	掲載号
パスワードの決定		インシデント発生前の予防	2006-05-10号

パスワードを決める際には以下の点に注意することが推奨されます。

1. - アカウント名と同一または類似の文字列を使用しない。
2. - 電話番号や誕生日など、個人情報を基にした文字列は使用しない。
3. - 何らかの言語の何らかの辞書に載っている単語を使用しない。
4. - 複雑なパスワードを記憶する方法を考える。
5. - アルファベットの大文字・小文字および数字を混ぜる。
6. - 可能であれば特殊記号を混ぜる。
7. - 異なるシステムに対しては異なるパスワードを使用する。

参考文書（日本語）

1. RFC 2504
2. ユーザのセキュリティハンドブック 3.4. パスワード
3. http://www.ipa.go.jp/security/rfc/RFC2504JA.html#304
4. マイクロソフト 個人ユーザー向けセキュリティ
5. 強力なパスワード : その作り方と使い方
6. http://www.microsoft.com/japan/athome/security/
   privacy/password.mspx
7. JPCERT/CC REPORT 2004-11-04号 [今週の一口メモ]
8. http://www.jpcert.or.jp/wr/2004/wr044301.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-002
2. Choosing and Protecting Passwords
3. http://www.us-cert.gov/cas/tips/ST04-002.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
パスワードの取り扱いについて		インシデント発生前の予防	2006-05-17号

パスワードを取り扱う際には、以下のような点に注意することが推奨されます。

1. - 自分のパスワードを他人に教えない。
2. - パスワードを他人の目につく場所に残さない。
3. - パスワードを入力する対象が本来意図したもの (サイトなど) であることを確認する (サーバ証明書など)。
4. - パスワードを入力する際には、周囲から覗き込まれていないことを確認する。
5. - ネットワーク越しにパスワードを送信する際には、通信経路が暗号化されていることを確認する。
6. - コピー&ペーストを使ってパスワードを入力しない。
7. - パスワードを定期的に変更する。

参考文書（日本語）

1. RFC 2504
2. ユーザのセキュリティハンドブック 3.4. パスワード
3. http://www.ipa.go.jp/security/rfc/RFC2504JA.html#304
4. マイクロソフト 個人ユーザー向けセキュリティ
5. 強力なパスワード : その作り方と使い方
6. http://www.microsoft.com/japan/athome/security/
   privacy/password.mspx
7. JPCERT/CC REPORT 2004-11-04号 [今週の一口メモ]
8. http://www.jpcert.or.jp/wr/2004/wr044301.txt
9. JPCERT/CC REPORT 2006-05-10号 [今週の一口メモ]
10. http://www.jpcert.or.jp/wr/2006/wr061701.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-002
2. Choosing and Protecting Passwords
3. http://www.us-cert.gov/cas/tips/ST04-002.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
ユーザアカウントとパスワードの整理		インシデント発生前の予防	2004-04-21号

年度が改まって 3週間が経ちました。不要になったユーザアカウントが残っていないか、改めて確認することを強くお勧めします。またこの機会に各ユーザならびに管理者のパスワードを変更することをご検討ください。

Topへ

タイトル	対象	目的別カテゴリ	掲載号
パスワードの決定		インシデント発生前の予防	2004-11-04号

パスワードを決める際には以下のような点に注意することが推奨されます。

1. - 電話番号や誕生日など、個人情報を基にした文字列は使用しない。
2. - 何らかの言語の何らかの辞書に載っている単語を使用しない。
3. - 複雑なパスワードを記憶する方法を考える。
4. - アルファベットの大文字と小文字を混ぜる。
5. - アルファベット、数字、特殊記号を混ぜる。
6. - 異なるシステムに対しては異なるパスワードを使用する。

具体的には、意図的にスペルミスした単語 (文字列) を用いたり、記憶しやすい「文」を基に文字列を生成するなどの方法があります。例えば、

I like to play basketball.

という記憶しやすい文で、音や字形の近い文字に置き換えて、各単語の頭文字などを取り出すと共に、大文字と小文字を混ぜることで、Il!2pBb. という文字列を生成するといったような方法があります。

I like to play basketball.

1. ==> I l!ke 2 play Basket ball .
2. ==> I l! 2 p B b .
3. ==> Il!2pBb.

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-002
2. Choosing and Protecting Passwords
3. http://www.us-cert.gov/cas/tips/ST04-002.html

Topへ

リムーバブルメディア

タイトル	対象	目的別カテゴリ	掲載号
リムーバブルメディアの自動実行機能を無効にする		インシデント発生前の予防	2007-02-28号

PC にリムーバブルメディアを挿入・接続したときに、メディア内のファイルを自動実行する機能が働くことがあります。この機能は、意図に反してファイルを実行する可能性につながるため、特に必要がない限り無効に設定することを推奨します。また、何らかの理由でリムーバブルメディア自動実行機能を無効にできない場合は、PC に不審なメディアを挿入・接続しないよう推奨します。

なお、リムーバブルメディアの自動実行機能を使用して拡散するワームの存在が、過去に複数確認されています。

参考文書（日本語）

1. マイクロソフト サポートオンライン
2. CD-ROM の自動実行機能を有効または無効にする方法
3. http://support.microsoft.com/kb/155217/ja
4. Windows XP エキスパートゾーン
5. プログラム CD の自動再生をオフにする
6. http://www.microsoft.com/japan/windowsxp/expertzone/
   tips/february/knox1.mspx
7. トレンドマイクロ ウイルスデータべース
8. WORM_QQPASS.ADH
9. http://www.trendmicro.co.jp/vinfo/virusencyclo/default5.asp?VName=WORM_QQPASS.ADH&VSect=T
10. Symantec Security Response
11. W32.Falgna
12. http://www.symantec.co.jp/region/jp/avcenter/venc/data/jp-w32.falgna.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
リムーバブルメディアの適切な運用方法を決める		保守・管理について	2006-11-08号

SB メモリや外付け HDD など、手軽に使える大容量なリムーバブルメディアが普及しています。これらのメディアを業務などで扱う場合には、情報管理担当者の管理下において、用途別に使用する機器を分け、それぞれに適切な運用方法を設けることを推奨します。

一例として、下記のような用途と運用方法が考えられます。

1. - データ一時保存 (運搬) 用
2. → データの運搬に必要な時以外は、基本的にファイルを保存せず、定期的に専用ソフトウエアなどを用いデータの完全消去を行う。社外に持ち出す場合はデータを暗号化する。
3. - データ長期保存用
4. → 保存するデータは暗号化し、メディアは安全な場所に保管する。

その他にも、使用状況を記録する、機器ごとに管理者を決めるなどの運用により、盗難・紛失による情報漏洩の予防につながると考えられます。

なお、リムーバブルメディアの使用については、組織内の情報管理ポリシーをご確認ください。

Topへ

ログの収集

タイトル	対象	目的別カテゴリ	掲載号
記録情報 (ログ) を増やしてインシデント調査に活用する		保守・管理について	2006-08-09号

ワームの感染活動や弱点探索などの不審なアクセスが断続的に、または継続して発生している場合、関係するサーバプログラムの記録情報 (ログ) を、デバッグモードに切り換えるなどの方法で一時的に増やすことで、インシデントの詳細が把握できる場合があります。

ただし、この方法はシステム負荷の上昇を招くため、不審なアクセスによってシステムの負荷が上昇している場合は、サービスを提供できなくなるなどの不都合が生じる恐れもあります。上記の方法をとる場合はシステムの負荷を考慮して、慎重に検討する必要があります。

使用しているサーバプログラムの記録情報 (ログ) の設定方法や変更時の影響などについては、OS やサーバプログラムのマニュアルなどを参考に予め把握しておくことをお勧めします。

Topへ

機関/組織

タイトル	対象	目的別カテゴリ	掲載号
JVN (JP Vendor Status Notes)		セキュリティ関連の機関や団体、用語や技術に関する説明	2004-10-06号

JVN とは、経済産業省告示「ソフトウェア等脆弱性関連情報取扱基準」を受けて、日本国内の製品開発者の脆弱性対応状況を公開するサイトです。JVN は、JPCERT/CC と独立行政法人 情報処理推進機構 (IPA) により、本年 7月から共同で運営されています。

IPA に報告された脆弱性情報のうち、2004年10月5日 (日本時間) 現在、3件が国内外のベンダなどとの調整の後に公開され、JVN に掲載されています。

参考文書（日本語）

1. JPCERT/CC
2. 脆弱性情報コーディネーション概要
3. http://www.jpcert.or.jp/vh/
4. 経済産業省
5. 「情報セキュリティ早期警戒パートナーシップ」の運用開始について
6. http://www.meti.go.jp/policy/it_policy/press/0005399/

Topへ

タイトル	対象	目的別カテゴリ	掲載号
JPCERT/CC レポートで紹介しているセキュリティ関連情報について		セキュリティ関連の機関や団体、用語や技術に関する説明	2004-10-14号

基本的に以下のような基準を目安にして選定しています。

1. - JVN (JP Vendor Status Notes) のうち「重要」と JPCERT/CC が判断したもの
2. - US-CERT Technical Cyber Security Alert
3. - US-CERT Vulnerability Notes のうち「重要」と JPCERT/CC が判断したもの
4. - CIAC Information Bulletin のうち、Vulnerability Assessment が MEDIUM 以上のもの
5. - CIAC Technical Bulletin
6. - JPCERT/CC が主催するセキュリティ関連イベントの情報
7. - その他関連組織が公開した情報 (TIPS などを含む)

ただし、これらはあくまで目安であり、実際にはその都度掲載の有無を検討しています。

参考文書（日本語）

1. JP Vendor Status Notes - JP
2. http://jvn.jp/jp/

参考文書（英語）

1. Technical Cyber Security Alerts
2. http://www.us-cert.gov/cas/techalerts/
3. US-CERT Vulnerability Notes
4. http://www.kb.cert.org/vuls/
5. CIAC Bulletins
6. http://www.ciac.org/cgi-bin/index/bulletins

Topへ

タイトル	対象	目的別カテゴリ	掲載号
US-CERT から公開される脆弱性情報について		セキュリティ関連の機関や団体、用語や技術に関する説明	2004-10-20号

US-CERT から公開される Vulnerability Notes には、個々の情報に Metric と呼ばれる数字が記載されています。この数字は、脆弱性の深刻度を大まかに示す数値として 0 から 180 の間で設定され、以下のような要件で決められています。

1. - その脆弱性の一般への影響度または認知度
2. - その脆弱性を使ったインシデントの US-CERT への報告の有無
3. - その脆弱性の、インターネットのインフラにおける脅威の有無
4. - その脆弱性の脅威にさらされる、インターネット上のシステムの概数
5. - その脆弱性を悪用することによる影響内容
6. - その脆弱性を悪用することの難易度
7. - その脆弱性を悪用するのに必要な環境/条件

このようにして決められた Metric が 40 を超えた場合、US-CERT は、その脆弱性情報を US-CERT Technical Alerts の候補にします。ただし、数値そのものが深刻度を示すとは限らないことに注意してください。例えば、Metric 40 の情報が Metric 20 の情報に比べて 2倍深刻であるとは限らない、ということです。

参考文書（英語）

1. US-CERT Vulnerability Notes
2. http://www.kb.cert.org/vuls/
3. US-CERT Vulnerability Notes Field Descriptions
4. http://www.kb.cert.org/vuls/html/fieldhelp#metric

Topへ

タイトル	対象	目的別カテゴリ	掲載号
米国 CERT Coordination Center (CERT/CC) と「CERT」について		セキュリティ関連の機関や団体、用語や技術に関する説明	2004-10-27号

1988年11月の Morris ワーム事件をきっかけに米国カーネギーメロン大学の Software Engineering Institute (SEI) に作られた CERT CoordinationCenter (CERT/CC) は世界で最初の CSIRT (Computer Security IncidentResponse Team) です。

CSIRT をあらわす一般名詞として、しばしば CERT (Computer EmergencyReponse Team) という単語が用いられることがありますが、現在、CERT/CC の「CERT」という文字列は CERT/CC の登録商標であり、また何かの頭文字を取った単語ではありません。

なお、JPCERT/CC の「CERT」は Computer Emergency Response Team の頭文字を取ったものであり、米国政府系 CSIRT である US-CERT の「CERT」は Computer Emergency Readiness Team の頭文字を取ったものです。

参考文書（英語）

1. The CERT Coordination Center FAQ
2. http://www.cert.org/faq/cert_faq.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
FIRST (Forum of Incident Response and Security Teams) とは		セキュリティ関連の機関や団体、用語や技術に関する説明	2008-03-12号

FIRST は世界中の CSIRT (Computer Security Incident Response Team) が相互の情報交換やインシデント対応に関する協力関係を構築する目的で 1990年に米国 CERT/CC などが中心となって設立されたフォーラムです。世界各地から合計 190 を超えるチームが参加しています。

日本からは JPCERT/CC が 1998年の 8月に参加し、現在までに 10 を超えるチームが正式メンバーになっています。

FIRST には、大学内に設置され学生や職員向けにサービスを提供する CSIRT、政府組織内の CSIRT、自社製品のセキュリティ関連情報の分析と公開を行なっている CSIRT など多様な形態のチームが集まっています。

FIRST では年に数回、メンバのみの会合 (TC, Technical Colloquium) を開催するとともに、毎年 6月に年次会合を開催しており、最新のセキュリティ関連技術についてのチュートリアルや講演が多数行われます。

また、この年次会合は FIRST のメンバー以外も参加できるオープンな国際会議になっており、既存の FIRST 参加メンバーが親睦を深める場であるとともに、新たなチーム同士の連携を促す場ともなっています。

2008年の年次会合は 6/22(日) から、カナダのバンクーバーで開催される予定です。

参考文書（英語）

1. FIRST (Forum of Incident Response and Security Teams)
2. http://www.first.org/
3. Computer Security Incident Response Team (CSIRT)
4. Frequently Asked Questions (FAQ)
5. http://www.cert.org/csirts/csirt_faq.html
6. About the Conference: Who, Why, Where
7. http://www.first.org/conference/2008/about.html
8. FIRST Events Calendar
9. http://www.first.org/events/calendar.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
FIRST (Forum of Incident Response and Security Teams) とは?		セキュリティ関連の機関や団体、用語や技術に関する説明	2005-09-22号

FIRST は世界中の CSIRT (Computer Security Incident Response Team) 同士の情報交換やインシデントレスポンス業務の協力関係を構築する目的で 1990年に米国 CERT/CC などが中心となって設立されたフォーラムです。

1. FIRST (Forum of Incident Response and Security Teams)
2. http://www.first.org/
3. 設立当初は 10数チームであった参加チームも現在は 170を超えています。JPCERT/CC は日本で初めて 1998年の 8月に正式メンバーとなりました。現在、日本からは既にいくつかのチームが正式メンバーになっています。
4. FIRST Member Teams
5. http://www.first.org/about/organization/teams/
6. なお、FIRST の正式メンバーになるためには既存メンバーによる推薦が必要です。参加チームは JPCERT/CC のような地域に根ざした CSIRT ばかりではなく、企業や大学、軍などの自組織向けにサービスを提供する CSIRT や自社製品のセキュリティ関連情報の分析、公開などを行なっている CSIRT など多岐に渡っています。
7. Computer Security Incident Response Team (CSIRT)
8. Frequently Asked Questions (FAQ)
9. http://www.cert.org/csirts/csirt_faq.html
10. 現在 JPCERT/CC は、Web サーバのレプリカの運用や、運営委員会メンバーへの職員の輩出などを通して、FIRST の活動に積極的に協力しています。
11. FIRST Steering Committee
12. Frequently Asked Questions (FAQ)
13. http://www.first.org/about/organization/sc.html
14. FIRST は年に 1回、6月に Annual Computer Security Incident Handling Conference を開催しています。これは FIRST 参加メンバーの親睦を深めたり、インシデント関連情報を交換することなどを目的に開かれていますが、その他にも最新のセキュリティ関連技術についてのチュートリアルがあるなど、FIRST のメンバー以外も参加することができるオープンな国際会議です。今年は 6/26(日) から 7/1(金) に、シンガポールで開催されました。来年は 6/25(日) から 6/30(金) に米国ボルチモアで開催される予定です。
15. FIRST Events Calendar
16. http://www.first.org/events/calendar.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
「CERT」と「CSIRT」について		セキュリティ関連の機関や団体、用語や技術に関する説明	2006-09-27号

コンピュータセキュリティインシデントに対応する活動を行う組織名称に、しばしば「CERT」という語を用いることがあります。

JPCERT/CC の「CERT」は Computer Emergency Response Team (response: 対応) の頭文字ですが、米国 US-CERT の「CERT」は Computer Emergency Readiness Team (readiness: 準備) の頭文字です。また、CERT/CC の「CERT」は、何かの頭文字ではないとされています。このように「CERT」という語は組織によってその意味が異なります。

このような組織を呼称する際の一般名詞としては、「CSIRT」(「シーエスアイアールティー」もしくは「シーサート」と読みます) という語を用いるのが一般的です。

参考文書（日本語）

1. JPCERT/CC に関してよくある質問と答え
2. 1. 組織概要
3. http://www.jpcert.or.jp/faq.html#q01
4. JPCERT/CC REPORT 2004-10-27 [今週の一口メモ]
5. 米国 CERT Coordination Center (CERT/CC) と「CERT」について
6. http://www.jpcert.or.jp/wr/2004/wr044201.txt

参考文書（英語）

1. CERT/CC
2. The CERT Coordination Center FAQ
3. http://www.cert.org/faq/cert_faq.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
CSIRT の役割について		セキュリティ関連の機関や団体、用語や技術に関する説明	2006-10-04号

一般的に CSIRT (Computer Security Incident Responce Team) に求められる役割には、以下のようなものがあります。

1. - インシデントの報告を受け取り、調査をし、対応する
2. - コンピュータセキュリティインシデントに関する技術的・社会的な情報を収集・伝達して、インシデントの発生を未然に防ぐ
3. - ソフトウェアの脆弱性に関する情報を収集・伝達して、インシデントの発生を未然に防ぐ
4. - カンファレンスやワークショップへの参加・聴講によって得られた知識・技術を伝達して、constituency の啓発を行う

ただし、実際には constituency (サービス対象) によって CSIRT に求められる役割は異なります。

参考文書（日本語）

1. JPNIC・JPCERT/CC Security Seminar 2005 講演資料
2. インシデントレスポンス概論 3. CSIRT
3. http://www.jpcert.or.jp/present/2005/
   IncidentResponseOverview2005.pdf

Topへ

タイトル	対象	目的別カテゴリ	掲載号
CSIRT の種類について		セキュリティ関連の機関や団体、用語や技術に関する説明	2006-10-12号

CSIRT (Computer Security Incident Response Team) は、constituency (サービス対象) に対する役割によって分類することができます。以下に役割による CSIRT の分類の一例を挙げます。

- Internal CSIRT: 自組織や顧客が関わるインシデントに対応する CSIRT

- National CSIRT: 国や地域全体が関わるインシデントに対応する CSIRT

- Incident Response Provider: 契約に応じて外部組織のインシデントの対応を代行する CSIRT (いわゆる「セキュリティベンダ」)

- Coordination Center: 報告されたインシデントに対応できる CSIRT や連絡先を探し、インシデント対応の調整を図る CSIRT

- Analysis Center: インシデントの脅威や脆弱性を調査、分析する CSIRT

- Vendor Team: 自社製品の脆弱性に対応する CSIRT

インシデントの対応などで CSIRT に連絡する際は、事前にその CSIRTが掲げている役割を調べて適切な連絡先かどうかを確認するようお勧めします。

参考文書（日本語）

1. JPNIC・JPCERT/CC Security Seminar 2005 講演資料
2. インシデントレスポンス概論
3. http://www.jpcert.or.jp/present/2005/
   IncidentResponseOverview2005.pdf

参考文書（英語）

1. CERT/CC
2. CSIRT Documents
3. http://www.cert.org/csirts/national/documents.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
CSIRT の活動内容の制限について		セキュリティ関連の機関や団体、用語や技術に関する説明	2006-10-18号

CSIRT (Computer Security Incident Response Team) は、constituency (サービス対象) に対する役割によって分類することができます。以下に役割による CSIRT の分類の一例を挙げます。

たとえば、JPCERT/CC の活動目的はインシデントの予防、再発防止および影響範囲の拡大防止の観点からシステム運用管理の技術的な支援を行なうことであり、法的な拘束力の行使ではありません。そのため、行為者の特定や懲罰、被害者の救済等の活動は行っておらず、また、要求された場合でも対応できないことがあります。

インシデント対応の一環として、インシデント当事者に関係する CSIRT に連絡を行う際には、事前に連絡先 CSIRT の活動内容や制限を把握しておくことをお勧めします。

参考文書（日本語）

1. JPNIC・JPCERT/CC Security Seminar 2005 講演資料
2. インシデントレスポンス概論
3. http://www.jpcert.or.jp/present/2005/
   IncidentResponseOverview2005.pdf
4. JPCERT/CC REPORT 2006-10-12号 [今週の一口メモ]
5. CSIRT の種類について
6. http://www.jpcert.or.jp/wr/2006/wr063901.txt

参考文書（英語）

1. CERT/CC
2. CSIRT Documents
3. http://www.cert.org/csirts/national/documents.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
National CSIRT の連絡網を活用する		セキュリティ関連の機関や団体、用語や技術に関する説明	2006-10-25号

インシデント対応の調整を National CSIRT に依頼することで、インシデントの当事者との連絡が可能となる場合があります。

インシデント対応の過程で、インシデントの当事者に連絡する必要がありながら、当事者の連絡先が不明であったり、連絡内容や要望を適切に伝達できなかったり、連絡しても応答が無い場合などがあります。特にインシデントの当事者が国外に存在する場合は、そのような状況に遭遇する可能性が高くなります。また、各国、各地域における法的な制限をはじめとした事情を把握していないと、不適切な、または実行できない対応を要望してしまい、結果として効果的なインシデント対応につながらない可能性があります。

インターネットが普及している国では、それぞれの地域を代表する National CSIRT が存在することが多く、特に FIRST やAPCERT に加盟している National CSIRT は、その地域の事情に詳しく、かつ適切な連絡先を把握していることが期待できます。JPCERT/CC も FIRST および APCERT に加盟しています。

参考文書（日本語）

1. JPNIC・JPCERT/CC Security Seminar 2005 講演資料
2. インシデントレスポンス概論
3. http://www.jpcert.or.jp/present/2005/IncidentResponseOverview2005.pdf
4. JPCERT/CC REPORT 2006-10-18号 [今週の一口メモ]
5. CSIRT の活動内容の制限について
6. http://www.jpcert.or.jp/wr/2006/wr064002.txt

参考文書（英語）

1. FIRST (Forum of Incident Reponse and Security Teams)
2. Alphabetical list of FIRST Members
3. http://www.first.org/members/teams/
4. APCERT (Asia Pacific Computer Emergency Response Team)
5. Member Teams
6. http://www.apcert.org/about/structure/members.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
National Cyber Security Awareness Month		セキュリティ関連の機関や団体、用語や技術に関する説明	2007-10-11号

米国では、毎年 10月を "National Cyber Security Awareness Month" として、インターネットの安全性を高めるための啓発活動を展開しています。この活動には、米国国土安全省、NCSA (National Cyber Security Alliance)、Multi-State ISAC、各種非営利団体、IT 系企業などが参加しており、 様々なユーザ層に向けた活動が行われています。

今年は 10月1日の NCSA Summit を皮切りに全米各地の大学で関連した啓発イベントなどが開催されています。

参考文書（英語）

1. SANS Internet Storm Center
2. Cyber Security Awareness Month - Daily Topics
3. http://isc.sans.org/diary.html?storyid=3429

Topへ

タイトル	対象	目的別カテゴリ	掲載号
CSIRT 間のネットワークを活用する		セキュリティ関連の機関や団体、用語や技術に関する説明	2005-11-24号

インシデントが発生し、そのインシデントに何らかのかかわりがある (アクセス元であるなどの) 可能性のある海外の組織への連絡を必要とする場合があります。しかしながら、その連絡先が分からないために連絡できず、結果としてインシデントの原因究明やインシデントからの復旧に時間がかかってしまう場合がしばしばあります。

このような場合は、JPCERT/CC などの国や地域を代表する CSIRT (Computer Security Incident Response Team) が適切な連絡先の情報を持っていることがあるので、活用することをお勧めします。

参考文書（日本語）

1. 技術メモ - 関係サイトとの情報交換
2. http://www.jpcert.or.jp/ed/2002/ed020001.txt

参考文書（英語）

1. FIRST (Forum of Incident Response and Security Teams)
2. Member Teams
3. http://www.first.org/about/organization/teams/
4. Asia Pacific Computer Emergency Response Team
5. http://www.apcert.org/
6. Computer Security Incident Response Team (CSIRT)
7. Frequently Asked Questions (FAQ)
8. 4. What types of CSIRTs exist? (参照: National CSIRTs)
9. http://www.first.org/about/organization/teams/

Topへ

検疫ネットワーク

タイトル	対象	目的別カテゴリ	掲載号
検疫ネットワーク		インシデント発生前の予防	2006-03-01号

ノート PC などの外部から持ち込んだパソコンを社内 LAN に接続する際に、まずその持ち込んだパソコンがウィルスやワームなどに感染していないか検査するための隔離された専用ネットワーク、いわゆる「検疫ネットワーク」に強制的に接続するようにシステムを構築することを強くお勧めします。

一般的に、この「検疫ネットワーク」は、社内 LAN から隔離されたネットワークで、ウィルスやワームなどへの感染の有無を確認するだけでなく、OS のパッチが適用されているか、ウィルス検知ソフトのパターンファイルが最新の状態になっているかなどの検査を行ない、検査を全てパスした場合にのみ社内 LAN への接続を許可するように設定します。

Topへ

個人情報

タイトル	対象	目的別カテゴリ	掲載号
自分の個人情報が盗用されたことに気付いたら		インシデント発生時の対処	2006-01-18号

盗用に気付いた場合、盗用が確認された口座やアカウントを閉じるだけでは充分ではないことに注意してください。

盗用されたことが確認された以外の口座やアカウントについても、盗用されていないか速やかに確認し、盗用されていない場合でも暗証番号やパスワードを変更することを強くお勧めします。

参考文書（日本語）

1. JPCERT/CC REPORT 2006-01-12号 [今週の一口メモ]
2. http://www.jpcert.or.jp/wr/2006/wr060101.txt

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-019
2. Preventing and Responding to Identity Theft
3. http://www.us-cert.gov/cas/tips/ST05-019.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
個人情報のダミーデータを利用する		インシデント発生前の予防	2009-01-15号

個人情報を扱うアプリケーションの開発時にはテストデータの取扱いに注意する必要があります。実際の個人情報をテストに使用して開発委託先などから情報が漏洩するケースが発生しています。

このような危険を防ぎ、安全に開発をすすめるためにダミーデータを活用する方法があります。現実のデータに近いダミーデータを作成するサービスやアプリケーションが利用可能です。

参考文書（日本語）

1. 窓の杜
2. 【NEWS】プログラムの動作テスト用のダミーデータを簡単に大量作成「プラデータ」
3. http://www.forest.impress.co.jp/article/2008/04/22/
   pladata.html
4. People to People Communications 株式会社
5. 疑似個人情報をテスト用データとして使
6. http://www.start-ppd.jp/howto1.html

参考文書（英語）

1. CPAN
2. Data::Faker - Perl extension for generating fake data
3. http://search.cpan.org/~jasonk/Data-Faker-0.07/lib/Data/Faker.pm

Topへ

タイトル	対象	目的別カテゴリ	掲載号
プライバシー保護のために		インシデント発生前の予防	2004-07-22号

個人名や電子メールアドレスなどの個人情報を Web サイトの入力フォームなどを通じてネットワーク上に流す場合には、最低限以下の項目に注意する必要があります。

- 情報がどのように扱われるのか、情報を受け取る側が提供しているプライバシーポリシーなどを事前に読んで確認しておく。

- 通信経路が暗号化されているかどうかを確認する。Web (の入力フォーム) の場合は URL が http:// ではなく、https:// であることを確認する。

- 情報を受け取る側が、本当にユーザの想定しているサイトであるかどうかを確認する。例えば相手のドメイン名が想定しているものであることを確認する、https:// で提供されている Web サイトの場合は証明書の内容を確認する、など。

更に以下の項目にも注意することが推奨されます。

- 情報を受け取る側が信頼できる企業、団体かどうかを世の中の評価、評判などから確認、判断する。

- 電子メールアドレスを登録する場合は、SPAM メールの送付先に使われる可能性があるので、オンライン登録用のアドレスを別に用意する。

- クレジットカード番号を入力する場合は、オンライン専用のクレジットカードを別途用意し、利用可能金額を最低限の額に制限しておく。

参考文書（英語）

1. US-CERT Cyber Security Tip ST04-013
2. Protecting Your Privacy
3. http://www.us-cert.gov/cas/tips/ST04-013.html

Topへ

タイトル	対象	目的別カテゴリ	掲載号
個人情報の盗用に気付くためには		インシデント発生前の予防	2006-01-12号

個人情報の盗難を正確に把握できるのは、個人情報 (のデータベース) を管理している企業、組織ですが、ユーザ側でも以下の点に注意することで自分の個人情報が盗用されていることが分かる場合があります。

1. - カードの利用明細に通常と異なる、または予期しない請求がある
2. - 使用していない通話に対する電話料金の請求がある
3. - 普段使用している電子メールの受信に失敗する (パスワード漏洩の可能性)
4. - カードなどの利用が拒否される
5. - オンラインバンキングのログイン履歴に記憶にないものがある

盗用に気付いた場合は、速やかに該当する個人情報を管理している企業、組織に連絡するなどの対応を行なう必要があります。また、普段から連絡先を手帳に控えておくなど、常に連絡が可能な状態にしておくことを強くお勧めします。

参考文書（英語）

1. US-CERT Cyber Security Tip ST05-019
2. Preventing and Responding to Identity Theft
3. http://www.us-cert.gov/cas/tips/ST05-019.html

Topへ

盗聴

タイトル	対象	目的別カテゴリ	掲載号
盗聴プログラムに注意		インシデント発生前の予防	2005-12-07号

銀行の (正規の) サイトとの間でやり取りされるユーザ名やパスワード、更にスクリーンショットなどが盗まれるインシデントが発生しています。これは、不審な Web サイトにアクセスしてしまったことで、気付かないうちに盗聴プログラムが PC にインストールされてしまったことが原因との報告があります。 これらの盗聴プログラムはウィルス検知ソフトウェアでも検知されない場合が多いため注意が必要です。具体的には、むやみにリンクをたどらない、むやみにファイルをダウンロードしない、Web ブラウザを常に最新の状態に保つ、JavaScript などのスクリプトを必要最低限のサイトを閲覧する以外には無効にしておく、などの対処法があります。

Topへ