セキュリティウォッチ : パスワードとクレジットカード、第 2 部

セキュリティウォッチパスワードとクレジットカード、第 2 部

Jesper M. Johansson

擬似的多要素ログオンプロセス
ブラウザのアドインの問題
認証システムは決して変更されてはならない
セキュリティレベルの低いパスワードにダウングレードする
擬似的多要素ログオンを迂回する
侵害されたパスワードに関する問題
いくつかのメリット
見掛けだけのごまかしでユーザーを誤った方向に導く
開くべきか、開かざるべきか、それが問題だ
安全な通信を提供する
プライバシーについて

3 回シリーズの第 2 回目へようこそ。このシリーズでは、セキュリティの問題に関して、IT 業界がユーザーを助けるのではなく、むしろ混乱させている状況について説明します。2008 年 7 月号の TechNet Magazine では、実行不可能かつ間違ったアドバイスと、紛らわしいログオン手順について説明しました (第 1 部をまだお読みでない方は、

technet.microsoft.com/magazine/cc626076 をご覧ください)。きわめて一般的でありながら間違ったセキュリティ上のアドバイスと複雑なログオン手順が、どのようにユーザーを混乱させ、個人情報を保護するためのユーザーの努力を台無しにしているかについて論じました。

今月の記事では、ユーザーのセキュリティに関する実例を使用して、この議論を続けます。来月号の TechNet Magazine に掲載予定のこのシリーズの最終回では、世界中のセキュリティプロフェッショナルを召集します。

擬似的多要素ログオンプロセス

2005 年 10 月に、FFIEC (米国連邦金融機関検査協議会) がガイドライン『Authentication in an Internet Banking Environment』(インターネットバンキング環境における認証) を発表しました (www.ffiec.gov/press/pr101205.htm 参照)。履行までの期限がわずか 14 か月であったため、米国内の金融機関はすぐに、この新しいガイドラインを満たすための方法を大急ぎで模索し始めました。

しかし、ほとんどの金融機関は、この期限に間に合いませんでした。そうした金融機関も、最終的にはガイドラインの順守を実現しましたが、その多くは、ガイドラインを満たすこと以外には何の意味もない手段で実現したにすぎませんでした。つまり、ユーザーのセキュリティを強化することにつながらない措置を講じた ("セキュリティショー" を演じた) のです。最も注目される役に立たないソリューション例の 1 つは、実際には多要素ではない多要素認証を実現しようとするソリューションです。

たとえば、ユーザーがパスワードを入力するときの入力リズムを測定するテクノロジを考えてください。このテクノロジを Web サイトで使用するソリューションでは、従来のログオンダイアログボックスとまったく同じ外観のログオンダイアログボックスが表示されます。ただし、このダイアログボックスは Adobe Flash オブジェクトであるという点が異なります。

Flash オブジェクトでは、キーが押されている時間やキーを押す間隔などの特徴を含む、ユーザーの入力リズムが記録されます。このデータは、パスワードと共に Web サイトに送信され、保存されている値と比較されます。入力リズムのデータと保存されているデータの差異が一定範囲内にあり、パスワードが一致すれば、ログオンが許可されます。これは、クライアント側でサードパーティ製ハードウェアを搭載する必要なく、擬似バイオメトリクス認証方法をサイトで使用できるという概念に基づいたソリューションです。

ここでは、これを擬似的多要素認証と呼びます。擬似的多要素認証は、真の多要素認証ではありません。というのは、真の多要素認証では、次の 2 つ以上の要素が評価されるからです。

ユーザーの所有物 (スマートカードなど)
ユーザーの知識 (パスワードなど)
ユーザーの特徴 (指紋など)

擬似的多要素認証では、実際に複数の要素を認証プロセスに含めるのではなく、たった 1 つの要素 (つまり、パスワード) から複数の条件を読み取ります。そして、読み取った追加の条件を使用して、ユーザーの特徴を推論します。

擬似的多要素認証に使用されるテクノロジには、多くの欠点があります。そうしたすべての欠点により、採用したテクノロジは、解決するはずのセキュリティ上の問題を解決できないという事態を引き起こしています。

ブラウザのアドインの問題

擬似的多要素認証システムでは、必要となる高度なクライアント側の処理を提供するのにブラウザのアドインを使用します。すべてのソフトウェアにはバグが付き物で、そのようなバグの中には脆弱性の原因となるものがあります。ソフトウェアの更新が困難で、更新がインストール済みかどうかをユーザーが把握していない場合、そうした脆弱性は深刻な問題となります。

