SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Women Developers Summit 2022 セッションレポート(AD)

プロダクトの安全のために「攻め」の脆弱性診断と「守り」のSensor監視に取り組むPSIRTの日々

【B-4】セキュリティ技術者として大切にしていること、攻めと守り、仕組みづくりの視点から

  • X ポスト
  • このエントリーをはてなブックマークに追加

攻めの脆弱性診断:ツールと手動と内部ならではのアプローチ

 越智氏が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監視のワークフローは、不審な点があれば起票し、深掘りして、何らかの対応が必要であれば開発チームに対応を依頼するようになっている。

Sensor監視のながれ
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の仕組みに取り込むような設定を施した。これにより検索が楽になっただけではなく、グラフで可視化されたというメリットも得ることができた。

GitHub audit logのSIEMへの取り込み
GitHub audit logのSIEMへの取り込み

 実際にログをSIEMに取り込むようになると、定期的に角(ピーク)が出ることが分かった。例として、休日や祝日が重なると角がでない。もしも、休日や祝日に角が立つと「何か異変が?」と気づくことができる。

次のページ
セキュリティ技術者 として「幅を広げる」「視点・視野を広げる」「積み重ね」を大切に

関連リンク

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Women Developers Summit 2022 セッションレポート連載記事一覧

もっと読む

この記事の著者

CodeZine編集部(コードジンヘンシュウブ)

CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16845 2023/01/11 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング