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

Share

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

PCI DSSとは

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

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

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

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

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

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

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

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

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

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

AWS環境下でのPCI DSS準拠

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

PCI DSSの12要件とは

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


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

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

カード会員データの保護

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

最新版「PCI DSS 4.0」とは

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

まとめ

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

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

Share

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

Share

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

Share

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

Share

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

IoTとは

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

IoTの活用事例

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

ITとIoTの6つの違い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

Share

もしあなたの会社が不正アクセスされたら

Share

不正アクセスとは、アクセス制御機能を持つWebサービスやサーバ等に、正当なアクセス権限を持たない者が侵入する行為、およびそうした侵入を助長する行為を指します。あなたの会社で不正アクセスが生じた場合、その対応を誤ったり、対処が遅れたりすることで、事業への損害、評判の低下といった重大な事態につながる恐れがあります。本稿では、不正アクセスの主な手口を紹介し、被害を防ぐための対策、実際に被害にあってしまった場合の対処方法を解説します。

「不正アクセス」とは

「不正アクセス」と聞くと、本来その権限を持たない者が、サーバや情報システムの内部へ侵入を行う行為をイメージしますが、厳密にどのような行為を指すのかは、1999年に公布(最新改正は2013年)された「不正アクセス行為の禁止等に関する法律(不正アクセス禁止法)」で規定されています。特に注意しておきたいのが、同法では、他人のID・パスワード(「識別符号」)を不正使用した場合だけでなく、それ以外の情報を入力してWebサービスやサーバ等のシステム(「特定電子計算機」)を作動させる行為なども、「不正」とみなされる点です。また、不正アクセスを助長する行為としてID・パスワードの不正取得が禁じられているほか、ID・パスワードの不正な保管行為も同法に抵触します。違反した場合は、3年以下の懲役又は100万円以下の罰金が処せられます。

調査やテストで不正アクセスの加害者となる危険性も

なお、不正アクセス禁止法の定義に関しては、当該アクセスが「承諾」を得ていなければ不正とみなされる、という点にも注意が必要です。システムのセキュリティ診断を例に考えてみましょう。SQAT.jpを運営する株式会社ブロードバンドセキュリティでは、Webアプリケーションや社内ネットワークにセキュリティ上の弱点が存在しないかどうかを評価する脆弱性診断ペネトレーションテストを、システムを管理する企業からアクセスに対する承諾をいただいたうえで実施しています。もしこうした行為を、承諾もないのに実施していたとしたらどうでしょう。たとえそれが善意に基づくものであっても、不正アクセス禁止法に抵触することとなり、刑事罰が科されるかもしれません。

脆弱性診断やペネトレーションテストを行うツールは多数存在しており、無料で手に入れることも可能ですが、安易に使用することは禁物です。万一あなたの会社の技術者が、運用管理や保守、攻撃耐性の確認等の目的でこうしたツールを使用しており、その対象となるシステムが他社の管理下にある場合、不正アクセス禁止法に抵触するリスクがあることは覚えておくべきでしょう。

不正アクセス、その方法と手口

では、そもそも悪意を持った、攻撃者による不正アクセスの手口にはどのようなものがあるのでしょう。典型的なのは、「盗んだIDとパスワード、あるいは推測したパスワードを使って、システムに不正にログインする」というものです。ID・パスワードの組み合わせを総当り的に試してログインを図る「ブルートフォース攻撃」、辞書にある語句を利用する「辞書攻撃」、不正に入手したログイン情報を利用する「パスワードリスト攻撃」などが知られています。

中でも近年特に話題を集めているのは「パスワードリスト攻撃」です。背景には、数十万~数億件規模のID・パスワードがセットで売買されていたり、インターネット上に公開されていたりする事態があちこちで確認されており、攻撃者が不正アクセスのための情報を容易に手に入れやすくなっている状況があります。また、もし複数のシステムに対して同じID・パスワードが使いまわされている場合、1件の情報を入手することで複数のシステムへのログインが可能になるという点も、攻撃者を引き付けています。

