Windows10のサポート終了-その影響とリスクを考える-

Share

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

2025年10月、Windows 10のサポートが終了します。サポート切れのソフトウェアを使用し続けることで、企業はセキュリティリスクにさらされる可能性が高まります。そして脆弱性が放置され、攻撃者に狙われやすくなることで、情報漏洩や業務停止の危険が増大します。本記事では、Windows 10のサポート終了に伴う影響や、企業が取るべきセキュリティ対策を解説します。実際に脆弱性を悪用した攻撃事例を紹介し、どのようにしてリスクを最小化できるのか、具体的な対応策を提案します。

【関連ウェビナー開催情報】
弊社では4月23日(水)14:00より、「2025年10月 Windows10サポート終了へ 今知るべき!サポート切れのソフトウェアへのセキュリティ対策ガイド」と題したウェビナーを開催予定です。2025年10月にサポート終了を迎えるWindows10の脆弱性とサポート切れのソフトウェア製品への対応策について解説します。ご関心がおありでしたらぜひお申込みください。詳細はこちら

記事に関連したわかりやすい解説動画も公開しております。
是非こちらもご覧ください!

2025年10月、Winodws10のサポートが終了

Microsoftは2025年10月14日、Windows 10のサポートを終了します。最終バージョンは22H2となっており、このバージョンを含め、すべてのエディションはこの日をもってサポートが終了します。サポート終了後は、以下のサービスが提供されなくなります。

  • テクニカルサポート
  • セキュリティ更新プログラム
  • バグ修正(パッチの提供)
  • 機能更新プログラム

Windows10搭載PCは引き続き動作しますが、セキュリティ更新プログラムを受け取れなくなるため、このため、企業のシステムは新たな脅威に対して脆弱になり、マルウェアに感染するリスクが非常に高まります。

Windows10サポート終了の背景

MicrosoftがWindows 10をサポート終了するに至った背景には、主に次のようなものがあります。

  • 新技術の導入の必要性 最新のセキュリティ技術やパフォーマンス向上のための新機能を取り入れるため、古いOSから新しいOSへの移行が必要になりました。
  • 市場の変化への対応 ユーザーのニーズが変化し、より高いセキュリティや新機能が求められるようになったことから、古いOSでは対応しきれなくなりました。

当初Windows10は「最後のバージョンのWindows」と位置付けられていましたが、セキュリティ環境の変化や新技術の進展により、Windows11への移行を推奨する流れとなりました。

Windows10サポート終了後の影響 企業が直面するリスク

サポートが終了したソフトウェアの継続利用は、重大なセキュリティリスクを伴います。Windows10の場合、セキュリティ更新が行われなくなることで、新たに発見される脆弱性に対して無防備な状態となってしまいます。日々進化するサイバー攻撃において、攻撃者はこうしたサポート終了後のソフトウェアを格好の標的としています。システムへの主な影響としては、以下が挙げられます。

システムへの影響

  1. 脆弱性を突かれるリスクの増加
    サポート終了後に発見された脆弱性は、修正されないまま放置されることになります。攻撃者はこの未修正の脆弱性を悪用し、システムへの不正アクセスやデータの窃取を試みる可能性が高まります。特に企業のネットワーク環境では、1台の更新されていないPCが、システム全体にとっての弱点となりかねません。
  2. ソフトウェアの互換性における課題
    最新のアプリケーションやハードウェアは、サポートの終了したOSでの動作保証を行いません。Windows10のサポート終了後は、新しいソフトウェアやデバイスが正常に機能しなくなる可能性が高く、業務効率の低下が懸念されます。

企業への主な影響

運用リスク

  • システム故障による業務中断
  • セキュリティ侵害やマルウェア攻撃によるダウンタイムの増加
  • ソフトウェアの互換性や技術サポートに関する課題
  • 古いソフトウェアを使い続けると、最新のアプリケーションやハードウェアとの互換性が失われる可能性があります。例えば、最新のクラウドサービスが利用できなかったり、新しいデバイスとの接続ができなかったりすることで、業務の効率が低下します。

コンプライアンス上の問題

  • コンプライアンス規制を満たさないことによる法的罰則
  • 個人情報保護に関する政府機関等からの監視強化

近年、多くの業界で求められる各種規制やコンプライアンス要件では、最新のセキュリティ対策の実施が必須となっています。サポート終了したWindows10の使用は、これらの基準に抵触する恐れがあり、企業の信用失墜や法的制裁につながる可能性があります。

