脆弱性診断はアプリケーションやサーバ、ネットワークに、悪用できる脆弱性がないかを診断します。ライフサイクル別にどんな診断が必要か、ツール診断と手動診断、ペネトレーションテストとの違いなどを解説します。

企業が施すセキュリティ対策は広範かつ複雑になっています。外部からのサイバー攻撃や、内部での情報の持ち出しなど、セキュリティの脅威が多様化しているためです。企業が保護すべき情報、アプリケーション、機器の種類・数などが拡大していることも理由に挙げられます。

これに伴い、情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法がいくつも存在します。この記事では、その中の 「脆弱性診断」を取り上げて、その定義、特徴、メリット、実際の利用方法などを紹介します。

脆弱性とは

脆弱性とは、不正アクセスやコンピュータウイルスなどの攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所のことです。

悪意のある第三者（サイバー攻撃者）によって脆弱性を悪用されると、コンピュータ内部データ（情報）の盗取・改竄・削除、また他のコンピュータへの同様の悪事が可能になり、自組織のシステムに脆弱性が存在した場合、サイバー攻撃者に狙われやすくなる可能性が高まります。

放置された脆弱性のリスクについてはこちらの関連記事もあわせてご参照ください。
「BBSec脆弱性診断結果からみる― 脆弱性を悪用したサイバー攻撃への備えとは ―」
「定期的な脆弱性診断でシステムを守ろう！-放置された脆弱性のリスクと対処方法-」
「既知の脆弱性こそ十分なセキュリティ対策を！」
「今、危険な脆弱性とその対策―2021年上半期の診断データや攻撃事例より―」

脆弱性診断とは

脆弱性診断とは、企業・組織のシステムに内在するセキュリティ上の既知の欠陥（＝脆弱性）を特定する検査です。
Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど診断対象により様々な脆弱性診断があります。セキュリティ上の問題点を可視化することで、情報漏洩やサービス停止等のセキュリティ事故を防ぐために、どのような対策を実施すればよいか検討するのに役立ちます。

脆弱性診断は一度実施したらそれで終わり、というものではありません。脆弱性診断により発見された問題に対し対策を実施することで、より堅牢なシステム・環境・体制を構築することができます。

重要なのは、システムライフサイクルの各フェーズで、適切な診断を実施し、洗い出されたセキュリティ上の問題に優先順位をつけて、ひとつひとつ対処することです。

脆弱性診断の必要性

情報資産を守るため

情報のセキュリティの3要素、「機密性」「完全性」「可用性」を守るためにも、脆弱性診断は必要な理由の一つです。
「機密性」…限られた人だけが情報に接触できるように制限をかけること。
「完全性」…不正な改ざんなどから保護すること。
「可用性」…利用者が必要なときに安全にアクセスできる環境であること。
これらの要素を適切に満たすことが、情報セキュリティを担保する上では欠かせないものとなります。

情報セキュリティ事故を未然に防ぐため        

攻撃者より先にシステムに隠れた脆弱性を検出して対策することで、攻撃や事故発生の確率を下げることができます。ひとたび個人情報やクレジットカード情報の漏えい事故が発生すれば、さまざまな対応・復旧費用や対策工数の発生は避けられません。ブランドの毀損や企業イメージの低下も招きます。

サービス利用者の安心のため

パソコンやインターネットを補助的に利用していた昔と異なり、現在はWebサービスやアプリケーションそのものが利益を生み出しています。生活や経済がネットワークなしに成り立たない現在、脆弱性診断などのセキュリティ対策は、事業を継続しサービス利用者の安心を守るため、欠かせないものとなっています。

脆弱性診断の種類

診断対象により、さまざまな脆弱性診断サービスがあります。まず、企業が開発したWebアプリケーションが挙げられます。問合せや会員登録といった、入力フォームの入出力値の処理、ログイン機能の認証処理などに対して、幅広く網羅的に脆弱性診断が行われます。

次に、そのWebアプリケーションを実行するサーバやネットワーク機器、OSやミドルウェアに脆弱性がないか検査する プラットフォーム診断があります。

アプリケーションの脆弱性診断には、既知の攻撃パターンを送付して対象システムやソフトウェアの挙動を確認する「ブラックボックステスト」という方法があります。 「ブラックボックステスト」では、実装時における脆弱性は検出できますが、そもそもプログラムの設計図であるソースコード中に存在する脆弱性を網羅的には検査することには適していません。

この場合、ソースコード開示のもと「ソースコード診断」する方法が有効です。「ソースコード診断」は「ブラックボックステスト」に対して 「ホワイトボックステスト」とも呼ばれます。また、「ソースコード診断」はさらに、プログラムを実行しないで行う「静的解析」と、実行して行う「動的解析」に分類できます。

ソースコード診断についてはこちらの記事もあわせてご参照ください。
「ソースコード診断の必要性とは？目的とメリットを紹介」

そのほか、近年増加の一途をたどる スマホアプリケーションや IoT機器を対象とした脆弱性診断もあります。

（株式会社ブロードバンドセキュリティのサービス分類に基づく）

脆弱性診断とペネトレーションテストの違い

脆弱性診断とペネトレーションテストは、双方とも脆弱性などを検出する点では似ていますが、目的と方法が少し異なります。脆弱性診断は既知の脆弱性を網羅的に検出することを目的としています。

ペネトレーションテストは、「侵入テスト」の名前のとおり、疑似的なサイバー攻撃を仕掛けてセキュリティ対策の有効性を評価するために実施します。技術的アプローチだけでなく、対象となる組織の構成や、業務手順、ときには物理的な施設の特徴すら加味して、攻撃シナリオを作成する「レッドチーム演習」と呼ばれるテストを実施することもあります。

シナリオに沿ってペネトレーションテスターが攻撃を実行し、システムに侵入できるか、ターゲットとする資産（多くは知的財産）にたどり着くことができるかどうかなどをテストします。ペネトレーションテストは脆弱性診断と比べて、技術力はもちろん、より幅広い見識やセンスが求められます。

脆弱性診断の方法（ツール診断・手動診断）

ツール診断とは、脆弱性診断ツールと呼ばれるコンピュータプログラムを実行して、その応答から脆弱性を検知していくもので、自動診断とも呼ばれます。脆弱性診断ツールには、たとえばWebアプリケーション診断の場合に、検査コードと呼ばれる不正なHTTPリクエストを送信し 擬似攻撃するプログラムがあります。

これに対して手動診断は、技術者がプロキシツールを介してWebブラウザでサイトにアクセスした際に発生するリクエストを書き換える形で、脆弱性を確認する方法です。ツール診断と比べ検査項目も広く、また細かな検査ができるのが特徴です。

「ツール診断」による脆弱性診断

「ツール診断」では、セキュリティベンダーが、商用または自社開発した診断ツールを用いて脆弱性を見つけ出します。機械的に不正なHTTPリクエストを送り付ける疑似攻撃を行いますが、クラッカーによる攻撃とは異なり、あくまでも 脆弱性を見つけ出すことが目的であるため、システムを破壊することはありません。

ツール診断は機械的な検査であるため、過検知や誤検知なども含まれることが多く、その結果は担当者が補正することで正確な情報が得られます。比較的手軽に行えることから、開発段階で実施されることも多い診断です。また、定期的な簡易診断として用いることで、コストを低減しつつ最新の状態を保つことができるといった利用方法もあります。

「手動診断」による脆弱性診断

