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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

「セキュリティ診断」とは何か?セキュリティ診断には脆弱性診断、ソースコード診断、ペネトレーションテストなどの方法があります。今回は、企業にセキュリティ診断が不可欠な背景を説明します。また、診断以外のセキュリティ対策にも触れます。

セキュリティ診断の必要性とはのサムネ

サイバー攻撃や組織における管理またはシステムの設定不備・不足等が原因となり、機密情報等の漏洩事故および事件が相次いで発生しています。東京商工リサーチの調べによれば、上場企業とその子会社で起きた個人情報漏洩または紛失事故・事件件数は2021年で137件となり過去最多を更新しました。*1実際に企業がデータ侵害などの被害を受けてしまい、機密情報等の漏洩が発生してしまうと、システムの復旧作業に莫大なコストがかかるほか、データ侵害によるインシデントが信用失墜につながることで、 深刻なビジネス上の被害を引き起こします。被害を最小限に抑えるために、適切な事故予防、攻撃対策をとっていくことは、企業の重要な業務のひとつとなっています。

セキュリティ対策やセキュリティ診断は、企業にとっていまや基幹業務に不可欠であり、社会的責任でもあります。この記事ではセキュリティ診断の内容と必要性などを解説します。

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

セキュリティ診断とは、システムのセキュリティ上の問題点を洗い出す検査のことを指します。脆弱性診断、脆弱性検知、など呼び方もさまざまで、また対象によってソースコード診断、システム診断、Webアプリケーション診断、ペネトレーションテストなどに分類されます。

なお、複数の診断方法のうち、同様の診断をセキュリティベンダーや診断ツール提供者がそれぞれ微妙に異なる名称で呼んでいるケースもあります。

「セキュリティ診断」という用語は、単に「脆弱性診断」を指すこともあれば、セキュリティに関するさまざまな診断や評価全体を包括して「セキュリティ診断」と呼ぶ広義の使い方もあります。

「セキュリティ」には、情報セキュリティだけではなく、デジタル社会へのリスク対応全般が含まれる場合もありますが、「セキュリティ診断」という用語は、企業など組織の事業における(情報)セキュリティリスクの低減を主な目的とした検査のことをいいます。

資産である情報の「機密性」「完全性」「可用性」を守るため、セキュリティ診断を行うことで、情報セキュリティの観点からみた構造上の欠陥や、組織体制、あるいは運用上の弱点を見つけることができます。発見された問題に対し優先順位をつけて対策を実施することで、より堅牢なシステム・環境・体制を構築することができます。

企業に求められる情報セキュリティ対策の例

企業が実施するセキュリティ対策のうち、よく話題にあがるものをいくつかピックアップして説明します。

不正アクセス対策

不正アクセス対策のサムネ

不正アクセスとは、本来アクセス権限を持たない者が、何らかの手段を用いて第三者の情報にアクセスすることをいいます。なりすまし不正侵入といった形が一般的です。不正アクセスによって、個人情報や知的財産が奪われる、サーバやシステムが停止するなど、企業活動に影響するリスクが生じます。不正アクセスに対しては、「不正アクセス行為の禁止等に関する法律(不正アクセス禁止法)」によって、アクセス管理者にも次の管理策を行う義務が課されています(ただし、罰則はありません)。
・識別符号の適切な管理
・アクセス制御の強化
・その他不正アクセス行為から防御するために必要な措置
セキュリティ診断を通じてシステムに存在する弱点を洗い出し、発生箇所を特定することで、こうした不正侵入などへの対策を立てやすくする効果があります。

脆弱性対策

脆弱性とは、一つ以上の脅威によって付け込まれる可能性のある資産または管理策の弱点をいいます。脅威とは、「システム又は組織に損害を与える可能性がある、望ましくないインシデントの潜在的な原因」で、いわばシステムにおけるバグのようなものです。それらの脆弱性は、「危険度を下げる」「蔓延を防ぐ」「影響度を下げる」ことで、悪用されにくくすることができます。

脆弱性対策とは、これらの角度からシステムの欠陥をつぶしていく行為ともいえます。利用しているソフトウェアの既知の脆弱性をアップデートやパッチの適用で常に最新版に保ったりすることや、システム開発の場面でそもそも脆弱性を作りこまないように開発することなどが、その典型例です。

標的型攻撃対策

近年、「高度標的型攻撃(APT)」と呼ばれる、新しいタイプの攻撃が警戒されるようになりました。もともと、標的型攻撃とは、特定の企業や組織に狙いを定めてウイルスメールを送るなどの攻撃を仕掛けるものでしたが、高度標的型攻撃は、特定のターゲットに対して長期間の調査と準備を行い、ときには社内のネットワーク構成図や会社組織図、キーパーソンの休暇の取得状況まで調べ上げたうえで、サイバー攻撃を仕掛けてきます。

標的型攻撃対策のサムネ

従来、標的型攻撃の対策としてはセキュリティ意識を高める訓練が主でしたが、今では「侵入されること」を前提に、セキュリティ機器を使った多層防御システムを構築することの大切さが、広く認識されるようになってきました。高度標的型攻撃に特化したセキュリティ診断を受けることで、攻撃被害スコープを可視化したり、脅威リスクのシミュレーションを行うことができます。

運用を含むリスクアセスメント

システムが技術的に強固に守られていても、アクセス用のIDとパスワードを付箋紙に書いてモニターに貼り付けていたら、安全は保たれるべくもありません。

システムなど技術的側面からだけでなく、作業手順や業務フロー、作業環境、組織のルールなどの運用面も含めてリスク評価を行うことを「リスクアセスメント」と呼びます。リスクアセスメントを通じて、リスクの棚卸による現状把握ができ、優先順位をつけて改善策を講じていくことが可能になります。

セキュリティ診断の方法と種類

セキュリティ診断の分類はいくつかあります。
<診断対象による分類>
 ・Webアプリケーション脆弱性診断
 ・ネットワーク脆弱性診断
 ・ソースコード診断
 ・スマホアプリ脆弱性診断
 ・ペネトレーションテスト
 ・クラウドセキュリティ設定診断
 ・IoT診断

