マレーシア航空、フリークエントフライヤーのデータが9年間流出 / Malaysia Airlines Frequent Flyers Data Exposed in Nine-Year Breach(転載)

malaysia-1-1000x600.jpg

Malaysia Airlines Frequent Flyers Data Exposed in Nine-Year Breach
:

マレーシア航空のマイレージプログラム「エンリッチ」の会員が、2010年3月から2019年6月の間のどこかで個人情報が流出した可能性があると警告されている。同航空会社は、未知数のフライヤーの名前や生年月日、連絡先などが流出した可能性があると発表した。

2010年3月から2019年6月までの間のどこかでマレーシア航空のエンリッチプログラムの会員だった場合、個人を特定できる情報が漏洩した可能性があると航空会社は述べています。Channel Asiaによると、航空会社は現在、最大9年間続いた可能性のあるデータ侵害を公開しているという。

曝露データには、氏名、生年月日、ステータス、連絡先が含まれています。

報告書によると、フライヤーの身元の重要な詳細が期間中にハッカーに暴露された可能性があるという。そのデータには、以下のようなものが含まれています。

  • 会員氏名
  • 生年月日
  • 性別
  • 連絡先情報
  • フリークエントフライヤー番号
  • フリークエントフライヤーエリートのステータス
  • ロイヤリティ層のレベル情報

しかし、航空会社によると、ハッカーに旅程情報が流出したことはなかったという。また、予約、発券情報、身分証明書、クレジットカード情報はすべて安全に保たれていた。

航空会社は、今回のデータ流出によって影響を受けた可能性のあるフライヤーの数については明言していない。メディアの声明では、航空会社は、盗まれたデータがフライヤーに悪用されたとは考えていないとしています。エンリッチの会員には、2021年3月1日(月)に送信された電子メールで初めて侵害の事実が知らされました。

"マレーシア航空は、個人情報が悪用されたという証拠はなく、今回の事件ではアカウントのパスワードも開示されていません。"と、航空会社の声明文は、チャンネル・アジアによると読み上げられています。"それにもかかわらず、エンリッチ会員には、予防措置としてアカウントパスワードの変更を奨励しています。今回の事件は、マレーシア航空自身のITインフラやシステムに影響を与えるものではなかった"

データ侵害が大手ロイヤリティプログラムを悩ませ続ける

ロイヤリティプログラムは、個人情報を盗むために使用できる多くのデータポイントが含まれているため、ハッカーの主要な標的となり続けています。とはいえ、データ侵害の犠牲者は航空会社だけではありません。2020年3月、マリオット リワードはデジタル攻撃を受け、500万人以上のフライヤーの情報が流出したと発表しました。

インターンの設定ミスがSolarWinds侵害の原因か / Former SolarWinds CEO blames intern for 'solarwinds123' password leak(転載)

インターンの設定ミスがSolarWinds侵害の原因か
Former SolarWinds CEO blames intern for 'solarwinds123' password leak

SolarWindsの現在および元トップ幹部は、明らかに何年も診断されなかったパスワードセキュリティの重大な過失について、会社のインターンを非難しています。

問題のパスワード「solarwinds123」は、2019年に公開されたインターネット上で、独立したセキュリティ研究者によって発見されたもので、この漏洩によってSolarWindsのファイルサーバーが公開されたと同社に警告を発した。

複数の米国の議員が金曜日、下院の監督委員会と国土安全保障委員会の合同公聴会で、パスワードの問題でSolarWindsを怒鳴りつけました。

"私は子供がiPadでYouTubeを見過ぎないように、『solarwinds123』よりも強力なパスワードを持っています」とKatie Porter議員。"あなたとあなたの会社は、ロシア人が国防省の電子メールを読むのを防ぐことになっていました!"

マイクロソフトのブラッド・スミス社長は、金曜日の公聴会でも証言していたが、その後、国防総省が実際にロシアのスパイ活動の影響を受けたという証拠はないと述べた。マイクロソフトは、ハッキングキャンペーンのフォレンジック調査を主導してきた企業の一つです。

"私の知る限りでは、国防総省が攻撃を受けたという証拠はない "とスミス氏はポーター氏に語った。

SolarWindsの代表者は金曜日に、パスワードの問題が報告されるとすぐに、数日以内に修正されたと議会関係者に話しました。

新しいCISベンチマークでセキュアなクラウド製品・サービスを実現 / Secure Cloud Products and Services with New CIS Benchmarks(転載)

Blog | Secure Cloud Products and Services with New CIS Benchmarks:

クラウドは、クラウドサービスプロバイダ(CSP)が絶えず新製品やサービスを導入し、拡大を続けています。CISは、これらの機能をクラウドで安全に保護するためのより多くのリソースを提供しています。『The Beginner's Guide to Secure Cloud Configurations』では、ユーザーがパブリッククラウドのアカウント、製品、サービスなどを安全に保護する方法を説明しています。

CISベンチマーク・コミュニティからの新しいガイダンス

CISは、有志のネットワークに呼びかけて、パブリック・クラウドのガイダンスを拡大してきました。この取り組みの結果、CISはクラウドのCSP製品やサービスに特化したベンチマークを作成することができました。

CIS は、リソースを磨き、独自のサービスごとに CIS ベンチマークを作成するのではなく、CSP に倣い、CSP の製品ごとにサービスを分類した。その代わりに、CISはCSPに倣い、CSPの製品ごとにサービスをグループ化しました。各CSPは数十の製品を提供しており、提供する機能に基づいてクラウドサービスをグループ化しています。

3つのレベルのCISクラウドベンチマーク

このガイドでは、クラウドに適用可能な3つのCIS Benchmarkカテゴリを紹介しています。

  1. CIS Foundations Benchmarks
  2. Cloud product-level CIS Benchmarks
  3. Standalone cloud service CIS Benchmarks

各ベンチマークレベルでは、CIS Foundations Benchmarksから始まり、CIS Hardened Imagesを介して仮想マシンのセキュリティを確保することで、セキュリティの追加レイヤーを提供しています。

