2021年版 私のセキュリティ情報収集法を整理してみた（転載）

 私のセキュリティ情報収集法を整理してみた（2021年版）

新年あけましておめでとうございます。毎年年頭に更新している「私の情報収集法」を今年も公開します。何かの参考になれば幸いです。

インプットで参照している情報源（海外）

海外からの攻撃が主流となる中、海外情報をいち早く把握する事の重要性が増している気がしますので、今年は海外情報源から書きたいと思います。

昨年の記事では多くの海外サイトを紹介しましたが、試行錯誤の結果、まとめサイトでもある「morningstar SECURITY」や「DataBreaches.net」を押さえておけば、主要サイトが概ねカバーされると分かったので、今年は数を絞っています。

サイト	キタきつね寸評
morningstar SECURITY	去年と変わりませんが、情報の更新頻度、そして関連ソースの網羅性という意味では、英語系のセキュリティニュースとしては最良の情報ソースの１つかと思います。私は「Daily Security News」と「Security Blogs」を主にチェックしていますが、人によって興味が違うかと思いますので、「Malware/APT」「Exploits」「Vulnerabilities」といったカテゴリー別の記事をチェックする使い方も出来るかと思います。 ※私はChrome＋Google翻訳(プラグインがあります）でニュースタイトルをチェックする使い方をしていますが、短時間でタイトルを把握するのに非常に便利です
Infosecurity Magazine	こちらも去年記事で掲載しているのですが、このサイトを2番目としました。基本署名記事で記事の質は高く、引用先ソースもきちんと書かれている事が多いので、興味があるニュースを深堀りする際に重宝します。 ここでの記事は日本ではあまり取り上げられていないニュースが多く、世界的なセキュリティ業界の動きを知るべき、セキュリティコンサル（本業）にも役立っている良質な情報ソースです。 ※日曜や長期休暇中には一切情報発信がされないホワイトな（？）サイトです。
security affairs	Security Affairs/Cybaze Spa創業者、ENISA CTIグループ、Cyber Defense Magazine誌の編集長等、数々の顔を持つPierluigiPaganini氏のサイト、あるいはTwitter（@securityaffairs)はウォッチしておいて良いソースかと思います。 security affairsブログは、「Read, think, share... Security is everyone's responsibility」（読んで、考えて、共有する・・・セキュリティは全ての人の責任）というコンセプトで良質なニュースを提供し続けていますので、毎日記事を読む事で”考える癖”が身に付いた気がします。 ※個人の感想です
DataBreaches.net	実は・・・上記3サイトの閲覧で手一杯になっていて、最近はこちらのサイトをそんなに巡回してませんが、以前はこちらのサイトからの情報を元にしていくつも当ブログ記事を書いてました。 上記3サイトが最新ニュースを元にしているのに対して、こちらのサイトのまとめ方はインシデント（データ漏えい発生）ベースなので、見落としていたインシデントを知る切っ掛けになる事もあるサイトです。 ハッキング、マルウェア、データリーク、ヘルスケアといったカテゴライズもされているので、興味ある分野の情報を拾うのにも適しているかと思います。
FBI（Cyber Crime) CISA（Alearts and TIPS)	国の支援を受けたAPT攻撃等が増えている事もあり、最近巡回する様になったのが、FBIとCISAのサイトです。 ここにアラート（警戒）情報が掲載された場合、全世界的に攻撃を受ける（日本企業や組織も同じ脆弱性を突かれる）可能性があるケースも増えてきているので、アラートが出てないか確認する事もソース確認という意味では重要になってきました。 ※基本的に米国内向けの情報ですが、リリースのタイトルだけでもチェックしておくべきサイトかと思います。

※まとめサイトである「morningstar SECURITY」や「DataBreaches.net」をウォッチしない場合、良質な記事が多い「Security Boulevard」や「Bleeping Computer」、「ThreatPost」辺りも巡回先に入れると良いかと思います。

上記の情報サイト以外に、フォローしておくべきブロガー（インフルエンサー）として以下の方々も個人的には外せません。

サイト	キタきつね寸評
Krebs on Security	去年も挙げましたが、11周年を迎えたKrebs on Securityは、定期的にウォッチしているサイトの筆頭です。Krebs氏は元ワシントンポストの記者で、2016年には当時世界最大級のDDoS攻撃（最大665Gbps)をこのブログが受けた（アカマイがギブアップした）事でも有名です。 こちらのサイトには多くのセキュリティ関係者が集まる事で知られており、Krebs氏の鋭い洞察記事もさる事ながら、大きな事件記事のコメント欄を読むと勉強になり、視野が広がるかと思います。 ※上記morning star SECURITYで更新対象となっていますので、このサイトを単独でウォッチする必要はありません ※当ブログ名の「Fox on security」はKrebs氏のこのサイトにあやかってつけています。
Graham Cluley	英国を代表するセキュリティブロガーで、2009年/2010年にComputerWeekly誌によってITブログアワード（ユーザーオブザイヤー）で表彰されています。英語系のサイトでは色々な所で署名記事を見かけますし、講演活動にも積極的で、Twitter等を含め発信力がありますのでウォッチしておくべき1人だと思います。 ※Twitterアカウント（@gcluley)をフォローして、Graham氏の発信情報をチェックするのも良いかと思います。 twitter.com
Troy Hunt	マイクロソフトのオーストラリア地区ディレクターが本職ですが、本職以上に、自身のID（メールアドレス）やパスワードが漏えいしてないかチェックできる、「Have I Been Pwned」（HIBP）を運営している事で有名です。HIBPに登録されたIDは既に100億件を超えており、ここを見ると誰もがデータ漏えい事件の「被害者」である事がよく分かります。 無害化された漏えいパスワード辞書も公開してますので、会員サイト等の管理者の方は、侵害されたパスワード辞書（パスワード登録時の比較用）として利用／参考にされるのも良いかと思いおます。 Hunt氏のブログ（Twitter）で、HIBPに新しいDBが登録されたコメントが出た場合、どこかで侵害事件が発生した（往々にしてニュースになってない）事を表しますので、インシデントを追いかけられている方はウォッチしておくべき情報源の１つかと思います。 ※上の画面だと、右下（Recently added breaches）が直近追加のDB（＝インシデント）となります。
Schneier on Security	ブルーシュ・シュナイアーは暗号やセキュリティで著名な研究者です。著書も多数ありますが、特に、「セキュリティはなぜやぶられたのか」は古い本ですが、日本語にも訳されているので、セキュリティ関係の方に是非読んでもらいたい本の１つです。 ブログでの発信は、他のセキュリティ関係のソースと取り上げるニュースが被る事が多いので、必ずしもフォローが必要とは思いませんが、どうしてそのニュースを取り上げたのか、彼はどう考えているのか、そうした視点で記事を読むと新しい気づきがあるかも知れません。 ※上記morning star SECURITYで更新対象となっていますので、このサイトを単独でウォッチする必要はありません セキュリティはなぜやぶられたのか 作者:ブルース・シュナイアー 出版社/メーカー: 日経BP 発売日: 2007/02/15 メディア: 単行本

※海外情報源として英語（日本語）ソースだけで良いのか・・・と言うと、私はできていませんが、今後はダメになってくると思います。国家の支援するAPT攻撃（例えばSlarWinds事件）を考えると、攻撃をかけてくる国（母国語）の情報ソースを把握する、あるいは英語ソースと比較して差分を見ないと、その背景が見えてこなくなる気がします。

インプットで参照している情報源（国内）

国内のセキュリティ関係の情報は、コロナ禍前までは通勤途中の効率性を考えてRSS＋スマホで収集していたのですが、テレワークが主となり、PCでのチェック（主に朝）が多くなり、スマホをあまり使わなくなりました。

PCでも巡回するサイトは去年と大きくは変わらないのですが、網羅性（大きな記事の見落とし）を重視してサイトを巡回しています。