<ソースコードや設計書の開示の有無による分類>
 ・ホワイトボックステスト
 ・ブラックボックステスト

<診断実施時にプログラムを動かすかどうかによる分類>
 ・動的解析
 ・静的解析

ホワイトボックステスト/ブラックボックステスト、動的解析/静的解析については、SQAT.jpの以下の記事でご紹介しています。こちらもあわせてご覧ください。
「脆弱性診断の必要性とは?ツールなど調査手法と進め方」

Webアプリケーションセキュリティ診断

Webアプリケーションに対して行う診断です。事業活動に欠かせないWebサイトはデータの宝庫です。ハッキング対象の約7割がWebサイトであるともいわれています。ひとたびデータ侵害が起こると、事業継続に影響を与えかねないインシデントを引き起こすリスクがあります。

ネットワークセキュリティ診断

サーバ、データベース、ネットワーク機器を対象として脆弱性診断やテスト、評価を行います。搭載されているOS、ファームウェア、ミドルウェアなどのソフトウェアについて、最新版か、脆弱性がないか、設定に不備がないかなどを確認します。ネットワークの脆弱性対策をすることで、サーバの堅牢化を図る、不正アクセスを防止するなどの効果を得られます。

ソースコードセキュリティ診断

WEBアプリケーションは、プログラムの集合体であり、脆弱性はプログラム処理におけるバグであるといえます。入力チェックやロジック制御に、バグ(考慮不足)があるから、想定しない不具合が発生すると考え、プログラムコード(ソースコード)を調べていくのがソースコード診断です。ソースコード診断はプログラムに対するセキュリティ観点でのチェックであるとともに、開発工程の早い段階で、脆弱性を検出することが可能になります。

セキュリティ診断で未然に事故を防ごう

セキュリティ診断で未然に事故を防ごうのサムネ

セキュリティ診断のひとつとして挙げた脆弱性診断には、さまざまな診断ツールが存在しており、無料で入手できるものもあります。しかしツールの選定や習熟には一定の経験や知見が求められ、そもそも技術面だけでは企業のセキュリティを確保することはままなりません。セキュリティの専門会社の支援を受けて、客観的な評価やアドバイスを受けるのも有効な手段です。

セキュリティ専門会社による脆弱性診断を実施することで、日々変化する脅威に対する自システムのセキュリティ状態を確認できるため、適時・適切の対策が可能です。予防的コントロールにより自組織のシステムの堅牢化を図ることが事業活動継続のためには必須です。

まとめ

  • Webアプリケーションセキュリティ診断、ネットワークセキュリティ診断、ソースコード診断、セキュリティに関するさまざまな診断やテストが存在する
  • 不正アクセスなどの攻撃を防ぐためシステムの脆弱性を見つけて対策することが必須
  • 技術的対策だけでセキュリティを担保することは難しい
  • 人間の脆弱性や業務運用までを含む包括的な視点で組織にひそむリスクを洗い出すことも重要
セキュリティ診断サービスのサムネ

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

SQLインジェクションの脆弱性、企業が問われる2つの責任とは

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

この記事では、XSS(クロスサイトスクリプティング)と並ぶ、Webアプリケーションの代表的脆弱性といえる「SQLインジェクション」について解説します。

XSSとSQLインジェクションの違いや、SQLインジェクション攻撃が実際に行われるまでの手口、セキュリティ会社がどのようにSQLインジェクションの脆弱性の有無を判断しているかなどを解説します。また、SQLインジェクションを放置した責任を企業が問われた裁判の判決も紹介し、最後にSQLインジェクションの対策方法を考えます。

SQLインジェクションとは

「SQLインジェクション」とは、データベースを操作する「SQL」という言語を悪用して、Webアプリケーションの入力フィールドに悪意のあるSQL文を入力するなどして行うサイバー攻撃のことです。SQLインジェクション攻撃によって、なりすまし、Webサイトの改ざん、あるいはデータを盗んだり破壊したりといったことが可能になります。

XSSとSQLインジェクションの違い

もうひとつの代表的な脆弱性であるXSSは、Webサイトにアクセスしているユーザに対して攻撃を行います。一方、SQLインジェクションは、攻撃対象がユーザではなくデータベースです。データベースに登録されている全てのデータが攻撃対象になり得るという点で、SQLインジェクションの方が、被害が発生した場合の規模がより大きくなる傾向があります。管理者にとって見つかったらとても嫌な脆弱性のひとつです。

SQLインジェクション攻撃が行われる仕組み

SQLとはデータベースを操作するための言語です。MySQL、PostgreSQL、Oracleなど、さまざまなデータベースで広く使われており、これらのデータベースは、すべてSQLインジェクションの攻撃を受ける可能性があります。

「Shodan(ショーダン)」というちょっと変わった検索エンジンでは、Webサイトのコンテンツではなく、インターネットに存在するコンピュータやIoT機器を探せるのですが、このShodanで「sql」と検索すれば、サーバヘッダに「SQL」が入ったコンピュータやサーバの一覧が山ほどリストアップされます。

サイバー攻撃者は、しばしばこうした情報をもとに標的を探し出し、一覧の中から、SQLインジェクションの脆弱性が放置されているサーバをさまざまな方法で絞り込み、攻撃を実行します。

脆弱性診断の現場でSQLインジェクションはどのぐらい見つかるのか

弊社が実施しているWebアプリケーション脆弱性診断の2020年上半期統計(14業種延べ533企業・団体。4596システムの診断結果)では、SQLインジェクションは、検出される全脆弱性(システム全体の83.9%)のうち1%ほどとなっています。被害が発生した場合のインパクトが極めて大きな脆弱性ですので、これは決して小さい数字であるとは言えません。

SQLインジェクションを検出する方法

一般的なやり方としては、入力フィールドに本来許可してはいけない文字列を設定した場合にWebアプリケーションがどう反応するか、といったことを観察し、SQLインジェクションの脆弱性の有無を診断します。こうした文字列を「診断文字列」と呼ぶことがあります。ちなみに、SQLインジェクションの脆弱性が存在する場合に、個人情報の取得ができるかどうかまでを実際にやってみるのがペネトレーションテストです。