ブラウザのアドインには、この両方の欠点があり、更新が困難で、インストールされているバージョンが最新かどうかに関する十分な情報がユーザーに提供されません。そのため、ユーザーは、このような欠点がなければ公開する必要がないソフトウェアをインターネットに公開しなければなりません。

アドインを最新の状態に保つために、アドインの Web サイトに定期的にアクセスしてアドインを更新しなければならないこともあります。言うまでもないことですが、ほとんどのユーザーが、このようなことを実行する可能性はきわめて低いでしょう。セキュリティ機能を提供するためだけにエンドユーザーが関連のないソフトウェアをインターネットに公開する必要があるシステムは、明らかに検討が必要です。

認証システムは決して変更されてはならない

"ユーザーの特徴" という要素には、他の 2 つの要素にはない欠点とも言える特性があります。パスワード (ユーザーの知識) は変更可能で、セキュリティトークン (ユーザーの所有物) は新たに製造可能ですが、使用できるバイオメトリクス認証システムの数はかなり限られています。たとえば、指紋であれば、通常、1 人のユーザーにつき 10 種類しかありません。もし事故でいずれかの指を失ってしまえば、通常それを元に戻すことはできません。

では、これが、擬似的多要素ログオンの例にどのように当てはまるかを見てみましょう。別の要素の一部として収集された指標を、簡単に置き換えたり変更したりすることはできません。確かに、パスワードが変更されればユーザーの入力の仕方も変わりますが、ユーザーがキーボードのキーを押す大まかな方法は変わりません。この手法で使用されるのは、まさにこの点です。しかし、この指標が侵害された場合、指標を合成することは不可能ではありません。改ざんとまではいかなくても、攻撃者はこれらの指標をキャプチャして、再現することができます。

セキュリティレベルの低いパスワードにダウングレードする

パスワードは、長いものを使用し、頻繁に変更することをお勧めします。また、このシリーズの第 1 部で説明したように、(一部のアドバイスとは逆に) パスワードを安全な方法で記録しておくこともお勧めします。ただし、この方法は、手作業によるパスワードの入力には向いていません。長いパスワードは入力しづらいので、記録されたパスワードは、コピーして貼り付けられるときにより役立ちます。多数のパスワードを記録しておく最良の方法の 1 つは、Password Safe (sourceforge.net/projects/passwordsafe) などのソフトウェアユーティリティを使用することです。このようなツールを使用すると、完全にランダムなパスワードを生成し、生成したパスワードを暗号化された形式で保存して、ログオンダイアログボックスに直接貼り付けることができます。つまり、このようなツールを使用すれば、パスワードを把握する必要さえありません。

しかし、問題点もあります。パスワードを入力するときの入力リズムは、ユーザーがパスワードを入力しない限り測定できません。そして、入力リズムを測定するオブジェクトにパスワードを入力する必要がある場合、このパスワードを管理する手法は機能しなくなります。15 文字の完全にランダムなパスワードを正しく入力することは、簡単な作業ではありません。そのため、多くの場合、このようなシステムを使用する際には、ユーザーは単純なパスワードを使用する傾向があります。しかし、15 文字の完全にランダムなパスワードは、単独で使用した場合も、短いパスワードと擬似的多要素認証システムを併用した場合よりもはるかに安全です。

事実上、擬似的多要素認証を単独で実装するということは、ユーザーがセキュリティレベルの低いパスワードの使用を余儀なくされるということになります。この後すぐに説明しますが、残念ながら、適切なパスワード管理手法を使用するユーザーに対応することで、擬似的多要素認証システムで提供できるほぼすべての価値が無用となります。

擬似的多要素ログオンを迂回する

サイトで擬似的多要素認証を実装している場合でも、擬似的多要素システムを迂回する方法をサポートする必要があります。というのも、ほとんどのサイトでは、サイトにアクセスできるようにするために、すべてのユーザーに "第四者" テクノロジのインストールを求めることはできないからです。一部のユーザー (たとえば、一部の TechNet Magazine 著者) は、このようなソフトウェアのインストールを常に拒否するでしょう。

