変貌するランサムウェア、いま何が脅威か
―2020年最新動向―

Share

データ等を不正に暗号化し、「身代金(Ransom)」を支払うよう個人や企業を脅迫・恐喝するランサムウェア。近年世界各地で猛威を振るい、日本国内での被害も複数報じられています。本記事では、そのランサムウェアをめぐる最新情報をご紹介します。なお、ランサムウェアに関する基本的情報については、「ランサムウェア その被害と対応策、もし感染したら企業経営者はどう向き合うべきか」をご参考ください。

ランサムウェア特集2021年版を公開しました!
2021年の最新動向については、「ランサムウェア最新動向2021
―2020年振り返りとともに―」をご覧ください。

ランサムウェアの現状

現在のランサムウェアは、「Ransomware-as-a-Service」(通称「RaaS」)と呼ばれる形態、すなわち、ランサムウェアそのものを提供するのではなく、サービスとして犯罪行為を提供する形態が主流となっています。また、従来のメールのばらまきやワームによる拡散のように機械的にランサムウェアをばらまく方式に加えて、攻撃者が手動で侵入し、ネットワーク内で慎重に被害範囲を拡大させて攻撃の影響を最大化する「人手によるランサムウェア攻撃(human operated ransomware attacks/campaigns)」が増えています。人手によるランサムウェア攻撃の手法には、APT(Advanced Persistent Threat:持続的標的型攻撃)との類似点が多く、APTへの対策がそのままランサムウェア攻撃への対策となりつつあるという現状があります。

また、単に身代金の支払いを要求するだけではなく、身代金を支払わなかったらデータの暴露を行うと脅すタイプのランサムウェア(とその犯行グループ)もあり、身代金を支払ったにもかかわらずデータが暴露されてしまったケースも出ています(なお、こうした犯行では、データを暴露するサイトがダークウェブに開設されています)。さらに、一部のランサムウェアはデータ破壊の機能も備えているため、以前にもましてオフラインバックアップの重要性が増しているともいえます。

身代金の額も年々上昇しており、ENISA(欧州ネットワーク情報セキュリティ庁)の2020年版年次レポートによると、2019年に支払われたと推計される身代金は100億ユーロ(約1.2兆円)を超えました。その他、各種調査機関の四半期レポートでも、2020年はさらに身代金の支払い額が増えていることが報告されています。

このような状況下においては、サイバー保険が一層重要性を増し、多くの企業ではランサムウェア等の被害からの復旧を前提として契約を行っていると考えられます。しかし、スイスの保険会社の米法人がランサムウェア攻撃をサイバー保険の免責事項にあたる戦争に該当するとして支払いを拒否したことから、現在係争中となっているケースがあり、「サイバー保険を掛けていれば大丈夫」と言い切れない点に注意が必要です。

各種ランサムウェアの概要

現在、活況を呈しているともいえるランサムウェア。2020年の時点でどのようなランサムウェアが確認されているのでしょう。主なものを以下に紹介していきます(類似の特徴を持つランサムウェアは、ランサムウェアファミリーとして、まとめて解説しています)。

REVil/Sodinokibi

<概要>
REVil、またの名をSodinokibi(またはSodin)。当初はアジア圏を中心に、現在は地域を問わず多くの被害が確認されているRaaSです。アフィリエイトプログラムも盛んで、支払われた身代金の30%~40%をアフィリエイトに支払っているとも言われ、組織的な犯行であることが知られています。2019年に活動停止を宣言したランサムウェアGandCrabのコードとの類似性が高いこと、身代金の支払いを行わなかった場合にデータの暴露を行う脅迫を行うことでも知られています。このランサムウェアファミリーの初期アクセス活動は、標的型フィッシングメールによるもののほか、リモートデスクトップサービス(RDP)やVPNゲートウェイなどの脆弱性を悪用したケースもあります。

<被害事例>
2020年1月に英・外貨両替商が被害を受け、230万米ドル(約2億5千万円)の身代金が支払われました。この事例では、脆弱性が修正されていないVPNサーバ「Pulse Connect Secure」が攻撃の足掛かりにされたことが知られています。

Nephilim/Nefilim

<概要>
このランサムウェアは、身代金の支払いと、身代金の支払いを行わなかった場合のデータ暴露という二重の脅迫を行うことで知られています。2020年6月にニュージーランドのCERTが公開した注意喚起によると、Cirtix ADCなどの脆弱性(CVE-2019-19781、2020年1月に修正プログラム公開済み)を悪用したり脆弱な認証機構を突破したりすることにより不正アクセスを行った後、Mimikatz、psexec、Cobalt Strikeなどのツールを利用して権限昇格や横展開を行って永続性を確保し、その後、このランサムウェアによるファイルの暗号化と身代金の要求が行われます。

<被害事例>
日本企業の豪子会社で2020年1月と5月の二度にわたってランサムウェアの被害が発生しましたが、そのうち5月に発生した被害がNefilimによるものであるとされています。なお1月のランサムウェア被害は、次に紹介するNetWalkerによるものでした。

NetWalker/Mailto

<概要>
主に欧米諸国とオーストラリアの企業をターゲットとしたランサムウェアで、他のランサムウェア同様に、身代金の支払いと、身代金の支払いを行わなかった場合のデータ暴露という二重の脅迫を行います。初期アクセスはRDP、標的型フィッシングメール、古いバージョンのApache TomcatやOracle WebLogic Serverへの攻撃により行われます。一方、侵入後の権限昇格にはSMBv3の脆弱性(CVE-2020-0796)などの脆弱性が用いられます。

<被害事例>
直近の事例では2020年10月にイタリアのエネルギー会社が被害を受け、1400万米ドル(約1億5千万円)の身代金を要求されたという報道があります。5TBほどのデータが暗号化されたうえ、持ち出された可能性があり、身代金を支払わない場合にはデータを暴露するという脅迫も受けています。

Ryuk/Conti

<概要>
Ryukは2019年に猛威を振るったランサムウェア、Contiは2020年に登場したランサムウェアで、類似性が指摘されています。いずれも北米での被害、それも公的機関や医療機関での被害が多い点に特徴があり、他のマルウェア(Trickbotなど)を介して侵入したのちデータの暗号化と持ち出し、身代金の要求を行います。Contiについては、身代金の支払いを拒否した組織のデータの暴露を行っており、EDRのフッキングをバイパスすることも報告されています。

<被害事例>
Contiについては2020年10月に米マサチューセッツ州とジョージア州の医療機関で被害があり、データの暴露が行われたことが確認されています。Ryukに関しては、米CISAが、医療機関での被害を受け、Trickbotおよびバックドア マルウェアであるBazarLoader/BazarBackdoorと合わせての注意喚起を行っています。

ChaCha/Maze/Sekhmet/Egregor

<概要>
ChaChaにルーツを持つランサムウェアがMazeで、SekhmetやEgregorはその亜種として位置づけられています。REVil/Sodinokibi同様にアフィリエイトモデルを採用している点に特徴があり、複数のグループが連動して動いているとされています。2020年11月、国内大手企業の被害により日本でも名を知られるようになったRagnar Lockerも、過去にアフィリエイトとして協力関係にあったといわれています。身代金の要求に加えて、支払いを拒否した場合のデータ暴露の脅迫を行う点もREVil/Sodinokibiと共通する点です。被害が発生しているのは特定の地域に限らず、世界規模と言っていいでしょう。Mazeでは、多様なエクスプロイトツールやマルウェアとの組み合わせで初期アクセスや横展開などが行われています。

<被害事例>
スイスのサイバー保険大手が2020年3月に被害を受けた事例や、2020年4月の米国の航空機メンテナンス会社の事例などが挙げられます。後者については、Mazeによるデータの窃取と公開を行ったうえで、攻撃後もターゲットのネットワーク内に潜伏し、データを摂取し続けていたことが判明しています。

その他のランサムウェア

  • Avaddon:botnetによりフィッシングメールが送信される点に特徴があるランサムウェア。RaaS。身代金要求に加えてデータ暴露の脅迫も行う。
  • CL0P:オランダの大学などが被害に遭ったランサムウェア。データ暴露のためのサイトを持っている。なおオランダの大学では身代金を支払ったことで復号鍵を入手し、データを復号化できた。
  • Dharma:侵入経路がRDPというオーソドックスなRaaS。MimikatzやLaZagneなどの追加のツールを使い、横展開する。
  • DopplePaymer:ランサムウェア「BitPaymer」をルーツに持つ。新型コロナウイルス(COVID-19)に関連したフィッシングメールを用いること、botnetやマルウェア感染させたインストーラなど多様な初期アクセスが確認されている点などが特徴。
  • Ragnar Locker:2020年11月に国内大手企業が被害を受けたランサムウェア。他のランサムウェアオペレータと協力して攻撃が行われる点に特徴がある。
  • WastedLocker:2020年7月、ウェアラブルデバイスやGPSの測位システムを提供する米企業への攻撃に用いられたランサムウェア。ロシアのサイバー犯罪組織・Evil Corpとの関連が指摘されている。

今後求められるランサムウェア対策とは

冒頭でも触れたとおり、今やランサムウェア攻撃はAPT(持続的標的型攻撃)と同様の戦術を用いるものとなっています。ランサムウェア攻撃とAPTの違いはもはや、攻撃者の最終的な目標が身代金をはじめとする金銭か、そうでないのか、という1点にしか過ぎないといえます。

「APTは国レベルのサイバー攻撃だから自分たちには関係ない」と思っていたとしたら、その認識を改める必要があります。今はランサムウェア攻撃でAPTと同じ手法が使われ、長期にわたる準備期間を経てデータを人質に取られ、身代金を要求される可能性がある―そんな時代になってしまったのです。