手動診断は、経験と専門性を持つ技術者によって実施され、機械的な判断では見落としてしまう 画面遷移・分岐にも対応できるメリットがあります。発見した脆弱性の再現手順や、最新動向を加味した対策方法などを提示してくれるのも、手動診断ならではの特徴と言えます。

ツール診断と手動診断は、どちらが優れていると比較するものではありません。それぞれの 特長を生かし、予算に合わせて組み合わせることで、コストパフォーマンスを発揮できるでしょう。

脆弱性診断の進め方

セキュリティベンダーに脆弱性診断を依頼する際は、まず 診断する範囲を決めます。組織にとって重要度が高い部分、すなわちサイバー攻撃を許してはいけないシステムやサーバ、Webアプリケーションを選定します。

診断が終了するとベンダーからレポートが提供され、報告会が行われることもあります。レポートに記載された脆弱性には深刻度などがスコア化されていることもあります。内容に応じて優先度をつけて、脆弱性をふさぐ必要があります。

脆弱性診断のまとめ

企業の情報システムが複雑かつ大規模になった現在、カード情報や個人情報・機密情報を狙う内外からの脅威に対して、企業もさまざまな予防手段を打っていく必要があります。情報システムやそれを取り巻く環境・体制が堅牢であるかどうかを検査、評価する方法として「脆弱性診断」があります。

・脆弱性診断とは企業・組織のシステムに内在するセキュリティ上の既知の欠陥（＝脆弱性）
　を特定する検査
・Webアプリケーション、スマホアプリケーション、サーバ、ネットワークなど
　診断対象により様々な脆弱性診断がある
・脆弱性診断を実施し洗い出されたセキュリティ上の問題に優先順位をつけて、
　ひとつひとつ対処することが重要である

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 DSS1https://www.jcdsc.org/pci_dss.phpは、上記カードブランド5社が設立した組織であるPCI SSC（PCI Security Standards Council）によって管理されています。2022年3月31日には最新版であるPCI DSS 4.0が公開されています*2https://www.pcisecuritystandards.org/document_library/。

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 v3.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 v4.0」とは

PCI DSS v4.0では、暗号やモニタリングなどが強化されるほか、多要素認証等についてもキャッチアップが行われ、さらなるセキュリティ強化が図られています。弊社では11月に「PCI DSS v4.0で変わる脆弱性診断」と題したウェビナーで、PCI DSS v4.0で求められる脆弱性スキャンやペネトレーションテストについて、v3.2.1からの変更点を中心にお話しています。ご関心がおありでしたらお問い合わせいただき、ぜひご参考にしていただければと思います。

まとめ

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

Security 玉手箱 TOPに戻る
TOP-更新情報に戻る

クラウドサービスを利用する企業は約7割を超え、いまやITビジネス環境に欠かせない存在です。AWS、Azure、GCPなどのクラウドサービスの代表例と、クラウド導入のメリットと不安、クラウドセキュリティを担保する方法を解説します。

日本の各企業でも、クラウドサービス（クラウド）の利用はさらに進み、オンラインによるコミュニケーションやデータ共有、迅速なシステム構築などに活用されています。 しかし、ハードウェアを自社内やデータセンター等の設備内に設置する「オンプレミス」と比べ、セキュリティに対する漠然とした不安の声もあります。導入担当者やセキュリティ担当者は、クラウドセキュリティを確保していく必要があります。

この記事では、企業で活用されているクラウドサービスを例示しながら、「クラウド」「SaaS」「PaaS」「IaaS」「オンプレミス」などクラウド関連の用語を解説します。またクラウドサービスのメリットや不安点を挙げた上で、最後にクラウドセキュリティについて論じます。

クラウドサービスとは

クラウドサービスとは、ソフトウェアやサーバ、インフラなどを製品としてではなくサービスとしてクラウド事業者が提供するものです。これまでのソフトウェアやサーバの調達と異なり、利用者はサブスクリプション形式で利用料を支払い、クラウド上にあるリソースをサービスとして利用します。

クラウド（cloud）という名称は、ネットワークの模式図上で雲のような形状で示されるところからきました。ひとつの雲で表されますが、実際には複数のサーバ機器やネットワーク機器で構成され、サーバにはサービスに必要なソフトウェアが導入されています。

サーバを事業所内に設置するような利用形態「オンプレミス」という用語は、「クラウド」の対義語のように使われていますが、英語のon-premiseの本来の意味合いは「敷地内の」というものです。

なおクラウドサービスを分類すると、3つの主要サービスがあります。具体的なイメージを掴めるよう、法人で幅広く使われているクラウドサービスを挙げながら紹介します。

SaaS（Software as a Service、サース、サーズ）

Gmail（Webメール）、Microsoft Office 365（オフィスソフト）、Dropbox（ストレージ）、Slack（チャット）などのサービスがあります。一般ユーザが使用するアプリケーションをサービスとして提供します。

IaaS（Infrastructure as a Service、アイアース、イアース）

利用者が選択したスペックやOSに合わせた、仮想的なマシン（インフラ）を提供します。利用者側で必要なアプリケーションをさらにインストールするなどして、用途に合わせてカスタマイズできます。

たとえばWebサービスを顧客に展開するときに、Webサーバとして活用するケースがあります。Amazon Elastic Compute Cloud（Amazon EC2）、Azure Virtual Machines、Google Compute Engine（GCP）といったサービスがあります。

PaaS（Platform as a Service、パース）

IaaSが提供する仮想マシンに加え、上位のミドルウェアを含め提供するプラットフォームがPaaSです。さまざまなサービスがありますが、たとえばAWSのAmazon Relational Database Service（Amazon RDS）では、主要なリレーショナルデータベース（RDB）をサポートします。また、GCPのGoogle App Engine（GAE）は、JavaやPythonなどで開発したアプリケーションをGCPのインフラ上で簡単にデプロイ、管理できるようになっています。

CaaS（Container as a Service、カース）

コンテナ技術を用いると、例えば開発用、本番用といった異なるサーバやOS間で同一の環境を持ち運べるなど、効率的なアプリケーション開発が実現できますが、複数のコンテナを組み合わせた大規模な環境では、それらを運用、管理するのに手間がかかります。CaaSは、複数のコンテナ利用に必要なオーケストレーション機能（管理/サポートする機能）を多数提供し、開発業務のさらなる効率向上を可能にします。代表的な例には、Docker、GKE（Google Kubernetes Engine）、Amazon ECS（Elastic Container Service）、VMware PKSなどのサービスがあります。

なお企業向けのクラウドセキュリティの議論はIaaSやPaaSを対象にしたものが中心です。これは、SaaSのセキュリティ管理は、クラウド事業者とサービサーが担うため、企業側で対応する余地があまりないためです。この記事でも、特に断りのない限りIaaSやPaaSを念頭に説明を進めていきます。

日本政府もAWSを導入！クラウドを利用する日本企業は7割に

2020年2月、政府が「政府共通プラットフォーム」にAWSを利用する 方針であることを発表しました。政府が採用を決める前から、企業でもクラウド利用が広がっています。以下は、総務省の通信利用動向調査の結果です。クラウドを全社的または一部の部門で活用する日本企業は毎年増え続け、2021年では70.2%に上っています。

国内におけるクラウドサービス利用状況

クラウドサービス導入のメリット

ピーク性能に合わせて購入するのが一般的なオンプレミスと比べ、クラウドでは必要な時に必要なスペックで サーバやソフトウェアの契約を行うことが可能です。