サイト	キタきつね寸評
Izumino.jp セキュリティ・トレンド	こちらも去年までと変わりません。セキュリティ関係者の方であればまずココを抑える方は多いのではないでしょうか。私も更新頻度や幅広いソース先からの情報網羅性を考え、ここを第1の国内情報源にしています。 更新頻度が高く、大きなインシデントが発生した際は「他の情報が押し流される」事も多々ありますので、時間が無い方や、情報収集に慣れてない方はタイトルを流し見する癖をつける事をお勧めします。
Security Next	情報更新頻度もさる事ながら、そして小さなインシデントやセキュリティ関係の調査結果もよく掲載されているので、「新着記事」は定期的な巡回先となっています。 セキュリティ関係の全般的なニュースだけではなく、脆弱性や製品・サービス等のカテゴライズもされているので、自分の興味が強い所を巡回先にすると効率的な情報収集が実現できるかと思います。 ※”誤送信しました”や、”USBメモリ落としました”クラスの発表まで丹念に拾っているのはこのサイト位かと思います。
piyokango氏のTwitter	Piyologも大きなインシデントが発生した際に、状況確認するのに重宝する情報ソースですが、piyokango氏の真骨頂はやはりTwitterでの情報発信かと思います。 多忙そうな時期は情報発信がやや低調に見える事もありますが、インシデント公式発表は他の方に比べて発信が速い事が多く、セキュリティ関係の方であれば、抑えておくべき情報ソースの１つと言えます。 各種セミナー以外にも、Podcastで辻さん、根岸さんらと配信している#セキュリティのアレや、日経XTECHで連載しているpiyokangoの週刊システムトラブル等も勉強になる事が多いです。
日経クロステック（xTECH)	大きな国内インシデントが発生した際の解説記事が参考になる事が多いのがこちらです。2020年はPulse Secure VPNの脆弱性や、ドコモ口座など社会的に影響が大きな報道記事がいくつもあり、取材情報を元にした署名記事（事件分析）は読んでいて勉強になりました。
UCカード（重要なお知らせ）	私はカード情報のセキュリティ（PCI DSS）が専門分野の１つであり、この分野のインシデントを長年追いかけているので、大手カード会社の中でもセゾン系のカード情報漏えいに関するリリースは情報発信が早く、網羅率も高いので極力毎日見る様にしています。
ScanNetSecurity	網羅性という意味ではこちらも外せないかも知れません。カード情報関係のインシデントも良く出ているので、チェック漏れが無いかをたまにチェックしています。また、事件のリリース魚拓も掲載されているので、過去のインシデントを調査する際などにも重宝しています。

※上記の情報ソースで国内セキュリティ関係（全般）の主要記事は網羅されると思いますが、新聞各社の最新記事の情報を見落とす事もあるので、最近は意識して日経新聞、朝日新聞、毎日新聞のWebサイトを流し見（※スクープ記事が無いか）する様にしています。

インプットに使っているツール

2020年はRSS ReaderやGoogleアラート等をご紹介していましたが、テレワークが主となり、PCの前で作業する事が多くなったので、スマホでの情報収集が、休憩時間や偶にある外出時間程度と、その比率が以前より大幅に下がりました。その中で現在使っているツールは以下の通りです。

サイト	キタきつね寸評
Yahoo!ニュース  (iOS)	Yahoo!ニュースのテーマ設定でRSS的にニュースを拾っています。多いなニュースで、コメント欄が解放されている時は、客観性をつけるために、なるべくオーサーや読者コメントを流し見する様にしています。 ※コロナ禍で生の情報（人との会話）が希薄になり、真偽の分からない情報に流されやすくなってきている気がしており、自分の意見（コア）を持った上で、多くの意見に触れる事の重要性が増している気がしています。 尚、現在フォロー中のテーマは以下の通りです。
Twitter	Twitterは情報が早い（鮮度が良い）ので、多くの方にとっての情報収集は、「良質な情報発信をする方」をフォロー出来ていれば十分かと思います。 ※ご参考になるかは分かりませんが（キタきつねのTwitterフォロワー） ※私の場合、Twitter＝スマホなので、テレワーク（PC）メインになっている中では、あまり効果的に情報収集に使えていない気がしますが、特に海外インフルエンサーの投稿は（日本でまだ情報が来てない事も多いので）意図的に読む様にしています。
TweetDeck	上記でTwitterをあまり活用できていないと書いているので、矛盾があるのですが、以前名和さんに教えて頂いたツールで、リアルタイムに情報を拾うのに、大画面＋TweetDeck（キーワード登録）は非常に有効です。 ※例えばDDoSをキーワード登録し、頻繁にTabが更新される＝何か大きな事件があった兆候を掴むといった使い方も（フォロワー次第ですが）出来る様です。 ※TweetDeck流し見専用にサブモニターが（もう1台）欲しくなります

調査によく使っている便利ツール

最後は、私が昨年よくお世話になった便利なツール類です。

サイト	キタきつね寸評
Wayback Machine	サイト情報を過去に遡るという事を（無料で）実現できます。 この巨大な魚拓サイトは、インシデント調査、あるいは事件リリース等を追いかける際に非常に重宝していて、このサイトが無いとカード情報漏えい系のインシデント分析は出来ないといっても過言ではありません。
SHODAN	諸々の脆弱性を検索するこうしたサービス、あるいは同等機能を持つサービスをハッカー側は常時探しており、そこで見つけた脆弱性を攻撃してくる傾向が強くなってきています。だからこそ、ホワイト（防衛）側も、こうしたツールを有効に使って自社／自組織の脆弱性を”定期的に”チェックする事が重要かと思います。
DeepL	海外サイトからの情報収集を行う上で、Google翻訳は無償である事を含めて素晴らしいものがありますが、翻訳の精度（※以前に比べて格段に上がっています）という点では、アレ・・・と思う事も多々あります。 尚、DeepL有償版ではなく、多少制約はありますが無償版だけでも海外ニュースソースからの情報を翻訳するのは十分かと思います。 私は本業で海外と方とやり取りをする事がありますが、海外業務を担当する日本人の多くがDeepLを使っている印象があります。（他社の方と話すと、このツールを使っている方が結構多いです）Google翻訳の方がまだまだ便利な部分も多いのですが、ここぞという部分の翻訳にDeepLを使う事で、より読みやすい日本語文書になりますのでオススメです。 ※少し英語に自信が無い方は、海外出張（あるいは海外ゲストの簡単な通訳）程度でしたらPOCKETTALKも最近は精度が上がっていますので、こうしたツールでも十分かと思います。
ウェブ魚拓	WaybackMachineが勝手に録画してくれる全録機だとすれば、ウェブ魚拓は手動録画（魚拓）として使えるサイトです。Piyokango氏がよく使っている（いた）ので私も真似をして使う様になりました。 インシデント、特にECサイトからのカード情報漏えい事件では公式発表（事件を受けてのリリース）がいつの間にか「消されている」事があります。 ※企業の情報開示姿勢としてはどうかと思いますが、ビジネスへの影響を考えると仕方が無い事かと思います。 こうしたサイトを後から調査する事もあるので、当ブログの記事では、インシデントの公式発表魚拓をなるべく取っておく様に（最近は）しています。
ATT&CK	色々とインシデントを追いかける中、まだまだ出来てない部分が多いのですが、ATT&CKをもっと深く理解する事＝基本に立ち返る事の重要性を改めて感じています。
Qualys SSL Server Test	日本ではこうしたツールを事前の合意なしにかける事がアレ内緒で調査する時もありま・・・ですが、海外ではホワイトハッカーもよくこうしたツールを使っている様です。 残念ながら、（このサイトで検出される通信に関する）セキュリティ対策が酷い所は、まだまだ日本の企業／組織でも多いので、Web脆弱性診断を定期的に行ってない所は、最低限こうしたツールを利用して自社の脆弱性を確認する事が重要かと思います。 ※違う見方をすればお金をかけなくてもある程度の事はこうしたツールを使えば確認できるという事でもあるのですが、なかなか日本では利用されてない（様に思える）のが残念な所です。
No more ransom Project（日本語）	2020年はランサム（2重脅迫）の年といっても過言では無い程に、ランサム被害が多発しました。 カスペルスキーが4年前に発足させたNo more ransom projectでは一部ランサムにはなりますが、解除方法なども開示しており、ランサム関連の情報として、まず抑えておくべき情報がここにあります。 ※ランサム被害を受けた企業は、短時間に身代金（ランサム）を請求される事が多く、パニックになる訳ですが、こうしたサイトでまずは何をすべきなのかを一度落ち着いてみてから次の行動を起こす事が重要であり、押さえておくべきサイトの１つと言えます。

