【転載】サイバーな方のインテリジェンスをやっているorやろうとしてる人に読んでもらいたい記事のメモ


サイバーな方のインテリジェンスをやっているorやろうとしてる人に読んでもらいたい記事のメモ OPSEC for hackers <- これは実質聖書 slideshare.net/grugq/opsec-fo… Threat Intelligence: My opinion on what it is and isn't linkedin.com/pulse/threat-i…: サイバーな方のインテリジェンスをやっているorやろうとしてる人に読んでもらいたい記事のメモ

OPSEC for hackers <- これは実質聖書

slideshare.net/grugq/opsec-fo…

バックアップ

--

Threat Intelligence: My opinion on what it is and isn't

linkedin.com/pulse/threat-i…

（以下機械翻訳）

脅威インテリジェンスに関しては、多くの組織がそれを行っていると主張しています。この投稿では、脅威インテリジェンスとは何か、脅威インテリジェンスではないものについての私の意見を取り上げます。脅威インテリジェンスではないものから始めましょう：
  • ブランドの監視、または私がクラウド（他の誰かのコンピューター）でのインシデント対応と呼んでいるもの。これは、組織に類似した偽のドメイン、App Storeの偽のアプリ、Playストア、偽のソーシャルメディアプロファイルを探しています。脅威インテリジェンスチームがこれを任務に持っている場合（私の意見では、ブランド保護チームのような別のチームがこれを処理する必要があります）、真の脅威インテリジェンス機能になる時間がない可能性があります。
  • 侵害された資格情報またはクレジットカード。上記のように。
  • 自動ブロックと検出のために、インジケーターまたは侵入の痕跡（IOC）またはシグニチャを環境に取り込む。行うのは良いことですが、脅威インテリジェンスではありません。
それでは、「脅威インテリジェンス」という用語を見て、それを定義しましょう。脅威はマルウェアではありません。脅威はマルウェアを使用している人です。この人または潜在的にグループには、動機、目標、およびTTP（戦術、技術、および手順）があります。脅威インテリジェンスとは、人やグループを追跡/調査することです。

インテリジェンスの定義。インテリジェンスは長い間存在しており、インテリジェンスの収集またはスパイは売春に次いで2番目に古い職業であると言われています。インテリジェンスは、インテリジェンスサイクルと呼ばれるプロセスの出力です。このサイクルは次のとおりです。要件->収集->処理->分析->配布。その後、プロセスは要件段階で再開されます。このプロセスの出力（インテリジェンスの顧客または利害関係者に配布されるもの）はインテリジェンスであり、コンピューターではなく人によって行われます。

要件段階では、ここでインテリジェンスプログラムの優先順位が設定されます。その前に、インテリジェンスの顧客または利害関係者がインテリジェンスチームのメンバーであるかどうかを特定する必要があります。米国政府では、情報消費者の第1位は大統領府です。商用スペースには、CISO /エグゼクティブ（脅威インテリジェンスチームの第1の顧客である必要があります）、セキュリティオペレーションセンター（SOC）、インシデント対応、サードパーティのリスク、脆弱性管理（パッチの優先順位付けを可能にする）など、従来のインテリジェンスの顧客プロファイルが多数あります。 、レッドチーム、ハントと詐欺（銀行の場合）が他にもあります。これは、潜在的なインテリジェンスの顧客/利害関係者のタイプすべてではありませんが、最も一般的なタイプです。インテリジェンスの顧客を特定したら、次に、顧客と協力して、顧客のインテリジェンス要件/ニーズを理解し、優先順位を付ける必要があります。これは難しいプロセスです（ほとんどの人はインテリジェンス機能を使用する方法や優れたインテリジェンスの顧客になる方法を知りません）が、これの最終結果は組織の優先インテリジェンス要件またはPIRです。PIRの開発については、下部にあるリンクを参照してください。

PIRを文書化したら、利害関係者のインテリジェンスのニーズに答えるのに役立つもの/データを観察できる可能性のある場所を確認できます。典型的なソースは、内部テレメトリ（ネットワーク全体で起こっていること、以前のインシデントなど）、オープンソース（Pastebin、ソーシャルメディア、ニュース記事など）、クローズドソース（犯罪者の地下または「ディープアンドダークウェブ」ですが、情熱を持ってその用語は嫌いですが、犯罪者との直接的なオンラインエンゲージメント）、あなたのセクターの他の組織との共有（直接またはISACを介したものなど）など。これは、研究者またはインテリジェンスコレクターがインテリジェンスプロセス内に位置する場所です。

たくさんのコレクションを入手したら、なんとかして処理する必要があります。多くの組織（多くのソースがある）は、脅威インテリジェンスプラットフォーム（TIP）または分析プラットフォームを使用してこれを管理しています。

