
情報処理推進機構(IPA)は2026年10月21日、The PHP GroupがPHPにおける2つの脆弱性に対するセキュリティリリースを同日23時(日本時間)に公開予定であると発表したことを受け、事前準備を呼びかけている。
【10月21日23時に修正公開】PHPに深刻な脆弱性、IPAが事前準備を呼びかける|EnterpriseZine(エンタープライズジン)
プログラミング言語のPHPに「PHP2Shell」と呼ばれる重大な脆弱性が見つかり、緊急アップデートがリリースされました。「PHP2Shell」の2つの脆弱性は、セキュリティ企業のCalifとWizがそれぞれ独立して2026年8月に発見していたことが報告されています。
PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 - GIGAZINE
「PHP2Shell」はCVE-2026-109618、CVE-2026-109619の2つの脆弱性を指します。悪用されると攻撃者によってサーバーが乗っ取られ、機密データが盗み出されたり、サーバー上で稼働しているウェブサイトが改変されたりする可能性があるという重大な脆弱性で、PHPは日本時間の2026年10月21日深夜に緊急アップデートをリリースしました。
PHPが緊急アップデート「8.5.12」「8.4.27」「8.3.36」「8.2.35」をリリース - GIGAZINE
PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 - GIGAZINE
セキュリティ企業のCalifによると、OpenAIが2026年6月に発表したセキュリティイニシアチブ「Patch the Planet」の一環として、1つ目の脆弱性を2026年8月1日に発見し、8月11日にPHPに報告。さらに、8月21日に2つ目の脆弱性を発見しています。
PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 - GIGAZINE
Google傘下のAIプラットフォーム・Wizは、Califの動きとは独立して2026年8月19日に脆弱性を発見。24日に脆弱性をPHPに報告したとのこと。
PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 - GIGAZINE
Calif、WizはOpenAIのCodex Securityチーム、PHPのセキュリティチーム、Google Geminiチームと協力して、脆弱性の発見と対応の調整、パッチの検証を行いました。
PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 - GIGAZINE
その間、Google Cloud、Cloudflare、AWS、Microsoft、Automattic、Fastly、Akamai、Imperva、Vercel、およびその他の業界パートナーは、ただちにPHPを更新できない組織向けのガイダンスや検知手法、一時的な緩和策の準備を助けたとのことです。
PHPの重大脆弱性「PHP2Shell」はセキュリティ企業のCalifとWizがAIを用いて発見しOpenAIの枠組みを使って対策したことが判明 - GIGAZINE
プログラミング言語「PHP」開発プロジェクトは10月21日(協定世界時)、「緊急」レベルの脆弱性2件を修正したPHP 8.5.12/8.4.27/8.3.36/8.2.35を公開したと発表した。20日に予告していたセキュリティアップデートに関するもので、攻撃者が遠隔で任意のコードを実行できてしまう脆弱性などを修正する。「全てのPHPユーザーは、直ちにアップデートすることを強く推奨する」と公式サイトで案内している。
1つ目の脆弱性は、メモリ不足時の処理に起因するもの(CVE-2026-109618)で、リクエストの内部データの初期化中に処理が中断され、その後の終了処理が不完全なデータを正常なものとして扱う恐れがあるという。
2つ目は、リクエストが使っていたメモリを解放した後も、そのメモリを指す内部状態が残ってしまう問題(CVE-2026-109619)で、同じプロセス(ワーカー)によって処理される別のリクエストが、リセットされる前に残った内部状態を使用してしまう恐れがあるとしている。
対象は、PHP-FPM、Apacheのモジュール版(mod_php)、php-cgi、FrankenPHP、LiteSpeedなど。中でもmod_phpが最も危険としており、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃を引き起こせることが実証されているという。
Linuxディストリビューションや長期サポート(LTS)を提供するベンダーには事前にパッチを渡しており、各社の更新パッケージを確認するよう求めている。
更新対象外となっているPHP 8.1以前については、ベンダーに修正の有無を確認するか、サポート中のバージョンへ移行するよう呼び掛けている。その一方で、脆弱性の深刻さを踏まえ、7.4、8.0、8.1向けにも最小限の修正を施したソースコードを公開した。
なお、すぐに更新できない場合の対策として、メモリ使用量の上限をなくす設定や、ファイルのアップロード状況をセッションに記録する機能の無効化なども挙げている。ただし、いずれも特定の攻撃経路への露出を減らす措置で、「完全な緩和策はなく、アップデートが唯一の安全な選択肢」としている。
PHPの脆弱性を巡っては、国内企業が予防措置としての緊急メンテナンスを相次ぎ発表。保育園向けSaaSを運営するコドモンの他、BASE、Cygames、ニコニコ、pixiv、静岡銀行、阪急電鉄などが公式サイト/Webサービスを一時的に停止。さくらインターネットやXServer、GMOペパボなどのレンタルサーバ各社も緊急メンテナンスを実施している。なお、pixivなど一部ではサービスを再開している。
⇧ とりあえず、
『「完全な緩和策はなく、アップデートが唯一の安全な選択肢」』
⇧ 厄介極まりないよね...
単純に「プログラミング言語」の「PHP」の「バージョン」を上げられれば良いのだが、「バージョン」を上げることで稼働していた「システム」が動かなくなるケースもありそうですしな...
「今夜に対応して頂きたい大至急のお願い」――高市早苗首相は10月21日午後10時前、自身のXアカウントで、PHPの「緊急」の脆弱性について、修正パッチを「可及的速やかに適用できる準備」をするよう求めた。パッチはこの投稿の約1時間後(21日午後11時ごろ)に公開された。
高市総理「大至急、PHPパッチ適用を」Xで異例の要請 エンジニアは評価「経営層に伝わる」(1/2 ページ) - ITmedia NEWS
首相が個別のソフトウェア脆弱性について、Xで直接対応を呼び掛けるのは異例。エンジニアからは「総理が発信したことにより、経営層にもリスクが認知される」など一定の評価が出ている。
高市総理「大至急、PHPパッチ適用を」Xで異例の要請 エンジニアは評価「経営層に伝わる」(1/2 ページ) - ITmedia NEWS
高市氏はXで、修正パッチの速やかな適用が困難な場合について「例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つ」とも述べた。国家サイバー統括室も同様の内容をXで呼び掛けていた。
高市総理「大至急、PHPパッチ適用を」Xで異例の要請 エンジニアは評価「経営層に伝わる」(1/2 ページ) - ITmedia NEWS
脆弱性への対応では、システム停止による業務への影響が懸念され、パッチ適用が先送りされることもある。首相が一時停止もリスク低減策の一つとして示したことは、経営層が停止を判断する後押しになり得る。
高市総理「大至急、PHPパッチ適用を」Xで異例の要請 エンジニアは評価「経営層に伝わる」(1/2 ページ) - ITmedia NEWS
⇧ う~む...
「経営層」には「専門家」の「情報」を判断材料にして欲しいところではあるのですが...
App-to-Backend Attack(A2B攻撃)とLiving Off The Land(LOTL) Attacks
ネットの情報を漁っていたところ、
2026年10月13日、情報通信研究機構(NICT)は、国内で相次ぐ情報漏えい事案の原因の一つとして、「A2B攻撃(App-to-Backend Attack)」と呼ぶ攻撃手法を特定し、注意喚起を公表しました。
A2B攻撃とは、攻撃者が一般公開されているスマートフォンアプリを解析し、そのアプリが通信するバックエンドサーバーの情報を手掛かりに攻撃する手法です。
⇧ 上記サイト様で「App-to-Backend Attack(A2B攻撃)」について言及されていた。
Wikipediaによりますと、
App-to-Backend Attack(別名:A2B攻撃、エーツービーこうげき)は、一般に公開されているアプリケーションを解析し、その情報を悪用して接続先であるバックエンドサーバを攻撃する手法である。
攻撃者はスマートフォン向け基本ソフトであるAndroidなどの公開アプリを入手して解析し、通信するサーバの接続先や通信の仕組み(API)などを特定する。その後、得られた情報をもとにサーバの仕様に合わせた攻撃を実行する。2026年10月に情報通信研究機構(NICT)の脅威情報分析チームである「LETTICE」によって、国内で相次ぐ情報漏えい事案の原因の一つとして特定、命名された。
アプリ自体に脆弱性が存在しなくても、接続先のバックエンドサーバに不備があれば不正アクセスや個人情報の漏えいにつながるおそれがある。人工知能(AI)の悪用により解析が効率化され、より多くのシステムへ被害が拡大することが懸念されている。
⇧「ネイティブアプリ」を解析して「サーバーサイド」側との通信の構造をについての「情報」を取得、分析、悪用して、「サーバーサイド」側の「脆弱性」を突いた攻撃が行われるということらしい。
一応、「国立研究開発法人情報通信研究機構(NICT:National Institute of Information and Communications Technology)」が「対策」を発信しているらしく、
影響と対策
NICTは、この攻撃手法がAndroidアプリのみに限定されるものではないと警告している。iOSアプリやWebサービスのバックエンドAPIでも同様の手法によって被害を受ける可能性があり、それらを提供する事業者にも注意を呼びかけている。
さらに、AIを活用することでアプリの解析作業や脆弱性の発見プロセスが効率化されるため、攻撃が想定よりも多数のシステムに波及する危険性も指摘されている。
対策として、NICTはAndroidアプリを公開する事業者に向けて以下の3種の推奨対策を注意喚起として公表している。
- 侵害の確認
- 脆弱性の点検
- 暫定的な緩和策
あわせて、攻撃に関連する侵害指標の情報も提供している。
⇧ 上記の「対策」をすべきであると講じている。
なのだが、
近年のサイバー攻撃は、もはや「マルウェアを検知すれば止まる」ものではなくなっています。 正規ツール、正規アカウント、正規通信を悪用する Living off the Land(LoTL)型攻撃 が主流となり、EDR や MDR が前提としてきた検知モデルそのものが問い直されています。
EDRでは見えない攻撃に、なぜ「Hunt」が必要なのか ― Akamai Hunt チームが担う脅威ハンティングの実像 ―|Akamai
EDR や MDR は、非常に重要なセキュリティ対策です。
一方で、多くの場合、以下の前提に依存しています。
・マルウェアの実行
・既知の振る舞いやシグネチャ
・アラートを起点とした事後対応
LoTL 型攻撃では、これらの前提が成立しません。
EDRでは見えない攻撃に、なぜ「Hunt」が必要なのか ― Akamai Hunt チームが担う脅威ハンティングの実像 ―|Akamai
⇧ 上記サイト様によりますと、
- Living Off The Land(LOTL) Attacks
については、「正常」な処理が実施されるらしいので、「侵入」を検知できたとしても、攻撃されたかどうかを確認できないというケースが起こり得ると...
で、表題の件。
- App-to-Backend Attack(A2B攻撃)
- Living Off The Land(LOTL) Attacks
が組み合わさった場合、「攻撃」を特定するのが困難になりそうよね...
とりあえず、「Google Gemini」氏に質問してみたところ、以下のような回答が返って来た。
📌 セキュリティソリューション比較
※ App-to-Backend Attack(A2B攻撃)とLiving Off The Land(LOTL) Attacksに対する効果を指標としたソリューション
| No | ソリューション | 主な監視・制御範囲 | 関連・対象プロトコル | OSI参照モデル | TCP/IPモデル | A2B攻撃への効果 | LOTL攻撃への効果 | 補足・EDRとの関係 |
|---|---|---|---|---|---|---|---|---|
| 1 |
EDR(参考基準) |
エンドポイント(端末内)のプロセス、ファイル、レジストリ等 | OS内部システムコール、API(Win32/POSIX)、RPC、NetBIOS等 |
第5〜7層(セッション〜アプリ) |
アプリケーション層(※主にOS・プロセス内部) |
【低】端末上で完結しないAPIリクエストや、サーバー側(バックエンド)の不正を見通せない。 |
【低〜中】正規の管理ツール(PowerShell等)が使われるため「マルウェア」と判定できず、検知が難しい。 |
エンドポイントの基本防衛には不可欠だが、これ単体では高度な攻撃の全体像を捉えきれない。 |
| 2 |
MDR(運用サービス) |
EDR/XDR/NDR等のアラート、ログの24時間365日高度分析・対応 | (監視対象ツールに依存:HTTP/S、DNS、Syslog、NetFlow等) |
第1〜7層全域(統合・運用層) |
全階層(統合・運用層) |
【中〜高】アプリ・API関連のログや通信異常をSOCのアナリストが相関分析・調査。 |
【高】自動検知をすり抜ける「正規ツールの不審な使い方」を、専門アナリストが文脈・挙動から人間系で発見。 |
ツール(EDR/XDR)の限界を「人(SOC)の知見と分析」で補う運用ソリューション。 |
| 3 |
SASE(ZTNA / CASB / SWG) |
通信トラフィック全般、クラウド・SaaS接続、アクセスコントロール | HTTP/S、DNS、TLS/SSL、SAML、OIDC、QUIC等 |
第3〜7層(ネットワーク〜アプリ) |
インターネット〜アプリケーション層 |
【高】API・バックエンドへのアクセスをゼロトラスト(ZTNA)で厳格化し、不正なAPIコールや横展開を遮断。 |
【中〜高】正規ストレージ等を利用したC2通信やデータ持ち出しをクラウドゲートウェイで検知・遮断。 |
場所を問わず全通信を可視化。EDRが苦手なネットワーク層の防御を強固にする。 |
| 4 | XDR | エンドポイント、ネットワーク、クラウド、IDなどの統合データ | クロスレイヤー分析(HTTP/S、DNS、Kerberos、NetFlow、Syslog等) |
第3〜7層(統合分析) |
インターネット〜アプリケーション層 |
【中〜高】アプリ・APIの不審な挙動とバックエンド側のログを統合し、攻撃の一連の流れを検知。 |
【高】正規ツールの悪用を、IDやネットワーク挙動と横断的に紐づけることでコンテキスト(文脈)から検知。 |
EDRのデータを基盤にしつつ、他領域のログと組み合わせて高度な攻撃を発見する。 |
| 5 | NDR | ネットワークトラフィック(AI/機械学習による振る舞い分析) | TCP、UDP、IP、ICMP、DNS、HTTP/S、TLS(JA3/JA4等)、SMB等 |
第3〜7層(ネットワーク〜アプリ) |
インターネット〜アプリケーション層 |
【中】バックエンド通信における異常なリクエスト頻度や未定義プロトコルの利用を検知。 |
【高】端末上のプロセスが正規であっても、不審な通信先や異常なデータ転送量をネットワーク側でキャッチ。 |
エンドポイントにエージェントを入れられない機器も監視可能。EDRのネットワーク版。 |
| 6 |
CNAPP(CSPM / CWPP) |
クラウド環境、コンテナ、Kubernetes、マイクロサービス | HTTP/S、gRPC、Cloud Provider APIs、K8s API等 |
第5〜7層(セッション〜アプリ) |
アプリケーション層 |
【高】APIの脆弱性(BOLA等)やコンテナ・マイクロサービス間の不正通信を直接保護。 |
【低〜中】クラウド基盤やコンテナ内での設定不備・権限昇格などの悪用を検知。 |
クラウドネイティブなバックエンド環境そのものを守るのに最も適したソリューション。 |
| 7 | WAAP / API Security | Webアプリケーション、各種APIリクエスト・トラフィック | HTTP/1.1, HTTP/2, HTTP/3, REST, SOAP, GraphQL, WebSocket等 |
第7層(アプリケーション層) |
アプリケーション層 |
【特高】アプリとバックエンド間の通信を直接検査。不正なAPIパラメータ改ざん、Bot攻撃、BOLA等を高精度で検知・遮断。 |
【低】アプリ・API通信の保護に特化しているため、OS内部のLOTL攻撃には関与しない。 |
A2B攻撃に対して最も直接的に機能するアプリ・API層の防壁。 |
| 8 | ITDR | Identity基盤(Active Directory、Entra ID、Okta等)の脅威検知 | Kerberos、NTLM、LDAP/S、OAuth 2.0、SAML 2.0、OIDC等 |
第7層(アプリケーション層) |
アプリケーション層 |
【低〜中】不正な認証トークンやクレデンシャルを用いたバックエンドアクセスを保護。 |
【特高】LOTL攻撃の核心である「正規資格情報の悪用」「特権昇格」「Kerberoasting等のID攻撃」をID基盤側で検知。 |
IAM(設定・制御)の運用中に発生する「リアルタイムなID攻撃」を検知・即時レスポンス。 |
| 9 | SIEM + UEBA | 組織全体の各種ログ、ユーザー・デバイスの振る舞い分析 | ログ転送(Syslog、CEF、LEEF、HTTPS API、Event Log等) |
アナリティクス層(全層ログの抽象化) |
アナリティクス層(全層ログの抽象化) |
【中】API利用ログやID認証ログを集約・分析し、異常なアクセスパターンを特定。 |
【高】正規アカウントや標準ツールの「普段と異なる不審な挙動(アクセス時間・頻度等)」を検知。 |
過去のベースラインと比較するため、LOTLのような内部潜伏型攻撃の発見に強力。 |
| 10 | IAM / CIAM | アイデンティティ(認証・認可)、アクセス権限管理 | LDAP/S、RADIUS、SAML、OAuth 2.0、OIDC、FIDO2/WebAuthn等 |
第7層(アプリケーション層) |
アプリケーション層 |
【高】トークンの不正利用検知やリスクベース認証により、バックエンドAPIへの不正アクセスを防止。 |
【中】万が一端末が侵入されても、最小権限の原則(PoLP)により横展開や権限昇格を阻止。 |
ゼロトラストアーキテクチャの根幹となるID基盤。 |
| 11 | BAS / ASM | 攻撃表面(暴露資産)の可視化、疑似攻撃テストの自動化 | HTTP/S、SSH、RDP、DNS、BGP、SNMP等(各種スキャン/診断) | 第3〜7層全域 |
インターネット〜アプリケーション層 |
【中】バックエンドAPIの野良公開やテスト環境の放置(ASM)を発見・是正。 |
【中〜高】LOTL攻撃の手法(標準ツールの悪用シナリオ)が自社環境で成立するかを定期的に自動テスト(BAS)。 |
予防・評価観点からSOC/EDRのルール・検知漏れ(ブラインドスポット)を継続的に補強。 |
📌 保守・運用の負担とコストでの比較
| No | ソリューション | 保守・運用の負担 | コストの傾向 | 主な負担・コストの要因 |
|---|---|---|---|---|
| 1 | EDR | 中 | 中 | 端末ごとのエージェント管理と、日常的に発生するアラートのトリアージ(真偽判定)。 |
| 2 | MDR | 低 (自社視点) | 高 | 自社での運用・監視が不要になる反面、専門ベンダーへのサービス委託費用(人件費の置き換え)が高額。 |
| 3 | SASE | 中〜高 | 高 | ネットワーク経路の変更や、全社員のアクセス権・ポリシーの継続的な見直しが必要。 |
| 4 | XDR | 高 | 高 | 複数ドメイン(端・網・雲・ID)からの大量アラートを相関分析するための高度な専門知識が必要。 |
| 5 | NDR | 中 | 高 | ネットワーク機器・トラフィック容量に応じたライセンスコストと、パケット解析のチューニング。 |
| 6 | CNAPP | 中 | 中〜高 | クラウド開発スピードや構成変更(IaC)に合わせたクラウドインフラ・コードの継続的監査。 |
| 7 | WAAP / API Security | 中 | 中 | アプリやAPIの仕様変更・バージョンアップに伴う、WAFルールや例外処理のメンテ。 |
| 8 | ITDR | 中 | 中 | ID基盤(Active Directory等)の構造理解と、特権アカウントの振る舞い監視の維持。 |
| 9 | SIEM + UEBA | 特高 | 特高 | 【最大の運用負荷】 あらゆるログの収集・パース(構造化)・相関ルールの自社開発。データ量課金で費用が跳ね上がりやすい。 |
| 10 | IAM / CIAM | 中 | 中 | ユーザープロビジョニング、パスワードポリシー、多要素認証(MFA)の管理運用の継続。 |
| 11 | BAS / ASM | 低〜中 | 中 | 自動テストのスケジュール管理と、検出された露出資産・脆弱性の修正バックログの消化。 |
📌 用語
| No | 略語 | 正式名称 (英語) | 主な概要・役割 |
|---|---|---|---|
| 1 | EDR | Endpoint Detection and Response | PCやサーバーなど端末(エンドポイント)内の挙動を常時監視し、不審な動作の検知と迅速な対応・調査を行うツール。 |
| 2 | MDR | Managed Detection and Response | EDRやXDRなどのセキュリティツールの運用・監視を、専門のアナリスト(SOC)が24時間365日体制で代行するサービス。 |
| 3 | SASE | Secure Access Service Edge | ネットワーク機能(SD-WAN等)とセキュリティ機能(ZTNA, SWG, CASB等)をクラウド上で統合提供するフレームワーク/サービス。 |
| 4 | ZTNA | Zero Trust Network Access | 「誰も信用しない」原則に基づき、暗黙の信頼を与えず、アクセスごとにユーザーと端末を検証して必要最小限のアクセス権を与える仕組み。 |
| 5 | CASB | Cloud Access Security Broker | ユーザーとクラウドサービス(SaaS/PaaS)の間に位置し、クラウド利用状況の可視化やデータ保護、セキュリティポリシー適用を行う仕組み。 |
| 6 | SWG | Secure Web Gateway | Web通信の中継地点として、不審なWebサイトへの接続ブロックや悪意あるファイルのダウンロード防止を行うクラウド型プロキシ。 |
| 7 | FWaaS | Firewall as a Service | 従来のオンプレミス型ファイアウォール機能をクラウドサービスとして提供し、拠点を問わず統一されたアクセス制御を行う仕組み。 |
| 8 | XDR | Extended Detection and Response | EDRの監視対象をエンドポイントだけでなく、ネットワーク、クラウド、メール、IDなどに拡張・統合して横断分析するツール。 |
| 9 | NDR | Network Detection and Response | ネットワーク内の全トラフィックをAI/機械学習等でリアルタイム解析し、異常通信や脅威の兆候を検知・自動対処するツール。 |
| 10 | CNAPP | Cloud Native Application Protection Platform | クラウド基盤、コンテナ、Kubernetes、アプリケーション開発・実行環境全体を統合的に保護・管理するプラットフォーム。 |
| 11 | CSPM | Cloud Security Posture Management | AWSやAzureなどのクラウド基盤の設定ミスやコンプライアンス違反、セキュリティリスクを自動で診断・可視化する仕組み。 |
| 12 | CWPP | Cloud Workload Protection Platform | クラウド上の仮想マシン(VM)やコンテナ、サーバーレス環境などのワークロード(実行環境)そのものを保護するツール。 |
| 13 | WAAP | Web Application and API Protection | 従来のWAF(Webアプリケーションファイアウォール)に加え、API保護、DDoS対策、Bot対策などを統合したWeb・API防衛ツール。 |
| 14 | ITDR | Identity Threat Detection and Response | Active DirectoryやEntra IDなどのアイデンティティ(認証・認可)基盤に対する攻撃や資格情報の悪用をリアルタイムで検知・対処するツール。 |
| 15 | SIEM | Security Information and Event Management | 組織内のあらゆる機器やシステムのログを一元的に集約・蓄積し、相関分析によって潜在的な脅威を発見するログ分析プラットフォーム。 |
| 16 | UEBA | User and Entity Behavior Analytics | ユーザーやデバイス(機器)の「日常の行動パターン」を機械学習で学習し、そこから逸脱した不審な挙動(内部不正や乗っ取り)を検出する技術。 |
| 17 | IAM | Identity and Access Management | ユーザーのID(識別情報)とアクセス権限を適切に作成・管理・制御し、正規の利用者のみに必要なリソースへのアクセスを許可するシステム。 |
| 18 | CIAM | Customer Identity and Access Management | 顧客・一般ユーザー向けのID/アクセス管理システム。大量のユーザー処理、スムーズなログイン体験、強固な認証・セキュリティを両立する。 |
| 19 | BAS | Breach and Attack Simulation | 攻撃者の最新攻撃手法(LOTLや横展開など)を安全に自動シミュレーションし、自社の防衛メカニズムの検知漏れや脆弱性を検証するツール。 |
| 20 | ASM | Attack Surface Management | インターネット上に公開されている自社のIT資産(サーバー、IP、ドメイン、APIなど)を自動で探索・特定し、攻撃者から狙われやすい領域(攻撃表面)を管理する手法。 |
| 21 | BOLA | Broken Object Level Authorization | APIの脆弱性の一つ。オブジェクト識別子(IDなど)の検証不備により、他人のデータに不正アクセスできてしまう状態(OWASP API Top 10の最頻出リスク)。 |
| 22 | BFLA | Broken Function Level Authorization | APIの脆弱性の一つ。機能レベルでの権限チェック不備により、一般ユーザーが管理者向けAPIなどを不正に実行できてしまう状態。 |
| 23 | C2 | Command and Control (Server) | 悪意のあるソフトウェア(マルウェア)や侵入した攻撃者が、標的ネットワーク内の端末に遠隔指示を出したりデータを持ち出したりするために設置する指令サーバー。 |
⇧ いずれにしても、「セキュリティ」の「運用監視」の「環境構築」は「コスト」もかかりますし、継続的に「メンテナンス」していく「負担」もあり、「ランニングコスト」もかかりますわな...
ちなみに、
⇧「ゼロトラスト負債」なる「パワーワード」も話題になったとか...
毎度モヤモヤ感が半端ない…
今回はこのへんで。