偉大な先人達へ敬意を表して・・・

当ブログでは、この記事を書くのも今年で4回目になります。「情報収集法」という考え方は、私のオリジナル記事という訳ではなく、日本のセキュリティ業界をリードしていると言っても過言では無い、根岸さんとPiyokangoさんが以前に書いている記事に触発されて書き始めたものです。

セキュリティ業界という訳ではありませんが、喜多さんの下記の本は、私のバイブル的な存在です。万人にお勧めできる情報収集法／情報整理法ではありませんが、（セキュリティの世界で）プロの方やプロを目指される方には、その価値が分かるのではないかと思います。

サイバー攻撃に対抗するには多様な視点やコラボレーションが重要--英サイバー防衛担当幹部 / What's the key to tackling cyberattacks? Building a diverse team to think smarter（転載）

サイバー攻撃に対抗するには多様な視点やコラボレーションが重要--英サイバー防衛担当幹部:

　サイバーセキュリティチームが企業や政府、その他の組織や人々をサイバー攻撃から守るためには多様な考え方が必要だ。そして、サイバー犯罪との戦いで、異なる視点を持つ人々が協力できるようにするには、コラボレーションが重要になる。

　英内閣府のサイバー防衛担当副ディレクターPete Cooper氏は、困難に立ち向かい、社会のサイバーリスクを減らすためには、この種の協力を重んじる姿勢が必要になると語った。

　英空軍のジェット機パイロットからサイバー作戦アドバイザーに転身したCooper氏は、英国で初めて分野横断的なサイバー戦略コンテストを創設した人物でもある。同氏は、国際的なサイバーセキュリティの問題に取り組むためには優れたコラボレーションと多様性が重要だと考えている。

　Cooper氏は、「Black Hat Europe 2020」の基調講演で、「私たちは、自分たち課題について多様な視点を持っており、それぞれが違った視野を持っている。コラボレーションの本当の価値は、世界を多様な視点から見ることにある」と述べた。

　「それによって共通の視点を生み出すことができ、共同で視野を広げることでさらに遠くまで見渡せるようになると同時に、あらゆることに対して共通の理解を深めていくことができる」

　同氏は、異なる視点を混在させることで、リソースの使い方や取れるアクションが大きく変わる可能性があると説明した。さらに既知のシナリオや、これまでは知られていなかったシナリオへの新しい対処法さえ見つかるかもしれないという。

　「そのことがほかにはないコラボレーションを生み出し、これまでは見えなかった障害や、チャンスや、アイデアを見つけることができるだろう。それがコラボレーションを行う本当の意味だ」とCooper氏は語った。

　「多様なチーム間でのコラボレーションで最善のソリューションはこれらの共同でのソリューションであり、それを実行するにはそのようなコラボレーションが必要になる」

　サイバー攻撃やデータ侵害の防止やそれらのインシデントへの対応はサイバーセキュリティの重要な要素だが、それは仕事のごく一部にすぎない。業界の文化や、組織内の情報セキュリティチームの文化にもそのことを反映させる必要がある。

　「インシデントは全体の一部が見えているにすぎない。水面下の状況を見て何が問題かを理解したり、発生した事象が何を意味しており、それらを把握するためにはどんなアイデアがあり得るかを理解するには、積極的で優れた文化が必要だ」とCooper氏は説明した。

　また同氏は、異なる視点を持ち寄るには時間と手間がかかるが、サイバーセキュリティが達成しようとしているあらゆることに対して、コラボレーションと多様性は役に立つと指摘した。

　「それができれば、私たちは共通の視点を共有し、視野を広げるようになる」

　「協力し合って共通の視野から多くのことを学ぶほど、今後重要なリスクに取り組もうとする際に、誰にとってもよりよい結果になる」と同氏は付け加えた。

2020年のクラウドネイティブの脅威 / Cloud-Native Threats in 2020（転載）～クラウドサービス（オンラインストレージ）を悪用した脅威が増加か！？～

Cloud-Native Threats in 2020:

2020年に私が行った様々なことの中で、キルチェーンの中でクラウドサービスを悪用した主なサイバー攻撃を集めたものがあります。私は公開されている情報を使って、個人的な（明らかに不完全な）リストを構築しました。完全な年表は記事の最後に掲載していますが、いくつかの統計は以下のチャートにまとめています...

クラウドサービスは、信頼性が高く回復力のあるホスティングインフラストラクチャを提供し、従来のセキュリティ管理を迂回することができ、最後に、ユーザーから暗黙のうちに信頼されているため、脅威行為者に悪用されるケースが増えています。これは、GuLoaderやBazaarLoader（最近の壊滅的な攻撃の波でRyukランサムウェアを配信するために配備された）のようなドロッパーの採用が増えていることを説明しています。

前述したように、これはクラウドネイティブの脅威の状況を部分的に示しているに過ぎませんが、いずれにしても、悪意のある目的でクラウドサービスを悪用することがどれだけ頻繁になっているかを示す有用な指標になることを期待しています。

国土交通省北海道開発局の癒し系ツイート（転載）

 「国道40号ばばばばばえおうぃおい～」　国交省北海道の謎ツイート、原因は「サーバ更新時のエラー」

　「国道40号ばばばばばえおうぃおい～べべべべべべべべべえべえええべえべべべえ（9.9km）で通行止を実施しています」――道路情報を伝える国土交通省北海道開発局のTwitterアカウントが1月19日、このような謎のツイートを投稿し、Twitter上で話題を呼んでいる。同局によれば、サーバ更新作業中のエラーが原因だという。

　同アカウントは、通行止め情報をまとめているWebサイト「北海道地区道路情報」の更新に合わせて自動で情報を発信している。話題のツイートは19日午後3時ごろに自動投稿された。実際にはツイートに記載されていた国道40号の通行止めは行われておらず、同アカウントは後にツイートを削除。午後5時ごろには誤作動があったとしてアカウントを一時停止した。

　投稿直後から、Twitterでは「面白い」「癒やされた」と話題になり、ツイートを読み上げた動画やオリジナル曲が作られるなどネット特有の盛り上がりを見せた。一方「文章を変換すると『こちらにこい』になる」など、内容について考察するユーザーもいる。

　謎のツイートが投稿された理由について、国土交通省北海道開発局は「北海道地区道路情報のWebサイトを管理しているサーバの更新作業中にエラーが発生し、通常なら表に出ないテスト用のデータがツイートされた。内容に意味はない」と説明した。外部から不正アクセスや攻撃を受けた痕跡はないとしている。

　同局はサーバを点検し、午後7時ごろにツイートを再開。「ご迷惑をおかけして申し訳ありませんでした」と謝罪した。

SolarWinds事件(SunBurst)のフォレンジック調査（転載）～自社だけでセキュリティ対策を頑張っても、オンラインでくるアップデートモジュールが汚染されてしまうと手も足も出ない。。。～

SolarWinds事件(SunBurst)のフォレンジック調査
 

エグゼクティブサマリー

