Google Chromeが2017年からHTTP接続に警告を表示

参考リンク:
Google Chromeが2017年からHTTP接続に警告を表示 → 外部リンク
chrome56 no ssl

Google Chromeチームは9月8日(米国時間)、「Chromium Blog」において、2017年1月のGoogle Chrome 56からパスワードやクレジットカード情報を送信しているHTTPサイトを「安全ではない(Not secure)」と表示すると伝えました。
最初は、アドレスバーにグレーで「Not secure」と表示されるようになるとのことでが、最終的にはすべてのHTTPページを対象に、破損しているHTTPSページと同じ赤い三角のアイコンで安全でないことを表示するようになる…とのことです。

chrome56 no ssl

Gmailに認証に関する警告機能が追加されます

参考リンク:
Google、「Gmail」にセーフブラウジング保護を追加 → 外部リンク

米Googleがメールサービス「Gmail」に認証に関する警告機能を追加します。
この機能の追加により、Web版とAndroid版のGmailで、SPFまたはDKIMで認証されないメールの送信者プロフィール画像・企業ロゴ欄に?マークを表示して、メールが認証されていないことをひと目で確認できるようになり、利用者が「このメールに使われているメールアドレスは危険かもしれない」という判断ができるようになります

※貴社のメールサーバーが送信ドメイン認証技術の「SPF」あるいは「DKIM」に対応していない場合、メールの送信相手がGmailをお使いであれば「?」マークが表示されますよ…という意味です。


UTMの取り扱いを開始しました

UTM(Unified Threat Management)をご存知でしょうか?

UTMは「統合脅威管理」などと訳され、コンピュータウイルスやハッキングなどの脅威からネットワークを効率的かつ包括的に保護する管理手法で、ファイアウォール・VPN・アンチウイルス・不正侵入防御(IDS・IPS)・コンテンツフィルタリング・アンチスパムなどの機能をセキュリティアプライアンスとしてゲートウェイ1台で処理します。
この「ゲートウェイ」を指して「UTM」と言います。

ウイルス対策用のアプリケーション(アンチウイルスソフト)だけでは対応しきれなくなっている現在のウイルス・スパム・マルウェア等の脅威に対し、ネットワークの入り口防御・出口防御を行うとことで、端末へのダブルロックが必須な時代になっています。

最近では、ユーザーPCのファイルを暗号化し、そのファイルに対して身代金の支払いを要求する『ランサムウェア』が猛威をふるいましたが、このランサムウェアに対しても対策が可能です。

img_cp4000_07

「あやしいメールを開くな」…注意は無意味か?

米Verizonによる分析

参考リンク:
「あやしいメールを開くな」は無意味? 掛け声で終わらせない方法 → 外部リンク
米Verizonの分析では2015年に発生した900件以上のデータ侵害になりすましメールが使われた。
データ漏えい事案のうち900件以上で、フィッシングメール(なりすましメール、標的型攻撃メール)が使われ、受信者の30%が開封していたことが分かった。13%はマルウェアなどが密かに埋め込まれた添付ファイルを開き、11%はメールのリンクから誘導されるフィッシングサイト(なりすましサイト、偽サイト)にアクセスして個人情報などを入力してしまっていたことも判明した。
「あやしいメールを開くな」とよく言われるが、同社は補完的な対応が不可欠だと指摘する。


求められる「三位一体の対策」

前回のエントリー「三位一体の対策を – IPAが標的型攻撃に注意喚起」でも記載しましたが、もう一度さらに平易な言葉な置き換えて記載しておきたいと思います。

メールに対する警戒意識の向上と維持

      「あやしいメールを開くな」と普段から指示を行うことについて、間違っているとは思いません。
      が…現在のシステムにおいては「作業者が故意に開かなくても」システムの脆弱性を突いてセキュリティ上の重大な問題を引き起こすマルウェア・ウイルスが存在します。
      このような状況を利用者(従業員)がしっかりと認識をしたうえで警戒心の向上・維持を行うことが求められています。

受信メールの真正性を保証する仕組みの導入

      最近のメールは見た目で「あやしいメール」かどうかが判断できないほど巧妙になっています。
      なりすましメールへの対応策として「見た目」ではなく、「送信ドメイン認証」(SPF・DKIM)等のシステマチックな対応が必要です。

個人情報を保有するデータベースをインターネットにアクセスするネットワークから切り分ける

      外部からのメールを受信するためだけに、VirtualBOXなど仮想化された環境を準備し、その仮想化PCの中のメール受信ソフトでメールを受信するようにします。
      このようにすることにより、万一ウイルス等に感染しても、会社内のネットワークを直接汚染することがなくなります。

三位一体の対策を – IPAが標的型攻撃に注意喚起

IPAによる注意喚起

標的型攻撃メールを起因とした個人情報流出の事案が後を絶ちません。
この状況に対し情報処理推進機構(IPA)は、大規模な情報漏えいに繋がりかねない企業を狙う標的型攻撃に対応するために、リテラシの向上適切な運用管理セキュアなシステムの構築 の三位一体で対策をする必要があると企業・組織に対して注意喚起を行いました。