1.どこからでもアクセスできる

WebメールやオンラインストレージといったSaaSを利用している場合、どこにいてもインターネットがあればアクセスできます。

2.負荷に応じて動的にシステム変更可能

アクセスの増減に合わせて、Webの管理ツールを操作するだけで、サーバを追加したり削減したりできます。オンプレミスと比べ、変更にかかる時間を大幅に短縮できます。 TVで取り上げられた場合などに発生する、突発的なアクセス増にも柔軟に対応可能です。

3.開発者が多くどんどん便利になっている

利用が急拡大しているグローバル規模のクラウド事業者は、世界中から優秀な開発者を集めており、次々と機能追加が行われています。

クラウドサービスに対する4つの不安

1.情報漏えいリスク

どこからでもアクセスできて便利な反面、オンプレミス環境のように手元に情報を保持していない分、漠然とした不安や、攻撃対象になりやすいのではないかといった懸念があります。こうした懸念に応えるセキュリティ対策については後述します。

2.システム稼働率や法規制対応

クリティカルなサービスを提供する企業では、稼働率などを保証するSLA（Service Level Agreement）や、冗長構成を必要とする場合があります。また、クラウドサービスの利用にあたり、社内の基準やコンプライアンス、業界基準、国内法に準拠している必要があります。

これらの不安に対応して、AWSなど大手のクラウドサービスではSLAや第三者機関から取得した認証など、各種基準への対応状況を公表しています。

3.従量課金による費用変動

クラウドサービスの課金体系には、月額・日額の固定料金制もあれば、従量課金制もあります。利用形態によっては、オンプレミス環境を用意したほうが安価な場合もあります。システム利用計画を建ててから契約しましょう。

4.カスタマイズやベンダーのサポート体制

クラウド事業者は複数の顧客に共通のサービスを提供することで。オンプレミス環境と同様のカスタマイズやサポートは望めない場合もあります。

クラウドセキュリティ要件のガイドライン

クラウドサービス提供者側のセキュリティ要件として、たとえば総務省では「クラウドサービス提供における情報セキュリティ対策ガイドライン」を提供しています。

クラウド事業者は施設の物理セキュリティや、ネットワークなどのインフラのセキュリティに責任を持ちますが、利用者側にもネットワーク周りの設定や管理アカウントの管理などの対策が求められます。

クラウドの設定ミスに起因する事故

AWSに置かれていた、米ウォールストリートジャーナル紙の購読者名簿220万人分が、第三者による閲覧が可能な状態になっているという事故がありました。これは、利用者側の設定ミスに起因するものです。

オンプレミス環境ではサーバを直接操作する人は限られており、サーバルームの入退室記録簿等々、事故が起こらないようにさまざまなルールや、それを守る体制がありました。しかしクラウドでは、前述したようにどこからでもアクセスして、Web管理ツールで簡単にシステムを変更できるという利点が、逆に事故につながる場合があります。

クラウドセキュリティ対策の方法は？

ひとつは、クラウドサービスの設定に関わるベストプラクティス集を利用する方法です。各クラウドベンダーから公開されており、日本語版も用意されています。CISベンチマークという第三者機関が開発したセキュリティに関するガイドラインもあります。ただし、網羅性が高く項目も多いため、必要な項目を探すには時間がかかる場合もあります。

もうひとつは、クラウドの設定にセキュリティ上の問題がないか診断するツールを利用する方法です。実用するには一定の習熟が必要で、たとえば出力された多数の脆弱なポイントについて、どこを優先して対処していくかの判断が求められます。セキュリティ企業が提供する診断サービスを利用する方法もあります。パブリッククラウドの設定にリスクがないか専門家が診断します。

まとめ

・クラウドのセキュリティは、クラウドサービスの提供側と利用者側双方で担保する
・提供側はインフラ等のセキュリティに責任を負う
・利用者側はセキュリティ、ネットワーク、アカウントなどの設定・管理を適切に行う
・利用者側の対策として、ベストプラクティスの活用、自動診断ツール、セキュリティベンダーの提供するサービスを利用するといった方法がある

標的型攻撃とは、攻撃者が明確な目的を持って、特定の企業や組織･個人などを狙って行うサイバー攻撃です。日本国内では、2011年頃から多く報告されるようになりました。

サイバー攻撃の多くには、これまではっきりした目的がありませんでした。無差別に感染させるウイルスやワーム、不特定多数に向けて大量送信されるスパムメールなど、従来の攻撃は標的を選ばない「ばらまき型」が多くを占めていました。しかし標的型攻撃では、たとえば「製造業Ａ社の保有する、～分野の技術に関わる特許等の知的財産」など、ゴールが明確に設定されています。

標的型攻撃のうち、特に国家機密やグローバル企業の知的財産をターゲットとした、豊富な資金を元に、極めて高い技術水準で、長期間行う標的型攻撃のことをAPT（Advanced Persistent Threat：高度で継続的な脅威）と呼ぶこともあります。

メールから侵入する「標的型攻撃メール」とは

標的型攻撃の多くは、業務を装ってメールを送り、添付されたファイルやメール文中のリンク先にマルウェアを仕込む「標的型攻撃メール」をきっかけに行われます。マルウェアは、OSや特定のアプリケーション、プログラミング言語や開発環境の脆弱性を突いて感染を果たします。

「ハッカー御用達サーチエンジン」などと呼ばれる「SHODAN（ショーダン）」「Censys（センシス）」という検索エンジンがあります。GoogleのようにWebページを検索するのではなく、インターネットに接続されているサーバやコンピュータ、 IoT機器を対象とした検索エンジンで、これらを用いることで、たとえば脆弱性のあるOSにも関わらずパッチがあてられずに放置されているサーバを見つけることができます。

脆弱性が見つかったら、その脆弱性を突くマルウェアをブラックマーケットで購入あるいは開発し、PDFファイルなどに偽装し、メールに添付し標的型攻撃メールが送られます。少々簡素化していますが、こういう手順で標的型攻撃は行われます。

標的型攻撃メールの事例

標的型攻撃メールによってマルウェア感染や被害が発生した事例として独立行政法人情報処理推進機構（IPA）は、2012年に発行した「標的型攻撃メール<危険回避>対策のしおり」に具体的事例のリストを掲載しています。そこには、

・日本政府や中央官公庁

・日本を含む世界の化学･防衛関連企業48社

・日本の重電メーカー

などの組織が「報道された標的型攻撃メールの事件」として並んでいます。

同じくIPAが2015年に発行した「IPA テクニカルウォッチ 標的型攻撃メールの例と見分け方」では、標的型攻撃メールの生々しい偽装例が記載されています。それによれば、

・新聞社や出版社からの取材申込

・就職活動に関する問い合わせ

・製品に関する問い合わせ

・セキュリティに係る注意喚起

・注文書送付

・アカウント情報の入力要求

などに偽装して標的型攻撃メールが実際に送られたということです。

標的型攻撃メールの見分け方

標的型攻撃以前には、いわゆる「怪しいメールの見分け方」という鉄板の基準がありました。代表的な判断基準はたとえば「知らない人からのメール」「フリーメールからのメール」「日本語の言い回しが不自然」などが挙げられます。標的型攻撃以前には確かにこれらの基準は有効でした。しかし、こういった基準が標的型攻撃以降、必ずしも通用しなくなっています。

