【転載】OSINT 2019 Guide

OSINT 2019 Guide

注意事項

本資料は、セキュリティ専門家のTek氏に許可をもらい、ブログ記事『2019 OSINT Guide』を翻訳したものです（Thanks, Tek）。
内容については、最大限の努力を持って正確に期していますが、本書の内容に基づく運用結果については責任を負いかねますので、ご了承ください。
他の翻訳は、『Scientia Securtity on GitHub』を参照してください。
ブログは『セキュリティコンサルタントの日誌から』を参照してください。

概要

最近多数のOSINTプロジェクト（Open Source Intelligence）を実施しています。2019年新年のお祝いとして、私が学んだ多くのテクニックを紹介します。もちろん、これは完璧なガイドではありませんが（そして、どんなガイドも完璧にはなり得ないでしょう）、この資料が初心者にとってOSINTを学ぶ助けになり、経験豊富なOSINTハッカーが新しいテクニックを学ぶ助けになることを願っています。

方法論

伝統的なOSINT方法論を端的にいえば、以下のように言えるでしょう。

要求定義（何を探しているのか？）
データ収集
収集した情報の分析
ピボットと報告（収集した情報をもとにピボットを行い、更なる要求定義を行うか、調査を終了し報告書を書くか、決定します。）

この方法論はすこし直観的であり、あまり助けにならないかもしれません。しかし、私はそれでも定期的にこのフレームワークに戻ることが重要だと考えています。そして、このプロセスを反復できるように時間を取ることをお勧めします。調査中、収集されたデータ量がわからなくなり、調査の方向性を把握することが難しくなります。この場合、少し休憩を取り、Step 3とStep 4に戻ることを推奨します。つまり、分析を行い、何を発見できたか整理し、ピボットしたり、答えを引き続き探すべき新しい質問（あるいはより具体的な質問）を定義する手助けをなることを列挙します。

他にできるアドバイス：

決してあきらめないこと。 情報を得るためにあらゆる可能性を試し、やりつくしたと感じる瞬間が来るでしょう。でもあきらめないでください。すこし休憩を取りましょう（１時間、あるいは１日別のことをしても良いかもしれません）。そして持っているデータを改めて分析をやり直し、別の視点から再度捉えなおしてみまてください。ピボットできる新しい情報があったでしょうか？もしかしたら、そもそも立てた調査用の質問が間違っていた可能性はないでしょうか？Justin Seitz氏が最近粘り強さに関するブログ記事を投稿し、様々な事例を紹介しています。
証拠を保存すること。 オンラインにある情報はすぐに消失します。一回のOpSecのミス、例えばTweetに「Like」ボタンを押してしまったとしましょう。調査対象者が疑い始めたら、突然全てのソーシャルメディアアカウントとWebサイトが削除されてしまう可能性があります。そのため、証拠は保存しておく必要があります。スクリーンショット、アーカイブ、Webアーカイブ（より詳細には後で議論します）、あるいは自分にあった方法でも構いません。
タイムラインは役に立つ。 フォレンジック調査では、タイムラインとイベント発生時のピボットが同じタイミングであることが重要です。OSINTにおいて、タイムラインはそこまで重要ではありません。しかし、データを体系化する上でタイムラインは重要なツールとなります。いつWebサイトが作成されたのでしょうか？いつFBアカウントが作成されたのでしょうか？最後にブログが投稿されたのはいつでしょうか？こうした情報を一度テーブルに並べることで、自分が探していることについて良い視点が得られるでしょう。

そして、私が有益だと思う二つのメソッドがあります。最初の方法はフローチャートです。これは、データの種類（例えば、e-mail）に基づきより多くの情報を探し出すためのワークフローを表現した図です。私が見た中で最も良い図は、IntelTechniques.comを運営しているMichael Bazzell氏が提唱している図です。例えば、E-mailアドレス情報を調査する場合、Michael Bazzell氏のワークフローを以下に示します。

Michael Bazzell氏によるメールアドレスに対するOSINTワークフロー

これ以降、私は自分独自の調査ワークフローを構築し、時間をかけて少しづつ自分が見つけたテクニックを付け加えて改善していくのがよい考えだと思うようになりました。

私が推奨するもう一つの方法は、特に長期間の調査に有効で、ACH（Analysis of Competing Hypotheses）という方法です。この方法論は、CIAにより1970年代に開発された方法で、アナリストが分析時にバイアスに影響されないようにし、異なる仮説を注意深く評価することを助けてくれます。これは非常に時間を必要するツールであるため粘り強く使う必要があります。しかしもし１年間の長い調査中に調査指針を失った場合は、注意深く仮説を評価することを支援する上でよいプロセスになるのでしょう。

自分のシステムを準備する

調査に入る前に、調査対象の人たちに警戒されないようにOpSecの観点から考えるべきことがあります。目立たない個人のWebサイトへアクセスすればIPアドレスを露呈することになり、自身の場所や所属をさらすことになります。ほかにも、個人のソーシャルメディアアカウントを利用し、間違って「Like」ボタンを押してしまう可能性も考えられるでしょう。

そのため、自分が調査する時は以下のルールに従うようにしています。

調査用ブラウザからの全てのアクセスは、商用のVPNやTORを利用することです。 多くの商用VPNは、異なる国でサーバを提供しており、Torは出口ノードとして特定の国を選択することができます。そのため、国を選択することで、不用意なコンテキストとその痕跡を残さずに済みます（USの組織から、USのために調査を実施しているなど）
スキャンやクローリングのタスクは、自分との関係性がない安いVPSから行う必要があります。
調査専用のソーシャルメディアアカウントを利用し、偽名で作成します。

こうした試みをすることで、臨んだ通り自分の姿を隠しながら調査をすることができ、調査対処から特定される可能性もほとんどありません。

ツール

情報セキュリティの世界において、ツールは常にみんなの興味を引く話題でしょう。但し、持っているスキルではなく、数えきれないほどのツールのリストをレジュメ（CV）に列挙している人々を除いてですが。では、はっきり言ってしまいましょう。 ツールは基本的に問題ではありません。ツールを使って何をするかが問題となります。 もし、何をしているか理解できていなければ、ツールは訳に立たないでしょう。理解できない、あるいは評価できないデータの長いリストが並ぶだけです。ツールをテストして、コードを読み、自分自身のツールを作る必要がありますが、自分のやろうとしていることを確実に理解する必要があります。

完璧なツールキットが存在しないのは当然です。最も良いツールキットは、自分が知っており、利用しやすく完璧に使いこなすことができるツールです。しかし、私が使っているツール、あるいは読者が興味をもつであろう他のツールを紹介したいと思います。

Chromeとプラグイン

私は調査用ブラウザとして、Chromeを使います。なぜなら、HunchlyというツールがChromeでしか使えないためです。ここでは、さらに有益なプラグインを紹介しておきましょう。

archive.is Button は、archive.isに素早くWebページを保存することができます（詳細は後に記載）
Wayback Machineは、archive.orgの中にあるアーカイブされたページを検索します。
OpenSource Intelligenceは、多くのOSINTツールへの素早くアクセスできます。
EXIF Viewerは、イメージ内のEXIFデータを素早くみることができます。
FireShotは、スクリーンショットを素早くとることができます。

Hunchly

私は最近、Hunchlyを使い始めましたが、非常に良いツールです。HunchlyはChromeのエクステンションであり、調査中に見つけた全てのWebデータをセーブ、タグづけ、検索することができます。基本的には、調査を開始するときにエクステンションにある「キャプチャ」のボタンをクリックするだけです。Hunchlyは、アクセスしたページ全てをデータベースに保存し、後でタグやノートを追加できるようにしてくれます。

これは、年間130USDかかりますが、このツールがもたらす利便性に比べればそこまで高いとは言えないでしょう。

Hunchlyダッシュボードのスクリーンショット

Maltego