• Orion ソフトウェアのビルドとコード署名のインフラストラクチャが侵害されたことの決定的な詳細を示しています。
• Orion のソースコードが悪意のあるバックドアを含むように直接変更されたことを確認するコンパイル結果を開示しています。
• バックドアされたOrionのソフトウェアパッチが、既存のソフトウェアリリース管理システムを介して配信されたことを確認する、ソフトウェア配信の成果物を開示しています。
• 将来のソフトウェアサプライチェーン攻撃を検出して防止するための新しいアプローチを提案しています。

概要

IT監視・管理ソリューションを製造するSolarWinds社が、巧妙なサプライチェーン攻撃の最新の標的となっています。2020年3月から6月にかけてリリースされた複数のSolarWinds Orionソフトウェアアップデートには、攻撃者が影響を受けたシステムに対して監視や任意のコマンドの実行を可能にするバックドアコードが含まれていることが判明しています。

ReversingLabsのこのサプライチェーン攻撃の解剖調査により、Orionソフトウェアのビルドおよびコード署名インフラストラクチャが侵害されていることを示す決定的な詳細が明らかになりました。影響を受けたライブラリのソースコードは、悪意のあるバックドアコードを含むように直接変更され、既存のソフトウェアパッチリリース管理システムを通じてコンパイル、署名、配信されました。

ソフトウェアのサプライチェーンに対するこの種の攻撃は決して目新しいものではありませんが、今回と異なるのは、可能な限り長く検出されないようにするために攻撃者が使用したステルスのレベルです。攻撃者は、影響を受けたコードベースに溶け込み、ソフトウェア開発者のコーディングスタイルや命名基準を模倣しました。これは、Orion ソフトウェアを使用するあらゆる組織のバックドアにするために追加されたかなりの数の機能によって一貫して実証されました。

ソフトウェア開発者からの隠蔽

事件の外部からストーリーをまとめることは困難です。しかし、残されたパンくずの痕跡から、攻撃者が Orion ソフトウェアのリリースプロセスを侵害するために使用した方法について、ある程度の洞察を得るには十分です。

このような調査は通常、既知のものから始めます。この場合、バックドアードされたソフトウェアライブラリのリストです。OrionプラットフォームソフトウェアパッケージのアップデートSolarWinds-Core-v2019.4.5220-Hotfix5.msp内のSolarWinds.Orion.Core.BusinessLayer.dllというファイルが、悪意のあるバックドアコードを含むことが知られている最初のバージョンです。このライブラリは、FireEyeの技術ブログで徹底的に分析されており、バックドアの動作について非常によく説明されています。

しかし、メタデータの分析から、攻撃者の忍耐力、巧妙さ、Orion ソフトウェアビルドシステムの状態について、さらなる結論を導き出すことができます。

FireEyeブログで概説されているように、悪意のあるバックドアコードを含む最初のバージョンは2019.4.5200.9083でしたが、攻撃者によって改ざんされた以前のバージョンがありました：2019年10月のバージョン2019.4.5200.8890で、このバージョンはわずかに修正されただけでした。悪意のあるバックドアコードは含まれていませんが、将来的にそれをホストする.NETクラスが含まれています。

この最初のコード修正は、明らかにコンセプトの証明に過ぎませんでした。彼らの三段階の行動計画 ビルドシステムを破壊し、独自のコードを注入し、署名されたパッケージが期待通りにクライアント側に表示されることを確認する。これらの目的が達成され、サプライチェーンが侵害される可能性があることが攻撃者自身に証明されると、攻撃者は実際の攻撃ペイロードの計画を開始しました。

クラスの名前である OrionImprovementBusinessLayer は、意図的に選ばれたものです。残りのコードに紛れ込むためだけでなく、ソフトウェア開発者やバイナリを監査する人を騙すためです。このクラスと、それが使用するメソッドの多くは、他のOrionソフトウェアライブラリにも含まれており、それらのライブラリ内のコードとテーマ的に一致していることさえあります。これは、ステルス性を保つ意図だけでなく、攻撃者がコードベースに精通していたことを暗示しています。

例えば、UserID を計算する関数を比較してみてください。Orion Client のコードでは、この関数はレジストリから以前に計算された値を読み込もうとしたり、ユーザの新しい GUID を作成したりします。

これを模倣して、攻撃者はこれらの関数の独自の実装を作成してUserIDも計算し、同じように名前を付けました。彼らの関数は、後に ID 型に同じ GUID 形式を使用していることさえあります。

正確ではありませんが、このコードはオリジナルと同じような機能を果たしています。クラス、メンバー、変数を適切に命名するパターンは、バックドアされたコードの至る所に見られます。

実際に、Orionクライアントライブラリのコードで使用されるCollectSystemDescriptionとUploadSystemDescriptionというメソッドがあります。IOrionImprovementBusinessLayer インターフェースがあったように、攻撃者はバックドアコードを配置したクラスの名前を模倣しました。

しかし、ライブラリに追加されたコードは、魔法のようにそれ自体が実行されるわけではありません。攻撃者は何らかの方法でそれを呼び出す必要があります。そして、それが行われた方法は、ビルドシステム自体が危険にさらされたことを物語っています。

赤くハイライトされたコードは、攻撃者が入れた追加機能です。この小さなコードブロックは、Orion ソフトウェアがバックグラウンドのインベントリチェックを実行している間に、バックドアを実行する新しいスレッドを作成します。このような場所は、この種のコードを追加するのに最適な場所です。つまり、攻撃者が注入した残りのコードと同様に、このコードも溶け込んでしまうのです。

.NET コードを逆コンパイルして新しいものを注入し、その後にコードを再コンパイルする方法もありますが、今回はそうではありませんでした。InventoryManagerクラスはソースコードレベルで修正され、最終的には通常のOrionソフトウェアのビルドシステムでビルドされました。

これは、バックドアされたバイナリのタイムスタンプ、同じパッケージ内の他のライブラリ、およびそれらを配信するパッチファイルを見ることで確認できます。

PE ファイルヘッダと CodeViews のタイムスタンプは完全に一致しています。これは、リビジョン番号が 1 に設定されているということは、 そのファイルが一度だけコンパイルされたか、あるいはクリーンビルドされたかを意味します。ファイルは署名され、タイムスタンプのために交差署名されているので、ヘッダ内のタイムスタンプを確実に検証することができます。クロスサインのタイムスタンプは、ビルド環境の外にあるリモートサーバによって制御され、改ざんされることはありません。

署名はライブラリのコンパイルから1分以内に発生しています。これでは、攻撃者がビルドシステムを監視し、バイナリを置き換え、これに完全に一致するようにメタデータを変更することができる時間がありません。これらのタイムスタンプを完全に一致させる最も簡単な方法は、攻撃者のコードをソースに直接注入し、既存のビルドシステムと署名システムに、Orionソフトウェア開発者によって定義されたコンパイルとリリースのプロセスを実行させることです。

最後に、MSP のパッチファイルには CAB アーカイブが含まれており、ライブラリのローカルの最終更新時刻を保持しています。これは、ビルドシステムがGMT+1タイムゾーンで動作していると仮定して、署名中にファイルが最終更新されたことを確認するものです。

同じ名前空間に属するバックドアされたライブラリの周囲のファイルも同時にコンパイルされています。これらのファイルは互いに依存していないので、ビルドシステムが完全なビルドを実行していない限り、同時にビルドされることはありません。

MSP のパッチファイルは署名されており、その署名時間はパッケージの内容と一致しているので、パッチファイルが残りのビルドと同じマシン上で作成されたことを確認できます。

大きな疑問は、ソースコントロールが侵害されたのか、攻撃者のコードがビルドマシンに置かれただけなのかということです。

残念ながら、それはメタデータでは明らかにできません。ソフトウェアのコンパイル中に保存されるような成果物はありません。しかし、攻撃者はコードがコードベースの中にあるように見えるようにするために、多くのトラブルを経験しました。これは確かに、ソフトウェア開発者による監査からコードを隠すために行われました。

