脆弱性診断の費用相場：見積もりの幅はどこから出るのか

何を診るか。 Webアプリケーションの作りを見るのか、OS やミドルウェアの設定と既知の欠陥を見るのか、スマートフォンアプリを見るのか、クラウドの権限設定を見るのかで、まったく別の作業になります。上の相場はWebアプリケーション診断のもので、対象の層が変われば別の見積もりが立ちます。

何を単位に数えるか。 画面数で数えるのか、リクエスト数で数えるのか、FQDN の数で数えるのかによって、同じシステムでも見積もりの母数が変わり、ログイン後の画面が多いサービスでは、ここだけで倍近く動きます。

診断のあとに何が付くか。 報告書を出して終わりなのか、質問に答えてくれるのか、修正後の再診断が含まれるのか。ツールの出力をそのまま渡す形と、人が偽陽性を落として再現手順まで付ける形とでも、人件費が変わります。再診断が別料金だと、直してから確かめるまでにもう一度予算が要ります。

どのアカウントと役割を用意するか。 一般の利用者と管理者、契約が別のテナント同士のように、いくつの役割を用意するかで作業量が変わります。多要素認証やシングルサインオンが絡むと、その準備自体にも手間がかかります。

他人の権限に手が届かないか。 他人の ID を指定して他人の情報が見えないか、一般の資格のまま管理者向けの機能に入れないか。この種類は仕様書が無くてもアカウントを2つ用意して見比べれば確かめられますが、役割の組み合わせの数だけ試すことになります。

その業務でしか決まらない規則を含めるか。 価格や数量を書き換えて注文が通ってしまう、手順を飛ばして確定まで進めてしまう。通信の形としては正常なリクエストで、その業務でそれが許されているかどうかでしか欠陥と判定できません。手動診断の費用が上がる理由のひとつがここにあります。

複数の手順にまたがる処理を追うか。 カートから決済、確定までのように、いくつものリクエストが状態を持って続く流れは、1本ずつ叩く形では踏めません。

どこまでの操作を許すか。 テスト用のデータを作ったり書き換えたりする操作は認証後の診断では普通に行いますが、取り消せない操作と、負荷をかけて可用性を試す種類は別に取り決めることが多く、本番で実施するのか同等の環境を用意するのかでも金額が動きます。

どこまで内部の情報を渡すか。 仕様書や設計、API の定義、ソースコードまで渡すほど、外から叩くだけでは届きにくい箇所に手が届きます。同時実行の競合や暗号の使い方などが、その典型です。

資産が増える。 部署ごとに立てたサブドメイン、検証用に公開したままのサーバー、統合した子会社のドメイン。前回の診断のときには存在しなかったので、報告書には載っていません。

脆弱性が増える。 コードを1行も変えなくても、使っているミドルウェアに新しい脆弱性が公表されれば、昨日まで問題として認識されていなかったサーバーが、今日から既知の攻撃対象になります。診断当日に「問題なし」だった構成が、3か月後に攻撃可能になっていることは珍しくありません。

システム自体が変わる。 機能を足す、設定を変える、権限の付け方を見直す、外部のサービスと繋ぐ。外から見て分かるのはその一部で、権限の境界や業務ごとの規則がどう変わったかは、外形からは判断できません。

「候補」と書いたのは、検出と実証が別の工程だからです。実際に攻撃が成立するかを確かめる工程は PentaTrail では CTEM 側の機能で、条件に合うものだけが対象になります。

外部観測型の継続監視は、ログインせず到達できる範囲を見ます。認証が要るパスは「ここは認証が要る」と記録して、その先には入りません。社内からしか到達できないシステム、ソースコードや使っているライブラリの一覧、社員の端末、ID 基盤やクラウドの管理画面も、別に連携を用意しない限り対象外です。どこで止まるかはASM・脆弱性診断・ペネトレーションテストの違いに図で書きました。