Maltegoは、OSINTツールというより脅威インテリジェンスツールと呼ぶべきでしょう。しかしグラフは、調査データを分析し、表現するうえで最も良い方法になります。基本的に、Maltegoはグラフを表現し、グラフ内に新しいデータを見つけるために変換するためのGUIを提供してくれます（例えば、Passive DNSデータベースからドメインに紐づくIPアドレスなどを表示してくれます）。少し高額ですが、脅威インテリジェンスや攻撃基盤分析などをやっていればその価値はあるでしょう。（初年度999ドル。そして、ライセンス更新ごとに年499ドルです）。ほかにも、Maltego Community Editionを使うこともできます。これは、データの変換やグラフのサイズなどに制約がありますが、小さい調査であれば十分すぎるほどの機能を提供してくれます。

Maltegoのスクリーンショット(情報源: Paterva)

Harpoon

私は、Harpoonというコマンドラインツールを作成しました（このツールの詳細は、このブログ記事を参照してください）。これは脅威インテリジェンスツールとして作成しましたが、OSINT用コマンドを多数追加しました。これは、Linux環境にあるPython3で動き、オープンソースです（多分、MacOSとWindowsOSでも動くと思います）。

例えば、キーサーバーにあるPGPキーを探す際には、Harpoonを以下のように使います。

$ harpoon pgp search tek@randhome.io
[+] 0xDCB55433A1EA7CAB  2016-05-30      Tek__ tek@randhome.io

さらに、プラグインに関する長いリストがあります。ぜひ追加すべき新しい機能を思いついたら、提案あるいは開発、あるいはリクエストを挙げてください。

Python

しばしば、ツールを使っても簡単には終わらない特定のデータ収集と可視化タスクを早く切り上げたいと思うでしょう。その場合、自分でコードを書く必要があります。私の場合、Pythonを使うことが多いです。最近のプログラミング言語であれば同様に目的を達成できますが、私はPythonが持つフレキシビリティと利用可能な多数のライブラリを活用するため、Pythonを選んでいます。

Justin Seitz (Hunchlyの作者)は、PythonとOSINTについて言及していますので、彼のブログAutomating OSINTと彼の著書Black Hat Pythonはぜひ読んでみてください。

他のツール

OSINTツールはほかにも多数ありますが、全ての調査で有益とは言えないツールもありました。以下に、読者が知っておくべき他のツールを紹介します。個人的には必須ツールにはなりませんでしたが、こうしたツールは非常に興味深く、完成度の高いツールです。

SpiderFootは多数の異なるモジュールを持つ、偵察用ツールです。非常に良いウェブインターフェースを持っており、異なるタイプのデータ間の関係性を示すグラフを生成してくれます。私がこのツールを好きでない点は、利用者のために全てを見つけてきてくれる魔法のツールと考えられてしまう点です。しかし、何を探しているか利用者の考えをくみ取り、結果を分析してくれるツールはありません。要するに、自分自身で研究し全ての結果を一つづつ読まなくてはいけません。良いツールでよいインターフェイスを持っていますが、SpiderFootはその点についてはあまり役に立ちません。

SpiderFootのスクリーンショット(情報源:spiderfoot.net)

recon-ngは、素晴らしいCLIツールで、異なるプラットフォーム、ソーシャルメディア、脅威インテリジェンスプラットフォームから情報を取得することができます。正直、Harpoonに正直よく似ています。なぜ使わないかというと、Harpoonが自分ニーズに必要な機能を提供してくれており、提供されるシェルインターフェイスが苦手であるためです。
Buscadorは、Linuxの仮想マシンで、異なるOSINTツールが含まれています。私は、いつも自分用にカスタマイズされたシステムを好みますが、ツールを一つづつインストールする手間なく新しいツールを試すことができる良い方法です。

さあ始めよう！！

さて、それでは具体的な内容に入っていきましょう。OSINT調査において何が助けになるでしょか？

技術的なインフラストラクチャ

技術的インフラストラクチャの分析は、脅威インテリジェンスとオープンソースインテリジェンスが交差する点です。しかし、いくつかの点で調査の重要なパートになり得ます。

さて、読者が探すべきは以下の通りです。

IPとドメイン：この目的のツールは多く存在しますが、Passive Total（現在は、RiskIQ）が最も良い情報源になると思います。Webインターフェイスから1日１５クエリまで、API経由でも１５クエリまで無料で使えます。ほとんどこのツールを使っていますが、Robtex、HackerTargetand、Security Trailsも他の良い代替ツールになります。
証明書: Censysは素晴らしいツールです。しかし、より知られておらず少し劣りますがcrt.shも非常によい証明書の透明性データベースです。
スキャン：IPアドレス上でどのようなサービスが動いているか確認することは有益です。Nmapを使って自分でスキャンすることもできますが、全てのIPv4アドレスに定期的にスキャンしてくれるプラットフォームを活用することもできます。その二つのプラットフォームこそ、CensysとShodanです。この二つは異なる側面に焦点を当てており、それぞれの特徴を知り、両方を使いこなす必要があります（ShodanはIoTに焦点を置いており、CensysはTLSに焦点を置いています）。BinaryEdgeは最近登場し急速に発展している代替となるプラットフォームです。より最近では、Fofaと呼ばれる中国プラットフォームが登場しました。別の情報源として、Rapid7 Open Dataが挙げられますが、スキャンファイルをダウンロードする必要があり、自分で分析を行う必要があります。最後にIPアドレスに関する時系列データはプラットフォームの変遷を理解する上で金脈となることを指摘したいと思います。Censysはこうしたデータを有償プランでしか提供してくれません（アカデミックの研究者は無料で利用することができます）が、ShodanはIPごとにこうしたデータを提供してくれ、非常に素晴らしいです。harpoon shodan ip -H IPがコマンドがもたらす内容はぜひ確認してください（Shodanのライフアカウントを支払う必要があります）
脅威情報：OSINTではあまり重要ではありませんが、ドメイン、IP、URLに対する悪性のアクティビティを確認することは常に興味深いことを教えてくれます。これを行うために、私はPassive TotalとAlienVault OTXに依存しています。
サブドメイン：あるドメインに対するサブドメインのリストを取得する方法は様々あります。例えば、Google検索（Site：ドメイン）を使う方法から、証明書に記載されている代替ドメインを探す方法などが挙げられます。Passive Total、BinaryEdgeは、この機能を実装しています。そのため、初期リストを得るためであれば、こうしたサービスに直接クエリを投げることが手っ取り早いでしょう。
Googleアナリティックスとソーシャルメディア：最後の情報は、とても興味深いもので、複数のwebサイトで、同じGoogleアナリティックス・アドセンスIDを使っているか確認することです。このテクニックは2015年発表され、ココに詳しく書かれています。こうしたコネクションを探すためには、私はPassive Total、SpyOnWeb、NerdyDataを使っています。 (publicwwwは、別の有償サービスとして知られています)。

検索エンジン

コンテキストに依存して、調査中は異なる検索エンジンを使い分けてるかもしれません。私は、そのほとんどをGoogle、Bing（欧州・北米用）、Baidu（アジア用）、Yandex（ロシア・東ヨーロッパ）に依存しています。

もちろん、最も基礎的な調査ツールは、検索演算子です。Googleの検索演算子のリストはココにあります。以下に最も興味深いものを抜粋しました。

以下のブーリアン型の論理演算子を使いクエリを結合することができます。AND、OR、+、-
filetype：特定のファイル拡張子を検索を行います。
site：特定のWebサイトへフィルタを書けます。
intitleとinurl：タイトルやURLにフィルタを行います。
link：特定のURLへのリンクを持つWebサイトを探すことに特化します。（2017年に非推奨になりましたが、現在でも一部機能します）

以下に例文を示します。

NAME + CV + filetype:pdf：この組み合わせは特定のCVを探し出すのに役立ちます。
DOMAIN - site:DOMAIN：Webサイトのサブドメインを探すのに役立ちます。
SENTENCE - site:ORIGINDOMAIN：特定の文章をコピーしたり剽窃したサイトを探し出します。

よく詳しくなるためには、以下を参照してください。

画像

画像の観点では、二つのことを知っておくべきでしょう。どのように画像に関する追加情報を探し出すか、そしてどのように類似した画像を探し出すかです。