Windows 10に存在する脆弱性とその脅威

Windows 10は定期的にセキュリティアップデートが提供されていますが、過去にはいくつかの深刻な脆弱性が発見され、修正されています。以下は、Windows10における代表的な脆弱性です。

CVE-2017-0144(EternalBlue)

  • 概要:CVE-2017-0144(EternalBlue)は、Windows7、8、10、XPを対象にした脆弱性で、サーバーメッセージブロック(SMBv1)を通じて悪用されます。この脆弱性はMicrosoftから提供されたセキュリティパッチで修正済みですが、パッチ未適用のシステムでは依然としてリスクがあります。
  • 影響:この脆弱性が悪用されると、攻撃者はリモートコード実行ができるため、サーバやクライアントPCを完全に制御できるようになります。ランサムウェアの「WannaCry」や「NotPetya」は、この脆弱性を悪用した例です。

CVE-2019-0708(BlueKeep)

  • 概要:CVE-2019-0708(BlueKeep)は、Windows7、Windows Server2008 R2などのバージョンに影響を与えるリモートデスクトッププロトコル(RDP)の脆弱性です。Windows10でも一定の影響を受ける可能性があり、リモートデスクトップサービスにおいて攻撃者が未検証のリクエスト送信することにより、任意のコードを実行できる危険性があります。
  • 影響:攻撃者がこの脆弱性を悪用すると、リモートでシステムを完全に制御でき、感染したコンピュータを他のシステムに拡大させることができます。この脆弱性は、深刻なセキュリティインシデントを引き起こす可能性があります。

Windows 10の脆弱性を悪用した攻撃の事例

攻撃者はWindows10の脆弱性を悪用して、システムへの不正侵入や情報漏洩、マルウェアの拡散を行います。以下は、脆弱性を悪用した攻撃の事例です。

Windows MSHTMLの脆弱性

Microsoftは2024年7月の更新プログラムでWindows MSHTMLの脆弱性「CVE-2024-38112」へ対応したプログラムを公開しました。この脆弱性はInternet Explorer(通称:IE)の一部を構成するMSHTMLブラウザエンジンの欠陥によるものです。本脆弱性については1年半にわたって悪用されていたことが確認されており、米CISAのKnown Exploited Vulnerability Catalogにも新規追加されました。

攻撃の概要
今回報告・悪用されたWindows MSHTMLの脆弱性「CVE-2024-38112」はMSHTMLを悪用し、現行OSで無効化されているはずのIEを呼び出すものです。IEモードやMSHTMLなどのドライバ類は、レガシーサイトへのアクセスの要望に応えるために残存していますが、2024年7月のセキュリティ更新まではショートカットファイル内でインターネットショートカット用にMSHTMLが使用できたため悪用されました。攻撃の概要は下図のとおりです。マルウェアのダウンロードが主目的となっていることがわかります。

サポート切れソフトウェアのセキュリティリスク

  1. セキュリティの脆弱性が修正されない
    サポートが終了したソフトウェアには、新たに発見された脆弱性に対するセキュリティパッチが提供されません。そのため、ハッカーにとって格好の標的となり、マルウェア感染や不正アクセスのリスクが高まります。
  2. ランサムウェアやマルウェア攻撃の増加
    近年、サポート終了ソフトウェアを狙ったランサムウェア攻撃が増加しています。例えばWindows XPのサポート終了後、「WannaCry」というランサムウェアが流行し、多くの企業が被害を受けました。これと同様の攻撃が、サポート終了後のWindows 10やその他の古いソフトウェアでも発生する可能性があります。
  3. 法規制やコンプライアンス違反
    企業がサポート終了ソフトウェアを使い続けることは、法的リスクを伴います。特にGDPR(EU一般データ保護規則)や日本の個人情報保護法では、適切なセキュリティ対策を講じることが求められています。サポートが終了したソフトウェアを利用することは、これらの規制違反となる可能性があり、企業の信頼性が損なわれる要因となります。
  4. ソフトウェアの互換性問題
    古いソフトウェアを使い続けると、最新のアプリケーションやハードウェアとの互換性が失われる可能性があります。例えば、最新のクラウドサービスが利用できなかったり、新しいデバイスとの接続ができなかったりすることで、業務の効率が低下します。
  5. ITコストの増加
    一見すると、古いソフトウェアを使い続けることはコスト削減につながるように思えますが、実際にはその逆です。セキュリティの問題が発生すれば、データ漏えいやシステム停止による損害が発生し、結果的に大きなコストがかかる可能性があります。

