攻撃やインシデントはなくならない　“Communication”“Continuous”でセキュリティ力を強くする

新設セキュリティ対策チームの課題

伊藤洋也氏：私からは「エンジニアリングでCommunicationを回す」というタイトルで発表します。

名前は伊藤洋也と申します。2007年からGMOペパボ株式会社に勤めていて、2021年の春で14年目になります。ホスティングサービスでの開発経験が長くて、サーバーサイドのAPIの実装やLinuxの低いレイヤーでのトラブルシューティングを得意としています。私生活では2020年の秋に栃木県の那須塩原市に移住して、リモートワークをしています。

まずチーム発足の話と私個人のキャリアの話をしますね。2018年3月にセキュリティ対策室に異動しましたが、正直私はそれまでセキュリティ分野に、そんなに熱心に取り組んできていませんでした。徳丸本（※徳丸浩氏の『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践』の通称）を読んで、Webセキュリティについては軽く勉強していましたが、特に自信はなかったんですよね。そんな状況で、GMOペパボのセキュリティ対策チームでどうやってやっていこうか考えていました。

新設されたチームには課題が山積みです。コードを書いたり、ツールを動かしたりする以前の課題もたくさんあります。まず、新卒で入社した森田（@mrtc0）とどうやってチームを走っていくかという課題。2つ目に新しいチームが組織内で横断的にコミュニケーションを回すにはどうしたらいいか。3つ目には技術力やエンジニアリングでコミュニケーションを解決するという課題です。このような課題を初期に据えました。

まず、チーム内コミュニケーション。チームといっても私と森田の2人の話なんですが、私はGMOペパボでの経歴が長くて内情をよく把握している立場にいたので、森田のメンターとして振る舞いました。具体的にはGMOペパボの技術スタックについてあれこれ教えたり、GMOペパボが抱えている技術的な問題や課題感を共有したりしました。ほかにも森田と他の同僚間のコミュニケーションをつないだり、プリンシパルエンジニアという上位等級のエンジニアとして背中を見せてきたりしました。

森田は、いわゆるセキュリティエンジニアとして高い経験、スキルを備えてGMOペパボに入ってきたんですが、このチカラを最大化するために、メンタリングに注力しました。シニアエンジニアに昇格できるまで支援できたのも、うれしく思っています。

一方で森田には、セキュリティについてあれこれとイロハの教えを受けるという、リバースメンターをやってもらいました。セキュリティ対策の基本から各種ツールの使い方や、業界やコミュニティの話など、今でも教えてもらっています。チーム発足初期に双方が教えをリードできる立場にあったことで、互いの立場を尊重できたのは、とてもラッキーだったと思っています。

小さなチームのセキュリティ対策のレバレッジ効果

では、このようなチームが組織の中でどうやってコミュニケーションを回していくかをお話ししようと思います。Co3（セキュリティ対策室の方針、Communication ・Completeness ・Continuous）で、「Communication」が何度も出てくるんですが、DevSecOpsで最近引き合いに出されるモデルで、Dev・Sec・Opsが融合し合って組織文化になるという理想があります。

つまりGMOペパボにいるみんなが、当たり前にセキュリティに取り組んでほしいという姿が理想です。小さな異変や気づきを気軽に共有できたり、平時や緊急事態を問わずコミュニケーションで迅速・正確な対応につなげたり、というところを組織文化として作り上げることで、小さなチームのセキュリティ対策が会社全体のレバレッジとなるのではないかと考えています。

小さなチームが会社内の全てのセキュリティに関する情報を追うのは、なかなか困難なことで、同僚からあれこれとセキュリティ情報をプッシュしてもらえるとありがたい面があります。例えば、ユーザーからの問い合わせで、何か疑わしい内容が出てきてしまったとか、脆弱性の修正方法で迷っているので相談したいとか、インシデントの疑いがある事象が起きてしまったとか、世間で話題になっているセキュリティのネタがあるとか。こういったことを気軽に共有してもらいたいのですが、それにはちょっとしたコツがいるなと思います。

工夫点として「Slack」のReacji Channelerを使って「SSS」という絵文字が付けられると、情報がセキュリティをトピックするチャンネルに共有されるようにしました。熊野（熊野多聞氏）が全パートナー（GMOペパボにおける従業員の呼称）向けに実施する情報セキュリティ研修の中で「SSS」絵文字のチュートリアルを行ったことで、技術職だけでなくカスタマーサポート職からの共有も増えて、とても助かっています。