追加情報を探し出すためには、最初のステップとして、EXIF情報に注目しましょう。EXIF情報は、イメージが作成されたときに付与されるメタデータであり、作成時刻、使われたカメラの情報、さらにはGPS情報が付与されていることもある非常に面白い情報を含んでいます。これらを確認するため、私はコマンドラインツールであるExifToolを使うことが多いですが、ChromeやFirefox向けに提供されているExif Viewerアドオンも非常に使いやすいと思います。さらに、面白い機能を備えているPhoto Forensic website使うのも一つの手でしょう。（他の代替手段として、exif.regex.infoやFoto Forensicsも挙げられます）。

似たようなイメージを探すためには、Google Images、Bing Images、Yandex Images、TinyEyeを使えばよいでしょう。TinyEyeは使いやすいAPIを提供しており（使い方はココを参照のこと）、Bingは画像の特定の部分を使って検索することができる有益な機能を持っています。remove.bgなどのツールを使って、イメージのバックグラウンドを取り除くことで、より良い結果を得ることができます。

例えば、場所を見つけ出すなど、画像の内容を分析する楽な方法はありません。どの国が候補に挙がるか推測するためには、画像の中に移りこんでいる特定の目印を探し出す必要があります。そして、ネット上で検索を行い、衛星画像と比較していく必要があります。このテクニックについて学ぶためには、Bellingcatが実施した興味深い調査結果が、ココやココにありますので参照してください。

さらに学ぶためには、以下のリソースを参照してください。

BellingcatによるMetadata: MetaUseful & MetaCreepy
First Draft newsによるThe Visual Verification Guide

ソーシャルネットワーク

ソーシャルネットワークの分野では、多くのツールが存在します。しかし、プラットフォームに多く依存します。以下に有益なツールとテクニックを抜粋します。

Twitter：APIは、ツイートが公開された時間とツールを教えてくれます。x0rzが開発したtweets_analyzerは、アカウントのアクティビティの概要をまとめてくれるツールです。メールアドレスからTwitter IDを探してくる方法も複数存在しますが、少し特殊な方法を使います。
Facebook：Facebookの調査で最も良いリソースは、Michael BazzellのWebサイトでしょう。特に彼の独自ツールのページは秀逸です。
LinkedIn：LinkedIn上で私が見つけた最も有益なテクニックの一つは、メールアドレスからLinkedInプロファイルを見つける方法です。

キャッシュプラットフォーム

調査時において、素晴らしい情報源になるものの一つに、Webサイトのキャッシュを作成するプラットフォーム群が挙げられます。なぜなら、Webサイトは押したり、Webサイトの時系列的な変遷を分析できるためです。こうしたプラットフォームは、自動的にWebサイトをキャッシュするものもあれば、リクエストに応じてキャッシュするものもあります。

検索エンジン：多くの検索エンジンは、クローリングしたときのWebサイトのコンテンツをキャッシュとして保存します。これは非常に有益であり、多くのサイトのキャッシュを見ることができます。但し、最後にキャッシュされるタイミング（多くの場合１週間以内だと思います）を管理できないこと、すぐに削除されてしまう事実も抑えておく必要があります。そのため、もし面白い情報をキャッシュ上で見つけたら、すぐに保存することをお勧めします。私はGoogle、Yandex、Bingなどの検索エンジンのキャッシュを使っています。

インターネットアーカイブ：Internet Archiveは、インターネットに公開された全てを保存するという目的で動いているプロジェクトです。この中には、自動的にクローリング対象のWebページを保存するだけでなく、そのサイトの変遷も巨大なデータベースとして保存しています。彼らは、Internet Archive Wayback Machineと呼ばれるWebポータルを提供しており、Webサイトの変遷を分析する上で非常に優れた情報源です。一つ知っておくべき重要なことは、Internet Archiveは要請があればコンテンツを削除するということです。（実際、Stalkerware company Flexispyの件で、削除したことがあります）。そのため、保存しておく必要があるコンテンツは、別の場所に保存しておく必要があります。

他の手動キャッシュプラットフォーム：私は、Webページのスナップショットを保存でき手、他の人が取得したスナップショットを閲覧できるarchive.todayを好んで使っています。多くの調査でこのサイトへ依存しています。perma.ccも良いですが、無料アカウントでは１か月１０リンクまでしか使えないという制限があり、プラットフォームは、図書館や大学に焦点を当てています。このソースコードはオープンソースで提供されており、キャッシュプラットフォームを独自で構築したいと考えた場合、間違えなくこのソフトを使うでしょう。

Webキャッシュが存在するか一つづつ手作業で確認していくことはめんどくさいと考える人も多いでしょう。そのため、私は、Harpoonに簡単なコマンドを実装しました。

さらに、以前言及したHunchlyは、「レコーディング」機能を有効にした場合、アクセスしたあらゆるページをローカルアーカイブに自動的に保存してくれることも覚えておく必要があります。

証拠の取得

次のポイントに移りましょう。それは、証拠の取得です。証拠の取得は、調査における重要なフェーズの一つです。特に、調査が長引く場合には非常に重要です。間違えなく、Webサイトが変更された、Twitterアカウントが削除されたなど、何度か自分が見つけた証拠をなくす経験をするでしょう。

覚えておくべきことは、以下の通りです。

Internet Archiveに完全に依存することは難しいですので、他のキャッシュプラットフォームや可能であればローカルに保存することをお勧めします。
画像、文書を保存しましょう。
スクリーンショットを取得しましょう。
ソーシャルメディアに関する情報を保存しましょう。攻撃者はいつでもこうした情報を削除することができます。（Twitterアカウントにおいては、Harpoonは、ツイートとユーザ情報をJSON形式のファイルで保存するコマンドを用意しています。）

さらに勉強するためには、以下のリソースをご覧ください。

How to Archive Open Source Materials（Aric Toler from Bellingcat）

短縮URL

短縮URLは、利用する際に非常に興味深い情報をもたらします。異なるサービスにおいて、統計情報を取得する方法をまとめました。

bit.ly：URLの最後に、https://bitly.com/aa+ のように + を追加してください。
goo.gl：（もうすぐ非推奨になりますが）URLの最後に + を追加することで、https://goo.gl/#analytics/goo.gl/[ID HERE]/all_time のようになURLへリダイレクトします。
ow.ly：hootsuite社が提供する短縮URLサービスですが、統計情報を見ることはできません。
tinyurl.com：統計情報を取得できませんが、http://preview.tinyurl.com/[id] にすることでURL自体をみることができます。
tiny.cc：https://tiny.cc/06gkny~ のように ~ をつければ、統計情報を見ることができます。
bit.do：http://bit.do/dSytb- にハイフン（-）をつければ、情報を取得することができます。(統計情報は非公開の場合があります)
adf.ly：この短縮URLは、リンクへのリダイレクト時に広告を表示することで収益を上げることを提案しているサービスです。彼らは、j.gsやq.gsなどその他のサブドメインを多数利用し、公開の統計情報を閲覧することができません。
tickurl.com：https://tickurl.com/i9zkh+ のように + をつければ統計情報へアクセスできます。

いくつかの短縮URLは連番のIDが使われている可能性があります。その場合、同時刻に作成された似たようなURLを推測できる可能性があります。このアイディアの事例はこのレポートを参照してください。

企業情報

いくつかのデータベースでは、企業情報を検索することが可能です。メインで利用されるものは、Open CorporatesやOCCRP database of leaks and public recordsが挙げられます。その後、各国に応じたデータベースに依存していきます。例えば、フランスではsociete.comが有名ですし、米国であればEDGARへ、イギリスであればCompany Houseへアクセスすべきでしょう（より詳細な情報はココから参照してください）。

参考文献

OSINTを学ぶ上で更なるリソースとしていかが挙げられます。

Bellingcatによる貴重なリソース：ガイドとコミュニティが作成した情報リスト
The Github repository：Awesome OSINT
The OSINT framework
osint.link

これですべてです。時間をかけてこのブログを読んでくれてありがとうございます。もし追加すべきリソースがあればTwitterなどから気軽にコンタクトしてください。

このブログ投稿は、Nils Frahmを聞きながら書きました。

更新１：Yandex Images、remove Background、 Forensicを追加しました。このテクニックを教えてくれたJean-Marc Manachとfo0に感謝します。