CIS-Foundations_Benchmarks-Products_and_Services.png

  1. CIS Foundations Benchmarks は、パブリック・クラウドで安全に構成するためのアカウントレベルの出発点を提供します。これらのリソースは、アイデンティティとアクセス管理、ログと監視、ネットワークなどをカバーしています。基礎的なガイダンスは、AWS、Azure、Google Cloud Platform、Oracle Cloud、IBM Cloud、およびAlibaba Cloudで利用可能です。

  2. Cloud product-level CIS Benchmarksは、CSPの製品およびサービス構成のガイダンスを提供し、コンピュート、データベース、ストレージ、コンテナなどの分野が含まれています。これらのCISベンチマークにより、ユーザーは該当するクラウドサービスを選択し、環境に応じてクラウドを構成することができます。製品レベルのCISベンチマークは、クラウドアカウント内で使用されるクラウドサービスに組み込まれたセキュリティの追加レイヤを提供することで、CIS Foundations Benchmarksを補完します。

  3. Standalone cloud service CIS Benchmarksは、より広範な構成ガイダンスを必要とするCSPサービスに特化したものである。これらの場合、製品レベルのCISベンチマークにはサービスのセクションがあり、サービスのスタンドアロンCISベンチマークを指し示します。

CIS AWS End User Compute and Kubernetes Benchmarks

クラウド製品レベルのCISベンチマークの第一弾としてリリースされたのが、CIS AWS End User Compute Services Benchmarkです。これには、Amazon WorkSpaces、Amazon WorkDocs、Amazon AppStream 2.0、Amazon WorkLinkの構成推奨が含まれています。ユーザーは、該当するサービスを選択し、自分の環境で稼働しているものに合わせて構成することができます。

CIS-AWS_End_User_Compute_Services_Benchmarks-Cloud_Products.png

場合によっては、サービスに必要な設定が、1つのクラウドサービスに特化したCISベンチマークを必要とすることがあります。この場合、製品レベルのCISベンチマークには、クラウドサービスのセクションが含まれますが、サービスのための別のCISベンチマークを指すことになります。スタンドアロン型のクラウドサービスのCISベンチマークの例としては、CIS Kubernetesベンチマークがあります。

CIS-Amazon_Elastic_Kubernetes_Service_Benchmark-Cloud_Services.png

CIS currently offers multiple CIS Benchmarks for Kubernetes:

  • Amazon Elastic Kubernetes (EKS)
  • Google Kubernetes Service (GKE)
  • Oracle Container Engine for Kubernetes (OKE)

CISは、Azure Kubernetes Service、Alibaba Kubernetes、Red Hat OpenShift KubernetesのCIS Benchmarksを今後数ヶ月のうちにリリースする予定です。

Secure Configurations with CIS Hardened Images

仮想イメージは、物理コンピュータと同じ機能を提供する仮想マシン(VM)のスナップショットです。仮想イメージはクラウド上に存在し、ユーザーはローカルのハードウェアやソフトウェアに投資することなく、日常的なコンピューティング操作をコスト効率よく実行することができます。

ハードニングとは、システムをサイバー攻撃に対して脆弱にする潜在的な弱点を制限するプロセスです。標準イメージよりも安全性の高いハードニングされた仮想イメージは、システムの脆弱性を軽減し、マルウェア、不十分な認証、およびリモートからの侵入からシステムを保護します。

CIS-Hardened_Images-Products_and_Services.png

安全に構成されたCIS Hardened Imagesは、クラウド上でのOSのセキュリティ確保を支援します。CIS Hardened Imagesは、CIS Benchmarksの要件を満たしており、4つの主要なクラウドコンピューティングマーケットプレイスで利用できます。AWS、Azure、Google Cloud Platform、Oracle Cloudの4つの主要なクラウド・コンピューティング・マーケットプレイスで利用できます。

Additional Layers of Cloud Security

CISは、CSPと直接協力して、各プラットフォームで最も利用されているクラウド製品やサービスを特定します。その情報をもとに、今後のCISベンチマークの開発計画を策定していきます。

すべてのCIS Benchmarksの推奨事項は、他のガイドラインや追加リソースを参照しています。これらのクラウドガイドにより、CISは、CIS BenchmarksとCSPの文書との関係を示している。その意図は、CSP が提供するガイダンスを、セキュリティの面でもそうでない面でもユーザに知らせることにある。この文書は、ユーザが、サービスを実行する際に、CSP が負う責任と、それを支援する責任を認識するのに役立つ。

クラウドの拡大が急速に進むということは、それだけ多くの製品やサービスが間もなく登場することを意味しています。CISは、CSPと緊密に連携して、開発の一歩先を行くようにしています。これにより、グローバル・ユーザー・コミュニティにコストをかけずに、タイムリーで効果的なガイダンスを提供することを計画しています。

バックアップ

NSA、ゼロトラストセキュリティモデルに関するガイダンスを発表 / NSA Releases Guidance on Zero Trust Security Model(転載)


NSA Releases Guidance on Zero Trust Security Model:

ゼロ・トラスト・セキュリティ・モデルの採用

エグゼクティブサマリー

サイバーセキュリティの専門家が、ますます分散した複雑な企業ネットワークを高度なサイバー脅威から守るためには、ゼロトラストのセキュリティモデルと、ゼロトラストの原則に基づいて設計されたシステムを展開し、運用するために必要な考え方を採用することで、機密データ、システム、およびサービスを安全に保護することができるようになります。

ゼロトラストは、従来のネットワークの境界線の内側と外側の両方に脅威が存在することを認識した上で、セキュリティモデル、一連のシステム設計原則、および協調的なサイバーセキュリティとシステム管理戦略です。ゼロトラストのセキュリティモデルでは、1つの要素、ノード、またはサービスに対する暗黙の信頼を排除し、代わりに、アクセスやその他のシステムの反応を決定するために、複数のソースから供給されるリアルタイムの情報を介して、運用状況を継続的に検証することを要求します。