この2020年8月には、日本企業約40社において、VPN(Virtual Private Network)のID・パスワードが盗まれ、インターネットに公開されるという事件が発生しました。VPNは、本来、セキュリティを確保したうえで企業ネットワークへアクセスするために使われる「安全性の高い入口」です。そこにログインするためのID・パスワードが盗まれることが極めて大きな被害につながり得ること、裏を返せば、攻撃者にとって極めて大きな利得につながり得ることは、論をまたないでしょう。

もちろん、不正アクセスのための攻撃は、ID・パスワードを狙ったものだけではありません。ID・パスワードの入手につながる脆弱性も格好の標的になります。例えば、Webアプリケーションや公開Webサーバの脆弱性はその最たるものです。攻撃者はしばしばSQLインジェクションの脆弱性クロスサイトスクリプティングの脆弱性などを悪用して個人情報を不正に入手し、ID・パスワードを特定してシステムへの侵入を試みます。

ID・パスワードの保護に加え、結果としてID・パスワードの特定につながる脆弱性を放置しないことが、不正アクセスを防ぐためには最重要といえるでしょう。

「あなたの会社が不正アクセスされています」
突然やってくる電話やメール

もし実際に不正アクセスが行われた場合、それはどのようにしてわかるのでしょう。残念なことに、自分では気づけず、外部から指摘されて知ることが少なくありません。例えば、クレジットカード情報が不正アクセスによって盗まれた場合、カード会社から直接、漏えいや不正利用の兆候がある等の連絡が来ることがあります。また、サイバー犯罪の捜査過程で、あなたの会社に不正アクセスが行われていることが発覚した場合、さらには、それが他の会社での被害につながっていることが発覚した場合には、警察やセキュリティ事故発生時の調整を行う機関など(一般社団法人 JPCERT コーディネーションセンター等)から連絡が来ることもあります。

なお、サイバー攻撃が起こることを想定した組織体制がない場合、やってきた連絡が正当なものであるかの判断自体がつかない場合もあるかもしれません。実在する機関を装い、虚偽の不正アクセス事案を連絡する犯罪が発生する可能性も想定し、連絡の真偽は必ず確認するようにしましょう。

不正アクセスを防ぐための日頃の対策

日頃からWebサービスやサーバのセキュリティ強化に取り組むことで、不正アクセスの発生を抑え、万が一不正アクセスが発生した場合にも早期あるいは即時に把握することが可能になります。

例えば、サーバに対するアクセスログを収集・保存し、同一IPからの複数回ログインに対するアラートをルール化する等の設定をしておくことで、誰かが不正ログインを行っていることを早期に知り、ブロックするなどの対処を行えるようになります。

不正アクセスされてしまったら、すぐに行うべきこと

以前の記事「情報漏えいとは? 代表的な原因や求められる対応策」では、「情報漏えい事故の報告書と収束までの流れ」として、事故発生時の報告書作成の注意点について解説しました。今回は、不正アクセスされた直後の対応や、真相究明を行う社内の組織体制構築でのポイントをご紹介します。

不正アクセス事故対応のチーム作り

セキュリティ事故対応を行う専門部署であるCSIRTが社内にない場合は、事故対応チームを速やかに組織しなければなりません。どのような編成を想定すべきか、参考として、モデル的な図解を下記に示します。

https://www.nca.gr.jp/activity/imgs/recruit-hr20170313.pdf より当社作成

もちろん、セキュリティ専門企業でない限り、ほとんどの組織にとってはここまでの編成をとることは合理的とはいえません。既存の組織・人員の状況に応じて、下記のような事項をポイントにチームを編成し、自組織の業種業態、慣習、人材、文化等を踏まえながら継続的にチームの発展・強化に取り組むことをお勧めします。

  • CSIRTがインシデント発生時における最終判断(システム停止も含む)までを担う場合は、責任を担う経営陣を参画させる。
  • 現体制におけるキーマンを特定し、そのキーマンを必ずメンバーに加える。
  • 現体制で実施できている役割がないか確認する(「実施できている役割は踏襲する」という判断も重要)。
  • 技術的な知識、経験、人材を持たない場合は、最低限CSIRTに必要な機能(=有事の報告、伝達を的確に行い、意思決定者へ早期伝達すること)を有する、「コーディネーション機能に重点を置いたCSIRT」を目指す。

