Googleが10億の悪質なメール詐欺から学んだこと / What Google learned from 1 billion evil email scams(転載)~攻撃全体の5%は日本が標的~


What Google learned from 1 billion evil email scams:

Googleとスタンフォード大学の研究者が、世界的に送信されたフィッシング/マルウェアのメールを5ヶ月間分析した詳細な調査結果を発表しました。"メールベースのフィッシングやマルウェアに狙われているのは誰か?リスクを差別化する要因を測定する」と題して、10億通以上のメールを調べた。その結果は、インターネット測定会議でのプレゼンテーションに反映された。

Gmailによって自動的にブロックされたフィッシングやマルウェアキャンペーンについて調べたところ、フィッシングの世界での現在の傾向や出来事について、かなりのことを発見したそうです。

不正メール分析:主な調査結果

  • 攻撃の42%が米国内のユーザーを標的に
  • 英国の10%のターゲットユーザー
  • 日本に拠点を置くユーザーを対象とした攻撃は5%に上る

攻撃は主に北米と欧州を中心に行われ、米国はフィッシングやマルウェアメールの受信量が最も多い。しかし、最もリスクが高い国はアフリカとヨーロッパです。調査によると、16カ国が米国よりも平均的に高いリスクを示しています。

英語:詐欺の国際言語

ローカライゼーションは特に人気があるわけではなく、ほとんどの攻撃者は英語のメールテンプレートを複数の国に展開しています。フィッシングメールの83%、マルウェアメールの97%は英語で書かれている。しかし、日本国内のフィッシングメールの78%は日本語で書かれており、一部のローカライズが行われていることにも注目している。

1つのテンプレートは100~1,000人のターゲットに送信され、キャンペーンは平均して1~3日で終了します。小規模なキャンペーンでは、1週間で1億通以上のGmailユーザーを対象としたフィッシングメールやマルウェアメールが送られてきます。

年齢層、データ漏洩、デバイスの減少

ターゲットにされるリスクは、各年齢層が上に行くほど少しずつ増えていきます。もしあなたが55-64歳であれば、18-24歳や35-44歳の年齢層よりも魅力的な提案をされる可能性があります。これは、理論的には高齢者ほど詐欺に遭いやすいということなのか、それとも単にオンラインでの足跡を見つけやすいということなのか、どちらにしても決められていません。

過去のデータ侵害はリスクを高めます。データ漏洩で個人情報が公開された場合、攻撃される確率ははるかに高くなります。覆水盆に返らずですし、詐欺師が積極的にメールを列挙したり、人口統計学的情報を掘り下げたりするのは理にかなっています。

携帯電話に固執することで攻撃のリスクが最も低くなりますが、複数のデバイスを使用することで最も高いリスクが発生します。1台のパソコンを使用すると、その中間に位置することになります。

Webシェル攻撃とはどんなものか(転載)

Webシェル攻撃とはどんなものか Microsoft 365 Defenderが月間14万件も検出する脅威

 Microsoftは2021年2月11日(現地時間)、サイバー攻撃でWebシェルが使われるケースが増えていると公式ブログで報告した。『Microsoft 365 Defender』のデータによると、2020年8月から2021年1月末までの期間においてWebシェルが使われた脅威の件数は月平均14万件に到達しており、前年の7万7000件のほぼ2倍に達しているという。

 ユーザーが何らかの方法で任意のコマンドをサーバ実行するためにWebサーバにインストールして使うソフトウェアやその仕組みを「Webシェル」と呼ぶ。

 Webシェルは特定のソフトウェアを指すのではなく、PHPやASPのようなプログラミング言語の実行環境を指す。そうしたプログラミング言語にはシステムの任意のコマンドを実行するために幾つかの手段が用意されている。

 攻撃者はさまざまな方法でこの機能を使い、遠隔からサーバ上で任意のコマンドを実行できるようにして攻撃する。Webシェルがサイバー攻撃に使われていることは以前からよく知られており、増加傾向が続いていることも報告されていた。今回のMicrosoftの報告はこの傾向が継続しているのみならず、これまでよりも速いペースで増加していることを示した。

 Webシェルのインストールは通常、Webアプリケーションの脆弱性を利用する形で実行される。インターネットには脆弱性を修正するパッチが適用されないまま運用されているサーバが多数存在する。攻撃者はこうしたサーバをスキャンによって発見し、Webシェルのインストール先として利用する。

 Webシェルは比較的簡単に設置でき、効果的に利用できることから、サイバー攻撃において利用が活発化している可能性が指摘されている。攻撃のエントリーポイントとして使用できる他、攻撃を永続化する仕組みとしても使用できる。Webシェルは構成によっては検出が難しく、実際に実行されなければ危険性を検出できないものも多い。今後もWebシェルを使用したサイバー攻撃は増加することが予測されるため注意が必要だ。

