記録破りのDDoS攻撃!サイバー脅威の拡大と企業が取るべき対策とは?

Share

近年、DDoS攻撃の規模と頻度が急激に増加しており、企業や組織にとって無視できない脅威となっています。特に、2024年第4四半期には、過去最大規模となる5.6テラビット毎秒(Tbps)のDDoS攻撃が確認され、サイバー攻撃の新たな段階へと突入したことがわかりました。この攻撃は、わずか80秒間で1万3,000台以上のIoTデバイスを利用して実行され、Cloudflare社のDDoS防御システムによって自動的に検出・ブロックされました。

お問い合わせ

お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

DDos攻撃の事例として、SQAT.jpでは日本航空へのサイバー攻撃の実態についても解説しています。こちらもあわせてぜひご覧ください。
【徹底解説】 日本航空のDDoS攻撃被害の実態と復旧プロセス
Dos攻撃とは?DDos攻撃との違い、すぐにできる3つの基本的な対策

DDoS攻撃の増加と進化する手口

2024年第4四半期には、Cloudflare社が軽減したDDoS攻撃の件数が690万件にのぼり、前四半期比16%、前年比83%の増加を記録しました。さらに、1Tbpsを超える大規模攻撃の件数は前四半期比で1,885%も増加し、これまで以上に大規模な攻撃が常態化しつつあります。

HTTP DDoS攻撃では、既知のボットネットによる攻撃が全体の73%を占め、11%は正規のブラウザを装った攻撃、10%は疑わしいHTTPリクエストによる攻撃でした。ネットワーク層(L3/L4)攻撃では、SYNフラッド(38%)、DNSフラッド(16%)、UDPフラッド(14%)が主要な手法として確認されています。また、Miraiボットネットの亜種による攻撃が特に顕著であり、2024年第4四半期には、この攻撃手法の使用頻度が131%も増加しました。

企業が直面するDDoS攻撃のリスクとは?

DDoS攻撃がもたらす影響は多岐にわたります。最も直接的な被害は、システムのダウンによる業務停止であり、企業の信用低下や顧客離れにつながる可能性があります。また、近年増加している「ランサムDDoS攻撃(Ransom DDoS)」では、攻撃を受けた企業が身代金の支払いを要求されるケースが増えています。2024年第4四半期には、Cloudflare社の顧客でDDoS攻撃を受けた顧客のうち、12%が身代金の支払いを求められ、前年同期比で78%の増加を記録しました。

業界別にみると、通信業界が最も多くの攻撃を受け、次いでインターネット関連業界、マーケティング・広告業界が標的となっています。特に、金融業界は依然としてサイバー犯罪者にとって魅力的なターゲットとなっており、資金詐取を目的とした攻撃が増加しています。

DDoS攻撃から企業を守るための対策

DDoS攻撃の脅威が拡大するなか、企業は効果的な防御策を講じる必要があります。特に、以下のような対策が推奨されます。

  1. 常時オンのDDoS防御システムの導入
    DDoS攻撃の多くは短時間で発生するため、人間の対応では間に合わないケースが多いです。自動検知・防御機能を備えたDDoS対策ソリューションを導入することで、攻撃を迅速に無力化できます。
  1. ネットワーク層とアプリケーション層の両方を保護
    DDoS攻撃には、L3/L4(ネットワーク層)攻撃とL7(アプリケーション層)攻撃があります。両方の層に対する防御対策を講じ、ファイアウォールやWAF(Web Application Firewall)を活用することが重要です。
  1. ゼロトラストアーキテクチャの採用
    攻撃者の侵入を最小限に抑えるために、ゼロトラストモデルを導入することも有効です。認証・認可プロセスを強化し、アクセス制御を厳格化することで、不正なトラフィックを遮断できます。
  1. クラウドベースのDDoS対策の活用
    オンプレミスのDDoS対策はコストが高く、攻撃の規模が拡大するにつれて対応が難しくなります。クラウドベースのDDoS防御サービスを活用することで、スケーラブルなセキュリティ対策を実現できます。
  1. 定期的な脆弱性診断とインシデント対応計画の策定
    攻撃のリスクを最小限に抑えるために、定期的なセキュリティ監査を実施し、DDoS攻撃を想定したインシデント対応計画を策定することが不可欠です。特に、SLA(サービスレベルアグリーメント)を明確にし、攻撃発生時の対応フローを事前に決めておくことが重要です。

今後のDDoS攻撃トレンドと企業が取るべきアクション

DDoS攻撃は今後さらに巧妙化し、大規模化すると予想されています。特に、AIを活用したボットネット攻撃や、IoTデバイスを悪用した攻撃が増加する見込みです。さらに、特定の企業や業界を標的とした「高度な標的型攻撃(APT)」の手法がDDoS攻撃にも応用される可能性があります。

企業は、単に防御するだけでなく、プロアクティブなセキュリティ戦略を採用し、攻撃を未然に防ぐ体制を構築する必要があります。DDoS攻撃はもはや一部の企業だけの問題ではなく、あらゆる業界にとって喫緊の課題となっています。

