(1) メールマガジン

(2) WEBサイト

(3) 提携サイト、マガジン

編集部は民間企業の一部門であり、利益を実現することが重要な活動目的のひとつとなっています。編集部の利益の中心は、読者からの購読料（法人ライセンス含む）、関連する資料販売および企業からの協賛・広告収入です。
これらの利益のうち、編集部では、読者からの購読料および関連資料販売をもっとも重要なものと位置付けています。
そのため、提供する情報の内容は、読者にとって価値があると編集部が判断したものを収集、整理したものになります。
読者にとって価値があるものであるが、協賛・広告主の方にはネガティブな要素をもつ情報についても、読者への価値を優先し、掲載いたします。

つまり、編集部は、SCANサービスの読者に対して忠実であり、それ以外の人々および存在（社会正義、国家安全含む）に対してはプライオリティを下げた運営を行なっていることを意味します。

編集部が公開する情報の当事者および関係者の方々、あるいは扱われる情報の種類や内容の傾向をあらかじめ承知しておきたい読者の方々にとって、有益であると考えます。

編集部に情報提供を行ないたい外部の方にとっても、当該情報を編集部に提供した後、どのように扱われるかを情報公開原則によって、あらかじめ確認することができます。

不幸にして、みずからセキュリティホールあるいはインシデントを発生させてしまった方にとっては、その情報がどのような基準で公開されてゆくかを知ることができます。

OS、アプリケーション、ネットワークプロトコルなどのセキュリティ上の問題に関する情報です。

カスタムアプリケーション、サーバアプリケーションの設定上の問題、情報漏洩、WEB改竄、ウイルス配布などとおよびそれらにつながる可能性のある設定ミスに関する情報を指します。設定ミスが主として人為的なものによると判断されたものは、編集部ではインシデントとして扱われます。
この区分は、発生したインシデントおよびインシデント予防、対策、事後対応のための情報提供を行なっているサービス＝"Scan Incident Report"の取り扱う範囲との兼合いで線引きされています。

例えば、悪用可能性の低いクロスサイトスクリプティング、メールサーバの不正中継、技術的に可能であるが検証が困難なセキュリティホールなどです。
いずれの問題もセキュリティホールでもインシデントでもないと主張するサービス提供者の方は少なからず存在します。編集部では、なんらかの悪用可能性が存在したり、本来意図しない状態が存在する場合は、セキュリティホールあるいはインシデントとして取り扱います。

ホストのアプリケーション名やバージョンに関する統計など独自のデータベースおよび調査結果を編集部では保有しています。
収集した情報は一般的に公開されているものであり、インターネットからアクセス可能になっているサービスを利用して収集したものに限ります。
編集部では、データの公開が読者にとって価値があると判断した場合、無償あるいは有償で公開します。
インターネットというパブリック（誰でも自由にアクセスできるという意味）なネットワーク上にホストを公開することは、ホストに関する情報も自ら公開していることになります。したがいまして、一般的な方法で入手可能なホストに関するさまざまな情報の公開に関して編集部では制限を設けておりません。ホストに関する情報をインターネットから見えないようにする方法はあり、その方法がとられていないことは、公開を制限する意図がないものと判断しています。

主としてサービス運用に供されるサーバアプリケーション（カスタムアプリケーション含む）あるいはOS （以下、総称してソフトウェアプロダクトあるいはシステム）などに関するセキュリティ情報の公開を一定の条件下において行なっています。一定の条件とは、主として利用者が多く、直接・間接に社会的影響の大きいもので、公開することで多数の読者の利益となると編集部が判断した場合です。

当該ソフトウェアプロダクトあるいはシステムの開発者、提供者（以下、ベンダ）による公表だけでなく、第三者からの情報公開や情報提供も含んで情報公開を行なっています。当該ソフトウェアプロダクトあるいはシステムの開発者、提供者（以下、ベンダ）による公表だけによらない情報を公開している理由は下記です。

ベンダが問題あるいは影響範囲について、正しく認識できない場合があります。その場合、ベンダが公開した内容だけでは、管理者がその問題と影響度を正しく認識できない危険性があります。