次に、インテリジェンスサイクルの分析部分があります。これは、人々が収集されたものと、それが何が起こったのか、推定確率のレベル（可能性が高い、可能性が高い、可能性があるなど）を付けて将来起こりそうなことの全体像を形成するのにどのように役立つかを見る場所です。100％事実に基づくものを調べるために分析チームは必要ありません。次に、アナリストはさまざまなタイプのインテリジェンス製品を作成し（オーディエンスに基づいてさまざまなタイプのインテリジェンス製品、つまりCISOはセキュリティオペレーションセンターとは異なるインテリジェンスニーズと配信形式を持ちます）、適切な利害関係者に配布します。その後、フィードバックが受信され、それに基づいて、インテリジェンスサイクルがいくつかの追加要件で再開される可能性があります。

これにより、典型的なサイバー脅威インテリジェンスチーム内で次のような役割が与えられます。
  • インテリジェンスリーダーまたはマネージャー。彼らはプロセスをエンドツーエンドで担当します。関係者と協力してインテルのニーズを理解し、フィードバックを受け取り、チーム/機能を管理するなど。

  • 技術研究者/アナリスト。通常、インテリジェンスサイクルの収集部分に含まれますが、分析部分にも含まれる場合があります。技術的な消費者（SOC、ハント、IRなど）向けに技術データを収集したり、技術に焦点を当てたインテル製品を作成したりします。通常、TIP、統合などの技術ツールの実行/構成にも関与します。

  • 従来の情報アナリスト。通常、インテリジェンスサイクルの分析部分に含まれます。通常、経営幹部向けのインテル製品の作成、戦略的インテルタイプの製品、戦術的でない聴衆へのプレゼンテーションなど、より伝統的なインテリジェンス分析タスクに関与します。伝統的に、政府、法執行機関、諜報機関などでの経験があります。
私たちが書いた他のブログ（Intel 471）は、もっと読みたい人のために書いています。
Labels: ,

【転載】闇サイトで不正操作プログラムを販売　容疑の男を逮捕



闇サイトで不正操作プログラムを販売　容疑の男を逮捕:

【ニュース】

◆闇サイトで不正操作プログラムを販売　容疑の男を逮捕 (朝日新聞, 2020/11/04 19:17)
https://www.asahi.com/articles/ASNC4663DNC4OIPE00K.html?iref=comtop_BreakingNews_list


【関連まとめ記事】

◆全体まとめ

◆闇サイト / ダークウェブ (まとめ)
https://malware-log.hatenablog.com/entry/Dark_Web

ーー

 パソコンに感染して遠隔操作するマルウェア（悪意あるプログラム）を、闇サイトで専用ソフトを使わないと閲覧できないネット空間「ダークウェブ」の掲示板サイトで購入者を募り、販売したとして、愛知県警は4日、自称フリーカメラマンの沢田海成容疑者（21）=千葉県白井市=を不正指令電磁的記録保管・提供などの疑いで逮捕し、発表した。容疑を認めているという。


　サイバー犯罪対策課によると、沢田容疑者は6月3日～8月13日、マルウェアの一つ「DarkComet（ダークコメット）」の圧縮ファイルを、自らが所有する外付けのハードディスクに保存したほか、6月3日にはこの圧縮ファイルの購入を希望した男性に販売した疑いがある。


　ダークコメットは、感染したパソコンを不正に操作し、データ閲覧や改ざん、外部への送信、カメラの起動などを行う。同課によると、沢田容疑者は何らかの方法でファイルを入手したとみられ、マルウェアを1ファイル3万円で販売するという趣旨を掲示板に書き込んでいたという。


　この書き込みを県警の捜査員が5月中旬に発見。沢田容疑者は、同じ掲示板に違法薬物や架空口座の販売をほのめかす書き込みもしていたといい、県警はマルウェア以外にも5～7月に少なくとも90万円を売り上げていたとみている。

Labels: ,

【転載】IPAが「ソフトウェア脆弱性関連情報管理シート」を公開。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。

EjUy10CVgAA7vfz.jpg:large
さとっぺ retweeted: 「ソフトウェア脆弱性関連情報管理シート」を公開しました。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。 ipa.go.jp/security/techn…:

さとっぺ retweeted:

「ソフトウェア脆弱性関連情報管理シート」を公開しました。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。

ipa.go.jp/security/techn…

EjUy10CVgAA7vfz.jpg:largeEjUy3fpU4AEfnoh.jpg:large



バックアップ

Labels: , ,

【転載】トランプ大統領のパスワード

 


トランプ大統領のパスワード

トランプ大統領は大統領選挙での劣勢が伝えられていますが、逆転に向けてこの脇の甘さが問題となるかも知れません。

jp.techcrunch.com