ゼロ・トラスト・セキュリティ・モデルでは、違反は避けられないか、すでに発生している可能性が高いと想定しているため、常に制限をかけています。必要なものだけにアクセスし、異常な活動や悪意のある活動を探します。ゼロトラストは、包括的なセキュリティを組み込んでいます。監視、粒度の高いリスクベースのアクセス制御、およびシステム・セキュリティの自動化を、すべての 動的な脅威の中で、重要な資産(データ)をリアルタイムで保護することに集中するために、インフラストラクチャの側面に注目しています。環境を提供します。このデータ中心のセキュリティモデルでは、最小特権アクセスの概念をすべてのアクセスに対して適用することができます。

ゼロトラストの原則を用いて設計されたシステムは、既存の脅威に対処するために、より良い立場にあるはずですが、そのようなシステムに移行するには、途中でセキュリティ態勢を弱めないように、慎重な計画を立てる必要があります。

リスクを最小限に抑え、ロバストでタイムリーな対応を可能にするためには、ゼロトラストの原則とコンセプトがネットワークとその運用エコシステムのほとんどの側面に浸透していなければなりません。 最高経営責任者からエンジニア、オペレータに至るまで、組織はゼロ・トラストの道に乗り出す前に、ゼロ・トラストの考え方を理解し、それにコミットしなければなりません。

以下のサイバーセキュリティガイダンスでは、ゼロトラスト・セキュリティモデルとその利点、および導入のための課題について説明しています。詳細な戦略を構築し、必要なリソースを投入し、実装を成熟させ、望ましい結果を得るためにゼロ・トラスト・モデルに全面的にコミットすることの重要性を論じています。以下の推奨事項は、この最新のサイバーセキュリティモデルの採用を検討しているサイバーセキュリティリーダー、企業のネットワーク所有者、管理者を支援するものです。

Falling behind

今日のIT環境は、接続性、ユーザーの多様性、豊富なデバイス、グローバルに分散されたアプリケーションやサービスにより、悪意のある活動の影響を受けやすくなっています。システムとユーザーは、悪意のある行為者を遠ざけつつ、組織のリソースに接続して相互作用するためのシンプルで安全な方法を必要としています。現在および新興のクラウド、マルチクラウド、ハイブリッドネットワーク環境の複雑さが増していることに加えて、敵の脅威が急速にエスカレートし、進化していることから、従来のネットワークサイバーセキュリティ防御の有効性の欠如が露呈しています。従来の境界線ベースのネットワーク防御は、何層にもわかれたセキュリティ技術で構成されていますが、現在の脅威環境のため、サイバーセキュリティのニーズを満たすことができないことが証明されています。サイバー犯罪者から国家権力者に至るまで、現代の脅威行為者は、より執拗で、よりステルス性が高く、より繊細になってきている。規則性があります。これらの脅威行為者は、インサイダーの脅威行為者と同様に、そのアクセスを利用して国家や経済の安全保障を脅かし、危害を加えることに成功しています。最も熟練したサイバーセキュリティの専門家であっても、分散した企業ネットワークをこれまで以上に洗練されたサイバー脅威から守ることは困難です。組織は、インフラストラクチャを保護し、データ、サービス、アプリケーション、およびインフラストラクチャへの統一的かつ粒度の高いアクセス制御を提供するためのより良い方法を必要としています。

複数の視点からの可視性を統合し、リスクを考慮したアクセス決定を行い、検出と対応のアクションを自動化する最新のサイバーセキュリティ戦略を実装することで、ネットワーク防御者は、機密データ、システム、アプリケーション、およびサービスを安全に保護するために、はるかに優れた立場に立つことができるようになります。ゼロトラストは、サイバーセキュリティのアーキテクト、インテグレータ、実装者が、異なるが関連するサイバーセキュリティ機能を統合して、サイバーセキュリティの意思決定のためのまとまりのあるエンジンに統合する際の指針となることを目的とした「想定違反」セキュリティモデルです。しかし、完全に効果を発揮するためには、ゼロ・トラストの原則をネットワークとその運用エコシステムのほとんどの側面に浸透させ、リスクを最小限に抑え、ロバストでタイムリーな対応を可能にする必要があります。ゼロ・トラスト・ソリューションへの移行を選択した組織は、このセキュリティモデルと、このセキュリティモデルの下でサイバーセキュリティを達成するための計画、資金調達、運用に必要な考え方を完全に受け入れるべきです。

Increasingly sophisticated threats

ゼロトラスト・セキュリティモデルを採用し、このセキュリティモデルに基づいて既存の情報システムを再構築する。は戦略的な取り組みであり、完全な利益を得るまでには時間がかかる。新しい敵対ツールへの戦術的な緩和対応ではありません。戦術、および技術。しかし、最近のいくつかの非常に公開されたシステム侵害は、広範囲に及ぶ システムの脆弱性、システム管理や防御的なネットワーク運用の欠陥などがあります。これらの 事件は、純粋に戦術的な対応では不十分な場合が多いことを示しています。成熟したゼロトラスト環境では サイバーセキュリティの防御者は、新たな脅威行為者を検出する機会を増やし、迅速に対応できる選択肢を増やすことができます。洗練された脅威に対処するために配備されています。ゼロトラストの運用を成功させるために必要なマインドセットの採用 このような環境では、サイバーセキュリティの防御者は、これまで以上に微妙な脅威の指標を認識することができるようになるでしょう。戦術的な ゼロトラスト環境であっても、適切なセキュリティモデル、マインドセットがあれば、対応が必要になる可能性が高い。と応答ツールを使用することで、防御者はますます高度化する脅威に効果的に対応できるようになります。

What is Zero Trust?

ゼロトラストは、セキュリティモデル、システム設計の原則、および協調的なサイバーセキュリティとシステムのセットです。ネットワークの内外を問わず脅威が存在することを認識した管理戦略 の境界線を越えてはいけないという前提に疑問を投げかけます。ゼロトラストは、ユーザー、デバイス、ネットワークコンポーネントが ネットワーク内の位置情報に基づいて暗黙のうちに信頼されています。ゼロトラストは、包括的なセキュリティ監視を実現します。粒度の高い、動的でリスクベースのアクセス制御、システムセキュリティの自動化を、ネットワーク全体で協調的に実施します。インフラストラクチャのすべての側面で、重要な資産(データ)をリアルタイムで保護することに特化しています。動的な脅威環境。このデータ中心のセキュリティモデルでは、最小特権アクセスの概念を適用することができます。誰が、何を、いつ、どこで、どのようにして、どのようにして、という質問への回答が、あらゆるアクセスの意思決定のための重要な鍵となります。