このSlackの絵文字の話は月に1回行われる社内イベントのペパボテックフライデーで、同僚に向けて宣伝したり対策の啓蒙しています。社内イベントでもチームの存在感を出すことで、同僚からもセキュリティについて相談を受けたりと、コミュニケーションを回していくところが少しずつ確立できたと思います。

インシデント対応においては円滑なコミュニケーションが求められる

次にエンジニアリングでコミュニケーションを解決するところで、もう少し技術的な話に踏み込みます。DevSecOps＋シフトレフトの考え方で前倒しで対策を重ねるというところは、森田や他のサービスに所属しているエンジニアによって整えられていく体制ができました。

一方で、十分に対策を積み重ねていても、どうしても避けられない障害やセキュリティインシデントは発生してしまうので、こういったトラブルに襲われても、迅速にリカバリーする体制を整えていく必要があると思っていました。

前置きしますが、GMOペパボでは一般的に障害と呼ばれる可用性を損なう事象も「インシデント」と呼んでいます。完全性や機密性を損なう事象も「インシデント」ももちろんインシデントです。

その定義でのインシデント対応時のコミュニケーションの話をします。障害対応をしたことがある人はよくわかると思うんですが、復旧作業をするエンジニアには大きなプレッシャーがかかりますよね。何が起きているのかがよくわからないし、何をすれば復旧できるのかがわからない状況で、場合によってはストレスを感じてしまいます。

さらに障害発生時にはチャットツールに大量のアラートが流れてきて、メッセージが溢れてしまってやり取りが追いかけにくくなったり、Slackのスレッド機能の場合、限定された人しか情報が見られないUI/UXなので、コミュニケーションがさらに混乱したりすることがあります。こういった状況下で、他の職種間でもコミュニケーションが滞ることがよくありします。

エンジニアは復旧作業の際に、ログやソースをチャットに貼り付けてコミュニケーションを進めますが、そのままではマネージャーやカスタマーサポートの方たちは解釈するのが難しくて状況伝達がうまくいかないこともあります。このような状況の中で、インシデントが他のサービスに伝播して、さらに連絡が滞って影響範囲が拡大するのを度々見ます。

このようなコミュニケーションのロスでビジネスに大きな影響が出ることは避けたいなと思っています。

インシデント対応を支援するSlack botを作成

こんな課題感を持った上で、Slack botでインシデント対応を支援する取り組みを行いました。このボットはsssbotという名前なんですが、いろいろな機能を持っているのでピックアップして紹介したいと思います。まずボットを呼び出すと、チャンネル作成のフォームが出てきます。チャンネルはインシデント対応ごとに作って記録を一元化して追いかけやすくします。

sssbotは複数のチャンネルに通知を飛ばして、いろいろな職種の人たちに共有を図ります。このときに初動対応チームと呼ばれる、それぞれのサービスごとにあらかじめ編成されたチームをinviteして初動を促します。インシデント対応チャンネルを作った人はそのときの状況をよく理解している人なので、ボットがこの人に対して、みんなに状況を伝えてねと指示出しをします。

初動対応チームの人たちはいきなりinviteされて「なんだ、なんだ」という状況に陥りがちなので、まずは落ち着いて今何が起きているのかをボットが伝えます。15分ごとにタイムキーパーが介入して「今どうなっているの？」と状況判断を促す業務もありします。

GitHubの自動で記録を取る機能も付けています。このスクリーンショットは、弊社で定期的に実施しているインシデント対応訓練での利用例です。postmortemのプルリクエストを自動で作る機能も持っています。インシデントの振り返り、根本原因の分析、改善のアクションを促すことも支援しています。

sssbotは、チャンネルを作るだけのシンプルなボットから、徐々に機能を拡張して社内に普及してきました。コミュニケーションを変えるというのは、つまり同僚のやり方を変えることであって、ゆっくりと時間をかけてフォローを重ねていきました。具体的にはすべてのインシデント対応チャンネルにセキュリティ対策チームが加わったり、インシデント発生時にはCTOやVPoEも必ずinviteされたりします。

このように、ボットの不満点やフィードバックを拾い上げる機会を自ら作っています。社内イベントのペパボテックフライデーの中で、sssbotの新しい機能や事例を紹介して、みんなが当たり前にボットを使ってくれるようになるまで、ちょっとずつやり方を変えてアプローチしました。

