皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

あるセキュリティベンダーの調査レポートによると、IEやエクスプローラーになりすますウイルスによる感染被害が日本でも出ています。

今日はそれについてお伝えします。

IE・エクスプローラーへのなりすましウイルス

このウイルスは『URLZone』というもので、存在そのものは10年以上前に見つかったものですが、数年前まではヨーロッパを中心とした被害であったものが、ここ最近は日本が中心になっているようです。

特徴としては、IEやエクスプローラーになりすますことと、サンドボックス環境でのウイルスを検知がしにくいこととされています。

感染経路の一つはメールで、『注文書や請求書』など、業務関連のメールに見せかけたメールに添付されている文書ファイルなどから感染することが明らかになっています。

詳細な内容はさておき、このようなウイルスへの感染を防ぐには、受信したメールをよく確認することです。

差出人、件名、本文、これらを見て、普段から取引のある相手であれば差出人であるメールアドレスはわかりますし、件名や本文に関しても書き方には特徴があるはずです。

それらが不明なものであったり、怪しいものである場合には間違いなく添付ファイルをクリックしてはいけません。

社内ルール的に可能であれば、『Firefox Send』などを使い、暗号化されたストレージ経由にて書類の受け渡しを行うなどし、メールではファイルの受け渡しを行わないようにすることも被害を防ぐ方法の一つです。

普段から無意識にメールのやりとりを行われている事業者の方、一度、社内のルールを見直してみてはいかがでしょうか。

しかし、それはロシアから送られてきたレポートでした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

私は普段、偽装メール（なりすまし）対策の一環としてSPFやDKIM、DMARCを使うことをお勧めしていますが、この偽装メール（なりすまし）は日本国内に限った話しではありません。

ロシアから届いたDMARCレポート

普段、DMARCレポートが届くのは現状Googleからのみであったのですが、ある日、ロシアからDMARCレポートが届きました。

その段階では、このロシアからのDMARCレポートそのものがスパムメールなのでは？と疑いをもち、メールのヘッダ情報などを調査しましたが問題は見受けられませんでした。

何かしっくりこず、セキュリティチェックを通してレポートファイルを確認したところ、どうやらロシアのIPアドレス宛にコーポレートドメインを偽装してメールが配信されたようでした。

前者の方はロシアでメールを含めたサービスを提供している企業で、その企業がDMARCレポートを配信する仕組みを取り入れていたことからコーポレートドメインのDMARCレポートが届いたということで、実際に問題な行為を行ったのは後者のIPアドレスを利用した者と考えられます。

このように、偽装メール（なりすまし）は日本国内宛にとどまらず海外宛にまで及んでいます。

現在、コーポレートドメインをはじめすべてのドメインに対してDMARCを採用しているのですが、メールに対する制御は『none：そのまま受信させる』のまま様子見をしていた状態でした。

今回のことを考えると、やはり『quarantine：隔離させる』か、『reject：受信を拒否する』に変更していくことになるでしょう。

これらに変更することで、受信者のメールサーバーに対して隔離、もしくは拒否を依頼することができますので被害を抑制することが可能です。

しかし、課題も残ります。

先日起きたケースとして、相手先がGmailなどに自動転送していた場合、Fromは送信元メールアドレスのままなであったものの、出力されるIPアドレスは転送元のIPアドレスでした。

（相手先の契約サーバーの仕様によって左右されます。）

このような場合はつじつまがあわないことになりますのでSPF認証は失敗となり、DMARCにおけるメールの制御によっては相手にメールが届かないケースが出てきたりします。

しかし、そこには多くの危険が潜んでいます。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

ここ最近、Googleを主導としたウェブの暗号化については多少ホットな話題ではありますが、ビジネス上、頻繁に使われる電子メールのやりとりにおいてはそれが忘れられているように感じます。

今日は、そんな電子メールの安全なやりとりに関してお話しします。

電子メールのやりとりに多い例

よくあるケースとして、以下のようなやりとりが行われることが多いです。

１．AからBにパスワード付の添付ファイルを添付したメールを送る

２．AからBに別のメールで１のパスワードを送る

３．Bが１と２を受け取り、添付ファイルを開く

このやりとりの流れに心当たりがある方は多く存在するかと思います。

しかし、このやりとりにおいて電子メールは平分、つまり暗号化されていないもので送られていることが大半です。

この場合、悪意のある第三者にパスワードを盗聴されてしまえば簡単に添付ファイルは開くことができてしまいます。

電子メールの安全なやりとり

電子メールのやりとりにおいて問題なのは、平分で送っていても添付ファイルに対するパスワードは別のメールで送っているから大丈夫だという認識です。

これはまったくもって大丈夫ではありません。

ではどうするか？

電子メールにおいても暗号化を用いることです。

よく知られているものとしては、銀行などから送られてくるメールに付いているデジタル署名（S/MIME）証明書を用いる方法です。

双方がデジタル署名（S/MIME）用の証明書を取得し、それを使って電子メールを送信することで暗号化することができます。

これを用いた場合、もし相手がデジタルIDを持っていなかった場合には平分で送られてしまうことにはなりますが、送信者を証明してくれるものにもなるため、『なりすまし防止』にも役立ちます。

また、他の方法としてはPGPというツールを用いて暗号化をする方法があり、この場合においては電子証明書がなくても暗号化してやりとりすることができます。

いずれにしても相手のあることですから、各取引先と協議を行い、お互いにリスクを回避するためにこれらの導入を検討されることをお勧めします。

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

2010年以降減少傾向にあった迷惑メールの検知数は、2016年に入って再び上昇し、増加しています。

そして、中でも多いのは『なりすましメール』と呼ばれるものです。

この『なりすましメール』を排除していくには、メールの送信側と受信側における連携が必要であり、送信側においては送信するメールの正しい情報を提供することが必要になります。

送信ドメイン認証の仕組み

前述の通り、まずは送信側において正しい情報を提供する必要があります。

その第一歩として送信ドメイン認証を使ったりしますが、その場合には下記のような状態となります。

※前提：送信側・受信側ともにSPFを導入済み

１．送信側のA社が受信側B社にメールを送ります

２．受信者側のB社はA社のDNSサーバに問い合わせを行います

３．２の要求に対し、A社のDNSサーバが送信用メールサーバに関する情報を返します

４．３の確認結果に基づきメールを配信する

SPFレコードの設定方法

送信側の設定としてはDNSサーバにSPFレコードを追加します。

そこに、SPFもしくはTXTとして以下の記述を追加します。

※前提：送信用メールサーバのIPアドレスが192.1.1.1の場合で、ドメインがexample.comの場合

“v=spf1 +ip4:192.1.1.1 -all”

これを追加するだけです。

また、受信側としてSPFの検証機能を導入すれば『なりすましメール』を区別できるようになりますが、メールサービスやメールサーバソフトによって異なりますので、ご利用のレンタルサーバ会社へ問い合わせることなどが必要です。

（レンタルサーバ側にて導入済みであれば、受信側としては何も行うことはありません。）

ただし、昨今SPFだけでは不十分ということも指摘されており、近いうちにそれを補うものをご紹介できればと思います。