ますます洗練されている標的型攻撃メールの基準に対応するため、IPAは前掲のレポート「IPA テクニカルウォッチ 標的型攻撃メールの例と見分け方」で、不審か否かを見分けるための着眼点として以下を挙げています。

・知らない人からのメールだが、メール本文の URL や添付ファイルを開かざるを得ない内容

・心当たりのないメールだが、興味をそそられる内容

・これまで届いたことがない公的機関からのお知らせ

・組織全体への案内

・心当たりのない決裁や配送通知

・ID やパスワードなどの入力を要求するメール

・フリーメールアドレスから送信されている

・差出人のメールアドレスとメール本文の署名に記載されたメールアドレスが異なる

・日本語の言い回しが不自然である

・日本語では使用されない漢字が使われている

・実在する名称を一部に含む URL が記載されている

・表示されている URL と実際のリンク先の URL が異なる

・署名の内容が誤っている

昔ながらの基準と変わらない点もあるものの、「心当たりのないメールだが、興味をそそられる内容」「これまで届いたことがない公的機関からのお知らせ」「組織全体への案内」などは、業務上開封せざるをえないことも少なくないでしょう。「よほど仕事を怠けていない限りひっかかる」これは標的型攻撃メールに関してよく言われる言葉です。

近年の標的型攻撃メールは日本語も洗練されています。上記の基準ですら判別できない場合もあると心得ていたほうが間違いないでしょう。

標的型攻撃への入口対策

標的型攻撃メールを防ぐ「標的型攻撃メール訓練」

標的型攻撃メールを開封しないように、従業員のセキュリティリテラシーを上げるために「メール訓練」「標的型攻撃メール訓練」などと呼ばれるセキュリティサービスがあります。

模擬の標的型攻撃メールを作成し、事前に知らせずに従業員にメールを送信、本文中のリンクをクリックしたり添付ファイルを開いてしまった人を調べ、部門毎の攻撃メール開封率などを管理者に報告するサービスです。

標的型攻撃メール訓練サービスの比較のポイント

標的型メール訓練サービスは提供業者が多く、費用やサービスクオリティはさまざまです。ここで簡単に、いい標的型攻撃メール訓練会社の比較のポイントを列挙します。

・実施前に社内の業務手順や、うっかり添付ファイルを開いたりリンクをクリックしてしまいそうなメールの傾向を、丁寧なヒアリングをもとに考えてくれるかどうか

・開封率の報告だけでなく、添付ファイルを開いた後の初動対応分析や、万一開いた場合の報告体制、エスカレーションの仕組の助言などを行ってくれるかどうか

・標的型攻撃メールの添付ファイルを開いたりリンクをクリックすることで具体的にどのように被害が発生するか、リスク予測をしてくれるかどうか

・訓練で洗い出された課題解決のために従業員向け研修を実施してくれるかどうか

標的型メール訓練サービスは各社それぞれ個性と品質の差があります。一見似ているように見えますが、どのように運用するかによってサービスクオリティが大きく変わってきます。

組織には人事異動もあり業務内容も変わります。メール訓練をやる場合は、エビデンスのために実施する場合はともかく、本当に根付かせたいのであれば定期的な実施が必須といえるでしょう。

「入口対策」を考えると、教育訓練を施す標的型メール訓練は 「ヒト」 に対する対策として有効な対策の一つです。しかし、うっかり危険なファイルを開いてしまう確率がゼロになることは残念ながらありません。

もしあなたの会社の人事担当者に、就職を希望する優秀な経歴を持つ学生から、レジュメや志望動機を書いたPDFを添付したメールがGmailで届いた場合、彼･彼女はきっとそのメールを開かざるをえないでしょう。「よほど仕事を怠けていない限りひっかかる」のです。もはや「防ぐ」という視点と同時に、侵入されることを前提に考える時期が来ています。

開封率の低減を最重要視するのではなく、「開封されても仕方なし」というスタンスで取り組むことが重要です。訓練の目標を「開封された後の対応策の見直しと初動訓練」に設定し、定められた対応フロー通りに報告が行われるか、報告を受けて対策に着手するまでにどれくらいの時間を要するかを可視化して、インシデント時の対応フローおよびポリシーやガイドラインの有効性を評価することをお勧めします。また、従業員のセキュリティ意識を向上させるために、教育および訓練と演習を実施するのが望ましいでしょう。

標的型攻撃の対策方法

「侵入されることを前提に考える」とは、もはや完全に防ぐことはできないと認めることです。これは標的型攻撃がセキュリティ対策や産業に与えた最も大きな影響のひとつといえるでしょう。標的型攻撃やAPT攻撃以降に、「この製品を買えば100％防げます」オーバーコミット気味のセキュリティ製品の営業マンが、もしこんなセリフを言ったとしたら、もはや安請け合いどころか明白な嘘です。

標的型攻撃以降、「出口対策」「内部対策」という順番で、新しいセキュリティ対策の言葉が次々と生まれました。

「出口対策」とは、ファイアウォールやアンチウイルスソフトで防ぎ切ることができずに感染してしまったマルウェアが、重要な情報を盗み出し、外部に重要情報を送信する（盗み出す）前に、その通信を検知しブロックする対策のことです。

「内部対策」とは、標的型攻撃メールで特定のPCに感染したマルウェアが、隣のPCや、参照権限のあるサーバなど、ネットワークを「横移動（ラテラル･ムーブメント）」して、Active Directoryなどのクレデンシャル情報や、知的財産が置かれたサーバにたどりつかないよう横展開を阻害する対策のことです。ネットワークの区画化やSIEMによる分析、ユーザーの行動を分析するUEBA、果てはニセのクレデンシャル情報をネットワークに地雷のように置くデセプション製品など、各社工夫をこらした高価な先端製品が各社によって開発･提供されています。

一方で、従来の「入口対策」をパワーアップした対策として、添付されたファイルがマルウェアではないかどうかをSandboxという環境で安全に検証してからユーザーに届ける製品などが国内でも普及しました。

どれも優れた製品ですが、いずれにせよ完全に防げる神話はもう崩れています。侵入前提の対策や組織作りが必要です。しかし、高価なSandboxやSIEMなど先端の製品による対策をすべての組織でできるわけではありません。

しかし悲観する必要はありません。実は、昔から言われている基本対策も標的型攻撃に対して有効な対策の一つなのです。まずはWindowsOSやMicrosoft Office、Adobeなどの主要アプリケーションを最新の状態に保つことです。

また、Webサイトやアプリケーションなどの公開サーバ、社内ネットワークを対象に、見過ごしているセキュリティホールがないかどうかを見つける脆弱性診断の定期的実施や、いざ侵入できたらどこまで被害が拡大しうるのかを調べるペネトレーションテストの実施も同様に有効でしょう。

「我が社には盗まれるような特許も個人情報もない」これもよく言われる言葉です。しかし、近年「サプライチェーン攻撃」と呼ばれるサイバー攻撃が話題になっています。たとえば、大手グローバル自動車会社のB社を最終目的として、部品製造を行う系列の中小企業などから攻撃を行い、本丸を目指す方法などを指します。もはや関係ないと言える企業は少ないといえるでしょう。

まとめ

・標的型攻撃は、攻撃者が明確な目的を持ち、特定の企業や組織･個人などを狙って行うサイバー攻撃
・標的型攻撃には、業務を装った巧妙なメールの添付ファイルやメール文中のリンク先にマルウェアを仕込む「標的型攻撃メール」によるものが多い
・従業員のセキュリティリテラシーを上げて標的型メールを開封しないようにするためには、「標的型攻撃メール訓練」などのセキュリティサービスがある
・標的型攻撃を100％防御することは不可能なため、感染することを前提とした「出口対策」「内部対策」を講じることで攻撃成功の確率を下げる

