リーン・トラストは、ゼロ・トラストの対抗として2019年にGartner社が提唱した概念です。全ての信頼を”0″に無理やりするのではなく、信頼して良いもの・ダメなものをリスクに応じて分けて考えることで最適化しましょうというアプローチになります。これは、在庫管理の例で考えるとわかりやすいと思います。どちらが現実的なアプローチでしょうか？

	ゼロ・トラスト	リーン・トラスト
不良品に対する考え方	不良品を出さない	不良品はどうしても出てしまう
不良品の数	0	一定の割合
準備する在庫の数	0	適切な数
不良品が出てしまった場合	迅速に対応できない	迅速に対応できる

“不良品” を、 “本来は信頼してはいけないが誤って信頼しまった認証” と読み替えるとどうでしょうか？インシデント・レスポンスやサイバー・レジリエンスが叫ばれる現在では、これを0にすることは非常に困難です。

リスクをどう担保するか？

リーン・トラストは、一定のリスクを許容する考え方です。では、そのリスクをどのように担保すれば良いでしょうか？


ゼロ・トラストでも『すべてのデータソースとコンピューティングサービスをリソースとみなす』とNIST SP800-207の中の『ゼロトラスト 7原則』で定義されていますが、リーン・トラストではエンドポイントの保護を最重要視することでリスクを担保します。サイバー攻撃が巧妙化する中、攻撃の侵入経路は多様化しているため全ての脅威の遮断が不可能な状態では、信頼が構築されていない相手とやりとりをするためにはエンドポイントの保護が不可欠だからです。

リーン・トラストに対応したフレームワークは？

ゼロ・トラストでは、前述のNIST SP800-207やForrester Researchが、ゼロ・トラストの考え方を基にしたフレームワークとしてZTA（Zero Trust Architecture）を公開しているため、それを参照することで構築方法が理解できます。Gartner社はゼロ・トラストでのセキュリティ対策に加え、ネットワークの最適化・快適化も含むフレームワークとして、2019年にSASE（Secure Access Service Edge）のフレームワークも公開しました。


リーン・トラストの考え方を基にしたフレームワークとしては、CARTA（Continuous Adaptive Risk and Trust Assessment）があります。こちらもGartner社が”Adaptive Security Architecture”の進化形として2010年に提唱し、2017年頃から再度注目を集めている、リスクと信頼の適応評価に基づく継続的なサイバーセキュリティ評価のフレームワークです。こちらを参照することでリーン・トラストの構築方法が理解できます。

リーン・トラストは、ゼロ・トラストの玄関になり得るか？

後述しますがCARTAにはCASBやUEBAなど、SASEの要件と被るものが含まれます。前述の通りSASEにはZTAが含まれます。従って、ZTA・SASE・CARTAは完全に独立はしておらず、ゼロ・トラストとリーン・トラストも独立した関係ではありません。そのため人によっては、ZTA→SASE→CARTAのようにステップアップしていきましょうといった説明をされる方もいます。

しかしながらZTAですら範囲が広く、対応するには相応の時間がかかります。2021年9月にGartner社はHype Cycle for Cloud Security, 2021の中で、SASEから一部の要件だけを抽出したSSE（Security Service Edge）という概念を発表しました。この理由は、完全なSASEに移行するには数年単位での時間を要することがわかってきたためです。

※黄色文字の4機能については、2024年までに30%の企業が導入予測とされている優先度の高い機能を指します。


このような状況下で、3ステップを踏襲して最終的にリーン・トラストのCARTAを実現することが現実的なのかどうか、私は懐疑的です。それよりは、ゼロ・トラストよりも現実的な考え方であるリーン・トラストのCARTAを入口として構築し、ZTA・SASEをロードマップに置く方が良いと私は考えています。

リーン・トラストの構築方法は？

最後に、リーン・トラストを構築するためのフレームワークであるCARTAの要件（7原則）について説明します。