NSA は、国家安全保障システム(NSS)、国防総省(DoD)ネットワーク、および防衛産業基地(DIB)システムを含む重要なネットワークに対して、ゼロトラスト・セキュリティモデルを検討することを強く推奨しています。これらの原則を特定の環境、特に大企業内で統合することは、複雑になる可能性があります。これらの課題に対処するために、NSA は、ゼロトラスト設計アプローチを整理、指導、簡略化するための追加のガイダンスを開発しています。

Adopt a Zero Trust mindset

現代のダイナミックな脅威環境に適切に対処するためには、以下のことが必要です。

  • 協調的かつ積極的なシステム監視、システム管理、防御的運用能力。
  • 重要なリソースへのすべての要求とすべてのネットワークトラフィックが悪意のあるものである可能性があることを想定しています。
  • すべてのデバイスとインフラストラクチャが危険にさらされている可能性があることを想定する。
  • 重要なリソースへのすべてのアクセス承認にはリスクが伴うことを受け入れ、迅速な損害評価、制御、復旧作業を実行できるように準備していること。

Embrace Zero Trust guiding principles

ゼロトラストソリューションには、以下のような運用能力が必要です。

  • 信用してはいけない、常に確認すること:すべてのユーザ、デバイス、アプリケーション/ワークロード、データフローを信頼できないものとして扱う。動的なセキュリティポリシーを使用して、必要最小限の権限で認証し、明示的に権限を付与する
  • 違反を前提とする:敵対者がすでに環境内に存在することを前提に、意識的にリソースを運用し、防御する。デフォルトで拒否し、すべてのユーザー、デバイス、データフロー、アクセス要求を精査する。すべての構成変更、リソースアクセス、ネットワークトラフィックをログ、検査し、継続的に監視して、不審な活動がないかどうかを確認します。
  • 明示的な検証:すべてのリソースへのアクセスは、複数の属性(動的および静的)を使用して、一貫性のある安全な方法で実施され、リソースへの文脈に基づくアクセス決定の信頼度を導き出すべきである。

Leverage Zero Trust design concepts

ゼロトラストソリューションを設計する場合

  • ミッションの成果を定義する:重要なデータ/アセット/アプリケーション/サービス(DAAS)を特定する組織固有のミッション要件からゼロトラストアーキテクチャを導き出します。
  • 内側から設計:まず、重要なDAASを保護することに集中してください。第二に、それらにアクセスするためのすべてのパスを保護します。
  • アクセス制御ポリシーを作成するためにDAASへのアクセスを必要とする人/物を決定する:セキュリティポリシーを作成し、すべての環境(LAN、WAN、エンドポイント、境界線、モバイルなど)に一貫して適用する。
  • 行動する前にすべてのトラフィックを検査し、ログを取る:エンドポイントとネットワークからすべてのレイヤーにわたるすべてのアクティビティの完全な可視性を確立し、疑わしいアクティビティを検出できる分析を可能にします。

Examples of Zero Trust in use

ゼロトラストの基本的な目的は、ユーザー、プロセス、およびデバイスがどのようにして データ、ユーザー、デバイス、およびその他のセキュリティ関連のコンテクスト情報の組み合わせ(例えば、位置情報、時刻 日、ユーザーまたはデバイスの以前のログに記録された動作)をアクセス決定に使用することをタプルと呼びます。の一部として このタプルの中に信頼できる情報を持つためには、ユーザとデバイスの両方の明示的な認証が必要です。このタプルには ゼロトラスト決定エンジンは、アクセス要求のタプルを検査し、データのセキュリティポリシーと比較します。または要求されているリソースにアクセスすることができます。そして、アクセスを許可するかどうかをリスクを考慮した上で決定し、以下のログエントリを送信します。そのアクセス要求と決定が将来の不審な活動分析の一部になるようにします。このプロセスは、すべての 各センシティブなリソースへの個別のアクセス要求が可能であり、拡張アクセスの間も定期的に繰り返されます。

以下に、成熟したゼロトラスト実装が、従来のアーキテクチャが通常可能な場合よりも悪意のある活動を検出することができるいくつかの例を示します。

Compromised user credentials

この例では、悪意のあるサイバー・アクターが正当なユーザーの資格情報を侵害して 組織のリソースを使用しています。この場合、悪意のある行為者は不正なデバイスを使用しており、リモートアクセスや不正なデバイスを使って組織の無線LANに接続しています。従来のネットワークでは、ユーザーの資格情報だけでは 多くの場合、アクセスを許可するには十分ですが、ゼロトラスト環境ではデバイスが知られていないため、認証に失敗します。と認証チェックを行うため、アクセスが拒否され、悪意のある活動がログに記録されます。さらに、ゼロトラストでは ユーザーとデバイスのアイデンティティのための強力な認証 ユーザーの強力な多要素認証を使用することで ゼロトラスト環境で推奨されている、ユーザーの資格情報を盗むことをそもそも難しくすることができます。

Remote exploitation or insider threat