BBSecでは

「ランサムウェア対策総点検」のうちのサービスの一つ、「ランサムウェア感染リスク可視化サービス」では標的型攻撃を受けてしまった場合の現状のリスクの棚卸を行うことが可能です。従来の標的型メール攻撃訓練からもう一歩踏み込み、「ヒト」の対策ではなく、「情報」の対策として、システム環境の確認や、環境内で検知された危険度（リスクレベル）を判定いたします。

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

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

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

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

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

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

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

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

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

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

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

不正アクセス対策

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

脆弱性対策

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

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

標的型攻撃対策

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

この記事では、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インジェクションですが、リスクはゼロではありません。定期的な脆弱性診断は有効性の高い対策と考えてよいでしょう。

今回の記事では、2017年末に日本の航空大手の海外法人が被害を受けたことで一気に警戒感が高まった「ビジネスメール詐欺」について解説します。ソーシャルエンジニアリングの手法を応用したビジネスメール詐欺の手口や攻撃プロセスを説明し、被害件数や被害額なども紹介しながら、どんな対策が有効性が高いのかを考えます。

ビジネスメール詐欺とは

ビジネスメール詐欺とは、入念に準備した偽の電子メールを企業・組織の従業員に送り、不正に送金などを行わせる犯罪です。英語は「Business E-mail Compromise」です。「BEC」と略され、「ビーイーシー」あるいは「ベック」と呼ばれることもあります。

ビジネスメール詐欺の種類

ビジネスメール詐欺にはどのような種類があるのでしょう。独立行政法人情報処理推進機構（IPA）による注意喚起では、詐欺の手口にもとづく、下記5タイプの分類が使用されています。

・取引先との請求書の偽装
・経営者等へのなりすまし
・窃取メールアカウントの悪用
・社外の権威ある第三者へのなりすまし
・詐欺の準備行為と思われる情報の詐取

なお、この分類は、米国政府系機関のIC3（Internet Crime Complaint Center：インターネット犯罪苦情センター）の定義によるものであり、IPA以外にも、多くのセキュリティ機関で使用されているものです。実際のケースでは、しばしば上記に挙げた手口を複数組み合わせる形で攻撃が実施されます。

ビジネスメール詐欺は人の心理の弱点を突く

ビジネスメール詐欺では、メールアカウント窃取などで技術的な手口も使いつつ、人間の認知能力・心理などの弱みを突いた、巧みなソーシャルエンジニアリングが行われます。

得意先の担当者になりすまし「振込先の口座が今月から変更になった」と連絡する、海外出張中の社長を装い「緊急な案件で資金が必要だ」と確認の余地なく従わせる、「明日の正午までに」と時間を区切って切迫感を高める、頼れる知人のふりをして「君にしか相談できない」と内密感をかもし出し発覚を遅らせる、などなど、やり方は実に多彩です。攻撃者は、ある意味、人間心理を知り尽くした詐欺のプロフェッショナルとも言え、標的となった相手を信じ込ませるために、ありとあらゆる手段を総動員します。

ビジネスメール詐欺実行のプロセス

ビジネスメール詐欺では、詐欺メールの送り先となるターゲットは、職務等にもとづいてあらかじめ絞り込まれます（例：送金に関わる経理担当者など）。もし同じ職務を担当する社員が複数名いるなら、事前の情報収集で「より攻撃に弱い」とみなせる人物がターゲットになります。典型的な実施プロセスは下記の通りです。

1．標的とする企業の選定
2．フィッシング、マルウェア感染などのサイバー攻撃による電子メールアカウント乗っ取り
3．乗っ取った電子メールアカウントを用いた情報の収集・分析
　例：
　・組織図や人事情報
　・意思決定者や経理担当者などのキーパーソンの氏名・役職・権限・業務管掌
　・企業の業務プロトコルや各種社内規定、企業文化
　・毎月の経理処理のスケジュール
　・主要取引先の担当者氏名・役職・権限、取引の詳細
　・ターゲット候補に関する情報
　（性格や気質、言葉遣いの癖、趣味やプライベート、出張・休暇情報など）
4．ターゲット、攻撃シナリオの決定
　例：経理担当者A氏をターゲットにし、大口取引先B社の経理担当者C氏になりすます
5．詐欺ドメインの取得
　例：大口取引先B社とよく似たドメインの取得、メールサーバの設定 他
6．なりすましメール送信
　例：A氏に対し、C氏を装った電子メールを送信
7．攻撃成功
（なりすましであることに気づかれることなく、メールの内容にもとづく行動を起こさせる）
　例：A氏がなりすましメールの指示通りに、攻撃者の口座へ入金処理を実施

ビジネスメール詐欺と標的型攻撃メールとの違い

ビジネスメール詐欺は、「ターゲットを絞り込む」という点で、「APT」と呼ばれる標的型攻撃で使われるメールと似ていますが、その目的をみると、両者には明らかな違いがあるといえます。 標的型攻撃の最終的な目標は、多くの場合、航空エンジン設計や新薬開発のような、莫大なお金と時間をかけて生み出された知的財産だったり、ときに重要な国家機密だったりします。一方、ビジネスメール詐欺は、単に「なるべくたくさんのお金をかすめ取る」ことでその目的が達成されます。金銭的報酬を最終目的に、ターゲットについて調べに調べたうえで実行されるのが、ビジネスメール詐欺といえるでしょう。

それぞれの攻撃シミュレーション

＜標的型攻撃メール＞
攻撃者のターゲットに対して、たとえば「名門大学の新卒学生や取引先を装い、人事担当者に対して履歴書PDF付きのメールや業務に関するファイルを添付したメールを送る」など、ターゲットとなる人物が思わず開封してしまうような内容のメールを送ります。

＜ビジネスメール詐欺＞
多くは、自分の上司、同僚や見知った人物などとのこれまでの業務上のやり取りに攻撃者が直接介入し、取引先になりすまして、通常の業務プロセスやスケジュールに添って、いつも通り（ただし、振込先の口座が違うなど、一部の情報が異なる）のメールを送ります。

ビジネスメール詐欺の被害件数、被害額

IPAが毎年発表している「情報セキュリティ10大脅威」では、「ビジネスメール詐欺による被害」は2018年に初登場し、いきなり第3位にランクインしました。その後、2019年は2位、2020年は3位です。こうした、上位に居座り続ける脅威には、対策が難しく、いざ発生すると被害が大きなものになりやすいという傾向があります。

では、具体的にはどのくらい被害が出ているのでしょう。前出の米国IC3（Internet Crime Complaint Center：インターネット犯罪苦情センター）によると、2013年10月～2016年5月の統計では、米国内外における被害件数は22,143件、被害額は約31億ドルでした。その後、2016年6月～2019年7月の統計では被害件数166,349件、被害額は約262億ドルとなり、件数、被害額ともに大きく増加しています。*2 https://www.ic3.gov/Media/Y2016/PSA16061 https://www.ic3.gov/Media/Y2019/PSA190910

日本のデータとしては、一般社団法人 JPCERTコーディネーションセンター（JPCERT/CC）が2019年に実施した調査結果があります。国内企業12社を対象としたアンケートによると、詐欺メールによって請求された金額の合計は、約24億円にのぼったそうです（実際の被害が発生しなかったものも含めて計上）。