オランダのセキュリティ専門家が、トランプ大統領のTwitter（ツイッター）アカウント、@realDonaldTrumpのパスワードを推測してアクセスすることに成功したという。パスワードは「maga2020!」だった（パスワードはすでに変更されている）。

GDI Foundationのセキュリティ研究者でセキュリティ脆弱性を見つけて報告するDutch Institute for Vulnerability Disclosure（オランダ脆弱性公表機関）の代表を務めるVictor Gevers（ビクター・ゲバーズ）氏はTechCrunchに、大統領のアカウントパスワードを推測し、5回目の試みで成功したと語った。

アカウントは2段階認証で保護されていなかったため、ゲバーズ氏のアクセスを許してしまった。

（Tech Crunch記事より引用）

 

 

キタきつねの所感

ホワイトハッカーによる疑似ハッキングは、ホワイトハウスの副報道官は「まったく真実でない」と否定していますが、大統領のSNSセキュリティのコメントを拒否した様ですので、疑似ハッキングは成功してしまったのかと思います。

とは言え、大統領選の終盤のこの時期にこうした「ニュース」をぶつけてくる事に、何かの”意図”を感じなくもありません。

 

それはさておき、仮にこの件が本当だったとして、ホワイトハッカーに突破されたパスワードは、何故5回の試行で破られてしまったのでしょうか？少し真面目に漏えいしたとされる、パスワード強度を考えてみます。

 

「maga2020!」

 

パスワードの構成上は、英小文字、数字、記号が使われており、パスワード長は9文字とまずまずの長さです。しかし、”2020”と”！”はパスワード保有者にとってユニーク（特有なもの）とは言えません。

”2020”は誰でも「今年」の事を指す事は分かると思いますので、パスワード桁数を増やす事には貢献しても、構成要素とては弱いかと思います。記号の”！”もユニークではありませんので、このパスワードの肝となるのは、【maga】となる事は明らかです。

 

この単語・・・どこかで見覚えがあるなと思った貴方！正解です。

 

『Make America Great Again』の頭文字以外の何物でもありません。

 

そりゃ・・・パスワード破られても不思議ではないですね。

 

（ホワイト）ハッカーは、攻撃をする際に、対象者（トランプ大統領）のSNS等から情報を拾い、例えば誕生日であるとか、ペットの犬の名前であるとか、今回の様に『選挙キャンペーンフレーズ』をパスワード候補として攻撃してきます。

 

今回の【maga】は、「容易に推測できるパスワード」（の一部）だったと言えるのです。

 

とは言え、このパスワード（mage2020!)、強度がすごく弱いという訳ではありません。仮に、大統領選の対立候補であるバイデン氏が使っていたとしたら、ホワイトハッカーは恐らく破れなかったと思います。

 

参考まで、パスワードチェッカーとして有名な「How Secure Is My Password?」では、16時間で解読されるとの評価です。

f:id:foxcafelate:20201024062301p:plain


同じく、パスワードチェッカーとして評価が高い「Kaspersky Password Checker」では、28日の評価結果です。

f:id:foxcafelate:20201024062504p:plain

 

もう１つ。過去の漏えい事件で流出したパスワードかどうか分かる「Pwned Passwords」では、驚くべき事に『流出したという事実が無い』と評価されました。

f:id:foxcafelate:20201024062358p:plain

 

 

私でしたらどうやってトランプ大統領のパスワードをベースを変えずに強化するか、と考えると・・・

 