オープンソースの航空機データベース / Launching an Open Source Aircraft Database for Venezuela(転載)

Launching an Open Source Aircraft Database for Venezuela


近年、航空機の追跡は、オープンソースの研究者のツールボックスの中でも重要な役割を果たしています。航空機追跡サイトでは、警察の活動からCOVID-19ワクチンの配送まで、あらゆることを誰でも監視することができます。このガイドで書いたように、航空機が上空でどのような動きをしているかを知ることができれば、進行中のイベントをフォローしたり、ニュースを先取りしたりするのに役立ちます。

多くの民間航空局は、航空機の登録情報をオンラインで公開しています。米連邦航空局(FAA)のFAAレジストリ、カナダ運輸省のCanadian Civil Aircraft Register、英国のG-Infoレジストリなどがこれにあたります。航空機の登録番号を知っていれば、各国の登録ページで調べて、航空機のモデル、シリアル番号、登録者などの情報を得ることができます。

しかし、すべての民間航空局がこのように航空機の登録情報を公開しているわけではありません。ベネズエラの場合、民間航空局(Instituto Nacional de Aeronautica Civil:INAC)はこのような情報をオンラインで提供していません。そのため、ベネズエラの航空機登録情報を知りたい研究者は、他の情報源を探す必要がある。

2020年1月、ベネズエラで登録された航空機のオープンデータベースを開始しました。オープンソースのフライトトラッキングデータと、航空機追跡愛好家からの有益なアドバイスを利用して、このデータベースには約240機の航空機の詳細が含まれています。これらの航空機の大部分はベネズエラで登録されているが、中にはベネズエラと何らかの関係がある外国籍のものもある(詳細は後述)。

このデータベースは、登録番号やシリアルナンバーなどの航空機の識別情報を一元的に管理するためのものです。 このデータベースには、航空機のスポッターが撮影した写真や飛行履歴などの追加情報も含まれている。航空会社に登録されている民間航空機のように、航空機の所有権が明らかなものもありますが、他の航空機の所有者や運航者を特定することははるかに困難です。そのため、航空機がいつどこに移動したのかを知ることは、ベネズエラの富裕層や権力者の動きと関連があるかもしれないからだ。

データベースの概要

データベースに登録されている情報の大部分は、4つのフライトトラッキングプラットフォーム(addsbexchange.com、opensky-network.org、flightradar24.com、radarbox24.com)という複数のソースから得られたものです。データのほとんどは、過去1年間にこれらのサイトをライブモニターして収集したものです。また、航空機愛好家の方々からは、航空機に関するデータを提供していただいたほか、データベースをより便利にするためのフォーマットに関するヒントもいただきました。

データベースのカラムは、4つの「識別子」カラム、1つの「注記」カラム、そして(現時点では)10の「追加情報」カラムに分類されています。

以下では、各カラムの目的を説明するガイドと、このデータベースがどのように利用されているかを示す初期の例を紹介します。

列の入力には、Google SheetsのCONCATENATE機能を使用しています。これにより、文字列の結合やURLの自動入力が可能になります。フライトトラッキングサイトでは通常、検索を行うために飛行機の登録番号か24ビットのICAOアドレスのいずれかを入力する必要がある。

しかし、各サイトが検索後にどのようにURLを入力するかを見ることで、CONCATENATE機能を使って、他の関連する飛行機登録や24ビットICAOアドレスのために必要なURL検索の全文を予測し、自動的に入力することができます。

例えば、下の画像は、opensky-network.orgに登録されているYV2966という航空機の検索結果を示しています。このURLは「0D81C9」で終わっていますが、これはこの飛行機の24ビットICAOアドレスです。


opensky-network.org検索のURL構造が航空機の24ビットのICAOアドレスで終わることを知っているので、CONCATENATE関数を使ってこのデータを列に入力し、サイトへのリンクを自動的に生成することができます。下の画像では、「$D73」は、24ビットのICAOアドレスを含むD列と、YV2966のそのアドレスを含む73行を指しています。


それを踏まえた上で、コラムの内容をご紹介します。