サポート終了後のソフトウェアへの対応策

  1. 速やかなアップグレード
    最も安全な対策は、最新のソフトウェアへアップグレードすることです。例えば、Windows 10のサポート終了が迫っているため、企業や個人はWindows 11への移行を検討することが推奨されます。
  2. 仮想環境での隔離
    どうしてもサポートが終了したソフトウェアを使い続ける必要がある場合は、**仮想マシン(VM)**を利用し、ネットワークから切り離して運用する方法もあります。これにより、セキュリティリスクを最小限に抑えることが可能です。
  3. セキュリティ対策の強化
    古いソフトウェアを使用する場合、ファイアウォールの強化や最新のエンドポイントセキュリティを導入することで、攻撃のリスクを軽減できます。また、多要素認証(MFA)を導入することで、不正アクセスのリスクを低減できます。
  4. 定期的な脆弱性診断
    企業では、定期的な脆弱性診断を実施し、セキュリティの問題を早期に発見することが不可欠です。セキュリティ専門家による診断を受けることで、サイバー攻撃のリスクを軽減できます。
  5. クラウドサービスへの移行
    古いソフトウェアの代替として、クラウドベースのサービスを活用する方法もあります。例えば、Microsoft 365やGoogle Workspaceといったクラウドサービスに移行することで、常に最新のセキュリティアップデートを受けられます。

Windows11へのアップグレード

最も推奨される対策は、Windows 11へのアップグレードです。

Windows11への移行がもたらすメリット

リスクを回避するためには、最新のOSへのアップグレードが不可欠です。現時点では、Windows11への移行が最も現実的な選択肢となっています。Window11では、セキュリティ機能の強化に加え、パフォーマンスの向上や最新テクノロジーへの対応が図られています。主なメリットは以下の通りです。

  • 最新のセキュリティ更新が継続的に提供され、新たな脅威からシステムを保護
  • ハイブリッドワークやAI活用に最適化された機能により、業務効率が向上
  • 各種セキュリティ要件への準拠により、コンプライアンスリスクを軽減

企業向けの対応策

  1. 現在の環境の把握:
    ・使用中のWindows 10バージョンとハードウェア構成を調査
    ・Windows11へのアップグレード可能性を評価
  2. 移行計画の策定:
    ・Windows11への段階的な移行スケジュールの作成
    ・互換性のないアプリケーションの特定と対応策の検討
  3. セキュリティ対策の強化:
    ・ESUの導入検討
    ・多層防御の実装
  4. PCライフサイクル管理の見直し:
    ・PC管理台帳の作成・更新
    ・計画的な買い替え・更新サイクルの確立
  5. 従業員教育とサポート体制の整備:
    ・移行に関する情報提供と教育
    ・移行期間中のサポート体制の確立

Windows10のサポート終了に向けて、綿密な移行計画の策定が求められます。まずは現行のPCやシステムがWindows11の動作要件を満たしているか確認し、必要に応じて機器の更新計画を立てましょう。また、重要なデータのバックアップや、新システムに関する従業員向けトレーニングの実施も欠かせません。企業はIT部門と緊密に連携しながら、段階的な移行スケジュールを組むことで、業務への影響を最小限に抑えることができます。

情報資産の棚卸

組織内に存在する情報に関し、機密とするもの、公知であってよいものを分類し、それらがどこに格納されて、どのように利用されているかを可視化した上で、防御の対応をする機器・人・組織といったリソースを適切に振り分けて防御する仕組みを構築することが求められます。

これにより、システムへのマルウェアの侵入等の早期発見にも繋がり、事業活動の継続を左右する重要情報へのアクセスを遮断することで、万一侵入を許しても被害を最小限に抑えられます。

信頼できる第三者機関の脆弱性診断サービスを実施

企業として実施できるサイバー攻撃への対策として、信頼できる第三者機関による脆弱性診断が挙げられます。第三者の専門家からの診断を受けることで、現状の問題点や対応の優先順位などリスクを可視化することができるため、早急に効率よく対策を実施するのに役立ちます。