確実なのは、ビルドインフラが侵害されたということです。さらに、デジタル署名システムは、信頼できないコードに署名することを余儀なくされた。現時点では、SolarWindsの証明書が他の悪意のあるコードの署名に使用されたという証拠はありませんが、その可能性は排除されるべきではありません。そして、予防措置として、そのビルドシステムで使用されたすべての証明書と鍵を失効させる必要があります。

セキュリティアナリストに隠れて

このような環境でオリオンのソフトウェアを実行している顧客のタイプを考えてみましょう。このようなソフトウェアのサプライチェーン攻撃を成功させるためには、攻撃者はレーダーを潜り抜け、何百万ドルものセキュリティ投資を回避する必要があります。攻撃者は、高度に専門化された検出ソフトウェアと、脅威を検出するためにそれを実行している人々を騙して、数ヶ月間、このソフトウェアを使用して積極的に異常を探し出す必要があります。このトリックを成功させるためには、攻撃者は隠れたままでいることと目的を達成することの間で適切なバランスを取る必要があります。

大規模なセキュリティ予算には、かなり多くの特典が付いています。内部脅威の調査ができることは、確かにその1つです。そして、脅威ハンターがデータの異常ほど探したがるものはありません。YARAルールは、ただ横たわっている奇妙なものを見つけるための一つの方法に過ぎない。

文字列 "Select * From Win32_SystemDriver "は、おそらくかなりの数の中に見られる。そのため、攻撃者は圧縮とBase64エンコーディングを組み合わせて、このようなノイズの多い文字列をすべて隠すことにしたのです。前述の文字列のBase64変種を探すハンティングルールがかなりの数存在するため、このような2段階のアプローチが必要でした。

これらのステップを逆にすることで、上で見つかったC07NSU0uUdBScCvKz1UIz8wzNooPriwuSc11KcosSy0CAA==は "Select * From Win32_SystemDriver "になります。そして、すべての脅威狩りのルールは、賢くないままです。

このような文字列難読化はコード全体で繰り返されます。これが、ソフトウェア開発者のレビューで目立つことと、セキュリティシステムを騙すことの間のバランスであり、攻撃者にとっては、この賭けが実を結んだことになります。

サプライチェーン攻撃の防止

ソフトウェアのサプライチェーンの安全性確保に重点を置いているセキュリティ企業はほとんどありません。ほとんどのセキュリティ企業にとって、この種の攻撃がもたらすリスクを減らすことについて話すことは、遠い未来の話です。多くの点で、私たちはまだ問題意識の段階にあります。このような事件は、ソフトウェアを出荷する側と消費する側にも同様に影響を与える多面的な問題であることに注意を喚起するのに役立ちます。

ReversingLabs の研究開発チームは、このような大きな問題が広く懸念される前に考えることに誇りを持っています。そのために、私たちはこのような問題に対処するための製品やソリューションのプロトタイプを数多く作ってきました。

ソフトウェアのサプライチェーンの保護は、解決が待たれている大きな問題です。そして社内では、開発者とユーザーの双方を保護するための製品戦略を定義しました。

私たちは、「ゴールド」ソフトウェアのリリースイメージをリリースや消費の前にスキャンできるシステムを想定しています。このシステムは、ソフトウェアの改ざん、デジタル署名、およびビルド品質の問題を探すために意図的に構築されています。このシステムは、継続的なソフトウェア開発とリリースサイクルに組み込まれており、これらの問題を表面化させ、それらを排除するためのガイダンスを提供することを目的としています。

このようなシステムの重要な側面の1つは、コンパイルされたソフトウェアのバージョン間の動作の違いをピンポイントで特定する能力です。静的挙動指標と呼ばれるこの記述は、基本となるコードの動作を、それを実行するマシンに与える可能性のある影響に変換します。

追加された（緑）コードと削除された（赤）コードの違いとしてレイアウトすると、ソフトウェアの動作の変化の影響が明らかになります。バックドアされたSolarWindsバイナリでは、これにより、このサプライチェーン攻撃をより早くキャッチすることが可能になったであろう多くのセキュリティアラームが発生します。

以下のリストでは、最初に改ざんされたバージョンと、悪意のあるバックドアコードを含むバージョンとの間の重要な静的コードの動作の変化を強調しています。

1. 1つ以上の実行中のプロセスに関する情報を読み取る

アプリケーションが突然、環境で実行中の他のプロセスを認識するようになることは、非常に珍しいことです。成熟したコードベースでは、この機能は通常メジャーリリースで追加されます。通常、この種のコードの背後には大きな機能が計画されています。そして、通常、追加するにはそれなりの理由があります: ある種のプロセス間通信や、実行中のプロセスを制御したいという願望です。他のシナリオでは、このような無計画な追加は懸念の原因となります。

2. MD5/SHA1 アルゴリズムの .NET Framework クラスへの参照が含まれています。

珍しいものではありませんが、MD5 や SHA1 のようなハッシュ化アルゴリズムは、特定の問題を解決するために実装されるのが一般的です。それは、ある種のコンテンツの検証、認証、または一意性のチェックのいずれかです。これらのそれぞれは通常、高レベルの要件にマッピングされ、機能変更のリクエストや同様の開発タスクまで追跡することができます。

3. kernel32.dll / advapi32.dllネイティブWindows APIへの参照が含まれています。

.NET ライブラリから突然 Windows ネイティブ API を参照するというのは非常に珍しいことです。システムと相互作用する基礎となるコードは、管理されたアプリケーションであっても必要ですが、より良い方法があります。例えば、提供されている言語ランタイムは、ほとんどの開発者がネイティブ関数に求めるものと同じ効果を、型の不確実性に対処することなく、一般的に達成することができます。サプライチェーン攻撃のコンテキストに関係なく、これ自体が開発者がコードの匂いと呼んでいるものです。

4. WMIを使用してシステム情報を列挙する

Windows Management Instrumentation (WMI) は、アプリケーションがローカルおよびリモートコンピュータシステムの状態に関する情報を取得することを可能にするシステム機能のセットです。IT管理者は、これらの機能を使用してコンピュータシステムをリモートで管理しています。なぜこのような機能が突然追加されるのかを理解することは非常に重要です。アプリケーションの範囲が劇的に変化して、リモート・コンピュータ・システム間の相互作用がその重要なタスクの一部になったということは考えられません。そして、ローカルシステムから何かを取得することが目的であれば、すでにその情報を持つコードがあるかもしれません。

5. ユーザー/アカウントの権限を列挙しています。

ユーザーやアカウントの権限を調べることは、通常、権限を昇格させるための最初のステップです。上昇した権限でコードを実行するのは、制限されたフォルダにファイルをコピーしたり、実行中のプロセスを操作したり、システムの設定を変更したりなど、限定されたアクションを実行するために行われます。これらのアクションはすべて、その背後にしっかりとした理由がなければならないものであり、成熟したコードベースに追加することは、少なくとも疑問の余地があります。開発者は、この種のことを認識し、サインオフしなければなりません。

6. システムのシャットダウンを妨害する

アプリケーションの不必要な特権というテーマに固執して、最後に大きな赤旗を掲げています。コンピュータをシャットダウンしたり再起動したりすることは、予期せずコードに追加されたものではありません。これは、複数のコードコンポーネント間の調整を必要とする機能であり、通常はアプリケーション内の単一の場所で実装されます。それが他の場所に現れることは、間違いなく懸念の原因となります。

ソフトウェアの展開プロセスのどの側にいるかに関わらず、ソフトウェアコードの変更の影響に関するレポートは、非常に貴重な情報です。ソフトウェア開発者にとっては、基礎となるコードの動作についての情報に基づいた意思決定を行うことができます。また、ソフトウェアの消費者にとっては、異常なコードの追加を確実に検出することができます。いずれにしても、このようなシステムの影響は、ソフトウェアのデプロイメントプロセスに大きな変化をもたらします。このようなソフトウェアサプライチェーン攻撃が再発しにくくなる検証バリアとしての役割を果たします。