この例では、悪意のあるサイバーアクターが、インターネットベースのモバイルコードを悪用してユーザーのデバイスを侵害しています。あるいは の場合、アクターは悪意のある内部の認可されたユーザです。典型的な、ゼロトラストではないシナリオでは、アクターは ユーザーの資格情報を取得し、ネットワークを列挙し、特権を昇格させ、ネットワークを介して横方向に移動して危殆化させます。膨大なデータを蓄積し、最終的には永続化します。ゼロ・トラスト・ネットワークでは、侵害されたユーザの資格情報とデバイスの は、証明されるまではすでに悪意のあるものとみなされ、ネットワークはセグメント化されているため、列挙と 側方移動の機会。悪意のある行為者はユーザーとデバイスの両方として認証することができますが、その一方で データは、セキュリティポリシー、ユーザの役割、ユーザとデバイスの属性に基づいて制限されます。成熟したゼロトラスト 環境では、データの暗号化とデジタル著作権管理により、どのデータが使用できるかを制限することで、さらなる保護を提供することができます。また、アクセスが許可されていた場合でも、機密データにアクセスされた場合の対処方法を説明しています。さらに、分析的な 機能は、アカウント、デバイス、ネットワークアクティビティ、データアクセスの異常なアクティビティを継続的に監視します。検知されている間は このシナリオでは、このレベルの侵害が発生した場合、被害は限定的であり、防御システムが検出して開始するまでの時間は 適切な緩和対応が大幅に減少する。



Compromised supply chain

この例では、悪意のある行為者が悪意のあるコードを一般的な企業のネットワークデバイスやアプリケーションに埋め込みます。この例では、悪意のあるアクターは デバイスまたはアプリケーションは、ベストプラクティスに従って、組織のネットワーク上で保守され、定期的に更新されます。従来のネットワーク・アーキテクチャでは、このデバイスやアプリケーションは内部にあり、完全に信頼されています。このタイプの ゼロトラストの成熟した実装では、暗黙のうちに信頼されているため、妥協は特に深刻なものになる可能性があります。アーキテクチャを採用することで、デバイスやアプリケーションが本質的に 信頼されています。その特権とデータへのアクセスは厳重に管理され、最小限に抑えられ、監視されます。マイクロ)はポリシーによって実施され、異常な活動を監視するために分析が使用されます。さらに デバイスが署名されたアプリケーションの更新プログラムをダウンロードできる可能性があります (悪意があるかどうか)、デバイスの許可されたネットワーク接続 に接続しようとすると、ゼロトラスト設計ではデフォルトによる拒否のセキュリティポリシーが採用されるため、他のリモートの アドレスがブロックされる可能性があります。また、ネットワーク監視によって 許可されたアクセス要求に関連付けられていないデバイスまたはアプリケーションからの横方向の移動

Zero Trust maturity

ゼロトラストの導入には時間と労力がかかります。多くのネットワークでは、既存の インフラストラクチャを活用し、ゼロトラストの概念を組み込むために統合することができますが、成熟したゼロトラストへの移行が必要となります。トラストアーキテクチャでは、ゼロトラスト環境のメリットをフルに享受するために、追加の機能が必要になることがよくあります。移行 を成熟したゼロトラストアーキテクチャに一度に変更する必要はありません。ゼロトラストの機能を段階的に を戦略計画の一部として活用することで、各段階でそれに応じてリスクを低減することができます。ゼロトラストの実装が時間の経過とともに成熟していくと 可視性を高め、自動化された対応により、防御者は脅威に追いつくことができるようになります。

NSA は、ゼロトラストの概念を既存の環境にどのように統合するかを検討する際には、ゼロトラストのセキュリ ティモデルを採用することを推奨している。ゼロトラストの取り組みは、初期準備から基本、中間、上級の段階まで、継続的に成熟していくロードマップとして計画され、サイ バーセキュリティの保護、対応、運用は時間の経過とともに改善されていくべきである。


Potential challenges on the path to Zero Trust

企業ネットワークにゼロトラストを導入する際には、いくつかの課題が発生する可能性があります。のソリューションを提供します。最初の潜在的な課題は、企業全体での完全なサポートが不足していることです。管理者、ユーザーのいずれかが、ゼロトラストを実現するために必要な考え方を完全に受け入れなければなりません。ゼロ・トラストに必要な考え方は、どのようなソリューションも成功させるために完全に受け入れなければなりません。もし 管理者やネットワークディフェンダーがそうしないと、リーダーは構築と維持のために必要なリソースを使いたくありません。賛同者や必要な専門知識がない場合や、ユーザーがポリシーを迂回することが許されている場合、ゼロトラストのメリットは は、その環境では実現できません。基本的な、あるいは中間的なゼロ・トラスト機能でさえも、いったん ネットワークを利用しているため、実装を成熟させ、十分な利益を得るためには、フォロースルーが必要です。

ゼロ・トラストの概念を環境全体に適用する必要性が広まっているため、機能のスケーラビリティが不可欠です。以前は各アクセスに対して一度しか発生しなかったアクセス制御の決定が、リソースへのアクセスが使用されると継続的に実行されるようになるため、これらのアクセス決定を行い、強制し、ログに記録するための堅牢なインフラストラクチャが必要になります。さらに、データタグや追加のネットワークセンサーなど、これまでアクセス制御の決定に含まれていなかったネットワークの要素が、信頼性と一貫した使用が必要とされる重要な要素になる可能性があります。

マインドセットを継続的に順守し、ゼロトラストセキュリティモデルを長期的に適用することも重要な要件です。管理者や防御者は、デフォルトディニーのセキュリティポリシーを常に適用し、常に違反が発生していると仮定することに疲れてしまうかもしれませんが、ゼロトラストのアプローチが失敗した場合、サイバーセキュリティのメリットが著しく低下したり、排除されたりします。

Carefully minimizing embedded trust empowers a more secure mission

ネットワーク環境がますます複雑化していることと、それを危うくする敵対者の能力には、以下のような対策が必要になります。防御の焦点を変更します。ゼロトラストの考え方では、信頼を排除することで重要なデータとアクセス経路の安全性を確保することに焦点を当てています。可能な限り、すべての許可されたアクセスを検証し、定期的に再検証します。しかし、ゼロ 信頼は軽々しく引き受けてはならず、達成するためには多大な資源と粘り強さが必要になります。適切に ゼロトラストが完全に実装されていれば、侵入の防止、検出、阻止をより速く、より確実に行うことができるようになります。従来のあまり統合されていないサイバーセキュリティのアーキテクチャやアプローチよりも効果的です。

バックアップ