単純な手法としては、記号を増やします。(最初に入れると見破られそうですが）これだけでも意外とホワイトハッカーの攻撃は凌げたと思います。

　例）『maga20!20!』『ma#ga2020!』

 

記号を２つ使うと（その記号を置く位置も併せて）試行すべき組み合わせが膨大に増えますので、ハッカー側は結構大変かと思います。単語（magaや2020）の間に挟むとより複雑性が増しますのでオススメです。

 

もう１つの手法として、（私のオリジナルという訳ではありませんが）、他の要素と関係性の無い単語を増やします。

　例）『mage2020!JAPAN』『mage2020!yankees』

 

日本やニューヨークヤンキース（出来ればファンでない所が望ましい）といった、選挙やトランプ大統領とあまり関係が無く、SNS上でも出てこない単語（※ここが重要です）が１つ入っただけで、例えツール攻撃したとしても、ハッカーがパスワード解読にかかる時間は膨大なものとなるかと思います。 

トランプ大統領アカウントのハッキング、事実だとすれば、非常に重要なTwitterアカウントであるが故に（下手な事をつぶやくと国際問題や世界の株価に大きく影響する）、大統領や大統領陣営はもっとSNSのセキュリティにも気を遣うべきだったかと思います。もし何でしたら酒席セキュリティ担当として雇って下さい。

とは言え、パスワード強化よりも先に『2要素認証』を設定すべきだとは思いますが。

 

※どこがオリジナルか分からないのですが、複数の関係ない単語を使った強力なパスワード作成手法について、英語圏で広く出回っている説明イラストを参考まで貼っておきます。

XKCDマウスオーバー：情報理論とセキュリティを理解していて、そうでない人（おそらく混合ケースを含む）と腹立たしい議論をしている人には、心からお詫び申し上げます。

 

 

余談です。日本だとオランダのセキュリティ専門家（ホワイトハッカー）の『疑似ハッキング』行為は、不正アクセス禁止法（3年以下の懲役または100万円以下の罰金）に引っかかります。

その事自体は当然の事とは思いますが、私は認められたホワイトハッカー企業や個人に、制約付きで同様な脆弱性調査を認めるべきでないかと思います。

Labels:

【転載】コインチェックのインシデント対応レポート～AWSのイメージが良くなり、ドメインレジストラのイメージ悪化～


ある日突然、自社ドメインが乗っ取られた――“原因も手口も不明”の攻撃に、セキュリティチームはどう立ち向かったか - ITmedia エンタープライズ: 

　2020年6月、仮想通貨取引所「Coincheck」を運営するコインチェックのコーポレートサイトに、あるセキュリティインシデントの報告書が掲載された。当時、重要な事例として筆者のセキュリティ連載「半径300メートルのIT」でも取り上げたことから、記憶に残っている読者もいるのではないだろうか。


　インシデントのあらましを簡単に説明しよう。これは、コインチェックが利用する外部のドメイン登録サービスにおいて、コインチェックのネームサーバ（DNS）情報が、何者かに書き換えられたものだ。これにより、同社のドメインのレコードが偽のDNSに登録され、同社にメールで問い合わせた顧客のメールアドレスと本文が第三者に流出する可能性があった。コインチェックはインシデント発生後、対応についてのレポートを公開するとともに、利用するドメイン登録サービスを変更したと発表した。


　このインシデントは、一般に「不正アクセス」という言葉から連想する事件とは異なり、一見地味な印象を受けてもおかしくないものだ。しかし、報告書には、セキュリティ担当者ならば誰でも青ざめるような展開が赤裸々につづられていた。

コインチェックによるインシデントの第1報（出典：コインチェック）

　ITmedia エンタープライズ編集部は、実際に同社でインシデント対応に当たった喜屋武 慶大氏（サイバーセキュリティ推進部長）に講演を依頼。2020年9月に開催したオンラインイベント「ITmedia Security Week 秋 - ITmedia エンタープライズ」の特別講演として、当時の様子を当事者の目線で振りかえってもらった。その内容は、セキュリティ担当者だけでなく組織でITに関わる人ならば誰もが非常に参考になるものだった。本稿は喜屋武氏の講演の内容をレポートする（注）。

注：本稿はITmedia エンタープライズ主催「ITmedia Security Week 秋」の講演「ドメインが乗っ取られた！！そのとき我々はどう対応したか」を基に再構成した。

　読者の皆さんには「自分がもしもセキュリティ担当者なら、気付くことができただろうか」と問いかけながら、目を通していただきたい。

2020年6月1日正午ごろ：「何かがおかしい」という報告から全てが始まった

　その日（インシデント発生当日）、最初に違和感に気付いたのは、社内のSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）チームだった。

「ITmedia Security Week 秋 - ITmedia エンタープライズ」に登壇し、インシデント対応の様子を語ったコインチェックの喜屋武 慶大氏（サイバーセキュリティ推進部長）

　2020年6月1日正午ごろ、コインチェックで通常の監視業務に当たっていたSREチームは、普段と異なる状況を察知した。前日に比べて自社サービスに対するリクエスト数が異常に少なかったのだ。

　「『何かがおかしい。怖い』という報告が、SREチームから社内で使う『Slack』のワークスペースに上がってきた。それが発端だった」（喜屋武氏）

　SREチームはまず、リクエスト数の激減以外にも何か異常がないかどうかをチェックした。すると、前日の5月31日を境にサービスのレスポンスタイムが遅延していることが分かった。「この時点では誰もDNSの書き換えという結論は想像していなかった」と喜屋武氏は振り返る。

　「Slackでのやりとりをはた目で見ながら『何か障害でも起きたのだろう、あとで共有してもらえばいい』と思っていた」（喜屋武氏）
リクエスト数が減少し、レスポンスタイムが遅延していたことが、インシデント検知につながった（出典：コインチェック）

　この違和感をきっかけに、SREチームは本格的な調査に乗り出した。しかし原因はなかなか見つからない。アプリケーションには異常がなく、サーバもロードバランサーも問題がないように見える。ただし、喜屋武氏によれば、ユーザーの感覚としては普段と変わらないように見えても、モニタリングダッシュボードに示されるレスポンスタイムはどんどん遅延していったという。リクエスト数は減っているにもかかわらずだ。

6月1日午後：レスポンス遅延が悪化　「障害ではなく、攻撃だ」と気付いたきっかけ

　6月1日の午後になると、レスポンス遅延はさらに進み、体感で分かるレベルになってしまった。また、全ての社員ではなく、特定のメンバーに限ってレスポンス遅延が発生していることも分かってきたという。

　原因を突き止めようと、SREチームは、遅延が確認できた環境から経路を確認するtracerouteコマンドを実行した。すると、通常ならば数ホップで同社が利用する国内のAmazon Web Services（AWS）まで到達するはずのリクエストが、なぜかアムステルダム（オランダ）のリージョンにあるAWSのCDN（Content Delivery Network）サービス「Amazon CloudFront」を経由していた。

　これこそがレスポンスの遅延の原因と思われたが、そもそもなぜリクエストがオランダを経由するのかが分からない――。不審に思った喜屋武氏は、AWSのサポートに連絡を取った。コインチェックがインシデント対応に奔走する“長い夜”は、この時点で既に始まっていた。

　喜屋武氏が「権威DNSに何か問題があるのでは」とAWSのサポートに確認したところ、返ってきた答えは「これはAWSのDNSではない」だった。同氏はその際の反応について「『えっ！』と驚くしかなかった」と話す。このやりとりをきっかけに、AWSのCDN（Content Delivery Network）サービス「ns-1515.awsdns-61.org」に0を足して「ns-1515.awsdns-061.org」にすり替える、一見しただけでは気付かないような手口だった。

whois情報を見るとDNSの指定が書き換わっていた（出典：コインチェック）

　この時点からインシデントが一段落するまで、SREチームはAWSのサポートとのやりとりを重ねることになった。

　「（違和感に気付いた当初は）ひょっとしたらAWSの障害が原因ではないかと思って問い合わせたことをきっかけに、結果として別の原因が判明した。しかし、その後もAWSのサポートは（インシデント対応に）付き合ってくれた。こういうときに素早く反応してもらえたので、サポート契約していて良かったと感じている」（喜屋武氏）

2020年6月1日夕方：レジストラが乗っ取られていたことが判明

　6月1日夕方ごろ、本格的なインシデント対応が始まった。まずは、システム担当の執行役員に対して、これまでのいきさつを報告した。また、状況報告に使うコミュニケーションツールをSlackからWeb会議サービス「Zoom」に切り替えた。「Zoomが詰め所のような形になり、そこに参加する形で執行役員に指揮を執ってもらった」と、喜屋武氏は語る。

　状況を報告されたシステム担当の執行役員は、想定しない報告に当初「えっ！」と驚くのみだった。後日、役員は喜屋武氏に「重めのシステム障害を想定していたため（サイバー攻撃を受けたと報告が来た際は）何を言われているのかさっぱり分からなかった」と明かした。

　DNSが改ざんされたと分かった以上、初動対応として、コインチェック側はレジストラにログインし、DNSを元に戻そうとした。しかし、IDとパスワードを使ってもログインできない。パスワードをリセットしようとすると、今度はリセットのためのメールがコインチェックに届かない――。つまり、この時点で、レジストラのIDは完全に乗っ取られてしまっていた。

　喜屋武氏がドメイン名を検索して状況を確認すると、日本時間で5月31日の深夜にDNSレコードがアップデートされていた。もちろん、コインチェック社内でその時間に当該の操作をした者はいなかった。5月31日深夜を境にレジストラの登録情報が乗っ取られ「coincheck.com」が奪われてしまった。コインチェックがこの事実を把握したのは、6月1日の19時過ぎだった。

調査の過程で見覚えのないMXレコードが見つかったことで、レジストラが乗っ取られていたことが判明した（出典：コインチェック）

　タイミングの悪いことに、新型コロナウイルス感染症（COVID-19）の影響でレジストラの電話サポートなどが縮小されていた。コインチェックはレジストラにメールで対応を依頼したが、その時点でレジストラの営業時間外だったため、最悪対応が翌日になってしまうことも考えられた。このタイミングで、コインチェックは社外のセキュリティアドバイザー2人にも状況を報告し、インシデント対応に参加してもらうことになった。

2020年6月1日夜：なぜ、どうやって攻撃された？　長い捜索が始まる

　DNSが不正に書き換えられてしまった場合、それを元に戻せるのはレジストラだけだ。レジストラの対応を待つ間、コインチェックは、今回のインシデントの根本原因を探る調査を開始した。

　この時、真っ先に疑われたのはマルウェア感染による不正アクセスだった。しかし、喜屋武氏がログを確認したところ、社内の端末にマルウェア感染は確認できなかった。不審なアクティビティーがないかどうか、未知のマルウェア攻撃がある前提で調査を継続したが、エンドポイントからのアラートも上がっていない。操作ログや通信ログ、プロセスログにも、それらしい痕跡はなかった。喜屋武氏は「マルウェア攻撃が原因である可能性は低い」と判断し、次の調査に移ることにした。

　マルウェア以外に、アカウント乗っ取りやパスワードクラック、セッションハイジャックなどが原因になっている可能性もあった。このうち、アカウント乗っ取りが発生していれば、他のサービスを攻撃されている可能性も高い。しかし、シングルサインオン（SSO）ログやSaaSのログイン履歴に不審な点はなかった。セッションハイジャックの可能性も低かった。レジストラに最後にログインした日時がかなり前であり、5月31日時点では有効ではないことが確認できたためだ。

　「パスワードに関しては、サービスで設定できる最長の文字数を、パスワードジェネレーターで生成している。それなりの強さであり、総当たりでパスワードクラックを行うことは不可能。使い回しもしていない」（喜屋武氏）

　残された可能性は、レジストラの脆弱（ぜいじゃく）性だった。調査に参加したセキュリティアドバイザーからは「海外でもレジストラの脆弱性をきっかけとした攻撃が発生している」というコメントを得ていた。この時点では可能性の一つでしかなかったが「結果的には、レジストラの脆弱性が原因だった」と、喜屋武氏は話す。

　「もしレジストラの脆弱性が原因だったなら、（他の事業者も対象にした）攻撃キャンペーンがあるはずだと考えたが、当社以外に攻撃されているという情報がなかった。念のためレジストラにログインした端末は隔離し、他のサービスにもサインオンできないようにした」（喜屋武氏）

　調査が進む中、2020年6月1日20時52分ごろ、レジストラから「DNSの情報を元に戻した」という連絡が来た。この時点で、コインチェックではシステム担当執行役員から社長にインシデント発生の報告を上げていた。同社は社内で制定済みの対応フローに従い、緊急事態対策本部を設置した。

2020年6月1日深夜：ドメインがついに回復　判明した衝撃の手口とは

　DNSは元に戻ったものの、この時点では、インシデントが社内やユーザーを含めてどの程度の範囲に影響を与えたのか、明確に見えていなかった。影響範囲の確認を兼ねて調査を続けていると、DNSに不審なMXレコードが設定されていることが判明した。攻撃者は、コインチェックのメール情報を盗もうとしていたのだ。

　「不正に設定されたIPアドレスを確認すると、coincheck.comを返すメールサーバが動いていた。しかし、SPFレコードの設定が書き換えられていなかったため、coincheck.comを送信元とするメールを送信することが狙いではなさそうだった」（喜屋武氏）

　この動きを確認した時点で、時刻は6月2日の深夜1時を過ぎようとしていた。DNSは無事に取り戻せたが、インシデントを引き起こした攻撃の詳細や原因はまだ分かっていなかった。この状況では、攻撃者が再びDNSを改ざんできてしまう可能性もある。喜屋武氏は自分とSREチームの1人を残して他のメンバーを解散させ、2人体制の監視に入った。そして、全社員のメールボックスをくまなくチェックし始めた。

　すると、重大な事実が見えてきた。複数の社員のメールボックスの中に「GitHub」をはじめとする複数のサービスからパスワードリセットのメールが大量に届いていたのだ。該当の社員にヒアリングしたところ、彼らは一様に「パスワードをリセットするような操作はしていない」と答えた。実際に、喜屋武氏は社員の操作履歴を精査し、成功したパスワードリセットのリクエストがなかったことを確認した。

　ここまでの状況から、初めて攻撃の全体像が見えてくる。

　「レジストラの情報を書き換えることで、攻撃者が用意したサーバに問い合わせさせ、偽のレコードを引いてくる。これにより、攻撃者がcoincheck.comに届くメールを不正に取得した」（喜屋武氏）

　攻撃者はDNSを直接攻撃せずに、レジストラを攻撃することでDNSを乗っ取ったのだ。

判明した攻撃の全体像（出典：コインチェック）

2020年6月2日：プレスリリース第一報を公開、そして……

　翌日の6月2日、コインチェックは、朝、昼、夕方の定期Webミーティングを設定した。Web会議には指揮官であるシステム担当の執行役員に常にオンライン状態でいてもらい、進捗（しんちょく）を報告した。Web会議を対策本部にするスタイルはあくまでもCOVID-19対策だったが、これが意外な効果を生んだ。

　「リアルな会議室でホワイトボードを前にするようなこれまでの会議スタイルとは異なり、Web会議なら作業をしながらでも報告ができる。そこに入れば誰かがいて、助言をもらえる。振りかえると、この体制はとてもやりやすく、メンバーのから評判も良かった」（喜屋武氏）

　ユーザーのサポート窓口となるメールアドレスで利用しているドメインは、すでに攻撃の対象となっていた。ユーザーへの悪影響を防ぐため、コインチェックは新たに「coincheck.jp」のメールアドレスを設定し、動作を確認した上で、インシデントについて記したプレスリリースを公開した。その後の展開は、ITmedia エンタープライズやその他の報道で皆さんもご存じのことだろう。

被害を増やさないために――担当者が語る予防策

　喜屋武氏は今回のインシデントを振り返り「本物に酷似したドメイン名をDNSに設定されてしまう攻撃例は、知る限り世界初ではないか」と話す。この攻撃の恐ろしい点は、いったんドメインを乗っ取られ、MXレコードを書き換えられてしまうと、自分が正規のユーザーであることを証明する手段がほとんどなくなってしまうところだ。このような手口は、社内で使うサービスのパスワードがメールを使ってリセットされる設計の弱みを突いたようにも見える。

　視聴者に向けたメッセージとして、喜屋武氏は「（今回のインシデントからは）ドメイン乗っ取りの被害が甚大であることを確認できた。DNSはとても大事なサービスだ。このインシデントを参考にし、レジストラに登録したDNSの設定はしっかり監視してほしい。また、権威DNSに使っている関連サービスのアカウント管理情報やレコードは定期的にチェックしてほしい」と話し、講演を締めくくった。


Labels: ,

サイバー保険でインシデント対応の費用が賄えるのか？

記事を読んでいたら、相反する2つトピックを見つけた。

1つ目が、サイバー保険を付帯した標的型攻撃メール訓練のニュースで、インシデント費用を最大600万円補償するというもの。

2つ目は、インシデント発生時における対応費用の実態が約1.5億円となっているというもの。

1件目のサイバー保険を付帯した標的型攻撃メール訓練で、インシデント対応費用が最大600万円で全然足りないのは何となく理解できる。

グリコのおまけ的な扱いであることを認識していれるか、とりあえず「サイバー保険導入」の事実を成立させたい組織には向いているが、リスクファイナンスを真剣に考えるとあり得ない選択だと思う。

■記事1

サイバー保険を付帯した標的型攻撃メール訓練をOEM供給:

ラックは、パートナー向けにサイバー保険を付帯したトレーニングサービス「サイバー保険付き標的型攻撃メール訓練 プレミアム」を提供開始した。

同製品は、疑似的な標的型攻撃メールを従業員へ送付する体験学習型の訓練プログラム「ITセキュリティ予防接種」にサイバー保険を付帯したもの。

同社の販売パートナーチャネル向けにOEM供給し、パートナーは自社製品やサービスに組み込んだり、オリジナルサービスとして販売することができる。

損害保険ジャパンを引き受け保険会社とするサイバー保険を付帯。訓練を実施した企業において、サイバー攻撃に関する調査費用をはじめ、復旧や再構築費用、損害賠償金について最大600万円まで補償する。

■記事2

約4割でインシデント被害、対応費用は約1.5億円 - 4.4％が「Emotet」経験:


国内法人における約4割のセキュリティ担当者が、セキュリティインシデントに起因する被害を経験したとする調査結果をトレンドマイクロが取りまとめた。被害への対応や改善策の導入などで約1億4800万円の費用が生じていたという。


同社が6月に国内法人においてインシデント状況を把握しているリスク管理、ITシステム、情報セキュリティなどの担当者1086人を対象にインターネット調査を実施し、結果を取りまとめたもの。所属組織の内訳を見ると民間企業が980人、官公庁自治体が106人となっている。


2019年4月から2020年3月の1年間に被害の有無に関係なく、何かしらのインシデントを経験した回答者は78.5％だった。インシデントの内容を見ると、「フィッシングメールの受信」が42.8％でもっとも多い。


ついで「ビジネスメール詐欺のメール受信」が29.1％と多く、「不正サイトへのアクセス（26.5％）」「標的型攻撃（22.2％）」「ランサムウェア感染（17.7％）」と続いた。

約1割で「DDoS攻撃」「内部不正」が発生していたほか、「システムの脆弱性の悪用（11.4％）」や「システムの設定ミスの悪用（7.6％）」などシステムの問題を突く攻撃なども見られる。さらに4.4％は、マルウェア「Emotet」を経験していた。一方、21.5％はインシデントが発生していないと回答している。


Labels:

【転載】イミュータブルインフラストラクチャとは？


イミュータブルインフラストラクチャってご存じだろうか？

【解説】

「イミュータブル」とは「変更不可能な」という意味で、言い換えると「一度作成したら、その状態を変えることができない」と表現することもできます。反対語は「ミュータブル (変更可能な)」となります。

現実世界の例を出してみましょう。例えば「重要な書類を書く場面」を想像してみるのはいかがでしょうか ? ボールペンで書類を書くことを「イミュータブル (変更不可能な)」だとすると、鉛筆で書類を書くことを「ミュータブル (変更可能な)」と考えることができます。

 【メリット】

1. 書類を書き換えられなくなる

ボールペンで書類を書くことにより、書類を書き換えられなくなるというメリットがあります。重要な書類のほとんどはボールペンで書くことにより、書いた内容を保証しています。これは「一度書いた書類の状態を変えることができない」と言い換えることもできます。提出した重要な書類を勝手に書き換えられてしまったら困ります。

2. 書類が汚れない

例えば、住所を書き間違えてしまうこともあります。そのときに鉛筆で書類を書いていれば、繰り返し書き換えられるため便利に感じるかもしれません。しかし、実際には消しゴムを使って消すことになります。消そうと思っても「キレイに消えなかったり」、消えるには消えたけど「消しカスが大量に出てしまったり」、繰り返し書き換えることにより、書類が汚れてしまいます。書き換えによって書類が汚れないという点もメリットの 1 つと言えます。

【まとめ】

本記事では、重要な書類を書く場面を比喩に「イミュータブル」を紹介しました。実際のワークロードでは、例えば Amazon EC2 インスタンスを「イミュータブル」に運用し、修正をする場合には新しくインスタンスを作り直せる仕組み作りが重要です。

【所感】

イミューダブルインストラクチャとは、インフラ（OS、ミドルウェア）へのパッチ適用は一切行わず、脆弱性が見つかったら、脆弱性対策が行われた最新版のインスタンスに移ることで脆弱性対策を行うということである。

つぎはぎでパッチ適用を行う事が将来的なシステムの安定化に危害を及ぼすという考え方で、IaaSならではの発想である。

実際はOSやミドルのバージョンが変わっちゃうとその上のアプリも影響を受けてしまうため、運用工数といった観点では地道にパッチ適用するのと変わらない気がする。

ただ、脆弱性対策の観点でこのようなアプローチがあるというのはとても勉強になった。

【参考】

https://aws.amazon.com/jp/builders-flash/202005/metaphor-immutable/

Labels: ,

【転載】IT技術用語における「疎結合」とは？


 【例文】

アプリケーションを「疎結合」にする

マイクロサービスは「疎結合」な特性を持っている

【解説】

「疎結合」とは「結合度を緩める」という意味で、言い換えると「独立性を高める」と表現することもできます。反対語は「密結合」となります。

現実世界の例を出してみましょう。例えば「年賀状など、手紙を送る場面」を想像してみるのはいかがでしょうか ? 手紙を郵便ポストに投函することを「疎結合」だとすると、郵便局で配達員に直接手渡しすることを「密結合」と考えることができます。

【メリット】

では、現実世界の例をさらに深堀り、メリットを考えましょう。

1. 郵便局の営業時間を気にせずに手紙を送れる

郵便ポストに投函することにより，郵便局の営業時間を気にせずに手紙を送れるというメリットがあります (24 時間営業ではないという前提とします)。郵便ポストさえあれば、好きなときに投函できますよね ! これは「手紙を送ること」と「配達をすること」の「結合度を緩めている」と考えることもできます。

2. たくさんの手紙を投函できる

年賀状の時期など、たくさんの手紙を送る場面もあるでしょう。もし郵便局で配達員に直接手渡しをしてしまうと、もしかしたら配達員の手が回らなくなってしまう可能性もあります。さらに受付に順番待ちができてしまうかもしれません。郵便ポストさえあれば、たくさんの手紙も投函しておくことができます。これも「結合度を緩めている」からこそ得られるメリットと考えることができます。

3. 定期的に回収できる

配達員の視点で考えると、手紙を直接手渡しで受け取るよりも、好きなタイミングに郵便ポストから回収できた方が柔軟です。「結合度を緩めている」からこそ、配達員の「独立性を高められている」と考えることができます。

【まとめ】

実際のワークロードでは「レポート生成処理」や「画像変換処理」において「疎結合」を意識すると良いでしょう。AWS では、例えば Amazon SQS を活用した「疎結合アーキテクチャ」を構築することができます。アプリケーション A と アプリケーション B の「結合度を緩める」というイメージです。

【所感】

所謂3層構造と言われる、Web、アプリ、DBサーバをそれぞれ分離して構築することも「疎結合」の範疇に入る。

セキュリティ的な要素のイメージが強いが、システムの安定稼働（障害発生時の影響範囲を限定する）の観点でも意味のあるポイントと言える。

【参考】

https://aws.amazon.com/jp/builders-flash/202003/metaphor-loose-coupling/

Labels: ,
登録: 投稿 (Atom)