SQLインジェクションの脆弱性を突かれた被害事例、企業が負う2つの責任

SQLインジェクションの脆弱性への対策を怠った結果、Webサイトが攻撃を受けて被害が発生してしまった場合、企業はどのような責任を負うことになるのでしょうか。

運営責任

あるショッピングサイトの被害事例からご紹介しましょう。このサイトでは、SQLインジェクションによる攻撃を受け、クレジットカード情報を含む最大10万件の個人情報が漏えいしました。その結果、営業停止による機会損失に加え、顧客に対する賠償用買い物ポイントの付与、お詫び状送付、被害者対応、インシデントの調査などに多くの費用がかかりました。

これは、欠陥を含むシステムを運営していた代償であり、「運営責任」を問われたかたちです。

開発責任―東京地裁判決より

続いて、運営責任ではなく、システムの「開発責任」を問われた例として、2014年にあった裁判の判決(平成23年(ワ)第32060号)をご紹介します。

とある企業の依頼で開発、納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性が存在し、その結果、不正アクセスによる情報漏えい事故が発生しました。開発を依頼した側の企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として裁判に訴えました。東京地方裁判所はそれを認め、開発会社には約2,200万円の損害賠償支払いが命じられました。

SQLインジェクションはより過失度が大きい脆弱性

情報漏えいとは? 代表的な原因や求められる対応策」で解説していますが、どんな情報が漏えいしたかによって、情報漏えいの深刻度は異なります。たとえば、メールアドレスとセットでそれに紐付くパスワードも漏えいしていたとしたら、メールアドレスのみが漏えいした場合と比べ、事態はより深刻です。

そして、データベースに保存されるのは重要な情報ですから、そこを攻撃対象とするSQLインジェクションは、対策の優先順位が非常に高い脆弱性だといえます。対策を怠り、事故を招いた場合、社会やユーザからは非常に厳しい目が向けられるでしょう。

たとえば、納品したオンラインショッピングのシステムにSQLインジェクションの脆弱性が存在していたら、上述のように債務不履行、納品物の瑕疵とみなされ、SQLインジェクションの脆弱性を放置したままWebサイトを運営していたら、管理義務を果たしていないとみなされる可能性があるのです。

さらに言えば、Webサイトの開発責任が他社にあり、他社から賠償を受けられたとしても、Webサイトの運営側ではエンドユーザに対してなんの申し開きも立ちません。たとえばこれは、食中毒を出したレストランが、顧客に対して「傷んでいた食材を納品した卸業者が悪い」と言えないのと同じことなのです。

SQLインジェクション対策

重要な情報が集まるデータベースは、守るべき優先度がきわめて高く、SQLインジェクション対策としてさまざまな取り組みが行われています。

まず、DevSecOpsの考えのもとでセキュアコーディングを行ったり、開発段階で脆弱性が作り込まれていないかソースコード診断を行ったりすることは、コストパフォーマンスの高い、きわめて有効な対策です。

さらに、近年、SQLインジェクションをはじめとするWebアプリケーション脆弱性に対処する仕組みが、アプリケーションやミドルウェア、開発環境側で整いつつあります。脆弱性のあるWebアプリケーションへの悪意ある通信をブロックするWeb Application Firewall(WAF)の普及も進んでいます。

2021年現在、最新のアプリケーションと開発環境を用いて新規にWebアプリケーションを開発するなら、たとえセキュリティを意識せずに開発に取り組んでいたとしても、SQLインジェクションの脆弱性が作り込まれることは少なくなってきているといえるでしょう。

しかしながら、すべての開発会社が最新の環境で開発を行える、ということはありません。DevSecOpsも、開発の考え方としてはまだ新しく普及はこれからという面があり、また、ソースコード診断を行うことができるような予算やスケジュールを確保できないことも多いでしょう。さらに、開発やリリース時点では脆弱性が存在しなかったとしても、Webサイトの機能追加や新しい攻撃手法の発見等によって、脆弱性は日々新たに生み出されていきます。

こうした実情に対して有効なのは、Webアプリケーションの定期的な脆弱性診断です。SQLインジェクションによるリスクを考えると、これはサイトを運営するならばぜひとも実施すべき対策、といえるでしょう。

まとめ

  • SQLインジェクションとはデータベースを操作する「SQL」という言語を悪用して行うサイバー攻撃、あるいはその脆弱性のことです。
  • Webサイトにアクセスしているユーザを狙うXSSと違って、Webサイトに登録済みのデータを狙うSQLインジェクションでは、より規模の大きい被害が発生する傾向があります。
  • 多くのデータベースではSQL言語が使われており、それらのデータベースはすべて潜在的にSQLインジェクションの攻撃を受ける可能性があります。
  • SQLインジェクション攻撃では、大規模な個人情報漏えいが起こる可能性が高く、そうなった場合、企業は運営責任を問われます。
  • SQLインジェクションの脆弱性を作り込んでしまった会社に損害賠償を命じる判決が下されたこともあります。
  • 最新の環境で開発を行えば発生しづらくなってはいるSQLインジェクションですが、リスクはゼロではありません。定期的な脆弱性診断は有効性の高い対策と考えてよいでしょう。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

Botの脅威!
IoT機器を踏み台にする新たなボットネットも登場

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

いろいろな場面で「ボット(Bot)」という言葉を耳にします。今回の記事では、仕事や暮らしを便利にする「良いボット」ではなく、感染端末によるネットワークを形成し、サイバー攻撃のインフラとして悪用される「悪いボット」について、その感染経路や、攻撃活動の種類、感染予防の対策などを解説します。また、近年問題になっているIoT機器に感染するボットの被害事例を紹介し、IoT機器のメーカーやユーザが実施すべき対策について考えます。

ボット(Bot)とは

「ボット」とは「ロボット」に由来する言葉で、特定の作業を自動で行うプログラムやアプリケーション、機器のことです。iPhoneに搭載されたSiriなどのチャットボットが身近な例として挙げられます。いずれのボットも、プログラムに従ってアルゴリズムやAIで判断を行い、定められたタスクを実行します。

