攻めの脆弱性診断：ツールと手動と内部ならではのアプローチ
越智氏がfreeeにジョイン後、最初に取り組んだのが前職のキャリアで培ったスキルを活かせる脆弱性診断。セキュリティ上の問題点を探す手法はいろいろとあるが、越智氏が得意とするのがブラックボックステストと呼ばれる手法で、プロダクトやサービスに疑似的な攻撃をしかけて、そのふるまいから脆弱性を探る。
これまで慣れた手法ではあったものの、脆弱性診断を回していくにはメインの診断の前後にやるべきことが多数ある。まずは診断の対象を決める。新しくリリースされる機能などが該当し、仕様の確認やスケジュール調整も必要になる。また診断は本番環境で実行するわけにはいかない。万が一、攻撃が刺さってしまえば環境やデータを破壊しかねないからだ。そのため診断用の環境やダミーデータも用意する。
当初は関係者から直接「どんな機能ですか？」「どんなものが必要ですか？」とヒアリングしており、相当な労力がかかっていた。またfreeeではリリースのスピードも早いため、診断のスピードも高める必要がある。そこで準備に必要なことをテンプレート化することにした。その際「診断ヒアリングし太郎」という通知の仕組みも作った。Googleフォームへの記入依頼をSlackで通知するというシンプルなものだ。越智氏は「ささいなことですが、診断を回しやすくなりました」と話す。なお11月の開発合宿にて、この仕組みに機能を追加することが予定されている。
診断の準備が整うと、メインの脆弱性診断となる。攻め方にはツールと手動の2種類、加えて内部（自社内）だからこそできることがある。
ツールでは、何千何百もの膨大なパターンの疑似攻撃を浴びせる。人手では無理だが、ツールなら可能だ。攻撃後はツールからの通知内容や、HTTPレスポンスの情報も確認する。例えばステータスコードが「400（Bad Request）」や「500（Internal Server Error）」が想定されるところで、「200（OK）」のような傾向が異なる場合注意が必要だ。リクエストが通ってしまったことになるため、見せてはいけないものを見せていないかなどを確認する。またレスポンス時間が異様に長いところでは何らかの脆弱性が影響していないかを確認する。
手動では、ツールではできないビジネスロジックや権限に関することを検証する。例えばプロフィール情報を取得するためのAPIがあったとする。「GET /api/profile/1」とリクエストしたら、該当する情報が返されるなど。ここで誰かが末尾の「1」の部分を別の数字に置き換えたらどうなるか。もしこの情報が限られた人しか閲覧できないものなら、「403（権限がありません）」という応答なら正しい。もし見えてしまえば、即座に情報漏えいにつながってしまう。こうしたものは手動で確認していく。
加えて、内部だからこそできる診断もある。社内だからこそソースコードや設定を確認できて、開発チームと密にコミュニケーションができるので、仕様から「リスクが高いのでは？」と思えるところはじっくりと検証することもできる。また脆弱性診断をしているときに不審な挙動があれば、越智氏らが「抜き打ち」で調べることもあるという。
越智氏は「こういった形で脆弱性がないかを探し、もし見つかった場合は開発のチームの方に対応してくださいねとお願いして、脆弱性を塞いでリリースというような流れになります。この一連をたくさん流していくことで、常にセキュリティを高めていく活動をしています」と説明する。
守りのSensor監視：大量のブロックで深掘りしてみると
脆弱性診断を一通りまわすことに慣れてきたころ、守りの視点となるSensor監視にも取り組むことにした。freeeではSIEM（Security Information & Event Mangement）と呼ばれる、各種ログを解析して可視化するツールを導入している。「どれを担当したい？」と聞かれ、越智氏はWAF（Web Application Firewall）を選んだ。WAFは先の脆弱性診断では攻撃のHTTPリクエストをぶつけられる側だからだ。自分が行う攻撃と守りの両方を見ることになる。
Sensor監視のワークフローは、不審な点があれば起票し、深掘りして、何らかの対応が必要であれば開発チームに対応を依頼するようになっている。
SIEMを用いた監視の実例を見てみよう。とあるサービスでブロックが頻発していることが分かった。グラフで時間を拡大し、IPアドレスを絞り、確認する。さらにこのIPアドレスの通信内容を確認する。ブロックされている通信は何らかの探索をしているようで、パスした通信は攻撃性のない通常のリクエストだった。そのため問題はないということで、この件はクローズとなった。
もう1つ、興味深い実例を見てみよう。freeeでは一般ユーザーにも解放しているAPI（Public API）がある。ある日、特定のユーザーの特定のAPIパスにて大量のリクエストでブロックが生じていた。何か異常が起きているということで起票（イシューがオープンに）された。
深掘りをしてみると、ただ単にリクエストを大量に送信しているだけで、悪い探索をしているのではないようだと分かった。越智氏は「おそらくPublic APIを活用するなかで、コードのミスか何かで大量に送る状況になっていたのではないかと結論づけて、サポート経由でお客様にお知らせしました」と対応を説明する。少しして大量のリクエスト由来のブロックも発生しなくなり、越智氏は「お客様のほうでご対応いただけたのかな」と安心してイシューをクローズしたそうだ。
越智氏は「WAFでブロックする時は悪い攻撃が多いというイメージでしたが、お客様のちょっとしたミスでも起こりうることが印象的でした。守りのSensor監視をするなかで、悪い通信かどうかの見極めが難しいなと思いました」と話す。
このSIEMの流れは、おおよそ1件あたり20〜30分ほど費やしていた。そこで起票や深掘りに必要な情報をまとめる仕組みを作ることで、対応時間の大幅な短縮につながった。結果として確認できる範囲が5倍に増えたという。なお、この仕組みはfreeeのPSIRTにいる、もう1人の女性エンジニアの活躍で作成された。
PSIRTでは攻めや守りだけではなく、普段の仕組み作りも重要になる。例えば越智氏は、GitHub audit logをSIEMに取り込む仕組みを作った。インシデントは外部からの攻撃だけとは限らない。内部起因のインシデント予防につなげるため、この仕組みを作ることにしたという。
それまで監査ログを調べるには、GitHubから手動で文字列から検索する必要があった。これが地味に手間がかかっていたのだ。実際に構築した仕組みはシンプルで、GitHubのAPIを使用してaudit logを取得する。その後は重複や抜けがないか処理し、AWSのS3バケットに保存し、後は既存のSIEMの仕組みに取り込むような設定を施した。これにより検索が楽になっただけではなく、グラフで可視化されたというメリットも得ることができた。
実際にログをSIEMに取り込むようになると、定期的に角（ピーク）が出ることが分かった。例として、休日や祝日が重なると角がでない。もしも、休日や祝日に角が立つと「何か異変が？」と気づくことができる。