取引先、関係者、個人情報保護委員会への連絡

あなたの会社のステークホルダーに対して、現時点で判明している事故の事実関係を連絡します。規制業種の場合は所轄官庁への報告義務があります。なお、個人情報保護法では、個人情報漏えい等の場合、本人通知や監督官庁への報告を努力義務としていますが、2022年に施行予定の改正個人情報保護法では一定範囲においてこれが義務化されるため注意が必要です。

不正アクセスの原因究明

続いて取り組むべきは、原因究明です。不正アクセスを受けた場合、侵入経路の特定や証拠保全などは自社でどこまで可能なのでしょう。監視やSOC(セキュリティオペレーションセンター)サービスの契約などによって保存してあるログを解析可能な場合、「不正アクセスの発端と展開過程がわかるから、自経路の解析や被害範囲の特定もできる」と考えてしまうかもしれません。しかし、火事場のように混乱する事故発生直後は、日頃から備えをしていた企業ですら、一刻を争う状況下で解析すべき情報の膨大さに圧倒されるものです。また、刑事事件として告発を行う場合や損害賠償請求を行う場合には証拠保全が必要となりますが、混乱し、慣れない状況下で証拠保全を念頭に調査や対応を行うのは大きな負荷となります。

さらに、「サイバー攻撃を行う5つの主体と5つの目的」で解説した「APT攻撃」が行われるケースも想定しておく必要があります。APTでは、侵入の痕跡を消されることが少なくなく、そのような場合、侵入経路の特定や証拠保存は難しくなります。しかし、日々ログの収集を行っていたとしたら、その痕跡からデジタルフォレンジックを実施することが可能です。

不正アクセス事故を前提に、「かかりつけ」セキュリティ企業を持つ

日頃からのアクセスログ収集や分析、SOCサービスの契約、CSIRT組織の設置など、平時の備えが不正アクセスを防止し、いざ不正アクセス事故が起きたときの対応力を高めてくれます。さらにもう1つ有効な取り組みとしてお伝えしたいのが、頼りになるセキュリティ企業との関係構築です。あなたの会社の業務やシステムのことを知っている、かかりつけ医のようなセキュリティ企業は、何かあったときのための備えのひとつになります。

それまで取引が一度もなかったセキュリティ企業に、事故が発生した際に初めて調査や対応を依頼したとしたらどうでしょう。社内のネットワーク構成、稼働するサービス、重要情報がどこにどれだけあるのか、関係会社や取引先の情報などについて、わずかな時間も惜しまれるインシデント対応の現場で、いちから説明しなければならなくなります。

脆弱性診断などの実施でセキュリティ企業に依頼を行う際は、信頼できる企業かどうか、いざというときにサポートしてくれるかどうか等、診断以外のサービス体制も幅広く調べたうえで、長期的な観点から利用を検討することをお勧めします。

まとめ

  • 不正アクセスとは、アクセス制御機能を持つWebサービスやサーバ等に、正当なアクセス権限を持たない者が侵入する行為、およびそうした侵入を助長する行為を指します。不正アクセス禁止法の違反者は、3年以下の懲役又は100万円以下の罰金に処せられます。
  • たとえ悪意がなくても、セキュリティ診断ツールなどを使用することで不正アクセス禁止法に抵触することがあります。
  • ID・パスワードの管理だけでなくWebアプリケーションやサーバの脆弱性管理も重要です。
  • 不正アクセスが実際に起こってしまったら、早急に対応チームを組織し、ステークホルダーへの連絡や原因究明を行います。
  • いざ不正アクセス事故が起きたときの対応力を高めるには、日頃からのアクセスログ収集や分析、SOCサービスの契約、CSIRT組織の設置、「かかりつけ」セキュリティ企業との関係構築などが有効です。

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

Share

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

Share

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

IoTとは

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

IoTの活用事例

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

ITとIoTの6つの違い

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

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

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

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

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

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

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

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

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