人間の手間を減らし生活を便利にするのが本来のボットの役割ですが、サイバーセキュリティの世界には、コンピュータやネットワークに脅威を与える「悪いボット」がたくさん存在します。ひょっとしたら、この記事を読んでいるあなたのPCの中にも「悪いボット」が隠れているかもしれません。

マルウェア、ウイルスとボットの違い

ボットはマルウェア、ウイルスの一種です。「『マルウェア』とは何か?」の記事で説明したトロイの木馬と同様に、感染したPCにバックドアを作り、PCを外部から遠隔操作可能な状態にします。PCのユーザは感染に気づかないことが多く、ボットオーナーの意のままにPCが操られます。

感染端末への外部からの遠隔操作は、C&C(シー・アンド・シー)またはC2(シー・ツー)などと呼ばれるサーバを通じて行います(C&C、C2とは「Command and Control:指示と制御」の略です)。

ボットウイルスに感染した端末を「ゾンビPC」と呼ぶこともあります。たとえばDDoS攻撃などに悪用されるボット化した大量のPCのイメージが、ホラー映画に登場するゾンビの群れに似ていることから名付けられたと言われています。

ボットの予防対策と感染経路、検知、駆除

ボットの感染対象は、近年PCだけでなく、スマホやIoT機器にまで及んでいます。感染経路は通常のマルウェアと変わりません。PCやスマホの場合はメールの添付ファイル、URLのクリック、Webサイトの閲覧で感染することもあります。

ボット感染の予防対策は、PCやスマホについてはOSやソフトを最新の状態にアップデートしたり、アンチウイルスソフトを最新の状態にすることが求められます。これも通常のマルウェア対策と変わりません。アンチウイルスにパターンファイルが存在するボットであるなら、検知して駆除することができます。また、「ランサムウェア」の記事で説明したEDRを使うことで、ボットによって実行される攻撃活動を検知できる場合もあります。

しかし、どんなに対策をとっていたとしても、亜種が次々と開発され、攻撃手法も変化し、常にすべてを防げるとは限らない点も通常のマルウェアと一緒です。

スパム送信やDDoS攻撃、ボットの活動の種類

ボットは、宿主であるPCなどの機器のインターネット接続とCPU資源を用いて、スパムメール送信やDDoS攻撃など、コンピュータとインターネットにおけるさまざまな反社会的活動を行います。近年は、スマホアプリの中で動作し、不正や詐欺などを行うボットも存在します。

ボット化した端末が大量に集められ、制御下におかれた状態を「ボットネット」「ボットネットワーク」と呼びます。ボットネットは、スパムメール送信やDDoS攻撃など、規模がものを言うサイバー攻撃のインフラとして悪用されます。単なるトロイの木馬とボットとの違いは、このボットネットを形成するかどうかという点にあります。

近年、IoT機器に感染を広げ形成される、大規模なボットネットが問題となっています。

なぜボットはPCだけではなくIoT機器を狙うようになったのか

2016年、当時セキュリティの歴史上最大と言われたDDoS攻撃を行ったのが、「Mirai」と呼ばれるマルウェアによって形成されたボットネットでした。Miraiの特徴は、ネットワークカメラやルータなど、家庭内のIoT機器を主要ターゲットとしていたことです。なぜ家庭内のIoT機器が狙われたのでしょう。

それは、IoT機器がPCなどと比較して、1)工場出荷時のままで使用されることが多い、2)PCより圧倒的に台数が多い、3)外部からの接続を許容することが多い、という3条件がそろっていることが背景にあります。これらの条件がそろうと、犯罪者は単一の手法で一気に大量の機器を感染させることが可能となり、大規模なDDoS攻撃などを成立させることができるのです。

IoTボットの感染経路:Miraiの場合

悪名高いMiraiマルウェアの場合、Telnetに割り当てられるTCPの23番ポートが開いていないか探索したり、管理画面に辞書攻撃(「ブルートフォース攻撃」の記事を参照)などを行って不正にログインするなどして、ボットがインストールされました。

しかし、これらの感染経路や攻撃の特徴も、日々アップデートされ変化していきます。さすがに、本稿執筆時の2020年時点で、TCP23番ポートの開放は少なくなっており、かわりにUniversal Plug and Play(UPnP)が利用するポートを狙う攻撃などが観測されています。

メーカー/ユーザ別、IoT機器のボット感染対策

IoTボット感染対策としてIoT機器メーカーは、「パスワードをデフォルトで使えないようにする」「telnetが利用する23番ポートやUPnPが利用するポートなど、悪用される可能性があるポートに外部からアクセスできないようにしておく」などの対策を行うことが求められます。また、販売後のサポート体制の一環としてセキュリティパッチを継続して一定期間提供し続けることや、セキュリティパッチの自動適用の機能を搭載するといったことも必要でしょう。

一方、ユーザ側は、まずは「パスワードをデフォルトで使わない」「パスワードを長くする」「メーカーのセキュリティパッチが出たらすぐに当てる」など基本対策が大事です。しかし、セキュリティパッチの適用は一般のご家庭ではなかなか実行が難しいところではないでしょうか。また、TCP23番ポートのインターネットへの開放など、攻撃に悪用される可能性のある設定の修正も推奨されますが、これもまた一般のご家庭での対応は難しいところではないかと思います。

自分でセキュリティパッチが当てられない、設定の変更は難しいといった状況でIoT機器を購入される際は、セキュリティパッチの自動適用機能の有無や、セキュリティ上の懸案事項が出た場合のメーカーの対応などもチェックするとよいでしょう。また、古いネットワークカメラやルータなどのIoT機器については、サポート期限が切れている場合や、セキュリティパッチ自体の提供ができない・終わっているといったものがあります。こういった機器については(特にテレワークで在宅勤務をされている場合には)早急に買い替える必要があります。

IoTボットに狙われる脆弱性の検知事例

