タグ別アーカイブ: ゼロトラスト

ISMSを基盤としたゼロトラストの展開

CSAジャパン ゼロトラストWG 諸角昌宏

ゼロトラストに取り組んでいる組織が増えている中、ゼロトラストの戦略を曖昧にしたままセキュリティ製品の導入に走っているケースが見受けられる。ゼロトラストは、今までのセキュリティの考え方、特にリスク管理の延長線上にある考え方である。すべてのアクセスを検証する、最小権限の原則、継続的な監視とログ分析など、今までのどちらかというと静的なセキュリティ対策に対して、動的なセキュリティ対策にしていくことにより、現在のITシステムの環境に適合させていこうというものである。したがって、ゼロトラストの考え方や戦略を正しく理解し、自組織に適用していくことが求められる。

本ブログのベースになっている「ISMSを基盤としたゼロトラストの展開」資料では、ゼロトラストの考え方を理解するために3つのゼロトラスト導入戦略(NIST SP800-207、CISA成熟度モデル、NSTACモデル)を説明し、ゼロトラストの考え方や戦略の理解を深めたうえで、ISMSフレームワークにゼロトラストを採用する方法について考察している。したがって、ゼロトラストの戦略についてはそちらの資料を参照していただくこととし、本ブログではISMSフレームワークにゼロトラストを採用する方法についての考察を説明する。

なぜISMSフレームワークにゼロトラストを採用する方法を考えたか?

まず、ISMSフレームワークにゼロトラストを採用する方法を考察した理由について説明する。