サイバー攻撃手法は日々更新されており、さらに取引先や子会社などを含むサプライチェーンを踏み台にした攻撃など、どんなにセキュリティ対策を実施していても自組織のみではインシデント発生を防ぎきれないのが実情です。脆弱性診断の定期的な実施といった基本的なセキュリティ対策を行うとともに、万が一インシデントが発生してしまった場合の備えとして信頼できる第三者の専門企業に相談することをおすすめします。

まとめ

Windows 10のサポート終了は2025年10月14日に迫っています。セキュリティリスクを回避するためには、Windows 11へのアップグレード、または代替策の導入が必要です。企業の担当者は、計画的な移行準備を早期に開始することを推奨します。

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

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

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

詳細・お見積りについてのご相談は、お問い合わせフォームからお気軽にお問い合わせください。お問い合わせはこちら。後ほど、担当者よりご連絡いたします。

SQAT脆弱性診断サービス

自ステムの状態を知る

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

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

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

  • 2025年4月16日(水)14:00~15:00
    知っておきたいIPA『情報セキュリティ10大脅威 2025』~セキュリティ診断による予防的コントロール~
  • 2025年4月23日(水)14:00~15:00
    今知るべき!サポート切れのソフトウェアへのセキュリティ対策ガイド
  • 2025年4月30日(水)13:00~13:30
    CVSSとSSVCで実践する次世代脆弱性管理:サイバー攻撃対策セミナー2024
  • 最新情報はこちら


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

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

    PCI DSSとは ―12の要件一覧とPCI DSS準拠―

    Share

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

    PCI DSSとは国際カードブランド5社により定められた、クレジットカード情報を守るためのセキュリティ基準です。2024年4月1日にはPCI DSS v4.0が運用を開始しています。本稿では、PCI DSSとは何か、PCI DSSv4.0の要件について解説。準拠のために何が必要になるのか等について触れながら、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 DSS1は、上記カードブランド5社が設立した組織であるPCI SSC(PCI Security Standards Council)によって管理されています。2024年4月1日からはPCI DSS v4.0が運用開始しています*2

    PCI DSS準拠が求められる企業

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

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

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

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

    日本では、経済産業省が一部の加盟店に対して、クレジットカード情報の保存・処理・伝送を一切しない、いわゆる「クレジットカード情報の非保持化」か、PCI DSSの準拠のどちらかを選択することを認めています。(国際ブランド側には非保持化の概念自体なく、すべて事業体に対してPCI DSSの準拠が求められています。)

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

    上記のような状態で、「非保持化しているつもり」「PCI DSS準拠対象外のつもり」になっていないかどうかに注意しましょう。 このようなレギュレーション適用の判断については、正確性が重要です。PCI DSSに詳しいセキュリティ企業のアドバイスを受けることをおすすめします。

    AWS環境下でのPCI DSS準拠

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

    PCI DSSv4.0の要件一覧

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


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

    1. ネットワークのセキュリティ制御を導入し、維持します。
    2. すべてのシステムコンポーネントに安全な設定を適用します。

    アカウントデータの保護

    3. 保存されたアカウントデータを保護します。
    4. オープンな公共ネットワークでの通信時に、強力な暗号化技術でカード会員データを保護します。

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

    5. すべてのシステムとネットワークを悪意のあるソフトウェアから保護します。
    6. 安全なシステムおよびソフトウェアを開発し、維持します。

    強固なアクセス制御の実施

    7. システムコンポーネントおよびカード会員データへのアクセスを、業務上の必要性に応じて制限します。
    8. ユーザーを識別し、システムコンポーネントへのアクセスを認証します。
    9. カード会員データへの物理的なアクセスを制限します。

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

    10. システムコンポーネントおよびカード会員データへのすべてのアクセスを記録し、監視します。
    11. システムおよびネットワークのセキュリティを定期的にテストします。

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

    12. 組織の方針とプログラムによって情報セキュリティをサポートします。


    PCI DSSv3.2.1から要件のタイトルも要件9以外変更になりました。要件の理解を高めるために詳細要件との用語の定義、文章の修正が行われました。

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

    PCI DSSの評価方法 -PCI DSS準拠認定のために実施すること-

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

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

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

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

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

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

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

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

    BBSecでは

    なお、株式会社ブロードバンドセキュリティは、PCI SSC認定QSA(PCI DSS準拠の訪問審査を行う審査機関)です。また、PCIDSS準拠のためのネットワークスキャンやペネトレーションテストの実績を多数持っています。準拠基準についての疑問や対応困難な状況があるといったような懸念・不安などは曖昧なままにせず、QSAにご相談いただくことをおすすめいたします。

    弊社では「今さら聞けない! PCI DSSで求められる脆弱性診断 -4月1日運用開始!PCI DSSv4.0での脆弱性診断実施におけるポイントとは-」と題したウェビナーで、PCI DSS v4.0で求められる脆弱性スキャンやペネトレーションテストについて、v3.2.1からの変更点を中心にお話しています。ご関心がおありでしたら、ぜひご参考にしていただければと思います。

  • 2024年5月29日(水)13:00~14:00
    今さら聞けない!PCI DSSで求められる脆弱性診断-4月1日運用開始!PCI DSSv4.0での脆弱性診断実施におけるポイントとは-
  • 最新情報はこちら

    まとめ

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

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


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

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


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

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

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

    セキュリティトピックス動画申し込みページリンクへのバナー画像

    緊急セキュリティ警告:ArrayOS AG における深刻な脆弱性 CVE-2023-28461

    Share

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

    Array Networks社のArrayOS AGに存在する重大な脆弱性について、企業が知るべき最新情報をお伝えします。ネットワークセキュリティについて情報収集されている方は必読です!

    脆弱性の概要と深刻度

    CVE-2023-28461は、ArrayOS AGのセキュリティ基盤を揺るがす深刻な認証脆弱性です。CVSSスコア9.8という極めて高い危険度は、即時の対応を求めています。

    脆弱性の特徴

    • 影響バージョン:ArrayOS AG 9.4.0.481以前
    • 攻撃難易度:非常に低い
    • 潜在的リスク:システム不正アクセス、情報漏洩、サービス運用妨害

    攻撃の実態と脅威

    2023年3月15日に公表されたこの脆弱性は、すでに複数の攻撃キャンペーンで悪用されています。特に注目すべきは、Earth Kashaという脅威アクターによる組織的な攻撃です。

    攻撃の特徴

    • 2023年4-5月:リモートコード実行が疑われる攻撃
    • 標的:日本および世界各国のテクノロジー企業、政府機関

    企業が取るべき対策

    この脆弱性から組織を守るために、以下の対策が不可欠です。

    修正プログラムの適用

    Array Networks社から提供されている修正プログラムを速やかに適用することが最も重要です。特に、バージョン9.4.0.481およびそれ以前のバージョンを使用している場合は、最新のアップデートを適用してください。

    アクセスログの監視

    不審なアクセスや異常な動作を早期に発見するために、アクセスログを定期的に監視し、異常がないか確認します。特に、VPN接続や外部からのアクセスが多い環境では注意が必要です。

    セキュリティ機器の強化

    インターネット境界に設置されているセキュリティ機器(ルータやファイアウォールなど)の設定を見直し、不必要なポートやサービスを閉じることで攻撃面を減少させます*3

    脆弱性管理の実施

    使用しているシステムやアプリケーションの脆弱性情報を定期的に確認し、ゼロデイ脆弱性や既知のエクスプロイトに対する対策を講じます。特に、Array AGシリーズのような外部からアクセスされる機器は優先的に管理します*2

    多要素認証の導入

    認証機構自体の強度を高めるため、多要素認証(MFA)を導入し、パスワードだけでなく他の認証手段も組み合わせて使用します。

    リスク軽減のための具体的なステップ

    システム管理者向け緊急対応

    • ArrayOS AGのバージョンを速やかに確認
    • 公式パッチの即時適用
    • 不審なアクセスログの分析
    • 外部セキュリティ専門家への相談検討

    最後に

    この脆弱性は単なる技術的な問題ではなく、組織の存続に関わる重大なセキュリティリスクです。迅速かつ包括的な対応が求められます。セキュリティは待ったなし。今すぐ行動を起こしてください。


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

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

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

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

  • 2024年12月4日(水)13:00~14:00
    インシデント発生の事前準備・事後対応-拡大するサイバー攻撃への対策方法とは-
  • 2024年12月11日(水)14:00~15:00
    ランサムウェア攻撃の実態と対策:2024~脅威に備える最新の対策法を解説~
  • 2024年12月18日(水)14:00~15:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 最新情報はこちら


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

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

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

    Share

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

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

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

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

    プログラミング言語

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

    言語 2024年 2020年
    JavaScript 64.60% 69.70%
    HTML/CSS 54.10% 62.40%
    Python 53% 41.60%
    SQL 47% 56.90%
    TypeScript 43.40% 28.30%
    Bash/Shell 34.20% 34.80%
    Java 30.00% 38.40%
    C# 28.80% 32.30%
    C++ 20% 20.50%
    C 18.70% 18.20%
    PHP 16.90% 25.80%
    PowerShell 14.40% 注 1)
    Go 14.00% 9.40%
    Rust 11.70% 4.80%
    Kotlin 9.90% 8.00%
    Dart 6.00% 3.70%
    Ruby 5.80% 7.50%
    Lua 5.30% ランク外
    Swift 4.90% 6.10%
    Visual Basic 4.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 NEWS TOPに戻る
    バックナンバー TOPに戻る

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

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

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

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

    SQLインジェクションで航空セキュリティシステムをハッキング!あなたのフライトは安全?

    Share

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

    近年、航空機のセキュリティはますます厳しくなってきています。しかし、私たちが安心して空の旅を楽しんでいる裏側で、実は深刻なセキュリティ問題が潜んでいることをご存知でしょうか?この度、イアン・キャロルサム・カリーは、空港のセキュリティシステムに存在する重大な脆弱性を発見しました。この脆弱性を悪用すると、誰でも簡単に航空会社の乗組員になりすまし、セキュリティチェックなしで機内に乗り込むことが可能になります。さらには、コックピットへの不正侵入もできてしまうのです。

    KCMシステムとは?

    KCM(Known Crewmember)システムは、航空会社の乗務員がスムーズに空港のセキュリティチェックを通過できるようにするためのシステムです。乗務員は、特別なバーコードやIDを提示することで、通常のセキュリティ検査を免除されることができます。

    脆弱性の発見

    イアン・キャロルとサム・カリーが注目したのは、KCMシステムを運営しているベンダーの一つであるFlyCASSという会社でした。FlyCASSのシステムには、SQLインジェクションという脆弱性が存在しており、この脆弱性を利用することで、誰でもシステムに不正にアクセスし、乗組員の情報を自由に書き換えたり、新しい乗組員を追加したりすることが可能になっていました。

    問題の深刻さ

    この脆弱性がもたらす影響は計り知れません。

    • セキュリティの崩壊: 航空機のセキュリティの根幹を揺るがすものであり、テロなどの悪質な行為に悪用される可能性も否定できません。
    • 乗客の安全への脅威: 不正に機内に乗り込んだ人物が、機内で暴れたり、機体を操作したりする可能性も考えられます。
    • 航空業界への信頼の失墜: このような重大なセキュリティ問題が発覚した場合、航空業界全体の信頼を失墜させ、人々の航空機に対する不安感を煽る可能性があります。

    開示とその後

    イアン・キャロルとサム・カリーは、この問題の深刻性を認識し、速やかに関係各機関に報告しました。しかし、残念ながら、問題の修正には時間がかかり、また、関係各機関からの対応も遅々として進まなかったという現状があります。

    対策

    この問題を解決するためには、以下の対策が急務です。

    • 脆弱性の迅速な修正: FlyCASSをはじめとする関連企業は、脆弱性を早急に修正し、システムの安全性を確保する必要があります。
    • セキュリティ意識の向上: 航空業界全体で、セキュリティに対する意識をより一層高め、定期的なセキュリティ監査を実施する必要があります。
    • 法整備の強化: 航空機のセキュリティに関する法整備を強化し、このような事態が再び起こらないようにする必要があります。

    まとめ

    今回の発見は、航空業界のセキュリティシステムを信頼しきってはいけないことを示すものであり、私たちに大きな警鐘を鳴らしています。私たちは、この問題をきっかけに、より安全な航空業界の実現に向けて、社会全体で取り組んでいく必要があるでしょう。

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

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

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

  • 2024年9月11日(水)14:00~14:30
    CVSSとSSVCで実践する次世代脆弱性管理:サイバー攻撃対策セミナー2024
  • 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
    【好評アンコール配信】
    システム開発のセキュリティ強化の鍵とは?
     -ソースコード診断で手戻りリスクとサイバー攻撃を未然に防ぐ-
  • 最新情報はこちら


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

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

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