- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
順位とスコアの読み方に続いて、今回は自分の順番をどう決めるかを扱います。
まず結論
OWASP Top 10 を全部潰したという主張について、OWASP 自身が「そういう主張は勧めない。単に事実ではないから」と書いています。一覧を上から消しても、消し終えた状態はありません。
外から来る順位もスコアも、直す順番までは決めてくれません。決めるのは自分の側だと、標準の文書自身が書いています。
「OWASP Top 10 の10項目をすべて対策しました」という報告を受け取ったとき、OWASP の公式文書はこの種の主張をどう扱っているでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
網羅を主張するな、と書いてある文書
前回までに、外から来る順位の作られ方と、スコアが何を表しているかを見ました。残った問いは単純です。では自分は、何から直せばいいのか。
まず、一覧を上から消す方法が成り立たないことを確認します。OWASP Top 10 には「標準としての使い方」という短い文書が付いていて、末尾にこうあります。
OWASP discourages any claims of full coverage of the OWASP Top 10, because it’s simply untrue.
網羅したという主張を勧めない、理由は単に事実ではないから。根拠はその直前にあります。
Tools cannot comprehensively detect, test, or protect against the OWASP Top 10 due to the nature of several of the OWASP Top 10 risks
道具の出来が悪いからではなく、並んでいる項目の性質による。同じ文書は自分の位置づけもこう書いています。
know that it is the bare minimum and just a starting point
出発点であって、到達点ではない。読み取れるのは、一覧には「消し終えた」という状態が定義されていないということです。
なぜ判定できないのか — 文書自身が挙げている例
同じ文書が挙げている具体例を見ます。前提として、Top 10 は自分が何を集めた文書かをこう書いています。
we document AppSec risks, and not necessarily easily testable issues.
リスクを集めたのであって、テストしやすい問題を集めたのではない。続けてこうあります。
対象 原文の表現 判定の手段A04(設計の項目) beyond the scope of ほとんどのテスト形式のmost forms of testing 範囲外ログと観測が can only be done with interviews 聞き取りと、実際の機能しているか and requesting a sampling 対応事例の抽出静的解析でできること look for the absence of logging ログが無いことは分かる静的解析でできないこと it might be impossible to 重要な事象を記録してdetermine いるかは判定できない
2行目に注目してください。ログと観測が機能しているかは、聞き取りでしか確かめられないとあります。道具の出力ではなく、人に聞いた内容が根拠になる項目が一覧に混ざっているということです。原文は侵入テストについても、対応の発動を確かめられるのはテスト環境までで、そこは which is rarely monitored in the same way as production(本番と同じようには観測されていないことが多い)と書いています。
つまり、一覧の項目には確かめ方が違うものが混在している。これが、チェックリストとして扱えない理由です。
OWASP Top 10 の「標準としての使い方」は、Top 10 が何を集めた文書だと書いていますか。
要件に課される条件が、文書ごとに違う
別の文書を見ます。同じ OWASP が出している ASVS(Application Security Verification Standard)です。ASVS 5.0 は、要件が満たすべき条件をこう書いています。
The requirement must be verifiable, and the verification must result in a "fail" or "pass" decision.
検証可能であること、そして検証が合否のどちらかに決着すること。これは Top 10 の not necessarily easily testable issues と正面から対になっています。同じ領域を扱う2つの文書が、要件に課す条件のところで違うのです。
違いを知らずに両方を並べて対応表を作ると、「対策済み」の欄が合否なのか聞き取りの印象なのかが分からなくなります。
- ・「対応済み」の欄は、根拠の種類がないと読めない
- ・到達可能性は本教材の語で、標準の用語ではない
そして ASVS は、水準を誰が決めるかについてこう書いています。
Rather than the ASVS prescriptively stating what level an application should be at, an organization should analyze its risks and decide what level it believes it should be at
標準が規範として指定するのではなく、組織が自分のリスクを分析して決める。これが、本レッスンの題への出典側からの回答です。ASVS は自分の割り当てについても it may not be a 100% fit for every situation(すべての状況に100%適合するとは限らない)と認め、組織が自分のリスク上の考慮に基づいて上の水準の要件を先に優先したいことがある、と書いています。
用途によって、どちらが適しているかが入れ替わる
「標準としての使い方」には、用途ごとに Top 10 と ASVS のどちらが使えるかを並べた表があります。対比がはっきりしている2行だけを見ます。
Use Case OWASP Top 10 2021 ASVSAwareness Yes (空欄)Coding standard Bare minimum Yes
上の行では Top 10 が Yes で、ASVS 側が空欄です。知ってもらう用途では Top 10 のほうが適していると原文の表が示しています。下の行では逆転して、Top 10 が Bare minimum、ASVS が Yes です。
同じ文書が、自分が勝っている用途と負けている用途を自分で書き分けている。用途を先に決めないと道具が選べないということです。ASVS 側も、自分の肯定的な仕組みを rather than the Top 10 negative things not to do(やってはいけないことを並べた Top 10 ではなく)と対比しています。
使い分けそのものは既存のセキュリティ運用クイズ群(OWASP プロジェクト)が扱います。ここで足したいのは、要件に課される条件が違うという構造です。
ASVS 5.0 は、アプリがどの水準を満たすべきかを誰が決めると書いていますか。
一覧の項目を、自分の構成に当てはめる
Top 10 の各項目を自分の構成に照らすとき、確かめ方が項目ごとに違います。合否に決着するものと、聞き取りでしか確かめられないものが同じ一覧に並びます。
項目の種類 確かめ方 決着するか検証可能なもの 検証の実行 fail / pass設計に関わるもの 多くのテスト形式の外 決着しないログと観測 聞き取りと事例の抽出 決着しない
責任の線の、どちら側にあるか(仮想化・クラウド編)
仮想化・クラウド編『どこまでが自分の責任か — 線は契約で決まり技術で消えない』では、同じ構成要素でも線のどちら側にあるかで自分がすることが変わりました。線の位置は技術では消えません。
対象 自分がすること 相手がすること自分の側 設定と更新を行う 関与しない相手の側 結果を受け取る 設定と更新を行う境目の上 約束の確認が要る 約束の確認が要る
脆弱性の一覧を自分の構成に当てはめる作業と、責任の線のどちら側かを見る作業。扱っているものは別ですが、共通する構造は何でしょうか。
どちらも「外から与えられたものを、そのまま使えない」状態から始まります。使えるようにするために間に何が挟まるかを考えてください。
この章のまとめ
- OWASP は Top 10 の完全な網羅を主張することを勧めないと書いている。理由は
it’s simply untrue。 - 網羅できないのは道具の出来ではなく、項目の性質による。A04 は多くのテスト形式の範囲外で、ログと観測は聞き取りでしか確かめられない。
- Top 10 は自分を
bare minimum and just a starting pointと位置づけている。出発点であって到達点ではない。 - ASVS 5.0 は要件に「検証可能で、合否に決着すること」を課す。Top 10 の
not necessarily easily testable issuesと正面から違う。 - 水準を決めるのは標準ではなく組織だと、ASVS 自身が書いている。
- だから順番は、一覧の並びではなく、自分の構成に届く経路があるかの判定から作られる。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
OWASP が「Top 10 の完全な網羅」を主張することを勧めない理由として、公式文書が挙げているのはどれですか。
用語集(4語)
- OWASP Top 10
- OWASP が公開する Web アプリケーションのリスクの文書。自身を bare minimum and just a starting point と位置づけている。
- ASVS (Application Security Verification Standard)
- OWASP の検証用の標準。要件が検証可能で、検証が fail か pass に決着することを条件とする。ASVS 5.0 の本文は 5.0/en/ 以下に置かれている。
- 検証可能 (verifiable)
- ASVS が要件に課す条件。確かめられるだけでなく、結果が合否のどちらかに決着することまでを含む。
- 到達可能性
- 外から来た指摘が、自分の構成で実際に届く経路を持つかどうか。本教材が使う語で、標準の用語ではない。