元SKE48メンバーら逮捕 投資助言詐欺疑い(転載)~SKE48は知らないが、自身の経験から保険の重要性を説く立派な卒業生もいれば、詐欺に勤しむカスな卒業生もいる~


為替相場の変動を予想して投資する金融商品「バイナリーオプション」の助言名目で金をだまし取ったとして、愛知県警は16日、詐欺や特定商取引法違反(不実告知)などの疑いで、アイドルグループ「SKE48」元メンバーの無職、山田樹奈(じゅな)容疑者(22)=名古屋市中区=ら男女4人を逮捕した。

 他に逮捕されたのは自営業の車館宙生(くるまだち・ひろむ)容疑者(24)=同市中区、自称店員の高橋美琴容疑者(23)=同市中区、大学生の田口零朗容疑者(22)=同市中区。車館容疑者と高橋容疑者はいずれの容疑も否認、山田容疑者と田口容疑者は詐欺容疑について否認している。

 県警は100人以上から約5800万円をだまし取った疑いがあるとみて全容解明を急ぐ。山田容疑者は会員制交流サイト(SNS)や出会い系アプリで勧誘する役割で、偽名を使い、SKEのメンバーだったことは伏せていた。

米CISA/MS-ISAC発行「ランサムウェアガイド 2020年9月」ランサムウェア対応チェックリスト試訳(転載)

piyokango retweeted: @piyokango 米CISA/MS-ISAC発行「ランサムウェアガイド 2020年9月」ランサムウェア対応チェックリスト試訳 qiita.com/todkm/items/6f… #Qiita:
piyokango retweeted:
@piyokango 米CISA/MS-ISAC発行「ランサムウェアガイド 2020年9月」ランサムウェア対応チェックリスト試訳 qiita.com/todkm/items/6f… #Qiita

はじめに


以下は、米サイバーセキュリティ・インフラストラクチャー・セキュリティ局(CISA)と州横断ISAC(Multi-Sate ISAC)が2020/09/30に共同でリリースした ‘RANSOMWARE GUIDE SEPTEMBER 2020’ の後半部分 Part 2: Ransomeware Response Checklist で、ランサムウェア被害にあったときのチェックリスト形式の対応マニュアルです。一般的な企業なら必要十分でコンパクトな内容だと思います。

直訳で意味が通りづらい部分は適宜意訳しています。米国特有の固有名詞は正確な翻訳を意図していません。

また見出しが長文で書かれている個所は、独自に簡潔な見出しに変更し、見出しだった文章をそのセクションの最初の文にスライドさせています。

Part 2: ランサムウェア対応チェックリスト


万一あなたの組織がランサムウェアの被害者になった場合、CISAは以下のチェックリストを利用して対応することを強く推奨する。最初の3つのステップ(訳注:下記1.~3.のこと)は必ず実施すること。

検知と分析


1. 影響を受けたシステムの特定と即時の隔離


  • 複数のシステムまたはサブネットが影響を受けたと思われる場合、ネットワークをスイッチレベルでオフラインにする。インシデント発生中にシステムを個別に切断できない場合があるため。

  • ただちにネットワークを一時的にオフラインにすることができない場合は、ネットワークケーブル(例. イーサネット)の場所を特定し、感染を封じ込めるために、影響を受けたデバイスのプラグを抜くかWi-Fiから切断する。

  • 最初に侵入した後、攻撃者はあなたの組織の活動や通信を監視して、自分たちの攻撃が検知されていないかを知ろうとする。したがって、組織で協力して、攻撃を検知したことや対策を取ろうとしていることを攻撃者に知られないように、電話などネットワーク以外の通信手段でシステムを隔離すること。さもないと攻撃者は横展開して攻撃を続けようとしたり(これはすでにありふれた戦術になっている)、ネットワークをオフラインにされる前にランサムウェア感染を拡大しようとする。

2. デバイスの電源を落とす例外的なケース

ネットワークからデバイスを切り離せない場合のみ、ランサムウェアのさらなる感染拡大を防ぐため電源を落とす

3. リストアとリカバリの優先順位付け


  • リストアすべき重要システムの特定と優先順位付けをおこない、影響を受けたシステム内のデータの性質を確認する。

  • リストアやリカバリの優先順位付けは、あらかじめ定義しておいた重要情報資産リストに基づいて行う。そのリストには安全衛生、収益源となるシステム、他の重要な情報システムや、それらシステムが依存するシステムも記載しておくこと。

  • 影響を受けていないと思われるためリストアやリカバリの優先順位を下げたシステムやデバイスも記録しておくこと。そうすればあなたの組織はより効率的に業務を再開できるようになる。

4. 初期分析の文書化


あなたのチームと話し合って、起こった事実について最初の分析にもとづく最初の理解を文書化しておく

5. 利害関係者と今後の対応についての合意形成


社内外のチームや関係者がインシデントによる被害の低減や対応、リカバリのために何ができるかを合意しておく。

  • あなたが入手できる情報を共有して、インシデントに関係する支援をいちばんタイムリーに受けられるようにすること。状況の変化に応じて、マネジメントや管理職に定期的に情報提供すること。関係者の中には、IT部門、マネージド・セキュリティサービスプロバイダー、サイバー保険会社、各部署の選任されたリーダーを含めること。

  • 関係する政府機関や、ISAC、地方や国家の司法機関などの支援をうけることも考慮すること。下記連絡先リストを参照。

  • 必要に応じて、広報部門と連携して社内および社外に正確な情報が伝わるようにすること。

  • 'Public Power Cyber Incident Response Playbook' には組織としてのコミュニケーション手順の指針や、対外的なセキュリティインシデント発表のひな型があるので、あなたのチームと協力してできるだけ早く同様の手順や公式発表の草稿を作っておくこと。インシデント発生中に公式発表文を作成するのは最善策ではない。社内外とどの程度詳細に情報共有するのが適切か、情報をどのように流すのかは、このPlaybookを参照すれば事前に決めておくことができる。

封じ込めと除去


6. システムイメージとメモリキャプチャの採取


影響を受けたデバイス(例 ワークステーションやサーバ)のサンプルからシステムイメージとメモリのキャプチャを採取する。