ベンダは、じゅうぶんな対策（パッチ、バージョンアップなど）が準備できない限り、情報公開を行なわないことが少なくありません。しかし、その一方では、ベンダによる情報公開以前に問題の存在が広く知れ渡ってしまうことがあります。ベンダが対処方法を確立できていなくても、なんらかの対処方法がある場合は、情報公開を行なうことで管理者が危険に対処することが可能となります。例えば、当該アプリケーションやサービスの利用をとめることもそのひとつです。
既知のセキュリティホールでありながら、ベンダから正式な発表のないものも確かに存在します。

理由は不明ですが、ベンダが情報公開を行なわない場合があります。危険が存在する以上、管理者は知る必要があります。誰も知らなければ、危険は存在しないわけですが、今日、誰も発見しない可能性は低いと考えた方がよいでしょう。
既知のセキュリティホールでありながら、ベンダから正式な発表のないものも確かに存在します。

特定のソフトウェアプロダクトあるいはシステムに関するセキュリティホールは、下記の基準で情報公開を行います。

情報入手時に公開する （ベンダ、セキュリティベンダ、各国CERT、BUGTRAQ 等）

当該ベンダへの連絡および確認、複数の情報ソースによる確認、社内での検証など、当該情報以外の複数の方法で確認がとれた場合、
ベンダにおける対処が確認された場合（あるいは逆に、一週間以内にベンダが対処を実施する可能性が低いことが確認された場合）、公開を行う。

2ch でIE のセキュリティホールをつく「fusianasanトラップ」が蔓延 (2001.12.20)
http://old.netsecurity.ne.jp/article/1/3581.html

編集部での検証（可能な範囲で）後、ベンダにその内容を連絡します。ベンダの対応スケジュールを確認の上、そのスケジュールにあわせて、セキュリティホールの公開を行ないます。

一般的に、利用者にとって顕在的、潜在的なリスクを知ることは重要なことです。にもかかわらず、多くのインターネットサービスは、利用者に対して、サービスを利用するにあたって起こりうるリスクをじゅうぶんには開示していません。開示しない理由には、意図的に開示を行なっていない場合とサービス提供者の知識が不十分なため開示の必要性を感じていない場合があります。

自社製品のメーラーにセキュリティホールが存在しているにも関わらず、その危険性をメーラー利用者に明示せず、「セキュリティ強化」のためのアップデートモジュ−ルとして配布したベンダがありました。
「セキュリティホールへの対処」と「セキュリティ強化」とでは、緊急度、重要度などが異なる上、その危険性の内容についてもベンダからの情報はありませんでした。

ShurikenPro2などに任意コマンド実行、添付ファイル強制起動のセキュリティホール(2002.9.9)
http://old.netsecurity.ne.jp/article/1/6570.html

サービスを利用する上でjavascriptなどのスクリプトやcookieが必須であるインターネットサービスは、それらが動作不能でも利用できるサービスに比較すると、新しい攻撃方法に対して脆弱であるといえます。
しかし、利用する上で必須であるのにもかかわらず、こうした潜在的な危険性について利用者に明示的に告知しているサービスはありません。利用者がリスクについて、適切な判断を行なえるようにこうした危険性はあきらかにすべきであると考えます。
増加している携帯電話などの非PC端末へ向けたインターネットサービスでは、すべての利用者に高いリテラシーを期待できません。そのため、利用に当たってのリスクは明らかにしておくべきといえます。

上記のいずれの場合でも利用者にとっては、リスク情報が開示されていません。インターネットの利用は自己責任とはいいながらも、自ら判断するために必要な情報が開示されていないために、リスク判断ができない状態での利用を強要することになります。これは利用者にとって、好ましいことではありません。

リスク判断のための情報開示には、過去のインシデント記録も含まれるべきであると編集部では考えています。
例えば、個人情報の漏洩あるいは悪用可能性の高い設定ミス（実際に事件は発生する前）に関する情報も利用者にとってはリスクを判断する上での有益な情報です。
個人情報を何度も漏洩するサービスに個人情報を登録する利用者は少ないでしょう。これは利用者の判断によるリスク回避です。しかし、個人情報を漏洩した事件が過去にあったことが公開されていなければ、利用者はリスクを回避する行動をとることができません。
一般のサービスでは、火災、食中毒、詐欺事件などインシデントは公開されますが、それにより、危険な店あるいは危険な商品を回避するという利用者はリスク回避行動をとることができます。インターネット上でも、そうあるべきと考えます。