SQAT.jpを運営する株式会社ブロードバンドセキュリティは、脆弱性診断ペネトレーションテストをはじめとして、APIIoT機器まで、さまざまなセキュリティ診断サービスを提供しています。

診断対象のTCP23番ポートが外部に向けて開いていたというのは、脆弱性診断で数年前であればたびたび指摘される項目でした。最近ではTCP23番ポートの開放が指摘されるケースはまれですが、代わりにIoT機器がDoS攻撃等の脆弱性がある古いバージョンのファームウェアを使っていたことを指摘するといったケースが出ています。社内で利用するPCやIoT機器に、ボットの侵入や悪用を許す弱点がないかを判断するためには、日頃の基本対策だけでなく、第三者による脆弱性診断やペネトレーションテストが役に立ちます。

まとめ

  • ボットとは、特定の作業を自動で行うプログラムやアプリのことです。チャットボットに代表される「良いボット」とサイバーセキュリティ上の脅威となる「悪いボット」があります。
  • 「悪いボット」はウイルスやマルウェアの一種で、ボットネットと呼ばれる感染端末によるネットワークを形成し、サイバー攻撃のインフラとして悪用されます。
  • ボットネットは、スパムメール送信やDDoS攻撃など、大規模なサイバー攻撃に悪用されます。
  • 攻撃の容易さや台数が多いことから、PCだけでなくIoT機器を狙うボットが増えています。
  • ボットの感染予防として、他のマルウェア同様、OSのアップデートやソフトウェアを最新に保ち、不要なポートを閉じるなど基本対策が有効です。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

DXとセキュリティ

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

今回は、デジタル技術を活用して経済にイノベーションをもたらすDXと、そのセキュリティについて考えます。「DX」と「IT化」との違いや、日本企業のDXを阻害すると考えられている「2025年の崖」とは何か、そして、政府によるDX推進のための補助金などを紹介します。

また、DXと歩みを同じくするように進化を続けるサイバー犯罪に対応するための心構えについても、今回は考えてみたいと思います。

DXとは

DXは、Digital Transformation(デジタルトランスフォーメーション)の略称です。Trans(トランス)には「交差する」という意味があり、「Trans」を「X」と表記することがあるため(「X」は線が交差しているから)、「DT」でなく「DX」と略されます。

DXとは、デジタル技術を活用してビジネスやサービスを変革し、イノベーションを推進することです。

単なる「IT化」と「DX」の違い

これまでの「IT化」は、既存のビジネスにITを導入することによって、「効率化」「省力化」「高速化」を行いました。既存のビジネスプロセスや商習慣は大きく変わることなく、IT技術はあくまで「手間を減らすため」「少ない人数でできるようにするため」「以前よりも速くするため」に奉仕する存在でした。

一方でDXは、従来の方法を単に強化してサポートするだけではなく、デジタル技術が生み出すイノベーションによって、全く新しいビジネスモデルを生み出す点が異なります。

レガシーに足を取られて前進できない~DXを阻む「2025年の崖」とは

経済産業省は2018年、「DXレポート ~ITシステム『2025年の崖』克服とDXの本格的な展開~」と題した報告書を公開し、日本経済のDXを阻害する要因に対して警鐘を鳴らしました。「2025年の崖」とは、過去の「IT化」によって生み出されたシステムのメンテナンスに予算と人員がとられて、日本経済が停滞してしまうという予測です。

森喜朗首相(当時)によって「IT革命」が叫ばれた西暦2000年頃、NHFを代表とするシステムインテグレータ企業は、日本企業の複雑かつときに奇怪にすら見えたビジネス慣習に、いかに寄り添って微細にカスタマイズをして納品するか、その腕前を競い合いました。こうして複雑にカスタマイズされたシステムが年を経て技術が時代遅れになり、ブラックボックス化して機能追加もままならなくなり、管理も属人化してしまいました。

経産省のレポートでは、こうした新しい価値を生まないシステムの維持のために、IT投資の9割が使われ、それによって日本経済が停滞すると予測しています。まさに砂漠に水を撒き続けるような状態です。

技術的な負債となり得るIT投資

(出典:経済産業省「DXレポート ~ITシステム『2025年の崖』克服とDXの本格的な展開~」)

あなたの会社が今やろうとしていることは、このようなIT投資になっていないでしょうか。DXを進める際に注意したいポイントです。

DXの成功事例、Uberは何が革新的だったのか

配車サービスのUberは、DXの成功事例のひとつといえるでしょう。乗り合いサービスを提供したいドライバーと利用者をマッチングするアプリは、世界各国で使われています。GPSと地図、マッチングと評価の機能、Uberが用いているのは特段新しい技術ではありません。Uberが行ったのは、新しいビジネスモデルの創出なのです。

一方でUberは、ロンドンやニューヨークをはじめとする世界中で、タクシー業界を壊滅させるサービスとして猛反発を受けています。既存の業界やビジネスプロセス、商習慣に対して、ときに破壊的インパクトを与えるのもDXの特徴のひとつといえるかもしれません。

2025年の崖にも、DXによる解決方法はきっとあるはずです。

税金や補助金など、DX優遇あれこれ

人口減少社会に突入した日本経済の起爆剤として、政府はDXを強力に推進しています。2020年10月には、大手経済紙が、2021年度の税制改正で、DXを進める企業への税制優遇策を政府が検討していると報じました。

税制優遇は詳細がまだ明らかにはなっていませんが、その他にも「IT導入補助金」「DX認定制度」など、DXを推進するためのさまざまな施策が政府の後押しで行われています。あなたの会社でも利用できるものがあるかどうか、一度調べてみてもいいかもしれません。なお、2020年度の「IT導入補助金」交付申請締め切りは、2020年12月18日17時です。

革新が進むサイバー攻撃

残念ながら、サイバー攻撃もまた、DXによってイノベーションが進んでいます。これまでもサイバー攻撃は進化を続けてきましたが、サイバー犯罪にも質的変化や革新が起こりました。