英語？ 日本語？ ビジネスメール詐欺の文面

日本でビジネスメール詐欺が注目を集めるきっかけになった被害事例は、大手企業の海外法人で起こったものでした。そのため「ビジネスメール詐欺は英語」とイメージしがちなのですが、2018年7月には日本語メールによるビジネスメール詐欺の攻撃事例が報告されています。その後、メールの日本語化は着実に進んでおり、2020年のIPAによる注意喚起でも、巧妙化する日本語の偽メールへの警戒が呼びかけられています。たとえ海外法人を持たず海外の取引先が一社もないとしても、安心はできないと考えておくべきでしょう。

ビジネスメール詐欺に有効な対策、ふたつのアプローチ

情報収集プロセスへの対策

ウイルス対策・不正アクセス対策・OSの更新・IDやパスワードの管理・二要素認証の採用など、一般的なセキュリティ対策は、「ビジネスメール詐欺実行のプロセス」のフィッシング、マルウェア感染などのサイバー攻撃による電子メールアカウント乗っ取りにも有効です。

実行プロセスへの対策

ビジネスメール詐欺を防ぐには、詐欺メールを見抜くための体系的な対策が求められます。教育によりセキュリティリテラシーの向上を図る、口座の変更などがあったら必ず社内承認を経るといった研修や運用面での対策、そして、偽メールを検知するために電子署名を付与したり、メールセキュリティ製品を導入したりするといった技術的対策、さらに、自社ドメインとよく似たドメインが第三者によって取得されていないか調査を実施するなど、多面的な取り組みが効果を高めるでしょう。

ビジネスメール詐欺ではどこまで自社の情報を集められるのか？

ビジネスメール詐欺は「ターゲットについて調べに調べたうえで実行される」と前に述べました。相手を欺くために練りに練られたメールを、最も攻撃に弱いと見立てたターゲットに送る。それがターゲットの元に届いてしまったとき、その後できる対策は決して多くはありません。

そこで求められるのが、前に述べた「ビジネスメール詐欺実行のプロセス」の、なるべく早期の段階にフォーカスした対策です。具体的には、2および3のフェーズ、すなわち「電子メールアカウントが乗っ取られて攻撃のための情報が収集、分析される」段階を想定してセキュリティ課題を抽出し、対策を立てることをおすすめします。「シフトレフト」に関する記事で言及しているように、対策は、プロセスの前段階であればあるほど効果的です。

なお、SQAT.jpを運営する株式会社ブロードバンドセキュリティでは、標的型攻撃への対策として開発された「SQAT® APT」というサービスを提供しています。このサービスでは、攻撃が成功した場合に社内の情報が一体どこまで収集されてしまうのか、どこまで侵入を許し何を知られてしまうのか、といった点を把握できるようになっており、ビジネスメール詐欺対策としても威力を発揮します。 もっともうま味のある成果を狙って、もっとも弱いところを突いてくる。それがビジネスメール詐欺です。起こりうる被害を可視化して対策を立て、早い段階で攻撃の芽を摘みましょう。

まとめ

• ビジネスメール詐欺とは偽物のメールを送って不正な送金等を行わせる犯罪です。
• 人間の弱点を突く、という点でソーシャルエンジニアリングのひとつと言うことができます。
• メールアカウントの乗っ取りなどを行い、企業・組織とそこで働く人について徹底的かつ緻密な調査を実施します。
• 「情報セキュリティ10大脅威」のベスト3に3年連続ランクインしている極めてやっかいな脅威です。
• ビジネスメール詐欺を防ぐには、詐欺メールに照準を合わせた対策を多面的に実施することが効果的ですが、一般的なセキュリティ対策も役立ちます。

今回は、サイバー攻撃の変わり種、システムではなく人間の弱点に付け入る攻撃、ソーシャルエンジニアリングを紹介します。

まずソーシャルエンジニアリングの具体的な手法を挙げ、どのように人間の弱点が利用されるのかを説明し、日本で起こったソーシャルエンジニアリングによる被害実例を紹介します。

途中ちょっと寄り道をして、オレオレ詐欺はソーシャルエンジニアリングなのかどうかについて考えつつ、最後に具体的かつ実践的な対策方法と、逆効果となる、とある対策・管理方針について言及します。

ソーシャルエンジニアリングとは

ソーシャルエンジニアリングとは、人を心理的に操作して、攻撃者にとって都合のいい行動を起こさせたり、機密情報を漏えいさせたりするサイバー攻撃です。情報収集やシステムへの不正アクセスなどを目的としています。

認知能力、心理など「人間の脆弱性」を攻撃するソーシャルエンジニアリング

アメリカの非営利のセキュリティ研究団体MITRE社の説明によると、ソーシャルエンジニアリングとは、人心を巧みに操り、その弱みにつけこんで、悪意ある相手に利するような行動や情報を引き出すというものです。具体的な例を挙げると、技術的な手段によらずに、口頭による会話といった「社会的（ソーシャル）」な手段で、ID・パスワードなどの重要情報を、巧みなやり方で関係者から直接聞き出す行為などがソーシャルエンジニアリングです。大きくは、人間の認知能力のさまざまな弱点やスキにつけ込むサイバー攻撃全般のことだといえるでしょう。

脆弱性診断サービスを提供するBBSecとして「脆弱性」という観点で申し上げるなら、ソーシャルエンジニアリングとは、「システムやソフトウェアではなく人間の脆弱性を突く攻撃」と言うことができます。

ソーシャルエンジニアリングの具体的手法

以下に典型的なソーシャルエンジニアリングの手法を挙げます。

・ショルダーハッキング
　 例）パスワード等をユーザの肩越しに覗き見る
・トラッシング（スカベンジング）
　 例）清掃員などに変装して標的組織に侵入し、書類やHDDなどのゴミや廃棄物をあさる
・なりすまし電話
　例）システム担当者などになりすましてパスワードなどを聞き出す
・ベイティング
　例）マルウェアを仕込んだUSBメモリを廊下に落とす
・フィッシング（ヴィッシング、スミッシング等 含む）
　 例）信頼できる存在になりすまし、ID・パスワード、クレジットカードなどの情報を入手する
・ビジネスメール詐欺
　例）取引先などになりすまし、犯人の口座へ振込を行わせる
・標的型攻撃メール
　例）ターゲットに対する入念な調査に基づいて作成した、完成度の高いなりすましメールを送る

たとえば「なりすまし電話」ですが、上記に挙げた例とは逆に、入社したばかりの何も知らない社員を装ってシステム担当者に架電し、やり方がわからないふりをするなどして徹底的にイライラさせて、思わずパスワードを口に出させるなどの方法も存在します。人間の認知能力のスキをつくソーシャルエンジニアリングには、実にさまざまな方法があるのです。

ソーシャルエンジニアリングの最大の特徴とは

人の脆弱性を突くソーシャルエンジニアリングの最大の特徴は、ターゲットを信頼させ、攻撃者に有益な情報の提供などを自発的に行わせてしまう点にあります。MITRE社の説明に「人を操る」とあった通り、権力や暴力を振りかざして重要情報を聞き出した場合、それは単なる脅迫であってソーシャルエンジニアリングではありません。

ターゲットの心を意のままに操作して、自発的に、ときに笑顔で協力させてしまう点にこそ、ソーシャルエンジニアリングを行う犯罪者の真骨頂があります。