このデータベースがスペイン語で書かれているのは、ベネズエラの研究者や市民ジャーナリストが、自国の空を記録することに興味を持つことを想定しているからです。

識別子

A列からD列には、航空機の登録番号、モデル番号、製造者シリアル番号、および固有のICAO 24ビットアドレス(「ヘックスコード」とも呼ばれる)が記載されています。これらの情報により、航空機を歴史的にもリアルタイムにも追跡することができます。多くの場合、データベース内の情報は、2つまたは3つの異なるオープンソースを使用して編集されています。

これらの欄の情報は、航空機がベネズエラの空域で観測された後に、上記のフライトトラッキングウェブサイトの1つに手動で入力されています。

メモ

E欄の「メモ」には、航空機に関する興味深い情報や潜在的な関連情報が記載されています。このノートには、その航空機が過去に行った旅行や、その航空機について言及したニュース記事やプレスリリースなどが含まれます。

例えば、このデータベースに登録されている十数機の航空機が、米国財務省が公表した制裁リストに登場しています。例えば、2020年1月21日に他の14機とともに制裁を受けたボンバルディア・リアジェット45のYV2738は、国営石油会社であるペトロロス・デ・ベネズエラ(PDVSA)の所有物であることが理由である。今回の制裁は、ベネズエラのニコラス・マドゥロ大統領の政権に「圧力」をかけるためにトランプ政権が行った広範な行動の一環である。

メモ欄には、カラカス中心部にあるGeneralissimo Francisco de Miranda空軍基地(俗称:La Carlota)からの着陸または離陸も観測されています。この空軍基地は軍事施設であり、少なくとも2014年以降は民間機の飛行が公式に禁止されているため、ここに着陸する民間機は注目に値する。一般の航空会社や民間航空機は、カラカスの南と北にそれぞれあるオスカー・マチャド国際空港とシモン・ボリバル国際空港を利用するのが一般的だ。それでも、セスナS550サイテーションSIのYV3310は、11月23日の朝、シウダー・グアヤナに向かうためにラ・カルロータを離陸しました。

ベネズエラのニュース「El Diario」によると、Conviasa(国営フラッグキャリア)は、滑走路が商業用に閉鎖されているにもかかわらず、La CarlotaからLos Roques島群島へのフライトを運航し、ベネズエラの富裕層や権力者にサービスを提供しているとのことです。データベースのフライトトラッキングツールを使えば、他にどのような航空機がこの基地を利用しているかを確認することができます。


追加情報

F列からO列には、各航空機の追加情報が記載されています。これらの情報は、飛行履歴、登録データ、インシデントデータ、写真、およびTwitterから取得したデータに分類されています。

各項目の説明は以下の通りです。

Flight historyF-I列には、adsbexchange.com、flightradar24.com、radarbox24.com、およびflightawareからのフライト履歴データが含まれています。フライト履歴は、サイトによっては様々な費用をかけて有料で提供されているため、各サイトによって大きく異なる場合があります。

Registration DataJ列はplanelogger.comからの登録履歴です。そのような情報が利用可能な場合、この欄には、航空機が持っていた以前の登録/所有者のリストが表示されます。Planeloggerによると、YV3016になってConviasaに所属する前は、FAB2592としてブラジル空軍に所属していました。 


Incident HistoryK列は、航空事故に関するデータをまとめたウェブサイト「Aviation Safety Network」から、航空機の事故履歴を示しています。例えば、YV1118のエントリーでは、2017年9月19日にサンタ・エレナ・デ・ウアイレン空港の着陸帯をオーバーランしたことが示されています。 

Planespotter PicturesL列とM列には、人気の高い航空画像サイトであるplanespotters.netとjetphotos.comでplanespottersが撮影し、共有している航空機の画像へのリンクがあります。

これらの画像は、航空機に関する視覚的なデータを提供するだけでなく、航空機の飛行履歴に関する情報が含まれていることもあり、有用です。例えば、jetphotos.comのYV2152のエントリーには、2017年11月24日にグアテマラシティのラ・アウロラ国際空港で撮影された同機の画像が含まれており、その日に同機がその場所に存在していたことを視覚的に確認することができます。

Twitter InformationN列とO列には、航空機の登録番号や24ビットのICAOアドレスに言及したツイートの検索結果が含まれています。この2つの識別子は、趣味や研究者、ジャーナリストが航空機についてツイートする際に使用される可能性が高いものです。

