ChatGPTを使ったAWS Security Hubのトリアージオペレーターの作成

GPT4がリリースされてLLM界隈の盛り上がりがすごいですね。
LLMの何がすごいって私個人の考えとしては、これまで人間が行なってきた判断という領域を簡単にシステム化できるようになったのがすごいと思っています。
さらに言えば、LLMは24/365で何並列でも判断を行なって、それで疲れて判断がブレるということもなく判断し続けることができます。

つまり、アラートやインシデントのトリアージに向いている訳ですね！！！

個人的にこのトリアージという行為は、ひたすらシステムが上げてきた問題を知性溢れる人間がシステムの一部となって処理し続けなければならないという、非人間的な扱いを受ける辛い業務です。
そのくせ判断を支える一定の知識は必要であり、対象システムの変化に追従できる速度で知識の更新が必要というのでなかなかシステム化しにくい領域でした。

という訳でまだ必要な知識の少なさそうなSecurityHubを題材にトリアージオペレーターを考えてみたいと思います。

プロンプト

今回は簡単にインシデントを抑制するか、開発者に通知を行うかという例で考えます。
フローによってはインシデントのプライオリティを再考させる、自動修復するなどいろいろやりようはあるので、その辺りはフローに合わせて読み替えてください。

あなたはAWS SecurityHubで発生したインシデントのトリアージを行います。
あなたには下記に列挙したアクションが提供されます。

開発者へ通知
抑制

開発者へ通知は抑制、解決するルールがない、または判断ができないときに選択します。
抑制は抑制ルールに記載の内容と一致する、または対応が不要だと考えるときに選択します。


トリアージのさいにあなたは下記の形式で回答しなければなりません。

一致した抑制対象: [抑制ルールにの対象、または一致しなければ なし と記載すること]
一致した抑制理由: [抑制ルールの理由、または一致しなければ なし と記載すること]
理由: [あなたが入力された情報、一致した抑制対象、一致した抑制理由から論理的にどのアクションを選択したのかという理由]
アクション: [あなたが選択したアクション]

もし限定的に抑制するに一致した場合、根拠を提示してください。根拠を提示できない場合は開発者へ通知を選択するようにタスクをやり直してください。


抑制ルールは下記に列挙したものになります

{rule}


それでは、下記の入力に対してタスクを実行してください。

{input}

{rule}には下記のような形式で埋め込みを行います。

対象: Config.1
理由: 常に抑制を行う。AWS Configのベストプラクティスに則ると、1つのリージョンでグローバルリソースに対する設定があり、他のリージョンではグローバルリソースに対する設定がない状態にしなければならないため。仮に抑制して問題が起きるならCloudformation StackSetsなどを使いOrganizationレベルで強制すべき内容になる。

対象: AutoScaling.6
理由: 条件付きで抑制を行う。例えばEKSなどではAZ単位にAuto Scalingグループを作っている。これはcluster-autoscalerがASG単位に作らないとaffinityでazを指定しても制御ができないためになる。こういったAZ単位にASGを作らなければならないケースでは抑制することを許可する。

{input}にはSecurityHub -> EventBridgeで受け取ったJSONで置き換えます。
精度問題との兼ね合いでもし余分な情報があることが問題になるなら一部だけを埋め込むというようなことをすると良さそうです。

タスクの概要の指定

あなたはAWS SecurityHubで発生したインシデントのトリアージを行います。

まず、初めに実行するタスクの概要を指定します。
この1文がどれだけタスク実行能力に影響を与えるのかはわかりませんが、ある意味おまじないですね。

アクションの定義

あなたには下記に列挙したアクションが提供されます。

開発者へ通知
抑制

開発者へ通知は抑制、解決するルールがない、または判断ができないときに選択します。
抑制は抑制ルールに記載の内容と一致する、または対応が不要だと考えるときに選択します。

トリアージしてどういったアクションをどういった条件のときに行うのかを定義します。

今回は簡単に精度を出して、簡単に組めるようにというので固定的な2つのアクションを定義していますが、原理的にはここは動的なアクションにすることも可能だとは思っています。
例えば「入力を解決するために必要なアクションを列挙してください。アクションには必ず開発者への通知を含めてください」みたいな形ですね。
このアクションからコードを生成して、そのコードを実行するフローを構築することで動的なアクションを実現することができます。

余談ですが、ChatGPTをシステムに組み込むさいには精度問題がつきまとうため、新人を入れるときのように判断できない場合にはエスカレーションするフローは必須かなとは思っています。

回答フォーマットの設定

トリアージのさいにあなたは下記の形式で回答しなければなりません。

一致した抑制対象: [抑制ルールにの対象、または一致しなければ なし と記載すること]
一致した抑制理由: [抑制ルールの理由、または一致しなければ なし と記載すること]
理由: [あなたが入力された情報、一致した抑制対象、一致した抑制理由から論理的にどのアクションを選択したのかという理由]
アクション: [あなたが選択したアクション]

もし条件付きで抑制するに一致した場合、根拠を提示してください。根拠を提示できない場合は開発者へ通知を選択するようにタスクをやり直してください。

ここは今回のプロンプトの中核です。
どのルールに一致したか、そのルールで抑制理由をどのように定義しているかを先に書くことでステップバイステップな回答になり、後続の理由やアクションの精度が高まります。

また、理由をアクションの前に書くのもアクションの決定精度を高めるための手法になります。
この理由自体は精度以外にもデバッグ目的というのもあり、LLM実行後にチャットへの通知やチケットの記載をするさいに妥当な理由で行われているか、アクションが想定したものと違うさいにどういった理由で選んだのか考えるためにも使うことができます。
地味にこの理由を言わせるのは他でも使えそうな手法です。