ソーシャルエンジニアリングはどのように人間の弱点につけ込むのか

ソーシャルエンジニアリングは攻撃対象が信頼してしまう存在などになりすましてターゲットを信頼させ、心を開かせたり油断させることで行われます。

そのために攻撃者がしばしば目を付けるのが、「権威」に対する人間の弱さです。会社の取締役を装って電話をかける、得意客になりすましたビジネスメールを送る、大手金融機関や有名ブランドをかたったフィッシングメールを送る、などの手口に騙されるのが典型的なケースです。

なお、メールアカウントを乗っ取って旧知の取引先などになりすましたメールを送信することで拡散を図るEmotetは、フィッシングを行うマルウェアであり、ソーシャルエンジニアリングの一類型と言うことができます。

オレオレ詐欺はソーシャルエンジニアリングか

権威以外にも「義務感」「正義感」あるいは「好意」につけ込む方法もよく用いられます。多くの人は、困っている人に出会ったら「助けなければ」と感じます。助ける相手が親しい人物や好感を持てる人物であればなおさらです。

そこで思い浮かぶのがオレオレ詐欺ですが、ちなみに、この手の犯罪は、「ソーシャルエンジニアリング」なのでしょうか？

答えはNoです。ソーシャルエンジニアリングは、コンピュータセキュリティの文脈で使われる言葉であり、コンピュータやシステムへの不正アクセスを行うことを目的のひとつに含むという前提があります。そのため、オレオレ詐欺がソーシャルエンジニアリングと呼ばれることは一般にはほとんどありません。

ニューノーマル、テレワーク時代に気をつけたいソーシャルエンジニアリング

大きな環境変化の最中や直後などは、ソーシャルエンジニアリングの絶好の機会です。平時にはない緊張を強いられることで人々の不安やストレスが増し、感情的に動揺しやすくなるためといわれています。2020年、新型コロナウイルスの感染が一気に拡大した当初も、品薄状態だったマスクの配布をうたうメールやWebサイト、保健所からの連絡を装った攻撃などが複数確認されました。ニューノーマル時代、こうした攻撃に引き続き警戒が必要であることはいうまでもありません。

また、テレワークによって従業員どうしが切り離された就業環境においては、フィッシングメールや標的型攻撃メールの感染確率が上がると言われています。これは、オフィスにいたなら同僚や情報システム部門に「変なメールが届いた」と気軽に相談できていたことが、テレワークによって難しくなるからです。

日本で起こったソーシャルエンジニアリングの被害実例

2015年に発生した日本年金機構の情報漏えい事件は、「【医療費通知】」という件名の標的型攻撃メールが公開メールアドレスに届き、その添付ファイルを開いたことが発端であったとされています。

また、2017年に大手航空会社がビジネスメール詐欺で数億円をだましとられた事件も、2018年に仮想通貨取引所から暗号資産が流出した事件も、いずれもソーシャルエンジニアリングが攻撃のステップのひとつとして用いられています。

ソーシャルエンジニアリング対策・防止策

では、こうしたソーシャルエンジニアリングを防止する対策方法には、どのようなものがあるのでしょうか。

「ソーシャルエンジニアリングの具体的手法」で挙げた攻撃に対しては、たとえばショルダーハッキングならプライバシーフィルターを利用する、ビジネスメール詐欺ならメールの指示をうのみにせず本人に電話をして確認するなど、さまざまな対策方法が存在します。また、近年攻撃者はSNSを活用してターゲットに関する情報を集めることが知られていますので、SNSの利用に組織としてルールを設けるなどの方法も有効です。研修や教育なども効果があります。

しかしその一方で、人間の脆弱性を突く攻撃を完全に防ぐことはできない、という観点に基づいた対策も、併せて必要になります。攻撃を防ぐ対策と同時に、攻撃が防げなかった場合（成功してしまった後）の対策も考える必要があるのです。BBSecはこの考えのもと、標的型攻撃リスク診断やペネトレーションテストなどのサービスを提供し、攻撃を受けることを前提としたセキュリティ対策に取り組む企業・組織の皆様をご支援しています。

企業が絶対にやってはいけないソーシャルエンジニアリング対策

ソーシャルエンジニアリングは人間の脆弱性を突く攻撃です。だからこそ、対策として絶対にやってはいけないことがあります。それは、騙された人を叱責する、何らかのペナルティを与える等の懲罰主義の管理です。

罰を受けるのを恐れることによって、事故が発生しても報告がなされず、それが、インシデントの発見の遅れを招き、組織にとっての致命傷を生むことがあります。あなたも私も、人間は皆、あやまちを犯す生き物なのです。あやまちを犯すことが覆い隠されてしまうような管理は、何の成果も上げられないでしょう。

まとめ

• ソーシャルエンジニアリングとは、人の心を操って重要情報等を聞き出したりすることです。
• ショルダーハッキング、フィッシング、ビジネスメール詐欺、標的型攻撃メールなど、さまざまな手法があります。
• ソーシャルエンジニアリングは、「権威」「義務」「好感」などに惑わされる人間の弱さをあらゆる手口で突いてきます。
• 環境が急激に変化する時は、ソーシャルエンジニアリングの付け入るスキが生まれます。ニューノーマルや急速なテレワーク化への対応を迫られる現在も、その例外ではありません。
• 懲罰主義による管理は、ソーシャルエンジニアリング対策として何の効果もなく、インシデント発生の対応が遅れる要因になります。

いま、インターネットを「フィッシングとは」で検索すると、実にたくさんのサイトが見つかります。その説明を最大公約数的にまとめると、次のような感じです。

フィッシング詐欺とは、偽サイトを作ってオンラインバンキングなどのIDとパスワードを盗み不正送金等を行うもので、ユーザは騙されないように正しいURLかどうかを検証したり、メールの日本語に不自然な点はないかを慎重に確認することが求められます。

確かにそのとおり…なのですが、でも、「これで十分なのか？」と思いませんか？ たとえば、「この日本語、完璧…。自分よりうまい」と、偽メールを見て感じたことはないでしょうか。また、偽サイトが作られた場合、本物のサイトを運営している企業はどうすればよいのでしょう。本記事では、フィッシングの最新の脅威動向を踏まえながら、法人視点でフィッシングへの対策を考えます。

フィッシングとは

フィッシングとは、電子通信において、信頼できる存在になりすまして、ユーザ名やパスワード、クレジットカード情報などの機密情報やデータを入手する詐欺的な行動のことを指すとされています。信頼できる存在になりすます点で、ソーシャルエンジニアリングのひとつです。魚釣りの「Fishing」の「F」を「Ph」にした「Phishing」と表記され、語源には諸説あります。

なお、日本では、「フィッシング詐欺」という言い方が使われることが多いです。「フィッシング」という言葉自体にすでに「詐欺」の意味が含まれているため厳密には重ね言葉なのですが、カタカナのみの語句よりも直感的な分かりやすさはあるといえるでしょう。

銀行が本腰を入れたフィッシング詐欺対策の成果

日本では、都市銀行や地方銀行などの金融機関が、フィッシング詐欺の危険性を訴える啓発キャンペーンを組織的に行ってきました。その結果、フィッシングといえば、偽サイトなどに誘い込んでIDとパスワードを不正に入手するサイバー攻撃であるというイメージが定着し、前述のような「正しいURLかどうかを点検する」「メールの日本語に不自然な点はないかを確認する」といった対策が普及してきました。しかし、これがフィッシングのすべてを表すわけではもちろんありません。