また、2019年には、アメリカで、防犯・監視カメラに攻撃者がアクセスし、子供や寝ている人に話しかけるという事件*5が起きました。同じメーカーが提供する玄関チャイムに、接続されている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、各種モジュールなど対象の組み合わせが無限に存在することから、事前に目的・予算・期間などを綿密に定義したうえで実施する必要があります。


Share

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のセキュリティ強化に取り組みましょう。


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

Share

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アプリケーションの脆弱性を積極的に発見し対処することは運営者の社会的義務です。


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

Share

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年下半期 カテゴリ別脆弱性検出状況


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

Share

サイバー攻撃の原因となる「脆弱性」を理解する

Share

情報漏えいなどの被害をもたらすサイバー攻撃の多くは、「脆弱性」を悪用して行われます。メディアを賑わすセキュリティ事故の相当数が、脆弱性への対応を放置することで引き起こされたものです。脆弱性が生まれる原因、脆弱性情報を収集する方法、脆弱性を見つけるために利用できるチェックツールや診断サービスについての理解を深め、適切な対応を行えるようにしましょう。

「脆弱性」とは?―設定ミスなどによるバグが攻撃に悪用

脆弱性の多くは、「プログラムの設計ミスやコーディングミスなどによるバグ」になります。バグが存在せず正しく動作するプログラムやWebアプリケーションであっても、設計者が想定しないやり方で機能が悪用され、結果としてサイバー攻撃が成立する場合には、その「悪用されうる機能設計」が脆弱性とみなされます。また、システムやサービス全体という視点からは、設定に関して何らかの誤りがあり、そのことによって情報漏えいが起こったりサイバー攻撃が行われたりする可能性がある場合、そうした設定ミスが脆弱性とみなされます。たとえば、ポートの開放に関する設定、権限管理、AWSをはじめとするクラウドサービスの設定ミスがセキュリティ事故を招いた例は枚挙に暇がありません。

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

脆弱性は「きじゃくせい」ではなく「ぜいじゃくせい」と読みます。対応する英語は、「Vulnerability」(「攻撃を受けやすいこと」の意)です。ハードウェア、サーバのOS、ソフトウェア、Webページ、Webアプリケーションなどに脆弱性が存在した場合、それが悪用されることで個人情報や知的財産を盗むようなサイバー攻撃を招くことになります。

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

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

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

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

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

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

さらに、特定の脆弱性によってどのような実害が発生するかは、脆弱性を発見したセキュリティ企業がブログなどで情報を公開している場合もあります。追加で調べてみてもいいでしょう。

日頃からできる脆弱性対策

衣服等の破れを補修する「継ぎ当て」や傷口に貼る「絆創膏」のことを英語で「パッチ(patch)」と言いますが、脆弱性を修正するプログラムも「パッチ」と呼ばれます。修正プログラムを適用することは「パッチをあてる」と言われたりします。脆弱性が発見されたら速やかにパッチをあてるのが原則ですが、下記のようにいくつか留意すべき事項がありますので、念頭に置いておきましょう。

・パッチをあてることにより、システムに影響が及ぶ場合があります。適用にあたっては事前に調査を行い、必要に応じて十分な検証を実施してください。なお、自組織で開発したシステムに関しては、必ずテスト環境を用意し、パッチ適用による整合性チェックを行ってください。

・自組織のネットワークやサーバでどんなソフトウェアが動いているのか、定期的に棚卸しを行って把握しておくことも重要です。棚卸しの過程で不要なサーバや機器などが発見されたら、将来のリスクの種を取り除く上で削除可能かどうかを確認してください。なお、棚卸しの際、ソフトウェアのバージョン台帳のようなリストを作成しておけば、新しい脆弱性が報告されたときに、自組織のシステムが該当するのかをすぐにチェックできます。

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

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

・テレワーク化が急速に進む今日では、以上の留意事項に加え、クライアントサイドでのパッチ適用が適切に行われているかをチェックする体制を構築することも重要です。また、シャドーITの状況把握も厳格に実施する必要があります。「IT部門が知らないサービスを勝手に利用され、結果として脆弱性の有無について未検証のクライアントソフトやブラウザプラグインが使われていた」という事態は防がねばなりません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

関連情報

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

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


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

Share

サイバー攻撃を行う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攻撃の脅威


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

Share