ボット自体はコミュニケーションを自動で支援するだけで、問題の解決は人間が行わなければいけません。これは私の場合なんですが、Linuxカーネルの問題で起きてしまったインシデント対応の復旧解決にも入っていて、一部SREとオーバーラップするかたちで活動しています。

トラブルシューティングの記事をテックブログに公開しているので、ご覧ください。

これからの事業を拡大していくGMOペパボにはセキュリティの課題が山積みです。私のようなセキュリティを主軸としていないキャリアの人間でもアプローチして取り組めるところはたくさんありますし、森田のようにセキュリティを主軸にやりたい人でもコミットできるところはあるので、ぜひGMOペパボに興味を持っていただければなと思います。

では森田に変わります。

DevSecOpsの図でどこまで守れているのかを知る

森田浩平氏：私から「セキュリティ対策を継続させるプロダクトの開発」をお話しします。

まず自己紹介なんですが、森田浩平と言います。Twitterは@mrtc0のアカウントでやっています。経歴は2018年4月に新卒入社して、それまでは脆弱性診断の会社でアルバイトをやっていました。

先ほど熊野（熊野多聞氏）、伊藤（伊藤洋也氏）からCompletely、Communicationと続いて、私は継続ということで「Continuous」のお話をします。一般的に、攻撃やインシデントがなくなることはまずないので、セキュリティ対策を継続していく必要があります。私たちは対策を継続するために、レバレッジの効いた技術を使って持続的な効果をもたらすことを意識して取り組んでいます。

対策を継続するためにエンジニアリングで問題を解決しているということを今回お伝えしたいと思っています。

セキュリティ対策室の業務として、今回の発表で何度もキーワードとして出てきているDevSecOpsの推進があります。これは「セキュリティ対策はやって当たり前」というマインドセットへ切り替えて、それを維持することが目的となっています。DevSecOpsの図を見たことがある方はすぐにイメージが湧くと思うのですが、DevとOpsがグルグルと交わっているところをSecが包括しています。

これはDevとOpsに加えて、Secも一連の流れに組み込む。つまりすべての工程でセキュリティを導入することが意図的に書かれている図だと思います。GMOペパボの事業部を横断して見たときに、コードを書いて、ビルドして、テストをして、デプロイして、運用してというDevSecOpsそれぞれのフェーズで、「私たちはセキュリティを提供できる基盤を持っているのか」「自分たちはどこまで守れているのか」を確認しました。

それがDevSecOpsサイクルのところなんですが、真ん中の青が開発サイクルで、周りの緑が対策なんですね。実際はこの図に利用しているツールも載せていて、どこが守れているかがわかるような図になっているんですが、今回は簡略版です。

例えば右の図の右下部分ですね。アプリケーションの依存パッケージの監査ができたら次はそれを自動でアップデートする仕組みを作って緑の領域をどんどん増やしています。

もちろんサービスごとの共有モデリングを行う必要があるんですが、事業を横断して支援する立場で、セキュリティ対策を支援する仕組みはあるのかという観点でこの図を作ることで、組織としてここが守れていないというのが一目でわかるようになりました。

脆弱性の情報を収集してトリアージをする

実際にこれらの取り組みを継続させるために、どのようなことをしているのか具体的なお話をしていきたいと思います。まずは脆弱性情報の収集やトリアージについてです。ほぼ毎日CVE（共通脆弱性識別子）や脆弱性情報が出ているんですが、セキュリティ対策室ではGMOペパボが抱えているすべてのサービスの脆弱性情報のトリアージを行っています。

インターフェイスとしてSlack botを利用していて、その通知を元に影響があるかどうかを調査しています。影響のある脆弱性は、Slackにピン留めをしてさらに詳細に調べています。審査の結果、対応を要する脆弱性については、別途GitHubのissueでリスク評価や緩和策を含めた対策を書いた上で、対象サービスに通達、対応を依頼しています。

このとき、各サービスでの攻撃実現性を確認するために脆弱性をつくコードを書くことがあります。伊藤（伊藤洋也氏）のブログにもLinuxカーネルのDoSの脆弱性に関する記事が書かれているんですが、POC（概念実証）を書いて再現して、条件や影響範囲を特定することもあります。

セキュリティツール「Wazuh」を導入

