サイバーセキュリティの最も苛立たしいルールの1つは、組織がテクノロジーにどのような投資を行っても、あるいはそのアーキテクチャがどれほど洗練されていても、通常、人やプロセスをハッキングするのは、テクノロジーを破るよりも簡単だということだ。多要素認証（MFA）は非常に効果的であるため、攻撃者はわざわざMFAを直接攻撃することはない。 MFAを回避する そして、他のビジネスレイヤーやユーザーをターゲットにして、環境における足掛かりを得る。
MFAを回避する場合、サイバー犯罪者は、詐欺メール、テキスト、および「」からの通知と思われる通知を使用する。ヘルプデスクの電子メールアカウント「のユーザーをターゲットにする。 そっこうばくげき また、 「MFA疲れ」 攻撃を受けている。しかし、ハッカーが手口を進化させ、ヘルプデスクそのものを狙うようになったらどうなるだろうか？
単なる机上の空論ではない。シーザース・エンターテイメントは 1,500万ドル サイバー犯罪グループによる "システムへの侵入と妨害 "を受けて。組織 報告済み この情報漏えいは、「外部委託のITサポート・ベンダーに対するソーシャル・エンジニアリング攻撃」から始まったという。昨年のことだ、 LAPSUS$ ある組織のヘルプデスクに電話をかけ、サポート担当者に特権アカウントの認証情報をリセットするよう説得しようとした。
シーザーズ・エンターテインメントへの攻撃は、組織がヘルプデスクを強化する必要がある理由を示している。しかし、口で言うのは簡単です。セキュリティ優先のオペレーションを展開するには、リーダーシップのサポート、技術的投資、従業員への投資、トレーニングなどが必要です。重要なことは、最近の攻撃の中にはヘルプデスクを特にターゲットにしたものもありますが、ヘルプデスクが特に攻撃を受けやすいとか、安全でないとか、リスクが高いということではありません。組織は、セキュリティ・ファーストの原則を次のような形で導入する必要がある。 すべての ビジネスプロセスだ。彼らは 全て 危険である。
そうは言ってもね、 散蜘蛛とALPHV/BlackCat が最近、ヘルプデスクにスポットライトを当てている。そこで、セキュリティ・チームとヘルプ・デスクが取るべきベスト・プラクティスと、ゼロ・トラストのヘルプ・デスクを開発するために問うべき質問をいくつか確認してみよう。
ヘルプデスク（またはサービスデスク）は、ほとんどの企業でITランドスケープの標準的な部分です。ヘルプデスクにはさまざまな機能がありますが、コンピュータにログインできない、あるいはリソースにアクセスできないといった問題が発生した場合の最初の窓口となることがよくあります。このような問題を解決するために、ヘルプデスクは、以下のようなかなりリスクの高いアクションを実行できる場合があります：
- パスワードのリセット
- ロックアウトされたユーザーのMFAを解除する
- 新規アカウントの作成
ヘルプデスクのスタッフは、システム全体の問題に対処するために管理用アカウントを作成したり、MFAを一時的に完全に削除したりするなど、さらにリスクの高いアクションを実行するための入口となるかもしれません。ヘルプデスクスタッフが直接そのようなアクションを取ることができなくても、できる他のグループのためにチケットを開くことができるかもしれません。
ヘルプデスクは、セキュリティ・ポリシーを一時停止したり、回避したりすることができる。さらに、組織はユーザーや顧客が接続され、生産的で、幸せな状態を維持することを望んでいるため、脅威行為者はヘルプデスクの連絡先情報を簡単に見つけることができます。
良い知らせは、ヘルプデスクが重大なリスクをもたらす可能性がある一方で、セキュリティチームは、アイデンティティ、プロセスの文書化、自動化、および深層防御の開発を優先することによって、これらの危険を最小限に抑えることができるということである。
まず、あなたのヘルプデスクを知ることから始めましょう。彼らは通常何をしているのか？どのような 可能性がある 彼らは何をしているのか？彼らは何にアクセスでき、なぜそのアクセスが必要なのか？
すべての組織は、ヘルプデスクが自分たちの環境にどの程度アクセスできるかを尋ねるべきである。セキュリティ・チームは、その答えを最小権限の概念に照らして定期的に見直す必要がある。信頼ゼロに近づけるためには、ヘルプデスクは必要なときに必要な機能だけにアクセスできるようにすべきです。ヘルプデスク担当者の広範囲な管理者アクセスは禁物です。
この良い判断材料は、ヘルプデスクのサービスカタログである。サポート要員は、これらのサービ スの実行に必要なアクセス権、およびこれらのサービスのみを持つべきである。セキュリティチームは、ヘルプデスクスタッフが必要以上の権限を持っていないか、特にユーザの ID セキュリティ設定を調整する可能性のあるアクションについてレビューする必要があります。
ヘルプデスクが通常何をし、何ができるかを把握したら、ランブックとプロセス文書を見せてくれるよう頼む。もし文書がないのであれば、作成し、本人確認を含め、適切なセキュリティ慣行が行われているかを確認する必要がある。
新しいフェデレーションや新しいテナントをディレクトリに追加するようなアクションは、 より厳格なプロセスに従うべきである。新しいフェデレーションや新しいテナントをディレクトリに追加するようなアクションは、より厳密なプロセスに従う必要があります。誰かが通常のプロセス以外でリスクの高いアクションを開始しようとした場合、セキュリティ・システムはその試みを検出し、セキュリティに警告してブロックする必要があります。
また、ヘルプデスク・チームだけで終わらせないこと。ヘルプデスクはユーザーを支援するために多くの自由裁量を持つことができますが、時には複雑でリスクの高いタスクを完了するために別のグループを導入する必要があります。複数のグループが一緒に作業する場合は、どのタスクが複数の機能を必要とするのか、誰がリクエストを検証するのか、どのように文書化するのかを、すべてのチームが把握していることを確認してください。
サイバー犯罪者は、どのチームがどのアクションに責任を持つかについて、あなたが行った仮定を悪用する。VIPが新しいマネージャーを雇い、すぐに管理者リクエストが必要だと言った場合、ヘルプデスクはどのようにそのリクエストを受け取り、確認し、他のチームと調整するのだろうか？リクエストが組織内からのものであること、そして悪者を手助けしていないことを確認するために、すべての仮定をチェックする必要がある。
ヘルプデスクの従業員は、リーダーやセキュリティチームから、確立されたプロセスに従い、文書化を義務付け、ユーザーを確認する必要があることを聞く必要がある。特に 安全な診療を維持するための例外的な要求のために。
ヘルプデスクは、セキュリティ・チームとリーダーシップ・チームが自分たちの背中を押してくれていることを知るべきです。これは単なる技術的、運用的な変更ではなく、リーダーシップが組織全体で培わなければならない文化的な価値観です。なぜなら、リスクの高いリクエストは、社内のリーダー、社外のVIP、または脅威行為者から来る可能性が高いからです。彼らは、問題を解決したり、何らかのアクセスを得たりするために、「緊急」のリクエストをカスタマー・サポート・チームに連絡してくるかもしれません。
そのような状況では、ヘルプデスクの従業員は常に "No "とは言えない。その代わりに、彼らが "No "と言えるような技術、プロセス、文化を育てよう：「はい、そのために必要なことは以下の通りです。これらのステップを前もってスクリプト化しておくこと、そして追加のステップが必要なときにリーダーシップとセキュリティ・チームがヘルプデスクの味方になってくれることを知っておくことが、情報漏洩を防ぐ上で大きな違いを生むかもしれない。
トップダウンのプロセスだけではない。 オートメーション 手動プロセスやVIPのプレッシャーにさらされるのを制限することが理にかなっている場合。自動化は特効薬にはならない。ヘルプデスクは、例外を求める電話に対応し、電話をかけてきた人に自動化を紹介するか、信頼できる承認を必要とするエスカレーション手順を持つ必要があるかもしれない。
ヘルプデスクと面談し、彼らができることを理解し、優先順位の高いアクションをカタログ化し、文書を作成し、リーダーシップチームが、たとえユーザーに迷惑をかけることになっても、組織は常にセキュリティの側に立つことを日常的に説明しているとします。
次に答えなければならないのは、ヘルプデスクまたはカスタマーサポートチームがどのように本人確認を行うかということです。ユーザーの身元を認証することは絶対に重要です。なぜなら、サポート・セキュリティが十分に設計され、文書化されていても、チームの誰かがユーザーに権利がないリクエストに対応した場合、効果がないからです。
最近、フィッシングの懸念に対処する一つの方法として、目視確認が注目されている。組織は NIST 800.63A 優れた」強度の検証に必要な機能が、その状況にとって理にかなっているかどうかを確認する。独立した視覚的検証を行うために必要な技術的要件と、ヘルプデスクがこのメカニズムを実装するために必要なトレーニングを考慮すると、これは慎重に行うべきである。視覚的検証は、リクエストを行う人を知らない遠隔ヘルプデスクについて話している場合、達成するのが容易になりつつあるディープフェイクの影響を依然として受けやすい可能性がある。このような課題があるため、私は、視覚的検証がほとんどの状況で効果的に実装されることに懐疑的である。
その代わりに、組織は伝統的な深層防御アプローチと MFA を使用して、その人物が本人であることを確認することができる。よく練られた要求と検証の方法は、単一の最初の信頼ベクトル、例えば定義された電子メールやサポ ートポータルへのログインから始まるかもしれないが、第2の信頼されたシステムを使用した帯域外 接触のような追加要素も統合すべきである。帯域外コンタクトを利用する方法には、以下のようなものがある：
- 管理者の承認：管理者がチケッティングシステムでアクセスリクエストを承認していることを体系的に確認します。
- マネージャー（従業員の場合）または登録担当者（顧客の場合） に電話し、リクエストが有効かどうかを確認してもらう。マネージャーは通常、従業員と連絡を取るための帯域外の方法を持っています。
- サービスデスクの従業員とリクエストを行うユーザーで電話会議を行う。次に、マネージャーやチームメンバーのような第三者に電話会議に参加してもらい、ユーザーとそのリクエストを視覚的に確認します。
- 承認を迅速化するために、企業ディレクトリから引き出した同僚やアシスタントに依頼を確認させることもできる。
どのような検証システムも壊れる可能性があるが、リスクの高いリクエストに対応する前にIDを検証するためにいくつかの無関係な要素を組み合わせることで、ヘルプデスクがほとんどのフィッシングの試みに対応できるようにすることができる。例えば、Active Directory、電子メール用のM365、Teamsを使用しているMicrosoftのショップであれば、最強のMFAアプローチを望むのであれば、絡み合っているこれらの要素を組み合わせたくないかもしれない。
このようなソーシャル・エンジニアリング攻撃に対して、ヘルプデスクやその他の業務を強化するもう一つの方法は、IDプルーフィングである。アイデンティティ・プルーフィングについては、近日中に詳しくご紹介する予定です。