これらのTwitter検索の情報は、航空機の所有者や過去の履歴に関する重要な情報を、その航空機についてのツイートやスレッドの形で提供することができます。

Other DetailsP列には、ホビー用フライトトラッキングサイトであるopensky-network.comのデータが含まれています。この情報には、航空機のシリアル番号、年代、ヘックスコード、登録所有者などが含まれます。

Q列とR列は、航空機を空軍、民間、航空会社、国際に分類し、Conviasaに登録されているかどうかを示しています。

ゼロ・トラストはどこから始まり、なぜ重要なのか? / Where Does Zero Trust Begin and Why is it Important?(転載)



 ゼロトラストは、情報セキュリティアーキテクチャの重要な転換です。これは、過去の境界線の防御を詳細に記述したモデルから、最も価値のあるもの、つまりデータに近い制御層へと私たちを連れてきます。フォレスター社のアナリストが最初にゼロトラストを定義したとき、ゼロトラストは攻撃者の横移動を防ぐためにアプリケーションを隔離するネットワークに焦点を当てていました。その後、マイクロサービスを含むコンポーネント間の認証と保証を提供することで、粒度が高く浸透したものへと進化してきました。

ゼロ・トラストのメリットがますます明らかになるにつれ、このモデルの普及は明らかになり、NIST Special Publication 800-207で定義されているように、信頼されたコンピューティング・ベースとデータ中心の制御に依存しています。では、ゼロ・トラストがより普及するにつれ、それは何を意味するのでしょうか。IT およびサイバーセキュリティの専門家は、どのようにして導入を管理し、その有効性の保証を維持するのでしょうか?

ゼロトラストアーキテクチャ。絶対に信頼しない、常に検証する

ゼロトラストアーキテクチャは、スタックのどの層も、それがハードウェアであろうとソフトウェアであろうと、基礎となるコンポーネントを信頼していないという点を強化します。そのため、セキュリティプロパティは、最初の使用時と断続的な使用時に、すべての依存関係と相互依存関係に対して期待通りであることを保証するために検証されます(ゼロトラストの動的な認証と検証の考え方)。各コンポーネントは、隣接するコンポーネントや依存するコンポーネントが脆弱である可能性があるかのように構築されます。そのため、個々のコンポーネントは、それが主張された信頼レベルを保証するコンポーネントである必要があり、侵害または侵害の試みを検出できる必要があると想定しています。

これは、ゼロトラストがすべての層で分離の原則を植え付けるという点で、少し混乱を招くパラダイムである可能性があります。これは、コンポーネント間のいわゆるゼロトラストのポイントを強制しますが、セキュリティ特性とアイデンティティの検証は、期待される制御が満たされていることを保証するために継続的に実行されます。あるコンポーネントは、依存関係の期待される特性が保証されていない場合、実行しないことを選択するかもしれません。ゼロトラストアーキテクチャは、「絶対に信頼せず、常に検証する」ことを保証します。これにより、各コンポーネントの横移動や特権実行の検出と防止が可能となり、システムとソフトウェアの保証が向上します。

基本理念

アイデンティティ、認証、認可、アクセス制御、暗号化は、コンポーネント間の保証を検証するために意図的かつ動的な意思決定が継続的に行われるゼロ・トラスト・アーキテクチャの中核的な考え方の一つです。ゼロ・トラストは、フォレスター社の概念として生まれた結果、ネットワーク層で議論されることが多いですが、ゼロ・トラストの定義は、過去10年間でかなり進化し、インフラストラクチャ、デバイスのファームウェア、ソフトウェア、およびデータにまたがる普及した概念となっています。

ゼロトラストは、ネットワークに関連してよく議論されますが、ネットワークセグメントごとにアプリケーションを分離し、強力な暗号化や動的認証などの制御が満たされていることを保証します。ゼロトラストはマイクロサービスレベルでも適用でき、サービス間の検証を通じて制御と測定の保証を提供します。このモデルを詳細に適用することで、攻撃者の横移動の防止と検出がさらに強化されます。

インフラストラクチャの保証

ゼロトラストは、インフラストラクチャの保証から始まります。Hardware root Of Trust (RoT)は、Trusted Platform Module(TPM)にバインドされた暗号化されたアイデンティティで不変です。このインフラストラクチャ保証の例では、ゼロトラストアーキテクチャの原則を説いています。ブート時に、システムはまず、ハードウェアコンポーネントが期待通りであることを確認します。