また、入力リズムはさまざまな理由で変わる可能性があるため、サイトではその変化に対応する必要があります。たとえば、ユーザーが手首をねんざして、入力リズムが一時的に変化しているとします。その際、サイトで入力リズムが分析された結果、第三者がそのユーザーの資格情報を使用してログインを試みていると見なされたら、そのユーザーはどのようにしてサイトにアクセスしたらよいでしょうか。恒久的な負傷であれば、ユーザーが保存されているリズムの値を再設定することで、この問題に対応できます。しかし、一時的な負傷の場合、おそらくユーザーは、すぐに元の入力リズムに戻ると考えて、保存されている値を再設定することは望まないでしょう。

さらに、すべてのユーザーが擬似的多要素認証システムを使用できるわけではありません。たとえば、音声認識インターフェイスを使用してコンピュータを操作している身体に障害のあるユーザーは、プログラムによる入力が禁止されているかどうかによっては、ダイアログボックスに情報を入力できない場合があります。その場合、法律の規定によって、障害のあるユーザーに対応する代替システムが必要となる可能性があります。

このすべてのシナリオに対応する最も簡単でわかりやすい方法は、標準のパスワードベースの認証もサポートすることです。

侵害されたパスワードに関する問題

擬似的多要素認証システムは、パスワードベース認証に関連するさまざまな問題を解決するとされています。しかし、このシステムでは、パスワードを侵害する深刻なあらゆる手段を完全に遮断することはできません。パスワードベース認証を使用するシステムを侵害する主な手段には、次の 5 つがあります。ここで "侵害する" とは、攻撃者が別のユーザーのパスワードを取得して使用することを意味します。

パスワードの推測
キーストロークロガー
フィッシング攻撃
ユーザーにたずねる
パスワードやそのハッシュを保存するシステムへの侵入

パスワードの推測は、攻撃者にとって、あまり一般的な攻撃方法ではなくなり、キーストロークロガーとフィッシングによってすっかり影が薄くなっています。また、部分的にではありますが、パスワードの推測は、擬似的多要素認証によって軽減されています。擬似的多要素システムに侵入するには、攻撃者はパスワードだけでなく入力リズムを推測する必要があるため、従来のパスワードを推測する方法が擬似的多要素認証システムで機能する可能性は低いでしょう。入力リズムの指標を合成することは、理論的には可能ですが、通常はフィッシング攻撃やキーストロークロガーで実際のデータをキャプチャできるため、合成の必要はほとんどありません。また、システムによって、標準のパスワードのみのログオンインターフェイスが提供される場合、攻撃者は単純にそのシステムを使用してパスワードを推測できます。

さらに、パスワードの推測による攻撃の大部分は、強力なパスワードによって阻止できます。強力なパスワードを使用するように (場合によりツールを使用して) ユーザーを指導できれば、擬似的多要素認証は必要ありません (一方、擬似的多要素認証システムで一般的に使用される簡単なパスワードは、パスワードの推測がより実行可能な攻撃方法となる手助けをしていると言えます)。したがって、ここでパスワードの推測による攻撃を軽減する対策として提供している情報が有効になるのは、パスワードのみのログオンがサポートされない場合に限ります。しかし、既に指摘したように、これはほぼ不可能です。つまり、ユーザーが擬似的多要素認証システムで脆弱なパスワードを使用すると、パスワードの推測が再び実行可能な攻撃方法になる場合があります。擬似的多要素認証は、セキュリティを強化するどころか弱めることになります。この問題には、さらなる調査が必要です。

擬似的多要素認証は、キーストロークロガーの問題を解決することもできません。現在一般的に使用されているキーストロークロガーで入力リズムをキャプチャするものは把握していませんが、そのようなキーストロークロガーを設計できない理由はまったくありません。キーストロークロガーは、キーボードとコンピュータ、またはキーストロークをキャプチャするソフトウェアとの間に介在するハードウェアです。どちらの場合も、ロガーは、擬似的多要素認証ソリューションで使用されるすべてのデータへのフルアクセスを持っています。

実際、認証ソリューションはユーザーモードで実行されますが、キーストロークロガーはそれよりもはるか下位に位置するため、キーストロークロガーはさらに多くのデータにアクセスできます。パスワードのキャプチャに使用される Web ベースオブジェクトとキーボードとの間に信頼済みパスがなければ、このような侵害を回避することはできません。擬似的多要素認証ソリューションの普及が進めば、そのようなキーストロークロガーが作成されるのは、まず間違いないでしょう。