(恐らく)2020年最後のマリオットポイント購入&50%増量セール（2020年11月26日～12月22日）

会員の方は、ご購入またはプレゼントされたポイントに50％のボーナスがつきます。会員が1暦年中に購入またはプレゼントできるポイント数は50,000ポイントが上限ですが、このセール期間中は3倍の150,000ポイントになります。

このオファーは、マリオットのウェブサイトからアクセスできます。

ポイントを受け取る会員のアカウントは、最低90日以上、または資格のある活動があった場合は30日以上オープンしていなければなりません。

Here’s the price at a 50% bonus:

50％のボーナスで購入したポイントのコストは、1ポイントあたり0.83セント（1,875円で225,000円分のポイントがもらえる）です。

結論

現在のアワードの空室状況は素晴らしく、通常よりも少ないポイント数で販売されているホテルも多くあります。

ポイントを利用した予約は、高額な宿泊施設や、前払いや返金不可の料金よりもキャンセルの柔軟性が必要な場合には、最も意味があります。

JAL、JGC・FLY ONステイタスカードの全員への発行終了　2021年から希望者のみに（転載）～コスト削減の嵐と思いつつ、実際は搭乗券にステータス印字されるので、カードを使うことはなく、理解はできる～

JAL、JGC・FLY ONステイタスカードの全員への発行終了　2021年から希望者のみに:

日本航空（JAL）は、JALグローバルクラブ（JGC）会員と、FLY ON ステイタスを達成した全員に対するステイタスカード発行を、2021年から取りやめる。

公式アプリの「JAL」アプリでステイタスを確認できることから、全員に対するカード発行を取りやめ、希望者のみにカードを発行する。申込期間は2021年2月中旬から12月中旬まで。

FLY ON ステイタスカードまたはJGC ワンワールドサファイアカードは、申込手続き時点で有効な最上位のステイタスカードを申し込める。なお、JALグローバルクラブ会員のFLY ON ステイタスカードには、従来どおりJALグローバルクラブのロゴが入る。

上位ステイタスの達成、発行済ステイタスカードの有効期限更新が必要なタイミング、もしくは日本地区以外でのJALグローバルクラブへの入会で申し込みができる。2022年3月末または2023年3月末まで有効なステイタスカードを発行済みの場合、同じステイタスのカードを申し込むことはできない。再発行は電話での問い合わせが必要。新型コロナウイルス特別対応により、FLY ON ステイタスが2022年3月末まで延長の対象の場合、申込みができる。

【転載】Win10 HomeエディションでWindows Updateを抑制する方法 / Take control of Windows 10 feature updates using these settings

Take control of Windows 10 feature updates using these settings

マイクロソフトは、Windows UpdateがWindows 10の新しい機能アップデートをインストールする方法をユーザーがより大きくコントロールできるようにする新しい設定を追加しました。"

Windows 10のバージョン1903で、Microsoftは、グループポリシーエディタで使用し続けたい特定のWindows 10機能アップデートを設定する機能を追加しました。10月には、Patch Tuesdayのアップデートで、デバイス上のセーフガードホールドをバイパスできる追加ポリシーが追加された。

この記事では、Windows 10の機能アップデートをコントロールできるように、両方のグループポリシーを強調しています。

Windows 10の機能アップデートバージョンを指定

Windows 10には「TargetReleaseVersionInfo」と呼ばれる新しいポリシーが搭載されており、機能のアップデートがインストールされないようになっています。

このポリシーを使用すると、使用するWindowsのバージョンを指定して、指定したバージョンがサポート終了に達するまで、Windows 10が新しい機能リリースをインストールしないようにすることができます。

このポリシーはWindows 10 Pro版とEnterprise版でのみ機能し、使用するWindows 10のバージョンを設定することができます。

また、以下の手順でWindows 10 Homeでも有効にすることができます。

Windows検索を開きます。
レジストリエディタ」を検索し、検索結果に表示されたら選択します。
レジストリエディタで、以下の場所に移動します。HKEY_LOCAL_MACHINE\SOFTWAREPolicies\MicrosoftWindows\WindowsUpdate
Windows Updateを右クリックし、「新規作成」→「DWORD(32ビット)値」を選択します。
名前に「TargetReleaseVersion」と入力し、値を1に設定します。
ここで、再度Windows Updateを右クリックし、「新規作成」→「文字列の値」を選択します。
新しい文字列の値に「TargetReleaseVersionInfo」という名前を付け、その値にとどめておきたいWindows 10のバージョン番号を設定します。

Windows 10のバージョン2004を使用して20H2を回避したい場合は、「2004」という値を設定する必要があります。

セーフガードホールドのバイパス

Windows 10の2020年10月のパッチチューズデーアップデートで、グループポリシーエディタには、アップグレードブロック（デバイスに配置されたセーフガードまたは互換性ホールド）をバイパスできるようにする1つの新しいポリシーが付属しています。

最近のWindowsアップデートの騒動の後、Microsoftは互換性のないドライバやソフトウェアなどを搭載したデバイスの機能アップデートをブロックするために「セーフガードホールド」を導入しました。

新しいポリシー「機能アップデートのセーフガードを無効にする」を使用すると、これらのアップグレードブロックを削除することで、Windows 10 アップデートをより迅速にダウンロードしてインストールすることができます。

このポリシーは、[コンピュータの構成] > [管理テンプレート] > [Windows コンポーネント] > [Windows Update] > [Windows Update for Business]の下で使用できます。この機能を使用するには、ポリシー「機能アップデートのセーフガードを無効にする」を選択して有効にします。

"セーフガードホールドをブロックせずに、機能アップデートをデバイスに展開する場合に、この設定を有効にします。セーフガードホールドとは、既知の互換性の問題で、問題が解決されるまでアップグレードが影響を受けるデバイスに展開されないようにブロックするものです。このポリシーを有効にすると、テスト用のデバイスに機能アップデートを展開したり、セーフガードホールドをブロックせずに機能アップデートを展開したりすることができます」とポリシーでは説明されています。

また、Windows 10 Homeでも、以下のレジストリファイルで有効にすることができます。

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DisableWUfBSafeguards"=dword:00000001

Googleのシステム障害、認証サービスダウンがはらむリスクがあらわに（転載）～クラウドサービス使うときは、年1回程度の大規模障害を受け入れる覚悟が必要～

Googleのシステム障害、認証サービスダウンがはらむリスクがあらわに:

　2020年12月14日20時55分ごろから約50分間にわたってGoogleの主要サービスが使用できなくなった。日本ではすでに終業時間の企業が多かったが、Googleアカウントに関連するサービスが約50分間使用できなくなった。

サービスダウンではなく認証システムのトラブル、発生の要因は

　本稿執筆時点でGoogleから今回のサービス停止に関する詳細報告はない。現時点では「Google Cloud Status Dashboard」に掲載されている簡素な説明が障害の原因を伝えるのみだ。

　執筆時点での説明によれば、今回のサービス停止は「Google Cloud Platform」および「Google Workspace」で動作するもののうち、アカウントログインと認証を必要とする全てのサービスで発生した。原因は、クラッキングなどではなく、自動化されたクォータ（quota）管理システムにあるとされている。

　クオータとは、システムやアプリケーションごとにストレージの利用条件を設定する仕組みだ。一つのサービスがストレージを全て使い尽くしてしまうリスクを避ける場合などに使われる。

　今回の障害は、Googleが運用する「中央ID管理システム」が必要とするストレージ容量が、クオータの設定によって不足したことで、認証システムが適切に動作しなくなったことが原因だという。データ量がクオータの設定上限に至った理由や自動拡張されなかった理由はまだ明らかになっていないため、単純な設定の問題か、認証サービスダウンを狙った悪意ある攻撃の影響なのかは定かではない。

単一アカウントを使用することの利便性と危険性

　「Google Workspace」を契約するビジネスパーソンであれば、Googleが提供するさまざまなサービスを利用していることだろう。Google以外のサービスの認証にGoogleアカウントを利用するケースも考えられる。