さらに関連するログと、先行して侵入しているマルウェアのバイナリ、それに関連する観測事項やセキュリティ侵害インディケーター(IoC)をすべて収集すること(例. 疑わしいコミュニケーション・アンド・コントロールのIPアドレス、疑わしいレジストリエントリ、その他の検知された関連ファイル)。下記連絡先リストはこれらの作業を支援してくれる。

  • 非常に消失しやすい性質のエビデンスや、一部しか確保できないエビデンスについては、損失や改ざんを防ぐために十分注意して保存すること(例. システムメモリ、Windowsセキュリティログ、ファイアウォールのログバッファ内のデータ)

7. 法執行機関への相談


入手可能な復号方法があるかもしれないので国の法執行機関に相談する。セキュリティー・リサーチャーはすでにいくつかのランサムウェアの暗号化アルゴリズムを解明している。

引き続きインシデントの封じ込めと被害の低減のため、以下のステップを続けること。

8. 影響を受けたシステムの特定と封じ込め


特定のランサムウェアについて信頼できるガイダンスを調査し(例. 政府や各種ISAC、著名なセキュリティーベンダー等)、追加の推奨手順を実施して、影響を受けたことが確定しているシステムを特定し、封じ込める。

  • 既知のランサムウェアのバイナリの実行を停止、または無効化し、システムに対する被害や影響を最小化する。その他、関連する既知のレジストリ値やファイルを削除する。

9. 最初に不正侵入を受けたシステムとアカウントの特定


電子メールアカウントも含む。

10. 関連システムの封じ込め


ここまでで特定された不正侵入や侵害にもとづいて、さらなる不正侵入に継続的に悪用される可能性のある関連システムをすべて封じ込める。

不正侵入は機密情報の大量窃取をともなうことが多い。引き続き認証情報の悪用による不正アクセスから、ネットワークやその他の情報源を守るには、以下の対策を含めてもよい:

  • VPN、リモートアクセスサーバー、シングルサインオン、クラウド、その他の外部公開されている情報資産の無効化。

11. 推奨する追加対策:サーバ側データ暗号化の迅速な特定


  • 感染したワークステーションによってサーバ側のデータまで暗号化されてしまった場合、それを素早く特定する手順は以下のとおり。
  1. 関連するサーバーで「コンピュータの管理」>「セッション」および「開いているファイル」をチェックし、それらのファイルにアクセスしているユーザーやシステムを特定する。

  2. 暗号化されたファイルやランサムノートのファイルプロパティーをチェックし、それらのファイルの所有者となっているユーザーを特定する。

  3. ターミナルサービスのリモート接続マネージャーのイベントログをチェックし、成功しているRDP接続がないか確認する。

  4. Windowsセキュリティログ、SMBイベントログ、関連するすべてのログをチェックし、重要な認証イベントやアクセスイベントがないか確認する。

  5. 影響を受けたサーバーでWiresharkを実行し、ファイルの書き込みや名前の変更に関係するIPアドレスをフィルタで特定する(例 “smb2.filename contains cryptxxx”)。

12. 侵入検知・防止システムのログ精査

組織にある既存の検知システムまたは防止システム(ウイルス対策、エンドポイント検知対応(EDR)、IDS、侵入防止システム(IPS)等)およびログの精査をする。

それによって攻撃の初期段階に関係していた、別のシステムやマルウェアについてエビデンスを明らかにできる。

  • 先行して侵入している「ドロッパー」マルウェアのエビデンスを探す。ランサムウェア感染はそれ以前に起こっていた未解決のネットワーク不正侵入の証拠かもしれない。ランサムウェア感染は、TrickBot、Dridex、Emotetといったランサムウエアがすでに存在していた結果であることが多い。

  • これら最新のマルウェアのオペレーターはネットワークへのアクセス方法を販売していることが多い。場合によっては、攻撃者はそうしたアクセス方法を悪用してデータを窃取してから、データを公開するぞと脅迫した後で、さらに被害者を脅迫して支払いを迫ろうとネットワークをランサムウェアに感染させる。

  • 攻撃者はネットワークに手動でランサムウェアをドロップし、不正侵入後の活動を分かりにくくする場合がある。継続的な侵入を防ぐには、バックアップから復旧させる前にそのようなドロッパーを注意して特定しておく必要がある。

13. 継続的攻撃の分析

外部から内部、内部から外部への継続的攻撃のメカニズムについて踏み込んだ分析を行う

  • 外部から内部(outside-in)の継続的攻撃には、不正アカウントによる外部システムへの認証済みアクセスや、境界システムのバックドア、外部システムの脆弱性の不正利用などが含まれることがある。

  • 内部から外部(inside-out)の継続的攻撃には、内部ネットワークに埋め込まれたマルウェア、または環境寄生(自給自足)型のシステム変更(例. Cobalt Strikeのような市販の侵入テストツールの悪用、PsExecを含むPsToolsの悪用、マルウェアを遠隔インストールし制御することによるWindowsシステムの情報収集や遠隔管理操作、PowerShellスクリプトの悪用)が含まれることがある。

  • これらを特定する方法として、エンドポイント検知・対応(EDR)ソリューションの導入や、ローカルとドメインのアカウント監査、集中ログ収集システムで見つかったデータの精査、環境内での動きが一度でも特定された場合は、その該当するシステムのより深いフォレンジック分析が含まれることがある。

14. 優先順位に基づくシステム復旧


重要なサービスの優先順位付けに基づいてシステムを復旧する。(例:安全衛生または収益源となるサービス)

できればあらかじめ設定済みの標準イメージを利用する。

15. パスワードリセットと未対応部分への対処


環境が完全にクリーンにされ復旧した後(影響を受けたすべてのアカウントや継続的な不正メカニズムの除去を含む)、影響を受けたすべてのシステムのパスワードリセットを行い、セキュリティ面や可視化されていなかった部分の脆弱性や未対応部分に対処すること。

パッチの適用、ソフトウェアのアップグレード、その他それまで講じていなかったセキュリティ予防策の実施が含まれることもある。

16. インシデント終了宣言