続いて「Wazuh」についてお話しします。Wazuhはエージェントをサーバーにインストールするモデルのセキュリティ基盤ツールです。GMOペパボではサーバー全台に導入をしているツールです。FIM（File Integrity Monitoring）などの機能があるんですが、構築と導入は、山下（@pyama86）と常松（@tnmt）が進めてくれました。

今はセキュリティ対策室で運用を固めています。セキュリティツールの導入を経験されたことがある方はわかると思うんですが、導入しただけでセキュリティ対策が完了するわけではないんですね。そこから例えばルールの整理や自分たちの組織に合った運用を固めていく必要があります。

このWazuhの運用も同じで、右の図に書いた施策に取り組みました。一部の施策についてはこのあともう少し詳しく触れていくんですが、例えばWazuhの機能の提案やバグ報告や、ドキュメントの修正など、作ったライブラリをコミュニティに貢献、還元する活動もしています。

先ほどのWazuh運用の施策の話なんですが、継続的に取り組む必要があるものの1つに、ルールの整備があります。Wazuhにはデフォルトでルールがあるんですが、検知対象が非常に多いので自分たちでカスタマイズをして通知を減らして、本当に必要な通知だけ流す必要がありました。

WazuhにはCentralized configurationと呼ばれるエージェントの設定など、そういったルールをマネージャー側で集中管理できる仕組みがあるため、これを利用して不要なルールを除外していきました。セキュリティ対策室だけでなく、サービス側にも調整を手伝ってもらって、ルールの削減に取り組みました。

ただし、いくつか課題もありました。Wazuhのルールは、1枚のXMLにベタ書きする必要があったり、テストを自動化する仕組みが備わっていなかったりしたので、サービスの人たちがルールを書きやすい環境をセキュリティ対策室が整備しました。例えば個別のYAMLからXMLに変換したり、そのYAMLの中にルールと一緒にテストを含めたりして、そのルールが意図したとおりイベントを検知するか、テストできる仕組みなどを導入しました。

続いての施策で、通知のカスタマイズがあります。Wazuhは基本的に全サーバーに導入しているので、ステージング環境にもインストールしているんですが、検証などで生じる一時的なエラーも検知されるんですね。なので大量に通知が来てしまう問題がありました。

またアラートが流れても、これが何のアラートでどのようなアクションを取ればいいのかがわからない状態だったので、その通知の流量や内容をコントロールするために、フィルタリングする仕組みを作りました。

これによって、例えば同じアラートが単位時間の上限に達したら、そのアラートはドロップするとか、通知内容にインシデントプレイブックのリンクを貼ったりとか、アノテーションを付けてアクションを促したりとか、確認する負荷を下げました。

セキュリティ領域はまだまだ伸びしろがある

ここまで見ると、かなりWazuhにチカラを入れているように見えるんですが、ほかにもサービスを安全にするための技術の検証導入などを行っています。例えば常松が話した社内のKubernetesクラスタの管理ツールであるNKEのFalcoやセキュリティポリシーを導入したり、「ロリポップ！マネージドクラウド」のユーザーが利用するパッケージの検証に、Open Policy Agentなどを利用したりしています。

あとはアプリケーションのパッケージなどのインベントリを横断的に検索できるアーキテクチャを作ったり、Linuxカーネル周辺のバグや脆弱性の実現可能性の調査などしたりしています。脆弱性診断やSOCなどを行うセキュリティエンジニアというよりも、内容がSREと被る部分もあり、ガリガリコードを書くことが多いのがGMOペパボのセキュリティエンジニアの特徴なのではないかなと思います。

ここまで、私たちのセキュリティ対策についてお話ししてきましたが、まだまだ伸びしろをもつ領域もあります。例えばアプリケーションセキュリティだと、今でもSAST（静的解析）やDAST（動的解析）を利用している部署があるんですが、まだまだ発展の余地がある状況です。インフラやインシデント対応に関してもプレイブックの自動化などを行っていきたいと考えています。

サービスの規模に対して、セキュリティエンジニアの割合が少ないので、我々が専門としていない、例えばモバイルなどの領域は、まだまだ伸びしろがあると思っています。

というわけで、私たちと一緒にサービスをセキュアにしてくれる方を募集しています。今回の発表を聞いて興味を持った方はぜひお話だけでもと思います。セキュリティエンジニアだけではなくて、GMOペパボの各サービスのソフトウェアエンジニアやSREとしてセキュリティに関わりたい方も募集しているので、ぜひよろしくお願いいたします。

私たちの発表は以上です。ご清聴ありがとうございました。