「アタックサーフェスマネジメントは外側を守ること」という縮小解釈がもたらす重大なリスク：辻伸弘の「投げます。一石、」（2）（2/3 ページ）

[辻伸弘，SBテクノロジー株式会社]

把握すべき3つの段階と順序

　次に、ASMで把握すべき“対象”を考えてみよう。

　ASMにおける把握対象は、「IT資産」「アクセス制御」「脆弱性」の3つに分類できる。これらは単に並列に並んでいるわけではなく、この順番で見ていくことが極めて重要だ。

1.IT資産：全ては「知る」ことから始まる

　最初に必要なのは、自分たちがどんな資産を持っているのかを知ることだ。ドメイン名、IPアドレス、OS、アプリケーション、ネットワーク機器のファームウェアやハードウェアなど、可能な限り全てを網羅的に把握するのが理想である。

　先に述べたように、資産管理という土台ができていない場所に、いくら高価なセキュリティ対策を積み上げても望んだ効果を得ることができない。自分たちが把握していない抜け漏れがないか、まずは手持ちのカードを全て並べることから始めなければならない。

2.アクセス制御：「要らんもん」を通さない

　資産を把握したら、次にその状態を確認する。具体的には「アクセス制御」が適正になされているかどうかだ。どのポートが開いているのか、認証は施されているのか、その認証はID／パスワードだけなのか、加えて多要素認証を設定しているのか、権限設定は適切かといった点をチェックする。

　重要なのは、「脆弱性の有無」を見る前に、「そもそもここを開けておく必要があるのか」を問うことだ。例えば、管理画面をインターネットに向けて開けてしまっているとする。これは脆弱性があるかないか以前の問題で、「認証の前に、管理画面はそもそも外部公開すべきではない」ものだ。どうしても外部からメンテナンスが必要なら、接続元のIPアドレスを制限してフィルタリングすればいい。余談だが、認証が設定されていても管理画面にアクセスが可能な状態ということが脆弱性を悪用する条件である場合もあるので、思っている以上に注意が必要となる。

　脆弱性管理をする前に、不要な通信を遮断し、守るべきポイントを最小限にする。これが「アクセス制御」の本質である。

3.脆弱性：リスクを評価し、優先順位を決める

　アクセス制御で不要な通信を遮断したとしても、WebサーバやVPN機器のようにどうしてもインターネットに向けて開けておかなければならないポートはある。ここで初めて「脆弱性」の管理が登場する。

　見るべきは「脆弱性があるかないか」だけではない。その脆弱性の種類は何か、悪用されたときにどんな影響が出るのか、既に悪用可能、もしくは悪用が認められているのか、修正パッチや回避策（緩和策）はあるのか。これらを総合的に判断し、「どの脆弱性から直すべきか」という対策の優先順位を決めていく（トリアージ）。脆弱性管理の考え方に関しては、本連載でも追い追い取り上げていきたいと思う。

　昨今の事件を受け、多くの組織がいきなり「脆弱性診断」を行おうとするが、それは間違いだ。まず「IT資産」を知り、次に「アクセス制御」で不要な入り口を減らす。その上で残った必要な接点に対してのみ「脆弱性」の評価を行う。このプロセスを経ずに、ただ、やみくもに脆弱性を探すのは非効率なだけではなく、対応の優先順位を誤ることともなり、セキュリティレベルの底上げにもつながらない。

筆者の考える「アタックサーフェスマネジメント」の入り口

米国政府機関が米国政府機関に求める厳格な運用

　ASMの運用がいかに厳格であるべきかについては、米国CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）が出している運用指令「BOD 23-01／23-02」が参考になる。この指令では、米国政府機関に対して下記のような指示を行っている。

• 7日ごとに資産の可視化を行う
• 14日ごとに脆弱性の検出を特権で行う
• 管理インタフェースへのアクセス制御

米国CISA「BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks」

　特筆すべきは、脆弱性検出において「特権で行うこと」を求めている点だ。つまり、対象から見て外部からのスキャンだけでなく、認証情報を用いて対象にログオンした状態で、ローカルの脆弱性まで検出することを求めているのだ。また、対象はインターネットに直接つながっていない、論理的に隔離されたネットワーク上の資産も含まれる。

　「インターネットからスキャンして終わり」という、何と呼んでいいか分からないようなものとは、全く異なることが分かるだろう。攻撃者の脆弱性悪用サイクルが短縮化している現在、年に1回の診断では到底間に合わない。自組織のリスク許容度に合わせて、可能な限り短いスパンでサイクルを回し続ける必要がある。言うまでもないかもしれないが、このサイクルには検出された問題点への対応も含まれる。