新しい制御機構の必要性

SUNBURSTは、アクセス、洗練された技術、忍耐力を武器とした次世代の危殆化対策を紹介しています。貴重なビジネスを運営している企業や、顧客にとって重要なソフトウェアを製造している企業にとって、ソフトウェアを検査し、改ざんの兆候がないか、悪意のあるものや不要なものが追加されていないか、アップデートを監視することは、リスク管理プロセスの一部でなければなりません。この種の改ざんは、従来のセキュリティソフトウェアスタックで信頼されているソフトウェアディストリビューションを悪用するもので、既知の悪意のあるインプラントと比較しても特異なものです。ディストリビューションは、たとえ境界制御によっても、容易に検査することはできませんでした。世界的に知られたソフトウェアブランドや、信頼されたビジネスクリティカルなプロセスの背後に隠れていることで、フィッシング・キャンペーンでは夢のようなアクセスが可能になります。

NIST CSFなどのサイバーセキュリティフレームワークの多くは、継続的なリスク管理とデータとソフトウェアの検査の必要性を文書化しています。これには、社内外を問わず、すべてのサードパーティ製およびオープンソースのソフトウェアを継続的に検査し、改ざん、悪意のあるコンテンツ、または組織の許容ポリシーに抵触する望ましくない特性がないかどうかを確認する必要性も含まれています。

英AnyVan、410万人分のユーザー情報が漏洩し、ダークウェブに晒される。 / AnyVan 4.1 Million Users Comprised with Data-Breach（転載）

AnyVan 4.1 Million Users Comprised with Data-Breach:

AnyVanは、ロンドンのハマースミス（英国）に本社を置く、輸送パートナーのチェーンネットワークから委託、輸送、撤去サービスにアクセスするためのヨーロッパのオンラインプラットフォームです。それはヨーロッパの移動のみに焦点を当てています。また、パトロンの配送経路と輸送サービスプロバイダーの配送経路を簡単に比較し、それらを関連付けることで、保管スペースや運搬量を最適化することでコストを削減し、CO2排出量を削減することができるため、引越しサービスの面ではヨーロッパのフロントランナーの一つとなっています。しかし、最近AnyVanは、不正なデータ侵入とハッカーによるパトロンの個人情報の横領について、そのユーザーを肯定した。

同社は、同社が被害者となったデータ漏洩に関する通知をパトロンに送付することで、パトロンに通知したという。AnyVanはその後、2020年12月31日にこの事件を発見したことを明らかにしており、その理由についても "なぜこんなに遅くに通知されているのか？"と言及しています。

AnyVanは、上記の事件について、「このデータ漏洩が当社の注意を引いたのは12月31日でしたが、事件自体は9月末に発生したと理解しています。事件が発生してからすぐに、当社の専門ITチームが調査し、以下の改善措置を講じました。

