ブログ

Attack Surface管理の必要性と注意点

2023.7.14

はじめまして。CAAV開発を担当している@yoneyoneyoです。
最近はサボっていますが、脆弱性報告やBugbountyなどもやっていたりします。

前回のブログではASM(Attack Surface Management)としてのCAAVの利点を紹介しましたが、そもそもなぜAttack Surfaceを探して、管理する必要があるのでしょうか。

しっかりと管理されている環境においては、WebサイトやDNSサーバー、VPN機器やルーターなど、インターネット上に公開されているサーバーやネットワーク機器(以下、「公開サーバー」と呼ぶ)を今更把握する必要はないと感じる方も多くいらっしゃると思います。しかしながら、実際には「一時的に使用するサーバー(例えばテスト用ですぐ閉鎖する)なので申請は無くても大丈夫」、「キャンペーンで使う一時的なWebサイトなので申請しなかった」「プロモーションのため急いでWebサイトを立ち上げる必要がある」など、様々な理由により、ユーザー部門が独自にIT機器やシステム、クラウドサービスを契約し、情報システムの管理部門(IT管理者)が把握できないケースが昨今問題となっています(シャドーITとも呼ばれたりします)。



管理されないサーバーが増えると…


こういったガバナンスが無視され公開されたサーバーは、企業のセキュリティポリシーが無視されていることも多く、管理が不十分(パッチが適用されない、使用後放置される、利用のための設定が不足しているなど)となりサイバー攻撃を受けることがあります。こういった現状を防ぐため、公開サーバーを把握、管理するためのASMと呼ばれるツールが話題となっています。 このASMですが、2023年5月29日に公開された経済産業省のガイダンスに記載されている通り、「ASMはリスク低減効果が期待される一方で、収集・分析する情報の不確実性などの実施にあたっての留意点が存在する。」とも書かれています。これはどういったことでしょうか。

経済産業省のガイダンスではいくつか注意すべき事項が書かれています。

  • 不正確な情報の検知
    • 自社で管理していないサイトが発⾒される点
    • 脆弱性情報の確度
    • 偽陽性・偽陰性(フォールスポジティブ・フォールスネガティブ)という点
  • 対象となる企業への影響
  • 脆弱性評価の⽅法
  • リスク評価指標の活用方法
  • 検索エンジン型の更新頻度
  • 例えば、「不正確な情報の検知」であれば、多くのASMのツールでは、様々なアルゴリズムや情報を用いて、関連する公開サーバーの特定を行うよう設計されています。しかしながら、多くのASMの製品では、見逃すくらいなら情報として表示する、ユーザーに正否を判定させる、この判断により更に情報をかき集める/判断することができる(賢くなる)というスタンスになっています。そのため、検出結果には多くの「自社で管理していないサーバー」が表示され、担当者は日々、自社管理のサーバーであるかの仕分けに追われます。

    以下、既存のASMツールの検出アルゴリズム例をいくつか紹介します。

    <検出アルゴリズムの例>

  • 別のTLD(Top Level Domain)もあなたのもの
    保有しているドメインのTLD以外のTLDも確保しているかもしれないという推測のもと、.com、.netなどを自社で管理している可能性があるとしてサジェストしてきます(弊社のmbsd.jpであれば、mbsd.comやmbsd.netなどがサジェストされる)。もちろんブランディングを守るため、他のTLDを事前に確保しておくケースはありますが、確保していないケースも多くあり、これらがサジェストされることで大量の「自社で管理していないサーバー」が表示される結果となります。

  • 隣のIPはあなたのもの
    オンプレミスが主流の時代では、サーバーを構築するためホスティングを行うと、/28、/27などのネットワークが払い出されるケースが多くありました。そのため、自社管理のサーバーを検出するためのロジックとして、IPアドレスを1つ、ずらした隣のIPはあなたのものではないか?というサジェストが行われることがあります(管理しているIPが192.0.2.1の場合、一つずらした192.0.2.2をサジェストする)。しかし、クラウドサービスを利用している場合、隣のIPは自社とは無関係の公開サーバーに割り当てられている可能性があります。

  • Passive DNS情報をそのまま表示
    ASMツールによってはDNSの名前解決履歴をデータベース化した(PassiveDNS)などで収集したサブドメイン情報をそのまま表示するようなケースもあります。過去の状況を追いかける場合には有効ですし、Bugbountyをやる場合であれば、CDNやWAFを適用する前のレコード情報が取得できる可能性があり、CDN/WAFを迂回してオリジンサーバに直接試してみるみたいな使い方ができます。しかしながら、運用を鑑みると現時点の情報が大切であり、名前解決できないサブドメインも多く含まれてしまい、これらの情報が有効であるかをユーザー側で確認するのは多くの労力を要します。


    このようにASMを有効に運用していくためには、体力がかかるものとなっています。
    CAAVには、公開サーバーの棚卸しや脆弱性の可視化を行う機能が実装されており、ASMとして利用することが可能です。CAAVのASM機能は上記の課題を解決した、いわばお手軽に利用できるASMとなっており、以下のような特徴を有しています。

  • 優先的に確認する必要がある情報に絞って表示する
  • 機械学習も活用し誤検知、過検知を抑え、信頼性の高い情報を表示する
  • 初期のチューニングにかかるコストや運用にかかるコストが少ない
  • 低価格での提供
  • CAAVを使用することで初期コスト・運用コストを抑えることができる

    これは、CAAVで掲げるビジョン「お客様に負担をかけないサイバーセキュリティ管理を提供します」の通り、ユーザーが「自社で管理していないサーバー」の対応に追われないよう設計されています。具体的には検索のロジックを更に深掘りし、これまでの脆弱性診断、ペネトレーションテスト、Bugbountyへの知見、また、機械学習を最大限活用し、仕分けを支援することで実現しています。

    また、CAAVはセキュリティチェックを行い、リスクを管理する(脆弱性管理)機能も有しております。経済産業省の導入ガイダンスのASMのプロセスでは、リスクの管理はASMのスコープではないとされていますが、Attack Surface情報を有効に活用するためにはリスクの管理は必要機能と言えます。CAAVのセキュリティチェックを行い、リスクを管理する(脆弱性管理)機能はまたの機会に紹介させて頂きます。

    CAAVを使うことで「リスクへの対応」までカバーすることができる

    今回はAttack Surface管理の必要性と注意点を解説しましたが、近いうちにドメイン/サブドメインを調査する手法も紹介してみたいと思います。

    CAAVにご興味を持って頂いた方は、こちら(https://portal.caav.jp/inquiry)からお問い合わせください。