話題になっているCVE-2022-22536は半年前の脆弱性
CVE-2022-22536はCVSSv3の10を記録したSAP ICM(Internet Communication Manager)でHTTP Request Smugglingが可能な脆弱性ですが、SAPで発表されたのは今年の2月です。SAPの特性上、扱えるエンジニアが限定的で外注が大半であることが想像されます。これ程危険度があったとしてもアップデートが行われていないサービスが多くあることが予想されるため、実被害事例が観測されたことを機に危険性を啓蒙し更新を促す意味でも話題にしたのではと深読みしてしまいます。
CVE-2022-22536のテクニカルな話に戻します。この脆弱性はフロントエンドサーバとバックエンドサーバでリクエストの終端の解釈の違いを悪用し被害者になりすます機能を実行したり、中間 Web キャッシュを汚染したりする攻撃により被害をもたらします。従って脆弱性の性質上、HTTPSから直でSAP アプリサーバの場合は該当しません。SAP Web DispatcherまたはHTTPゲートウェイが間にいる時に該当のバージョンで脆弱になります。もちろんPoCは存在するのですが専用のスキャナーがOnapsisより提供されているので脆弱かどうかの確認はスキャナーの方を利用すると良いでしょう。
アクションを起こせるかは体系化した情報管理と組織との役割分担の合意形成次第
さて皆さんの組織では今ある手元の情報だけでこの脆弱性が組織にとって危険なのか否かジャッジできる状態にあるでしょうか。
現在SBOMが注目を集めていますが、これはソフトウェア部品表であって、今回の様な脆弱性はアーキテクチャとマッピングできて初めて素早いジャッジが可能になります。
このように脆弱性情報に対し組織のインテリジェンスとして機能させるには明確な役割と管理目標に責任を持った地盤を作った上で部品管理とアーキテクチャの脅威モデリングが連動する様な体系的なリスクマネジメントが必要となります。
米国サイバーセキュリティ法の下作成された「医療機器におけるサイバーセキュリティ: 品質システムの考慮事項と市販前申請の内容 – 業界および食品医薬品局スタッフ向けガイダンス草案」に記載されたSPDF（セキュア製品開発フレームワーク）が参考になります。(五章のUsing an SPDF to Manage Cybersecurity Risksの部分です)
セキュリティリスクマネジメント
1．脅威モデリング
2．サードパーティー製ソフトウェアコンポーネント
3．未解決の異常のセキュリティ評価
4．セキュリティリスクマネジメントの文書
5．TPLC セキュリティリスク管理(Total Product Life Cycle)
モデルは他にもたくさんありますが、ポイントはソフトウェアの部品、構成、設定が合意済みの優先づけの基準と管理フローに則って初めてインテリジェンスとして機能するということです。ソフトウェアバージョン情報の連携や設定や構成のベストプラクティスを個々に取得することは最終的にインテリジェンスとして活用する明確な目標に基づいていなければ例外管理の複雑化や判断の依存によりいずれ破綻することになります。組織に個別情報に対する例外判断を対応するのではなく、体系的な定常運用判断と異常時のエスカレーションとしての運用管理を浸透させ個別事象への依存性を排し常に現時点の例外と将来的な動向に対応できる組織体制とその理解の醸成に努める必要性があります。
そしてもう一つ忘れてはならないのはリスクマネジメントをより高い組織目標を支援する手段として組織に理解される様に啓蒙し、組織の活動・プロダクトマネジメントと親和性を保つように努めることです。そうすることで互いのやりたいことの押し付けではなく両者がやるべきことを一緒に目指す状態が実現されます。さて、手元の情報だけで脆弱性が組織にとって危険なのかジャッジできる状態目指す上で必要な状態や要素は理解できたと思います。次に難しい観点として組織と合意形成する基準づくりだと思います。具体例を元に考えてみましょう。
話題になっている・流行っているからと言って危険な脆弱性とは限らない
8月17日を境に猛烈に話題になっている脆弱性CVE-2022-38392が恐ろしく話題になっているのがグラフから判ります。
さぞかし危険な世界的な影響がある危険な脆弱性と思いきや中身は「ジャネット・ジャクソンのMVでPCがクラッシュする脆弱性」です。
脆弱性の話題性は必ずしも危険性に依存せず多数の要因で複雑に形成されることを理解する必要があります。
しかし、逆に危険だと判っている脆弱性が話題になることは、攻撃される可能性が上がる一つの兆候と考えることができます。
段階を追って説明すると、まず皮肉にも話題になったことでビジネスとしてのサイバー攻撃が成り立つようになり、攻撃ツールを作る予算の目処が着く様になります。
次に防御する側のサービスも商売にするため話題になった脆弱性をより話題になるように盛り上げる情報発信活動を行なうようになります。
こうして一般化した攻撃がまだ対策されていないサイトを無作為に探すようになり、ばら撒かれた攻撃通信に被弾してしまう可能性が出てくるという流れです。
つまり話題性は今後の被害拡大性を考える上で付加的な要素とはなりますが基準にはなりません。
PoCが知れ渡ればIOCも知れ渡る。脆弱性としては時間が経つほど危険と考えるのは必ずしも正しくない
純粋に脆弱性が危険なのは攻撃者は手段を確立していて守る側手段が確立していない場合です。時間が経つほど対策事例の知見が溜まっているはずなので必要なパッチを当てないのは組織の不手際でリスクを増しているに過ぎません。
なぜそもそもパッチを当てるのか？「攻撃されないため」が答えではないでしょうか。攻撃されるかの観点で見直すのとTenable社の発表やパッチを当てるべき脆弱性は発見されるCVEの3％ほどと言われており同社ではその観点で見直したVulnerability Priority Rating(VPR)という評価基準を提供しています。
対応すべき脆弱性が絞れ優先度が明確になるのは嬉しいがベンダー依存である点がネックになると想像されます。そんな時にはFIRST.orgが管理するオープンなソフトウェアの脆弱性を悪用して侵害される可能性を数値化したExploit Prediction Scoring System (EPSS) という基準を採用する方法が一手です。（Exploit Prediction Scoring System (EPSS)MissionのUsage Agreementからも利用可能であることが確認できると思います）全CVEに対してスコアリングされAPIも提供されています。
CISAの攻撃があった脆弱性のリストやExploit-DBで実際にPoCをさしてみる方法もありかも知れません。重要なのは提案した基準が組織に納得感をもたらし受け入れ自身の組織の文化として取り込んでもらう事です。先のVPRも元々PCI DSS準拠でnessus回していた様な企業では親和性高いでしょうし、ペネトレーションテスターに信頼が厚ければ直接指して確かめるクローラーを開発しその結果を基準にしても良いでしょう。
ここまで手元にある情報で外からの脆弱性ニュースが組織にとって危険か判断するためにどんな状態に組織をすべきか。目指すためのポイントについて述べさせていただきました。
不安定な世の中のニュースに一喜一憂せず、涼しい顔で専門的な判断を下し組織をより高い目標へと目指させるそんなセキュリティ組織を世に作っていくこと、一緒に目指していければと思います。
以上です。参考になれば幸いです。