クロスサイトリクエストフォージェリ(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単体のリスクが低くても確実に対策を行うことが重要です。

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

ブルートフォース攻撃 ~ 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は、多要素認証とリスクベース認証を推奨しています。
  • 多要素認証やリスクベース認証など、これからは複数の手段でアカウントを守ることが普通になります。

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

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、各種モジュールなど対象の組み合わせが無限に存在することから、事前に目的・予算・期間などを綿密に定義したうえで実施する必要があります。

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

APIのセキュリティ脅威とは

Share

APIとは、ソフトウェアが相互に機能やデータを利用しあうための仕組みで、機能や開発効率を向上させるなどのメリットがあります。しかしAPIにもセキュリティ上のリスクがあり、セキュリティ対策を怠ったことによる被害も報告されています。今回は、APIの安全な利活用について解説します。

「API」とは

「API」とは「Application Programming Interface」の略で、複数のソフトウェアが相互に機能を利用しあうために設けられたインターフェースを意味します。コンピュータプログラムやWebサービスなどをつないで連携させ、さまざまな機能やデータを共有可能にすることで、従来にない価値を生み出せるという点が大きなメリットといわれています。例えば、あるアプリが、特定の機能を持つAPIを利用することで、それまでなかったサービスをユーザに提供できるようになります。

APIのなかでも広く利用されているのがWebに公開されている「Web API」で、多数のWebサービスやプラットフォーマーが各社のWeb APIを公開しています。身近な例としては、位置情報ゲームで地図情報サービスが提供するAPIを利用するケースなどがあります。

APIの積極的な活用は、IoTや企業のDX(デジタルトランスフォーメーション)の実践に不可欠と言っても大げさではありません。さまざまなアプリやWebサービスがAPIを通じて相互接続することで、利用者の利便性の向上、経済の活性化など、単独では実現できなかった価値を生み出せるようになります。こうした仕組みのことを「APIエコノミー」と呼ぶこともあります。

あなたの身近にあるAPIの活用例

Webサービスなどを利用しているときに「Facebookでログイン」「Googleでログイン」などのボタンを見たことはありませんか? Facebook、Google、Twitterなどで設定したアカウントを使って、別のECサイトなどにログインする「ソーシャルログイン」は、各サービスが公開するAPIを使って実現されています。また、企業などのWebサイトで地図情報がGoogle Mapから呼び出されて掲載されている、あの仕組みもAPIによるものです。

API活用のメリット

APIを活用すれば、個別の機能を各サービスで一から開発する必要がなくなるため、開発効率が上がり、コストを抑えることができます。機能を提供する側も、機能を使ってもらうことで自社のブランド力の向上、広告収入といった経済的利益を得られます。また、前出の「ソーシャルログイン」などでは、独自のログイン用プログラムを各企業がそれぞれ開発する場合に比べ、一定のセキュリティ水準を確保できるという効果も期待できます。

Web APIはWebアプリケーションでどう使われるか

ここで、「Web API」はいわゆる「Webアプリケーション」でどう使われるのか、少し補足しておきましょう。

WebアプリケーションがAPIを用いて地図情報だけを外部の地図サーバから取得しているケースについて考えてみます。Webサーバはブラウザからのリクエストを受け、WebアプリケーションからAPIを経由して地図情報を地図サーバにリクエストします。地図サーバはAPIを介して地図情報をWebアプリケーションへ送り返します。それを受けたWebサーバが、地図情報を含めたページ全体をユーザに返します。ユーザから見たときにはAPIを使っているかどうかはわかりませんが、このように、APIは、特定の機能のため、特定の情報のやり取りのために利用されているのです。

APIのセキュリティの重要性

Webサービスを利用するユーザ側から見れば、そこでAPIが使われているかどうかは何ら重要なことではありません。しかしサービス提供側から考えた場合、APIにもWebアプリケーション同様、脆弱性をはじめとするさまざまなセキュリティリスクが存在することを忘れてはなりません。また、近年のスマートフォンの普及により、スマートフォンのアプリケーションがAPIを直接利用するケースも増えており、今までサーバ側での利用が主流だったAPIがユーザの手元から直接利用される時代になっている点にも注意が必要です。

適切なセキュリティ対策を怠った場合のリスクは、むしろWebアプリケーションよりも深刻かもしれません。さまざまなソフトウェアと連携するというAPIの特質から、被害が自社のコントロールの及ぶ範囲を超えて広がる可能性が想定されるためです。

APIが原因で起こったサイバー攻撃被害

2018年、米大手SNSが開発者向けに公開していたAPIのバグが悪用され、ログインを行う際のカギとなるデータが盗まれる事件が発生しました。2019年には、大手配車マッチングアプリで、APIが降車時の支払い方法の検証をしないことで、無賃乗車ができてしまうバグが報告されています。

米大手SNSの事件は、多数のAPIが組み合わされることによって、バグの検出やセキュリティ上の問題の発見が遅れたり困難になったりするという問題をあらわにしたものでした。また、配車マッチングアプリのバグは、APIの入力値を検証することの重要性を改めて気づかせるものでした。

その利便性から急速に普及が進んでいるAPIですが、「事故やサイバー攻撃被害の発生によって初めて、リスクの存在を認識する」という昨今の状況を踏まえると、セキュリティに関してはまだまだ未成熟な領域であるといえるでしょう。

「OWASP API Security Top 10」などのリソースを活用して対策を立てる

こうしたサイバー攻撃被害や事故を受け、今、APIのセキュリティは最重要事項の1つとして取り組まれるようになっています。その大きな成果の1つとして、「API Security Top 10」をご紹介しましょう。これは、Webアプリケーションセキュリティに関する国際的コミュニティOWASP(Open Web Application Security Project )がAPIセキュリティに関する10大リスクを選定・解説したもので、2019年末に公開されました。API固有のセキュリティリスクを把握し、対策を講じるために役立ちます。


OWASPによるAPIセキュリティ10大リスク

1.オブジェクトレベルでの許可の不備(Broken Object Level Authorization)
2.認証の不備(Broken User Authentication)
3.データの過度な露出(Excessive Data Exposure)
4.リソースの制限、頻度の制限の不足(Lack of Resources & Rate Limiting)
5.機能レベルの認可の不備(Broken Function Level Authorization)
6.一括での割り当て(Mass Assignment)
7.不適切なセキュリティ設定(Security Misconfiguration)
8.インジェクション(Injection)
9.不適切なアセット管理(Improper Assets Management)
10.不充分なロギングとモニタリング(Insufficient Logging & Monitoring)

(翻訳:SQAT.jp 編集部)


上記のような資料は、自組織のAPIセキュリティを点検する際のガイドラインとしてぜひ活用したいものです。さらに、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。

まとめ

・APIとはアプリやWebサービスなどが相互に機能やデータを利用しあうための仕組みです。
・API活用には、開発のスピードアップやコスト削減などのメリットがあります。
・近年はスマートフォンからAPIを直接利用できるケースも増えており、利用の機会が増えています。
・APIにもセキュリティ上のリスクがありますが、様々なサービスとつながるために利用するという性質から、ひとたび事故や攻撃が起こった場合、より広い範囲に影響が及ぶ可能性があります。
・APIのセキュリティ対策を怠ったことによるサイバー攻撃被害や事故が報告されています。
・OWASP「API Security Top 10 2019」などを参考にAPIのセキュリティ強化に取り組みましょう。

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

Webアプリ脆弱性の代表格「クロスサイトスクリプティング」の攻撃事例と対策

Share

クロスサイトスクリプティング(XSS:Cross Site Scripting)とは、サイバー攻撃に悪用される脆弱性のひとつです。

この脆弱性を悪用した攻撃の多くが、Webサイトを横断(Cross Site)して行われたためこの名称がつけられました。現在では攻撃類型が増えたことから、必ずしもサイト横断的な攻撃でなくても、クロスサイトスクリプティングと呼ばれることがあります。

今回は、クロスサイトスクリプティングを悪用したサイバー攻撃の事例やその対策について説明します。

クロスサイトスクリプティングの種類

クロスサイトスクリプティングとは、動的にHTMLを生成するWebアプリケーションで、ユーザの操作を介して不正なスクリプトを実行させる(できる)事象を指します。

クロスサイトスクリプティングの脆弱性には、大きく分けて下記の3種類があります。

1.反射型
攻撃者がリクエストに混入させたスクリプトなどが、Webサーバからのレスポンスに含まれる形で実行されるもの

2.蓄積型
攻撃者がWebサーバ上に何らかの方法でスクリプトを格納したうえで、被害者がアクセスすることでスクリプトが実行されるもの

3.DOMベース
Webサーバ側がスクリプトで動的にHTMLを生成する場合にスクリプトタグを生成してしまうことに起因し、ブラウザ側での処理の際に不正なスクリプトが実行されるもの

クロスサイトスクリプティング脆弱性が悪用された事件による騒動

クロスサイトスクリプティングの脆弱性が悪用された被害が多数報告されています。なかでも有名なのは、過去に二つの大手ITサービスで発生した事件です。

2010年、YouTubeとTwitterで、クロスサイトスクリプティングの脆弱性を悪用した攻撃が相次いで発生、虚偽情報を知らせるポップアップが表示されたり、ユーザが意図しない投稿が繰り返されたりするなど、世界中で騒動となりました。

Twitterへの攻撃は、ユーザが意図しない投稿を行うもので、見つけた脆弱性がどう動くのか実験したいというちょっとした出来心が攻撃意図に含まれていたと言われています。YouTubeについてはフェイクニュースをポップアップで表示するなどのいたずらに近い内容でした。いずれも被害は軽微で、すぐに気づくことができた点は幸運だったといえるでしょう。

クロスサイトスクリプティングを悪用した攻撃の本当の危険性と恐ろしさ

クロスサイトスクリプティング攻撃の危険性

一方、上記のようないたずら目的ではない攻撃では、正規サイトと全く見分けがつかないフィッシングサイト等へ誘導されたり、ログイン状態の維持のために利用しているCookieなどのセッション情報を盗まれたり、入力した情報(例えばパスワードやクレジットカードの番号やセキュリティコード)が盗まれるといったことが行われます。この結果、アカウントへの不正アクセス、クレジットカード情報・個人情報の漏えい、あるいはクレジットカードの不正利用などが行われることがあります。またスクリプトの実行による任意コードの実行やマルウェア感染といった問題も存在します。このようにクロスサイトスクリプティング脆弱性は悪用された場合に甚大な被害が発生する可能性が高いという点に危険性があるといえます。

ユーザに被害が出てから発覚することのリスク

Webアプリケーションを利用するユーザの側では、身に覚えのないクレジットカードへの課金など、具体的な被害が発生するまで攻撃を受けたことにすら気づかないこともあるでしょう。一方のWebアプリケーション開発側・運用側でも、実際にユーザやクレジットカード会社から被害発生を知らされるまで気づかないというケースもあります。

ユーザ側の視点でみると、「自分が被害に遭ったのに、サイトの運営者が気付いていないなんて」と憤る可能性もありますし、「こんな不完全なサイトを運営するなんて」と不信感を抱く可能性もあるでしょう。クロスサイトスクリプティング脆弱性のあるサイトを運用することはともすればユーザの信頼を損なう結果に結びつく可能性があるのです。

クロスサイトスクリプティングの発見報告状況

SQAT.jp を運営する株式会社ブロードバンドセキュリティが行ったWebアプリケーション脆弱性診断の2020年上半期の統計によれば、クロスサイトスクリプティングは、検出される全脆弱性の約5%を占めています。

冒頭で「Webアプリ脆弱性の代表格」と述べている割にあまり比率が多くない、と感じるかもしれませんが、むしろ古くから警鐘が鳴らされ、対策も公表されているにもかかわらず、新たに作られたWebサービスにも(ステージング環境の診断を含むとはいえ)一定割合存在する点に注目すべきでしょう。

クロスサイトスクリプティングは入出力制御に関する問題です。したがって金融・保険業界、情報通信産業やECサイト関連等の、「オンラインでの商取引を厳格に行う必要がある業界」「個人情報や決済情報を厳密に扱う必要がある業界」では、クロスサイトスクリプティングを含む入出力制御に関する問題への対策が厳格に行われています。これらの業界では開発段階でのソースコード診断やステージング環境での脆弱性診断などを行って必要な修正を施したうえで本番環境へ移行しているケースが多いのです。

このように、シフトレフトの考えに基づいて開発中にソースコード診断を行う、開発の最終段階やWebサイトの改修などの都度こまめに脆弱性診断を行うことで、クロスサイトスクリプティングの脆弱性をより早い段階で解消する効果は見逃せないものではないでしょうか。

クロスサイトスクリプティングの脆弱性を発見し対処する必要性

以前の記事で紹介した裁判事例では、WebアプリケーションにSQLインジェクション脆弱性を発生させた開発会社に対して、実際に損害を被った企業向けに約2,200万円の損害賠償支払いを命じる判決が2014年に下されています。

また、2020年6月に公布された改正個人情報保護法においては、サイバー攻撃によって個人情報漏えいが発生した場合でも、被害者個人(本人)と個人情報保護委員会への通知が義務付けられました。違反には最高で1億円の罰金が科され、悪質な場合は社名も公表されます。2022年の施行に先立ち、具体的な運用方法について年内に政令や規則がまとめられる見通しですが、今後、Webサイトを運営する企業の義務と万が一の場合の責任は重くなることが予想されます。

先にみたように、クロスサイトスクリプティングの脆弱性に気づかず放置することで、フィッシングに悪用されるケースや、不正アクセス、情報漏えいなどさまざまな被害が生じる可能性があります。

本稿執筆時点の2020年、クレジットカード情報をWebサイト上で盗むためにクロスサイトスクリプティングの脆弱性を悪用する攻撃が問題となっており、現在もクロスサイトスクリプティングが脆弱性の代表格であることに変わりはありません。

クロスサイトスクリプティングの対策方法

クロスサイトスクリプティングの脆弱性を生み出さないための対策としては、以下の方法が挙げられます。

1.JavaScript実行のために埋め込まれる特殊文字を変換して処理(エスケープ処理)することや入力文字種を制限して特殊文字を許容しないといった対策を行う

2.正規のスクリプトが悪用されないようにするため、処理中に文字列が意図しないスクリプトとして解釈されないようにホワイトリストなどによる検証を行う

3.DOMベースXSS対策として、DOM操作用のメソッドやプロパティを使用する

4.Webアプリケーション開発にあたって信頼性の高いライブラリを利用する

また、Webアプリケーションへの入力値のチェックなどを行うWAF(Webアプリケーションファイアウォール)を用いた防御なども考えられるでしょう。ただしWAFを使った防御では、そもそもの脆弱性を解消するという本質的問題解決をはかることができない点に注意が必要です。

クロスサイトスクリプティングを脆弱性診断で発見し、適切に対応して利用者の安全を守り、組織の顔であるWebサイトやWebアプリケーションの健全性を維持することは、WebサイトやWebアプリケーションを運営する企業や組織にとって必ず行わなければならない義務といえるかもしれません。

まとめ

・クロスサイトスクリプティングはサイバー攻撃に悪用されるWebアプリケーション等の脆弱性のひとつです。
・蓄積型や反射型、DOMベースなどの種類があります。
・Webサイト等に悪意のあるスクリプトを混入させることで攻撃を行い、ユーザの情報を盗み出すなどの被害が発生します。
・「特殊文字の変換処理」「入力文字種の制限」などの対策実施によって防ぐことができます。
・クロスサイトスクリプティングに限らずWebアプリケーションの脆弱性を積極的に発見し対処することは運営者の社会的義務です。

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

TLS暗号設定ガイドラインがアップデート
~TLS 1.0/TLS 1.1は完全に非推奨へ~

Share

2020年7月7日、情報処理推進機構(IPA)と情報通信研究機構(NICT)は、「TLS暗号設定ガイドライン」第3版を公開しました。これは、電子政府推奨暗号の安全性の評価プロジェクト「CRYPTREC」が作成したWebサーバでのTLS暗号設定方法をまとめたものであり、2018年5月8日公開の「SSL/TLS暗号設定ガイドライン」第2版の改訂版となります。なお、第3版では、ガイドラインの名称から「SSL」の語句が消えています。「SSLの使用を禁止すべき」とする前回改訂以降の流れを反映したものといえるでしょう。本記事では、第3版における主な変更点を紹介します。

第3版における変更点としてまず指摘したいのが、「推奨セキュリティ型」の設定基準の更新です。IPA/NICTの本ガイドラインでは、「高セキュリティ型」、「推奨セキュリティ型」、「セキュリティ例外型」(安全性上のリスクを受容してでも継続利用せざるを得ない場合の設定基準)という3つの設定基準が提唱されていますが、第2版で「推奨セキュリティ型」において利用が認められていたTLS 1.0およびTLS 1.1が、第3版では「セキュリティ例外型」でのみ利用可能となりました。なお、SSL 3.0にいたっては、第3版では「セキュリティ例外型」からも除外されています。

ChromeやFirefoxなどの主要ブラウザ(クライアント)においては、2020年上半期をもってTLS 1.0/1.1が無効化され、相互接続の互換性維持目的でTLS 1.1以下をサポートするメリットは既になくなっています。加えて、常時HTTPS化という世界的な流れの中では、TLS 1.0/1.1が利用可能なWebサイトは「安全でない」とみなされる場合もあるでしょう。なお、SSL Pulseによる調査では、約15万の主要サイトのうちTLS 1.3が利用できるのは31.7%、TLS 1.2が利用できるのは97.6%にのぼっています(7月8日時点のデータより)

図:SSL/TLSの利用率推移

https://www.ssllabs.com/ssl-pulse/ のデータにもとづき当社作成

また、プロトコルのバージョンだけでなく暗号スイートについても見直しが行われ、TLS 1.2に対してもPFS(Perfect Forward Secrecy)*5を有する鍵交換方式(ECDHE、DHE)を含む暗号スイートのみの使用が強く推奨されています。PFSは、2013年のスノーデン事件をきっかけにその重要性が認識され普及が進んだ暗号スイートです。最新のTLS 1.3では、既定でPFSを有する鍵交換方式のみが採用されており、今後、鍵交換方式が満たすべき標準になると考えられます。

その他の暗号スイートについてはどうでしょう。まず、現在広く普及し、サーバ証明書で鍵長をコントロール可能なRSA方式での鍵交換については、PFSを有していないという理由で「推奨セキュリティ型」の設定基準から除外されています。DH(DHE)方式の鍵交換については、使用する製品やその設定等によって選択される鍵長が異なることがあります。2048ビット以上の鍵長を明示的に設定できない製品(Apache 2.4.6以下等)では、1024ビット以下の鍵長のDHEを含む暗号スイートは利用できないようにするなどの対策も必要です。ちなみに、前出のSSL Pulseによる調査では、9.6%のWebサイトで1024ビット以下の鍵長のDH(DHE)がサポートされており、脆弱な秘密鍵が使用されてしまう可能性は依然として存在する点にあらためて注意が必要でしょう(7月8日時点のデータより)。

最後に、TLS 1.0/1.1の継続使用に関しては、セキュリティ対策の指標として広く用いられている各種国際的標準でも非推奨への動きがみられることを押さえておきましょう。例えば、IETF(Internet Engineering Task Force)は、TLS 1.0/1.1廃止のRFC(技術仕様文書)発行を進めており、NIST(National Institute of Standards and Technology)は、2019年8月時点でのガイドライン案において、2024年1月1日までにTLSを使用するすべての米国政府のサーバでTLS 1.3をサポートすることや、RSA方式での鍵交換を停止することを提案しています。また、PCI DSS(Payment Card Industry Data Security Standard)では、2016年公開のPCI DSS v3.2において、初期TLS(TLS 1.0および初期のTLS 1.1実装)を利用しているシステムはクレジットカード業界における監査基準に適合しないとみなしています。OWASPでも、2019年3月にリリースされたOWASP ASVS 4.0において、すべてのWebサイトが通信に関して満たすべき要件として、TLS 1.1以下の古いバージョンのプロトコルを無効化することを求めています。なお、IPA/NICTの本ガイドラインで用いられている3つの設定基準(「推奨セキュリティ型」「高セキュリティ型」「セキュリティ例外型」)は、これら各種標準の指針に対応したものであり、準拠への取り組みや、暗号設定における今後のセキュリティ対策を検討する上でも役に立ちます。ぜひ参照されることをお勧めします。

関連情報

● 量子コンピュータの実用化と耐量子暗号の標準化動向

●2019年下半期 カテゴリ別脆弱性検出状況

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

サイバー攻撃の要因、脆弱性とは?
-脆弱性がもたらすリスク、企業がとるべき脆弱性対策-

Share

情報漏えいなどの被害をもたらすサイバー攻撃。そのなかでも「脆弱性」は、セキュリティを脅かす大きな要因となり得ます。メディアを賑わすセキュリティ事故の多くは、脆弱性への対応を放置することで引き起こされたものです。この記事では、脆弱性とは何か、なぜそれがサイバー攻撃の起点となるのか、我々はどのようにしてサイバー攻撃の被害から自組織を守ることができるのかについて解説します。脆弱性を悪用した攻撃事例をもとに、脆弱性がもたらすリスクやその対策、脆弱性情報を収集する方法、脆弱性を見つけるために利用できるチェックツールや診断サービスについて理解を深め、適切な対応を行えるようにしましょう。

「脆弱性」とは?

脆弱性は「きじゃくせい」ではなく「ぜいじゃくせい」と読みます。対応する英語は、「Vulnerability」(「攻撃を受けやすいこと」の意)です。脆弱性とは、不正アクセスやコンピュータウイルスなどの攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所のことです。

脆弱性の多くは、「プログラムの設計ミスやコーディングミスなどによるバグ」になります。バグが存在せず正しく動作するプログラムやWebアプリケーションであっても、設計者が想定しないやり方で機能が悪用され、 結果としてサイバー攻撃が成立する場合には、その「悪用されうる機能設計」が脆弱性とみなされます。

脆弱性を悪用した攻撃の事例とその後の企業の対応について

脆弱性への対応を怠り社長が辞任に追い込まれたケースも

脆弱性への対応を誤ることは、しばしば事業の運営に甚大な影響をもたらします。典型的な事例をご紹介しましょう。2017年、クレジットカード等の与信に関わるアメリカの大手消費者情報調査会社がサイバー攻撃を受け、自社で保有していた4億件の個人の信用情報の約3分の1にあたる、1億4,000万件もの情報が盗まれました。この攻撃は、Webアプリケーションの開発フレームワークであるApache Strutsの脆弱性を、脆弱性情報とパッチの公開後速やかに修正できなかったことに起因するものです。

攻撃の端緒となった脆弱性に対しては、2017年3月にパッチや対策方法が公開されました。会社側では公開を受けて修正を図ったものの、組織体制の不備等もあいまって修正は不完全な形となり、結果、システムへの不正アクセスを許すことになりました。さらに、攻撃は同年5月から確認されていたにもかかわらず同社が事件を公表したのは9月。4か月もの間事態が公表されなかったことが大きな批判を浴び、CEOなど一部の幹部は辞任に追い込まれ、格付けも引き下げられたのです。脆弱性が引き金となり、このように甚大な影響がもたらされることは少なくないのです。

脆弱性を悪用したセキュリティ事故は日々発生しています。
SQAT.jpでは以下の記事でも取り上げていますので、ぜひあわせてご参考ください。

● 「定期的な脆弱性診断でシステムを守ろう!-放置された脆弱性のリスクと対処方法-
● 「備えあれば憂いなし!サイバー保険の利活用

脆弱性情報はWebサイトでチェックできる

脆弱性は、さまざまなソフトウェアやプラットフォームで日々発見されています。そうした情報は、多くの場合、ソフトウェアやプラットフォーム提供元のWebサイトに掲載されます。
少なくとも、自組織で利用している主要なプラットフォームに関しては、緊急性が高い脆弱性が出現していないかどうかを、提供元のWebサイトで定期的にチェックするとよいでしょう。

JVNを利用した脆弱性情報の正確な情報収集と活用法

一般社団法人JPCERTコーディネーションセンターとIPA(独立行政法人情報処理推進機構)では、公表された脆弱性情報を収集して公開するサービス「JVN(Japan Vulnerability Notes)」を共同運営しています。日本で利用されている大半のソフトウェアの脆弱性の情報は、このサイトでチェックできます。

脆弱性情報ソースと活用

インシデントやゼロデイの発生情報については、セキュリティ専門のニュースサイト、セキュリティエバンジェリストのSNSなどからも情報をキャッチできます。

情報の裏取りとして、セキュリティベンダからの発表やtechブログ等を参照することもと重要となります。攻撃の影響範囲や危険度を確認するには、Exploitの有無を技術者のPoC検証ブログやNVD等で確認することも有効です。

「脆弱性」はサイバー攻撃の端緒となる

サイバー攻撃の数は年々増加し続けており、その手口は高度化・巧妙化しています。このため、あらゆる企業・組織がサイバー攻撃の脅威にさらされています。そして、そして残念ながら、多くのWebアプリケーションやシステムには脆弱性が存在している可能性があります。情報漏えいなどの被害をもたらすサイバー攻撃の多くは、この「脆弱性」を悪用して行われます。脆弱性の放置は、サイバー攻撃を誘発し、事業活動に甚大な影響を及ぼしかねません。

脆弱性を突かれた場合のリスク

悪意のある第三者によって脆弱性を突かれてしまった場合、問題箇所の悪用、コンピュータ内部データ(情報)の盗取・改竄・削除、また他のコンピュータへの同様の悪事が可能になります。その結果、不正アクセスや自動的に動作させるウイルスやボットに感染する恐れもあります。また、システムやサービス全体という視点からは、設定に関して何らかの誤りがある場合など、設定ミスが脆弱性とみなされます。たとえば、ポートの開放に関する設定、権限管理、AWSをはじめとするクラウドサービスの設定ミスがセキュリティ事故を招いた例は枚挙に暇がありません。

「脆弱性が多い」と言われるソフトウェアの傾向

脆弱性が数多く報告されているのは、一体どんなソフトウェアでしょう。ひとつ共通することは「ユーザが多い」ということです。たとえば、皆さんがこのサイトをご覧になっているWebブラウザ、そのWebブラウザが動作するMicrosoft WindowsなどのOS、ビジネスでよく使われるPDFファイルを扱うAdobe Acrobat、WebサーバソフトのApache、データベースアプリケーションのMySQLなどです。いずれも、全世界に膨大な数のユーザを持つソフトウェアであり、規模のインパクトという点から、攻撃者にとって極めて魅力的、いわば人気があるのです。かつ、このようなソフトウェアでは、開発元において、脆弱性を早期に発見し、修正プログラムの公開、所定機関への報告を迅速に行う必要性が高いことから、報告件数が当然ながら多くなる傾向がみられます。

わかりやすい例としては、オンライン会議ソフトのZoomがあります。Zoomでは、2020年になって脆弱性が次々と発見されていますが、そこには、新型コロナウイルス対策の一環でテレワーク化が進み、Zoom利用者が爆発的に増えたという背景があります。攻撃者の格好のターゲットになったことと、Zoomの脆弱性の増加は、連動した現象なのです。

ここまでの説明でお気づきかもしれませんが、「脆弱性が多く報告されている」ことは必ずしも「品質が悪い」ことを意味するのではありません。脆弱性が存在してもそのことが報告・公表されていなければ、「脆弱性がある」とは認知されないわけです。

脆弱性対策の基本と企業での実践方法

脆弱性対策の基本的な考え方としては、システムの欠陥をつぶし、脆弱性を無くすこと(「攻撃の的」を無くすこと)が最も重要です。企業での実践方法としては以下の項目があげられます。

修正パッチの適用


衣服等の破れを補修する「継ぎ当て」や傷口に貼る「絆創膏」のことを英語で「パッチ(patch)」と言いますが、脆弱性を修正するプログラムも「パッチ」と呼ばれます。修正プログラムを適用することは「パッチをあてる」と言われたりします。パッチをあてることにより、システムに影響が及ぶ場合があります。適用にあたっては事前に調査を行い、必要に応じて十分な検証を実施してください。なお、自組織で開発したシステムに関しては、必ずテスト環境を用意し、パッチ適用による整合性チェックを行いましょう。

ソフトウェアやOSの定期的なアップデート

アップデートされた最新バージョンでは既知の脆弱性や不具合が修正されていますので、後回しにせずに更新を行うようにしてください。

セキュアプログラミングで脆弱性を作りこまない体制に

自組織で開発したソフトウェアやWebアプリケーション等の場合は、サービスが稼働する前の上流工程(開発段階)から、そもそも脆弱性を作り込まない体制を構築することが大切です。

また、テレワーク環境では、以上の項目に加え、クライアントサイドでのパッチ適用が適切に行われているかをチェックする体制を構築することも重要です。また、シャドーITの状況把握も厳格に実施する必要があります。

「IT部門が知らないサービスを勝手に利用され、結果として脆弱性の有無について未検証のクライアントソフトやブラウザプラグインが使われていた」という事態は防がねばなりません。

ツールを使って脆弱性を見つける

脆弱性を発見するためのソフトウェアは「チェックツール」「スキャンツール」「スキャナ」などと呼ばれます。以下に、代表的なものをご紹介しましょう。有償、無償のさまざまなツールが提供されていますので、機能や特徴を知り、ニーズに合致するものを試してみてはいかがでしょうか。

  有償ツール 無償ツール
Webアプリケーション向けAppScan、Burp Suite、WebInspect など OWASP ZAP など
サーバ、ネットワーク向け Nessus(一部無償)、nmap など Nirvana改弐、Vuls など

「脆弱性診断」サービスで自組織のソフトウェアの脆弱性を見つける

上記でご紹介したツールを使えば、脆弱性のチェックを自組織で行うことが可能です。しかし、前述の通り、「脆弱性が存在するのに報告されていない」ために情報がツールに実装されていないソフトウェアも数多くあります。また、一般に広く利用されているソフトウェアであれば次々に脆弱性が発見、公開されますが、自組織で開発したWebアプリケーションの場合は、外部に頼れる脆弱性ソースはありません。さらに、実施にあたっては相応の技術的知識が求められます。そこで検討したいのが脆弱性診断サービスの利用です。脆弱性の有無を確認するには、脆弱性診断が最も有効な手段です。

脆弱性診断サービスでは、システムを構成する多様なソフトウェアやWebアプリケーション、API、スマホアプリケーション、ネットワークなどに関し、広範な知識を持つ担当者が、セキュリティ上のベストプラクティス、システム独自の要件などを総合的に分析し、対象システムの脆弱性を評価します。組織からの依頼に応じて、「自組織で気付けていない脆弱性がないかどうか」を調べる目的のほか、「脆弱性に対して施した対策が充分に機能しているか」を検証する目的で実施することもできます。

対策が正常に機能しているかの検証を含めた確認には専門家の目線をいれることをおすすめしています。予防的にコントロールをするといった観点も含め、よりシステムを堅牢かしていくために脆弱性診断をご検討ください。

脆弱性との共存(?)を図るケースもある

最後に、診断で発見された脆弱性にパッチをあてることができないときの対処法をご紹介しましょう。

まず、「パッチを適用することで、現在稼働している重要なアプリケーションに不具合が起こることが事前検証の結果判明した」場合です。このようなケースでは、システムの安定稼働を優先し、あえてパッチをあてずに、その脆弱性への攻撃をブロックするセキュリティ機器を導入することで攻撃を防ぎます。セキュリティ機器によって「仮想的なパッチをあてる」という対策になるため、「バーチャルパッチ」とも呼ばれます。

また、脆弱性が発見されたのがミッションクリティカルなシステムではなく、ほとんど使われていない業務アプリであった場合は、脆弱性を修正するのではなく、そのアプリ自体の使用を停止することを検討できるでしょう。これは、運用によってリスクを回避する方法といえます。

なお、前項でご紹介した脆弱性診断サービスの利用は、脆弱性に対して以上のような回避策をとる場合にも、メリットがあるといえます。発見された脆弱性について、深刻度、悪用される危険性、システム全体への影響度といった、専門サービスならではのより詳細な分析結果にもとづいて、対処の意思決定を行えるためです。

まとめ

・サイバー攻撃の端緒となる脆弱性はプログラムの設計ミスなどによって生まれます。
・海外では脆弱性への対応を怠ったことで発生した情報漏えい事故で社長が辞任に追い込まれた事例もあります。
・脆弱性情報はベンダのWebサイトやJVNなどで公開されています。
・自組織のネットワークやソフトウェアなどの棚卸しを行い、それぞれのバージョンを把握しましょう。
・利用者が多いソフトウェアほど脆弱性が発見されます。必ずしも「脆弱性の報告数が多い=品質が低い」というわけではありません。
・脆弱性診断サービスは、自組織で開発したWebアプリケーションなどの脆弱性を発見するのに有効です。

関連情報

● 脆弱性診断の必要性とは?ツールなど調査手法と進め方

● 2019年下半期 カテゴリ別脆弱性検出状況


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

サイバー攻撃を行う5つの主体と5つの目的

Share

サイバー攻撃とは、コンピュータやネットワーク、Webアプリケーションの脆弱性などを利用し、情報の窃取やデータの改ざん、業務妨害、破壊活動などを行うことです。さまざまなサイバー攻撃の種類がありますが、個別の攻撃方法を理解すること以上に重要なのが、「誰が」「なぜ」その攻撃を行うかです。この点を理解することで、より効果的な対策を考えることが可能になります。

「サイバーテロ」「サイバー保険」そして今回のテーマである「サイバー攻撃」など、「サイバー」はコンピュータやインターネットに関連する物事を示す際の接頭辞として用いられますが、元々はアメリカの数学者ノーバート・ウィーナーが提唱した「Cybernetics:サイバネティクス(人工頭脳学)」という学問から生まれた言葉です。

サイバー攻撃は種類よりも攻撃主体と目的が重要

ひとたび「サイバー攻撃」でインターネット検索すれば、おびただしい数のサイバー攻撃の種類が一覧で表示され、詳しく解説されています。

しかし、たとえばあなたの家の窓が石を投げ込まれて割られた際に、その石の種類や名前、あるいは石を窓に投げ込む際に使用した器具のことを詳しく知りたいと思うでしょうか。まずは「誰が」「何の目的で」石を投げたのかが気になるに違いありません。

よく耳にするサイバー攻撃としては以下のようなものがあります。

APT攻撃 様々な攻撃手法を用いて、高度かつ継続的に侵入を試み、目的を達成する。
サプライチェーン攻撃 様々な攻撃手法を用いて、サプライチェーンの中の弱点を狙って、サプライチェーンの内部に侵入することを目的とする。最終的にAPT攻撃に発展することや、ランサムウェア攻撃に発展することも。
ランサムウェアあらゆるサイバー攻撃手法を用いてデータを暗号化し、身代金を要求する攻撃。APT攻撃やサプライチェーン攻撃の目的としての破壊活動につながる可能性もある。
ビジネスメール詐欺 巧妙ななりすまし、メールアドレス乗っ取りなどを中心とした各種のサイバー攻撃。

サイバー攻撃 5つの攻撃主体

サイバー攻撃は誰が行うのでしょうか。いろいろな考え方や分け方がありますが、以下では、大きく5つに分けて解説します。

1.愉快犯や悪意のある個人

このグループに分類される攻撃主体の特徴は攻撃に継続性がないことです。「愉快犯」とは、「標的型攻撃とは?」で解説したとおり、趣味や知的好奇心、技術検証など、悪意の伴わない迷惑行為が特徴です。多くは個人の趣味や研究の延長として行われます。「悪意のある個人」とは、同僚のメールを盗み読む、有名人のTwitterアカウントを乗っ取るなど、明確な悪意をもったサイバー攻撃者を指します。「愉快犯」も「悪意を持った個人」も、個別の差はあるものの攻撃の継続性や技術力・資金力に限界があるといっていいでしょう。

2.ハクティビスト

「アクティビスト(社会活動家)」という言葉と「ハッカー」を合わせた言葉である「ハクティビスト」は、サイバー攻撃を通じて社会的・政治的メッセージを表明します。

3.産業スパイ

企業が保有する各種開発情報や未登録特許など、さまざまな知的財産を盗むためにサイバー産業スパイが世界で暗躍しています。新薬研究や航空エンジン設計など、莫大な開発費を要する産業領域で先んじることが主な目的です。企業を超えたより大きな組織の支援を受けている場合には、豊富な資金を背景とした高い技術力を持ち、継続的に攻撃を行うことがあります。

4.国家支援型組織(ステートスポンサード)

国家が金銭面で下支えをしている攻撃グループを指します。主にAPT(Advanced Persistent Threat:高度で持続的な脅威)攻撃を行い、諜報活動や破壊活動を行うことが特徴です。3.の産業スパイ活動を行うこともあります。

5.サイバー犯罪組織

個人情報やクレジットカード情報などを盗み、その情報をマネタイズすることで資金を得るタイプの組織を指します。2018年のある調査では、世界全体でのサイバー犯罪による被害総額を約60兆円と見積もっています。一大「産業」となったサイバー犯罪には、多数の犯罪者が関わり、彼らは組織化・訓練され、高い技術力と豊富な資金力を持っています。「標的型攻撃」のほとんどは、国家支援型組織とサイバー犯罪組織によって行われていると考えられています。

ただし、たとえば愉快犯的なハクティビスト、知財窃取を受託する犯罪組織なども存在し、以上5つの主体は必ずしも明確に分けられるものではありません。

サイバー攻撃 5つの目的

サイバー攻撃が行われる目的は、以下のように5つにまとめることができます。

1.「趣味や知的好奇心」目的のサイバー攻撃

愉快犯が行うサイバー攻撃は、知的好奇心を満足させる、技術や理論の検証を行う等の目的で行われます。

2.「金銭」目的のサイバー攻撃

産業スパイや犯罪組織が行うサイバー攻撃は金銭を目的に行われます。彼らの活動も我々と同じく、経済合理性に基づいています。

3.「政治・社会的メッセージの発信」目的のサイバー攻撃

2010年、暴露サイトとして有名なウィキリークスの寄付受付の決済手段を提供していた決済サービス会社が、政治的判断でウィキリークスへのサービス提供を取り止めた際、決済サービス会社に対して、「アノニマス」と呼ばれるハクティビスト集団がDDoS攻撃を仕掛けました。このように、ハクティビストは、彼らが理想と考える正義を社会に対してもたらすことを目的にサイバー攻撃を行います。

4.「知的財産」目的のサイバー攻撃

産業スパイは、企業が保有するさまざまな営業秘密や開発情報、知的財産の窃取を目的にサイバー攻撃を行います。盗んだ知財をもとに事業活動等を行い、最終的に金銭的利益を得るわけです。なお、知財を目的としたサイバー攻撃は、一定期間、特定の産業を重点的に狙うなどの傾向があります。

5.「諜報」目的のサイバー攻撃

いわゆる諜報活動のために個人情報(通信履歴や渡航履歴を含む)を収集するなどの活動もあります。敵対関係にあるターゲットを標的とした破壊活動のほか、ときに自国の産業保護を目的として産業スパイ活動が行われることもあります。

なお、上記は、前項の5つの主体と同様、相互に関連し合い、はっきりと区分できるものではありません。もし知的好奇心から闇市場で販売されているランサムウェアを使ったら、その場合は金銭が目的のサイバー攻撃でもあることになります。また、犯罪組織の中には、「病院を攻撃しない」と表明することで医療従事者へのリスペクトを社会的に発信するような組織も存在します。

表で理解する、代表的なサイバー攻撃手法

最後に、代表的なサイバー攻撃手法を取り上げ、それぞれの攻撃でどのような手法が用いられ、どのような対象がターゲットになるのかを、表形式で見てみましょう。

具体的な攻撃手法の例 ターゲット
Webアプリケーションの
脆弱性を悪用する攻撃
・バッファオーバーフロー
・SQLインジェクション
・ディレクトリトラバーサル
・クロスサイトスクリプティング
 (XSS)
Webアプリケーション
不正アクセス・
不正ログイン
・Brute-Force攻撃
・パスワードリスト型攻撃
・パスワードスプレー攻撃
・内部不正
・有効なアカウントの
 窃取・売買・悪用
各種アプリケーションやシステム、ネットワーク
フィッシング・フィッシングメール
・スミッシング(フィッシングSMS)
・フィッシングサイト
・個人
・法人内個人
DoS攻撃・DDoS攻撃・フラッド攻撃
・脆弱性を利用した攻撃
・ボットネット悪用
・組織・企業
・国家
・社会・重要インフラ
・個人
のWebサービスなど
ゼロデイ攻撃修正プログラムが公開されていない
脆弱性に対する攻撃
・組織・企業
・国家
DNS攻撃・DoS攻撃
・DNSキャッシュポイズニング
・カミンスキー攻撃
・DNSハイジャック
 (ドメイン名ハイジャック)
・企業・組織
・国家
・個人
のWebサービスなど
ソーシャル
エンジニアリング
・会話等によるクレデンシャル
 情報等の窃取
組織・企業内の個人

ここで挙げられた攻撃手法のうち特に注意が必要なものは、SQAT.jpで今後詳しく解説していきます。

まとめ

・サイバー攻撃とはWebアプリケーションの脆弱性など、さまざまなセキュリティホールを悪用して攻撃を行い、情報窃取などを行うことです。
・効果的なセキュリティ対策のためには、サイバー攻撃の種類以上に、その目的や攻撃主体について知ることが重要です。
・サイバー攻撃主体の分類にはいろいろな考え方がありますが、「愉快犯や悪意のある個人」「ハクティビスト」「産業スパイ」「国家支援型組織」「サイバー犯罪組織」の5つに整理することが可能です。
・サイバー攻撃の目的は「趣味や知的好奇心」「金銭」「政治・社会的メッセージの発信」「知的財産」「諜報」の5つに整理できます。ただしこれも諸説あります。

関連情報

●標的型攻撃とは? 事例や見分け方、対策をわかりやすく解説

●高まるAPT攻撃の脅威

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

マルウェアに感染したら
-マルウェアの種類と対策、ウイルスとの違いは-

Share

マルウェアは、コンピューターやモバイルデバイスを標的にする悪意のあるソフトウェアの総称です。以前よく聞かれていたのは「ウイルス」ですが、いまや攻撃の手口は「ウイルス」という言葉で表せる範囲を超え、多様化・巧妙化しています。

もしもマルウェアに感染したら、どのような対処をとればよいのでしょうか。また、感染する前にできる予防策として何か有効でしょうか。
本記事を活用し、適切な対策を講じ、マルウェア攻撃のリスクを最小限に抑えましょう。

マルウェアとは

「マルウェア」とは「malicious(悪意のある)software(ソフトウェア)」の略称です。マルウェアは、コンピュータ、サーバ、クライアント、コンピュータネットワーク等に損害を与えるため、あるいはユーザの意図や利益に反する活動を行うために設計されたソフトウェアです。さまざまなタイプのマルウェアが存在します。

ウイルスとマルウェアの違い

「ウイルス」はマルウェアの一種です。インターネット黎明期、「ウイルス」と呼ばれるプログラムの多くは、コンピュータサイエンスを学ぶ学生などによって、実験やイタズラ目的で開発されていました。

諸説ありますが、実験やイタズラの範疇を超える、明確な悪意を持った犯罪者や組織によってウイルスが作られはじめた2005年頃から「マルウェア」という言葉が使われるようになりました。

こんにちマルウェアは、サイバー犯罪者や犯罪組織、各国の政府などによって開発され、個人情報や金融情報、知的財産、機密情報を盗んだり、プライバシーを侵害する意図で利用されています。

マルウェアの代表的な種類

代表的なマルウェアとしては、以下のようなものがあります。

ウイルス 多くの場合、一見無害に見えるファイルの中に隠されています。ユーザによりファイルをクリックされ実行されることで自己増殖を行い、データの破壊などの有害な動作を行います。
ワーム ワームはウイルスとは異なり、ファイルの中に隠れていることはありません。自己増殖もワームだけで行うことができます。ウイルスやワームは感染したコンピュータだけに影響を及ぼすものではなく、コンピュータネットワークを経由して他のコンピュータに拡散します。
トロイの木馬 無害なあるいは有益なプログラムに偽装してユーザを油断させ、インストールを行わせるマルウェアです。ウイルスやワームと異なり自己増殖することはありません。古代ギリシャ時代、トロイの街を攻撃するため、贈り物に見せかけた大きな木馬に兵士を潜ませて侵入を行った方法が名前の由来です。主にバックドア*1と呼ばれる不正な裏口を作ったり、オンラインバンキングなどのパスワードを盗んだり*2、別のプログラムをダウンロードするなどの動きをします。
スパイウェア 個人や組織の情報を同意なしに収集したり、その情報を攻撃者に向けて送信することを目的としたマルウェアです。
アドウェア 多くはユーザが知らないうちにインストールされ、インターネット閲覧の際にユーザが望まない広告を表示します。すべてが違法とは言えない場合もあります。
ランサムウェア ユーザのファイルやデータを勝手に暗号化し、身代金(ランサム)を支払うまで復号しないと脅すマルウェアです。身代金を払ってもデータが元に戻るとは限りません。
キーロガー コンピュータのキーボード入力を記録するソフトウェアで、本人の同意や法的根拠なく使用された場合にマルウェアとみなされます。パスワードや機密情報を盗むために使用されます。
バックドア*1 英語で「裏口」の意味で、一度侵入したシステムなどに次回以降も不正にアクセスする際、それを容易にするために設けられる通信接続手段を指します。
ボット マルウェアによって乗っ取られ、遠隔からの指示によって自由に操られるようになったコンピュータを、「ボット」または「ゾンビPC」と呼びます。複数のボットをボットネットとして制御し、DDoS攻撃等のサイバー犯罪に悪用します。
バンキングマルウェア*2 オンラインバンキングのIDやパスワード、クレジットカード情報などを盗むマルウェアです。不正送金などの被害が報告されています。
ファイルレスマルウェア 通常のマルウェアはコンピュータのハードディスク内に存在しますが、コンピュータのRAM内でしか動作しないように設計されているマルウェアです。

マルウェア感染の経路:3大感染経路は「電子メール」「Web閲覧」「記憶媒体」

マルウェアの感染経路としては、大きく「電子メール」「Web閲覧」「記憶媒体」の3つが挙げられます。

「電子メール」経由の感染 標的型攻撃メールなどで、メールの添付ファイルを開いたり、文中に記載されたURLをクリックすることでマルウェアに感染します。
「Web閲覧」経由の感染 単にWebサイトをブラウザで見るだけで感染する「水飲み場型攻撃」などが知られています。
 USBメモリなどの
「記憶媒体」経由の感染
USBメモリやCD-ROM、DVD、外付けHDDなど、各種記憶媒体などもマルウェアの感染経路として悪用されます

その他にも、ファイル共有ソフトで手に入る音楽や動画ファイルを装ったマルウェアや、ソフトウェアのニセのアップデートを装うものなど、さまざまな感染経路が存在します。

マルウェアに感染したらどうなる?:マルウェア被害と症状

実験やイタズラ目的で開発されたマルウェアの多くは、ユーザに派手なメッセージを見せたり、アドレス帳にあるメールアドレス宛に手当たり次第に勝手にメールを送ったり、あるいはPCの挙動を重くするなど、感染したことが明白である症状を呈したり挙動をするものが少なくありませんでした。

現在も、オンラインバンキングで不正送金を行うマルウェアや、重要データを暗号化して身代金要求を行うランサムウェアなどは、目に見える被害や症状を示すマルウェアといえるでしょう。

しかし、前述したようなサイバー攻撃の目的の変化によって、ユーザにまったく感染を気づかせないマルウェアも増えています。

一連の攻撃活動を行った後で、自らを消去して完全に痕跡を消す自己消滅型のマルウェアも存在しており、すべてのマルウェアに自分で気づくことはおよそ不可能といえます。

マルウェアに感染したらどう対処すべきか

もしマルウェア感染したことが明らかであるならば、Wi-Fi機能のOFFやLANケーブルを抜くなどのネットワーク切断はすぐに行った方がいいでしょう。ネットワークを経由して感染を広げるインターネットワームなどの拡大を抑えることができます。

一方でPCやサーバの電源を落とすことは避けてください。感染経緯の究明などに利用できる証拠が失われることがあり、事故調査や、その後の適切な対策実施に悪影響を及ぼします。

多くの会社で、マルウェアに感染した場合の対応手順が決められています。まずはネットワークを切断し、速やかに情報システム部門やネットワーク管理者に連絡して指示に従ってください。

マルウェアの検知・駆除ツール「ウイルス対策ソフト」

こうしたマルウェアを検知・駆除する方法として使われるのが「ウイルス対策ソフト」(「アンチウイルスソフト」)です。ウイルスの対抗手段であることから、古くは「ワクチン」とも呼ばれました。

ウイルス対策ソフトは「パターンマッチング」と呼ばれる方法でマルウェアを検知します。ウイルス対策ソフトがあらかじめ持っている「パターンファイル」「定義ファイル」と呼ばれるマルウェアの特徴に関するデータと参照することで、マルウェアを検知します。

しかしパターンマッチングでは、まだ出回っていない新しいマルウェアを検知できません。そのため、プログラムの挙動を分析してマルウェアを検知する「ヒューリスティック分析」「振る舞い検知」などの技術が開発されました。

一方で近年、膨大な数の新しいマルウェアが作られたり、ブラックマーケットにおいて主要なアンチウイルスソフトでは検知できないマルウェアが販売されるなど、ウイルス対策ソフトだけでは充分な対策とは言えなくなっています。

マルウェアに感染する前にできる「予防対策」

各ユーザのクライアントPCのマルウェア対策としては、ウイルス対策ソフトの利用がもっとも一般的な方法です。また、最近ではEDR(Endpoint Detection and Response)製品などを利用するケースも増えています。これに加えて、3大経路の1つである電子メールからの感染を防ぐ対策として、標的型攻撃メール訓練によるユーザ教育が有効でしょう。また、ランサムウェア攻撃を受けた場合の復旧に備えたデータのバックアップなども重要になります。

一方で、管理者の観点からはマルウェア感染の脅威が及ぶのはPCだけではありません。自社が提供するWebサイトにマルウェアや不正なコードを埋め込まれる「Web改ざん」にも同様の注意が必要となります。こうした攻撃を許してしまう要因はクロスサイトスクリプティング(XSS)などの脆弱性です。そのような脆弱性が存在しないかどうかは、Webアプリケーション診断などによって感染の前に明らかにすることができます。Webサイトの改ざんを検知するサービスも存在します。

また、これは感染予防対策ではありませんが、感染したことにいちはやく気づくために、SOC(Security Operation Center)サービスなどを利用して外部との不正な通信を検知したり、ログを収集して分析することも有効です。

マルウェアによる攻撃手法は常に進化しています。最新の情報を常にチェックし、適切な対策を講じることで、マルウェアのリスクを最小限に抑えることができます。

まとめ

・マルウェアとは「malicious(悪意のある)software(ソフトウェア)」の略称で、ウイルスもマルウェアの一種です。
・ウイルス対策ソフトだけでは検知できないマルウェアも存在します。
・マルウェアの主な感染経路はメール・Web・USBメモリなどの記憶媒体です。
・もし感染に気づいたらネットワークを切断します。ただし電源を切ってはいけません。
・予防対策として標的型攻撃メール訓練やセキュリティ診断なども有効です。

関連情報

●標的型攻撃とは? 事例や見分け方、対策をわかりやすく解説

●セキュリティ診断の必要性とは?

※外部サイトにリンクします。

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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

テレワーク環境下における営業秘密の保護

Share

緊急事態宣言が解除されて1か月余り。通常勤務に戻る企業もあれば、テレワークを存続させる企業もあり、対応はさまざまです。不動産業界の調べによれば、東京都心のオフィスビルの空き室率は2020年3月以来微増しており、テレワークを今後も継続する企業は少なくないようです。

もともと欧州ではワークライフバランスの立場から在宅勤務(テレワーク)を推進してきました。オランダでは2016年に労働者が自宅を含む好きな場所で働く権利を認める法律が施行されています。フィンランドでも今年1月に同様の法律が施行されました。コロナ禍によってこうした動きは一層加速されており、米国は民間企業主体ではあるものの、やはり大手IT企業を中心に在宅勤務を義務化・恒久化する動きがあります。

しかしながら、日本においてはテレワークが欧米ほど浸透していません。国土交通省が今年3月に実施した「令和元年度テレワーク人口実態調査」では「会社でないと閲覧・参照できない資料やデータがあった」のは26.8%、また、セキュリティ対策に不安があったのは3.4%とありました。情報へのアクセス整備やセキュリティ対策不備に伴う漏えいへの不安がテレワーク推進の妨げになっていると考えられます。

テレワークにおける情報漏えいの不安

テレワークの場合、自宅での「在宅勤務」、出先や移動中に行う「モバイルワーク」、シェアオフィスなどを利用する「サテライトオフィス」のいずれにしても、インターネットを通じて業務データを社外で利用することに変わりありません。また、作業者が使用しているPCに重要なデータをダウンロードして作業する場合、セキュアゾーンで実施されないことも多いでしょう。そこにセキュリティ上の不安があるものと思われます。

総務省「テレワークセキュリティガイドライン第4版」においても、起こりうる事故として「情報漏えい」「重要情報の消失」を挙げています。確かに、企業が保有する設計図・製造ノウハウ・調査研究データなどの技術的な情報、取引内容・顧客リスト・財務データなどの営業上の情報は、事業存続および競争力強化にとって重要な情報資産であり、漏えいすることによるリスクははかりしれません。こうした懸念から、テレワークへの切り替えを躊躇する向きもあるでしょう。

そこで、適切にセキュリティを確保して情報流出の不安を解消しながらテレワークを実施できるよう、経済産業省は5月7日、「テレワーク時における秘密情報管理のポイント (Q&A解説)」を公表しています。以下に、そのポイントをみていきましょう。

「不正競争防止法」により保護される営業秘密(機密情報)

セキュリティ対策によって保護すべき、企業が保持する「営業秘密」は、一定の要件を満たすことで不正競争防止法の下で保護されます。法的保護を受けることにより、例えば電子データで取り扱われている機密情報がセキュリティの脆弱性を突かれて漏洩した場合でも、差止請求や損害賠償請求などが可能です。このため、事業における金銭的被害や信用失墜といったリスクを軽減できます。

ただし、営業秘密として法的に認められるためには、対象となるデータに対して以下の条件が整っていることが必要です。

1.秘密管理性:その情報が秘密であるとわかるように管理されていること
2.有用性:事業活動に役立つ情報であること
3.非公知性:世間一般に知られていないこと

「秘密管理性」の趣旨は、「企業が秘密として管理しようとする対象(情報の範囲)が、従業員等に対して明確化されることによって、従業員等の予見可能性、ひいては経済活動の安定性を確保する」ことにあるとされています。つまり、情報が営業秘密として保護されるためには、「秘密である」こと自体をはっきり示す必要があります。

「非公知性」は、営業秘密保有者の管理下以外では一般的に入手することができない状態とされています。このため、営業秘密としての条件を満たすには、容易に人に見られたり、聞かれたりしないようにしなければなりません。

テレワーク環境で営業秘密を保護する対策

テレワーク環境下で、秘密管理性と非公知性の要件を満たして情報を保護しつつ、情報漏えいを防止するには、状況に応じて以下のような対策が挙げられます。

状況別 対策の例
テレワーク対応導入の第一歩 ●営業秘密管理規程、情報取扱規定等をテレワークに即した内容に改訂
●諸規程の従業員に対する周知徹底
●情報に応じたアクセス権者の設定 等
業務における情報持ち出しおよび
社外からのアクセス
●データのファイル名や当該データ上に「㊙」(マル秘)・「社内限り」等の秘密であることの表示を付す*2
●情報のコピー・持ち出しにおける上長等の事前許可/返却・破棄ルールの周知・徹底と持ち出し記録の整備
●紙の資料・PC等を机上等に放置しないといった取扱いルールの徹底
●ID・パスワードによるアクセス制限の実施
●チャットツールで営業秘密についてやりとりするスレッドと参加者を限定 等
社外作業 ●PCにのぞき見防止フィルム等貼付の徹底
●音声が漏れない場所でのオンライン会議実施徹底
●公共無線LANの使用禁止、従業員のポケットWi-Fi・テザリングの禁止、業務使用Wi-Fiの貸与 等
情報漏えい、不正持ち出しの防止 ●メールの転送・添付制限、送信前の上長承認、上長のCC追加設定
●遠隔操作でPC内データを削除できるツールの利用
●PCに対するUSB、スマホ接続不可設定
コピーガード付き記録媒体の利用 等

営業秘密として秘密管理性要件を満たすと認められる技術的要素

テレワークにおける情報流出対策として規程を整備し、徹底した従業員教育を行ったとしても、所詮は人間が実施することであるため、悪意の有無にかかわらず、すべてが絶対確実に守られるとは言い切れません。そのため、前述の対策の例にも、技術的に強制するような仕組みがいくつか含まれています。

アクセス制御と権限管理の徹底

データ管理における秘密管理性要件については、通常、アクセス制御が実施されていることをもって、「秘密である」ことを示すと見なされています。これは、アクセス制御の基本的な考え方が、当該情報を知るべき者だけが情報にアクセス可能であるべきという「Need to Know」の原則に基づいていることと関係があります。アクセス制御とは、正規に承認されたユーザにのみコンテンツへのアクセスを許可するセキュリティ対策だからです。

このため、秘密管理性の要件を満たすためには、アクセス制御自体が適正に実施されている必要があります。例えば、同じアカウントを複数の従業員が使い回しているような状態や、パスワードに社員番号をそのまま当てはめていて他人が容易に推測可能な状況の場合、秘密管理措置を講じていないと判断される恐れがあります。

アクセス制御が「対象へのアクセスそのものを制御する」のに対し、「行為の実行権限を管理する」のが権限管理です。権限管理とは、ログインによってWebシステムやファイルサーバへアクセスするためのユーザを認証するシステムにおいて、各ユーザアカウントの役割を定義し、データに対する閲覧・編集等、実行できる処理についての権限を付与・管理することを言い、当該ユーザに対して必要最低限の権限を付与する「最小権限の原則(Least Privilege)」を適用します。データの重要性や種類に応じて、特定のグループだけが編集権限を持ち、他の従業員には閲覧のみを許可するといった設定です。

適正なアクセス制御・権限管理のどちらが欠けても「脆弱なシステム」であると言わざるを得ません。

認証機構の堅牢化

アクセス制御に欠かせない認証機構ですが、IDとパスワードによる単要素認証は、リスト型ハッキング攻撃等の標的となりやすいため、テレワーク導入・継続に備え、パスワード強度に対するポリシーの見直しをお勧めします。現在、セキュリティの各種基準・仕様においては8文字未満のパスワードは脆弱であるとみなされており、14文字以上のパスワードが推奨されています。流出したパスワードや汎用的で推測容易なパスワードを排除する実装の導入も有効です。

しかしながら、ユーザにとっては長いパスワードを複数覚えておくのは至難の業であるため、パスワードの使いまわしもなくならないでしょう。これを防ぐには、ID/パスワード以外に、認証要素(指紋や顔等の生体認証、またはワンタイムパスワードトークンやSMS等の所有物認証)を1つ以上追加した、多要素認証の導入をお勧めします。

この他、データの管理についても注意が必要です。データをUSBやDVDに記録できないようにする、プロジェクト終了後のデータ消去について確認する手段を講じるなどです。

テレワーク導入・継続における技術的要素について、詳しくはこちらもご参照ください

法的要件の確認にも有効なセキュリティ診断

営業秘密として保護されるべき法的要件を技術的な側面で満たしているかどうか確認する有効な手段に、セキュリティ診断があります。営業秘密に当たる情報を扱っているWebアプリケーション、ネットワーク(プラットフォーム)、スマホアプリ、IoT機器等に対し、第三者であるセキュリティ専門企業による診断を受けることをお勧めします。

先に述べた、アクセス制御や権限管理が適切に導入・運用されているかも、セキュリティ診断によって確認できます。

自らは気づいていない脆弱性を洗い出して悪用された場合のインパクトを事前に調査し、技術的に対応できること、対応が難しければ法的保護を受けるために講じるべき回避策や代替手段として何を整備しておくべきかを検討するなど、リスク対応策を検討しておくことが事業継続の肝となります。


参考情報

・テレワーク時における秘密情報管理のポイント (Q&A解説)
https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/teleworkqa_20200507.pdf

・逐条解説 不正競争防止法
https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/20190701Chikujyou.pdf


まとめ

・テレワークは緊急事態宣言後も一定の割合で継続される見込み
・テレワーク導入・継続における情報流出の不安には、経済産業省による「テレワーク時における 秘密情報管理のポイント (Q&A解説)」が対策のヒントになる
・テレワーク環境下でも、会社の重要情報を「不正競争防止法」による法的保護の対象である「営業秘密」として管理することが肝要
・適正なアクセス制御と権限管理は営業秘密の秘密管理性要件を満たす技術的なセキュリティ対策である
・機密情報を扱うシステムに対するセキュリティ診断の実施は、リスク対策における技術的な対応策と法的保護策の切り分けにも活用できる

関連情報

●<インタビュー>上野 宣 氏 / ScanNetSecurity 編集長

●<コラム>「ゼロトラストアーキテクチャ」とは?

Security Report TOPに戻る
TOP-更新情報に戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像