参考リンク:
【注意喚起】攻撃の早期検知と的確な初動による深刻な被害からの回避を → 外部リンク


リテラシの向上・適切な運用管理 という側面から

メールに対する警戒意識の向上と維持

      非常に巧妙化している標的型攻撃メールの文面・タイトル等の内容に対し、従業員に定期的な教育を行い、攻撃メールに対する警戒心の向上・維持を図ることを勧めています。
      また、誤ってメールを開いてしまった場合も含めた、従業員から所定の担当部門への報告訓練などにも言及されています。

受信メールの真正性を保証する仕組みの導入

      なりすましメールへの対応策として「送信ドメイン認証」(SPF・DKIM)などメールの真正性を保証する仕組みの導入も検討に値する…としています。

セキュアなシステムの構築・適切な運用管理 という側面から

個人情報を保有するデータベースをインターネットにアクセスするネットワークから切り分ける

      ことが必要…としています。
      また、不審な添付ファイルを開かなければならない場合については、仮想環境で開くなど添付ファイル確認用の環境のシステム面での整備も検討を要する…としています。

スパムメールに対するセキュリティ的考察

個人情報流出

旅行代理店大手JTB(ジェイティービー)が、6月14日 氏名や住所・電話番号・パスポート番号などを含む顧客情報を不正アクセスにより流出した可能性があると発表しました。

参考リンク:
不正アクセスによる個人情報流出の可能性について → 外部リンク

今回発生した事例では、「取引先を装ったメール」により偽の添付ファイルを開かせることでウイルスに感染させるという「標的型攻撃」と呼ばれる手口が使われていたようです。

スパムメール – 標的型攻撃

「標的型攻撃」でターゲットに送信されるメールは「スパムメールとわかりにくく」なってきています。
特定の企業や団体、組織を狙い、ウェブ上に公開されている組織の情報を用いたり、実在する企業名や担当者を用い、メールヘッダーを偽装することで、見かけ上本物の業務メールのように見える点が特徴で、メールの内容も「お世話になっております」など一般的にビジネスで使われる文章を使い、スパムメールに気をつけていても見分けがつかないほど巧妙に作成されている場合が多くなってきました。

標的型攻撃のここから先の流れは、

  • 偽装された添付ファイルを開かせることでウイルスに感染させるパターン(主流)
  • 悪意を持ったURLへのアクセスを誘導するパターン

となってきます。

スパムメール – ばら撒き型攻撃

また「標的型攻撃」に似た手法として「ばら撒き型攻撃」という手法も存在します。
「ばら撒き型攻撃」は標的型攻撃のように特定の企業や団体を標的にしたものではなく、不特定多数のメールアドレスに向けて発信され、個人のメールアドレス宛てに届くメールでも、ウイルス感染のリスクが増えてきました。

メールのセキュリティ向上 – 送信ドメイン認証(SPF・DKIM)

このように「スパムメール」を配信する悪質な利用者は「他者に成りすます」ことで自分たちの目的を遂行します。
ではどのようにすれば、自社に成りすまされることがなく、自社の顧客を守ることができるのか?
この問いに答えるのが「送信ドメイン認証」という技術(SPF・DKIM)です。

「自社のサーバーから送信した」ことを証明する「送信ドメイン認証」(SPF・DKIM)を実装したサーバーからメールを送信することは、「自社であること」を証明します。
言い換えれば「他社の証明されていないメール」は「スパムである」ことを証明することに繋がります。

自社のドメインを「送信ドメイン認証」に対応させることにより、自社とお客様を守るという需要はますます増えきます。
顧客の信用は、自社のセキュリティ向上により守るのです。

注:今回のJTBの事案では、メールに対するセキュリティ向上だけではなく、社内のネットワークについてのセキュリティ向上も必要となってくる可能性もあります。本文が長くなりますので、本投稿ではこの内容を扱いません

【2016年度版】フィッシング対策ガイドラインが改訂

フィッシング対策協議会が「フィッシング対策ガイドライン」を改訂し、2016年度版を公開しました。

同ガイドラインは2008年より継続して提供されており、利用者におけるフィッシング詐欺対策だけではなく、サービス事業者におけるフィッシング詐欺対策として提供されて提供されている点が重要です。

本年度版の改訂ではサービス事業者におけるフィッシング詐欺対策において、被害が発生する前に心がけておくべき対策 及び 被害が発生した際の対応事項について『三段階の優先度』が設定されており、サービス利用者がフィッシングメールを判別できるようにする対策として、送信ドメイン認証技術「DMARC」についての記載が初めて追加されています。

参考リンク:
フィッシング対策協議会 → 外部リンク
フィッシング対策ガイドライン(PDF) → 外部リンク

SSLv2に含まれる脆弱性(DROWN)について

ウェブサイトを閲覧するときのお話です。
「http://~」ではなく「https://~」で始まるURLへアクセスすると、なんだか安心感がありますよね。

SSL認証の鍵マーク
SSL認証の鍵マーク

この鍵マークがあれば『サーバーとの通信が暗号化されていますよ』ということなのですが、この暗号化された通信であっても『解読される恐れがある』という脆弱性が発見されました。