たとえばランサムウェアは、1989年に初めて発見され、長らくパッとしないサイバー犯罪のひとつとして存在し続けていました。しかし2013年、身代金受け取りにビットコイン等の仮想通貨を用いるというビジネスモデルの刷新によって、一転「収益を生むサイバー犯罪」に変わりました。近年、暗号化して人質にしたデータの復号だけでなく、データを一般公開すると脅し二度金銭を要求したり、大事なデータをオークションで販売するなど、ランサムウェアは悪質化の一途を辿っています。

「DX with Cybersecurity」、SQAT.jpが考える3つのキーワード

内閣サイバーセキュリティセンター(NISC)は、報告書「サイバーセキュリティ2020 」の中で、「DX with Cybersecurity」として「サイバーセキュリティ対応能力の効果・効率を向上させるためにDXを推進する」と記載しています。

なかなか難しい「DXとセキュリティ」というテーマではありますが、SQAT.jpとしてあえて3つのキーワードを挙げてみましょう。

1.担当者だけではない

デジタル技術そのものが新しい価値と利益を生み出すDXでは、セキュリティは情報システム部門やセキュリティ部門、あるいは品質管理部門や経営企画だけが担えばよいものではなく、すべての部門が自分事として取り組む必要があります。事業会社であるなら、たとえ間接部門に所属していても全部署の人が利益を考えて活動しなければならないことと同じように、全社員がセキュリティを考えて動く必要があります。

2.能動的セキュリティ

これまでセキュリティは、攻撃を未然に防ぐよう対策を行い、万一事故が発生したらそれを受けて対応するのが常でした。しかしこれからのDX時代は違います。企画段階からセキュリティバイデザインで要件定義を行い、将来脆弱性を生まないように、コード診断を行いながらDevSecOpsで開発をスピーディに進めるなど、先手先手でセキュリティの試みを能動的に行うようになるでしょう。「シフトレフト」があたりまえになって、その言葉すらなくなるかもしれません。

3.持続・継続性

DXによって生み出されるサービスの多くでは、「新時代の石油」と呼ばれる「データ」、つまり、位置情報や決済情報、健康情報等と結びついた個人情報が、渦となって集積することになるでしょう。セキュリティを担保する活動を定常的に行い続けることが、DX時代の企業の新しい存在意義のひとつになると考えられます。そこでは、クラウドの活用や自動化の推進、優秀な人材の確保が欠かせません。また、SQAT.jpが提唱してきた「セキュリティのかかりつけ医」的な会社との関係を構築することも鍵になるのではないでしょうか。

DX時代もセキュリティの本質は変わらない

DX時代、セキュリティ業務はその対象をIoTやAPIにまで拡大し、その方法も様変わりしていくことが予想されます。しかし、脆弱性診断で隠れたセキュリティホールを探したり、脆弱性が報告されたらすばやくパッチをあてたり、日々パスワード管理を行ったりするなど、安全を守るための活動を日々積み重ねていくことの重要性に変わりはありません。

DXの時代はむしろ、全社にセキュリティの重要性が認識され、受け身だった仕事に能動的な側面が増えることで、セキュリティの業務の価値がいっそう高まっていくでしょう。

まとめ

  • DXとは、デジタル技術を活用してビジネスにイノベーションをもたらすことです。
  • 既存のビジネスにITを導入するだけの「IT化」とDXは異なります。
  • 複雑にカスタマイズされてブラックボックス化した既存システムは企業のDXを阻害します。
  • 政府は優遇税制や補助金などを用意してDXを推進しています。
  • サイバー犯罪もまた革新と進化を続けています。
  • しかしDX時代とはいえ、セキュリティ業務の本質は何ら変わるものではありません。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

今回は、クロスサイトスクリプティング(XSS)のような「大物の脆弱性」と比較すると、一見地味に見えてしまう「CSRF」の意外な危険性について取り上げます。CSRFの脆弱性リスクやXSSとの違い、さらに実際の診断の現場での検出頻度や、見つかった際に行うべき対応、予防策についてもご紹介します。安全なWebサイト運用のために必読です。

クロスサイトリクエストフォージェリとは

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

「クロスサイト」は「Webサイトをまたぐ」という意味で、「リクエスト」はユーザがWebアプリケーションなどに処理を要求すること、「フォージェリ」には「偽造品」などの意味があります。CSRFの脆弱性を悪用することで、ユーザが意図していないリクエストを強制的に行わせることが可能になります。攻撃者は罠として用意した偽造サイトを用いてユーザーに意図しないリクエストを強制的に送信させます。結果として、ユーザーの認証情報を利用した不正な操作や、個人情報の流出が引き起こされる可能性があります。

クロスサイトリクエストフォージェリとクロスサイトスクリプティングの違い

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

  • XSS:Webサイトに悪意のあるスクリプトを埋め込む
  • CSRF:ユーザの意図しないリクエストを強制的に実行させる

脆弱性診断の現場にみるCSRFの実態

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

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

CSRFによる攻撃と被害例

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

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

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

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

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

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

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

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

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

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

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

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

CSRF脆弱性への対策

最も効果的な対策は「トークン」呼ばれる推測困難な文字列の使用です。

  • ユニークな推測困難な文字列を生成
  • リクエスト時に追加検証
  • PHP、Java、ASP.NETの主要フレームワークで実装可能

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

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

注意!トークン実装の落とし穴

フレームワークに機能があっても、実際のコーディング時に1行追加することを忘れがちです。「機能がある=安全」ではありません。

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

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

まとめ:CSRFは名脇役、されど油断大敵

  • CSRFとは、「シーサーフ」と呼ばれる、攻撃者が罠として用意したサイトを用いて、ユーザが意図しないリクエストを強制的に行わせることを可能にする脆弱性です。
  • CSRFは単独では大きな脅威ではありませんが、他の攻撃手法と組み合わさることで深刻なセキュリティリスクになり得ます。
  • CSRFとXSSは、どちらもサイトを横断してサイバー攻撃を行う点だけは共通していますが、発見頻度やリスク、対策方法は異なります。
  • 定期的な脆弱性診断と、最新のセキュリティ対策が何より重要です。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