同様に、擬似的多要素認証では、フィッシング攻撃も解決できません。攻撃者は、偽のログオン画面だけでなく、Flash オブジェクトを併用してパスワードと入力リズムをキャプチャできます。

確かに、擬似的多要素認証は、攻撃者がユーザーのパスワードだけを提供する手法を使用している場合には役立ちます。たとえば、ユーザーからパスワードを取得する最も簡単な方法は、ユーザーにたずねることです。驚くことに、直接的であろうと電話やフィッシングメッセージを使用する場合であろうと、ユーザーにたずねるという方法は有効な手法であることは実証されています。

もちろん、ユーザーに入力リズムをたずねることの有効性は、はるかに低くなります。また、企業のパスワードデータベースが侵害された場合、おそらく攻撃者が入手できるのはパスワードのみです。しかし、繰り返しになりますが、こうした攻撃が軽減されるのは、システムで標準のパスワードのみの認証を使用していない場合に限られます。

また、実際にパスワードデータベース自体が侵害された場合、攻撃者はおそらく、単一 (または多く) の標準のユーザーアカウントパスワードを入手した場合に可能なレベルよりもはるかに深くまでシステムを侵害していると考えられます。したがって、パスワードデータベースを入手した攻撃者による攻撃を軽減しようとすることは、あまり有効ではありません。

いくつかのメリット

公平に見て、(システムで標準のパスワードのみのログオンオプションが提供されないことを前提とすれば) 擬似的多要素認証で解決できる問題もいくつかあります。たとえば、擬似的多要素認証を使用すると、パスワードの共有を回避できます。ただし、これは、共同の銀行口座など、複数のユーザーがアカウントを共有することが適正なシステムでは障害となることがあります。

また、適切に設計された (Web サイトログインではない) 対話型ログインダイアログボックスを使用すると、入力リズムが一致しなかった場合に別の認証手順を実行するようにユーザーに強制できます。これにより、機密性の高い環境でアカウントが侵害された場合のセキュリティを強化できます。

見掛けだけのごまかしでユーザーを誤った方向に導く

ユーザーを最も混乱させるのは、誤ったセキュリティ情報を提示することです。おそらく最も一般的なのは、図 1 のように、Web ページ上に南京錠のイメージを表示することです。このページでは、南京錠の横に Secure という単語まで表示しています。

図 1 厄介な南京錠アイコンの乱用例 (画像をクリックすると拡大表示されます)

おわかりのように、南京錠のイメージと Secure という単語を追加するだけでページのセキュリティを確保できるわけではありません。しかし、定評がありアクセスが多い Web サイトでさえ、これは不安になるほど一般的に行われています。そのため、多くのユーザーは、このような安全性の視覚的手掛かりを Web ページの本文中で探すことに慣れていて、これらの手掛かりが実際に意味を持つ場所であるアドレスバーを見ていません (この問題については、W3C Web Security Context Wiki のエントリ (w3.org/2006/WSC/wiki/PadlockIconMisuse) を参照してください)。

残念ながら、このような乱用には、他にも非常に多くの例が存在します。調査によると、証明書が一見して明らかに偽物である場合でさえ、ユーザーは悪意のある Web サイトを識別できません (詳細については、www.usablesecurity.org/papers/jackson.pdf を参照してください)。結局は、比較対象として使用できる本物がない場合でも偽物と本物を簡単に識別できる能力があるかどうかにかかっていると言えます。それにはスキルが必要です。ですが、Web ページ上の誤解を招くおそれがある見掛けだけの安全性のごまかしによって、ユーザーは誤った情報に引き寄せられてしまい、そのスキルの形成が妨げられます。

この問題の 1 種で特に気になる例を、図 2 に示しています。この場合、情報が表示されているページは、実際には安全ではありません。アドレスバーを見ると、使用しているプロトコルを示す http という文字列を確認できます。このサイトでは、非常に一般的な最適化の手法が使用されています。つまり、ログオンフォームを含むページが暗号化されるのではなく、フォームの送信のみが暗号化されています。このページに示されているように、"安全であること" が "暗号化されていること" と同等である見なす場合、ログオンは安全です。ただし (非常に重要なことに)、ユーザーは、資格情報が送信される前に送信先を確認することができません。サイトでは、フォームが送信される前にユーザーにサイトの正当性を証明する証明書が表示されません。これは、背後の人が自分のことを受け止めてくれることを前提として後ろに倒れる、信用ゲームのようなものです。フォームが送信されたときには、既に被害が発生している場合があります。