常に最新の脅威情報を把握し、効果的な防御策を講じることで、企業のシステムとデータを守ることができます。DDoS攻撃のリスクを最小限に抑えるためには、今すぐ適切な対策を実施することが求められるでしょう。


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

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

  • 2025年2月19日(水)14:00~15:00
    Web担当者に求められる役割とは?Webサイトのガバナンス強化とセキュリティ対策を解説
  • 2025年2月26日(水)13:00~14:00
    AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク
  • 2025年3月5日(水)13:00~14:00
    ランサムウェア対策の要!ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年3月12日(水)14:00~15:00
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
  • 最新情報はこちら


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

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

    2038年問題とは?-2000年問題の再来?2038年問題の影響と解決方法-

    Share

    本記事では最近話題の「2038年問題」について解説します。2038年問題は狭義のサイバーセキュリティと関連するものではありませんが、そのまま放置してしまうとサイバーインシデントを引き起こす可能性がある問題となります。対応に準備に時間を要する問題であることから、読者の皆さまに早い段階から関心を持っていただければと考えています。

    2000年問題を振り返る

    初期のプログラミング言語(FORTRANやCOBOL注 1) など)はデータ型に日付型がなかったため、文字列を割り当てて日付として処理をしていました。

    この時、日付を文字列で処理する際、1960年代~80年代の人類は自分が作ったプログラムがその後長く使われるなどと思わず、「とりあえずYY-MM-DDで表示すればデータ量削減にもなるし、いいだろう」と考え、慣例として西暦年を下2桁で処理していました。

    図1:2000年問題の原因となった表示方法

    何しろ今とは異なりCPUもメモリも、貧弱でも超高価な時代です。資源の節約は必要な限り実行しなければならない課題だったといえます。しかし、1990年代に入ったところで人類はふと気づきます。「これはもしや、西暦年の下2桁だけだと2000年になった時、処理上1900年に戻ってしまうのでは?」と。

    図2:2000年問題

    そうして、1990年代半ばからプログラムの書き換えが行われ、それまで下2桁だった西暦年を4桁に変更し、万が一の時のために1999年12月31日から2000年1月2日までの間、一部のIT業界の人たちが正月返上で出勤して不測の事態に備えたのが2000年問題です。

    2000年問題では実際、2000年1月1日当日、特に何かが起こることはありませんでした。その背景は以下の通りです。

    2000年問題が2000年1月1日に何も問題とならなかった背景

    • COBOLやFORTRANなどのレガシー言語で古くに書かれたアプリケーションやマイコンなど対象が限定されていたこと
      (※C言語などの比較的新しい言語は日付型をデータ型に持っていたため関係がなかった。)
    • 発生日が明確だったこと
    • 対策が西暦年の2桁を4桁表示に変更するという方法に集約されていたこと
    • 数年間にわたって事前の対策がとられていたこと

    限定的な対象に対し、事前に入念な準備を行ったことが功を奏し、インシデントが発生しなかったことが2000年問題の結果です。

    計算機とデータ型:2038年問題の技術的背景

    さて2024年現在、コンピューター・タブレット端末・スマートフォンなど、見た目などから計算機であることがわかりづらいようになっていますが、やはりコンピューターは計算機です。実際アプリケーションを動かすにしてもプログラムがされていて、プログラムの実行には必ず計算が伴います。そして、プログラム上でデータを処理するためにはデータの種類を定めるデータ型というものがあります。

    データ型の例

    データ型
    文字列(str)今ご覧になっているいわゆる文字列のこと
    整数型(int)1, 2, 50, 1065, -5などの整数(負の数も含む)
    浮動小数点型(float)3.14, -0.001, 356.25などの小数点を含む数(負の数も含む)
    ブーリアン型(bool)真(True)か偽(False)のいずれかで表わされる
    日付型(date)世界標準時(UTC)を基準として、1970年1月1日からの経過秒数を表すタイムスタンプデータ。整数型データで表わされる

    2000年問題のときはFORTRANやCOBOLに日付型が存在せず、文字型で処理していたこと、また限られた資源を節約するために下2桁で年を表していたことが原因でした。一方、2038年問題は日付型のタイムスタンプデータを格納する整数型のデータ長(ビット幅)の実装が原因となるものです。

    SQAT.jpでは以下の記事で2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介しています。こちらもあわせてご覧ください。
    【続】プログラミング言語の脆弱性対策を考える:2024

    2038年問題の技術的課題

    符号付32ビット整数型から符号付64ビット整数型への移行の壁

    前述したデータ型の例の表にもあるように日付型は絶対的な日付を表すものではなく、1970年1月1日午前0時0分を基準日時(エポックタイム)としてそこからの経過秒数をタイムスタンプデータとしてあらわすものです。C言語ではtime_tと呼ばれるこのデータでは、タイムスタンプデータを格納するのは符号付32bitの整数型となっています。符号付整数型は最初の1bitを正負符号のために使用します。符号の1ビットがあるため、実際に日付データ用に利用できるのは正負を表す最初の1ビットを除く31ビットで、利用できるビット長は(231-1)=2,147,483,647秒となります。よって基準日時からおよそ68年を上限として演算・表示ができるものとなります。

    図3:符号付32bitであらわした2038年1月19日3時14分7秒

    図3は1970年1月1日午前0時0分から2,147,483,647秒が経過した、2038年1月19日3時14分7秒(※うるう秒は考慮しておりません)の符号付32bit整数型でのtime_tの状態です。一番左側の符号0は正の値を表しており、1970年1月1日午前0時0分から2,147,483,647秒、正の方向に経過したことを示します。

    さて、二進法の常で右側の31bitがすべて1になった場合、通常一番左側の1ビット目が1になります(二進法の繰り上がり)。

    図4:符号付32bitのままで2038年1月19日3時14分8秒になった場合

    1970年1月1日午前0時0分から2,147,483,648秒経過すると図4のようになります。符号付の場合、一番左側の符号1は負の値を表すため、1970年1月1日午前0時0分から2,147,483,647秒、負の方向に遡った1901年12月13日20時45分52秒を示します。つまり放置しておくと日付データが大きく誤ることとなります。この問題が最も深刻になるのは符号付32bitのtime_tを何らかの形で参照し、それを正しいものという前提で処理しているプログラムが、2038年1月19日の時点(または2038年1月19日以降の日付を参照する時点)で未改修のまま残ってしまうことで影響を及ぼしてしまうことなのです。

    ウェビナー開催のお知らせ

  • 2024年12月18日(水)14:00~15:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 最新情報はこちら


    2038年問題を回避する3つの対応策

    対策として考えられる方法はいくつかありますが、根本的な対策は以下の3つになります。

    1. time_tを符号付64bit整数型に変更する
    2. time_tを符号なし32bit整数型に変更する
    3. time_tの基準日時を1970年1月1日午前0時0分から別の日時に移動する

    主要OS・アプリケーションの2038年問題対応状況

    2038年問題の影響が一番大きく出ると当初予想されていたのが各種OSです。以下に各OSの対応状況を記載します。

    各OSの対応状況

    OS
    Linux64bitアーキテクチャ向けには当初より64bitのtime_tを提供。
    32bitアーキテクチャについてはLinux Kernel 5.6で64bit化対応済み。5.4/5.5についてもバックポートで対応済み。*1
    FreeBSD原則として64bit対応済みだが、i386アーキテクチャの32bitアーキテクチャのみ非対応。I386アーキテクチャについては符号なしの32bit整数型 time_tを提供*2
    Windows64bitで1601年1月1日0時からの100n sec単位の差分計算をしていることから2038年問題は対象外といわれている*3
    macOSmacOS10.0(Cheetah)で基準時を2001年1月1日0時に変更しており、2038年問題は対象外。また、32bitアプリケーションはmacOS 10.15(Catalina)以降では使用できない*4

    表にもある通り、最新のOSであればほぼ問題なく2038年問題をクリアできることがわかります。問題はOSの機能を補完する各種ドライバやライブラリ群、また、そのうえで動くアプリケーションでしょう。それぞれ確認は必要となりますが、代表的なものの対応状況は以下の通りです。

    ライブラリ/アプリケーション名対応状況
    GNU C Library (glibc)バージョン2.34でx86アーキテクチャ上での64bit整数型time-tに対応。ただしx86アーキテクチャ上のglibcのtime_t自体は32bitのままで、_TIME_BITSプリプロセッサマクロが64に設定されていて、かつLFSが有効な場合にのみ利用可能などの制限あり*5
    NFSNFSv4(RFC7530)秒単位のデータは符号付64bitであることが定義されている*6(※2.2.1 nfstime4の項を参照)
    XFSLinux 5.10でオプションとしてナノ秒単位を64bitで計算・表示する「big timestamps」を追加し、2486年まで対応できるように修正。ただしデフォルトで追加が反映されるものではなく有効に設定する必要がある*7
    MySQL8.0.28でFROM_UNIXTIME(), UNIX_TIMESTAMP(), CONVERT_TZ() の64bit対応。ただしOS側が64bit対応である必要あり(いずれの関数もOSの日付型データを参照するため)*8
    MariaDB11.5.1でタイムスタンプを2106年02月07日6時28分15秒まで拡張*9
    Visual C++32bitであえて指定されていない限りは64bitがデフォルト値*10

    上記はごく一部の対応状況ですが、仮に対応していても制限事項がつくものが存在する点に注意が必要です。ここまで記載した内容で何となくお気づきの方もいらっしゃるかもしれませんが、2038年問題は発生する可能性がある箇所が2020年問題に対して格段に多いため、時間がかかることが予想されます。

    2000年問題と2038年問題の違い

    • 対象がOS/ライブラリからアプリケーション、機器類まで非常に幅が広い
    • 2000年当時に比べて格段にデジタル化が進んでいる
    • 対策方法が一様ではないものや、現在動いているシステムに対して即時変更をかけられないものがある

    企業が取るべき2038年問題対策:自社システムの診断方法

    自社のプログラムの調査は?

    さて、「PCやサーバなんかを買ってきたものの、自社で作ったものはどうすればいいの?」というケースもあるでしょう。自社で作ったものは…そうです。自分たちで調べるしかないのです。実際に調査をして対応をした事例がまとめられた論文が公開されています。

    組込み機器開発における2038年問題への対応事例

    https://www.ipsj.or.jp/dp/contents/publication/39/S1003-1809.html

    この事例では製品のライフサイクルがもともと20年前後を想定していることから、まずは2038年を最低限クリアすることを要件として調査を開始しています。このケースは組み込み機器になりますが、その単体の機器でもOS部分を含む総行数330万行のコードから符号付32bit整数型のtime_tを明示的に使用する箇所およそ3500か所が発見されています。

    この事例でとられたステップを簡単にまとめます。

    この事例では3500か所に対して5.8人月で実行された修正作業もさることながら、そのレベルの工数で抑制するために事前の洗い出しや対策案の立案、修正作業の手順策定といったところの重要さが感じられます。特に対策案を選定するにあたって要件が明確だったことが対策案の選定を容易にしたことがわかることから、作業開始前(せめて対策案の選定前)に要件を明確にしておくことの重要さを実感させられます。

    さて、2038年問題に該当するコードを検出するためのツールは日本の研究者も含め、いくつかのGitHubレポジトリからリリースされています。最近では立命館大学のサイバーセキュリティ研究室によるY2k38チェッカーがリリースされています。

    Y2k38チェッカーチェッカー作者によるプレゼン資料

    こういったチェッカーは自社開発のプログラム資産のざっとしたチェックに使えるでしょう。また、チェッカー以前の問題として、まずは自社のプログラム資産が2038年問題の影響を受けないか、そろそろ確認を行い、準備を始める期間に入ってきたといえるかもしれません。

    組み込み機器とは?:2038年問題の最大の影響

    実はここまでにあまり触れていない、最大の2038年問題があります。それは、先ほどの論文の事例にもある組み込み機器の問題です。

    組み込み機器といわれてもピンとこない方もいらっしゃるかもしれません。身近な例でいうと家電製品を制御するために組み込まれているコンピューターになります。一番パソコンに近いものであれば最近のハードディスク内蔵か外付け対応のテレビが挙げられます。このほかにも例えば電車に乗るときの自動改札機、切符販売機、水道や電気ガスなどのメーター類や街中で見かけるデジタルサイネージなども組み込み機器です。ほかにも工場のセンサー類やオートメーション用の機器類、配電設備や浄水・配水設備などのインフラ設備、病院の検査機器などにも組み込み機器が用いられています。

    先ほどの事例のようにライフサイクルが決まっていて、そのライフサイクルの間のみ使用するというのが利用者(消費者)側に正しく認識されていれば問題ないのですが、実際のところ、組み込み機器こそライフサイクルを超えて、転売などをされて使い続けられるケースが多く、販売業者も製造業者もすべての出荷品の現状をトレースできないケースがあるといわれています。特に償却期間が5年を超えるような固定資産については入れ替えの検討なども含めて対応する必要が出てくることから、そろそろ取りまとめを始めなければならないでしょう。また、個人向けのIoT機器や家電のように、長期間の利用は想定されていない(売り切りに近い)製品については直前になって買い替えが必要といったアナウンスが出てくる可能性もあるでしょう。

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    まとめ

    2038年問題は日付データが誤ることで社会的に大きな影響を与える可能性があります。本記事公開日(2024年12月)時点ではまだまだ先の問題と思っている方が多いと思いますが、そろそろロードマップを書き始めないと対策に取る時間が足りなくなる可能性があります。これを念頭に置き、早めの対策方法を考えておく必要があるでしょう。


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

    注:
    1)FORTRAN
    ・数学分析用を目的としたプログラミング言語
    ・データ型は整数、実数、複素数、文字、論理の5種類
     COBOL
    ・1950年代終わりに開発されたプログラミング言語
    ・データ型は文字、数字、数字編集の3種類


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

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

    APIとは何か(2)~APIの脅威とリスク~

    Share

    APIセキュリティは、現代のビジネスにおいて不可欠な課題です。シリーズ第2回の今回は、APIを悪用した攻撃手法や、OWASP(Open Web Application Security Project)よりリリースされている「OWASP API Security Top 10」で取り上げられるリスクの詳細を解説します。インジェクション攻撃やDDoS攻撃、APIキーの悪用、アクセス制御に関する脆弱性など、主要な脅威を紹介しながら、APIが悪用された場合の影響について解説します。

    前回記事(シリーズ第1回)「APIとは何か~基本概念とセキュリティの重要性~」はこちら。

    APIとは~前回からの振り返り

    日頃からインターネットなどのネットワークを使用することが多い今日、現代における多くの企業はAPIに大きく依存しており、今やAPIは不可欠なものとなっています。Akamai社のレポート「The API Security Disconnect」によると、調査対象となった企業の約8割以上が2023年に行った調査において、「過去12か月以内にAPIセキュリティをより重視した」と回答しています。しかし、2022年~2024年で調査した回答者のうち、半数以上が、APIのセキュリティインシデントの影響により顧客の信頼を失い、さらにそこからほぼ半数は生産性の低下や従業員の信頼の低下にもつながったといいます。

    また、SNS事業者が提供するAndroid版アプリに存在した脆弱性が悪用された結果、膨大な量のアカウント情報が漏洩した事例*11も報告されています。これは攻撃者が大量の偽アカウントを使用し、様々な場所から大量のリクエストを送信し、個人情報(ユーザ名・電話番号)を照合するというものでした。

    APIが悪用されるとどうなるか

    APIが悪用された場合、多岐にわたる深刻な影響が生じます。特に、認証や認可の不備は深刻なセキュリティホールとなり得ます。攻撃者はこれらの脆弱性を悪用して不正アクセスを行い、機密データや個人情報を盗み出す恐れがあります。また、認可が適切に設定されていないと、本来は外部からアクセスできないはずのデータにまで侵入され、第三者からデータの改ざんや不正操作が可能となってしまいます。さらに、APIを標的にしたDDoS攻撃によりサービスがダウンし、正規ユーザが利用できなくなることで、企業の信用失墜や業務の中断といったダメージを引き起こします。これらの影響は、経済的損失だけでなく、法的問題やブランドイメージの毀損など、長期的な悪影響をもたらすため、APIのセキュリティ強化が不可欠です。

    APIを悪用した攻撃の事例はいくつか報告されていますが、いずれの攻撃も、「OWASP API Security Top 10」で挙げられている問題と関連性があります。

    OWASP API Security Top 10

    APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASPが、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したものです。

    「OWASP API Security Top 10」上位のリスク

    特に上位5つの項目については、以下のような重大なリスクにつながるため、リリース前に十分な対策が施されていることを確認すべきです。

    • 不正アクセス
    • なりすまし
    • 情報漏洩
    • サービス運用妨害(DoS)

    主なセキュリティ脅威

    インジェクション攻撃

    インジェクション攻撃は、悪意のあるコードをAPIに挿入し、不正な操作を行う攻撃です。APIの入力データを検証せずに処理している場合、攻撃者にデータベースへのアクセスを許すリスクが生じます。特にSQLインジェクションやコマンドインジェクション攻撃が多く、攻撃を受けてしまった場合、データベースの情報漏洩やシステムの制御不備などの被害があります。

    認証およびセッション管理の不備の脆弱性を悪用

    APIの認証とセッション管理の不備を悪用することで、攻撃者は不正アクセスやなりすましを行います。パスワード強度が不十分な場合やトークンの管理が適切に行われていない場合、セッションハイジャックや不正に重要な情報を閲覧されることによってデータの漏洩が発生するリスクがあります。適切な認証管理およびセッション管理を行うことが重要です。

    DDoS攻撃

    DDoS攻撃は、複数のPCからアクセスされることによる膨大な量のリクエストをAPIに一斉に送り込むことで、システムのリソースを枯渇させ、サービスの提供を妨害する攻撃です。APIの特性上、処理を高速に行うために外部からのリクエストを許容する必要がありますが、その柔軟性が悪用されます。攻撃者はボットネットを利用し、大量のトラフィックを発生させてサーバのリソースを消費させます。これにより、顧客はサービスが利用できず、自組織においても業務に多大な影響を及ぼします。APIを保護するためには、トラフィックの監視やレート制限、WAF(Webアプリケーションファイアウォール)などのセキュリティ対策が重要です。

    APIキーの悪用

    APIキーは、APIへのアクセスを制御するために利用されますが、攻撃者に奪われると不正利用のリスクが生じます。盗まれたAPIキーは無制限のアクセスやサービスの悪用に使われる恐れがあります。安全な管理や無制限にアクセスができないように適切なアクセス制御を実施すること等が重要です。

    アクセス制御の不備による影響

    APIのアクセス制御の不備の脆弱性を悪用することで、攻撃者は許可されていないデータや機能にアクセスできます。適切な権限設定がされていない場合、データの漏洩や不正な操作の実行のリスクがあります。権限の設定など適切なアクセス制御が求められます。

    思わぬデータの公開や改ざん

    APIの設計や実装の不備により、データが意図せず公開・改ざんされるリスクがあります。適切な認証・認可がないと、攻撃者が内部の機密情報にアクセスすることが可能になります。例えば、本来ならシステム管理者のみがアクセスできる設定画面または顧客情報やシステムに関する情報などの重要情報が格納されている場所に攻撃者がアクセスできてしまった場合、システムの設定を変更されたり重要情報が奪取されたりする恐れがあります。また、過剰に情報を提供するAPIレスポンスや暗号化されていないデータ転送も、情報漏洩や改ざんの危険性を高めます。データ保護には、適切なアクセス制御と暗号化の実装が不可欠です。

    アカウント乗っ取り

    不正アクセスによってユーザアカウントが乗っ取られ、APIを悪用される可能性があります。一度アカウントが乗っ取られると、攻撃者は個人情報の閲覧や不正操作、さらには他のシステムへの攻撃拡大を図る可能性があります。多要素認証(MFA)の導入やAPIキーの適切な管理、ログイン試行の監視など、セキュリティ対策の強化が必要です。

    まとめ

    現代の企業にとってAPIによるアプリケーション連携は不可欠ですが、その悪用によるセキュリティリスクも増加しています。APIを悪用した攻撃の事例は、「OWASP API Security Top 10」に関連しています。主なセキュリティ脅威には、インジェクション攻撃、認証やセッション管理の不備、DDoS攻撃、APIキーの悪用、アクセス制御の脆弱性、不適切なデータ公開や改ざん、アカウント乗っ取りなどがあります。これらは重大なリスクを孕んでいるため不正アクセス、なりすまし、機密データの盗難を含む情報漏洩、データ改ざん、サービスのダウンによるサービス低下や業務への影響、ひいては企業の信用失墜といった深刻な結果を招きます。こうした被害を防ぐため、APIの設計段階から適切なセキュリティ対策を行い、監視やアクセス制御の強化が不可欠です。

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


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

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

    あなたの情報は大丈夫?
    人気コーヒーショップのオンラインストアで約9万件の個人情報流出!事件から学ぶ情報セキュリティの重要性

    Share

    2024年5月、大手コーヒーショップの公式オンラインストアで大規模な個人情報漏洩事件が発生しました。この事件により、約9万2685件の個人情報と5万2958件のクレジットカード情報が漏洩した可能性が明らかになりました。本記事では、事件の内容と顧客への影響、そして企業がとるべきセキュリティ対策についてご紹介します。

    事件の概要

    2024年5月、大手コーヒーショップの公式オンラインストアで大規模な個人情報漏洩事件が発生しました。この事件により、約9万2685件の個人情報と5万2958件のクレジットカード情報が漏洩した可能性が明らかになりました。

    事件の経緯

    • 2024年5月20日:警視庁からの連絡により事態を認識、オンラインストアでのクレジットカード決済を停止
    • 5月23日:オンラインストアを一時閉鎖
    • 5月30日:不正アクセスによるシステム侵害を公表

    この事件は、2020年10月1日から2024年5月23日までの期間に会員登録したユーザーに影響を及ぼしました。特に、2021年7月20日から2024年5月20日までの間にクレジットカード決済を利用した顧客のカード情報が漏洩の対象となっています。重要なのは、この漏洩が公式オンラインストアに限定されており、楽天市場や公式アプリでの購入には影響がないことです。

    漏洩した情報の詳細

    今回の事件で漏洩した可能性のある情報は、以下の通りです。

    個人情報

    • 氏名
    • 住所
    • 電話番号
    • 性別
    • 生年月日
    • メールアドレス
    • ログインID
    • ログインパスワード
    • 配送先情報

    クレジットカード情報

    • クレジットカード番号
    • カード名義人名
    • 有効期限
    • セキュリティコード(CVV/CVC)

    特に注目すべきは、クレジットカードのセキュリティコードが漏洩している点です。セキュリティコードは通常、オンライン決済の際に使用される3桁または4桁の数字で、カード裏面に記載されています。この情報が漏洩すると、不正利用のリスクが大幅に高まります。一般的に、PCI DSS(Payment Card Industry Data Security Standard)という国際的なセキュリティ基準では、セキュリティコードを保存することは禁止されています。そのため、公式オンラインストアがこの情報を保存していた事実自体が、セキュリティ管理の甘さを示しているといえるでしょう。

    影響を受けた顧客数

    この事件で影響を受けた顧客数は以下の通りです。

    個人情報漏洩

    約9万2685人 対象期間:2020年10月1日~2024年5月23日に会員登録した顧客

    クレジットカード情報漏洩

    約5万2958人 対象期間:2021年7月20日~2024年5月20日にクレジットカード決済を利用した顧客

    この数字は、公式オンラインストアの利用者の大部分を占めると考えられます。特に、クレジットカード情報の漏洩は深刻な問題で、不正利用による金銭的被害のリスクが高まっています。

    漏洩の原因と手口

    今回の情報漏洩の主な原因は、公式オンラインストアのシステムに対する不正アクセスです。攻撃者はシステムの脆弱性を突き、特にペイメントアプリケーションを改ざんすることで情報を盗み取りました。使用された手口は「Webスキミング」と呼ばれるもので、以下のような手順で実行されます。

    1. 攻撃者がウェブサイトのコードに不正なスクリプトを埋め込む
    2. ユーザーがフォームに入力した情報(クレジットカード情報など)が攻撃者のサーバーに送信される
    3. 正規の決済処理と並行して、情報が盗まれる

    この手法の危険性は、ユーザー側では異常を検知しにくい点にあります。正規のウェブサイトを利用しているように見えるため、被害に気付くのが遅れる可能性が高くなります。

    Webスキミング攻撃は近年増加傾向にあり、2018年から2019年にかけて大手通販サイトBritish Airwaysが同様の攻撃を受け、約38万人の顧客情報が漏洩する事件が発生しています。このような攻撃を防ぐためには、以下のようなセキュリティ対策を実施することが必要になります。

    • 定期的なセキュリティ監査の実施
    • ウェブアプリケーションファイアウォール(WAF)の導入
    • コンテンツセキュリティポリシー(CSP)の適切な設定
    • 従業員に対するセキュリティ教育の徹底

    今回の事件のケースでは、これらの対策が十分でなかった可能性が高いといえるでしょう。

    対応と今後の対策

    事態の発覚後、企業は迅速な対応をとりました。

    • オンラインストアの一時閉鎖
    • クレジットカード決済の停止
    • 影響を受けた顧客への個別連絡
    • クレジットカード会社との連携による不正利用の監視
    • 第三者調査機関によるフォレンジック調査の実施

    また今後の対策として、以下の取り組みを行う方針を示しています。

    • システムの脆弱性の完全修正
    • 定期的なセキュリティ監査の実施
    • リアルタイム監視システムの導入
    • 従業員に対するセキュリティ教育の強化
    • 外部専門家によるセキュリティ診断の定期実施

    特に重要なのは、PCI DSSへの準拠です。これにより、クレジットカード情報の取り扱いに関する国際的な基準を満たすことができます。また、今回の事件について、企業は顧客とのコミュニケーションを重視し、説明動画の公開や定期的な情報更新を行っています。この透明性の高い対応は、信頼回復に向けた重要なステップといえるでしょう。

    関連記事

    SQAT.jpではPCI DSS準拠について、以下の記事で紹介しています。ぜひあわせて
    PCI DSSとは ―12の要件一覧とPCI DSS準拠―

    顧客がとるべき対策

    公式オンラインストアを利用した顧客は、以下の対策をとることが推奨されます。

    • クレジットカードの利用明細を定期的に確認し、不審な取引がないか注意する
    • 不審な取引を発見した場合は、直ちにクレジットカード会社に連絡する
    • 公式オンラインストアで使用したパスワードを他のサービスでも使用している場合は、速やかに変更する
    • 不審なメールや電話に注意し、個人情報の追加提供を求められても応じない
    • クレジットカード会社が提供する不正利用補償サービスの内容を確認し、必要に応じて利用する

    また今後、オンラインショッピングを利用する上では以下の点に注意することが重要です。

    • 信頼できるサイトでのみ買い物をする
    • クレジットカード情報を入力する際は、URLが「https」で始まっていることを確認する(=暗号化通信の導入)
    • 公共のWi-Fiでのオンラインショッピングは避ける
    • 異なるサービスごとに別々のパスワードを使用する
    • 二段階認証が利用可能な場合は積極的に活用する

    情報セキュリティの重要性

    今回の事例は、企業における情報セキュリティの重要性を改めて浮き彫りにしました。今後企業は以下のような点を考慮し、常にセキュリティ対策を見直し、強化していく必要があるでしょう。

    継続的なセキュリティ対策の実施

    一度だけの対策では不十分で、常に最新の脅威に対応できる体制が必要です。

    従業員教育の徹底

    技術的対策だけでなく、人的要因によるセキュリティリスクも軽減する必要があります。

    インシデント対応計画の策定

    事件発生時に迅速かつ適切に対応できるよう、事前に計画を立てておくことが重要です。
    外部専門家の活用自社だけでなく、専門知識を持つ外部の目を通してセキュリティを評価することが有効です。

    法令遵守の徹底

    個人情報保護法やPCI DSSなど、関連する法令や基準を厳守する必要があります。

    まとめ

    今回の大手コーヒーショップの公式オンラインストアにおける個人情報漏洩事件は、現代のデジタル社会が直面するセキュリティリスクを如実に示しています。約9万人以上の顧客情報が漏洩し、そのうち5万人以上のクレジットカード情報も危険にさらされました。事件の主な原因は、Webスキミングと呼ばれる攻撃手法によるものでした。企業はシステムの脆弱性を突かれ、ペイメントアプリケーションが改ざんされる結果となりました。事態発覚後、企業は迅速な対応を取り、オンラインストアの一時閉鎖やクレジットカード決済の停止、影響を受けた顧客への個別連絡などを行いました。今後は、システムの脆弱性修正や定期的なセキュリティ監査など、再発防止に向けた取り組みを強化する方針です。顧客側も、クレジットカードの利用明細の確認や不審な取引への警戒など、自己防衛策を講じる必要があります。また、オンラインショッピング全般において、セキュリティ意識を高めることが重要です。この事件は、企業における情報セキュリティの重要性を改めて認識させるものとなりました。継続的なセキュリティ対策の実施、従業員教育の徹底、インシデント対応計画の策定など、包括的なアプローチが求められています。デジタル化が進む現代社会において、個人情報の保護は企業の重要な責務です。今回の事例を教訓に、企業はセキュリティ対策を強化し、顧客の信頼を守り続けることが求められています。同時に、利用者側もセキュリティ意識を高め、自己防衛策を講じることが大切です。官民一体となったサイバーセキュリティの向上が、安全なデジタル社会の実現につながります。


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

    BBSecでは

    サイバーインシデント緊急対応

    突然の大規模攻撃や情報漏えいの懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    SQAT® 脆弱性診断サービス

    サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。


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

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

    【続】プログラミング言語の脆弱性対策を考える:2024

    Share

    本記事は2020年9月公開の記事「プログラミング言語の脆弱性対策を考える」の続編となります。前回の記事をまだご覧になっていない方はぜひ、この機会にご一読ください。

    いま「C言語の脆弱性対策について簡単に教えて」と生成AIに尋ねてみると、弊社SQAT.jpの記事が引用記事として出てきます。前回の記事を公開してからそろそろ5年ぐらいの月日がたつということで、今回は2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介します。

    2020年から2024年で変わったこと

    生成AIの汎用化

    2024年の夏、最初の会社の同期20人で5年ぶりに集まりました。その中でコードを業務で書いているメンバーが同じテーブルに集まったとき、最初に出た話題は「生成AIって何使っている?」でした。所属する会社も違い、使っている言語はバラバラ、コードを書く目的や環境、書く頻度もまちまち、利用する生成AIもバラバラなのですが、全員が生成AIを使っていることに少々驚きました。この友人が全員口をそろえて生成AIについて評価していた点は、コードを作るときに最初にかかる時間と手間が圧倒的に削減されるという点です。

    これまでは「こういうことを処理するコードを作ろう」と思うと、わかるところは先に大まかに書いたうえで、わからないところや怪しい部分はプログラミング言語のリファレンスをひっくり返し、Webで検索し、情報を集めたうえでコードスニペットを起こし、実際のコードとして動かし…という順で作業していました。一方、生成AIを使う場合はこういったことをやろうと思った時点で足りない部分を生成AIに質問すればスニペットが返ってくる(場合によってはコードブロックが返ってくる)ので、コードづくりの前半部分の悪戦苦闘がかなり軽減されます。

    ところが、短所もいくつかあります。まず生成AIサービスが免責事項として常に掲げるように、必ずしも正しい答えが返ってくるわけではない点には理解が必要とされるところです。
    引用元をよくみると、古いバージョンの言語に基づいたQ&Aサイトの回答を参照していることもよくありますし、プロンプトに対して素直に答えるという性質上、 プロンプトに入れていない前段処理に対して不整合が発生する内容のスニペットが回答される、といったことはわりと日常茶飯事です。

    学習データやプロンプトの入れ方次第では返答されるコードスニペット自体にエラーや脆弱性が含まれる場合もあります。プロンプトに関係のない前後の処理との不整合でエラーが発生したり、他のコードブロックとの兼ね合いでエラーが発生したり、そのエラーが結局脆弱性につながるものだったりという可能性は十分にあります。

    また、一般的な商用サービスの生成AIでは入力が学習データに使用されます。つまり自身が入力したデータが流用されるという前提でサービスを利用することになります。このため、自社の知的所有権への配慮や、個人情報や機微情報、場合によっては非公開情報全般への配慮が必要となる点にも注意が必要です。エンタープライズサービスとしてこういったことを回避するサービスもありますが、それ相応の費用が必要となります。

    ただ、自前で大規模言語モデル(LLM:Large language Models)をつくるよりも人件費や設備費用などが圧倒的に安価で手軽であるという点では規模の経済性を実感するところはあります。そういった観点から、将来、どの企業でも自社でAIを全く使わないという選択肢はあまりないかと思います。プログラミングに限らずですが、AIとほどよく付き合って効率的に仕事を進めつつ、エラーや脆弱性をきちんと見逃さない仕組みをもって問題を回避していく、
    そういう仕事法になっていくかもしれません。

    ノーコードとローコード

    以前からどちらも存在はしますが、2020年代に入ってからノーコードやローコードといった選択肢が増えてきています。

    ノーコード
    プログラミングの知識がなくてもアプリケーションを開発できる手法です。専門的なコードを書くことなく、ドラッグ&ドロップなどのビジュアル操作で簡単にアプリケーション開発ができます。ITの専門スキルがない人でもアイディアをデジタル化できる点が特徴です。小規模なプロジェクトの開発に適しています。
    ローコード
    最小限のプログラミングでアプリケーションを開発する手法です。基本はビジュアル操作ですが、必要に応じて一部コードを書きます。柔軟性とスピードのバランスが特徴です。

    最近だとAWSがローコード構築サービスをリリースした*2のが一例となるでしょう。ノーコードやローコードを使用するメリットとしては、各業務の定義やフロー、プロセスが明確であれば定型業務やバックヤード業務の一部を合理化できることです。効率化することで時間短縮ができ、別のより生産性の高い仕事に人を割り振れるといった副次的な効果も期待できます。ただ、業務の内容が不明確な場合や、業務が日々恣意しい的な運用をされている場合には大きなメリットを得ることは難しいかもしれません。

    ここで脆弱性の話です。実際ノーコードといっても実は補助的にパラメータの入力が必要な場合があります。また、外部とのAPI連携をノーコードの画面から実行するといった構成のノーコード機能を持っているSaaS(Software as a Service)もあります。そして誤ったパラメータの入力で入出力の脆弱性を発生させる可能性がある、APIとのやりとりの詳細はユーザでは見えない(SaaSのサポート担当者は見えるケースが多いようです)ため、誤った接続先に接続していた場合や連携しているAPIになんらかの脆弱性があった場合に切り分けが煩雑になるといったところは懸念材料として頭の片隅に置いたほうが良いでしょう。

    ノーコードもローコードも非常に便利です。そのノーコードフロー自体の仕組みやパラメータの動きや連携先のAPIの信頼性などを理解したうえで使えば、劇的に効率化が図れるため、API同様にうまく付き合っていくということが重要になるのではないでしょうか。

    プログラミング言語

    専門家たちがどのプログラミング言語を使っているかというデータが、毎年Stack Overflowから発表されます。2020年と2024年でどの程度変わったか、比較をしてみましょう。

    言語2024年2020年
    JavaScript64.60%69.70%
    HTML/CSS54.10%62.40%
    Python53%41.60%
    SQL47%56.90%
    TypeScript43.40%28.30%
    Bash/Shell34.20%34.80%
    Java30.00%38.40%
    C#28.80%32.30%
    C++20%20.50%
    C18.70%18.20%
    PHP16.90%25.80%
    PowerShell14.40%注 1)
    Go14.00%9.40%
    Rust11.70%4.80%
    Kotlin9.90%8.00%
    Dart6.00%3.70%
    Ruby5.80%7.50%
    Lua5.30%ランク外
    Swift4.90%6.10%
    Visual Basic4.10%ランク外

    出典:Stack Overflow Developer Survey2020年版/2024年版より弊社作成
    2020年版:https://survey.stackoverflow.co/2020#technology-programming-scripting-and-markup-languages-professional-developers
    2024年版:https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language-prof

    ここからは2020年と2024年の脆弱性診断結果の比較で目についた点を深堀りしてみたいと思います。

    プログラミング言語と適材適所

    前述した「専門家たちはどのプログラミング言語を使っているか」というデータの表からもわかるとおり、このWeb大全盛の時代に「PHPを使う」と回答したエンジニアの比率は下がっています。また、BBSecのシステム脆弱性診断結果からもPHPの脆弱性報告件数が減っていることがわかります。米国の脆弱性情報データベースNVDによるとPHPの脆弱性自体の数が減っている*2(2019年が34件に対して2023年は6件)ということも関連があるかと思いますが、診断結果のエビデンスで見かける機会も減っています。

    脆弱性の存在するバージョンの使用の検出内訳

    (上図:2020年上半期、下図:2024年上半期)

    2020年上半期
    2024年上半期

    当社が発行するセキュリティレポートでは、半期(6か月)毎にBBsec脆弱性診断の結果を集計・分析。その傾向を探るとともに、セキュリティに関する国内外の動向を分かりやすくお伝えしています。
    最新号のダウンロードはこちら

    GitHubでのプルリクエスト(機能追加や改修など、作業内容をレビュー・マージ担当者やその他関係者に通知する機能)の数も2013年をピークにここ数年は5%台半ばでの微増微減を繰り返している状態になっています*3。けれど、現在稼働しているWebサイトのうち75.8%がPHPを使用している*4といわれていることも事実です。また、CMSの代名詞ともいえるWordPressはPHPで開発されているのですが、WordPress 注 2)が全Webサイトの実に43.4%で使用されています*5。つまり、WebサイトのうちPHPを使っているサイトは76%ぐらいあるけれど、半分以上はWordPressとその派生のパッケージが市場シェアを支えているという構造になっています。そのため、実際に動いているサイトのほとんどがPHPであることは間違いないですが、その大半はWordPressで、それ以外のサイトは少数派というのが現状です。

    PHPの強みはWeb開発に特化した、可読性が高く学習しやすい言語である点です。小中規模でセキュリティ要件があまり高くないWebサービスやCMSであればPHPで開発するのが一番便利であり、保守性も高いでしょう。一方で、大量のデータの処理・分析が必要なケース、セキュリティへの配慮からバックエンドとフロントエンドを切り離して開発・運用する必要があるケース、パフォーマンスが重視されるケース、マルチデバイス対応が必要なケースなど、PHPでは要件を満たさないケースが出てきていることも事実です。

    PHPの市場をけん引しているCMSでも、「ヘッドレスCMS」と呼ばれるタイプなど、これまでとは異なるCMSへの需要が伸びているといわれています。今後は、旧来のCMSや中小規模のWebサイトはそのままPHP、マルチデバイスやパフォーマンス、バックエンドへの特殊な処理要件やセキュリティ要件などがある場合は別の言語といった形で、さらにすみわけが進んでいくのかもしれません。そういった意味でも “WebならPHP” という時代から、”適材適所でWeb開発も言語を選ぶ” 時代になってきたといえるでしょう。

    2024年のC言語

    C言語系統で開発というと「2024年でもまだ?」という声が上がりそうなところですが、実際C言語系統はOSまわりでいまだに健在です 注 3)。また古いプログラム(コード、ドライバなど)で互換性が保証される場合はそのまま利用されているケースもあるといわれています。つまりは、C言語系統の言語が抱える根本的な問題、メモリハンドリング(メモリの使い方の変化に伴うメモリエラーを適切に処理する能力)関連の問題もいまだにそこかしこで健在しています。この問題が特に注目を集めたのが、昨今のCrowdStrike Falconのエラーを含んだパターンファイルの配布によるBSOD(Blue Screen of Death)の大量発生です。

    関連情報

    弊社では、10月16日(水)に開催予定のウェビナーのオープニングセッションとして、「10分でわかるCrowdStrike障害」を取り扱います。ご関心がおありでしたらぜひお申込みください。詳細はこちら


    この問題で再び脚光を(よくない形で)浴びたのがC系統言語の問題です。NULLポインタ参照は、現代の脆弱性の考え方からいうと非常に危険な脆弱性を発生させる原因の一つになります。これらすべての原因は以前にもご紹介した通り、メモリハンドリングを行う言語であるがゆえに発生することです。メモリまわりの脆弱性(元をたどればバグ)の発生頻度を、プログラミング言語自体を変えることで抑えたいと思っている人は多数いて、その結果、よりメモリハンドリング関連の問題が少ないRustへの移行を行うという動きが出てきています。最初期の例としてはMozilla ServoのレンダリングエンジンがC++からRustに書き換えられたもの*6が挙げられるでしょう。Microsoftも、OSの一部をRustに書き換えることについて2022年~2023年に言及しています。

    最近ではGoogle AndroidがドライバのRustへの置き換えが順調である旨をブログで発表*7しています。また、DARPA(アメリカ国防高等研究計画局)ではC/C++をRustに置き換えるためのプログラム「TRACTOR」で大規模言語モデルを利用した置き換えを行うことを発表*8しています。TRACTORほど大規模ではなくても、CからRustへの移行ツールがGitHubコミュニティで活発に開発されています。もちろんRustへ移行すれば即座に完全にメモリハンドリングの問題から100%解放されるわけではありません。また、C言語系統のプログラムの置き換え先がRustしかないわけでもありません。ですが、現在進行しているRustへの置き換えはC言語しかなかった時代の最後にして最大の遺産であり、OS周りのC言語依存からの脱却への一歩となることでしょう。


    注:
    1) 2020年版はBash/Shell/PowerShellが1つにまとめられているため、PowerShell個別のデータはなし。
    2) WordPressはWordPress本体よりもそのプラグインの脆弱性が多く報告されています。また、WordPress専用の脆弱性・マルウェアスキャナはたくさんありますが、2024年9月にはWordPressのコミュニティへの投稿でスキャナ検出ができないマルウェアがあるといった旨の投稿があるなど、その市場シェアを狙った動きも伺えます。こうした動きについては最新の情報を追うなどし、対策の実施を検討されることをおすすめします。
     参考:https://wordpress.org/support/topic/new-malware-found-in-wordpress-installations-hidden-admin-users-redirects-and/#post-18010647
    3) Windows OSに限らず、多くのOSはC言語系統の言語をOSの開発に使用しています。Windowsの場合はCとC++が使用されています。ここにCrowdStrike FalconはC言語系統で書かれたセンサーとパターンファイルを使用してマルウェアや侵害行為の検出をしています。セキュリティ製品あるあるで、センサー自身がシステムブート時に読み込み必須なドライバとなっています。BSOD大量発生の件は、CrowdStrikeのQAプロセスが不十分だったことが大きな原因ではありますが、パターンファイルに不整合がありメモリの境界外読み取りエラーを発生させました。センサーはシステムブート時に読み込み必須なドライバとなっているため、Windows OS起動時にCrowdStrike Falconのセンサーを起動する必要がありましたが、問題のパターンファイルが境界外読み取りエラーを発生させたため、問題のパターンファイルがインストールされたすべてのWindowsマシンがブートできず、ブルースクリーンを表示するだけの箱/板になってしまう状況に陥りました。これが2024年7月にニュースになったインシデントの概要です。
     参考:https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf


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

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

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

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

    脆弱性診断は受けたけれど~脆弱性管理入門

    Share

    ~とある会社Aと脆弱性診断の結果を受け取った関係者とのやり取り~

    脆弱性診断を受けたA社では入社3年目のセキュリティ担当・Bさんが結果に頭を抱えています。なぜなら、社内ネットワークに使っているスイッチにCVSSスコア9.8の脆弱性、リモートアクセスに使用しているVPNゲートウェイにCVSSスコア8.8、オンラインショップ用の受発注管理に利用しているデータベースにCVSSスコア7.5の脆弱性が見つかってしまったからです。リスクはどれも「高」レベルとして報告されたため、Bさんは上司に相談し、すべてに修正パッチを当てるようスイッチとVPNゲートウェイについてはインフラチームの担当者に、データベースについては開発部に連絡することにしました。

    インフラチームのCさんとSlackでやり取りをしていたBさんはCさんからこんなことを伝えられます。

    インフラチームCさん「修正パッチを適用するとなると、インフラチームは基本みんなリモートだから、誰かを土日のどこかで休日出勤させるか、急ぎだったら平日の夜間に勤務させて、パッチを当てることになるけど、どれぐらい急ぎなの?」

    「あと、VPNとスイッチ、どっちを先に作業したほうがいいの?パッチの情報を調べてみたら、VPNのほうは一度途中のバージョンまで上げてから最新バージョンまで上げないといけないみたいで、作業時間がすごくかかりそうだから、別日で作業しないとだめかもしれないんだよね」

    Bさんは答えに詰まってしまいました。リスクレベルは高だといわれているけれども、どれぐらい急ぐのかは誰も教えてくれないからです。

    答えに詰まって「確認してから折り返し連絡します」と返したところ、「セキュリティ担当はいいなあ。土日とか夜間に作業しなくていいし、すぐに答えなくてもいいんだから」と嫌味までいわれてしまいました。

    Bさんは脆弱性診断の結果が返ってきてから1週間後、開発部門のD部長にセキュリティ担当と開発部門の定例会議の際に報告事項としてパッチ適用の件を報告しました。するとD部長はこういいました。

    開発部D部長「この件、1週間ほど報告に時間を要したようですが、脆弱性診断の結果以外に何か追加の情報はありますか?あと、この脆弱性診断の結果によるとリスクレベル高とありますが、社内の規定としてどの程度急ぐかといった判断はされましたか?」

    開発部のほかの人にもこんなことをいわれてしまいます。

    開発部担当者「パッチを適用する場合、ステージング環境で影響を調査したうえで必要であればコードや設定の修正などを行う必要がありますが、その時間や工数は考慮されていないですよね。通常の開発業務とどちらを優先すべきかといった判断はどうなっているんですか?」

    Bさんはまたもや言葉に詰まってしまいます。セキュリティ担当は自分と上司の2人だけ、上司は別の業務との兼務でパッチの適用の優先順位付けまで考えている時間はありません。自分もEDRやファイアウォールの運用をしながら脆弱性診断の依頼や結果を受け取るだけで、とても他の部門の業務内容や環境のことまで把握しきる余裕がないのです。


    ここまで、架空の会社A社と脆弱性診断の結果を受け取った関係者の反応を物語形式でお送りいたしました。現在、弊社の脆弱性診断サービスでは脆弱性単体のリスクの度合いの結果をご提供させていただくことはあっても、その脆弱性をどういった優先度で修正しなければならないかといった情報はご提供しておりません。なぜならば、パッチを適用するにあたって優先順位をつけるためにはお客様しか知りえない、以下の要素が必要になるためです。

    パッチ適用の優先順位をつけるための3つの要素

    1. 脆弱性を持つアセットが置かれている環境
      ・インターネット上で公開された状態か、IPSやFWなどで制御されたネットワーク内か、もしくはローカル環境依存といった非常に限定的な環境かといった分類
      ・CVSSでいう環境スコア(CVSS-E)の攻撃区分(MAV)にあたる、実際の環境依存の要素
    2. アセットが攻撃を受けた場合に事業継続性に与える影響
    3. アセットが攻撃を受けた場合に社会や社内(運用保守・人材)に与える影響

    冒頭のA社のケースでは以下のように整理できるでしょう。

    アセットが置かれている環境

    • VPN:インターネット上で公開された状態
    • データベース:設定を間違っていなければIPSやFWなどで制御されたネットワーク配下だが、公開ネットワーク寄り
    • スイッチ:設置環境によって制御されたネットワーク内かローカル環境になる。

    アセットが公開されている場合、攻撃者からよりアクセスしやすいことからより緊急度が高いといえるので、VPN=データベース>スイッチの順になると考えられるでしょう。

    アセットが攻撃を受けた場合に事業継続性に与える影響

    アセットが攻撃を受けた場合に自社の事業継続にどの程度影響が出るかといった要素です。
    仮にランサムウェア攻撃によって影響を受けた場合、それぞれのアセットの停止でどの程度の影響が出るかを想定してください。A社の場合事業継続性への影響度順でいうと、データベース>VPN>スイッチの順になると考えられます。

    今回の場合はデータベースが事業に直結しており、顧客情報を含むデータを持っているため、継続性への影響度が高いという想定です。アセットの利用目的や環境によってはこの順番が入れ替わることもあります。

    アセットが攻撃を受けた場合に社会や社内に対して与える影響

    A社がランサムウェア攻撃を受けた場合はオンラインショッピングサイトのデータベース関連で以下の影響が見込まれます。

    • 顧客情報の漏洩
    • 運用およびシステムの復旧にかかる費用と工数

    このほかにVPNやスイッチもフォレンジック調査の対象となって業務が行えなくなる可能性が高いと考えられます。VPNに関しては利用できない期間、社員の出社が必須になるなどワークスタイルへの影響も出る可能性もあります。こういったことから、社会および社内に対して与える影響でA社の例を考えると影響度は、データベース>VPN=スイッチと考えられるでしょう。

    SSVCとは

    こうした情報があったうえで利用ができようになる優先順位付けの方法があります。それが「SSVC(Stakeholder-Specific Vulnerability Categorization)」です。SSVCは脆弱性管理プロセスに関与する利害関係者のニーズに基づいて脆弱性に優先順位を付けるための方法論とされており、経営・マネジメント層、システム開発者、システム運用者といったステークホルダーと一緒に脆弱性に対処していくための方法論といえます。SSVCは脆弱性そのものの技術的評価ではなく、脆弱性にどのように対処するかという観点での評価を行うフレームワークになります。

    SSVCの3つのモデル

    1. ソフトウェアやハードウェアの供給者、すなわちパッチを開発する人が用いる「Supplier Decision Model
    2. ソフトウェアやハードウェアを利用する側、つまりパッチを適用する人が用いる「Deployer Decision Model
    3. CSIRTやPSIRT、セキュリティ研究者やBug Bounty Programなど、脆弱性に対して何らかの調整やコミュニケーションのハブとなりうる人、コーディネーターが用いる「Coordinator Decision Model

    このうち、「Deployer Decision Model」と「Supplier Decision Model」ではプライオリティ(対応優先度)付けの結果を4つにわけています。

    SSVCで得られるプライオリティ付けの結果

    Deployer ModelSupplier Model
    Immediateすべてのリソースを投入し、通常業務を止めてでもパッチの適用を直ちに行うべきである全社的にすべてのリソースを投入して修正パッチを開発し、リリース
    Out-of-cycle定期的なメンテナンスウィンドウより前に、やむを得ない場合は残業を伴う形で緩和策または解消策を適用緩和策または解消策を他のプロジェクトからリソースを借りてでも開発し、完成次第セキュリティパッチとして修正パッチをリリース
    Scheduled定期的なメンテナンスウィンドウで適用通常のリソース内で定期的な修正パッチのリリースタイミングでパッチをリリース
    Defer現時点で特に行うことはない現時点で特に行うことはない

    ここではDeployer Decision ModelをもとにA社がどのようにパッチを適用すべきか検討してみましょう。

    まず、Bさんは上司に相談したうえで、前述した3つの要素、「脆弱性を持つアセットが置かれている環境」、「事業継続性への影響」、「社会や社内への影響度」を定義していく必要があります。また、この定義に当たっては実際の環境や利用用途、部門内のリソースなどをよく知っているインフラチームや開発部といった当事者、つまりステークホルダーの関与(少なくとも承認)が必要となってきます。このほかに優先順位付けの結果、”Immediate”や”Out-of-Cycle”が出た場合の対応プロセスも用意しておく必要があります。Bさん1人で何かできることはそれほど多くはなく、社内のステークホルダーへの聞き取りや経営層への説明、必要なプロセスの準備と合意形成など、上司や部門全体も含めて組織的に取り組まなければならないといえます。さらに、Bさんは脆弱性自体が持つ以下の要素を調べる必要があります。

    脆弱性が持つ要素

    自動化の可能性

    攻撃者がツール化して脆弱性を悪用するかどうかを判定するものとなります。これは攻撃者がツール化した場合、攻撃者間でツールの売買が行われるなど汎用的に悪用される可能性があるため、把握が必要な要素となります。一部の脆弱性はCISA VulnrichmentやCVSS4.0のSupplement MetricsのAutomatableの値が参照できますが、情報の参照先がないものについてはPoCの有無やPoCの内容から自動化の可否を判断する必要があります。この点はSSVC利用の難点として挙げられることもあります。

    悪用の状況

    実際に攻撃されていることを示すActive、PoCのみを示すPoC、悪用されていないことを表すNoneの3つに分類されます。この情報は時間の経過とともに変化する可能性が最も高く、逐次状況を確認する必要があります。情報の参照先は、KEVカタログ、CISA VulnrichmentのExploitationの値、CVSS4.0のThreat MetricsやNVDのReferenceのPoCの有無といったものが利用できます。唯一難点があるとすれば、日本国内でシェアの高い国内メーカー機器の情報がKEVカタログやCISA Vulnrichmentなどにあまり反映されない点にあります。

    まとめ ~CVSSとSSVCの活用~

    これまではCVSSが高い値のものだけ対処していた、という組織も多いでしょう。CVSSは脆弱性の単体評価ができ、脆弱性が広く悪用された場合の深刻度を測るための評価システムです。ただし、その脆弱性が存在するアセットがどのように利用されているか、そのアセットが業務継続性や運用保守、ひいては社会全体に対してどのような影響を与えるかといった観点が欠けていることが長らく問題視されてきたのも事実です。

    脆弱性管理は手間がかかる、登場人物が多い、意見がまとまらないといったこともあるでしょうし、「自動化の可能性とかわからないし、攻撃の状況をずっと見ているほどの時間の余裕はない!」といった様々なお声があるかと思います。しかし、今この瞬間どの企業がいつサイバー攻撃を受けるのか全く見当もつかない状況の中、少しでもリスクを回避したい、どこにリスクがあるのか手がかりをはっきりしておきたいという企業の皆さまもいらっしゃるかもしれません。本記事を通じて、こういった脆弱性管理手法があることを知っていただき、活用することでリスク回避ができるようになるための役立つ情報提供となれば幸いです。

    参考情報:

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

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2024年9月18日(水)13:00~14:00
    【好評アンコール配信】
    ランサムウェアの脅威を知る-脅威に備えるためのランサムウェア対策-
  • 2024年9月25日(水)13:00~14:00
    【好評アンコール配信】
    ランサムウェア対策の要~ペネトレーションテストの効果、脆弱性診断との違いを解説~
  • 2024年10月2日(水)13:00~14:00
    【好評アンコール配信】
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!
     - ツール診断と手動診断の比較 –
  • 2024年10月9日(水)13:00~14:00
    【好評アンコール配信】
    システム開発のセキュリティ強化の鍵とは?
     -ソースコード診断で手戻りリスクとサイバー攻撃を未然に防ぐ-
  • 最新情報はこちら

    Youtubeチャンネルのご案内

    SQATチャンネル(@sqatchannel9896)では毎月、アナリストが語る「セキュリティトピック」解説動画やウェビナー動画を更新しています。 ぜひチャンネル登録をして、チェックしてみてください。


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

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

    長期休暇明けのサイバーセキュリティ対策
    企業が実施するべき7つの重要ステップ

    Share

    長期休暇明けは、企業にとってサイバーセキュリティリスクが高まる時期です。休暇中に発生した脆弱性や新たな脅威に対応するため、適切な対策を講じることが重要です。本記事では、企業が実施するべきセキュリティ対策について、7つご紹介します。

    修正プログラムの適用

    休暇中に公開されたOSやソフトウェアの修正プログラムを確認し、適用することが最初のステップです。システム管理者の指示に従って修正プログラムを適用することで、既知の脆弱性を修正し、セキュリティを強化できます。

    定義ファイルの更新

    セキュリティソフトの定義ファイルを最新の状態に更新することも重要です。電子メールの送受信やウェブサイトの閲覧を行う前に定義ファイルを更新することで、最新のウイルスやマルウェアに対する防御力を強化できます。

    サーバ等のログ確認

    サーバ等の機器に対する不審なアクセスが発生していないか、各種ログを確認します。不審なログが記録されていた場合は、早急に詳細な調査等の対応を行うことが必要です。ログ確認により、潜在的なセキュリティインシデントを早期に発見し、対処することができます。

    不審なメールへの警戒

    長期休暇明けはメールがたまっているため、不審なメールの添付ファイルやURLには特に注意が必要です。不審なメールを受信した場合は、添付ファイルを開かず、本文中のURLにもアクセスしないようにしましょう。また、システム管理者に報告し、指示に従うことが重要です。

    持ち出し機器のウイルスチェック

    長期休暇中に持ち出していたパソコンや外部記憶媒体のウイルススキャンを行うことも忘れずに。このステップにより、持ち出した機器がウイルスに感染していないかを確認し、組織内でのウイルス拡散を防止します。

    緊急連絡体制の確認

    不測の事態に備えて、緊急連絡体制や対応手順を確認しておくことも重要です。連絡フローが現在の組織体制に沿っているか、各担当者の連絡先に変更がないかなどを確認しておきましょう。

    データのバックアップ

    最後に、重要データのバックアップを行い、ランサムウェア攻撃に備えることが大切です。バックアップデータは安全な場所に保管し、定期的に更新することで、データの消失や改ざんに対するリスクを軽減できます。

    まとめ

    これらの対策を適切に実施することで、長期休暇明けのサイバーセキュリティリスクを大幅に軽減します。企業は常に最新のセキュリティ脅威に対する警戒を怠らず、従業員の意識向上と技術的対策の両面からセキュリティ体制を強化していくことが重要です。サイバー攻撃の手法は日々進化しており、一度の対策で安心することはできません。定期的なセキュリティ評価と対策の見直しを行い、常に最新の脅威に対応できる体制を整えていくことが、企業の重要な責務となっています。

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


    ランサムウェア感染リスク可視化サービス デモ動画

    またサービスのデモンストレーション動画を公開中です。こちらも併せてご覧ください。

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン

    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2024年8月21日(水)14:00~15:00
    ランサムウェア対策の要~ペネトレーションテストの効果、脆弱性診断との違いを解説~
  • 2024年8月28日(水)12:50~14:00
    【好評アンコール配信】「知っておきたいIPA『情報セキュリティ10大脅威 2024』~セキュリティ診断による予防的コントロール~
  • 2024年9月4日(水)14:00~15:00
    インシデント発生の事前準備・事後対応 -拡大するサイバー攻撃への対策方法とは-
  • 2024年9月11日(水)14:00~14:30
    CVSSとSSVCで実践する次世代脆弱性管理:サイバー攻撃対策セミナー2024
  • 最新情報はこちら


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

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


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    お盆休み明けに急げ!
    WindowsとMicrosoft Projectの脆弱性
    ‐CVE-2024-38063/38189修正で安全な業務再開を‐

    Share

    2024年8月、Microsoftはセキュリティ更新プログラムをリリースしました。この更新プログラムは、【CVE-2024-38063】および【CVE-2024-38189】という二つの深刻な脆弱性に対応するものであり、当該脆弱性はWindowsおよびMicrosoft Project全ユーザーに重大なリスクをもたらします。

    【CVE-2024-38063】

    CVE-2024-38063は、WindowsのTCP/IPスタックに存在する脆弱性です。この脆弱性を悪用すると、リモートの攻撃者は特定の条件下で任意のコードを実行することが可能です。これにより、攻撃者はターゲットの制御を完全に奪取し、システム全体を不正な操作に利用する可能性があります。Windows 10、Windows 11、およびWindows Server 2016、2019、2022といった幅広いバージョンが影響を受けるため、現行のWindowsを利用している多くのユーザーが影響を受ける可能性がある非常に危険な脆弱性です。

    【CVE-2024-38189】

    CVE-2024-38189は、Microsoft Projectに関連する脆弱性です。こちらもリモートの攻撃者が特定の条件下で任意のコードを実行できるというものです。この脆弱性を悪用されると、プロジェクト管理ソフトウェアのデータが危険にさらされる可能性があり、企業や組織にとっては機密情報の漏洩やプロジェクトの進行に深刻な影響を与えるリスクがあります。

    【対策】

    影響を受けるシステムを保護するために、早急に2024年8月のセキュリティ更新プログラムを適用することが強く推奨されます。

    Microsoftは、このセキュリティ更新プログラムを適用することで当該脆弱性を修正し、システムの安全性を向上させるとともに、攻撃のリスクを大幅に軽減することができる、としています。現在、日本では夏季休暇を取得している方も多いと思われますが、休み明けの更新適用を忘れずに行うことを心がけてください。また、夏季休暇明けの従業員への更新適用の声がけを徹底してください。

    詳細な脆弱性及び対策についてはMicrosoftの公式セキュリティガイドラインをご参照ください。

    【重要ポイントまとめ】

    更新の概要

    • 2つの重大な脆弱性に対応
    • 影響:WindowsとMicrosoft Projectのユーザー

    脆弱性の詳細

    CVE-2024-38063(Windows関連)

    • 影響:Windows 10, 11, Server 2016, 2019, 2022
    • リスク:攻撃者がシステムを完全に制御する可能性
      CVSS:3.1:9.8(緊急)

    CVE-2024-38189(Microsoft Project関連)

    • リスク:プロジェクトデータや機密情報の漏洩
    • CVSS:3.1:8.8(重要)

    重要性

    早急な更新が必要

    対策

    • セキュリティ更新プログラムを速やかに適用
    • システムとネットワークの監視強化
    • セキュリティ設定の見直し

    情報源

    詳細はMicrosoftの公式セキュリティガイドラインを参照

    ユーザへの呼びかけ

    常に最新のセキュリティ情報に注意を払い、適切な対策をとること

    【関連リンク】

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2024年8月21日(水)14:00~15:00
    ランサムウェア対策の要~ペネトレーションテストの効果、脆弱性診断との違いを解説~
  • 2024年8月28日(水)12:50~14:00
    【好評アンコール配信】「知っておきたいIPA『情報セキュリティ10大脅威 2024』~セキュリティ診断による予防的コントロール~
  • 2024年9月4日(水)14:00~15:00
    インシデント発生の事前準備・事後対応 -拡大するサイバー攻撃への対策方法とは-
  • 2024年9月11日(水)14:00~14:30
    CVSSとSSVCで実践する次世代脆弱性管理:サイバー攻撃対策セミナー2024
  • 最新情報はこちら

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


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

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

    PCI DSS v4.0で変わるセキュリティ対策のポイント

    Share
    2枚のクレジットカードのイメージ

    PCI DSS v3.2.1の引退まで1年を切っていますが、対応状況はいかがでしょうか。2022年3月31日にリリースされたPCI DSS v4.0の準拠運用は、即時要件に対しては遅くとも2024年4月に開始される時期となり、システム系の大きな変更点が伴う未来日付要件を含めたv4.0完全対応完了までは、残り1年半となっています。この記事では、PCI DSS v4.0で変わるセキュリティ対策のポイントについて、脆弱性診断に関する要件に着目し、今後どのように対応すべきかについて解説します。


    PCI DSS v4.0:新たなセキュリティスタンダードへの移行

    PCI DSSとは、Payment Card Industry Data Security Standardの頭文字をとったもので、クレジットカード会員データを安全に取り扱うことを目的として策定された、クレジットカード業界のセキュリティ基準です。American Express、Discover、JCB、MasterCard、VISAの5つのカードブランドによって設立された組織、PCI SSC(PCI Security Standards Council)によって管理されており、クレジットカードを取り扱うすべての事業者に対して、カード情報の保護とセキュリティの実施を求めるものです。この基準に準拠することで、クレジットカードを取り扱う事業者の信頼性と顧客の安心感を高め、ブランド価値の保護、そして業界全体のセキュリティレベルの向上に寄与します。

    2022年3月31日には最新版PCI DSS v4.0が発表されました、 以前のメジャーバージョンであるPCI DSS v3.0は2013年11月に発表されたもので、今回8年4か月ぶりのメジャーアップデートとなります。今後2024年3月31日には2年間の移行期間が終了したv3.2.1が引退し、以降v4.0のみが有効な基準となることが決まっています。

    PCI DSS v4.0移行スケジュール

    未来日付要件は、現在はベストプラクティス要件の位置づけのため、2025年3月31日までは対応必須ではありません。しかし、残り1年半程度の対応期間の中で、システム改修や新規ソリューション導入等を行わなければならない場合、予算化や製品選定、対応ベンダ選定、運用に向けた検証作業、手順書見直しなど、対応すべき事項は決して少なくありません。

    少なくとも今年度中には、要件の要求ポイントと自組織に不足する要素を洗い出し、対応スケジュールの立案が済んでいることが望ましい時期です。

    PCI DSS v4.0改定のポイント

    PCI DSS v4.0は、従来のv3.2.1に比べて、以下のようなポイントで改定されています。

    ● 決済業界のセキュリティニーズに対応
    ● 継続的なプロセスとしてセキュリティを促進
    ● さまざまな方法論に柔軟性を追加
    ● 検証方法を強化

    出典:https://www.pcisecuritystandards.org/document_library/
    PCI-DSS-v4-0-At-a-Glance-r1-JA.pdf

    PCI DSS v3.2.1からの主な変更点

    PCI DSS v4.0では、いくつかの重要な変更点があります。事業者がPCI DSS準拠の対応を検討する際には、これらの変更点に注意を払う必要があります。

    要件タイトル変更

    まず、大きな変更の一つ目が、要件タイトルの変更です。要件9以外すべてが変更となりました。加えて、要件の理解を高めるために、詳細要件と用語の定義、文章の修正が行われました。

    PCI DSSv4.0要求事項(PCIデータセキュリティ基準まとめ)

    進化した要件

    次に、新たな脅威や技術、決済業界の変化に対応するため追加された新規要件や、既存要件が一部変更/削除されたものがあります。該当する要件は67件ありますが、その中でも大きなものとしては、以下のようなものがあげられます。

    PCI DSS v4.0新要件内容まとめ

    多要素認証について

    PCI DSS v4.0では、要件8.5.1にて、多要素認証(MFA)について、実装方法が明確に要件化されました。

    PCI要件8.5.1「多要素認証の構成について」要件内容

    また、要件8.4.2では「カード会員データ環境(CDE)へのすべてのアクセス」にMFA(多要素認証)が要求されることになりました。8.4.3では「カード会員データ環境(CDE)にアクセスまたは影響を与える可能性のある、事業体のネットワーク外から発信されるすべてのリモートネットワークアクセス」に対してもMFAが求められており、それぞれでMFAが必要となります。

    これは例えば、ある担当者が最初にリモートアクセスによって事業者のネットワークに接続し、その後ネットワーク内からカード情報データ環境(CDE)への接続を開始した場合、その担当者は「事業者のネットワークにリモートで接続するとき」と「事業体のネットワークからカード会員データ環境(CDE)へアクセスするとき」の2回、MFAを使用して認証する必要があるということです。なお、CDEへのアクセスに対するMFAはネットワークまたはシステム/アプリケーションのレベルで実装することができます。CDEネットワークに接続する際にMFAを使用した場合、その後のCDE内の各システムコンポーネントにログインする際には追加のMFAを使用する必要はありません。

    脆弱性診断に関する主な変更点

    PCI DSS v3.2.1からv4.0への変更点のうち、脆弱性診断に関わるポイントとしては以下の3点が挙げられます。

    脆弱性診断に関する主な変更点(脆弱性スキャンの頻度・認証スキャンの実施・ペネトレーションテストの内容)

    脆弱性スキャンの頻度は「四半期に一度」だったところが「3カ月に1回」へと変更されました。PCI DSSの時間枠要件の意図は「その時間枠を超えない範囲で、できるだけ近い感覚で実行されること」であるところを、「四半期に一度」では最大半年ほど間隔があいてしまうことも許容することになってしまうため、厳格化されたものと思われます。

    認証スキャンの実施については、十分な特権ユーザのID/パスワードのアカウント、もしくはクライアント証明書を保持した状態であることが必要になります。十分な権限による脆弱性スキャンができない事情がある場合は、当該システムについて文書化することが求められます。

    ペネトレーションテストに求められる内容については、PCI DSS v3.2.1では、業界承認のテスト方法(NIST SP800-155など)であればよいと規定されていましたが、結果としてペンテスターへの依存度が高くなり、さまざまな形態のペネトレーションテスト結果の提出が許容される形となっていました。こうした状況を是正し、準拠レベルを標準化するため改定されたのではないかと考えられます。

    脆弱性診断実施にあたって求められる対応

    PCI DSS v4.0では脆弱性診断実施にあたって求められる対応にも変更があります。高リスクの脆弱性(CriticalやHigh)以外の脆弱性、すなわち中・低リスクの脆弱性(MediumやLow)についても、ターゲットリスク分析の上で対応をすることが要求されています。また、脆弱性は日々新しいものが発見・更新されていますので、各種のスキャン等で検出された高リスクの脆弱性対応だけでも大きな負担であるところを、さらに中低のリスクとされる脆弱性についても対処が必要となると、脆弱性管理は非常に負担の大きな作業になることが予想されます。

    PCI DSS v4.0に求められる脆弱性診断のポイント(診断実施機関の長期化・診断実施時のリスクの考慮)

    QSA(Qualified Security Assessors:認定審査機関)の見解次第ではありますが、ターゲットリスク分析の結果、『対処の必要なし』と判断した事業者側の意見が通った場合は別として、中低リスクの脆弱性についても対処が基本的に必要になると考えますと、今まで通りのやり方(PCI DSS v3.2.1手法の脆弱性管理)では指摘を受ける可能性もあります。この規定の”目的”部分を見ると、機械的に中小リスクだから対応は一律不要と判断するのではなく、ターゲットリスク分析において、きちんとした根拠を持って”対処が不要”とした事業者が結論を出す必要があると読み取れます。

    脆弱性診断に関する主な変更点については、SQAT® Security Report 2023年 春夏号
    PCI DSS v4.0で変わる脆弱性診断 ~2024年4月1日完全移行で慌てないために~」でも取り上げています。
    以下より資料(PDF)ダウンロードいただけますので、ぜひご参考ください。
    https://www.sqat.jp/sqat-securityreport/

    PCI DSS v4.0への移行に向けて

    PCI DSSの準拠対応を検討する事業者にとって、PCI DSS v4.0への移行は重要な課題です。新たな要件や変更点に対応するためには、準備が必要となります。

    PCI DSS v4.0準拠までのステップ

    ● PCI DSS v4.0の精査
    ● 現状の環境での差異を把握
    ● 詳細化・明確化要件の対応を開始
    ● 新規要件およびシステム化対応の予算を確保
    ● 新規要件およびシステム化対応の実施
    ● 全体の対応状況の確認

    PCI DSS v4.0では、ここで取り上げたほかにも、クラウド環境でのセキュリティ要件の明確化、セキュリティ管理の強化といった変更点もあります。事業者はv4.0に準拠対応しようとした場合、従来よりも高いレベルのセキュリティを実現することが求められます。専門家の助言や適切なソリューションを活用することが、スムーズな準拠対応の一助となるでしょう。当社ブロードバンドセキュリティがその助けとなれば幸いです。

    関連情報

    ウェビナー抜粋動画

    過去ご好評いただいたウェビナーの抜粋動画を無料で公開しています。

    「今さら聞けない!PCI DSSで求められる脆弱性診断あれこれ」
    PCI DSSの準拠対応についてご紹介しつつ、PCI DSSで求められる脆弱性診断とペネトレーションテストの概要について今さら聞けない!?内容を徹底解説しています。今後も皆様のお役に立てるセミナーを企画してまいりますので、ご要望がございましたらぜひ、お問い合わせください。


    BBSecでは

    BBSecは、PCI SSC認定QSA(PCI DSS準拠の訪問審査を行う審査機関)です。準拠基準についての疑問や対応困難な状況があるといったような懸念・不安などは曖昧なままにせず、QSAにご相談いただくことをおすすめいたします。準拠に向けた適切な対応を検討するためのアドバイスや、事情に応じた柔軟な対応も可能です。

    お問い合わせはこちら
    ※外部サイトにリンクします。

    PCI DSS v4.0対応脆弱性診断サービス随時対応受付中!

    次回ウェビナー開催のお知らせ

    ・2023年10月18日(水)13:50~15:00
    自動車産業・製造業におけるセキュリティ対策のポイント -サプライチェーン攻撃の手口と対策方法-
    ・2023年11月15日(水)13:50~15:00
    Webアプリケーションの脆弱性対策 -攻撃者はどのように攻撃するのか-

    最新情報はこちら

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


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

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

    Webアプリケーションの脆弱性入門

    Share
    人がアプリケーションを持っているイラスト

    Webアプリケーションは私たちの日常生活に欠かせない存在となっています。しかし、それらのWebアプリケーションが攻撃者からの脅威にさらされていることをご存知でしょうか?Webアプリケーションに脆弱性が存在すると、悪意のある第三者によって個人情報や企業の機密情報が漏洩するリスクが生じます。この記事では、Webアプリケーションの脆弱性の種類について解説します。

    脆弱性とは

    脆弱性とは(ポイントマークとその周りに人がいる)イメージ

    脆弱性とは、プログラムの不具合や設計上のミス等によるバグが原因となって発生したセキュリティ上の欠陥や弱点のことを指します。Webアプリケーションに脆弱性が存在する場合、攻撃者がシステムに侵入し、機密情報を盗み出したり、サービスを乗っ取ったりするリスクが生じます。企業はWebアプリケーションの脆弱性を理解し、それに対処するための適切な対策を講じる必要があります。

    脆弱性の種類

    脆弱性にはさまざまな種類があります。以下に代表的な例を挙げます。

    1. SQLインジェクション

    データベースを使って情報を処理するWebアプリケーションは、その多くがユーザからの入力値をもとにデータベースへの命令文を構成しています。SQLインジェクションは、攻撃者がWebフォームなどの入力欄に特定のコードを入れることで不正な命令文を構成し、データベースを不正利用できてしまう脆弱性です。これを悪用することで、例えば、データベースの情報を盗んだり、改ざんしたり、消去したりできる可能性があります。

    2. クロスサイトスクリプティング(XSS)

    クロスサイトスクリプティング(XSS)は、ネットバンキングや掲示板のように、ユーザから入力された値を処理して出力するWebページに攻撃者が悪意のあるスクリプトを埋め込むことで、Webページを閲覧したユーザのWebブラウザ上でスクリプトを実行させることができる脆弱性です。これを悪用されると、ユーザが意図しない情報の送信や表示ページの改ざんなどのリスクが発生します。

    3. クロスサイトリクエストフォージェリ(CSRF)

    クロスサイトリクエストフォージェリ(CSRF)は、攻撃者が罠として用意した偽サイトを用いてリンクや画像をクリックさせることで、ユーザが意図していないリクエストを強制的に行わせることができる脆弱性です。例えば、SNSで「いいね!」をする、銀行の振込操作など、被害者がログインしているWebサービスの操作を攻撃者が悪用することが可能です。

    4. セッション管理の不備

    Webアプリケーションの中には、セッションID(ユーザを識別するための情報)を発行し、セッション管理を行うものがあります。このセッション管理に不備があることで、セッションIDを固定化できたり、有効なセッションIDが推測可能だったりすると、セッションハイジャックと呼ばれる攻撃が成立する危険性があります。これにより、攻撃者が本来のユーザになりすまして権利を行使することで、プライベートな情報の閲覧や、設定の変更などが行われる可能性があります。

    5. アクセス制御の不備

    Webアプリケーションにおいて、本来付与されている権限の範囲内でのみ動作するような制御が実装されていない問題を指します。例えば、一般ユーザとしてログインした際に管理者としての権利を行使できてしまう権限昇格、パラメータを操作することで、本来制限された領域外のファイルやディレクトリにアクセスすることが可能となるパストラバーサルなどです。不正アクセスや意図しない情報の公開をはじめとした、様々なリスクが生じます。

    脆弱性を悪用した攻撃による影響

    脆弱性が悪用されると、企業に深刻な影響が及ぶ恐れがあります。脆弱性が引き起こす可能性のある影響の例を、以下に示します。

    機密情報の漏洩

    攻撃者は、脆弱性を利用して機密情報を盗み出すことができます。クレジットカード情報や個人情報など、大切な情報が漏洩することで、企業の信頼性に係る問題や法的な問題が発生する可能性があります。

    データの改ざん

    脆弱なWebアプリケーションは、攻撃者によってデータの改ざんが行われる可能性があります。データの改ざんによって、Webアプリケーションの正確性が損なわれたり、信頼性が低下したりする可能性があります。

    サービスの停止または遅延

    脆弱性を悪用されると、サービスの停止、遅延、またはデータベースの消去といった、システム全体に影響が及ぶ被害を受ける恐れがあり、企業のビジネス活動に重大な影響が生じる可能性があります。

    金銭的な損失

    脆弱性のあるWebアプリケーションは、企業にとって金銭的な損失をもたらす可能性があります。攻撃者による不正アクセスでデータが盗難された結果、企業に損害賠償責任が生じる場合があります。

    企業の信頼喪失

    セキュリティに関する問題が公になると、企業の評判に悪影響を与える可能性があります。顧客やパートナーからの信頼を失うことは、企業にとって非常に重大な損失です。

    脆弱性対策の方法

    脆弱性の悪用を防ぐためには、以下のような対策が考えられます。

    正しい権限管理の実施

    ユーザには場面に応じた必要最小限の権限のみ付与することが推奨されます。また、不要な機能やリソースへのアクセスを制限することも脆弱性を軽減させるポイントとなります。

    定期的なセキュリティチェックの実施

    定期的なセキュリティチェックの実施(セキュリティとパソコンの周りに人)イメージ

    Webアプリケーションに対しては、機能追加などのシステム改修時はもちろんのこと、定期的なセキュリティチェックを行うことが重要です。脆弱性スキャンやペネトレーションテストなどの手法を活用し、問題を早期に発見して修正することが大切です。

    最新のセキュリティパッチの適用

    Webアプリケーションを開発・運用する際には、使用しているフレームワークやライブラリの最新のセキュリティパッチを適用することが必要です。これにより、既知の脆弱性やセキュリティ上の問題を解消することができます。

    まとめ

    脆弱性のあるWebアプリケーションは、攻撃の潜在的なターゲットになります。セキュリティ対策を徹底し、脆弱性の早期発見と修正を行うことが重要です。また、さまざまな対策手法やセキュリティツールを活用し、脆弱性を作り込まないセキュアな開発環境作りに取り組んでください。企業のデータや顧客の個人情報を守るためにも、脆弱性対策は欠かせません。今回の記事がお役に立てれば幸いです。

    セキュリティ診断サービスのサムネ

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

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