上述の手順を踏むことや外部の支援を得ることも含め、確立された規準にもとづいて、所定のIT部門またはITセキュリティ責任者がランサムウェア・インシデントの終了を宣言する。

復旧とインシデント終了後の活動


17. システムの再接続とデータのリストア


システムを再接続し、重要なサービスの優先順位付けにもとづいてオフラインで暗号化されたバックアップからデータをリストアする。

リカバリー中にクリーンなシステムを再感染させないように注意すること。例えば、リカバリのために新たなVLANを構成する場合、確実にクリーンなシステムのみを追加すること。

18. 学びや対応結果の文書化


インシデントからの学びや関連するインシデント対応活動を文書化することで、組織のポリシー、計画、手順を更新・改善するための情報源として活かし、同様のインシデントについて今後の演習のガイドとする。

19. 当局や業界団体などとの情報共有


インシデントからの学びや関連する侵害インディケーター(IoC)を当局に共有し、さらに業界ISAC、情報共有分析機関(ISAO)にも共有し、コミュニティー内部の他の人々や組織の利益にもなるように考慮する。



インターネットに晒されている機器を調べるサイト【SHODAN】


SHODANという検索エンジンがある。

一時期はIoT検索エンジンとか言われていたが、ネット上に晒されている機器を検索することができるサービスである。

https://www.shodan.io/

アクセスすると、検索ウィンドウがあると思うので、IPアドレスやポート番号等のキーワードを入れて検索する。

※注:罠の可能性もあるので、脆弱っぽい機器を見つけたとしても安易にアクセスしないでください。

【インターネット直結のプリンタでパスワード設定が無い機器を調べるときの例】
printer password is not set

【日本国内でtelnetがオープンになっているインターネット機器を調べるときの例】
country:"JP" port:23

【日本国内のAnonymous FTPを調べるときの例】
country:"JP" Anonymous FTP

【日本国内でインターネットにポート445がオープンになっているWindows PC(Windowsサーバは除外)を調べるときの例】
port:445 country:"JP" OS:"Windows" country:"JP" !OS:"Server"

【既知の脆弱性(例:CVE-2019-0708)を持つデバイスを検索するときの例】
vuln:CVE-2019-0708
            ※フリーアカウントでは不可。

Onion Address(v2/v3)を検索するときの例
"Onion-Location"

【参考】
日本国内で接続されている IoT 機器数(IPA)
https://www.ipa.go.jp/security/iot/20170417.html

増加するインターネット接続機器の不適切な情報公開とその対策(IPA)
https://www.ipa.go.jp/files/000052712.pdf

Exchange Serverの脆弱性まとめとSHODANでの観測状況(マクニカネットワークス)
https://blog.macnica.net/blog/2020/06/exchangeserver-shodan.html

OSINT 用検索エンジンあれこれ
https://ninoseki.github.io/2018/12/03/osint-search-engine.html

-2020/7/11追記-
【ダークウェブのIPアドレス調査の例】

-2020/8/26追記-

【特定のドメイン(証明書のコモンネーム)を調べる場合の例】

-2020/9/1追記-
【IPで検索する場合の例】
net:115.165.122.0/24

-2021/3/16追記-
【検索フィルタ一覧】
filterdesc.
asnThe Autonomous System Number that identifies the network the device is on.
beforeOnly show results that were collected before the given date (dd/mm/yyyy.
cityShow results that are located in the given city.
countryShow results that are located within the given country.
geoThere are 2 modes to the geo filter: radius and bounding box. ex: geo:50,50,100. or geo:10,10,50,50.
hashHash of the "data" property
has_ipv6If "true" only show results that were discovered on IPv6.
has_screenshotIf "true" only show results that have a screenshot available.
hostnameSearch for hosts that contain the given value in their hostname.
ispFind devices based on the upstream owner of the IP netblock.
linkFind devices depending on their connection to the Internet.
netSearch by netblock using CIDR notation; ex: net:69.84.207.0/24
orgFind devices based on the owner of the IP netblock.
osFilter results based on the operating system of the device.
portFind devices based on the services/ ports that are publicly exposed on the Internet.
postalSearch by postal code.
productFilter using the name of the software/ product; ex: product:Apache
stateSearch for devices based on the state/ region they are located in.
versionFilter the results to include only products of the given version; ex: product:apache version:1.3.37
bitcoin.ipFind Bitcoin servers that had the given IP in their list of peers.
bitcoin.ip_countFind Bitcoin servers that return the given number of IPs in the list of peers.
bitcoin.portFind Bitcoin servers that had IPs with the given port in their list of peers.
bitcoin.versionFilter results based on the Bitcoin protocol version.
http.componentName of web technology used on the website
http.component_categoryCategory of web components used on the website
http.htmlSearch the HTML of the website for the given value.
http.html_hashHash of the website HTML
http.statusResponse status code
http.titleSearch the title of the website
ntp.ipFind NTP servers that had the given IP in their monlist.
ntp.ip_countFind NTP servers that return the given number of IPs in the initial monlist response.
ntp.moreWhether or not more IPs were available for the given NTP server.
ntp.portFind NTP servers that had IPs with the given port in their monlist.
sslSearch all SSL data
ssl.alpnApplication layer protocols such as HTTP/2 ("h2")
ssl.chain_countNumber of certificates in the chain
ssl.versionPossible values: SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2
ssl.cert.algCertificate algorithm
ssl.cert.expiredWhether the SSL certificate is expired or not; True/ False
ssl.cert.extensionNames of extensions in the certificate
ssl.cert.serialSerial number as an integer or hexadecimal string
ssl.cert.pubkey.bitsNumber of bits in the public key
ssl.cert.pubkey.typePublic key type
ssl.cipher.versionSSL version of the preferred cipher
ssl.cipher.bitsNumber of bits in the preferred cipher
ssl.cipher.nameName of the preferred cipher
telnet.optionSearch all the options
telnet.doThe server requests the client to support these options
telnet.dontThe server requests the client to not support these options
telnet.willThe server supports these options
telnet.wontThe server doesnt support these options