図 2 安全でないページの見掛けだけの安全性のごまかし (画像をクリックすると拡大表示されます)

HTTPS でセキュリティを強化するプロトコルである Secure Sockets Layer (SSL) は、2 つの重要な役割を果たします。1 つ目の役割は、サーバーの正当性をユーザーに証明することで、2 つ目の役割は、クライアントとサーバー間で使用されるセッションの暗号化キーをネゴシエートするための、簡単なメカニズムを提供することです。

フォームの送信だけが暗号化される場合、1 つ目の最も重要な目的は果たされません。この最適化の手法を使用しているサイトでは、キーをネゴシエートするためだけに SSL が使用されています。皮肉にも、それは単純に、標準のキーのネゴシエーションプロトコルを使用することで実行でき、それによって SSL を使用した場合のコストとオーバーヘッドを回避できます。

図 2 のようなサイトは、珍しいものではありません。多くのサイトでは、フォーム自体ではなく、フォームの送信だけに対して SSL の保護が提供されます。しかし、このサイトには、さらに気になる特徴があります。ブラウザのアドレスバーに「https://www.<site>.com」と入力すると (安全な https の表示に注目してください)、SSL を使用していないサイトにリダイレクトされます。サイトに資格情報を送信する前に証明書を調べようとしても、サイトでは証明書の表示が拒否されます。

すべてのサイトがそれほど悪いわけではありませんが、不適切なサイトは数多く存在します。米国の 2 大クレジットカード発行会社は、その一例です。実際、私が使用している 3 大クレジットカード会社のうち、ログオンフォームで証明書を提供しているのは、アメリカンエキスプレスだけです。また、アメリカンエキスプレスのサイトでは、HTTP 要求を HTTPS にリダイレクトしています。お見事です。

見掛けだけの無意味な安全性のごまかしと、ログオンフォームでの証明書の欠如に関する最後の見解を述べましょう。なぜサイトでこのようなことが横行しているのか、疑問に思う人もいるでしょうが、それは単純に経済的な理由です。証明書を表示するにはページを暗号化する必要があり、ページを暗号化すると処理オーバーヘッドが発生します。処理オーバーヘッドとは、同じ負荷の処理に、より多くのコンピュータが必要になることです。そして、コンピュータの台数が増えれば、コストも増えます。残念ながら、顧客のプライバシー保護と増益のどちらかを選択する場合、多くの組織は増益を選択します。

開くべきか、開かざるべきか、それが問題だ

私は先日、健康保険会社から驚くべき電子メールメッセージを受け取りました。ここ 10 年の間にコンピュータを使用したことのある人ならだれでも、要請していない電子メールの添付ファイルは決して開けるべきではないことを知っています。そこで、図 3 のようなメッセージを受け取ったときに、私がどれほど驚いたかを想像してみてください。

図 3 "安全な添付ファイル" を含む電子メールメッセージ (画像をクリックすると拡大表示されます)

どうやら私は、健康保険会社の Web サイトで質問をしていたようです (そして、このメッセージが到着したときには、そのことを忘れていました)。これは、その質問に対する会社からの返答でしたが、初めは巧妙なフィッシングかと思いました。これが正当なメッセージだとわかったとき、身の毛がよだつ思いをしました。

一番最初の手順は、添付ファイルをダブルクリックして、メッセージの暗号化解除を開始することでした。セキュリティコミュニティと IT 管理者は、10 年間もの歳月を費やし、ユーザーに添付ファイルをダブルクリックしないように指導してきました。それにもかかわらず、添付ファイルをクリックするように求める企業があるというのです (しかも、この方法を使用しているのは、この保険会社だけではありません)。この場合、ユーザーはどのように対応するべきでしょうか。ユーザーが学ぶこと、または忘れるべきことは何でしょうか。

次に、Microsoft® Office Outlook® 2007 のプレビュー機能を使用して添付ファイルを表示しました。図 4 に示すように、Outlook では、このメッセージは攻撃である可能性があると見なされ、開かないように警告されました。

図 4 Outlook 2007 によって安全なドキュメントが悪意のあるドキュメントと見なされる (画像をクリックすると拡大表示されます)

