目次

    脅威ベースのペネトレーションテスト(TLPT)とは?|金融機関が注目するサイバー攻撃対策

    大橋 謙介
    2020年2月14日

    business people group with  headphones giving support in  help desk office to customers, manager giving training and education instructions

     最近金融機関を中心として、脅威ベースのペネトレーションテスト(TLPT)の実施を検討するお客様が増えています。お問い合わせを受けご説明に伺った際、お客様が共通で持たれているのが「今までのセキュリティ対策と何が違うのか?」という素朴な疑問です。


     TLPTの検討を開始したものの、“これまでも対策の有効性は「脆弱性診断」や「ヒアリングによるアセスメント」を実施して確認している。TLPTでは何をテストするとどういう効果が得られるのか?”ということを明確にできていないようです。


     本記事では、複数企業における、お客様の立場でのCSIRT運用、TLPT(Whiteチーム運営)に関わるコンサルティング実績を基にして、

     

    ・これまでのセキュリティ対策は何ベースなのか
    ・脅威ベースとは何か、なぜ必要なのか


    などのポイントを、事例を用いてわかりやすく解説します。

     

    注目を浴びる「脅威ベースのペネトレーションテスト」

     脅威ベースのペネトレーションテスト(以下、TLPT)の検討開始は、G7 サイバー・エキスパート・グループ(CEG)による、以下の3つの文書※ が起点になっていると考えられます。(2018年10月)

    • ① 金融セクターのサイバーレジリエンス強化に向けた次のステップ 背景説明
      ② 脅威ベースのペネトレーションテストに関するG7の基礎的要素
      ③ 金融セクターにおけるサードパーティのサイバーリスクマネジメントに関するG7の基礎的要素

    ※金融庁 「脅威ベースのペネトレーションテスト」及び「サードパーティのサイバーリスクマネジメント」に関するG7の基礎的要素の公表について

     

     文書①では金融セクターにおける近年の執拗な攻撃に対するサイバーレジリエンス(サイバー攻撃への耐性やダメージからの回復)の改善を目的として②③を次のステップと位置付けた背景が示されています。
     その上で、文書②では、まず自社のサイバーレジリエンスを向上させること、文書③では自社だけでなくサードパーティのサイバーレジリエンスの相互での確認が、サイバーリスクマネジメントの有効なプラクティスを検討する際に、金融機関にとって有益とあります。

     これを受け、まずは②自社のサイバーセキュリティレジリエンス向上を目指すとして、「脅威ベースのペネトレーションテスト(TLPT)」の実施を検討するお客様が増加しました。金融業界でのこうした動向を参考にして、例えば製造業においても、サプライチェーンにおける対応能力の実効性の強化の文脈で、G7の考え方を取り入れる例もあります。

     

     さらに、金融情報システムセンター(FISC)から「金融機関等におけるTLPT実施にあたっての手引書」(以下、TLPT手引書と記載します)が発刊され(2019年10月)、より手順が具体化したことも、TLPT検討に踏み出すきっかけとなっていると思われます。

     

     ご相談頂いたお客様は、上記文書やセキュリティベンダーの解説文等で定義された、「脆弱性診断」「ペネトレーションテスト(PT)」「脅威ベースのペネトレーションテスト(TLPT)」の特徴を抽出、比較すれば社内で施策の有効性を説明できるはずと考えるのですが、そのアプローチで行き詰る場合が多いようです。そのことが、「もう少し簡単な言葉で既存のセキュリティ対策との関係を示しながら、執拗な攻撃に耐える上でのTLPTのメリットを示せないか」といったご相談につながっていると思われます。

    【 参 考 】TLPT手引書における、TLPTの定義

    ペネトレーションテストにおいて、(金融機関等の)コントロール下で、実在の攻撃者の戦術、テクニック、手順を模倣することにより、金融機関等のサイバーセキュリティレジリエンスを侵害しようとする、攻撃の試行である。これは特定の脅威インテリジェンスに基づき攻撃を試行するものであり、予備知識と、業務への影響を最小限に抑えつつ、金融機関等の人、対応プロセス、システムに焦点を当てた攻撃を試行するもの。

     そこで本記事ではこうしたお悩みに答えるべく、脅威ベースとはなにか?TLPTと脆弱性診断の違いは?といった点について次章以降で解説していきます。

     なお、本書は事例に基づいているため、特定のお客様社内の推進にあたり、TLPTの定義に対し解釈を入れている部分があります。

    セキュリティリスクマネジメントにおける「脅威ベース」の位置づけ

     一般的にセキュリティリスクは、「情報資産価値×脆弱性×脅威」で表すことができます。よって、セキュリティリスクを抑えるということは、それぞれのパラメータを減少させるということです。これらのパラメータを用いて、「脅威ベースとは何か」を考えてみます。

     

    Secure SketCH_リスク増加の要因とコントロール図1. リスク増加の要因とコントロール

    情報資産の価値

     まず、企業における情報資産価値の増加を考えてみます。情報資産価値は「機密性」「完全性」「可用性」の三つの観点で評価されますが、いずれも「新事業の立ち上げ」などの場面で、サプライチェーンとの情報交換をして製品サービスの付加価値を増やしていけば、それに比例して増加していきます。

     

     減少させることを考えるならば、新事業や技術革新をあきらめるしか無いため、原則として企業価値の向上に合わせて増加するものとなります。

    脆弱性

     次に脆弱性ですが、新事業自体の「仕組み」の脆弱性(例:ポイント還元率の差を利用し無限にポイントを増やすなど)や、新しい技術に潜む脆弱性(クラウドサービスの乗っ取りなど)は、新事業への取り組みに比例して増加します。脆弱性はコントロール可能であり、事業を支える機能が悪用されないよう対策を実施することで抑え込むこととなります。


     脆弱性を認識する方法として「ヒアリングによるアセスメント」があります。まず必要と思われる対策を網羅的にチェックリスト化し、自社における対策状況について“〇やっている/×やっていない”をつけるといった手法です。
    ×が残存している脆弱性であり、脆弱性がどれほどの脅威にさらされ、それを突かれた時の影響度を測ることで、リスクを高・中・低として評価します。その評価結果が対処の優先度の根拠となります。

     

     「脆弱性診断」も同様で、脆弱性を網羅的に認識して対処する手法です。まずスキャンツール等により可能な限り脆弱性を収集します。その上で検出された脆弱性を評価し、対策リストを作成した上で脆弱性を対処します。

    脅威

     最後に脅威ですが、外的要因であるため“来るもの拒めず”が原則です。そしてその企業が提供するサービス製品が魅力的になるほど、コストをかけてでも奪いたい情報や妨害したいサービス等があるため脅威の執拗さは増していきます。


     脅威自体のコントロールはできませんが、将棋盤をひっくり返して考えると同様、守る側から攻撃者側に視点を変えることは対策を考える上で有効な手段です。棋士が対局相手をどのように投了させるのかを考えて手を組み立てるのと同じように、攻撃者がどのような手を使って来るか( ActiveDirectoryを狙うのか、標的型メールを送るのか)を組み立てます。そして最終的に、自社のどの重要情報を奪い取ることなのか、改ざんして金銭等をごまかせるのか、サービス停止に追い込んで脅迫できるのか、といった仮説を立てます。仮説を立てるには過去の棋譜を目の前の勝負に生かすことが有効で、これが脅威情報の活用にあたります。この思考方法が
    Threat-Led(脅威ベース)と考えています。

     

    脅威インテリジェンスを活用するための3つのポイント|サイバー分野の情報戦略

    脅威ベースで仮説を立てて検証する

     「脅威ベースで仮説を立てる」とはどういうことでしょうか?

     先日、お客様のサイバーセキュリティチームとの忘年会があり、その時の会話がわかりやすい例でしたのでご紹介します。

     忘年会の会場は立食形式で比較的自由に入室可能です。また、グループ会社複数社の合同忘年会であり、顔見知り以外の方とも歓談できました。会場入口(道路)に“〇〇社様会場”といった看板が出ています。

     この状態をどう思いますか?迷わず来場できるし、広く歓談できるので「良いこと」だと思いますか?

     脅威ベースの目線を持っているサイバーセキュリティチームのある方から、以下のような話がありました。

    「最近、ビルオーナーが店子に貸し出す前から盗聴器を仕掛ける例があるそうだ。ちなみにこの周辺にも複数ビルを持っていたはず」

     

    これを受けセキュリティチームとして調査開始です。(ビル名等で検索しオーナーを確認しただけですが)ここまでが基本的な脅威情報の用い方です。続いて

     

    「でもさ、この会場は盗聴器なんか仕掛けなくても・・・」

    • ① 〇〇社様会場という看板が人通りのある道路にあれば、〇〇社のサービスに興味がある
      産業スパイが通り掛かれば目をつけるだろう(脅威の動機を生起させる脆弱性)
    • ② 合同忘年会のため参加者は顔見知りとは限らないため、第三者が入ってきて「聞き耳」を
      立てることができる(脅威が悪用する脆弱性)
    • ③ 第三者に会話が漏洩(業務の話題や年末のねぎらいに含まれるインシデント情報など)する
      可能性があるため、サイバーセキュリティチームとしての会場選択が成っていない

     

     よくある光景を当たり前とせず、脅威情報を基に利便性の裏側にあるリスクを考えることが、「新たな気付き」を導き出します。これが脅威ベース(攻撃者目線)を用いる最大のメリットです。極論すると、次回から会場選択の条件に「看板が建屋外に出る店は選択しない」が要件として加わり、酒席からの漏洩リスクを減らすことができるかもしれません。

     

     冗談のような例ですが、「思わぬところにある脆弱性」に気付けたことが成果なのです。

     

     脅威ベース(攻撃者目線)は、攻撃者の目的を効率よく達成するシナリオを導き出します。上記の例で言うと①②は脆弱性で、③が漏洩というリスク(ゴール)になる3段階のシナリオです。この場合は「道路上の看板」「第三者に気が付けない」の2つが脆弱性ですが、たった2つの脆弱性を使えば目的が達成できるのだから、少ないコストで攻撃できる(二手詰)。よってサイバーセキュリティチームとして成っていないと評価したのです。

     また、もしかしたらすでに、見知らぬ人が居たら幹事が声がけするといったルールが備わっていたかもしれません。幹事や現場を仕切る若手が、どれほど気が利くのかの動きをテストすることも有効かもしれません。

     

    Young businessman sitting in office chair in front of a wall with cloud thought sketched on a chalkboard above his head-1

     

     TLPTに話を戻します。TLPTは、ペネトレーションテスト(PT)に入る前に、Threat-Led(脅威ベース)の考え方で、攻撃者目線の仮説を立てます。自社の魅力的な事業を洗い出し、事業の関係者を巻き込んだ上で、「自分たちがされては困ること」を「攻撃シナリオ」として用意します。

     

     先の例は2つの脆弱性を組み合わせた攻撃で成功にたどり着きました。しかし、実際はシステムや運用・業務内容・物理構成など、多数のサービスの構成要素の組み合わせとなるため複雑です。そのようにして、内情を把握している者が、攻撃者に成り代わって導出した有効な脆弱性の組み合わせが「攻撃シナリオ」です。

     

     ただしここで気を付けることは、内部事情に偏った脅威を設定してはいけないということです。脅威情報(世の中の攻撃動向)を調査の上、発生する蓋然性があるシナリオに調整していく必要があります。また内部者である社員等しか知らない情報は、Redチームが行き詰った際のヒントとし、最初から教えないようWhiteチームがコントロールします。実際のAPTのような長期戦想定を、定められた時間でこなす必要があるからです。情報が欲しければ、例えば上司を装ったメール等で引き出してもらうのですが、開封まで待つことで時間切れとなるわけにはいきません。

      

     併せて、本物の攻撃者が内情をどこまで掴んでいるかも調査します。例えば自社の「業務マニュアル」のような、社内業務の脆弱性を突く上で有効な情報が、インターネット上やダークWebに公開されていないか、といった観点です。もし公開されている場合は、攻撃者が知っている内部事情を定義できるため、攻撃シナリオの精度を高めることができます。

     

     脅威の目線の取り入れ方をお伝えしましたが、この概念が強いほど脅威ベースが高まっていくと考えられます。TLPT手引書におけるペネトレーションテストの定義は「脆弱性を利用して、侵入の可否、および侵入した場合の影響を検証する手法」とあります。この時点で脅威の目線であるのですが、今回のシナリオ作成ではそれに加え、内部者が敵に回ることでAPTに近い執拗さを出し、世の中の脅威情報と合わせ実在する攻撃の模倣に近づけていますので、上記手順は脅威ベースが高い、つまりTLPTと言えるはずです。

     一般論として、少なくとも世の中の脅威情報を考慮した攻撃シナリオを用意しないと、TLPTではなく、ペネトレーションテスト(PT)と解釈されると考えています。

     

     こうして作成されたシナリオに基づき、ペネトレーションテスト(PT)を実施し、仮説であるシナリオを検証していきます。TLPTは「攻撃者目線で収集した情報(TL)に基づく、ペネトレーションテスト(PT)による仮説検証」と解釈できます。

     

    脆弱性ベースと脅威ベースの使い分け 

     冒頭で、「ヒアリングによるアセスメント」「脆弱性診断」は、最初に脆弱性を網羅的に洗い出した上でそのリスクを評価する、と説明しました。それに対し、Threat-Led(脅威ベース)は目的を達成するための最も効率が良い打ち手(脅威シナリオ)に基づいた検証になります。“多く”の脆弱性を発見することも大事ですが、攻撃者が楽に目的に迫れる、“短い”数手詰みに関わる脆弱性を探すことがポイントです。

     

     もし既存の対策であるヒアリングや脆弱性診断に「XX-Led」とつけるのであれば、洗い出した脆弱性に基づいていることから「Vulnerability-Led(脆弱性ベース)」と言えるのではないでしょうか。脆弱性ベース(対策者目線)と脅威ベース(攻撃者目線)は互いに補完するものであり、どちらが優れているといったものではありません。TLPTを導入したからヒアリングによるアセスメントは不要といったことは無く、組み合わせて利用します。

     

     脆弱性ベース(対策者目線)の利点は、少なくとも「自分たちで気が付ける範囲の脆弱性」については除去された状態にしやすいことです。定義されたベースラインからのギャップを埋めていけばゴールが見えてきます。ただし、このアプローチは「対策すること」がゴールとなりがちで、本来のゴールである「守られていること」「何かあったら対処できること」にたどり着けていない可能性があります。

     

     お客様を訪問した際に、 

     

    「すでにSOCを導入しているが、これまでクリティカルな発報はこれまで出ていない。本当に事故が起きていないのか、実は検知できていないのかは、まだ検証できていない。TLPTで実際に疑似攻撃を起こして検知できるか検証したい」

     

    という言葉がありました。Vulnerability-Led(脆弱性ベース)に基づき導入した対策をThreat-Led(脅威ベース)で検証したいということです。まさに、これがTLPTの目的となります。

     

    脆弱性診断とTLPTの違い

     Vulnerability-Led(脆弱性ベース)に基づき導入した対策をThreat-Led(脅威ベース)で検証する。この関係が最終的に手段として「脆弱性診断」と「TLPT」にどのように現れるのでしょうか。
     
    Secure SketCH_脆弱性診断と脅威ベースのペネトレーションテストの違い図2. 脆弱性診断とTLPTの違い
     
    【 注 】ペネトレーションテスト(PT)の位置づけですが、先程お伝えしたように脅威目線の度合いによるため、図2において明確な線引きが表現できませんでした。実際お客様の話を聞くと、脆弱性診断において人手で検証する度合いが大きいものを指す場合や、ペネトレーションテスト実施業者の選定時に「脅威情報をどれ程活用しているか」を確認する場合など幅広です。筆者の経験則では、ペネトレーションテストは図2の脆弱性診断とTLPTの間に存在すると考えています。

    目的

     TLPTではシステムやIT資産における技術的な対策強度の評価に加え、「攻撃の検知と組織的対応力の評価」が定められています。先に引用したお客様の言葉であるSOCの検知・発報力の検証の延長として、発報を受けたCSIRTが正しく対処できるかも確認することとなります。また、「このような脅威に対応できず回復できなかった」というシナリオは報告書としてまとめられます。被害規模を想定し、経営判断可能な情報をまとめ、必要であれば態勢見直しが計画されます。

     対して脆弱性診断は、システムが疑似攻撃を防げるかを技術的に検証し、システム的な更新や運用見直しで対応することが目的となります。(例:システム的な脆弱性の原因となったパッチの適用と、パッチ適用の運用双方の見直し)

    評価観点

     TLPTでは評価観点として「テストゴール」が定められます。脆弱性診断は基準や規格に沿って脆弱性を洗い出し評価する場合が多いですが、 TLPTは事業や組織に重大な影響を与える事象を引き起こせるかになります。例えば侵入者がシステムに侵入できなかったとしても、ファイルサーバやごみ箱漁り、宴会で聞き耳を立てるといった行為で必要な情報を奪い取れるのであれば手段は選びません。(手段を選ばないと言っても、本番システム・業務に悪影響を与えてはいけません)

    評価対象

     このようにTLPTは手段が多岐にわたることから関係者を幅広く招集してブレスト形式でシナリオを作成します 。その上で「騙される人」「攻撃を検知対処する人」「攻撃者に加担する人」といった役割を分担していきます。そのため、脆弱性診断と比べて関係者が幅広くなっています。これは計画段階で組織についてのスコープを決定する際に行なわれ、対応能力向上に資する詰将棋の盤面の定義に相当します。

     幅広く招集した内部者の知見を使い、既存の対策を踏まえて乗り越えてくるシナリオを用意することで、疑似攻撃の成功や痕跡の残存が増え、SOC、CSIRTがそれを検知対処できるかが問われることになります。

    実施時期

     目的と実施方法が異なることが、実施時期の差として出てきます。脆弱性診断は、自分が気付ける脆弱性は可能な限り早く気が付けることが望ましいと言えます。そのため開発初期段階からのDAST/SAST、およびリリース直前には結合テストと並行した脆弱性診断が行われます。

     対してTLPT(脅威ベース)は「運用のほころび」も含め発見する必要があります。そのため運用開始後から一定期間を置いてからの実施が望ましいと考えます。「運用のほころび」とは、攻撃者から見て魅力的な情報(目的を叶える上で有効)な脆弱性 が、利便性を欠く等を理由に悪用しやすい状態にあることを指します。
    • 本番システムから持ち出した本番データをファイルサーバに放置している
    • 本番プログラムをリリースするシステム上にソースコードが残存し、DB接続パスワードが読み取れる
    • 上長からの指示であれば正規のオーダー以外の経路で担当者が本番アクセスすることが常習化している
    • 特権IDのパスワード変更が滞っており再利用できる
    • 広報用SNSアカウントが業務外利用されている
    • 社内Active Directoryのドメイン名や社内サーバのホスト名などが漏れている

     

    ▼合わせて読みたいブログ

    ペネトレーションテストとは?脆弱性診断との違いや脅威ベースの考え方

    TLPT実施に向けて

     TLPTで対象とすべきシステムは、事業や組織に重大な影響を与えるシステムです。選定の根拠は大きく3つあります。

    • 脅威情報(世の中の攻撃動向)に基づき狙われやすい傾向にある
    • システムの重要性区分(機密性・完全性・可用性)が高い
    • 外部性(障害時などによる社会的影響)があり、複数のシステムと協調することで脅威にさらさせることが多い


     こうやって選定されたシステムに対しTLPTを実施することの合意形成・説明と併せ、疑似攻撃によるシステム停止等のリスクを回避するための動きが必要になってきます。脆弱性診断はテスト環境で実施することもありますが、TLPTは本番環境を対象とすることで効果が発揮されるため 、事前にどこまで疑似攻撃を仕掛けてよいのかを決定する必要があります。


     そのためTLPTの推進は、シナリオ作成から完了までを通して、多くの人との調整が伴います。疑似攻撃によるシステム影響が考えられるのであれば、TLPTを中断し手順の見直しも必要です。また、プロセスも評価の対象とすることから、システムオーナー(ユーザ)だけでなく、CSIRTやシステム運用部門を含め調整範囲となります。この調整は、社内事情を知っているお客様と、外部コンサル等のTLPT運営経験者の共同作業となります。(Whiteチームの運営)


     これまで積み上げてきたセキュリティ対策の妥当性を評価し、自社のセキュリティ対策の耐性・限界を知ることは、今後のセキュリティ対策の明確な道標になると考えています。

     

    新規CTA

     

     

    facebook linkedin twitter hatena bookmark
    資料ダウンロード

    メルマガ登録

    人気記事

    人気e-Book