次に、システムブートプロセスは、システムと各依存関係を、TPM 内の暗号化 ID を使用してデジタル署名で証明された、期待される測定値を含む、いわゆる「ゴールデンポリシー」のセットに対して検証し始めます。ポリシーの比較が一致しない場合は、プロセスが再起動されたり、システムのブートプロセスが停止されたりします。ハードウェアとソフトウェアベースの RoT オプションはいくつかありますが、ブートからファームウェアと BIOS の回復力のガイドラインは、一般的にポリシーと測定値の開発に従います。

認証は、ブートプロセスの各段階で RoT によって署名され、依存するコンポーネントを識別すると同時に、信頼の保証を提供するために使用されます。依存関係は連鎖させることもできますし、個別に検証することもできます。これらのアテステーションは実行時にも提供され、動的認証とアクセス制御(この場合はインフラストラクチャコンポーネント)の信頼ゼロ要件をサポートする。アテステーションは、コンポーネントの身元を確認するための要件を支援し、コンポーネントの保証を提供するために不可欠なものです。

コンポーネントやソフトウェアに侵入した攻撃者は、脅威であり続けるため、この動的で定期的な検証と認証で生き延びる必要があります。また、攻撃者は、権限をエスカレートさせたり、互いに信頼できない分離されたコンポーネント間で横方向に移動したりする方法を見つけ出さなければなりません。

信頼されたコントロールセット

NIST の Firmware Resiliency Special Publication に基づいた Trusted Computing Group (TCG) の Reference Integrity Manifest は、ファームウェアのポリシーと測定のための信頼できるコントロールを提供します。スタックを上げていくと、ゼロトラストに必要な検証を提供するための信頼されたコントロールセットには、CIS コントロールと CIS ベンチマークが含まれています。NIST、CIS、TCG などの信頼された第三者は、コントロールとベンチマークの要件を設定するために必要な外部で確立された検証プロセスを提供する。この例としては、特定の保証レベルのCISオペレーティングシステムまたはコンテナベンチマークに準拠するために使用される証明書が挙げられる。

ゼロ・トラストへのシフトを支える証拠は?

興味深いことに、ゼロ・トラスト・アーキテクチャが形になり始めたのとほぼ同時期に、ロッキード・マーチンはサイバーキルチェーンを開発した(2011年)。Cyber Kill Chain は、攻撃の段階を分離し、段階間での緩和と検知の防御を可能にするために最初に定義されました。MITRE ATT&CK フレームワークは、ロッキード・マーチンのモデルを基礎に、使用から学んだギャップや進化する脅威の状況を考慮して、今日では主に使用されている。本論文では、相関プロセスを単純化するためにサイバーキルチェーンを使用するが、MITRE ATT&CK フレームワークに抽象化することも可能である。

ロッキード・マーチンのキルチェーンは、サプライチェーン攻撃を含む高度な持続的脅威攻撃(APT)の巧妙化に対応するために開発されました。認証を介して(動的に)身元を証明する要件を含む、攻撃フェーズ間の防御と制御を実装することで、攻撃者の横移動や特権昇格の試みをより簡単に検知できるようになりました。キルチェーンの早い段階で検知と防御を行うことは、攻撃の成功(データの流出やネットワーク内の混乱など)を防ぐために理想的である。

検出と防御の技術をスタック内やアプリケーションや機能全体に広く適用し、認証済みコンポーネントを検証するために動的アクセス制御を使用することで、ゼロトラストのアーキテクチャのテネ ットをサポートし、キルチェーンの早期検出を可能にしています。ゼロトラストの考え方が機能している証拠は、攻撃者の滞留時間パターンによって証明されているように、キルチェーンの検出制御と併用して展開することを考慮すれば明らかです。

ドウェルタイムの低減

キルチェーンが初めて使用されて以来、攻撃者の滞留時間(攻撃者がネットワーク上で検知されずに留まる時間)は劇的に短縮されてきました。これは、地域によってサイバーキルチェーンとゼロトラストの防御策が採用されたことで、世界的な滞留時間と地域的な滞留時間の両方が変化したことで明らかになっています。FireEyeのM-Trendsの年次報告書によると、世界の滞留時間の中央値は2013年に229日、2020年の報告書では56日となっています。ゼロトラストのアーキテクチャパターンとキルチェーンとMITRE ATT&CKの防御フレームワークの採用には格差があることが知られており、地域別の数字もこのアーキテクチャアプローチの成功を裏付けています。