人手によるランサムウェア攻撃やAPTに対する対策は非常に複雑です。「今後いつ攻撃を受けることになるかわからない」という前提で、まずは自組織のシステムが攻撃者から見てどのような状態にあるか、現状を知ることが必要になります。セキュリティコンサルタントによるリスクアセスメントやペネトレーションテストによるリスクの洗い出しを行って、攻撃を受けた場合にどのような影響が起こりうるかを把握することを推奨します。

リスクアセスメントやペネトレーションテストなど今すぐには難しい、という場合は、初期アクセスに最も頻繁に用いられる標的型攻撃メールの訓練、公開Webアプリケーションの脆弱性診断、侵入された後の対策として重要なマルウェアによる横展開リスクの診断など、できることから少しずつでも手を付けていくアプローチをぜひ検討してください。

参考情報:
https://www.ipa.go.jp/security/announce/2020-ransom.html
https://www.enisa.europa.eu/publications/ransomware
https://www.ipa.go.jp/files/000084974.pdf


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

ランサムウェア その被害と対応策、もし感染したら企業経営者はどう向き合うべきか

Share

企業内のデータを勝手に暗号化して使用不能にし、元に戻すための身代金を要求するサイバー攻撃「ランサムウェア」について解説します。人命に関わる事態を引き起こした、海外のランサムウェア被害事例や、20年以上前から存在していたランサムウェアが、近年これほど多く被害が報告されるようになった理由を考え、感染経路と対策方法、注意事項をお知らせします。

ランサムウェアとは

ランサムウェアとは、PCのハードディスクやファイルサーバのデータ等を攻撃者が暗号化し、大事なデータにアクセスできないようにしたうえで、元に戻してやるからと称して「身代金(Ransom)」を支払うよう個人や企業を脅迫・恐喝するマルウェアです。

たとえば、ある日全データが使えなくなってしまったら、業務が止まって組織の存続に関わる影響が生じます。

身代金はビットコインなどの仮想通貨で要求されることがほとんどです。ただし、支払ってもデータ等が必ず元に戻るとは限りません。また、暗号化されたファイルのパスワードを解析して、自力で元に戻すことは、ほぼ不可能です。

ランサムウェア感染事例、間接的な死亡者も

2017年5月、「WannaCry(ワナクライ)」と呼ばれるランサムウェアが世界中で猛威を振るい、日本の大手企業も被害を受けたことが新聞やテレビで大きく報道されました。この報道でランサムウェアを知ったという方もいらっしゃるのではないでしょうか。

今年に入ってからもランサムウェアの被害は増え続けており、2020年7月には、スポーツ用のスマートウォッチで知られる米ガーミン社がランサムウェアの攻撃を受け、サービスが一部停止しました。

つづく2020年9月には、ドイツの病院のシステムがランサムウェアに感染、搬送予定だった患者の受け入れができなくなることで、治療が遅れ、その結果亡くなるという痛ましい事件も起こっています。

ランサムウェアの歴史と隆盛の理由

世界初と考えられている「AIDS(エイズ)」と呼ばれるランサムウェアは1989年に発見されました。それから20年以上にわたってランサムウェアは、サイバー犯罪の地味な手法のひとつに過ぎませんでした。

しかし、その後、2013年に発見された「CryptoLocker(クリプトロッカー)」のように、ビットコインなどの仮想通貨を用いることで、警察などの追跡から逃れやすくなるとともに世界中から身代金を請求できるようになるという革新が起き、グローバルで急速に蔓延するようになりました。FBIによれば、2013年10月1日~2019年11月7日のおよそ6年間でビットコインだけで約1億4400万アメリカドルが身代金として支払われるなど、大きな被害を生んでいるのです。

ランサムウェアの新しい傾向「暴露型」「破壊型」とは?

従来はファイルを暗号化して身代金を要求するだけだったランサムウェアですが、新しい傾向として「暴露型」と「破壊型」と呼ばれる類型のものが出てきています。

「暴露型」のランサムウェア攻撃とは、暗号化する前にデータを盗み出し、身代金に加え、企業の機密情報をインターネットに公開するぞと、二重に脅迫を行う新しい手法です。

また、「ランサム(身代金)ウェア」とは、そもそも「お金を払えばデータは元に戻る」という想定のもとに成り立つ犯罪ですが、近年、その想定を外れる、「破壊型」などと呼ばれるランサムウェア攻撃の例も報告されています。

「破壊型」は、システムやビジネス、施設等にダメージを与えることを目的としてデータの暗号化を行うもので、内閣サイバーセキュリティセンターが2018年に公開した資料では、こうしたランサムウェアは「機微な情報や重要な社会インフラ等を取り扱う組織にとって(中略)機能停止を引き起こす別次元の攻撃となり得る」と言及されています。

ランサムウェアだから身代金を支払えば済むと思っていたら、ファイルを暴露されたり、システムを破壊されたり・・・そんなケースが起こりうるのです。

ランサムウェアの感染経路

ランサムウェアは、すでに感染したUSBメモリやCD-ROMなどの可搬媒体の使用によって感染することもありますが、最も注意すべき感染経路は、電子メールとWeb閲覧のふたつ、つまり、電子メールに含まれた悪意ある添付ファイルを開くことと、本文中のURLをクリックすることによる感染です。

中でも知っておきたいのが、マルウェアを介してランサムウェアに感染するというケースです。たとえば、「Emotet(エモテット)」に感染したとしましょう。Emotet自体はランサムウェアではなくマルウェアで、ご存じの通りメールアカウントの乗っ取りや、過去のメールデータを盗み出すことで知られています。しかしEmotetはこれ以外に、「Trickbot(トリックボット)」「Qbot(キューボット)」などのトロイの木馬ウイルスをダウンロードすることでも知られています。

それらをダウンロードした後どうなるかというと、たとえばTrickbotであれば、Trickbot自体のランサムウェアとしての機能があり、その機能を使ったランサムウェア攻撃を行うことがあります。また、Trickbotは他のランサムウェア、たとえば「Ryuk(リューク)」「Conti(コンティ)」などを追加でダウンロードしたうえでランサムウェア攻撃を実行することもあります。

このように、1つのマルウェアに感染することで様々なランサムウェアに感染する可能性があり、攻撃のパターンも複数あるということを認識しておく必要があります。

EDR、SIEM、標的型攻撃メール訓練がランサムウェア対策に有効

ランサムウェアの対策として、EDR(Endpoint Detection and Response)やSIEM(Security Information and Event Management)製品を活用して、早期検知とブロックを行う方法がよく知られていますが、最大の感染経路のひとつである「メール」を対象にした訓練を行うことも有効でしょう。

ランサムウェア対策のメール訓練としては、「定型のメールを一斉送信し、部署毎に開封率のレポートを出す」ことに加え、事前に会社の組織図や業務手順等のヒアリングを行ったうえで、よりクリックされやすいカスタマイズした攻撃メールを作成し、添付ファイルや危険なURLをクリックすることで最終的にどんな知財や資産に対してどんな被害が発生するか、具体的なリスク予測までを実施することをおすすめします。

セキュリティ企業のサービスを検討する際は、こうした対応が行えるかどうかを選定の条件にするとよいでしょう。さらに、ひとたび社内に入り込んだマルウェアやランサムウェアがどのように感染拡大する可能性があるかを診断するサービスを利用することも、対策を立てるうえでの選択肢として考慮すべきでしょう。

以前、不正アクセスに関する記事の解説で、「かかりつけ医」ならぬ「かかりつけセキュリティ企業」を持つことの、有事の際の心強さをご説明しましたが、こうしたサービスの利用をきっかけとして、信頼できるセキュリティ企業を見つけるのもいいかもしれません。

なお、ブロードバンドセキュリティでは、標的型メール訓練、標的型攻撃リスク診断「SQAT®APT」ほか、多彩なラインナップで、ランサムウェア対策への取り組みをご支援しています。

感染したときのための無料復号ツール

ランサムウェアで暗号化されたデータを復号する無料ツールが、インターネットにいくつも公開されています。欧州刑事警察機構(ユーロポール)やセキュリティ企業による共同プロジェクト「No More Ransom」によるものなどが有名です。

こうしたツールを使用してデータ復旧を試みることはもちろん可能です。しかし、そのデータが企業にとって重要であればあるほど、デジタルフォレンジックを行う専門企業の支援を受けるのが最善の対応であると、SQAT.jpは考えます。

セキュリティインシデント対応の経験がない技術者がランサムウェアの対応をするのは、全く得策ではありません。その理由は、証拠保全ができなくなり説明責任を果たせなくなる可能性があること、感染経路がわからなくなることで対策が打てなくなり、その結果、企業として自信を持って終息宣言を出せなくなることなど、いくつか挙げられます。

また、もし暴露型のランサムウェア攻撃の場合、データが暴露されることで被害を受けるステークホルダーは、グループ会社や取引先など多岐にわたり、もはや自社だけの問題ではなくなります。そもそも暴露型であることなど、攻撃の初期段階ではわからないのです。

ランサムウェアの身代金を支払うとマネーロンダリングの犯罪に?

なんらかの理由で攻撃者に対して身代金を支払うという決定を組織が行った場合、たとえばアメリカ合衆国財務省はランサムウェアへの身代金支払いをマネーロンダリングの一種、すなわち違法行為とみなすことがあり、事前に米財務省への申請が必要になる場合があることをご存じでしょうか。支払いのためのアドバイザリーが公開されていますので、外資系企業や米国子会社のある企業は注意しましょう。

