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

Share

2025年10月14日、Windows10のサポートが終了します。これにより、マイクロソフトによるセキュリティ更新プログラムの配信と技術サポートが完全に停止されます。現在、多くの企業や個人ユーザーがWindows10を利用していますが、サポート終了を見据え、システムの移行やアップデート計画を早急に検討する必要が出てきています。

お問い合わせ

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

サポート終了後に直面するリスク

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

1. 脆弱性を突かれるリスク

サポート終了後に発見された脆弱性は、修正されないまま放置されることになります。攻撃者はこの未修正の脆弱性を悪用し、システムへの不正アクセスやデータの窃取を試みる可能性が高まります。特に企業のネットワーク環境では、1台の更新されていないPCが、システム全体にとっての弱点となりかねません。

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

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

3. ソフトウェアの互換性における課題

最新のアプリケーションやハードウェアは、サポートの終了したOSでの動作保証を行いません。Windows10のサポート終了後は、新しいソフトウェアやデバイスが正常に機能しなくなる可能性が高く、業務効率の低下が懸念されます。

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

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

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

計画的な移行の重要性

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

おわりに

Windows10のサポート終了は、企業・個人を問わず、重要な転換点となります。セキュリティリスクや業務効率の観点から、サポート終了後のソフトウェア使用は避けるべきでしょう。早期から移行計画を策定することで、潜在的なリスクを回避しつつ、最新技術を活用できる環境を整えます。この機会に、Windows11への移行について具体的な検討を始めてみてはいかがでしょうか。


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

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

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

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

  • 2025年1月22日(水)14:00~15:00
    ランサムウェア対策の要!ペネトレーションテストとは? -ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年1月29日(水)13:00~14:00
    サイバー攻撃から企業を守る!ソースコード診断が実現する“安全な開発”
  • 最新情報はこちら


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

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

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

    Share

    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接続や外部からのアクセスが多い環境では注意が必要です。

    セキュリティ機器の強化

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

    脆弱性管理の実施

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

    多要素認証の導入

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

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

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

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

    最後に

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


    Security Report 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コーポレートサイトへのリンクバナー画像

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

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

    Share

    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 DSS3は、上記カードブランド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の対象外となり、準拠の必要はありません。

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

    上記のような状態で、「非保持化しているつもり」になっていないかどうかに注意しましょう。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 Report TOPに戻る
    TOP-更新情報に戻る


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

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

    アプリ開発のセキュリティ対策
    ―シフトレフトでコスト削減と品質向上アプリ開発のセキュリティ対策―

    Share

    アプリ開発環境では各開発フェーズのセキュリティ確保が重要です。セキュリティを度外視した開発を行っていると、インシデント発生を招き、結果的に事業継続を脅かす恐れがあります。アプリ開発のセキュリティ対策で有効な、「シフトレフト」の考え方を実践されていますでしょうか? 本記事では、シフトレフトの考え方に基づいた、対策実施のポイントを解説します。

    アプリ開発におけるセキュリティリスク

    建物や乗り物、日用品や食品といった、身の回りの製品が安心して利用できるものでなければならないように、我々が日々利用している様々なアプリケーションもまた、安全なものでなければなりません。

    とにかく早くリリースすることのみを優先したり、労力を極限まで削ったりするなど、セキュリティを度外視したアプリケーション開発を行っていると、セキュリティインシデントが発生するのは時間の問題です。情報漏洩を起こしてしまった結果、ユーザや委託元企業への損害賠償、信用失墜による取引停止など、事業継続自体を脅かす危機に陥る恐れもあります。

    設計・開発フェーズにおける脆弱性対処

    とはいえ、アプリケーション開発におけるセキュリティについて、何がポイントなのか、どこから手を着けたらよいかわからない……ということもあるかもしれません。

    IPA発行「脆弱性対処に向けた製品開発者向けガイド」(2020年8月)には、「リソースに限りのある製品開発者が、脆弱性への対処についてどれから着手してよいか判断に迷う」といった困りごとに対応するためのヒントが記載されています。

    例えば、「設計・開発」フェーズにおける脆弱性対処として以下の項目が挙げられています。

    脆弱性対処の不備によるリスク

    では、開発工程において脆弱性対処が十分でないと、どのような影響があるか、確認してみましょう。

    構成要素に脆弱性があると…

    OS、アプリケーション、プログラム言語、またはライブラリ等の構成要素に既知の脆弱性が存在すると、これを悪用したサイバー攻撃を受ける可能性があります。日々、新しい脆弱性が報告されており、その情報が公開されています(下記例)。CVSSスコアの部分を見ると、深刻度の高い脆弱性も報告されていることがわかります。

    ▼オープンソースのプログラミング言語PHP関連で報告されている脆弱性の例

    オープンソースのプログラミング言語PHP関連で報告されている脆弱性の例の画像
    IPAのJVN iPedia 脆弱性対策情報データベース「PHP」検索結果より

    ▼JavaScriptライブラリjQuery関連で報告されている脆弱性の例

    JavaScriptライブラリjQuery関連で報告されている脆弱性の例の画像
    IPAのJVN iPedia 脆弱性対策情報データベース「jquery」検索結果より

    後から脆弱性が発覚した場合、その対処には多くのコストがかかります。開発にあたってはあらかじめ構成管理体制ができており、それが継続して可能な状態であることが重要です。

    セキュアコーディングでないと…

    開発担当者のスキルに依存することなく、セキュリティレベルが適切に保持されるよう、セキュアコーディング規約を策定して、これをもとに開発を行うことが重要です。

    脆弱性が作り込まれた状態で運用されていると、サイバー攻撃による情報漏洩・改ざんやシステム停止といった被害に遭う恐れがあります。実際に、国内でも次のようなインシデントが報告されています。

    年月 事例
    2022年 5月 フリマアプリより個人情報約275万件以上漏洩の可能性*3
    原因:SQLインジェクション
    2022年 6月 資格検定申込サイトよりメールアドレス29万件以上漏洩の可能性*2
    原因:SQLインジェクション
    2022年 12月 無線Wi-Fi製品問い合わせフォームに入力されたメールアドレス千件以上漏洩の可能性*3
    原因:SQLインジェクション
    2023年 4月 共同研究機関より研究参加者のメール5千件以上漏洩の可能性*4
    原因:SQLインジェクション

    デジタル庁発行「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」(2022年6月30日)によると、脆弱性を作り込まないようにセキュアコーディングを実施するにあたり、次のような対応が推奨されています。

    ● セキュリティ実装においては、担当者によるミスやばらつきの発生を防止することが重要であるため、セキュリティ関連のコーディングや設定は、テンプレートの使用や、自動化機能を用いて対応することが望ましい。

    ● アプリケーション開発は、安全で利便性の高い、セキュアコーディングをサポートするような機能を有した開発用ツールやフレームワークを活用することで、人為的なミスを抑え、セキュリティ確保することが有効である。

    開発環境のセキュリティが確保されていないと…

    工場に不審者の出入りが自由だったり、製造ラインが汚染されていたりすることで製品の安全性が脅かされるのと同様、アプリケーション開発においても開発環境のセキュリティ確保が重要です。

    開発環境に係るセキュリティインシデント例として、次のようなものがあります。

    [事例1]

    自動車メーカーの委託先企業がGitHubにソースコードを公開し、5年間近くアクセス可能な状態に。個人情報29万件以上漏洩の恐れ。

    開発環境に係るセキュリティインシデント[事例1]の画像

    [事例2]

    クラウド型CI/CDツール(ソフトウェア開発支援ツール)のCircleCIにおいて、ユーザが利用するGitHub等のサードパーティリポジトリサービスに不正アクセス発生。

    開発環境に係るセキュリティインシデント[事例2]の画像

    ソースコードリポジトリやCI/CDツールは今や効率的に開発を進めるのに欠かせないサービスである一方で、セキュリティ上の問題が発生すると、組織全体にその影響が及びかねないという側面もあります。サービス自体に潜む脆弱性やクラウド設定等、利用するサービスの特性を理解した上で十分注意を払う必要があります。

    シフトレフト導入による効果

    前述のIPA「脆弱性対処に向けた製品開発者向けガイド」では、「Ⅰ.方針・組織」「Ⅱ.設計・開発」「Ⅲ.出荷後の対応」の各段階におけるセキュリティ対策が解説されています。

    開発ライフサイクルのより早い段階で、セキュリティに対する考慮を組み入れるのが、「シフトレフト」と呼ばれる考え方です。リリースの直前など、開発サイクルの後工程で脆弱性が発覚すると、その対処には時間も労力もかかるでしょう。とはいえ、対処しないわけにもいきません。手戻りを未然に防ぐことで、結果的に全体の開発期間を短縮し、コスト効率と品質向上を図る効果が期待できます。

    シフトレフトは、もとはソフトウェア開発におけるプログラムの不具合(バグ)への対処において提唱されたものです。下記のような実態がみられるため、工程を前倒しにし(シフトレフト)、静的コードテストや単体テスト等を開発の前段階に組み込んでいくと、コスト削減効果がある、となったわけです。

    ソフトウェアのバグとその修正対応の関係

    ● バグの多くがコーディング段階で作り込まれる(青い線)

    ● テストが後になるとバグの発見も後になる(オレンジ色の線)

    ● バグの修正対応は後になればなるほどコストが増大する(赤い線)

    ソフトウェアのバグとその修正対応の関係の画像
    Capers Jones「 Applied Software Measurement: Global Analysis of Productivity and Quality
    https://www.stickyminds.com/article/shift-left-approach-software-testing

    では、バグへの対処をセキュリティ上の課題への対処に置き換えるとどうでしょうか。実際に、セキュリティにおいてシフトレフトを実践したGoogleが、トータルコストの減少効果があったと発表しています。*5下図で、シフトレフト導入前後で、セキュリティ上の欠陥に対処するコストを示している赤い線の状況が大きく異なることがわかります。

    ▼従来のセキュリティテストパターン

    従来のセキュリティテストパターンの画像
    https://cloud.google.com/blog/ja/products/identity-security/shift-left-on-google-cloud-security-invest-now-save-later

    ▼シフトレフト導入後のセキュリティの状況

    シフトレフト導入後のセキュリティの状況の画像
    https://cloud.google.com/blog/ja/products/identity-security/shift-left-on-google-cloud-security-invest-now-save-later

    セキュリティにおけるシフトレフトの実施内容

    アプリケーション開発において、より早い段階でセキュリティへの考慮を組み入れる、とはどういうことでしょう。具体的な実施内容は、こちらのようなイメージになります。

    セキュリティにおけるシフトレフトの実施内容の画像

    これを実現するためには、開発の企画・設計段階からセキュリティを考慮する「セキュリティ・バイ・デザイン」の概念に基づいて、開発チーム(Developer)とセキュリティチーム(Security)と運用チーム(Operations)が、互いに協力し合うことで品質向上を実現する、「DevSecOps」の体制を組んで臨むことが肝要です。

    実装工程におけるソースコード診断

    アプリケーション開発のセキュリティ対応の実施において、たびたび登場するのが脆弱性検査です。検査の種類はいくつかあります。

    ● ソースコード診断

    ● Webアプリケーション脆弱性診断

    ● ネットワーク脆弱性診断(プラットフォーム脆弱性診断)

    ● スマホアプリ脆弱性診断

    ● IoT脆弱性診断

    ● ペネトレーションテスト 等

    このうち、実装工程でソースコードに作り込んでしまった脆弱性を検出するのが、「ソースコード診断」です。他の種類の脆弱性診断では検出しづらい潜在的な脆弱性を、開発ライフサイクルのより早い工程で洗い出すことが目的です。他の脆弱性診断に先駆けて実施されるべき診断と言えます。

    セキュアコーディングを実践しつつ、ソースコード診断を効率的に行うためには、自動診断ツールを利用するのも有効です。静的コード解析を行うソースコード診断ツールの選定においては、以下のような点がポイントとなるでしょう。

    BBSecでは

    BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

    ソースコード自動診断

    システムの開発段階から対策を行うことで、リリース直前での手戻りを防ぎませんか?BBSecのCracker Probing-Eyes® Coreはソースコードに潜む脆弱性を具体的に特定することで、根本的な問題解決ができます。安価でできるツール診断により、スケジュールに余裕 のない場合でもお気軽に、短時間で安全性の確認ができます。また新規設備投資も不要のため、コストや労力の削減にもつながります。

    ソースコード自動診断のサムネ

    Cracker Probing-Eyes Core® キャンペーン近日開始予定!
    詳細につきましては、お問い合わせフォームからお問い合わせをお願いいたします。
    お問い合わせはこちら

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

    ・2023年9月27日(木)14:00~15:00
    知っておきたいIPA『情報セキュリティ10大脅威 2023』
    ~セキュリティ診断による予防的コントロール~

    最新情報はこちら

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


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

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