その両方をいち早く取り入れたのがアメリカであることが知られていました。2017年を例に挙げると、アメリカ大陸の滞留時間の中央値は75日、アジアの滞留時間の中央値は172日でした。小規模な組織や、どの地域でもリソースの少ない組織は、どの時点でも、大規模でリソースの豊富な組織とは大きく異なる滞留時間を経験する可能性があります。滞留時間の数値は、これらの管理が成功していることを具体的なデータで実証するのに役立つ。

ゼロトラストは、アプリケーションが分離されたネットワークのみの定義から、すべてのコンポーネント間の予期せぬ動作の検出をサポートするために、より詳細なレベルへと進化しました。ゼロトラストとロッキードのキルチェーンの間の論理的なつながりは、モデルの明確な価値を示しています。これはまた、ゼロ・トラストの将来を、インフラストラクチャの起動からマイクロサービスレベルに至るまで、その身元と保証レベルが検証されていることを保証する分離されたコンポーネントの基盤の上に構築され、ますますデータ中心になっていくと予測することにも役立ちます。

NIST SP 800-207では、ゼロトラストを次のように定義しています。

"ゼロ・トラスト(ZT)は、ネットワークが危殆化していると見られる状況下で、情報システムやサービスにおいて、正確で、要求ごとに最小の特権を持つアクセス決定を実施する際の不確実性を最小化するために設計された概念と考え方の集合体を提供します。ゼロ・トラスト・アーキテクチャ(ZTA)は、ゼロ・トラストの概念を利用した企業のサイバーセキュリティ計画であり、コンポーネントの関係、ワークフロー計画、アクセス・ポリシーを包括しています。したがって、ゼロ・トラスト・エンタープライズとは、ゼロ・トラスト・アーキテクチャ計画の成果物として、企業のネットワーク・インフラストラクチャ(物理的および仮想的)と運用ポリシーのことを指します。"

以下のリストは、NIST CSRC Publication SP 800-207から引用したものです。

  1. すべてのデータソースとコンピューティングサービスは、リソースと見なされます。
  2. 場所に関係なく、すべての通信が安全に行われます。
  3. 個々の企業リソースへのアクセスは、セッションごとに許可されています。
  4. リソースへのアクセスは動的なポリシーによって決定されます。
  5. 所有するすべてのデバイスと関連するデバイスは、可能な限り最も安全な状態になっています。
  6. すべてのリソースの認証と認可は動的であり、厳密に実施されます。
  7. ネットワークインフラの現状をできるだけ多くの情報を収集し、セキュリティ姿勢の向上を図る

ロッキードのキルチェーンの目的は、脅威を積極的に検知することである。ゼロ・トラストの原則は、キルチェーンの段階に沿った予防と検出を支援します。

ロッキードのキルチェーン

  1. 偵察。メールアドレス、会議情報、ネットワークデータの収集
  2. 武器化 配信可能なペイロードへのバックドアを持つエクスプロイトの結合
  3. 配信すること。兵器化されたバンドルをメール、ウェブ、USBなどを介して被害者に配信すること
  4. エクスプロイテーション。脆弱性を利用して被害者のシステム上でコードを実行すること
  5. インストールすること。アセットへのマルウェアのインストール
  6. コマンド&コントロールC2 犠牲者を遠隔操作するためのコマンドチャンネル
  7. 目的に対する行動。キーボードを手で操作することで、侵入者は本来の目的を達成することができます。

みずほ、甘い想定重ね被害拡大 ATM障害、顧客目線の業務体制課題(転載)~みずほ10年ごとに大規模障害を起こす?~


みずほ、甘い想定重ね被害拡大 ATM障害、顧客目線の業務体制課題

データ移行で発生したみずほ銀行のシステム障害についてまとめてみた

2021年2月28日、みずほ銀行でシステム障害が発生し、全国で同行のATMが利用できなくなる、キャッシュカードが取り込まれたまま戻ってこないなどのトラブルが発生しました。ここでは関連する情報をまとめます。

取り込まれ戻ってこないキャッシュカード

f:id:piyokango:20210301045353p:plain
みずほ銀行サイト上に掲載されたシステム障害発生の案内

障害が発生したのは2021年2月28日11時頃。障害により各地で生じた影響は以下が報じられるなどしている。なお、法人向けに提供されるサービスでは今回のシステム障害による不具合は確認されていない。

  • みずほ銀行の自行ATM5,395台の内、54%にあたる2,956台が停止し(2月28日19時40分頃時点)、預金引き落とし等が出来なくなった。台数はその後訂正され、最大4,318台が停止していたことが明らかにされた。 
  • 障害発生中は、ATMよりキャッシュカード、通帳が機器から戻されない事象が発生。取り出せなくなる影響を受けた件数は5,244件。
  • インターネットバンキング(みずほダイレクト)の一部の取引(定期預金、グローバル口座サービス)でもシステム障害が発生。