あまり不安を煽りすぎるのもどうかと思うのですが、発見された脆弱性を突いて悪意のある第三者が暗号化を解読する可能性があるのは、
・HTTPSサーバーがSSLv2で接続可能な場合
・SSLv2で接続できる他のサーバーで同じ秘密鍵を使い回している場合
であり、現在のWEBサーバーの主たる設定ではありません。
※現在はSSLと表記していても、技術的後継であるTLSに移行しています。

しかしながら…
・未だHTTPSサーバーの17%でSSLv2接続を行って
おり、
・秘密鍵を使い回ししているHTTPSサーバーが16%存在
するそうです。

企業のサーバー管理者の皆様、「SSL/TLSを導入しているから安心」だと思っていませんか?
ご自分の企業のWEBサーバーはお客様へ安心できるセキュリティを提供できているでしょうか?
是非一度ご確認ください。
ご不明な場合はご相談もお承りいたします。

参考リンク:
The DROWN Attack(研究者たちが立ち上げたDROWNに関する情報ページ) → 外部リンク
全HTTPSサイトの33%でSSL/TLSが解読される恐れのある脆弱性「DROWN」、OpenSSLチームは修正パッチを配布 → 外部リンク
SSLの脆弱性で日本の大手サイトを含む全世界1100万以上のHTTPSサイトが攻撃を受け得ると判明 → 外部リンク

認証メール配信とは(送信ドメイン認証まとめ)

認証メール配信」に利用している技術、第四回は「送信ドメイン認証」についてまとめをしてみたいと思います。

このブログ第一回第二回第三回に書いてきましたとおり、送信ドメイン認証という技術は、大きく二種類に分けられます。
一つは送信元IPアドレスを根拠に、正規のサーバーから送られたかどうかを検証する技術で、
もう一つは、送られたメールの中に電子署名を挿入し、その正当性を検証する技術です。

実は前者にはSPF以外にもSender IDという技術があり、後者にはDKIM以外にDomainKeysという技術があります。
Sender IDはライセンスの自由性に問題があるため普及率が低く、DomainKeysは後継技術としてDKIMが策定されたため、普及しませんでした。

さらに、現在最も普及しているSPFとDKIMの送信ドメイン認証技術の認証結果を基に、自動でアクセスを制御したりレポーティングしたりできるようにする仕組みとしてDMARCが策定されましたが、未だ一般的に利用されている技術ではないのが実情です。

送信ドメイン認証のまとめ

【送信元IPアドレスを根拠に、正規のサーバーから送られたかどうかを検証する技術】
SPF(Sender Policy Framework) → 第一回参照
Sender ID → ライセンスの自由性に問題

【送られたメールの中に電子署名を挿入し、その正当性を検証する技術】
DomainKeys → 後継技術としてDKIM
DKIM(DomainKeys Identified Mail) → 第二回参照、第三回参照

【SPFとDKIM両方を利用する、次世代の送信ドメイン認証技術】
DMARC(Domain-based Message Authentication、Reporting & Conformance) → 2012年1月、Google・Facebook・Microsoftをはじめ15社の企業がスパムやフィッシングの脅威撲滅を目的としたワーキンググループ。未だ普及率云々というフェーズではない

『認証メール配信』はどうして迷惑メールになりにくいのか まとめ

SPFを利用し、全てのヘッダ情報においてドメインが一致しているから
・メールサーバのIPアドレスを逆引きした時に返ってくるホスト名のドメインでメールを送信するから
DKIMを利用し、電子署名には第三者署名ではなく作成者署名を用いているから

目次へ戻る

認証メール配信とは(DKIM作成者署名と第三者署名編)

認証メール配信」に利用している技術について。第三回は「DKIMの署名」についてです。

第二回 認証メール配信とは(DKIM編) でご紹介したとおり、DKIMという技術は電子署名をベースとして成す技術ですが、この電子署名、実は二つの種類が存在します。
作成者署名
第三者署名

メールのFromアドレスに記載されているメールアドレスのドメイン名で署名した場合を作成者署名といい、それ以外を第三者署名といいます。

作成者署名で電子メールを正しく認証できた場合は、間違いなくメール送信者のドメインから送信されたメールであることが確認できます。
しかし、第三者署名で電子メールを正しく認証できた場合であっても、メール送信者のドメインであることは確認できず、どのドメイン名のメールサーバから送信されたのか…であれば確認できる…という、署名の違いが存在します。

この二つの署名の違い、つまり『署名の強度』なわけですが、ASP(アプリケーションサービスプロバイダ)のサービスとしてメルマガ配信を利用するような他社のサービスの場合、サービス提供の仕様上DKIMを使用できても「第三者署名」である可能性が高く、「作成者署名」である可能性はほぼありません(このブログ記載時)。
※一部「作成者署名」を提供しておられる事業者様が居られますが、弊社のサービス提供価格とは比べ物にならない程高価な状況です。

認証メール配信サービスでは、この作成者署名を利用しており、電子メールの身元について明らかなサービスであるため、迷惑メールフォルダに送られにくいサービスであると言えます。

目次へ戻る