　今回のサービス停止は、こうした単一のアカウントに依存した状況が障害発生時の回避方法の選択肢を狭めるものであることを示す結果となった。障害が発生した時間帯が日中であればさらに多くの企業が影響を受けた可能性がある。

　今回の問題はGoogleが直接提供するサービスに限定されるものではなく、Googleの認証機能を使用するサードパーティー製のサービスでも発生した。

【転載】マイクロソフトは2021年8月17日のInternet Explorer終息に着手 / Microsoft begins to finally kill off Internet Explorer

Microsoft begins to finally kill off Internet Explorer

マイクロソフト社は、Chromiumベースの新しいブラウザ「Microsoft Edge」を採用して、時代遅れのInternet Explorerを廃止するために、さらなる措置を講じようとしている。

マイクロソフト社は何年にもわたってユーザーにInternet Explorerからの切り替えを勧めてきたが、いまだにブラウザの市場シェアは5％近くにとどまっている。

多くの人にとってはまだ始まっていないとしても、間もなく開始されるマイクロソフトは、人々をInternet Explorerから遠ざけるためのより積極的な措置を取ることになるだろう。

互換性のないサイトのMicrosoft Edgeへの自動リダイレクト

Microsoft Edgeの最近のバージョンから、Internet Explorerが互換性のないサイトにアクセスすると、Microsoft Edgeで自動的にブラウジングセッションが起動し、ブラウジングセッションを継続するようになりました。

互換性のないサイトのリストはMicrosoftが管理しており、現在はTwitter、Facebook、Instagram、Google Drive、Microsoft Teams、ESPN、Yahoo Mailなど1,156サイトが含まれています。

このリダイレクトは、以下のように「IEtoEdge BHO」というInternet Explorerのブラウザヘルパーオブジェクト（BHO）を介して行われます。

BHOに関連付けられたファイルは、「C:Program Files (x86)」フォルダの下にあります。

ie_to_edge_bho.dll
ie_to_edge_bho_64.dll
ie_to_edge_stub.exe

BHOでは、Webサイトを閲覧する際に、Internet Explorerに対応していないWebサイトがないかどうかを確認しています。対応している場合、BHOは自動的にMicrosoft Edgeでサイトを開き、以下のように「このサイトはInternet Explorerでは動作しません！」というメッセージを表示します。

アラートを表示すると、Microsoft Edgeでは、Internet Explorerの設定やデータ、CookieをMicrosoft Edgeに移行するようユーザーに促すメッセージも表示されます。

"以下の閲覧データがインポートされます。お気に入り、パスワード、検索エンジン、開いているタブ、履歴、設定、クッキー、ホームページ」とマイクロソフトは説明する。

データを移行しないことを選択した場合でも、『ブラウジングを続ける』ボタンをクリックして、Microsoft Edgeでウェブサイトを閲覧することができるという。

Internet Explorerと互換性のないサイトを閲覧している間、Microsoft Edgeでは、デフォルトブラウザを新しい最新のブラウザに設定するよう促すバナーが表示されます。

Microsoft Edgeでサイトを開くと、互換性のないサイトのIEタブは、コンテンツがなかった場合は自動的に閉じられます。そうでない場合は、"あなたが到達しようとしていたウェブサイトはInternet Explorerでは動作しません "と説明するMicrosoftのサポートページにリダイレクトされます。

10月26日、マイクロソフトは、先日追加されたサポートドキュメントに詳細が記載されているこのリダイレクト動作をユーザーが制御できるようにする新しいグループポリシーテンプレートを導入します。

RedirectSitesFromInternetExplorerPreventBHOInstall - Internet Explorer での「IEtoEdge BHO」のインストールを防ぐことができます。
RedirectSitesFromInternetExplorerRedirectMode - Internet Explorer の Microsoft Edge へのリダイレクトを無効にします。
HideInternetExplorerRedirectUXForIncompatibleSitesEnabled - 管理者がMicrosoft Edgeに表示されるリダイレクトアラートを無効にできるようにします。

Microsoftのサポート文書では、このリダイレクトは11月17日頃にリリースされるMicrosoft Edge 87で開始されるとされていますが、BleepingComputerのテストでは、Microsoft Edge 86.0.622.51ですでにリダイレクトが発生しています。

マイクロソフトのサービスは11月にIEのサポートを失う

今回のリダイレクトに加えて、Microsoftは、Microsoftが提供するさまざまなサービスでInternet Explorerのサポートを無効化する予定だという。

また、Microsoftは8月のブログ記事で、Microsoft Teamsが11月30日からInternet Explorer 11のサポートを終了することを明言していた。

Microsoftは最終的に、2021年8月17日にすべてのサービスでInternet Explorerのサポートを終了する予定だ。

引き続きInternet Explorerのサポートを必要とするユーザーは、Microsoft EdgeのInternet Explorer Modeを使用して後方互換性を保つことができるようになる。

【転載】Windows 10はコントロールパネルを非表示にしている。どうアクセスするか / Windows 10 now hides the SYSTEM control panel, how to access it

Windows 10 now hides the SYSTEM control panel, how to access it:

Windows 10 20H2のリリースに伴い、Microsoftは現在、由緒あるSYSTEMコントロールパネルへのアクセスを禁止し、代わりに新しく更新された「バージョン情報」設定ページにユーザーをリダイレクトしています。

SYSTEMコントロールパネルは、Windows NT 3.51とWindows 95で最初に導入され、インストールされているWindowsのバージョン、オペレーティングシステムのビットタイプ、コンピュータ名、ワークグループ、CPU、およびメモリに関する情報を提供します。

コントロールパネルはコンピュータに関する多くの情報を提供しているため、Windows PCのトラブルシューティングやコンピュータの基本情報を決定する際によく使用されています。

7月にBleepingComputerは、Microsoftが「バージョン情報」の設定ページを更新し、SYSTEMページにある情報のほとんどを含むようにしたと報じた。当時、マイクロソフト社は、SYSTEMコントロールパネルを開いたときにユーザーを「バージョン情報」ページにリダイレクトする隠し機能もテストしていました。

Windows 10 20H2で、マイクロソフトはコントロールパネルの棺桶に別の釘を打ち込み、ユーザーがSYSTEMコントロールパネルにアクセスできないようにしました。現在、ユーザーがそれを開こうとすると、代わりに [バージョン情報] ページが表示されます。

最新のディスク管理ツールのテスト、リフレッシュレートオプション、「プログラムと機能」コントロールパネルを「アプリと機能」設定にリダイレクトするテストを行うことで、マイクロソフトがコントロールパネルを徐々に削除していることがわかります。

最終的には、Windows 10 は設定が異なる場所に配置されていて混乱しているので、これは良いことだと思います。設定機能の下にそれらを整理することで、特定の設定を見つけやすくなります。

日常的にSYSTEMコントロールパネルを使用している方には朗報ですが、以下に説明するように、まだアクセスする方法があります。

Windows 10 20H2でSYSTEMにアクセスする方法

MicrosoftがSYSTEMコントロールパネルをリダイレクトしている間、特別に細工されたWindowsショートカットを介してアクセスする方法があります。

SYSTEMコントロールパネルを開くショートカットを作成するには、以下の手順に従ってください。