日時出来事
2021年2月28日午前定期預金のデータ移行作業中にシステム障害が発生。
同日 11時頃全国に設置されたみずほ銀行の一部のATMが利用できなくなる障害が発生。
同日 13時頃みずほ銀行がWebサイト上にシステム障害の発生を掲載。
同日 午後みずほ銀行がWebサイト上にデータ移行が原因であり復旧対応中であることを掲載。
同日 夜システム障害の復旧完了。
2021年3月1日7時店舗外のATMなどを中心に一部再開が出来ず。
同日 9時頃全国支店に設置されたATMなどをすべて復旧。
同日 15時頃稼働確認ができていなかった店舗外42台の復旧を確認。
同日 夕方みずほ銀行が今回のシステム障害について記者会見。頭取が謝罪。
2021年3月2日キャッシュカード、通帳の返却が8割完了。
2021年3月3日金融庁がみずほ銀行に報告徴求命令。

他行利用による手数料は後日返金

  • ATM不具合はイオン銀やゼブン銀、ローソン銀のATMでは発生しておらず、同行ATM以外を利用した際にかかる手数料は後日返金される。これ以外に代替手段により生じた費用についても取引店舗に相談するように案内が行われている。
  • ATMに取り込まれたままのキャッシュカードや通帳は後日返却対応が行われる。他行キャッシュカードの場合は他行経由での返却手続きとなることが案内されている。

機器再起動で順次復旧

  • Webサイト上にはシステム障害は解消したと掲示されている(3月1日4時頃確認)。
  • インターネットバンキング(みずほダイレクト)は3月1日0時時点で復旧済み。
  • ATMや通帳繰越機は機器の再起動が必要で、2月28日21時までに復旧作業は完了しなかった。
  • 再起動が行われた店舗より順次復旧していると説明し、2021年3月1日サービス開始時(朝7時)までの復旧を目指していたが、3月1日7時開始予定の拠点の内、主に銀行店舗外に設置されたATMが復旧できていないとしてリストが掲示された。8時以降にサービスを開始予定している拠点で現在作業中となっているのは51か所とした。(3月1日9時半時点)

データ移行中の不具合が原因


事前見積を超える処理量でシステム過負荷

www.youtube.com

  • 3月1日の記者会見でデータ移行と月末処理による過負荷が障害の原因であったことが明らかにされた。当時対応が行われていたのは定期預金のデータ移行45万件と月末処理25万件の70万件。
  • 通常は実施しない定期預金のデータ移行は事前のテストで処理量を見積もっていたが、月末に行っている25万件が通常より多く、結果として全体の処理量が想定を上回ってしまった。
  • システム障害の責任については、みずほ銀行とグループが責任をもって対処するものと頭取が回答。
  • 通常体制でトラブルシュートが可能と判断したことが障害への対応が後手になった背景にある。マニュアル通りに対応しようとしたことが要因と記者会見で回答している。

金融庁が報告徴求命令

  • 金融庁は2021年3月3日にみずほフィナンシャルグループ、みずほ銀行に対し報告徴求命令を出した。
  • 障害発生日に銀行側と連絡が取れずに長時間待たされるなど多数の顧客に影響が及んだ事態を重く見たため。
  • 報告の期限日は2021年3月末。

トラフィック分析演習(2021年2月版) - あなたは#pcapとアラートのリストを取得します - あなたのタスクは、インシデントレポートを書くことです。 / Traffic Analysis Exercise - you get a #pcap and a list of alerts - Your task is to write an incident report(転載)


TRAFFIC ANALYSIS EXERCISE - ASCOLIMITED

ASSOCIATED FILES:

  • 2021-02-08-traffic-analysis-exercise.pcap   (11,145,351 bytes)
  • 2021-02-08-traffic-analysis-exercise-alerts.jpg   (2,237,669 bytes)
  • 2021-02-08-traffic-analysis-exercise-alerts.txt   (6,442 bytes)

NOTES:

  • All zip archives on this site are password-protected with the standard password.  If you don't know it, look at the "about" page of this website.

SCENARIO