もうひとつのポイントとして、こうした多くのインシデント情報が公開されることにより、利用者はインターネット利用にともなって存在するリスクを認識することができます。現在のインターネットの利用には、リスクがともない、インシデントが発生した際に、個人の権利や利益を守る制度は確立されていません。利用者が自己責任で利用するために、こうした状況についての情報は不可欠と考えられます。

これを総合的に判断し、編集部では、一般のインターネットサービス利用者に影響があるインシデント情報は、正しくリスクを認識させ、各々にとって適切な行動を判断するために必要不可欠と考えています。多くの場合、サービス提供者は、影響の有無と大きさについての判断を甘くしがち（利用者に影響はほとんどなく、したがって情報公開は不要）であり、利用者側は逆の立場をとります。当然のことながら、利用者は判断のための情報が多いほど、より正しい判断ができると考えます。
多くの場合、サービス提供者は、影響の有無と大きさについての判断を甘く（利用者に影響はほとんどなく、したがって情報公開は不要と考え）しがちであり、一方利用者側は受ける影響を深刻に捉え、情報公開は必要という逆の考え方をします。

SCAN 編集部は、前者の立場をとっています。つまり、可能な限り多くのインシデント情報を利用者に提供する立場をとっています。これは編集部が利用者（個人/ユーザ企業/SI事業者）からの収益を事業の柱としているためです。

情報入手時に公開します。

当該サービス提供者への連絡および確認、複数の情報ソースによる確認、社内での検証など、当該情報以外の複数の方法で確認を行ないます。なお、編集部が情報の整理、検証を終えた時点で対処が完了している場合は、当該サービス提供者への連絡を割愛することもあります。
サービス提供者における対処が確認された場合（あるいは1週間以内に対処を行わないことが確認された場合）、公開を行います。
情報の連絡から情報公開までのスケジュールは、サービス提供者への連絡時点から3時間から24時間を目安に情報公開を行ないます。時間が短いのは、すでに問題が一般に公開されており、緊急の対処が必要であるためです。サービス提供者側の対応完了までの間、利用者は危険な状態であることを知らずに利用する可能性があることになります。一般に悪意ある攻撃者は一般の利用者よりも、情報収集に熱心であり、悪意ある攻撃者が公開されているセキュリティホールを一般利用者よりも先に知り、攻撃を開始する可能性は少なくありません。これは、利用者にとって大きなリスクです。
個人情報の流出事件の多くは、個人情報が広範に盗まれてから、対処が完了するケースが少なくありません。

当該サービス提供者が多数の場合、編集部だけではサービス提供者への連絡などに対応できません。このような問題に対処することが期待される官公庁あるいは外郭団体に連絡を行なうことで、個別対応にかえることがあります。こうした機関が意味のある対応を行なうか、どうかは、わかりませんが、少なくともリスク情報をインターネット上で開示することにより、利用者はリスク回避行動をとることが可能になります。

当該サービス提供者に連絡の上、情報公開を行います。可能な限り、サービス提供者の対応スケジュールにあわせた形で対応します。
当該サービス提供者が多数（3件以上）にわたる場合、および連絡が困難であると想定される場合、関連機関への連絡をもってかえることもあります。
社会的影響が低く、利用者にもたらすリスクも低い場合、編集部では確認したインシデント情報をサービス提供者に連絡せず、一般公開しないことがあります。利用者にとってのリスクが低いことと、公開の前提となるサービス提供者への直接、間接の連絡業務の工数が多く見込まれるため、対応する人手が不足することが予測されるためです。編集部は有償で編集部の提供する情報を購入していただいている読者からの収益に支えられています。編集部のリソースにも限りがあり、かつ読者の方々からの収益を有効活用するために社会的影響が大きいと思われるものを優先しております。
例えば、編集部には、国内約20万件のドメインデータベースがあり、OSやWEBサーバのバージョンなどを把握しています。危険性の高いドメインは一目瞭然です。しかし、その数は、莫大であり、個別に連絡し、対処方法を教えることは、莫大な工数を必要とするにも関わらず、無償のボランティアとなります。そのため、編集部では対応していません。折に触れ、深刻な問題が発生した場合に、このような問題に対処することを期待されている官公庁あるいは外郭団体に対し、編集部から無償で関連する情報を提供することにしています。

