特権アクセス管理(Privileged Access Management、PAM)の重要性
Oktaのデータ漏洩は防げたのか?
先月、Oktaはサードパーティーサポートベンダーの1社がハッキンググループLapsus$の攻撃を受け、数百人もの顧客データが漏洩した可能性があることを公表しました。[1]このインシデントは、被害組織がアイデンティティおよびアクセス管理(IAM)における業界のリーダーであることから、特に注目されました。
この攻撃は、脅威者がローカルシステムを侵害し、特権を昇格させ、環境内を移動するという、よくあるパターンで行われた可能性があることが、その後の報告で明らかになりました。侵入後、攻撃者は最初の偵察を行って、企業のセキュリティ体制を調べます。Oktaベンダーの調査によると、Lapsus$ハッカーグループは、侵入したシステムにFireEyeエンドポイント保護エージェントがインストールされていることを突き止め、そのエージェントを終了させることで保護をバイパスすることができたとされています。(以前にもこのようなケースはありました。) 攻撃者はその後、攻撃を阻止するものが何もないため、エンドポイントエージェントによってブロックされるはずの、有名な認証情報ダンプユーティリティであるMimikatzの公式版をダウンロードしたと言われています。[2]
この種のインシデントを防ぐ方法について、専門家の提言は、インシデントへの備えや事業継続能力の評価、ログ管理の改善、パスワードの頻繁なリセット、コミュニケーションと情報共有の改善など、さまざまです。しかし、もっと具体的には、どうすればこの侵害を未然に阻止することができたのでしょうか。
まず、FireEyeのエンドポイントエージェントを停止させる機能から見ていきましょう。もし、きめ細かなアクセス制御を実施していれば、攻撃者がFireEyeエージェントを停止させることを防げた可能性があります。(なお、Symantec Endpoint Security製品は、このような改ざんを確実に防止して警告する独自の技術を採用しています。)
Symantec PAM Server Controlの紹介
Symantec PAM(Broadcom Software提供)ではセキュリティの侵害を防止するのに不可欠な機密性の高い管理者クレデンシャルの保護、特権ユーザーアクセスの制御、セキュリティポリシーのプロアクティブな適用、仮想、クラウド、物理のすべての環境にわたる特権ユーザーの活動の監視と記録などの機能が提供されます。Symantec PAMの中核機能の1つは、サーバーコントロールエージェントを使用して、Windowsをはじめとするサーバー上でオペレーティングシステムレベルのアクセスと特権ユーザーの操作をきめ細かく保護してセキュリティ侵害から保護する機能です。

Symantec PAM Server Control(PAMSC)エージェントは、一元管理されたタスク委任とプラットフォーム固有のソフトウェア制限を使用して、ファイル、ディレクトリ、リソース固有のカーネルレベルの制御、レジストリ保護、その他のローカライズされた詳細な制御を実行し、重要なサーバーにホストされている高価値資産とリソースが悪意ある、あるいは偶発的な内部関係者の操作によって生じる被害から確実に保護します。
Server ControlエージェントがOktaのような侵害に対処する方法
Oktaのインシデントでは、攻撃者がローカルシステム上でエンドポイント保護を提供するFireEyeエージェントを終了させることができたとされています。この行為は、Symantec PAM Server Controlを使用することで抑止できた可能性があります。Server Controlを使用すると、重要なシステムデーモン、FireEyeなどのアプリケーションプロセスは、システム内の権限レベルに関係なく、許可されたユーザーのみがシャットダウン(強制終了)できます。つまり、システム管理者であれば、管理者アカウントを持っているからといってエージェントを強制終了することはできません。
PAM Server Controlの「プロセスクラス」機能を使用すると、独自のアドレス空間で実行されている実行可能プログラムを強制終了から保護できます。PROCESSレコードを定義することで、重要なデーモンやアプリケーションをDoS攻撃から保護することができます。PAM SCは、次のkillシグナルを傍受し、認証します。
■ sigterm - term 15 (共通のkillシグナル。)
■ sigkill - kill 9
■ sigstop - stop (機種依存)
sighup、sigurs 1などの他のシグナルは、対象となるプロセスに渡され、そのプロセスでkillシグナルを無視するか、何らかの方法で応答するかを決定します。
PROCESSクラスレコードで許可されるアクセスタイプを次に示します。
READ R UNIXに渡すkillシグナルを許可
NONE N 傍受したkillシグナルをブロック
例
1 newres PROCESS /usr/sbin/syslogd owner(nobody) defacc(N) \
audit(ALL)
この例では、syslogdというプロセスを不正なkillコマンドから保護するプロセスレコードを定義しています。プロセスを強制終了しようとする試みは、許可されたものも許可されていないものも含めてすべて監査されます。
Server Controlの使用を抑止する方法
sigterm、sigstop、sigkillシグナルによる強制終了から保護されるPROCESSクラスをServer Controlに定義します。
例
1 [管理者]ウィンドウの[SELANG]で、リソースをPROCESSクラスに定義します。
PAMSC> newres PROCESS /usr/sbin/syslogd defacc(none) owner(nobody)
プログラムはプロセスクラスで定義されています。
2 rootウィンドウで、SEPMDADMユーティリティのプロセス識別子番号(PID)を探します。
# ps -ef | grep /usr/sbin/syslogd | grep -v grep
ユーティリティのプロセス識別子が表示されます。ユーザーIDに続く最初の数字がプロセスID、つまりPIDです。
3 root ウィンドウで、TERMシグナルを使用してプロセスを強制終了し、Traceウィンドウを確認します。
# kill pid
パーミッションが拒否されました。
4 rootウィンドウで、KILL (-9)シグナルを使用してプロセスを強制終了します。手順2のPIDをkillコマンドで渡すパラメータとして使用し、Traceウィンドウを監視します。
# kill -9pid
パーミッションが拒否されました。
5 Auditorウィンドウで、監査ログを確認します。PROCESSデータベースレコードに対する拒否の監査記録が表示されるはずです。
$ /usr/seos/bin/seaudit -a -sd today | tail
まとめ
Symantec PAM Server Controlの細分化ルールにより、昇格権限を持つ内部関係者がプロセスを停止するのを防止できます。特定のプログラムをサービス拒否攻撃、悪意あるユーザーからのプログラムの強制終了から確実に保護するには、sigtermシグナル、sigstopシグナル、およびsigkillシグナルで強制終了されないように保護するPROCESSクラスをServer Controlに定義します。
お客様のPAMソリューションに関するBroadcom Softwareによる支援の詳細については、こちらにお問い合わせください。
[1] https://www.acaglobal.com/insights/update-okta-announces-366-customers-impacted-lapsus-breach
[2] https://www.itpro.co.uk/security/cyber-security/367236/leaked-mandiant-report-okta-breach-lapsus-operation

2022年の保護の強化につながる4つの数字
最も困難な課題の解決をシマンテックが支援

We encourage you to share your thoughts on your favorite social platform.