BeyondTrust社Blog ”Least Privilege Application Management – A Lesson Learned from SolarWinds Orion” December 22, 2020 by Morey J. Haberより
SolarWindsのOrionへ侵入し、その後、数千に上るとみられる顧客データを流出させるのに利用された高度な国家規模の攻撃は、その範囲の広さと考えられる影響の度合いにおいて世間を震撼させました。
厳しい試練の年に、この攻撃は非常に強烈で屈辱的な反省を促すことになります――誰もがハッキングの被害者となりうるということです。誰もがです。どんなにセキュリティ管理やソフトウェア、プロセス、研修を積んだとしても、すべての攻撃を遮断することはできません。つねにリスクを減らすために努力することは可能ですし、そうすべきですが、リスクの目盛りがゼロになることは、決してありません。
自分たちが驚くべきデジタルインフラストラクチャを創造してきたことを、あらためて思い知らされたわけですが、もしこれが侵入を受け、実行時の情報や機密情報を盗まれれば、このパンデミックの中で徐々に慣れつつある、新しい形態の世界や経済、生活などに非常に大きな影響を与えかねないでしょう。攻撃側にとって、このようなデジタルインフラストラクチャは、詐取した機密情報、知的財産や保有資産を人質に取って脅迫状を送れば、また競合他社であれ国家であれ、敵対する者の将来の利益を奪えば、莫大な富を蓄積することができる格好の手段となりうるものです。
SolarWindsへの攻撃とアプリケーション権限について理解する
自社のソリューションがSolarWindsに対して行われた攻撃を完全に防げると、一点の曇りもなく自信をもって主張できるベンダーはいませんし、そんな主張に出合ったら、用心した方がいいでしょう。それはそれとして、企業や組織はこの種の攻撃経路を将来的に防ぐための戦略上の措置を講じることは可能です――旧式なインフラストラクチャ管理の根本的な問題のひとつを理解し、これに取り組めばの話ですが。この根本的なセキュリティ問題は、すべてのアプリケーションが、すべてに広くアクセスできる無制限の権限、すなわち特権アクセス管理の用語でいえば、グローバル（またはドメイン）で共有のadministrator（またはroot）アクセス権を持たねばならないということです。
グローバル共有の管理者アクセス権とは何でしょう？ それは、あるアカウントが、ある環境に対して無制限にアクセスできることを指します。これは通常、操作をスムースに行うためにセキュリティ上の例外として利用される手段です。そうしたアカウントはたとえば、アプリケーション管理ソフトウェアの中で許可リストに入り、アンチウィルスソフトウェアから除外されるため、ブロックされることも警戒のフラグが立つこともありません。アカウントはあるユーザやシステムそのもの、アプリケーションなどの名で、ある環境におけるあらゆる資産やリソースで操作が可能になります。この種のアクセスは多くのセキュリティ専門家から「神の特権」とあだ名され、膨大で軽減しようもないリスクを引き起こしてきました。
グローバル共有の管理者アクセス権は通常、旧式なアプリケーションによるオンプレミスのIT環境で監視や管理、もしくは自動化するために使用されています。この共有の管理者アカウントは、ネットワーク管理ソリューション、脆弱性管理ソリューション、資産検知ツール、携帯デバイス管理ソリューションなどなど、私たちがオンプレミスで、また自分たちのIT環境で動作しているのを目にする多くのツールに使われています。
真の問題は、こうしたグローバルな管理者アカウントはソリューションが正しく動作するのに必要であり、そのためにセキュリティ上のベストプラクティスである最小権限のアプリケーション管理という概念を用いることができないということです。アカウントの特権や許可が削除されてしまえば、アプリケーションはおそらくダウンしてしまうでしょう。だから動作の継続のため、全面的で規制のないアクセス権が認められているのですが、これが膨大な攻撃面を形成してしまうのです。
SolarWindsの場合に起きたのはまさにこれです。アプリケーションそのものが自動更新を介して侵入され、攻撃者がアプリケーションを使って被害者の環境全体に渡って無制限の特権アクセスを悪用したのです。攻撃者はSolarWindsを騙って実質的にどんなタスクも実行することができ、しかも監視や強化が施されている高度なベンダーセキュリティを持つシステムでは実行しないだけの注意も払っていました。これによって、私たちがもともと立てていた前提のひとつが明らかになりました。このマルウェアがセキュリティソリューションを迂回して侵入し、検出を回避することができる標的でのみ実行できるほど高度なものだとすれば、それはグローバル共有の管理者特権を使って行っているのだということです。単一のソリューションだけでは検出も攻撃の遮断もできるはずがありません。
当社は昨年出したブログでのサイバーセキュリティ年間予測で、2020年にはマルウェアの自動更新が急増するだろうと述べました。ですから、一般的な脅威はまだわからず、予測もできませんが、この特殊なSolarWindsへの攻撃の規模と破壊力は今後、長きに渡って反響を呼ぶことになるでしょう。
旧式なアプリケーションを巻き込んだ攻撃をいかに防ぎ、減らすか
大きな課題は、どうすれば今の環境を刷新して、危険を伴う過剰な特権を必要とするアプリケーションやアカウントに依存しなくてすむようにできるか、ということです。
まず、ネットワーク管理や脆弱性管理のソリューションといった、スキャン技術に基づくこうした旧式なアプリケーションの多くには問題がありません。単に、こうしたアプリケーションを実装するのに必要な技術とセキュリティモデルが時代遅れなのです。ここは変えなければなりません。
SolarWindsの侵入がサイバーセキュリティにおいてこれまで起きた中で最悪の事件だと考えるとすれば、それは正しいかもしれません。Sasser、Blaster、Big Yellow、Mirai、WannaCryといったマルウェアを憶えているサイバーセキュリティの専門家にとっては、システムへの影響は同等くらいでしょうが、SolarWindsへの攻撃では、攻撃者やペイロード（攻撃実行体）が果たした役割のせいで、これら、かつてのワームも取るに足らないもののように思えてしまうのです。
深刻な攻撃は過去数十年にも行われてきましたが、リソースが攻撃され、そのせいで標的や感染の程度、影響の大きさがいまだにわからないというような、これほどまでに高度なやり方でのケースは経験したことがありません。SasserやWannaCryに攻撃されればそれとわかります。ランサムウェアの場合でさえ、その影響を短期間で知ることができます。
SolarWindsの一件では、レーダーの範囲内にとどまることが攻撃者の第一目標でした。そして覚えておいていただきたいのは、今ある他の旧式なアプリケーションでも同じ根本的な問題が存在していることです。グローバル共有の管理者特権を持つ他の多くのアプリケーションは、数千もの企業に攻撃を仕掛けるために、私たちの環境で利用することが可能であり、その結果は悲惨なのです。残念ながら、これは補強できるような脆弱性ではありません――というより、むしろ攻撃はこうした特権を必要とするアプリケーションの中にある機能を使って行われるのです。
では、どこから手をつければいいのでしょうか。
まず、自分の環境にあるこうした過剰な特権を必要とするアプリケーションをすべて特定し、発見する必要があります。
- 企業規模向けの検知ツールを使い、複数のシステムで同じ特権アカウントを使用しているアプリケーションがどれかを判断します。認証情報が共有されている可能性が非常に高く、横方向への移動に悪用されることがあります。
- ドメイン管理者グループを調べ、今あるアプリケーションやサービスを把握します。ドメイン管理者特権を必要とするアプリケーションはどれも危険度が高いものです。
- ウィルス対策のグローバル除外リストにあるアプリケーションを見直します（特定のホストでの除外対象と比較するため）。こうしたことは、エンドポイントのセキュリティスタックで最初にすべき最も重要な措置――マルウェア阻止――のもとで行われるでしょう。
- 企業全体で使われているソフトウェアの一覧を見直し、アプリケーションが動作し、自動更新を実行するためにどの特権を必要としているか判断します。これによって、正しい動作のためにローカルの管理者特権が必要なのか、またはローカルの管理者アカウントが存在しているのかを見極めることができます。たとえば、アプリケーションの特権昇格のための偽装アカウントは、この目的のためだけにローカルのプロキシアカウントを持っていることもあるのです。
次に、――可能な場合はいつでも――最小権限のアプリケーション管理を実装する必要があります。この結果、過剰な特権はすべて削除されます。ただし先に述べたように、これが不可能な場合もあります。結局、グローバル共有特権アカウントの必要性をなくすためには、次のことが必要になるでしょう。
- アプリケーションの新しいバージョンのリューションへのアップグレード
- 新しいベンダーに問題を解決を依頼
- 負荷をクラウドか別のインフラストラクチャに委ねる
例として脆弱性管理をとりあげてみましょう。従来の脆弱性査定スキャナはグローバル共有特権アカウントを（時には複数）使って、リモートで対象に接続したり、脆弱性を識別するのに管理者アカウントとして認証したりします。ホストがメモリ窃取型のマルウェアに感染している場合、認証に使われるハッシュも盗まれ、横方向への移動に使われたり常駐する場所を確立するのに使われたりしてしまうのです。
脆弱性管理のベンダーはこの問題を認識していたので、スキャンのために永続的な管理者アカウントを保管する代わりに、Privileged Access Management (PAM) ソリューションを組みこみ、最新の特権アカウントを取得してスキャン作業を完了させています。PAMソリューションが使えない場合は、脆弱性管理のベンダーは認証されたスキャンのための単一の共有管理認証情報ではなく、APIを監査のために使えるローカルのエージェントとツールを開発することによっても、リスクを軽減してきました。
この例での私の見解は単純です。旧来の脆弱性管理技術も進歩しているので、今ではグローバルアプリケーションのアカウントとアクセスという大きな危険に顧客をさらすようなことはありません。残念ながら他の技術ベンダーの多くはソリューションを進歩させていないため、旧来のソリューションに代わるものが出てきたり最新のものに代わったりしない限り、脅威はなくなりません。
もし動作継続のためにグローバル共有管理者アカウントを必要とする製品を運用しているならば、2021年に向けて技術の見直しかアップグレードを行うことが急務です。すでに脅威を軽減することに成功しているベンダーから購入するか、将来的に導入を積極的に進めるようにした方がいいでしょう。
最後に、最小権限アプリケーション管理について考えてみましょう。特権アクセス管理ソリューションは、機密情報を保管し、アプリケーションが最小レベルの特権で機能できるように設計されているが、そもそもこれを内蔵するように設計されているわけではありません。
先の例に戻ると、脆弱性管理ソリューションはUnixとLinuxの特権管理技術を利用して脆弱性査定スキャンを実行することができますが、もともと特権アクセスを与えられているわけではないのです。特権アクセス管理ツールはスキャナという形でコマンドを実行し、結果を返します。スキャナのコマンドに対して最小の特権を推奨し、システムのシャットダウンなど不適切なことをスキャナが行おうとすると拒否するのです。ある意味では、こうしたプラットフォーム上の最小特権はsudoに近く、コマンドを呼び出すプロセスに拘わらず、特権を持つアプリケーションを制御したり規制したり実行したりすることができます。これは単に、過剰な特権が必要であり、ふさわしい代替案が現実的でない場合に、ある旧式なアプリケーションに適用することができる特権アクセス管理のひとつの方法に過ぎません。
2021年以降のサイバーリスクを軽減するには：次の主なステップ
どんな組織も攻撃者の標的になりえますし、過剰な特権を持つアプリケーションが全社的な打撃を与えることもありえます。SolarWindsへの侵入をきっかけに、私たちは皆、こうした過剰な特権アクセスのリスクを持つアプリケーションを見直し洗い出しておかねばなりません。ただちに脅威をなくすことができないとしても、どうすればそれを軽減できるか、判断する必要があるでしょう。
最終的に、リスクを軽減し、是正しようという努力の結果、アプリケーションを交換したりクラウドへ切り替えようという道に進んだりすることになるかもしれません。ひとつ確かなことは、特権アクセス管理の考え方は、人間が扱う場合と同じようにアプリケーションに当てはまるということです。アプリケーションを正しく管理しなければ、全社のセキュリティが壊滅します。したがって、環境全体に対する無制限のアクセス権をどんなものにも持たせるべきではありません。特定し、削除し、将来は避けることができるようにすべき脆弱な環はひとつだけなのです。
Morey J. Haber, BeyondTrust社 最高技術責任者 兼 最高情報セキュリティ責任者
Morey J. Haberは、BeyondTrustの最高技術責任者であり最高情報セキュリティ責任者でもあります。IT業界での経験は25年以上に渡り、Apress社から「Privileged Attack Vectors（第2版）」、「Asset Attack Vectors」、「Identity Attack Vectors」といった書籍を出版しています。2018年、BomgarがBeyondTrustを買収し、その名称を取得しました。彼はもともと2012年にeEye Digital Security の買収の一環としてBeyondTrustに加わりました。その前の2004年、セキュリティエンジニアリングの統括長としてeEyeに加わり、フォーチュン500掲載企業である顧客の戦略的業務に関する話し合いや脆弱性管理アーキテクチャを担当しました。eEyeに入る前は、Computer Associates, Inc. (CA)の開発マネージャーとして、新製品のベータサイクルや指定されたカスタマーアカウントなどの業務を担っていました。彼はまた、飛行訓練シミュレータの構築で政府の委託を受け、信頼性と保全性に関するエンジニアとしてのキャリアを築きました。ストーニーブルックにあるニューヨーク州立大学の電子エンジニアリング科で理学士の学位を取得しています。