悪用可能性の低いクロスサイトスクリプティング、メール不正中継可能性、検証が困難なセキュリティホールが、これにあたります。
情報公開することは、利用者にとってのメリットにつながるという認識のもと、情報公開します。

悪用可能性の低いクロスサイトスクリプティング、メール不正中継可能性、技術的に可能であるが検証が困難なセキュリティホールなどは、検証および悪用可能性を実証するためには、編集部自身が法的もしくは倫理的に不正なアクセス行為を行なう必要が生じることがあります。そのような場合には、編集部では確認することはできません。しかし、もし、問題が顕在化した場合、利用者は不利益を被る可能性があります。言葉を変えれば、グレーな情報であっても事前に可能性を知ることができれば利用者は危険回避行動をとることができるということになります。

悪用可能性の低いクロスサイトスクリプティング、メール不正中継可能性、技術的に可能であるが検証が困難なセキュリティホールなどの問題について、セキュリティホールでもインシデントでもないと主張するサービス提供者の方がいますが、編集部では、読者のメリットを基準として判断し公開します。当該サービスを利用している可能性のある読者や当該サービスに関係している読者の数と影響度が読者のメリットを判断する基準になります。

また、特定のカスタムアプリケーションによるサービスに問題があった場合、技術的に可能であるが検証が困難なセキュリティホールの存在が推定されることがあります。しかし、カスタムアプリケーションの場合、検証するために、実際に稼動しているサービスにアクセスと解析を行なうか、まったく同じ環境を構築してテストするしか方法のないことがあります。これは事実上、関係者以外には検証ができないことを示しています。しかし、まったく情報公開を行なわない場合、利用者はリスクのある可能性について対応することができません。なんらかの表現、方法、検証されている問題以上のリスクがある可能性について情報公開が必要であると考えます（あくまでも一部問題が検証されている場合に限ります）。

上記の問題について、当該サービス提供者が多数の場合、編集部だけではサービス提供者への連絡などに対応できません。このような問題に対処することが期待される官公庁あるいは外郭団体に連絡を行なうことで、個別対応にかえることがあります。

特定のサーバのアプリケーション名やバージョン情報＝例えば利用者がよく利用しているサービスのサーバあるいはアウトソースしているレンタルサーバのサーバの管理状態の情報は、利用者が自身の安全を確保するために役立つ情報となります。
情報公開することは、利用者にとってのメリットにつながるという認識のもと、情報公開します。

国内のサーバやサービスの管理水準の実態に関する情報は、ほとんど公開されておりません。インターネット上で不特定多数が利用可能なサービスは、パブリックサービスであり、パブリックである以上、一定の管理を行なうことは必要であり、その管理状況は公開されてしかるべきであると考えます。公開したくない場合は、インターネット上で不特定多数に公開せず、特定の人しか利用できないサービスにすればよいのです。パブリックサービスとして公開している以上、アクセスしてわかる範囲の情報は、公開すべきであると考えます。この基準にのっとり、編集部では、国内ドメインデータベースを有償で提供しています。データベースに記載されている内容は、インターネット上で簡単に当該サービスから入手することが可能であり、当該サービスによって公開されている情報は、簡単に入手不能のように設定することが可能です。入手不能にすることによる想定されるデメリットはほとんどありません。

東京電話インターネットWEB改竄記事に関する訂正とお詫び(2002.8.22)
http://old.netsecurity.ne.jp/article/1/6341.html
情報安全社のWebサイトにクロスサイトスクリプティング脆弱性(2002.6.24)
http://old.netsecurity.ne.jp/article/1/5653.html