ゼロトラストは、セキュリティ対策としては適切なものであるが、リスク管理として重要である情報資産の重要性について言及されていない。特定非営利活動法人デジタル・フォレンジック研究会のコラム第896号:「ゼロトラストアプローチとリスク論的アプローチ」(https://digitalforensic.jp/2025/10/20/column896/)において佐々木良一 理事(東京電機大学 名誉教授 兼同大学サイバーセキュリティ研究所 客員教授)が以下のように述べている。「ゼロトラストの考え方自体は適切なものであるが、同時にリスクアセスメントを中心とするリスク論的アプローチも併用しないと適切な対策にならない」。リスクについて、上記コラムでは「リスク=損害の大きさ×損害の発生確率」という工学分野の確率論的リスク評価の定義を使っている。情報セキュリティにおいてリスクは、「リスク=影響度x発生確率」と表現されるが、概念的には同じであり、ここでは影響の方が損害より広い概念として捉え、「損害の大きさ=影響度」と捉えることとする。ここで、ゼロトラストは、「損害の発生確率」と結び付けることができるが、「損害の大きさ」(対象システムの重要性)についてはカバーされていない。したがって、ゼロトラストにおいてリスク論的アプローチを併用することが重要であるということになる。 そこで、「ISMSを基盤としたゼロトラストの展開」資料では、リスク管理プロセスにゼロトラストを統合させることでこれを実現することを考察した。さらに、リスク管理プロセス(ISO 31000 / ISO 27005)にゼロトラストを統合させるという概念的な話よりは、リスク管理プロセスを中核に据えているISMS(ISO/IEC27001)のプロセスにゼロトラストを統合することで、より実際に利用できる方法となると考えた。ISMSは、日本では約60%の組織が認証を取得しているように広く普及しており、このフレームワークにゼロトラストを統合させることが有効であると考えた。なお、リスク管理プロセスにゼロトラストを統合させるには、NISTのサイバーセキュリティフレームワーク(CSF)などをベースにすることも考えられるので、ISMSに限定する話ではないことは述べておく。

ISMSフレームワークにゼロトラストを統合させる方法

ISMSを基盤としたゼロトラストの展開」資料では、以下の仮想のインターネットオーダーシステムを用いて、これに必要となるISMSのプロセスとそれに統合するゼロトラストについて説明している(本ブログの図は、すべてこの資料より引用している)。詳細については、そちらの資料を参照していただくとして、ここではそのポイントとなる以下の点について説明する。

  1. 資産特定の考え方
  2. リスクアセスメントにおけるリスクスコアの考え方
  3. 適用宣言書の考え方
  4. モニタリングおよびレビューの考え方

1. 資産特定の考え方
資産特定として、ゼロトラストで説明されているプロテクトサーフェスを用いた。プロテクトサーフェスは、ビジネス情報システムとして資産の集まりとして管理する方法で、理解しやすく、関連する一連のトランザクションフロー、アーキテクチャ要素、アクセスポリシーの作成が容易となる。したがって、プロテクトサーフェスごとに管理することで、従来の資産ごとに比べて管理しやすいことになる。また、ゼロトラストの段階的な導入をこのプロテクトサーフェスごとに行うことができるため、既存の資産はISMSで管理しながら、定義できたプロテクトサーフェスから順次ゼロトラスト化していくことが可能になる。もちろん、対象となる資産を従来ISMSで用いたものをそのまま扱うことも可能であるが、プロテクトサーフェスとして管理することの方がメリットがあると考えている。
以下が、オンラインオーダーシステムを想定したプロテクトサーフェスの例である。

2. リスクアセスメントにおけるリスクスコアの考え方
リスクスコアとして、CISAのゼロトラスト成熟度モデルの成熟度を使用し、以下の観点でリスクスコアを計算する。

  • 影響度:資産の重要性に基づいてプロテクトサーフェスの重要度を評価

  • 発生確率:ゼロトラスト成熟度で評価

ここで、発生確率として成熟度を使用する理由であるが、CISA成熟度モデル(従来 → 初歩 → 高度 → 最適)を「セキュリティコントロールの強度」とみなし、成熟度が上がるほど発生確率が低下するとして評価に利用することができると考える。また、成熟度の向上に応じてリスクスコアがどう下がるかを定量的に評価することが可能になると考える。

以下が、オンラインオーダーシステムを想定したリスクスコアの例である。なお、発生確率は同じレベルにおいても振れ幅を考慮して数値化している。なお、ここではプロテクトサーフェス単位でリスクスコア化しているが、プロテクトサーフェスに含まれるトランザクションフロー単位、あるいは、プロテクトサーフェスに含まれるそれぞれの柱単位にリスクスコアすることも可能である。

    3. 適用宣言書の考え方
    ISMSでは管理策に基づいた適用宣言書が必須となる。ここは、ISO/IEC27001の管理策に対してプロテクトサーフェスとしてどのような管理になるかを記述し作成することができると考える。
    以下が、オンラインオーダーシステムを想定した適用宣言書の例の一部である。

    4. モニタリングおよびレビューの考え方
    ここでは、ゼロトラストの特徴であるリアルタイム性を持たせたリアルタイム/継続的なモニタリングと自動化による改善を行うことを考える。ログ、テレメトリ、ユーザー行動分析(UEBA)などを用いて、リアルタイムにアクセスを監視し、継続的評価とポリシーの調整を繰り返すことで、ゼロトラストの成熟度を高めるように進める。これにより、ISMSを動的かつ継続的に補完することができるものと考える。
    以下が、オンラインオーダーシステムを想定したモニタリングおよび改善の例である。

    まとめ:ISMSフレームワークにゼロトラストを統合させるメリット

    ここで述べた方法によるメリットをまとめると以下の3点になる。

    1. ゼロトラスト化においてリスク論的アプローチを併用することを実現できる。
    2. ISMSの延長線上にゼロトラストを統合させていくことで、ゼロトラストを1から始めることによる労力、投資を抑えることができる。
    3. リモートワークの普及、クラウドサービスの普及拡大など、ゼロトラストの導入は組織の喫緊の課題であり、ISMSフレームワークをベースとすることでスムーズな移行およびスモールスタートが可能である。既存のISMSはそのまま維持・継続しながら、プロテクトサーフェスごとにできるところからやり、ステップアップしていくという方法が取れる。

    このような点から、ISMSという既存のフレームワークを利用することで、ゼロトラストへの効果的な移行が可能になると考えられる。今後は、これを実際にユースケース化していくことを考えていきたい。

    以上

    Log4Shellとゼロトラスト

    本ブログは、CSA本部のブログを著者の許可を得て翻訳したものです。本ブログの内容とCSA本部のブログとに相違があった場合には、CSA本部のブログの内容が優先されます。

    Log4Shellとゼロトラスト

    このブログは、Appgateのこちらの記事を元にしています。
    著者:Jason Garbis、Appgate

    Log4Shellの脆弱性が発覚してからわずか数週間しか経っていませんが(関連する問題はまだいくつか残っています)、世界中のセキュリティチームは、診断、検証、更新、コミュニケーションのために奔走しています。一歩下がって振り返るにはまだ少し早いかもしれませんが、私はいくつかの考えをコミュニティと共有したいと思います。

    Log4Shellは、悪用が容易であるだけでなく、一般的に攻撃対象がすべてのユーザーに利用可能であり、非常に陰湿な脆弱性です。多くの場合、そのユーザーは認証前の状態です。場合によっては、悪意ある者がウェブサイトのログインページから直接攻撃を仕掛けて成功させることも可能です。さらに、このエクスプロイトは、通常、信頼されたゾーンの企業ネットワーク上で動作するロギングサーバー自身によって実行されます。ロギングサーバーは、インターネット上の悪意のあるサイトにアウトバウンドのリクエストを行い、悪意のあるコードを取得し、ローカルで実行します。

    この種の脆弱性に対しては、ゼロトラストセキュリティとその中心的な考え方である最小権限の原則を実施することの重要性を示しています。それは、不必要にインターネットにさらされているアプリケーションがあまりにも多いからです。ZTNA(Zero Trust Network Access)技術を使用すると、ユーザーがアクセスを許可され認証されない限り、すべてのリソースを見えなくし、攻撃対象を減らすことができます。

    Log4Shellは、認証のみのセキュリティではあまりにも弱すぎることを示す好例で、悪意のあるアクターにログイン画面を見せるだけでも悪用されてしまいます。ゼロトラストの最小権限の原則は、プライベートなアプリケーションがネットワーク上に隠れていることを保証し、悪用される可能性を最小限にします。

    もちろん、会社のWebサイトのように、公開しなければならないアプリケーションやWebサイトもあります。しかし、企業はセキュリティの考え方を変えることで、顧客専用のWebアプリケーションに対しては、実際の顧客にしかアクセスできないようにすることを検討すべきです。

    例えば、ビジネス向けの出荷・物流サービスを提供している企業であれば、顧客のログインページをあらゆる攻撃者に公開する理由はありません。ゼロトラスト方式を採用すれば、正当なお客様だけがログインを試みることができ、攻撃者がログインサイトを悪用することを防ぐことができます。このような安全性の高いアクセス方法をお客様に要求することは、合理的であるだけでなく、お客様に対するビジネスのセールスポイントにもなり得ます。

    一般に公開する必要のあるサーバーやサイトについては、組織はゼロトラストの原則である最小権限モデルを適用しなければなりません。これらのサーバーは、広い範囲の社内ネットワークにアクセスできないようにする必要があります。すべてのアクセスはデフォルトでは拒否され、定義されたポリシーに基づいて明示的に許可されたアクセスのみが許可されなければなりません。このモデルは、インターネットへのアウトバウンドアクセスにも適用する必要があります。

    企業は、ネットワーク上で稼働しているリソースだけでなく、それらのリソースが何にアクセスすることを許可されているのかを明確に把握し、明確に定義されたゼロトラストポリシーによってアクセスを許可する必要があります。これは、内部のサーバー間のアクセスについても、正当かつ合理的な要件です。セキュリティチームは、必要なアクセスを許可するためのポリシーを文書化し設定する責任をITチームやアプリケーションチームに負わせなければなりません。また、セキュリティチームは、それ以外のすべてのアクセスを制限する責任も負わなければなりません。

    管理者からサーバーへのアクセス(アップデートや設定変更など)には、ITサービスマネジメント(ITSM)のビジネスプロセスに基づいてアクセスを制御するゼロトラストシステムを用いて、定義されたメンテナンスウィンドウを使用すべきです。さらに進んだ組織では、サーバーをペットではなく家畜のように扱うDevOpsのアプローチを検討する必要があります。つまり、サーバーのアップグレードやメンテナンスは行わず、マスターイメージを更新して新しいサーバーをデプロイすることになります。

    サーバーからインターネットへのアクセスの場合、ほとんどのサーバーは任意のインターネットサイトにアクセスする正当な必要性はなく、むしろアクセスを許可することはセキュリティ上の弱点となります。組織は、このようなアクセスをブロックするか、許可された厳格なサイトに制限する必要があります。DNSやNTPなどのコアネットワークやインフラサービスは、企業が管理する内部システムに限定する必要があります。

    Log4Shellはまた、ソフトウェアサプライチェーンのセキュリティと完全性に関するもっともな疑問を提起していますが、これについては別のブログ記事で取り上げます。ソフトウェアをどの程度信頼しているかにかかわらず、「侵害を想定する」というゼロトラストの原則に基づいて運用する必要があります。オープンソース、ベンダーから提供されたソフトウェア、または独自に作成したソフトウェアが危険にさらされていると想定する場合、最低限、ソフトウェアのインバウンドとアウトバウンドを制限し、すべてのアクセスがポリシーによって明示的に制御されていることを確認し、実際の動作を記録して監視する必要があります。

    今日のリモートワークの世界における複雑な脅威の状況、脆弱性が発生する頻度、ハイブリッド環境の複雑さ、デバイスの急増を考慮すると、多くの企業や政府機関は、ゼロトラストへの移行に急速に乗り出しています。ZTNAソリューションは、以下の方法で移行をスムーズに行うことができます:

    • 例えば、SPA(Single Packet Authorization)を使用して、ポートを積極的に隠蔽し、インターネットに接続されたサーバーを権限のないユーザーから見えないようにします。
    • デバイスとユーザーのリスクへの対応:きめ細かなZTNAポリシーは、限られたリスクに基づいてユーザーデバイスに適切な権限を調整し付与することができます。
    • サーバーやユーザーデバイスとの間のトラフィックを制御します。多くのZTNAソリューションは、「アップルール」(例えば、ユーザーのモバイルデバイスがデータベースにアクセスする必要がある場合など)として知られる、リソースのやり取りに対するユーザー/デバイスのポリシーを必要とするユースケースでうまく機能します。しかし、「ダウンルール」、つまりサーバー、サービス、リソースから「下方向」のユーザーデバイスとのやりとりを扱うこともサポートされるべきです(例:リモートデスクトップのサポートやエンドポイントプロテクションの集中管理プラットフォーム)。この両方をサポートするZTNAプラットフォームを見てください。
    •  幅広いITおよびセキュリティエコシステムの統合をサポートします。ZTNAは、脅威インテリジェンスツール、SIEM(Security Incident and Event Management)ソリューション、EDR(Endpoint Detection and Response)プラットフォーム、ITSMソリューションなどと統合する必要があります。
    • エンタープライズスケールとスピードでの運用。多くの組織は単一のユースケースからスタートしますが、最終的には、ZTNAソリューションは、組織全体のアクセスコントロールの全負荷に対応できなければならず、また、ネットワークやクラウドエコシステム全体のすべてのアプリケーションを含む、拡大するフットプリント内の負荷レベルの増加にも対応できなければなりません。

    この数週間は、情報セキュリティに携わる多くの人々にとって困難な時期でした。あなたが実務者であれば、その献身的な努力に感謝します。もしあなたが組織のビジネスサイドにいるのであれば、企業を守るために夜も週末も働いているセキュリティチームやネットワークチームに、どうか辛抱強く対応していただきたいと思います。

    Log4Shellは、これまでに見たことのない最悪の脆弱性であり、セキュリティに対するゼロトラストアプローチの必要性とその価値を明確に示しています。この事件をきっかけにして、ゼロトラストへの移行を始めたり、加速させたりしてください。無駄にする時間はありません。ゼロトラストの原則とアプローチは、明らかに優れたセキュリティを提供することが証明されており、あなたには組織をより良い場所へと導く責任があります。今こそ、始める時です。

    本当のSDPよ立ち上がれ! ~ Will the real SDP please stand up?

    本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。


    本当のSDPよ立ち上がれ!

    原文: 2019年7月10日
    日本語版: 2019年7月23日

    Software Defined Perimeter(SDP)という用語は、ゼロトラスト(Zero Trust)モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス(CSA)によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

    ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント(PDP)とポリシー実行ポイント(PEP)モデルになります。SDPの認証プロセスにおいては、「コントローラ(Controller)」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ(Gateway)」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

    SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

    通信前の認証

    SDPのもう1つのユニークな要素はSingle Packet Authorization(SPA)です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

    もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

    SDPはどのくらい強力ですか?

    2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

    私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

    原文 “Will the real SDP please stand up?” は、こちらを参照してください。