ブルートフォース攻撃とは、不正アクセスを行うために、パスワードを総当たりで試すことです。今回は、辞書攻撃やパスワードスプレー攻撃など、さまざまなパスワードへの攻撃を紹介しながら、ユーザと管理者が行うべき対策、そして最新の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 NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

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 NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

クロスサイトスクリプティング(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 NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

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

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状況別 対策の例
テレワーク対応導入の第一歩 ●営業秘密管理規程、情報取扱規定等をテレワークに即した内容に改訂
●諸規程の従業員に対する周知徹底
●情報に応じたアクセス権者の設定 等
業務における情報持ち出しおよび
社外からのアクセス
●データのファイル名や当該データ上に「㊙」(マル秘)・「社内限り」等の秘密であることの表示を付す*4
●情報のコピー・持ち出しにおける上長等の事前許可/返却・破棄ルールの周知・徹底と持ち出し記録の整備
●紙の資料・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 NEWS TOPに戻る
バックナンバー TOPに戻る


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

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

情報漏えいの原因と予防するための対策

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

サイバー攻撃の被害を受け、システムの機密情報等が漏えいする事故の件数は年々増加しています。実際に企業がデータ侵害などの被害を受けてしまい、機密情報等の漏洩が発生してしまうと、システムの復旧作業に莫大なコストがかかることになり、企業にとって大きなビジネス損失につなる恐れもあります。では、未然に事故を防ぐ対策はどのような方法があるのでしょうか。本記事では、情報漏えいの原因と予防策について解説します。

情報漏えいとは

情報漏えいとは、サイバー攻撃などによる不正アクセスや、ノートPCの紛失などによって、企業や組織の保有する外部に出てはいけない情報が漏れてしまうことです。個人情報漏えいが特に注目されますが、企業の営業情報や知的財産、機密情報など、漏えいする情報は多岐にわたります。

個人情報漏えい

インターネットの普及に伴い、Webサービスへの会員登録などで個人情報が大量に蓄積され、同時にノートPC・スマホ・USBメモリ等の記憶媒体の容量が増加、情報漏えいも大規模化しました。こうした社会の変化に対応し、2005年(平成17年)、「個人情報の保護に関する法律(個人情報保護法)」が施行されました。

個人情報保護法では、個人情報漏えいが発生した組織は、事実関係と再発防止策に関して、政府の個人情報保護委員会等に「速やかに報告するよう努める」とされており、業種によっては監督官庁への報告義務が課される場合もあります。

情報漏えいの重大度の違い

どんな情報が漏えいしたかによって漏えい事故の深刻度は異なります。「顧客の個人情報が○○件漏えい」といった報道の見出しを見かけますが、漏えいの件数以外にも、情報漏えい事故の重さ、深刻さを左右するポイントを挙げます。

・クレジットカード情報
被害に遭ったユーザーに金銭被害をもたらす可能性の有無という点で、漏えいした情報にクレジットカード情報が含まれていたかどうかは重要なポイントです。損害賠償等が発生した場合、クレジットカード情報が含まれていると被害者への賠償額がアップします。

・セキュリティコード
クレジットカード情報の名義人・カード番号・有効期限だけでなく、3桁のセキュリティコードを含むかどうかが事故の深刻さを左右します。被害に遭ったユーザーに金銭被害をもたらす可能性がより高くなるからです。

・パスワード
たとえばメールアドレスとセットでそれに紐付くパスワードも漏えいしていたとしたら事態はより深刻です。オンラインサービスなどに悪意の第三者が不正ログインできてしまうからです。

・平文パスワード
一般的にパスワードは、もしパスワードを記載したファイルが漏えいしても、第三者が内容を閲覧できないように暗号化して管理するのが常識です。しかし、稀に暗号化されていない平文(ひらぶん)のパスワードが流出する場合があります。こうなった場合、申し開きが全くできない最悪の管理不備のひとつとして、厳しい批判と鋭い糾弾の対象となります。擁護する人は誰もいなくなります。

・機微情報
信条(宗教、思想)や門地、犯罪歴等、さまざまな社会的差別の要因となる可能性がある情報を機微情報といいます。特に、各種成人病やその他疾病など、保健医療に関わる機微情報は医薬品のスパムメールや、フィッシングメールなどに悪用されることがあり、その成功確率を上げるといわれています。


以上のように、ひとくちに個人情報漏えいといっても、その重大さの度合いは異なり、社会やユーザーからの受け取られ方にも差があります。

弁解の余地もない真っ黒な管理状態ではなく、「不幸にも事故は起こってしまったが、打つべき予防対策は事前にしっかり打たれていた」と、ステークホルダーに理解されれば、ビジネスインパクトは限定的なものになる可能性もあります。

情報漏えいの原因

「ハッカーによるサイバー攻撃」「従業員による内部犯行」。情報漏えいが起こる原因としてすぐにこれらが思い浮かびますが、そういった悪意に基づく攻撃ばかりが情報漏えいの原因ではありません。

冒頭で挙げたPC・スマホ・USBメモリの不注意による紛失はいまも漏えい原因の多くを占めていますし、Webサイトのアクセス制限設定ミスで個人情報が見える状態になっていたり、開発中の会員管理システムのテストデータとして、うっかり誤って実在する個人の情報を使ったり等々、必ずしも悪意によるものではなく、管理不備やケアレスミスでも情報漏えいは発生します。

近年、クラウドコンピューティングが普及したことで、影響の大きい設定変更等の操作をブラウザからワンクリックで行うことが可能になりました。こうしたクラウドサービスの設定ミスによる情報漏えいも増加しています。

上場企業での情報漏洩件数は2年連続で過去最多を更新

サイバー攻撃や組織における管理またはシステムの設定不備・不足等が原因となり、機密情報等の漏洩事故および事件が相次いで発生しています。東京商工リサーチの調べによれば、上場企業とその子会社で起きた個人情報漏洩または紛失事故・事件件数は、2022年で165件となり、2021年から連続で過去最多を更新しました。

不正アクセスによる情報漏えい事故

もちろん、悪意ある攻撃も猛威を振るっています。ハッカーによるサイバー攻撃など、以前はアニメと映画の中だけのお話でした。しかし、不正アクセスによる情報漏えいが2010年以降増加し始めました。

特定非営利活動法人日本ネットワークセキュリティ協会(JNSA)が毎年行っている調査「情報セキュリティインシデントに関する調査報告書」によれば、それまでの攻撃と質が異なる攻撃、「標的型攻撃」が観測されはじめた2010年頃から、不正アクセスが原因となるサイバー攻撃は8年で20倍という伸びを見せています。ケアレスミスや管理不備への対策とは別の手を打つ必要があります。

漏えい原因における不正アクセスの比率

2010年 1.0 %
2011年 1.2 %
2012年 1.5 %
2013年 4.7 %
2014年 2.4 %
2015年 not available
2016年 14.5 %
2017年 17.4 %
2018年 20.3 %

情報漏えい事故が起こった後の対応方法

事故が起こった後の対応の善し悪しも、ユーザーや社会の受け取り方を大きく変えます。独立行政法人情報処理推進機構(IPA)は、情報漏えい事故が起こった企業や組織に向けて「情報漏えい発生時の対応ポイント集」を公開していますが、過去に個人情報漏えい事案に対処した経験がある練度の高いCSIRTチームが社内に存在でもしない限り、被害実態調査やその後の対策などは、専門セキュリティ企業に相談するのがもっとも安全で一般的な方法です。

セキュリティ業界では、セキュリティ緊急対応サービスに相談が来る曜日や時間に傾向があると言われています。それは、「金曜日の午後」「連休前の午後」です。つまり、事故は週前半または半ばに発生していたが、なんとか自分たちで解決できないかもがき苦しんだ後、最後の最後であきらめて、「休日を挟む前に」セキュリティ企業へ連絡をするからです。自分たちで精一杯手を尽くした努力も空しく諦めざるを得ないとは、身につまされる話です。

しかし、時間が経過すればするほど、調査に必要なエビデンスが失われることもあります。情報漏えい事故が起きたら、信頼できる専門企業にすぐ相談してください。

情報漏えい事故の報告書と収束までの流れ

専門セキュリティ企業の協力の元、デジタルフォレンジックによる原因や被害範囲などの調査が行われ、一定の社会的インパクトがある情報漏えいであれば、報告書を公開します。場合によっては記者会見を行い、調査分析のための第三者委員会が組織される場合もあります。

インシデントの全容を解明した報告書作成には数か月かかるかもしれませんが、その前にまず事件の概要、情報漏えい対象者の範囲や救済措置などについては、なるべく早く情報公開することが大事です。

速報第一報に限らず、情報漏えい事故の調査報告書に必要な項目は下記のとおりです。


・漏えいした情報の内容

・漏えい件数

・原因

・現在の状況

・今後の対策


重要なのは、速報公表まであまり時間をかけないことです。時間がかかるほど、どんなにその調査が合理的で必要なものであっても、SNSなどで「事故を隠そうとしたに違いない」といった、批判の対象となることがあります。

また、第一報につづく第二報では、内容の大きな修正があってはなりません。特に第二報で漏えい件数が大幅に増えていたりすると、「事故を小さく見せかけようとした」「初動対応に失敗した」などの誤ったイメージすら与えかねません。速報では、論理的に最大の漏えい可能性がある件数を、必ず記載してください。詳細な調査を待たずとも、速報で最大値推定を出すのは難しくありません。

企業側は、組織の透明性を確保しながら、とにかく誠意を見せることが重要です。たとえば報告書の「今後の対策」の欄に、どんな対策を実施するかという詳細を公表する必要はありません。しかし、大まかな予定であっても「いつまでに何々という対策を実施する」とマイルストーンを設置して計画を可視化することで、ステークホルダーやユーザーの心証は好転します。

情報漏えいを予防する対策

これまで述べてきたように、情報漏えいには性質の異なる複数の原因があり、原因毎に予防対策は異なります。

まずは従業員によるノートPCやUSBメモリの紛失などを減らすために、セキュリティリテラシーを向上させるアウェアネストレーニングが有効です。IPAが刊行する「情報漏えい対策のしおり」など、無料の教材や動画も多数公開されています。同時に、ノートPCやUSBメモリの管理規定も定めましょう。

また、近年増加しているAWSのようなクラウドサービスの設定不備による事故の対策として、設定ミスや、現在の設定のリスクを網羅的に検知するサービスも提供されるようになっています。

先に挙げた通り、不正アクセスによる情報漏えいは過去約10年で20倍という驚くべき増加を見せています。サイバー攻撃の侵入を許す穴がないかどうかを探す脆弱性診断や、脆弱性を利用してひとたび侵入された場合、何がどこまでできてしまうのかを検証するペネトレーションテストも、不正アクセスに対する極めて有効な対策方法です。

新しい社員の入社や退職など、組織は日々変化し、業務やシステム構成・Webアプリケーションも進化を続けます。昨日までは安全だったWebアプリケーションに、今日新しい脆弱性が見つかることもあります。上記に挙げた対策はいずれも一度実施したら終わりではありません。定期的に継続することで真の効果を発揮します。

そもそも事故が起きないことが一番素晴らしいことですが、せめて「事故は起こったものの打てる手はちゃんと打っていた」と言えるようにしておくべきです。

まとめ

・個人情報保護法では、個人情報の漏えいを起こした組織が講ずるべき措置が定められている。
・情報漏えい事故の深刻度は、漏洩した件数だけでなく、漏えいした情報の内容にも大きく左右される。
・情報漏えいは、悪意に基づく不正アクセスのほか、設定不備や管理上の不注意が原因で発生することもある。
・情報漏えい事故が発生したら、速やかに信頼できる専門セキュリティ企業に依頼するのが有効。
・情報漏えい事故に関する事実の公表は、組織の透明性を確保しながら誠意をもって臨むことが重要。
・情報漏えいの予防には、従業員のセキュリティリテラシー向上教育、クラウド設定不備の検査、脆弱性診断やペネトレーションテスト等の対策がある。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


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

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