これは シーエー・アドバンス Advent Calendar2023 20日目の記事です。
19日目の記事は @yagisawa_riko さんの 「tableauを使って推しが総選挙10位内に入るためのデータ分析してみた」 でした。
21日目の記事は @azama_yasuhiro さんです。
はじめに
こんにちは。
シーエー・アドバンス（CAAD）技術統括本部セキュリティチームの @asami-H-Ishi です。
社内（グループ会社含む）サービスの脆弱性診断をサポートする業務として、主に診断前の対象調査を担当しています。
開発未経験で異業種から転職して、10月で8年目に入りました。
入社当時の自分が理解できるレベルを意識して社内マニュアルやQiita記事を書いています。
（マニュアルについては過去に「業務内容のマニュアル化のすすめ〜弊社脆弱性診断チームの事例を添えて〜」という記事を書いていますので、よかったら読んでみてください٩( ᐛ )و）
さて、8年目ともなるとアドベントカレンダーのネタに困るようになってきました。
今回はタイトルどおり脆弱性診断実施前にする対象調査の時点で「ある問題」を見つけたらチケットを起票しているよ、の話をさせていただきます。
脆弱性診断って？ 対象調査って？
脆弱性診断は、攻撃者が付け入ることのできる弱点（脆弱性）がないかどうかをチェックするセキュリティテストです。
プログラムの不具合（バグ）や設計上のミスによりできてしまった脆弱性を放置すると、不正アクセス、データの改ざん、情報漏洩、マルウェアの感染などのトラブルに発展するおそれがあります。
脆弱性診断を実施する目的は、「ユーザ情報が漏えいする」「システムを踏み台にされる」といった事故が発生しないようにすることです。
脆弱性診断の流れは、ざっくり下記のとおりです。
| # | 流れ | 備考 |
|---|---|---|
| 1 | ヒアリング | 対象サービスの情報を聞き取ります |
| 2 | 対象調査 | サービスにアクセスして規模、機能等の情報収集をします |
| 3 | 工数見積 | 診断に必要な工数を見積もります |
| 4 | 脆弱性診断 | ツール診断、手動診断を実施します |
| 5 | チケット起票 | 検出された脆弱性の報告をします ※弊社では報告書の作成は行わず、チケットで管理しています |
| 6 | 修正対応 | ※サービス開発側で実施 |
| 7 | 再診断 | 指摘事項の修正が完了しているか確認します |
| 8 | 診断完了 | 起票したチケットがクローズになったら診断完了です |
上記2番の対象調査では、診断を実施する前に対象サービスについて情報収集をし、サービスの規模、機能などを確認しています。
診断作業ではなく確認作業が主なので、この時点で脆弱性を報告する「チケット起票」は行いません。
Q.じゃあなんでこの記事のタイトルは "対象調査の時点で「ある問題」を見つけたらチケットを起票しているよ" って書いてあるの？
A.後述の観点さえあれば、対象調査の時点で見つけられるからだよ！
対象調査中に見つけたら起票する「ある問題」と、見つけるための観点、そして対策
対象調査中に見つけたら起票する「ある問題」とは、下記のとおりです。
- 利用していない古いAPI
- 利用していない古いページ
- 利用していない古い機能
これらが存在している、動いている状態のアプリケーションでは、次のようなリスクが考えられます。
- 開発側が想定していない下記事象が起こる可能性
- データの不整合
- 認可制御のバイパス
- 情報の漏洩
- 開発側が把握できずそのまま放置される可能性
- 新たな脆弱性が報告された場合に調査されない
「利用していない」時点で、メンテナンス対象から漏れてしまう・すでに漏れていることが考えられます。
メンテナンスできていないことによるリスクについては、挙げるまでもありません。
そして、「利用していない」「メンテナンスしていない」箇所はリスクがある、という観点があれば、該当箇所は簡単に見つけられます。
そして、対策は端的に、「利用していない古いAPI、ページ、機能は削除する」です。
おわりに
今回の記事は、サービスを開発・運用していく上で気をつけられることとして書きました。
リスクを減らすため、利用していないAPI、ページ、機能は削除しましょう！
思えば、家の中でも使ってないものは捨てた方がいいですよね（いつか使うかも、と取っておいた結果、ダンボールから虫がわくとか、着なくなった服を手入れできず置いていたらお気に入りの服まで傷んでしまった、とか……）。
年末に向けて大掃除のことも考えなければいけませんね。
とりあえずクリスマスを楽しんでから、大掃除頑張って、よい新年を迎えましょう！