LAN segment data:

  • LAN segment range:  10.2.8.0/24 (10.2.8.0 through 10.2.8.255)
  • Domain:  ascolimited.com
  • Domain controller:  10.2.8.2 - AscoLimited-DC
  • LAN segment gateway:  10.2.8.1
  • LAN segment broadcast address:  10.2.8.255

 

TASK

  • Write an incident report based on the pcap and the alerts.
  • The incident report should contains 3 sections:
  • Executive Summary: State in simple, direct terms what happened (when, who, what).
  • Details: Details of the victim (hostname, IP address, MAC address, Windows user account name).
  • Indicators of Compromise (IOCs): IP addresses, domains and URLs associated with the infection.  SHA256 hashes if any malware binaries can be extracted from the pcap.

     

    ANSWERS

    • Click here for the answers.

    悲報!タイ国際航空、エアバスA380型機を退役 / Sad: Thai Airways Retiring Airbus A380 Fleet(転載)


    Sad: Thai Airways Retiring Airbus A380 Fleet:

    タイ航空がコロナウイルスの流行でA380を退役させる最初の航空会社になるようです。

    タイ国際航空、エアバスA380型機6機すべてを退役させる

    タイ国際航空は現在リストラを進めており、その一環として数種類の航空機が退役することが明らかになりました。最も重要なのは、タイ国際航空が6機のエアバスA380を退役させることです。

    これにより、タイ国際航空はエールフランス航空、ルフトハンザ航空に次いで3社目のA380全機を退役させることになりました。さらに、エティハド航空とカタール航空のA380フリートの将来については、まだ審査対象外となっています。

    タイ国際航空はA380型機の戦略をあまり練ったことがありませんでした。

    • 航空会社のほとんどは威信のためにA380を購入したようで、それがタイ国際航空の長年にわたる多くの悪い決断の原動力になっているようです。
    • ロンドン、フランクフルト、東京などへのフラッグシップ路線にA380を使用していたが、ロードファクターや歩留まりに苦戦していた。
    • このような少ないA380の編成は、あまり効率的ではありませんでした。

    タイ国際航空はA380の引退に加えて、ボーイング747とエアバスA330のフリートを引退させる予定です。タイ国際航空が747の全機を売りに出したことから、タイ国際航空が747を引退することはすでに知っていました。A380の場合、タイ国際航空は以前に2機を売りに出していたので、タイ国際航空がこれらの飛行機のうち4機だけを保有することを示唆しています。

    Thai Airways’ 747 first class

    タイ国際航空のファーストクラス終了?

    この時点では、タイ航空がファーストクラスを廃止する可能性が高いと思われますが、それは確かに残念です。確かに航空会社はこの商品でお金を儲けたことはなく、むしろ威信をかけず、王族のための商品にしていたのです。

    近年、航空会社は747とA380のファーストクラスしか提供していませんでしたが、この2機が退役したことで、タイ国際航空のファーストクラスの将来性はあまり感じられません。

    興味深いことに、タイ国際航空は間もなく3機の新しいボーイング777-300ERを受け取ることになっている。しかし、この時点で航空会社がこれらの飛行機の引き渡しを受けるかどうかは疑問であり、それに関しては、航空会社がたった3機の飛行機のために別々のサービスを提供し続けるとは思えない。

    私はいつもタイ国際航空のファーストクラスでのフライトを楽しんできましたが、特にバンコクのタイ国際航空の素晴らしいファーストクラスラウンジは、世界でも最高のラウンジの一つだと思っていたので、寂しくなります。

    Thai Airways’ excellent first class lounge Bangkok

    ボトムライン

    タイ国際航空がエアバスA380の6機を退役させることになり、A380の全機を退役させる航空会社は3社目となります。その上に747とA330も退役することになりますが、それはすでにわかっていました。

    これで、歴史的にはA380と747に限定されていたことを考えると、タイもファーストクラスを廃止する可能性が高いと思われます。

    タイ国際航空が計画していたA380の引退をどう思いますか?

    お客様の個人情報流出に関するお詫びについて 株式会社 NTT データ数理システム(転載)~お詫びメールについて不審メールではないか確認依頼を受けたのだが。。。。~



    [PDF] お客様の個人情報流出に関するお詫びについて 株式会社 NTT データ数理システム 2021年2月26日 msi.co.jp/paper20210226.…: [PDF] お客様の個人情報流出に関するお詫びについて
    株式会社 NTT データ数理システム
    2021年2月26日
    msi.co.jp/paper20210226.…