Windowsデスクトップが表示されるように、開いているすべてのアプリケーションとフォルダを最小化します。
デスクトップを右クリックし、以下のように「新規作成」>「ショートカット」を選択します。
ショートカットの作成] ウィンドウが開いたら、[エクスプローラーシェル::{BB06C0E4-D293-4f75-8A90-CB05B6477EEE}をコピーしてフィールドに貼り付けます。その後、「次へ」ボタンを押します。
ショートカットの名前を尋ねるページが表示されます。名前に「SYSTEM」と入力し、「完了」ボタンを押します。
デスクトップにSYSTEMというショートカットが作成され、SYSTEMコントロールパネルを再度開くために使用できるようになります。

Windows 10 20H2でこのショートカットを作る方法を説明した動画が以下にあります。

この SYSTEM ショートカットは、スタートメニューで「SYSTEM」を検索し、「アプリ」セクションの下に表示されるアイコンを選択することで、スタートメニューから直接起動することもできます。

現在の Windows 10 Insider プレビュービルド（Windows 10 20231 でテスト済み）では、SYSTEM コントロールパネルにアクセスする他のすべての方法は、新しい [バージョン情報] ページにリダイレクトされます。

freee、パスワード付き添付ファイルのメール受信を廃止（転載）～ハンコ文化と並ぶ悪しき風習のPPAP根絶へ！～

freee、パスワード付き添付ファイルのメール受信を廃止 - ITmedia NEWS:

　クラウド会計ソフトを提供するfreeeは11月18日、メールに添付されたパスワード付きファイルの受信を12月1日に廃止すると発表した。メールを受信した場合、メールサーバで添付ファイルは自動的に削除される。メール本文は維持したまま受信できるが、ファイルが削除された旨が本文に追記されるという。

freeeは「パスワード付きファイルはマルウェア検査を迂回（うかい）してしまうことからセキュリティリスクを増大させる」と指摘。パスワード付きファイルの受信をやめることで、添付ファイルを通じて感染するマルウェア「Emotet」などを防ぎたい考え。

効果が薄いとわかっていてもなかなか仕組みを変えられないのが日本企業の特徴だが、いかにして廃止を実現したのか。

今回、パスワード付きファイルのメール受信廃止を決めたfreeeでは、どのように社内の理解を取り付け、実現させたのか。話を聞くと、以前から行ってきたセキュリティに対する意識の醸成が大きな影響を与えていることがわかった。

　freee CIO（Chief Information Officer：最高情報責任者）の土佐鉄平氏によれば、セキュリティ上の観点から、これまでもfreeeからの送信メールにはなるべくファイルを添付しない方針だったそうだ。

　同社はGoogle Workspace（旧G Suite：Gmailやカレンダー、ドライブ、ドキュメント、スプレッドシートなどのツールを含むクラウド上のワークスペース）を利用しており、従業員にはGoogle ドライブを使ってファイル共有を行うことを推奨。個人情報を含むものなど特に重要な情報は、メールではなくドライブを利用するよう指示してきた。

　ただし、取引先のポリシーによってはドライブへのアクセスが制限されていることもあるため、その場合は別の手段を選択。ほかに選べる手段がなければ、例外的にメールにファイルを添付して送信するという運用だった。

　その一方、これまで外部からのメール受信の際には添付ファイルの受け取りは制限されていなかった。パスワードが後送される、いわゆるPPAP方式のファイル受信も行っていたという。

　ここ数年、不審メールの検知が増えていたfreee。土佐氏は「幸い、実害を受けることは今までなかったが、やはりパスワードで暗号化されてスキャンツールが効かない状態で受信しているケースは結構あった。以前からずっと、これは課題だと認識していた」と語る。

　具体的に、パスワード付きファイルをメールで受け取らないことを検討し始めたのは、米CISAによりEmotetへの注意喚起が出たことがきっかけだった。ウイルス対策ソフトやファイアウォールの設定、電子メールに添付された実行ファイルのブロックなど、これまでも対策を講じるよう推奨されてきた項目に加えて、「ウイルス対策ソフトでスキャンできないタイプのメール添付ファイル（zipファイルなど）のブロック」が対策として推奨されていたからだ。

「公的な機関からの注意喚起という後ろ盾を得て、これを機に廃止を進めてしまおうということになった」（土佐氏）

　土佐氏らはパスワード付きファイルを受信しない設定方法と、受信廃止による影響について調査を進め、11月2週目まで社内で検証を実施。11月18日、取引先への周知のために廃止をアナウンスした。この日はちょうど平井大臣からPPAP廃止の方針が出た翌日で、タイムリーな発表となったが、テストも含めた準備自体は1カ月ほどかけて行ってきたものだった。

「調査により、Google Workspaceを利用する企業ユーザーなら、Gmailの添付ファイルに関するコンプライアンスルールの設定が管理画面から比較的簡単にできることがわかった。暗号化されたファイルをメールから削除することも容易で、かつ送信元による例外処理の設定も可能だとわかったので、原則としてパスワード付きファイルは受信しないルールとし、仕組み上、どうしてもパスワード付きファイルをメールで送らざるを得ない相手については例外処理とすることにした」（土佐氏）

　同社CSIRT（Computer Security Incident Response Team：コンピュータセキュリティ問題への対応チーム）の吉本真一氏は「Gmail以外のメールサービスでも、同様の設定は技術的には対応可能」として、「設定の難易度はサービスによって違いがあると思うが、いずれもさほど難しくないのではないか」と語る。

　freeeでは、取引先やパートナーに、パスワード付きファイルをメールで送らないよう依頼する際、外部にも説明しやすいようにと対外的なアナウンスを実施。社内への告知は外部への公表の前日だったそうだが、大きな反発はなかったという。

「折に触れて、PPAPやパスワード付き添付ファイルの問題点については社内へアピールしていたので、そのこと自体は浸透していたのだと思う。金融機関とのやり取りが多い部署などとは『もし廃止することになったら、結構影響を受けそう』といった対話もしていたが、そこでも大きな反発はなく、せいぜい『大胆なことを考えますね』という感じ。そのため、社内的には“行ける”という感触をつかんでいた」（土佐氏）

　発表後の社外からの反響もおおむね好意的だ。「スタッフからは、ほとんどのところで先方に対応いただけていると聞いている」と土佐氏。「12月1日の廃止に向けて、もっと例外設定の依頼がたくさん来るものと構えていたが、思ったより依頼は来ていない」という。

「セキュリティポリシーの一環として、送信ファイルが自動的にパスワード暗号化されるソリューションが入っている相手なら仕方がないと思っていたが、Google ドライブが使えない相手先からも『別のストレージなら対応できる』と提案をいただくなど、社内外ともに賛同が多い」（土佐氏）

　freee社内のセキュリティへの理解度、認識の高さは、これまでの教育のたまものでもある。

「従業員には入社初日のセキュリティ研修で、なぜメールでのファイル送信はいけないのか、クラウド上のドライブによるファイル共有の方が望ましいのはなぜか、説明している。また四半期に1度は、セキュリティに関する理解度チェックをeラーニングで実施するなど、コツコツと活動している」（土佐氏）

　理解度テストは全5問。復習していれば100点が取れる内容で、「テストの点数が上がることよりも、選択肢を読むことが大切で、全員に受けてもらうことにこだわっています」と土佐氏は言う。

　またfreeeでは、新たなセキュリティ上の問題（インシデント）についての情報を、経営陣とともに従業員にも共有している。

「話題になっているインシデントについては、CSIRTから経営陣向けに定期的に報告をしている。インシデントに対してfreeeではどういう対策がとられているか、また足りない部分については『このように対策すべき』という取り組みを説明するが、その報告の様子を全社にも動画で配信している」（土佐氏）

　取り上げるインシデントは世間で起きているニュースなので、従業員にも興味を持ってもらいやすい。専門的な難しい用語は避け、こちらも少なくとも四半期に1度は配信するようにしているという。セキュリティインシデントの社内理解が進むとともに、経営者がセキュリティに関心を持つ姿勢もアピールできる点で、実に優れた取り組みと言えるだろう。

　こうしたセキュリティに関する啓蒙活動により、「メールにファイルを添付しないことについても、freeeでは社内の共通認識となっていた」と土佐氏。パスワード付きファイルの受信廃止が他社より比較的進めやすかったのは、これまでの教育の成果と言って過言ではないだろう。

【参考】
無意味な「パスワード付き添付ファイル」受信をfreeeが廃止できた理由（ダイヤモンド・オンライン）

三菱パワーがMSP（マネージドサービスプロバイダ）の不正アクセスの2次被害を受ける（転載）～サプライチェーンリスク顕在化事例～

MSP経由で不正アクセス、提供ソフトにゼロデイ脆弱性 - 三菱パワー

三菱パワーが被害に遭ったMSP経由の不正アクセスについてまとめてみた

三菱パワーは、マネージドサービスプロバイダ（MSP）経由で不正アクセスを受けたことを明らかにした。一部情報の流出が確認されているが、機微な情報や個人情報は含まれていなかったとしている。

9月初旬より約1カ月間にわたり、同社や同社子会社のパソコン、サーバが不正アクセスを受けたもの。サーバの設定情報やアカウント情報、認証プロセスにおけるメモリダンプなど、システム関連の情報が窃取された。

機微な情報や機密性の高い技術情報、取引先に関する重要な情報、個人情報の流出などは確認されていないという。また親会社である三菱重工グループなどへの不正アクセスについても否定した。

同社によると、9月7日に同社のサーバ1台がマネージドサービスプロバイダ経由でマルウェアに感染。同プロバイダが提供するソフトウェアに修正プログラムや対策など用意されていないいわゆる「ゼロデイ脆弱性」が存在し、悪用された。

その後、ネットワークの偵察を経て断続的に感染を拡大する活動が行われ、同月22日には同社子会社のサーバに攻撃の起点を移すなど横展開されている。

株式会社日立システムズのプレスリリースバックアップ

三菱パワー株式会社のプレスリリースバックアップ

不正アクセスで顧客情報約8.8万件が被害か（転載）～想定損害賠償額は21億円程度か～

不正アクセスで顧客情報約8.8万件が被害か - 保険代理店

顧客管理システムが不正アクセスを受けた保険代理店のライフィは、データベースに保存されていた顧客情報8万8564件が被害に遭った可能性があることを明らかにした。

今回の問題は、同社サイトを通じて顧客情報の管理システムにおける脆弱性を突かれ、データベースが不正アクセスを受けたもの。10月13日に判明し、流出した顧客情報を特定するため、調査を進めていた。

調査の結果、保有する顧客情報が不正アクセスを受けたものの、流出した具体的な情報の特定はできず、攻撃を受けたファイル内に保管されている全顧客情報8万8564件が流出したと結論づけた。

具体的には、同社サイトを通じて保険商品のパンフレットを請求したり、同社スタッフと面談、メール、電話を通じてやり取りした最大8万8111件の顧客に関しては、氏名、住所、電話番号、生年月日、メールアドレス、対応履歴などが記録されていた。

ITセキュリティリスクアセスメントの実施 / Conducting an IT Security Risk Assessment

Conducting an IT Security Risk Assessment

企業のリスクを低減する能力を高めましょう。新しいホワイトペーパーでは、効果的なITセキュリティリスクアセスメントの実施が重要な理由をご紹介しています。ITセキュリティリスクアセスメントの実施

すべての企業は、既知のものから未知のものまで、ほとんど毎日のようにリスクに直面しています。リスク評価は、ビジネスの混乱や損害を最小限に抑えるために、テクノロジーやその他の企業資産に対する脅威を評価するのに役立ちます。

リスクは様々な形で発生するため、企業がこれらの脅威に備え、対処するための最善の方法は、事業目的に沿った強力で構造化されたリスク軽減戦略と計画を策定することです。

現在および将来のリスクを軽減し、潜在的な損害を軽減するためのリスクアセスメントを成功させるための重要なステップをより深く理解することができます。これらのステップには以下が含まれます。

資産の特定と評価
既知の脅威の識別
脆弱性の特定
リスクの特定
リスク治療の決定

このISACAホワイトペーパーは、ITセキュリティリスク評価プロセスを初めて利用する方や、ITセキュリティリスク評価プロセスに慣れていない方のための情報システムやビジネスの専門家向けのホワイトペーパーです。

バックアップ（非公開）

【転載】「会社の看板」は早く利用して、こちらから捨てたほうが良い

「会社の看板」は早く利用して、こちらから捨てたほうが良い

日本最大の大手広告代理店が、40代以上の正社員230人を業務委託の個人事業主に切り替える制度を開始するというニュースが話題になつています。

正社員という日本型の雇用形態は、企業から見れば大きなリスクになっています。事業環境の変化が大きくなればなるほど、固定費となる社員を抱え込むのは、経営を不安定させる要因なのです。

すでに日本では、企業年金制度が確定給付型から確定拠出型（日本版401k）にシフトし、年金の運用リスクが企業から従業員に転嫁されました。

今後も大きな流れとして、会社側がリスク回避のために、従業員を実質的に切り捨てていくと思います。

であれば、会社で社員として働いている人がやるべき事は、2つです。

1つは会社の看板を可能な限り利用すること

そして

もう1つは、会社に捨てられる前に自分から会社を捨てられる力を身に着けておくことです。

会社の看板があることによる1番大きなメリットは「お金を借りる力」が持てることです。個人事業主になれば、信用力がつくまで借り入れすることができません。会社にいるうちに、お金を借りられるだけ借りておく。「信用力のマネタイズ」をできるだけ早くやっておくことです。

NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係（転載）

NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係：働き方改革時代の「ゼロトラスト」セキュリティ（6） - ＠IT:

NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳

NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係

　SP 800-207は米政府がネットワークやセキュリティのモデルとしてのゼロトラストについて言及する際に、政府標準として扱われるべく提言されたものです。今後、他のSP 800シリーズ同様に、世界中の多くの組織がこのSP 800-207を参考に、ゼロトラストについて議論すると思います。

　今回はSP 800-207から、「ゼロトラストにおける7つの原則」といえる部分を解説していきます。

NISTによる「ゼロトラストにおける7つの基本原則」

　SP 800-207には、ゼロトラストが生まれた背景、基本的な考え方、そして実践の方法がまとめられています。これからゼロトラストを学ぶ上で非常に良質なドキュメントといえるでしょう。

　中でも第2章冒頭に掲げられた、「ゼロトラストにおける7つの基本原則」は、ゼロトラストを実現する上での理想的な考え方がまとめられています。

データソースとコンピュータサービスは、全てリソースと見なす
「ネットワークの場所」に関係なく、通信は全て保護される
組織のリソースへのアクセスは、全て個別のセッションごとに許可される
リソースへのアクセスは動的なポリシーによって決定される
組織が保有するデバイスは、全て正しくセキュリティが保たれているように継続的に監視する
リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される
資産・ネットワーク・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する

　これらの7つの基本原則をまとめ、以下を満たした状態が理想的なゼロトラストであると提言しています。

全てのリソースへのアクセスの認証と認可がリクエストごとに動的に決定される
全てのリソースの状態が、その判断に用いられる
全てのリソースの機器や通信が保護され、状態が可視化によって監視されている

　では、これらの7つの基本原則について詳しく見ていきましょう。

【1】データソースとコンピュータサービスは、全てリソースと見なす

　アクセスする側／される側に関係なくネットワークに接続されている全ての機器をリソースとして見なします。

　小型のストレージ機器、IoTデバイスなど、あらゆる大きさや機能を持っているデバイスもリソースとして考えます。もちろん、クラウドサービスもリソースの一つとして考えます。さらに、個人が所有している機器であっても組織のリソースにアクセスするのであればリソースとして考えます。

【2】「ネットワークの場所」に関係なく、通信は全て保護される

　この原則における「ネットワークの場所」とは、社内ネットワークやプライベートネットワークといった、一般的に「従来の境界線の内側や外側」とされる範囲を指しています。

　従来の境界型セキュリティモデルでは、ネットワーク境界線の内側は安全であり、暗黙的な信頼を付与していました。ゼロトラストの基本原則では、「セキュリティシステムで保護されたネットワーク境界範囲内であっても、インターネットと同様に利用可能な最も安全な方法で通信を保護すべきである」としています。

【3】組織のリソースへのアクセスは、全て個別のセッションごとに許可される

　従来のネットワークアクセスの考え方では、一度行われた認証や認可を一定時間キャッシュし、パフォーマンスを効率化します。しかし、ゼロトラストでは「全て個別のセッションやリクエストごとに許可されるべき」とされています。さらに、「アクセス時に許可される権限は、そのアクセスに必要最小限の権限にすべき」とされています。

　セキュリティよりもパフォーマンスを優先した設計が招く、横展開によるアクセス侵害を防ぐための、極めて重要なコンセプトです。

【4】リソースへのアクセスは動的なポリシーによって決定される

　従来のネットワークアクセスの考え方では、あらかじめ決められたポリシーによってアクセス許可が決定されていました。例えばユーザーIDとパスワードの組み合わせやクライアント証明書の確認などです。

　ゼロトラストでは、さまざまな属性をパラメーター化し、都度ポリシーに従って計算を行い、アクセスを許可します。下記が要素として扱われます。

クライアントの識別としては、ユーザーアカウントや関連属性など
デバイスの状態では、インストールされているソフトウェアのバージョンやネットワークの場所、アクセス日時など
振る舞い属性として、ユーザーやデバイスの異常な振る舞いの記録の有無
環境属性として、ネットワークの場所や時間、報告されている攻撃など

　これらの状態や属性を基に、データのリスクレベルに応じて許可すべきアクセスルールを決定し、その一連のセットがポリシーとなります。これらの状態や属性は時間によって常に変化するため、データへのリクエストを行うたびに最新の状態を基にアクセスの許可を決定します。

【5】組織が保有するデバイスが、全て正しくセキュリティが保たれているように継続的に監視する

　この基本原則では、組織内に存在する全てのデバイスがセキュリティを保って正常に動作している状況を監視し、必要に応じてタイムリーなアップデートや修正の実施を求めています。これは、「どのデバイスも本質的には信頼できない」という考えに由来します。

　脆弱（ぜいじゃく）性が発見されているにもかかわらず修正が行われていないようなデバイスを、セキュリティが保たれたデバイスと同じ扱いにしません。組織に接続する個人のデバイスも含めて常に監視を行い、セキュリティを保持することが求められます。

【6】リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される

　従来のモデルでは、ユーザーにおける認証・認可は一度認証された結果の使い回しが想定されていました。再認証によるユーザーの手間の省略やパフォーマンスの向上を求めた結果です。

　しかし基本原則では、現在実行中の通信においても継続的に信頼性の再評価を行い、場合によっては再認証の実施を求めています。

【7】組織は、資産・ネットワークインフラ・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する

　この基本原則では、資産のセキュリティ状況、トラフィックの状態、アクセス要求のログなど、組織のネットワークやデバイスにまつわる情報を常に取得し、さらに分析した結果を活用したポリシーの作成やセキュリティの改善を求めています。

　これは、組織の成長やテクノロジーの進歩によって変化し続ける組織のネットワーク形態やデバイス、ユーザーの利用状況に応じて、ポリシーの作り方やセキュリティの在り方を常にアップデートし続けるという考えです。

ゼロトラストの7つの基本原則と従来の境界型防御

　これらの7つの基本原則は、実現する技術にとらわれない普遍的な書き方です。いままでのネットワークセキュリティの考え方に基づいて提供されているさまざまなセキュリティソリューションが、ゼロトラストにおいても活用が可能なのは、そのためです。

　過去のゼロトラストの議論では、「ゼロトラストは従来の境界型防御を除去する」という部分が強調されてきました。しかし境界型防御の機能は、ゼロトラストを実現する機能の一部として、「マイクロセグメンテーション」「マイクロペリメタ」の形で取り入れられています。

　重要なのは、従来の境界型防御の排除ではなく、これらの7つの基本原則が満たされた状態が理想的なゼロトラストであると定義されていることです。

　また、「Never trust, always verify.」という言葉に代表されるように、暗黙的な信頼をゼロにするために、「全て（All）」という言葉が多用されているのが分かります。

　ただし、これらはあくまで理想的な目標であって、「現実的には全てが純粋な形で完全に実装されるとは限らない」とも書かれています。

　NISTが提言したSP 800-207 Zero Trust Architectureでは、現時点で理想的なセキュリティの姿を基本原則によって定義付けました。またSP 800-207では、これらの原則を実現するアイデアやコンセプトの集まりを「ゼロトラスト」とし、ゼロトラストのコンセプトやアイデアを利用する組織のサイバーセキュリティのプランを「ゼロトラストアーキテクチャ」として説明しています。

　ゼロトラストは、境界型防御の単純な否定ではなく、テクノロジーの進化に沿ったモダンなITアーキテクチャと共存可能なセキュリティコンセプトであると、SP 800-207からは読み解けます。

NIST SP800-207(EN)バックアップ

NIST SP800-207(JP)バックアップ

「データ侵害インデックス」サイト「Cit0day[.]in」で検索する方法 / Cit0day Search Tool（転載）

Cit0day Search Tool:

After my podcast episode about the Cit0day data leaks, my colleague Jesse initiated the idea of making our own search engine. The 23,000 breached databases within this massive leak can be queried on various breach notification sites, but they all simply provided a notice of hit within the Cit0day collection. None of them identify WHICH breached database contains the exposure. We now offer a tool for this. Head over to:

https://breach.myosint.com/

Provide any email address and immediately receive notification of the specific data breach which contains the email address. I present more details on the show tomorrow.

JPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開（転載）

sugimu retweeted: 公式ブログJPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開。これまで最もご要望の多かった、リアルタイムイベントログ分析を可能にする機能を追加しました。お試しください。^YK blogs.jpcert.or.jp/ja/2020/10/log…:

sugimu retweeted:

公式ブログJPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開。これまで最もご要望の多かった、リアルタイムイベントログ分析を可能にする機能を追加しました。お試しください。^YK blogs.jpcert.or.jp/ja/2020/10/log…

ーー

JPCERT/CC では、イベントログの分析をサポートするツール「LogonTracer」の最新版バージョン1.5をリリースしました。これまでのLogonTracerは、セキュリティインシデントの事後調査という用途に特化していましたが、リリース直後からLogonTracerをリアルタイムログ分析にも活用したいという要望が多く寄せられていました。そのため、今回のアップデートでは、リアルタイムイベントログ分析を可能にする機能を追加しました。
今回は、このアップデートについて紹介します。その他のアップデート内容については下記のリリースをご覧ください。

https://github.com/JPCERTCC/LogonTracer/releases/tag/v1.5.0

Elasticsearchのサポート

LogonTracerは、Elasticsearchと連携することでリアルタイムログ分析が可能になります。
図1は、LogonTracerとElasticsearchを連携させた場合のイメージです。LogonTracerは、デフォルトではWinlogbeatを使用してElasticsearchに送信されたイベントログをインポートすることが可能です。

LogonTracerは、Elasticsearchからインポートしたログを分析し、結果をElasticsearchに保存することができます。イベントログを可視化して分析する場合、LogonTracerから確認する必要がありますが、不審なアカウントのランキングやサマライズしたログの分析結果はElasticsearchにも保存されるため、ElasticsearchやKibana上で同様の分析結果を確認することが可能です。
図2は、LogonTracerの分析結果をKibana上で表示した様子です。KibanaのWatcherなどを使用して、LogonTracerからレポートされた不審なログをアラートするように設定しておけば、リアルタイムで異常検知のサポートになります。

Elasticsearchからのログインポート

ElasticsearchからLogonTracerにログをインポートには、Web GUIから行うことができます。左下の「Load from ES」ボタン（図3の左）をクリックすると、インポート用の設定画面（図3の右）が表示されます。

Elasticsearchからインポートする際の、さらに詳細な設定（index名など）はコマンドラインから行うことができます。詳しくはLogonTracerのWikiをご覧ください。

https://github.com/JPCERTCC/LogonTracer/wiki

LogonTracerにログをインポートする際の注意

LogonTracerの分析機能の大きなポイントの1つにイベントログの可視化があります。可視化は、ログ分析の大きなサポートになりますが、大規模なログの可視化は、ログ表示の遅延や大規模なグラフを目視で分析することは難しいという問題があります。これは、LogonTracerに限らず大規模な情報を可視化するシステムには、共通する課題です。
そのため、LogonTracerに、長期間（1ヶ月や1年など）のログをインポートすることは、可視化速度の低下につながるためお勧めできません。１週間または1日（適切な期間はホスト数やユーザ数によって異なります）などの間隔で、必要なログをインポートして、分析することを推奨します。
LogonTracerを、ADイベントログの監視に使用する場合は、cronなどで定期的にイベントログを読み込んで分析し、分析結果をElasticsearchに蓄積することで、Kibana上でLogonTracerの分析結果を監視する運用を行ってください。確認が必要なログが見つかった場合、LogonTracerに対象期間のログをインポートしてログの可視化を行うことで、効率的な監視が可能になります。

登録: 投稿 (Atom)