1. ワンタイム セキュリティ ゲートを置き換える 1段階の認証ではなく、攻撃保護とアクセス保護の2つのサイクルを継続的に行うために、EPPにはEDR機能の追加、Firewallにはトラフィック解析機能の追加などが有用。 EPP（Endpoint Protection Platform）： マルウェアによる攻撃を水際で防ぐことを目的として、ファイルベースのマルウェア攻撃をシグニチャ（定義ファイル）や機械学習、振舞い解析などで検知し調査分析や修復を支援するエンドポイントセキュリティ製品 EDR（Endpoint Detection and Response）： 端末にマルウェアの侵入を防ぐための対策だけでなく、万が一侵入を許してしまった場合に備えて、その存在をいち早く検知して脅威を除去することを可能にするエンドポイントセキュリティ製品

2. リスクを継続的に発見・監視・評価・優先順位付けする外部攻撃・IAM・データ・BCMにおいてProactive/Reactive（事前/事後）のリスク調査を継続的に評価・分析することを前提に、どの程度のセキュリティリスクであれば受け入れられるか、優先順位をつける。 IAM（Identity and Access Management）： ユーザー ID の管理・プロビジョニング、アクセスの認証・許可などを管理し、正しい個人を、正しい理由で、正しいリソースに、正しい回数アクセスさせるためのソリューション BCM（Business Continuity Management：事業継続マネジメント）： 事業継続計画の策定から、その導入・運用・見直しという継続的改善を含む、包括的・統合的な事業継続のためのマネジメントのこと

3. リスクと信頼の評価を早期に実行する DevSecOpsの概念と密接に関連。セキュリティを開発プロセスに組み込まなければならない。サードパーティ製品やデジタルサービスプロバイダーなどの場合も同様。 DevSecOps： 開発のチーム（Development）と運用のチーム（Operations）が互いのミッションを補完することにより、ビジネスにおけるシステムの有用性を高め、迅速かつ確実な実装と運用を実現する概念の”DevOps”から派生した、DevOpsによる開発と運用にセキュリティを加えた概念

4. 包括的にあらゆる種類のリスクを測定する ボトムアップ型の可視化に加え、トップダウン型の可視化も行うためにはUEBAやCASBなどを利用したユーザーの行動分析が有用。 UEBA（User and Entity Behavior Analytics）： ユーザーおよびエンティティ（実体）の振る舞い解析。ネットワーク内の人間や機械による通常の振る舞いと異常な振る舞いをモデル化し、疑わしい振る舞い、攻撃の可能性を特定すること CASB（Cloud Access Security Broker）： クラウドサービスの利用状況を可視化/制御するために、ユーザーとクラウドサービスの間にコントロールポイントを設けること

5. 迅速な検知と対応のために自動化、AIを分析に利用する SOCやSOARなどを利用することが有用。 SOC（Security Operation Center）： 24時間365日体制でネットワークやデバイスを監視し、サイバー攻撃の検出や分析、対応策のアドバイスを行う組織 SOAR（Security Orchestration, Automation and Response）： セキュリティ運用の自動化及び効率化を実現する技術を指し、インシデント対処の自動化・インシデント管理・脅威インテリジェンスの活用の3本柱からなるソリューション

6. サイロ（孤立）化しないように統合されたセキュリティを構築する 現在の攻撃手法はサイロを超えて横断的に広がるため、SIEMでの相関分析やSTIX、TAXIIに準拠した脅威情報、金融ISACなどで共有される脅威情報などの利用が有用。 SIEM（Security Information and Event Management）： 複数製品のログを一元管理し、相関分析を行う STIX（Structured Threat Information eXpression）： 米国政府が推進しているサイバー攻撃対策において、検知に有効なサイバー攻撃を特徴付ける指標(indicator)などを取り込んだサイバー攻撃活動に関連する項目を記述するための技術仕様 < STIX言語で記述する脅威情報のXMLファイルの構成> TAXII（Trusted Automated eXchange of Indicator Information）： 米国政府の支援を受けた非営利団体のMITREが中心となり策定を進めた、サイバー攻撃活動の情報を交換するための検知指標情報自動交換手順の技術仕様。TAXIIを用いることで、STIXで記述されたサイバー攻撃活動の観測事象、検知指標などの様々な脅威情報の交換をプログラム処理可能になる

7. データに基づいたリスク判断と決定を継続的に行う DevOps（DevSecOps）と同様に、リスクマネジメントについてもRiskOps（RiskBuildOps）のサーキットを適用してリスクの可視化・判断の高速化を図ることが有用。