また、たとえ日本企業であっても、反社会的勢力に対して金銭を供与するという事実は何ら変わりません。事前の充分な法的配慮が必要となることは言うまでもないでしょう。

なお、支払っても元に戻るとは限らないことをここで再度申し上げておきます。

まとめ

  • ランサムウェアとは大事なデータを暗号化して元に戻す際に身代金(Ransom)として、お金の支払いを要求するマルウェアのことです。
  • 世界中でランサムウェアの被害が報告されており、ドイツの病院のランサムウェア攻撃事例では死者が出ています。
  • 身代金支払いにビットコインなどの仮想通貨を用いるなど、ランサムウェアは進化し、世界中で大流行するようになりました。
  • データを暗号化するだけでなく、データを盗み出してインターネットに公開する「暴露型」など、新しいランサムウェア攻撃の事例も報告されています。
  • ランサムウェアの主な感染経路のひとつがメールであるため、ランサムウェア対策には、EDR、SIEMに加え、標的型攻撃メール訓練が有効です。
  • アメリカではランサムウェアの身代金を支払うと、マネーロンダリングに加担したとみなされることがあるので、注意が必要です。

まずは無料で資料をダウンロード

SQAT®APTの詳しいサービス内容が記載されている資料がダウンロードできるURLをお送りいたします。
見積もりについてのご相談は、お問い合わせよりご連絡ください。


年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。




Share

クラウドとテレワーク時代、企業に二要素認証・多要素認証の利用が求められる理由

Share

二要素認証とは、IDとパスワードだけでなく、パスワードに加えてトークンや指紋など、計2つの要素を用いて本人確認を行うことです。今回の記事では、認証に用いられる3つの要素に触れながら、「多要素認証」「二段階認証」との違い、実際の使用例、アメリカ国立標準技術研究所(NIST)の認証に関するガイドラインなどを解説し、企業がこうした認証方式をどのような場合に用いるべきかを提案します。

二要素認証とは

インターネットにおける「認証」とは、たとえば、あるWebサービス等を利用しようとしているユーザが、本当にその本人であるか、その正しさを確認するプロセスや行為のことです。「二要素認証」とは、セキュリティ水準を高めるために、ふたつの要素を用いて認証を行うことです。

「KNOW」「HAVE」「ARE」、認証に用いる3要素とは

「要素」とは、認証に用いる情報等のことです。たとえば、あるWebサービスの利用時、IDとパスワードの入力が求められるのであれば、それは「IDを持つ人がこの人であるかどうかを確認するためにパスワードという要素が用いられている」ということになります。