フィッシングの目的とは

サイバー攻撃の包括的フレームワークとして知られるMITRE ATT&CKでは、「フィッシング」は、メールの添付ファイル、メールのリンクのほか、ソーシャルメディア等のサードパーティサービスを用いて実行されると記載されています。また、その主な目的は、標的のシステム上で悪意のあるコードを実行すること、または、有効なアカウントを利用するためのクレデンシャル（身元識別に用いられるID、パスワードなどの情報）を収集すること、とされています。

あのEmotetがやっていることもフィッシング？

2020年に国内で多数の被害が確認されたマルウェア「Emotet」は、PCやブラウザに保存されたクレデンシャルを盗む活動を行ったり、「Trickbot」などのトロイの木馬をダウンロードして、「Ryuk」などのランサムウェアを展開することがわかっています。

Emotetは、ユーザをわざわざ偽サイトに誘導してからクレデンシャルを盗るような悠長なことはしません。ですから、IDとパスワードをうっかり入力して盗られて不正送金されて大変！という、都銀地銀が注意喚起するタイプのフィッシングとは異なりますが、 上記MITRE ATT&CKのフレームワークを踏まえると、明らかに「フィッシングを行うマルウェア」と言えるでしょう。

フィッシングの手法と手口

フィッシングでは、攻撃者は「信頼できる」とみなされる存在を何らかの形で装い、標的を罠にかけます。たとえば、本物そっくりのサイト、もっともらしい文面のメール、もっともらしい名前のファイルなどがそうです。

なお、フィッシングの中でも、特定の企業や個人を狙ったものは「スピアフィッシング」と呼ばれており、攻撃側は、目的を達成するために、標的を徹底的に研究し、特定の相手にとって不自然さを感じさせないメールやフォームを作りこみます。なお、スピアフィッシングにおいて、上級管理職など、組織の重要人物を狙った攻撃は「ホエーリング（「捕鯨」の意）」と呼ばれます。

関連した手法として、DNSの設定を書き換えて偽サイトに誘導する「ファーミング」、電話などの音声通話を用いた「ヴィッシング」、SMSを使う「スミッシング」どもあり、その手口はさまざまです。

フィッシングのターゲットと被害件数

2020年6月にフィッシング対策協議会が公開した「フィッシングレポート2020」によると、フィッシングサイトのURL件数を用いた分析の結果、2019年において最も狙われたビジネス領域はクラウドコンピューティングサービス（2,106件）でした。次いでネットショップ・ECサイト（1,256件）、銀行（882件）、通信事業者（421件）、クレジットカード（350件）の順となっており、これら上位5つのビジネス領域で、件数全体の約8割を占めることが明らかになっています。トップのクラウドコンピューティングサービスが、2位以降を大きく引き離している点に注目しましょう。

「フィッシングと聞くと、銀行の不正送金を連想してしまう」という方は、認識のアップデートが必要かもしれません。なお、同協会に届け出られたフィッシング報告件数自体も、前年比2.8倍（55,787件）というペースで大きく伸びており、この点にも警戒が必要です。

企業にとっての2つのフィッシング脅威

企業にとってのフィッシングの脅威は、大きく2つに分けられるといえます。ひとつは、自社の従業員がフィッシングの餌食になってしまうこと、もうひとつは、自社ブランドをかたるフィッシングサイトが、世界のどこかの国のサーバに立ち上げられてしまうことです。前者においても大きな被害が発生する可能性はありますが、後者の場合は、自分たちのブランド名のもと多くのユーザが被害にあってしまうという点で、次元の違うインパクトを引き起こしかねません。

もし自社のフィッシングサイトが立ち上げられてしまった場合、本物のサイトを運営する自分たちに過失があったか否かにかかわらず、社会的信頼の失墜や、ユーザ離れなどが生じる可能性があります。

無料で依頼できるテイクダウン（閉鎖）

もしフィッシングサイトを立ち上げられてしまった場合、そのサイトを閉鎖するためのアクションを早急に行う必要があります。このアクションのことを「テイクダウン」と言いますが、実は、それに無料で対応してくれる機関があります。一般社団法人JPCERTコーディネーションセンターです。同センターでは、「インシデント対応依頼」という窓口を設けており、企業に代わって、サイト管理者へフィッシングサイトが公開されていることを連絡しフィッシングサイトの停止を依頼してくれます。フィッシングサイト以外にも、複数のインシデントへの対応依頼が可能ですので、ぜひ一度チェックしてみてはいかがでしょうか。

企業にとってのフィッシング対策

自社がフィッシングの標的となった場合に被害を未然に食い止め、もしフィッシングサイトが作られてしまったとしてもその被害を最小に食い止める――これは、Webサイトを持つすべての企業が取り組むべきセキュリティ課題といえるでしょう。では、具体的にどうすればよいのか。例として、フィッシング対策協議会による「重要5項目」をご紹介しましょう。

１．利用者に送信するメールには「なりすましメール対策」を施すこと
２．複数要素認証を要求すること
３．ドメインは自己ブランドと認識して管理し、利用者に周知すること
４．すべてのページにサーバ証明書を導入すること
５．フィッシング詐欺対応に必要な組織編制とすること

あなたの会社の取り組みは、いかがでしょうか？もし、どこから手を付けてよいのかわからない、ということであれば、セキュリティ専門企業に相談されることをおすすめします。

もしフィッシングの被害にあったら

それでは、自社の従業員がフィッシングの被害にあうことを防ぐにはどうすればいいでしょうか。

いわく「メールの送信元を確認する」「メールやSMSの文面に違和感がないかチェックする」「正しいURLか確認する」等々…。冒頭でも述べましたが、検索上位に並ぶこうした対策は、一昔前から変化がありません。もちろん、いずれも間違ってはおらず、こうした基本的啓発活動の重要さは今後も変わることはないのですが、攻撃者の技術力は日進月歩です。たとえば今日、偽メール文を見て日本語の不自然さをみじんも感じない、というケースは少なくありません。

基本対策を実践するのはまず当然として、今後は、「騙されてしまうことはあり得る」と想定し、被害前提・侵入前提での対策も考える必要があります。BBSecでも、この認識のもと、「もしフィッシングにひっかかってしまった場合、どこまで企業の資産に被害が及ぶのか、その結果、どれだけビジネスインパクトがあるのか」を検証するサービスを提供しています。

まとめ

• フィッシングとは、信頼できる存在を装って、守秘性の高いデータの取得を図るサイバー攻撃です。
• フィッシングの一環として、悪意のあるコードを実行する活動が行われることもあります。その意味で、あのEmotetでやられていることもフィッシングといえます。
• フィッシングの攻撃対象としては、銀行やECサイトが連想されがちですが、実はもっとも多いのはクラウドコンピューティングサービスです。
• 自社ブランドのフィッシングサイトが立ち上げられてしまった場合、専門機関を介して閉鎖依頼をかけることができます。
• フィッシングの手口は巧妙化・多様化しています。「騙されてしまうことはあり得る」と想定し、被害前提・侵入前提で対策をとることが必要です。

いろいろな場面で「ボット（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を運営する株式会社ブロードバンドセキュリティは、脆弱性診断やペネトレーションテストをはじめとして、APIやIoT機器まで、さまざまなセキュリティ診断サービスを提供しています。

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

まとめ

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