健康保険会社が、世界で最も一般的な電子メールクライアントで使用されるごく基本的なセキュリティチェックに反することは、皮肉であり、残念でもあります。この保険会社が、新しいセキュリティソリューションを Outlook でテストしていないことを考えれば、同社が個人情報を保護するために何かを行っているのかは疑わしいものです。さらにはっきり言えば、顧客のプライバシーが十分に保護されていないとして非難されないように、この会社では他にどのようなソリューションが実装されているのでしょうか。これは、金融機関が演じたセキュリティショーと同じです。この場合、ソリューションの主目的は非難の回避であり、実際に顧客を保護することではありません。

添付ファイルが実際には何なのかを見てみたところ、ActiveX® コントロールオブジェクトでした。添付ファイルの内容を確認するには、それを Internet Explorer® で開いてオブジェクトをインストールする必要がありました。表示されたのは、図 5 のような安心感を与えるための画面です。ご覧のとおり、デザイナは、メッセージを通常の封筒のように見せるためにあらゆる手段を講じており、信用できる封筒であることを主張するスタンプまで押されています。

図 5 Trusted というスタンプが押された封筒を表示する安全なドキュメント (画像をクリックすると拡大表示されます)

このようなテクノロジには、さまざまな理由で問題があります。まず、添付ファイルを開くという、ユーザー側で非常に不適切な操作が促進されます。また、実際のメッセージでは、常に確認なしで添付ファイルを開くようにシステムを構成するという非常に不適切なガイダンスが提供されます。電子メール自体では信用できると示されているのに Outlook では信用できない通知されるという、コンピュータの相反するメッセージにより、メッセージがかなり不審に見えます。そして、実際の添付ファイルには、本当に信用できることをユーザーに納得させるための、見掛けだけの無意味な安全性のごまかしが含まれています。ユーザーがこのようなメッセージを信用するようになったら、同じような形態の悪意のあるメッセージを信用するようになるまで、それほど時間はかからないでしょう。

安全な通信を提供する

確かに、このテクノロジで解決するとされる問題は非常に重要です。信用できる方法でユーザーと通信するのは、簡単なことではありません。ただし、この特定のソリューションは過度に設計されています。ユーザーの混乱を招き、ユーザーのシステムが侵害されるという当初の目標とは正反対の結果をもたらす可能性があります。

現在、適切に設計された Web サイトでは、"メッセージセンター" が使用されています。この設計では、企業が顧客とやり取りする必要があるときには、「メッセージセンターにメッセージがあります。Web サイトにアクセスしてログオンし、[メッセージセンター] リンクをクリックしてメッセージを表示してください。」という内容の電子メールメッセージを顧客に送信します。Secure Multipurpose Internet Mail Extensions (S/MIME) を使用してすべての顧客への電子メールメッセージに署名すると、ユーザーに送信元の正当性を証明できるという、おまけのメリットもあります。また、電子メールメッセージに "このリンクをクリックしてください" という事項が含まれない場合には、つまり、ユーザーが企業の URL を手作業で入力することで、間違いなく目的のサイトにアクセスできるという別のメリットもあります。

企業は、メッセージセンターと署名付きメッセージを使用することで、顧客とやり取りする信頼済みパスを確立できます。メッセージワークフローで顧客が目にするものはすべて認証済みであり、企業が不適切なセキュリティ対策を促進することもありません。

プライバシーについて

このシリーズの第 1 部と第 2 部では、セキュリティプロフェッショナルが実はユーザーに害を与えていて、それがどのように行われているかについて説明しました。IT プロフェッショナルはセキュリティを管理する必要があります。しかし、決定事項や実装しているソリューションの多くはユーザーを混乱させ、不適切な判断を促したり、セキュリティに関する誤った認識を与えています。このような相反する概念がユーザーに悪影響を及ぼさないようにする必要があります。

前述のとおり、一般ユーザーにとってセキュリティとは、単純にパスワードとクレジットカード番号を保護することです。ユーザーは、テクノロジが機能すること、そして信用できることを望んでいます。残念ながら、ユーザーは判断を下す必要があり、ユーザーが詳細な情報に基づいて判断を下せるようにすることが私たち IT プロフェッショナルの仕事です。

このシリーズの最終回となる第 3 部では、ユーザーが利用できる最も重要なテクノロジの一部が期待値に達していない理由ついて説明します。また、召集をかけます。ぜひ、2008 年 9 月号のセキュリティウォッチコラムもご覧ください。