要素には、パスワードのような「ユーザが知っていること(something you know」、部屋のカギのような「ユーザが所持しているもの(something you have」、指紋や虹彩(眼球の瞳の周辺にある膜)のような「ユーザ自身であるもの(something you are」などがあり、このうちどれかふたつの要素を用いて認証を行うことを二要素認証と呼びます。

二要素認証を行えば、従来のようなパスワードだけを用いた認証よりも、セキュリティ水準を高めることができます。

「二要素認証」と「二段階認証」「多要素認証」の違い

過去に日本国内で普及していた認証方法に「二段階認証」があります。これは、パスワード入力の後に「秘密の質問」などを設けて、ユーザが知っていることを用いてもう一回認証を行い、セキュリティを高めようとするものです。

「多要素認証」とは、「ユーザが知っていること(something you know)」「ユーザが所持しているもの(something you have)」「ユーザ自身であるもの(something you are)」のうち、ふたつ以上の要素を用いて認証を行うことで、二要素認証は多要素認証に含まれます。

なお、多要素認証は英語では「MFA(Multi-Factor Authentication)」と表記され、2つの要素を用いる場合に「Two-Factor Authentication」という呼称が使われることがあります。

よくある「秘密の質問」は、セキュリティ的にはどうなのか

余談になりますが、「秘密の質問」を用いるタイプの二段階認証は、2020年現在、ユーザの認証手段に常時使われることは望ましくない、というのが多くの専門家の認識となっており、多要素認証が利用できない場合の非常代替手段として、またはアカウントの回復に用いる認証の一部として、限定的に用いられることが望ましいとされています。

もし秘密の質問を使う場合には、「(何年たっても思い出せる程度に)記憶できる」「(何年間も答えが変わらず)一貫性がある」「(どんなユーザでも)回答可能である」「(攻撃者が答えを知ることがない程度に)機密性が高い」「(どのユーザでもわかるように)明確である」という5つの条件を満たすことが望まれます(*)

基準となるNISTのガイドライン

アメリカ国立標準技術研究所(NIST)が公開しているガイドライン「SP 800-63」(最新版は2017年公開の第三版「SP 800-63-3」)は、オンラインで行われる認証に関して最も参照されるドキュメントのひとつです。

同書は、NISTが考える「電子認証はこうあるべき」を記載したもので、「SP 800-63A」「SP 800-63B」「SP 800-63C」から構成されています。

SP 800-63Aでは認証やIDの管理全般について記述し、SP 800-63Bはトークン等の認証器の仕様として「AAL1」「AAL2」「AAL3」の三種類を定め、SP 800-63Cではフェデレーション認証について記述しています。

日本の経済産業省の規格も「SP 800-63-3」を参照して作られています。

LINE、Google、Facebook、Slack ~ 二要素認証・多要素認証を使用した具体例

すでに、LINEやGoogle、Facebook、LinkedIn、Slackなどの大手ITサービスでは、二要素認証・多要素認証が利用されています。スマートフォンやメールアドレス宛にパスコードを送る、「Authenticator」と呼ばれる認証用アプリにパスコードなどを表示させるなど、方法もさまざまです。

以前「ブルートフォース攻撃」に関する記事で解説したとおり、サイバー攻撃の激化・高度化にともなって、パスワードだけで認証する時代はもう終わりを迎えています。今後、二要素認証・多要素認証は上記に挙げた大規模なサービスにとどまらず、企業内でも積極的に活用されていくことでしょう。では、どんな場面でこれを用いればいいのでしょうか。

「企業が二要素認証・多要素認証を使うべき」2つのシナリオとは

SQAT.jpでは、「セキュリティのレベルが異なる領域間でのアクセスや通信」に対して、二要素認証・多要素認証を使うことをおすすめしています。

具体的な例を挙げると、「クラウドサービスを利用するために、社外のクラウドサービスのアカウントに社内からアクセスするとき」、そして、「テレワーク等の実施のために、社外からイントラネットなど社内にアクセスするとき」のふたつです。

特に、社外からイントラネットなど社内にアクセスするときは、トークンを使った多要素認証を用いたVPN接続をおすすめします。

なお、SNSやメールサービスなどのSaaSで、ユーザ本人のアクセスであることを確認する必要性が高いサービスなどでも、多要素認証が用いられることが多いといえます。社内からこうしたサービスにアクセスしている場合、当該サービスが多要素認証を適用しているか、適用できるような設定になっているかも確認してみてはどうでしょう。

クラウドサービス利用時はアイデンティティアクセス管理等、認証まわりに注意

SQAT.jpを運営する株式会社ブロードバンドセキュリティでは、主要クラウド(IaaS)を対象としたセキュリティ診断サービスも提供していますが、診断の結果リスクを指摘される事項の大半が、認証に関わる問題です。クラウドサービスを、つい「オンプレミス環境の延長」あるいは「オンプレミス環境と同じ」と考えてしまうことで、誤った設定がなされてしまうことがあるようです。詳細は、「診断結果にみるクラウドセキュリティの今」で詳しく解説していますので、ぜひご覧ください。

まとめ

  • 二要素認証とは、「KNOW」「HAVE」「ARE」という3つの認証要素の中の2つを用いて認証を行うことです。
  • 二要素認証は多要素認証に含まれます。
  • 二要素認証・多要素認証を行うことでセキュリティ強度を高めることができます。LINE、Google、Facebookなど多くのサービスでこの認証方式が使われています。
  • NISTが公開したガイドライン「SP 800-63-3」は認証に関して世界で最も参照されるドキュメントのひとつです。
  • セキュリティのレベルが異なる領域間でのアクセスや通信には、二要素認証・多要素認証を使うことをおすすめします。
  • クラウドサービスを利用する場合は、認証関係の設定ミスに注意しましょう。

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

クロスサイトリクエストフォージェリ(CSRF)はサイバー攻撃の「名脇役」?
脆弱性診断におけるCSRFの検出頻度と対策

Share

今回は、XSSのような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について解説します。

CSRFが脆弱性診断の現場で検出される頻度や、見つかった際に行うべき対応、そもそもCSRFの脆弱性をアプリケーションに作り込まないための予防策、また、脆弱性を放置するとGoogle Chromeなどの主要ブラウザでWebサイトを閲覧できなくなることなどを説明します。

CSRFとは

Webアプリケーションの脆弱性のひとつであるCSRFは、「Cross Site Request Forgery(クロスサイトリクエストフォージェリ)」の略称です。読み方は「シーサーフ」です。英語で「Cross」は「X」と表記することがあるため、CSRFを「XSRF」と表記することもあります。

「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFは、攻撃者が罠として用意した偽造サイトを用いて、ユーザが意図していないリクエストを強制的に行わせるサイバー攻撃です。

CSRFとXSSの違い

クロスサイトリクエストフォージェリと似た名前の脆弱性に「クロスサイトスクリプティング(XSS:Cross Site Scripting)」があります。どちらもサイトを横断(Cross Site)してサイバー攻撃が行われる点が共通していますが、それ以外は何ら同じところはない別物で、発見される頻度や攻撃による影響、対策方法は異なります。

脆弱性診断の現場でCSRFはどのぐらい発見されるか

あなたがいまご覧になっているサイト「SQAT.jp」を運営する株式会社ブロードバンドセキュリティでは、日々、さまざまなお客様のシステムに対して脆弱性診断を行っています。

ブロードバンドセキュリティが2020年上半期に総数4,596のシステムに対して行った脆弱性診断の結果、CSRFを含む「セッション管理関連の脆弱性」は17%のシステムで検出され、その中にCSRFは12%含まれていました。つまりCSRFの脆弱性が存在したシステムは17%×12%、全体の約2%になります。ここで2%という数字をどうとらえたらよいのか、このあと、CSRFの攻撃例やリスクを紹介しながら考えていきます。

CSRFによる攻撃と被害例

CSRFの脆弱性を悪用した攻撃事例としては、掲示板等に本人が全く意図していない書き込みをさせた例(「遠隔操作ウイルス事件」や「はまちちゃん事件」が有名)があります。

もしCSRFが脆弱性診断で見つかったら、すぐに対応が必要な場合もあります。特に、個人情報の登録や変更などに関わるログイン後のページで発見された場合は、すぐに修正を行わなければなりません。

意図しない掲示板の書き込み以外にも、CSRFの脆弱性を悪用すれば、たとえば「サイトAにログインして会員登録を行っているつもりが、実際には攻撃者が罠として用意したサイトBにログインしており、そこで個人情報を抜き取られる」ような攻撃が行われる危険性もあります。もしそうなれば、サイト運営者としての責任が厳しく問われることは間違いありません。

対策を怠ると他サイトへの遷移ができなくなる可能性も

また、主要なWebブラウザは、XSSやCSRFなどからの保護のために、脆弱性のあるWebサイトをブラウザに表示させない仕様を整えつつあります。たとえばGoogle Chromeは、Chrome 80以降、サイトを越えてCookie情報をやり取りするためのSameSite属性に対して制限を加え、CSRFを防御可能な設定値のみを許容する方向へと段階的に進んでいます*1 。CSRFを防御可能な設定値については他の主要ブラウザも同様の方向に進んでおり、Webアプリケーション開発においてCSRF対策は(他の対策とともに)取らないわけにはいかないものの一つとなりつつあります。

セキュリティ企業が見るCSRFのリスクとは

なお、わたしたちセキュリティ診断サービス会社にとってCSRFとは、一定頻度で検出されるものの、CSRF単体ではそれほどリスクは大きくない脆弱性です。事実、CSRFだけを使った攻撃事例はあまり多くないのです。

CSRFで注意すべきは、他のサイバー攻撃手法と組み合わされることでリスクや被害が大きくなることです。

たとえば「セッションフィクセーション」と呼ばれるセッションIDを強制・固定化する攻撃と、CSRFの脆弱性を悪用した攻撃を組み合わせることで、「セッションハイジャック」と呼ばれるサイバー攻撃が成立すれば、セッションの乗っ取りが行われ、オンラインバンキングでの不正送金などにつながる可能性があります。

CSRFのリスクは低い? 高い?

CSRFだけを考えてしまうとリスクはそれほど高くないため、対応は後回しにされがちです。しかし実際のサイバー攻撃はそう単純ではなく、いくつもの方法が複合されて行われます。「見つかったらすぐに対応が必要な脆弱性のひとつ」とわたしたちが考える理由がそこにあります。

CSRFは、単体では攻撃者にとってそれほど使い勝手の良い脆弱性ではありません。しかし、CSRFはいわば、自身では主役は張れないものの、サイバー攻撃の主役を引き立てるために機能する、名脇役のような脆弱性と言えるかもしれません。

CSRFの対策とトークンによる保護

CSRFの脆弱性を悪用した攻撃で最も警戒すべきはログインしたユーザをターゲットとした攻撃になります。この場合、ログインしたユーザからの正しいリクエストであることを証明するために、「トークン」と呼ばれる推測困難な文字列を使って確認を行うことや再度の認証を行うこと*2などで攻撃を防ぐことができます。

事実、PHP、Java、ASP.NET等の開発言語で提供されている、Webアプリケーションフレームワーク(Laravel、Spring等)は、CSRFの脆弱性を悪用した攻撃を防ぐために、ユニークなトークンを発行する仕組みを持つようになっています。しかし、それでもなおCSRFの脆弱性が見つかることがあるのです。これはどうしてでしょう。

なぜCSRF攻撃対策のトークンは発行されないのか

開発フレームワークがトークンを発行する機能を持っているのにWebアプリケーションでCSRFの脆弱性が発見される理由は、単純そのもので「そもそもトークンを発行するための1行がかかれていない」*3から、ということが多いのです。「機能があるから大丈夫だろう」という思い込みが思わぬリスクを招きます。

前半で、ブロードバンドセキュリティが行った脆弱性診断の結果、約2%でCSRFの脆弱性が検出されたとお伝えしましたが、リスクを知り、適切な対策を確実に実装することで、この数字をもっと少なくすることができるでしょう。

まとめ

  • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
  • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
  • もし、個人情報の登録などに関わるログイン後のページでCSRFの脆弱性が発見された場合、すぐに修正する必要があります。
  • Google Chromeほかの主要ブラウザでは近年、CSRFの対策に有効とされる制限を開始しています。対応しない場合にはWebサイトがブラウザに表示されなくなる可能性もあります。
  • CSRFは他のさまざまなサイバー攻撃と組み合わされて利用されることが多いので、たとえCSRF単体のリスクが低くても確実に対策を行うことが重要です。

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Share

診断結果にみるクラウドセキュリティの今

Share

弊社では現在、Amazon Web Services(以下AWS)、Microsoft Azure(以下Azure)、Google Cloud Platform(以下GCP)の主要三クラウドを対象とした「クラウドセキュリティ設定診断サービス」をご提供しています。本記事では、弊社の視点で、診断を行う中でみえてきた、クラウドセキュリティの今をお伝えします。

クラウドをめぐるトレンド

昨今、クラウド関連では新しいキーワードが続々と登場しています。例えば、皆様も以下のような言葉を耳にしたことがあるのではないでしょうか。

  • ゼロトラストアーキテクチャ
  • SDP(Software Defined Perimeter)
  • IDaaS(Identity as a Service)
  • コンテナ・マイクロサービス

「ゼロトラストアーキテクチャ」「SDP」は、クラウドを含む企業インフラの在り方を変える仕組み、「IDaaS」は多くのIT関係者の頭痛の種である認証機構をクラウドで実現する新しいサービス、「コンテナ・マイクロサービス」は、開発や運用を効率化するクラウド技術であり、いずれも、しばしば「革新的」「画期的」といった形容詞と共に語られます。しかし、「革新的」「画期的」なものを取り入れさえすれば、クラウドのセキュリティは担保されるのでしょうか。

診断結果からみえてくるもの

弊社ではAWS、Azure、GCPというIaaSを対象としたクラウドセキュリティ設定診断サービスをご提供しています。診断で検出されることが多い問題は、表 1のとおりです。

表1 弊社のクラウドセキュリティ設定診断で多く検出される問題

ID/アクセス管理(IAM)に関する問題
  • 利用されていない認証情報が存在する
  • 長期間ローテーションされていないキーが存在する
  • MFA(多要素認証)が有効化されていない
  • パスワードポリシーが基準を満たしていない
  • セキュリティキーの適用が有効になっていない管理者アカウントが存在する
  • ロギングに関する問題
  • 必要なログが記録される設定になっていない
  • ログが適切に暗号化されていない
  • モニタリングに関する問題
  • ログメトリックフィルタとアラート/アラームが存在しない
  • ネットワーク通信に関する問題
  • SSHやリモートデスクトップサービス(RDS)へのアクセスが制限されていない
  • その他
  • 推奨される暗号化が施されていない
  • OS Loginがプロジェクトで有効になっていない
  • 均一なバケットレベルでのアクセスが有効になっていない
  • 特に目立つのは、ID/アクセス管理(以下IAM)の設定周りの不備です。IAMはクラウドのセキュリティにおける最重要事項であり、この領域でさまざまな問題が検出されているという結果は、危機感を抱くべき状況といえます。

    例えば、「パスワードポリシーが基準を満たしていない」、「長期間ローテーションされていないキーが存在する」、「MFAが有効化されていない」(仮想MFAのみ有効である場合も含む)といった問題は、従来のオンプレミス環境での運用水準を前提とした設定・運用を、クラウド環境に対してもそのまま適用していることが原因ではないかと推測されます。また、「利用されていない認証情報が存在する」のは、異動した社員や退職者の認証情報が削除されずに放置されているためと推測されますが、もし、「ひょっとしたら」「うちの会社も」と感じられるようでしたら、早急に確認することをおすすめします。

    ロギングやモニタリングに関する問題も目を引きます。まず、本番環境において適切なロギングやモニタリングが行われていない場合、対象の環境に何らかの問題が起きた時になすすべもない状況に陥る可能性があります。また、開発環境やステージング環境については、ロギングやモニタリングが無効になっている場合、そのことが問題発生時の原因究明を阻害する要因になりえます。開発環境やステージング環境で意図的にロギングやモニタリングを無効にしている場合は、そのようなリスクがあることを認識し、適宜対応の見直しを検討する必要があります。もちろん、その前提として、本番環境とステージング・開発環境が厳密に分けられていて、アクセスや認可がしっかり設定されていることが必要です。

    さらに、ネットワーク通信に関しては、「SSHやリモートデスクトップサービス(RDS)へのアクセスが制限されていない」という問題が検出されています。これについては、Shodanなどで各ポートを開放しているサーバを検索するとクラウドサービスのFQDNを表示するサーバ多数がクエリを返してくる、という状況があり、そのことをご存知の方であれば、「ああやはり」という感想をお持ちになるのではないでしょうか。クラウドでもオンプレミス環境同様、SSHやRDSへのアクセスを制限しないことは攻撃者に初動の足掛かりを与えることにつながります。制限を掛けることが必須であるはずなのに、案外そうなっていないケースがみられる、というのが、診断結果における現状です。

    いずれの問題についても、「うっかり」も含め、クラウド環境での基本的なセキュリティ設定への対応が十分に行われていないことを示す結果になっているといえます。

    実際のインシデント・事件ではどうだったか

    では、実際のインシデントではどのような対応不備が確認されているのか、クラウドコンピューティングのセキュリティに取り組む国際的非営利団体「クラウドセキュリティアライアンス」(以下CSA)が本年9月に公開したケーススタディ分析「Top Threats to Cloud Computing: Egregious Eleven Deep Dive」から見てみましょう。

    同資料では、近年発生したクラウド上での大規模セキュリティインシデントの中から9件を取り上げ、CCM(Cloud Control Matrix)というフレームワークを用いて分析しています。なお、CCMは、クラウドサービスに必要な管理策・統制とその実装方法の提示を行うフレームワークとして、情報セキュリティとITガバナンスの観点から対処すべき点に関する指針をまとめたものです。同フレームワークに基づく指摘項目数をインシデントごとに集計したものが表 2となります。

    表 2 ケーススタディ事例に対するCCMコントロールドメイン別の指摘項目数

    9件中8件で指摘されたのが、まず、弊社のクラウドセキュリティ設定診断結果でも顕著であった「IAM」、そして「SEF」(セキュリティインシデント管理、Eディスカバリ、クラウドフォレンジックス)関連の不備でした。また、インシデントの過半数において、「TVM」(脅威と脆弱性の管理)、「HRS」(人事)、「IVS」(インフラと仮想化のセキュリティ)、「CCC」(変更管理と構成管理)の問題が指摘されています。

    先ほど述べたとおり、CCMは情報セキュリティに加えてITガバナンスの観点を含むフレームワークであり、弊社がセキュリティ診断で用いている指標との間に直接の互換性はありません。しかしながら、例えば、「利用されていない認証情報が存在する」問題は前述の「IAM」に加えて「HRS」に、ロギングやモニタリングの問題は「IVS」に関連付けられます。また、「TVM」は弊社の脆弱性診断と共通の目的を持つものです。その意味で、セキュリティ面での課題を解消・改善する取り組みは、確実にインシデントの発生抑制に寄与するといえるでしょう。

    新しいキーワードに目を向ける前に

    クラウドサービスの急速な普及が進む中、セキュリティ対策が不十分な状態で導入に踏み切り、セキュリティ事故を引き起こす組織が後を絶ちません。背景には、従来のオンプレミス環境で「外からアクセスされるわけではないから今まで通りでもまあいいか」と設定や運用をなおざりにしてきた「うっかり」を許し、設定ミスを防げなかった、等さまざまな状況があると考えられます。ID/アクセス管理といった基本的な対応の不備が目立つのもその表れでしょう。

    クラウドは今まさに旬のテクノロジーであり、冒頭に紹介したような新しいキーワードは、今後も次々に登場するものと思われます。キーワードを考慮して新たな戦略を練る前に、利用するクラウドサービスの基本的なセキュリティ設定はできているかを確認することが大切です。例えば、「ゼロトラストアーキテクチャ」を本気で適用しようとした場合、もしIAMの設定に不備があったとしたらどうでしょう。ゼロトラストアーキテクチャに求められる厳格な認証・認可の運用に致命的な問題を引き起こしかねません。新しいものに目を向ける前に、足元を見直す。弊社は診断サービスを通じてこれを支援していきたいと考えています。

    まずは無料で資料をダウンロード

    クラウドセキュリティ設定診断サービスの詳しい内容が記載されている資料がダウンロードできるURLをお送りいたします。
    見積もりについてのご相談は、お問い合わせよりご連絡ください。


    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Share

    ブルートフォース攻撃 ~ IDとパスワードだけのセキュリティはもうオワコン?

    Share

    ブルートフォース攻撃とは、不正アクセスを行うために、パスワードを総当たりで試すことです。今回は、辞書攻撃やパスワードスプレー攻撃など、さまざまなパスワードへの攻撃を紹介しながら、ユーザと管理者が行うべき対策、そして最新のWebアプリケーションの検証基準であるOWASP ASVS 4.0にも記載のある多要素認証やリスクベース認証を説明し、これからのアカウント保護について考えます。

    ブルートフォース攻撃とは

    ブルートフォース(Brute Force)とは「力任せ」という意味です。サイバーセキュリティの用語「ブルートフォース攻撃(Brute Force Attack)」とは、パスワードに対する攻撃のことを表し、たとえば数字四桁のパスワードなら「0000」からはじまり「0001」「0002」「0003」…と順に「9999」まで試すことで、いつかは正しいパスワードを確実に探し当てることができる、まさに力づくの攻撃手法です。

    知識が不要で、誰でもできる難易度が低い攻撃です。ブルートフォース攻撃を行うためのツールが出回っている点も難易度を引き下げる要因となっています。

    辞書、パスワードリスト、リバースブルートフォース、パスワードスプレー…、パスワードを破るサイバー攻撃の手法は多種多様

    IDとパスワードだけでログインできるシステムの場合、そのふたつさえ明らかになれば不正アクセスが成立します。そのため、不正アクセスのためにパスワードを破る攻撃は多種多様な工夫が行われ、進化を遂げています。いくつか代表的なパスワード破りの攻撃を紹介しましょう。

    ・辞書攻撃
    全く意味のない文字列を暗記するのは難しいため、多くの場合人間は意味のある言葉をパスワードに用います。辞書攻撃は、一般的な単語やあるいはよくパスワードに使われる言葉(「123456」「qweryty」「password」etc.)を試していく攻撃方法です。ブルートフォース攻撃よりも時間がかかりません。

    ・パスワードリスト攻撃
    たとえば同一のメールアドレスで、A、B、C三つのWebサービスに登録しており、WebサービスAの情報漏えいによってIDとパスワードのリストが流出した場合、パスワードを使い回していた場合、サービスBとCにも不正アクセスされてしまう可能性があります。すべてのサービスでパスワードを別々に管理することが難しい点を突いた攻撃です。

    ・リバースブルートフォース攻撃
    ブルートフォースと「逆(リバース)」の攻撃、つまり「123456」や「password」など、非常にしばしば用いられる文字列にパスワードの方を固定して、IDをさまざまなメールアドレス等に変えてログインを試みます。

    ・パスワードスプレー攻撃
    パスワードスプレー攻撃はよく使われるパスワードを大量のアカウントへのログインに試す攻撃で、一種の辞書攻撃ともいえます。一般的にほとんどのWebサービスや各種の認証機構は現在、パスワード入力を何度か間違えるとロックされて一定時間操作ができなくなる、同一IPアドレスからの接続を遮断するというブルートフォース攻撃への対策が取られています。しかし、パスワードスプレー攻撃は、大量のアカウントに対してロックされない最大の回数のパスワード試行を、時間をおいて、ときには数ヶ月もの期間、「low-and-slow」ともいわれる方法でくりかえし行うことで、一般的なブルートフォース攻撃対策を潜り抜ける点に特徴があります。

    診断会社がブルートフォース攻撃を業務として行うとき

    SQAT.jpを運営する株式会社ブロードバンドセキュリティは、セキュリティ診断サービスを提供しており、お客様からのご希望に基づき、オプションとしてパスワードへの模擬攻撃を行うことがあります。たとえば、認証系の攻撃テストの項目のひとつに疑似ブルートフォース攻撃が含まれていたりします。

    ブルートフォースや辞書攻撃はパスワード解析ツールなどを稼働させて診断を行いますが、PCの負荷が高くなるため、診断を行う技術者はその作業中、PCで別の作業がほとんどできなくなったりすることがあります。

    なお、こうしたセキュリティ診断業務としてのブルートフォース攻撃等は、すべてお客様からの依頼に基づいて、事前にヒアリングを行い、書面で契約を締結して実施されます。一般の方が、ネットで見つけたパスワード解析ツールを企業のWebサイトなどに対して勝手に使用したりすると、即「不正アクセス行為の禁止等に関する法律」に抵触する犯罪となることをここに記載しておきます。

    パスワードの黄昏、IDとパスワードのみの認証はもうオワコン?

    これまでのセキュリティに関する記事や読み物ならば、このあたりで、ユーザ向けなら「強いパスワードを作る方法」「サービス毎の別々のパスワード管理」等を紹介し、システム管理者向けなら「パスワードを流出させない対策」「万が一事故が起こったときのためのパスワードのハッシュ化とソルトによる不可逆暗号化」などを提案して終わりにしたことだと思います。

    しかし本稿執筆の2020年の今、それだけで十分ではないのでは?とわたしたちは考えます。

    どんなに強いパスワードを設定していても、ハッシュ値で保護していても、「レインボーテーブル」と呼ばれるハッシュ化されたパスワードの解析ツールを用いてしまえばパスワードが解析されてしまいます。もちろんパスワードのハッシュ化に加えてソルトやストレッチといった方法でさらに保護することも必要ですが、ソルト、ストレッチが複雑化・多重化されていなければハッシュ同様に解析されてしまう可能性も否定できません。

    さらに、パスワードリスト攻撃に使われるIDとパスワードのセットは、大手サービスの情報漏えいなどで流出したデータ等が用いられますが、これらはアンダーグラウンド市場などで、数億件のIDとパスワードのセットを低価格で購入することができますし、一定の方法で検索するとネットに落ちていることすらあります。

    パスワードだけで認証する時代はもう終わったと捉えるべき時期に来ています。パスワードの適切な管理の重要性は今後もまったく変わりませんが、それだけでなんとかなった時代にはもう戻れないのです。

    認証のセキュリティ対策に求められる要件は?Webセキュリティの国際検証基準「OWASP ASVS 4.0」

    Webアプリケーションセキュリティに関する国際的コミュニティOWASP(Open Web Application Security Project)は、アプリケーションの設計や開発、脆弱性診断などにおいて必要となるセキュリティ要件の検証基準としてASVS(Application Security Verification Standard)を公開しています。最新版のOWASP ASVS v4.0 では、従来に比べて認証に関する記載がいっそう細かくなっています。

    いわく「パスワードの長さを12文字以上にしなさい」「将来パスフレーズに利用できるようUnicodeを受け入れなさい」「ブルートフォースのような認証系攻撃のためにレート制限などの対策をしなさい」等々。そのなかでも目を引くのは、多要素認証とリスクベース認証の推奨です。

    多要素認証とリスクベース認証~ひとつの方法でアカウントを守る時代の終わり

    多要素認証とは、ワンタイムパスワードなどに代表されるトークンや、指紋や虹彩等の生体認証など、IDとパスワードに代表される「あなたが知っているもの」以外の複数の要素(「あなたが持っているもの」「あなた自身の何か」)を用いて行う認証方法のことで、オンラインバンキングや、LINEやGmail等のサービスで使ったことがある読者もいるかもしれません。

    リスクベース認証は、ログインを試みようとしている時刻やIPアドレス、ブラウザなどの情報を元に、そのユーザの通常の行動と照らし合わせて、いつもと異なっていたら、追加の要素による認証を求め確実な本人確認を行う方法です。新しいパソコンを購入した直後に、いつもはIDとパスワードだけでログインできていたサービスが、ショートメッセージでスマホに送られたパスコードの入力を求めるといった事象に遭遇したことがあると思いますが、それがリスクベースの認証の一例になります。

    くり返しますが、これからは、ひとつの手段でアカウントを守るのではなく、複数の手段でアカウントを守ることが普通になります。

    まとめ

    • ブルートフォース攻撃とは総当たりでパスワードを破ろうとするサイバー攻撃で、難易度が低く攻撃ツールも出回っています。
    • 不正アクセスのためにパスワードリスト攻撃やリバースブルートフォース攻撃など、パスワードを破る攻撃は多様な進化を遂げてきました。
    • 強いパスワードの設定、パスワードのハッシュ化とソルトによる不可逆暗号化などはとても大事ですが、それだけでアカウントを守ることは難しい時代になっています。
    • OWASP ASVSの最新版であるv4.0は、多要素認証とリスクベース認証を推奨しています。
    • 多要素認証やリスクベース認証など、これからは複数の手段でアカウントを守ることが普通になります。

    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Share

    PCI DSS―ペネトレーションテスト、そして非保持の落とし穴

    Share

    PCI DSSとは国際カードブランド5社により定められた、クレジットカード情報を守るためのセキュリティ基準です。クレジットカード加盟店等がPCI DSSに準拠しない場合、カードの取り扱いが停止される場合もあります。本稿では、PCI DSSの対象、12の要件、準拠のために何が必要になるのか等について触れながら、AWSのPCI DSS準拠や、PCI DSSが求めるペネトレーションテストなどについて解説します。

    PCI DSSとは

    PCI DSSとは「Payment Card Industry Data Security Standard」の略称で、クレジットカード業界や関連事業者がクレジットカード情報を安全に取り扱うことを目的に定められた、12の要件から構成される国際基準です。American Express、Discover、JCB、MasterCard、VISAの5つのカードブランドが共同で2004年に策定しました。

    PCI DSSは、上記カードブランド5社が設立した組織であるPCI SSC(PCI Security Standards Council)によって管理されています。2021年には、最新の改訂版となるPCI DSSバージョン4.0の公開が予定されています。

    PCI DSSの対象となる事業者の条件

    PCI DSSは、クレジットカード情報の保存・処理・伝送などを行うすべての事業者(クレジットカード加盟店・銀行・クレジットカード決済サービス企業等)が準拠する必要がある国際基準です。

    年間のクレジットカード決済件数に応じて1~4の4段階でレベル分けがなされ、それぞれのレベルで検証が行われます。例えば最もレベルが高いレベル1の事業者に対しては、PCI SSCの認定セキュリティ評価機関(QSA:Qualified Security Assessor)による、毎年1回の訪問監査が必須となります。

    準拠が必要な場合、あなたの組織がどのレベルに属するのかをまず把握しておきましょう。

    PCI DSSに準拠しなくてよい「非保持化」と、その落とし穴

    一方で、クレジットカード決済をまったく取り扱わない企業や、取り扱っていてもクレジットカード情報の保存・処理・伝送を一切しない、いわゆる「クレジットカード情報の非保持化」を行っている企業はPCI DSSの対象外となり、準拠の必要はありません。

    ただし、対象外かどうかは厳密に確認する必要があります。例えば、「自分の組織ではクレジットカード情報の保存等は一切行っていない」と思っていたとしても、決済代行サービスの管理画面上でPIN(Personal Identification Number:個人識別番号)などのカード会員情報を見ることができるなら、それは保存や処理にあたります。「作業者の目にはそうした情報は一切ふれない」という場合でも、カード決済端末からの情報が一度でも組織内のシステムを通過するなら、それは伝送にあたります。

    上記のような状態で、「非保持化しているつもり」になっていないかどうかに注意しましょう。PCI DSSに詳しいセキュリティ企業のアドバイスを受けることをおすすめします。

    AWS環境下でのPCI DSS準拠

    代表的なクラウドサービスのひとつであるAWS(Amazon Web Services)は、最も規模の大きい「レベル1」のサービスプロバイダとして、PCI DSSに準拠しています。こういったサービスプロバイダを上手に活用すれば、あなたの組織でPCI DSS準拠に対応すべき範囲を減らすこともできます。ただし、慎重な運用が必要となることに変わりはありません。まずはAWSの責任共有モデルの理解からはじめましょう。

    PCI DSSの12要件とは

    以下に示すように、PCI DSSでは、6つの項目にわたって計12の要件が定められています。


    安全なネットワークとシステムの構築と維持

    1. カード会員データを保護するために、ファイアウォールをインストールして構成を維持する
    2. システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない

    カード会員データの保護

    3. 保存されるカード会員データを保護する
    4. オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する

    脆弱性管理プログラムの維持

    5. すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアまたはプログラムを定期的に更新する
    6. 安全性の高いシステムとアプリケーションを開発し、保守する

    強力なアクセス制御手法の導入

    7. カード会員データへのアクセスを、業務上必要な範囲内に制限する
    8. システムコンポーネントへのアクセスを識別・認証する
    9. カード会員データへの物理アクセスを制限する

    ネットワークの定期的な監視およびテスト

    10. ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する
    11. セキュリティシステムおよびプロセスを定期的にテストする

    情報セキュリティポリシーの維持

    12. すべての担当者の情報セキュリティに対応するポリシーを維持する


    (PCI DSSバージョン 3.2.1より)

    PCI DSSで求められる要件は明確で具体的です。そのため、一般的なセキュリティ管理のルールを策定する際の参考にされることがしばしばあるのですが、PCI DSSの要件に準拠したからといって、組織全体のセキュリティが万全になるとは言い切れない点に注意が必要です。例えば、PCI DSSでは、営業機密などへのアクセス制御不備があったとしても準拠に影響しない場合がありますし、PCI DSSへの準拠によってGDPR等の法制度に対応できるわけでもありません。PCI DSSを参考にする際は、それがあくまでクレジットカード情報の保護に特化した基準であることを念頭においたうえで活用するようにしましょう。

    PCI DSSに準拠するためにやることは

    PCI DSS準拠にあたっては、PCI DSSの基準に関するアンケートに回答する「自己問診」、PCI SSCが認定したASV(Approved Scanning Vendors:認定スキャニングベンダ)等によって行われるネットワークスキャン、PCI SSCが認定したQSA(Qualified Security Assessor:認定セキュリティ評価機関)による訪問監査などが、前述の4つのレベルに応じて実施されます。

    PCI SSC準拠と継続のための2つのネットワークスキャン

    PCI DSSにおけるネットワークスキャンとは、クレジットカード情報を扱うシステムや機器に対して、少なくとも四半期に1回、および対象システムに大幅な変更があった場合に、脆弱性スキャンを実施するものです。もし重大な脆弱性が発見された場合、準拠の認定や継続のためには、脆弱性の修正や代替案実施後の再スキャンで準拠基準に達しているという評価を得ることが必要になります。

    ネットワークスキャンには、クレジットカード情報を扱うシステム等に対して外部から行うスキャンと、内部から行うスキャンの2つがあり、外部からのスキャンは必ず認定スキャニングベンダ(ASV)によって実施されなければなりません。

    PCI SSC準拠と継続のためのペネトレーションテスト

    また、クレジットカードの加盟店等は、少なくとも1年に1回(決済サービスプロバイダ等は1年に2回)、および対象システムに大幅な変更があった場合に、ペネトレーションテストを実施しなければなりません。

    ペネトレーションテストを実施する際には、それがPCI DSSの要求を満たすテストであるかどうかを必ず確認しましょう。一般的基準で充分に高度とされるペネトレーションテストであっても、手法や範囲などがPCI DSSの要件を満たしていなければ、「システムの安全性は高まったがPCI DSSの準拠や継続ができなくなった」という事態が起こり得ます。

    ペネトレーションテストには、外部からのネットワークスキャンのようなベンダ認定の仕組みがないため、選定での判断には注意が必要です。PCI DSSのペネトレーション要件に精通した企業の助力を求めるとよいでしょう。

    なお、株式会社ブロードバンドセキュリティは、QSAとして12年にわたり約110社に対して、PCI DSS準拠認定付与支援およびオンサイト評価を行っております。また、PCIDSS準拠のためのネットワークスキャンやペネトレーションテストの実績を多数持っています。

    最新版「PCI DSS 4.0」とは

    PCI DSSでは現在8年ぶりのメジャーバージョンアップに向けた作業が進んでおり、2021年半ばにリリースされる見込みです。次期バージョンはPCI DSS 4.0となり、暗号やモニタリングなどが強化されるほか、多要素認証等についてもキャッチアップが行われ、さらなるセキュリティ強化が図られると予測されています。

    まとめ

    • PCI DSSとは、国際カードブランド5社により定められた、安全にクレジットカード情報を取り扱うためのセキュリティ基準です。
    • クレジットカード情報の保存・処理・伝送を行うすべての事業者(クレジットカード加盟店・銀行・クレジットカード決済サービス企業等)が、PCI DSSに準拠する必要があります。
    • PCI DSSへの準拠では、自己問診や、ASV(認定スキャニングベンダ)によるネットワークスキャン、QSA(認定セキュリティ機関)による訪問監査などが実施されます。
    • ペネトレーションテストを実施する際は、テストの手法や範囲などがPCI DSSの要件を満たしていることを確認する必要があります。
    • 2021年には、次期バージョンPCI DSS 4.0が公開される予定です。

    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Share

    すぐにできるDoS攻撃/DDoS攻撃を防ぐ3つの対策

    Share

    DoS攻撃とは一度に膨大なアクセス要求などを行うことで、インターネットを通じて提供するサービスを不能状態に陥れるサイバー攻撃です。本稿では、DoS攻撃とDDoS攻撃の違いや、史上最大規模となった攻撃の事例、攻撃の特徴などを解説し、すぐにできるDoS攻撃/DDoS攻撃の対策方法をご紹介します。

    DoS攻撃とは、DDoS攻撃との違い

    「DoS」とは「Denial of Service」の略で「サービス拒否」を意味します。「DoS攻撃」とは、Webサービスを提供するサーバなどに向けて大量の通信等を発生させることで負荷をかけ、本来のユーザがサービス提供を求めた際に、提供を拒否されるようになることを目的に行うサイバー攻撃です。

    複数の分散した(Distributed)拠点からDoS攻撃を行うものが、「DDoS(Distributed Denial of Service)攻撃」と呼ばれます。

    DoS攻撃/DDoS攻撃によるサービス停止は機会損失を生み、ブランド毀損は通常のサイバー攻撃より大きい場合もあります。また、直接攻撃対象とならなくても、攻撃の踏み台にされることで間接的な加害者となる危険性もあります。

    史上最大規模の攻撃、最新の攻撃進化事例

    古くは攻撃者が大量のリクエストを送ることでサーバなどをサービス停止状態に陥らせるタイプの攻撃が主流でしたが、近年では、分散化・大規模化が進んでいます。例えば、IoTのリスクと求められるセキュリティ対策で紹介した「Mirai」は、IoT機器に感染し、それらの機器をサイバー攻撃の踏み台として悪用することによって、史上最大のDDoS攻撃を引き起こしました。

    また、単純なサービス妨害からより複雑化した犯罪へという変化もみられます。例えば、JPCERTコーディネーションセンターでは、2019年、DDoS攻撃の実行を示唆して仮想通貨を要求する脅迫型メールが国内外の複数の組織で確認されていることを報告し、注意喚起を行っています。

    DoS(サービス拒否)型の攻撃はサイバー攻撃の手法としては最も古いものの1つですが、その大規模化・複雑化は日々進行しているのです。

    「敷居が低いサイバー攻撃」それがDoS/DDoS

    DoS攻撃/DDoS攻撃の特徴のひとつが攻撃の難易度の低さです。

    多くの場合、コンピュータプログラムを書いてマルウェアを開発するような技術力は不要で、APTのような組織・資金・技術力もいりません。

    インターネット上には、多数のDoS攻撃ツールが存在します。また、ストレステスト等の正規ツールを悪用してDoS攻撃を行う場合もあります。そればかりか、クレジットカードさえあればすぐに利用できる「DDoS攻撃を請け負う違法サービス」すら存在しています。

    DoS攻撃/DDoS攻撃を突き動かす政治社会的動機

    DoS攻撃、特にDDoS攻撃の特徴を示すキーワードが「社会・政治」です。

    2010年、米大手決済サービスが、国際的な内部告発サイトが運営のために支援者から寄付を集める際に利用していた口座を、規約にしたがって凍結したことに対し、ハッカー集団がDDoS攻撃を実施、米大手決済サービスのサービスが一部停止する事態に陥りました。

    このように、実施のハードルが低いDoS攻撃/DDoS攻撃は、人々が自身のさまざまな意思を表明するために、あたかもデモ行進のように実施されることがあります。かつては、DDoS攻撃をデモ活動同様の市民の権利として認めるべきであるという議論がまじめに行われていたこともありました。しかし、実際には「気に食わない」だけでもDDoS攻撃は行われ得るのです。社会課題の解決、ナショナリズム、倫理などを標榜していたとしても、端から見るとヘイトや嫌がらせと変わらないことがあります。

    DoS攻撃/DDoS攻撃によるブランド毀損はあっという間に

    政治的、社会的、あるいは倫理的文脈から批判が集中した企業やサービスなどに対して、一度DoS攻撃/DDoS攻撃がはじまると、その趣旨に共感した人々が次々と参加し、ときに雪だるま式に拡大することがあるのもこの攻撃の特徴です。

    また、DoS攻撃/DDoS攻撃は、攻撃が起こっていることが外部からもわかるという点で、外部に公表するまでは事故の発生がわからない情報漏えいのようなタイプのサイバー攻撃とは異なります。「広く一般に知られる」ことが容易に起こりうるため、ブランドへの負のインパクトが発生する可能性も大きいといえます。

    DoS攻撃/DDoS攻撃の発生に気づくのは難しい

    そもそもWebサービスは、その性質上外部に公開されるものです。そのためDoS攻撃やDDoS攻撃を完全に防ぐことは容易ではありません。特に多数の機器を踏み台として巻き込むDDoS攻撃の標的となった場合には、気づく間もなくあっという間にサービス拒否状態に陥る可能性が高いでしょう。

    脆弱性や設定不備を狙ったDoS攻撃は防ぐことが可能

    一方で、防ぐことができるタイプの攻撃も存在します。それは、サーバ等の設定不備や、プログラムの脆弱性を突いて行われるDoS攻撃です。

    一部のWebサイトでは、「長大な文字列を受け入れてしまう」「ファイルの容量を制限しない」など、DoS攻撃につけ込まれてしまう問題が存在することがあります。また、ネットワーク関連の設定の不備によってDoS攻撃を受ける可能性も存在します。しかし、こうした脆弱性は、修正による回避が可能です。

    また、あなたの企業が直接DoS攻撃の攻撃対象とならなくても、上述のような脆弱性を放置しておくとDDoS攻撃の踏み台にされることもあります。その対策としては、各種機器・OS・ソフトウェアの脆弱性管理を適切に行うことや、脆弱性診断等のセキュリティ診断を定期的に実施して未知のリスクを把握し、対処することが重要です。

    診断会社あるある「すわ、DoS攻撃?」

    ここで余談ではありますが、診断実施に伴う「あるある」エピソードを。

    セキュリティ診断を行う際には、必ず、実施の年月日や時間帯を関連する部署に周知しなくてはなりません。

    実は、診断実施に伴って事業部門等が「DoS攻撃が発生した!」と勘違いすることが、しばしばあるのです。もちろん、一般にインターネット上に公開しているシステムの場合には業務に差し支えるような検査の仕方をしないというのが大前提ですが、それでも、大量の問合せ等が発生すると何も知らされていない担当部署はサイバー攻撃と勘違いすることがあります。ついでにこの際に抜き打ちで社内のサイバー訓練を・・・と目論みたい気持ちが出たとしても、それを実行に移すのは大変危険です。訓練は訓練させる側にきちんとした検証シナリオがあってこそ効果を発揮します。まずは関係各所との連携を徹底するところから始めましょう。

    DoS攻撃/DDoS攻撃にも有効な3つの基本的対策

    DoS攻撃、特にDDoS攻撃の対策としては、CDN(Content Delivery Networks)の利用、DDoS攻撃対策専用アプライアンス、WAF(Webアプリケーションファイアウォール)などが威力を発揮します。

    そして、これらの対策を適用する際には、同時に、セキュリティ対策の基本ともいえる以下の3点に対応できているかどうかも確認しましょう。

    1.必要のないサービス・プロセス・ポートは停止する
    2.DoS攻撃/DDoS攻撃の端緒になりうる各種の不備を見つけて直す
    3.脆弱性対策が施されたパッチを適用する

    いずれもセキュリティ対策の「基本中の基本」といえるものばかりですが、防御可能なタイプのDoS攻撃を回避し、システムがDDoS攻撃の踏み台にされることを防ぐためにきわめて有効です。

    これまで述べたように、DoS攻撃/DDoS攻撃は、機会損失やブランド毀損など事業継続性を損なうダメージをもたらし得るサイバー攻撃です。DDoS攻撃の踏み台となれば社会的責任が問われることもあるでしょう。経営課題のひとつとして認識し、対処することが大切です。

    まとめ

    • DoS攻撃とはサーバなどに負荷をかけてサービスを提供できなくするサイバー攻撃です。
    • 攻撃実行の難易度が低く、人々の意思表明のために大規模に行われることもあります。
    • 脆弱性を突いて行われるDoS攻撃は、脆弱性診断などで発見し対策することができます。
    • 必要のないサービス・プロセス・ポートの停止、などの基本的対策がDoS攻撃/DDoS攻撃にも有効です。

    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Share

    IoTのリスクと求められるセキュリティ対策

    Share

    パソコンやコンピュータだけでなく、さまざまなモノがインターネットにつながるIoTの到来によって、我々の社会や経済、生活の利便性は大きく向上していますが、利便性に注目が集まる中、忘れられがちなのがセキュリティではないでしょうか。昨今、IoTを狙った攻撃は増加の一途をたどっています。本稿では、IoTの特徴を紹介したうえで、そのリスクや、セキュリティ対策で求められる基本的な考え方を解説します。

    IoTとは

    IoT(アイオーティー)とは「Internet of Things」の略称で「モノのインターネット」という意味です。これまでインターネットは、コンピュータやサーバ同士を接続するためのものでしたが、IoTでは、工場の制御システム、各種社会インフラ、医療機器、自動車、住宅、情報家電など、さまざまな「モノ」同士がインターネットを介して情報のやりとりを行うことで、新たな付加価値を創造します。また、IoTはAIなどと同様、デジタルトランスフォーメーションの核となる技術領域のひとつとして期待されています。

    IoTの活用事例

    現在研究が進んでいる、5Gネットワークを活用した自動運転車は、IoT技術をクルマに活用した例です。その他にもIoTのセンサーを設置することで水道管の漏水や工場設備の故障を検知したり、ネットワークカメラでペットの様子を確認したりなど、私たちの周囲にも徐々にIoT機器・サービスが登場しはじめています。

    ITとIoTの6つの違い

    しかし、こうしたIoT機器・サービスもまた、ネットワーク機器やサーバ、Webアプリケーションなどと同様にサイバー攻撃の標的となりえます。2016年7月に総務省・経済産業省・IoT推進コンソーシアムによって公開された『IoTセキュリティガイドライン』によれば、セキュリティを確保しながらIoTを利活用するには、下記のような「IoT特有の性質」を理解して対策を講じることが重要です。

    1.脅威の影響範囲・影響度合いが大きい

    2.IoT機器のライフサイクルが長い

    3.IoT機器に対する監視が行き届きにくい

    4.IoT機器側とネットワーク側の環境や特性の相互理解が不十分である

    5.IoT機器の機能・性能が限られている

    6. あらゆるIoT機器が通信機能を持つため、開発者が想定していなかった接続が行われる可能性がある

    IoT機器・サービスに潜むリスクとサイバー攻撃事例

    IoT機器・サービスを狙ったサイバー攻撃はその急速な普及を背景に増加の一途をたどり、潜在するリスクも続々と報告されています。上記に挙げたようなIoT特有の性質から、ひとたび攻撃や悪用が起こると、その影響範囲はこれまでと比較にならないほど大きくなる恐れがあります。例えば、数年前に世界的に猛威を振るったマルウェア「Mirai」は、IoT機器に感染し、そうした機器をサイバー攻撃の踏み台として悪用することによって、史上最大のDDoS攻撃を引き起こしました。

    また、2019年には、アメリカで、防犯・監視カメラに攻撃者がアクセスし、子供や寝ている人に話しかけるという事件*4が起きました。同じメーカーが提供する玄関チャイムに、接続されているWi-Fiのパスワードが盗聴により漏えいする脆弱性があったことも報告*2されています。2020年には、音声アシスタントサービスを提供するAmazon Alexaに、音声履歴や個人情報等を盗み出せる脆弱性*3が存在することがイスラエルのセキュリティ企業の研究部門によって明らかになりました。

    上記はいずれも家庭で使用されているIoT機器の例ですが、産業用のIoT機器も今やサイバー攻撃の足掛かりとして格好のターゲットになっています。*4「社会のあらゆる領域にリスクが存在している」というのが現状といえるでしょう。

    総務省・経産省らによる『IoTセキュリティガイドライン』が示す5つの指針

    前掲の『IoTセキュリティガイドライン』では、IoT機器やIoTを使ったサービスを手掛ける事業者に対して、下記「IoTセキュリティ対策の5指針」に沿った対策を講じるように促しています。

    1.IoTの性質を考慮した基本方針を定める

    2.IoTのリスクを認識する

    3.守るべきものを守る設計を考える

    4.ネットワーク上での対策を考える

    5.安全安心な状態を維持し、情報発信・共有を行う

    IoT機器・サービスを手掛ける事業者は、IoT機器のライフサイクルを踏まえながら、上記指針に沿って設計や製造、サービス提供のあり方を見直し、必要な措置をとることが求められます。

    実装すべきセキュリティ機能を『IoTセキュリティチェックリスト』で把握

    押さえておきたいリソースとして、もう1つ、セキュリティ専門機関である一般社団法人JPCERTコーディネーションセンターが2019年に公開した『IoTセキュリティチェックリスト』をご紹介しましょう。これは、IoT機器の開発や製造、IoTサービス提供に関わる事業者を対象にしたもので、IoTデバイスを安全に運用するために実装しておきたいセキュリティ機能がチェックリスト形式でまとめられています。

    リストには、「ユーザ管理」「ソフトウェア管理」「セキュリティ管理」「アクセス制御」「不正な接続」「暗号化」「システム設定」「通知」の8つのカテゴリに分類された39の機能が記載されています。さらに、それぞれの機能が、Sensor(センサー)、Aggregator(センサーからのデータを集約する機能)、Communication Channel(通信チャネル)といった、IoTシステムを構成する基本単位のいずれに対応するのかも一目でわかるようになっており、自組織のIoTセキュリティ対策に取り組むうえでぜひ活用することをお勧めします。

    IoTセキュリティの落とし穴

    なお、IoTのセキュリティでは、自組織で対策を講じるだけでは十分ではありません。IoTサービスにおいては、IoT機器を開発製造する企業、それを活用したサービスを設計する企業、サービスを提供するためのアプリケーションを開発する企業、サービスの運用を行う企業など、複数の当事者が存在、相互に依存しあっており、それぞれの当事者にリスクが存在します。つまり、複数の企業間で、共通した同水準のセキュリティレベルを維持することが求められるのです。これは、従来のITサービスの場合に比べても決して楽なことではなく、最もセキュリティ対策の手薄な企業がいわば「弱い鎖」となって、攻撃を許すことにもなりかねません。

    さらに、国や地域によって異なる法規制への対応が必要になることもあります。IoTによって企業間のつながりが特定の地域を超える可能性があるためです。例えば、日本国内での販売やサービス提供はOKでも、ヨーロッパではGDPR(EU一般データ保護規則)、アメリカではCCPA(カリフォルニア州消費者プライバシー法)等のプライバシー関連法規に抵触するケースなどもありえます。日本の個人情報保護法もグローバルな動きの影響を受け今後変更される可能性もあります。法規制対応に関する注意も怠ってはなりません。

    IoTセキュリティ診断、相場料金の現状は?

    IoTは、Webアプリケーションやイントラネットのようないわば均質化した診断対象とは異なり、その利用用途がスマート家電から工場、社会インフラまで実に幅広いという特徴があります。OSやファームウェア、ASIC、FPGA、各種モジュール、アプリケーションの組み合わせはほぼ無限です。この点が、IoTのセキュリティ診断とその他のセキュリティ診断を分かつ最大の違いといえます。例えば、Webアプリケーション診断のように「1リクエストいくら」といった形で料金が提示されることはめったにありません。

    IoTのセキュリティ診断を実施するにあたっては、実施の都度、対象の機器、システムの構成を踏まえたうえで、目的や予算、期間を考慮して診断内容を決定することが求められます。専門業者の診断サービスを利用する場合には、「さまざまな診断手法を熟知しているか」、「十分な診断実績はあるか」、といった点を判断指標に選定することをお勧めします。

    まとめ

    • IoTは「モノのインターネット」のことです。IT機器だけでなく、クルマや家電など、あらゆるモノがインターネットでつながることで経済や生活に付加価値をもたらします。
    • IoTのセキュリティ対策では、数年サイクルでリプレイスされるIT機器と異なりライフサイクルが長い、いざ事故が発生した場合の影響が大きいなど、IoT特有の性質を考慮する必要があります。
    • IoT機器に感染するマルウェア、家庭用の監視カメラへの不正アクセス、産業用IoT機器への脅威など、さまざまなIoT機器・サービスへのサイバー攻撃やリスクが報告されています。
    • IoT機器・サービスのセキュリティには、「機器の設計製造」「サービス設計」「アプリケーション開発」「サービス運用」など複数の当事者が、それぞれ責任をもって取り組む必要があります。
    • IoTのセキュリティ診断は、OSやファームウェア、ASIC、各種モジュールなど対象の組み合わせが無限に存在することから、事前に目的・予算・期間などを綿密に定義したうえで実施する必要があります。

    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Share