ルールの定義

抑制ルールは下記に列挙したものになります

{rule}

こういう条件のときはこうするといった自然言語でのルールを列挙します。

先に書いたような対象、理由を列挙した抑制ルールを記載します。
ここでは全てのルールを記載しても構いませんが、対象: AutoScaling.6といった固定的なキーが存在するためKVSやファイルでルールを保管して取り込むでも構わないと思います。

原理的にはここで抑制ルールの例として列挙して、その例の考え方に合わせてトリアージしてくださいとすれば今後AWSがアップデートして新しいルールにも追従できると思います。
ただし、ある意味こういったフローはシステムに寄るところが大きく、おそらくルールの提示の仕方は変えないとまともな精度が出ないような気はしています。
おそらく一般的なセキュリティの判断思考を明示してルール化して、それに対象のシステムの情報を含ませるとかすると上手く行くのではと思わなくもないですが、相当頑張らないと難しそうだなとは思っています。

ChatGPTでの実行例

EKS用のASGとそうではないASGで上手く判断ができていますね。
ちょっとまだ机上段階でどのくらいの成功率を出せるのかまでは見えていませんが、ある程度は自然言語で管理したルールベースにトリアージを行うことができそうです。

ルール管理のシステム化

この方式でのトリアージの場合は、おそらくプロンプトの変更よりもルールの追加や更新を多く行っていくことになります。
一例にはなりますが、下記のような仕組みを作ると運用しやすい状況になるのではと考えています。

1. ChatGPTの実行結果をチャットに流す
2. そのチャットメッセージに対して返信する形でルールを追加
3. そのルールを永続化して、タスクを再実行
   a. 以降はその永続化したルールを読み込んでタスクを実行していく

とすることで、Human Reviewを行い是正しつつ以後は新しいルールに従うということで、手軽にLLMの挙動を変えながら運用を進めていくことができると思います。
ただし、セキュリティ領域というので妥当な理由なく抑制するのは良くない行為のため、追加のさいにその理由は抑制理由として妥当なものなのか、といったチェックをLLMでやらせるとより便利かもしれませんね。

また、他にもChatOps的にルールの一覧や特定ルールの取得、ルールの削除などもできるようにするとより便利に扱えるかと思います。

この辺りの話を踏まえて、ふんわりと考えている話ですが、ChatGPTのフロー組み込みにはいくつか観点があると思います。

• ChatGPTは失敗することを前提に組む
  • 間違った判断をしたときに人間が是正するフローを用意する
• ChatGPTの動作はログを出して追跡可能にする
• プロンプト内で固定的な内容と動的な内容を分ける
  • 今回で言えば指示は固定、判断基準になるルールやインシデントの内容が動的
  • さらに言えばインシデントはシステムが発行するものになるため、人間が運用上で管理しないといけないのはルールだけになる
• 動的な内容を変更しやすいフローを用意する

このあたりはもう少し実運用でどうなるかを踏まえてベストプラクティスを作っていきたいですね。

より精度を上げるための手法

おそらく、これだけでもある程度の成功率を出せるとは思っているのですが、下記のようなことをするとより精度を出せると思います

• 対象リソースの情報を含める
  • 精度を求めるならリソースの種類に合わせて全パターンの取得コマンドを作って実行する
  • 精度が下がってもいいならAWS CLIなどのドキュメントをベクトル化したものと組み合わせて取得コマンドをChatGPTで作って実行する
• システムの構成情報を含める
  • どう言語化するかは悩ましいが、システム上そのセキュリティ問題は発生しえないケースはある（e.g. sshdの入ってないコンテナでSGで22を開けても無害など）
  • 例えばTerraformやKubernetes Manifestをそういった情報を作れそうだが未定
• 過去の対応履歴を含める
  • 開発者への通知を行ったもので、開発者がそれに対しどのようなアクションを取ったかを記録し、LLMに埋め込めるようにすることで、開発者が取ったアクションに合わせて判断を行えるようにできるかもしれない
  • 例えば、過去のN件発生したがインシデントは対応されないため抑制しても構わないなどの判断ができるかもしれない
• 対話フローを構築する
  • もし、かなり高い精度が必要になる場合、判断材料があるのかを判断させ、なければ分かる人に聞くというのも手
  • ただし、フローとしては複雑化し、人間が強くフローに絡むので、確実に精度の高いものが必須なケース以外では採用しない方が良さそう

この列挙した内容を見てわかる通り、精度を上げるために必要なものというのは私たち人間がこれまでトリアージを行なってきたときに判断の材料として何を見て判断したのかというものと同じものになります。
ここを洗い出すために一度、私たち人間はどういったフローで、何を見て判断しているのか、というのを暗黙値から形式知にする作業をしていくと楽しそうですね。

おわりに

https://twitter.com/k_kinzal/status/1637284923601227778

というわけでみんなもっとシステム運用を楽にしようよ！！！というお気持ちを込めて書いてみました。
本丸はアラート対応のトリアージだとは思っていて、こちらはモニタリングの情報をどうテキスト化するかなどさらに難易度が高くはなるのですが、もしこれができればアラート疲れなんて言葉がこの世からなくすことができます。
もっと言えば、障害発生時に人間が何かすることはなくなり、ChatGPTが提案した修復アクションを確認して実行するだけという世界になり、より精度が出るようになればもう人間がやることはなくなるところまで辿りつけるかもしれません。

私たち知性溢れる人間はシステムの奴隷ではないので、早くこの世界に辿り着くという意味でも、みなさんシステム運用のChatGPT対応についてより掘り下げてみませんか。