同社が発表した通知と声明によると、パトロンの名前、電子メール、パスワードの暗号ハッシュがアクセスされ、おそらく役者によってダークウェブ上に表示されたという。どうやら、他の機密情報は侵害されていないようだ。さらに、彼らは事件の調査が続いていることを追加しました。しかし、これはすべて、アクターがユーザーのデータや情報を悪用するのに十分な時間を持っていた後にのみ来た。推定では約410万人のユーザーがこのデータ侵害の影響を受けているという。AnyVanはICO (Information Commissioner's Office)に連絡しなかったが、これはユーザーの機密データが漏洩したことを示す重要な一歩であった。

予防策として、同社は利用者に対し、AnyVanで使用するアカウントのパスワードやその他の個人情報を更新するよう助言した。また、同社は、利用者が知らず知らずのうちに他の情報や個人情報を誰かと共有しないように注意を促した。また、同社は、ユーザーが被った個人情報のこのデータ侵害について謝罪し、彼らは非常に迷惑をかけて申し訳ありませんと述べた。

クラウドを利用する際の設定ミスにより第三者に迷惑をかける場合（転載）～PayPay、楽天、Salesforce、etc～

クラウドを利用する際の設定ミスにより第三者に迷惑をかける場合:

クラウドサービス等を利用する際にも当然に、誰が、何に対してどういうアクションができるのか？という設定が必要となってきます。アクセス方針について適切に決めていたとしても、設定を誤ると期待した効果が生じません。なので、適切に設定されていることは、クラウドサービスを利用する際にユーザが当然に確認すべき事項となります。この設定ミスにより第三者に迷惑をかけた場合は、ユーザの責任となるでしょうね。。。

ただ、設定が非常に複雑であったり、システムの理解が浅い利用者を想定している場合は、それ相応の対応（つまり、想定利用者の能力に応じて簡単に安全な設定ができるようにする機能や、説明ページ、場合によっては担当営業やカスタマーセンターによる対応）等を準備することはサービス提供者には必要となるでしょうね。。。この辺りの法律的な話は弁護士等の法律家の方がうまく説明してくれると助かりますね。。。

と、色々と最近の事件をみて思いました・・・

● PayPay

・2020.12.07 当社管理サーバーのアクセス履歴について

● 楽天

・2020.12.25 クラウド型営業管理システムへの社外の第三者によるアクセスについて

● Salesforce

・2020.12.25 【お知らせ】当社一部製品をご利用のお客様におけるゲストユーザに対する共有に関する設定について

・2021.03.19 SMBC日興証券・信託銀行、個人情報約12万件が閲覧可能な状態に　Salesforce製品に設定ミス　一部で流出も

【バックアップ】

当社管理サーバーのアクセス履歴について（PayPay）

クラウド型営業管理システムへの社外の第三者によるアクセスについて(楽天)

【お知らせ】当社一部製品をご利用のお客様におけるゲストユーザに対する共有に関する設定について(Salesforce)

PCでディスプレイの揺らぎが気になる際の対処法～Chromeのハードウェアアクセラレーションが原因か？～

12月に新たにパソコンを購入したのだが、 どうも調子がおかしい。

事象的にパターン化できないのが心苦しいところなのだが、分かっている範囲で整理すると、

・ディスプレイでリサイズしている感じの歪みが発生

・たまーにディスプレイが真っ暗になり、30秒くらいすると復帰

・上記の事象はバッテリーモードで使用中に発生

・Chromeを使用中に発生

上記のような感じである。

新しいPCだし、放っておけば直るかとも思ったのだが、たまーに発生するディスプレイが30秒真っ暗になる事象は、たまーにでも不安を掻き立てられ、メーカーサポートに問い合わせてみた。

その際の対処法が下記。

----------------------

【1】Windows を完全にシャットダウンし、放電を行います。

【2】BIOS 設定値の初期化を行います。

【3】Windows Update にて最新の状態にする。

【4】グラフィックスドライバーを更新する。

【5】Google Chrome の設定を変更する。
　　　→ハードウェアアクセラレーションの無効化

--------------------------------------------------

5番目に気になる方法があり、まずは5番からやってみることにした。

というか、PC自体は購入後1か月も経っていないのと、事象から察するにChromeのアクセラレーションが一番の原因の気がする。。。

とりあえずChromeのアクセラレーションを無効化して様子を見てみよう。

むかしDELLのパソコンを使っていたが、サポートに電話すると二言目には「OS再インストールしてください」と言われ、閉口したことがある。

VAIOのサポートはとても親身な気がする。

Google ChromeでURLバーにドメインしか表示されない問題を解消する方法

 

普段ブラウザはGoogle Chromeを使っているのだが、どこかのタイミングからか、URLバーに表示されるはずのURLがドメインだけに短縮され、マウスカーソルを当てないとすべて表示されないという、個人的にイヤな事象が発生していた。

調べてみると、Google Chromeにおけるフィッシングによる被害を防ぐための新たな取り組みとのことなのだが、アクセスしているURLが一部隠されてしまうのは、個人的には迷惑である。

そこで、元に戻す方法を調べてみた。

当初Chromeの設定で元に戻せるのかと思っていたが、どうも拡張機能を入れて全体を表示させることで解消させるアプローチ委となるようだ。

で、そのツールが下記。

Suspicious Site Reporter

Google謹製なので、おそらく安心していいと思う。

実際入れてみたところ、たちどころにURLが勝手に省略される事象が直った。

メデタシメデタシ

【参考】

アドレスバーの省略 URL を全表示する Chrome拡張機能

U.S. GAO 国防省の15のシステム開発を監査してみて（転載）～米国の国防予算に占めるIT予算化比率は5.1%～

U.S. GAO 国防省の15のシステム開発を監査してみて・・・開発手法やセキュリティについてコメント付けてます:

U.S. GAO 国防省の15のシステム開発を監査した結果を公表しています。。。参考になりますね。。。報告書は63ページあります・・・ 

It requested about $36.1 billion for IT for fiscal year 2020. 

とありますから、国防省はIT予算として361億ドル、約4兆円の予算を要求しているんですね。。。日本の防衛予算は約５兆円ちょっと（2020.12.21 我が国の防衛と予算（案）-令和３年度予算の概要- ）ですから、すごい金額ですね。。。まぁ、国防省の予算が7,000億ドル弱（77兆円）のようですから。。。（ちなみに、人件費・福利厚生費が40％弱を占めるみたいです）

Cost estimates decreased for 11 programs (ranging from .03% to 33.8%) and 10 programs experienced schedule delays (ranging from 1 month to 5 years).

とありますから、15のプログラムのうち11で開発コストが下がっているんですね。でも10のプログラムで遅延が発生していると・・・

10 of the 15 programs reported using commercial off-the-shelf software, which is consistent with DOD guidance to use this software to the extent practicable. Such software can help reduce software development time, allow for faster delivery, and lower life-cycle costs.

とあるので、10/15が市販ソフトを活用しているようですね。。。これはDODの方針にあっていると・・・

In addition, 14 of the 15 programs reported using an iterative software development approach which, according to leading practices, may help reduce cost growth and deliver better results to the customer. However, programs also reported using an older approach to software development, known as waterfall, which could introduce risk for program cost growth because of its linear and sequential phases of development that may be implemented over a longer period of time. Specifically, two programs reported using a waterfall approach in conjunction with an iterative approach, while one was solely using a waterfall approach.

ということは、ウォータフォールの開発手法だけではダメで、うまくアジャイルと組み合わせなさいという感じですかね。。。

In contrast, only eight of the 15 programs reported conducting cybersecurity vulnerability assessments—systematic examinations of an information system or product intended to, among other things, determine the adequacy of security measures and identify security deficiencies. These eight programs experienced fewer increases in planned program costs and fewer schedule delays relative to the programs that did not report using cybersecurity vulnerability assessments.

脆弱性のテストをしているプロジェクトが8/15あって、脆弱性テストをしているプロジェクトの方が、開発遅延やコスト増が少ない感じみたいですね。。。

GAOのこの強力な監査能力が結果的に政府の力を強めているのかもしれないと思うようになってきました。。。

2021年のサイバー脅威、「Nデイ脆弱性」とは！？（転載）

2021年のサイバー脅威、「テレワークの一般化」と「既知の脆弱性」がカギに:

トレンドマイクロは12月22日、脅威動向を予測したレポート「2021年セキュリティ脅威予測」を公開しました。あわせて公式ブログ記事も公開しています。

2020年は、新型コロナウイルス感染症（COVID-19）の拡大により、業務形態、流通網、生活様式など、世界中で幅広い変化が発生しました。サイバーセキュリティにおける脅威も、そうした変化で発生した隙をつくように、さらに巧妙さと危険度が増しています。

こうした背景から「2021年セキュリティ脅威予測」では、まず「自宅のテレワーク環境がサイバー攻撃の弱点になる」「テレワーク用企業向けソフトウェアやクラウドアプリケーションの深刻な脆弱性が狙われる」といった可能性を指摘しており、脆弱なホームネットワークから従業員の自宅のコンピュータを乗っ取って組織ネットワークへ侵入する事例などが予想されています。他方で、既にインターネット上では、脆弱性の影響を受ける特定のVPN機器のリストも公開されており、該当する組織での早急な対応が求められています。

また「新型コロナウイルスに便乗する攻撃キャンペーンの継続」「医療機関が直面するセキュリティリスク」も予測されています。2020年に日本国内では、マスク不足に便乗した偽の通販サイトや偽の給付金の申請サイトなどが確認されました。今後も、感染状況やワクチン関連の情報に偽装した不正サイトや不正メールが横行すると考えられます。一方で、医療機関やワクチン開発関連組織への諜報活動が懸念されます。

そして、サイバー攻撃に悪用される脆弱性（セキュリティ上の欠陥）において、ベンダからの修正プログラム（パッチ）提供などの対応策がない「ゼロデイ脆弱性」だけでなく、修正プログラムが提供されているものの、公開されたばかりでパッチが適用されていない可能性がある既知の脆弱性「Nデイ脆弱性」がより一層問題になると予測されています。

「2021年セキュリティ脅威予測」では、その他にも以下のようなトピックを解説しています。

・攻撃者はホームオフィスを新たな犯罪拠点に

・テレワークの導入によって企業はハイブリッド環境と持続困難なセキュリティアーキテクチャに直面

・外部からアクセス可能なAPIが企業の情報漏えいの攻撃経路に

・パンデミックで進む個人情報の収集と共有に注目するサイバー犯罪者

・セキュリティ強化の推進

「2021年セキュリティ脅威予測」（PDFファイル）は、トレンドマイクロの公式サイトから無償でダウンロード可能です。

バックアップ（非公開）

「Origami Pay」システム停止までを説明したブログエントリが貴重な記録だと評判（転載）～貴重な”しんがり”ネタ～

「Origami Pay」システム停止までを説明したブログエントリが貴重な記録だと評判【やじうまWatch】:

2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。

取り組んだこと

 

決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご提供するという性質上、突然のサービス終了は関係する方々のビジネスに直接的・間接的に大きく影響する可能性もあり、慎重にすすめる必要があります。

今回システム停止を計画するにあたり、下記の要件が存在しました。

• お客さま・加盟店様・その他パートナー様への影響を出来る限り小さくするために、十分な事前告知と準備期間を経てサービス終了を行うこと。
• 障害・不正利用等のシステムリスクを出来るだけ小さくすること。
• サービス終了までのシステム維持コストを出来るだけ小さくすること。

当初から少なくとも半年以上はかかるプロジェクトとなることが見込まれていたため、複数フェーズに分けて段階的に機能を停止していく基本方針を置きました。 対外アナウンスや機能停止は一度行ってしまうと後戻りできないため、下記のように事前計画を入念に行いました。以下ではそれぞれの項目について紹介していきます（便宜上ステップのように順番に記載していますが、実際は途中段階で新しい事実が発覚して前段階に巻き戻ったりといったことを繰り返しながら計画を作っていきました）。

1. 外部へ影響を与える機能・業務の特定
2. 法務・コンプライアンス要件の特定
3. サービス終了計画の作成
4. システム停止計画の作成
5. 計画に沿ったシステム停止と影響確認

1. 外部へ影響を与える機能・業務の特定 

サービスを段階的に停止していくにあたり、外部への影響度・内包されるシステムリスク・維持コストなどの観点から機能や業務を分解していきます。

今回Origami Payサービス終了を計画するにあたり洗い出した機能・業務の一例は以下のようなものです。

• バーコード提示型のインタフェースによるお支払い
• QRコード読み込み型のインタフェースによるお支払い
• クレジットカードを利用したお支払い
• 金融機関口座連携を利用したお支払い
• ウォレット機能を利用したお支払い
• 加盟店様による返金・金額変更
• 加盟店様によるお支払い履歴確認
• 加盟店様への売上金振込
• 一般のお客さまからのお問い合わせ対応
• 加盟店様からのお問い合わせ対応

機能・業務をどこまで細かく分解するかは、「停止タイミングが異なるか」を軸として行いました。例えばOrigami Payではクレジットカードを使ったお支払い方法と、金融機関口座を紐付けたお支払い方法が提供されていましたが、両者では不正利用リスクが異なるために「加盟店でのお支払い」と一括りにするのではなく個別に停止スケジュールを検討することとしました。

2. 法務・コンプライアンス要件の特定

サービスの特性によっては法務・コンプライアンス観点からサービス終了の進め方に要件が存在する可能性があります。

Origami社では資金移動業・第三者型前払式支払手段発行者・電子決済等代行業・クレジットカード番号等取扱契約締結事業者といった各種業法への登録や、PCI-DSSへの準拠を行っていました。 各事業廃止にあたり、リスク管理体制の維持や消費者保護の観点等から法務・コンプライアンスチームと連携して1で特定した機能・業務に抜け漏れがないか、またそれぞれを停止するにあたり注意を要する点がないか密に連携しながら要件を洗い出しました。 例えば資金移動業を廃業するにあたってはお預かりしている残高をお客さまに確実にお返しするために、メール連絡・ウェブサイト告知や官報掲載などのコミュニケーション計画が求められます。

3. サービス終了計画の作成

1で特定した機能・業務それぞれについて停止日・事前告知日等を定めていきます。

法務・コンプライアンス要件を満たすことは当然ですが、外部ステークホルダーの皆様との調整観点で営業・事業開発チームと、社内業務との調整観点でオペレーションチームやコーポレートチームと協力しながら計画していった結果、下図のような9ヶ月にわたるスケジュールが出来上がりました。

細かく全スケジュールに触れていくことは難しいので、システム停止に影響が大きいマイルストーンだけ下記にまとめます。

2020/2 ウォレット機能によるお客さま間送金の停止

2020/3 ウォレット機能によるお支払い停止

2020/4 クレジットカードによるお支払い停止・バーコード提示型のお支払い停止

2020/6 一般のお客さま向けサービスの停止・お客さま向けアプリの配信停止

2020/9 加盟店様向けサービスの停止・加盟店様向けアプリの配信停止

支払い手段ごとに細かく停止時期が異なっていますが、前記のようにシステムリスクや不正利用リスクを早期に小さくしていくことと、外部影響を鑑みて早期に機能を閉じられるかといった現実性をあわせて検討した結果、このように支払手段ごとに段階的な停止を行うこととしました。また、一般のお客さまによる利用が終わった後も返品等による返金・金額変更等が発生する可能性を考慮し、新規のお支払い停止から90日間のバッファ期間を経て加盟店様向けサービスの停止を行うこととしました。

機能の停止とその告知以外にも考慮すべきことはこのタイミングで洗い出します、一例として、広くサービス終了告知を行う際にはそれに便乗したフィッシング詐欺等が発生するリスクもあり、その対策として不正ログイン・不正取引の自動検知・監視体制強化も計画していきました。

4. システム停止計画の作成

サービス停止計画から各フェーズで停止できるサブシステムを特定し、システム停止作業のスケジュール・内容を計画します。

Origami PayはAWS上に構築されたバックエンドシステムとiOS, Android向けに提供されているお客さま向け・加盟店様向けモバイルアプリで構成されていました。バックエンドシステムはウェブアプリケーションの改修でリアルタイムに機能停止を行えますが、モバイルアプリは新しいバージョンをアプリストアに登録しても大多数のお客さまが最新バージョンにアップデートいただくまでにタイムラグがあります。今回はバックエンド側のフラグに合わせて各停止フェーズ向けの画面・挙動に切り替えられる仕掛けを内包したバージョンを事前にアプリストア上で配布し始めておくことで、実際の機能停止タイミングで表示をスムーズに変更する下準備を行いました。

AWS上に存在する内製システムを停止していくことに加えて、システムと接続されている外部サービスや、業務で利用しているクラウドサービスについて利用停止・契約解除タイミングも計画します。 各フェーズで停止する機能から不要となる関連サービスを特定していくのですが、それに加えて最終的にはすべての外部サービス利用が漏れなく終了している必要があります。年次の外部サービス棚卸しが終わった直後だったこともあり、外部サービス台帳を出発点として、各サービスの停止計画を作りました（参考までに下図がOrigamiで作成していた台帳のサンプルになります）。

内部システムと外部サービスの停止計画が決まったら、それをもとにサービス終了までのシステムコストの大まかな見積もりを行います。 AWS環境については構成変更によるコスト推移を完全に予想することが難しいのですが、Billing and Cost Managementを使うことで過去の請求実績の細かい内訳（サービス別・サイズ別・リージョン別など）が分析できるため、そこから各フェーズにおけるシステム停止後のコストを見積もりました。

5. 計画に沿ったシステム停止と影響確認

4のスケジュールにそって機能停止を行います。完全なサービス停止以前では一部機能のみを停止することになるため、予期せぬ影響がでた場合に備えて作業手順を細分化し、切り戻し手順を用意して実施します。数人でダブルチェックを行いながら作業をすすめる必要がありましたが、結果的に関係者が自発的に多く集まったこともあり盤石な体制で多くの作業を進められました。

停止作業・インフラ整理を行った後は数日間AWSコストの監視を行います。システム停止計画で事前に想定していた水準まで日次コストが下がっているかを確認し、想定したコスト減が達成されていない場合は要因を調査・解消します。 Cost Explorerを用いると日次コストのサービス内訳が確認できるので原因分析をしやすくなります。ECS・EC2・RDSなどのComputing / Database系コストは予測しやすいですが、Networking / Governance系等はコスト予想が難しく、目標コストを達成するためにフェーズごとの追加調整なども行いました。

下図が実際にサービスを運用していたAWSアカウントのコスト推移です。全機能の提供を終了したのは9月、そのインフラ整理を行ったのが10月なので11月にコストが大きく下がっていますが、その途中経過でもほぼ事前計画どおりの水準までコストを削減できました。事前にコスト計画を定めて進めたことで金銭的なコストを抑えられたことも勿論ですが、管理すべきリソースが減り、結果的にシステムリスク低減・人的な運用負荷の軽減にもつながりました。

6. (おまけ) Twitterをエゴサしてエモい気持ちになる

まったく余談ですが、事前告知でお支払い機能が停止される日時までお伝えしていたこともあり、停止前後はTwitter検索すると感想や思い出を投稿してくださった方もいらっしゃいました。中には、サービスが止まる直前を狙って記念決済をしてくださっているツイートなどもあり気持ちが温まるタイムラインを眺めながらシステム停止を行っていたりしました。

さいごに

これだけ慎重に時間をかけてサービスを終了していくという経験は初めてだった為、計画段階も実施段階も途中過程でいろいろな学びがありました。しかしそれでも運営してきたサービスを終了するというのは決して楽しい話ではなく、最後まで一緒にがんばってくれた関係者の方々には感謝してもしきれません。 サービス終了なんて頻繁に立ち会うことではないかもしれませんが、本投稿が将来そんなタイミングを担当される方の参考になれば幸いです。

私自身も含め、今回サービス終了を一緒に進めてくれたメンバーも参画してメルペイでは日々サービス開発を進めています。ミッション・バリューに共感できるエンジニアリングマネージャー・エンジニアを募集していますので、一緒に働ける仲間をお待ちしております。

【参考】

決済サービスを閉じるときのやることリスト